A redundant uplink on an Aruba switch is discarding frames. Is that the expected backup path, or did a protection feature intervene? Start with the spanning-tree instance that carries the affected VLAN, then compare its root, port roles, and recent topology changes against your design.
This guide uses Aruba CX 6300 switches and the AOS-CX 10.16 command reference. All commands are read-only. Interface 1/1/49, VLAN 20, and LAG 10 are examples.
Why spanning tree matters
Ethernet switching has no Layer 2 hop count. If a broadcast or unknown unicast frame enters a switching loop, copies can circulate and multiply. The resulting congestion and MAC address movement can disrupt even devices far from the original cabling error. Spanning Tree Protocol (STP) exchanges Bridge Protocol Data Units (BPDUs), elects a root bridge, and keeps redundant paths available while maintaining a loop-free forwarding topology. A standby path can take over after an active path fails.
1. Identify the mode and affected instance
show spanning-tree
show vlan 20Record the configured STP mode and check that VLAN 20 is present on the intended links. With MSTP, identify the instance that contains VLAN 20. Several VLANs can share a single MST instance and therefore the same spanning-tree forwarding topology. With RPVST+, inspect VLAN 20 directly.
MSTP
show spanning-tree mst-config
show spanning-tree mst
show spanning-tree mst detailCompare the region name, revision, and VLAN-to-instance mapping on neighboring switches intended to share an MST region. A mismatch creates a region boundary, which may be intentional. If the boundary is unexpected, compare the configuration with the design before changing any mapping. Read the root address and root port in the affected instance. At an MST boundary, distinguish the root from the regional root when interpreting the output.
RPVST+
show spanning-tree vlan 20
show spanning-tree vlan 20 detailCompare the root ID and uplink roles for VLAN 20 on both switches. If VLAN 30 works over the same links, compare its root and roles as a control. A different root can be intentional when the design distributes traffic across uplinks.
2. Interpret port roles and track changes
| Observation | What to verify |
|---|---|
| Root port is forwarding | Its upstream neighbor and path cost match the intended path toward the root. |
| Designated port is forwarding | This port is the forwarding path for its segment in the instance under review. |
| Alternate port is discarding | Another path reaches the root. A healthy backup link can remain in this state indefinitely. |
Root-Inc | Root Guard detected superior BPDUs. Identify the neighbor advertising the better root before changing the guard. |
Loop-Inc | Loop Guard is holding the port because expected BPDUs stopped arriving. Inspect the peer and the physical path. |
Capture the detailed STP output twice during the issue. Compare the topology change count, time since the last change, forwarding transitions, and per-port BPDU counters where available. A historical count provides a baseline. A counter that rises during each interruption helps narrow the investigation. A port receiving topology-change notifications may be relaying changes from elsewhere, so confirm the next hop before identifying a source.
3. Check the physical link or LAG
show interface 1/1/49
show interface lag 10
show lacp interfacesCheck for link transitions and increasing error counters. For an LACP bundle, inspect both the logical interface and its member ports. Compare the partner system ID and the members’ synchronization, collecting, and distributing states on both ends. A physical member can show link up while LACP keeps it out of forwarding.
Example: Intermittent loss after an uplink move
VLAN 20 maps to MST instance 1. The distribution root stays the same, but MST1 records fresh topology changes each time traffic drops. The intended forwarding uplink shows increasing receive errors, while its peer records link transitions at the same times. The backup stays available as an alternate between events.
Check the optics, patch leads, and port settings on both ends under the approved change plan. After remediation, confirm that MST1 retains the expected root, the primary and backup roles match the design, and the topology change count stays steady during a representative observation window. Test VLAN 20 from a client to its gateway and application. If a failover test is in scope, confirm that the backup forwards during the test and verify the expected topology after restoration.
Keep protection aligned with the link role
Use edge-port behavior and BPDU Guard on links dedicated to endpoints. Use Root Guard where a downstream device must never become the root. Evaluate Loop Guard on redundant paths where the switch expects to receive BPDUs. When a guard activates, investigate the condition before changing the protection.