skip to content

How do 802.1D spanning-tree bridges agree on a single root bridge, and how is one bridge ID judged better than another?

level: middleimportance: must knowfreq 38%

answer

  1. everyone claims the crown at first
  2. a lower root ID overrides
  3. eight octets read as one number
  4. relay the best root heard

basics

~20 s

Every bridge starts by claiming to be root and advertising its own bridge ID. A bridge that hears a lower root ID adopts it and relays it; bridge IDs compare as one number, priority first, MAC second, lowest winning.

solid answer

~40 s

At start-up each bridge assumes it is the root: it puts its own bridge ID in the Root Identifier of the Configuration BPDUs it sends, with a root path cost of zero. When a bridge receives a BPDU naming a lower root ID than the one it holds, it accepts that bridge as root, stops advertising itself as root, and passes the better root ID on toward the segments it serves, adding its own cost. The bridge ID is 8 octets, a 2-octet priority then a 6-octet MAC address in network byte order, so comparing it as one unsigned number checks priority first and uses the MAC only to break a tie. Soon every bridge reports the same root ID, which RFC 4188 exposes as `dot1dStpDesignatedRoot`, the quickest check that the tree agrees.

code

pseudocode · 14 lines
pseudocode
# bridge ID = 16-bit priority field, then 48-bit MAC, read as one number
bid(b) = (b.priorityField << 48) | b.mac

on_start():
    rootId = bid(self)
    rootCost = 0
    send Configuration BPDUs claiming rootId

on_configuration_bpdu(port, bpdu):
    if bpdu.rootId < rootId:
        rootId = bpdu.rootId          # accept the better root
        stop claiming to be root
        recompute the path toward rootId
        relay rootId on the segments this bridge serves

go deeper

for a junior

Remember that every bridge first claims to be root and that the lowest bridge ID, priority then MAC address, is the one everyone ends up repeating.

for a middle

Walk the election: own-ID claims, overruling on a lower Root Identifier, relaying the winner. Show why reading the 8 octets as one number puts priority ahead of the MAC address.

for a senior

Show that the election is continuous: a newcomer with a lower ID or a failed root triggers re-election and path recomputation, and explain how you confirm agreement from each bridge's reported root.

for a principal

Frame the absence of incumbency as a design property: anything that can send a lower bridge ID can reshape the domain, so root placement and the protection of that choice belong in network policy.

## The bridge ID as a number Spanning tree needs every bridge to agree on one **root bridge** without any central coordinator. It does that with a value every bridge already has, its **bridge ID**, and one rule: the **lowest bridge ID wins**. RFC 4188 describes the bridge ID as **8 octets**: - the first **2 octets**, in network byte order, hold the **priority**; - the last **6 octets** hold the bridge's **MAC address**, which must be unique. Read as a single unsigned 64-bit number, the priority occupies the most significant bits. Comparing two bridge IDs therefore compares their priorities first, and the MAC addresses matter only when the priorities are equal. Since MAC addresses are unique, two different bridges can never tie. ## The election, step by step The election is carried in **Configuration BPDUs**, the hello messages bridges exchange; their exact layout and timers are a separate subject. The part that matters here is the **Root Identifier** each one carries, the bridge ID of the root as the sender currently believes it to be. 1. **Everyone claims.** When a bridge starts, it knows of no better bridge, so it considers itself root: it sets its root ID to its own bridge ID, its root path cost to zero, and sends Configuration BPDUs saying so. 2. **A better claim wins.** When a bridge receives a BPDU whose root ID is lower than the root ID it holds, it records that bridge as root and stops claiming the role for itself. 3. **The winner's claim is relayed.** The bridge passes the better root ID on in the BPDUs it sends toward its other segments, with its own root path cost filled in. 4. **The lowest ID spreads everywhere.** Any bridge holding a worse root ID is overruled as soon as the better claim reaches it, so the lowest bridge ID in the layer-2 domain propagates to every bridge. 5. **Agreement.** The election has settled when every bridge reports the same root ID. From there, each bridge works out its best path toward that root, which is the next step of the protocol, not part of the election. Root path cost plays no part in choosing the root. It is compared only between BPDUs that already name the same root, when a bridge picks its path toward it. ## A worked comparison | Bridge | Priority (hex) | MAC address | Ordering | |---|---|---|---| | B1 | 32,768 (`0x8000`) | `00-00-5E-00-53-20` | third | | B2 | 32,768 (`0x8000`) | `00-00-5E-00-53-10` | second | | B3 | 28,672 (`0x7000`) | `00-00-5E-00-53-30` | **first: root** | B3 has the highest MAC address of the three and still wins, because `0x7000` is lower than `0x8000` and priority is compared before the address. Between B1 and B2, whose priorities are equal, the MAC decides and B2 ranks ahead. If B3 were removed, B2 would become root. Written out as 16 hexadecimal digits, B3 is `7000 00005E005330`, B2 is `8000 00005E005310` and B1 is `8000 00005E005320`. Reading left to right, the first digit that differs decides, exactly as when comparing two ordinary numbers. ## The election never ends There is no incumbency. The comparison runs every time a BPDU arrives, so: - a bridge that joins later with a lower bridge ID **takes the root role** as soon as its BPDUs are heard; - if the root fails, bridges stop receiving fresh root information; under 802.1D the stored information ages out after **Max Age** (20 seconds by the IEEE default), the bridges fall back to claiming root themselves, and the lowest remaining bridge ID wins; - every change of root makes every bridge recompute its paths, so a root change is a disruptive event, not a cosmetic one. That is why designs set a deliberate primary and secondary root rather than trusting whatever bridge IDs the hardware happens to carry. ## Checking agreement RFC 4188 gives each bridge a `dot1dStpDesignatedRoot` value, the root it currently believes in, which is also the Root Identifier it uses in the Configuration BPDUs it originates, and a per-port `dot1dStpPortDesignatedRoot`, the root named by the bridge that serves each segment. Comparing them across switches shows at a glance whether the domain agrees on one root, and which bridge that is.

  • Under 802.1D, what happens to the election if the current root bridge loses power?
    The other bridges stop receiving fresh root information. Bridges that do not see a link go down keep the stored information until it ages out after Max Age, 20 seconds by the IEEE default; then they claim root again and the lowest remaining bridge ID wins. A deliberate secondary root with the next-lowest priority makes that outcome predictable.
  • Is the root bridge always the bridge with the lowest MAC address in the network?
    No. Priority is compared first, so a bridge configured with a lower priority wins even if its MAC address is the highest in the network. The MAC address decides only among the bridges that share the lowest priority value.

A room where everyone starts by announcing their own ticket number as the lowest, and switches to repeating any lower number they hear. Soon everyone repeats the same number, the lowest ticket in the room, and a newcomer holding a lower ticket can still take over.

saying these in an interview costs you the question

  • The root is elected once at power-up and then never changes.
  • Bridge priority is compared only after the MAC address.
  • The highest bridge ID wins, just as in the OSPF designated-router election.
  • Only the root bridge sends BPDUs, even at start-up.
  • Root path cost decides which bridge becomes the root.