Spanning Tree Root Bridge Election and Design Rules - 夜莺博客

Spanning Tree Root Bridge Election and Design Rules

Spanning tree is deterministic, but it is only as good as the election you designed. Leave everything at the default priority of 32768 and the root bridge becomes whichever switch happens to have the lowest MAC address — usually an access switch in a wiring closet, which turns your carefully built two-tier topology into a traffic detour. This guide covers how the election actually works, how to configure root roles properly on Cisco switches, and the verification commands that prove the topology you intended.

How the Election Works

Every bridge advertises a bridge ID: a 2-byte priority followed by the MAC address. The lowest bridge ID wins, which means:

  1. The switch with the lowest priority becomes the root. Default is 32768; the value must be a multiple of 4096.
  2. If priorities tie, the switch with the lowest MAC address in that VLAN becomes root.
  3. Each non-root switch then elects a root port — the port with the lowest path cost to the root — and each segment elects a designated port. Everything else blocks.

With PVST+/Rapid PVST+ there is one instance per VLAN, and modern switches fold the VLAN number into the low bits of the priority (extended system ID), so a VLAN 10 instance never shows a truly "round" 32768. Do not let that surprise you during audits.

The Bridge ID, Bit by Bit

A classic bridge ID is eight bytes: two of priority, six of MAC address. On modern switches the last 12 bits of the priority field are not priority at all — they carry the VLAN ID, a behaviour Cisco calls the extended system ID. That one detail explains the two questions engineers ask during every root audit:

  • Why does a VLAN 10 switch report priority 32778 rather than 32768? Because 32768 plus VLAN 10 is what is actually transmitted in the BPDU.
  • Why can priority only be configured in steps of 4096? Because the low 12 bits belong to the VLAN, leaving the top 4 bits (values 0–15) for priority, and 15 × 4096 = 61440.

The practical consequence: hard-code only multiples of 4096, and never rely on a priority tie to break the way you expect — the MAC address decides, and MAC addresses are inherited from whichever chassis or line card the vendor ships. Two switches from the same batch can therefore differ by a single digit in the third MAC octet, which is not a design input you want.

Path Cost Decides More Than Priority Does

Priority picks the root; cost builds the tree. Every link gets a cost derived from its bandwidth, and each switch sums the costs along the path back to the root. The lowest total wins the root port, and the same sum decides which ports become designated. Two cost standards exist and mixing them is a common, silent bug:

Link speed 802.1D short (default) 802.1t long
10 Mbps 100 2,000,000
100 Mbps 19 200,000
1 Gbps 4 20,000
10 Gbps 2 2,000
40 Gbps 1 500
100 Gbps 1 200

The short table saturates above 1 Gbps — a 10G and a 100G link both cost 2 — so a fault on a slow path can make STP prefer a path that is physically longer. For any modern fabric, configure the long method everywhere and keep it consistent:

switch(config)# spanning-tree pathcost method long

You rarely need to touch individual costs, but when you do, the interface-level command is the tool:spanning-tree vlan 10 cost 100 on the uplink that should lose. Raise the cost on the path you want blocked rather than lowering the one you want active — a raised cost is easy to reason about across a mixed topology.

Root Port and Designated Port: The Tie-Breakers in Order

When two links offer equal cost, STP resolves the tie in a fixed order. Memorise it, because each step tells you which knob to turn:

  1. Lowest root path cost. The sum from the BPDU, computed with whichever cost method the local switch uses.
  2. Lowest sender bridge ID. The neighbouring switch with the lower priority (and then MAC) wins, so the segment's designated switch is the one closer to the root.
  3. Lowest sender port ID. Port priority followed by port number on the neighbour, which is why port-priority exists.
  4. Lowest local port ID. Only reached when the BPDUs arrived on the same neighbour port — the classic shared-segment or hub case.

In an MLAG or port-channel design the last two steps rarely matter because the bundle hides the physical members, but on a legacy shared segment they decide which uplink blocks. If you must influence the outcome, spanning-tree vlan 10 port-priority 16 on the relevant interface beats guessing at MAC addresses.

Configure Root Roles Properly

! Preferred: let the switch pick a safe priority
switch(config)# spanning-tree vlan 10 root primary
switch(config)# spanning-tree vlan 10 root secondary

! Explicit priorities when you need deterministic values across platforms
switch(config)# spanning-tree vlan 10 priority 4096      ! primary (multiple of 4096)
switch(config)# spanning-tree vlan 20 priority 8192      ! secondary

! A range of VLANs in one statement
switch(config)# spanning-tree vlan 1-100 root primary

The root primary keyword does not set a fixed number: the switch inspects the current root priority for those VLANs and sets its own lower — 24576 with extended system ID support, or one less than the lowest existing root if that is already lower. This is why root primary is the portable choice and hard-coded priorities belong in designs where you control every device. Remember that root primary is a one-shot measurement, not a rule: if a downstream switch later appears with priority 4096, the primary you configured does not automatically react. Root guard is what stops that switch from winning.

Load Sharing with Per-VLAN Root Placement

One root means one blocking link per segment, so half of a redundant uplink pair carries nothing. The standard fix alternates roots by VLAN: distribution switch A is primary for the odd VLANs and secondary for the even ones, switch B the reverse.

! On distribution switch A
spanning-tree vlan 1-99,201-299 root primary
spanning-tree vlan 100-199,300-399 root secondary

! On distribution switch B
spanning-tree vlan 100-199,300-399 root primary
spanning-tree vlan 1-99,201-299 root secondary

Keep that mapping in the design document. Two engineers "fixing" root placement in different change windows is how a balanced tree becomes a single-rooted ladder. Note that this only load-shares Layer 2 traffic — if most of the traffic is Layer 3, equal-cost routing gives you the same benefit for free and the per-VLAN roots are there only for what genuinely must bridge.

MST: One Region, Many Instances

Per-VLAN instances stop scaling somewhere past a few hundred VLANs, and the answer beyond that is Multiple Spanning Tree. An MST region is defined by three things that must match exactly on every switch in it — name, revision number and the VLAN-to-instance mapping:

spanning-tree mode mst
spanning-tree mst configuration
 name DC-CORE
 revision 1
 instance 1 vlan 1-99
 instance 2 vlan 100-199
 exit
spanning-tree mst 0-1 root primary       ! on switch A
spanning-tree mst 2 root secondary

A one-character difference in the region name, or a mapping that disagrees, splits the domain into separate regions that then interconnect through the Common Spanning Tree (instance 0). The symptom is exactly the one in the troubleshooting table: inconsistent ports and a tree that ignores your design. Verify by comparing the digest: show spanning-tree mst configuration digest should print the same string on every switch in the region.

Design Rules That Prevent 3 a.m. Calls

  • Root at aggregation or core, never in an access closet. Cisco's own guidance is that the root should be a backbone or distribution device.
  • One primary, one secondary, then nothing else. Every other switch keeps the default so the failure of the primary always lands on the secondary you tested.
  • Keep the L2 diameter small. Deep trees mean long convergence and more blocked bandwidth; if the diameter grows, it is a sign you need routing at the distribution layer.
  • Protect the edge. BPDU guard on access ports stops a user's switch or a bridging loop from injecting BPDUs; root guard on ports facing downstream switches stops a rogue switch from stealing the root role.
  • Agree on one protocol. Mixing classic STP, RSTP and MSTP instances across the same L2 domain creates convergence surprises — standardise (Rapid PVST+ or MST) and document instance mappings.
  • Match the cost method. One switch left on the short cost table while the rest use long produces a tree nobody can explain.

Protections Belong in the Design, Not the Ticket

Each STP protection exists because of a specific accident, and each should be applied deliberately during build:

  • PortFast on every true edge port, so a workstation link skips the 30-second listening/learning wait. Never on a port facing another switch.
  • BPDU guard on those same edge ports. A BPDU arriving where none should means a switch or a loop; the port shuts and the rest of the tree stays safe. Pair it with errdisable recovery on a sensible timer.
  • Root guard on ports facing downstream switches that must never bid for root. It blocks superior BPDUs and marks the port root-inconsistent without shutting it down.
  • Loop guard on point-to-point uplinks, to catch a one-way link that stops receiving BPDUs before it can unblock and create a loop.
  • BPDU filter is the dangerous one — applied globally it silently disables STP. Use it only on access ports that already have PortFast, or not at all.

Timers and Convergence

Classic STP converges in roughly 30–50 seconds because of its timers: hello 2 s, max-age 20 s, forward delay 15 s per listening and learning cycle. Rapid PVST+ and RSTP replace the timer-based wait with a proposal/agreement handshake on point-to-point links, so a topology change converges in well under a second and the forward-delay timers only matter at the edge. Two habits follow: confirm your links are discovered as point-to-point (show spanning-tree interface … detail reports the type), and do not tune timers to paper over a missing design — shortening max-age to 6 s only relocates the flapping.

Verification

show spanning-tree vlan 10
show spanning-tree root
show spanning-tree vlan 10 root
show spanning-tree interface gigabitEthernet1/0/1 detail
show spanning-tree summary
show spanning-tree inconsistentports
show spanning-tree mst configuration digest

The output to read closely: Current root has priority 16384, address … tells you who actually owns the VLAN; Designated root versus Designated bridge shows whether this switch is on the path or merely adjacent; the topology-change counter distinguishes a stable tree from one that keeps reshuffling; and the path-cost column of the root table is what your load-sharing design is actually built from. Compare This bridge is the root against your design document — if it appears on an access switch, stop and fix the election before chasing anything else.

Troubleshooting the Three Usual Suspects

Symptom Check
An access switch is root show spanning-tree root on every candidate; look for a hard-coded low priority or MAC-based tie-break. Fix with root primary plus root guard on downstream-facing ports.
Topology change counter climbing Find the flapping port (show spanning-tree detail), check for a user loop, enable BPDU guard and portfast only on true edge ports.
Traffic taking a long path Compare root path costs and port priorities; a wrong pair of uplink costs sends traffic the long way around even though the tree is loop-free.
Ports inconsistent/blocked unexpectedly show spanning-tree inconsistentports — usually a mismatched MST region or a port type (point-to-point vs shared) discovery problem.
Two switches both report root Usually two separate domains joined by a link that is blocking, or a region split. Compare digests and BPDU contents on the interconnecting link.

相关阅读:RSTP 与 MSTP:实例与收敛迁移Spine-Leaf 与三层架构的 STP 阻塞带宽 以及 Arista EOS PortFast 与 BPDU Guard 边缘端口配置

原文链接:Cisco - Spanning Tree Protocol