3.1Troubleshooting 802.1Q trunking

The infrastructure domain is the largest in ENCOR at 30 percent, and trunking is its entry point. In the field you routinely hit faults like "I created a new VLAN but the far site cannot see it" or "frames from VLAN 10 are somehow leaking into VLAN 99," and both share one trait: the cause is invisible until you compare the configuration on both ends of the link. This section builds the ability to read show interfaces trunk and show interfaces switchport to determine whether the trunk formed, which VLANs are actually forwarding, and whether the native VLAN matches, and to pick the right suspect for each symptom.

3.1.1802.1Q tagging and the native VLAN

• 802.1Q inserts a 4-byte tag immediately after the source MAC address of an Ethernet frame, and its 12-bit VLAN ID (1-4094) indicates which VLAN the frame belongs to. A link that carries frames with the tag intact is a trunk, multiplexing multiple VLANs onto one physical link, whereas an access port carries a single VLAN with no tag.
• The native VLAN is the single VLAN sent untagged on a trunk, defaulting to VLAN 1. The receiving side treats untagged frames as belonging to its own native VLAN, so if the two ends disagree, frames in VLAN A on one side are treated as VLAN B on the other—this is VLAN leaking (VLAN hopping). Set it explicitly with switchport trunk native vlan 99.
• A native VLAN mismatch does not bring the link down—the nasty part is that communication half-works while leaking—but with CDP enabled a %CDP-4-NATIVE_VLAN_MISMATCH syslog appears. For security, the recommended practice is to change the native VLAN to an unused VLAN and tag every VLAN with switchport trunk native vlan tag.

3.1.2DTP and static trunk combinations

• DTP (Dynamic Trunking Protocol) is a Cisco-proprietary protocol that negotiates with the neighboring port to decide automatically whether the link becomes a trunk or an access port. The modes are switchport mode dynamic desirable (actively proposes a trunk) and switchport mode dynamic auto (only accepts a proposal). switchport mode trunk is a static trunk and switchport mode access a static access port.
• Learn the outcome table by the principle "no trunk forms unless someone actively proposes one," not by rote. desirable+auto = trunk, desirable+desirable = trunk, but auto+auto stays access (both merely wait, so no proposal is ever made). trunk+auto/desirable = trunk. trunk+access is a mismatch: no trunk forms and VLANs do not pass.
• Production designs conventionally avoid DTP and pin the mode statically, configuring switchport mode trunk plus switchport nonegotiate (stop sending DTP frames) on both ends. On access ports, specify switchport mode access to close off unintended trunk formation via DTP negotiation—a foothold for VLAN hopping attacks.

3.1.3The allowed VLAN list and what actually forwards

• A trunk allows all VLANs (1-4094) by default, but you can narrow it with switchport trunk allowed vlan 10,20,30. Always use switchport trunk allowed vlan add 40 when adding—forgetting add replaces the entire list, a classic outage in which every previously working VLAN drops at once.
• show interfaces trunk prints three lists in narrowing order: Vlans allowed on trunk (configured), then Vlans allowed and active in management domain (also existing and active on the switch), then Vlans in spanning tree forwarding state and not pruned (also forwarding under STP). For a symptom where only one VLAN fails, seeing which of the three stages it drops out at pinpoints the cause.
• So if a VLAN is "in the allowed list yet does not pass," it is either not created or shut down on the switch (it disappears at stage two) or blocking under STP / pruned by VTP pruning (it disappears at stage three). Verify VLAN existence with show vlan brief and the STP state with show spanning-tree vlan 10.

Suppose you are investigating a fault between campus distribution switch DSW1 and access switch ASW1. The symptom: "hosts in VLAN 10 and VLAN 20 communicate fine, but only hosts in the newly added VLAN 30 cannot reach their gateway." Running show interfaces trunk on ASW1 shows Gi1/0/1 with Mode on and Status trunking, so the trunk itself formed, and Vlans allowed on trunk lists 10,20,30. Concluding "it is allowed, so the configuration is correct" is a only-partly-correct judgment. Lower in the same output, Vlans allowed and active in management domain shows only 10,20—30 has disappeared. That is not an allowed-list problem; it means VLAN 30 does not exist on ASW1 at all. show vlan brief confirms VLAN 30 is missing, while DSW1 already had it, so the configuration landed on only one side. Creating vlan 30 makes 30 appear in the second list, then in the third, Vlans in spanning tree forwarding state and not pruned, and connectivity returns. If instead 30 were missing only from the third list, the next suspects would be STP blocking the port for that VLAN or VTP pruning removing it, and you would move on to show spanning-tree vlan 30. By contrast, if the symptom were not "VLAN 30 fails" but "hosts in VLAN 1 and VLAN 99 can unexpectedly see each other," the allowed list is not the issue—a native VLAN mismatch is the strong suspect, and you should compare the Native vlan column on both ends. The class of symptom (everything down / one VLAN only / unintended reachability) determines where you look, and that mapping is the heart of trunk troubleshooting.

3.1.4Section summary

• 802.1Q multiplexes via the VLAN ID in a 4-byte tag and only the native VLAN is untagged; a mismatch causes VLAN leaking without dropping the link
• DTP hinges on whether an active proposer exists, so auto+auto never trunks; production pins it statically with switchport mode trunk plus nonegotiate
• The stage at which a VLAN drops out of the three lists (allowed -> active -> forwarding) in show interfaces trunk names the cause; omitting add on allowed vlan is a full-replacement outage