ArubaOS-CX Access Port vs Trunk Port: Which to Use

ArubaOS-CX replaced the ProCurve habit of labelling ports tagged or untagged with two explicit modes - access and trunk - and then added a third state that trips up experienced engineers: a trunk port with a native VLAN that carries untagged frames. This article lays the two modes side by side, shows the configuration for each on a CX switch, and explains the verification commands that prove the switch is doing what the design intended rather than what the last paste left behind.

The two modes at a glance

Configuring an access port

switch# configure terminal
switch(config)# interface 1/1/5
switch(config-if)# no shutdown
switch(config-if)# no routing
switch(config-if)# vlan access 20
switch(config-if)# exit

On AOS-CX, no routing is what makes the port a Layer 2 port; the fail-safe default on many platforms is Layer 3 with routing enabled, and a port left in routing mode ignores vlan access entirely. That single line is the most common reason a "configured" access port still does not pass traffic in its VLAN.

Configuring a trunk port

switch(config)# interface 1/1/24
switch(config-if)# no shutdown
switch(config-if)# no routing
switch(config-if)# vlan trunk allowed 10,20,30
switch(config-if)# vlan trunk native 999
switch(config-if)# vlan trunk native 999 tag
switch(config-if)# exit

Three variants are worth memorising:

• vlan trunk allowed all carries every VLAN defined on the switch. Convenient in a lab, dangerous in production because a newly created VLAN is automatically allowed.
• vlan trunk native 999 sends untagged frames on VLAN 999 - the equivalent of Cisco's native VLAN.
• vlan trunk native 999 tag keeps VLAN 999 tagged as well, which is the setting to use when a hypervisor expects every VLAN on the link to be tagged, including the management one.

Voice and AP scenarios

A trunk is not required to carry a second VLAN to an IP phone. AOS-CX supports a voice VLAN on an access port, so the phone can send tagged voice traffic while the attached PC stays untagged on the data VLAN. The practical rule: use access mode for anything with a single untagged data flow, and reach for trunk mode only when the device needs to see multiple tagged VLANs itself.

Verifying what the port is really doing

switch# show vlan
switch# show vlan 20
switch# show interface 1/1/24
switch# show interface 1/1/24 trunk
switch# show running-config interface 1/1/24

show interface <port> trunk is the fastest single check: it prints the mode, the native VLAN and whether it is tagged, and the allowed VLAN list. If a port is meant to trunk and this output shows no mode, the port is still in its default state regardless of what the running configuration looks like elsewhere.

Common mistakes

• Configuring the access VLAN on a port that still has Layer 3 routing enabled.
• Setting the native VLAN to a value that differs between the two ends of the link, which silently merges two VLANs into one broadcast domain.
• Adding a port to a LAG while the physical member still holds its own VLAN configuration - the LAG configuration wins, and the leftovers confuse troubleshooting.
• Assuming vlan trunk allowed all is safe; a new VLAN with no uplink permission can create an unintended segmentation.

For deployment checklists and templates see our AOS-CX access and trunk port best practices and the native VLAN and untagged traffic guide. Engineers migrating from ProCurve terminology will find the mapping in the ArubaOS-Switch VLAN tagging and trunk CLI guide, and command equivalents for Cisco-trained staff are collected in the Cisco IOS to AOS-CX migration table. A Chinese-language version of this comparison is available as ArubaOS-CX Access 与 Trunk 端口对比.

原文链接：https://airheads.hpe.com/discussion/help-moving-from-old-procurve-switch-to-new-aruba-6300-arubaos-cx