I85PREP
⌘ K
Aruba Switching Expert (Written) study materials
Aruba Switching Expert (Written) study resources

STP Root Placement in a Redundant Triangle

Aruba Switching Expert (Written) · Put your knowledge to work in context.

All case studies

STP Root Placement in a Redundant Triangle

Three distribution switches - D1, D2, D3 - are cabled in a triangle (D1-D2, D2-D3, D1-D3), all running RSTP with default priorities. D1 is the current root only because its base MAC is lowest. Access switches dual-home to D1 and D2. During a recent maintenance window, D1 was reloaded and the network reconverged with a 4-second outage on some access VLANs. The team wants deterministic behavior: D1 should always be root, D2 should be the designated backup, and D3 should never become root. They also want to know why a reload caused a multi-second outage despite RSTP.

1. Specify the STP priority configuration to make root election deterministic and explain the values.

Read the worked answer

Set explicit priorities so election never depends on MAC:

  • D1: spanning-tree priority 4096 (lowest → root).
  • D2: spanning-tree priority 8192 (second lowest → backup root).
  • D3: spanning-tree priority 61440 (highest allowed step below default, so it loses to both).

Priorities are in 4096 increments; 0 is discouraged (reserved/edge cases), 4096 is the practical lowest. With these values, D1 wins regardless of MAC, D2 takes over predictably if D1 fails, and D3 is effectively excluded. Verify with show spanning-tree that D1 is root and D2 shows D1 as root with itself as secondary.

2. Explain the likely cause of the 4-second outage on D1 reload and how to reduce it.

Read the worked answer

Several compounding factors are plausible; diagnose rather than assume:

  • Access ports without edge/PortFast: if access ports are not configured as edge, RSTP runs the proposal/agreement handshake and can briefly block on topology change. Enable spanning-tree portfast (edge) on host ports.
  • Topology change propagation: a root reload generates TC; without spanning-tree portfast on edge ports and without TC suppression, MAC tables flush and cause flooding/blackholing for seconds.
  • Non-RSTP neighbors or mismatched modes: if any link negotiated to legacy 802.1D behavior, convergence reverts to slow timers (listening/learning ~30s) - but 4s suggests RSTP with proposal delays or BPDU loss during reload.
  • Uplink LAG not used: dual-homed access without LAG can cause one leg to be blocking; on reconvergence the blocked leg must transition.

Reduce it by: edge ports on all host-facing interfaces, explicit root/backup priorities, LAGs on dual-homed access, and verifying all switches run the same RSTP mode. Measure with show spanning-tree detail TC counters and interface event logs to confirm the actual cause before changing timers.