"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. On HP ProCurve / Aruba AOS-Switch, a port can be an untagged member of only one port-based VLAN, so making it untagged in a new VLAN quietly takes it out of the old one, and an uplink's untagged (native) VLAN can change without anyone touching the trunk. Cisco hides the per-VLAN view behind switchport mode, which means you sometimes need to capture the link to see what tag actually leaves the port, as in the lab below.
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 enableDetail 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.
Practice VLANs in the browser
PingLabz Pro includes guided VLAN and trunking labs in an IOS-style simulator. The free Essentials lab is a good first step if you are new to the prompt.
VLAN and Trunk Troubleshooting Field Guide
Included with PingLabz Pro · 10 pages · US Letter PDF
Follow a frame from the host to its gateway. Cisco and Linux inspection commands, a worked tag mismatch, practice cases, and a change record.
Already a member? Sign in.
Lab: Tagged and Untagged Frames on the Wire
The same VLAN 10 ping crosses an access cable without a tag and an interswitch trunk with a tag. This lab used Cisco IOSv-L2, Experimental Version 15.2(20200924:215240), with Linux hosts in Containerlab. It tested Layer 2 forwarding and direct SVI reachability; it did not test inter-VLAN routing.
| Connection | Interfaces | VLANs and addresses |
|---|---|---|
| Interswitch trunk | SW1 Gi0/1 to SW2 Gi0/1 | Allowed 10,20,99; native 99 |
| VLAN 10 access hosts | Gi1/0 on each switch | 10.71.10.11 and 10.71.10.12, both /24 |
| VLAN 20 access hosts | Gi1/1 on each switch | 10.71.20.11 and 10.71.20.12, both /24 |
| Linux trunk connection | SW2 Gi1/2 to Linux eth1 | eth1.10: 10.71.10.13/24; eth1.20: 10.71.20.13/24; untagged eth1: 10.71.99.13/24 |
| Native VLAN ping target | SW1 Vlan99 | 10.71.99.1/24 |
VLAN 99 carries test traffic here so its untagged frames are visible. That is a lab choice, separate from the unused native VLAN recommendation above. VLANs 10, 20 and 99 existed on both switches. The SW1 trunk configuration excerpt was:
...
SW1(config)#interface GigabitEthernet0/1
...
SW1(config-if)#switchport trunk encapsulation dot1q
SW1(config-if)#switchport mode trunk
SW1(config-if)#switchport nonegotiate
SW1(config-if)#switchport trunk native vlan 99
SW1(config-if)#switchport trunk allowed vlan 10,20,99
SW1(config-if)#no shutdown
SW1(config-if)#exit
...The working trunk reported all three VLANs allowed, active and forwarding:
...
SW1#show interfaces trunk
Port Mode Encapsulation Status Native vlan
Gi0/1 on 802.1q trunking 99
Port Vlans allowed on trunk
Gi0/1 10,20,99
Port Vlans allowed and active in management domain
Gi0/1 10,20,99
Port Vlans in spanning tree forwarding state and not pruned
Gi0/1 10,20,99
...VLAN 10: Tagged on the Trunk, Untagged on the Access Cable
These are excerpts from the saved tcpdump -e -n decodes. The interswitch trunk shows the VLAN 10 request and reply with ethertype 802.1Q (0x8100) and vlan 10:
...
03:41:09.496872 aa:c1:ab:64:46:8e > aa:c1:ab:34:73:8e, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4 (0x0800), 10.71.10.11 > 10.71.10.12: ICMP echo request, id 31, seq 0, length 64
03:41:09.504123 aa:c1:ab:34:73:8e > aa:c1:ab:64:46:8e, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4 (0x0800), 10.71.10.12 > 10.71.10.11: ICMP echo reply, id 31, seq 0, length 64
...The access cable shows that same ICMP exchange, including identifier 31 and sequence 0, with IPv4 directly after the Ethernet addresses:
...
03:41:09.490252 aa:c1:ab:64:46:8e > aa:c1:ab:34:73:8e, ethertype IPv4 (0x0800), length 98: 10.71.10.11 > 10.71.10.12: ICMP echo request, id 31, seq 0, length 64
03:41:09.509255 aa:c1:ab:34:73:8e > aa:c1:ab:64:46:8e, ethertype IPv4 (0x0800), length 98: 10.71.10.12 > 10.71.10.11: ICMP echo reply, id 31, seq 0, length 64
...The access frames are 98 bytes in this decode; the tagged trunk frames are 102 bytes. The four-byte difference is the 802.1Q header. For the fields inside it, see the 802.1Q VLAN tag explained.
Native VLAN 99: No Tag on the Trunk
The Linux host sent this ping through its parent eth1 interface to SW1's VLAN 99 SVI. On the same interswitch trunk, both directions have ethertype IPv4 (0x0800) and no vlan 99 header:
...
03:41:18.894831 aa:c1:ab:12:8a:80 > 0c:00:85:e5:80:63, ethertype IPv4 (0x0800), length 98: 10.71.99.13 > 10.71.99.1: ICMP echo request, id 38, seq 0, length 64
03:41:18.921965 0c:00:85:e5:80:63 > aa:c1:ab:12:8a:80, ethertype IPv4 (0x0800), length 98: 10.71.99.1 > 10.71.99.13: ICMP echo reply, id 38, seq 0, length 64
...An untagged frame still belongs to a VLAN inside the switch. On this trunk, the receiving port classifies it into native VLAN 99. The captured MAC table also learned the Linux host's untagged source MAC in VLAN 99 on SW2 Gi1/2.
What the Linux Trunk Host Sees
The parent eth1 capture sees tagged traffic. Here is a VLAN 10 exchange with the Linux host:
...
03:41:12.515311 aa:c1:ab:64:46:8e > aa:c1:ab:12:8a:80, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4 (0x0800), 10.71.10.11 > 10.71.10.13: ICMP echo request, id 25, seq 0, length 64
03:41:12.515354 aa:c1:ab:12:8a:80 > aa:c1:ab:64:46:8e, ethertype 802.1Q (0x8100), length 102: vlan 10, p 0, ethertype IPv4 (0x0800), 10.71.10.13 > 10.71.10.11: ICMP echo reply, id 25, seq 0, length 64
...The capture on logical VLAN interface eth1.10 sees the same exchange after Linux removes the VLAN header:
...
03:41:12.515311 aa:c1:ab:64:46:8e > aa:c1:ab:12:8a:80, ethertype IPv4 (0x0800), length 98: 10.71.10.11 > 10.71.10.13: ICMP echo request, id 25, seq 0, length 64
03:41:12.515352 aa:c1:ab:12:8a:80 > aa:c1:ab:64:46:8e, ethertype IPv4 (0x0800), length 98: 10.71.10.13 > 10.71.10.11: ICMP echo reply, id 25, seq 0, length 64
...The parent capture also contained tagged VLAN 20 and untagged VLAN 99 traffic. A capture on a Linux VLAN subinterface therefore cannot, by itself, tell you whether the frame was tagged on the cable. Check the parent interface or the switch-facing cable as well.
Native VLAN Mismatch: Two Allowed Lists, Two Symptoms
SW1 stayed native 99 while SW2 changed to native 199. The results depended on whether VLAN 199 was allowed:
| Test | Allowed VLANs on both ends | Captured result |
|---|---|---|
| VLAN 199 filtered | 10,20,99 | CDP native VLAN mismatch warning; zero STP inconsistent segments; native ping lost 4 of 4 packets; VLAN 10 ping passed |
| Both native VLANs present and allowed | 10,20,99,199 | Both switches logged received-PVID errors and local/peer PVID blocking; each reported two inconsistent segments; native ping lost 3 of 3 packets; VLAN 10 ping passed |
With VLAN 199 filtered, the STP check was:
...
SW1#show spanning-tree inconsistentports
Name Interface Inconsistency
-------------------- ------------------------ ------------------
Number of inconsistent ports (segments) in the system : 0
...With both VLANs allowed, the same check on SW1 showed the two affected VLAN segments:
...
SW1#show spanning-tree inconsistentports
Name Interface Inconsistency
-------------------- ------------------------ ------------------
VLAN0099 GigabitEthernet0/1 Port VLAN ID Mismatch
VLAN0199 GigabitEthernet0/1 Port VLAN ID Mismatch
Number of inconsistent ports (segments) in the system : 2
...The second capture also showed PVID_Inc for VLANs 99 and 199 on Gi0/1. VLANs 10 and 20 remained in the trunk's forwarding list. Restoring native VLAN 99 and allowed VLANs 10,20,99 on both ends restored the native ping. A mismatch did not block every VLAN, and the first test did not produce PVID blocking. See native VLAN configuration for the configuration checks.
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 NativeFor 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
switchport mode access + switchport access vlan 10vlan 10 + untagged 1/0/1family ethernet-switching { interface-mode access; vlan { members 10; } }switchport mode trunk + switchport trunk allowed vlan 10,20,30vlan 10 tagged 1/0/24 (and 20, 30)interface-mode trunk; vlan { members [ 10 20 30 ]; }switchport trunk native vlan 999vlan 999 untagged 1/0/24 (and tagged for others)native-vlan-id 999The 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.
Read “Tagged” as VLAN Membership, Not a Port Mode
Use these terms alongside the configuration examples above. HP/Aruba ProCurve and AOS-Switch use a different CLI from Aruba AOS-CX; “Aruba” alone does not identify the syntax.
| Platform | Tagged VLAN membership | Untagged access VLAN | Untagged VLAN on a multi-VLAN link |
|---|---|---|---|
| Cisco IOS / IOS XE | switchport mode trunk and switchport trunk allowed vlan 10,20,99; non-native VLANs are tagged in this lab | switchport mode access and switchport access vlan 10 | switchport trunk native vlan 99; permit 99 in the allowed list when carrying its traffic |
| HP ProCurve / Aruba AOS-Switch | Under vlan 10, use tagged 24 for port 24; repeat for other tagged VLANs | Under vlan 10, use untagged 1 for port 1 | Under vlan 99, use untagged 24; that same port can be tagged in VLANs 10 and 20 |
| Aruba AOS-CX | Interface command vlan trunk allowed 10,20,99; non-native VLANs are tagged | Interface command vlan access 10 | Interface command vlan trunk native 99, then set the intended allowed list |
“Tagged” describes one VLAN's treatment on a link; “trunk” describes the port carrying VLANs. A Cisco trunk can carry both tagged VLANs and one untagged native VLAN. AOS-CX also supports explicit native VLAN tagging, so confirm that option before assuming native traffic is untagged. The Cisco lab above demonstrates the default untagged native traffic, not that optional setting.
FAQ
What Is the Difference Between Tagged and Untagged VLANs?
A tagged Ethernet frame carries an 802.1Q VLAN ID; an untagged frame relies on the receiving port's VLAN assignment. In the lab, the VLAN 10 ping was tagged on the trunk and untagged on the access cable. VLAN membership stayed the same across both links.
Is Untagged vs Tagged the Same as Access vs Trunk?
They describe different things: the frame format and the port mode. An ordinary access port uses untagged traffic for its access VLAN, while the lab trunk carried tagged VLANs 10 and 20 plus untagged native VLAN 99. See Cisco access, trunk and dynamic switchport modes when checking the port configuration.
What Is the Difference Between a Native VLAN and a Tagged VLAN?
The native VLAN supplies the VLAN identity for untagged traffic arriving on an 802.1Q trunk. With the lab settings, its outgoing frames were also untagged, while the other allowed VLANs carried explicit tags. “Allowed” does not mean “tagged”: native VLAN 99 was allowed too.
Does Return Traffic on an Untagged Interface Get Set to the Native VLAN?
On ingress, an untagged frame takes the receiving port's access VLAN if that port is in access mode, or its native VLAN if it is a trunk. The switch does not assign a VLAN because a packet happens to be a reply. The lab's VLAN 10 reply left the access port untagged but crossed the trunk tagged as VLAN 10; the native VLAN 99 reply crossed that trunk untagged.
Why Does Linux Show No VLAN Tag on a VLAN Subinterface?
Linux has already separated that traffic into its VLAN interface and removed the header before the captured view shown here. The eth1.10 decode showed plain IPv4 while the parent eth1 decode showed vlan 10 for the same exchange. Choose the capture point before drawing a conclusion about the wire format.
Can a Trunk Be Up While VLAN Traffic Still Fails?
Yes. The native mismatch tests left VLAN 10 working while the native ping failed; allowing both mismatched native VLANs also produced PVID blocking for those VLANs. Check the allowed and forwarding lists, STP inconsistencies and actual host reachability; if the gateway is the suspect, continue with SVI troubleshooting.
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.