Replacing an Access Switch Under IP Phones: How Does the Phone Actually Learn Its Voice VLAN?

Published: October 23, 2026 | Last Technically Reviewed: October 23, 2026

Quick Summary

The desk phones are registered, and the PCs connected through them have network access. Replacing the old access switch looks like a routine job until someone checks the port configuration. There is no obvious voice VLAN command, and LLDP-MED reports VLAN ID 0. If the replacement port carries tagged voice and untagged data, how will the phones know which VLAN to use?

An administrator raised almost exactly this problem in a 2026 Aruba networking discussion. The post never establishes how the phone was configured. It does show why carrying over the old VLAN numbers may not preserve the way the phone connects.

Quick answer

An IP phone may learn its voice VLAN from LLDP-MED, CDP, a local setting, a supported DHCP VLAN discovery option, or a provisioning system. The phone model and firmware determine which source takes precedence. The switch's running configuration cannot always tell you what the phone actually chose. Before replacing the access switch, check the advertised policy, the phone's active VLAN setting, the tags it sends, and whether both the phone and its attached PC are authorized and working.

A successful change means the phone registers, calls carry audio in both directions, and the PC keeps its intended network access.

A Working Phone Port Does Not Explain How the Phone Learned Its VLAN

In the ArubaNetworks discussion, an administrator described a port carrying both a desk phone and a PC. The port was an access port for the phone VLAN. The proposed change was to tag voice traffic and use a native or untagged VLAN for the PC. Yet the existing configuration had no clear voice command, and LLDP-MED appeared to report VLAN ID 0.

The administrator asked whether the switch configuration alone could reveal how the phone knew its VLAN. In a follow-up, the same person asked how the phone would choose between two VLANs on a single port. Suggestions included phone-side configuration and LLDP-MED, but nobody established the actual discovery source. There was no complete switch output, phone model, firmware, received policy, packet capture, or confirmed migration result.

These details matter during a replacement. A phone might still be using a VLAN configured locally months earlier. It might have learned the VLAN when it last booted, inherited it from a provisioning profile, or simply been operating untagged on the access VLAN. All four arrangements can support a working call, but they may require different settings on the new switch.

The baseline needs to record what the phone is doing, not just what the switch configuration suggests.

Static Settings, LLDP-MED, CDP and DHCP Can All Influence Voice VLAN Discovery

A switch port allowing a tagged VLAN does not automatically teach that VLAN to a phone. LLDP-MED can advertise a network policy, but the phone must support and adopt it before its outgoing frames change.

The underlying protocols help explain the difference. IEEE 802.1AB defines LLDP for discovering adjacent network devices and their connections. ANSI/TIA-1057, published in April 2006, extends LLDP for media endpoints and network policy exchange. Its published scope is available through the linked standards catalog; the full standard has not been independently reviewed for this article. Cisco's IOS XE LLDP-MED guide explains the Voice application policy, VLAN, tagging indication, Layer 2 priority and DSCP. An advertisement tells the phone which policy is available. It does not tag Ethernet frames for the phone. The endpoint has to apply the policy when sending traffic.

The phone's firmware also determines the order in which it considers discovery sources. The Cisco 8800 Multiplatform administration guide for release 11.3(1) and later, updated November 21, 2019, documents LLDP-MED first, then CDP, manual VLAN and DHCP VLAN option. For the documented DHCP discovery feature, Cisco recommends Option 132. A similar order appears in its 7800 Multiplatform guide for 11.3(1) and later. That order belongs to the documented phone firmware. Other SIP phones may use a different sequence.

DHCP-based VLAN discovery is not the same as obtaining an IP address or provisioning-server information. A successful DHCP lease shows that the phone obtained an address on a network. It does not tell you how the phone selected that network in the first place.

Who teaches the phone its VLAN?

Local Phone Setting ---+
                       |
LLDP-MED Policy -------+
                       |
CDP Advertisement -----+----> Phone VLAN Decision
                       |
DHCP VLAN Discovery ---+
                       |
Provisioning Profile --+
                                  |
                                  v
                         Tagged / Untagged Voice
                                  |
                                  v
                         DHCP / Registration / Calls

A phone may use only some of these methods. Check the documented order and the configuration actually applied to that model.

Why LLDP-MED VLAN ID 0 and a Missing Voice Command Do Not Tell the Whole Story

Start by identifying which field is showing zero. A displayed VLAN ID might be a local media policy, a neighbor's policy, another LLDP VLAN field, or a placeholder for a policy that was not advertised. That number alone does not tell us what tags the phone transmits.

Three different interpretations need to be separated.

First, under IEEE 802.1Q VLAN tagging, a frame whose tag has VID 0 is priority-tagged: the tag can carry priority information without assigning a normal VLAN ID. Cisco's VLAN 0 priority-tagging explanation illustrates that frame-level behavior. That is a property of the Ethernet frame, not an explanation of the switch's LLDP-MED output.

Second, LLDP-MED Network Policy includes more than a VLAN number. The application type and the unknown-policy and tagged indicators determine how the field should be interpreted. The LLDP-EXT-MED-MIB reproduced by LibreNMS identifies itself as the TIA TR41.4 revision dated July 28, 2005, published in Section 13.3 of ANSI/TIA-1057. Its lldpXMedLocMediaPolicyVlanID object describes zero as a value used for priority-tagged frames, with the ingress port's default VID applied. That definition only helps when the policy field is meaningful: lldpXMedLocMediaPolicyUnknown says to ignore VLAN, priority and DSCP when the policy is unknown, while lldpXMedLocMediaPolicyTagged says VLAN ID and Layer 2 priority are ignored when the policy is untagged or port-based VLAN operation is unsupported. This wording belongs to the cited 2005 MIB revision. Other vendor implementations and CLI displays need to be checked on their own terms.

Third, vendors may show a zero when a policy is withheld. An ArubaOS-Switch 16.10 access-security example documents Media Policy VLAN ID 0 or 4095 with a suppressed LLDP-MED network policy in a specific unauthenticated-port scenario. It is a documented explanation for that ArubaOS-Switch configuration, but not a diagnosis of the Reddit case.

There is a useful configuration check on ArubaOS-Switch. Its 16.10 LLDP-MED configuration guide says network policy is advertised only on ports belonging to a VLAN designated for voice. If an interface has no port-level voice command, examine the VLAN-level voice designation and port membership. Separately, the AOS-CX 10.16 Fundamentals Guide's lldp med command reference states that the Network Policy TLV is sent only when a voice VLAN policy is present. It also states that the switch sends LLDP-MED TLVs after receiving an LLDP-MED TLV from the connected endpoint. The two guides describe different Aruba operating systems, so their commands and display fields should be checked separately.

Finally, Cisco's 7800 Multiplatform Technical Details, under Special VLANs, for release 11.3(1) and later and updated November 21, 2019, explicitly treats policy VLAN values 0, 1 and 4095 as untagged in that phone's policy-resolution logic. It explains how the documented Cisco phone handles those values. It cannot establish what the Aruba phone in the discussion was transmitting.

For a reliable answer, save the full LLDP-MED policy, including its flags, check the active VLAN on the phone, and capture traffic where 802.1Q tags are visible. The advertisement, the phone's setting, and the actual frames should agree.

Conflicting advertisements and delayed discovery

Cisco's 7800 Multiplatform technical details also describe a phone that can change VLAN and repeatedly reboot when CDP and LLDP-MED advertise inconsistent policies. The behavior is a documented possibility for that implementation, not a universal phone response.

Discovery timing matters just as much as the final configuration. The Cisco 7800 Multiplatform 11.3(1)+ Installation chapter, VLAN Settings Parameters, updated November 21, 2019, explicitly gives Network Startup Delay a three-second default so the switch port can reach forwarding state before the first LLDP-MED packet. The same chapter says that when LLDP-MED receives no acknowledgment, the manual or default VLAN may be used when applicable, and describes a six-second waiting period when CDP is also used. The timing values are specific to that phone documentation. On a replacement switch, STP and authentication can also affect when discovery takes place. A new edge-port configuration, or a change in authentication timing, should therefore be tested from a true cold boot rather than only by moving a running phone to a new jack.

Tagged Voice, Untagged Data: How the Phone and PC Share One Port

In a typical phone-and-PC setup, the phone tags its voice traffic and passes PC traffic untagged to the switch's data VLAN. However, the phone's own PC-port settings may change that behavior.

           Access Switch Port
           |                |
      Voice Path         PC Data Path
       (tagged)       (tagging varies)
           |                |
           +--------+-------+
                    |
                 IP Phone
                    |
               PC Pass-through
                    |
                    PC

Cisco's 7800 Multiplatform installation settings include PC Port VLAN ID. With that feature configured, the phone can tag previously untagged frames arriving from the PC while leaving already tagged PC frames unchanged. The documentation lists values from 0 to 4095, although not every value represents an ordinary VLAN that can be used for forwarding. Check the actual setting and capture traffic upstream of the phone.

A PC obtaining an address does not prove the phone received the right voice policy. Likewise, a registered phone does not establish that the PC passed authentication. When one endpoint fails, troubleshoot its own path first: voice VLAN advertisement and registration for the phone; data VLAN, bridge behavior and EAPOL pass-through for the PC. If both obtain addresses but calls fail, examine call signaling, RTP media, routing, access rules and QoS.

Authentication complicates matters. Phone MAB and PC 802.1X can coexist in some documented access designs, but you must check multi-session support, authorization granularity, RADIUS VLAN attributes and EAPOL pass-through. The Cisco 7800 Multiplatform documentation is especially unsuitable for a blanket wired-802.1X verdict. In the same Release 11.3(1) and Later guide, the Technical Details section titled LLDP-MED and IEEE 802.X says the phone does not work in a wired 802.1X environment, while the Ethernet Configuration submenu lists an 802.1X Authentication switch and authentication states. Both chapters show November 21, 2019 as their update date. Neither passage, read alone, proves the behavior of an installation running different or newer firmware. Verify the precise phone SKU, firmware, authentication method and PC-port EAPOL behavior with current documentation or a pilot.

Can Authentication and Dynamic Port Policies Affect Voice VLAN Discovery?

They can, but this is a dependency to preserve during migration, not a separate guide to every NAC feature.

A June 2026 Fortinet warehouse discussion asked whether PoE ports could accommodate a voice phone, a PC behind it and a camera connected directly, with policies determined by the endpoint. The administrator had FortiGate and 148F-PoE switches but no separate FortiNAC. The replies offered suggestions, including dynamic port policies; the thread does not document a successful final deployment.

Fortinet's FortiSwitch 7.2.2 use cases describe combinations including phone MAB, LLDP-MED, PC 802.1X and RADIUS-assigned VLANs. These examples depend on the phone, switch, and RADIUS policies being compatible. In particular, the voice VLAN advertised to a phone may need to match the VLAN assigned through authorization. By contrast, FortiOS 7.4.4 Dynamic Port Policy applies actions to a switch port and may bounce that port. Changing a port policy is not the same as authorizing each connected MAC independently. Fortinet's 7.6.5 voice detection example specifically matches the FortiFone family and requires the documented FortiGate and FortiSwitch detection setup. That example does not establish equivalent discovery for Cisco or Yealink phones.

For this migration, check whether an authentication result or dynamic port action could change the native VLAN, suppress an LLDP-MED advertisement, or bounce a port while the phone and PC are active. Test the complete phone-and-PC arrangement before enabling those actions across a site. An LLDP profile alone does not establish safe coexistence, and MAB identifies a MAC address rather than reliably authenticating the device behind it.

What Evidence Must Be Captured Before Replacing the Access Switch?

The baseline should explain why the phone works on the existing switch. Record the switch and firmware, VLAN-level voice configuration, tagged and untagged membership, LLDP/CDP policies, edge-port or STP behavior, authentication, PoE and QoS. Record the phone model, firmware, active VLAN source, local and provisioned settings, PC-port VLAN treatment and startup delay. Include DHCP options, call-controller reachability, and the actual behavior of the attached PC.

A useful way to review this evidence is the Four-Layer Voice VLAN Evidence Check. It groups the investigation by what is configured, advertised, forwarded, and ultimately working. It is an engineering checklist, not a vendor command set or a reference to OSI layers.

Capture both the switch's local policy and the phone's received policy when possible. Leave any item without supporting evidence open instead of marking it as passed. A PC address from the expected subnet is useful evidence, but it does not replace authentication or frame-tag verification.

Switch migration dependency chain

Existing Phone and Switch
           |
   Capture Working Baseline
           |
 Identify Actual VLAN Source
           |
 Compare Advertised Policy
           |
 Check Phone and PC Frames
           |
 Verify Auth and Startup Timing
           |
      Prepare Pilot Port
           |
   Approved Migration Window
           |
 Phone + PC + Call Acceptance
           |
          Sign-Off

The aim is to carry the working phone and PC behavior onto the new switch, not simply translate configuration commands.

How to Prove the Phone, PC and Voice Service Survived the Switch Replacement

Choose a representative phone and connected PC. Record how they work on the existing switch, then run the same checks on a pilot port of the replacement. Include an actual power-on sequence, not only a link reconnect after the phone is already registered.

If timing could affect discovery, record the sequence from link-up through port forwarding, LLDP-MED exchange, VLAN selection, DHCP, and call registration. If discovery fails, identify whether the advertisement was absent, late, conflicting or ignored before altering VLAN configuration. In an 802.1X design, observe authorization timing as well. Test both signaling and RTP media; registration alone can conceal one-way audio.

Use a lab or approved maintenance window for disruptive tests. Keep the old configuration and rollback path available until both phone and PC meet their acceptance criteria. A successful ping is not enough if the phone cannot place a working call.

Before a hardware refresh, Network-Switch's Business Network Readiness & Modernization review can help organize switch, PoE, uplink and BOM compatibility questions. Voice VLAN discovery, LLDP-MED behavior and NAC policy still need to be validated against the exact phone, switch and policy-server documentation. That review is not a security audit or a compatibility certification.

Before signing off, answer one final question: How does the phone learn its VLAN today, and will it continue to do so on the new switch without losing authorization or voice service?

Sources and References

The following sources support the protocol descriptions, documented product behavior, and public engineering discussions cited in this article. Product and firmware limitations stated in the article apply to the references below.

Standards and Protocol Definitions

1. IEEE 802.1AB, Link Layer Discovery Protocol (LLDP). Official IEEE project information for LLDP and neighbor discovery. This is a standards overview page, not the full standard.

2. ANSI/TIA-1057, LLDP for Media Endpoint Devices (LLDP-MED). Standards catalog reference for LLDP-MED extensions used to advertise media endpoint network policy. The catalog listing is not the full standard text.

3. IEEE 802.1Q, Bridges and Bridged Networks. Official IEEE standards information for VLAN tagging and priority-tagged Ethernet frames.

4. LLDP-EXT-MED-MIB, TIA TR41.4 revision dated July 28, 2005. Public repository copy of the MIB defining LLDP-MED media-policy fields, including VLAN ID, Unknown Policy and Tagged. Interpret the definitions with the relevant policy flags; this is not an official TIA-hosted copy.

Cisco Technical Documentation

1. Cisco IOS XE, LLDP-MED Configuration. LLDP-MED Network Policy TLV, advertised voice VLAN, tagged setting, Layer 2 priority and DSCP.

2. Cisco 8800 Series Multiplatform Phones, Administration Guide, Release 11.3(1) and Later. Documented phone-specific VLAN discovery order and DHCP VLAN Option 132; guide updated November 21, 2019.

3. Cisco 7800 Series Multiplatform Phones, Administration Guide, VLAN and Ethernet Settings. Phone VLAN discovery, Network Startup Delay, CDP waiting behavior, PC Port VLAN ID and 802.1X configuration fields; Release 11.3(1) and Later, updated November 21, 2019.

4. Cisco 7800 Series Multiplatform Phones, Administration Guide, Technical Details. Special VLAN values 0, 1 and 4095 in this phone implementation, CDP/LLDP-MED conflict behavior and the historical 802.1X statement; Release 11.3(1) and Later, updated November 21, 2019.

5. Cisco, VLAN 0 Priority Tagging. Vendor explanation of 802.1Q priority-tagged frames using VID 0, distinct from an LLDP-MED policy display.

HPE Aruba Networking Documentation

1. ArubaOS-Switch 16.10, Access Security and Suppressed LLDP-MED Network Policy. A documented scenario in which Media Policy VLAN ID can be displayed as 0 or 4095 when the policy is suppressed.

2. ArubaOS-Switch 16.10, LLDP-MED Network Policy Configuration. Voice VLAN designation and conditions for advertising network policy on relevant switch ports.

3. AOS-CX 10.16, LLDP-MED Command Reference. AOS-CX-specific conditions for LLDP-MED TLV transmission, including a configured voice VLAN policy. Do not interchange AOS-CX commands with ArubaOS-Switch commands.

Fortinet Technical Documentation

1. FortiSwitch Administration Guide 7.2.2, Use Cases. Examples combining phone MAB and LLDP-MED with PC 802.1X, RADIUS VLAN assignment and relevant policy dependencies.

2. FortiLink Guide 7.4.4, Configuring Dynamic Port Policy Rules. Device matching and port-level policy actions, including LLDP, QoS, 802.1X, VLAN policy and optional port bounce.

3. FortiLink Guide 7.6.5, Voice Device Detection. Documented FortiFone-specific voice detection example with its FortiGate/FortiSwitch setup requirements, not general third-party phone detection.

Public Engineering Discussions

1. r/ArubaNetworks, "Phones query" (August 2026). Original community question about a phone and PC on one port, absent obvious voice VLAN commands and an LLDP-MED display showing VLAN ID 0. The phone discovery source and migration outcome were not established.

2. r/fortinet, "Is it possible to have Voice/Data VLAN via LLDP-MED + MAC NAC on the same ports?" (June 2026). Warehouse network design question about phones, PCs and cameras sharing a class of PoE ports. The thread documents requirements and suggestions, not a completed deployment.