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.
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...
following this recommended guide should make it work.
or better use mst
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.
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 🙂
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.