There is a way to make Meraki vMX redundant in Azure using the ha-nva-fo script.
Deploying Highly Available vMX in Azure - Cisco Meraki
https://documentation.meraki.com/MX/Other_Topics/Deploying_Highly_Available_vMX_in_Azure
> For implementing Azure functions to support High Availability vMXs, please reference:
>
> https://github.com/Azure/ha-nva-fo
The ha-nva-fo script is intended for NVA (Network Virtual Appliance) and is not specific to Meraki vMX.
Therefore, it needed to be modified for Meraki vMX.
I have created a patch.
Meraki vMX (Azure) creates a separate Managed Resource Group, so we needed to be able to specify multiple Resource Groups.
https://github.com/myhomenwlab/ha-nva-fo/tree/patch-meraki-vmx
[Supplementary information]
Incidentally, there is also a way to use BGP with Azure Route Server.
MitchellGulledge/Azure_Route_Server_Meraki_vMX
https://github.com/MitchellGulledge/Azure_Route_Server_Meraki_vMX
Well done!
The documentation for deploying VMX HA in Azure is a real pig. Meraki's documentation. Azure's documentation. It's all bad.
And the fact that Azure's own github has code that does work "out of the box" is bad as well. I like how you mentioned the FUNCTIONS_EXTENSION_VERSION change required as well.
I haven't seen that BGP solution, and that is also nice. I might be tempted to try this method next time.
Note: Document for vMX and Azure Route Server have been published. More choices are now available.
vMX and Azure Route Server - Cisco Meraki
https://documentation.meraki.com/MX/Deployment_Guides/vMX_and_Azure_Route_Server
Hi, has anyone tested the BGP option against de AZ Route Server? I thought Route Server could only run BGP as BGPoIPSec, I think I've read this somewhere. Same as AWS transit gateway which I think it only can run BGPoGRE. Maybe I'm wrong, because taking a look at the provided link BGP seems to be configure natively in the Meraki dashboard.
What if no option for deploying vMX (active and spare) using Av Zones? My customer requires Anyconnect access to the vMX cluster when deployed and I've read it is not compatible with the use of Av Zones. Are you aware of current state of this restriction? Provided it is still in place, I should deploy both vMX with no Av Zone support. Thanks!
>My customer requires Anyconnect access to the vMX cluster when deployed and I've read it is not compatible with the use of Av Zones.
The issue is when deployed into a Zone, all inbound access to the VMX is blocked by Azure - so there is no way to allow AnyConnect to connect in.
Thanks for your quick response. Understood, provided I need anyconnect VPN, I must deploy vMX with no Av Zone.
Still a couple of doubts related to vMX redundancy in Azure:
In case you must deploy vMX in two different AZ Regions, then I think you can't solve the HA using Azure Functions.
I think best approach is deploying two standalone vMX hubs, each inside one of the peered Regions. Ok, you have to pay for two meraki licenses. However, you do not have to worry about complex HA scenarios or adding the route server (still do not know how vMX can run BGP against it as I read it required BGPoIPSec)
vMX in Region 1 would publish vnets in Region1 and vMX in region2 would inject vnets in Region 2. Inside Azure, UDRs for subnets in Region 1 would route the on-prem prefixes towards vMX in Region 1. UDRs for subnets in Region 2, towards vMX in Region 2. All of this is a simplification, because in real world there is a FW applicance between server vnets and the vMX. So UDRs would point to the FW and FW to the vMX. It should work.
In this scenario I am aware subnet UDR for the vMX would require specific routes towards the customer server vnets towards the FW appliance. So AutoVPN decapsulated traffic will be sent to the FW from the vMX. However, I have to study how the vMX will send outgoing traffic to the FW.
When you deploy a vMX, Azure provides you with a basic ENI so you automatically get Azure internet access and vMX registers with Meraki cloud. So once registered, I will need to modify it to make control and also AutoVPN and Annyconnect traffic to be sent to the FW (as we do for on-prem Hubs). Azure assigns you a dynamic IP in your vnet and sets Azure vnet-reserved DGw .1 as vMX DGw. I suppose changing vMX subnet UDR to route 0.0.0.0 towards the FW IP would work: Traffic towards vnets would pass the FW, traffic towards internet would also be sent to the FW. And I guess Azure would still apply source nat to internet traffic sourced by the vMX vnet IP. Is my assumption right?
Thanks for sharing this.
We were working on doing a POC to build and test automatic failover of vMX in Azure. We took help from both Meraki and Azure support to get this automated but we were not able to do it due to lack of much documentation.
We will modify your script and give a try.