Someone wanted to learn this too, so Grasp built them a personal learning path.

Interpreting VLAN Tags, Trunks, and Native VLANs

Welcome back. You have already traced how a switch learns MAC addresses and keeps broadcast traffic scoped to a VLAN, then used ARP to resolve a local next hop. The missing piece is how switches preserve that VLAN context when traffic must cross a shared inter-switch link.

This lesson explains how to recognize an 802.1Q-tagged Ethernet frame, decode its VLAN fields in Wireshark, and interpret what an absent tag means on a trunk. By the end, you should be able to distinguish ordinary access-port traffic from tagged trunk traffic, and identify the configuration risk created by a native-VLAN mismatch.

VLAN membership is local; trunks carry the context

A VLAN creates a separate Layer 2 forwarding and broadcast domain on the same physical switching infrastructure. The same physical switch may contain VLAN 20 for users, VLAN 30 for servers, and VLAN 99 for management, but the switch maintains each VLAN's MAC-address learning and flooding behavior separately.

A device attached to a conventional access port normally sends and receives untagged Ethernet frames. The switch associates that ingress port with one VLAN, so the frame obtains VLAN context when it enters the switch. The endpoint does not need to encode “VLAN 20” in its own Ethernet frame.

The problem appears when two switches must carry traffic for several VLANs over one physical link. A receiving switch needs to know whether a frame arriving over that link belongs to VLAN 20, VLAN 30, or another allowed VLAN. An 802.1Q trunk solves this by inserting VLAN information into the Ethernet header for tagged traffic.

IEEE 802 1Q: Tagging and Trunking 101

Watch the selected portions of IEEE 802.1Q: Tagging and Trunking 101 from Sunny Classroom for a concise visual account of why trunks exist and how a tag is inserted and later removed.

First watch the trunk purpose to connect per-switch VLAN membership to the need for a shared inter-switch link. Then watch tag insertion, focusing on the switch adding VLAN context as a frame leaves a trunk port. Finish with tag removal, which shows why an access-connected endpoint normally never sees the tag.

A useful mental model is that the switch performs four distinct actions:

It classifies an arriving frame into a VLAN, based on the ingress port and any tag present.
It learns the source MAC address within that VLAN.
It makes its forwarding or flooding decision within that same VLAN.
It formats the frame for the egress port: untagged for a normal access port, usually tagged for a trunk.

The VLAN tag is therefore not an end-to-end property of the IP packet. It is Ethernet-link context that can be added, removed, or changed at each switched boundary.

Anatomy of the 802.1Q tag

An 802.1Q tag is four bytes inserted after the source MAC address and before the original EtherType or Length field. In an ordinary IPv4 Ethernet II frame, the two bytes after the source MAC are usually 0x0800, identifying IPv4. In a tagged frame, those bytes first become 0x8100, which signals that an 802.1Q tag follows. The original EtherType then appears after the four-byte tag.

An Ethernet II frame showing the 4-byte 802.1Q tag placed between the source MAC address and the original Type/Length field; the tag contains the TPID, priority, drop-eligibility, and VLAN-ID fields.

The four tag bytes consist of:

Field	Size	Purpose in a capture
Tag Protocol Identifier, TPID	16 bits	Usually `0x8100`; identifies an 802.1Q-tagged frame.
Priority Code Point, PCP	3 bits	Carries Layer 2 priority, with values from 0 through 7.
Drop Eligible Indicator, DEI	1 bit	Marks a frame as eligible for preferential discard during congestion.
VLAN Identifier, VID	12 bits	Identifies the VLAN to which the frame belongs.

Older documentation may call the DEI bit the Canonical Format Indicator, or CFI. In current Ethernet use, the more operationally useful interpretation is DEI: a congestion-handling indication rather than the VLAN identity.

The VLAN ID is the primary field for Layer 2 segmentation. Although 12 bits can represent values from 0 through 4095, typical operational VLAN IDs are $1$ through $4094$ :

VLAN ID $0$ is used for priority-tagged frames and does not identify an ordinary VLAN membership.
VLAN ID $4095$ is reserved.
VLAN IDs $1$ through $4094$ are usable subject to platform and design restrictions.

Do not confuse PCP with VLAN ID. A frame may have PCP 5 and VLAN ID 20: the first expresses delivery priority, while the second determines its Layer 2 forwarding domain.

For example, a decoded capture might show:

802.1Q Virtual LAN
    Priority: 5
    DEI: 0
    ID: 100
Type: IPv4 (0x0800)

The tag-control information for that example is 0xA064: PCP is 5, DEI is 0, and VID is 100. Wireshark does this bit decoding for you, so the practical task is to verify each displayed field rather than manually convert hex during an incident.

The tag adds four bytes to the Ethernet frame. For a conventional 1500-byte payload, the maximum Ethernet frame increases from 1518 bytes to 1522 bytes when the FCS is included. Switches recompute the FCS when they insert or remove a tag. Most host-interface and SPAN captures do not show the FCS, and usually do not show the preamble either; their absence from Wireshark is not evidence that Ethernet omitted them on the wire.

Inter-Switch Link and IEEE 802.1Q Frame Format

Read Cisco’s Inter-Switch Link and IEEE 802.1Q Frame Format to consolidate the exact position and internal fields of the tag, then connect those fields to traditional native-VLAN trunk behavior.

In the section “IEEE 802.1Q Frame,” begin with the insertion description. Notice that the tag changes the Ethernet frame, requiring a new FCS. In “Field Descriptions,” read from TPID through VID, paying particular attention to the difference between priority and VLAN identity. Finally, near the later discussion of 802.1Q trunks, read the native-VLAN passage. Treat the native-VLAN statements as the conventional trunk behavior you will validate in captures and configuration.

What a trunk capture can, and cannot, prove

A packet captured directly on an inter-switch trunk is often the cleanest place to observe 802.1Q tags. A VLAN 20 frame crossing that trunk might appear in Wireshark as:

Ethernet II
    Destination: 00:11:22:33:44:20
    Source: 00:11:22:33:44:10
802.1Q Virtual LAN
    Priority: 0
    DEI: 0
    ID: 20
Type: ARP (0x0806)
Address Resolution Protocol

This connects directly to the ARP lesson. The ARP request is still an Ethernet broadcast, but the VLAN tag tells the receiving switch that it is a broadcast only in VLAN 20. It must not flood that ARP request into VLAN 30.

In Wireshark, begin with these display filters:

vlan

vlan.id == 20

vlan.id == 20 && arp

The first filter shows frames with a decoded VLAN header; the second narrows the view to one VLAN; the third is useful when investigating ARP scope or an apparent duplicate-IP problem in a particular VLAN.

Virtual Bridged LAN (VLAN, IEEE 802.1 Q)

Use Wireshark’s VLAN reference to compare a tagged-frame decode with the fields you see in your own captures and to note the filter syntax.

Under “Ethernet Packet Format,” read the tagged-frame layout, then continue through the “VLAN Tag” table. In “Example traffic,” inspect the complete decoded sample beginning with the example frame; follow its Priority, CFI, ID, and inner IP EtherType entries. Finally, in the “Display Filter” and “Capture Filter” portions, read from the VLAN filter examples. Use vlan.id == 20 as your preferred Wireshark display filter when isolating one tagged VLAN.

Be careful not to over-interpret a missing VLAN header. An untagged frame at a capture point can have several explanations:

It was captured on an access port, where the switch sends ordinary untagged Ethernet.
It was captured on a trunk and belongs to that trunk’s untagged native VLAN.
A SPAN, virtual-switch, NIC driver, or offload feature presented a modified view of the frame.
The source interface configuration is not actually a trunk.

Thus, “no 802.1Q header is visible” does not independently prove “this is native-VLAN traffic.” You need the capture location and both ends’ switchport configuration.

Native VLAN handling: untagged does not mean unclassified

On the conventional 802.1Q trunks commonly encountered in Cisco enterprise environments, one VLAN is configured as the native VLAN. Frames belonging to that VLAN are transmitted without an 802.1Q tag. All other permitted VLANs are transmitted with tags.

On ingress, a switch processes a conventional trunk this way:

Incoming frame on the trunk	Receiving switch classification
Tagged with VID 20	VLAN 20, assuming VLAN 20 is permitted on the trunk
Tagged with VID 30	VLAN 30, assuming VLAN 30 is permitted on the trunk
Untagged	The receiving port’s configured native VLAN, also called its port VLAN identifier in broader 802.1Q terminology
Tagged with a disallowed or unknown VLAN	Usually discarded rather than forwarded into another VLAN

The important architectural principle is this:

A native VLAN is not “no VLAN.” It is the VLAN a trunk locally assigns to untagged traffic.

The switch still applies VLAN-scoped MAC learning, flooding, security policy, and forwarding behavior. The tag is absent only on that one trunk segment.

Native VLAN - the DEFINITIVE illustration

Watch the selected demonstration from Native VLAN - the DEFINITIVE illustration by Practical Networking. It provides a capture-based contrast between tagged traffic and traffic crossing a trunk untagged as the native VLAN.

Watch tagged trunk traffic first. Observe that Wireshark displays different VLAN IDs for the two ICMP exchanges while they cross the same trunk. Then watch native traffic, comparing the unchanged tagged VLAN 22 exchange with VLAN 33 traffic after it becomes native and loses its visible VLAN header. Finish with the receive rule: tagged frames follow their VID, while untagged frames are assigned to the receiving port’s local native VLAN.

The native-VLAN mismatch

Consider a trunk between Switch A and Switch B:

Trunk setting	Switch A	Switch B
Native VLAN	99	1
Allowed VLANs	1, 20, 99	1, 20, 99

If Switch A sends a VLAN 99 frame, it sends it untagged, because 99 is native locally. Switch B receives that untagged frame and classifies it as VLAN 1, because 1 is native locally.

The reverse direction creates the opposite mistake: Switch B sends VLAN 1 untagged, and Switch A classifies it as VLAN 99. Tagged VLAN 20 traffic may continue working perfectly, which is why this fault can be confusing in production: only the untagged/native traffic is misclassified.

A native mismatch is therefore a segmentation defect, not merely a cosmetic configuration inconsistency. It can create connectivity failures, unexpected broadcasts, or traffic exposure between VLANs that were meant to remain distinct.

For an architecture review, the minimum controls are straightforward:

Configure the same native VLAN at both ends of every trunk.
Explicitly restrict the VLANs permitted on each trunk.
Avoid using the default VLAN or a business-critical user VLAN as the native VLAN.
Where the platform and design support it, consider tagging native-VLAN traffic as an additional safeguard rather than relying on untagged delivery.
Validate operationally with both configuration and a trunk-side capture when a fault is suspected.

A short EVE-NG validation workflow

Build two Layer 2 switches connected by a trunk, with two hosts in VLAN 20 and two hosts in VLAN 30. Configure VLAN 30 as the native VLAN on both trunk interfaces and allow VLANs 20, 30, and 99 across the trunk.

Capture the inter-switch link, then generate one ping in each VLAN. Your evidence should look like this:

Test traffic	Expected trunk observation
VLAN 20 host to VLAN 20 host	802.1Q header present, `vlan.id == 20`
VLAN 30 host to VLAN 30 host	No 802.1Q header, assuming VLAN 30 is the native VLAN
ARP for a VLAN 20 peer	Ethernet broadcast plus an 802.1Q VLAN 20 header
ARP for a VLAN 30 peer	Ethernet broadcast without a visible 802.1Q header on the trunk

Then temporarily change the native VLAN on one trunk endpoint to VLAN 99. Do not change the allowed VLAN list. Repeat the VLAN 30 ping and inspect both the capture and the switch MAC-address tables. The traffic that was previously interpreted as VLAN 30 at both ends is now received as VLAN 99 on one side, so the expected peer in VLAN 30 will not be reached. Restore the matching native-VLAN configuration immediately after observing the behavior.

This is a useful troubleshooting discipline: do not stop at “the ping failed.” Correlate the capture’s tag state with the local trunk configuration and the VLAN in which each switch learns the source MAC.

Key takeaways

An 802.1Q tag is a four-byte Ethernet-header insertion between the source MAC and the original EtherType or Length field.
0x8100 usually identifies the tag; PCP expresses Layer 2 priority, DEI expresses discard eligibility, and VID identifies the VLAN.
Access-port traffic is ordinarily untagged because the switch assigns VLAN context from the ingress port.
Trunks carry multiple VLANs by tagging frames, then the receiving switch uses the VID to classify them.
On a conventional trunk, the native VLAN is sent untagged, but it remains a fully defined VLAN.
An untagged frame in a capture is meaningful only when you also know the capture location and trunk configuration.
A native-VLAN mismatch causes each switch to classify untagged frames into a different VLAN, producing a subtle but serious segmentation failure.

Next, you will move from VLAN carriage to Ethernet physical and link-layer health, using auto-negotiation, speed, duplex, and interface counters to diagnose link problems.