Downtime hits harder than most IT teams would like to admit. A short outage can interrupt payment systems, break VPN sessions, stall cloud apps, and leave remote sites disconnected from critical services. That is why high availability remains one of the most important design choices in a branch or campus edge deployment. A properly built MX warm spare pair reduces the chance that a single hardware issue turns into a major business interruption.
For organizations that rely on Cisco Meraki security appliances, a warm spare deployment creates a cleaner path for network downtime prevention. When the primary appliance fails, the spare can take over automatically instead of waiting for manual intervention. This design is useful across several Meraki MX models, from smaller branch appliances such as the Meraki MX67 to larger platforms such as the Meraki MX85.
An MX warm spare pair removes a major single point of failure at the network edge. If the primary appliance goes offline because of hardware failure or uplink failure, failover can happen automatically. That lowers disruption for users and reduces the pressure on IT staff during an incident. In many environments, that difference alone justifies the extra hardware.
This design also improves maintenance planning. High availability supports smoother firmware upgrades because the appliances can shift roles during the upgrade process to keep disruption low. That makes HA useful for more than emergencies. It also improves routine operations and gives teams more flexibility when planning lifecycle work.
A Meraki MX HA deployment uses VRRP between two appliances. One appliance is marked as the primary, and the other is the spare. Those are fixed roles. The traffic-handling role is different. The MX that is actively passing traffic is the active unit, while the other remains passive until failover occurs.
The failover decision relies on heartbeat traffic. The primary sends VRRP heartbeats across the LAN side on all configured VLANs. As long as the spare sees those heartbeats, it stays passive. If heartbeats stop for roughly three seconds, the spare assumes the primary is unavailable and takes over. That behavior makes LAN design extremely important, because the spare needs a reliable path to hear those VRRP advertisements.
DHCP state matters too. The DHCP lease table is synchronized between the primary and spare over UDP port 3483. That prevents duplicate-addressing problems after failover and helps clients continue operating more smoothly during the transition.
This is the first rule of Meraki HA: the spare must match the primary model. A warm spare pair cannot mix different models. An MX85 must pair with another Meraki MX85. An MX67 must pair with another Meraki MX67. The same restriction applies to territorial variants, so even near-identical units with different regional designations should not be paired together.
That matters when teams compare Meraki MX models during procurement. A branch office may be well served by an MX67 pair, while a site with heavier throughput and more users may need an MX85 pair. Capacity planning should happen before the HA design is finalized, because the spare is not a place to downsize. It must be able to assume the full production role immediately.
Meraki MX warm spare can be deployed in routed mode or in one-armed VPN concentrator mode. Routed mode is the common choice when the appliance serves as the security gateway for a branch or office and handles internet edge functions directly. VPN concentrator mode is used when the MX acts as a high-availability Auto VPN head-end.
For routed environments, the MX pair handles internet connectivity and security services, and the LAN side uses normal appliance IP addresses for configured VLANs. In concentrator mode, the design centers on a shared virtual IP used for non-management communication, while both appliances still keep their own management reachability.
Most businesses planning branch resilience will use routed mode. That is the more relevant model for firewall redundancy, local internet breakout, and branch security. It is also the mode where topology choices have the biggest impact on failover quality and the risk of a dual active problem.
The most reliable routed HA design connects both MX appliances through downstream switching so VRRP heartbeats can pass cleanly across the LAN. A fully redundant design with two switches or a downstream switch stack removes a single point of failure and gives the pair a more stable heartbeat path. The recommended diagrams in the MX HA reference show this clearly: both appliances connect into redundant downstream switching, and both WAN paths are distributed for resilience. The diagram on page 9 shows a fully redundant design with two Layer 2 switches, while page 10 shows a switch stack version with similar failover logic.
There are a few key rules here. The MX appliances should be able to communicate on all configured VLANs. There should be no more than one additional hop between them. Spanning Tree should be enabled on the downstream switching because the HA design introduces a loop by design. If that LAN-side heartbeat path is unstable, failover behavior becomes unpredictable.
This is also where teams often create the dual active problem. Dual active happens when both appliances are online and cloud-connected, but the spare no longer sees VRRP heartbeats from the primary. Both units then think they should be active. That can disrupt DHCP, routing, VPN behavior, and general traffic handling. A clean switching path between the appliances is one of the best ways to prevent that condition.
The sequence matters. The secondary appliance should be added and configured in the Dashboard before it is physically connected to the live network. This reduces the chance of confusion during first boot and helps the spare fetch the correct HA settings as soon as it comes online.
The configuration workflow is straightforward. In Dashboard, go to Security & SD-WAN > Monitor > Appliance status, then select Configure warm spare. Enable the feature, enter the serial number of the secondary MX, and choose the uplink IP method. If static WAN settings are needed on the spare, set those on the local status page before powering the unit off for installation. Then cable the WAN and LAN paths according to the planned HA topology and power the spare on.
There are a few operational limits to keep in mind. Adding or replacing a spare can cause a brief connectivity interruption during HA initialization. Warm spare deployments also remove support for VLAN objects in Layer 3 rules, and MX HA pairs cannot exceed 255 VLANs. These details matter when working in larger branch environments or redesigning an existing production network.
This is one of the most important HA design choices. If the pair uses MX uplink IPs, each appliance sends internet traffic with its own WAN IP. That avoids the need for extra public IPs, though failover becomes more disruptive because active sessions see a source IP change and often need to reconnect.
If the pair uses virtual uplink IPs, both appliances share a VIP on each uplink. This requires an additional public IP per uplink, though it creates a more seamless failover because the outbound IP remains the same during the role change. For services with long-lived sessions, published NAT rules, or sensitive client workflows, virtual uplink IPs are often worth the added planning. The VIP must live in the same subnet as the physical uplink IPs and must be unique.
There is one planning detail many teams miss. If port forwarding or NAT rules are used, those services should point to the HA pair’s virtual IP rather than an individual appliance WAN IP. Also, changing a WAN connection to use virtual IPs can cause a brief outage on both internet uplinks, so it is best done during a planned maintenance window.
A failover test should imitate a real loss of service. The swap button in the Dashboard is not the right method for testing HA behavior. It changes primary and spare roles, but it is not intended as a failover simulation. A true test requires disconnecting the uplink to the primary MX, so the spare has to react to the loss.
That test should happen after the full topology is in place and after both WAN and LAN paths have been checked. Verify the Dashboard state before and after the test. Confirm the active role changes as expected. Confirm that users can still reach cloud applications, VPN resources, and any inbound services that depend on NAT or port forwarding.
If the pair uses virtual uplink IPs, watch for clean session persistence. If it uses physical uplink IPs, plan for more visible disruption and client reconnect behavior. Both methods work. They simply serve different operational goals.
The most common mistakes are easy to avoid with better planning:
There are also model-specific edge cases. Cellular failover in HA is limited to MX67C and MX68CW models with embedded cellular modules. A standard Meraki MX67 warm spare design still works well for wired WAN redundancy, though embedded cellular HA behavior applies only to the cellular-capable variants.
A high-availability MX pair is one of the most effective ways to reduce edge downtime. It gives the network a second path when hardware fails, lowers manual recovery effort, and supports smoother maintenance over the life of the deployment. For many businesses, that makes HA a baseline design choice instead of an optional upgrade.If you are comparing Meraki MX models for a branch refresh, sizing an MX85 pair for a larger office, or planning an MX67 deployment for a smaller site, Stratus Information Systems can help you design the topology, choose the right uplink strategy, and deploy the HA pair cleanly from day one. That kind of planning goes a long way toward real network downtime prevention.
