If you’re not running the Rapid Spanning Tree Protocol in your switched network, you should consider it. There are a number of significant improvements over the 802.1D spanning tree protocol that decrease the convergence to sub-second times when a spanning tree change occurs.
Note that RSTP is used for both per-VLAN spanning tree and for multi-VLAN spanning tree. We’ll discuss only the rapid-pvst mode.
The Rapid Spanning Tree Protocol (RSTP) has been around since around 2001 and was ratified as IEEE standard 802.1w in 2004. It is based on the Cisco extensions Port Fast, Uplink Fast, and Backbone Fast to 802.1D.
There are several new port roles in addition to the Root and Designated roles, shown in Figure 1.
An Alternate port is an alternate path to the root bridge while a Backup port is one that receives a BPDU from another port on the same switch (implying that there is a downstream hub).
The port states have been reduced to only three: Discarding, Learning, and Forwarding. The old states of Blocking, Listening, and Learning are mapped into the Discarding state. The result is reduced time for a port to make it to the Forwarding state.
The big difference with RSTP, however, is in how BPDUs operate. Every switch generates BPDUs and downstream switches acknowledge upstream BPDUs. This basically implements a keepalive mechanism that quickly identifies failed links or ports and is the fundamental mechanism that drives the faster convergence time.
There is a fall-back mode that allows a switch to properly communicate with another switch that is running the older style 802.1D spanning tree algorithm. The compatibility mode is on a per-port basis, so the existence of a legacy switch will affect only the link to its neighbors, not the entire spanning tree.
The Cisco document, Understanding Rapid Spanning Tree Protocol (802.1w), is a good explanation of the differences and how RSTP works. The important concept is that RSTP’s improvements reduce convergence time when a failure occurs.
To enable and verify RSTP on a Cisco IOS switch (the Juniper config is similar enough that I don’t need to repeat it here). Note that a mode change will cause the spanning tree in the switch to reset, so a connectivity outage will occur.
Router(config)#spanning-tree mode rapid-pvst
Router#show spanning-tree summary
Switch is in rapid-pvst mode
…
Note that CatOS doesn’t allow rapid-pvst if BackboneFast is enabled. A Cisco document, Spanning Tree from PVST+ to Rapid-PVST Migration Configuration Example, contains an interesting comment about running a mixed STP domain:
In mixed mode, you do not receive the complete advantages of rapid-PVST+. The overall convergence time is the same as the convergence time of PVST+ mode. In order to take full advantage of rapid-PVST+, all the switches in the spanning tree topology must run the rapid-PVST+ .
Given this constraint, how do you know that a spanning tree is running RSTP and that it isn’t constrained to slower convergence times? First, make sure that all switches are running RSTP by running the command show spanning-tree summary or using SNMP to query the value of stpxSpanningTreeType (Cisco-stp-extensions-mib).
Next, you need to make sure that all interfaces are connected to peers that are also running RSTP. With rapid-pvst+, this is done on a per-VLAN basis:
Switch#show spanning-tree vlan 80
VLAN0080
Spanning tree enabled protocol rstp
Root ID Priority 24656
Address 001e.133b.8480
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 24656 (priority 24576 sys-id-ext 80)
Address 001e.133b.8480
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Aging Time 300
Interface Role Sts Cost Prio. Nbr Type
——— —- — —- —– — ——–
Gi1/0/10 Desg FWD 19 128.10 P2p Peer(STP)
Gi1/0/14 Desg FWD 4 128.14 P2p
The differences in the Type field indicate that the peer on interface Gi1/0/10 is running STP and needs to have its config updated while the peer via interface Gi1/0/14 is running RSTP. The corresponding SNMP variable is stpxRPVSTPortStatus (CISCO-STP-EXTENSIONS-MIB):
[root@QAecampus03 root]# snmpwalk -c qasnmp 220.20.40.5
1.3.6.1.4.1.9.9.82.1.13.1.1.3.80
SMPv2-SMI::enterprises.9.9.82.1.13.1.1.3.80.10 = Hex-STRING: 10
SNMPv2-SMI::enterprises.9.9.82.1.13.1.1.3.80.14 = Hex-STRING: 00
The value of 10 indicates a peer switch not running Rapid PVST+, while a value of 00 indicates a peer that is correctly configured.
Leave a Reply