Will spanning tree stop every loop?

It stops the loops it can see, which is most of them on a properly managed network. The limits are real. It only runs on managed switches that have it enabled. An unmanaged switch in the path is invisible to it. Reconverging is not instant, so a loop can still cause a brief disruption before the switch blocks it. Treat it as the safety net. It is not a reason to skip labeling and topology discipline.

Can a loop happen with just one cable?

Yes. It is the single most common way. One patch cable with both ends landing in the same switch is a complete loop; so is one landing anywhere else in the same layer-2 network. No second switch or clever topology is required. Which is exactly why an idle cable end left near an open port is dangerous.

Why does the whole network die instead of just the looped switch?

Because the storm is made of broadcast and multicast frames, which switches forward everywhere by design. The circulating traffic floods out across every uplink into every connected switch. So a loop in one corner saturates the entire layer-2 segment. Splitting traffic onto separate VLANs is what limits that blast radius.

Is a loop the same thing as a broadcast storm?

They are cause and effect. The loop is the physical wiring mistake: two active paths where there should be one. The broadcast storm is what follows, as looped broadcast and multicast traffic multiplies with nothing to expire it. Prevent the loop. The storm never starts.

Do I need managed switches to prevent loops?

To let the network protect itself, yes. Spanning tree and loop-guard features are managed-switch features. On an all-unmanaged network your only protection is discipline: one documented path between devices, labeled uplinks, never chaining dumb switches into a ring. For anything past a tiny single-purpose rig, managed switches earn their cost right here.

Network Loop Prevention on Show Networks

By VJ Ries · Published 2026-07-12 · Updated 2026-08-01 · 10 min read

Network loop prevention on a show network comes down to three habits: keep exactly one active path between any two switches; turn on spanning tree (STP) so the managed switch itself blocks any accidental second path; label both ends of every uplink so nobody patches a cable back into the network it came from. A single cable with both ends in the same layer-2 network is a complete loop. Plain Ethernet has no way to expire a circling frame, so broadcast and multicast traffic multiplies until the network saturates. Then the show goes dark. STP plus disciplined labeling are what keep one tidy-minded patch from taking everything down.

What is a network loop, and how does it take down a show?

At layer 2, the plain Ethernet switching layer where almost all AV gear lives, there is no hop counter: nothing that says this frame has traveled too far so drop it. A network loop is any path where traffic leaving a switch can find its way back to the same switch without passing through a router. The simplest version is one cable with both ends plugged into the same switch. The next simplest is two switches joined by two cables instead of one. The moment a broadcast frame enters the loop (or a multicast, or an unknown-unicast), the switches dutifully forward it around the ring. And around again. And again. Forever.

That one frame becomes thousands. Add the normal discovery chatter of a show network, where Dante and NDI both lean on multicast (see the AV networking guides), and the loop does not circulate one packet; it amplifies every broadcast on the wire into a storm. Switch CPUs peg. MAC address tables thrash as the same device appears to arrive on every port at once. Forwarding for real traffic collapses.

So a loop is rarely a slow-network problem. It is almost always a total, all-at-once outage. Audio drops and control panels stop responding. The switch web interface quits answering, and every link light in the rack blinks in the same panicked rhythm.

What is spanning tree (STP), in plain terms?

Spanning tree is the switch feature that exists specifically to make loops survivable. Turn it on. The managed switches in a network then talk to each other and discover every path between them. Out of those they pick one loop-free set of active links: a tree with no rings in it. Any extra path that would close a loop is put into a blocking state. The cable stays plugged in, the link light may even glow, but the switch refuses to forward normal traffic across it. If an active link later fails, spanning tree unblocks one of the standby paths and the network heals itself without anyone re-patching.

For a show crew the takeaway is short. Spanning tree is the safety net that catches a loop before it becomes a storm: the accidental one, the helpful patch, the doubled uplink. It is not a license to be sloppy. Reconverging takes time, so a blocked-then-unblocked path can still cause a brief interruption. And it only runs on managed switches that have it on. An unmanaged switch has no spanning tree at all, which is why a ring of dumb switches is one of the fastest ways to kill a network.

How do you prevent loops on a show network?

Prevention is layered. Design the topology so a loop cannot form by accident. Let the switch catch the one you build by mistake anyway. Make the cabling hard to misread. In practice, a short checklist:

Design for one path. Between any two switches, plan exactly one uplink unless you are deliberately building redundancy and letting spanning tree manage it. Decide that topology before load-in so how many links run between two switches has a documented answer.
Turn spanning tree on, do not assume it. On every managed switch, confirm spanning tree is actually on and enable whatever edge-port loop protection the box offers. It is the highest-value setting on a show network.
Label both ends of every uplink and trunk. A cable that clearly reads 'SW1 p24 to SW2 p24' on both ends does not get guessed back into a random port. Color-code or reserve the uplink ports on the switch face where you can.
Control the ports people touch. Wall plates, guest drops, and spare patch points are where accidental loops enter. Keep loose cable ends capped or clearly parked, and never leave both ends of a coil hanging near open ports.
Never ring unmanaged switches. Dumb switches have no loop protection. If you must chain them, chain them in a line, never in a loop, and never cross-link two of them 'for redundancy.'
Test before the crew depends on it. A green link light says the cable has power, not that the network is healthy. Verify the live topology matches the plan and that spanning tree blocked the paths you expected it to.

How do you find a loop that is already happening?

When a network is already storming you rarely have time to be clever. Break the loop first. Diagnose second. Start by reading the symptoms. A loop looks nothing like a single dead device:

Reading the room: what points to a loop versus a one-off device failure.
Symptom	Points to a loop	Points elsewhere
Link lights	Many or all ports blinking hard in unison, including ports that should be idle	One device's light misbehaving while the rest look normal
Scope of failure	Everything on the segment dies at once, across every trade	A single device or a single feed is down
Switch management	Web UI or console unreachable or crawling	Management pages respond at normal speed
Onset	Sudden, right after someone patched, moved, or tidied a cable	Gradual, or tied to one device being power-cycled

Stop touching AV gear. The problem is on the network, not the console. Power-cycling the mixer wastes the minutes that matter.
Bisect the network. Pull uplinks one at a time. When the storm stops the instant a specific cable comes out, that cable, or the loop it closed, is your culprit.
On managed switches, read the port counters: the ports carrying the loop show wildly high, near-identical traffic, follow them to the doubled path.
On unmanaged gear, pull cables until the network recovers, then add them back one at a time until it dies again to find the offending pair.
Once found, remove the extra path, then before the next show add the spanning tree or the labeling that would have caught it on its own.

When are loops most likely to bite?

Loops cluster around a few predictable moments; knowing them is most of the prevention:

Redundant links added by hand. A second run 'for backup' between two switches is a loop unless spanning tree is managing it. Redundancy without spanning tree is just a loop you built on purpose.
Patch panels and wall plates. A mis-punched panel or a wall drop that quietly returns to the same switch hides the second path inside the walls, where nobody ever sees the offending cable.
Guest and spare cables. The tidy-up patch, the presenter who plugs a laptop into two wall ports, the coiled spare with both ends parked near the rack.
Struck-and-rebuilt rigs. A network torn down and rebuilt every show starts blank each time. Last night's careful labeling has to be re-verified tonight. Assume nothing.
Unmanaged switch rings. Cheap switches chained without a plan, especially when two people each close the ring from opposite ends.

Where does loop prevention live in your documentation?

Heroics during the storm are not the durable fix for loops. A network someone can read is. Write the topology down: one path between each pair of switches, spanning tree enabled, uplink ports labeled. Then the accidental second path is obvious on the drawing long before it is plugged in. That is exactly what a switch-port map is for. One row per port: what each port is, which uplink it carries, what should never be patched into it.

In WireFlow the switches, ports and links sit on the same diagram as the rest of the signal flow, so the intended topology and the port assignments are one document instead of a switch config that only exists in the closet; pair the port map with a VLAN plan and a duplicate-address habit for the same switches. For where this fits before show day, see port-to-port documentation and the preproduction workflow.

Frequently asked questions

Will spanning tree stop every loop?: It stops the loops it can see, which is most of them on a properly managed network. The limits are real. It only runs on managed switches that have it enabled. An unmanaged switch in the path is invisible to it. Reconverging is not instant, so a loop can still cause a brief disruption before the switch blocks it. Treat it as the safety net. It is not a reason to skip labeling and topology discipline.
Can a loop happen with just one cable?: Yes. It is the single most common way. One patch cable with both ends landing in the same switch is a complete loop; so is one landing anywhere else in the same layer-2 network. No second switch or clever topology is required. Which is exactly why an idle cable end left near an open port is dangerous.
Why does the whole network die instead of just the looped switch?: Because the storm is made of broadcast and multicast frames, which switches forward everywhere by design. The circulating traffic floods out across every uplink into every connected switch. So a loop in one corner saturates the entire layer-2 segment. Splitting traffic onto separate VLANs is what limits that blast radius.
Is a loop the same thing as a broadcast storm?: They are cause and effect. The loop is the physical wiring mistake: two active paths where there should be one. The broadcast storm is what follows, as looped broadcast and multicast traffic multiplies with nothing to expire it. Prevent the loop. The storm never starts.
Do I need managed switches to prevent loops?: To let the network protect itself, yes. Spanning tree and loop-guard features are managed-switch features. On an all-unmanaged network your only protection is discipline: one documented path between devices, labeled uplinks, never chaining dumb switches into a ring. For anything past a tiny single-purpose rig, managed switches earn their cost right here.

Document your AV network in WireFlow

VLANs, IPs, PoE, and switch ports live on the same diagram as your signal flow, one source of truth for the whole system.

Start a free network plan · See the sample project