Which switch becomes the STP root bridge? The switch with the lowest bridge ID wins within the participating spanning-tree instance: compare the priority/system-ID field first, then the bridge MAC address if that field ties.[1] A faster uplink does not make a switch the root; path cost answers a different question—how another switch reaches the selected root.[1]
This guide uses a fictional three-switch VLAN to separate root election from root-port selection, then shows what to check on Cisco IOS/IOS XE-style switches. The example is a conceptual exercise, not output from an executed lab.
What is the bridge ID?
With the extended system ID, the bridge ID contains a configurable priority component, a system-ID extension, and a MAC address; in PVST+ and Rapid PVST+, the extension identifies the VLAN.[1] The bridge ID is eight bytes overall, with six bytes used for the MAC address.[1]
| Component | What to compare | Practical consequence |
|---|---|---|
| Configurable bridge priority | Lower is preferred | Select the intended root deliberately.[1] |
| Extended system ID | VLAN ID for PVST+/Rapid PVST+ | Compare switches within the same VLAN, not unrelated VLAN outputs.[1] |
| Bridge MAC address | Lower wins when the preceding field ties | Default priorities leave the election to the MAC address.[1] |
On the Cisco platform documented here, the default configured priority is 32768 and configurable priorities use increments of 4096.[1] The displayed priority includes the VLAN extension, so a configured priority of 8192 in VLAN 10 appears as 8202; this is the configured value plus the VLAN ID, not an unexpected configuration change.[1]
Scope matters: PVST+ and Rapid PVST+ run a tree per VLAN, whereas MST maps VLANs to spanning-tree instances.[1] This walkthrough is a single PVST+/Rapid PVST+ VLAN, not an explanation of MST boundary behavior.
Root election process: follow the BPDUs
BPDUs carry the advertised root ID, root path cost, sending bridge ID, port identifier, and timing information.[1] A useful conceptual sequence is:
- Start with self as root. Before learning better information, a switch advertises itself as the root.[1]
- Compare received information. A lower advertised root ID is superior, so the switch updates its view when it learns of a better root.[1]
- Propagate the better root information. Participating switches communicate the improved information through BPDUs until the connected topology agrees on the root.[1]
- Select the paths. Non-root switches select a root port toward that root, with root path cost central to that decision; STP also chooses designated ports and suppresses redundant forwarding paths.[1]
Do not describe this as a vote or a comparison of switch CPU capacity. The root identity comes from bridge-ID comparison, while port roles come from comparing the path information.[1]
Worked example: why the lowest MAC does not always win
Assume three fictional switches participate in VLAN 10, exchange BPDUs correctly, and have no policy preventing the election. The addresses below are invented for this exercise.
| Switch | Configured priority | Displayed priority for VLAN 10 | Bridge MAC |
|---|---|---|---|
| Distribution-A | 8192 | 8202 | 0200.0000.0030 |
| Distribution-B | 16384 | 16394 | 0200.0000.0020 |
| Access-C | 32768 | 32778 | 0200.0000.0010 |
Applying the bridge-ID rule, Distribution-A wins despite having the highest MAC address in the example, because its priority field is lower.[1] If all three instead use the default priority for VLAN 10, Access-C wins the tie through its lower MAC address.[1]
Changing an uplink cost on Access-C can affect its preferred path toward the root, but it does not change the bridge IDs and therefore does not make Access-C the root.[1] Keep these two troubleshooting questions separate:
- Wrong root switch? Inspect bridge priority and bridge ID first.
- Correct root, unexpected uplink? Inspect root path cost and the port-selection information first.
These are suggested diagnostic starting points, not a substitute for checking the full topology.
Cisco configuration: choose an intended primary and backup
For this fictional VLAN, explicit priorities make the intended ordering easy to review. The syntax follows Cisco's documented per-VLAN priority configuration; confirm support on your platform and release before use.[1]
On Distribution-A:
configure terminal
spanning-tree vlan 10 priority 8192
end
On Distribution-B:
configure terminal
spanning-tree vlan 10 priority 16384
end
With the remaining switches at default priority and normal BPDU connectivity, this produces the ordering in the table.[1] These values are example design choices, not universal best-practice numbers. Record the current root and expected affected VLANs before changing production priorities, and use a controlled change window.
Cisco also provides spanning-tree vlan 10 root primary and spanning-tree vlan 10 root secondary as priority-setting conveniences.[1] The documented secondary command sets priority to 28672, while primary selects a lower value based on the existing root information.[1] Neither command creates a separately negotiated standby-root role: future elections still compare bridge IDs.[1]
What if a better switch joins, or the root fails?
In ordinary STP operation, superior root information can change the selected root; a newly connected switch with a lower bridge ID can therefore displace the existing root.[1] Do not assume the first switch to boot keeps the role permanently.
If Distribution-A disappears in the fictional example and the surviving switches remain connected, Distribution-B has the best remaining bridge ID and becomes the root after failure detection and reconvergence.[1] The configured backup is not guaranteed to win against an unknown switch with an even lower bridge ID.[1]
For practice, predict the root before disconnecting anything. In an isolated lab, remove the current root, observe the replacement, and then reconnect the original root to test your prediction. Do not claim a fixed outage duration without measuring the actual topology and protocol behavior.
Verification and troubleshooting checklist
Start with the documented Cisco spanning-tree display commands; supported options vary by platform.[1]
show spanning-tree vlan 10
show spanning-tree summary
show spanning-tree detail
Use this suggested checklist on the intended root and at least one neighboring switch:
| Check | Evidence to collect | Question to answer |
|---|---|---|
| Mode and scope | STP mode, VLAN or instance | Are all observations about the same tree? |
| Root identity | Root ID priority and address | Do the connected switches agree on the intended root? |
| Local identity | Bridge ID priority and address | Is a lower-priority competitor winning legitimately? |
| Root versus local | Compare complete Root ID and Bridge ID | Does the intended root identify itself as root? |
| Path selection | Root port, cost, neighboring port roles | Is the root correct but the route toward it unexpected? |
| Connectivity | VLAN presence, trunks, link state, BPDU counters and relevant protection configuration | Can root information reach the affected switch? |
If two supposedly connected switches both believe they are root for the same VLAN, investigate the connection between their STP views before repeatedly lowering priorities. Suggested checks include missing VLANs, trunk restrictions, disabled STP, BPDU filtering, or protection state; confirm the actual cause from device evidence.
Common interview pitfalls
- “Lowest MAC wins.” Only after the priority/system-ID field ties.[1]
- “Highest priority wins.” Say lowest numerical bridge priority to avoid ambiguity.[1]
- “The fastest switch becomes root.” Root election uses bridge identity, not uplink bandwidth.[1]
- “There is one root for the whole physical network.” State the VLAN or spanning-tree instance being discussed.[1]
- “Secondary means an STP backup-root state.” It is a Cisco configuration convenience that changes bridge priority.[1]
- “Lowering port cost elects a new root.” It influences path selection, not the bridge identity used in root election.[1]
A concise interview answer
“STP elects the switch with the lowest bridge ID for the relevant spanning-tree instance, comparing priority and the system-ID extension before using the MAC address as the tie-breaker.[1] Switches learn the preferred root through BPDUs; non-root switches then choose their best path toward it.[1] I configure priorities deliberately and verify Root ID, Bridge ID, and root-port information rather than relying on default MAC-address ordering.”
Related reading
- OSPF DR/BDR election: a separate election mechanism
- LACP load balancing: why one flow uses only one link
Summary
Choose the root by bridge ID; choose the path toward it using path information. That distinction is the core of the interview question.[1]
Preparing for a network engineering interview? Draw three switches, assign priorities and MAC addresses, and explain who wins before and after a failure—then validate your reasoning in an isolated lab.
Post a Comment