'My Trunk Won't Pass VLAN 20' — A 6-Step Debug Workflow (CCNA)

You configured a trunk between two switches. VLAN 10 hosts ping each other across it just fine. VLAN 20 hosts cannot. Same trunk. Same switches. What’s going on?

This is one of the most common debug moments in CCNA-level labs. It catches everyone the first time. Here’s the systematic workflow we use in the CCNA Career Track — it finds the cause in under 5 minutes 95% of the time.

Step 1 — confirm the trunk is actually a trunk

Run on both ends:

SW1# show interfaces Gi1/0/24 switchport | include Mode
Administrative Mode: trunk
Operational Mode: trunk

Both must say Mode: trunk. If either says static access or dynamic auto, the trunk failed to negotiate. Common cause: you set one side to mode trunk but left the other as default (which is dynamic auto) on a platform where both sides need to actively initiate.

Fix: set both ends explicitly:

SW1(config)# interface Gi1/0/24
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport nonegotiate

The nonegotiate disables DTP — explicit beats implicit. Configure the same on SW2’s matching port.

Step 2 — check the allowed-VLAN list

Even on a fully working trunk, only VLANs in the allowed list cross it.

SW1# show interfaces Gi1/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  1-10

That’s the bug right there. 1-10 does not include VLAN 20. Even though VLAN 20 exists on the switch, the trunk is silently dropping it.

Fix: add VLAN 20 to the allowed list.

SW1(config-if)# switchport trunk allowed vlan add 20

The word add is important — without it, you overwrite the list and may lose VLAN 10.

Verify:

SW1# show interfaces Gi1/0/24 trunk
Port      Vlans allowed on trunk
Gi1/0/24  1-10,20

Step 3 — confirm VLAN 20 exists in the VLAN database

A subtle one. The VLAN must exist as a database entry, not just be referenced on an access port.

SW1# show vlan brief
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Gi1/0/1, Gi1/0/2, ...
10   USERS                            active    Gi1/0/3, Gi1/0/4
99   MGMT                             active    Gi1/0/23

VLAN 20 is missing. The trunk is allowing it but the switch doesn’t know what VLAN 20 is. Frames tagged with 20 get accepted at the trunk but then dropped because there’s no internal VLAN data structure.

Fix: create VLAN 20 in the database — on both switches.

SW1(config)# vlan 20
SW1(config-vlan)# name SERVERS
SW1(config-vlan)# exit

On SW2 too. Now show vlan brief shows VLAN 20.

Step 4 — check VTP isn’t pruning it

If you’re running VTP (older Cisco environments), the protocol can auto-prune VLANs from trunks where it thinks they’re not needed.

SW1# show vtp status
VTP Operating Mode: Server
VTP Pruning Mode: Enabled

If pruning is enabled and VLAN 20 has no active access ports on the other end, VTP might decide to skip flooding VLAN 20 over the trunk. Strange but it happens.

Fix: either disable VTP pruning (no vtp pruning) or add an access port in VLAN 20 on the receiving switch (gives VTP the signal that VLAN 20 is “wanted”).

In 2026 most environments disable VTP entirely or use VTP v3 in transparent mode. See the VTP library topic for the full picture.

Step 5 — native VLAN mismatch

Less common but devastating when it happens. The native VLAN on a trunk is the one that travels untagged. If SW1’s native VLAN is 1 and SW2’s is 99, every untagged frame gets interpreted as the wrong VLAN.

SW1# show interfaces Gi1/0/24 trunk | include Native
Port      Native vlan
Gi1/0/24  1

SW2# show interfaces Gi1/0/24 trunk | include Native
Port      Native vlan
Gi1/0/24  99

CDP / DTP will log this mismatch — check show log for messages like:

%CDP-4-NATIVE_VLAN_MISMATCH: Native VLAN mismatch discovered on interface ...

Fix: make both ends agree. Best practice: don’t use VLAN 1 as native (it’s also the management VLAN by default in old labs — security risk). Use an explicit unused VLAN like 999.

SW1(config-if)# switchport trunk native vlan 999
SW2(config-if)# switchport trunk native vlan 999

Make sure VLAN 999 exists in the database on both.

Step 6 — confirm the physical layer

The least sexy step but the most common cause when steps 1–5 check out: bad cable, wrong patch, or a switchport that’s err-disabled and looks “up” in some quick views.

SW1# show interfaces Gi1/0/24 status
Port    Name   Status      Vlan   Duplex   Speed Type
Gi1/0/24        connected   trunk  a-full   1000  10/100/1000BaseTX

connected is what you want. notconnect, disabled, or err-disabled mean trouble. Recheck the cable, the patch, and the port-security configuration on user-facing ports (port security can err-disable trunks if it gets misapplied).

The 6-step workflow as a checklist

When VLAN traffic mysteriously isn’t crossing a trunk:

1. Trunk mode confirmed both ends?
2. VLAN in allowed list?
3. VLAN exists in database?
4. VTP pruning interfering?
5. Native VLAN matches?
6. Physical layer healthy?

This catches 95% of cases. The remaining 5% are spanning-tree blocking the trunk for that VLAN (rare), a port-channel misconfiguration (more common), or the destination host actually being in the wrong VLAN to begin with (don’t laugh — common with student labs).

How to get faster at this

The fastest way is doing it 50 times in our weekly 1:1 labs until you stop having to think about the checklist. The slower way is reading more articles like this one. Both work — but only one closes the gap from “I read about VLANs” to “I troubleshoot VLAN issues by reflex in front of a network outage.”

Free first session is on the house if you want to try the format.

More from the library

• VLANs Without the Overload — the core mental model
• Trunks and 802.1Q — full reference
• VLANs library topic
• Switching Operation