When working with VLAN interfaces in Linux, you'd expect to see the 802.1Q tags in your packet captures. However, many admins encounter situations where tcpdump shows untagged frames even when VLAN interfaces are properly configured. Let's examine why this happens and how to properly capture VLAN tags.

When you create a VLAN interface with:

ip link add link eth0 name eth0.20 type vlan id 20
ip link set eth0.20 up

The Linux kernel handles VLAN tagging/untagging at the networking stack level. This means:

• Packets transmitted through eth0.20 get tagged automatically
• Packets received on eth0 with VLAN 20 get untagged before reaching eth0.20

The key points about tcpdump behavior:

tcpdump -i eth0      # Shows raw packets including VLAN tags
tcpdump -i eth0.20   # Shows packets AFTER VLAN processing (tags removed)

To actually see the VLAN tags, you must capture on the physical interface (eth0), not the VLAN interface (eth0.20).

To verify VLAN tagging is working:

# Method 1: Capture on physical interface
tcpdump -i eth0 -vvv -e

# Method 2: Use VLAN filter expressions
tcpdump -i eth0 -v 'vlan'

# Method 3: Check interface counters
watch -n 1 'cat /proc/net/vlan/eth0.20'

For DHCP specifically, use this approach:

# On one terminal:
tcpdump -i eth0 -Un -w - | tcpdump -r - -e -v 'port 67 or port 68'

# On another terminal:
dhclient -d -v eth0.20

This will show you the raw packets including VLAN tags while observing the DHCP process.

To confirm the kernel is properly handling VLANs:

# Check kernel module
lsmod | grep 8021q

# Detailed interface info
ip -d link show eth0.20

# VLAN statistics
ethtool -k eth0 | grep vlan

Remember that some NICs handle VLAN offloading in hardware, which might affect what you see in captures.

---

When working with VLAN-tagged interfaces in Linux, you might encounter situations where tcpdump doesn't show VLAN tags in captured packets, even though the VLAN configuration appears correct. Here's a typical scenario:

# ip link add link eth0 name eth0.20 type vlan id 20
# ip link show eth0.20
12: eth0.20@eth0:  mtu 1500 qdisc noqueue state UP
    link/ether 9c:c7:a6:95:65:1c brd ff:ff:ff:ff:ff:ff
    vlan id 20 

Despite this configuration, running tcpdump shows untagged packets:

# tcpdump -i eth0 -XX
0x0000:  ffff ffff ffff 9cc7 a695 651c 0800 4500

The Linux networking stack handles VLAN tags differently depending on where you capture the traffic:

1. When capturing on the physical interface (eth0), you'll see the raw frames before VLAN processing
2. When capturing on the VLAN interface (eth0.20), you'll see processed frames after VLAN tags have been stripped

To properly capture VLAN-tagged traffic, you have several options:

Method 1: Capture on the physical interface with vlan filtering

tcpdump -i eth0 -e vlan and vlan 20

Method 2: Use the vlan keyword in tcpdump

tcpdump -i eth0 -v -XX vlan 20

Method 3: Use the proper interface for your capture

tcpdump -i eth0.20 -XX

If you're still not seeing tagged traffic when you should be, try these diagnostic steps:

# Check VLAN module is loaded
lsmod | grep 8021q

# Verify VLAN configuration
ip -d link show eth0.20

# Check kernel VLAN support
dmesg | grep -i vlan

# Monitor traffic counters
watch -n 1 'cat /proc/net/vlan/eth0.20'

For more detailed analysis, you can use tcpdump with raw sockets to see the actual VLAN tags:

tcpdump -i eth0 -s0 -w vlan_capture.pcap &
dhclient -d -v -1 eth0.20
killall tcpdump

Then analyze the capture in Wireshark or with:

tcpdump -r vlan_capture.pcap -XX -e

• Make sure your switch port is configured as a trunk port with the correct VLAN allowed
• Verify your network card supports VLAN tagging (especially important with some virtual NICs)
• Check for VLAN acceleration features that might bypass the normal network stack

To confirm VLAN tagging is working end-to-end:

# On the Linux host:
ping -I eth0.20 

# On a remote host in the same VLAN:
tcpdump -i  -XX vlan 20