cisco native vlan mismatch enables vlan hopping

the untagged frame problem nobody notices until it's too late

here's a fun fact about trunk links: they're supposed to tag every frame with a vlan id, except for one. the native vlan. that one traffic type rides the trunk completely untagged, no label, no id, nothing. it's a leftover from 802.1q trying to stay compatible with old switches that didn't understand tagging at all. and it's also a quiet little door that a lot of networks leave wide open without realizing it.

what actually happens when native vlans don't match

picture two switches connected by a trunk. switch a says "my native vlan is 1." switch b says "my native vlan is 99." both sides think they're being reasonable. neither one is wrong on its own. but now switch a is sending untagged frames expecting them to land in vlan 1 on the other end, and switch b is receiving those untagged frames and just dumping them into vlan 99 because that's what it was told to treat as native. the frame never had a tag to argue with. it just goes wherever the receiving switch decides.

that means traffic can cross from one vlan into another without ever passing through a router, without an acl ever seeing it, without anyone touching a firewall rule. it's not a bug being exploited, it's a config mismatch quietly doing exactly what it was told to do.

why this turns into vlan hopping

vlan hopping attacks lean on exactly this behavior. one common technique, double tagging, relies on the attacker's frame having an outer tag matching the native vlan and an inner tag for the target vlan. the first switch strips the outer tag because it matches native, forwards the frame untagged, and the next switch reads the inner tag as if it were the original one. congratulations, the frame just hopped vlans without touching a layer 3 device.

a native vlan mismatch doesn't require an attacker to be clever at all. it can leak traffic on its own just from misconfiguration. add a native vlan of 1 (the default, the one nobody bothers to change) and you've basically built the on-ramp for double tagging attacks yourself, for free, with zero attacker effort.

cdp is already telling you

if you've got cdp running between cisco switches, it actually flags this for you. you'll see a log message along the lines of:

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet0/1 (99), with Switch2 GigabitEthernet0/2 (1).

this message gets ignored constantly because it doesn't break anything visibly. no outage, no ticket, no angry users. it just sits in the log looking like noise. it's not noise. it's cisco handing you a free vulnerability report and most people scroll past it.

how to actually check your own trunks

on each switch, look at the trunk interface config and confirm the native vlan explicitly instead of trusting the default:

show interfaces trunk

this shows you the native vlan for each trunk port on both ends. walk both sides of every trunk link and compare. if they don't match, you've found your leak. don't assume they match just because someone set them up once, config drift happens constantly, especially after equipment swaps or partial migrations.

the fix: pick an unused vlan and use it on both ends

the real fix isn't just "make them match." it's making them match on a vlan that isn't doing anything else. create a dedicated, unused vlan purely to serve as the native vlan, something nobody's assigning to user ports or servers, and set it identically on both ends of every trunk:

vlan 999
name NATIVE_UNUSED

interface GigabitEthernet0/1
switchport trunk native vlan 999
switchport trunk encapsulation dot1q
switchport mode trunk

repeat that same native vlan on the other switch's matching interface. never use vlan 1, it's the default everywhere and attackers assume it. never use a vlan that carries real user or server traffic either, because if double tagging ever does get attempted, you want the native vlan to be a dead end, not a path into something valuable.

the takeaway

native vlan mismatches are the kind of thing that doesn't show up as an outage, so they survive in production for years. they're not glamorous, there's no exploit script needed, just a config nobody double checked. audit your trunks, match your native vlans, dedicate an unused vlan for that purpose, and stop treating cdp mismatch warnings as background noise. that log line is the easiest security fix you'll do all week.