802.1Q VLAN tagging: the tag, trunk ports, native VLAN and QinQ

802.1Q VLAN tagging is the IEEE method for carrying many VLANs over one Ethernet link: the sending port inserts a 4-byte tag after the source MAC address, and the 12-bit VLAN ID inside it tells the receiving port which VLAN the frame belongs to. Everything else on this page follows from two questions a switch asks of every frame: which VLAN does this belong to on the way in, and should it leave tagged or untagged on the way out.

The basics of what a VLAN is, and why you would build one, are on the VLANs and broadcast domains guide. This page goes one layer down: the bits in the tag, the ingress and egress rules that decide tagging, how trunk ports behave on real switches, native VLAN handling and stacked QinQ tags. The current text is IEEE 802.1Q-2022, Bridges and Bridged Networks, which has absorbed amendments that were once separate documents, including provider bridging (802.1ad) and Multiple Spanning Tree (802.1s).

01 /What is inside an 802.1Q tag?

The tag is 32 bits long and sits between the source MAC address and the original EtherType. Its first 16 bits are the Tag Protocol Identifier (TPID). A receiver reads the two bytes where it expects an EtherType, finds 0x8100, and knows a tag follows instead. The second 16 bits are the Tag Control Information (TCI), split three ways.

Two VID values trip people up. VID 0 means the frame is priority-tagged: it carries a PCP value but no VLAN, and the receiving port treats it as if it were untagged for VLAN purposes. Some IP phones and older NICs send these. VID 4095 is reserved and never appears on the wire. That leaves 4094 usable VLANs per tag.

The tag adds 4 bytes, so the largest standard Ethernet frame grows from 1518 to 1522 bytes. The IP payload limit stays at 1500 bytes. Any device in the path that enforces the old 1518-byte limit drops full-size tagged frames while small ones pass, which produces the classic symptom of ping working and file transfers stalling.

02 /How does a switch decide which VLAN a frame belongs to?

802.1Q defines the decision as a set of per-port parameters rather than as a port "mode". Vendor CLIs wrap these in friendlier words (access, trunk, tagged, untagged), but the model underneath is the same on every compliant switch.

• PVID (port VLAN ID): the VLAN assigned to any frame that arrives untagged or priority-tagged. On an access port it is the access VLAN; on a trunk it is the native VLAN.
• Acceptable frame types: admit all frames, admit only VLAN-tagged frames, or admit only untagged and priority-tagged frames. A port set to admit only tagged frames drops anything untagged instead of placing it in the PVID.
• Ingress filtering: when enabled, a tagged frame whose VID is not in the port's member set is discarded on arrival rather than forwarded.
• Member set and untagged set: for each VLAN, the ports that may send it, and the subset that send it with the tag removed.

On the way out, the switch looks up the frame's VLAN in the egress port's sets. If the port is not a member, the frame does not leave. If the port is in the untagged set for that VLAN, the tag is stripped; otherwise the tag goes out with the original VID. An access port is a port that is an untagged member of one VLAN; a trunk is a port that is a tagged member of several, plus at most one untagged VLAN.

03 /What do the priority bits mean?

The 3-bit PCP field is what people still call 802.1p. It is only a label: a switch acts on it only if its queues are configured to trust it. The standard recommends a mapping from traffic type to PCP value, and most vendors follow it. One detail surprises people: PCP 1 (background) is lower priority than PCP 0 (best effort).

An untagged frame has no PCP field at all, which is why voice VLAN designs tag phone traffic even on access ports: the tag is the only place a Layer 2 priority can live.

04 /How do trunk ports behave on real switches?

Cisco IOS XE is the syntax most engineers meet first, and its defaults are worth knowing because they are permissive. According to the Catalyst 9300 VLAN trunk configuration guide (IOS XE 17.15.x), a Layer 2 interface defaults to switchport mode dynamic auto, which becomes a trunk if the neighbour asks for one through the Dynamic Trunking Protocol (DTP). A trunk carries all VLANs, 1 to 4094, unless you prune the allowed list, and its native VLAN is VLAN 1.

A trunk built deliberately looks like this, on Cisco IOS:

interface TenGigabitEthernet1/0/48
 description uplink to dist-1
 switchport mode trunk
 switchport nonegotiate
 switchport trunk native vlan 999
 switchport trunk allowed vlan 10,20,30
!
interface GigabitEthernet1/0/5
 description desk port
 switchport mode access
 switchport access vlan 20

switchport mode trunk fixes the role, switchport nonegotiate stops DTP frames, the native VLAN moves to an unused ID, and the allowed list carries only what the far side needs. Older Catalyst platforms that also supported Cisco's pre-standard ISL encapsulation need switchport trunk encapsulation dot1q before switchport mode trunk is accepted; current platforms speak only 802.1Q.

Pruning matters for more than tidiness. Every VLAN allowed on a trunk is another broadcast domain flooded across it and, in per-VLAN designs, another spanning tree instance the switch has to run. Removing VLAN 1 from the allowed list is allowed; the Cisco guide notes that control protocols such as CDP, LACP, DTP and VTP keep using VLAN 1 on the trunk anyway.

05 /How should the native VLAN be handled?

The native VLAN is the trunk's PVID: untagged frames arriving on the trunk land in it, and frames in it leave untagged. That makes it the one place on a trunk where the tag cannot tell the two ends what VLAN a frame is in. If one end treats untagged frames as VLAN 1 and the other as VLAN 99, the two VLANs merge across the link. The Cisco guide warns that a native VLAN mismatch can also cause spanning tree loops, because each side builds its tree for a different VLAN on the same wire. On Cisco switches running CDP, a mismatch also shows up as a native VLAN mismatch log message, which is often the first clue.

There are three sane policies, in rising order of strictness:

1. Match it on both ends. The minimum. Verify from the show output on both switches after every change.
2. Make it an unused VLAN. Pick an ID with no member ports and no subnet, for example 999, and set it as native on every trunk. Untagged frames then land somewhere harmless. This also removes the path for double-tag VLAN hopping, where an attacker on the native VLAN sends a frame with two tags so the first switch strips one and forwards the other.
3. Tag the native VLAN too. Many switches can tag every VLAN on a trunk, native included, and drop untagged frames (on Catalyst switches that support it, the global command is vlan dot1q tag native; in 802.1Q terms it is "admit only VLAN-tagged frames"). Do this on both ends at once or the link stops passing the native VLAN.

Hypervisor uplinks, firewalls and wireless controllers often expect one untagged management VLAN on an otherwise tagged link. Write down which VLAN that is before you tighten the policy.

06 /What is QinQ and when do you need a second tag?

Provider bridging, still widely called QinQ and originally IEEE 802.1ad, puts a second tag outside the first. The outer service tag (S-tag) uses TPID 0x88A8 and belongs to the carrier; the inner customer tag (C-tag) keeps 0x8100 and the customer's own VID. A carrier can then carry all 4094 of one customer's VLANs inside a single service VLAN without coordinating numbering, and two customers can both use VLAN 10 without colliding.

The cost is another 4 bytes. A double-tagged full-size frame is 1526 bytes, so every link in the provider path needs a larger MTU, commonly set to jumbo sizes on provider gear. Some pre-standard implementations used other outer TPIDs such as 0x9100, so when two vendors' QinQ will not interoperate, compare the outer TPID first. Inside an enterprise, QinQ mostly appears on metro Ethernet handoffs and in data centre interconnects; if you only have one administrative domain, plain 802.1Q with a sensible VLAN plan is simpler.

07 /Do servers and hypervisors tag frames too?

Yes, and it is common. A Linux host can terminate a trunk directly. The ip-link manual page documents the VLAN link type, including a protocol option that selects 802.1Q or 802.1ad tagging:

ip link add link eth0 name eth0.20 type vlan id 20
ip link add link eth0 name eth0.30 type vlan protocol 802.1Q id 30
ip addr add 192.0.2.10/24 dev eth0.20
ip link set eth0.20 up
ip -d link show eth0.20

The same manual page notes a capture trap: with header reordering on (the default), the VLAN header is removed before the frame reaches the VLAN device, and many NICs insert and strip tags in hardware. A capture on the wrong interface can show untagged frames even though the wire carries tags. Capture on the parent interface, or on a mirror port fed by the switch, before concluding the tag is missing.

08 /Common 802.1Q mistakes

• Leaving DTP negotiation on access ports. A port in dynamic mode can become a trunk for any device that asks. Set access ports to switchport mode access explicitly.
• Allowing every VLAN on every trunk. Flooding and spanning tree work scale with the count. Prune to what the far side needs.
• Native VLAN mismatch. Two VLANs silently merge. Set it identically, ideally to an unused ID.
• Forgetting the extra 4 or 8 bytes. Tagged and double-tagged frames need 1522 and 1526 bytes of frame size through every device in the path, including firewalls and media converters.
• Trusting PCP from hosts. A PC can mark its own frames priority 5. Re-mark or ignore host markings at the access edge unless the device is a known phone.
• Assuming "trunk" means the same thing everywhere. On Foundry IronWare a trunk was a bundle of ports, which the rest of the industry calls a link aggregation group. The port carrying several VLANs was simply a tagged port. A bundle hashes flows across its members in much the same way that equal-cost multipath routing hashes them across routed next hops.

09 /How to check that tagging works

1. On both ends of every trunk, read the operational state: show interfaces trunk lists mode, encapsulation, native VLAN and the VLANs allowed and active on each trunk; show interfaces GigabitEthernet1/0/5 switchport shows the administrative and operational mode of one port.
2. Compare the native VLAN and the allowed lists from both ends side by side, not from the change ticket.
3. Confirm the frames on the wire. Mirror the trunk to a capture host (see the SPAN and port mirroring guide) and run tcpdump -nn -e -i eth1 vlan; with -e, tcpdump prints the link-level header including the VLAN ID and priority of each tagged frame.
4. Test with full-size frames. From a host in the VLAN, send a ping with the don't-fragment bit set and a 1472-byte payload (1500 bytes of IP) to a host across the trunk. If small pings pass and this one fails, something in the path is dropping 1522-byte frames.
5. Pull a host onto the native VLAN port, or send untagged traffic onto the trunk, and confirm it lands where your policy says it should, or nowhere if the native VLAN is unused or tagged.

10 /How Foundry IronWare expressed 802.1Q

IronWare on FastIron switches and BigIron chassis never had an access or trunk mode. Ports were added to a VLAN as untagged or tagged members, which maps directly onto 802.1Q's untagged set and member set. A port could be an untagged member of one VLAN and a tagged member of many. The native VLAN of other vendors was expressed with dual-mode: a tagged port that also sends and accepts one VLAN untagged, commonly used for IP phones with a PC behind them. The worked configuration is on the VLANs page; the wider set of Layer 2 topics, from bundling to port authentication, is indexed in the switching section.