Every spanning-tree-enabled switched network or broadcast domain has a single switch designated as the root bridge. It serves as the reference point for every spanning-tree-enabled switch in that broadcast domain, and the spanning tree algorithm uses it to determine which redundant paths to block, preventing Layer 2 loops. The root bridge is chosen through an automatic election process every time the topology forms or changes.
The Bridge ID (BID)

The figure below illustrates the Bridge ID (BID) fields. The BID is a unique identifier for each switch participating in spanning tree, and it is what the entire root election process actually compares. It is a 64-bit field divided into three parts:
- Bridge Priority — 4 bits, configurable in increments of 4096 (values from 0 to 61440), with a default of 32768
- Extended System ID — 12 bits, used to carry the VLAN ID in Per-VLAN Spanning Tree (PVST+) environments
- MAC Address — 48 bits, the switch’s unique hardware address
4 bits + 12 bits + 48 bits = 64 bits total. The Bridge Priority field is administrator-configurable, while the MAC address is fixed and globally unique to each switch, and together they guarantee every switch has a unique Bridge ID even when priorities are left at their default value.
Why the Extended System ID matters: In Per-VLAN Spanning Tree (PVST+), each VLAN runs its own independent spanning tree instance, and in principle each instance needs its own Bridge ID. Since a switch has only one MAC address, without the Extended System ID field encoding the VLAN number directly into the BID, every VLAN instance on the same switch would compute an identical Bridge ID, breaking independent per-VLAN root election entirely. The Extended System ID solves this by embedding the VLAN ID into the BID itself, so each VLAN’s spanning tree instance has a genuinely distinct Bridge ID even though the underlying MAC address is shared.
Root Bridge Election
When switches boot, every switch initially assumes it is the root bridge and begins sending configuration BPDUs every 2 seconds by default (the Hello Time). Each BPDU carries the sending switch’s own Bridge ID along with the Root ID it currently believes is the best (lowest) in the network.
Adjacent switches receive these BPDU frames and compare the advertised Root ID against their own. If the Root ID in a received BPDU is lower than the receiving switch’s current Root ID, the receiving switch updates its own Root ID to match, effectively agreeing that the sending switch (or whichever switch that BPDU is ultimately advertising) is a better candidate for root bridge.
Critically, the eventual root bridge doesn’t need to be directly adjacent to every switch in the topology; the lowest Bridge ID propagates outward, hop by hop, via BPDU frames, until every switch in the broadcast domain has converged on agreement about which single switch has the lowest BID overall. That switch, with the lowest Bridge ID in the entire broadcast domain, is elected the root bridge for that spanning tree instance.
Election by Priority, Then by MAC Address
The Bridge ID comparison always considers Priority first, then MAC address as a tiebreaker. Before any manual configuration, every switch uses the same default priority of 32768, which means the priority portion of the comparison is tied by default across the entire topology. When priority is tied, the election falls through to the second half of the comparison: the switch with the numerically lowest MAC address wins and becomes the root bridge.
In a topology where three switches all remain at the default priority of 32768, the switch with the lowest MAC address among them becomes the root bridge. Once elected, all of the root bridge’s own ports transition into the designated port role and enter the forwarding state — the root bridge itself never has a root port, since by definition it doesn’t need a path toward a “better” root; it is the root.
Configuring the Root Bridge Manually
Relying on the default MAC-address tiebreaker to determine the root bridge is generally poor practice in production networks, since it can place the root bridge on an arbitrary access-layer switch rather than a purpose-selected, well-connected core or distribution switch, leading to suboptimal traffic paths and unnecessary added latency across the topology.
Setting Bridge Priority Directly
Switch(config)# spanning-tree vlan 10 priority 4096
This sets the bridge priority for VLAN 10 to 4096 on this switch. Priority values must be a multiple of 4096 (0, 4096, 8192, 12288, and so on up to 61440); Cisco IOS rejects values that aren’t valid multiples.
Using the Simplified Root Primary/Secondary Commands
Cisco IOS also provides a simpler, less error-prone way to designate root and backup root switches without calculating an exact priority value:
Switch(config)# spanning-tree vlan 10 root primary
This command automatically sets the priority low enough to make this switch the root bridge for VLAN 10, relative to the current lowest priority already seen in the topology. On a secondary switch intended as the backup root:
Switch(config)# spanning-tree vlan 10 root secondary
This sets a priority that will make the switch root only if the primary root fails, without requiring you to manually calculate and compare exact priority values across multiple switches.
Verifying the Root Bridge
Switch# show spanning-tree vlan 10
Sample output:
VLAN0010
Spanning tree enabled protocol rstp
Root ID Priority 4096
Address 0018.1234.5678
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
The line “This bridge is the root” confirms the local switch has been elected root bridge for that VLAN. On a non-root switch, this line instead shows the Root ID (priority and MAC address) of the actual elected root bridge, along with the local switch’s own Bridge ID and its root port.
Root Bridge Behavior in Modern STP Variants
| Feature | Classic STP (802.1D) | RSTP (802.1w) | MSTP (802.1s) |
|---|---|---|---|
| Root Election Logic | BPDU comparison by Bridge ID | Same logic, fully backward compatible with 802.1D | Same logic, applied independently per instance |
| Convergence Time | Approximately 30–50 seconds | Typically under 6 seconds, often sub-1-second on point-to-point links | Depends on VLAN-to-instance mapping |
| Typical Use | Legacy networks | Most modern campus networks | Large environments with many VLANs needing load balancing |
| CCNA/CCNP Focus | Election process, port states | Port roles, proposal/agreement mechanism | Instance-to-VLAN mapping |
Use MSTP when you want multiple independent spanning-tree instances to achieve VLAN-based load balancing across redundant uplinks, rather than every VLAN sharing a single, identical spanning tree topology.
CCNA Exam Pointers
- Bridge ID = 4-bit Priority + 12-bit Extended System ID + 48-bit MAC address = 64 bits total
- Default bridge priority = 32768; must be configured in multiples of 4096
- Root election compares priority first, then MAC address as the tiebreaker
- The Extended System ID encodes the VLAN ID, allowing each PVST+ instance to have a distinct Bridge ID despite sharing one MAC address
- All ports on the elected root bridge become designated ports in the forwarding state; the root bridge has no root port
spanning-tree vlan [id] priority [value]— manually sets a specific priority (must be a multiple of 4096)spanning-tree vlan [id] root primary/root secondary— simplified commands to designate primary and backup root without manual priority calculationshow spanning-tree vlan [id]— verify root bridge status; look for “This bridge is the root”- RSTP (802.1w) is backward compatible with classic STP (802.1D) and converges dramatically faster
Conclusion
The root bridge is the single reference point every spanning-tree-enabled switch in a broadcast domain converges around, elected through a straightforward Bridge ID comparison: lowest priority wins, with MAC address breaking any tie at the default priority. Understanding the precise 4-bit/12-bit/48-bit structure of the Bridge ID, why the Extended System ID exists at all, and how to deliberately configure root and backup root switches with spanning-tree vlan [id] root primary rather than leaving the outcome to an arbitrary MAC-address tiebreaker, is what separates textbook knowledge from being able to actually design a predictable, well-performing Layer 2 topology.
Frequently Asked Questions
What is a root bridge in Spanning Tree Protocol?
The root bridge is the single switch elected as the reference point for all spanning tree path calculations within a broadcast domain, chosen through an automatic comparison of each switch’s Bridge ID. Every other switch in the topology determines its own best path toward the root bridge and blocks any redundant paths that would otherwise create a Layer 2 loop, ensuring only one active, loop-free path exists between any two points in the network at a given time.
How does the STP root bridge election process work?
Every switch begins by assuming it is the root and sends configuration BPDUs every 2 seconds (the default Hello Time), each carrying its own Bridge ID and the best Root ID it currently knows about. When a switch receives a BPDU advertising a lower Root ID than its own, it updates its belief and begins advertising that lower ID onward. This process propagates through the entire broadcast domain until every switch agrees on which single switch has the lowest overall Bridge ID, and that switch becomes the elected root bridge.
What components make up the Bridge ID for root election?
The Bridge ID is a 64-bit value made up of three parts: a 4-bit Bridge Priority field (configurable in multiples of 4096, defaulting to 32768), a 12-bit Extended System ID that carries the VLAN number in PVST+ environments, and the switch’s 48-bit MAC address. Priority is compared first during root election; if multiple switches share the same priority, typically because none have been manually configured, the switch with the numerically lowest MAC address wins the tiebreaker and becomes the root bridge.
Why is manual configuration of the root bridge recommended?
Left at default settings, every switch shares the same priority of 32768, meaning root bridge election falls back entirely to whichever switch happens to have the lowest MAC address, an essentially arbitrary outcome with no relationship to network design or topology. This can place the root bridge on a poorly connected access-layer switch rather than a well-connected core or distribution switch, creating suboptimal traffic paths and unnecessary latency. Manually setting a lower priority on your intended core switch using spanning-tree vlan [id] root primary ensures predictable, intentional root placement aligned with your actual network design.
What happens to ports on the root bridge after election?
Every port on the elected root bridge transitions into the designated port role and enters the forwarding state, since the root bridge is, by definition, the reference point every other switch measures its path against. The root bridge itself has no root port, a root port exists specifically to provide a switch’s best path toward the root bridge, and the root bridge has no need for a path toward itself. This makes the root bridge the one switch in the topology whose every active port forwards traffic without any of them being blocked.