Here are the notes from the Cisco Engineer that assisted with troubleshooting this issue,
"You have class-2 PoE IP telephones that are using approximately 2.6 -
3.0 Watts when in sleep mode. When resuming
operation, the devices
request a power value of 65 via LLDP. During
this transition, the
phones are being reset by the Cisco switch.
Debugging this issue on the
switch we found the following:
014173: May 16 16:21:32.550: ilpower_powerman_request_from_lldp:
rx lldp
power class tlv from port GigabitEthernet0/19
014174: May 16 16:21:32.550: Shut down interface
(Gi0/19) since
consumption power 6500 is greater than allocation 3000
Power value of 65 allows utilization between 3.84 and
6.49 W. The
problem isn't that the device is requesting more power
than allowed by
the class, rather that it is attempting to use LLDP to
request higher
power. According to the ANSI standard, this type
of request requires a
reload of the device.
###################
10.2.5.4 Power value
The Power Value field shall represent the maximum
power consumption of
an Endpoint Device or the minimum power available from
a PSE port of a
Network Connectivity Device when the LLDPDU is
transmitted. It shall not
be used to indicate instantaneous variations of power
required or
offered at the time of transmission of the LLDPDU.
A PD Endpoint Device that requires more power than
previously
advertised, due to a hardware reconfiguration, shall
not advertise a
higher power value than is currently advertised by the
PSE Network
Connectivity Device it is connected to on that port.
If the PD Endpoint Device requires power greater than
either the power
value currently advertised by the PSE Network
Connectivity Device or the
upper power limit of the corresponding IEEE 802.3af
power class, then it
must renegotiate this new power limit by resetting the
port (i.e. by
triggering renegotiation of power at the IEEE 802.3af
level).
Therefore, the
reboot is expected behavior. As a workaround to the
issue, the power TLV was disabled from the LLDP field as the Cisco Engineer suggested.
RESOLVED with Lync Server CU4 (Novemeber) patch!!!
This issue was resolved back in November with the Cumulative Update 4 firmware release.
ReplyDeleteThank you Jeff, I'll pass this information along to the network team!!!
ReplyDelete