root guard vs bpdu guard on edge access ports

[lloydXmas]

For me, I always use BPDUGuard on edge port and root guard on Core switch ports that connect to other switches.

However, with a customer I have seen they use root guard on all their access layer ports. The reason being, if a port is err-inconsistent, it can resolve itself instead of the NOC or other engineers having to login to have to manually clear it. 

is there any other concerns with using root guard on switch access ports instead of BPDUGuard?

[MHM Cisco World]

Yes' the Dis/Core link to access SW must config as root guard to prevent any access SW to be root and keep dis/core sw as root for stp domain.

Access to host port  can config as bpdu guard 

It have no need to config root guard in access to host port 

[MHM Cisco World]

See location of root gaurd between dis and access sw' and between access and host we config bpdu guard  

[lloydXmas]

I understand where and how to configure it. The core/dis ports are configured with root-guard to prevent any switch with coming the root. 

My question is, if a company decides to configure access ports with 'root-guard' for the sole reason as to prevent a routing loop if a user plugs in a switch. the port will go to err-inconsistent and thus be blocked. If user remove the switch/loop then the port goes back to normal operation which saves someone from manually logging in to unblock the port.

This seems similar to just using bpdugurad at the access layer ports and also "errdisable recovery cause bpduguard".

Again, my question is what are the things to be considered when using root guard at the access layer? 

[MHM Cisco World]

no need err-disable recovery as soon as SW that attend to be root remove or change it priorty the port retrun to STP FWD 

[Flavio Miranda]

Hi @lloydXmas 

 The fact of the port is configured with root guard does not remove the port from err-disabled.  They might have the command 

errdisable recovery cause bpduguard

If you have access to the switch, run the command "show errdisable recovery" and you can check that.

The difference between bpdu guard and root guard is that bpdu guard disable the port uppon BPDU reception and Root guard allow the device from particiapation on the STP as long as the device does not try to become a root.

[lloydXmas]

It does though...

the port will go to err-inconsistent and will effectively block the switch or loop until it is removed. Once removed, the port goes back to normal operating state which is why this customer uses it (for ease of blocking and recovering)

[Flavio Miranda]

I failed to find it in written but I will keep looking. To me I still believe they are using the command  "errdisable recovery cause bpduguard"

[lloydXmas]

With rootguard the port does not go to err-disabled. It goes err-inconsistent, which means when the device is removed from the port, it automatically goes back to normal operating mode. 

With err-disabled, you need to use recovery cause you mentioned as the port is permanently shutdown 

[M02@rt37]

hello @lloydXmas,

-- Using root guard on access ports might be seen as overly restrictive in some network designs. In a typical hierarchical network architecture, access switches should not have the responsibility of being the root bridge. Core or distribution switches are usually the best candidates for the root bridge. As such, using root guard on access ports might be an unnecessary precaution in such scenarios.

-- Root guard is primarily designed to protect against unauthorized switches attempting to become the root bridge in the spanning tree network. When root guard is enabled on an access port, if a switch with a lower bridge priority or a lower MAC address is connected to that port, the port will be put into a "root-inconsistent" state, effectively blocking it from becoming the root bridge. This can be beneficial to prevent accidental root bridge changes, but it may not be necessary on all access layer ports.

-- While root guard helps protect the network from unintended root bridge changes, it can also introduce additional complexity. STP convergence may be impacted when root guard is enabled, as the port has to go through a process of transitioning from a blocked state to forwarding once the inconsistency is resolved. This transition time can lead to temporary network disruptions.

[lloydXmas]

---

M02@rt37 wrote:

hello @lloydXmas,

-- Using root guard on access ports might be seen as overly restrictive in some network designs. In a typical hierarchical network architecture, access switches should not have the responsibility of being the root bridge. Core or distribution switches are usually the best candidates for the root bridge. As such, using root guard on access ports might be an unnecessary precaution in such scenarios.

---

This makes no sense! The idea here is to prevent a user at the access layer from forming a loop by connecting a switch or other device. BPDUGuard does this by shutting down the port when a BPDU is received. 

RootGuard does this by putting the port to err-inconsistent when w switch tries to become the root.

Question is, what is the difference when using either at the access layer.

[M02@rt37]

@lloydXmas,

when using either BPDU Guard or Root Guard at the access layer, the primary goal is indeed to prevent users from creating network loops by connecting unauthorized switches or devices.

Main difference between the two features lies in their approach to handling the situation:

BPDU Guard: As you correctly mentioned, BPDU Guard will immediately shut down the port if it receives any BPDU frames. This effectively prevents any potential loops at the access layer as soon as a switch or device generating BPDUs is connected. The port will be put into an "errdisable" state, and network administrators will have to intervene manually to bring the port back up after addressing the issue.

Root Guard: On the other hand, Root Guard works differently. It doesn't shut down the port immediately. Instead, if a switch connected to a port with Root Guard enabled sends superior BPDUs (BPDUs claiming to be from the root bridge), the port is put into a "root-inconsistent" state. In this state, the port is effectively blocking traffic, but it can still receive BPDUs. The port will remain in this state until the switch stops receiving superior BPDUs, effectively removing the threat to the Spanning Tree topology. Once the port stops receiving the superior BPDUs, it will transition back to the forwarding state.

Considering the differences:

-BPDU Guard acts more aggressively, immediately disabling the port upon BPDU reception.

-Root Guard is more lenient in the sense that it allows the port to remain operational as long as the superior BPDUs are being received, but it will block traffic until the threat is removed.

In most cases, BPDU Guard is the preferred option for access layer ports because it provides a more robust and immediate response to any unauthorized switch or device that might create a loop. Root Guard, as you pointed out in your original question, is more commonly used on uplink ports to protect the core/distribution switches from potential root bridge challenges.

[MHM Cisco World]

BPDU guard or root guard you need to remove the cause of Issue 
NOW BPDU guard can auto recovery and can not 
Root guard it already auto recover ONLY

[M02@rt37]

@MHM Cisco World,

The auto-recovery mechanism you mentioned might refer to the "errdisable recovery" feature that some network devices support. This feature allows the switch to attempt to re-enable errdisabled ports automatically after a specified time or after a certain number of occurrences. However, it is not specific to BPDU Guard; it applies to all errdisable reasons.

[MHM Cisco World]

Friend I mention auto recover (without specify type) because the bpdu guard use err disable auto recovery 

Root bpdu dont use this recovery it use stp recovery.