When learning protocols, I like to build out a lab, take packet captures, debugs, and show commands and try to understand and justify the output. My most recent exercise is with PVST+. I built out the 6-switch topology below in CML. One of the first things I experimented with is bridge priority configuration. VLAN 10 is configured and 802.1Q trunked across all Interswitch links.

The bridge priority is a component of the bridge ID (BID). The BID is made up of the bridge’s base MAC address, the bridge priority, and the extended system-id (VLAN number). The lowest bridge ID in the STP domain wins the root bridge election. The default priority value is 32768, so the bridge with the lowest MAC address will win the root bridge election. It is advisable to control the root bridge election process by influencing the bridge priority to ensure optimal forwarding paths.

There are 3 methods of influencing bridge priority values. The priority can be explicitly configured in multiples of 4096. The other two methods are by issuing the “spanning-tree vlan x root [primary | secondary] commands. I personally recommend explicitly configuring bridge priority value on the switch that should be the primary root, and a secondary that can assume the root bridge role in case the primary root becomes unavailable.

Spanning-tree vlan x root secondary

In my testing, issuing the “spanning-tree vlan x root secondary” command simply decreases the default priority (32768) by 4096, making the priority value 28672. The local bridge has no way of knowing the priority value of every bridge in the network, so an assumption is made that every bridge except possibly the root has the default priority. This does not guarantee deterministic backup root placement. I proved this by configuring SW1 with priority 4096, SW4 with priority 12288, and issued “spanning-tree vlan 10 root secondary” on SW2. Notice that the running configuration on SW2 shows the configured priority that resulted from “root secondary” command being issued, instead of the actual configuration syntax that was issued. If SW1 goes down, SW4 will become the root bridge.

SW1# show running-config | sec spanning
spanning-tree mode pvst
spanning-tree extend system-id
spanning-tree vlan 10 priority 4096

SW2# show running-config | sec spanning
spanning-tree mode pvst
spanning-tree extend system-id
spanning-tree vlan 10 priority 28672

SW4# show running-config | sec spanning
spanning-tree mode pvst
spanning-tree extend system-id
spanning-tree vlan 10 priority 12288

Spanning-tree vlan x root primary

The “Spanning-tree vlan x root primary” command” is a little better. When this command is issued, the switch checks the current root bridge and configures the local priority to be better (lower) than the current root bridge. In my testing, this command caused the priority to become the current root bridge priority minus 4096. This approach works fine, as long as the spanning tree is converged when the command is issued. Recall that SW1 was configured with priority 4096, SW2 has priority of 28672 from the “secondary” command, and SW4 has priority 12288. To demonstrate a pitfall of this approach, I issued “spanning-tree vlan 10 root primary” on SW1 during a topology change event.

I first removed SW1’s priority configuration. This caused SW1 to default to priority 32768 and for the spanning tree to elect a new root, thus reconverge.

SW1(config)#no spanning-tree vlan 10 priority 4096
SW1(config)#do show run | sec spanning
spanning-tree mode pvst
spanning-tree extend system-id
SW1(config)#

During the reconvergence event, I issued the “root primary” command on SW1:

SW1(config)#spanning-tree vlan 10 root primary

This caused SW1 to set its priority to 27576:

SW1(config)#do show run | sec spanning        
spanning-tree mode pvst
spanning-tree extend system-id
spanning-tree vlan 10 priority 24576

Because the “root primary” command was issued during a topology change, SW1 was not yet aware of the superior priority configured on SW4. It is apparent the lowest priority SW1 was aware of is that of SW2, 28672. SW1 decremented SW2s value by 4096 to come up with 24576. 24576 is inferior to the priority configured on SW4, thus SW4 became the root bridge.

I used 802.1D compatible PVST+ for this lab, meaning that convergence is slow enough to easily cause this “priority problem”. It would have probably been harder for me to reconfigure priority settings fast enough with 802.1W (rapid) compatible spanning tree. Despite this, I recommend statically configuring bridge priority on the primary and secondary root bridges to ensure deterministic results.