Voice VLAN added to a standalone two-switch office: four symptoms, one tagging model
Two standalone FS-124F switches serve a 60-user office with no FortiGate on site; routing, DHCP and internet access come from an upstream firewall. Switch A carries the uplink to the firewall and the file server; switch B serves the first and second floors. Port 25 on both switches is the inter-switch link (ISL), a tagged trunk with native VLAN 10, which is also where both switches hold their management IPs. VLANs in use: 10 management, 20 staff, 30 guest, 40 voice, each with a DHCP scope on the firewall. Yesterday an engineer added VLAN 40 for new IP phones. On switch B he put the phone ports into VLAN 40 as untagged, added VLAN 40 to the local VLAN database, changed port 25's native VLAN from 10 to 40 to 'make voice the default', and added VLAN 40 to port 25's allowed list. He made no change on switch A. This morning phones on switch A show no VLAN and no IP; phones on switch B come up with 192.168.40.x addresses; PCs daisy-chained behind phones on switch B also get 192.168.40.x; and the monitoring server can no longer reach switch B's management IP. PCs plugged directly into wall ports on either switch work normally.
1. Explain each of the four symptoms using the tagged/untagged classification rules, and state which single change caused most of the damage.
Read the worked answer
The model to reason with: a frame arriving on a port is classified by whether it carries an 802.1Q tag. Tagged frames go to the VLAN in the tag if that VLAN is in the port's allowed list. Untagged frames go to the port's native VLAN. A trunk must agree on both on each end.
Symptom 1 - phones on switch A get no VLAN/IP. Switch A's port 25 was never updated, so VLAN 40 is not in its allowed list. Tagged VLAN 40 frames from the phones (or from switch B) are dropped at A's ISL. The phones' DHCP DISCOVER never reaches the firewall's VLAN 40 scope.
Symptom 2 - phones on switch B work. On B the phone ports are untagged in VLAN 40, so the phones get a VLAN 40 address locally; the traffic is then tagged onto the ISL, but the scope is reachable through the firewall uplink on switch A only if A forwards it - which is why the phones that work are getting addresses from a path that does not traverse the misconfigured ISL direction, and why the design is fragile even where it appears to work.
Symptom 3 - PCs behind phones get 192.168.40.x. Because the phone port's native VLAN was set to 40, the PC's untagged frames are classified into VLAN 40 as well. Voice and data are now the same broadcast domain - a security and QoS problem, not just an addressing problem.
Symptom 4 - switch B's management IP is unreachable. B's management IP lives in VLAN 10, carried untagged on the ISL. Changing port 25's native VLAN to 40 moved all untagged frames - including management traffic - into VLAN 40, so A can no longer reach B in VLAN 10.
The single worst change was setting the ISL's native VLAN to 40; it broke management reachability and is the reason the fault looked like a dead switch. The phone-port native VLAN 40 is the second error, and the missing allowed-VLAN on A is the third. Note what did not break: direct-PC ports in VLAN 20 still work, because VLAN 20 is tagged on the ISL and tagging was unchanged.
2. Write the corrected configuration for the ISL on both switches and for a phone-plus-PC port on switch B, and say why LLDP-MED belongs in the design.
Read the worked answer
ISL (port 25, identical on A and B):
- native-vlan 10 (management stays untagged, as it was)
- allowed-vlans 10,20,30,40 (tagged) Key rule: the native VLAN must match on both ends, and management traffic should never ride the native VLAN of a trunk that carries user VLANs unless you accept that a native-VLAN change blinds you.
Phone-plus-PC access port on switch B:
- native-vlan 20 - the PC's untagged traffic is staff data
- allowed-vlans 40 - the phone's voice traffic is tagged
- LLDP profile with an MED voice network policy advertising VLAN 40 (tagged), and QoS trust so the phone's DSCP/802.1p markings are honoured
- PoE and STP edge-port enabled for a single-attached phone This gives one physical port two logical networks: untagged data for the PC behind the phone, tagged voice for the phone itself.
Why LLDP-MED matters: Without it, every phone must be hand-configured with VLAN 40 and tagging, and any mismatch (a phone still set to untagged) silently lands voice in the data VLAN - exactly the failure above. LLDP-MED's network policy tells the phone the voice VLAN ID and whether to tag it, so configuration lives on the switch. It also gives you power negotiation data and inventory, which helps when a phone is moved between floors.
What to avoid: Do not use native-vlan 40 on phone ports. It is tempting because phones then 'just work' untagged, but it merges voice and data, makes QoS classification unreliable, and every PC behind a phone ends up in the voice scope.
Voice QoS: mark voice EF, trust the phone's markings on ingress, and keep voice and data in separate subnets so firewall policy and call admission stay meaningful.
3. You have just made the changes and users are still complaining. List the verification steps in the order you would run them, and what each result would prove.
Read the worked answer
Order matters: verify the trunk, then the VLAN database, then the access port, then the service.
Compare both ends of the ISL. Check native VLAN, allowed VLAN list, and link state on port 25 of A and B. A mismatch here explains any cross-switch failure and must be cleared before looking further.
Confirm VLAN 40 exists in the VLAN database on both switches with the correct ID and name, and that it is not accidentally the management VLAN. A VLAN that exists on one side only drops all its traffic at the trunk.
Check the MAC address table per VLAN on both switches. Look for phone MACs appearing in VLAN 40 and PC MACs in VLAN 20. If a phone MAC shows in VLAN 20, the phone is not using the tagged voice VLAN - suspect the LLDP-MED policy or a manually configured phone.
Check the access port state and PoE on a working and a failing phone port. Confirm the port is up at the expected speed and delivering power; a phone that boots without a link is a cabling/PoE fault, not a VLAN fault.
Verify DHCP end to end. Confirm the phone receives an address from the 192.168.40.0/24 scope on the firewall and that the gateway is the firewall's VLAN 40 interface. If the address is 192.168.20.x, classification is still wrong at the port.
Prove management reachability from the monitoring server to switch B's management IP, and confirm the switch's default gateway is still in VLAN 10.
Regression test: a directly connected PC, a PC behind a phone, a guest port in VLAN 30, and a phone on switch A - all four must behave as designed before you close the ticket.