Hands-On Lab: Configuring Spanning Tree Protocol Root Bridges Manually

This hands-on lab manually influences Spanning Tree root bridge election by adjusting bridge priority on two competing switches, verifying which switch becomes root before and after the change, and confirming the resulting port roles update accordingly.

STP Root Bridge PriorityBridge IDRoot Bridge Election

~3 دقیقه مطالعه · آخرین به‌روزرسانی ۳۱ شهریور ۱۴۰۵

Lab Objective

Observe the default Spanning Tree root bridge election outcome between two switches, then manually lower the priority on the preferred switch to force it to become root, and verify the resulting change in port roles.

Lab Purpose

Leaving root bridge election entirely to chance, based only on the lowest MAC address, can result in a poorly positioned or underpowered switch becoming root, creating suboptimal traffic paths. Deliberately setting priority on a well-placed switch is standard practice in production networks.

Lab Topology

Switch1 (core switch, preferred root)
Switch2 (access switch)

Connected via two redundant trunk links,
both in VLAN 1

Task 1: Identify the Current Root Bridge

Use a show command on both switches to determine which one is currently acting as the root bridge by default.

Task 2: Record the Default Bridge Priorities

Note the default priority value shown on each switch.

Task 3: Manually Set Switch1 as Root

Lower Switch1's bridge priority for VLAN 1 so it becomes the root bridge regardless of MAC address.

Task 4: Verify Switch1 Is Now Root

Confirm both switches now agree Switch1 is the root bridge.

Task 5: Verify Port Roles Updated Accordingly

Confirm Switch2's ports show the correct root port and any blocking port relative to the new root.

Solution and Verification

Switch1# show spanning-tree vlan 1 | include Priority

Bridge ID  Priority    32768

Switch2# show spanning-tree vlan 1 | include Priority

Bridge ID  Priority    32768
-- Both switches default to the same priority
-- of 32768 -- the tiebreaker is therefore the
-- lowest MAC address, which may or may not
-- favor the switch actually intended to be root

Switch1# show spanning-tree vlan 1 | include Root

Root ID    Priority    32768
           This bridge is the root
-- (in this scenario, Switch1 happened to already
--  win by MAC address, but this outcome is
--  never guaranteed without explicit configuration)

Switch1(config)# spanning-tree vlan 1 priority 4096

Switch1# show spanning-tree vlan 1 | include Priority

Bridge ID  Priority    4096
           This bridge is the root

Switch2# show spanning-tree vlan 1 | include Root

Root ID    Priority    4096
           Root has priority 4096, address 00aa.bb00.1111
-- Switch2 now explicitly recognizes Switch1
-- (with the lower, deliberately configured
-- priority) as the root, regardless of MAC
-- address comparisons

Switch2# show spanning-tree vlan 1

Interface     Role  Sts  Cost   Prio.Nbr
Gi1/0/1       Root  FWD  4      128.1
Gi1/0/2       Altn  BLK  4      128.2
-- Switch2's port toward the (now confirmed)
-- root bridge is correctly identified as the
-- Root Port, with the redundant link blocking

Key Takeaway

Priority must be a multiple of 4096 (Cisco IOS enforces this), and the lower the value, the higher the preference for becoming root — deliberately configuring priority is essential in any network with more than a trivial number of switches, since relying on MAC address alone provides no control over which switch actually ends up as root.

نوشته و پژوهش‌شده توسط دکتر شاهین صیامی

مقالات مرتبط

Hands-On Lab: Final Comprehensive CCNP Troubleshooting Challenge (BGP, DMVPN, and QoS Integration)

This hands-on lab presents a complex multi-layer failure across an integrated BGP-over-DMVPN topology combined with QoS marking, requiring systematic diagnosis of a route reflector misconfiguration, an NHRP registration failure, and an incorrectly applied QoS policy simultaneously affecting the same network.

ادامه

Hands-On Lab: Configuring BGP over DMVPN

This hands-on lab runs iBGP as the routing protocol across the same DMVPN hub-and-spoke topology used in the two previous labs, configuring the hub as a route reflector so spokes learn each other's routes without a full iBGP mesh, combining two previously separate concepts into one integrated design.

ادامه

Hands-On Lab: Configuring OSPF over DMVPN

This hands-on lab runs OSPF as the dynamic routing protocol across the same DMVPN hub-and-spoke topology, configuring the tunnel interface as an OSPF point-to-multipoint network type to correctly handle the hub-and-spoke adjacency pattern without requiring the broadcast network type's DR/BDR election.

ادامه

Hands-On Lab: Configuring EIGRP over DMVPN

This hands-on lab runs EIGRP as the dynamic routing protocol across the DMVPN hub-and-spoke topology built in earlier labs, verifying neighbor relationships form correctly across the multipoint tunnel and routes propagate without requiring per-spoke static configuration on the hub.

ادامه

Hands-On Lab: Configuring HSRP MD5 Authentication

This hands-on lab configures MD5 authentication on an HSRP group, verifying two routers with matching authentication strings form a normal active/standby relationship while a router with a mismatched string is excluded from the group entirely.

ادامه

Hands-On Lab: Configuring Cisco Umbrella-Style DNS Security via DNS Forwarding Redirection

This hands-on lab configures a router to redirect all client DNS queries toward a security-focused DNS resolver using DNS forwarding interception, approximating cloud-delivered DNS security enforcement without requiring per-client configuration changes.

ادامه