Deterministic Root Bridge Placement

Based on the previous discussion, you should now agree that deterministically setting your Root Bridge is a must. In fact, you should always set more than one Root Bridge one to act as the primary and another to act as a backup in the event the primary fails. If your bridged network is really large, you might want to even set a tertiary Root Bridge in case both the primary and the secondary fail.

This section considers how to deterministically place Root Bridges in your network. For considerations and recommendations on where you should place these devices, please consult Chapter 7.

There are two techniques available for setting Root Bridges:

The set spantree priority command
The set spantree root command

Manual Root Bridge Placement: set spantree priority

To force a particular bridge to win the Root War, you need to ensure that its BID is lower than all other bridges. One option might be to tweak the MAC address, but that could get ugly (trust me on this). A much simpler option is to modify the Bridge Priority. Because the high-order 16 bits of the BID consist of the Bridge Priority, lowering this number by even one (from 32,768 to 32,767) allows a bridge to always win the Root War against other bridges that are using the default value.

Bridge Priority is controlled through the set spantree priority command. The syntax for this command is:

   set spantree priority priority [vlan]

Although the vlan parameter is optional, I suggest that you get in the habit of always typing it (otherwise, someday you will accidentally modify VLAN 1 when you intended to modify some other VLAN). The text revisits the vlan parameter in more detail later. For now, just assume VLAN 1 in all cases.

Tip

Almost all of the Spanning Tree set and show commands support an optional vlan parameter. If you omit this parameter, VLAN 1 is implied. Get in the habit of always explicitly entering this parameter, even if you are only interested in VLAN 1. That way you don't accidentally modify or view the wrong VLAN.

Suppose that you want to force Cat-4 to win the Root War. You could Telnet to the switch and enter:

  set spantree priority 100 1

This lowers the priority to 100 for VLAN 1, causing Cat-4 to always win against other switches with the default of 32,768 (including the MGS with its lower MAC address).

But what happens if Cat-4 fails? Do you really want to fail back to the MGS? Probably not. Make Cat-2 the secondary Root Bridge by entering the following on Cat-2:

  set spantree priority 200 1

As long at Cat-4 is active, Cat-2 never wins the Root War. However, as soon as Cat-4 dies, Cat-2 always takes over.

Tip

Notice that I used 100 for the primary Root Bridge and 200 for the secondary. I have found this numbering convention to work well in the real world and recommend that you adopt it. It is easy to understand and, more importantly, easy to remember. For example, if you ever look at a show command and see that your current Root Bridge has a Bridge Priority of 200, you instantly know that something has gone wrong with the primary Root Bridge. This scheme also comes in handy when the subject of load balancing is discussed later.

Using a Macro: set spantree root

Starting in version 3.X of the Catalyst 5000 NMP code, Cisco introduced a powerful new macro to automatically program Bridge Priorities and other values. The full syntax of this macro is as follows:

   set spantree root [secondary] [vlan_list] [dia network_diameter] [hello hello_time]

To make a particular Catalyst the Root Bridge for VLAN 1, simply Telnet to that device and enter the following:

  set spantree root 1

This causes the Catalyst to look at the Bridge Priority of the existing Root Bridge. If this value is higher than 8,192, the set spantree root macro programs the local Bridge Priority to 8,192. If the existing Root Bridge is less than 8,192, the macro sets the local bridge priority to one less than the value used by the existing Root Bridge. For example, if the existing Root Bridge is using a Bridge Priority of 100, set spantree root sets the local Bridge Priority to 99.

Note

The current documentation claims that set spantree root sets the value to 100 less than the current value if 8,192 is not low enough to win the Root War. However, I have always observed it to reduce the value only by 1.

To make another Catalyst function as a backup Root Bridge, Telnet to that device and enter the following:

  set spantree root 1 secondary

This lowers the current Catalyst's Bridge Priority to 16,384. Because this value is higher than the value used by the primary, but lower than the default of 32,867, it is a simple but effect way to provide deterministic Root Bridge failover.

The dia and hello parameters can be used to automatically adjust the STP timer values according to the recommendations spelled out in the 802.1D specification. Tuning STP timers is discussed in detail in the "Fast STP Convergence" section of Chapter 7.

This might seem like a subtle point, but set spantree root is not a normal command it is a macro that programs other commands. In other words, set spantree root never appears in a show config listing. However, the results of entering set spantree root do appear in the configuration. For example, suppose that you run the macro with set spantree root 1. Assuming that the existing Root Bridge is using a Bridge Priority higher than 8192, the macro automatically issues a set spantree priority 1 8191 command. After the set spantree priority command is written to NVRAM, there is no evidence that the macro was ever used.

However, just because set spantree root is a macro, don't let that fool you into thinking that it is "unnecessary fluff." On the contrary, using the set spantree root macro has several benefits over manually using the commands yourself:

It can be easier to use.
It doesn't require you to remember lots of syntax.
If you must resort to timer tuning, set spantree root is safer than manually setting the timers because it calculates the values recommended in the 802.1D spec. See the "Fast Convergence" section of Chapter 7 for more detail on timer tuning.