How to Configure the Native VLAN on a Cisco Trunk (and Avoid Mismatches)
On an 802.1Q trunk, every VLAN's frames cross the link with a VLAN tag — except one. The native VLAN's frames are sent untagged, and by default that native VLAN is VLAN 1. That single untagged VLAN is where two things go wrong for CCNA and CCNP learners: the two ends of the trunk quietly disagree on which VLAN is native, and frames that should stay isolated leak into the wrong VLAN. This guide shows you how to set the native VLAN correctly, keep both switches in agreement, verify it, and pick a native VLAN that hardens the link instead of exposing it. Along the way you'll see why "untagged" does not mean "no VLAN" — untagged frames always belong to the native VLAN, and treating them as VLAN-less is exactly the misunderstanding attackers rely on.
Part of the VLANs, Trunking & Inter-VLAN Routing learning hub
Step 1 — Understand what the native VLAN is (and why untagged ≠ no VLAN)
An 802.1Q trunk carries traffic for many VLANs over one physical link. To keep them separate, the switch inserts a 4-byte 802.1Q tag into each frame that records its VLAN ID. The receiving switch reads that tag and forwards the frame into the matching VLAN. That is how VLANs stay isolated across a trunk.
The native VLAN is the exception: frames belonging to the native VLAN traverse the trunk with NO tag. This exists for backward compatibility — an 802.1Q trunk can interoperate with a device that doesn't understand tags, and control traffic like CDP, DTP, VTP, and PAgP historically rides untagged. By default the native VLAN is VLAN 1.
The key mental model: untagged does not mean 'no VLAN.' When a switch receives an untagged frame on a trunk, it places that frame into whatever VLAN is configured as native on that port. So the native VLAN is simply 'the VLAN an untagged frame is assumed to belong to.' If the two ends disagree about that assumption, traffic silently crosses VLAN boundaries — which is both a functional bug and a security leak.
Because the native VLAN is assumed rather than tagged, both switches on the link MUST be configured with the same native VLAN ID. Nothing in the frame itself carries that ID, so there is no self-correcting mechanism — only your configuration and CDP's after-the-fact warning.
Step 2 — Create a dedicated, unused native VLAN (not 1, not a data VLAN)
Security best practice is to make the native VLAN a VLAN you use for nothing else: not VLAN 1, and not any VLAN that carries user or server traffic. Put no hosts on it. The reason is a VLAN-hopping technique called double-tagging: an attacker sitting in the native VLAN crafts a frame with two 802.1Q tags — an outer tag matching the native VLAN and an inner tag for the target VLAN. The first switch strips the outer (native, untagged) tag, sees the inner tag, and forwards the frame toward the victim VLAN. The exploit only works when the attacker can source frames from the native VLAN, so if the native VLAN is an empty, dedicated 'parking lot' VLAN with no ports assigned, there is no attacker in it to launch from.
Create the VLAN and name it clearly so nobody assigns hosts to it later. This VLAN exists purely to be the native VLAN on your trunks.
Do this on both switches — the VLAN must exist on each device that will use it as native.
SW1# configure terminal
SW1(config)# vlan 99
SW1(config-vlan)# name NATIVE_DO_NOT_USE
SW1(config-vlan)# exitStep 3 — Form the trunk and set the native VLAN on the first switch
Configure the interface as a trunk, then set the native VLAN with the interface-level command 'switchport trunk native vlan 99'. This is the command that changes the native VLAN away from the default of 1.
A platform note: on switches that support both 802.1Q and the legacy ISL encapsulation (for example many Catalyst 3560/3650/3750 and 9300 Layer 3 switches), you must set the encapsulation to dot1q BEFORE 'switchport mode trunk' — otherwise the mode command is rejected. On dot1q-only access switches such as the Catalyst 2960, the 'switchport trunk encapsulation' command does not exist and you simply set the mode. Include the encapsulation line only if your platform requires it.
Statically forcing the mode with 'switchport mode trunk' (rather than relying on DTP auto-negotiation) makes the trunk deterministic. You'll harden the negotiation behavior further in Step 6.
SW1(config)# interface GigabitEthernet0/1
SW1(config-if)# switchport trunk encapsulation dot1q ! only on ISL-capable platforms
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk native vlan 99
SW1(config-if)# endStep 4 — Set the identical native VLAN on the other switch
Repeat the exact same native VLAN ID on the far end of the trunk. This is the step people skip — they change the native VLAN on one switch, assume it 'took,' and leave the neighbor on the default VLAN 1. The result is a native VLAN mismatch: one end sends untagged frames expecting VLAN 99, the other end receives them and drops them into VLAN 1.
There is no negotiation of the native VLAN. It is a manual agreement between two configs. If SW1 says native is 99, SW2 must also say native is 99 — a matching value, on the matching link.
Make sure VLAN 99 also exists on SW2 (Step 2) before you rely on it here.
SW2(config)# interface GigabitEthernet0/1
SW2(config-if)# switchport trunk encapsulation dot1q ! only on ISL-capable platforms
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk native vlan 99
SW2(config-if)# endStep 5 — Verify the native VLAN on BOTH switches
Confirm the result with 'show interfaces trunk' and read the 'Native vlan' column. Do this on both switches — verifying only one end proves nothing about agreement. Both must read 99.
You can also confirm on a single port with 'show interfaces GigabitEthernet0/1 switchport' and look at the 'Trunking Native Mode VLAN' line.
If the two ends disagree and CDP is running, IOS logs a native VLAN mismatch. This message is your friend — it tells you exactly which ports and which VLAN IDs are in conflict. Note that CDP only detects the mismatch; it does not fix it, and the frames are still being misdelivered while the warning fires.
SW1# show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 99
Port Vlans allowed on trunk
Gi0/1 1-4094
SW1# show interfaces GigabitEthernet0/1 switchport
...
Trunking Native Mode VLAN: 99 (NATIVE_DO_NOT_USE)
...
! Example mismatch log seen when the far end is still on VLAN 1:
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on
GigabitEthernet0/1 (99), with SW2 GigabitEthernet0/1 (1).Step 6 — Harden the native VLAN
Two optional commands raise the security bar further. First, 'vlan dot1q tag native' is a global command that forces the switch to TAG native-VLAN frames on all 802.1Q trunks instead of sending them untagged. This defeats the double-tagging VLAN-hopping attack outright, because the outer native tag is no longer stripped for free. Use it when every device on your trunks is 802.1Q-aware (which is normal in a switch-to-switch backbone).
Second, disable Dynamic Trunking Protocol on the link with 'switchport nonegotiate'. DTP auto-negotiation is the other VLAN-hopping vector (switch spoofing): a host pretending to be a switch can negotiate a trunk and gain access to all VLANs. Since you already forced 'switchport mode trunk' in Steps 3–4, turning off negotiation removes that attack surface with no downside.
Keep enforcing the rule that no access ports live in the native VLAN. The dedicated, empty native VLAN plus native tagging plus no DTP is the standard hardened baseline. Feature availability for 'vlan dot1q tag native' varies by platform and IOS/IOS-XE version, so confirm support on Cisco's current documentation for your specific switch.
SW1(config)# vlan dot1q tag native
SW1(config)# interface GigabitEthernet0/1
SW1(config-if)# switchport nonegotiate
SW1(config-if)# end
! Apply the identical hardening on SW2.Common problems (and the fix)
Native VLAN mismatch between the two ends. One switch is set to native 99, the other is still on native 1 (or a different value). Untagged frames get delivered into the wrong VLAN and CDP logs %CDP-4-NATIVE_VLAN_MISMATCH. Fix: run 'show interfaces trunk' on BOTH switches, compare the Native vlan columns, and set them to the same ID with 'switchport trunk native vlan 99' on whichever end is wrong.
Leaving the native VLAN on VLAN 1. VLAN 1 is the default everywhere, carries control traffic, and is the assumed native VLAN on unconfigured ports — a predictable target. Fix: create a dedicated, unused VLAN (Step 2) and set it as native on every trunk; do not carry user data in the native VLAN.
Assuming 'untagged' means 'no VLAN.' Learners see the native VLAN's frames leave the trunk without a tag and conclude those frames are VLAN-less. They are not — they belong to the native VLAN, and any untagged frame arriving on the trunk is placed into whatever the receiving port calls native. Fix: reason about untagged frames as 'native-VLAN frames' and make sure both ends agree on what that VLAN is.
Putting hosts in the native VLAN. If access ports live in the same VLAN you use as native, you've handed an attacker the launch point for double-tagging VLAN hopping. Fix: keep the native VLAN empty (no access-port assignments), and optionally enable 'vlan dot1q tag native' to force tagging.
Setting native VLAN before the port is actually a trunk. On some platforms 'switchport trunk native vlan' has no effect while the port is in access or dynamic mode. Fix: confirm the port is trunking with 'show interfaces trunk' (it must appear in the list) — set the encapsulation to dot1q first on ISL-capable switches, then 'switchport mode trunk', then apply the native VLAN.
Frequently asked questions
What happens if the native VLANs don't match on the two ends of a trunk?
With a native VLAN mismatch, each switch places the other's untagged frames into its own native VLAN, merging traffic from two different VLANs and creating a Layer 2 leak between them. On Cisco switches CDP detects this and logs a %CDP-4-NATIVE_VLAN_MISMATCH message, but the trunk still forwards, so the two VLANs silently bridge until you fix it. Spanning tree can also block or behave unexpectedly because BPDUs for the native VLAN cross on the wrong VLAN.
Does the native VLAN have to match on both sides of an 802.1Q trunk?
Yes, both ends must agree on the same native VLAN number for untagged frames to land in the intended VLAN. The link may still pass traffic if they disagree, which is what makes the mismatch dangerous rather than an outright failure. The only exception is when you force all VLANs to be tagged, which removes the untagged native VLAN from the equation entirely.
Why is VLAN 1 the default native VLAN considered a security risk?
VLAN 1 carries control-plane traffic like CDP, VTP, PAgP, and DTP by default and is present on every switch out of the box, so leaving it as the untagged native VLAN gives an attacker a predictable, always-present VLAN to target. Because native-VLAN frames are untagged, an attacker on an access port in VLAN 1 can attempt double-tagging (VLAN hopping) to inject frames into other VLANs. Moving the native VLAN to a dedicated unused VLAN and pruning VLAN 1 shrinks that attack surface.
How does 'switchport trunk native vlan tag' differ from just changing the native VLAN number?
Changing the native VLAN number moves which VLAN is sent untagged, but that VLAN's frames are still untagged on the wire. Adding 'vlan dot1q tag native' (globally) or forcing tagging makes the switch tag every VLAN including the native one, so no frames leave untagged at all. Tagging the native VLAN is the strongest defense against double-tagging VLAN-hopping attacks, though both ends must support and expect tagged native traffic.
Do I need to add the native VLAN to the trunk's allowed VLAN list?
Yes; the native VLAN must exist and be in the trunk's allowed list for its untagged traffic to pass, and it must also be created in the VLAN database on both switches. If you prune the native VLAN out of the allowed list, untagged frames are dropped even though the port is still configured as native. A common mistake is setting a native VLAN that was never created or was removed from 'switchport trunk allowed vlan', which black-holes the untagged traffic.
Practice this on graded Cisco labs
Reading is step one — build VLANs, Trunking & Inter-VLAN Routing on real Cisco IOS and grade your own config, or try a free sample lab first.