I'm looking to enable some failover on our network. We have two ISP. Currently, the primary is in WAN1 and the secondary is in WAN 2. My understanding is that gives us failover if one of the lines drops. What it does not cover is a hardware failure in the MX84.
My ISP's do not provide two links so I think currently if we have a hardware failure I will have to swap the WAN port on the primary Firewall with the secondary one. It's not automatic but will do.
My plan was to enable Warm spare in the dashboard for the second Meraki with have. I assume I need a link cable between them both to keep the heartbeat. Does it matter which port I use.
Will it then work if it fails over we just swap the WAN port cable over?
You shouldn't connect the Mx's back to back. They will exchange heartbeats of the connected LAN ports.
In terms of the ISP's connections, I'm not sure your plan to keep only one MX connected will even work. Most people in this situation will add a switch (or switch pair) between the ISP links and the MX's.
That way both MX's can access the ISP connection allowing for automatic failover.
use MX uplink IPs: When using this option, the current active MX will use its distinct uplink IP or IPs when sending traffic out to the internet. This option does not require additional public IPs for internet-facing MXs, but also results in more disruptive failover because the source IP of outbound flows will change.
Use virtual uplink IPs: When using this option, both MXs will use a shared virtual IP (VIP) when sending traffic to the internet. This option requires an additional public IP per uplink, but allows for seamless failover because the IP address the network is using to communicate with the internet will be consistent. The VIP for each uplink must be in the same subnet as the IPs of the MXs themselves for that uplink, and the VIP must be different from both MX uplink IPs.
Darren OConnor | firstname.lastname@example.org https://www.linkedin.com/in/darrenoconnor/
I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.