Meraki and Cisco Nexus/Catalyst co-existence

[joebrug]

We're migrating over to a Meraki stack (2 x MX105's, 2 x C9300-M's, 4 x MS225's, APs, etc) from a Nexus (9372) and Catalyst (2960) set up. Trying to do this in a manner so slowly migrate instead of hoping my Meraki configuration is correct and doing a full cut over. In the meantime, we're having a lot of issues with STP. We have one trunk between a Nexus and a 9300. STP doesnt seem to be behaving properly, ie the Nexus thinks its the root bridge, and so does the Meraki side.. sometimes even the MS225's think they're the root bridge.

In our searches, we stumbled across some items that say Cisco/Meraki STP don't play nicely together, at least in their default configurations. Best I can tell, the Nexus/Catalyst side are using Rapid PVST mode, and the Meraki has RSTP enabled.

The documentation is a little Greek, so trying to get a little guidance on the best way to (temporarily) set this up so I'm not battling outages from STP. 

Right now, In "Switch Settings" I have my C9300 stack with a priority of 40960, and my MS225's at 53248. I believe the Nexus side of things are around 

The Nexus VLANs are in the 24000 range for priorities. 

Since we're moving to the Meraki's.. ideally I'd want that side to be the root, but before lowering their priorities, I want to make sure the Nexus/catalyst side of things "talk" happily. 

[Brash]

You're correct that Nexus/Catalyst use RPVST whilst Meraki uses RSTP.

These are technically interoperable. but the Meraki device will send STP updates on VLAN 1 only.

You need to ensure that VLAN 1 is trunked between the two switches.

Additionally, (from memory) the native VLAN on each side of the trunk has to match, otherwise you can have the VLAN 1 tag stripped off the packet and it natively tagged as a different VLAN.

Also, as per the documentation, it's not suggested to have the Meraki switch be the root in this scenario.

https://documentation.meraki.com/MS/Deployment_Guides/Advanced_MS_Setup_Guide#Rapid-PVST

[joebrug]

hi Brash, thanks for the response. 

I'll double check about VLAN 1, so even if VLAN 1 isnt used/configured on the Nexus/Catalyst side, it needs to exist/be enabled? 

If I'm reading your link properly, it is saying specifically the MS shouldn't be root bridge, right? I have no intention of an MS being root.. but the 9300's ideally should be.. if thats OK. 

[Brash]

Yes, that's correct.

The Meraki gear, including catalyst in Meraki mode uses VLAN 1 for STP BPDU's. So, if the nexus isn't using VLAN 1 or if VLAN 1 isn't allowed on the trunk, the switches won't receive the BPDU's.

My understanding of the doc is essentially that the Meraki switch (or Catalyst switch in Meraki mode) shouldn't be the root bridge when connected to a switch running RPVST. For your scenario it sounds like the Nexus should be the root bridge until you remove it from the network.

For clarification, are your C9300's running in Meraki managed or Meraki monitored mode?
If Meraki monitored, they'll be running RPVST out of the box and thus are fine to be the STP root bridge. If Meraki managed mode, they'll act more like an MS and therefore, the Nexus should be the STP root bridge.

[joebrug]

Okay. You're confident that Cisco RPVST and Meraki RSTP can talk as long as VLAN 1 is available? I only ask because something I read said to change from RPVST to MST. It was probably one of the many footnotes in Meraki docs that I cant find right now lol. 

Looks like I actually don't have VLAN 1 going

2960-X:

2960X-Upstairs#sh run int vlan 1
Building configuration...

Current configuration : 48 bytes
!
interface Vlan1
 no ip address
 shutdown
end

One of my Nexus's:

NX9K-1# sh run int vlan 1 all

!Command: show running-config interface Vlan1 all
!Running configuration last done at: Fri Feb 21 15:05:14 2025
!Time: Mon Feb 24 19:49:15 2025

version 7.0(3)I7(10) Bios:version 07.66

interface Vlan1
  no description
  shutdown
  mtu 1500
  bandwidth 1000000
  autostate
  delay 1
  medium broadcast
  snmp trap link-status
  carrier-delay msec 100
  load-interval counter 1 60
  load-interval counter 2 300
  load-interval counter 3 60
  mac-address 00fe.c8e6.b12f
  no management

and looks like I need to allow it over the trunk to the Meraki

interface Ethernet1/10
  description Uplink to Meraki 9300
  switchport mode trunk
  switchport trunk allowed vlan 20,50,172,1000,1010,1020
  mtu 9216

 and just for completion sakes:

NX9K-1# sh span sum
Switch is in rapid-pvst mode
Root bridge for: VLAN0001, VLAN0010, VLAN0020, VLAN0050, VLAN0099-VLAN0101
  VLAN0172, VLAN1000, VLAN1010, VLAN1020, VLAN1030
L2 Gateway STP                           is disabled
Port Type Default                        is disable
Edge Port [PortFast] BPDU Guard Default  is disabled
Edge Port [PortFast] BPDU Filter Default is disabled
Bridge Assurance                         is enabled
Loopguard Default                        is disabled
Pathcost method used                     is short
vPC peer-switch                          is enabled (operational)
STP-Lite                                 is disabled

Name                   Blocking Listening Learning Forwarding STP Active
---------------------- -------- --------- -------- ---------- ----------
VLAN0001                     0         0        0          3          3
VLAN0010                     0         0        0          3          3
VLAN0020                     0         0        0          4          4
VLAN0050                     0         0        0          4          4
VLAN0099                     0         0        0          3          3
VLAN0100                     0         0        0          3          3
VLAN0101                     0         0        0          3          3
VLAN0172                     0         0        0          5          5
VLAN1000                     0         0        0          4          4
VLAN1010                     0         0        0          4          4
VLAN1020                     0         0        0          4          4
VLAN1030                     0         0        0          3          3
---------------------- -------- --------- -------- ---------- ----------
12 vlans                     0         0        0         43         43

[Brash]

---

@joebrug wrote:

Okay. You're confident that Cisco RPVST and Meraki RSTP can talk as long as VLAN 1 is available? I only ask because something I read said to change from RPVST to MST. It was probably one of the many footnotes in Meraki docs that I cant find right now lol. 

Yes, one of my networks has C9500's running RPVST with Meraki MS switches connected off them.

They interoperate fine exchanging BPDU's on VLAN 1.

The doc suggests changing to MST for a fuller interoperability (for example, having an RPVST device on either side of a Meraki MS will prevent them from exchanging BPDU's). This is important if you're using a range of different switch vendors across your network, but less important if you simply have a couple of Cisco switches sitting on the side.

---

@joebrug wrote:

and looks like I need to allow it over the trunk to the Meraki

interface Ethernet1/10
  description Uplink to Meraki 9300
  switchport mode trunk
  switchport trunk allowed vlan 20,50,172,1000,1010,1020
  mtu 9216

It appears so yes. If this is a prod network, keep in mind there will be some reconvergence when you allow VLAN 1 as currently both switches would have different root bridges.

[joebrug]

Yes, production, so need to plan this properly. Already made too many angry users so far 🙂 

I'm curious.. so on my trunk port between the Nexus and Meraki.. since I dont have VLAN 1 allowed.. why do things seem to be behaving poorly at times? I would assume that since VLAN 1 isnt allowed over the Trunk, that Nexus has its STP config, and Meraki has its STP config. Not the case? and I suppose I could look at some packet captures to see what is really going on? 

For example. I have a 2960-X (switch 2) that is connected to another 2960-X (Switch 1) via port channel, who then has a port channel to the Nexus stack. That far switch (switch 2) is occasionally going offline and comes back shortly after. My assumption is STP but theres no logs or anything indicating that. 

[Brash]

You may not necessarily see problems from the misconfiguration.

Based on what you've described and the fact that VLAN 1 isn't trunked, it sounds like your network is essentially split into two separate STP domains, with the border between the Nexus and the Meraki (due to BPDU's not going across the link).

A packet capture would definitely confirm this behaviour.

Similarly, you could look at STP counters on the nexus. 

Something along the lines of the below will show sent and received BPDU counters on the interface:

show spanning-tree interface <interface number> detail

Note: The above command is an IOS-XE command and thus might differ slightly on NXOS

[joebrug]

I might try this tonight.. I'm curious though, is it either I allow VLAN 1 everywhere OR change to MST? or if I change to MST, do I still need to enable VLAN 1?

Also, if I didnt explain earlier, I have two Nexus's at the core using vPC. Here is the results of the command you mentioned for the port that is connected from NX1 > C9300-M-1 

NX9K-1# show spanning-tree interface e1/10 detail

 Port 10 (Ethernet1/10) of VLAN0010 is designated forwarding
   Port path cost 2, Port priority 128, Port Identifier 128.10
   Designated root has priority 24586, address 0023.04ee.be0a
   Designated bridge has priority 24586, address 00fe.c8e6.b12f
   Designated port id is 128.10, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 179028, received 0

 Port 10 (Ethernet1/10) of VLAN0020 is designated forwarding
   Port path cost 2, Port priority 128, Port Identifier 128.10
   Designated root has priority 24596, address 0023.04ee.be0a
   Designated bridge has priority 24596, address 00fe.c8e6.b12f
   Designated port id is 128.10, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 708972, received 0

 Port 10 (Ethernet1/10) of VLAN0050 is designated forwarding
   Port path cost 2, Port priority 128, Port Identifier 128.10
   Designated root has priority 32818, address 0023.04ee.be0a
   Designated bridge has priority 32818, address 00fe.c8e6.b12f
   Designated port id is 128.10, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 708968, received 0

 Port 10 (Ethernet1/10) of VLAN0172 is designated forwarding
   Port path cost 2, Port priority 128, Port Identifier 128.10
   Designated root has priority 24748, address 0023.04ee.be0a
   Designated bridge has priority 24748, address 00fe.c8e6.b12f
   Designated port id is 128.10, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 2
   Link type is point-to-point by default
   BPDU: sent 708970, received 2

 Port 10 (Ethernet1/10) of VLAN1000 is designated forwarding
   Port path cost 2, Port priority 128, Port Identifier 128.10
   Designated root has priority 25576, address 0023.04ee.be0a
   Designated bridge has priority 25576, address 00fe.c8e6.b12f
   Designated port id is 128.10, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 708972, received 1

 Port 10 (Ethernet1/10) of VLAN1010 is designated forwarding
   Port path cost 2, Port priority 128, Port Identifier 128.10
   Designated root has priority 25586, address 0023.04ee.be0a
   Designated bridge has priority 25586, address 00fe.c8e6.b12f
   Designated port id is 128.10, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 708972, received 1

 Port 10 (Ethernet1/10) of VLAN1020 is designated forwarding
   Port path cost 2, Port priority 128, Port Identifier 128.10
   Designated root has priority 25596, address 0023.04ee.be0a
   Designated bridge has priority 25596, address 00fe.c8e6.b12f
   Designated port id is 128.10, designated path cost 0
   Timers: message age 0, forward delay 0, hold 0
   Number of transitions to forwarding state: 1
   Link type is point-to-point by default
   BPDU: sent 708972, received 1

[joebrug]

@Brash @cmr 

Hello! An update. I allowed VLAN 1 across the trunk to/from Meraki 9300's and have posted the result below. No downtime happened at all. 7e80 is one of the 9300's in Meraki stack, so thats good. But I'm a bit concerned that the other vlans are still showing Nexus 1 as the root bridge. I'm not sure how to change that to be the Meraki side, without changing to MST ?

NX9K-1# sh span root

                                        Root  Hello Max Fwd
Vlan                   Root ID          Cost  Time  Age Dly  Root Port
---------------- -------------------- ------- ----- --- ---  ----------------
VLAN0001          4096 9c09.8b67.7e80       2    2   20  15      Ethernet1/10
VLAN0010         24586 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN0020         24596 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN0050         32818 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN0099         24675 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN0100         24676 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN0101         24677 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN0172         24748 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN1000         25576 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN1010         25586 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN1020         25596 0023.04ee.be0a       0    2   20  15  This bridge is root
VLAN1030         25606 0023.04ee.be0a       0    2   20  15  This bridge is root

[joebrug]

---

@Brash wrote:

For clarification, are your C9300's running in Meraki managed or Meraki monitored mode?
If Meraki monitored, they'll be running RPVST out of the box and thus are fine to be the STP root bridge. If Meraki managed mode, they'll act more like an MS and therefore, the Nexus should be the STP root bridge.

---

I actually have no idea. They were ordered as C9300-M, if I recall, if it matters. I'm happy to look if the setting exists somewhere, I haven't come across that one. 

[Brash]

If they were ordered as C9300-M, they will be in Meraki managed mode out of the box.

[RWelch]

👏 👏 👏 W2G @Brash 

[cmr]

Personally I would never run RPVST and Meraki together in production.  I have done and it was a nightmare if a traditional Cisco switch was either side of the Meraki switches.  As @Brash said, it can work if Meraki is only the edge with Cisco at the core, but personally I'd just change the traditional Cisco to MST and rest easy.

[joebrug]

hi crm,

thanks for the tips. I'd assume switching to MST comes with its own issues potentially? and is it relatively easy? does switching to MST negate the need to enable/allow VLAN 1 everywhere? 

I'm curious since VLAN 1 is currently not enabled/allowed on the Nexus/Catalyst side.. where the conflict lies? Or are they "talking" across the trunk via other vlans, but just cant sort themselves out? 

Looking at the event log from yesterday, theres MAC Address Flapping going on.

Anyway, running both systems together is very temporary, if that makes a difference in suggestions. 

[cmr]

The main points of PVST were to spread the overhead between devices for performance and availability.  These days in most networks the equipment is powerful enough to manage the spanning tree for all VLANs, so you should be fine to change it. 

Remember to change the core first and the other non Meraki switches as quickly as possible.  You will get a ~30s outage with at least the first change.

[joebrug]

Thanks. If I'm plugged into an MS225 stack..

MS225 > 9300M > trunk to Nexus > Nexus > catalyst 1 > catalyst 2

Wouldn't I want to change Catalyst 2 first? Guess I'm wondering at what point I might lose access to the switch. 

And to get it configured/working, is it much more than this on each Cisco switch?

1.    enable
2.    configure terminal
3.    spanning-tree mst configuration
4.    instance 1 vlan 1-2000

[cmr]

I'd change Nexus first, after the 30s the connection will recover.  If you change Catalyst 2 first it can take down at least that part of the network.

[cmr]

Also the C9300-M will only support 1000 VLANs.

[joebrug]

Interesting, I would've thought that changing STP mode will effectively kill communications with a switch that is still running Rapid PVST down the line. 

I dont think this question was answered.. if you change to MST on nexus/catalyst.. do you still need to have VLAN 1 set up/allowed or does MST negate the need?

[RWelch · Accepted solution]

If anyone's interested, you can view this VLAN1 scenario/configuration explained on the Learning Hub under Optimizing Meraki-Managed Uplink Connections.  The portion that will address your question will be on Slide # 14 of 17 (be sure to scroll down on slide # 14 to see the video toward the bottom of the page). 

[cmr]

Good link there @RWelch , that explains it well 😎

[JeroenVercoulen]

See: https://documentation.meraki.com/MS/Meraki_Campus_LAN%3B_Planning%2C_Design_Guidelines_and_Best_Prac...

This explains the different setups. Please keep in mind that introducing RPVST to an MSTP Meraki root can cause issues with blocking links.