Spanning-Tree RootGuard | NetworkLessons.com

RootGuard will make sure you don’t accept a certain switch as a root bridge. BPDUs are sent and processed normally but if a switch suddenly sends a BPDU with a superior bridge ID you won’t accept it as the root bridge. Normally SW2 would become the root bridge because it has the best bridge ID, fortunately we have RootGuard on SW3 so it’s not going to happen!

Let me demonstrate this with the following topology:

Let me show you the configuration by using SW2 and SW3, first I will make sure that SW3 is NOT the root bridge:

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

Now we’ll enable rootguard on SW2:

SW2(config)#interface fa0/16
SW2(config-if)#spanning-tree guard root 
%SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/16.

We get a nice notification message that it has been enabled. Let’s enable a debug so we can see what is going on:

SW2#debug spanning-tree events 
Spanning Tree event debugging is on

Now we’ll upset SW2 by changing the priority to the lowest value possible (0) on SW3. Normally it should now become the root bridge:

Forum Replies

Rene,
Hi. Couple questions.

I have seen some documents out there that recommend or advise to enable “root guard” on ports connected to end hosts at an access layer switch. Is there any value to still configure root guard if have those end host ports on the access layer switch configured with BPDU-guard & portfast?
I see where you advise above to configure rootguard on distribution or core layer switches - if I have a “V” design as indicated below, is there still any value of configuring root guard on the designated port of Switch 1 and the root port of Swit

... Continue reading in our forum

Hi Thomas,

I would prefer BPDU guard on the access layer switches towards the hosts. You don’t want to see any BPDUs from the hosts, if you see them then someone has been messing with bridge mode (bridging two NICs) or they connected a switch, one exception could be a wireless access point. Some of those send BPDUs. If you have BPDU guard enabled, there’s no need to use root guard since a BPDU triggers a violation.

We use root guard on interfaces where we DO want to receive BPDUs from but we don’t want to accept a root switch on these interfaces.

Take a look

... Continue reading in our forum

Mohammad,
Perhaps you are thinking that should a user plug in a switch that has a superior Bridge ID to the Core’s, then all users will be affected by the Root Guard putting the Access layer’s connection to the Distribution layer in “Root inconsistent” state?

This won’t happen if you do as Rene suggested and make sure that all of your user facing ports on the Access switches have BPDU guard enabled. If you do that, then any BPDU received, whether it is superior or inferior, will trigger that port to go into an err-disabled state. Think of Root Guard as being

... Continue reading in our forum

Hi Andrew,

In the same topology, assume that bpdu guard is configured on access switches interfaces to hosts, root guard is configured on distribution switches interfaces to access switches, and core switches interfaces to distribution switches. If your example 1) a new Distribution switch is plugged in with a superior BPDU would happen:
1)How would it change the entire spanning-tree topology? Could you give the steps how would it be root bridge?
2)Would our core switch which was root before, would remain root, or would it start to see new distribution switch a

... Continue reading in our forum

You could use it to protect your core/distribution layer switches. If you want to ensure one of your core switches always remains the root, then you could use this to protect yourself from someone (accidently) configuring a distribution switch as the new root bridge. You can also protect your distribution switches from selecting an access layer switch as the new root bridge.

17 more replies! Ask a question or join the discussion by visiting our Community Forum