Cisco Certified Network Associate (CCNA) 200-301 · Free study guide

Objective 2.2 — Configure 802.1Q trunks

An interswitch trunk carries traffic for multiple VLANs over one logical link. 802.1Q inserts a VLAN identifier into most frames so the receiving switch can preserve broadcast-domain membership across the connection.

Operational trunk state

Configure trunk mode according to the platform and design, then verify that the port operates as a trunk. Configured intent and operational mode can differ when negotiation, encapsulation support, or a port-channel affects the interface. The physical link being up proves only basic connectivity.

The trunk's allowed list controls which VLANs may cross. A VLAN must also exist and be active where the switch forwards it. Removing a VLAN from an allowed list does not delete the VLAN; it prevents that trunk from carrying it.

Tagging and native VLAN

Ordinary VLAN traffic is tagged on an 802.1Q trunk. Native-VLAN traffic is traditionally transmitted untagged. Both ends must agree about which VLAN is native; otherwise, an untagged frame can be classified into different VLANs on the two switches. This can create reachability surprises and a security concern.

Make the native VLAN explicit and avoid using it for ordinary user traffic where the design calls for an unused native segment. A native mismatch warning is evidence to investigate, not something to suppress without correction.

Allowed-list reasoning

Use the smallest list that supports required services, but preserve management, voice, wireless, or infrastructure VLANs deliberately. A careless replacement command can overwrite rather than add to an existing list. Review the resulting operational set after every change.

Every trunk in a multi-switch path must carry the VLAN. Verify hop by hop rather than staring only at the two endpoints.

IOS command map

On a lab interswitch link, switchport mode trunk makes the administrative intent explicit. Use switchport trunk native vlan 99 only when VLAN 99 is the approved native choice, and switchport trunk allowed vlan 10,20,30,99 to set the required allowed set. Some older switch families also require switchport trunk encapsulation dot1q; do not enter that command on platforms that support only 802.1Q and do not offer the selector.

Use show interfaces trunk to read operational trunks, native VLANs, allowed VLANs, and forwarding VLANs. Use show interfaces GigabitEthernet0/1 switchport for administrative and operational mode on one port, then compare the peer. Before using an add or replacement form of the allowed-list command, inspect the existing set so a repair does not remove another required VLAN.

Worked scenario

A trunk carries VLANs 10 and 30. Hosts in VLAN 10 work across it; VLAN 30 hosts do not. Both switches contain VLAN 30 and learn local MAC addresses. One side's allowed list omits 30. Correct the list using syntax that preserves other required VLANs, then confirm VLAN 30 is allowed, active, and forwarding on both ends.

Trunks and EtherChannel

When physical links form an EtherChannel, trunk policy belongs consistently on the logical port-channel. Member settings must be compatible. Troubleshooting a single member as if it were an independent trunk can hide the logical interface that actually controls forwarding.

Verification evidence

Check switchport administrative and operational mode, encapsulation, native VLAN, allowed VLANs, active forwarding VLANs, port-channel membership where applicable, and MAC learning on both sides. Then test traffic within the affected VLAN.

Common traps

• Assuming link-up means trunk-up.
• Confusing native with default VLAN.
• Adding a VLAN locally but omitting it from the trunk.
• Replacing an allowed list accidentally.
• Applying conflicting settings to channel members.

Readiness checklist

• I can explain which frames are tagged and untagged.
• I can diagnose native-VLAN disagreement.
• I can preserve and verify allowed VLANs.
• I follow every trunk in the path.