Root guard clarification

[nuggetinu]

For the sake of clarification, Cisco's site on STP states that "The root guard ensures that the port on which root guard is enabled is the designated port. Normally, root bridge ports are all designated ports, unless two or more ports of the root bridge are connected together."

The last part is confusing. How can two or more ports of the root bridge.

An illustration of a diagram featuring this possibility may help me understand this statement. Thanks in advance!

[Julio E. Moisa]

Hi

Usually the root guard is configured under the designated ports (facing to non root bridge switches). Now if your root bridge has 2 or more ports connected to the backup (secondary) root bridge, the root guard is not required. If you have 2 or more ports of the root bridge connected to itself it could generate loops. 

Hope it is useful

:-)

[Peter Paluch]

Hi Julio,

Usually the root guard is configured under the designated ports (facing to non root bridge switches).

I certainly see this often said about the Root Guard - and I would like to respectfully challenge this.

Consider this:

Now imagine that Sw1 is the root bridge, and that you configure both its fa0/1 and fa0/2 with Root Guard. Later, if someone changes the priority on Sw2 or Sw3 to make them the new root bridge instead, the Root Guard configured on Sw1 fa0/1 and fa0/2 will cause both these ports to become blocked, as they will refuse to become new Root Ports. What will be the net result, however? Sw1 will get isolated from the network, and the rest of the network will converge to the new root bridge, anyway. So has the Root Guard here done anything useful here? Hardly.

I also often see yet another incorrect explanation of the Root Guard placement: Assume that Sw1 is a root bridge, and Sw2 is the secondary root bridge. On Sw3, it would be the f0/3 that would be put into Alternate Discarding role/state to break the loop. Now, I keep seeing Root Guard being recommended to be configured on Sw3 f0/3. However, this is also wrong: If the f0/2 link between Sw1 and Sw3 failed, then the f0/3 link would be required to restore the connectivity of Sw3 to the rest of the network - but if f0/3 on Sw3 would be configured with the Root Guard, the port would get blocked, so again, instead of doing anything useful, Root Guard would only impair redundancy in your network.

Root Guard is not intended to be used inside your own network. Your own network is a controlled and trusted environment. If a root bridge changes, or if a Root Port on a given non-root switch needs to change, it is not because of a malicious event but rather because either you have made a deliberate configuration change, or the network has experienced a topology change and STP absolutely must take action to keep the network connected, yet loop-free. Putting Root Guard inside your own network would impair this self-healing property of STP.

The real purpose of Root Guard can be shown here:

Assume that the network in the oval is your network, and the cloud is someone else's network which you do not have control over. In addition, assume that you need to interwork your STP with STP in the cloud. STP being an unauthenticated protocol (for a very good reason) would here be totally at the whims of the operator of the cloud, and if the cloud suddenly decided to have its own root switch, it could overthrow your own root bridge (let's assume it is Sw1) and that is something you may not want.

So what you can do here is to configure the f0/4 on both Sw2 and Sw3 with the Root Guard. If the cloud tried to hijack the role of the root bridge, the f0/4 would become Root_Inconsistent and blocked, and your own network would be safeguarded against this unintended change of the root switch. As a collateral effect of Root Guard, if your network became partitioned (let's say that both f0/2 and f0/3 links failed), it would not heal itself through the cloud which is usually what the operator of the cloud would want to prevent, anyway (he does not want to be your connectivity backup).

To sum it up: Root Guard is not supposed to be activated inside your own network; there is nobody and nothing to prevent against. Root Guard is intended to be used on boundary ports toward a foreign uncontrolled network which needs to interoperate its STP with our STP, to make sure that the foreign network does not attempt to have its own root bridge, and overthrow our topology.

Best regards,
Peter

[Julio E. Moisa]

Hi Peter,
Thank you, I have read some articles and books and probably they have misunderstandings. Thank you so much, believe me I really enjoy your explanations.
:-)

[paul driver]

Hello Peter

Great post as usual, Just one thing in your topology, lets say sw1-sw2 are primary/secondary cores and root bridges and you apply root guard on sw1 -fa0/2  sw2-fa3 facing sw3 then would you agree this would be applicable, As the only isolated switch would become the Sw3 if for some reason that was promoted to stp root.?

res

Paul

[Peter Paluch]

Hi Paul,

Thank you!

lets say sw1-sw2 are primary/secondary cores and root bridges and you apply root guard on sw1 -fa0/2  sw2-fa3 facing sw3 then would you agree this would be applicable

Well... Yes, if in this particular topology, the Root Guard would be applied as you suggested, and if someone later configured Sw3 with a lower priority, it would become a root bridge in its own right but it would be a root bridge just for itself, as Sw1 and Sw2 would block their ports to Sw3, and keep their own idea of a root bridge. This, however, is just a variation on my "cloud" example earlier: The scenario you have proposed already includes Sw3 as the untrustworthy switch into the cloud.

However, what if all three switches were yours, thus trustworthy, and the f0/1 between Sw1 and Sw2 failed? Assuming that Sw1 is a root bridge, then to keep the network connected, Sw2 would need to make its f0/3 port a Root Port. But if f0/3 on Sw2 is protected with Root Guard, it will get blocked instead, and you will end up with Sw2 cut off the network completely.

This is why I believe that Root Guard is not supposed to be used inside your own network topology, because it actually defeats your redundancy.

Best regards,
Peter

[paul driver]

Hello Peter

Cheers for the clarification 

kind regards
Paul

[Peter Paluch · Accepted solution]

Hi,

Regarding the Root Guard, it should better be said that the Root Guard prevents a port from becoming a Root Port. It can have any other role - Designated, Alternate, Backup - but it is not allowed to become a Root Port. Should the port protected with Root Guard really start receiving such superior BPDUs which would ordinarily make it a new Root Port, it will be instead moved into Root_Inconsistent Discarding state, and will nor transfer any data until it stops receiving those superior BPDUs.

This is typically used when you are interconnecting two networks together that should run a common STP, but you want to make sure that one network does not hijack the root bridge in the other. The Root Guard on all boundary ports between the two networks would accomplish this: As soon as the other network tried to have its own root bridge, Root Guard would get the boundary ports blocked, and the information about the "wrong" root bridge would be ignored.

Normally, root bridge ports are all designated ports, unless two or more ports of the root bridge are connected together.

This statement is correct but in relation to Root Guard, it is in fact irrelevant. It says this:

If you have a root bridge, and connect two of its ports together, then one port (typically f0/1) will be Designated Forwarding, the other (typically f0/2) will be Backup Discarding. As you can see, this is a fundamental property of STP and has nothing to do with the Root Guard.

Feel welcome to ask further!

Best regards,
Peter