A brief family history
Once upon a time Cisco and Meraki were two separate entities with different ways of doing things. In those days you’d expect the odd incompatibility – the same as if you were trying to pair a Cisco with any other vendor’s equipment. However, since Cisco purchased Meraki years ago now you’d be forgiven for presuming that they’d put their heads together and ironed out STP incompatibility between the brands for the benefit of customers who are invested in both products.
Unfortunately, the Cisco Meraki MS225 switches at least appear to tail-dropped the memo with regards to “RPVST+” – Cisco’s much deployed per-vlan implementation of the RSTP standard.
Spanning Tree Standards Primer
If like me your background is in Cisco then you may have thought cracking open the CLI and entering spanning-tree mode rapid gets you RSTP. That is not the case. You get a Cisco interpretation of RSTP, officially named RPVST+ or Rapid Per VLAN Spanning Tree Plus. Here’s a high-level reminder of the different spanning tree protocols we’re dealing with:
STP was the original standard to prevent bridging loops. It was developed in the 80’s so converges slowly by modern standards. STP calculates one logical topology to be used for all VLANs.
RSTP is an improvement of the original STP. To give it its full name – Rapid Spanning Tree Protocol, helps indicate its purpose; to make convergence much faster. As with STP every VLAN uses the same logical topology.
This is a Cisco-proprietary implementation of RSTP which improves upon it by maintaining a logical topology for each VLAN. The + at the end indicates that the protocol is backwards compatible with RSTP and STP.
I connected up my brand spanking new Meraki MS225 3-switch stack to the Cisco core switch, trunked the required VLANs across the etherchannel, checked spanning-tree on the core was set to RPVST+ and that it’s bridge ID was low enough to remain the root bridge. Standard stuff.
The Meraki stack doesn’t have many options to configure here, so I did my trunking this side too and set the stack with an extremely high bridge ID and I thought I was off to the races.
During verification, both the core and the Meraki stack claimed to be the big dog. “This bridge is the root” greeted me on each device. Darn, an STP incompatibility issue if ever I saw one. In this scenario it didn’t cause an issue as there wasn’t yet a redundant link for spanning tree to get confused about, but this was not a desirable end state.
So, why did this STP incompatibility happen?
The Meraki switch runs RSTP, which as noted above uses one spanning tree topology for all VLANs. As such, RSTP only needs to send BPDUs on VLAN1 as all other VLANs will use the identical topology.
On the Cisco core switch, we are running RPVST+. This protocol can have a topology per VLAN, so sends BPDUs on all VLANs.
We’ve already mentioned that RPVST+ and RSTP are backwards compatible, so it should work right? Well, kind of. The reason it did not work in this scenario is that I did not have VLAN1 allowed across the trunk. I believed this to be perfectly reasonable as VLAN1 is not used for any purpose in my infrastructure and isn’t the native VLAN.
The kicker is that ‘backwards compatible BPDUs’ are only sent on VLAN1. All other VLANs use RPVST+ BPDUs instead. As VLAN1 was not allowed over the trunks, no superior BPDU was seen by the Meraki stack; and so it too believed it was the root bridge.
To say there is “compatibility” between RPVST+ and RSTP is probably a bit of a strong statement. What is happening here is that both switches agree to fall back to the original STP and use that instead. Unfortunately this comes with all the negatives of STP – such as the 1980’s convergence times.
If you do need to use RPVST+ with RSTP you’ll need to allow VLAN1 across the trunks, even if it’s not used. This will allow the switches to negotiate the correct root bridge by falling back to the original 802.1d STP. Not great, but it’s the best we can do until everyone agrees on a standard, or we do away with the need for spanning tree in our designs altogether.
If you liked this article, you may be interested in my overview of Cisco Express Forwarding – hope you enjoy!