Rapid PVST+ support

[ZacharyVoskuil]

Is there any info on potentially releasing support for Rapid PVST+ on the MS series?

I have MS350-48s in a few colos that would benefit from it.

[Nolan H.]

Doubt it, however the only hope that I can see for this is maaaaaaaaybe the new MS390 since it is 'cisco hardware' with meraki software. But i'm not holding my breath

https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide#Rapid-PVST

Rapid-PVST
This is a Cisco proprietary protocol on Catalyst/Nexus switches that is compatible with spanning tree (802.1D) and RSTP (802.1w). It is important to note however that as Rapid-PVST is a multi-VLAN spanning tree protocol, MS series switches can participate in spanning tree only when a spanning tree instance is running on VLAN 1 of all switches. In addition, VLAN 1 must be allowed on all trunk ports running Rapid-PVST, so that BPDUs are seen by the Meraki switches in the topology. In this configuration, the MS series switches should never be the STP Root Bridge.

[alburger]

The MS390 will support single instance MST which will integrate much better with R-PVST from a compatibility perspective.

[Nolan H.]

Thanks pickle Riiiiiiiiiiick!

[Philip D'Ath]

>The MS390 will support single instance MST which will integrate much better with R-PVST from a compatibility perspective.

I'll challenge you on that @alburger . How will single instance MST provide better compatability than the existing single instance RSTP when talking to a Cisco Enterprise per-vlan R-PVST?

[alburger]

The overall system level function of the MS390 supports decoding of R-PVST and with the implementation, MST single instance is backwards compatible with R-PVST functionality. This will inevitably reduce the number of configuration issues due to trunk configurations etc that is seen in classic MS to R-PVST deployments.

[Philip D'Ath]

The biggest problem I tend to run into is with this topology:

[R-PVSTP Switch] <-> [Meraki Switch] <--> [R-PVSTP Switch]

What happens is the Meraki switch only sees the untagged spanning tree packets. However the two R-PVSTP switches see each other as directly connected on the other tagged VLANs, as their STP packets are effectively tunneled via a dot1g tagged packet. Consequently they form a different and conflicting root of the spanning tree.

I don't see how this will make any difference.

[alburger]

I meant that there is better compatibility between platforms, not that we now allow for design issues. The proper design when an MS is intended to be the root bridge is MST on catalyst to allow for proper interop. The issue you brought up is still an issue as it is an improper spanning-tree design.

[Philip D'Ath]

I've run into this one a few times when we put in a new Cisco Meraki core and end up with some old Cisco enterprise switches during the transition (or potentially undiscovered).

ps. We typically convert any existing Cisco Enterprise switches to using MST before we start deployment these days to stop problems happening.

[alburger]

Totally, it is an unfortunate scenario for sure. I honestly wish that from an IOS perspective that STP was MST by default due to greater initial compatibility. At Meraki we have tried to make sure we document where we can, as R-PVST can bring down a network unknowingly.

[Bossnine]

This is something I have recently discovered, I have a large network location and (unknowingly) realized I have a lone old Cisco switch potentially causing issues. Reading all this I assume i need to change it to MST pretty quickly. It has been running for a few months now but only recently has it come to my attention.

[Philip D'Ath]

@Bossnine a single switch on its own should not cause a problem, but yes, I would change it to using mst.

[whistleblower14]

does Vlan1 need to be untagged (= native) on the trunk links?

It is important to note however that as Rapid-PVST is a multi-VLAN spanning tree protocol, MS series switches can participate in spanning tree only when a spanning tree instance is running on VLAN 1 of all switches. In addition, VLAN 1 must be allowed on all trunk ports running Rapid-PVST, so that BPDUs are seen by the Meraki switches in the topology.

how will the meraki switches behave when there are different native vlans on trunk links?

[Philip D'Ath]

I'm with @Nolan Herring . Cisco Meraki traditionally have only adopted open standard protocols. So I can't see any "per VLAN" spanning tree protocols being implemented.

[joey.debra]

Yeah, why don't you guys support MST fully. Why only single instance?
It does not introduce much complexity if you would allow multiple instances.

I agree it's a step up to finally support MST so you only have a single set of BPDU's floating around the network as long as the Catalyst switches are also running MST. But in a design where the core switches are not stacked (physical or virtual) you still end up with a blocked link...