An 802.1Q trunk can be \u201cup\u201d at the interface level and still fail to carry the VLAN that an application needs. That is why trunk troubleshooting should not stop at link state.<\/p>\n
A working trunk requires the two switches to agree on the operational Layer 2 role of the link, the VLANs that should cross it, and how untagged traffic is handled. These are current 200-301 CCNA skills in v1.1 and remain part of the February 2027 v2.0 blueprint. A useful CCNA 200-301 switching practice<\/a> exercise should require separate checks for the allowed VLANs, the operational trunk mode and the spanning-tree forwarding state before anyone changes switch configuration.<\/p>\n A normal access port belongs to one VLAN for ordinary endpoint traffic. A trunk is designed to carry traffic for multiple VLANs between network devices.<\/p>\n IEEE 802.1Q identifies the VLAN by inserting a tag into Ethernet frames that need to retain VLAN context across the shared link. A broader explanation of network trunking<\/a> is useful for the tagging model; troubleshooting starts when you ask whether the operational trunk is carrying the right<\/em> VLANs.<\/p>\n The key word is operational. A configuration line alone does not prove the switch is forwarding traffic for a particular VLAN.<\/p>\n On a Cisco 802.1Q trunk, native-VLAN traffic is normally sent untagged, while frames for other VLANs carry tags. That is why both ends must agree on the native VLAN and why an untagged frame can be interpreted differently when the configurations do not match. The trunk is one physical interface, but each VLAN still has its own forwarding and spanning-tree context.<\/p>\n First confirm that both interfaces are physically up and that each side is operating as expected.<\/p>\n On Cisco Catalyst platforms, That output immediately separates several failure types that otherwise look identical to an endpoint:<\/p>\n A trunk can carry VLAN 10 successfully while dropping VLAN 20 because the allowed list differs between the two sides or was pruned intentionally.<\/p>\n That creates a classic partial-failure symptom: some users or services work across the link and others do not.<\/p>\n Start with the affected VLAN. Verify that it exists on the relevant switches, then inspect the trunk\u2019s allowed and active lists. If VLAN 20 is missing from the allowed list on either side, the trunk can remain fully up while VLAN 20 traffic fails.<\/p>\nWhat an 802.1Q trunk actually carries<\/h2>\n
Start with physical and operational trunk state<\/h2>\n
show interfaces trunk<\/code> is one of the most useful first checks because it reports trunk status, encapsulation, native VLAN, VLANs allowed on the trunk, VLANs that are active, and VLANs that are actually in a spanning-tree forwarding state.<\/p>\n\n
show interfaces trunk<\/code> is especially useful because it separates several questions that are often collapsed into one. A VLAN can be present in the configured allowed list but absent from the set that is both allowed and active. It can also be active yet missing from the final forwarding set because spanning tree is not forwarding it on that interface. Reading those categories in order is more informative than checking only the configured trunk mode.<\/p>\nshow interfaces <interface> switchport<\/code> complements that view by showing the administrative and operational switching mode plus native-VLAN information. If one side is administratively configured as an access port while the other is intended as a trunk, the operational output usually exposes that disagreement before deeper troubleshooting is necessary.<\/p>\nAn allowed VLAN mismatch can break only part of the network<\/h2>\n