Help...MX250 HA Pair and Failover WAN Connection

Getting noticed

Help...MX250 HA Pair and Failover WAN Connection


I currently have two MX250s, connected HA. We have a Gig Comcast fiber connection with 6 IPs, however, Comcast failed to mention that they will charge us double if they enable another port on their device for us to use as a secondary connection.


The idea was to connect the Secondary MX WAN1 to a secondary port on the Comcast modem for the failover connection, buuut, since we do not want to be charged for 2 separate circuits (although it’s just one circuit), we cannot use those additional IPs as intended.


FYI: We have the Primary MX connected via VPN to the Azure cloud.


I know we can use a switch between the Firewall and Comcast modem; however, I really do not want to install a single point of failure to our WAN connection - which negates the entire reason for the failover links (and redundant firewalls) to begin with. To install one switch, we would need yet another switch, then that switch would need a secondary connection for redundancy, which takes us back to the drawing board.


So, if the Primary MX goes down, we will have to physically move the connection from the Primary MX WAN1 port to the Secondary MX WAN1 Port... This seems far easier than connecting more devices.

I really would like for this to all be automated, but just looks like it may be better to do this manually.


HOWEVER, I do not know if configuring WAN1 on the Secondary MX with the exact same IP as the Primary MX will be an issue. Keep in mind that we have a VPN connection to the Azure Cloud which sees the one IP from the Primary MX so this mirror configuration would be beneficial...


So, in theory: If the Primary MX goes down, one of our men on site can move the WAN cable from the Primary MX WAN1 port to the Secondary MX WAN1 port that has a mirror configuration, and the connection along with the VPN connection should come back up...



Building a reputation

I'll be curious to see some other's responses.  The only way I've done it so far is with another switch in the middle.

Kind of a big deal

A switch between the Comcast device and the MXs is the way to go if you want automated failover. However, my personal opinion is that there is little point in dual devices with only a single link. The likelihood of the link failing is far higher than the device failing, and you have to consider the chance of the Comcast device itself failing.


Adding another switch in series just increases the chance of something failing, whether it be the link, the Comcast device, the switch, or the MX. So I’d just eliminate the chance of the switch failing and go straight into the MX.


Having a second MX does provide you the option to have either a cold spare or warm standby. A cold spare could be all configured up (i.e. the WAN interface) but sitting in the rack disconnected and powered down. If you get a failure then you need to swap the MX in the Dashboard for the spare and get someone to change some cables and power it up. Benefit of this is you could technically use it as a spare for any MX in your network (just reconfigure the WAN), but it is a bit more challenging to swap over.


With the warm standby, an HA pair, I don’t think having the same IP address on both devices will be a problem in itself, but it’s likely to cause problems. The Standby MX won’t be able to communicate with the cloud and so it will continually report as offline, and for the same reason it won’t update its firmware, content filter lists, IDS/IPS filters, and so on. So you really end up in the same situation as a cold spare, but with the MX being tied to a network.


Would be great to hear other’s opinions.

Kind of a big deal

>I really do not want to install a single point of failure to our WAN connection
>However, my personal opinion is that there is little point in dual devices with only a single link
I'm with @Bruce .  It sounds like you have a single connection with a single ISP router.  You have single points of failure all over the place.
It sounds like AutoVPN is a major use case.  If that is the case, I would also consider:
* Getting a cheap domestic grade second Internet connection (ideally from a different ISP), and use that with the spare MX.  You might lose inbound NATs, but at least AutoVPN will be able to continue working.
* Get something like an MG21, and plug the "WAN2" port of both MX into it, and get a cellular data plan with a lump of data on it.
If it was me, I'd probably go with both the switch between Comcast and the MXs, and either a second cheap domestic ISP for backup or an MG21.



I didn't mention:  They do actually have another connection.  I have the spare MX connected to it, so when it fails over (and it has done so due to primary connection being lost), I will lose the Azure VPN connection. 


I have the redundancy for Circuits - I was just aiming to have the automated failover in case one of the MX's fail for some reason... However, now that I think of it, I have not had our Azure guy create a tunnel for the spare circuit.  We didn't know if the client was going to keep that circuit because it was for temporary use while the primary circuit was being prepared.  


I will confirm with the client if they will keep that circuit and have the Azure team create a separate VPN tunnel for that... Treat it as a hub (Azure) and spoke as we already have done since we have 2 locations and they both point to the same Azure IP.


I will look into placing a switch between the MX's and Comcast.



Kind of a big deal

Oh, you are using the native Azure VPN - that is your issue.


Change over to using a VMX, and it will become 100% reliable. 


If you want to test this, you can request a trial VMX to test it out.  From memory, every customer using native Azure VPN to an MX who has tried VMX has bought it.

They just get sick of the limitations of Azure VPN with regard to failover.



Thanks... I will take a look.

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.