Hi Rene
I have two psyhical links connected to the core switch in port-channel with multiple vlans. How should I configure rootguard? On vlans, psyhical links or directly on port-channel?
Hello Serveradmin
Take a look at this post:
If you have further questions, let us know!
I hope this has been helpful!
Laz
1 Like
Hi Team ,
This feature works only if switch with high priority is connected directly to root switch port or even if the high priority switch is connected via another switch in path to the root switch ?
Regards
Ziad
Hello Ziad
This feature will only affect the local switch. If it is configured on a specific interface, any superior BPDUs received on that interface will be disregarded and will not change the currently defined root bridge within the local switch.
Now this feature can be configured on the root bridge itself, or on other switches downstream. In any case, once a superior BPDU is seen on such an interface, it will block that particular VLAN. That means that such BPDUs are not sent upstream to the root bridge, but are blocked there.
So the feature will activate at the local switch, but will not allow the BPDUs to be further propagated.
I hope this has been helpful!
Laz
Hi All,
Any command can show interface guard root enable?
Hello Chun
There are two ways to see if root guard is employed on an interface. The first is to use the following command:
SW1#show spanning-tree interface gigabitEthernet 0/1 detail
A sample output from this command can be seen below:
Port 2 (GigabitEthernet0/1) of VLAN0001 is designated forwarding
Port path cost 4, Port priority 128, Port Identifier 128.2.
Designated root has priority 32769, address 5254.000c.f48d
Designated bridge has priority 32769, address 5254.000c.f48d
Designated port id is 128.2, designated path cost 0
Timers: message age 0, forward delay 0, hold 0
Number of transitions to forwarding state: 1
Link type is point-to-point by default
Root guard is enabled on the port
BPDU: sent 936, received 1
Notice on the second last line, it states that Root guard is enabled on the port.
The other way to check is to simply look at the running config like so:
SW1#show running-config interface gigabitEthernet 0/1
Building configuration...
Current configuration : 95 bytes
!
interface GigabitEthernet0/1
negotiation auto
no cdp enable
spanning-tree guard root
end
SW1#
You can see that the spanning-tree guard root command is in the configuration of the interface.
I hope this has been helpful!
Laz
Iâm using two backbones and Iâm using HSRP.
Is there any problem if I set the guard root on the interface Vlan of Backbone 1 and Backbone 2?
Hello YongHun
I havenât completely understood your topology. I assume that you want one of the two HSRP switches to be the root bridge for half of the VLANs being served, and the other to be the root bridge for the other half.
In any case, keep in mind that Root Guard should be applied to Layer 2 interfaces, specifically on the switch ports that are connected to other switches. It is not applicable to SVIs since SVIs are associated with Layer 3 functionality.
If you share a little bit more about your topology, and let us know some more about what you want to achieve, we may be able to help you further.
I hope this has been helpful!
Laz
Hello Team,
With this topology, i have enabled ROOT Guard on SW1 and given priority 0 in SW3 .At SW1, i could see both ports are in inconsistency and protected SW1 as a root bridge. But the strange thing is that SW2 accepted superior BPDU from SW3 and SW3 become a ROOT b/w SW2 and SW3.
How can we mitigate this with this topology.
SW1:-
SW2:-
SW3:-
the design may be a wrong as it suggested only in CORE/DIST/Access layer setup.
Hello, Sathish.
There is a âsolutionâ to this:
Solution 1
Configure Root Guard on SW1 ports and on SW2âs e0/2 port.
The problem? If the link between SW1 and SW2 fails, SW2 will try to converge and move over to e0/2 which can cause it to end up as root inconsistent.
If SW2âs e0/2 port is designated here, it means that SW3âs e0/2 port is blocking. If SW2 loses the path to SW1 over e0/0, it will completely stop receiving BPDUs! The root bridge is down and SW3âs e0/2 is blocking! So SW2 will actually declare itself the RB which will cause SW3âs Max Age timer to expire (because it wonât accept the BPDUs as they are inferior). Then, when SW3 sends the superior BPDUs from SW2, SW2 will not accept them because it violates the root guard policy 
You could implement an EtherChannel between SW1 and SW2 to mitigate this to a certain point, but the risk is still there.
The problem with Root Guard is that itâs not a 100% guarantee that it will guard your entire topology without any issues. It can mitigate other switches from becoming the Root Bridge, but only to a certain point. It is therefore important to design your network accordingly so you can apply Root Guard on the correct ports without worrying about a rogue switch taking over as the root bridge and ports being root inconsistent.
Take a look at this 2-tier design:
You could happily apply Root Guard on the distribution layer switch so the access switches never become the RB. Access switches in a 2-tier/3-tier design arenât connected together so you donât have to worry about anything there as their only connection is to the distribution layer.
If there is another distribution switch, the configuration is the same although a bit different.
Say, if you apply Root Guard on the links facing the access switches on the distribution switches, if the direct link between the distribution switches goes down, it will block the ports once the access switches advertise a superior BPDU to it. This can be solved by implementing an EtherChannel between the distribution-layer switches.
And even a better solution would be to not run a L2 topology but a complete L3 one instead That way you donât have to run STP at all so you donât have to worry about Root Guard, Loop Guard, etc.
David
1 Like
Thanks @andrew , one questionâŚhow can we fix this if port goes into âRoot Inconsistencyâ. Does it still function STP ( like sending BPDU ) and sending/receiving traffics ?. or is it mandatory to release the interface out of inconsistency? or how it would be done ?.
Hello Sathish
A port will remain in the Root Inconsistency state as long as superior BPDUs are being received. Once the superior BPDUs stop, the port will automatically go back to its operational state.
You could attempt to bring it back by shutting down the port and bringing it back up again, but if superior BPDUs are still being received, it will go into the inconsistency state again.
The proper procedure is to simply resolve the superior BPDU issue, and the root inconsistency state will resolve itself. Does that make sense?
I hope this has been helpful!
Laz
1 Like
Hello Sathish
From your description, it seems that the Root Guard feature is functioning correctly on SW1. Root Guard prevents a port from becoming a root port, thus protecting the bridge from receiving superior BPDUs on that port. This is why SW1 is protected as a root bridge.
However, SW2 is not protected by Root Guard and therefore itâs accepting superior BPDUs from SW3, making SW3 a root bridge between SW2 and SW3.
To mitigate this, you should enable Root Guard on E0/2 of SW2 as well. This will prevent SW2 from accepting superior BPDUs from SW3 and maintain the root bridge as it is.
Root guard does not necessarily mean that the local switch becomes the root. SW2 which is not the root can also have root guard configured on E0/2, and it can still receive superior BPDUs on E0/0 and recognize SW1 as the root bridge. Does that make sense?
I hope this has been helpful!
Laz
1 Like