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, with 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.

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).

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. HPE's own interoperability deck maps these side by side, and the full access/trunk comparison with LAG scenarios is covered in our access vs trunk scenario guide.

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

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.

原文链接：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