With spanning tree disabled, a second patch cable joins two access switches; what does one ARP broadcast do, and why does the storm never stop?
answer
- flood out every port but one
- copies return on the other cable
- one copy per direction, re-sent at wire speed
- source address seen on the wrong port
- nothing in the frame expires
basics
~20 sEach switch floods the broadcast out the other cable, so two copies circle the loop indefinitely, reaching every host on each pass. Hosts receive duplicates, both switches keep relearning the sender's MAC on the looped ports, and links and CPUs saturate.
solid answer
~50 sHost H1 on switch A sends an ARP request to the broadcast address. A floods it out every port except H1's, including both cables to switch B. B floods each copy out every port except the one it arrived on, so the copy from cable 1 goes back to A on cable 2 and vice versa, and A floods them again. Two copies now circle in opposite directions at wire speed, re-delivered to every host on both switches on each pass. Because a switch records a frame's source against its arrival port, both switches keep moving H1's MAC entry between ports, so traffic for H1 is misdirected, and unknown-destination unicast flooded down both cables arrives twice. Every new broadcast adds two more permanent copies until links and CPUs saturate. Nothing ends it: Ethernet has no hop count and switches don't remember frames. Only cutting a cable does.
go deeper
Be able to trace one broadcast: flooded out both cables, sent back by the other switch, round again. State the cause in one breath: no TTL in Ethernet, so only cutting a cable stops it.
Walk the frames step by step, then tie each symptom to its mechanism: flooding gives the storm and duplicates, source learning gives the MAC flapping, and every new broadcast adds more copies.
Distinguish circulation from multiplication: two parallel cables keep one copy per direction, while three or more looped ports per switch multiply copies. Explain why ageing and congestion never clear the loop.
Use the scenario to argue for defence in depth: spanning tree on every switch, edge-port protections and broadcast limits, because one stray cable can take down an entire broadcast domain.
## The setup Two **access switches**, A and B, are already joined by one cable. Someone patches a **second cable** between them, and **spanning tree is off**, so both inter-switch ports on each switch forward everything. Host **H1** sits on switch A; hosts H2 and H3 sit on switch B. H1 wants to reach H2 and broadcasts an **ARP request** (RFC 826) to `ff:ff:ff:ff:ff:ff`. Two switch behaviours drive what follows: - **Flooding**: a broadcast, or a frame for an unlearned destination, leaves on **every port except the one it arrived on**. - **Source learning**: a switch records each frame's **source MAC** against the port it arrived on, overwriting any earlier entry. ## Frame by frame 1. H1's request reaches A on H1's access port. A learns H1 there and floods the frame to its other hosts and out **cable 1** and **cable 2**. 2. B receives copy X on cable 1. It floods X to H2, H3 and out **cable 2**, back to A. 3. B receives copy Y on cable 2. It floods Y to H2, H3 and out **cable 1**, back to A. 4. A receives X on cable 2 and floods it to its hosts (H1 included) and out **cable 1** to B. Y arrives on cable 1 and leaves on cable 2. 5. Steps 2 to 4 repeat. X travels A to B on cable 1 and back on cable 2; Y circles the other way. Each switch here has exactly **two** ports in the loop, so a copy that arrives on one leaves on the other: the copies **circulate without multiplying**. Each pass takes only microseconds, so those two copies are re-delivered to every host port thousands of times per second. H2 answers each copy it receives, adding unicast load, but nothing removes the request. Where a switch has **three or more** ports in the looped topology (a third cable, or a ring with a cross-link), one arriving copy leaves on two or more looped ports, and the number of copies **multiplies on every pass**. That is the exponential storm usually described; the two-cable case reaches saturation by accumulation instead. ## What the network sees | Symptom | Mechanism | |---|---| | **Broadcast storm** | Every broadcast or flooded multicast (ARP, DHCP, service discovery) adds two copies that never expire; inter-switch links fill to line rate. | | **Duplicate frames** | A unicast frame for an unlearned destination is flooded down both cables, so the destination receives two copies. | | **MAC flapping** | A sees H1's source address arrive from H1's port, then cable 2, then cable 1; B sees it on cable 1, then cable 2. Each arrival overwrites the entry. | | **Misdirected unicast** | While A's entry for H1 points at a cable, H2's ARP reply to H1 is sent back towards B, or discarded, instead of reaching H1. | | **CPU exhaustion** | Each host's network stack processes every broadcast copy; each switch's management processor receives broadcasts for its own address and churns through MAC moves. | The flapping is often the first clue an operator sees: the switch logs the same MAC address **moving between two ports** many times a second. ## Why the storm never stops on its own - **No lifetime field.** The Ethernet header has no TTL or hop count, so no switch is ever told to discard a copy. IP packets in a routing loop die when `TTL` or `Hop Limit` reaches zero; frames do not. - **No memory of frames.** A switch keeps a table of addresses, not of frames it has relayed, so a returning copy is flooded like a new one. - **Ageing doesn't help.** Entries age out only after a period of silence. The default the IEEE 802.1D standard recommends, restated in RFC 4188's Bridge MIB, is 300 seconds. The looping copies re-teach the table continuously, so the wrong entries never go stale. - **Congestion doesn't help.** When the links saturate, queues drop some copies, but the survivors keep circulating and every new broadcast refills the loop. The storm ends only when a link in the loop is cut, whether the cable is unplugged, a port is shut down, or a protocol blocks a port. ## The principle that prevents it The cure is a **loop-free logical tree** laid over the **redundant physical mesh**. Spanning tree has the switches exchange **BPDUs**, the discovery messages that reveal the second cable, and then puts one end of the redundant link into a blocking condition. That port discards data frames but keeps listening for BPDUs. With cable 2 blocked at one end, H1's broadcast crosses to B once, is flooded to B's hosts, and stops. If cable 1 later fails, the BPDUs change and the blocked port takes over.
- In that two-switch, two-cable Ethernet loop, why do the copies not multiply, and when would they?Each switch has exactly two ports in the loop, so a copy arriving on one cable is flooded out only the other cable, plus the access ports, which end there. One copy per direction circulates. Add a third cable or a cross-link so that a switch has three looped ports, and each arriving copy leaves on two looped ports, so the count multiplies on every pass.
- In that two-switch Ethernet loop, why can other hosts fail to reach H1 even before the links saturate?The switches' entries for H1 keep being overwritten by looping copies of H1's own frames, which arrive on the inter-switch cables. Unicast for H1 is then sent back towards the other switch, or discarded, instead of leaving on H1's port. Each frame H1 sends briefly corrects the entry on its own switch, but the next looping copy moves it again within microseconds.
- Would raising the MAC ageing time or lowering it cure the flapping in an Ethernet loop?Neither. Ageing removes entries only after silence, and the looping copies are never silent; they re-teach the wrong port on every pass. A shorter ageing time just floods more unknown unicast into the loop, and a longer one changes nothing. Only breaking the loop stops the overwrites.
saying these in an interview costs you the question
- A switch drops a frame it has already forwarded once.
- With two parallel cables, every broadcast doubles on each pass.
- The storm stops once the MAC address tables age out.
- Only the host that sent the broadcast is affected by the loop.
- MAC flapping means two hosts are configured with the same IP address.