Spanning Tree Mapping: preventing broadcast storms before they take the plant down.

A single mis-cabled switch can flood an OT network with broadcast traffic until nothing else gets through. Production lines stop, safety systems go unreachable, often within a minute. The hard part is never fixing the loop. It is finding it.

Loops and broadcast storms

A switching loop forms when there is more than one Layer 2 path between two switches. When a switch receives a broadcast frame, an ARP request for example, it forwards it out of every port except the one it arrived on. In a looped topology that frame comes straight back, gets forwarded again, and the copies multiply exponentially.

That is a broadcast storm. The network floods with duplicate frames, available bandwidth drops to zero, switch CPUs saturate, and MAC address tables thrash as the same addresses turn up on port after port. Legitimate traffic cannot get through.

Without spanning tree, in one minute

From a single accidental loop the collapse is fast, and in an industrial network the consequences are physical:

• 0–5 sOne ARP request becomes duplicates, multiplying exponentially.
• 5–15 sSwitch CPUs hit 100% processing storm traffic.
• 15–30 sEvery link saturates; legitimate traffic starts to drop.
• 30–60 sMAC tables thrash constantly; switches become unstable.
• 1 min+Complete segment failure. The production line stops.

How spanning tree stops it

It works by election. Switches exchange BPDUs and choose a root bridge, the switch with the lowest Bridge ID, which combines a configurable priority with the switch's MAC address. Every other switch then calculates its shortest path to the root by path cost, and each port is given a role:

• Root portThe best path toward the root bridge. Forwards traffic.
• Designated portForwards traffic for the network segment it serves.
• Blocked portA redundant path, held logically disabled until it is needed.

When the topology changes, when a link drops or a switch is added, spanning tree recalculates the tree and updates the port states. With RSTP that reconvergence happens in seconds.

STP, RSTP and MRP: convergence time matters

Which protocol builds the tree decides how long an industrial network sits still after a topology change. Legacy STP under IEEE 802.1D takes 30 to 50 seconds to reconverge, 15 of those in the listening state and 15 in learning, all of it timer-based. RSTP (802.1w) cuts that to 1 to 6 seconds through proposal/agreement handshakes and edge port designation. For real-time applications even that is too slow, and MRP takes over.

The most expensive mistake in a network that grew over decades is mixing them. The moment a single switch still speaks legacy STP, the segment falls back to the slower STP timers. The convergence time you planned for is not the one you get, and you find out during the outage.

Industrial failover scenarios

When the redundancy is designed properly, a failure looks unremarkable from the plant floor:

• Primary ring failsThe secondary ring maintains PLC connectivity.
• Switch failsBlocked ports activate within 1 to 6 seconds under RSTP.
• Cable cutAutomatic rerouting via the alternate path.
• SCADA accessMultiple redundant paths to the control systems.

Assuming the redundancy is actually there and the tree agrees. That is precisely the assumption you cannot check without a map of the topology.

When it was never really configured

Done right, the storm never starts. But a network that grew over two decades, across vendors and hand-overs, rarely has spanning tree done right. The root bridge is wherever the election happened to land. Priorities sit at their factory defaults. A "temporary" redundant link became permanent years ago. The tree holds, quietly, until one topology change triggers the loop it was always hiding.

The blast radius

When a loop does form, the question is how far the damage spreads. The blast radius of a Layer 2 failure is every device in the same broadcast domain, which means the same VLAN. In the flat network designs still common in older industrial installations, that can be hundreds of devices across several production lines.

And Layer 2 failures do not respect geography. A broadcast storm started by one mis-patched cable at a remote site can saturate a WAN link and take down a building kilometres away.

Two ways the same mistake plays out

Spanning tree is a graph, not a table

The usual way to inspect spanning tree is to log into a switch and read show spanning-tree, then the next switch, then the next. Each one reports its own ports: this one forwarding, that one blocking. What none of them shows you is the tree itself. Which switch is actually root? Which physical loop is a given blocked port breaking? If that link fails, what is the blast radius?

Spanning tree is a property of the whole network, not of any single switch, and it has the shape of a graph. You cannot read a graph from a column of port states on twenty separate consoles. You have to draw it.

Mapping the spanning tree visually answers those questions from the live network, before a change is made, instead of during the incident review afterwards.

Why manual spanning tree analysis is nearly impossible

Reconstructing the spanning tree topology of a network that grew over two decades means collecting BPDU exchanges, bridge priorities, port costs and VLAN configurations across dozens or hundreds of switches. Four things make that unaffordable in practice:

• Data collectionPer-VLAN spanning tree instances, bridge priorities and MAC addresses, port costs and states, BPDU timing parameters, plus vendor-specific implementations.
• TopologyDozens of switches to document, multiple redundant paths, undocumented links, and the difference between physical and logical topology.
• ChangeConfiguration drift over the years, maintenance changes, emergency bypass links. The analysis is out of date the moment someone patches a cable.
• Risk assessmentBlast radius calculation, single points of failure, suboptimal root bridge placement, convergence time estimation, load distribution.

From map to safe change

With the tree mapped, a tense plant-down afternoon becomes a controlled change. Confirm the root bridge sits where it should. Test a failover and watch the redundancy behave. Then make the move knowing what will happen, because you have already seen it.

What automated visualisation gives you

The narrowin Network Explorer reads the spanning tree configuration out of the live network and draws the topology for you. A column of port states across twenty consoles becomes a map:

• Topology mappingAutomatic discovery and mapping of both the physical and the logical topology.
• Root bridgeRoot bridge identification and placement optimisation, with priorities and path costs compared across devices.
• Blocked portsMade visible, together with the physical loop each one is breaking.
• Per-VLAN instancesEvery spanning tree instance readable on its own instead of interleaved in text output.
• Blast radiusPer-link impact analysis and automated checks for STP misconfiguration.

The result: avoiding broadcast storms before they cause outages, and saving days or weeks of manual analysis.

Practical implementation in industrial networks

A spanning tree design that holds up in industrial environments follows a short list of rules. Put critical production systems in their own VLANs to bound the blast radius from the start. Set root bridges explicitly, primary and secondary, rather than relying on default priorities; typically on the core switches. Use edge port configuration on access ports to speed up convergence. Run RSTP consistently and avoid mixed STP/RSTP environments. And where guaranteed recovery times are required, use MRP in the field-level ring topologies.

Frequently asked