Root Guard is a layer 2 security mechanism designed to protect the “Root Bridge” and ensure it remains as the “Root” in the spanning tree topology. Root guard can protect against mis-configurations and mitigate MiM type attacks.

Lets say in the topology below “SW-1” has been elected as the “Root Bridge” with the default priority of 32768 however its MAC address is lower than “SW-2” what’s there to prevent “SW-2” or another switch that is plugged into the network with a lower “Bridge-ID” from becoming the root? Nothing….

This can have severe consequences – if a mis-configuration occurs it will impact the network performance, alternatively a malicious user could perform a MiM type attack making themselves the “Root Bridge” they could then route traffic through them while capturing data.

Root Guard to the Rescue!

Root Guard says If a superior BPDU (with a lower bridge-id) claiming to be the root bridge comes in on ports its configured on, it will place those ports into a loop inconsistent state (not err-disabled) thus preventing an STP topology change.  The port will remain down only for that switch/switches coming in on the violating port until the issue is resolved, or the device is restored as not being the root. Once superior BPDU’s stop coming in, the connection is restored automatically.

Root Guard is normally configured on the root bridge itself, or on the distribution switches. Cisco recommends you put it on the root bridge and protect that guy. you could put it on access switches but it all depends on how much you trust your admins.

 Configuration Example

In the example below, “Core-SW” is the “Root Bridge” with a default priority of 32769, and a lower MAC of 400. We will take a look at configuring “Root Guard” on the “Core-SW” we will then manually configure “SW-1” with a lower “Bridge-ID” and observe how “Root Guard” behaves.

The topology has been setup using GNS3

Step 1: Lets verify the current STP topology

Core-SW

#show spanning-tree

We can see that “Core-SW“ is running RSTP and it has a default priority of “32769” its MAC address is ending in “0400” this switch is currently acting as the “Root Bridge”, all ports are in a forwarding state.

SW-1

#show spanning-tree

“SW-1“ is also running RSTP and it has a default priority of “32769” its MAC address is ending in “0500” this switch knows the “Root Bridge” which is the “Core-SW”, “E0/1” is its root port back to the “Root Bridge”

Step 2: On both switches run debugging for spanning-tree so that we can review this information later.

Core-SW

#debug spanning-tree events

SW-1

#debug spanning-tree events

Step 3: On the “Core-SW” configure “Root Guard” on interface “E0/0” to prevent superior BPDU’s from being received on this interface.

#conf t

#Int e0/0

#spanning-tree guard root

A syslog message will be displayed indicating “Root Guard” has now been enabled.

Step 4: Configure “SW-1” with a lower spanning-tree priority for the default VLAN 1 of 4096

#conf t

#spanning-tree vlan 1 priority 4096

Step 5: let’s take a look on the “Core-SW”, as expected “Root Guard” has blocked interface “E0/0” as it has received a superior BPDU from “SW-1” on this port.

Let’s take a look at the STP topology, we should see no change

#show spanning-tree

From the output below we can see that “Core-SW” is still the “Root Bridge” however interface “E0/0” has now been blocked by “Root Guard”

Take a look at the debug messages on “SW-1” we can see that upon setting its spanning-tree priority to 4096 it updated its role and became the “Root Bridge” it transitioned its “Root Port” to “Designated”. This has happened because the “Core-SW” blocked this device and as “SW-1” has no communication with the “Core-SW” it considers itself as the “Root Bridge”

Let’s take a look at the STP topology for “SW-1”,

#show spanning-tree

We can see that the “Root Bridge” is itself and all ports are now forwarding.

Step 6: Lets restore the priority on “SW-1” and take a look at how “Core-SW” responds.

#no spanning-tree vlan 1 priority 4096

Instantly we can see debug messages, first setting itself back to the default priority and then updating its roles according to the superior BPDU received from “Core-SW”

Let’s take a look at the debugging messages on “Core-SW” we can see that “Root Guard” has stopped receiving superior BPDU’s on interface “E0/0”and therefore is now unblocking the port. However, there seems to be a dispute, this will be due to both switches having the default Priority of “32769” the next step is for the switches to resolve this dispute is based on the lowest MAC address, in this case it will be the “Core-SW”

Let’s take a look at the STP topology on “Core-SW”

#show spanning-tree

We can see that “Core-SW” is still the “Root Bridge” and “E0/0” is now forwarding again.