I got it, thank you!
1 Like
Hello, I am seeking clarification regarding the compatibility between MST (Multiple Spanning Tree) and RSTP (Rapid Spanning Tree Protocol) in our current network setup. We have two switches running MST in our VPC (Virtual Port Channel), connected via an EtherChannel to an access switch. The access switch is configured to run RSTP, and we are using two MST instances.
Could this configuration cause any issues? I would appreciate any insights on potential compatibility problems and suggestions for optimizing this setup.
Hey Laz,
Is it common to have PVST+ and MST configurations? If so, what would you recommend the ideal configuration would be? MST or PVST as root bridge?
Hello Houssem
MST and RSTP are STP protocols that are compatible and will interoperate directly without any significant issues, assuming the correct configuration. In your particular setup, you are incorporating some additional mechanisms including vPC and EtherChannel. MST/RSTP interaction should still work seamlessly, however there are some things you need to keep in mind when doing so. I will address the potential issues of MST/RSTP interaction in the context of vPC and EtherChannel. First letās take a look at how vPC and EtherChannel interact with STP in general:
- In a vPC environment, the two vPC peers (the MST-enabled switches) present a single logical STP entity to the rest of the network. This ensures that STP operates consistently and avoids loops caused by the dual-homing of devices.
- MST BPDUs are synchronized between the vPC peers so that the (RSTP-enabled) access switch sees the MST domain as a single logical switch.
- EtherChannel operates as a single logical link for STP purposes. This means that STP processes are performed on the logical port channel, not on the individual member links.
RSTP on the access switch will see the EtherChannel as a single link, and the same applies to MST on the vPC peers. - In a vPC, one peer switch sends the STP BPDUs for the port channel while the other peer suppresses its own BPDUs. It sends a duplicate BPDU of the other peer.
Now having said all of that, some of the issues that you should be aware of and that you may encounter include:
- Root Bridge elections - Make sure that the root bridge for the CIST is explicitly set to one of the vPC peers. If the access switch becomes the root, it may disrupt the desired topology. Make sure to use explicit priority settings to control this root bridge priority.
- Instance mismatches - Since the access switch runs RSTP and is unaware of MST instances, it will participate only in the CIST. This can result in suboptimal path selection if VLANs mapped to non-CIST MST instances on the vPC peers traverse the access switch.
- Misconfigurations in the vPC domain, such as inconsistent VLANs or improper STP configurations, could lead to loops or blocked ports.
Overall, this is a valid design. Keep these issues in mind and you should be OK! Let us know how you get along in your design and implementation!
I hope this has been helpful!
Laz
Hello Gordon
It is always ideal to run only a single STP protocol on a network. Running PVST+ and MST on the same topology is usually done out of necessity and not by design. This usually takes place when youāre interconnecting the networks of multiple sites due to a merger or a major reorganization of your network. It should ideally be a temporary situation until you can restore uniformity to your network.
The answer, as with most such questions, isā¦ āit depends.ā 
It depends on your network design and requirements.
Regardless of what protocols are being used, the general guideline remains that the root bridge should be the switch with the most stable and reliable connection, and the one that is most central to your network, since it plays a central role in determining the path that traffic will take through the network.
So there really isnāt a preference as to which STP protocol should run the root bridge. It is the topological criteria that play a more central role in this decision.
I hope this has been helpful!
Laz
Great answer. Thanks for clarifying that for me.
1 Like
Hello, I have the same problem. I have two switches in a VPC using MSTP, connected to another switch using RPST. I received the following message on the VPC primary switch:
"STP-2-PVSTSIM_FAIL: Blocking designated port port-channel10: Inconsistent superior PVST BPDU received on VLAN 2302, claiming root 88fe.0c9f.0000.1b08."After 20 seconds, I got another message:
"$ %STP-2-PVSTSIM_OK: PVST Simulation inconsistency cleared on port port-channel10."Since then, everything seems fine. However, the port states on the switches in the VPC went from BLK->LRN to FWD within 30 seconds.
My question is: why does this take 30 seconds, and why donāt I see the LSN state in the logs?
Thanks
Hello Houssem
Your scenario involves complex interactions between MST and PVST+ in a vPC environment. Thereās no exact answer to your query without some hands-on troubleshooting, but there are some principles I can share that can help you in your troubleshooting process.
When running MST on your vPC domain and connecting to a switch that is running a per-VLAN STP variant like Rapid-PVST you will often see messages about āPVST Simulationā inconsistencies. MST bridges must simulate a separate PVST+ instance for each VLAN so that PVST+ devices see a consistent spanning-tree domain. If MST detects a āsuperiorā PVST+ BPDU that conflicts with its own root information, it temporarily blocks the port to avoid a loop, then clears the inconsistency after a short convergence phase. More about PVST simulation on MST switches can be found here:
Regarding your questions:
- Why does the transition take 30 seconds?
- Spanning-tree transitions follow the traditional port states: Blocking, Listening, Learning, and Forwarding.
- In classic STP (802.1D-based), the Listening and Learning states each last 15 seconds by default, leading to a total of 30 seconds before the port moves to Forwarding.
- Even though you are using MST and PVST, when an MST region sees an inconsistent PVST BPDU, it often falls back to ālegacyā timer values for convergence. The port will go through Listening ā Learning ā Forwarding, which can take up to 30 seconds under default timers.
- Why donāt I see the āLSNā (Listening) state in the logs?
- Different platforms and code versions handle log messages somewhat differently. Not all intermediate STP port states (Listening vs. Learning) appear in real-time logs.
- Some systems only report major transitions (e.g., Blocking to Forwarding or vice versa) rather than every smaller step within the STP timers. By the time the device is ready to move from Listening to Learning and eventually to Forwarding, you may only see āLRNā (learn) in the logs or a final āFWDā transition.
- The important takeaway is that your switch did go through Listening and Learning, but it wasnāt necessarily explicitly logged line-by-line.
Since your port eventually moved to forwarding and the log shows the PVST Simulation inconsistency cleared, your network is now stable. The 30-second delay is just the normal āblocking to forwardingā progression under STPās default timers.
I hope this has been helpful!
Laz
Thank you @lagapidis
1 Like