802.1Q Tagging and the Four-Byte Insertion

A VLAN tag is four bytes inserted into an Ethernet header, and the insertion is the whole mechanism: the payload and its protocol are unchanged, and a bridge that does not understand the tag sees a frame it will forward without knowing that it belongs to a partition. That invisibility is what made tagging deployable on existing hardware, and it is also why membership is easy to misread, because a frame’s VLAN is not visible in the addresses it carries.

The tag’s position and its fields

The tag goes between the source address and the type field, which pushes the original type field four bytes later:

Field	Bytes	Contents
Destination address	6	Unchanged
Source address	6	Unchanged
Tag protocol identifier	2	0x8100
Tag control information	2	PCP, DEI, VID
Original type	2	The EtherType the frame would have had
Payload	46 to 1500	Unchanged
FCS	4	Recomputed over the new frame

The tag protocol identifier is an EtherType, 0x8100, which is why an untagged receiver does not simply break: it reads 0x8100 as a protocol type it does not recognise and drops the frame, while a bridge that does not implement tagging forwards it on the destination address alone, tag and all. The original EtherType follows the tag, so the encapsulated protocol is still identifiable after one four-byte skip.

The tag control information holds three fields. The VLAN identifier is twelve bits, giving 4096 values, of which 0 and 4095 are reserved, leaving 4094 usable VLANs. The priority code point is three bits, giving eight priority levels that map to traffic classes in the egress queues. The drop eligible indicator is one bit, used by provider-bridged networks to mark frames that may be dropped first under congestion; in a plain enterprise deployment it may be ignored.

The priority field is the reason tagging is used for more than partitioning. Eight levels are enough to separate latency-sensitive traffic from bulk traffic on a congested egress port, and the mapping from PCP to queue is a per-port configuration rather than a standard requirement. The relationship between the link-layer priority and the IP-layer differentiated services field is not fixed: the two are separate markings, and a bridge may be configured to derive one from the other or to ignore one entirely.

Untagged, priority-tagged, and the special identifier

Three cases look similar and behave differently:

• Untagged: no tag present. The frame’s VLAN membership, if any, comes from the port configuration.
• Priority-tagged: a tag with VID 0. The frame carries a priority but no VLAN membership. It is valid and is used to mark traffic on a link where the VLAN is implied by the port.
• Tagged with VID 1 to 4094: the frame carries explicit membership.

VID 0 is the priority tag, and a port configured with a native VLAN may accept such frames and treat them as belonging to that VLAN. VID 4095 is reserved and must not be used or forwarded. The distinction between priority-tagged and untagged matters because a port’s ingress rule can treat them differently: an untagged frame is assigned the port’s default VLAN, while a priority-tagged frame may be accepted with its priority preserved and the same default membership, or rejected, depending on configuration.

A port’s configuration is described by two independent decisions: whether it accepts tagged frames, and whether it accepts untagged frames. A port that accepts both and assigns untagged frames to a VLAN is the usual access port. A port that accepts only tagged frames and carries several VLANs is a trunk. A port that accepts only untagged frames is an access port with tagging disabled, which is a configuration that silently drops a tagged frame instead of misrouting it, and that difference is worth choosing deliberately.

Ingress and egress rules

Ingress processing for a tagged frame is a membership check. The bridge looks up the VID on the ingress port; if the VLAN is not in the port’s allowed set, the frame is dropped. If it is allowed, the frame enters that VLAN’s forwarding table, and the destination lookup is done within the VLAN rather than across all addresses.

Egress processing is where the tag is added or removed. A port that is a member of the frame’s VLAN as tagged transmits the frame with the tag. A port that is a member as untagged strips the tag before transmitting, and must recompute the frame check sequence because the bytes have changed. A port that is not a member does not transmit at all.

The strip-and-recompute on egress is not optional and it is not free. Removing four bytes changes the frame length, and the checksum covers the frame as transmitted. A switch that forwards a frame to an untagged port without recomputing will produce a frame that every receiver discards as corrupt. A software implementation that passes a buffer along and only adjusts the length will produce such a frame.

Because untagged egress strips the tag, the membership is invisible on the wire, which is the intended behaviour for an access port facing a host that knows nothing about VLANs. It also means that two hosts on different VLANs, both on access ports, can share a physical switch with no indication in the frames they send that a partition exists.

Learning is per VLAN. A bridge maintains a separate forwarding table per VLAN, or a single table keyed by VID and address, so the same MAC address on two VLANs is two independent entries and traffic does not cross between them. This is the isolation property, and it holds even when the addresses are identical.

Trunks, native VLANs, and the untagged frame on a trunk

A trunk carries several VLANs between two switches. Frames for each VLAN are tagged, with one exception: the native VLAN, whose frames are transmitted untagged. The native VLAN exists so that a trunk can interoperate with a device that does not tag, and it is the source of a well-known class of misconfiguration.

If the two ends of a trunk disagree about which VLAN is native, frames from one VLAN arrive untagged at the other end and are assigned to the other end’s native VLAN. The result is traffic crossing between VLANs that were meant to be isolated, with no error reported anywhere: both switches are behaving as configured, and the frames are well formed. The defence is to set the native VLAN to an unused identifier on both ends, or to configure the trunk to tag every VLAN including the native one, which some implementations support as an explicit option.

Another edge case is the maximum frame size. A tag adds four bytes, so a 1500-byte payload on a trunk produces a 1522-byte frame on the wire, counted from destination address through the checksum. An interface configured with a 1500-byte MTU and no allowance for the tag will drop those frames as oversized, and the symptom is that large packets fail across a trunk while small ones succeed. The interaction between tagging and frame size is covered in link MTU and jumbo frames.

Stacked tags

Provider networks need two levels: one tag identifying the customer, one identifying the service instance inside the provider’s own topology. The 802.1ad amendment defines a service tag with EtherType 0x88a8 that precedes the customer tag, giving a 8-byte tag stack. A frame with both is 1526 bytes at maximum payload, and a bridge must be configured to accept the outer tag as a tag rather than as a payload type.

A stack deeper than two is possible in some implementations and is not generally standardised. Each additional tag costs four bytes and another lookup, and the practical limit is set by the hardware’s parser depth rather than by the specification. A switch that supports one tag will treat a double-tagged frame’s inner tag as payload, which means the frame is forwarded as untagged traffic in the outer VLAN and the inner partition is lost.

What tagging does not provide

A VLAN is a partition of a broadcast domain, not a security boundary. A frame’s tag is set by the switch that receives it, based on port configuration, but a host that can send tagged frames can claim any VLAN that its port allows. If the port is configured to accept a wide range, the host can join VLANs it was not intended to reach. This is VLAN hopping, and the mitigation is to restrict the allowed VLAN list on ports facing hosts, not to rely on the tag’s presence as evidence of authorization.

Tagging also has no notion of a path. A VLAN identifier is local to the bridged domain and is not preserved across a router; two sites using VLAN 10 are unrelated unless a mechanism outside the tag connects them. The mechanisms that do preserve identity across a provider are overlays, covered in the network virtualization cluster rather than here.

Within a single domain, the tag interacts with the tree computation: a spanning tree instance can be shared by all VLANs or maintained per VLAN, and the choice determines whether a blocked port blocks one VLAN or all of them. That trade-off, and the port states it produces, is described in spanning tree port states. The table that per-VLAN learning populates is described in MAC learning and bridge forwarding.