NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
technotechnotec
Feb 01, 2019Guide
Voice VLAN command - LLDP seems to stop working
I have a strange issue with the voice vlan command that I'm trying to isolate between our switches and Shoretel phones, but it seems there's no debug options for LLDP on this switch.
We use the...
- Oct 06, 2019
FWIW this issue seems to be fixed. Originally the config was
interface 1/0/1
voice vlan 10
switchport mode access
switchport access vlan 20
But the switch would randomly stop passing the tagged VLAN traffic. I changed the config to:
interface 1/0/1
voice vlan 10
switchport mode trunk
switchport trunk native vlan 20
switchport trunk allowed vlan 10,20
I haven't had a single DHCP failure/VLAN tag drop since moving to this config.
This behavior seems to only occur on the M4300 series - the M4100 actually rejects switchport mode access as a valid option when using voice VLAN (I have those access ports configured in general mode but I'll be updating them later for the sake of consistency). Maybe it would be nice in future updates to prompt users to use a trunk config when enabling voice VLAN on switchports so they don't spend their time flailing about like I did (this problem lasted for like, seven or eight months!). :)
To be clear, it wasn't LLDP failing to maintain the voice VLAN tag, it was the switch refusing to pass tagged traffic and the phone dropping the VLAN tag after DHCP repeatedly failed (which is normal Mitel/Shoretel behavior).
If anyone else googles this problem hopefully they find this post. :) :womanvery-happy:
DaneA
Feb 04, 2019NETGEAR Employee Retired
Hi technotechnotec,
Were you able to update the firmware of the M4300-52G-PoE+ switch to v12.0.7.10? If yes, what are your observations?
Let me share the link and it might help:
Regards,
DaneA
NETGEAR Community Team
- technotechnotecFeb 05, 2019Guide
Hi DaneA !
The guide you posted is a little confusing to me.
I remember reading somewhere that auto-voip and the voice vlan command don't work together - it has to be one or the other. I have both options in production in separate environments and I've done a LOT of testing with it, so I feel confident stating the following:
auto-voip
- Moves the phones to a defined VLAN based on OUI and passes traffic UNTAGGED. The switchport has to be configured in general mode for this to work.
- Here's my production config:
auto-voip vlan 10
auto-voip oui 00:10:49 [OUI for Shoretel] oui-desc "Phones"!
interface x/0/x
auto-voip oui-based
description 'PC|Phone'
vlan pvid 20
vlan participation exclude 1
vlan participation include 20
exitIn this case, option 156 in DHCP only gives the location of the config server for the phone and no VLAN information is passed to the phones. The phones pass their traffic untagged over VLAN 10.
This config works fine, but the biggest issue I have with auto-voip is that it "locks" the configured voice VLAN so that no references to it can be removed from the switch. In practice, this also means it automatically tags itself in switchport trunks (which I don't want it to do) and I find the config somewhat crufty, as reliable as it's been.
voice vlan
- Tags the phone to a specific VLAN based on LLDP. The phones DHCP on the voice VLAN, download their config via FTP, and all is well.
- My config:
voice vlan
!
interface x/0/x
voice vlan 10
switchport mode access
switchport access vlan 20
It's my understanding that these two methods are mutually exclusive - when I was still figuring out these switches a couple of years ago, running both options on the switch simultaneously led to some somewhat buggy and unpredictable behavior (at least, it did on 12.0.4.8). "auto-voip" seems Netgear proprietary and does not involve LLDP so far as I can tell, instead moving traffic to VLAN 10 based on OUI alone; the "voice vlan" command works more like "switchport voice vlan" (Cisco) or adding the "voice" command to a VLAN (HP/Aruba) and functions via LLDP, dynamically forcing the phone to tag itself to the correct VLAN.
Where we are now, "voice vlan" (global) and "voice vlan 10" are the commands we use, and by and large it works fine...until it doesn't. To answer your question, I've updated the switch code, rebooted, and the phones DHCP'd to VLAN 10 without issue. For now. I'll keep an eye on the DHCP server and see if they stop renewing their leases and update this thread if/when that happens.
Thanks!
- DaneAMar 03, 2019NETGEAR Employee Retired
Hi technotechnotec,
Thank you for the update. It would be best that you open a chat or online support ticket with NETGEAR Support at anytime. Be sure to attach the tech support file from your M4300-52G-PoE+ switch and indicate what port number the the issue has occurred and this might be possibly escalated to our engineering team for investigation.
Regards,
DaneA
NETGEAR Community Team
- IT-Adm1nMar 04, 2019Aspirant
Just wanted to report that we are experiencing the same exact issue, but with two independant GS752TPv2 switches located in two different office sections, interconnected by a single up-link, both with the latest available firmware v6.0.0.45.
We have a combinasion of mostly Yealink VoIP phones and a few GrandStream units.
Everything worked fine for a few day, but the problem reoccurs after less than a week.
I can confirm the observations that the OUI based Auto-VoIP still sets the VLAN, but *untagged*, which breaks the configuration until said port is temporarilly set to untagged. Temporarilly untagged meaning until the next switch reboot that is as, when it works, LLPD indeed seems to consistently properly configure the phones to set and activate their VLAN tagging.
Rebooting a switch definitely cannot be done during business hours so this quite a hassle, especially the time required to insure that all phones indeed came back onoine properly afterwards.
One of the switch has fewer devices connected to it so I could troubleshoot during normal hours after confirming everyone were out to lunch and right after the switch reboot it started to properly communicate the LLPD configuration changes:
*Mar 04 2019 09:16:48: VLAN-6-VOICE_MBR_LLDP_ADD: Interface GigabitEthernet23 added to voice VLAN 5 by LLDP
*Mar 04 2019 09:16:48: VLAN-6-VOICE_MBR_LLDP_DEL: Interface GigabitEthernet23 removed from voice VLAN 5 by LLDPWhen the issue is present all of those LLDP events stop happening, only the link up/down events and related blocking/forwarding entries appear.
I would be fine with just issuing a restart command to the LLDP service/daemon, but I understand that this level of access may not be possible with the lower class model we have.
Hopefully there is a fix in the works and/or soon(ish).
If I need to open a support case I will, but no need if this is now a known problem etc.
- technotechnotecMar 28, 2019Guide
That's essentially what I've had to do. This issue is completely random and unfixable without a reboot. Oh well, here's hoping that engineering "may" help. :)
- tubesfarmerOct 06, 2019Initiate
FWIW this issue seems to be fixed. Originally the config was
interface 1/0/1
voice vlan 10
switchport mode access
switchport access vlan 20
But the switch would randomly stop passing the tagged VLAN traffic. I changed the config to:
interface 1/0/1
voice vlan 10
switchport mode trunk
switchport trunk native vlan 20
switchport trunk allowed vlan 10,20
I haven't had a single DHCP failure/VLAN tag drop since moving to this config.
This behavior seems to only occur on the M4300 series - the M4100 actually rejects switchport mode access as a valid option when using voice VLAN (I have those access ports configured in general mode but I'll be updating them later for the sake of consistency). Maybe it would be nice in future updates to prompt users to use a trunk config when enabling voice VLAN on switchports so they don't spend their time flailing about like I did (this problem lasted for like, seven or eight months!). :)
To be clear, it wasn't LLDP failing to maintain the voice VLAN tag, it was the switch refusing to pass tagged traffic and the phone dropping the VLAN tag after DHCP repeatedly failed (which is normal Mitel/Shoretel behavior).
If anyone else googles this problem hopefully they find this post. :) :womanvery-happy:
- tw-cmsOct 17, 2019Aspirant
I'm seeing pretty much this same exact issue on an S3300-52x-PoE+ switch, but there's no CLI on SmartSwitch models for me to configure your solution. Anybody have any ideas for this one? I've got OUI-based Auto-VoIP enabled for the ports, and under "Voice VLAN Configuration", I have the ports setup with "Interface Mode" as "VLAN ID 2".
- omarchandOct 18, 2019Aspirant
Export your config, edit the config file off-line, and then reload the new config file in the switch.
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!