ArubaOS-CX Access vs Trunk Ports: Configuration Templates

An ArubaOS-CX port is either an access port carrying a single untagged VLAN to an endpoint, or a trunk port carrying multiple tagged VLANs to another switch. The commands are short, but the surrounding hardening — BPDU guard, edge port type, TCN guard, loop protection — is what turns a working lab port into a production-safe one. This article gives you two copy-ready templates for ArubaOS-CX, a comparison of the two modes, the verification sequence, and the VSX-specific detail that trips people up.

Access vs trunk at a glance

Note there is no switchport mode verb as in Cisco IOS — the mode is implied by which VLAN command you apply.

Access port template for an endpoint

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

Four lines do the real work: no routing keeps the port strictly Layer 2, spanning-tree port-type admin-edge removes the listening/learning delay and every network-wide topology change, spanning-tree bpdu-guard err-disables the port the moment someone bridges a switch in, and spanning-tree tcn-guard stops that endpoint from triggering TCNs. Add loop-protect where a user can physically loop two wall ports.

Trunk port template for a peer switch

interface 1/1/49
    no shutdown
    no routing
    mtu 9198
    flow-control rx
    description "Link-to-Remote-Switch"
    vlan trunk native 999 tag
    vlan trunk allowed 10,20,30,99
    spanning-tree link-type point-to-point
    exit

Three deliberate choices here. vlan trunk native 999 tag keeps native traffic tagged, so no untagged traffic crosses the link at all — the cleanest way to avoid native-VLAN mismatches with a non-Aruba peer, and it makes the allowed list trivially extensible. vlan trunk allowed 10,20,30,99 is an explicit list; vlan trunk allowed all leaks every VLAN you create later, including ones that should never leave the rack. spanning-tree link-type point-to-point is the correct default for a full-duplex switch-to-switch link.

If the far end permits tagged-only traffic, spanning-tree ignore-pvid-inconsistency enable is unnecessary. Keep it in the template only when you must interoperate with a peer that sends untagged native frames.

VSX and LAG interfaces

When the downlink is a VSX LAG or a standard LAG, apply the VLAN configuration to the LAG interface, not to the members. Members stay bare; the aggregation interface owns the VLAN configuration and the spanning-tree attributes. This is the same discipline as Arista and Cisco and prevents the classic half-configured bundle.

Verification commands

show vlan
show vlan 20
show interface 1/1/49 trunk
show running-config interface 1/1/49
show spanning-tree
show lacp interfaces

Work top to bottom when traffic does not flow: show vlan proves the VLAN exists and is up, show interface ... trunk proves the VLAN is in the allowed list and which VLAN is native, and show spanning-tree proves the port is forwarding rather than blocked.

Common mistakes

• Leaving VLAN 1 as the native VLAN on a trunk — the classic VLAN-hopping vector.
• Making the native VLAN tagged on one side and untagged on the other; traffic for that VLAN vanishes with no log.
• Configuring VLANs on LAG members instead of the LAG interface.
• Applying spanning-tree bpdu-guard to a trunk port — it err-disables the link as soon as a legitimate BPDU arrives.
• Forgetting no routing on a port that should be Layer 2, or conversely expecting a Layer 2 port to answer pings.

For the side-by-side command table and tagging variants, see ArubaOS-CX access port vs trunk port comparison table and access vs trunk tagging examples; for the control-plane side of the same platform see VSX active gateway configuration.

Interoperating with a third-party switch on a trunk

ArubaOS-CX to ArubaOS-CX is the easy case. When the far end is Cisco, Huawei or a server NIC team, three details decide whether the trunk works:

• Tagged-only native VLAN. Setting vlan trunk native 999 tag means no untagged frames cross the link, so the peer's native-VLAN setting becomes irrelevant. This is the least fragile way to connect to a platform whose default native VLAN you cannot guarantee.
• Explicit allowed list on both ends. A VLAN allowed on one side and absent on the other forwards nothing in that VLAN and produces no log entry on either switch.
• Untagged management traffic. If the peer expects its management VLAN untagged, do not set the native VLAN to tagged — pick one convention per link and document it.

Diagnosing a port that carries no traffic

1. show interface 1/1/49 — is the port up/up and at the expected speed?
2. show interface 1/1/49 trunk — is the VLAN you need in the allowed list, and is the native VLAN what you think?
3. show vlan — does the VLAN exist and is it up? A VLAN created on one switch only is a silent black hole.
4. show spanning-tree — is the port forwarding rather than blocking or in a loop-protect disabled state?
5. show lacp interfaces — if the link is a LAG, is every member bundled (status up) rather than individual?
6. show mac address-table interface 1/1/49 — are MACs learning on the port at all? Nothing at all points above Layer 2.

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