Skip to content

W3·A3 — Stopping broadcast storms

Time: 30 min

Needs: two OL9 Switches + 4 VPCS

GNS3 project: w03-a3-stp

Info

Times listed are approximate and provided as timing guidelines only. Take as much time as you need to complete the activity.

Question

What happens when you introduce a physical loop in the network?

Warning

This activity deliberately creates a broadcast storm. Nothing is damaged, but the topology may become unusable if kept running for a long time. Know how to stop the nodes from the toolbar before you start.

Build it

  • Start by running two cables between them, using their first two interfaces, i.e.:
    • SW1.Ethernet0 -> SW2.Ethernet0
    • SW1.Ethernet1 -> SW3.Ethernet1
    • Don't cable the PCs yet. You will do that in the next step

  • With SW2 still down, start and configure SW1 similar to how you configured the bridge in A1

    • STP is enabled by default. Disable it:

      nmcli con mod br0 bridge.stp no

    • Then, disable one of the links: 

      ip link set dev eth0 down
      - Now start and configure SW2 similar to how you configured the bridge in A1 - Disable STP:

      nmcli con mod br0 bridge.stp no

  • Start a capture on the SW1.Ethernet1-SW2.Ethernet1 cable

On SW1, enable the first cable, while still watching the capture: 

ip link set dev eth0 up

Immediately, right-click on SW2 and pause it.

What just happened

  • The moment we enabled the second link, the network was flooded by a single packet that bounced between the two switches at a very high rate. The packet itself was a multicast which behaves similar to broadcast in Layer 2.
  • Stop the topology if you haven't done so already, otherwise Wireshark might fill your disk very quickly.
  • This is a serious problem. On the one hand, we need redundant links so that one link going down doesn't take the entire network with it. On the other hand, the broadcast storm we just witnessed.
  • This is what the Spanning Tree Protocol is designed to solve.

Do this - Fix it

First, take the link down, temporarily. On SW1: 

ip link set eth0 down

Then, on both SW1 and SW2, enable STP: 

nmcli con mod br0 bridge.stp yes

Re-enable the link. On SW1: 

ip link set eth0 up

bridge link show

What just happened

  • With STP enabled, the storm stopped.
  • Look closer at the output of bridge link show on SW1. One of the link is in blocking state.
    • STP prevents broadcast storms by detecting redundant links and proactively disabling them while still keeping the network as whole reachable.

Do this — Bring the full network up

Cable the four PCs:

  • PC1 and PC2 on SW1
  • PC3 and PC4 on SW2

Start them and assign them addresses in the 192.168.10.x range.

Run a few pings to ensure they can all reach the other three.

On SW1, bring one link down again: 

ip link set dev eth0 down
bridge link show

Run the pings again and verify that traffic is still going through

What just happened

  • We deliberately bring one link down and traffic keeps going through
    • Look closely at the output of bridge link show. The link that was in blocking state earlier is not now forwarding.
    • This is STP at work, and it happens instantly.

If it went wrong

Symptom Cause Fix
GNS3 unresponsive during Part 2 broadcast storm clic the big red button in the toolbar to stop the topology, then bring one link down before you restart it
No storm at all STP still enabled nmcli con mod br0 bridge.stp no