Cisco Native VLAN: How It Works and Why Mismatches Bite

Key Takeaways

The native VLAN is just “the VLAN that doesn’t get a tag.” Untagged frames arriving on a trunk are placed in it; frames leaving in it go out without a tag. That is the entire mechanism.
A mismatch does not break the link — it merges two VLANs. Traffic keeps flowing, which is exactly why this is dangerous. Two broadcast domains quietly become one.
CDP will tell you, with a %CDP-4-NATIVE_VLAN_MISMATCH message. It is one of the few log messages worth acting on immediately.
Never leave the native VLAN as VLAN 1, and don’t use it for user data. Give it an unused, shut-down VLAN that carries nothing.
vlan dot1q tag native removes the whole problem by tagging everything, including the native VLAN. It ships as a default line in my Cisco Switch Configuration Best Practices: Build Template. Understand the trade-off before enabling it.

People find the native VLAN confusing because it is usually explained as a special VLAN. It is not special. It is a rule about tagging, and it has exactly two halves.

The two rules

On an 802.1Q trunk:

Ingress: a frame arriving with no VLAN tag is assigned to the native VLAN. It has no tag, the switch has to file it somewhere, and the native VLAN is the answer to “where”.
Egress: a frame leaving in the native VLAN is sent with its tag removed. Every other VLAN is tagged on the way out.

That is it. The native VLAN is the one VLAN on an 802.1Q trunk whose membership is implied by the absence of a tag rather than stated by the presence of one. 802.1Q is the IEEE standard that defines how a VLAN identifier is inserted into an Ethernet frame, adding a four-byte tag between the source MAC address and the EtherType field.

Diagram of an 802.1Q trunk showing untagged frames being placed into the native VLAN on ingress and native VLAN frames leaving the trunk with the tag stripped

Why it exists at all

Backwards compatibility. When 802.1Q was introduced, a trunk might have a device on it that had never heard of VLAN tags — a hub, an old bridge, a management interface. Leaving one VLAN untagged meant such a device could still participate on the link instead of dropping everything it received.

That requirement has essentially disappeared from modern networks. The native VLAN has outlived it, which is why current practice is to make it as inert as possible rather than to use it.

What a mismatch really does

Configure VLAN 10 as native on one end of a trunk and VLAN 20 on the other, and here is the sequence:

Switch A has a frame in VLAN 10. VLAN 10 is native, so it strips the tag and sends it untagged.
Switch B receives an untagged frame. Its native VLAN is 20, so it files the frame into VLAN 20.
The frame has changed VLAN in transit, without being routed, without touching an ACL, and without anything logging a drop.

The result is that VLAN 10 on one switch and VLAN 20 on the other are now a single broadcast domain. Hosts can reach each other across a boundary you believe exists. Spanning tree also gets confused — the two VLANs’ topologies are now stitched together in a way STP never planned for, which can produce a loop that only appears under specific failure conditions.

Nothing goes down. That is what makes it a genuinely nasty fault: every symptom is “some things can reach things they shouldn’t”, which is rarely the first thing anyone tests.

How you find out

CDP compares the native VLAN on both ends of a link and complains loudly when they differ:

Switch console showing a CDP native VLAN mismatch notification between two trunk interfaces

The message looks like this:

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on
GigabitEthernet1/0/1 (10), with Switch2 GigabitEthernet1/0/1 (20).

Two things about that. First, it is a level-4 warning rather than an error, so it sits in the log looking unimportant next to genuine outages. Second, it depends on CDP — turn CDP off on the trunk, or trunk to a non-Cisco device, and nobody tells you at all. LLDP does not carry the same check.

And meanwhile, traffic passes:

Switch console showing traffic still passing across the trunk despite the native VLAN mismatch

To check it deliberately rather than waiting for a log message:

show interfaces trunk
show interfaces gigabitethernet1/0/1 switchport | include Native

show interfaces trunk is the better habit — it lists every trunk with its native VLAN in one column, so a mismatch across a stack shows up by eye.

The security angle: double tagging

Double tagging is a VLAN hopping attack in which the attacker sends a frame carrying two stacked 802.1Q tags so that the first switch strips one and the second switch acts on the other, delivering traffic into a VLAN the attacker was never permitted to reach. The native VLAN is the mechanism that makes it work, and understanding it follows directly from the two rules above.

An attacker on an access port in the native VLAN sends a frame carrying two 802.1Q tags: an outer tag matching the native VLAN, and an inner tag for the VLAN they want to reach.

The first switch processes the outer tag. It matches the native VLAN, so the rule says strip it. The frame goes out the trunk still carrying the inner tag.
The second switch sees a normally-tagged frame for the target VLAN and delivers it there.

The frame has crossed into a VLAN the attacker was never allowed into. It is one-way — there is no return path, because the reply comes back as an ordinary single-tagged frame — but one-way is enough for plenty of things, and it needs no privileged access at all.

It only works if the attacker’s access VLAN is the same as the trunk’s native VLAN. That single condition is why the mitigation is what it is.

What to actually configure

Make the native VLAN a VLAN nothing uses:

vlan 999
 name NATIVE-UNUSED
 shutdown
!
interface GigabitEthernet1/0/48
 description Uplink
 switchport mode trunk
 switchport nonegotiate
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30

Three things are doing work there:

Native VLAN 999, not 1. VLAN 1 is the default everywhere, carries control-plane chatter, and is the VLAN an attacker will assume.
Nothing is in VLAN 999. No access port uses it, so the double-tagging precondition cannot be met.
999 is not in the allowed list. The native VLAN does not have to be permitted on the trunk. Pruning it means untagged frames have nowhere to go.

Set the same native VLAN on both ends. That sounds obvious right up until someone adds a switch at 2am and takes the default.

Removing the concept entirely

Where the platform supports it, you can tag everything and stop having a native VLAN in any meaningful sense:

vlan dot1q tag native

With this set, the trunk tags outgoing frames on the native VLAN too, and untagged frames arriving on a trunk are dropped rather than filed into a VLAN. Both halves of the double-tagging attack fail: there is no tag-stripping step to abuse, and an untagged injection has nowhere to land.

The trade-off is that anything genuinely relying on untagged frames over that trunk stops working. In a network of managed switches that is usually nothing. It is a global command on most platforms, so verify before applying it to a live device — this is a good candidate for a timed rollback rather than a hopeful write memory.

The short version

Untagged in means native. Native out means untagged. Everything else — the mismatch behaviour, the CDP warning, the hopping attack, and the reason the mitigation looks the way it does — is a consequence of those two sentences.

Sources

Cisco — VLAN Configuration Guide: Configure VLAN Trunking, for native VLAN behaviour on 802.1Q trunks
Cisco — Configuring Access and Trunk Interfaces (NX-OS), for the tag-matching-native hazard and vlan dot1q tag native
Cisco — VLAN Hopping and Security Best Practices, for the double-tagging attack mechanism and its mitigations