ArubaOS-CX Access/Trunk Interface Best Practices

Getting edge and uplink interfaces right on HPE Aruba CX switches is one of those details that separates a stable network from one that produces mysterious outages at 2 a.m. This article distills the community-validated ArubaOS-CX access/trunk interface configuration good practices into ready-to-use templates, covering VLAN tagging decisions, loop protection and spanning-tree hardening for both host-facing and switch-facing ports.

Access Interface Template for ArubaOS-CX

For an edge port connecting a host, the recommended configuration disables routing, sets a jumbo-friendly MTU and enables loop protection plus BPDU guard so a rogue cable or switch on the edge cannot take down the VLAN:

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

BPDU guard disables interfaces that receive unexpected STP BPDUs, while port-type admin-edge moves the port to forwarding immediately, avoiding the 30-second spanning-tree delay for legitimate end hosts.

Three of those lines deserve a comment each. no routing removes the routed interface capability, which matters on platforms where an interface can be both switchport and routable; being explicit prevents a future operator from accidentally giving the edge port an IP address. mtu 9198 is the ArubaOS-CX jumbo-frame template value and must match end to end — a mismatch between 9198 and the default 1500 does not break small pings, it breaks large storage frames later, during a backup window. tcn-guard stops a topology-change notification from a flapping edge port from flushing the MAC table across the whole VLAN, which is the difference between one slow host and a two-second outage for everyone.

On ports that take a single host, also consider an explicit speed and duplex, and a port description that names the device rather than the patch panel port. Descriptions such as Link-to-Edge-Host age badly; SRV-PAYROLL-01 eth0 still tells a responder something useful three years later.

Trunk Interface Template for Peer Switches

For a trunk to a third-party switch, tag the native VLAN explicitly and restrict the allowed list to only the VLANs that must traverse the link. An explicit allow list prevents a newly created VLAN from leaking across the whole network:

interface 1/1/24
  no shutdown
  no routing
  mtu 9198
  description "Link-to-Remote-Switch"
  vlan trunk native 10 tag
  vlan trunk allowed 10,20,30
  spanning-tree link-type point-to-point
  spanning-tree ignore-pvid-inconsistency enable
  exit

The tag keyword is the important one: it tells ArubaOS-CX to send the native VLAN tagged, so the link carries no untagged traffic at all. The ignore-pvid-inconsistency statement prevents an STP port from being blocked purely because the two sides disagree about the PVID, which is a common consequence of intentionally tagging the native VLAN.

Note that vlan trunk allowed replaces the entire list, exactly as it does on most modern platforms, and the allowed list can be written as ranges and comma-separated groups: vlan trunk allowed 10,20,30-35 is valid, as is vlan trunk allowed all — which you should treat as a deliberate design decision rather than a default. On a fabric uplink carrying hundreds of VLANs, all is normal; on a link to a partner or a security appliance, it is a leak waiting to happen.

Native VLAN Tagging: A Matter of Policy

Whether the native VLAN is tagged or untagged is ultimately a design preference, but tagging it is the safer default: it guarantees no untagged traffic flows on the trunk, which makes future VLAN additions simpler and avoids interop surprises with peers that expect fully tagged links. Keep the allowed list as tight as the business requires.

When you do tag the native VLAN, pick a value that no host actually uses — a dedicated transit VLAN such as 999 fits that role well — and configure the same value on both ends. The classic failure mode is a trunk where one side tags the native VLAN and the other does not; the link comes up, most traffic passes, and only the untagged control protocols misbehave, which makes the fault look intermittent rather than misconfigured.

LAG and LACP Interfaces

Ports facing another switch in a bundle follow the same rules, with the VLAN configuration moved to the logical interface. On ArubaOS-CX you create the LAG first and then add members to it:

interface lag 10
  no shutdown
  no routing
  mtu 9198
  description "Uplink-to-Core"
  vlan trunk native 999 tag
  vlan trunk allowed 10,20,30
  lacp mode active
  lacp rate fast
  hash l3-src-dst
  exit
interface 1/1/49
  no shutdown
  lag 10
  exit
interface 1/1/50
  no shutdown
  lag 10
  exit

Put the VLAN and spanning-tree attributes on interface lag, never on the members — member interfaces inherit the LAG configuration, and a stray vlan access on a member is silently ignored or flagged as a mismatch depending on the platform generation. lacp rate fast exchanges PDUs every second instead of every thirty, which shortens failure detection dramatically on links you care about. The hash l3-src-dst statement balances traffic using the Layer 3 address pair, which usually gives a better spread for routed flows than the default Layer 2 hash; for pure Layer 2 server traffic, hash l2-src-dst can be the better choice.

Global Settings That Make These Templates Work

The loop-protect and spanning-tree statements depend on global configuration: spanning-tree must be enabled, and loop-protect uses the default tx-rx-disable action with a re-enable-timer (e.g. 3600 seconds) so a recovered port comes back automatically. Integrate these templates into your ArubaOS-CX REST API automation flow, and see AOS-CX Central onboarding for fleet deployment.

spanning-tree
spanning-tree mode mstp
loop-protect
loop-protect re-enable-timer 3600
loop-protect action tx-rx-disable
interface 1/1/1
  loop-protect
  exit

Two details about loop protection are worth memorising. The global loop-protect command enables the feature but does nothing until it is applied on an interface. And the tx-rx-disable action suppresses both transmission and reception on the port while it is in the loop-protected state, which is what you want on an edge port that may have been accidentally patched into another wall socket. If your policy is to block only the offending direction, change the action deliberately and document it — the default protects the whole VLAN.

Verifying Interface Configuration

show interface 1/1/1
show interface 1/1/1 brief
show vlan
show vlan 10
show spanning-tree interface 1/1/1
show loop-protect
show running-config interface 1/1/1
show lacp interfaces
show interface lag 10

The fastest sanity check on an access port is show interface 1/1/1 brief, which reports link state and access VLAN on one line, followed by show vlan 10 to confirm the port appears in the member list for the intended VLAN. For trunks, show interface 1/1/24 prints the mode, the native VLAN and whether it is tagged or untagged, and the allowed list — reading those four values against the design document catches almost every trunk misconfiguration before it becomes an incident. On bundles, show lacp interfaces surfaces the actor and partner state per member, which is how you spot a link stuck in a negotiating or suspended state.

Common Mistakes and How They Present

• VLAN on the LAG member instead of the LAG: the bundle comes up but some VLANs are missing, because the member configuration is not what forwards traffic.
• Untagged native VLAN on one side only: intermittent control-plane weirdness rather than a clean outage.
• MTU mismatch: everything works until a large frame hits the link, then a single application stalls.
• Missing global loop-protect: the interface statement is accepted but the feature is inert.
• BPDU guard on an inter-switch port: the port err-disables seconds after the link comes up — correct behaviour, wrong design.

Bulk Changes with Interface Ranges

Applying a template to twenty-four access ports one at a time is how configuration drift starts. ArubaOS-CX accepts a range on the interface command, so the same template can be applied in a single transaction:

interface 1/1/1-1/1/24
  no shutdown
  no routing
  mtu 9198
  vlan access 10
  loop-protect
  spanning-tree bpdu-guard
  spanning-tree port-type admin-edge
  spanning-tree tcn-guard
  exit

Two cautions apply. A range command sends every line to every member, so a description inside a range gives all twenty-four ports the same label — set descriptions individually. And BPDU guard inside a range that accidentally includes an uplink will disable that uplink seconds after the change, so read the range twice before pressing enter. Applying the range inside a maintenance window, with show interface brief open in a second session, is cheap insurance.

PoE and Wireless Access Ports

An access port that powers a wireless access point follows the same hardening template, with one difference in intent: the AP normally needs a management VLAN plus one or more user VLANs, so the port becomes a trunk with an untagged native VLAN carrying management traffic. The rest applies unchanged, and matters more here because an AP rebooting under PoE looks like a link flap to spanning-tree until the guards absorb it.

Why the Templates Are Shaped This Way

Every line in these templates answers a failure that has cost somebody a night's sleep. BPDU guard exists because a lab switch brought in to "just test something" once bridged two access VLANs into a forwarding loop. Loop protection exists because a patch cable between two wall sockets created a loop that spanning-tree never saw, since no BPDUs were ever involved. TCN guard exists because a flapping edge port used to flush the MAC table every couple of seconds. Explicit allowed lists exist because a forgotten lab VLAN once leaked across an entire campus. None of it is glamorous, and all of it is what separates a design document from a network that survives Tuesday afternoon.

Uplink Design Notes

Switches facing switches deserve a different reading of the same rules. BPDU guard must be absent, the port becomes a point-to-point link, and the allowed VLAN list should be exactly the transit list agreed with the peer. Where the uplink is a bundle, remember that the logical interface is what the peer sees: the partner switch computes its spanning-tree topology against the LAG, not against the individual members, so a per-member change that looks harmless locally can alter the topology on the far side. Keep an updated diagram of which LAG terminates where, and treat any change to an uplink bundle as a design change rather than a routine edit.

Related: access versus trunk port modes with configuration examples, and building EVPN-VXLAN fabrics on Aruba.

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