I85PREP
⌘ K
Aruba ACSA study materials
Aruba ACSA study resources

MSTP Region Mismatch After a Switch Swap

Aruba ACSA · Put your knowledge to work in context.

All case studies

MSTP Region Mismatch After a Switch Swap

A distribution pair of ArubaOS-Switch 2930F units runs MSTP with region name "CAMPUS-A", revision 1, and instances 1 (VLANs 10-20) and 2 (VLANs 30-40). A failed access switch is replaced with a spare ArubaOS-CX 6100 configured by a junior engineer. After the swap, users on VLANs 30-40 report intermittent connectivity, and show spanning-tree on the 2930F shows the CX switch as the root for the CIST. The CX was configured with region name "CAMPUS-A", revision 1, and the same VLAN-to-instance mapping. The engineer insists the region configuration matches and blames a hardware fault.

1. The region name and revision match, yet behavior changed. What is the most likely explanation, and how would you confirm it?

Read the worked answer

Matching name and revision is necessary but not sufficient. MSTP region membership also requires an identical VLAN-to-instance mapping and, critically, the switches must actually interoperate as MSTP peers. Two common causes fit the symptoms:

  1. The CX is running a different STP mode. ArubaOS-CX defaults to MSTP, but if the junior engineer left RPVST+ or another mode enabled on the CX, the CX would not join the MST region and would present itself as a separate CIST root. Confirm with show spanning-tree / show spanning-tree summary on the CX to verify mode mstp and the region parameters as the switch sees them.
  2. Mapping mismatch in practice. The engineer may have mapped VLANs 30-40 to instance 2 on the 2930F but to a different instance (or to the CIST) on the CX. Even one VLAN in the wrong instance breaks the shared topology for that VLAN.

Confirm by comparing show spanning-tree mst-config (2930F) against the CX equivalent, and check the CX's CIST root and regional root. If the CX shows itself as CIST root while the 2930F pair should be root, the CX is not in the region. Also verify the CX is not configured with a lower bridge priority that legitimately makes it root - but the region-mismatch explanation fits the "intermittent on 30-40 only" symptom better than a priority accident.

2. What is the safe remediation sequence, and what should be verified before and after?

Read the worked answer

Remediation must be staged to avoid a spanning-tree reconvergence storm on a live access layer.

Before:

  • Capture the current topology on both sides (show spanning-tree, root and port roles per instance) so you can compare after.
  • Schedule a window; changing STP mode or region parameters causes reconvergence and brief outages.

Sequence:

  1. On the CX, set the STP mode to MSTP explicitly and confirm region name, revision, and the full VLAN-to-instance mapping match the 2930F pair exactly.
  2. Ensure the CX bridge priority is higher (numerically) than the distribution pair so the distribution remains root for the CIST and both instances - do not let an access switch become root.
  3. Bring the CX uplink up only after configuration is verified; if possible, pre-stage the config offline and apply before connecting.

After:

  • Verify the CX appears in the same region as the 2930F pair, that the distribution pair is CIST and regional root, and that VLANs 30-40 have a consistent forwarding topology.
  • Confirm user connectivity on 30-40 and check for MAC flapping or topology-change notifications.
  • Add the region/mode/mapping check to the spare-switch staging checklist so the next swap does not repeat this.