VLAN Trunking
VLAN trunking is responsible for more network outages than most people realise. Not because it’s complicated. Because it’s just familiar enough that people think they understand it and skip the details that actually matter.
I’ve seen engineers with years of experience get caught out by native VLAN mismatches. Spent an afternoon once with someone whose trunk was carrying the wrong VLANs because of one wrong command. Traffic was dropping. They were convinced it was a routing problem. It wasn’t. It was a four-word mistake in the allowed VLAN list.
Let’s go through it properly so that’s not you.
What VLAN Trunking Actually Is
An access port carries traffic for one VLAN. A trunk carries traffic for multiple VLANs over a single physical link. That’s the whole thing.
When traffic from VLAN 10 crosses a trunk the switch adds a tag to the Ethernet frame identifying which VLAN it belongs to. The receiving switch reads the tag, knows it’s VLAN 10, handles it accordingly. When traffic eventually reaches an access port the tag gets stripped off before the frame goes to the end device. End devices never see the tag. They don’t need to know anything about trunking.
The tagging standard is 802.1Q from the IEEE. It adds a 4-byte tag into the Ethernet frame header. Inside that tag is the VLAN ID – a 12-bit field giving you VLAN IDs from 1 to 4094. There’s also a Priority Code Point field – 3 bits used for QoS marking. Traffic can be marked higher or lower priority as it crosses the trunk.
Cisco also had an older proprietary trunking protocol called ISL – Inter-Switch Link. Instead of inserting a tag it encapsulated the entire Ethernet frame in a new ISL header. Rarely see it on modern equipment but worth knowing it exists because it shows up occasionally in older networks and documentation. 802.1Q is what you should be using.
The Native VLAN
This is the one that bites people most often.
The native VLAN is the one VLAN on a trunk that doesn’t get tagged. Traffic from it is sent untagged across the trunk link.
The reason goes back to backwards compatibility when 802.1Q was introduced. Devices that didn’t understand VLAN tags could still pass untagged traffic. Made sense in 1998. Bit less relevant now.
Default native VLAN on Cisco switches is VLAN 1. VLAN 1 is also the default VLAN for access ports, the default for management on a lot of platforms, where CDP and spanning tree BPDUs travel by default. Having everything in VLAN 1 is not a good design.
Best practice is to set native VLAN to a dedicated VLAN carrying no user or management traffic. Something nobody actually uses.
interface GigabitEthernet0/1
switchport trunk native vlan 999
Critical bit: native VLAN must match on both ends of the trunk. One end on VLAN 1, other end on VLAN 999 – you’ll get a CDP native VLAN mismatch warning and traffic will do odd things. That’s one of the most common trunking problems out there.
Verify it:
show interfaces GigabitEthernet0/1 trunk
Native VLAN shows in its own column. Check both ends match. Every time.
DTP – Dynamic Trunking Protocol
This is the one that causes the most security concerns and the one most people have never properly thought about.
By default Cisco switch ports run DTP – Dynamic Trunking Protocol. It lets a port automatically negotiate whether it should be an access port or a trunk with whatever is on the other end.
| Local Mode | Remote Mode | Result |
|---|---|---|
| Access | Access | Access port |
| Access | Dynamic Auto | Access port |
| Dynamic Auto | Dynamic Auto | Access port |
| Dynamic Auto | Dynamic Desirable | Trunk |
| Dynamic Desirable | Dynamic Desirable | Trunk |
| Trunk | Dynamic Auto | Trunk |
| Trunk | Trunk | Trunk |
The problem is DTP sends negotiation traffic out of your switch ports. On ports connected to end devices that should never be trunks, that negotiation is unnecessary and leaks information about your VLAN configuration. It’s also a potential attack vector. A crafted DTP frame could try to negotiate a trunk with a rogue device and gain access to VLANs it shouldn’t reach.
Fix is simple. Explicitly configure every port and disable DTP negotiation.
Trunk ports:
interface GigabitEthernet0/1
switchport mode trunk
switchport nonegotiate
Access ports:
interface GigabitEthernet0/2
switchport mode access
switchport access vlan 10
switchport nonegotiate
Explicit mode. DTP disabled. No ambiguity, no negotiation traffic, no possibility of unexpected trunk formation.
Allowed VLANs on a VLAN Trunk
By default a trunk carries all VLANs that exist on the switch. If you’ve got VLANs 10, 20, 30, 40, and 99 on the switch, the trunk carries all of them.
Usually not what you want. Traffic for VLANs not needed on a specific trunk segment should be pruned. No point carrying VLAN 40 across a trunk if nothing on the other side needs it.
Configure the allowed VLAN list:
interface GigabitEthernet0/1
switchport trunk allowed vlan 10,20,30,99
Now that trunk only carries those four. Traffic from anything not in the list gets dropped at ingress.
This is where the command that wrecked an afternoon comes in. The syntax matters enormously.
switchport trunk allowed vlan 10,20,30
Sets the allowed list to exactly those VLANs. Replaces whatever was there before.
switchport trunk allowed vlan add 40
Adds VLAN 40 to the existing list.
switchport trunk allowed vlan remove 30
Removes VLAN 30 from the existing list.
Run the first form when you meant the second and you’ve just silently removed VLANs from a trunk. Traffic stops. Users ring in. You spend time troubleshooting what is actually a four-word mistake.
Always use add and remove when modifying an existing allowed list. Replace only when you’re setting it fresh.
VTP – VLAN Trunking Protocol
VTP is Cisco proprietary. Allows VLAN configuration to sync across multiple switches automatically. Define VLANs on a server, they distribute to clients throughout the domain.
Sounds useful. It has a deserved reputation for causing catastrophic outages.
VTP Server – creates, modifies, deletes VLANs. Advertises the VLAN database. Changes saved to NVRAM.
VTP Client – cannot create or modify VLANs. Receives VLAN info from servers. VLAN database not saved to NVRAM.
VTP Transparent – doesn’t participate in synchronisation. Has its own local VLAN database. Forwards VTP advertisements but doesn’t apply them.
The mechanism uses a revision number. Every time the VLAN database changes, revision number increments. Any switch that receives a VTP advertisement with a higher revision number than its own replaces its VLAN database with what’s in the advertisement.
That’s the VTP wipe. Switch taken out of service, VLANs changed on it in the lab, connected back to production. Higher revision number than the production switches. Every switch in the domain replaces its VLAN database with the test database. VLANs disappear from the entire network. Traffic stops everywhere.
I’ve seen it happen. Not pretty.
A lot of organisations run VTP transparent on everything now – effectively disabling VTP synchronisation while still passing advertisements through. Or they use VTP version 3 which has better protection against this scenario.
If you’re in a network running VTP v1 or v2 server/client mode, always reset revision number before connecting any switch to production:
vtp mode transparent
vtp mode server
Changing modes resets revision to zero. Then configure domain, mode, and password correctly before connecting.
Troubleshooting VLAN Trunking Problems
First command every single time:
show interfaces trunk
Output has four sections. Read all of them. Every one.
Port, Mode, Encapsulation, Status, Native vlan – Is the port actually a trunk? What’s the native VLAN? Status showing not-trunking on a port that should be a trunk means DTP negotiation failed or is disabled on one end.
Port, VLANs allowed on trunk – What’s in the allowed list? VLAN missing here means traffic is being dropped.
Port, VLANs allowed and active in management domain – VLANs that are in the allowed list AND exist on this switch. VLAN in the allowed list but not here means the VLAN hasn’t been created on this switch.
Port, VLANs in spanning tree forwarding state and not pruned – VLANs actually forwarding traffic. VLAN in the third section but not the fourth? Spanning tree might be blocking it or VTP pruning is active.
Work through those four sections in order. Trunk problems almost always fall into one of three categories. Native VLAN mismatch. Wrong allowed list. VLAN not created on the switch. Check those three things and you’ll find it.
A Clean VLAN Trunk Configuration
Here’s what a properly configured trunk between SW1-ACCESS and SW1-DIST should look like:
interface GigabitEthernet0/1
description UPLINK-TO-SW1-DIST
switchport trunk encapsulation dot1q
switchport mode trunk
switchport nonegotiate
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,30,99
spanning-tree portfast trunk
Explicit trunk mode. DTP disabled. Native VLAN on a dedicated unused VLAN. Allowed list restricted to only what’s needed. Documented with a description. Clean and predictable.
The switchport trunk encapsulation dot1q line is required on some older switches that support both 802.1Q and ISL. On most modern platforms it’s automatic but including it explicitly does no harm and makes the config unambiguous.
External Link: IEEE 802.1Q standard overview – IEEE resource for the 802.1Q VLAN trunking standard