ArubaOS-CX MSTP Configuration and Verification

ArubaOS-CX runs RSTP by default, which is fine until you need per-VLAN load balancing or a deterministic root bridge design. Multiple Spanning Tree (MSTP, IEEE 802.1s) solves both: multiple VLANs share one instance, and each instance can have a different root, so half your VLANs can prefer one uplink and half the other. This article covers the complete configuration sequence on AOS-CX — region parameters first, then instance mapping, then root placement and edge hardening — plus the verification commands that show whether switches actually landed in the same region. The classic single-uplink alternative is covered in ArubaOS-CX loop protect if you are not ready to move to MSTP.

MSTP concepts that decide your design

An MST region is a group of switches sharing three identical attributes: configuration name, revision number, and the VLAN-to-instance mapping table. Any mismatch means the switches are in different regions and only the Common Spanning Tree (CST) interoperates between them — which silently removes your load balancing.

Instance 0 is always the CIST (Common and Internal Spanning Tree) and is mandatory. All unassigned VLANs fall into instance 0, so leaving hundreds of VLANs unmapped concentrates all traffic on one topology.

Prerequisites

ArubaOS-CX 6400 / 8320 / 8325 / 8400 running 10.10+
VLANs created before they are mapped to an instance
All switches that must share an instance configured identically for
  spanning-tree config-name / config-revision / instance-vlan mapping

Step 1 — Create the region

switch# configure terminal
switch(config)# spanning-tree config-name HQ-CORE
switch(config)# spanning-tree config-revision 1
switch(config)# spanning-tree config-name      ! verify
switch(config)# spanning-tree config-revision  ! verify

The name is case-sensitive and is embedded in every BPDU. A single character difference creates a new region, so drive all switches from one source of truth — Jinja2 templating is the usual answer (see Ansible Jinja2 templating for network configs).

Step 2 — Map VLANs to instances

switch(config)# vlan 10-11,20-21
switch(config)# spanning-tree
switch(config)# spanning-tree instance 1 vlan 10-11
switch(config)# spanning-tree instance 2 vlan 20-21
switch(config)# spanning-tree instance 1 priority 0     ! root for inst 1
switch(config)# spanning-tree instance 2 priority 1     ! secondary root for inst 2
switch(config)# spanning-tree priority 1                ! CIST secondary

Priority is a multiple of 4096. Lower wins. The conventional design is a pair of core switches where each is root for one instance and secondary root for the other, giving per-VLAN load sharing with full redundancy.

Step 3 — Root and secondary root on the paired core

CORE-A:  spanning-tree instance 1 priority 0
         spanning-tree instance 2 priority 1
CORE-B:  spanning-tree instance 1 priority 1
         spanning-tree instance 2 priority 0

Step 4 — Harden the access edge

switch(config)# interface 1/1/1
switch(config-if)# spanning-tree admin-edge-port     ! host-facing port
switch(config-if)# spanning-tree bpdu-guard          ! shut on unexpected BPDU
switch(config-if)# spanning-tree loop-guard          ! protection on uplinks
switch(config-if)# spanning-tree root-guard          ! deny superior BPDU in

The four protections are complementary: admin-edge-port gives instant forwarding for hosts, bpdu-guard shuts a port if a switch or loop is plugged into it, loop-guard prevents a blocked uplink from becoming inconsistent, and root-guard stops a lab switch from stealing the root role.

Verification

show spanning-tree mst-config          ! name, revision, VLAN mapping
show spanning-tree summary root        ! who is root for each instance
show spanning-tree mst                 ! per-instance port roles and states
show spanning-tree detail              ! BPDU counters, TCN count
show spanning-tree interface 1/1/1

show spanning-tree summary root is the fastest sanity check: if two switches in the same region both claim to be root for instance 1, region parameters differ or a priority was mistyped.

Troubleshooting

Symptom                          Likely cause
Load balancing does not work      Region mismatch (name/revision/mapping)
Unexpected blocked port           Root priority lower than intended
Access port goes err-disabled     BPDU received on an admin-edge-port (bpdu-guard)
Loop after uplink failure         loop-guard not enabled on the uplink
Frequent TCN                      Flapping edge port without admin-edge-port

FAQ

Q: Is MSTP required for a VSX pair? No — VSX LAGs forward on both peers and STP stays out of the way, but MSTP is still worth configuring for the orphan-port and access-layer topology. See ArubaOS-CX VSF stacking if you are running a stack instead of VSX.
Q: How many instances are supported? 64 MSTIs plus instance 0 on current AOS-CX platforms.
Q: Can I migrate from RSTP without an outage? Configure the region parameters during a maintenance window; changing config-name on a live network recreates the region and triggers reconvergence.

原文链接：https://arubanetworking.hpe.com/techdocs/AOS-CX/10.17/HTML/l2_bridging_8400/Content/Chp_stp/mst.htm