STP Compatability

Submitted by rayc on Mon, 10/25/2021 - 09:38

Imagine if you will, your boss comes to you and says "Great news, we're getting all new equipment so now we can replace our old Catalyst 3500XL series core switch and 2900XL series access switches from the 1990's to some brand new Catalyst 9300 series switches" You might think all your Christmas's have come at once if you walk into a job using equipment that old and get some new stuff, either that or you could be clinically insane for taking a job like that? Either way, we now need to migrate our core network from legacy equipment running PVST+ to PVRST+ (Or MST but we'll talk bout that later) because why not use PVRST+.  For these examples, we have 3 switches connected redundantly with SW3 G1/0/2 interface in the BLK state. All switches are currently running PVST+ with SW1 as the root and have Backbonefast configured. SW3 is also configured with Uplinkfast. 

Topology for STP Compatibility examples

PVST+ and PVRST+

PVST+ and PVRST+ actually work pretty seamlessly together. You lose the RSTP features for recovering from a layer 2 failure between the two, but the switches will communicated and BPDU's will be sent and received without any issues. When migrating from PVST+ to PVRST+, backbonefast is not support. While it is not necessary to remove the backbonefast or uplinkfast configuration as it does nothing when RSTP is enabled because these features are built into RSTP, I personally would remove it as it removes an possibility of confusion for others when looking at the config. To removed the backbonebast configuration use the no command no spanning-tree backbonefast and to remove the uplinkfast configuration use the no command no spanning-tree uplinkfast. Feature like BPDUGuard, BPDUFilter, Rootguard, Loopguard and portfast are all still supported by RSTP so the configuration of those features is exactly the same and does exactly the same thing. 

negating backdonefast and uplink fast

When migrating to PVRST+ the process is very straight forward as both protocols are completely backwards compatible, however the process should still be done during an outage window as it will cause disruptions to dataflow as port states transition. In the above example, I have started the transition with the Core of the network, SW1. To change a switch to use PVRST+ use the global configuration command spanning-tree mode rapid-pvst. As soon as I ran this command connectivity to SW2 and SW3 was lost briefly while their interfaces transitioned. 

SW1 enabling PVRST+

As you can see the ports to SW2 and SW3 changed to the BLK state while the Max Age timer expired. Once expired, the ports transitioned to the learning state before reaching the final Forwarding state. The reason the Forward Delay timer and Max Age timer have to be used here is because SW2 and SW3 do not support the use of RSTP features to speed up failover. 

SW1 port status during PVRSTP transition

From the output you can see that SW1 can see both SW2 and SW3 as using 802.1D STP BPDUs and timers etc. Cutting over the other two switches in the topology to PVRST+ does not result in data loss as the Core Switch SW1 is already running PVRST+. When SW2 and SW3 are configured for PVRST+, the use of RSTPs features to speed up convergence kick in and the down time is minimal compared to the 50 seconds it took with the Core switch SW1. 

Below is the output of a debug debug spanning-tree events on SW3 after enabling it for PVRST+.

*Nov  9 01:25:23.231: setting bridge id (which=3) prio 32769 prio cfg 32768 sysid 1 (on) id 8001.2c4f.52e6.aa80
*Nov  9 01:25:23.231: RSTP(1): initializing port Gi1/0/1
*Nov  9 01:25:23.234: RSTP(1): Gi1/0/1 is now designated
*Nov  9 01:25:23.235: RSTP(1): initializing port Gi1/0/2
*Nov  9 01:25:23.236: RSTP(1): Gi1/0/2 is now designated
*Nov  9 01:25:23.237: RSTP(1): initializing port Gi1/0/3
*Nov  9 01:25:23.237: RSTP(1): Gi1/0/3 is now designated
*Nov  9 01:25:23.238: setting bridge id (which=3) prio 32778 prio cfg 32768 sysid 10 (on) id 800A.2c4f.52e6.aa80
*Nov  9 01:25:23.238: RSTP(10): initializing port Gi1/0/1
*Nov  9 01:25:23.240: RSTP(10): Gi1/0/1 is now designated
*Nov  9 01:25:23.240: RSTP(10): initializing port Gi1/0/2
*Nov  9 01:25:23.241: RSTP(10): Gi1/0/2 is now designated
*Nov  9 01:25:23.242: RSTP(10): initializing port Gi1/0/3
*Nov  9 01:25:23.242: RSTP(10): Gi1/0/3 is now designated
*Nov  9 01:25:23.243: setting bridge id (which=3) prio 32788 prio cfg 32768 sysid 20 (on) id 8014.2c4f.52e6.aa80
*Nov  9 01:25:23.243: RSTP(20): initializing port Gi1/0/1
*Nov  9 01:25:23.244: RSTP(20): Gi1/0/1 is now designated
*Nov  9 01:25:23.245: RSTP(20): initializing port Gi1/0/2
*Nov  9 01:25:23.246: RSTP(20): Gi1/0/2 is now designated
*Nov  9 01:25:23.247: RSTP(20): initializing port Gi1/0/3
*Nov  9 01:25:23.247: RSTP(20): Gi1/0/3 is now designated
*Nov  9 01:25:23.248: setting bridge id (which=3) prio 32798 prio cfg 32768 sysid 30 (on) id 801E.2c4f.52e6.aa80
*Nov  9 01:25:23.248: RSTP(30): initializing port Gi1/0/1
*Nov  9 01:25:23.249: RSTP(30): Gi1/0/1 is now designated
*Nov  9 01:25:23.250: RSTP(30): initializing port Gi1/0/2
*Nov  9 01:25:23.251: RSTP(30): Gi1/0/2 is now designated
*Nov  9 01:25:23.251: RSTP(30): initializing port Gi1/0/3
*Nov  9 01:25:23.252: RSTP(30): Gi1/0/3 is now designated
*Nov  9 01:25:23.266: RSTP(1): updt roles, received superior bpdu on Gi1/0/2 
*Nov  9 01:25:23.266: RSTP(1): Gi1/0/2 is now root port
*Nov  9 01:25:23.267: RSTP(1): syncing port Gi1/0/1
*Nov  9 01:25:23.268: RSTP(1): syncing port Gi1/0/3
*Nov  9 01:25:23.270: RSTP(1): starting topology change timer for 35 seconds
*Nov  9 01:25:23.270: RSTP(1): updt roles, received superior bpdu on Gi1/0/3 
*Nov  9 01:25:23.271: RSTP(1): Gi1/0/3 is now alternate
*Nov  9 01:25:23.272: RSTP(10): updt roles, received superior bpdu on Gi1/0/2 
*Nov  9 01:25:23.272: RSTP(10): Gi1/0/2 is now root port
*Nov  9 01:25:23.272: RSTP(10): syncing port Gi1/0/1
*Nov  9 01:25:23.273: RSTP(10): syncing port Gi1/0/3
*Nov  9 01:25:23.275: RSTP(10): starting topology change timer for 35 seconds
*Nov  9 01:25:23.276: RSTP(10): updt roles, received superior bpdu on Gi1/0/3 
*Nov  9 01:25:23.276: RSTP(10): Gi1/0/3 is now alternate
*Nov  9 01:25:23.277: RSTP(20): updt roles, received superior bpdu on Gi1/0/2 
*Nov  9 01:25:23.277: RSTP(20): Gi1/0/2 is now root port
*Nov  9 01:25:23.277: RSTP(20): syncing port Gi1/0/1
*Nov  9 01:25:23.278: RSTP(20): syncing port Gi1/0/3
*Nov  9 01:25:23.280: RSTP(20): starting topology change timer for 35 seconds
*Nov  9 01:25:23.280: RSTP(20): updt roles, received superior bpdu on Gi1/0/3 
*Nov  9 01:25:23.281: RSTP(20): Gi1/0/3 is now alternate
*Nov  9 01:25:23.282: RSTP(30): updt roles, received superior bpdu on Gi1/0/2 
*Nov  9 01:25:23.282: RSTP(30): Gi1/0/2 is now root port
*Nov  9 01:25:23.282: RSTP(30): syncing port Gi1/0/1
*Nov  9 01:25:23.283: RSTP(30): syncing port Gi1/0/3
*Nov  9 01:25:23.285: RSTP(30): starting topology change timer for 35 seconds
*Nov  9 01:25:23.286: RSTP(30): updt roles, received superior bpdu on Gi1/0/3 
*Nov  9 01:25:23.286: RSTP(30): Gi1/0/3 is now alternate
*Nov  9 01:25:23.287: RSTP(1): transmitting a proposal on Gi1/0/1
*Nov  9 01:25:23.288: RSTP(10): transmitting a proposal on Gi1/0/1
*Nov  9 01:25:23.289: RSTP(20): transmitting a proposal on Gi1/0/1
*Nov  9 01:25:23.289: RSTP(30): transmitting a proposal on Gi1/0/1
*Nov  9 01:25:23.307: RSTP(1): starting topology change timer for 35 seconds
*Nov  9 01:25:23.307: STP[1]: Generating TC trap for port GigabitEthernet1/0/2
*Nov  9 01:25:23.308: RSTP(10): starting topology change timer for 35 seconds
*Nov  9 01:25:23.308: STP[10]: Generating TC trap for port GigabitEthernet1/0/2
*Nov  9 01:25:23.309: RSTP(20): starting topology change timer for 35 seconds
*Nov  9 01:25:23.309: STP[20]: Generating TC trap for port GigabitEthernet1/0/2
*Nov  9 01:25:23.309: RSTP(30): starting topology change timer for 35 seconds
*Nov  9 01:25:23.310: STP[30]: Generating TC trap for port GigabitEthernet1/0/2
*Nov  9 01:25:23.317: RSTP(1): transmitting a proposal on Gi1/0/1
*Nov  9 01:25:23.317: RSTP(10): transmitting a proposal on Gi1/0/1
*Nov  9 01:25:23.318: RSTP(20): transmitting a proposal on Gi1/0/1
*Nov  9 01:25:23.318: RSTP(30): transmitting a proposal on Gi1/0/1
*Nov  9 01:25:23.352: RSTP(1): updt roles, received superior bpdu on Gi1/0/1 
*Nov  9 01:25:23.352: RSTP(1): Gi1/0/1 is now root port
*Nov  9 01:25:23.353: RSTP(1): Gi1/0/2 blocked by re-root
*Nov  9 01:25:23.354: RSTP(1): Gi1/0/2 is now alternate
*Nov  9 01:25:23.355: RSTP(10): updt roles, received superior bpdu on Gi1/0/1 
*Nov  9 01:25:23.355: RSTP(10): Gi1/0/1 is now root port
*Nov  9 01:25:23.356: RSTP(10): Gi1/0/2 blocked by re-root
*Nov  9 01:25:23.357: RSTP(10): Gi1/0/2 is now alternate
*Nov  9 01:25:23.358: RSTP(20): updt roles, received superior bpdu on Gi1/0/1 
*Nov  9 01:25:23.358: RSTP(20): Gi1/0/1 is now root port
*Nov  9 01:25:23.359: RSTP(20): Gi1/0/2 blocked by re-root
*Nov  9 01:25:23.360: RSTP(20): Gi1/0/2 is now alternate
*Nov  9 01:25:23.361: RSTP(30): updt roles, received superior bpdu on Gi1/0/1 
*Nov  9 01:25:23.361: RSTP(30): Gi1/0/1 is now root port
*Nov  9 01:25:23.362: RSTP(30): Gi1/0/2 blocked by re-root
*Nov  9 01:25:23.363: RSTP(30): Gi1/0/2 is now alternate
*Nov  9 01:25:23.404: RSTP(1): starting topology change timer for 35 seconds
*Nov  9 01:25:23.405: STP[1]: Generating TC trap for port GigabitEthernet1/0/1
*Nov  9 01:25:23.405: RSTP(10): starting topology change timer for 35 seconds
*Nov  9 01:25:23.406: STP[10]: Generating TC trap for port GigabitEthernet1/0/1
*Nov  9 01:25:23.406: RSTP(20): starting topology change timer for 35 seconds
*Nov  9 01:25:23.406: STP[20]: Generating TC trap for port GigabitEthernet1/0/1
*Nov  9 01:25:23.407: RSTP(30): starting topology change timer for 35 seconds
*Nov  9 01:25:23.407: STP[30]: Generating TC trap for port GigabitEthernet1/0/1

 

You can see that when SW3 transitioned to PVRST+, it assumed itself as the root and sent out BPDUs advertising as such. When the superior BPDUs were heard on its interfaces, the ports were transitioned to RP or ALT ports.

PVRST+ to MST

When migrating from PVRST+ or even PVST+ to MST, Cisco MST is backward compatible with legacy version of STP provided you understand how MST works. For example, when MST is on a boundary (as in an MST switch is connected to a non-MST switch or even a region Boundary) the MST switch only sends a single BPDU out using the CST IST Instance towards the downstream switch. This would be fine if we were using the industry standard 802.1D STP protocol, but PVST+ and PVRST+ both operate on a per VLAN basis and send BPDUs for each VLAN. Cisco MST, has a built in feature that allows it to detect when it's connected to a PVST+/PVRST+ switch and alter how it sends BPDUs. In our 3 switch example, when we first migrate SW1 to MST, SW2 and SW3 are still running PVRST+ and will send BPDUs for each VLAN attached towards SW1. SW1 now running MST, will receive the BPDUs for each VLAN and realise that it is connected to a PVST+/PVRST+ switch and in turn, will forward its own CST IST BPDU multiple times, one BPDU for each configured VLAN. This allows MST to simulate the required BPDU information to a PVST+/PVRST+ switch. 

When migrating to MST, it is important to remember a few things. 

  1. Always start from the Centre of the network and work your way out
  2. Take care to ensure that your VLAN and Instance mappings work out in accordance with your physical topology and select the Root and Secondary Root Bridge
  3. Before starting, ensure that you map out your region and which switches will be part of it. (There is no real benefit to breaking up your regions)
  4. Avoid mapping VLANs to the IST Instance 0.
  5. Ensure that the MST Root is the root for all VLANs.

 

In my topology, I have decided that SW1 will be the root, and SW2 will be the secondary. All VLANs will be mapped to a single Instance, MSTI1. My region name is WRMEM, and the MST configuration revision number is 1. For a reminder on how to configure MST click here. Starting with SW1, I first configure the mentioned MST options and ensure that it will become the root by changing the MST Instance priority. Once I have enabled MST on the switch, I can verify that the other switches are still reachable and that SW1 is the Root for all VLANs on all switches.

SW1 MST Configuration

To verify that SW1 is the root and that it has determined that SW2 and SW3 are both running PVST and is communicating as such, use the show command show spanning-tree mst 1

SW1 show spanning-tree mst 1

If we take a look at the output of show spanning-tree vlan 10 on SW2 we can see that it has referred back to standard STP timers etc when talking to SW1 but SW1 is still the root. 

SW2 show spanning-tree vlan 10

Cutting over SW2 and SW3 is simple and will cause minimal disruption to data flow as when all switches run MST, standard RSTP features are enabled. If going from MST to PVRST+ you would do the same thing but in reverse leaving the Core to be the last to be migrated.