Some network faults announce themselves. Spanning tree problems do not. They show up as a network that is fine for weeks and then unusable for ten minutes, as devices that drop and come back, as a laptop that will not get an address when somebody plugs it into the meeting room socket. Nothing is broken, so nothing gets fixed, and everyone decides the Wi-Fi is rubbish. This is what spanning tree actually does, how it goes wrong, and how to find it.
The 30-second version
- Spanning tree stops network loops by blocking redundant paths so only one is active.
- Without it, one loop takes down everything, not just the bit that looped.
- The classic cause is a patch lead plugged into two wall sockets by someone being helpful.
- Badly configured STP is its own problem, usually because the wrong switch became root.
- No edge ports means slow connections and devices that fail to get an IP address.
- It is fixable in an afternoon once you know what you are looking at.
On this page
What spanning tree actually does
A switched network cannot tolerate a loop. If there are two physical paths between the same two switches, traffic can go round and round forever, because an Ethernet frame has nothing in it that counts how many hops it has taken. There is no timer that eventually kills it. It just circulates.
Spanning Tree Protocol exists to prevent that. Switches talk to each other, work out the shape of the network, elect one switch as the root, and then deliberately block any port that would create a second path to it. You end up with a tree: one active route to everywhere, and the redundant links sitting in standby.
The payoff is that redundancy becomes safe. If the active link fails, a blocked port is unblocked and the network heals itself. That is the whole idea.
Versions matter. The original standard takes roughly 30 to 50 seconds to react to a change. Rapid Spanning Tree does the same job in a few seconds and is what you want on any modern network. There is also a multiple-instance version that handles VLANs separately. If your switches offer a choice and you are on the original, that alone is worth changing.
Why one loop breaks everything
This is the part that surprises people. A loop in one cupboard does not degrade that cupboard. It takes down the site.
Three things happen at once:
- A broadcast storm. Any broadcast frame circulates endlessly and multiplies at every switch, filling every link within seconds.
- The MAC address tables go unstable. Switches see the same device arriving on two different ports and rewrite their tables constantly, so legitimate traffic gets sent the wrong way.
- Switch processors saturate. Once a switch is busy dealing with the storm it stops doing its actual job, including talking to the management system you are trying to use to diagnose it.
That is why a loop feels like a total outage rather than a partial one, and why remote troubleshooting is so frustrating: the tools you need are on the network that has stopped working.
The symptoms, and why they mislead
Spanning tree problems are misdiagnosed constantly, because the symptoms point at everything except the network core.
| What people report | What is actually happening |
|---|---|
| "The Wi-Fi keeps dropping" | The wired network under the access points is unstable, so the Wi-Fi gets blamed. |
| "It goes slow for ten minutes then fixes itself" | A link flapping, with the network reconverging each time. |
| "It happens about the same time each day" | Somebody plugs something in, or a device powers on, at the same time each day. |
| "My laptop does not get an IP in that room" | A port taking too long to start forwarding, so DHCP gives up first. |
| "Everything was fine until we added a switch" | The new switch changed the topology, or became the root. |
| "All the lights flash together" | The clearest sign of a broadcast storm there is. |
That last one is worth knowing. On a healthy network, port activity lights blink independently and irregularly. When every light on the switch flashes in perfect unison, you are watching the same broadcast go round the loop.
How loops actually happen
Almost never through bad design. Nearly always through something ordinary.
- A patch lead into two wall sockets. Someone tidying up finds a loose cable and plugs the free end into the nearest spare port. Both sockets lead back to the same switch. Instant loop.
- An unmanaged switch under a desk. Somebody needed more ports, bought a five port switch, and connected it to two wall sockets to "make it faster".
- Two access points cabled together. Usually when someone daisy-chains rather than running a second cable back.
- A device with two connections. Some printers, cameras and older kit will bridge two networks if both are plugged in.
- Re-patching a comms cabinet. Any cabinet tidy-up without documentation is a loop waiting to happen.
Notice that none of these are technical failures. They are people being helpful. Which is exactly why the protection has to be in the switches rather than in a policy nobody reads.
The root bridge problem
Here is the subtler failure, and the one that causes mystery slowness rather than outages.
Spanning tree elects a root switch, and every path on the network is calculated towards it. The election is won by the lowest bridge ID, which is a priority value followed by the switch's MAC address. Every switch ships with the same default priority, so if nobody sets it, the election is decided by MAC address alone.
MAC addresses are effectively arbitrary. In practice that often means the oldest or cheapest switch in the building becomes the root, simply because its MAC happens to be lowest. Now every path is calculated towards a five port switch in a cupboard, and traffic between two servers may be taking a detour through it.
Nothing breaks. It is just slower than it should be, permanently, and no amount of bandwidth upgrading fixes it.
The fix is one setting. Decide which switch should be root, normally your core or the one everything else connects to, and give it a lower priority than the default. Give your second most central switch the next lowest, so there is a sensible backup if the core fails. Then the topology is yours by design rather than by accident of hardware serial numbers.
Edge ports, and the DHCP mystery
When a port comes up, spanning tree makes it wait while it works out whether the new connection creates a loop. On the original standard that wait is up to about 30 seconds. During it, the port carries no traffic at all.
A laptop plugged into that port sends its DHCP request, hears nothing because the port is not forwarding yet, and often gives up before the port opens. The user sees "no network", unplugs, tries again, and sometimes it works because the port is now ready.
The answer is to tell the switch which ports connect to end devices rather than to other switches. Those are edge ports, sometimes called portfast, and they start forwarding immediately.
Edge ports should always be paired with protection that shuts the port down if another switch is ever detected on it. That way you get instant connections for users and you are still protected from somebody plugging a switch into a desk socket.
Fixing it properly
- Turn spanning tree on everywhere, and use the rapid version. A single switch with it disabled undoes the protection for the whole network.
- Set your root bridge deliberately, with a defined backup. Do not let MAC addresses decide your topology.
- Mark end device ports as edge ports, so users get an instant connection and DHCP works first time.
- Enable protection on those edge ports so a rogue switch disables the port rather than the network.
- Enable loop protection if your switches offer it, which catches loops created by devices that do not speak spanning tree at all.
- Replace unmanaged switches in anything that matters. They cannot participate, so they are blind spots by design.
- Label and document the cabinet, because most loops are created by someone who could not tell what a cable did.
On UniFi and Omada
Both platforms handle this well, and both default to something sensible. Menu names shift between firmware versions, so treat these as what to look for rather than an exact path.
On UniFi, the spanning tree mode is a switch setting, and you want the rapid version rather than the original. Each port can be configured, which is where you set edge behaviour for ports that face end devices. There is also a separate loop protection feature worth having on, since it catches loops that spanning tree alone may not.
On Omada, spanning tree is configured under the switch settings with a choice of versions, and again rapid is the one to use on a normal business network. Omada also has loopback detection, which is a distinct feature from spanning tree and is the thing that catches somebody looping two wall sockets. Turning both on is the sensible default.
On either platform, the single highest value change is usually setting the root bridge deliberately, because it is the one nobody does and the one that quietly costs performance. If you already run one of these, our guides to VLANs on a UniFi Dream Machine and VLANs on Omada cover the next thing worth doing.
Network behaving strangely and nobody can say why?
Intermittent faults that nobody can reproduce are the ones that get lived with for years. We will look at the switching, find out whether spanning tree is part of it, and tell you what to change. Our engineers are certified on UniFi and Omada and work on both every week.