The scenario
Switch-A, Switch-B and Switch-C are cabled in a triangle, so there are two paths between any two of them. PC-1 (10.0.0.10) hangs off Switch-B and PC-2 (10.0.0.20) off Switch-C, on the same subnet. On real Ethernet switches with spanning tree turned off, this triangle is a loop, and the first broadcast, such as PC-1's ARP request for PC-2, would circulate around it without end. This platform does not reproduce that. In the simulator and in a live lab, switches that are cabled together are merged into one loop-free segment (a live lab builds them as a single Linux bridge), which behaves as if spanning tree had already blocked one link. Pings here succeed. The lab lets you look at the loop, reason about what real switches would do with it, and test what the redundant cables actually give you.
What you will work out
Understand why a switching loop causes a broadcast storm, how spanning tree prevents it, and what redundant switch links really protect against.
Why this matters
An accidental loop, such as a patch cable run between two wall ports that lead to the same switch, or a small unmanaged switch cabled in twice, is a classic way to take down a LAN. That is why managed switches normally run a spanning tree variant, and why features like BPDU guard exist to shut down an edge port that unexpectedly hears from another switch. The symptoms of a storm (every link busy, MAC addresses jumping between ports, everything slow at once) and the first move (break the loop, then find out why spanning tree did not) are worth knowing before you ever see one.
Running it
Switch Loops and Broadcast Storms opens on a canvas, already wired and addressed. Trace a packet through it hop by hop, or run the same topology live on real Linux network namespaces. How the two modes differ.
Open Switch Loops and Broadcast Storms
Runs in your browser. No install, no signup, and the simulation starts instantly.
Open the lab →