ArubaOS-CX Access vs Trunk Ports: Comparison and Configuration

Every ArubaOS-CX switch port must decide how it handles VLAN tagging: as an access port that carries a single untagged VLAN to an end device, or as a trunk port that carries multiple tagged VLANs between switches. Getting this decision wrong is one of the most common causes of "can't reach the server" tickets in campus networks. This article explains the access vs trunk distinction on AOS-CX, gives you a comparison table you can keep next to your desk, and shows the exact CLI commands to configure and verify both port types.

Access Port vs Trunk Port: The Difference

The underlying rule is simple and worth stating plainly: a frame leaving an access port has no VLAN tag, and a frame leaving a trunk port usually does. The switch keeps a per-port table that maps incoming untagged frames to a VLAN (the port's VLAN membership / PVID) and decides, on egress, whether to strip or preserve the tag.

Which Port Type Belongs Where: The Selection Matrix

Most real designs fall into one of the rows below. Pick the row that matches the device on the far end, and the port type follows automatically.

A useful heuristic: if the far-end device has no VLAN configuration of its own, use access; if it does, use trunk. The exception is a server where you intend the operating system to see tags - that is trunk, even if it is a single host.

Configuring an Access Port on AOS-CX

First create the VLAN, then assign the port:

switch(config)# vlan 10
switch(config-vlan-10)# name Sales
switch(config-vlan-10)# exit
switch(config)# interface 1/1/1
switch(config-if)# vlan access 10
switch(config-if)# no shutdown

Port 1/1/1 is now an access port in VLAN 10. End devices plugged in here get an untagged frame in VLAN 10 with no configuration on their side.

You can apply the same setting to a whole range in one shot, which is how you should build an access block of 24 or 48 ports:

switch(config)# interface 1/1/1-1/1/24
switch(config-if)# vlan access 10
switch(config-if)# no routing

The no routing line disables Layer 3 on the port and is good hygiene on an edge access block - it prevents an accidental ip address turning the port into a routed interface later.

Configuring a Trunk Port on AOS-CX

switch(config)# vlan 20
switch(config-vlan-20)# name Engineering
switch(config-vlan-20)# exit
switch(config)# interface 1/1/2
switch(config-if)# vlan trunk allowed 10,20
switch(config-if)# vlan trunk native 1

The trunk carries VLANs 10 and 20 tagged, and VLAN 1 untagged as the native VLAN. To make even the native VLAN tagged, add vlan trunk native tag. To restrict which VLANs can pass, use vlan trunk allowed explicitly - never leave a trunk allowing all VLANs unless you intend it.

switch(config-if)# vlan trunk allowed 10,20,30-40
switch(config-if)# vlan trunk allowed all
switch(config-if)# no vlan trunk allowed 99

Note that vlan trunk allowed is not additive in the sense people expect: issuing it replaces the allowed list. Always print the running configuration after editing a trunk, because a truncated range is invisible until a device in that VLAN goes silent.

Verification Commands

switch# show vlan
switch# show vlan 10
switch# show interface 1/1/1
switch# show running-config interface 1/1/1

show vlan shows each VLAN with its ports and tagging status; show interface 1/1/1 displays the operational state and the access/trunk assignment.

Two further checks deserve a place in every runbook:

switch# show vlan port 1/1/2
switch# show mac-address-table vlan 10
switch# show interface 1/1/2 trunk

show mac-address-table vlan 10 is the fastest way to prove that traffic is actually arriving on the VLAN you think - if the MAC is learned on the wrong port or not at all, the problem is tagging, not routing. A short verification workflow with expected outputs is documented in our ArubaOS-CX access vs trunk verification guide.

What Actually Happens to a Frame

Reading the frame-level behaviour once makes every future VLAN ticket easier. Consider an untagged frame arriving on a port:

The "frame arrives tagged on an access port" row is what makes an access port the safe choice at the edge. A device that tries to inject tags cannot reach another VLAN through an access port; on a trunk that is left wide open, it can.

Uplink Design: Single Trunk, LAG or VSX

Once you have decided that an uplink is a trunk, you still have to decide how many of them there are and how they are terminated:

• Single trunk - cheapest, simplest, and a single point of failure. Acceptable for a small closet switch that users can survive losing.
• LACP trunk (bonded uplink) - two or four links acting as one logical trunk with per-flow load balancing. The access switch's own VLANs are configured on the aggregation interface. Failure of one member is transparent to spanning tree, so reconvergence is instant.
• VSX pair with LAGs - two core switches share a virtual control plane, so an access closet can run one LAG whose members land on different physical switches. This is the standard AOS-CX campus design and is the only one of the three that survives a core node failure without an STP event.

Whichever you choose, keep the VLAN set identical on every member of the bundle and on both ends. An asymmetric allowed list on one member of a LAG produces the worst kind of intermittent fault: flows that hash onto the bad member fail while the rest of the traffic looks perfectly healthy.

When the Choice Is Not Obvious: Four Real Scenarios

1. Server VLAN trunking versus per-NIC access

A virtualisation host with ten VLANs can be cabled three ways: ten physical NICs each on an access port (simple, but ten ports per server and no redundancy per VLAN), one trunk carrying all ten VLANs (efficient, but a single point of failure unless bonded), or a LACP bond trunk (the standard answer). For the bonded variant, configure the aggregation first and then apply the trunk settings to the LAG interface, not to the individual members - member ports inherit the LAG configuration, and settings applied to a member are rejected or lost. A worked LAG example is in ArubaOS-CX access vs trunk with LAGs.

2. Access point with multiple SSIDs

A tunnel-mode AP needs only an access port because all client traffic is encapsulated back to the controller. A bridge-mode (or Aruba Instant / gateway-less) AP that maps an SSID directly onto a local VLAN needs a trunk with those VLANs allowed, plus a management VLAN. If only one SSID exists and it is bridged, an access port still works - which is why the same AP model appears on both rows of the matrix.

3. Cascading an unmanaged switch

Plugging a five-port unmanaged switch into a trunk port will flood every tagged VLAN to every port of that switch, and clients in the "wrong" VLAN will see traffic they should not. Always terminate unmanaged switches on an access port, and ideally apply port security or a MAC limit so one desk cannot become a mini distribution node.

4. Migrating from ProCurve / ProVision

Engineers arriving from ArubaOS-Switch look for untagged and tagged commands. AOS-CX replaces them: untagged 10 becomes vlan access 10, and tagged 10,20 becomes vlan trunk allowed 10,20 with vlan trunk native <id> controlling the untagged VLAN. The access/trunk interface best practices article includes a hardening template for both port types.

Decision Guide

• Plugging in a PC, server, IP camera or phone → access port.
• Uplink to another switch, router, or firewall → trunk port.
• Server with VLAN trunking (VMware, bare-metal with VLAN tags) → trunk port.
• Never put an end-user PC on a trunk - it can hop VLANs.

Five Mistakes That Cause Most Access/Trunk Tickets

1. Trunk with no allowed list. A port left at vlan trunk allowed all carries every VLAN, including ones with no business reaching that link.
2. Asymmetric allowed lists. Switch A allows VLAN 30, switch B does not. Traffic flows one way and silently dies on return.
3. Assuming the native VLAN is irrelevant. It is the single most common cause of "one VLAN works, the rest don't" - the untagged VLAN must match on both ends.
4. Applying trunk settings to LAG members. Configure the aggregation interface, then the trunk, never the reverse.
5. Not creating the VLAN. vlan trunk allowed 40 on a switch that has no VLAN 40 defined will not pass traffic; the allowance is a filter, not a creation.

Related Reading

See also ArubaOS-CX access/trunk interface best practices and Cisco VLAN configuration and verification workflow for the cross-vendor view. If you are chasing an untagged-traffic problem specifically, read the deep dive on native VLAN tagging behavior on AOS-CX.

原文链接：https://www.arubanetworks.com/techdocs/AOS-CX/10.07/HTML/5200-7762/Content/Chp_VLANs/vlan-over.htm