VLAN Footguns¶
Mistakes that cause traffic isolation failures, silent connectivity loss, or security breaches.
1. Forgetting to load the 8021q kernel module¶
You create a VLAN interface with ip link add, assign an IP, and bring it up. The interface appears to exist but no tagged frames are sent or received. The kernel silently ignores the VLAN configuration because the 8021q module is not loaded.
Fix: Load the module first: modprobe 8021q. Make it persistent: echo 8021q >> /etc/modules or create a modprobe conf file.
2. Switch port in access mode when it should be trunk¶
You configure a VLAN interface on the Linux host. The switch port is in access mode for VLAN 1. Tagged frames from the host are dropped by the switch because access ports do not understand 802.1Q tags. Traffic on the default VLAN works, but other VLANs are invisible.
Fix: Configure the switch port as a trunk: switchport mode trunk. Add the required VLANs to the allowed list. Verify with show interfaces trunk.
3. VLAN not in the trunk's allowed list¶
The trunk is configured, but VLAN 200 is not in the allowed VLAN list. The switch silently drops tagged frames for VLAN 200. Other VLANs on the same trunk work fine, making the problem look host-specific.
Fix: Add the VLAN to the trunk: switchport trunk allowed vlan add 200. Check with show interfaces trunk on both sides.
4. Native VLAN mismatch between trunk endpoints¶
Switch A has native VLAN 1, Switch B has native VLAN 100. Untagged frames from A are placed into VLAN 1 on A but VLAN 100 on B. Traffic crosses VLAN boundaries unintentionally. This is also a VLAN hopping attack vector.
Fix: Set the native VLAN to the same value on both ends. Best practice: use an unused VLAN as native and tag all traffic explicitly.
CVE: Native VLAN mismatch is the basis of the "double tagging" VLAN hopping attack. An attacker sends a frame with two 802.1Q tags: the outer tag matches the native VLAN and is stripped by the first switch, the inner tag routes the frame to the target VLAN. Using an unused VLAN as native and tagging all traffic blocks this attack entirely.
5. VLAN ID not created in the switch VLAN database¶
You configure a trunk port to allow VLAN 300 and set up the Linux VLAN interface. But VLAN 300 was never created on the switch (vlan 300). Some switches silently ignore traffic for non-existent VLANs. Others show the port as up but pass no traffic.
Fix: Create the VLAN on every switch in the path: vlan 300 + name description. Verify with show vlan brief.
6. MTU problems with VLAN tags¶
The 802.1Q tag adds 4 bytes to each frame. If the path MTU is exactly 1500 and the switch does not support "baby giant" frames, tagged frames at 1504 bytes are dropped. Small packets work, large transfers stall — the same symptoms as an MTU blackhole.
Fix: Ensure all switches support at least 1504-byte frames (most modern switches do). If not, reduce the VLAN interface MTU to 1496: ip link set eth0.100 mtu 1496.
7. Using VLAN 1 for production traffic¶
VLAN 1 is the default on virtually all switches. Control plane traffic (STP BPDUs, CDP, VTP) runs on VLAN 1. Putting production traffic on VLAN 1 mixes it with management traffic and increases the attack surface. Some switches cannot fully remove VLAN 1 from trunks.
Fix: Use dedicated VLANs for production traffic. Keep VLAN 1 for switch management only, or better, assign it to an unused role.
Under the hood: VLAN 1 is special: most switches send CDP, VTP, DTP, and STP BPDUs on VLAN 1. Some switches cannot fully prune VLAN 1 from trunks even when you try. Production traffic on VLAN 1 shares bandwidth with control plane traffic and is exposed to every trunk port in your network, increasing your attack surface.
8. Capturing on the VLAN interface instead of the parent¶
You run tcpdump -i eth0.100 to debug a VLAN problem. You see normal IP traffic but no VLAN tags because the VLAN interface strips tags on receive. You cannot tell if tagged frames are actually arriving.
Fix: Capture on the physical parent interface to see raw 802.1Q tags: tcpdump -eni eth0 'vlan 100'. Use the VLAN interface only to see post-processed traffic.
Debug clue: Use
tcpdump -eni eth0 -w /tmp/vlan-debug.pcapon the parent interface, then open in Wireshark. Wireshark's "VLAN" column shows tag presence and VLAN ID. If you see untagged frames where you expect tagged ones, the switch port is stripping tags (access mode, not trunk).
9. Docker macvlan losing connectivity to the host¶
You create a Docker macvlan network on eth0.100. Containers on the macvlan can reach other hosts on VLAN 100, but cannot reach the host's own eth0.100 IP. This is a known macvlan limitation — the host and its macvlan children cannot communicate directly at L2.
Fix: Create a macvlan interface on the host itself and route through it. Or use a separate physical NIC for host-to-container communication. Accept this limitation when designing your network.
10. VLAN interfaces surviving parent interface changes¶
You replace eth0 with a bond (bond0). The old eth0.100 VLAN interface still exists, pointing at the original eth0. It appears up but passes no traffic because eth0 is now a bond member and not handling traffic independently. Two VLAN interfaces may coexist — eth0.100 and bond0.100.
Fix: When changing the parent interface, delete old VLAN interfaces first: ip link del eth0.100. Recreate on the new parent: ip link add link bond0 name bond0.100 type vlan id 100.