Root guard is a feature that can be used to influence which switches are eligible to become the root bridge. Although priorities are used to determine who becomes the root bridge, they provide no mechanism to determine who is eligible to become the root bridge. There is nothing to stop a new switch being introduced to the network with a lower bridge ID, which allows it to become the root bridge. The introduction of this new switch can affect the network, as new paths may be formed that are not ideal for the traffic flows of the network. Figure 4-24 demonstrates why you might need to configure root guard.
Figure 4-24. Root Guard Topology
In Figure 4-24, a new switch (Switch-D) has been added to the network by connecting to Switch-C. Currently Switch-A is the root bridge and has a gigabit connection to Switch-B, which is the secondary root bridge. A lot of server-to-server traffic traverses the link between Switch-A and Switch-B. Switch-D has been configured with the lowest priority in the network (a priority of 0 as indicated by the bridge ID of Switch-D), and thus becomes the root bridge. This has the effect of blocking the gigabit port (port 2/1) on Switch-B, severely affecting the performance of the network, because server traffic must travel over 100-Mbps uplinks from Switch-A Switch-C Switch-B and vice versa.
To prevent the scenario in Figure 4-24 from occurring, you can configure the root guard feature to prevent unauthorized switches from becoming the root bridge. When you enable root guard on a port, if superior configuration BPDUs to the current configuration BPDUS generated by the root bridge are received, the switch blocks the port, discards the superior BPDUs and assigns a state of root inconsistent to the port.
Once superior configuration BPDUs cease to be received, the blocked port once again resumes forwarding, meaning that the root guard feature is fully automated, requiring no human intervention.
In Figure 4-24, if you enable root guard on port 2/3 of Switch-C, when Switch-D starts sending superior configuration BPDUs, the port is immediately blocked, and the spanning-tree topology is not affected.
To implement the root guart feature, you must complete the following configuration tasks:
Enabling Root Guard
Figure 4-25 shows a simple spanning-tree network topology.
Figure 4-25. STP Topology
In Figure 4-25, Switch-A is the root bridge, and Switch-B is configured as the secondary root bridge. Switch-C and Switch-D are non-root bridges that connect end devices to the network.
This scenario assumes that a single VLAN (VLAN 1) is in use, and that Switch-A has been configured as the root bridge, with Switch-B configured as the secondary root bridge. All other spanning-tree parameters are configured as the default on all switches.
On CatOS switches, root guard is disabled by default, and you can either enable or disable the feature for physical interfaces. Root guard applies to the entire interface, meaning all STP instances have the configuration applied. To configure root guard on CatOS, you use the following command:
set spantree guard root mod/port
Root guard is disabled by default on Cisco IOS switch interfaces. Just as for CatOS, if you enable root guard on an interface, the feature applies to all STP instances. To configure root guard on Cisco IOS, you use the following interface configuration command:
To configure root guard in the topology of Figure 4-25, you should configure the feature on all ports that are attached to switches that will never become root bridges. Switch-A and Switch-B are the only switches that should ever become root bridges, so you should enable root guard on the following ports:
Example 4-32 demonstrates configuring root guard on ports 2/2 and 2/3 on Switch-A.
Example 4-32. Configuring Root Guard on Switch-A
Switch-A> (enable) set spantree guard root 2/2-3 Enable rootguard will disable loopguard if it's currently enabled on the port(s). Do you want to continue (y/n) [n]? y Rootguard on ports 2/2-3 is enabled. Warning!! Enabling rootguard may result in a topology change.
The configuration of Example 4-32 means that any switches connected to port 2/2 (i.e., Switch-C) and port 2/3 (i.e., Switch-D) cannot become the root bridge. If any superior configuration BPDUs are received on ports 2/2 or 2/3, Switch-A blocks the port, and the port has a state of root inconsistent. The following shows the SYSLOG message that is generated if a superior configuration BPDU is received on a port that has root guard enabled:
%SPANTREE-2-ROOTGUARDBLOCK: Port 2/2 tried to become non-designated in VLAN 2. Moved to root -inconsistent state
Once superior configuration BPDUs cease to be received on the blocked port, the switch restores the port as indicated by this message:
%SPANTREE-2-ROOTGUARDUNBLOCK: Port 2/2 restored in VLAN 2
Example 4-33 demonstrates configuring root guard on interfaces Fa0/2 and Fa0/3 on Switch-B.
Example 4-33. Configuring Root Guard on Switch-B
Switch-B# configure terminal Switch-B(config)# interface range fa0/2 - 3 Switch-B(config-if)# spanning-tree rootguard
The configuration of Example 4-33 means that any switches connected to interface fa0/2 (i.e., Switch-C) and interface Fa0/3 (i.e., Switch-D) cannot become the root bridge. If any superior configuration BPDUs are received on either interface, Switch-B will block the port.
Testing Root Guard
To test Root Guard, configure root guard on Switch-B and then configure Switch-D so that it becomes the root bridge. You should be able to then see root guard in action.