Kernaali ToolsA blocked spanning-tree port can be the expected result of redundant links. Identify the exact protection mechanism and active forwarding path before re-enabling anything. Disabling STP to remove a warning can turn a protected loop into a broadcast outage.
Applies to: UniFi Network application, supported UniFi switches and AP uplinks, checked against the current STP/loop guide. The article distinguishes RSTP state, Loop Protection and BPDU Guard; available controls depend on the switch and firmware. Gateway ports must not be assumed to provide the same STP behavior as switch ports.
Validation: documentation-checked on . No device or lab test is claimed. Version references identify the documentation checked, not a firmware upgrade recommendation.
Read the state, not just the word blocked
| Mechanism | What to establish |
|---|---|
| RSTP alternate/discarding path | Whether another intentional path is forwarding and the topology has the expected root |
| Loop Protection disabled a port | Which physical or downstream loop caused protection to activate |
| BPDU Guard disabled an edge port | Whether a switch or other bridge was connected where only an endpoint was expected |
| Repeated topology changes with outages | Whether a cable, power issue or changing wired/mesh path is repeatedly altering the tree |
The official loop and STP guide explains the separate controls and recovery behavior. Do not treat an automatically discarded redundant path as a failed physical link.
Trace every path, including wireless uplinks
Draw a small private map from the affected switch to the root/uplink, including unmanaged switches, dual cables, bridged endpoints and AP mesh links. Compare it with actual link state rather than trusting a stale topology picture. Inspect recent cable moves and the time the warning began.
Synthetic example: two access switches have separate uplinks and an extra cable between them. One redundant port may correctly discard. If the only remaining forwarding path also fails, investigate that path before forcing the discarded one open. An accidental bridge through a workstation or a wired AP with a wireless path also deserves inspection.
Do not disable wireless meshing globally if any AP depends on it for uplink. Determine which APs are wired and which use a wireless parent. For link or reboot evidence, follow offline-device checks first.
Remove the verified cause with a recovery path
Retain console or independent management and identify the client impact before disconnecting a cable or changing a port. Remove the one unintended redundant connection, or correct the mistaken edge-port design. For intentional switch redundancy, keep STP and plan the root/port roles consistently across the topology.
Loop Protection and BPDU Guard can require manual re-enabling after the cause is corrected. Re-enable only the affected port, observe the result, and stop if protection activates again. Do not repeatedly override the protection while leaving the loop intact. Changing root priority or port roles can interrupt forwarding and belongs in a coordinated maintenance window.
Verify convergence, applications and rollback
Confirm the intended root and forwarding/alternate paths, stable link state and no continuing burst of topology-change events. Test DHCP and an application from a client beyond the affected switch. Where redundancy is part of the design, schedule a controlled single-link failure test with local recovery rather than improvising it over the only management session.
Restore documented port roles, priorities or mesh settings if a configuration change was incorrect. Reconnect a removed cable only after verifying that the resulting topology is loop-safe. A rollback must not deliberately recreate the known loop. Keep a brief private topology-change record and close temporary captures.
Power and uplink instability · DHCP after the uplink is restored
Technical references
Found an issue? Send a correction with a reproducible example.