ArubaOS-CX Native VLAN on Trunks: Untagged Traffic Explained

On ArubaOS-CX, a trunk port can carry many tagged VLANs plus exactly one untagged VLAN - the native VLAN - and the way CX phrases this (native vs allowed lists) confuses engineers coming from ProVision or Comware, where the same concept is spelled "untagged vlan" or "pvid". Getting native VLAN wrong on an inter-switch trunk silently drops or mis-tags all untagged traffic (CDP/LLDP frames, and any client that never tags). This guide explains native VLAN configuration on ArubaOS-CX trunks, the rule that decides whether untagged traffic is forwarded or dropped, the symptoms of a native VLAN mismatch, and the command mapping to ProVision and Comware.

Access vs Trunk vs the Native VLAN

• Access port: one untagged VLAN for end devices; the switch strips tags toward the client.
• Trunk port: carries multiple VLANs with 802.1Q tags; at most one VLAN (the native) may be carried untagged.

A native VLAN must exist on the trunk - by default VLAN 1. Any untagged frame arriving on the trunk is assigned to the native VLAN, and frames leaving in the native VLAN are sent untagged. It is a per-port property: the same VLAN can be native on one trunk and merely tagged on another.

What "native VLAN" means in 802.1Q terms

802.1Q has no special "native" bit. A port simply decides, per frame, whether to insert or strip a tag. CX models this as two per-port attributes:

• the native VLAN - what an untagged frame belongs to on the way in, and what a frame is allowed to leave untagged on the way out;
• the allowed VLAN list - which tagged VLANs the port will accept and forward.

A frame arriving with an 802.1Q tag is classed by its VLAN ID; a frame arriving untagged is classed as native. On egress, only the native VLAN leaves untagged; every other permitted VLAN leaves with a tag. This is the same model Cisco calls "native VLAN" and Comware calls "port trunk pvid", so the concept is portable even when the CLI is not.

Configuring Native VLAN and Allowed List

The classic example from the Aruba documentation - native VLAN 1, allowed VLANs 10, 30, 50:

Aruba-CX(config)# interface 1/1/1
Aruba-CX(config-if)# vlan trunk native 1
Aruba-CX(config-if)# vlan trunk allowed 10,30,50

Two details that cause most incidents:

• Untagged traffic is dropped unless the native VLAN is in the allowed list. With vlan trunk allowed 10,30,50 and native 1, untagged traffic is dropped because VLAN 1 is not allowed on the trunk. Either include the native VLAN in the allowed list, or change the native VLAN:

Aruba-CX(config-if)# vlan trunk native 5
Aruba-CX(config-if)# vlan trunk allowed 5,10,30,50

• Native VLAN must match on both ends. Two trunks with different native VLANs will exchange tagged frames correctly but silently misplace untagged frames (and often break spanning-tree BPDU handling).

How to tell whether untagged traffic is dropped

On a CX trunk the native VLAN behaves like a membership test, not a fallback. If the native VLAN is not a member of the allowed list, untagged frames that arrive are discarded and are counted as drops rather than forwarded into a default VLAN. That is why a CX trunk built as native 1 plus allowed 10,30,50 differs from the equivalent ProVision build, where "untagged 1" plus "tagged 10,30,50" would forward untagged frames into VLAN 1.

Aruba-CX(config-if)# vlan trunk native 1     ! classify untagged frames into VLAN 1
Aruba-CX(config-if)# vlan trunk allowed all  ! permit all tagged, native included
Aruba-CX(config-if)# vlan trunk allowed 10,30,50,1   ! explicit and reviewable

Prefer the explicit list in production: allowed all is convenient on a lab link but hands any future VLAN an unintended path. For the full port-mode picture, including the access-port case, see our ArubaOS-CX access vs trunk port modes guide.

Symptoms of a Native VLAN Mismatch

A native VLAN mismatch is one of the few faults that leaves tagged traffic completely healthy, which makes it easy to misdiagnose:

• Ping and application traffic between tagged devices on the same VLAN works normally across the trunk.
• Untagged service traffic fails - a client in the native VLAN on one side cannot reach a device in the native VLAN on the other side of the trunk.
• Management addresses on the untagged VLAN become unreachable while management on a tagged VLAN still responds.
• Spanning tree may log a topology change or a root-port flap, because BPDUs on the two sides are being classified into different VLANs.
• LLDP or CDP neighbour entries may disappear on one side even though the physical link is up.

The last two symptoms are the tell: if the link is up, tagged traffic flows, and yet the topology keeps churning, look at the native VLAN on both ends before looking anywhere else.

Command Mapping: PVOS and Comware Engineers

ProVision's model is "tagged vs untagged" per VLAN; Comware's is "link-type + pvid + permit"; CX collapses both into the interface-level vlan trunk native/allowed pair. The practical consequence is that a ProVision trunk migrates cleanly to CX only if you remember to add the untagged VLAN to the allowed list as well - the untagged keyword in ProVision implied membership; the CX native keyword does not.

Native VLAN, Spanning Tree and Control Frames

BPDUs, LLDP and CDP are transmitted untagged. On a CX trunk they therefore leave in the native VLAN and are received into the native VLAN of the far end. If the two ends disagree, the BPDUs are still seen on the wire but land in different VLANs, so each switch can believe it is the only one on that segment. The visible effect is often a spanning-tree topology change storm rather than a clean loop, plus duplicate MAC learning in the wrong VLAN.

If you deliberately want switch-to-switch control traffic to be tagged, tag the BPDU on the port rather than moving the native VLAN; and if you run LLDP for topology discovery, remember that lldp sends untagged frames by default, so a native VLAN mismatch also breaks the topology map. Our ArubaOS-CX LLDP transmit and receive guide covers the LLDP side, and the access vs trunk scenario guide walks the LAG cases.

Voice VLAN, Untagged Clients and Edge Ports

On access ports, the untagged/native behaviour is what makes a phone-plus-PC setup possible: the phone tags its voice traffic and forwards the PC's untagged frames, which must land in the data VLAN. If you move that port into a trunk so a second VLAN can be carried, the port's native VLAN must be set to the data VLAN, or the PC silently loses connectivity while the phone keeps working. This is the same native-VLAN rule as above, applied at the edge - and it is the reason so many "the phone works but the PC does not" tickets end in a trunk configuration change.

Untagged traffic sources engineers forget

It is tempting to treat the native VLAN as a legacy concern, but a surprising amount of production traffic is untagged and rides it:

• Spanning-tree BPDUs, LLDP and CDP frames between switches.
• PXE and TFTP boot traffic from servers that image before any VLAN is configured.
• Wake-on-LAN magic packets, which are broadcast and untagged by definition.
• Some hypervisor and BMC management interfaces that ignore their assigned VLAN until an OS loads.
• Voice phones acting as a two-port switch, passing PC traffic untagged.
• Legacy building-management and industrial devices with fixed untagged behaviour.

Any one of these breaks the moment the native VLAN is missing from the allowed list on a single trunk in the path - and because the failure is per-VLAN, the rest of the network looks healthy.

Migrating a ProVision trunk to CX

The mechanical difference between the two CLIs produces a predictable migration mistake. In ProVision, "untagged vlan 20" both classifies untagged frames and makes VLAN 20 a member of the port, so a working ProVision trunk is usually a set of tagged VLANs plus one untagged VLAN. Translated line-by-line to CX, that becomes vlan trunk native 20 plus vlan trunk allowed 10,30 - which drops all untagged traffic, because VLAN 20 is no longer in the allowed list. The correct translation adds VLAN 20 to the allowed list:

! ProVision: tagged vlan 10,30  +  untagged vlan 20
! CX equivalent:
Aruba-CX(config-if)# vlan trunk native 20
Aruba-CX(config-if)# vlan trunk allowed 10,20,30

Run the same reasoning in reverse when migrating CX to Comware, where the port must also be set to link-type trunk before pvid and permit have any effect.

Verification

Aruba-CX# show vlan
Aruba-CX# show vlan id 10
Aruba-CX# show interfaces 1/1/1 vlan        ! native + allowed per interface
Aruba-CX# show running-config interface 1/1/1
Aruba-CX# show interface 1/1/1                 ! counters: drops, tagged/untagged

Read the interface VLAN output as a pair: the native VLAN and the allowed list are printed separately, and the native VLAN has to appear in the allowed list for untagged traffic to be forwarded. Then check the interface counters - a native VLAN mismatch tends to show as a rising drop counter on one side of the trunk while the other side counts normal tagged traffic.

Troubleshooting Checklist

1. Compare show interfaces <port> vlan on both ends of the trunk. Native VLANs equal? Allowed lists consistent?
2. Confirm the native VLAN exists - a native VLAN that was never created on the switch cannot forward.
3. Check that the native VLAN is in the allowed list on both ends.
4. Look for spanning-tree topology changes and missing LLDP neighbours, which point at the untagged control path.
5. Check interface counters for untagged drops.
6. For LAG members, remember the native VLAN is a per-port setting: apply the same values on every member or the LAG will not form.

If clients on the far side of a CX-to-CX or CX-to-third-party trunk cannot reach the network but tagged VLANs work, check the native VLAN on both ends first. For the wider VSX/HA picture (both switches acting as one gateway), see our VSX configuration guide, and the edge-hardening practices for access and trunk ports in the access vs trunk configuration guide. For a verification-driven walkthrough of the same commands, see ArubaOS-CX access vs trunk verification with show vlan.

原文链接：https://arubanetworking.hpe.com/techdocs/AOS-CX/10.13/HTML/l2_bridging_6300-6400/Content/Chp_vlans/com-vla-com-pvo-com-aos-cx..htm