← All coursesBack to the simulator →

Redundancy and Spanning Tree

Why one link isn’t enough: loops and broadcast storms, Spanning Tree (root bridge, port states), RSTP, EtherChannel.

This is a text preview of the lessons for reading. The full version – an interactive simulator with animations, exercises and quizzes – runs in the app.

▶ Launch the interactive version

Lesson 1: The loop that kills a network

We want a backup

SW-ASW-BPC1SERVER

From the Network security course you know that one device or link = a single point of failure (SPOF for short; you’ll meet the term often). Here we’ll fix that – and hit an unexpected problem. Between two switches runs one cable. If you cut that cable (or it breaks), half the network is cut off. The logical fix: add a backup cable. But that very move – as you’ll see in a moment – can bring the whole network down.

Step by step

  1. Two switches, one cable between them. PC1 reaches the SERVER through them. It works – while that cable holds.
  2. The cable breaks → SW-B (and the SERVER) is cut off. A single point of failure. We want a backup.
  3. You add a second cable as a backup. Now you survive one failure… but you have a loop between the switches (two paths). And that, believe it or not, is a disaster – next module.

Broadcast storm

two links = a loopSW-ASW-BPC

Recall the broadcast from the Switching and VLANs course: a switch floods it to all ports. Now you have two links (a loop) between the switches. The PC sends one broadcast – SW-A sends it on both links to SW-B. SW-B floods it to all ports… including the other link back to SW-A. And again. The frame circles and multiplies endlessly – each switch sends a copy to every port, so one frame becomes two, four, eight… saturating every link within seconds. This is a broadcast storm – and the network collapses.

Step by step

  1. The PC sends one broadcast (e.g. ARP) to SW-A. Nothing unusual yet.
  2. SW-A floods it to all ports → on both links to SW-B. The broadcast has split in two.
  3. SW-B floods it to all ports too – including the other link back to SW-A. Which floods again… The frame circles round and multiplies.
  4. Within a few seconds the loop is full of copies of one broadcast. Links clog, switches overload – the whole network goes down. One loop, total outage.

MAC instability

SW-A MAC tableSW-APCSW-BMAC PC … port 1 (to the PC)

And here’s the loop’s second nasty trick: an unstable MAC table. A switch learns which port each MAC address is on (the ISO/OSI and TCP/IP course). When a frame from the PC circles the loop, it reaches SW-A once from one port, then from the other. So the switch sees the same MAC alternating on two ports and keeps overwriting it (MAC flapping). The table stops making sense and the switch doesn’t know where to send things. The storm gets address chaos on top.

Step by step

  1. SW-A learns: the PC’s MAC is on port 1 (where the PC is directly attached). Correct.
  2. But a copy of the frame circled the loop and arrived on port 2. SW-A thinks: "ah, the PC is on port 2 now" and overwrites the table.
  3. And round and round: port 1, port 2, port 1… MAC flapping. The switch no longer knows where the PC is, and delivery falls apart. A loop wrecks the network two ways – the storm and MAC chaos.
  4. Try it yourself. In the simulator build a loop from two switches (two links between them), switch on Advanced mode and open each switch’s modal → STP mode → Off. The looped links turn red and start flashing with a “STORM” tag. Then turn on RSTP on one switch – the storm vanishes and one link becomes “STP block” (a backup). That’s exactly the difference we’ll cover next.
  5. Bottom line: a backup link is essential, but an active loop is deadly. We need a backup that makes no loop until needed. That’s exactly what Spanning Tree solves – the next lesson (and you’ll see it act in the simulator).

▶ Open in the simulator

Lesson 2: Spanning Tree

The idea of STP

SW1SW2SW3PC1SRVthree switches in a ring = a loop

We want a backup, but no loop. The Spanning Tree Protocol (STP) solves it elegantly: switches talk to each other, find loops and for each one logically block one port, leaving a loop-free tree (hence "spanning tree"). The backup link is physically there, but STP keeps it blocked until needed. No storm – yet redundancy. All of this runs in this simulator too.

Step by step

  1. Three switches wired in a ring = a loop. With no protection a broadcast storm would erupt instantly.
  2. We turn on STP. The switches exchange messages (BPDUs), spot the loop and agree which port to sacrifice.
  3. STP blocks one port (here the SW2–SW3 link). The loop is gone → a loop-free tree. No storm, traffic flows.
  4. And note: the cable is physically still there – just logically off. When the main path fails, STP turns it on. A backup without a loop! How STP decides what to block is the next modules.

The root bridge

SW1SW2SW3PC1SRV

For switches to agree which port to block, they need one fixed point – an anchor the whole tree is built from. It’s called the root bridge. It’s elected automatically: each switch has a bridge ID (priority + its MAC address) and the lowest wins. The root is the center of the network – distances are measured from it and decide which ports stay active. The priority is configurable, so you can pick the root yourself (ideally the most powerful central switch).

Step by step

  1. Three switches. Each has its bridge ID (priority + MAC). Before the tree is built, a root must be chosen.
  2. The switches compare bridge IDs and the lowest wins: here SW1 becomes the root bridge – the anchor of the whole tree.
  3. From the root we now measure how far each switch is (path cost). That decides which ports stay and which one is blocked – next module.

Port states

SW1SW2SW3PC1SRVforwarding

STP doesn’t switch off whole switches, but individual ports. A port can be in two main states: forwarding (passes traffic – normal operation) or blocking (does not pass traffic, only listens to STP messages so it knows if it should come up). So a blocked port isn’t "dead" – it’s a ready backup that just stays silent. (When switching over, a port passes through brief listening and learning states before it forwards – which is why classic STP takes a while.)

Step by step

  1. The ports on the tree are in forwarding state – they pass traffic normally. Data flows here.
  2. The redundant port (SW2–SW3) is in blocking state: it does not forward traffic but listens to STP. This breaks the loop.
  3. The blocked port isn’t dead – it’s a silent backup. Whenever needed, STP switches it to forwarding. (Classic STP takes a moment due to the listening/learning states – RSTP speeds that up, next lesson.)

Choosing the blocked port

SW1SW2SW3PC1SRVROOT

So which port gets blocked? STP computes the cost of the path to the root (by link speed – fast = cheap). On each link between two switches, the port of the switch that is closer to the root wins (it stays forwarding); the port of the further one is blocked. Ties are broken by the lower bridge ID. In short: at each loop STP keeps active the path that leads most cheaply to the root and sacrifices the "extra" one.

Step by step

  1. SW1 = root. SW2 and SW3 are one hop from it (a direct link). These links to the root stay forwarding.
  2. That leaves the extra SW2–SW3 link (the one that made the loop). Both its ends reach the root by another, better path. This link is spare.
  3. STP blocks it at the end of the switch that is "further" from the root (higher cost / higher bridge ID). The loop is gone, the best paths to the root remain. You set the link cost in the simulator yourself and watch the block move.

Failure and switchover

SW1SW2SW3PC1SRVSTP block

And now the best part – why we do all this. When the active link fails, STP detects it, recomputes the tree and switches the blocked port to forwarding. The backup comes up by itself and the network keeps running. You’ve got redundancy without a loop or a storm. You’ll try exactly this in the simulator: in the stp-loop task a loop is wired, STP has auto-blocked one port (you’ll see "STP block"), traffic still flows – and when you down the active switch, the backup comes up.

Step by step

  1. Normal state: the tree via SW1, the SW2–SW3 backup link blocked. PC1 reaches the SRV. All good.
  2. The SW1–SW3 link fails. SW3 (and the SRV) loses its path to the root. Normally an outage – but we have a backup.
  3. STP recomputes the tree and unblocks SW2–SW3 (switches it to forwarding). The SRV is reachable via SW2. The network healed itself.
  4. That’s all of STP: a backup without a loop, automatic switchover on failure. Open the stp-loop task and try it live – down a switch and watch the block move.

▶ Open in the simulator

Lesson 3: RSTP and PortFast

Why classic STP is slow

Classic STP: before a port forwards (~30–50 s)BlockingListening ~15 sLearning ~15 sFwd0 s~30–50 s

STP has one annoyance: it’s slow. Classic (original) STP makes a port pass through intermediate states – listening and learning – before forwarding, and each takes around 15 seconds. Together that’s 30 to 50 seconds before a backup comes up after a failure or a newly plugged device can communicate. In today’s networks that’s an eternity (a call drops, an app times out). Hence a faster version – RSTP (next module).

Step by step

  1. After a failure (or plug-in) the port starts in Blocking – it doesn’t forward, only listens.
  2. Then Listening (~15 s): the port listens to BPDUs but still doesn’t forward or learn MACs.
  3. Then Learning (~15 s): the port now learns MAC addresses but still doesn’t forward traffic.
  4. Only now Forwarding. The whole thing took 30–50 s – far too long. RSTP cuts it to ~a second (next module).

RSTP: rapid convergence

Classic STP: 30–50 sRSTPRSTP: ~1 sstill waiting…

RSTP (Rapid Spanning Tree, 802.1w) does exactly what STP does – just much faster. Instead of waiting for fixed timers, neighboring switches actively negotiate (a "proposal / agreement" handshake): one proposes "I’ll forward", the other agrees at once. Convergence drops from tens of seconds to a fraction of a second (~1 s). Today RSTP is the standard – you’ll rarely meet classic STP. The idea (root, blocked port) stays the same, only the speed differs. Besides RSTP there are other variants (e.g. MSTP for scaling and PVST+ from Cisco – a tree per VLAN, which is how this simulator computes it too); you don’t need to know them to grasp the principle.

Step by step

  1. Top: classic STP: the port comes up slowly (30–50 s) – the marker crawls across the whole bar. Bottom: RSTP: almost instant.
  2. RSTP doesn’t wait for timers – neighbors actively say "I forward / I agree" and the port comes up in ~1 second.
  3. The principle (root, blocked port, tree) is the same as STP – RSTP just greatly speeds up the switchover after a failure. That’s why it’s the default today.

PortFast

PCSWITCHaccess port – a PC on the other end, not a switch

Slow switchover hurts most on access ports – the ones an end device (PC, printer) plugs into. There no loop can form (there’s no switch on the other end), so it makes no sense to wait 30 seconds before a PC gets the network after powering on. PortFast lets such a port forward immediately – it skips the intermediate states. Result: the PC has the network right after plugging in. Note: PortFast belongs only on access ports to end devices, never between switches.

Step by step

  1. On this port there’s a PC, not a switch. No loop can form here. So why wait 30 s?
  2. With PortFast the port skips the intermediate states and forwards immediately. The PC has the network right after power-on.
  3. Key rule: PortFast only on access ports to end devices. If you put it between switches by mistake, you’d bring back the risk of an unguarded loop. That’s why PortFast is protected – next module.

BPDU Guard

foreign SWSWITCHPCaccess port + PortFast (a PC expected)

PortFast is fast but trusting – it assumes an end device on the access port, not a switch. What if someone (by mistake or on purpose) plugs a switch into such a socket? An unguarded loop could form, or a foreign switch could take over the root-bridge role. BPDU Guard watches for this: a PortFast access port should never receive an STP message (BPDU). The moment one arrives, BPDU Guard shuts the port down immediately (err-disabled). Safe and simple.

Step by step

  1. An access port with PortFast – a PC is expected here. All fine, the port forwards immediately.
  2. But someone plugged a switch into that socket and it starts sending BPDUs. On a PortFast port that shouldn’t happen – a loop or root takeover looms.
  3. BPDU Guard reacts: the moment it sees a BPDU on a PortFast port, it shuts the port down. The foreign switch is cut off, no loop forms, the root stays yours. Safe.

▶ Open in the simulator

Lesson 4: EtherChannel

STP wastes bandwidth

SW-ASW-B2× 1 Gb/s cabled

STP saved us from a loop – but at a cost now visible. Between two switches you have two links (say 2× 1 Gb/s), yet STP blocks one. So although you ran two cables, you really use only one (1 Gb/s); the other just sits as a backup and wastes bandwidth. What if we could have a backup and use both links at once? That’s what EtherChannel solves.

Step by step

  1. You ran two cables between SW-A and SW-B – for backup and for performance. Logically you want 2 Gb/s.
  2. But STP blocks one link (else a loop). The second cable lies idle. You really have just 1 Gb/s – you paid for half of it for nothing.
  3. We want both: redundancy and full capacity. The fix: make the switches treat the two cables as one link – then there’s nothing to block. That’s EtherChannel (next module).

Bundle them into one

SW-ASW-B

EtherChannel (a.k.a. "port channel" or link aggregation) bundles several physical links into one logical link. Both switches agree to treat those, say, four cables as one big port. What follows: STP sees only one link → nothing to block → no waste. The bandwidth adds up (4× 1 Gb/s = up to 4 Gb/s). And if one cable in the bundle breaks, the others carry on (just at lower capacity) – redundancy is built in. One clever trick solves performance and backup at once.

Step by step

  1. Several cables run between the switches (four here). Without EtherChannel STP would keep only one active.
  2. EtherChannel bundles them into one logical link. Both switches now treat them as one port.
  3. STP now sees one link → blocks nothing. Traffic flows over all the cables, capacity adds up (4× 1 Gb/s). No waste.
  4. And if one cable breaks, the bundle runs on over the rest (just at lower capacity). Redundancy and performance in one. How the bundle forms is the next module (LACP).

LACP

SW-ASW-BLACP: "shall we bundle?" – "yes"

How do the switches know to bundle those cables? You can set it statically by hand on both ends – but if you slip up (one side has the bundle, the other doesn’t), a loop forms. Safer is LACP (Link Aggregation Control Protocol): both switches exchange messages and agree to aggregate the links. The bundle forms only if both sides agree. If not, the ports stay separate (and STP guards them). That’s why in practice LACP is used, not manual config.

Step by step

  1. The switches exchange LACP messages: "want to aggregate these ports?" When both sides agree…
  2. …the bundle forms. Safely – both sides have it the same, so no loop from a misunderstanding.
  3. And if only one side agreed, LACP won’t form the bundle – the ports stay separate and STP guards them. That’s why LACP is safer than manual config.

Load balancing

SW-ASW-B

One last question: with several cables in the bundle, how is traffic split between them? EtherChannel uses a hash of the addresses (source/destination IP or MAC): by it each connection gets one specific cable from the bundle. This spreads the traffic so no cable is overloaded. Note: a single flow (one transfer) always uses just one cable – so one huge transfer won’t go faster than a single link; the benefit is in the sum of many connections. And as you know, if one cable fails the hash is recomputed and it carries on.

Step by step

  1. Several connections (different colors) are split between the cables by an address hash – each connection gets its own cable. Traffic is spread evenly.
  2. But note: a single flow (one big transfer) still uses one cable. EtherChannel speeds up the sum of many connections, not one giant file.
  3. When one cable fails, its connections are re-hashed onto the remaining cables and carry on. Redundancy, performance and balancing – that’s EtherChannel in full.

▶ Open in the simulator

Lesson 5: Trunks in depth and synthesis

VLAN pruning

TRUNKSW-ASW-BV10 V20 V30V10 V20

A trunk by default carries all VLANs. But not every switch needs every VLAN. Here SW-B has no VLAN 30 – yet broadcasts from VLAN 30 would still be dragged to it over the trunk, where they have no business (wasting bandwidth and loading SW-B). VLAN pruning prevents this: on the trunk you allow only the VLANs the other side actually uses. Less needless traffic, a cleaner network.

Step by step

  1. SW-A has VLANs 10, 20, 30. SW-B only 10 and 20 (no VLAN 30 at all). The trunk between them carries all by default.
  2. A VLAN 30 broadcast is still dragged over the trunk to SW-B – which has no VLAN 30 at all. Wasted bandwidth and load.
  3. Pruning: you allow only V10 and V20 on the trunk. VLAN 30 is no longer carried over it – its broadcasts stay where they belong. A cleaner, faster network.

Native VLAN and VLAN hopping

SW-ASW-Battackersecret VLANtrunk native = VLAN 1 (✗) = attacker VLAN

Recall the native VLAN from the Switching and VLANs course (untagged traffic on a trunk – otherwise VLANs on a trunk are told apart by a tag carrying the VLAN number). Here’s a security trap: when the trunk’s native VLAN is left as the default VLAN 1 – the same VLAN an attacker can sit in – the attacker can do VLAN hopping (more in the switch in depth course) – by "double-tagging" a frame they slip into a foreign VLAN they shouldn’t reach (the first switch strips the outer tag because it matches its native, exposing the inner one – step by step below). Defence: use a dedicated unused VLAN for the native VLAN (not VLAN 1 where users sit), set it the same on both ends and ideally forbid untagged traffic on the trunk.

Step by step

  1. The trunk’s native VLAN is left as the default VLAN 1 – the same one the attacker sits in. That’s the hole the attack exploits.
  2. The attacker crafts a frame with TWO 802.1Q tags: an outer VLAN 1 (the trunk native) and beneath it an inner VLAN 20 (the secret target VLAN).
  3. SW-A looks at the outer tag = VLAN 1 = its native → it strips the tag and forwards the frame over the trunk. The inner tag VLAN 20 is now exposed.
  4. SW-B reads the remaining VLAN 20 tag and delivers the frame to the secret VLAN the attacker shouldn’t reach. VLAN hopping – and it’s one-way (no reply returns the same way).
  5. Defence: native VLAN the same on both ends, set to an unused VLAN (not VLAN 1). Then the outer tag has nothing to abuse and the attack fizzles.

A redundant network together

DIST-1DIST-2ACC-AACC-BPCSRVEtherChannel (full capacity)

Let’s put it together into a resilient network. Two distribution switches (DIST-1, DIST-2) joined by an EtherChannel (full capacity); below them access switches (ACC-A, ACC-B) with PCs and servers attached. Each access switch is connected twice upward (to both distribution switches) – so if one path or switch fails, there’s another. And to stop those doubled links making a loop, STP/RSTP guards them (blocking the spare and switching over after a failure). Redundancy at every level, no storm.

Step by step

  1. At the top two distribution switches, joined by an EtherChannel – both links used, redundancy inside the bundle.
  2. Below, access switches with PCs and servers. Each is dual-homed upward – to both distribution switches. If one fails, the other holds.
  3. Those doubled uplinks form loops – so STP/RSTP guards them: it keeps one blocked (backup) so no storm erupts.
  4. The result: no single point of failure at L2. EtherChannel gives capacity, dual-homing and STP/RSTP give resilience. What happens on a failure is the last module.

Failure and what’s next

DIST-1DIST-2ACC-AACC-B

The design’s final exam: something fails. Say switch DIST-1 or its link. In a flat network without redundancy that would mean an outage. Not here: STP/RSTP recomputes the tree, unblocks the backup uplink and traffic flows within a second via DIST-2. The user doesn’t even notice. That’s the point of the whole course: redundancy + STP/RSTP + EtherChannel = a network that survives a failure. And what’s next? You have the L2 and L3 foundation; the journey continues with the OSPF in depth course and beyond – OSPF in depth and network security.

Step by step

  1. Normal state: ACC-A runs via DIST-1 (the main uplink), the backup uplink to DIST-2 is blocked.
  2. DIST-1 (or its link) fails. ACC-A’s main uplink is gone. In a network without a backup this would be an outage.
  3. But RSTP fixes it within a second: it unblocks the backup uplink, ACC-A now runs via DIST-2. No outage.
  4. And that’s all of the redundancy and STP course: you’ve built a network that survives a failure, and you understand how it does it. Congratulations – you have a solid L2 and L3 networking foundation. And it keeps going: the OSPF in depth course brings OSPF in depth, and network security follows. See you there!

▶ Open in the simulator