I have following diagram and two distribution switch connected back to back over vPC
Related spanning-tree question is it ok to use RootGuard on both distribution switch where access switch is connected or i should only use RootGuard on ROOT switches?
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 portfast and 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.
Figure 1
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 outage.
Figure 2
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
Edit:
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.
RG from my TOP two switch from my diagram and just keep RG in middle layer toward access layer switches, is that right?
rootguard on the root switch doesn't actually accomplish anything. Its what the other switches believe that matters because they are the ones determining the direction to send frames. Basically, if the root switch is receiving superior BPDUs, then the rest of the topology is already compromised.
Root Guard exists to stop a rogue or misconfigured switch becoming the root bridge in a network which would cause disruption of the spanning tree topology. Usually your core switch should be root bridge. If a switch in a lower layer became root, not only would it cause a reconvergence of the STP topology (causing an outage), but it would also create an inefficient topology rooted at a lower capacity (hardware and interface bandwidth) and less connected switch. Root Guard can be configured on any port that should not become a Root Port (i.e. it should not be facing a Root or Secondary Root switch). The port can then only become a designated or blocking port.
You could potentially configure Root Guard on your downlinks (towards the access layer) on both the core layer and distribution layer switches, but consider the following:
If Root Guard is configured on the core switch only (on downlinks only, do not configure on core to core links) and an access layer switch generates a superior BDPU, the core switch will chop off the link to the distribution switch. This will disconnect the distribution layer switch, disconnecting ALL access layer switches connected to that distribution switch.
If Root Guard is configured on the distribution switch and the same superior BPDU is received, it will only disconnect the single access layer switch.
Configuring on both the core and distribution layer adds an extra layer of protection in case you forget to add it to one of the downlinks on the distribution layer switch, but in a correctly configured network, you should only need to configure Root Guard on the distribution layer downlinks.
I guess there is a situation where a core-core (i.e. root to secondary root) link could be severed. If Root Guard was configured on the downlinks of both core switches, the distribution layer would not be used as a path to the secondary root (Root Guard would chop it off on the secondary root). If there were any single-homed switches/hosts connected directly to the secondary core they would be disconnected from the network, but this is an unlikely scenario.