Meraki MS switches and Catalyst inter-operability issues with Spanning-tree

[Techgirl321]

This is more of a warning than a question.  I have just completed two large Meraki MS deployments.  In one we had to integrate Merakis on a legacy Cisco Catalyst infrastructure where only some Catalyst switches were being replaced.  Many were remaining.  

Issues:

Our native VLAN was configured for VLAN ID 5 on both sides of the trunk. MS350 on one side, Catalyst 3750 and 3850s on the other. 

Cisco Catalyst switch reported a VLAN ID mismatch for 3 of 8 allowed VLANs 

This caused the trunk to be blocked for those VLANs on that single trunk (meaning only one trunk from that switch existed to the network and it was blocking for those vlans)

The only fix was turning on "spanning-tree bpdufilter enable"  or turning spanning-tree off.

I am surprised that I have not seen more people complaining about this.

In the other deployment where I had a mostly homogeneous Meraki network, I still had to disable spanning tree on the port to our ISP uplink and make sure our MDF stack was root or we saw all kinds of wonky behavior. 

So my warning is, if you are seeing issues that dont make sense, check Spanning-tree... 

[ww]

following this recommended guide should make it work. 

https://documentation.meraki.com/MS/Port_and_VLAN_Configuration/Recommended_Configuration_for_Trunk_...

or better use mst

https://community.meraki.com/t5/Switching/Mekari-Cisco-MSTP-and-RSTP-Configuration-Questions/m-p/352...

[Techgirl321]

Though I did not try to configure MST on the Cisco Catalyst side, I did ensure that the trunk settings on both sides were identical (as the fist document states).  I knew to do this because on the homogeneous network that we did, I had a trunk that would not come up at all, (or behaved badly, I can't remember which)  because we had it pruned on one side and not on the other.  

I will try MST on the Cisco side and see if that works.

Filtering bpdus makes me nervous...I'd rather make it work.

[hoempf]

MST definitely works but depending on the size of the network it might be easier to just bpdufilter your Meraki network as you did. Just make sure you really filter it everywhere you cross from Meraki to Cisco so PVST+ doesn't build topologies using the Meraki switches as a transport, i.e. native VLAN looking ok but other VLANS have a different root because STP BPDUs are being carried over the Meraki switches to other Catalyst switches. This happens for example if you have a Meraki "core" and several Catalyst "islands" connected to it, which is usually the case in a star topology. MS switches will listen to STP BPDUs on their native VLAN (I think), BPDUs on other VLANs will just be forwarded like other frames (broadcast).

Switching from RSTP to MST is usually disruptive for the whole L2 domain. It can be done without much disruption but needs careful planning.

Trunks that don't come up because you prune on one side only (or use different native VLANs) are usually the result of the switch being smart by using other protocols like CDP to check the config on both sides and see if they match. Although it shouldn't just not come up, but instead log the VLAN mismatch and block traffic on the affected VLANs.

TL;DR: Filtering BPDUs is not the baddest thing you can do. It might be better even if you have no loops or if it's physically difficult to create loops between different switches than to fight interoperability. My 2c is keep it as simple as possible, but no simpler 🙂 

[Techgirl321]

We tried to change to MST but this did not work.  We kept the bpdufilter on.  

You are correct, I think the port only blocked when we had pruning on one side and not on the other.  

[StevenEarl]

We tried MST as well and as soon as one switch was up on MST the other switches would cause it to stop forwarding traffic. We did try shutting down the entire network, bring up a switch at a time configuring MST. We brought up a second switch and were able to convert to MST. We brought up a THIRD switch and before we could configure it, the other two switches went down. It seems the only way to get MST configured on a large network would be to bring up a switch at a time - convert it - shut it down and then move to the next switch.

Not sure we are going to try that as this location has 19 IDFs and if it didn't work...

We have the following on our Cisco 2960x switches

spanning-tree mode rapid-pvst
spanning-tree loopguard default
spanning-tree portfast edge default
spanning-tree portfast edge bpduguard default
no spanning-tree optimize bpdu transmission
spanning-tree extend system-id
spanning-tree backbonefast

What should we set our Meraki Trunks to?

Options are - Disabled - Root guard - BPDU Guard - Loop Guard

I'm asking because I have been in networking for 30 years but never had to really address spanning tree as we have been 100% standard Cisco and the core always won the contest for root
spanning-tree vlan 1-4094 priority 61440

[Bruce]

If the root of your network is a Cisco device running RPVST, and the Meraki devices are at the edge of the spanning-tree then there is a fair chance you'll get it working without having to implement MST, or anything else special - the Cisco switches transmit a standards based BPDU as well as the Cisco proprietary BPDUs. Any issues mainly occur if a Cisco device isn't the spanning-tree root, or if you're expecting to 'hop' across a non-Cisco device, e.g. Cisco <-> Meraki <-> Cisco. 

If your Cisco switches are root then you need to drop your priority on them to closer to 0, e.g. 8192, 4096, or even 0 itself. As default the Meraki devices use a default STP priority of 32768 (which I believe is what Cisco use), so if you have your root set at 61440 then its really unlikely it will actually ever be your root.