Based on the comments I think you are confused about
guard root. You configure
guard root on the downstream interfaces of all the switches, except the root switch. Basically, you are trying to protect the root interfaces on a switch (root switches do not have root interfaces) by preventing the other interfaces from becoming root interfaces. This will protect the topology that you have put in place. Interfaces that have
bpduguard do not need
guard root because they will disable if any BPDU (superior, or not) is received on the interface.
Cisco explains it in Spanning Tree Protocol Root Guard Enhancement. Notice in the example, it tells you to configure
guard root on the Switch C (non-root switch) interface toward Switch D.
The example in this section demonstrates how a rogue root bridge can
cause problems on the network and how root guard can help.
In Figure 1, Switches A and B comprise the core of the network,
and A is the root bridge for a VLAN. Switch C is an access layer
switch. The link between B and C is blocking on the C side. The arrows
show the flow of STP BPDUs.
In Figure 2, device D begins to participate in STP. For example,
software-based bridge applications are launched on PCs or other
switches that a customer connects to a service-provider network. If
the priority of bridge D is 0 or any value lower than the priority of
the root bridge, device D is elected as a root bridge for this VLAN.
If the link between device A and B is 1 gigabit and links between A
and C as well as B and C are 100 Mbps, the election of D as root
causes the Gigabit Ethernet link that connects the two core switches
to block. This block causes all the data in that VLAN to flow via a
100-Mbps link across the access layer. If more data flow via the core
in that VLAN than this link can accommodate, the drop of some frames
occurs. The frame drop leads to a performance loss or a connectivity
The root guard feature protects the network against such issues.
The configuration of root guard is on a per-port basis. Root guard
does not allow the port to become an STP root port, so the port is
always STP-designated. If a better BPDU arrives on this port, root
guard does not take the BPDU into account and elect a new STP root.
Instead, root guard puts the port into the root-inconsistent STP
state. You must enable root guard on all ports where the root bridge
should not appear. In a way, you can configure a perimeter around the
part of the network where the STP root is able to be located.
In Figure 2, enable root guard on the Switch C port that connects
to Switch D.
Switch C in Figure 2 blocks the port that connects to Switch D,
after the switch receives a superior BPDU. Root guard puts the port in
the root-inconsistent STP state. No traffic passes through the port in
this state. After device D ceases to send superior BPDUs, the port is
unblocked again. Via STP, the port goes from the listening state to
the learning state, and eventually transitions to the forwarding
state. Recovery is automatic; no human intervention is necessary.
This message appears after root guard blocks a port:
%SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77.
Moved to root-inconsistent state
This is another Cisco Root Guard diagram show the placement of
guard root, not on the root switch, but on the switches to be protected from a rogue root switch:
If the root switch is receiving superior BPDUs, then your topology is already compromised. It is not to protect the root switch, but it is designed to protect the rest of the switches from being fooled into thinking an incorrect switch is the root switch by protecting other interfaces from becoming root interfaces.