Hands-On Lab: Configuring Root Guard

This hands-on lab configures Root Guard on switch ports facing access-layer switches to prevent an unauthorized or misconfigured switch from becoming the Spanning Tree root, verifying the port enters a root-inconsistent state when a superior BPDU is received.

Root Guard ConfigurationRoot-Inconsistent StateSTP Topology Protection

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

Lab Objective

Configure Root Guard on a distribution switch's downlink ports toward access switches, verify normal operation is unaffected, then simulate an access switch attempting to become root and confirm Root Guard blocks it by placing the port into a root-inconsistent state.

Lab Purpose

Manually configuring root bridge priority, discussed earlier in this series, only controls the intended topology under normal conditions — it does nothing to prevent an access-layer switch from accidentally or maliciously advertising a lower priority and becoming root itself, which would disrupt the carefully designed traffic paths throughout the network. Root Guard enforces the intended root location at the port level.

Lab Topology

DistSwitch (intended root, priority 4096)
  ---- Gi1/0/1 ---- AccessSwitch1 (default priority)

VLAN 1 spans both switches

Task 1: Verify Normal Root Bridge Operation

Confirm DistSwitch is currently the root bridge and Gi1/0/1 is in the designated/forwarding role.

Task 2: Configure Root Guard on the Downlink Port

Enable Root Guard on DistSwitch's Gi1/0/1, the port facing AccessSwitch1.

Task 3: Verify Normal Traffic Is Unaffected

Confirm the port remains forwarding normally, since no superior BPDU is currently being received.

Task 4: Simulate AccessSwitch1 Attempting to Become Root

Lower AccessSwitch1's priority below DistSwitch's, simulating either a misconfiguration or an attack attempting to seize the root role.

Task 5: Verify Root Guard Blocks the Attempt

Confirm Gi1/0/1 enters a root-inconsistent state rather than allowing AccessSwitch1 to become root, and confirm DistSwitch remains root.

Solution and Verification

DistSwitch# show spanning-tree vlan 1 | include Priority

Bridge ID  Priority    4096
           This bridge is the root

DistSwitch# show spanning-tree vlan 1

Interface     Role  Sts  Cost   Prio.Nbr
Gi1/0/1       Desg  FWD  4      128.1

DistSwitch(config)# interface gigabitethernet1/0/1
DistSwitch(config-if)# spanning-tree guard root

DistSwitch# show spanning-tree vlan 1

Interface     Role  Sts  Cost   Prio.Nbr
Gi1/0/1       Desg  FWD  4      128.1
-- Still forwarding normally, no impact
-- under normal conditions

AccessSwitch1(config)# spanning-tree vlan 1 priority 0

-- 0 is the lowest possible priority,
-- guaranteed to win root election under
-- normal STP rules if Root Guard were not
-- present

DistSwitch# show spanning-tree vlan 1

Interface     Role  Sts        Cost   Prio.Nbr
Gi1/0/1       Desg  BKN*        4      128.1
*ROOT_Inc

DistSwitch# show spanning-tree inconsistentports

Name                 Interface        Inconsistency
VLAN0001             Gi1/0/1          Root Inconsistent
-- The port is blocked, and DistSwitch
-- remains the root bridge despite
-- AccessSwitch1's attempt

DistSwitch# show spanning-tree vlan 1 | include Priority

Bridge ID  Priority    4096
           This bridge is the root
-- Confirmed: DistSwitch is still root,
-- exactly as the network design intended

Key Takeaway

Root Guard does not simply ignore a superior BPDU — it actively places the receiving port into a distinct "root-inconsistent" blocking state, visible specifically in show spanning-tree inconsistentports, until superior BPDUs stop being received on that port, at which point it automatically recovers without requiring manual intervention.

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

مقالات مرتبط

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.

ادامه