MST and PVST+ Interoperability

MST (Multiple Spanning Tree) and PVST+ (Per VLAN Spanning Tree) both offer loop-free layer two topologies but they each use a different approach:

• MST maps multiple VLANs to an instance, reducing the number of spanning-tree instances.
• PVST+ calculates an instance for each spanning-tree instance.

The two versions are compatible but how should the two behave on the link that connects the two spanning-tree protocols?

PVST+ sends BPDUs for each instance/VLAN so you could let MST process each BPDU separately with the instance that is configured for the VLAN. MST, however, doesn’t have an instance for each VLAN so what kind of BPDUs should it send?

This is an issue…it is possible that two VLANs share the same MST instance but use different root bridges, root ports, and other attributes in the PVST+ domain. Which information should MST send in its BPDUs? There is no way to create a 1:1 mapping between the MST and PVST+ information.

Instead, when an MST region is connected to a PVST+ topology, MST is going to simulate PVST+ with a feature called the PVST simulation mechanism. What it does, is that the MST region will send PVST+ BPDUs (one for each VLAN) on the interfaces that are connected to PVST+ switches. These BPDUs all carry the same information and advertise the same root bridge. The interfaces that connect to the PVST+ topology are called boundary interfaces/ports.

Since PVST+ switches now receive BPDUs for each VLAN from MST carrying the same information, they will all make the same decisions when selecting a root bridge, root port, etc.

Where does the information that MST advertises in the simulated PVST+ BPDUs come from?  All MST switches have to agree on the same information, so we use the information from the IST for this. The root bridge in the MST region that is elected as the root bridge for the IST, will also be used in the PVST+ BPDUs that PVST simulation uses.

What about the other way around? From PVST+ to MST?

MST decides the port role (root, designated, non-designated) for the boundary interface for all VLANs only by looking at the information in the VLAN 1 BPDU.

Deciding the port role on the boundary interface for all VLANs is risky…after all, it means that we assume that all VLANs use the same root bridge, root ports, etc. We don’t know if the PVST+ domain agrees on the port role for all VLANs that we select on our MST boundary interface. There are, however, some simple checks that MST can use to figure out if PVST+ agrees on the port roles. Let’s take a look at each possible port role.

Designated Port

If MST wants to use the boundary as a designated port. It uses the following check:

MST BPDU from IST must be superior compared to each PVST+ BPDU from every VLAN that you receive on the boundary interface.

So, MST compares its own IST BPDU to all PVST+ BPDUs (one for each VLAN). If its own BPDU is superior, it knows that PVST+ agrees on the port role and we can safely turn the boundary interface into a designated port. If not, we know that PVST+ doesn’t agree on our port role and we block our boundary interface. The status of the interface shows up as broken.

Root Port

The boundary interface can become a root port if the VLAN 1 BPDU that it receives is the best BPDU that it receives on any of its boundary interfaces. This means, that the root bridge for VLAN 1 is located in the PVST+ domain. When this happens, the interface will go into the forwarding state for all VLANs. This is a tricky situation. MST acts as if all VLANs have their root bridge in the PVST+ domain and turns its boundary interface as the root port for all VLANs, but that might not be the case. To counter this, MST uses the following check:

PVST+ BPDUs for all VLANs except VLAN 1 must be identical or superior compared to the PVST+ VLAN 1 BPDU.

What this means is that MST listens to all PVST+ BPDUs that it receives on its boundary interface and checks if those BPDUs are superior compared to the VLAN 1 BPDU from PVST+. If so, MST can safely turn its boundary interface into a root port. If not, the switch reports an inconsistency error; the interface will be blocked and shows the broken state.

One caveat here is that PVST+ uses the system ID extension, which uses the VLAN number as part of the bridge ID. This makes it impossible to have PVST+ BPDUs from different VLANs with an identical value. Because of this, PVST+ BPDUs require a priority that is at least 4096 lower than the PVST+ VLAN 1 BPDU.

Non-designated Port

Last but not least, the boundary interface could be a non-designated port. It becomes a non-designated port if the boundary interface receives a VLAN 1 PVST+ BPDU that is superior to its own MST IST BPDU but not good enough to become a root port. In this case, the boundary interface becomes a non-designated port for all VLANs. MST has to check if the PVST+ domain also thinks this should be a non-designated port and it can quickly check this by listening to all PVST+ BPDUs. When the PVST+ BPDUs are superior to its own BPDU, it can become a non-designated port. Cisco switches don’t do any additional checks. Even if a superior BPDU was received, it would report a PVST inconsistency error and the port would go into broken mode, but since it’s blocked anyway, it doesn’t matter.

It is easiest to configure your network so that the MST region is the root bridge in your network. If your PVST+ domain has the root bridge, then MST will use the same root port for all VLANs. If the root bridge is in your MST region, then you change the cost per VLAN on your PVST+ switches to use different root ports and use a bit of load balancing.

Configuration

Let’s take a look at all of this in action. There are three switches I use:

SW1 will use rapid spanning-tree, SW2 and SW3 are going to use MST. We will use three MST instances and six VLANs. Let’s start by configuring the interfaces as trunks and add some VLANs:

SW1, SW2, & SW3
(config)#interface range GigabitEthernet 0/1 - 2
(config-if-range)#switchport trunk encapsulation dot1q 
(config-if-range)#switchport mode trunk 

SW1, SW2 & SW3
(config)#vlan 10
(config-vlan)#vlan 20
(config-vlan)#vlan 30
(config-vlan)#vlan 40
(config-vlan)#vlan 50
(config-vlan)#vlan 60
(config-vlan)#exit

We now have a basic configuration that we can use.

MST Root Bridge

In the first scenario, I’m going to use the MST region as the root bridge. VLAN 10, 20, and 30 will be mapped to instance 1, VLAN 40, 50, and 60 to instance 2. SW2 is going to be the root bridge for instance 0 and 1:

SW2(config)#spanning-tree mode mst

SW2(config)#spanning-tree mst configuration
SW2(config-mst)#name REGION1
SW2(config-mst)#instance 1 vlan 10, 20, 30
SW2(config-mst)#instance 2 vlan 40, 50, 60

SW2(config)#spanning-tree mst 0-1 priority 8192

SW3 will become the root bridge for instance 2:

SW3(config)#spanning-tree mode mst

SW3(config)#spanning-tree mst configuration
SW3(config-mst)#name REGION1
SW3(config-mst)#instance 1 vlan 10, 20, 30
SW3(config-mst)#instance 2 vlan 40, 50, 60

SW3(config-mst)#spanning-tree mst 2 priority 8192

SW1 is running rapid spanning-tree with its default priority. Let’s see what happens now when I try to make SW1 the new root bridge for one VLAN: