PVST and MST (in)compatibility

Spanning-tree protocol configurations can cause headaches among network engineers. Especially if we have mixed topology, with more than one STP implementation. In this article, we will look closer at the interoperability between the Cisco PVST and MST. Based on two scenarios, I’ll show you the behavior of both protocols in different circumstances.

Topology

For both scenarios, the same topology will be used. It consists of two interconnected switches. On the MST-Switch, as the name implies, there is MST spanning-tree configured. It’s a virtual Cisco Nexus. The second device – PVST-Switch it’s configured for PVST, and it’s a Cisco IOS. On each switch, there are VLANs 1-39 configured. Interfaces on both switches are configured as trunks. The MST-Switch has 4 MST instances configured, which are described on the topologies.

Scenario 1

In the first scenario, the MST-Switch is configured to be a root bridge for this topology, because it has a lower priority than PVST-Switch.

The MST-Switch configuration is as follows.

spanning-tree mode mst
spanning-tree mst 0-3 priority 12288
spanning-tree mst configuration
  name garzumdotnet
  revision 321
  instance 1 vlan 10-19
  instance 2 vlan 20-29
  instance 3 vlan 30-39

As you can see, the VLAN assignment for MSTi 0 is not configured explicitly. Actually, it’s done automatically by the switch. Instance 0 always has all the VLANs that are not assigned to any other MSTi.

And the PVST-Switch configuration looks as follows.

spanning-tree mode pvst
spanning-tree extend system-id

Since we know the configuration let’s check the topology behavior. We will start with the MST-Switch.

The output was shrunk to the first three MST instances. As we can see, for the MSTi’s 0-2, the MST-Switch is a root bridge.

If you take a closer look at the priority of each MSTi, it varies from the configured value – 12288. It’s because for each MSTi, the switch adds the MSTi number to the configured priority. So the MSTi 0 has configured value of 12288, but the MSTi 1 has 12289, MSTi 2 – 12290, and so on.

We have the PVST-Switch connected to the Eth2/1 interface. It’s in the forwarding state, so we can assume, that everything works as expected. In the last column, we can see, that our Nexus switch detected, that there is another spanning-tree protocol configured on the connected switch.

Let’s now check the PVST-Switch.

The output was shortened because the state is pretty much the same for all the VLANs. We can see, that the PVST-Switch bridge priority is higher than MST-Switch, which implies that the Nexus is the root bridge. Interface G0/0, that’s interconnecting switches is in the forwarding state for all instances.

Conclusion

From the scenario above, we can assume, that if we have PVST and MST switch connected together, with the root bridge on the MST, everything works, and forwarding is not blocked.

Scenario 2

Now, we will filp the situation. The PVST-Switch will be configured as a root bridge. To accomplish this, we will change the priority of all VLANs to 0. It will be lower, than configured priority on MSTis.

The configuration changes are as follows.

PVST-Switch(config)#spanning-tree vlan 1-39 priority 0

Let’s now check the spanning-tree status on the PVST-Switch.

As we can see, the situation changed. The PVST-Switch is now a root bridge for VLANs 1-2 (and all others not shown in the picture). The Gi0/0 interface is now designated and has forwarding status.

Let’s now check the MST-Switch.

There was generated a log message about changes in the spanning-tree. Let’s examine it.

MST-Switch# 2022 Apr 21 07:57:18 MST-Switch %STP-2-PVSTSIM_FAIL: Blocking root port Ethernet2/1: Inconsistent inferior PVST BPDU received on VLAN 2, claiming root 0002.0c5d.9877.0000

The log message might be mysterious at first, but even from the first look, we can see that something is wrong. There’s information, that port Eth2/1 was blocked. It’s our interface, that faces PVST-Switch. Next, we can see, that there is inconsistent inferior PVST BPDU that claims root for VLAN 2. If we take a closer look at the bridge ID, we can see, that it’s a priority (0002) combined with PVST-Switch bridge ID (0c5d.9877.0000).

Let’s check the actual status.

The situation becomes a little messy here. For all the MST instances, we have information, that the MST-Switch is a root bridge. It may be strange at first because PVST-Switch has a lower(better) priority configured, so it should act as a root bridge. But if we take a look a the interface information, we can see, that Eth2/1 in all instances is in the blocking state – with an asterisk. We can see in the last column the reason for the block – it’s PVST inconsistency.

Conclusion

If we’re interconnecting the MST and PVST switches together, and we want to have a root bridge for all the VLANs in the PVST domain, it won’t work. As you can see from the scenario above, we have two separated islands. The spanning-tree protocols are not cooperating with each other in such configuration, but it’s not the worst thing. The interface is in the blocking state on the MST-Switch, which means that no data traffic will be sent there, which implies no communication between those two switches (and potential hosts connected to them).