Hello @Tony-Sydney-AU  Thank you for your detailed explanation and recommendations. Regarding the suggestion to use BGP: On the MX side, we understand that we could proceed with the configuration, however on the AWS side there is currently no dedicated AWS engineer available. The customer is only running a few basic EC2 instances and does not have the resources or expertise to manage Transit Gateway BGP configuration. This is also outside the scope of our current support responsibility, so implementing BGP on AWS would be difficult at this time. Concerning the firmware version: You mentioned that multlink active-active requires firmware 19.2.2 or later. In our dashboard, version 19.2.2 is not selectable, but 19.2.4 (RC) is available. The customer has expressed concerns about running a Release Candidate version in a production environment. Could you please advise whether 19.2.4 RC is considered sufficiently stable compared to a general release, especially for production use? Any guidance on the risk level or real-world stability would be very helpful for us to address the customer’s concerns. Thank you again for your insights and support. Kind regards, Jinsoo Park ... View more

Hi @Tony-Sydney-AU  Thank you for getting back to me and for the detailed explanation.   I’d like to share our current situation for clarity.   We have an active Support Case open with Cisco Meraki, and we are currently troubleshooting a Site-to-Site IPsec VPN setup between a Meraki MX and AWS Transit Gateway using Primary and Secondary IPsec tunnels with health checks enabled.   Current observations:   When health checks are not configured, and only a single IPsec tunnel is active, traffic works as expected.   Traffic selectors are shown correctly (e.g. 10.184.x.x === 10.100.0.0/16, 10.130.0.0/16, 10.192.0.0/16)   No packet loss or instability is observed.   When health checks are enabled on both primary and secondary tunnels, traffic selectors change to 0.0.0.0/0 === 0.0.0.0/0, which we now understand is expected behavior.   However, in this state, we observe intermittent or complete traffic loss, even though:   Both tunnels show green (up) status in the dashboard   AWS routing for 192.0.2.3/32 is correctly configured   The issue is not consistently reproducible:   In some cases, applying the health check to the primary tunnel first, then the secondary, temporarily results in stable traffic   However, after leaving the configuration unchanged overnight, traffic may fail again the next day   Packet captures taken on the IPsec interface confirm that:   Health check probes (HTTP) are sent   Tunnel establishment remains up   Data traffic becomes one-way or drops intermittently when health checks are enabled   At this point, based on your answers, our configuration appears to align with documented and expected behavior, yet the instability persists only when health checks are enabled.   We agree that further investigation via the Support Case and backend logs is the right path forward, and we are continuing to work with Meraki Support to identify why traffic becomes unstable under health check conditions in our environment.   As an update from the active support case: Meraki Support observed that the health check probes (sourced from 192.0.2.3) were reaching the endpoint kix06s10-in-f14.1e100.net over HTTP (google.com), but the probes were receiving HTTP 404 responses. Based on the backend logs, the IPsec tunnels themselves remain up, however the health checks are failing due to the HTTP response, which likely contributes to the intermittent traffic behavior we are seeing.   At this point, we are checking with the customer whether it is possible to deploy a simple HTTP service within AWS that can reliably respond with a valid HTTP 200 status. Once confirmed, we plan to update the health check endpoint to this AWS-hosted domain and re-test the tunnel stability.   For reference, the MX appliances are currently running firmware version MX 19.1.11.   Best regards, Jinsoo Park ... View more

I’m not very good at English, so I’m using AI to help with translation. I think I may have explained things poorly earlier, so I’d like to clarify our setup: There is no LAN connection between MX1 and MX2. MX1 has one LAN link to MS A and one LAN link to MS B. MX2 also has one LAN link to MS A and one LAN link to MS B. MS A and MS B are configured together as a LAG pair. This design is based on the Warm Spare topology recommended in the official Meraki documentation. Since each MX is cross-connected to the two switches, should we remove the link from MX1 to MS B and the link from MX2 to MS A? ... View more

Hi, Single vs dual LAN connections Each MX currently has two LAN connections into the switched infrastructure: MX A has one LAN link to MS130-24 A and one LAN link to MS130-24 B. MX B also has one LAN link to MS130-24 A and one LAN link to MS130-24 B. So the MXs are dual-homed to the access layer. On MS130-24 A I can see that one of the MX ports (port 21) is in an “STP discarding packets from this port” state, which I understand is caused by RSTP trying to prevent a loop. Switch port configuration for the MX uplinks The switch ports that connect to the MXs are configured identically on both MS130-24 A and MS130-24 B: Mode: trunk Native VLAN: 1 Allowed VLANs: same list on both switches No BPDU guard / root guard / other special STP options configured. Inter-switch LAG configuration The LAG between MS130-24 A and MS130-24 B (ports 23–24 on each switch) is configured as a trunk, and is set to pass all VLANs. Both members of the LAG are up and forwarding. Port swap test I have not yet tested swapping the MX uplink ports between the switches, but I can perform this test and report whether the issue follows the switch port or stays with the MX. In addition, I am planning to adjust the STP root so that MS130-24 A is the root bridge and MS130-24 B is the secondary root, then repeat the warm-spare failover tests. Please let me know if you would like any additional information or specific STP/port status screenshots. Thank you. ... View more

We have two MX units and two MS switches. The MS switches are connected using LAG, and STP is running in RSTP mode. Each MX has its own unique physical IP addresses plus one VIP (total of three IPs). Since the LAN ports remained active, I now believe that this prevented proper failover behavior. I will run another test by disconnecting the LAN uplink or powering off the primary MX to validate this. Thank you for your helpful guidance. ... View more

After removing the WAN cables, the spare MX did become the master after about 1–2 minutes. However, even though the master role switched successfully, the network still remained unreachable. I waited an additional 15–20 minutes, but traffic never passed through the new master. This makes me suspect that the active LAN link on the primary MX prevented a proper failover, even though the role changed in the dashboard. I will test again soon with the LAN link removed or by powering off the primary MX. Thank you for the explanation ... View more

I made a mistake in my initial description — I did not disable the WAN ports from the Web UI. I physically disconnected both WAN1 and WAN2 cables on the primary MX. Since the LAN interface was still active, could that be the reason the failover did not occur? It seems the spare continued receiving VRRP heartbeats over the LAN, so it did not take over. I will try again by also disconnecting the LAN interface, or by powering off the primary MX entirely. Thank you for your clarification. ... View more