Meraki support was not of much help. Basically they require for a distribution switch to be the root switch which is directly connected to both active and spare MXs. And all other switches must be connected to the distribution (root) switch... as in the Meraki documentation: https://documentation.meraki.com/MX-Z/Deployment_Guides/NAT_Mode_Warm_Spare_(NAT_HA)   I did not get a clear answer from Meraki if my deisgn is to be supported somewhere in the future or not. I guess the only way getting this to work is redesigning current setup. I know I won't be buying a couple of MS425-32 switches to support all the 10Gbps links from other switches 😄     ... View more

@jdsilva, thanks for your input. I did not try pinging other devices that could not reach internet. I only tested pinging default GW and google's DNS servers. But yes, that makes sense. For us it is not easy to change the connections- all optical patches from switches run straight to the firewalls. No way to connect switches with eachother 🙂 I will let you know if I get answer back from Meraki's support. ... View more

I upgraded all switches, firewalls and APs to the latest beta firmwares available with no change in behavior. I did some packet captures and I can see that broadcast/multicast traffic reaches from client to the new active MX firewall successfully (ARP queries are replied by new active MX)... however unicast traffic does not even reach the root switch. The traffic path is the following: ClientPC -> AP -> accessswitch -> MX250-Prim-offline -> RootSwitch -> MX250-Spare-ACTIVE I will wait and see what the support thinks about this. ... View more

Yes, previously I had the MXs directly-connected as Meraki documentation seems to be best practice.   However then I had other problems: when disconnecting any switches primary uplink (port 25) the switch and clients behind it lost connection to internet. What I found weird was that the root switch had one port in STP-blocking state which should not happen on a root switch (all ports should be deisgnated-forwarding, unless a loop exists). Googling around I found out that MXs do not participate in spanning tree, thus the MXs caused a spanning tree loop which causes the root switch to block one of its ports. I see that as bad design and suspected that it could cause problems (although spanning tree was working, loops were blocked). After removing the direct-link between MXs the problem was solved- root switch had both it's ports designated-forwarding and no more problems when removing a switch's primary uplink.   The problem of removing MX250-Primary's WAN1 uplink existed in both cases- directly connected and network-connected design.   Actually I have 5 switches connected to MX firewalls via 10Gbit links (all trunks with same VLANs), so the directly connected link actually achieves nothing (most likely at least one of five switches has both uplinks connected to Primary and Spare MX to transfer VRRP heartbeats in each VLAN). The direclty connected link would only be 1Gbit which would be a bottleneck if a switch's uplink to primary-active MX goes down ( solvable with a 10G twinax, although extra cost).   All switches have manually configured STP bridge priorities (of which none are equal: each switch has unique priority). For some reason the traffic does not flow from nonroot-switch -> MX-Prim (offline) -> Root-switch -> MX-Spare-master.   One more diagram- if I disconnect a switch's primary uplink port9 (root port) then port10 goes from ALT->  Root port and the switch regains connectivity to cloud/internet. This does not explain much.    I am thinking of powering down the entire Meraki network of switches and MXs and then booting them up. Maybe it will resolve some quirks. I did have switches and MXs firmwares recently upgraded but I believe the firmware upgrade process rebooted each device. Thank you all for input. ... View more

All switches use the same gateway 172.16.56.1 which is an SVI on the MX250s. That configuration is working because if I just power off the MX250-Prim-Active and the MX250-Spare takes the Master role then all switches/clients can connect to the internet. ... View more