Meraki MX with C9407 Stackwise-virtual

[russell.sage]

I have a large Meraki based network that the customer has outgrown and has decided to replace the Meraki core switches, currently MS425-32 stacks. The decision was made to replace them with C9407 in stackwise-virtual mode. 

I have built a test network for staging and type approval. With a client connected to MS-350 downstream of the 9407's and connected to the internet. If the active switch is switched off, or a redundancy force-switchover is issued the client running a permanent pings to 8.8.8.8 shows an unacceptable level of ping timeouts. Typically 30 seconds. If I just unplug the link between the Active 9407 and active MX I see a single ping lost which looks to be caused by the MX VRRP transitioning. 

My research seems to indicate that seamless failover is unachievable with the Meraki MX due how they architected. 

I can't see a problem with the simple configuration on the C9407. The stackwise-virtual links and DAD links are all up and working. 

There is a MEC port-channel between the 9407 and Access switch with LCAP fast enabled.  

Show redundancy 

XC-YYY-X-WSM001#sh redundancy
Redundant System Information :
------------------------------
Available system uptime = 2 weeks, 5 days, 22 hours, 14 minutes
Switchovers system experienced = 1
Standby failures = 0
Last switchover reason = active unit removed

Hardware Mode = Duplex
Configured Redundancy Mode = sso
Operating Redundancy Mode = sso
Maintenance Mode = Disabled
Communications = Up

Current Processor Information :
-------------------------------
Active Location = Switch 2
Current Software state = ACTIVE
Uptime in current state = 18 hours, 27 minutes
Image Version = Cisco IOS Software [Dublin], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.12.6, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2025 by Cisco Systems, Inc.
Compiled Sun 31-Aug-25 06:06 by mcpre
BOOT = bootflash:packages.conf;
CONFIG_FILE =
Fast Switchover = Enabled
Initial Garp = Enabled

Peer Processor Information :
----------------------------
Standby Location = Switch 1
Current Software state = STANDBY HOT
Uptime in current state = 18 hours, 14 minutes
Image Version = Cisco IOS Software [Dublin], Catalyst L3 Switch Software (CAT9K_IOSXE), Version 17.12.6, RELEASE SOFTWARE (fc1)
Technical Support: http://www.cisco.com/techsupport
Copyright (c) 1986-2025 by Cisco Systems, Inc.
Compiled Sun 31-Aug-25 06:06 by mcpre
BOOT = bootflash:packages.conf;
CONFIG_FILE =

Any suggestions gratefully appreciated.

[balaji.bandi]

the information of the document does not provide, how these configured MX to Cat switch, can you share some configuration.

I believe - STP Transition: If the MX is seeing the 9407s as two different STP entities (or if the SVL merge/split causes a TCN), the port may move through Listening/Learning states (default 30 seconds).

Configure "Spanning-Tree Portfast Edge" Ensure the ports connecting to the Meraki MX are configured as edge ports. This bypasses the 30-second Listen/Learn delay.

I do not remember the settings, it's been quite a long time since deploying MX  - check the warm spare setting, anything you can tweak.

https://documentation.meraki.com/Platform_Management/Dashboard_Administration/Design_and_Configure/Architectures_and_Best_Practices/Cisco_Meraki_Best_Practice_Design/Best_Practice_Design_-_MX_Security_and_SD-WAN/General_MX_Best_Practices

[russell.sage]

The 9407 is set for RSPT. I have set the connection to the Meraki as SPT portfast trunk. My research has indicated that the Meraki doesn't support LACP. Research also indicates that Meraki may take several seconds to move traffic from Port 25 to 26 despite the link going hard down. I also understand the MX doesn't participate in SPT just passes BPDUs through

[paul driver]

Hello
When you perform core migrations you should always accommodate for outages.
Based on your topology, I would just have a aggregate PC just between the primary MX and 9047, this would negate any issue with STP and asymmetric routing.

This will then allow you to stage a migration of all your L2 interconnects first then L3 svis thereafter safely and without very little downtime.