Implementing Root Guard in an STP topology

[Mitrixsen]

Hello, everyone.

I am covering Root Guard for STP and I feel like I've hit a roadblock.

I understand how this feature works and what it does, I am just not sure where exactly should it be implemented. When it comes to Root Guard, it's all a matter of who the RB is and how the network is designed, right?

Take a look at this

The desired result is to have SW3 as the primary root and SW4 as the secondary (I've configured the priorities to achieve that) with root guard enabled, so an unauthorized/misconfigured switch won't replace them.

On SW3, I could configure root guard on both its G0/1 and G0/2 ports, correct? But on SW4, I can't configure it because if I did configure it on G0/2, it would block BPDUs from SW1. If I configured it on G0/1 and the G0/2 link went down, SW4 would not accept the BPDUs from the alternate path.

But this raises the question: you configure root guard to prevent an unwanted switch from becoming the RB. If SW4 is left unconfigured, what prevents us or someone else from making a misconfiguration and having SW4 accept someone else as the RB since there is no root guard to block it?

David

[Torbjørn · Accepted solution]

You configure root-guard towards "downstream" switches. In this case you would configure it on Gi0/1 on both SW3 and SW4. You are correct in that a SW3-SW4 link down situation would prevent the backup path from working. In your network design you should try to avoid the issue of the SW3-SW4 link going down by configuring it as an etherchannel.

You could also configure it on Gi3 on SW3, this will prevent a misconfiguration of SW4 causing issues for SW3. The downside to this would be ina situation where SW4 claims to be root while both SW3 and the link towards SW4 is down. This can be prevented by implementing UDLD/Bridge-assurance between SW3 and SW4.

Unfortunately, I don't think there is anything to be done to completely eliminate the risk of a SW4 misconfiguration. This would mostly have to be prevented by implementing solid authentication and procedures.

[M02@rt37]

Hello @Mitrixsen 

On SW3, enabling Root Guard on both G0/1 and G0/2 ports is appropriate because this will block any inferior BPDUs from switches like SW1 or SW2, ensuring that SW3 maintains its role as the primary root. However, for SW4, the configuration requires careful consideration. If you enable Root Guard on SW4's G0/2 port, it would block BPDUs from SW1, potentially disrupting the network if SW4 needs to assume the role of the root bridge. If you configure it on G0/1, SW4 might not accept BPDUs from SW3 if the G0/2 link goes down, which would prevent SW4 from taking over as the secondary root bridge as intended.

This leads to a critical consideration: the placement of Root Guard to protect the root bridge election process while ensuring network stability. On SW4, not configuring Root Guard on its ports could expose the network to the risk of another switch becoming the root bridge if SW4 accepts BPDUs from a rogue switch.

A balanced approach might involve configuring Root Guard on ports facing access layer switches or other potential entry points for unauthorized switches but avoiding its use on links between the primary and secondary root bridges (SW3 and SW4). This way, you protect the core of the network from misconfigurations or unauthorized devices while maintaining the designed root bridge hierarchy.

[Joseph W. Doherty]

As both your OP and other replies describe, the underlying problem is an alternate path transiting other switches.  Etherchannel has been mentioned but there are other possible options too.  However, the fundamental problem is a L2 topology.  I realize from many of your recent posted questions, you're studying STP.  Nothing wrong with that unless you don't appreciate why topologies based on L3 are recommended (i.e. in the real world we don't want to greenfield L2 topologies).

BTW, a clue about STP merits is all the proprietary Cisco STP enhancements.

[Mitrixsen]

Hello.

I am studying for a certification exam (ENCOR) so STP is something I have to cover. I look forward to seeing the L3 topologies.

[Torbjørn]

Good luck with your studies! It'll be well worth the efforts. Remember to also check the Learning network.

[Joseph W. Doherty]

Yup, that's fine, any you may still run into a STP environment you need to maintain.

However, in a brownfield STP environment, if you see it could be improved with STP enhanced features, you might want to also determine if it might improved using L3.  (Laugh, not against making any STP improvements within a brownfield environment.  Somewhat surprisingly, you'll often find the default pvst being used, and to me, an "easy" and worthwhile upgrade is moving switches to rapid-pvst [remember in a prior posting reply, I mentioned rapid standard covers some of Cisco proprietary STP enhancements too?].)

(BTW, FYI, when I write replies, I not only try to directly address the OP issue, but will often mention side issues that might be overlooked, by the OP or other readers.  For example, for your OP topology, if this was for real, besides L3, possibly REP rather than STP or perhaps the four switches might become two virtual stack pairs, or . . .)

[Mitrixsen]

Absolutely!

I appreciate your help and tips here guys!

[MHM Cisco World]

It root guard but it work on port, it prevent port to become root port. 

Where I can config, 

The four SW you share 

Is not common, usually all topology use triangle design 

Two core SW which config as root primary and root secondary 

Third access SW, 

The access SW two port connect to core SW can not config as root guard since it will effect election of access SW of primary or secondary root sw

Other port in access SW can config as root guard.