MX HA issue question

[abcdef12345]

Hello Community.

I have a question regarding MX Warm Spare deployment.

Our customer wants to configure an MX Warm Spare network.
However, I understand that adding a new MX device to a live network can cause a few minutes of service impact.

My question is:
Why does a service disruption occur during this process?

From a user’s perspective, an existing MX is already operating, and we are simply adding a secondary MX device for redundancy.
Based on that, I would expect no service interruption.

Am I misunderstanding something, or is this behavior related to the MX Warm Spare synchronization logic?

Best regards

[alemabrahao]

A brief service disruption is expected when converting a standalone MX into a Warm Spare pair, and it is caused by how Meraki MX handles VRRP activation, shared IP assignment, routing roles, ARP re‑learning, and network topology updates, not because the MX should go down, but because the network must transition from a single-router architecture to a redundant VRRP-based architecture.

[abcdef12345]

hello alemabrahao.

thanks to reply

is there related Meraki official docs?

best regards.

[alemabrahao]

https://documentation.meraki.com/SASE_and_SD-WAN/MX/Design_and_Configure/Deployment_Guides/MX_Warm_S...

Take a look at the documentation for more details.

[abcdef12345]

Hello alemabrahao

Thanks for your reply.

I have one more question.

I am testing Warm Spare in my lab network.
When I add a new MX device to the dashboard network, the primary MX LED changes to a rainbow color.
After confirming that the primary MX LED had changed to solid white, I powered on the secondary MX device.

At that point, does the Warm Spare logic start when the secondary MX is added to the dashboard network,
or only after the secondary MX is powered on and connected?

Best regards

[alemabrahao]

Warm Spare logic only becomes active once BOTH MX units are online and connected, not simply when the second MX is added to the Dashboard network.

[abcdef12345]

Thank you for your response.

However, during my current testing, I observed the following behavior.

When I added the spare MX device to the dashboard network, I confirmed that the primary MX LED changed to a rainbow state.
At that time, packet loss was observed from the client side.

After confirming that the primary MX LED had changed to solid white, I powered on the spare MX device.
While the spare MX was coming online in the dashboard, no ping loss was observed from the client, and the primary MX LED remained solid white.

Based on your explanation, I understand that simply adding a spare MX to the dashboard network
should not cause any service impact.
However, in my test, the service impact occurred when the spare MX was added to the dashboard,
while no service impact occurred when the spare MX was powered on and came online.

For reference, the client is connected to the LAN port of the primary MX.

Could you please explain why this behavior occurs?

Best regards

[alemabrahao]

That's not what I meant. Simply adding the MX to the inventory (dashboard) doesn't cause a problem; adding it to the network does, and that's the expected behavior due to what I explained in the first post.

Ideally, you should do this during a maintenance window, as you need to make all the connections so that the MXs can exchange VRRP information.

Meraki documentation explicitly states that Warm Spare requires two online MX units configured for VRRP-based HA to operate. 

Warm Spare logic starts ONLY after the secondary MX is powered on, connects, and establishes VRRP communication with the primary.

[alemabrahao]

Remember that this is the behavior of VRRP, which is an open protocol and can be implemented by any other vendor.

https://www.haproxy.com/glossary/what-is-vrrp-virtual-router-redundancy-protocol

[abcdef12345]

Thanks for reply

In meraki What I want to confirm is exactly at which step the Warm Spare logic is triggered and causes the service impact:
(1) when the spare MX is assigned to the network in the dashboard, or
(2) when the spare MX is powered on and becomes online.

Best regards

[alemabrahao]

When the spare comes online:

it downloads the same configuration as the primary (as required for Warm Spare)
it establishes VRRP heartbeats with the primary
it synchronizes required HA state (DHCP leases, monitoring, etc.)
it transitions into the Spare/Passive role while the primary remains Primary/Active

Only now is the Warm Spare pair fully operational.

Remember that both MXes must be the same version.

The documentation provides all the additional details.

[GIdenJoe]

Also validate some configurations in your network.
If you configured any MX IPv6 stuff, these will be disabled when enabling HA due to lack of support on HA pairs.  Yes still after all these years.

Configuring the warm spare before you add it physically to the network does not seem to cause any downtime in my experience.

Be aware of your WAN situation.  Are you going to use a virtual IP or not?  Using virtual IP is better for failovers since you just pass the virtual IP from the primary to the spare.  However in a single deployment you are using that IP as physical IP on your primary so you would need to move that device to another WAN IP before enabling the virtual IP function and assigning the original IP.