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. 

[NolanHerring]

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.

[WirelesslyWired]

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

[NolanHerring]

Thanks pickle Riiiiiiiiiiick!

[PhilipDAth]

>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 @WirelesslyWired .  How will single instance MST provide better compatability than the existing single instance RSTP when talking to a Cisco Enterprise per-vlan R-PVST?

[WirelesslyWired]

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. 

[PhilipDAth]

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.

[WirelesslyWired]

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. 

[PhilipDAth]

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.

[WirelesslyWired]

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.

[PhilipDAth]

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

[whistleblower]

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?

[PhilipDAth]

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

[GIdenJoe]

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...

[PhilipDAth]

>Yeah, why don't you guys support MST fully.  Why only single instance?

Because that is the standard.

[GIdenJoe]

Come on Philip you can do better than that.

"The standard" of MST IS the use of multiple instances.
It's the industry standard approach to getting some load balancing on your uplinks as an answer to Cisco's PVST+/RPVST.

MSTP uses RSTP as convergence method so no changes there but there is a need to have at least two spanning-tree instances.  And then Meraki just uses a half baked solution to get rid of PVST compat issues instead of going the extra mile and supporting "The standard" fully.

[theguywhoroutes]

Spoiler

And then Meraki just uses a half baked solution

Welcome to the World of Meraki...

I think Meraki isn't interested in implementing more than the common instance with MST because either:

1) Their products are designed to fit the needs of people who don't want to understand or learn about how MST/STP works.

2) It's a business strategy to try to make people think: "Oh, let's just get rid of our old cisco switches and buy a full Meraki solution" (providing they are aiming this strategy to companies that can just go ahead and spend a couple of grand on some new kit and get rid of the old traditional cisco kit)

[GIdenJoe]

I like your spoiler 😄

[PhilipDAth]

Meraki has not implemented MST at all.  It has implemented RSTP.

You use MST on Cisco Enterprise switches in a mixed Meraki environment because MST is compatible.

[redsector]

PVST was nice when the trunk connections weren´t strong enough for one line and then to be shared on more lines with PVST. But nowadays fibre cables running with 10G or aggregated more faster I don´t see any reasons to have PVST. In fact: It´s more difficult to find an network error with PVST/PVST+.