VRRP from Meraki MX100 to another legacy router

[rocktreesign]

I'm planning a network migration and have a legacy managed Cisco router on an MPLS network. We have some DCs and Internet via the MPLS at present. I want to get a second Internet link and use an MX100 for that link. I'm thinking of having an IPSEC tunnel from the Meraki to a DC for backup DC connectivity.

As my layer 3 switches MS210 will only do static routing, I wanted to use two VRRP instances between the Meraki MX100 and the Cisco. One to give primary Internet via the Meraki backed up by the Cisco and one to give primary DC connectivity via the Cisco and MPLS backed up by the Meraki and the IPSEC tunnel. The statics would be via the VRRP addresses to select which router is primary for a given destination.

I hope I've explained that well enough but two VRRP instances tracking their local WAN interfaces would achieve this. However, I don't know how functional the Meraki is in this situation.

Can it do 'proper' standard VRRP or is it a customised version for the warm standby function? Can it track an interface?

Anyone done anything like this before?

Thanks!

RTS

[KarstenI]

The MX uses VRRP for HA, but the implementation is proprietary and only works between two identical MX devices. You can't do VRRP with other devices as it is supported on a "regular" router.

[rocktreesign]

Thanks @KarstenI .  I got the impression it wasn't 'proper' VRRP from the documentation but was hoping they wouldn't say VRRP if it wasn't the full standard.  Back to the drawing board I think. 🙂

[Bruce]

As @KarstenI correctly states you can't do this using VRRP. However, you should be able to incorporate the MPLS router and MX into your network to achieve some of your desired outcomes, the main thing you'd end up losing would be hardware redundancy as the MPLS router would need to be in front or behind the MX.

One of the approaches you could consider is to use one WAN port on the MX to connect to the internet, the other to the MPLS router. You can then preference the internet link for internet traffic and the WAN link for WAN traffic, and if the internet link fails then the other WAN link (the MPLS) would get used for internet. Depending on the visibility you require you may need to get support to enable No NAT on the MPLS link, and potentially the inbound firewall in the Dashboard too (depending on where your traffic originates). What I don't think this is going to give you is your redundant path via the internet to the DC since I believe putting any kind of VPN on the MX towards the DC will make that the preferred route, rather than unencrypted out of the WAN port (to the MPLS router).

If you get the opportunity to put an MX in the DC (or already have one) in one-armed concentrator mode then you can go down the SD-WAN path, which can give you exactly what you are looking for.

[rocktreesign]

Thanks @Bruce .  Thats an interesting idea.  It does introduce a single point of failure and prevents us having the resilience from the IPSEC tunnel to the DCs and we were hoping to enhance resilience from this.

I'm thinking if I now put static routes for the DC destinations with tracking ("active while host responds to ping") on the MX via the MPLS router and make the tracking host the far end MPLS router peers for given DC subnets then the static route will stop being active if that MPLS leg fails (or the local MPLS leg or local MPLS router fails). I would need a permanent (non-tracked) static for the MPLS transit subnet(s).  In that failure scenario the traffic would then follow the route out of the IPSEC tunnel for those subnets.  Does that make sense?

In the above solution, the MX would be a single point of failure again but I could use the IPSEC tunnel.  The switch stack would need its default route via the MX interface. 

The issue would be internet connectivity.  Could I do the same in reverse for the Internet connectivity from the MX and send it via the MPLS router if the Internet link on the MX fails? 

What about if the whole MX fails?  I'm thinking I'm dead in the water?  I can't manually change the static routes on the switch stack without Internet connectivity to the switches can I?

I'm pretty new to Meraki so trying to understand this new world vs old world networking is a challenge and bringing them together seems more of a challenge!

Cheers

RTS

[Bruce]

Yep, that approach should work for providing redundancy to the DC destination.

The static route has a higher priority than the VPN peer and so should take preference all the time its available (MX route priority is here, https://documentation.meraki.com/MX/Networks_and_Routing/MX_Routing_Behavior). The MPLS router will need to be connected to one of the LAN ports of the MX, and yes, the MX is a single point of failure. I can't see a way around a single point of failure with what you have without adding more kit - but the MX devices are pretty robust anyway. In most instances you shouldn't need the transit subnets specified as static routes, you just have the connected route (between the MX and the router) and the tracked static points to the far end of that for the DC subnets - the MPLS router will take care of routing from there.

Like you said, internet connectivity won't fail-over in this scenario as if you try and put a static default via the MPLS network it will take priority and won't use the local internet unless it fails. Thinking of ways around this... if your MPLS provider can give you a second IP address from the MPLS router then you could do it by using that on WAN2, and then setting preferences for internet traffic - its not overly pretty, but might just work, and depends on how flexible your service provider is. 

Yep, if the MX fails your life becomes difficult, but not impossible. You'll need to establish internet connectivity to change the routing. You should be able to get the MS connected to the internet by using the Local Status Page on the MS. You can modify the Uplink IP address settings from here (the one it uses to connect to the Meraki cloud), so you could set the IP address and default gateway to get internet connectivity via the MPLS circuit (the routing for this is separate to the switch routing), and then once connected reconfigure the switch routing as needed.

[rocktreesign]

@Bruce Thanks.  Your replies are really helpful and I appreciate your help.

I was thinking the static route for the transit subnets allows me to use the far end of the transit subnet as the track host for whether the static route(s) are up or not.  This allows me to be granular with different failures within the MPLS.  i.e. if only one leg goes down, I can remove the routes to that DC only.  It may be overkill really and too much effort/complex to manage but we'll see when I draw it out.

The MPLS provider is willing to give me a second interface on the router with a different transit subnet so the idea of plugging that into WAN 2 of the MX is a great idea.

Finally, the confirmation that there is (albeit manual) recovery if there is no internet access is great.  It means we're not totally dead if the MX fails and I think I can get away with a manual process in that scenario.

Thanks for your help and watch this space for more queries as I flesh out the design and when I start building it!

Happy Holidays All!

RTS

[rocktreesign]

Hi,

I am trying to setup the scenario where I am tracking an IP in the MPLS network for a specific route reachable via that MPLS network.  That way I can be quite granular in what routes go via the MPLS network and which would failover to an IPSEC tunnel to the DC.  I'm doing this on the Meraki Live demo site with an MX100.

When I add the static route entry with 'while host responds to ping' for an IP in the MPLS network i get the error message...

"There were errors in saving this configuration:

• Host IP must be inside the static route's subnet."

It seems I can only use an IP in the attached subnet for the next hop?  That doesn't seem to be of much use.

The LAN interface of the MPLS router will be up and responding to pings even when its WAN interfaces are down or blackholing traffic so my static route would never be removed from the routing table and the MX100 would never use the IPSEC path to the DC. The only scenario that would failover is if the MPLS router fails completly.  Its much more likely for the circuit to fail so I need to cover that eventuality somehow.

Any ideas or thoughts?

Thanks

RTS

UPDATE - 5 mins after posting  -   I was misunderstanding the error message.  the host IP to ping must be in the destination subnet, not next hop subnet so it seems ok.  I'm guessing the logic is that if this IP in the destination subnet is not reachable via this next hop then don't use this static route which makes sense.  I wanted to use a transit subnet near to the destination but this works in any case.   Thanks if you read this far as I'm working through my design!