ArubaOS-CX Edge Port Hardening: Access and Trunk Templates

2026年9月2日 LOG admin

Configuring an ArubaOS-CX port as access or trunk is only half the job - in production the same interface needs spanning-tree and loop-protection hardening so a misbehaving edge device cannot take down the fabric. Based on the configuration patterns validated by Aruba engineers on Airheads, this article presents ready-to-use templates for access ports (hosts, APs, IP phones) and trunk ports (peer switches), with every hardening command explained.

Access Port Template for Edge Hosts

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

Three spanning-tree settings do the heavy lifting on access ports:

spanning-tree bpdu-guard - disables the interface if it receives any STP BPDU, catching rogue switches plugged into host ports.
spanning-tree port-type admin-edge - makes the port transition to forwarding immediately instead of waiting through STP timers.
spanning-tree tcn-guard - stops topology change notifications from this port propagating to the rest of the network.

loop-protect additionally shuts the port (default action tx-rx-disable) when it detects a loop from the connected device.

Two lines in that template are easy to overlook. no routing is the ArubaOS-CX way of declaring that the port belongs to L2 only; without it, the interface can carry both routed and switched traffic depending on the rest of the configuration, which makes troubleshooting ambiguous. mtu 9198 sets the interface MTU high enough for jumbo frames, which is the correct default on a switch that may later carry storage or hypervisor traffic - it costs nothing on edge ports and saves a maintenance window later.

Trunk Port Template for Peer Switches

interface 1/1/2
    no shutdown
    no routing
    description Link-to-Remote-Switch
    vlan trunk native 100 tag
    vlan trunk allowed 100
    spanning-tree link-type point-to-point
    spanning-tree ignore-pvid-inconsistency enable
exit

Key decisions on trunks:

vlan trunk native 100 tag - tagging the native VLAN means no untagged traffic crosses the link at all, which prevents VLAN leaking between peers. The far end must send only tagged frames.
vlan trunk allowed - list exactly the VLANs permitted rather than using allowed all; you can always add more later.
spanning-tree link-type point-to-point - for full-duplex switch-to-switch links, avoids unnecessary STP delays.

spanning-tree ignore-pvid-inconsistency enable deserves a note of its own. In an 802.1Q network, a port that receives a tagged frame whose VLAN ID equals the port's native VLAN would normally be dropped to protect against a misconfiguration. On a deliberate, fully-tagged peer link that protection is unnecessary, and leaving it enabled produces a port that silently discards part of its traffic. Enabling the ignore statement is safe here precisely because the native VLAN is tagged - there is no untagged domain left to confuse.

Global Prerequisites Before the Templates Work

The per-port statements above assume several global settings are in place. On ArubaOS-CX these are not enabled by default in every firmware train, and a missing global setting produces a port that looks correctly configured but does not behave as intended.

spanning-tree
spanning-tree config-name CORP-STP
spanning-tree config-revision 1
spanning-tree priority 4
loop-protect
loop-protect action tx-rx-disable
loop-protect re-enable-timer 300
loop-protect transmit-interval 5
interface 1/1/1
    loop-protect
exit

Three things to verify. First, spanning-tree must be enabled globally - the per-interface settings are inert otherwise. Second, loop-protect is a separate protocol from spanning tree and must be enabled globally with an explicit action and re-enable timer; the default action is tx-rx-disable, which shuts the port down rather than merely suppressing transmission, and the re-enable timer controls how long the port stays down before the switch retries. Third, if you run multiple switches, a consistent config-name and config-revision is what keeps all switches in the same spanning-tree region and prevents unexpected topology churn.

Template Variants: AP, IP Phone and Server Ports

Not every edge port should look the same. Wireless access points, IP phones and virtualisation hosts each need slightly different handling.

# Access point port: untagged management VLAN, PoE budget explicit
interface 1/1/5
    no shutdown
    description AP-Ceiling-3F
    no routing
    vlan access 200
    poe priority critical
    spanning-tree bpdu-guard
    spanning-tree port-type admin-edge
exit

# IP phone with a daisy-chained PC: tagged voice VLAN, untagged data VLAN
interface 1/1/6
    no shutdown
    description Phone-Finance-Desk-12
    no routing
    vlan trunk native 300
    vlan trunk allowed 300,400
    voice vlan 400
    spanning-tree bpdu-guard
    spanning-tree port-type admin-edge
exit

# Virtualisation host: LACP bundle, trunk with tagged NVGRE/storage VLANs
interface 1/1/10
    no shutdown
    description ESXi-Host-07
    no routing
    vlan trunk native 350 tag
    vlan trunk allowed 350,360,370
    spanning-tree port-type admin-edge
exit
interface lag 10
    no shutdown
    description LAG-ESXi-Host-07
    lacp mode active
    vlan trunk native 350 tag
    vlan trunk allowed 350,360,370
exit

Two conventions are worth adopting. On access point ports, set the PoE priority explicitly - the default may leave a camera or phone fighting your AP for the last watts in a closet where the power budget is tight. On phone ports that daisy-chain a workstation, use tagged voice traffic rather than an untagged voice VLAN; the latter requires the phone to strip the tag before forwarding data frames, and a misconfigured phone then floods your data VLAN with voice traffic.

LACP Uplink Trunk Template

interface 1/1/20
    no shutdown
    description To-Core-A
    no routing
    lag 20
    spanning-tree link-type point-to-point
exit
interface 1/1/21
    no shutdown
    description To-Core-B
    no routing
    lag 20
    spanning-tree link-type point-to-point
exit
interface lag 20
    no shutdown
    description Core-Uplink-Bundle
    lacp mode active
    lacp rate fast
    lacp fallback
    vlan trunk native 1 tag
    vlan trunk allowed 10,20,30,100-110
    spanning-tree link-type point-to-point
exit

Keep VLAN membership and hardening on the LAG, not on the individual member ports - configuration applied to a member port is not inherited, and duplication is how the two ends of a bundle drift apart. lacp rate fast reduces failure detection from 30 seconds to roughly one second, which matters on an uplink that carries a whole closet's traffic. lacp fallback keeps the member links in a forwarding state if LACP negotiation fails entirely, which is a deliberate trade-off: it prevents a total outage when the peer is misconfigured, at the cost of losing loop detection, so only enable it where you have spanning tree or loop-protect as the secondary guard.

Choosing Between BPDU Guard, Root Guard and Loop Protect

Feature	Protects against	Action on trigger	Where to use
spanning-tree bpdu-guard	Rogue switch or bridge on an edge port	Port goes down (err-disable style)	Every host, AP and phone port
spanning-tree root-guard	A downstream switch becoming root	Port is blocked, STP continues	Ports facing access switches you do not control
loop-protect	A Layer 2 loop through a device that does not speak STP	Port transmits suppressed or shut, then retries	Edge ports on switches where STP may be bypassed
spanning-tree tcn-guard	Topology change notifications from edge ports	TCN ignored	Access ports only

The reason to run BPDU guard and loop protect together is that they detect different faults. BPDU guard catches a device that participates in spanning tree when it should not; loop protect catches a device that does not participate but still forwards frames in a loop - a cheap unmanaged switch, a miswired patch, or a virtualised appliance bridging two uplinks. Neither replaces the other, and on a port where you enable BPDU guard, a violation takes the port down until it is manually re-enabled or configured with an auto-recovery timer.

Verifying the Configuration

show interface 1/1/1
show interface 1/1/1 extended
show spanning-tree
show spanning-tree interface 1/1/1
show loop-protect
show loop-protect interface 1/1/1
show vlan
show vlan 100
show lacp aggregates
show lacp interfaces
show poe interface 1/1/5
show running-config interface 1/1/1

Verify in this order: physical state first (show interface), then L2 membership (show vlan), then STP role and state, then the protection features. A port that is up and in the correct VLAN but showing a disabled loop-protect state tells you a loop event occurred and the port is waiting out its re-enable timer - which is exactly the information you want before you re-enable it manually.

Common Mistakes and Their Symptoms

Mistake	Symptom	Fix
spanning-tree not enabled globally	Per-port STP settings have no effect; loops not detected	Enable `spanning-tree` globally, then re-check port roles
Native VLAN left untagged on a peer link	Untagged traffic leaks between VLAN 1 domains at both ends	`vlan trunk native <id> tag` and configure the peer identically
Using `vlan trunk allowed all`	Unintended VLANs reach every switch; broadcast domains grow silently	List VLANs explicitly, add ranges as needed
VLAN config on member ports instead of the LAG	Bundle members carry different VLANs; traffic black-holes intermittently	Move all L2 config to the LAG interface
BPDU guard on a port facing another switch	Uplink drops whenever the far switch sends its first BPDU	Use loop protect or root guard instead, or remove BPDU guard

Change Control and Rollback

Hardening commands are the ones most likely to cause an immediate outage, because a protection feature by definition shuts something down when it triggers. Two practices reduce the risk. First, apply port templates during a window and verify with show spanning-tree interface immediately after, rather than trusting that the configuration took effect. Second, checkpoint before the change: ArubaOS-CX supports configuration checkpoints and rollback, so capture one before you touch a live trunk uplink.

checkpoint auto pre-hardening
show checkpoint
copy checkpoint pre-hardening running-config
write memory

Note the final line. ArubaOS-CX applies configuration immediately but writes a separate startup configuration - the same model as Cisco IOS and Huawei VRP. A change that works in the running configuration but is never saved disappears at the next reload, and if that reload is a planned power event, the hardening you applied last month is gone.

Design Notes from the Airheads Discussion

Aruba engineers generally agree that preferring tagged-only traffic on inter-switch trunks is the safest default - it guarantees future VLANs can be added without negotiating untagged behavior - and that keeping VLAN 1 out of the allowed list (or handling it explicitly) avoids surprises. Global prerequisites matter too: spanning-tree must be enabled on the switch, and loop-protect actions and re-enable timers are configured globally before the per-port settings take effect.

A second theme in the same discussion is consistency of intent between the two ends of a link. ArubaOS-CX will happily let you configure one side tagged and the other untagged, and the resulting failure is partial rather than total, which makes it expensive to diagnose. Writing the access and trunk templates down, applying them from automation where possible, and verifying both ends with the same show commands is what turns a good template into a reliable network.