Tagged vs Untagged VLANs: How Trunks and Access Ports Really Work

"Tagged" and "untagged" are how you describe whether a frame on a switch port is carrying an 802.1Q VLAN tag or not. The terminology matters because half of every VLAN troubleshooting ticket comes down to a port being tagged when it should be untagged, or vice versa. If you have ever had a working configuration that mysteriously broke when you connected a new vendor's switch, the answer was almost always a tagged/untagged mismatch.

This article walks through what tagged and untagged actually mean, how Cisco and other vendors describe the same concept with slightly different vocabulary, when to use each, and the cross-vendor translation cheat sheet you need when working in mixed environments. If you are studying for CCNA, configuring switches across multiple vendors, or troubleshooting a trunk that should "just work", this is the reference.

The Definitions

An untagged frame is an Ethernet frame with no 802.1Q VLAN tag. It looks exactly like a frame you would see on a network with no VLANs at all: destination MAC, source MAC, EtherType, payload, FCS. End hosts (PCs, printers, IP phones in the data context, almost everything that is not a switch or router) send and receive untagged frames natively.

A tagged frame has a 4-byte 802.1Q tag inserted between the source MAC and the EtherType. The tag carries the VLAN ID. Switches use the tag to know which VLAN a frame belongs to as it crosses a link that carries multiple VLANs.

So the question "is the frame tagged?" is the same as "does this frame carry a VLAN ID?" An untagged frame leaves it implicit (the receiver has to know the VLAN from context). A tagged frame makes it explicit.

Port Types: Where Tagged and Untagged Live

The confusion enters when other vendors use different vocabulary for the same things. HP/Aruba and Juniper, for example, describe ports in terms of how each VLAN is treated rather than calling the port "access" or "trunk":

The HP/Aruba mental model is per-VLAN: for each VLAN, decide whether this port carries it tagged, untagged, or not at all. The Cisco mental model is per-port: assign the port a mode (access or trunk), then derive the per-VLAN behavior from that.

Both express the same thing but invite different mistakes. HP/Aruba lets you accidentally configure a port that is untagged on multiple VLANs (which causes ambiguity). Cisco hides the per-VLAN view behind switchport mode, which means you sometimes need to debug what tag actually leaves the port.

When You Want Tagged

Tag frames when:

• The port carries multiple VLANs. The receiver needs to know which VLAN each frame belongs to. This is the trunk case.
• The receiver is a 802.1Q-aware device. A switch, router, virtualization host (vSwitch in tagged mode), wireless AP, firewall in trunk mode.
• You want explicit control. Tagged frames are unambiguous; if the tag says VLAN 100, that is what it is, regardless of what port-level configuration the port has.

The trunk between two switches is always tagged for every VLAN except the native VLAN. The trunk between a switch and a router-on-a-stick configuration uses tagged subinterfaces. The link from a switch to a virtualization host is tagged when the host's vSwitch is configured for trunked VLAN access (VMware "VLAN tagging mode 4095", Hyper-V trunked vNIC, etc.).

When You Want Untagged

Use untagged frames when:

• The port carries exactly one VLAN. The receiver does not need a tag because there is no ambiguity.
• The receiver is not 802.1Q-aware. Most end hosts, simple printers, IoT devices, and entry-level network gear default to untagged.
• You are using a native VLAN on a trunk. Frames in the native VLAN cross the trunk untagged for backwards compatibility.

The host-facing access port is the most common untagged case. PCs do not normally know how to send tagged frames; they send plain Ethernet, and the switch internally classifies the frame into the access VLAN configured on that port.

The Native VLAN: One Port, One VLAN, Untagged on a Trunk

The native VLAN is a special case where a trunk port (which is otherwise tagged) carries one specific VLAN untagged. It exists for backwards compatibility with hubs and old equipment that did not understand 802.1Q.

Default native VLAN: VLAN 1. As covered in detail in VLAN Hopping Attacks and Native VLAN Configuration and Security, you should always change the native VLAN to a dedicated unused VLAN (e.g. 999) for security reasons.

Both ends of the trunk must agree on the native VLAN, or you get a CDP warning and possibly STP issues. The PingLabz pattern: explicitly set the native VLAN on every trunk to the same dedicated unused VLAN, and ensure no host port is in that VLAN.

The Voice + Data Special Case

IP phones are a special case that mixes tagged and untagged on the same physical port. The phone receives traffic for two VLANs:

• Voice VLAN. Tagged. Carries the phone's voice traffic (RTP, signaling).
• Data VLAN. Untagged. Carries traffic from the PC connected behind the phone.

From the switch's perspective, the port is configured as an access port in the data VLAN, with a separate "voice VLAN" assigned. The switch treats the port as access (untagged) for the data VLAN, and tagged (using 802.1Q) for the voice VLAN. The phone receives both, splits them based on tag, and forwards the data VLAN traffic to the PC port behind it untagged.

Configuration:

Switch(config)# interface GigabitEthernet1/0/5
Switch(config-if)#  switchport mode access
Switch(config-if)#  switchport access vlan 10        ! Data VLAN (untagged)
Switch(config-if)#  switchport voice vlan 20         ! Voice VLAN (tagged)
Switch(config-if)#  spanning-tree portfast
Switch(config-if)#  spanning-tree bpduguard enable

Detail in Configuring Voice VLANs on Cisco Switches for IP Phones.

The Tagged/Untagged Mismatch: How Trunks Break

The classic failure: one end of a trunk has VLAN 100 tagged, the other end has VLAN 100 untagged (perhaps because someone configured the second switch as if VLAN 100 were the native VLAN). What happens?

Frames in VLAN 100 sent from end A arrive at end B with a tag. End B is expecting them untagged, sees the tag as confusion, and the behavior depends on platform: Cisco often drops the tagged frames on a port expecting the native VLAN to be different. Some platforms log warnings; some just silently drop.

The other direction: end B sends frames in VLAN 100 untagged (because B thinks 100 is the native VLAN). End A receives the untagged frames and treats them as belonging to A's native VLAN (whatever A's native is, which is something different). The frames disappear into the wrong VLAN.

The first symptom: hosts on VLAN 100 cannot reach each other across the trunk, even though "the trunk is up". show interfaces trunk on Cisco shows the trunk in trunking state but does not always flag the mismatch. show cdp neighbors often does, with a Native VLAN Mismatch warning.

Diagnosing Tagged/Untagged Issues

Three Cisco commands for the diagnosis:

! What VLANs are tagged on this trunk?
Switch# show interfaces gi1/0/24 trunk

! What VLAN is untagged (native) on this trunk?
Switch# show interfaces gi1/0/24 switchport | include Native

! CDP neighbor warnings (often catches mismatches)
Switch# show cdp neighbors detail | include Native

For per-VLAN packet capture, mirror the trunk port to a SPAN session and capture with Wireshark. Tagged frames show as "802.1Q Virtual LAN" in the packet detail; untagged frames do not.

Tagged vs Untagged in Virtualization

vSwitches in VMware, Hyper-V, KVM, and proxmox all support both tagged and untagged uplinks. The terminology varies but the concept is identical:

Most VMs run in "access" mode where the vSwitch does the tagging on the wire (VST, Virtual Switch Tagging) and the VM only sees untagged frames. The vSwitch is configured as a Layer 2 trunk to the physical switch carrying multiple VLANs tagged.

Cross-Vendor Translation Cheat Sheet

The functional outcome is identical; the vocabulary differs. Whenever you bring up a trunk between Cisco and HP/Aruba, the most reliable check is to verify that one VLAN per trunk is "untagged on Aruba" and "native on Cisco" with the same VID.

Summary

Tagged frames carry an explicit 802.1Q VLAN ID; untagged frames do not. Switches use tagging on multi-VLAN trunks to keep VLAN identity intact across links. Host-facing access ports send and receive untagged frames in one VLAN. The native VLAN is the one VLAN on a trunk that is sent untagged for legacy compatibility.

If you are working across vendors, remember that "tagged" and "untagged" are platform-neutral concepts; everyone implements 802.1Q the same way, but the configuration vocabulary differs. Mismatches between tagged and untagged on the two ends of a trunk are the leading cause of "trunk is up but traffic does not flow" tickets. Bookmark the VLAN cluster pillar for the full operational picture.