A structured lesson workspace with readable content, hands-on examples, and a clean path to completion.
| Switch | Priority | MAC | Result |
|---|---|---|---|
| SW1 | 32768 | 00:00:0A:00:00:01 | Not root |
| SW2 | 32768 | 00:00:0A:00:00:02 | Not root |
| SW3 | 4096 | 00:00:0A:00:00:03 | Root (lowest priority) |
| SW4 | 32768 | 00:00:0A:00:00:04 | Not root |
That table is the whole election in one picture. SW3 wins because it has the lowest priority. If SW3 had 32768 too, SW1 would win — lowest MAC of the equal-priority group. Two tiebreakers, applied in order, and the rest of the topology follows.
Left alone, STP picks the oldest switch with the lowest MAC. That's almost never the switch you want as root. The ideal root is the most central, most powerful, most reliable switch — usually the core, or one of a redundant pair of distribution switches.
If your access switch ends up as root, every flow in the campus traverses it, even traffic between two servers in the data center. That's traffic tromboning through a switch with 1 Gbps uplinks. Bad design, terrible performance, and completely avoidable by setting priority deliberately.
! Set SW1 as root for VLANs 10 and 20SW1(config)# spanning-tree vlan 10 priority 4096SW1(config)# spanning-tree vlan 20 priority 4096! Set SW2 as root for VLANs 30 and 40SW2(config)# spanning-tree vlan 30 priority 4096SW2(config)# spanning-tree vlan 40 priority 4096! Or use the macro command — automatically picks a value low enoughSW1(config)# spanning-tree vlan 10 root primarySW1(config)# spanning-tree vlan 10 root secondary
The `root primary` macro sets priority to 24576 (or 4096 if the current root is already lower than 24576). The `root secondary` macro sets 28672. These are convenient but less explicit than typing a specific priority — I prefer explicit values in production so the config documents itself.
`This bridge is the root` — SW1 won. If you ran the same command on SW2, you'd see a different priority in the Bridge ID line and no `This bridge is the root` statement — SW2 would be a non-root with a Root ID pointing at SW1's MAC.
Because each VLAN runs its own STP instance with its own root election, you can run SW1 as root for half your VLANs and SW2 as root for the other half. Both uplinks to the distribution layer get used — one for each set of VLANs. That's the traditional way to load-balance across redundant links.
Without this trick, one of the redundant distribution switches would be almost entirely idle — forwarding nothing because STP blocked all its ports to the access layer. With per-VLAN roots, both are productive.
Always configure explicit priorities on your intended root and secondary. Letting STP decide means the network's behavior depends on MAC address randomness — a design choice made by accident is not a design choice.
On any lab with multiple switches, run `show spanning-tree` before and after setting `spanning-tree vlan 1 root primary` on one switch. Watch how the port roles change. That single command moves the entire forwarding path.
Finish the lesson once you have worked through the material. This awards ★ 15 XP.