Trunking: Native VLAN Mismatch
A trunk that is up, passing traffic, and quietly bridging two broadcast domains together. Find the disagreement yourself, live, right below.
Symptom
A trunk is up and passing most VLANs, but one VLAN's traffic lands in the wrong broadcast domain. Trace the untagged path across the link.
Your mission
Inspect, recover, then verify
Format
Cisco IOS CLI
Investigate before you configure.
Use the CLI evidence to isolate the fault, make the smallest safe correction, then verify the network state changed.
Observe the symptom and link state.
Diagnose by comparing the protocol evidence.
Verify the expected device state and confirm the original symptom is resolved.
Console access: SW1 · SW2
This workspace stacks for portrait phones. Rotate to landscape for the full split-screen console.
Need a hint?
Reveal the root cause when you're ready.
Try the investigation first, then use this as your escape hatch, not a dead end.
Lab debrief
Turn the session into a repeatable troubleshooting pattern.
Use this reference after your attempt: first explain the symptom, then verify the evidence, then confirm the repair.
The problem
SW1 and SW2 are connected by a working trunk. Hosts in most VLANs communicate normally, but traffic sent untagged from one side arrives in a different VLAN on the other, and the console logs a recurring native VLAN mismatch notification.
What you'll practice
- Read the native VLAN on both ends of a trunk
- Explain why untagged frames leak between VLANs on a mismatch
- Interpret the CDP native VLAN mismatch log message
- Align the native VLAN and verify the corrected trunk
1. Read the native VLAN on both ends of a trunk
show interfaces trunk reports the native VLAN per port, and the two ends must agree. Learning to compare them side by side is the fastest way to confirm or eliminate this fault class.
2. Explain why untagged frames leak between VLANs on a mismatch
A frame sent untagged in VLAN 1 on one switch is interpreted as VLAN 99 on the other. That is a silent bridge between two broadcast domains, which is a genuine security concern as well as a connectivity bug.
3. Interpret the CDP native VLAN mismatch log message
CDP detects the disagreement and logs it every minute or so. Recognising that message on sight turns a vague connectivity complaint into a solved problem.
4. Align the native VLAN and verify the corrected trunk
You will set both ends to the same unused VLAN, the design practice that stops VLAN 1 carrying user traffic in the first place.
The topology
Two access switches are joined by a single 802.1Q trunk carrying several user VLANs. The fault is confined to the untagged VLAN configured on that trunk.
Commands to run yourself
The real diagnostic commands for this lab, copy-paste ready. Run these in the same order to reproduce the investigation on your own session.
show interfaces trunkshow interfaces GigabitEthernet0/1 switchportshow logging | include NATIVE_VLAN_MISMATCHTopology diagram
Fact-checked references
The commands and behaviour in this lab were checked against these primary references.
Frequently asked
Why does the trunk stay up if the two ends disagree?
802.1Q does not negotiate the native VLAN as a condition of forming a trunk. CDP notices the disagreement and logs it, but neither switch takes the link down, so tagged VLANs continue to work normally.
Why change the native VLAN away from VLAN 1 at all?
VLAN 1 is the default everywhere, so leaving user traffic untagged in it makes a mismatch far more likely to bridge something real. Moving the native VLAN to a dedicated unused VLAN means a mismatch leaks nothing of value.
Ready to run this lab yourself?
No setup, no image sourcing. Book a session or ask for a live demo.