Symptoms
You've got a trunk link that shows up/up, CDP sees the neighbor, yet traffic from certain VLANs is disappearing into a black hole. Hosts on VLAN 30 can ping each other locally but can't reach anything beyond the trunk. The router subinterface is configured. The VLAN exists. Everything looks right. And yet — nothing.
This is one of the most frustrating categories of network problems because the physical layer gives you no indication anything is wrong. No errors, no line protocol flaps, no CRC counters incrementing. The trunk is alive. The VLANs are just not passing.
Here's what you'll typically observe in one or more combinations:
- Hosts on one or more specific VLANs lose reachability while hosts on other VLANs work fine
- Pings from affected hosts time out; ARP requests never get a reply
show interface trunk
shows fewer active VLANs in the forwarding column than you expect- The MAC address table on the upstream switch has no entries for the affected VLAN
- Inter-VLAN routing on the router-on-a-stick or Layer 3 switch stops working for specific VLANs only
- CDP logs show a native VLAN mismatch warning that someone treated as cosmetic
The good news is there's a finite list of things that cause this, and each one leaves distinct fingerprints if you know where to look. Let's go through every one of them.
Root Cause 1: Native VLAN Mismatch
Why It Happens
802.1Q trunks forward tagged frames for all VLANs except one — the native VLAN. Frames belonging to the native VLAN are sent untagged across the trunk. Both ends must agree on which VLAN is native. When they don't, untagged frames arriving on one switch get placed into the wrong VLAN. Traffic that should land in VLAN 1 ends up in VLAN 10, or vice versa. The result is either a complete blackout for the native VLAN or, worse, a subtle cross-VLAN leakage that's a security incident waiting to happen.
CDP catches this mismatch and logs a warning. I've seen engineers dismiss it as "just a CDP message" and move on. That's always a mistake.
How to Identify It
Check your syslog or run
show logand look for this message:
%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on GigabitEthernet1/0/1 (1),
with sw-infrarunbook-01 GigabitEthernet1/0/24 (10).Then confirm with
show interface trunkon both sides and compare the Native vlan column:
sw-infrarunbook-01# show interface gigabitEthernet1/0/1 trunk
Port Mode Encapsulation Status Native vlan
Gi1/0/1 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi1/0/1 1-4094
Port Vlans allowed and active in management domain
Gi1/0/1 1,10,20,30
Port Vlans in spanning tree forwarding state and not pruned
Gi1/0/1 1,10,20,30If this switch shows native VLAN 1 and the neighbor shows native VLAN 10, you've found the problem. Untagged frames are being misclassified on one or both sides.
How to Fix It
Pick a native VLAN and configure it identically on both ends. Rather than using VLAN 1 (the default), use a dedicated unused VLAN — VLAN 999 is a common convention — so native VLAN traffic carries no actual user data:
sw-infrarunbook-01(config)# interface gigabitEthernet1/0/1
sw-infrarunbook-01(config-if)# switchport trunk native vlan 999Apply the exact same command on the far end. If you want to eliminate untagged native VLAN traffic entirely, add this global command on both switches:
sw-infrarunbook-01(config)# vlan dot1q tag nativeThis forces the switch to tag native VLAN frames outbound and drop any untagged frames it receives inbound. It completely eliminates native VLAN ambiguity. Use it consistently on both sides or not at all.
Root Cause 2: Trunk Not Allowing the VLAN
Why It Happens
The
switchport trunk allowed vlancommand controls which VLANs are permitted to traverse a trunk. The default is all VLANs (1–4094), but the moment someone runs
switchport trunk allowed vlan 40without the
addkeyword, the entire allowed list is replaced with just VLAN 40. Every other VLAN is silently dropped from that point forward. This is an extremely common mistake during VLAN additions. Someone's trying to add VLAN 40 to the trunk and inadvertently wipes the existing list in the process.
How to Identify It
sw-infrarunbook-01# show interface gigabitEthernet1/0/24 trunk
Port Mode Encapsulation Status Native vlan
Gi1/0/24 on 802.1q trunking 1
Port Vlans allowed on trunk
Gi1/0/24 40
Port Vlans allowed and active in management domain
Gi1/0/24 40
Port Vlans in spanning tree forwarding state and not pruned
Gi1/0/24 40Right there — "Vlans allowed on trunk" shows only VLAN 40. VLANs 10, 20, and 30 are gone. That's the culprit. The fix is straightforward but the damage depends on how long that config has been in place.
How to Fix It
Use the
addkeyword to append VLANs to the existing allowed list rather than replacing it:
sw-infrarunbook-01(config)# interface gigabitEthernet1/0/24
sw-infrarunbook-01(config-if)# switchport trunk allowed vlan add 10,20,30Or if you want to reset the trunk back to all VLANs:
sw-infrarunbook-01(config-if)# switchport trunk allowed vlan allAfter applying, verify that all expected VLANs appear in the final forwarding line:
sw-infrarunbook-01# show interface gigabitEthernet1/0/24 trunk
Port Vlans allowed on trunk
Gi1/0/24 1-4094
Port Vlans allowed and active in management domain
Gi1/0/24 10,20,30,40
Port Vlans in spanning tree forwarding state and not pruned
Gi1/0/24 10,20,30,40All four VLANs now appear in every column. Traffic should resume immediately — no bounce required.
Root Cause 3: VTP Pruning
Why It Happens
VTP (VLAN Trunking Protocol) pruning is designed to reduce unnecessary flooded traffic by removing VLANs from trunk links where no active ports exist in that VLAN on the downstream switch. The problem is it can prune a VLAN from a trunk even when that VLAN needs to transit through the switch — a switch with no local ports in that VLAN, but which is part of the forwarding path between two switches that do. VTP pruning doesn't understand transit traffic. It only checks local port membership.
VTP pruning only activates when VTP is in server or client mode. Switches running VTP transparent mode are not subject to pruning.
How to Identify It
The fourth line of
show interface trunkis the one that tells the real story. A VLAN that's allowed and active but missing from the "spanning tree forwarding state and not pruned" column is being pruned off the trunk:
sw-infrarunbook-01# show interface gigabitEthernet1/0/1 trunk
Port Vlans allowed on trunk
Gi1/0/1 1-4094
Port Vlans allowed and active in management domain
Gi1/0/1 10,20,30,40
Port Vlans in spanning tree forwarding state and not pruned
Gi1/0/1 10,20,40VLAN 30 is allowed and shows active but is absent from the final line. Confirm VTP is the cause with:
sw-infrarunbook-01# show interface gigabitEthernet1/0/1 pruning
Port Vlans pruned due to VTP:
Gi1/0/1 30Also check VTP pruning status overall:
sw-infrarunbook-01# show vtp status
VTP Version capable : 1 to 3
VTP version running : 2
VTP Domain Name : solvethenetwork
VTP Pruning Mode : Enabled
VTP Traps Generation : Disabled
Device ID : 0050.7966.6800"VTP Pruning Mode: Enabled" confirms pruning is active in the domain.
How to Fix It
Disable VTP pruning globally if it's causing more problems than it's worth:
sw-infrarunbook-01(config)# no vtp pruningIf you want to keep pruning enabled for most VLANs but exempt a specific VLAN on a trunk port, mark it as pruning-ineligible on that interface:
sw-infrarunbook-01(config)# interface gigabitEthernet1/0/1
sw-infrarunbook-01(config-if)# switchport trunk pruning vlan remove 30This tells VTP not to prune VLAN 30 on this specific trunk port, regardless of local port membership. VLANs 1 and 1002–1005 are permanently pruning-ineligible and don't need this treatment.
Root Cause 4: STP Blocking
Why It Happens
Cisco's Per-VLAN Spanning Tree Plus (PVST+) runs a separate STP instance for each VLAN. A trunk port can simultaneously be in forwarding state for VLAN 10 and blocking state for VLAN 30. This is intentional — it's how PVST+ enables per-VLAN load balancing. But when the topology isn't what you expect, critical VLANs end up blocked on the only path available to them.
In my experience, this surfaces most often after a network change. Someone adjusts STP priorities for one VLAN without realizing the effect on others. A new switch gets added without an explicit bridge priority configured, its MAC address happens to be numerically lower than the current root, and it becomes the unexpected root bridge for a VLAN — reshaping the entire forwarding topology for that instance.
How to Identify It
Run
show spanning-tree vlan <id>for the affected VLAN and look at the Sts (state) column for each interface:
sw-infrarunbook-01# show spanning-tree vlan 30
VLAN0030
Spanning tree enabled protocol ieee
Root ID Priority 32798
Address 0050.7966.6800
Cost 4
Port 24 (GigabitEthernet1/0/24)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 32798 (priority 32768 sys-id-ext 30)
Address 0050.7966.6801
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300 sec
Interface Role Sts Cost Prio.Nbr Type
------------------- ---- --- --------- -------- --------------------------------
Gi1/0/1 Desg FWD 4 128.1 P2p
Gi1/0/24 Root BLK 4 128.24 P2pGi1/0/24 is the root port for VLAN 30 but it's in BLK state — that's the problem. STP is blocking the uplink for this VLAN. Cross-reference with
show interface trunk: VLAN 30 appears in the active line but drops off the final "forwarding and not pruned" column, which is the same symptom as VTP pruning. The difference is that
show spanning-tree vlan 30will clearly show the BLK state.
How to Fix It
First determine whether the blocking is intentional load balancing or an unexpected topology error. If unintentional, correct the root bridge placement by setting an explicit priority:
sw-infrarunbook-01(config)# spanning-tree vlan 30 priority 4096Or use the built-in macro which sets the priority to a value lower than any existing root:
sw-infrarunbook-01(config)# spanning-tree vlan 30 root primaryIf unexpected BPDUs are arriving on a port and causing topology changes, use the following to see what's sending them:
sw-infrarunbook-01# debug spanning-tree bpdu receiveDon't disable STP as a shortcut. That will give you a forwarding loop that's far worse than a blocked port. Investigate why it's blocking and fix the root cause — usually a misconfigured bridge priority or an unexpected switch in the topology.
Root Cause 5: Encapsulation Mismatch (dot1q vs ISL)
Why It Happens
ISL (Inter-Switch Link) is Cisco's legacy proprietary trunking encapsulation. 802.1Q (dot1q) is the IEEE standard that replaced it. Older Catalyst platforms — 3550, 4500, 6500 series — supported both. When one side of a trunk is configured for ISL and the other is configured for dot1q, the trunk may still negotiate as "up" but frames will be malformed on arrival. The receiving switch tries to interpret ISL-encapsulated frames as 802.1Q, strips the wrong header, and either drops the packet or misclassifies it. Traffic appears to enter the trunk and vanish.
This shows up most in migration scenarios — connecting older Catalyst hardware to a modern IOS-XE switch during a refresh. The older switch defaults to ISL in its DTP negotiation; the Catalyst 9000 series doesn't support ISL at all. When the trunk mode is hard-coded without specifying encapsulation, whatever platform default applies takes over — and if those defaults differ, you have a silent mismatch.
How to Identify It
Look at the Encapsulation column in
show interface trunk:
sw-infrarunbook-01# show interface gigabitEthernet1/0/1 trunk
Port Mode Encapsulation Status Native vlan
Gi1/0/1 on isl trunking 1If this side shows
island the neighbor shows
802.1q, you've found it. In more severe mismatches where the trunk won't form at all, you'll see this:
Port Mode Encapsulation Status Native vlan
Gi1/0/1 on isl not-trunking 1Also check the running config for an explicit encapsulation command (or the absence of one) on the interface in question:
sw-infrarunbook-01# show running-config interface gigabitEthernet1/0/1
Building configuration...
interface GigabitEthernet1/0/1
switchport trunk encapsulation isl
switchport mode trunkHow to Fix It
Explicitly set the encapsulation to dot1q. On platforms that support ISL, you must set encapsulation before setting the trunk mode — IOS enforces this order:
sw-infrarunbook-01(config)# interface gigabitEthernet1/0/1
sw-infrarunbook-01(config-if)# switchport trunk encapsulation dot1q
sw-infrarunbook-01(config-if)# switchport mode trunkApply the same on the far end. On modern IOS-XE platforms like the Catalyst 9000 series, ISL is not supported at all — dot1q is implicit and the encapsulation sub-command doesn't exist. But when connecting to older hardware, always verify both sides explicitly rather than assuming DTP will negotiate correctly.
Root Cause 6: VLAN Not in the Database
Why It Happens
A VLAN must exist in the local VLAN database for traffic to be forwarded — even if the trunk allows it, even if STP is in forwarding state for it. On VTP client switches, VLANs are learned from the VTP server. If the VTP server doesn't have the VLAN defined, client switches won't have it either, and any frames tagged for that VLAN will be silently discarded. The trunk carries the tag. The switch just doesn't know what to do with it.
How to Identify It
sw-infrarunbook-01# show vlan brief
VLAN Name Status Ports
---- -------------------------------- --------- -------------------------------
1 default active Gi1/0/3, Gi1/0/4
10 MGMT active Gi1/0/5
20 SERVERS active Gi1/0/6, Gi1/0/7
1002 fddi-default act/unsup
1003 token-ring-default act/unsup
1004 fddinet-default act/unsup
1005 trnet-default act/unsupVLAN 30 is missing from the database entirely. Even though the trunk may allow VLAN 30, the switch has nowhere to put that traffic — it gets dropped.
How to Fix It
Create the VLAN locally:
sw-infrarunbook-01(config)# vlan 30
sw-infrarunbook-01(config-vlan)# name WORKSTATIONS
sw-infrarunbook-01(config-vlan)# exitIf the switch is a VTP client and won't accept locally created VLANs, you'll need to create the VLAN on the VTP server. Alternatively, temporarily switch this switch to VTP transparent mode to allow local VLAN creation, add the VLAN, then return to client mode. Just be aware that returning to client mode will re-sync the VLAN database from the server — make sure the VLAN is on the server first.
Root Cause 7: Port Not Actually in Trunk Mode
Why It Happens
DTP (Dynamic Trunking Protocol) negotiates trunk mode between switches. If both sides of a link are set to
dynamic auto, neither end initiates trunking and the link stays in access mode. No trunking means no VLAN tagging, so only the native access VLAN passes — every other VLAN is dropped. This happens when someone forgets to set the trunk mode explicitly, or when a port is reset to default configuration during troubleshooting.
How to Identify It
sw-infrarunbook-01# show interface gigabitEthernet1/0/1 trunk
Port Mode Encapsulation Status Native vlan
Gi1/0/1 auto 802.1q not-trunking 1"not-trunking" — this port is operating as an access port. Zero VLANs are being trunked. The remaining lines of the output will be empty or show nothing of value.
How to Fix It
Set the port explicitly to trunk mode and disable DTP negotiation at the same time:
sw-infrarunbook-01(config)# interface gigabitEthernet1/0/1
sw-infrarunbook-01(config-if)# switchport mode trunk
sw-infrarunbook-01(config-if)# switchport nonegotiateDo this on both ends of every inter-switch link.
switchport nonegotiatedisables DTP entirely on the port, preventing any unexpected mode negotiation and eliminating DTP as a potential security exposure — DTP can be abused to negotiate a rogue trunk from an untrusted endpoint.
Prevention
Most of these issues are entirely preventable with disciplined, explicit configuration habits. Always set trunk ports deliberately — mode, encapsulation, and native VLAN — rather than relying on defaults or DTP negotiation. Treat
switchport nonegotiateas mandatory on every inter-switch uplink. It costs nothing and eliminates an entire class of problems.
The single most common cause I've seen in production is the missing
addkeyword when updating a trunk's allowed VLAN list. Make it policy across your team: always use
switchport trunk allowed vlan addwhen appending to an existing trunk. If you're starting fresh and want all VLANs, explicitly run
switchport trunk allowed vlan allso the intent is clear in the config.
For VTP, consider moving your environment to VTP transparent mode. It's more operational overhead — you create VLANs manually on each switch — but it eliminates VTP pruning surprises, version mismatches, and the risk of a misconfigured VTP server wiping your entire VLAN database. In environments with configuration management or automation, transparent mode is almost always the safer choice.
STP root bridge placement should be explicit and documented. Set
spanning-tree vlan <id> root primaryand
root secondaryon your aggregation layer switches and document which switch is root for which VLANs. If the topology shifts unexpectedly, you want to know immediately — configure
spanning-tree topology-change syslogso every TCN gets logged.
Build a trunk verification sequence into your change procedures. Run this any time you modify a trunk or add a VLAN:
sw-infrarunbook-01# show interface trunk
sw-infrarunbook-01# show vlan brief
sw-infrarunbook-01# show spanning-tree vlan 30
sw-infrarunbook-01# show vtp statusA well-configured trunk is completely deterministic. The "Vlans in spanning tree forwarding state and not pruned" line should match exactly what you expect — no more, no less. If any VLAN in your allowed list isn't showing in that final column, you have a problem to investigate. Don't accept it, don't work around it — find the cause and fix it. The seven causes above cover the overwhelming majority of what you'll encounter.