Native VLAN Mismatch: Read the CDP Log, Fix the Trunk

Very few Cisco log messages hand you the interface and both sides of the misconfiguration in a single line. %CDP-4-NATIVE_VLAN_MISMATCH does, which is why it is at once the easiest Layer 2 fault to fix and one of the most commonly ignored. It is severity 4, it never takes the trunk down, and it repeats forever, so it gets filtered out of the syslog view and forgotten.

That is a mistake, because of what is happening underneath the warning. A native VLAN mismatch does not black-hole a link in any obvious way. It quietly stitches two VLANs together across the trunk, giving you an unauthorised Layer 2 path between two broadcast domains that your firewall and your router ACLs never see. This article is the symptom-to-fix path: what the message says, what is happening to frames, why the warning can vanish while the fault stays, and how to close it out. If you are still assembling the bigger picture of how VLANs and 802.1Q trunks carry traffic across a switched network, start there and come back.

One sentence of orientation and no more: the native VLAN is the single VLAN whose frames cross an 802.1Q trunk untagged, and if you want the full treatment of why untagged frames exist on a tagged link at all, that is a separate read. Everything below was captured on a live lab, two ioll2-xe switches running IOS XE 17.18.2 in Cisco Modeling Labs, trunked back to back with deliberately mismatched native VLANs.

The message, and how to read the two VLAN numbers

Here is the real thing, straight off the console of SW1. The timestamp has been trimmed from the front of each line, which is why the leading asterisk is left dangling:

SW1:
*CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on Ethernet0/0 (1), with SW2 Ethernet0/0 (99).
*CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on Ethernet0/0 (1), with SW2 Ethernet0/0 (99).
(repeats at the CDP interval: 19:56:21, 19:57:21, 19:58:18, 19:59:17, 20:00:15, 20:01:13 ...)

The message is self-diagnosing. Read it as four fields:

• on Ethernet0/0 is the local interface, on the switch that printed the line.
• (1) immediately after it is the local native VLAN. That is your side.
• with SW2 Ethernet0/0 is the neighbour device name and its interface, learned from CDP.
• (99) is the neighbour's native VLAN.

So SW1 is running native VLAN 1 on Et0/0 and SW2 is running native VLAN 99 on the other end of the same cable. The parenthesised numbers are the entire investigation, and the only question left is which of the two your standard says it should be.

Two operational details. Both switches log it, each with its own number first, so a central syslog shows two complementary messages for what is one fault. And look at the timestamps: roughly every 60 seconds, the CDP advertisement interval, forever. This is not a transient you can wait out. In a noisy buffer, show logging | include NATIVE_VLAN_MISMATCH pulls it straight out.

What is actually broken: two VLANs bridged into one

The warning is cosmetic. The forwarding behaviour is not.

On an 802.1Q trunk every frame carries a VLAN tag except the ones in the native VLAN, which are sent bare. The receiving switch has no tag to read, so it applies its own rule: an untagged frame arriving on a trunk belongs to my native VLAN. When the two ends disagree, that rule silently rewrites VLAN membership at the trunk boundary.

In the lab above, a frame in VLAN 1 leaves SW1 untagged. SW2 receives it, sees no tag, and places it into VLAN 99. In the return direction, a VLAN 99 frame leaves SW2 untagged and SW1 drops it into VLAN 1. The tagged VLANs on that trunk are unaffected and keep working perfectly, which is exactly why this failure is so good at hiding. Nothing goes down. What you get instead is:

• Leakage. VLAN 1 on SW1 and VLAN 99 on SW2 are now one broadcast domain, mixing ARP, DHCP, broadcasts and unicast flooding. If either was your management or quarantine VLAN, it is no longer isolated.
• Black-holing. A host in the native VLAN cannot reach its gateway across the trunk, because its frames arrive in the wrong VLAN and the gateway SVI never hears them. It presents as "one VLAN cannot reach anything past the trunk" while every other VLAN is fine.
• Address confusion. Two subnets sharing one broadcast domain gives you ARP entries that will not resolve and DHCP offers from a scope that has no business being there.

Spanning tree can react too, depending on the mode. Per-VLAN spanning tree sends the native VLAN's BPDUs untagged, so they land in the wrong instance on the far end, and PVST+ can spot the port-VLAN-ID inconsistency and block the port for the affected VLANs to contain the damage (MST shares one BPDU per region and will not raise the same per-VLAN complaint). If a trunk misbehaves for one VLAN and behaves for the rest, how spanning tree builds a separate topology per VLAN explains why the blast radius is VLAN-scoped rather than link-scoped. In this lab run, the only thing that complained on the console was CDP.

The trap: CDP detects it, CDP does not cause it

This is the part that catches people, and it is the reason to treat the message as a symptom rather than as the problem itself.

The mismatch is a pure configuration disagreement between two switchport trunk native vlan statements, and it exists whether or not anything notices. CDP carries the native VLAN in its advertisements, so a Cisco switch can compare what its neighbour claims against its own setting and raise the alarm. That detection is a courtesy, not an enforcement mechanism, which means:

• Run no cdp run globally, or no cdp enable on that interface, and the messages stop immediately while the two VLANs stay bridged. Hardening guides routinely recommend disabling CDP at the edge, so plenty of networks have already switched off their own smoke detector.
• Trunk to a non-Cisco switch, a hypervisor uplink, or a firewall doing 802.1Q, and there is no CDP relationship to do the comparison. IOS will not raise an equivalent alarm from LLDP, so mismatches on those links get found by users, not by logs.
• Silence after a change is not proof of a fix. It is proof that nothing is currently telling you. Verify the configuration, not the absence of a log line.

The fix

Confirm both ends first. The mismatch message already gave you the two numbers, but on a real trunk you want to see the running state, not just CDP's opinion of it:

show interfaces trunk                 ! compare the "Native vlan" column on both ends
show cdp neighbors detail             ! CDP reports the neighbor's native VLAN
show run interface Ethernet0/0 | include native

Then pick the value your standard mandates (which for most networks is a dedicated, unused VLAN and not VLAN 1) and set it on the end that is wrong:

interface Ethernet0/0
 switchport trunk native vlan 99

Two things to get right while you do it. The VLAN you choose must exist on both switches and be in the trunk's allowed list, otherwise you have swapped a mismatch for a pruned native VLAN, which is a different and more confusing failure. And if you are working remotely, know your management path before you type, because between changing the first end and the second you are the one causing the mismatch. Standardising the native VLAN across an estate is a design decision rather than an incident action, so moving the native VLAN off VLAN 1 without dropping the trunk is worth planning properly rather than doing at 2am.

The other legitimate fix is to stop having an untagged VLAN at all:

vlan dot1q tag native

This tags native VLAN traffic on egress instead of sending it bare, removing the ambiguity the whole problem depends on. It is global, and only safe if you apply it on both ends and every device sharing those trunks. Applying it on one side converts a mismatch you can see into an asymmetry you cannot.

Verify

1. show interfaces trunk on both switches, and the Native vlan column reads the same number. This is the check that actually matters.
2. Wait out two CDP intervals, about two minutes, and confirm no new NATIVE_VLAN_MISMATCH entries. Note the timestamp of the last occurrence before you change anything so you can tell old messages from new.
3. Test a host in the native VLAN across the trunk, gateway included. That is the traffic that was broken, so that is the traffic that proves it is fixed.

The same primitive an attacker uses on purpose

A native VLAN mismatch is an accidental version of a documented attack. In a double-tagging VLAN hop, the attacker sits on an access port whose VLAN matches the trunk's native VLAN and sends a frame carrying two 802.1Q tags. The first switch strips the outer tag on the way onto the trunk, because that VLAN goes untagged, and the second switch reads the inner tag and delivers the frame into a VLAN the attacker was never allowed to touch. The attacker is deliberately engineering the exact condition your trunk has stumbled into: an untagged frame that means one thing on one switch and something else on the other.

Treat the log line accordingly. It is a security finding as much as a connectivity one, and it belongs with the other Layer 2 trust failures covered in how double tagging and switch spoofing let a host cross VLANs. If two VLANs are bridged at a trunk, your segmentation model is wrong on that path whether or not anyone is currently abusing it.

What this was captured on

Gotchas

On IOL-L2 you need the encapsulation line first. ioll2-xe does accept switchport trunk encapsulation dot1q, and needs it before switchport mode trunk will take. On modern hardware that command is often gone because dot1q is the only option, so lab and production muscle memory differ here.

Everyone misreads which number is theirs. The first parenthesised VLAN belongs to the switch that printed the line, not to the neighbour. Fix the wrong end and you have simply moved the mismatch.

Only the broken state was captured in this run. The ioll2-xe image has no EEM and the PyATS console path was unavailable, so the post-fix silence was not machine-driven here. Run the verification steps above rather than trusting anyone's screenshot of a quiet log, this one included.

Severity 4 gets filtered. In an aggregated syslog carrying thousands of events a minute, a level-4 message that repeats every 60 seconds forever is exactly the kind of thing that ends up in a suppression rule. Alert on this mnemonic explicitly.

Key Takeaways

• %CDP-4-NATIVE_VLAN_MISMATCH names both interfaces and both native VLANs. The first number in parentheses is the local switch's, the second is the neighbour's.
• The damage is not the log noise. Untagged frames get re-homed at the trunk boundary, so two VLANs share one broadcast domain while every tagged VLAN keeps working normally.
• CDP only detects the condition. Disable CDP, or trunk to a non-Cisco device, and the alarm goes away while the bridged VLANs remain.
• Fix it with a matching switchport trunk native vlan on both ends, or vlan dot1q tag native on every device sharing those trunks.
• Verify with show interfaces trunk on both sides plus a traffic test in the native VLAN. Silence in the log is not verification.
• Treat it as a security event: a mismatch is the accidental form of the double-tagging VLAN hop and defeats segmentation the same way.

Native VLAN mismatches sit in the small group of Layer 2 faults that are trivially fixable and disproportionately dangerous, alongside VTP revision accidents and unpruned trunks. For the rest of that group, and the order to learn them in, work through the Layer 2 switching and trunking guide.