Root guard best practices? Where to put it?

[pdub206]

Hey all,

We recently implemented root guard on our two core devices, on both ports that point to our distribution layer.  This broke the link from our secondary router to the distribution layer, which remains in a BKN state due to the root BPDU that passes through our distribution layer and into the router.  After doing this, we are now unable to pass traffic inbound from our secondary router.

I'm wondering what would be considered a best practice with root guard -- should we leave it where it is, or push it down to the distribution layer where the interfaces connect to our access switches? Topology attached here.

I will note that we are only allowing what vlans we need across each link, and currently we are not allowing all vlans across the trunk between R1 and R2.

[nspasov · Accepted solution]

Hello Patrick-

You should have root guard enabled on:

- Core ports that are connecting to the distribution switches

- Distribution ports that are connecting to the access switches

Similar to this diagram (I was going to draw one but a quick google search got me one :) )

http://www.rogerperkin.co.uk/ccie/wp-content/uploads/2013/03/spanning-tree-root-guard.jpg

Also, what is the reason for not allowing all VLANs on the link between the core switches? Ideally, you would not want to block on that link. This can also (depending on actual setup) cause some traffic to be send to a blackhole if certain links are to die off. If the diagram that you attached is accurate then you would probably want to:

- Connect each distribution switch to each core (create triangle type connections not squares)

- Remove the link between distribution switches (optional but IMO preferred)

- Allow all VLANs on the link between the two core switches

- Let STP blocking happen on the link that is between the distribution and core switches while the link between the two cores remain in unblocking state

Thank you for rating helpful posts!

[pdub206]

Hi Neno,

Unfortunately, the nature of our topology is that the core is in a separate building, and dark fiber provides the two links between distribution/core.  I'm unable to allocate two more strands in order to make the full mesh as I would have liked to. 

The initial configuration had only one router, and the second was added in later for high availability purposes.  We implemented HSRP and ran into some STP issues, so this has been an ongoing project for a while now.  I had tried to make the changes to the trunk link between core routers previously (switchport trunk allowed all), and an event occurred.  I had to console in to revert changes on one of the routers before the event passed.

I would very much have liked to design this from scratch correctly the first time around, but sometimes resources are locked up until after you've already begun.  I will post my results and hopefully have this resolved.  Thank you for your input and the visual aide!

[nspasov]

I feel your pain Patrick. I think we have all been there :) Sometimes you just have to work with what you have and vs what you actually need...let's just face it, we did not go into IT for the glory :)

Thank you for rating helpful posts!

[paul driver]

Hello

Just wondering: what issues you encountered when you allowed all trunks to cross the interconnected between the two stp cores?

What stp mode are you using pvst, rstp, mst ?
Do you have any additional stp features applied like, backbonefast, uplinkfast loopguard, udld etc.

Any port security features such as portfast, bpduguard, storm control.etc..

Lastly are all your devices cisco or do you have a mixture 3rd party vendor core, distribution and access switches?

res

Paul

 

[pdub206]

Hi Paul,

We run MST with no extra options enabled, and prune vlans that are not needed from the trunk links.  We're also a Cisco only shop at the moment.  A simple config from an internal trunk looks like:

 description L2 TRUNK TO STANDBY
 switchport
 switchport trunk encapsulation dot1q
 switchport trunk allowed vlan 23,24,48,72,99,102-105,107-111,200,201,300,400
 switchport trunk allowed vlan add 402,500-502,600-604,610,700-702,800,999-1001
 switchport mode trunk
 logging event spanning-tree status
end

I believe the issue with allowing some vlans over the trunk links was that we had two vlans used for VRF traffic forwarding outbound.  I believe the routing protocol in use may have had an event because of allowing the vlans over the trunk, but I'm still unsure at this point.  We allowed all of our access layer vlans across and everything is working fine now in all over our MST instances.

[paul driver]

Hello

"I will note that we are only allowing what vlans we need across each link, and currently we are not allowing all vlans across the trunk between R1 and R2."

So as to not make a distribution switch(s) wanting to be the root for one/more specific vlans which seems likely you are doing by not allowing all of then to cross between the primary/secondary cores interconnects

I would suggest you do allow all your vlans to cross the trunks between the two core switches so they have full visibility and receive the correct bridge priority's for being primary and secondary stp roots,

FYI - you apply rootguard where you don't wish that specific port to become a root port for that lan segment

res

Paul