Content

| 3.5 |  | Evolution of Spanning Tree |
| 3.5.6 |  | Switchport tuning using root guard |

The traditional STP does not provide any means for the network administrator to securely enforce the topology of the switched Layer 2 network. This may become especially important in networks with shared administrative control. For example, one switched network controlled by different administrative entities or companies.

Forwarding topology of the switched network is calculated, based among other parameters, on the root bridge position. Although any switch can be Root Bridge in the network, it is better to place the root bridge manually, (somewhere in the core layer) so the forwarding topology will be optimal. The standard STP does not allow the administrator to enforce the position of the root bridge. If a bridge is introduced into the network with lower bridge priority, it will take the role of the root bridge.

> Note: Even if the administrator sets the root bridge priority to zero in an effort to secure the root bridge position, there is still no guarantee, as there might be a bridge with priority zero and a lower bridge ID. Root guard feature is designed to provide a way to enforce the root bridge placement in the network.

The root guard ensures that the port on which it is enabled is the designated port (normally, root bridge ports are all designated, unless two or more ports of the root bridge are connected together). If the bridge receives superior STP Bridge Port Data Units (BPDUs) on a root guard enabled port, this port will be moved to a root-inconsistent STP state (effectively equal to listening state), and no traffic will be forwarded across this port. The position of the root bridge will be enforced.

Consider an example of why a rogue root bridge can cause problems on the network and how root guard can help.

- Switches A and B comprise the core of the network and Switch 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 flow of STP BPDUs is shown with arrows.

In Figure device D begins to participate in STP. For example, software-based bridge applications launched on PCs or other switches connected by a customer to a service-provider network. If the priority of bridge D is zero or any value lower than that of the root bridge, the software bridge will be elected as a root bridge for this VLAN. In turn the Gigabit link connecting the two core switches will block, causing all the data in that particular VLAN to flow via a 100 Mbps link across the access layer. If there is more data flowing via the core in that VLAN than this link can accommodate, some frames will be dropped causing performance loss or a connectivity outage.

In order to protect the network against such issues, the root guard feature has been designed. Root guard is configured on a per-port basis, and does not allow the port to become a STP root port. This means that the port is always STP-designated, and if there is a better BPDU received on this port, BPDU guard disables the port, rather than taking the BPDU into account and electing a new STP root.

Root guard needs to be enabled on all ports where the root bridge should not appear. In Figure , root guard should be enabled as follows:

- Switch A: port connecting to switch C
- Switch B: port connecting to switch C
- Switch C: port connecting to switch D

In this configuration, switch C will block the port connecting to switch D, once it receives a better (superior) BPDU. The port will be put in a special STP state (root-inconsistent), which is effectively the same as the listening state. No traffic will pass through the port in this state. Once device D stops sending superior BPDUs, the port will be unblocked again and will go, via STP, into states of listening, learning, and eventually transition to Forwarding state. Recovery is automatic, no human intervention is required.

The following message is printed once root guard blocks a port.

> %SPANTREE-2-ROOTGUARDBLOCK: Port 1/1 tried to become non-designated in VLAN 77. Moved to root-inconsistent state