Spanning Tree Protocol Simulator — Root Election & Loop Prevention Interactive

Interactive three-bridge spanning-tree workbench with root-bridge election, root/designated/alternate port role assignment, a configurable link cost and link failure, a 3D cutaway model, guided experiments, a model-verification bench and a knowledge-check quiz.

← Networking Labs
About this tool — how it works & FAQOpen ▾Close ▴

About the Spanning Tree Protocol Simulator

This simulator models three bridges — A, B and C — connected by an AB link, a BC link and a configurable-cost AC link. Change which bridge has the lowest bridge ID, raise the AC path cost, break a link, or disable spanning tree entirely, and watch root election, root-path selection and port roles reorganize in real time.

What the simulator shows

• A real-time 3D cutaway of bridges A, B and C and their AB, BC and AC links, with home view, focus-selected-part, toggleable full enclosure, exploded view, auto-rotate, expand and label toggle controls, and numbered parts matching the companion diagram. • A lowest-bridge-ID preset selector (A, B or C) that changes which bridge is elected root. • An adjustable A–C path cost slider (5–40 cost units) that changes whether the direct AC link or the two-hop A-B-C route wins as the least-cost path. • An enable-spanning-tree toggle that, when disabled, lets all three links forward simultaneously to demonstrate an unbroken loop. • A disconnected-link selector (none, AB, BC or AC) to force a topology change and trigger reconvergence. • An illustrative convergence-interval slider (0.5–5 s) controlling how long the modeled tree takes to settle after a change. • Auto-traffic with an adjustable interval (0.5–5 s) and a manual "Send test traffic" action, alongside start/stop trial controls. • Play/pause, single 0.1 s step and 1 s step time controls, plus a playback-speed selector (10x slow motion, real time, 10x, 60x/1 minute-per-second). • Six live metrics: forwarding links, discarding links, root bridge index (A=1, B=2, C=3), convergence time remaining, schematic loop growth factor, and topology revision count. • A Curves & measurements tab with two charts (forwarding vs. discarding links; convergence time remaining), the full model equations, and snapshot readouts. • An Experiments tab with four guided scenarios (default tree, cost-driven tree, alternate root, loop demonstration), a model-verification bench of independent automated checks, and a timestamped event log with a copyable trial report. • A Learn & assess tab with four guided lessons (elect the root, choose root paths, discard redundancy, reconverge), a two-question knowledge-check quiz, and a written scope/reference statement citing Cisco's STP configuration guide.

How the tree keeps redundancy without a forwarding loop

With all three links physically connected, spanning tree does not remove any cable — it disables forwarding on exactly one port so that only one loop-free path exists between any two bridges at a time. In the default configuration, the AB and AC links forward while the BC link keeps a discarding endpoint, because AB and AC are both cheaper root paths than routing through the redundant BC segment.

Raising the A–C path cost above the two-hop alternative changes which link discards: once the direct AC route costs more than going A→B→C, the model switches to forwarding AB and BC instead, with AC's endpoint becoming the redundant, discarding link. This is exactly what the cost-driven-tree experiment demonstrates — the physical topology never changes, but the active forwarding tree does.

Reading root election, port roles and the loop demonstration

The equations panel states that the root is the lowest configured bridge ID and that each non-root bridge's root path is the minimum sum of link costs to that root; a fully connected three-bridge tree always settles at exactly two forwarding links. Changing the lowest-bridge-ID preset to C, for example, re-runs this election and changes which ports become root, designated or alternate/discarding throughout the topology.

Disabling spanning tree entirely (or removing the failed-edge constraint that keeps exactly one path open) lets all three links forward, and the schematic loop-growth factor climbs — bounded at 1000x in this model — to stand in for the exponential broadcast storm a real Layer 2 loop produces, without simulating an actual unbounded packet flood. The model uses a deterministic three-bridge tree with an abstract BPDU exchange and configurable convergence, and does not claim complete STP/RSTP timers, proposal/agreement, PortFast, guards or topology-change flushing.

Frequently asked questions

Does a discarding (blocked) port mean the cable is disconnected?

No. In the default tree, the BC link stays physically connected but one of its endpoints discards traffic because AB and AC already provide a cheaper path to the root. Spanning tree keeps the redundant physical link in place so it can take over automatically if an active link fails — it just prevents that link from forwarding while it is not needed.

How does raising the A–C path cost change which links forward?

Each non-root bridge selects the least-cost path to the root. When the A–C link cost is low, it beats the two-hop A-B-C route and forwards directly; the cost-driven-tree experiment raises the A–C cost above 20 so the two-hop path through B becomes cheaper, and the simulator switches which link's endpoint discards traffic as a result — the physical wiring never changes, only which path the tree elects to use.

What happens if spanning tree is turned off entirely?

The loop-demonstration experiment disables spanning tree with auto-traffic running: all three links forward at once, creating an actual Layer 2 loop, and the simulator's schematic loop-growth factor climbs sharply (bounded at 1000x) to represent the runaway broadcast traffic a real bridging loop produces, illustrating why the discarding port in the normal configuration matters.

What does this spanning-tree model not include?

This is a deterministic three-bridge teaching model using an abstract BPDU exchange and a configurable convergence delay as a teaching control rather than a guaranteed protocol timer. It does not model complete STP/RSTP behavior such as proposal/agreement, PortFast, root/loop guard or topology-change flushing, and every packet and fault injection stays inside the offline simulation.

Related tools & guides