cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
83
Views
1
Helpful
2
Replies

Implementing Root Guard in an STP topology

Mitrixsen
Level 1
Level 1

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

Mitrixsen_0-1720953243292.png

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

2 Replies 2

Torbjørn
Spotlight
Spotlight

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.

Happy to help! Please mark as helpful/solution if applicable.
Get in touch: https://torbjorn.dev

M02@rt37
VIP
VIP

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.

 

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.
Review Cisco Networking for a $25 gift card