Root Guard

[carl_townshend]

Hi guys

just brushing up on some topics.

If you have a network, say core, fiat and access all connected with redundancy, on which ports would you enable root guard?

my thought was user facing ports and the ports on the core, all other uplinks in the ring etc should have it off?

cheers

[Joseph W. Doherty]

https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/best/practices/recommendations.html#wp1052377

[Joseph W. Doherty]

---

@carl_townshend wrote:

If you have a network, say core, fiat and access all connected with redundancy, on which ports would you enable root guard?

For "your" network, in theory (you know what you're doing, and control all your switch configs), shouldn't be any need for root guard.  It's purpose is, principally, to protect you from other switches, administrated by another party, yet part of your L2 domain, to preclude them shifting your root switch.

---

@carl_townshend wrote:

my thought was user facing ports and the ports on the core, all other uplinks in the ring etc should have it off?

Ah, as for user ports, i.e. ports a "rogue" STP capable switch could be connected, BPDU Guard, would be the option to enable on those ports.

If unclear, there's a huge distinction between obtaining a "superior" BPDU, on a port, where BPDUs are expected/desired, vs. on a port where no BPDUs are expected.

[Royalty]

Hi @carl_townshend,

I'm going to share some official recommendations, with a bit of my own opinions mixed in

It is recommendation from many that you enable Root Guard on links that should not become root, and further, it should be enabled on downstream designated port (DP) links to other switches that lead away from the root.

An example of the above (from Cisco documentation and others) is to enable it on links from the core to distribution and/or links from the distribution to access, but it depends on the design. There is no problem with applying it to user-facing ports connected to end-hosts as well, but generally BPDU Guard is applied on user-facing ports as a way of preventing users/guests/attackers from connecting other LAN switches. BPDU Guard is preferred, as connecting unauthorised switches to the network, regardless of their STP root priority, opens the door to a magnitude of LAN network security attacks. Since BPDU Guard puts ports in the error-disable state if a BPDU is received, it is inherently more restrictive than Root Guard and is activated before Root Guard could ever have an effect anyway.

In my opinion, Root Guard has a good place on ports that connect different STP domains/boundaries together. Another good location, albeit related to the first, is on ports connecting to switches outside of your administrative control.

You have to consider your design on determining where to apply Root Guard, or if it is a good idea. Root Guard serves to prevent mistakes and misconfiguration more-so than it does prevent a malicious attacker, but I personally don't believe this to be much value in justification. BPDU Guard should take care of unauthorised access in building locations where attackers have access to connect other switches to Data Points. If an attacker is able to access the physical switch to physically plug into a port where no BPDU Guard is enabled (i.e. uplink ports), there are way bigger problems than Root Guard not being applied there too.

An example where Root Guard could cause issues... If you have an L2 switched design with a primary and secondary STP root that are directly interconnected, and that direct link fails, STP will need to re-elect root ports via downstream access-layer links. If those downstream ports have Root Guard configured, they will transition to root-inconsistent state, preventing STP from converging correctly

I am actually of the opinion that Root Guard in general is best used to interconnect other L2 switched domains under other administrative control, not between links to trusted managed network devices within one administrative domain. Root Guard can, as described above, fundamentally undermine the nature of STP Convergence. A switch you may never intend to become root may need to become root as part of a failover scenario. Not all networks are privy to resilient design, switch stacking technology, and/or are configured according to best practice for Root Guard to be effective.

Sometimes rambling can provide a lot of useful information; hopefully that is somewhat useful or welcomes discussion!

[M02@rt37]

Hello @carl_townshend 

Root guard should be enabled only on downstream facing ports where the switch must never receive a superior BPDU... So, core-to-distrib and distrib-to-access links.

It should'nt be enable on uplinks toward the root bridge or on redundant inter-switch links where stp need to converge "normally".

On user-facing ports, BPDU guard is preferred instead of root guard.

[Cristian Matei]

Hi,

   If in your case access switches are connected to core / dsitributuion switches, where core / distribution switches would be your STP root bridge (primary and secondary in case of redundancy at this level), you would enable Root Guard on the core / distribution switches, on the downstream ports facing access switches.

Thanks,

Cristian.

[paul driver]

Hello
Access-Switches
you don’t want root guard applied on these as they require resilience between your distribution, it can be argued that RG on the edge ports, but unless they are being trunked ( not administrative mode of access ) not applicable

Distribution
Not to be applied anywhere.

Core
Defiantly applicable to be applied on STP domain boundary ports
Again it can be argued also on downstream links towards the distribution, However it all depends on how the cores interact with each other and the distribution, if they are only interconnected via distribution switches then it will not be feasible to apply RG on downstream links 

[Joseph W. Doherty]

@carl_townshend , from the multiple replies, possibly it seems there's some difference of opinion regarding application of Root Guard.  However most of those differences are based on personal preferences.

At one end of the spectrum, you might not bother at all.  This might be if you see it as a low risk of it happening or, in modern networks, which are L3, there's no real major multi node L2 domain.

The other end of the spectrum, is you apply Root Guard every where you can that will insure the L2 network functions as you intend without any possible disruption.  This, though, has to be done with great care.  One might assume we only want our one root switch to be the root or the secondary, but what if the L2 network breaks and becomes partitioned?

So, the Cisco recommended best practice, if you're going to use this feature at all, you use it on an administrative boundary where your administrative neighbor could "accidentally" replace your root with one of their switches.  As such administrative boundaries are often some leaf in a larger L2 topology, often the root being there could be very impactful.

Above I mentioned L3 often avoids the need for Root Guard, but even in L3 we might use controled redistribution between ASs.  Same boundary concept.

As to edge ports, we shouldn't be receiving BPDUs on them, which is why BPDU Guard is recommended for those.  As it blocks all BPDUs it, and BPDU filter, negate any need for using Root Guard.

Possibly an interesting question to all our posted replies, do you always use Root Guard as described?

Personally, I don't recall ever using it.  Firstly, networks I've supported have been L3, or if not, migrated to L3.  Second, very rare had a shared L2 topology with an administrative boundary, and the one instance I recall, used BPDU Filter.