ArubaOS-CX Access vs Trunk: Best Practice Templates

ArubaOS-CX switches use two distinct port modes: access ports carry a single untagged VLAN for end hosts, while trunk ports carry multiple tagged VLANs for peer switches, firewalls and hypervisors. The Aruba Airheads community has distilled the common configuration practice for both roles, including the spanning-tree guards that protect edge ports and the native VLAN tagging decision that trips up many engineers. This article turns those best practices into ready-to-use CLI templates.

What follows keeps those two templates intact, then builds the surrounding operational knowledge: what each command actually does, how the guards interact with Spanning Tree, which mistakes show up repeatedly in the field, how to verify the result from the switch itself, and how to reset a port that has accumulated eight years of well-meaning edits.

Access vs Trunk on ArubaOS-CX

The distinction is not cosmetic. ArubaOS-CX interfaces are routed by default, so an interface without no routing behaves as a Layer 3 port and silently ignores every vlan sub-command you type at it. Similarly, a port left with no vlan access statement sits in VLAN 1, which is exactly the state that produces "the port is up but the host has no connectivity" tickets.

Why Port Mode Discipline Matters

An access port connects exactly one VLAN to one device, and the switch enforces that with an implicit ingress rule: untagged frames arriving on the port are classified into the access VLAN, and any tagged frame is dropped (or, on some releases, accepted only if the tag matches). A trunk port is the opposite arrangement — it expects tagged frames and classifies them by the dot1q tag, with the option of one untagged "native" VLAN for backward compatibility.

Three consequences follow, and they explain most real-world incidents:

• An access port and a trunk port cannot be reasoned about the same way. Tagging the native VLAN on a trunk makes the link behave like a pure 802.1Q trunk, which removes an entire class of ambiguity.
• Every VLAN you carry must be explicitly allowed. VLANs are not propagated along a trunk chain by themselves; on ArubaOS-CX the allowed list is explicit and defaults to VLAN 1 only.
• Edge ports need protection. BPDU guard, admin-edge and TCN guard are the difference between a user who plugs a home router into a wall socket and a campus-wide spanning-tree reconvergence.

Access Port Configuration Template

interface 1/1/<n>
no shutdown
mtu 9198
description "Link-to-Edge-Host"
no routing
vlan access <vlan-id>
loop-protect
spanning-tree bpdu-guard
spanning-tree port-type admin-edge
spanning-tree tcn-guard
exit

• no routing — puts the interface in Layer 2 mode; without it, the VLAN statements are accepted but never take effect
• vlan access <vlan-id> — sets the port's PVID to the access VLAN, so untagged frames from the host are classified there and return traffic leaves untagged
• mtu 9198 — enables jumbo frames on the port; keep it identical on both ends of any path that carries jumbo traffic
• loop-protect — sends loop-protect frames and shuts the port down rather than permitting a physical loop between two edge ports
• spanning-tree bpdu-guard - disables the interface if it receives MSTP BPDUs
• spanning-tree port-type admin-edge - transitions directly to forwarding during STP establishment
• spanning-tree tcn-guard - stops topology change notifications propagating to peer devices

The three STP statements work as a set and are worth reading together. admin-edge trusts that nothing with a bridge inside will ever connect, so the port can skip listening and learning and forward within milliseconds. BPDU guard is the safety net for that trust: if a BPDU does appear, the port goes into an error-disabled state instead of joining the topology. TCN guard stops the edge port from generating topology change notifications when it flaps, which prevents a single user's link state from flushing MAC tables across the whole spanning tree.

Trunk Port Configuration Template

interface 1/1/<n>
no shutdown
no routing
mtu 9198
flow-control rx
description "Link-to-Remote-Switch"
vlan trunk native <vlan-id> tag
vlan trunk allowed <vlan-id>
spanning-tree link-type point-to-point
spanning-tree ignore-pvid-inconsistency enable
exit

• vlan trunk native <vlan-id> tag - tags the native VLAN (recommended when the peer expects tagged-only traffic)
• vlan trunk allowed <vlan-id> - permits exactly the listed VLANs; use vlan trunk allowed all to allow all
• spanning-tree link-type point-to-point - assumes a full-duplex point-to-point link to a switch (default)
• spanning-tree ignore-pvid-inconsistency enable — suppresses the MSTP PVID-inconsistency check on the port, useful on trunks to third-party hardware whose native VLAN tag behaviour you do not control
• flow-control rx — lets the switch honour pause frames received from a peer; leave it off unless the peer actually sends them, or you risk head-of-line blocking

Native VLAN Tagging: The Key Decision

On a trunk connecting two ArubaOS-CX switches you can either tag the native VLAN (vlan trunk native <id> tag) or leave it untagged. Tagging the native VLAN is preferred when you control both ends, because it guarantees that only tagged traffic flows on the link and avoids pvid-inconsistency issues - you can add more tagged VLANs later without changing the native behavior. The peer interface must then be a tagged member of that VLAN.

The untagged-native alternative exists mainly for interoperation with devices that cannot tag their management VLAN. It is a genuine risk, not a style preference: an untagged native on one side and a tagged native on the other is the classic PVID mismatch, and it produces a link where the control VLAN is silently unreachable while user traffic keeps flowing. If you must run untagged native for compatibility, match the native VLAN number on both ends exactly and never leave the default of VLAN 1 on a production trunk.

Worked Example: Two Switches, VLANs 10, 20 and 99

Assume a distribution pair where VLAN 10 is user data, VLAN 20 is a server segment, and VLAN 99 is switch management. The uplink between the two switches is 1/1/49 on the access switch and 1/1/1 on the core.

! Access switch: uplink trunk
interface 1/1/49
    no shutdown
    no routing
    mtu 9198
    description "Uplink-to-Core"
    vlan trunk native 99 tag
    vlan trunk allowed 10,20,99
    spanning-tree link-type point-to-point
    exit
!
! Core switch: matching trunk
interface 1/1/1
    no shutdown
    no routing
    mtu 9198
    description "Downlink-to-Access"
    vlan trunk native 99 tag
    vlan trunk allowed 10,20,99
    spanning-tree link-type point-to-point
    exit
!
! End host on the access switch
interface 1/1/5
    no shutdown
    no routing
    description "Desk-1F-014"
    vlan access 10
    spanning-tree bpdu-guard
    spanning-tree port-type admin-edge
    spanning-tree tcn-guard
    exit

Note what is not configured: VLAN 20 is not present on the access switch's host-facing ports, and VLAN 99 never leaves the switches. Restricting the allowed list to the VLANs a link truly needs is the cheapest security control in a campus network — a VLAN that is not in the allowed list cannot be reached across that link even if an attacker spoofs its tag.

Local VLAN Configuration on the Switch

Before any interface can carry a VLAN, the VLAN itself must exist in the switch's VLAN database, and the ports must be members of it. ArubaOS-CX supports both interface-level and VLAN-level configuration, and the two views must agree.

vlan 10
    name USERS
    no shutdown
    exit
vlan 20
    name SERVERS
    no shutdown
    exit
vlan 99
    name MGMT
    no shutdown
    exit
!
! VLAN-level view of membership
vlan 10
    untagged 1/1/5-1/1/12
    tagged 1/1/49
    exit

Configuring membership from the interface context (vlan access, vlan trunk allowed) and from the VLAN context (untagged, tagged) both write the same state. Pick one convention per site and stick to it; mixing the two is how a port ends up untagged in a VLAN nobody remembers being a member of.

Verification Commands

show vlan
show vlan brief
show interface 1/1/1
show running-config interface 1/1/1

show vlan proves that the VLAN exists, shows its operational state and lists its member ports with the untagged/tagged role for each. show vlan brief gives the quick membership overview; show interface 1/1/1 confirms link state, speed, duplex and the current access or trunk mode, while show running-config interface 1/1/1 answers the question that matters most during a change review — what is actually configured on this port right now.

Three more commands are worth adding to the routine:

show interface 1/1/1 brief
show spanning-tree interface 1/1/1
show loop-protect

They confirm the port's administrative state, whether the STP role and guard state match your intent, and whether loop protection has tripped anywhere in the switch — the last of which is the fastest way to find the user who created a loop with an unmanaged switch under a desk.

Common Mistakes and How to Detect Them

Resetting a Port to a Known-Good State

When a port has drifted, editing individual lines is slower and riskier than returning it to a clean baseline and reapplying one of the templates above.

interface 1/1/5
    no vlan trunk allowed all
    no vlan trunk native
    no vlan access
    no spanning-tree bpdu-guard
    no spanning-tree tcn-guard
    no loop-protect
    routing
    exit

Note the final routing: on ArubaOS-CX this restores the interface to its Layer 3 default. From that clean state, apply the access or trunk template verbatim. Doing this during a maintenance window rather than live, and dumping show running-config interface 1/1/5 to a file first, means the rollback is a copy-paste rather than an investigation.

Design Notes for Access and Trunk Roles

• Define the VLAN list per link, not per switch. A trunk should carry the VLANs that must cross it, nothing more.
• Never run an untagged native VLAN on a production trunk without a documented reason. Tagging costs nothing and removes the PVID class of failure entirely.
• Use admin-edge plus BPDU guard on every host port, including ports that are currently unused but enabled. Unused edge ports without guards are the standard entry point for loop incidents.
• Keep MTU consistent end to end. Configuring 9198 on one side of an uplink and leaving 1500 on the other creates a path that works for web traffic and breaks for storage or backup traffic.
• For 802.1X and dynamic VLAN assignment, start from a host template that has the guards already applied; authentication changes the VLAN but should never change the edge protections.
• Document the pair of commands that define each port's role — vlan access or vlan trunk allowed — in your site documentation. Those two lines answer ninety percent of "why does this port behave like that" questions.

For more on VLAN behavior on the platform, see ArubaOS-CX access vs trunk native VLAN tagging, the Junos access, trunk and IRB examples, Cisco Nexus NX-OS VLAN and trunk configuration, and the companion verification walkthrough ArubaOS-CX access vs trunk: verify with show vlan.

原文链接：https://airheads.hpe.com/discussion/arubaos-cx-accesstrunk-interface-configuration-commongood-practices