This topic is to discuss the following lesson:
Simple and short explanation makes very easy to understand . One small question…?
Since Root bridge is specific to Switch , Is there any command to enable the Root guard globally ?
If No, We have to enable the “spanning-tree guard root” in all the Designated Ports of Root bridge to make it always root.
Please correct me If I misunderstood the concept here.
Root guard is always enabled per interface. Each switch will always elect one interface as its root port (unless the switch is the root bridge). The only thing this command does is ensuring that an interface can never become the root port.
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 Switch 2? Assume that I have configured SW 1 as the root bridge and SW 2 as the backup root bridge via manipulation of priorities.
Sw 1 Sw 2
/ / / switch 3
Many thanks for your time.
Drawing didn’t turn out very well essentially I don’t have a link between SW1 and SW2 and all communication between those switches is via/through switch 3.
- 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 at this picture:
In a network like this, you probably want one of the core switches to be the root bridge and the other one to be the backup. Your core switches should never accept a distribution switch as a root so you could configure root guard on the core interfaces that connect to the distribution switches.
Your distribution switches also should never accept the access layer switches as a root…so on the distribution switch interfaces facing the access layer, enable root guard.
In your example with SW1, SW2 and SW3. You want to make sure that SW1 or SW2 always remains the root. If someone gets access to SW3 and sets the STP priority to 0, it would normally become the root bridge. If you use root guard on SW1 or SW2 then you can prevent this without disturbing STP operations.
Hope this helps!
I have a question regarding to BPDU guards. If there is a hacker hanging his pc towards en access port lets say vlan 100. And the core is running mst with instace 1 vlan 100 and vlan 200. If the hacker generate a superior bpdu, would it say he can make his pc as root for vlan 100 and 200? But it is connecting to vlan 100 only, if not what would the scenario be?
On the “outside” of the MST region the switches will send PVST “compatible” BPDUs. If the interface is a trunk then you will see a BPDU on each VLAN. If it’s an access port then you will see BPDUs for that VLAN only.
So in this case, the attacker would see BPDUs for VLAN 100.
Catalyst switches with modern IOS images will refuse any 802.1Q tagged frames received on interfaces in access mode. An attacker should be able to send superior BPDUs for VLAN 100 but that’s it.
i’ve been uploaded the topology i’m working on
while i enable rootguard on the root switch which connected to other non root bridges with two cables per each and try to minimize the priority id on other bridges i lose connectivity to all other non root switches…would you help?
Are you getting any error messages? Normally enabling root guard is safe on the root bridge. It will only start blocking the interface when you receive a superior BPDU from a non-root bridge.
As long as the port continues to receive a superior BPDU, it is placed into “Root-Inconsistent” state which will disable it. Once the superior BPDUs stop being received, the port will automatically recover.
Refer to reply [September 6, 2015 at 22:11]
If we do accordingly [enable Root Guard on Core SW, Distribution SW ] then all access leyer Switch will be disconnected from Core , Dritributed and all user will be hampered who are getting service thru the switches. So My Opinion is to enable Root Guard on User facing interface , if any one sending superior BPDU then that user will be hampered not all User , right ??
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 a special type of BPDU Guard.
Configuring it this way, however, doesn’t prevent a scenario where a non-desirable Root Bridge could be elected at the Distribution layer.
Some examples of this:
- a new Distribution switch is plugged in with a superior BPDU and changes the entire spanning-tree topology.
- A Core switch fails, but an existing distribution switch now has a the superior Bridge ID.
In either case, your root bridge would not be at the core layer which would result in inefficient traffic patterns. To stop this from happening, you must set your switch priorities correctly, but the Root Guard feature acts as a final measure of protection.
I think this sentence is very clear in Cisco Web:
“This root-inconsistent state is effectively equal to a listening state. No traffic is forwarded across this port. In this way, the root guard enforces the position of the root bridge.”
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 as a root?
3)What would be the effect of root guard configuration on core switch interface to distribution switch interface on this case?
If your core switch has root guard configured on the interface connecting to your distribution switch, then as soon as it receives a superior BPDU from the distribution switch, it will block the interface to the distribution switch. Your core switch will remain the root bridge but “isolates” itself to protect itself.
Everything else that is connected to your distribution switch, including your access switch will see the distribution switch as the new root bridge.
Thank you for your answer Rene, but what is the advantage of this command then? Why we use it ?
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.
When interface go to root inconsistentports. Does it will stop forwarding the traffic on this port or just prevent switch to select another switch as root ?
And one more which type of interface will switch send BPDU frame ?