Comware

I have an HPE 1830 switch which is exhibiting some odd PoE delivery issues.

Connected to it are a couple of IP Telephones which work fine. The one i have on test currently is an Audiocodes C450HD Teams handset. 

When I go off-hook or answer a call, the handset reboots and the switch log shows PoE overload.

The odd thing about this is I have tried two different C450 handsets, several PoE ports and the fault still remains.

The phone is 802.11af so the 802.11at rated switch should be more than enough to run it. The total PoE load across all ports is currently 18 watts.

Hi @Caesium_ !

I am not sure about this particular switch, but some PoE switches shut the port down when PoE device requests more power than its class allows. I suspect that the phone reports a class which power limit is enough when it operates standalone, but when you connect a headset, the phone needs more power, but this amount is more than device's reported class allows. And when it requests this amount, switch thinks it's an error and shuts the port down.

I would try to set PoE settings (Power Over Ethernet > Port Configuration) of such ports to:
Priority: High
Power Limit Type: User and set the maximum value available. This should allow the PSE in the switch to supply maximum power of 15.4W (or 30W if High Power Mode is enabled) to the device ignoring its class.

Hi there, 

thanks for this, I have ensured the settings are as per below. 

The power delivery is set to static, the port is set to High Priority, High Power and User limit 30w but it's still overloading. 

I cannot see how much power exactly it's requesting but I'm struggling to understand how it can be drawing over 30 watts to cause an over load shutdown.

Your phones don't request more than 30W, you said they are 802.11af devices, so the theoretical limit for them is 15.4W In order to request more they need to negotiate additional power following 802.11at standard (typically using LLDP-MED) which obviously can't happen since they dont' support this protocol.

The issue is not that the phones request more than 15W, it is a little bit different. For example, when the phone is connected to the switch it initially reports its class as Class 2 and the switch knows that allowed power for such devices is 3.84-6.49 W. The phone boots up, everything is fine, but at the time you anwer the call from the headset the phone needs additional power to make the headset working. And this power might go over the 6.49W allowed, like 7.5 W for example. However, as I mentioned before some PSE implementations in PoE switches consider such requests as violation and shut the port down to avoid any possible damage. So it's not the lack of power budget in the switch, it's not the phone which requests more than the standard's maximum allowed power - it's just a violation of power limit for certain class. Normally when a device knows that it may request more than 6.49 W it doesn't report itself as Class 2, but it announces Class 3 that allows 6.49 - 12.95 W. We have two possibilites here - either the phone reports incorrect class (by 'incorrect' here I mean the class which upper limit is lower than the phone requests when goes off-hook with headset connected) or the switch incorrectly interprets the device's class reported.

My expectation is that the Power Limit Type: User is the solution, but since you have already tried that, seems like it's either not or it's a bug. However, before opening a case with support, please update your switch firmware, update your phone's firmware and give it a try. If the issue is still there, open a support ticket, as we need to dig deeper into diagnostic details of PoE in this switch and since it's neither ProVision nor Comware the troubleshooting requires special tools.

Thanks Ivan. 

I have procured a Unifi network switch which reports PoE consumption on a per port basis and it shows the IPT as 5.40w and the phone does not reboot on this switch.

My HPE is on the latest firmware already as I prempted that as an issue. The IPT is also on the latest available firmware. 

I think I will have to raise a support ticket.

Hi @Caesium_ !

Could you let us know if you logged a support ticket for this issue?

Thank you!

Hi There, 

I have raised it but progress on the ticket seems slow going. 

I have connected the IPT to a Unifi POE switch for testing purposes and have experienced no reboots at all. The unifi switch has less of a power budget (150w) than the OfficeConnect (180w) and reports the handset to be a class 3 and drawing around 6w of power. Well within the capacity of the HPE yet the reboots of the handset remain unsolved.

Hi @Caesium_ !

Does the phone draws around 6 W even when headset is used? What I would try to check (if Unify has this feature) is class reported by the device and power consumption in three cases:

1. Phone is idle, no active call
2. Phone is off-hook, active call, external headset is not used
3. Phone is off-hook, active call, external headset is used

Since Unify works in a stable manner, it would give us more informaiton on those parameters during different states of the phone. What is of special interest for us is difference between case 2 and 3, if I understand correctly the transition from case 2 to 3 is the moment when 1830 flaps the port. I am sure if you attach that info to the case, it will help our Support to illustrate the issue and if there is a need of lab test - to set up a lab test bed to reproduce the issue.

I am sure the power budget is not an issue here. What I am still suspecting it's bug either in the phones or in the 1830. Unfortunately the fact phones work with 3rd party vendor doesn't mean they follow PoE standards strictly, despite the fact it looks like this. Depending on the firmware of particular PSE switch may just ignore incorrect behavior of powered device and continue working.

Phone idle 5.34w

Off hook on speaker 5.80w

There is no headset in this equation, just speakerphone and handset receiver,

I cannot get realtime PoE consumption as i suspect the Unifi switch refresh of PoE wattage dsiplay is not immediate.

Sorry, my mistake, there is no headset of course. Since the power consumption stays below 6 w, it must be a bug in PSE and I hope this will get resolved soon by our Support.

An update on the case. 

I have sent various snmp logs and screenshots of the issue but after being asked to do SNMP walk tests of both the HPE switch and the Unifi switch I decided to call time on this issue. 

I am a Comms Solution Architect, not a network engineer and I do not have the time or inclination to spend time running advanced diagnostics on the HPE switch when the Unifi switch I have here does not exhibit the same fault.

The IP handset that was rebooting due to power overload is working perfectly on the Unifi switch, which means no matter how much diagnostics I do on the HPE, it's still not going to help. The issue is not with the IP Telephone handset but with the OfficeConnect switch.

The final straw for me was when I operated the mode switch on the front of the HPE OfficeConnect and the entire switch rebooted. It is clearly faulty and HPE support are not interested unless I run SNMP walk tests, which I view as pointless.

I have now replaced my HPE with a Unifi USW switch which has been in production service for 5 days now and no issues with rebooting whatsoever.

I'm very disappointed in this "enterprise grade" switch which I'll now dispose of, or use as a doorstop.