What is the difference between an access port, a trunk port and a native VLAN? An ordinary access port connects an endpoint to one data VLAN; an IEEE 802.1Q trunk carries multiple VLANs over one link.[1][2] The native VLAN is not a third port type: under normal untagged-native operation, it identifies the VLAN used for untagged traffic on a trunk.[1]
Access vs trunk vs native VLAN: the short comparison
The table describes ordinary Ethernet data traffic, not every control-protocol or voice-VLAN exception.
| Item | Purpose | Typical traffic on the wire | Cisco IOS-style setting |
|---|---|---|---|
| Access port | Attach an endpoint to one data VLAN.[2] | Untagged traffic in the basic endpoint example | switchport mode access and switchport access vlan 10 |
| Trunk port | Transport several VLANs across a link.[1] | Tagged non-native VLAN traffic; native traffic is normally untagged.[1] | switchport mode trunk |
| Native VLAN | Define the trunk's untagged VLAN association.[1] | Untagged in the default behavior described here.[1] | switchport trunk native vlan 999 |
| Allowed VLAN list | Limit which VLANs may traverse a trunk.[1] | A forwarding restriction, not a tag format | switchport trunk allowed vlan 10,20,999 |
Keep port mode, VLAN membership, tagging and forwarding state separate in your explanation. My troubleshooting habit is to check all four rather than treating the word “trunk” as proof that a particular VLAN works.
How a frame crosses two switches
This is an illustrative packet walk, not output from an executed lab. Assume two switches, a working trunk, VLAN 10 present and allowed on both sides, native VLAN 999, forwarding ports, and two ordinary untagged endpoints in VLAN 10.
Host A -- access VLAN 10 -- Switch A
|
802.1Q trunk
native VLAN 999
allowed 10,20,999
|
Host B -- access VLAN 10 -- Switch B
- Host A sends an untagged Ethernet frame to its access port. In this ordinary static-access example, the switch associates that traffic with VLAN 10.[2]
- When the frame leaves through the trunk, VLAN 10 is not the native VLAN, so the switch sends it with an 802.1Q tag identifying VLAN 10.[1]
- The receiving switch associates the tagged traffic with VLAN 10; the trunk extends that VLAN across the link rather than routing it into another VLAN.[1][2]
- For delivery to the ordinary untagged endpoint on an access port, the frame is transmitted without the trunk's VLAN tag.
Changing the trunk's native VLAN does not change the access VLAN of either host: Cisco configures those as separate interface attributes.[1] Likewise, carrying VLANs 10 and 20 over the same trunk does not provide IP routing between them; inter-VLAN communication needs a Layer 3 function such as routing through SVIs.[2]
Native VLAN, default VLAN and management VLAN are different ideas
Cisco's documented default native VLAN is VLAN 1, but the native VLAN can be changed.[1] A management VLAN describes the purpose of the traffic, whereas native VLAN describes its untagged treatment on a trunk.[2] They can use the same VLAN ID, but that is a design choice—not a requirement implied by the word “native.”
For the ordinary trunk behavior in this article, an untagged received frame belongs to the locally configured native VLAN, and traffic leaving in that VLAN is sent untagged.[1] Do not turn this default into a universal statement that native traffic can never be tagged: native-tagging options exist on some platforms, and their receive behavior must be checked in the exact platform documentation. This example assumes no native-tagging override; do not copy its assumptions into a differently configured network.
What happens with a native VLAN mismatch?
Consider a hypothetical trunk with native VLAN 10 on Switch A and native VLAN 20 on Switch B. If a VLAN 10 data frame leaves A untagged and B accepts and forwards that frame, B classifies it into its own untagged/native VLAN, VLAN 20—the receiving side cannot recover an absent VLAN ID from the frame.[1] This is a conceptual illustration of traffic misdirection, not a promise that every mismatched trunk will forward: Cisco warns that a native VLAN mismatch can also cause spanning-tree problems.[1][2]
My recommendation is to check both ends immediately when a mismatch warning appears. Do not disable spanning tree just to make the link appear usable.
A small Cisco IOS-style configuration example
The following is an original, illustrative configuration for isolated lab switches. Adapt interface names, feature support and VLAN-management policy to your platform; it has not been executed on a switch for this article. Create the example VLANs on both switches using a permitted VLAN-management mode.
Cisco documents separate commands for static-access membership, trunk mode, native VLAN and the allowed list.[1][2]
configure terminal
vlan 10
name LAB-USERS
vlan 20
name LAB-SERVICES
vlan 999
name LAB-NATIVE
exit
interface GigabitEthernet1/0/10
description LAB-ENDPOINT
switchport mode access
switchport access vlan 10
no shutdown
exit
interface GigabitEthernet1/0/48
description LAB-INTERSWITCH
switchport mode trunk
switchport trunk native vlan 999
switchport trunk allowed vlan 10,20,999
switchport nonegotiate
no shutdown
end
Configure the peer trunk consistently. In this lab, VLAN 999 is explicitly present and allowed to make the native-VLAN example transparent; this is not a production hardening prescription.
switchport nonegotiate suppresses DTP frames; it is not a replacement for switchport mode trunk.[1]
For devices that do not support DTP, Cisco documents using explicit trunk mode together with nonegotiate rather than relying on negotiation.[1]
Change-control warning: treat an allowed-list command without add or remove as setting the intended list, not as an incremental edit. Before changing an existing uplink, record its current configuration and preserve the management path.
Cisco provides add and remove options for modifying the allowed VLAN list.[1]
Verification and troubleshooting checklist
Start with these read-only Cisco IOS-style checks; output fields and command availability vary by platform.[1][2]
show interfaces GigabitEthernet1/0/10 switchport
show interfaces GigabitEthernet1/0/48 switchport
show interfaces GigabitEthernet1/0/48 trunk
show vlan brief
show running-config interface GigabitEthernet1/0/48
My suggested decision sequence is:
| Check | Question to answer | Next action |
|---|---|---|
| Physical link | Are both ends up and connected to the intended peer? | Resolve cabling, shutdown or interface errors first |
| Operational mode | Is the interswitch link actually operating as a trunk? | Compare configured and operational mode on both ends |
| Access VLAN | Is the endpoint attached to the intended data VLAN? | Inspect the endpoint port, not just the uplink |
| VLAN existence | Does that VLAN exist and remain active on each switch? | Check the VLAN database and management policy |
| Allowed list | Is the required VLAN permitted on each trunk along the path? | Compare the full path, not only the first switch |
| Native VLAN | Do both ends agree on untagged traffic handling? | Check native ID and any tagging overrides |
| Forwarding | Is the required VLAN actually forwarding rather than blocked or pruned? | Inspect STP and pruning state before changing topology |
| Layer 3 | Is the destination in another subnet/VLAN? | Investigate the gateway and routing after Layer 2 checks |
An allowed VLAN is not automatically a working VLAN: Cisco separately describes VLAN availability, allowed membership and spanning-tree forwarding behavior.[1] For example, if VLAN 10 works across the trunk but VLAN 20 does not, I would investigate VLAN-specific membership and forwarding before changing the entire port mode.
Common interview pitfalls
- “Every frame on a trunk is tagged.” Normal native-VLAN data traffic is untagged under the behavior described here.[1]
- “Native VLAN means VLAN 1 forever.” VLAN 1 is the documented default, not an immutable choice.[1]
- “The allowed list creates the VLANs.” VLAN creation and permitted trunk membership are separate configuration tasks.[1][2]
- “Two dynamic-auto ports will form a trunk.” Cisco's DTP description explicitly identifies auto/auto as a combination that does not establish trunking.[1]
- “An access port can never carry voice plus data.” On supported platforms, a voice-VLAN access port can associate phone traffic and attached-PC traffic with separate VLANs.[2]
- “A trunk routes between VLANs.” Trunking extends VLANs; routing between them is a separate Layer 3 function.[1][2]
- “Native mismatch only affects a harmless warning.” Cisco documents potential traffic misdirection and spanning-tree risks.[1][2]
A concise interview answer
“An access port normally places an endpoint in one data VLAN, while an 802.1Q trunk carries multiple VLANs across a shared link.[1][2] Non-native VLAN traffic is tagged, and the native VLAN normally carries untagged traffic; the native setting should match on both ends.[1] The allowed list limits which VLANs can traverse the trunk, but it does not replace VLAN creation or forwarding checks.[1][2] I would verify operational mode, access and native VLANs, allowed membership and STP state before troubleshooting routing.”
Optional isolated lab
Build the two-switch topology above without connecting it to production. First predict where tags will be present, then test same-VLAN connectivity and compare it with a packet capture appropriate to your platform.
Suggested fault exercise: remove VLAN 10 from the allowed list on one lab trunk, observe the impact, and restore the original configuration. Record actual results rather than assuming a successful command proves forwarding. Do not deliberately introduce a native mismatch into a production network.
Related reading
- Can a VTP client overwrite a server? Revision numbers explained
- STP vs RSTP port states and roles
- BPDU Guard vs BPDU Filter vs Root Guard vs Loop Guard
Summary
Access answers “which endpoint data VLAN?”, trunk answers “which VLANs share this link?”, and native answers “how is untagged trunk traffic associated with a VLAN?”[1][2]
Preparing for a network engineering interview? Practice the frame walk aloud, then explain how you would prove that one specific VLAN is working end to end.
Post a Comment