Root Guard

1. Introduction to Root Guard

Root Guard Spanning Tree is a tool used to stabilize the STP topology. By using Root Guard, we can control the placement of the Root Bridge.

To explain the use case of Root Guard, let’s consider a scenario where you are working for a service provider on the right and you need to connect a customer to your infrastructure.

Root Guard Spanning Tree example showing customer and service provider networks with separate STP topologies and Root Bridge protection.
Figure 1 – Two separate STP topologies: one for the customer, one for the service provider

In this example, the customer requires access to the service provider’s infrastructure to reach the internet.

In the diagram, you can see two distinct STP topologies, one for each network.

When the service provider network connects to the customer network, BPDUs will start flowing between the two STP topologies.

As a service provider, we do not want our Root Bridge to be located in the customer’s network.

2. Problem Without Root Guard

Here is the connection of our topology:

STP topology without Root Guard showing service provider switch becoming Root Bridge instead of customer switch in CCNA scenario
Figure 3 – Which switch becomes Root? BID values determine the STP election result

By default, Cisco switches operate using the Per VLAN Spanning Tree Plus (PVST+) protocol. This protocol creates a separate STP instance for each VLAN.

  • SW6 in the service provider’s STP topology is configured as the desired Root Bridge with a priority of 0 + VLAN 1, resulting in a BID (1:4982:01be:1092).
  • SW1 in the customer’s STP topology is configured with a priority of 0 + VLAN 1, resulting in a BID (1:4982:01be:1038).
  • The other switches use the default priority (32,768 + VLAN 1).

BID Comparison

Since the switch with the lowest BID becomes the Root Bridge in the STP topology, we have the following BIDs:

  • 1:4982:01be:1038 (SW1)
  • 1:4982:01be:1092 (SW6)

As BPDUs are exchanged, SW1 with the lower BID claims to be the Root Bridge and SW6 recognizes it as such.

STP Root Bridge election conflict without Root Guard in CCNA example showing both customer and service provider switches claiming Root Bridge role
Figure 3 – SW1 wins the Root Bridge election due to lower Bridge ID

Consequences of No Security Measures

Since no security measures are enabled, the service provider’s switches (SW4, SW5, and SW6) assume that SW1 is the new Root Bridge of the topology.

This is a serious issue because all traffic will be redirected to the Root Bridge. The port roles change to align with the new topology.

STP port roles diagram in CCNA Root Guard example showing Designated, Root, and Blocked Ports after Root Bridge election issue
Figure 4 – Port roles change after SW1 becomes Root Bridge

In this scenario, SW1 becomes the Root Bridge, and all traffic, even between switches like SW5 and SW6, is forwarded through SW1.

Undesirable STP traffic flow without Root Guard in CCNA example showing customer switch as Root Bridge and traffic redirection
Figure 5 – All traffic is redirected through the customer’s Root Bridge

This setup is undesirable. We want to ensure that the service provider’s STP topology always retains control of the Root Bridge.

3. Root Guard to the Rescue

Root Guard prevents superior BPDUs from being accepted on specific ports by treating them as untrusted. By enabling Root Guard on the interfaces facing the customer’s network on SW4 and SW5, we can ensure the integrity of the service provider’s STP topology.

Configuration of Root Guard

Let’s configure this feature:

Root Guard configuration example in CCNA showing how to protect service provider STP topology by enabling Root Guard on specific ports
Figure 6 – Root Guard configuration on SW4 and SW5 interfaces

On the interfaces connected to the customer:

SW4(config)# int g0/2
SW4(config-if)# spanning-tree guard root

SW5(config)# int g0/2
SW5(config-if)# spanning-tree guard root

4. What Happens When a Superior BPDU is Received?

When a superior BPDU is received, the affected port is placed into a Blocked state with a status of Root Inconsistent, effectively shutting down the interface.

Root Guard blocking superior BPDU in CCNA example showing blocked ports and Root Inconsistent state to protect STP topology
Figure 7 – Root Guard blocks the port upon receiving a superior BPDU

At this point, the blocked interface prevents any traffic from flowing between the customer and the service provider networks.

Root Guard blocking superior BPDU in CCNA example showing ports in Root Inconsistent state to prevent topology disruption
Figure 8 – Interfaces enter Root Inconsistent state, blocking customer-to-provider traffic

Verifying Port Status

You can verify the status of the port using the following command:

SW4# show spanning-tree interface g0/2

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- ------------------------
VLAN0001            Desg BKN*4         128.3    P2p *ROOT_Inc 

SW5# show spanning-tree interface g0/2

Vlan                Role Sts Cost      Prio.Nbr Type
------------------- ---- --- --------- -------- ------------------------
VLAN0001            Desg BKN*4         128.3    P2p *ROOT_Inc

5. Resolving the Situation

To resolve this issue, we must instruct the customer to increase the priority of SW1 in their STP topology, ensuring that it no longer competes to become the Root Bridge. For example:

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

Once SW1’s BID is higher, the port protected by Root Guard will automatically recover after the Max Age timer (20 seconds) expires.

Resolving Root Guard block in CCNA example showing Max Age timer recovery and customer switch priority increase to fix STP topology
Figure 9 – The blocked port is restored after Max Age expires and SW1 is no longer the Root Bridge

Restoring the Topology

As shown in the output, the Root Guard-protected port is unblocked. The STP topology reconverges, with SW6 resuming its role as the Root Bridge.

Restored STP topology in CCNA Root Guard example showing correct port roles and service provider switch as Root Bridge
Figure 10 – SW6 regains Root Bridge role and normal STP operation is restored

This ensures that traffic between the customer and service provider networks flows correctly.

Final Root Guard topology in CCNA showing correct traffic flow to service provider Root Bridge
Figure 11 – Root Guard ensures the STP topology stays controlled by blocking unauthorized root bridge claims

6. Conclusion

Root Guard is a key feature to keep full control of the Root Bridge in your STP topology.
Enabling Root Guard on untrusted ports, typically those facing customer or external networks prevents any device from sending superior BPDUs and seizing the Root Bridge role.

Key points to remember:

  • Purpose: Blocks superior BPDUs on protected ports, placing them in the Root Inconsistent state.
  • Recovery: Port returns to normal automatically after the Max Age timer (20 seconds) once superior BPDUs stop.
  • Configuration: spanning-tree guard root under the interface.

On the next lesson, we’ll see another protection feature for different types of STP failures: Loop Guard.