Integrating MX with Catalyst Switches in stackwise-virtual mode

[rsage_voda]

Anyone got any experience of mixing Meraki MX with catalyst switches in stackwise-virtual mode. Test Client working fine with access to the internet. When simulate a network failure by switching of the active switch the client loses connectivity to the internet and a continuous ping show an outage of circa 30 seconds. As a test re-established the network connectivity and just unplugged the connection from active C9407 to the Active MX P25 and still seeing loss of connectivity of up to 4 seconds. 

[alemabrahao]

Meraki MX does NOT support LACP for WAN or LAN ports. That means on the Catalyst side you must not use channel-group on the MX-facing ports.
If the Catalyst uplinks are in a port-channel, a failover will break traffic until the LACP state machine times out.

[rsage_voda]

Thank you for the response. The uplinks are not in a port-channel.

[ww]

What would be the expected failover time?

Where are the ping packets lost?

How long did stp on port 2/1/0/5 take to get to forwarding state?

[Brash]

Yep. Sounds to me like STP convergence time. Logs on the switch should be able to confirm that.

[rsage_voda]

This is what I am trying to determine. My research indicates that Meraki whilst supporting LACP only works in slow mode. So in theory it could take the Access switch 90 seconds to detect that its active core switch has failed and move traffic to the standby core switch but I would expect this to be quicker as the active core reboots on failover.

My understanding of SVL was that the active and standby are synchronized at the control plane level so I would not expect delay there.

I have subsequently found out that the MX can take 4 seconds to determine that the primary LAN connection has failed before it starts routing traffic down the secondary LAN connection to the standby core switch. Just pulling the primary LAN connection to the active MX will trigger VRRP transitions on the MX.

AI CHAT has also thrown 4 cisco bug ID's associated with SVL in 17.12.6 which when I put into the Cisco bug search tool reports I am not authorized to view. As the ID's didn't come back not found I have to assume that they are real. I am trying to find out what they are whether I need to abandon the 17.12.x train for 17.15.x

I wasn't around when the original network was built but speaking with the engineers who were and have conducted failover testing and upgrades the have no recollection of any impact. I am going to test that next week. 

[PhilipDAth]

I don't tend to dual-connect MXs.  I have had more HA system outages caused by spanning tree behaviour than by single-port or cable failures.