2026-06-03

VLAN Tag Missing in PCAP Analysis: 802.1Q Tags, Native VLAN, Trunk Ports, Driver Stripping, and Wrong

How to analyze missing VLAN tags in packet captures, 802.1Q tagging, native VLAN behavior, trunk port mistakes, driver tag stripping, capture filters, and VLAN mismatch failures.

A trace that shows untagged DHCP or one-way traffic on a configured trunk can contradict everything the switch says about its VLANs. Before declaring an 802.1Q failure, determine whether the frame crossed a native VLAN, whether the NIC or driver stripped the VLAN tag, and whether the capture point was before or after the trunk boundary. A PCAP can show the tags visible at that point and preserve VLAN IDs and priorities; it cannot prove that an absent tag was never present elsewhere in the path.

PCAP Surgery is useful because VLAN evidence depends heavily on capture point, driver behavior, filters, and whether the packet was captured before or after tag stripping.

What an 802.1Q tag proves

An 802.1Q tag carries VLAN identity in the Ethernet frame. If the tag is visible, the capture can show the VLAN ID, priority bits, and encapsulated ethertype.

If the tag is missing, several possibilities exist:

Packet is truly untagged.
Native VLAN removed the tag.
Capture point is after tag stripping.
Network driver stripped the tag before pcap saw it.
Capture filter excluded tagged frames.
Mirror/SPAN configuration changed the frame.
Virtual switch presented de-VLANized traffic.

Do not assume "no tag in pcap" means "no tag on the wire."

Native VLAN behavior

On many trunks, native VLAN traffic is sent untagged. That can surprise engineers who expect every trunk packet to show an 802.1Q header.

Symptoms:

VLAN 10 appears tagged, VLAN 1 appears untagged.
DHCP arrives untagged on native VLAN.
One side expects tagged native VLAN.
Switches disagree on native VLAN.
Untagged frames are classified into the wrong VLAN.

The pcap should be interpreted with switch port mode and native VLAN configuration.

Driver tag stripping

Operating systems and NIC drivers may strip VLAN tags before packets reach the capture tool. Capturing on a VLAN subinterface may show de-tagged packets because the OS has already classified them.

Better evidence may require:

Capturing on the physical interface.
Disabling VLAN offload if possible.
Capturing on a switch mirror port.
Capturing on both trunk endpoints.
Checking NIC driver offload settings.

PCAP Surgery can preserve and label captures from different points.

Capture filters and VLAN

Capture filters can behave differently for tagged frames. A filter that matches untagged IP traffic may miss tagged traffic unless the filter accounts for VLAN headers.

Symptoms:

Ping works but capture shows nothing.
Only untagged traffic appears.
DHCP is missing from one VLAN.
Same flow appears after filter is removed.

Before diagnosing the network, validate the capture filter.

Trunk allowed VLAN mistakes

If a VLAN is missing from allowed trunk lists, traffic may never cross the link. A capture on one side may show frames leaving, while the other side sees nothing.

Evidence:

Tagged frames leave source switch.
No matching frames arrive on destination side.
Other VLANs work.
STP state differs per VLAN.
Native VLAN mismatch logs appear.

This is a network configuration problem, not a host stack problem.

Virtualization and cloud mirrors

VMs, containers, and cloud packet mirrors complicate VLAN visibility.

Possible issues:

Hypervisor strips tag before guest capture.
Port group expects a specific VLAN ID.
Trunk mode not enabled for VM NIC.
Cloud mirror omits original L2 tag.
Container bridge sees only de-tagged traffic.

Always document capture point and virtualization layer.

Debug checklist

Use this workflow:

Identify expected VLAN ID.
Identify capture point.
Confirm physical vs VLAN subinterface capture.
Check whether native VLAN should be untagged.
Remove or adjust capture filters.
Check NIC VLAN offload behavior.
Capture on trunk ingress and egress.
Compare switch allowed VLAN configuration.
Preserve tagged and untagged examples.
Label each pcap with interface and port mode.

Final diagnosis

Missing VLAN tags in a pcap do not automatically mean missing VLAN tags on the wire. The cause may be native VLAN behavior, driver stripping, capture filters, virtual switching, or a truly misconfigured trunk.

PCAP Surgery helps preserve the exact tagged frames, untagged frames, capture points, and flow evidence needed to prove the VLAN failure path.

Build a layer-by-layer VLAN observation map

Document where the tag is expected to exist and where each sensor sits. A host capture on eth0, a capture on eth0.120, a hypervisor vSwitch trace, and a physical trunk tap observe different representations. An absent tag on a VLAN subinterface is normal after the kernel has classified the frame.

Observation point	Expected representation	Important caveat
Physical trunk tap	802.1Q tag on non-native VLANs	Tap/SPAN may alter or omit tags
Switch access port	Untagged customer frame	VLAN is assigned by port configuration
Native VLAN on trunk	Often untagged	Native VLAN mismatch can leak traffic
Host physical NIC	Tagged or metadata-assisted	Hardware may strip tag before capture
VLAN subinterface	Usually de-tagged logical traffic	Interface identity supplies VLAN context
VM guest	Depends on port-group/trunk mode	Hypervisor may consume the tag

Record device, switch port, port mode, native VLAN, allowed list, interface name, driver, offload settings, capture API, and direction. Without this map, two correct captures can appear contradictory.

How can NIC VLAN offload hide a tag?

Some NICs remove the 802.1Q header and pass VLAN information as descriptor metadata. Depending on OS, driver, and capture path, libpcap may not reconstruct that header. Compare a physical tap or switch capture and test offload changes only in a controlled window. Do not alter production offload merely to make a display look familiar.

Can a capture filter miss VLAN traffic?

Yes. Classic BPF offsets change when an 802.1Q header is present. A filter written only for untagged Ethernet can exclude tagged frames. Start with an unfiltered, bounded test or use an explicit VLAN-aware filter, then confirm packet counters before diagnosing network loss.

What does a visible tag prove?

It proves that the tag and VLAN ID were present in the frame representation delivered to that capture point. It does not prove the frame was accepted on the next switch, permitted across every trunk, or delivered to the destination.

Native VLAN mismatch packet pattern

When two trunk ends use different native VLANs, untagged frames can be assigned to different VLANs on each side. Look for untagged ARP, DHCP, IPv6 NDP, or control traffic whose endpoint expectation belongs to another VLAN. Pair the trace with switch configuration and MAC address tables; packet content alone does not reveal each port’s configured native VLAN.

Symptom	Evidence to collect
DHCP request but no offer	client VLAN, relay path, tagged/untagged direction
ARP request repeats	target VLAN, gateway MAC, return capture
One-way TCP	VLAN representation on both trunk ends
Only one VM fails	port-group VLAN/trunk settings
Tags vanish at host	NIC/driver metadata and subinterface capture

Validate the VLAN fix

Test tagged and untagged control flows deliberately. Confirm the expected VLAN ID at the physical trunk point, correct de-tagged delivery at the logical endpoint, return traffic on the same intended broadcast domain, and switch counters without drops or native-VLAN warnings. Include failover or VM migration if those paths change switching.

Do not stop after seeing one tagged frame. Verify ARP/NDP, DHCP where relevant, and an application handshake in both directions. A frame can carry the right tag and still be blocked by allowed-VLAN policy or assigned to the wrong port group later.

Actionable report and focused artifact

State: expected VLAN, native policy, capture point, visible tag/priority, direction, source/destination MAC, switch port mode, offload/filter state, first missing response, and a comparable healthy flow. Use wording such as “VLAN 120 tag is visible on switch-A trunk ingress but the corresponding frame is absent on trunk egress; switch allowed-VLAN counters are required.”

Preserve tagged and untagged examples, the first failed control exchange, and return path. Use capture scope help and the complete packet-evidence workflow so the derivative retains L2 context rather than starting at an application timeout.

Can PCAP Surgery add a VLAN tag to fix production traffic?

PCAP Surgery can support bounded preparation operations where implemented, but editing a file does not change live switch behavior. Diagnose and correct the switch, hypervisor, interface, or capture configuration, then use a derivative only for an authorized fixture with documented checksums and provenance.

Troubleshooting DHCP on a tagged VLAN

DHCP is a useful control because it combines local broadcast, VLAN forwarding, optional relay, and return unicast/broadcast behavior. Capture the client Discover, switch ingress representation, relay-forwarded request if present, server Offer, relay return, and client-visible Offer. Record transaction ID and client MAC so parallel clients are not mixed.

Missing boundary	Likely next check
Discover absent on access port	Client/NIC/port state
Discover on access, absent on trunk VLAN	VLAN membership or trunk allowed list
Tagged Discover reaches relay, no forwarded request	Relay/SVI configuration
Server sends Offer, client never sees it	Return VLAN, relay, snooping, or capture path
Offer visible with unexpected tag	Native/access/port-group mismatch

DHCP snooping, dynamic ARP inspection, port security, and relay policy can drop traffic even when tags are correct. Use device counters and logs for the exact client MAC and time.

What about QinQ or stacked VLAN tags?

Provider bridging can carry outer S-tags and inner C-tags. A capture point may add or remove one layer. Document both TPIDs and VLAN IDs and avoid assuming a single 802.1Q header. Classic PCAP can carry the observed frame, but interface metadata and capture placement remain essential.

How should a regression fixture represent VLANs?

Use authorized synthetic addresses and preserve the exact Ethernet headers required by the test. Record whether the fixture represents a trunk-side tagged frame or an endpoint-side de-tagged frame. Validate link type, frame length, VLAN ID, priority, inner ethertype, and checksums after any transformation.

The most useful conclusion always names the observation layer: “Tag absent in guest capture but present on physical trunk” is a driver/hypervisor boundary lead; “tag absent on trunk tap where VLAN 120 is non-native” supports a live configuration problem.

Preserve switch configuration snapshots and counters from the incident time, because a later corrected trunk state cannot explain what the original capture point was expected to observe.

Related guides

Continue with the same-language pages below. They cover adjacent stages without changing the canonical owner of this topic: