MX250 Warm Spare and Virtual IPs

[DunJer622]

Greetings,

I recently implemented an MX250 as my core firewall at my HQ.  As it has been doing well for a month, the plan was then to add a warm spare this month for redundancy.  However, the documentation seems to do a poor job of explaining Virtual IP configuration.  I have 2 circuits that I am currently using in my primary MX and the 2 WAN ports are each configured with a public static IP.  I would expect my spare to be configured with the same IPs.  However, the documentation seems to suggest that I would need 3 assignable public IPs per circuit?  Is that correct?  I'm really not understanding the design.  It is definitely WAY different than the HA setup for my previous SonicWALL hardware, as it simply used a crossover cable and a unique private IP for each firewall.

Any assistance with this matter would be greatly appreciated.

Thank you,

Jeremy 

[BrechtSchamp]

Check this out. Live config of Warm Spare ;).

https://youtu.be/1eG-Gye-JEo?t=423

[DunJer622]

Good video.

That said, I'm still a bit unclear about the public IP needs.  In the documentation, it states that the "Use MX uplink IPs" option does not require additional public IPs for the Internet-facing MXes, but a few sentences further it state, "regardless of which option is selected, both MX devices will need their own uplink IP addresses for Dashboard connectivity".  So, this seems to suggest that I need 2 IP addresses per circuit with this option and 3 public IPs with the "Virtual uplink IPs" option.  Am I understanding that correctly?

Thanks,

Jeremy

[BrechtSchamp]

Exactly :). With the advantage of the third (set of) virtual IP(s) being that the failover is less disruptive.

[PhilipDAth]

This is actually a complicated long discussion.

In a perfect world each MX WAN1 would be connected to the same upstream circuit, ditto with WAN2.  So each MX would have 2 IP addresses on each uplink.  Additional their would be a third VIP (or cluster address if you prefer) on each circuit, giving a total of three IP addresses per uplink.

When you have a virtual IP configured all outbound traffic goes out NATed from that IP address.  Also all VPNs are built from that address.  So when you have a failover it is quick.

If you don't have a virtual IP then the traffic goes out using the IP address of the current active MX.  Ditto for VPNs.  If you have a failover VPNs have to be re-established using the IP address of the standby MX.  Ditto for web browsing traffic.

Overall in most cases - this is not a big deal.  The VPNs usually rebuild quickly, and if a user clicks refresh on their web browser (if it failed right in the middle of a session) everything continues on.

I frequently do HA deployments without using a VIP address.

Now the more complicated case.  The MX's don't even need to be plugged into the same uplinks.  You could plug WAN1 of MX1 into uplink1 and WAN1 of MX2 into uplink2.  You might do this if you can only get PPPoE circuits, or some other kind of circuit where you strictly can not get a /29 of address space or more.

What happens is uplink2 can only be used if uplink1 has failed or the primary MX has failed.

You obviously can't use virtual IP in this case, because the WAN1 interface of each MX is not connected to the same subnet.

The failover cases are the same as when not using a VIP as above.  Each MX simply uses the address assigned to its WAN interface when it is active.

So you actually have a lot of deployment scenarios that can be handled.

[DunJer622]

The impact to my MX250 environment may be minimal, as I use a separate MX64 to manage all VPNs and I use 1:1 NAT and no port forwarding, so a different IP (upon failover) isn't horrible.  For me, its more of a matter that all 13 of my static IPs on each circuit are being utilized.  So, I have to look to see what I can do to recoup one.  I'd prefer to do the virtual IP approach, but recouping 2 is not going to happen.  So, I'll go with the MX uplink option for now, and then likely change to the virtual uplink option when we change our primary ISP later this year. 

Thanks for the good information, guys.