The MS390 will support single instance MST which will integrate much better with R-PVST from a compatibility perspective.
>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 @aaburger85 . How will single instance MST provide better compatability than the existing single instance RSTP when talking to a Cisco Enterprise per-vlan R-PVST?
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.
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.
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.
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.
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.
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.
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...
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.