A new access switch goes into a third-floor wiring closet on a Friday afternoon. It gets patched into the trunk running back to the core, configured from the same template that's worked a dozen times before: trunk the uplink, allow the VLANs, done. By Monday there are three tickets. Phones on the voice VLAN are dropping calls mid-conversation. One desk can print but can't reach the file share. A laptop that should land on the data VLAN is pulling an IP from the guest subnet instead. Nobody touched the core switch. The new switch's config looks identical to every other access switch in the building.
The thing the template didn't carry over is the native VLAN, and it's easy to see why: it's the one VLAN on a trunk link that doesn't get an 802.1Q tag. Every other VLAN crossing that trunk gets a 4-byte tag inserted into the Ethernet frame identifying which VLAN it belongs to, and the receiving switch reads that tag to know where the frame goes. The native VLAN is the exception, sent untagged, by design, mostly for backward compatibility with old equipment that never learned to speak 802.1Q. On Cisco gear the default native VLAN is VLAN 1 unless someone explicitly sets it elsewhere.
Here's where the new switch goes wrong: its trunk port still has the native VLAN set to the factory default, VLAN 1, while the core switch's matching trunk port was configured months ago with the native VLAN set to VLAN 99, a dedicated management VLAN, standard practice specifically so VLAN 1 traffic doesn't sneak across trunks untagged. Two switches, same physical trunk, disagreeing about which VLAN travels untagged. When the new switch sends untagged frames, it means VLAN 1. When the core switch receives untagged frames on that trunk, it interprets them as VLAN 99, because that's what its own configuration says untagged means. The frame gets placed on the wrong VLAN the instant it crosses the link, no misconfigured cable, no bad port, nothing that shows up on a physical layer check.
That's exactly the pattern behind the three tickets: traffic that should have stayed on one VLAN quietly reappearing on another, intermittently, depending on which frames happened to be untagged when they crossed that specific trunk. It's also precisely the kind of mismatch CDP is built to catch, if it's enabled: Cisco switches exchange native VLAN information in CDP advertisements, and a genuine mismatch triggers a syslog warning naming both VLANs and both ports. The fix is one line on the new switch's trunk configuration, matching its native VLAN to what the core switch already expects. The part worth remembering isn't the command, it's the instinct: a trunk isn't fully configured just because the VLANs are allowed across it. Two switches also have to agree on which one crosses without a tag, and that's a setting most templates silently assume rather than actually check.
This is the kind of trunk-level detail that separates knowing VLANs exist from being able to diagnose them under time pressure, which is exactly the ground the CCNA 200-301 Study Guide covers with 41 hands-on labs, including trunk and VLAN troubleshooting scenarios built to produce exactly this failure mode so you learn to recognize it before it's a helpdesk ticket: https://resources.codelivly.com/product/ccna-practical-the-hands-on-network-engineer-guide/
The free Routing & Switching Fundamentals path covers the OSI-model and VLAN groundwork this scenario builds on: https://codelivly.com/learning-paths/routing-switching-fundamentals
Top comments (0)