Native VLAN mismatch: the trunk that half works

A trunk port with mismatched native VLANs is one of networking's most deceptive problems. Traffic flows, the link shows up, and then--mysteriously--devices on the native VLAN cannot reach each other across the trunk. The trunk half works because tagged VLANs pass through correctly, but untagged frames are dropped or delivered to the wrong VLAN. Understanding why this happens and how to spot it will save you hours of troubleshooting.

What the native VLAN actually does

When a switch port operates in trunk mode (802.1q), it tags frames with a VLAN ID before sending them across the link--except for frames in the native VLAN. The native VLAN is sent untagged. On the receiving end, any untagged frame that arrives on a trunk port is automatically assigned to that port's native VLAN.

This design was meant to preserve backward compatibility with older devices that do not understand VLAN tags. But it creates a critical assumption: both ends of the trunk must agree on which VLAN is native. If they do not, untagged frames land in different VLANs on each side, and communication fails for devices on that VLAN.

How the mismatch breaks the trunk

Consider two switches connected by a trunk. Switch A has native VLAN 1, Switch B has native VLAN 100. A device on VLAN 1 at Switch A sends an untagged frame destined for a device on VLAN 1 at Switch B.

• →Switch A sees the frame on VLAN 1 (its native VLAN) and sends it untagged across the trunk.
• →Switch B receives the untagged frame and assigns it to VLAN 100 (its native VLAN).
• →The frame is delivered to VLAN 100 devices, not VLAN 1. The destination device never sees it.
• →Return traffic follows the same broken path in reverse.

Meanwhile, all tagged VLANs (2-4094) work perfectly because they carry explicit VLAN IDs in the frame header. Only the native VLAN traffic vanishes.

Spotting the symptom

Native VLAN mismatches produce a very specific symptom pattern:

• →Trunk port shows up and is in 'trunking' state (not err-disabled).
• →Devices on tagged VLANs communicate across the trunk with no issues.
• →Devices on the native VLAN cannot ping or reach each other across the trunk.
• →No obvious error messages or alerts in most cases.

The absence of errors is what makes this trap so effective. Many engineers assume a working trunk port is fully working.

Verification and fix

Check native VLAN configuration on both ends of the trunk:

! Cisco IOS
show interfaces trunk
show interfaces switchport

! Junos
show configuration interfaces ge-0/0/0 unit 0
show interfaces ge-0/0/0 native-vlan

! Arista
show interfaces trunk
show vlan native

The native VLAN must match on both sides. Best practice is to set both to VLAN 1 (the default) or to an explicit management VLAN that you control. Never leave it at the default if you are unsure--always configure it explicitly on both switches.

! Cisco IOS example: set native VLAN to 100 on both sides
interface GigabitEthernet0/1
 switchport trunk native vlan 100
 switchport mode trunk

After changing native VLAN, test connectivity on that VLAN immediately. The fix takes effect right away, and native VLAN traffic should flow.

Prevention

• →Always explicitly set native VLAN on trunk ports; never rely on defaults.
• →Document your native VLAN choice in your configuration templates.
• →Use the same native VLAN across all trunk ports in your network (usually VLAN 1 or a dedicated management VLAN).
• →Test native VLAN traffic during trunk bring-up, not just tagged VLANs.
• →Include native VLAN verification in your change control and audit checklists.