- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Rapid PVST+ support
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The MS390 will support single instance MST which will integrate much better with R-PVST from a compatibility perspective.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
@Bossnine a single switch on its own should not cause a problem, but yes, I would change it to using mst.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>Yeah, why don't you guys support MST fully. Why only single instance?
Because that is the standard.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I like your spoiler 😄
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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+.