C3560-C2960x - PoE / ILPOWER-5-IEEE_DISCONNECT

[Alessandro Bellina]

Hi everyone,

I'll make a small introduction, I work for a GDO retail trade in Italy and in recent months we have been implementing the AP of a multinational company for management of electronic labels in our stores.
Their access points have strange behavior on the ports of our C3560 and C2960X switches (at the moment I don't see any problems in the shops where we have the C9200Ls). Basically these initial APs seem to work fine, but after a while they go offline and you notice some strange behavior on the switch port.
I hypothesized a problem on the power, I analyzed the current that is absorbed by the AP and tried to force the maximum power of the port (although these APs are 802.1af compatible), but the result does not change.
The multinational company's technical department keeps insinuating that our switches burn the PoE port of their APs. Of course, I find this very strange.
I started hypothesizing an incompatibility of the APs with the C3560/C2960 series but I still don't have concrete data.

Attached logs  (I don't know if they are sufficient..)

Switch in question:

Switch Ports Model SW Version SW Image
------ ----- ----- ---------- ----------
* 1 52 WS-C3560-48PS 12.2(55)SE6 C3560-IPBASEK9-M
------ ----- ----- ---------- ----------
* 1 52 WS-C2960X-48LPS-L 15.2(2)E3 C2960X-UNIVERSALK9-M

[balaji.bandi]

what AP Model ?

Make sure Device Earthing / Grounding ok - seen some shops have bad grounding causing AP to burn my experience.

Try also :

power inline never

power inline auto

Note : Cat 9200 you do not see this issue right ?

[Alessandro Bellina]

The APs aren't Cisco.. with Cisco APs (any series) I've never had this problems.
I've attached the specs of the if it helps.

I had already tried with power inline, this is the result:

sw060123(config)#int Gi1/0/22
sw060123(config-if)#power inline never
sw060123(config-if)#power inline auto
Mar 8 14:13:45.462 CET: %ILPOWER-7-DETECT: Interface Gi1/0/22: Power Device detected: IEEE PD
Mar 8 14:13:46.616 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_PD_DETECTED_S, event= IEEE_PWR_GOOD_EV
Mar 8 14:13:46.616 CET: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/22: Power granted
Mar 8 14:13:46.762 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_LINK_UP_S, event= IEEE_PD_REMOVAL_EV
Mar 8 14:13:46.794 CET: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi1/0/22: PD removed
Mar 8 14:13:46.794 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_DETECTING_S, event= ILP_POWER_POLICE_DISABLE_EV
Mar 8 14:13:50.405 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_DETECTING_S, event= IEEE_CLASS_DONE_EV
Mar 8 14:13:50.405 CET: %ILPOWER-7-DETECT: Interface Gi1/0/22: Power Device detected: IEEE PD
Mar 8 14:13:51.576 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_PD_DETECTED_S, event= IEEE_PWR_GOOD_EV
Mar 8 14:13:51.576 CET: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/22: Power granted
Mar 8 14:13:51.880 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_LINK_UP_S, event= IEEE_PD_REMOVAL_EV
Mar 8 14:13:51.915 CET: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi1/0/22: PD removed
Mar 8 14:13:51.915 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_DETECTING_S, event= ILP_POWER_POLICE_DISABLE_EV
Mar 8 14:13:55.246 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_DETECTING_S, event= IEEE_CLASS_DONE_EV
Mar 8 14:13:55.246 CET: %ILPOWER-7-DETECT: Interface Gi1/0/22: Power Device detected: IEEE PD
Mar 8 14:13:56.504 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_PD_DETECTED_S, event= IEEE_PWR_GOOD_EV
Mar 8 14:13:56.504 CET: %ILPOWER-5-POWER_GRANTED: Interface Gi1/0/22: Power granted
Mar 8 14:13:56.599 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_LINK_UP_S, event= IEEE_PD_REMOVAL_EV
Mar 8 14:13:56.637 CET: %ILPOWER-5-IEEE_DISCONNECT: Interface Gi1/0/22: PD removed
Mar 8 14:13:56.637 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_DETECTING_S, event= ILP_POWER_POLICE_DISABLE_EV
Mar 8 14:14:00.038 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_DETECTING_S, event= IEEE_CLASS_DONE_EV
Mar 8 14:14:00.038 CET: %ILPOWER-7-DETECT: Interface Gi1/0/22: Power Device detected: IEEE PD
Mar 8 14:14:01.279 CET: ILP uses DC Disconnect(Gi1/0/22): state= ILP_PD_DETECTED_S, event= IEEE_PWR_GOOD_EV

[Alessandro Bellina]

Correct, on the C9200L I haven't encountered any problems yet.
I assumed that the AP isn't really 802.1af compatible, so by not doing a proper negotiation the AP (for his mistake), requests more Watt from the switch than it can handle..
A hypothesis that I can imagine on PoE+ switches, such as the 2960x, but which doesn'tt apply to C3560 switches since they only have PoE and therefore deliver a maximum of 15.4W

What do you think?
How can I check it? Or prove it's not the switch's fault?

Thak's you so much

[Leo Laohoo]

IOS-XE has LLDP enabled by default. 

Classic IOS has LLDP disabled by default.

[Alessandro Bellina]

LLDP is enabled on switches, but isn't present and can be activated on custom APs

[Leo Laohoo]

Post the complete output to the command "sh interface Gi 1/0/22 controll".

[Alessandro Bellina]

GigabitEthernet1/0/22 is down, line protocol is down (notconnect)
Hardware is Gigabit Ethernet, address is ****.****.**** (bia ****.****.**** )
MTU 1500 bytes, BW 100000 Kbit/sec, DLY 100 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Auto-duplex, Auto-speed, media type is 10/100/1000BaseTX
input flow-control is off, output flow-control is unsupported
ARP type: ARPA, ARP Timeout 04:00:00
Last input never, output 2w6d, output hang never
Last clearing of "show interface" counters never
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
2555743 packets input, 315237600 bytes, 0 no buffer
Received 31058 broadcasts (30967 multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 watchdog, 30967 multicast, 0 pause input
0 input packets with dribble condition detected
2674009 packets output, 306530294 bytes, 0 underruns
0 output errors, 0 collisions, 4 interface resets
0 unknown protocol drops
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier, 0 pause output
0 output buffer failures, 0 output buffers swapped out

Transmit GigabitEthernet1/0/22 Receive
306530358 Bytes 315238158 Bytes
1924495 Unicast frames 2524686 Unicast frames
726755 Multicast frames 30967 Multicast frames
22760 Broadcast frames 91 Broadcast frames
0 Too old frames 312423443 Unicast bytes
0 Deferred frames 2787039 Multicast bytes
0 MTU exceeded frames 27676 Broadcast bytes
0 1 collision frames 0 Alignment errors
0 2 collision frames 0 FCS errors
0 3 collision frames 0 Oversize frames
0 4 collision frames 0 Undersize frames
0 5 collision frames 0 Collision fragments
0 6 collision frames
0 7 collision frames 1229442 Minimum size frames
0 8 collision frames 1003560 65 to 127 byte frames
0 9 collision frames 130908 128 to 255 byte frames
0 10 collision frames 122571 256 to 511 byte frames
0 11 collision frames 48780 512 to 1023 byte frames
0 12 collision frames 20483 1024 to 1518 byte frames
0 13 collision frames 0 Overrun frames
0 14 collision frames 0 Pause frames
0 15 collision frames
0 Excessive collisions 0 Symbol error frames
0 Late collisions 0 Invalid frames, too large
0 VLAN discard frames 0 Valid frames, too large
0 Excess defer frames 0 Invalid frames, too small
1265812 64 byte frames 0 Valid frames, too small
950553 127 byte frames
322455 255 byte frames 0 Too old frames
90002 511 byte frames 0 Valid oversize frames
32370 1023 byte frames 0 System FCS error frames
12818 1518 byte frames 0 RxPortFifoFull drop frame
0 Too large frames
0 Good (1 coll) frames
0 Good (>1 coll) frames

[Leo Laohoo]

The way I see it, whatever is connected to Gi1/0/22 is crashing.

[Alessandro Bellina]

No because if I connect the same AP in another port or another switch the problem is the same.. The company that owns the custom APs, told me that the access points have a burnt port and that the fault is the switch, because supplied them with too much current.. I don't think this is possible, because even if the AP doesn't have LLDP protocol, the switch allocates (in this case) maximum 15.4W.. it's not that it transmits all of them, allocates!
Do you think I can do anything else? Or another test or limits on configuration? 

[balaji.bandi]

now sure what AP model is this do you have any documents? it says 802.af ( that is up to 15.4W) but the document you provided required only 5W is this correct to work AP?

is the all the AP get burned due to switch (personally I do not believe that)

[Leo Laohoo]

---

@Alessandro Bellina wrote:
told me that the access points have a burnt port and that the fault is the switch 

---

Actually, that is part correct.  There is a power module regulator.  If that regulator is set for low power and something is force-feeding 15.4WAC, it can burn out that regulator.  

I have seen it only happen to a particular client. 

---

@Alessandro Bellina wrote:
Do you think I can do anything else? 

---

Upgrade the IOS of both switches.  

For the 3560, upgrade to 12.2(55)SE12.  For the 2960X, upgrade to 15.2(7)E7.  

[Alessandro Bellina]

So I'll answer you in order on all the points:

The AP documents I added should be correct, because sent me directly from the manufacturer. I hope..
The only doubt that came to me is that the AP, during the classification event (where in this case it returns the value of class 3), the AP for some reason returns a wrong class compared to the one that actually necessaries..
I don't know how possible that is and if there is a real possibility of a failure due to this.
Perhaps the only one could (given that the AP consumes maximum only 3W) set the switch port to a maximum of 7W, thus forcing it to become class 2?

For updates, do you think there might be some bugs in the releases I currently have on the switches?
However, in the next few days I can updating without problems..