vMX in Azure High Availability

[ToryDav]

Hi All,

I have some vMX deployed in Azure right now and I am following this reference architecture, but I am having trouble with the following document.

https://documentation.meraki.com/MX/Other_Topics/Deploying_Highly_Available_vMX_in_Azure

This documentation is in my opinion quite vague. There are two diagrams shown that appear to be two different solutions, but that isn't exactly said in the document.

#1

#2

I am trying to create scenario #1, but I can't actually seem to get the routing to work over the "secondary" vMX.

The reason is because even with the VNET peering, the VNETs behind both vMX VNETs, still need a manual change to the route table during a failover scenario to change the next hop for traffic going to my spoke.

When I configure these vMX I have to add the subnets for the VNETs behind the vMX VNETs, in my case 10.50.1.0/24, they both are configured with this, and thus they both advertise that route to the spoke..

 
So my question is in solution #1, is this actually more "active / active"? Or is the primary/secondary controlled via setting the hub priority in the dashboard? For example

So how do we get true active passive in solution #1 without the Azure function, my guess is we cannot.

Should I just build this with both vMX in the same VNET, two different public IPs with both connecting to the same private subnet and use Azure function to change the next hop in the route table? 

[PhilipDAth · Accepted solution]

The documentation is sh*t in this area, both Cisco Meraki and Microsoft.

First, the Microsoft function updates the next hop in any tagged route tables.  So you can use any design in Azure where you can have a static route that can point at one vMX, and where you (by only changing the next hop) have it go to the other VMX.

A critical requirement is that the subnet that the VMX go into can not be used by anything you are trying to access (so the VMX can not go into the same subnet as a server you want to access).

In the last deployment I did - the client had everything they wanted to access in a single VNET, so I just added a brand new subnet into that same VNET to put both VMX into.

Bearing in mind the simple requirement for being able to change the next hop - you can have same the same VNET as everything else, one brand new VNET for both VMX, or two separate VNETs, one for each VMX.  Bear in mind if you create new VNETs you will need to configure VNET peering.

You should add a single route into the VNET route table system for each Meraki subnet via the "primary" VMX.  The Microsoft function will then change the next hop address to point to the secondary VMX on the primary VMX failing.  note that it only changes the next hop address back again if the secondary VMX fails.

[ToryDav]

Hi @PhilipDAth 

Thank you Philip! You ROCK. You have helped me understand the design requirements immensely, which seems to add more flexibility to what I am trying to do.

[PhilipDAth]

Also, using zones in Azure for a VMX has a problem (so I don't use Zones) ...

When you use a zone get get an "Advanced IP" SKU - and this does not allow inbound initiated traffic, and you can not change that.  So you can not use client VPN (or Cisco AnyConnect).  It also makes AutoVPN a little bit less reliable, as spokes can not re-initiate the tunnel after a failure, only the VMX can, and only if it knows about the failure that the spoke is suffering.

If you don't use a zone, then all inbound traffic is allowed.  Now you can use client VPN again.  And now a spoke (on a failure) can initiate a new AutoVPN into the VMX to repair a fault.

Note that because this case allows all inbound Internet traffic to the VMX, you should disable the local status page (IMHO).

[knolf]

I know this is an old thread but I have been testing another way to achieve HA using Meraki in Azure using Azure load-balancer.

Azure: Using a Load Balancer to achieve high-availability and load-balancin... - The Meraki Communit...