I85PREP
⌘ K
Junior Network Administrator study materials
Junior Network Administrator study resources

IP Phones and Guest Wi-Fi on a Misconfigured Trunk

Junior Network Administrator · Put your knowledge to work in context.

All case studies

IP Phones and Guest Wi-Fi on a Misconfigured Trunk

A dental clinic has one 48-port access switch serving VLAN 10 (clinical workstations), VLAN 20 (IP phones), VLAN 30 (patient guest Wi-Fi) and VLAN 99 (management, 10.99.0.0/24). Desks have an IP phone with the PC daisy-chained behind it. Each access port is configured only as switchport mode access and switchport access vlan 10. The single uplink to the core is an 802.1Q trunk; the core side has switchport trunk allowed vlan 10,20,99 and native VLAN 1, while the access switch trunk side has native VLAN 99. After a maintenance window: phones power up, display 'Configuring CM List', and never obtain an IP address; patient Wi-Fi clients occasionally reach hosts in 10.99.0.0/24; and the core logs %CDP-4-NATIVE_VLAN_MISMATCH. The DHCP scope for VLAN 20 is healthy and the phones worked on the old flat network.

1. Explain why the phones never get an address and give the exact configuration changes, distinguishing this from the guest Wi-Fi problem.

Read the worked answer

A Cisco-style phone only tags its own traffic into the voice VLAN when the port tells it to. With just switchport access vlan 10, the phone sends untagged frames, which land in VLAN 10 - a subnet with no voice scope and no option 150/TFTP pointer - so the phone never gets an address and hangs on 'Configuring CM List'. Power is fine, which is why it boots.

Fix: switchport voice vlan 20 on every access port. The phone then tags in VLAN 20 while the PC behind it stays untagged in VLAN 10, which is the intended design.

The guest problem is separate: the trunk allowed list is 10,20,99, so VLAN 30 frames are dropped on the uplink. Add 30: switchport trunk allowed vlan 10,20,30,99. Confirm VLAN 20 and 30 exist in the VLAN database on both switches before expecting either fix to work.

2. What does the native VLAN mismatch actually do to this network, and why is the CDP warning not the real problem?

Read the worked answer

Untagged frames on a trunk are classified into the receiving switch's native VLAN. The access switch sends untagged frames expecting native 99, but the core puts them in VLAN 1; the core's untagged frames land in 99.

Consequences:

  • Data from a non-native VLAN can appear in the management subnet 10.99.0.0/24 - the leak staff observed.
  • Untagged STP BPDUs are classified into different VLANs at each end, so the two switches may build inconsistent spanning trees for the same physical link.
  • A host on one side's native VLAN can inject untagged frames that arrive in the other side's native VLAN, a stepping stone to VLAN hopping.

%CDP-4-NATIVE_VLAN_MISMATCH is only a courtesy notice; the traffic leak and the STP inconsistency are the actual faults. Make both ends agree - preferably on an unused VLAN, not 99.

3. List the trunk- and port-hardening steps you would apply before handing the clinic back, and the attack each one blocks.

Read the worked answer
  1. switchport trunk native vlan 999 on both ends, with 999 absent from the allowed list and having no access ports - neutralises untagged-frame leakage and double-tagging.
  2. Explicit allowed list 10,20,30 (management pruned from access trunks) - limits broadcast domains and stops a compromised port from reaching VLAN 99.
  3. switchport mode trunk plus switchport nonegotiate on real trunks - blocks DTP negotiation by a rogue device.
  4. switchport mode access plus switchport nonegotiate on all user ports - a phone or PC cannot talk its way into a trunk.
  5. Shut or park unused wall ports in an unused VLAN - removes unused entry points.
  6. Management SVI restricted by ACL to the admin subnet, SSH only, Telnet disabled.

Together these close VLAN hopping and management-plane exposure without changing clinical traffic flows.