Poly Edge network passthrough failing | Community
Skip to main content
Explorer
April 9, 2025
Question

Poly Edge network passthrough failing

  • April 9, 2025
  • 14 replies
  • 46 views

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?

 

 

14 replies

Newcomer
November 3, 2025

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.

Newcomer
November 5, 2025

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



Community Super Champion | Partner
November 6, 2025

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

 

Explorer
November 6, 2025

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.

Newcomer
November 6, 2025

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,