What happens to an 802.1D spanning tree when someone plugs in a new switch whose bridge ID is lower than the current root's?

## Why a new switch can take over The spanning-tree root election has **no incumbency**. Every bridge compares the Root Identifier in each BPDU it receives with the root it currently holds, and a lower one always wins. Seniority, uptime and position count for nothing. So a switch that joins later with a lower **bridge ID** (2-octet priority, then 6-octet MAC address, lowest winning) takes the root role as soon as its claim is heard. Nothing in the protocol asks whether the newcomer is welcome; a BPDU with a lower Root Identifier is simply believed. That newcomer is rarely malicious. Common causes: - a switch from a manufacturer whose MAC addresses sort lower, plugged in at the **default priority** of 32,768 in a network where nobody tuned the root; - a lab or spare switch whose configuration still carries a **low priority** from a previous job; - a **replacement unit** configured from a copy of the core switch's settings and connected in a closet. ## The sequence under 802.1D 1. The new switch starts by claiming to be root and sends Configuration BPDUs naming itself. 2. Its neighbour compares that Root Identifier with the current root's, finds it lower, accepts the newcomer as root and relays the claim to its other segments. 3. The better claim spreads hop by hop until every bridge names the new switch as root. 4. Every bridge recomputes its path toward the new root, so many ports change role. 5. **Ports that must block** go to blocking at once, so traffic using them stops immediately. 6. **Ports that must start forwarding** pass through **listening** and **learning**, each lasting Forward Delay, about **30 seconds** in total at the IEEE default of 15 seconds. 7. The change is signalled as a **topology change**, and bridges age their MAC entries after Forward Delay instead of the normal ageing time (300 seconds by default, RFC 4188), so unknown destinations are flooded until tables refill. A faster protocol version replaces the timed waits of steps 5 and 6 with an explicit handshake between neighbours, but the topology still re-points toward the new root and MAC tables are still flushed. ## What users see | Effect | Cause | Typical scale under 802.1D | |---|---|---| | Traffic loss on re-routed paths | ports waiting in listening and learning | about 30 seconds | | Flooding and extra load | MAC entries aged out after the topology change | until tables refill | | Lasting slowness | forwarding now radiates from an edge switch on thin links | until the root is fixed | | A second outage later | unplugging the newcomer triggers another re-election | can approach 50 seconds | The last row surprises people. When the newcomer is removed, bridges that do not see a link go down still hold information naming it as root. That information has to age out after Max Age (20 seconds by the IEEE default) before they re-elect, and then the ports wait through listening and learning again, so the second disruption can be longer than the first. ## Prevention | Measure | What it does | What it does not do | |---|---|---| | Primary root at a low priority, for example 24,576 | a default-priority newcomer can no longer win | stop a newcomer configured even lower | | Secondary root at the next value, 28,672 | keeps the root at distribution if the primary fails | protect against a misconfigured newcomer | | A guard on edge and downstream ports | refuses a superior root claim from where none belongs | replace deliberate root placement | - Setting the intended root to **priority 0** is not a lock: another bridge at 0 with a lower MAC address still wins. - Port-level guards that refuse BPDUs or superior root claims on access ports are separate features, with their own placement rules. - Do not rely on new hardware having a higher MAC address than the old: address order is a tendency of each manufacturer, not a guarantee. ## How to tell it happened RFC 4188 gives each bridge a `dot1dStpDesignatedRoot` (the root it believes in), a `dot1dStpTopChanges` counter and a `dot1dStpTimeSinceTopologyChange` timer. A root ID that belongs to none of your distribution switches, or a topology-change count that jumped when users complained, is the signature of an unplanned root change.