How to Configure an 802.1Q Trunk Between Cisco Switches (Step by Step)
A trunk is one physical link carrying traffic for multiple VLANs, tagging each frame with 802.1Q so the switch on the other end knows which VLAN it belongs to. Get the trunk wrong — mismatched native VLAN, a missing entry in the allowed list, one side stuck in access mode — and traffic for that VLAN either doesn't cross the link or crosses untagged, which is a much harder problem to spot than a routing misconfig. Here's the full setup on Cisco IOS: set the mode, restrict the VLANs, match the native VLAN, and confirm it with a single show command.
Part of the VLANs, Trunking & Inter-VLAN Routing learning hub
Step 1 — Set the trunk mode (and encapsulation, if the platform asks)
On the link port on BOTH switches, hard-set trunking instead of letting Dynamic Trunk Protocol (DTP) negotiate it. DTP will usually get you to the same place, but a hard-set trunk is predictable, and predictable is what you want on a link that's about to carry several VLANs.
Older platforms that also support ISL make you pick the tagging method first with switchport trunk encapsulation dot1q. Newer switches — and most IOL/free-tier images used for practice labs — are dot1q-only and skip straight to switchport mode trunk; if the command isn't there, that's why. If your platform does require the encapsulation line, set it on both switches: leaving one side on the default 'negotiate' encapsulation and then issuing switchport mode trunk on it fails outright with 'Command rejected: An interface whose trunk encapsulation is "Auto" can not be configured to "trunk" mode.'
SW1(config)# interface gigabitEthernet0/1
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunkStep 2 — Restrict which VLANs are allowed to cross
By default a trunk allows all VLANs (1-4094) across it. That's rarely what you want in production — an unused VLAN leaking across the link is unnecessary broadcast traffic and an unnecessary attack surface. Pin the allowed list to exactly the VLANs this trunk needs to carry.
Do this on both ends with the same VLAN list. If the two sides don't agree, a VLAN allowed on one end but not the other simply won't pass traffic — no error, no log, it just silently doesn't work.
SW1(config-if)# switchport trunk allowed vlan 10,20,99Step 3 — Match the native VLAN and verify
The native VLAN is the one VLAN whose traffic crosses the trunk untagged. It has to be configured identically on both switches — if SW1 thinks the native VLAN is 99 and SW2 still thinks it's the default VLAN 1, untagged frames land in the wrong VLAN on the far end. CDP will flag the mismatch, but don't rely on catching that message; set it deliberately on both sides.
Repeat steps 1-3 on the peer switch's interface — including the encapsulation line if your platform needs it — then confirm the whole trunk from both ends with show interfaces trunk. It reports the mode, the encapsulation, the configured native VLAN, and — critically — the allowed and active VLAN lists side by side, so you can catch a mismatch before it costs you a lab.
SW1(config-if)# switchport trunk native vlan 99
SW1(config-if)# end
SW2(config)# interface gigabitEthernet0/1
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk allowed vlan 10,20,99
SW2(config-if)# switchport trunk native vlan 99
SW2(config-if)# end
SW1# show interfaces trunk
SW2# show interfaces trunkCommon problems (and the fix)
Native VLAN mismatch: the two ends configure different native VLANs. CDP will warn you ("native VLAN mismatch discovered"), and even without the warning you'll see it in show interfaces trunk — check the Native vlan column on both switches and make them match.
A VLAN missing from the allowed list: traffic for that VLAN just doesn't cross the trunk, with no error anywhere. Compare the allowed and active VLAN lists in show interfaces trunk on both ends; if a VLAN is allowed on one side and absent on the other, that's your leak.
One side access, one side trunk: if the peer port is still switchport mode access (or dynamic and negotiated the wrong way), the trunk side keeps sending 802.1Q-tagged frames for every non-native VLAN. The access-mode peer can't process those tags and drops that traffic, so only the native VLAN's untagged frames get through, landing in whatever VLAN the access port belongs to — every other VLAN loses connectivity across the link, not just a single merged VLAN. Hard-setting switchport mode trunk on both ends — rather than trusting DTP to auto-negotiate — is what prevents this in the first place.
Running through this on a real IOS trunk (not just reading about it) is what makes native-VLAN and allowed-list mistakes obvious instead of theoretical — worth doing once against a graded config so you know your show interfaces trunk output actually matches what a correct trunk looks like.
Frequently asked questions
What's the difference between 'switchport mode trunk' and the dynamic auto/desirable modes?
'switchport mode trunk' forces the port to trunk unconditionally, while the dynamic modes rely on DTP to negotiate: dynamic desirable actively asks the neighbor to trunk, and dynamic auto only trunks if the neighbor asks first. If both ends are left at dynamic auto, neither one initiates and the link quietly stays an access port. For a switch-to-switch link, hard-set both ends to trunk and add 'switchport nonegotiate' so no DTP frames are exchanged.
What actually happens if the native VLAN doesn't match on both ends of the trunk?
Because native-VLAN traffic crosses the link untagged, a mismatch merges two different VLANs at Layer 2, so frames sent untagged on one side arrive in the wrong VLAN on the other. CDP logs a 'native VLAN mismatch' message and per-VLAN spanning tree can go inconsistent on that link. It is also a VLAN-hopping vector, which is why the native VLAN should be identical on both ends and set to an unused VLAN rather than VLAN 1.
How do I add a VLAN to an existing trunk without knocking the others off?
Use 'switchport trunk allowed vlan add <id>' — the add keyword appends to the current list, whereas 'switchport trunk allowed vlan <id>' replaces the entire allowed list with just that one VLAN. Forgetting add is a common outage cause because it silently drops every other VLAN from the trunk. Confirm the result in the 'vlans allowed on trunk' column of 'show interfaces trunk' before you move on.
Do I still need to set the encapsulation to dot1q, or can I use ISL?
802.1Q (dot1q) is the only trunking encapsulation on modern Cisco switches; ISL is Cisco-proprietary, legacy, and unsupported on current platforms. Some older switches that supported both will not accept 'switchport mode trunk' until you first pin 'switchport trunk encapsulation dot1q', while switches that only do dot1q hide the encapsulation command entirely. That is why the guide treats encapsulation as a step you do only if the platform asks.
My trunk shows up but I still can't pass traffic for a VLAN — why?
A trunk only carries a VLAN if that VLAN exists in the VLAN database, is active, and sits in the port's allowed list on both switches. A VLAN that was never created, was removed from the allowed list, or was pruned is dropped even though the trunk itself is up and forwarding. Check the 'vlans allowed and active' column of 'show interfaces trunk' and confirm the VLAN with 'show vlan brief' on each end.
Practice this on graded Cisco labs
Reading is step one — build VLANs, Trunking & Inter-VLAN Routing on real Cisco IOS and grade your own config, or try a free sample lab first.