Poly Edge network passthrough failing

[justinmarthaler]

We have deployed Poly Edge e350 phone to our desk and have the network passthrough the phone to the PC.  In the last several months, we have had several calls about people that could not access the network on their computer.  After troubleshooting the problem, we determined the problem was addressed by rebooting the phone.  Once the phone is rebooted, network traffic passes normally.  The phones are currently on firmware version 8.2.3.0870.  Has anyone else experience this issue?  

One idea we've considered for handling this is to proactively reboot the phones during our weekly maintenance window.  Is there a way to perform that action automatically at scale?

[sparrow]

We experienced the same thing about a year and a half ago, but at the time, Poly only had the VVX line of phones and after a weekend firmware upgrade push from Zoom, the data passthrough port stopped working. Debugging the issue, it came down to the phone dropping dot1x authentication on the data connection. We disabled dot1x on those ports temporarily while Zoom worked with Poly to release a fix. If you can? Work with Zoom on gathering debugs from the phone, maybe it's a similar bug.

[wreckITralph]

We're experiencing this as well. This has been an ongoing issue in my company for a few months now. My first step in troubleshooting anything network-related at this point is rebooting the phone. We have the e350, e320 and e220s and are experiencing this on all of them. 

[Eliot]

hi @justinmarthaler 

i do not see anthing in the hp/poly release notes for 8.2.3.

Poly Documentation Library

you might try doing a reset to factory on your hp/poly edge e350 desk phones experiencing the issue.

you could also open support tickets with hp/poly and zoom.

Did my response answer your question? If so, please don't forget to mark the reply as an accepted solution.

thanks,  eliot

[justinmarthaler]

@Eliot - thanks for looking at the documentation library.  We haven't tried a factory reset as the problem doesn't seem to be recurring on the same phones.  We'll start keeping a list of phones that have needed a restart to pass traffic and see if there are any commonalities.  

I opened a ticket with Zoom but there wasn't much value in the response.  Basically, Zoom can't reboot the phones in batch, no one else is reporting this issue, and you should run some network tests and check your internet connectivity.  So that wasn't overly helpful.  And I shudder at the thought of engaging HP support.  My past experience has been abysmal at best.

[sparrow]

You can reboot all phones in your account or by site yourself. Go to phone system management => phones and devices => top right corner select Resync by account/site. You might also have some luck finding a parameter on the Phone Admin Guide to schedule reboots. Zoom unfortunately does not support nor troubleshoot local networks. Your only option would be to work with HP/Poly on debugging the issue. 

[wreckITralph]

I've opened a ticket with HP on this. I'll try to remember to update you if I hear of a resolution.

[mosinjack]

We've encountered a similar issue with the Poly Edge e350 phones, where rebooting resolves the passthrough problem. Rebooting during the weekly maintenance window seems like a good idea. I wonder if there's a way to automate this process across multiple devices, maybe through a script or system integration. Looking forward to hearing if others have found a more permanent solution!

[wreckITralph]

I've got a feature request in with Zoom for some better management tools -- like scheduled reboots of phone devices. Hoping it gets some traction.

[sparrow]

If you have a Zoom account team like a TAM or CSM? I'd start there. You can also pitch that idea as a separate postings in this Zoom Phone community as a feature enhancement request and get others to back you. I'll give you mine. 

[wreckITralph]

We do have a TAM. As soon as I get access to the feature requests section of this thing, I’ll post there. It’s not currently working for me. 

[justinmarthaler]

@mosinjack - in your experience, are the PCs that are not able to connect to the network getting their IP address via DHCP?  Have you been able to check whether the PCs have a normally assigned address, or do they have an IP address starting with 169 which means it didn't acquire a valid IP address from DHCP (at least on Windows).  We had an instance yesterday where we spent a bit more time troubleshooting and found the PC hadn't acquired a DHCP address.  The PC had been unused for a few days so the lease may have expired.  We rebooted the phone to get things working for the individual, but afterward we wondering if a different device with a static IP attached to the phone would have worked.  In other words, is all network traffic failing to pass through or is it just some types of traffic.  With the next person that calls about this issue, we're hoping to test the idea of plugging in a separate device with a static IP address.  I'll report back our findings, but would like to know if anyone else has tried this.

[wreckITralph]

In our case, the PC is showing a 169.x.x.x IP. We initially thought it just wasn’t getting DHCP but my network team says when this happens, they can’t even see the PC on the switch. It’s like the phone’s pass through port completely shuts down. 

[justinmarthaler]

Oh, that's good information.  I'll have our network team take a look at the switches to see if we're experiencing the same behavior.  My guess is that the port is essentially shutting down, but trying to look at it from various angles to better understand it.  By the way, we also opened a ticket with HP, but we don't have a TAM so I'm not optimistic we'll get much traction.

[sparrow]

I recommend you point your phone logs to an external Syslog Server. HP is going to ask you to enable quite a few module log levels and the internal phone buffer is going to be overwritten rather quickly. If you don't have a sys log server? You can always use a desktop syslog application to capture those phone logs. 

[sparrow]

I've not tried this myself, but here are a few parameters that should work. Use a Zoom phone template and sync with a test device before applying to all phones. 

Scheduled Reboot Parameters

Use the following parameters to configure scheduled reboot times for Poly phones.

prov.scheduledReboot.enabled

0 (default)— Disables scheduled reboot.

1—Enables scheduled reboot.

prov.scheduledReboot.periodDays

Specify the time in days between scheduled reboots.

1 day (default)

1–365 days

prov.scheduledReboot.time

Specify a time to reboot the Poly phone. Use the 24 hour time format (hh:mm).

03:00 (default)

prov.scheduledReboot.timeRandomEnd

If this parameter is set to a specific time, the scheduled reboot occurs at a random time between the time set for prov.scheduledReboot.time and prov.scheduledReboot.timeRandomEnd. The time is in 24-hour format.

0–5 hours

hh:mm

[justinmarthaler]

Thank you for finding and posting those settings @sparrow.  We come across those today as well.  We are considering applying those to a test group of devices, but our main concern is the unpredictability of the reboot.  We have a maintenance window on Saturday evenings, but the reboot interval is number of days between scheduled reboots.  If we schedule the first one on Saturday, will it always reboot on Saturday if our interval is 7?  What if the phone reboots for any other reason?  Does the interval start 7 days after that reboot or 7 days after the scheduled reboot?  And if we bring a new phone online, would we only want to do that on Saturdays?

If we do test this out, I'll post back with our findings so others can try this out.

[justinmarthaler]

HP Support got back to me and reported that other customers are having this issue and it has been "resolved" by disabling power saving mode.  You can deploy that setting by adding these lines to your provisioning template:

device.set="1"              

powerSaving.Enable="0"

We're currently pushing that update out to our phones and will see how it performs.  

[wreckITralph]

@justinmarthaler I got that email from HP the same day you posted this. Did some testing to make sure it worked right, but added that to about 4000 phones' provisioning templates this morning. How has it worked out for you?

[ITRSavage]

We've had the powerSaving.Enable="0" setting pushed to our E100 phones since our initial deployment last year and continue to struggle with network passthrough dropping.

[justinmarthaler]

@ITRSavage - thank you for posting.  That reminded me to report back to the group.  I am having the same experience after setting powerSaving.Enable = 0 with phones still experiencing the issue with network passthrough.  I do still have a case open with HP and the engineer wants some packet captures of the phone startup experience to see how CDP and LLDP are handled at startup in our environment.

[MoJoPBS]

Have you found a fix for this? We're actively having this issue with our e220 and other models. Utilizing wireshark I see TCP Spurious Retransmissions destroying our 20Gb ISP connection off a single device. Any ideas?

[MoJoPBS]

Has a fix been found for this issue? We're actively having the issue when any polycom phone is bridged to a computer it destroys our internet. Utilizing wireshark I see TCP Spurious Retransmissions from zoom IP address and my device.

[SW916]

We are now having this issue with Edge E550 on firmware 8.3.1.0614.  My switches are Cisco 9300X running IOS XE 17.12.5.  My Cisco port config is cookie cutter for phone + PC. 

Overnight, the PC loses connection to the network and the user will report it in the morning. A reboot of the phone fixes the issue.  It is sporadic but I have had probably four users report it this week.  I am going to have to try rolling these phones back to the previous firmware and locking it so Zoom does not update it. 

We just became Zoom Phone + Poly customers with 1200+ phone numbers ported over in the past 6 weeks.  This is disappointing - never had this problem with our Avaya phones.  Who is doing QC on these Poly phones and their firmware??

interface TenGigabitEthernet3/0/37
switchport access vlan 117
switchport mode access
switchport nonegotiate
switchport voice vlan 17
spanning-tree portfast
spanning-tree bpduguard enable

DB17F-C9300X-SW17#sh lldp neigh te3/0/37 deta
------------------------------------------------
Local Intf: Te3/0/37
Local Intf service instance: -
Chassis id: SAC-00BXDBPR3
Port id: c45a.b1df.2b92
Port Description - not advertised
System Name - not advertised
System Description - not advertised

Time remaining: 3003 seconds
System Capabilities - not advertised
Enabled Capabilities - not advertised
Management Addresses - not advertised
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(FD)
Media Attachment Unit type - not advertised
Vlan ID: - not advertised
Peer Source MAC: c45a.b1df.2b92
PoE+ Power-via-MDI TLV:
Power Pair: Signal
Power Class: Class 4
Power Device Type: Type 2 PD
Power Source: PSE
Power Priority: high
Power Requested: 20000 mW
Power Allocated: 20000 mW

MED Information:

MED Codes:
(NP) Network Policy, (LI) Location Identification
(PS) Power Source Entity, (PD) Power Device
(IN) Inventory

Inventory information - not advertised
Capabilities:
Device type: Endpoint Class I
Network Policies - not advertised
Power requirements - not advertised
Location - not advertised

------------------------------------------------
Local Intf: Te3/0/37
Local Intf service instance: -
Chassis id: 10.2.17.158
Port id: 4825.676a.9e33
Port Description: 1
System Name: Poly Edge E550

System Description:
Poly;Edge-Edge_E550;3111-87050-001,C;SIP/8.3.1.0614/08-Aug-25 11:19;UP/8.3.1.0614/08-Aug-25 11:19;

Time remaining: 99 seconds
System Capabilities: B,T
Enabled Capabilities: B,T
Management Addresses:
IP: 10.2.17.158
Auto Negotiation - supported, enabled
Physical media capabilities:
1000baseT(FD)
100base-TX(FD)
100base-TX(HD)
10base-T(FD)
10base-T(HD)
Media Attachment Unit type: 30
Vlan ID: - not advertised
Peer Source MAC: 4825.676a.9e33
PoE+ Power-via-MDI TLV:
Power Pair: Signal
Power Class: Class 4
Power Device Type: Type 2 PD
Power Source: PSE
Power Priority: high
Power Requested: 20000 mW
Power Allocated: 20000 mW

MED Information:

MED Codes:
(NP) Network Policy, (LI) Location Identification
(PS) Power Source Entity, (PD) Power Device
(IN) Inventory

H/W revision: 3111-87050-001,C
F/W revision: UP/8.3.1.0614/08-Aug-25 11:19
S/W revision: SIP/8.3.1.0614/08-Aug-25 11:19
Serial number: 4825676a9e33
Manufacturer: Poly
Model: Edge-Edge_E550
Capabilities: NP, PD, IN
Device type: Endpoint Class III
Network Policy(Voice): VLAN 17, tagged, Layer-2 priority: 5, DSCP: 46
Network Policy(Voice Signal): VLAN 17, tagged, Layer-2 priority: 5, DSCP: 44
Power requirements - not advertised
Location - not advertised

Total entries displayed: 2

[Eliot]

hi @SW916 

I understand that out of 1200 + phones, 4 PCs connected to your HP Poly Edge E series desk phone PC ports lost connection to the network overnight and needed to be rebooted last week. 

Root cause(s) should be determined as to why the PCs lost network connectivity overnight.

Because it appears to only occur overnight, maybe it has something to do with a power saving feature on the HP Poly desk phones.  This has been mentioned in this thread.

I would check the HP Poly Edge E series hardware revision, i.e. REV HA on the back of each phone to see if there are certain revisions involved in this issue.

It is possible that something is wrong with the HP Poly Edge E series phone including the PC port, the switch, switch port, the cables and patch cords, and or the PC.  Information on each PC that lost its network connection overnight and needed to be rebooted during the past 6 weeks could be helpful in troubleshooting. 

Do some of the same PC experience this issue more than once?  If so, you may want to consider having HP Poly replace the phones associated with network connectivity loss.   

I would suggest you consider meeting with all the parties involved such as your HP Poly account team, your Zoom account team, your Zoom partner (if involved), and your Cisco team. 

You may want to open support tickets with HP Poly and other involved vendors so that the issue is documented with HP Poly and other involved vendors. 

HP Poly desk phones have extensive logs which may be helpful in HP Poly diagnosing the issue.  Different levels of logging (more extensive) may be set for phones involved in PC network connectivity issues.

I would review the HP Poly release notes for all recent Edge E series firmware releases to see what they fixed, known issues, and possible workarounds.

https://lens.poly.com/manage/software-versions?tenantId=a697b29d-ba46-44e2-961e-3cf62aeab422

To deal with the immediate problem, I suggest you discuss locking the firmware on these phones to a previous version with your HP Poly and Zoom team.  Consider the impact of loss of issues fixed in 8.3.1.064.  Please see Zoom support article locking the firmware.

Setting up firmware update rules

https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0067686

Firmware update guidelines

https://support.zoom.com/hc/en/article?id=zm_kb&sysparm_article=KB0067890

Did my response answer your question? If so, please don't forget to mark the reply as an accepted solution.

thanks,  eliot

[justinmarthaler]

We've been working with HP on this for months.  We're currently testing an 8.4 firmware version that is supposed to address the issue.  Since it's difficult to test non-Zoom approved firmware, we only have it on two phones on the beta build and with the random nature of the problem, it's unlikely we'll know for certain if the issue is fixed.  However, HP is aware of the problem and thinks this can fix the issue.

So, you can either wait for the 8.4 release or start a ticket with HP now so they have another customer with the issue in their database.  They had us collect various packet captures when it happened.  I wouldn't open a ticket with Zoom as they determined it wasn't their issue and pushed us back to HP.

[SW916]

if HP has acknowledged that it is an issue at least in some environments, then that is promising. Because the first step in fixing a problem is acknowledging that you have one, and some vendors have to be lead kicking and screaming to that realization.

For now, I have a test/dev config template assigned to a group of phones which disables power saving mode. I also created a site that I have moved a handful of phones into, to test the firmware downgrade.

I have a TCL script running on my Ciscos now via EEM (every 10 minutes) which logs a state change whenever a port drops or adds a PC mac in/out of the table from the user/data Vlan, so that I can correlate user reports with time stamps of when the port actually got weird.   I do believe I have had one user report it mid-day but they may have come in late, so this will help get a better understanding of when it happens (so long as their PC stays powered on).

When they had you do a sniff, where did they have you place the sniffer - between the phone and PC or the phone and switch port?  I may open a ticket with HP after I collect some more data.

Thanks,