IEEE 802.1Q — the tagging model

802.1Q is the standard that adds a VLAN tag to an Ethernet frame, allowing multiple virtual LANs to share a single physical link. The tag is four bytes inserted between the source MAC address and the EtherType field. This lesson covers the frame format, the role of each field, and how VyOS implements the model.

The 802.1Q frame format

flowchart LR
  A[Preamble 8B] --> B[DA 6B] --> C[SA 6B] --> D[802.1Q Tag 4B] --> E[EtherType 2B] --> F[Payload] --> G[FCS 4B]

The 802.1Q tag is:

Access, trunk, and hybrid ports

flowchart LR
  subgraph Access[Access port]
    A1[Untagged frame]
  end
  subgraph Trunk[Trunk port]
    T1[Tagged frame<br/>VID 10]
    T2[Tagged frame<br/>VID 20]
    T3[Tagged frame<br/>VID 30]
  end
  subgraph Hybrid[Hybrid port]
    H1[Untagged on native VLAN]
    H2[Tagged for others]
  end

• Access port — carries frames for a single VLAN, untagged. Used for end devices (workstations, servers).
• Trunk port — carries frames for multiple VLANs, all tagged. Used for switch-to-switch and switch-to-router links.
• Hybrid port — carries both tagged and untagged frames; the untagged frames belong to the native VLAN.

Native VLAN

The native VLAN is the VLAN for untagged frames on a trunk or hybrid port. By convention, the native VLAN is VLAN 1, but operators should change it to a free VLAN (often VLAN 999) to mitigate VLAN-hopping attacks.

[edit]
vyos@vyos# set interfaces ethernet eth0 native-vlan '999'
[edit]
vyos@vyos# commit
[edit]
vyos@vyos# save

QinQ (802.1ad)

QinQ is double-tagging: a service provider wraps a customer 802.1Q tag inside a service-provider 802.1Q tag. The outer tag uses TPID 0x88A8 (or 0x8100 for older implementations); the inner tag is the customer’s.

[Outer 802.1Q tag: SP VLAN 100]
[Inner 802.1Q tag: Customer VLAN 20]
[Ethernet payload]

VyOS supports QinQ via stacked VLAN IDs:

set interfaces ethernet eth0 vif 100 vif 20 address '192.0.2.1/24'

The first-level VLAN is 100 (the SP tag); the second-level is 20 (the customer tag).

Reading a tagged frame in tcpdump

vyos@vyos:~$ tcpdump -i eth0 -e -n
14:23:01.421 aa:bb:cc:dd:ee:ff > 11:22:33:44:55:66, ethertype 802.1Q (0x8100), vlan 10, ethertype IPv4, 192.0.2.10 > 192.0.2.1: ICMP echo request

-e shows the link-layer header. The output shows the VLAN tag (vlan 10) and the inner EtherType (IPv4 in this case).

How the result is validated

show interface ethernet eth0 vif 10
ip link show eth0.10
ip -d link show eth0.10
tcpdump -i eth0 -e -n vlan 10

The first shows the VyOS view; the second shows the kernel view; the third shows detailed kernel state including VLAN ID; the fourth captures only VLAN 10 frames.

How it fails

The production failure modes the engineer must recognise:

• Trunk on a single-VLAN segment. A trunk port sending tagged frames to an access device that expects untagged. The device drops the frames.
• Native VLAN mismatch. One end has native VLAN 1; the other has native VLAN 999. Untagged frames are placed in different VLANs at each end; routing breaks.
• VLAN ID out of range. A vif 5000 is rejected by the schema. The valid range is 1-4094.
• VLAN hopping. An attacker double-tags a frame to reach a protected VLAN. Mitigation: change native VLAN from 1, disable unused VLANs, use private VLANs where appropriate.
• MTU + VLAN tag. A frame with a VLAN tag is 4 bytes larger than the untagged frame. Path MTU is reduced by 4 bytes.

Rollback

The recovery from a bad VLAN configuration:

• Wrong VLAN: delete interfaces ethernet eth0 vif <wrong>; commit; save.
• Native VLAN mismatch: reconfigure both ends to the same native VLAN.
• QinQ misconfiguration: delete the stacked VLANs and rebuild.

Production discipline

Cross-course references

The Proxmox course’s XXIX-Proxmox-Networking covers the host-side VLAN configuration. The OPNsense course’s XIV-OPNsense-VLAN covers the equivalent configuration on the firewall side. The Linux course’s XIX-Linux-NetFoundations covers the kernel’s VLAN model.

Quiz