Scenario 4-3: Configuring Root Guard

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.

NOTE

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.

Configuration Tasks

To implement the root guart feature, you must complete the following configuration tasks:

• Enable root guard

• Test root guard

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.

NOTE

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:

 spanning-tree rootguard 

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:

• Switch-A: Ports 2/2 and 2/3

• Switch-B: Interfaces Fa0/2 and Fa0/3

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.

Step 1.	On Switch-B, ensure that root guard is enabled on interfaces Fa0/2 and Fa0/3, as shown in Example 4-34. Example 4-34. Configuring Root Guard on Switch-B Switch-B# configure terminal Switch-B(config)# interface fa0/2 - 3 Switch-B(config-if)# spanning-tree guard root 14:46:27: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/2 on VLAN0001 14:46:27: %SPANTREE-2-ROOTGUARD_CONFIG_CHANGE: Root guard enabled on port FastEthernet0/3 on VLAN0001 Example 4-34 shows the console messages that appear when you enable root guard on a Cisco IOS switch.
Step 2.	On Switch-D, configure a priority of 0 for VLAN 1, as shown in Example 4-35. Example 4-35. Configuring IP on Switch-D Switch-D> (enable) set spantree priority 0 1 Spantree 1 bridge priority set to 0. At this stage, Switch-D has a lower bridge ID than the current root bridge (Switch-A). On Switch-B, you should see the following console message: 14:49:24: %SPANTREE-2-ROOTGUARD_BLOCK: Root guard blocking port FastEthernet0/3 on VLAN0001. This message indicates that interface Fa0/3 connected to Switch-D has been blocked, because superior configuration BPDUs have been heard on the interface and root guard is enabled.
Step 3.	On Switch-B, use the show spanning-tree inconsistentports command to display any interfaces that currently have an inconsistent STP state, as shown in Example 4-36. Example 4-36. Viewing Inconsistent Ports on Switch-B Switch-B# show spanning-tree inconsistentports Name Interface Inconsistency -------------------- ---------------------- ------------------ VLAN0001 FastEthernet0/3 Root Inconsistent Number of inconsistent ports (segments) in the system : 2 As you can see from Example 4-36, interface Fa0/3 in VLAN 1 is listed as root inconsistent.
Step 4.	On Switch-D, reset the priority for VLAN 1 to 32768, as shown in Example 4-37. Example 4-37. Configuring Priority on Switch-D Switch-D> (enable) set spantree priority 32768 1 Spantree 1 bridge priority set to 32768. At this stage, Switch-D has a higher bridge ID than the current root bridge (Switch-A). On Switch-B, you should see the following console message: [View full width] 14:58:58: %SPANTREE-2-ROOTGUARD_UNBLOCK: Root guard unblocking port FastEthernet0/3 on VLAN0001. This message indicates that interface Fa0/3 connected to Switch-D is now forwarding once again, because inferior configuration BPDUs have been heard on the interface.