Imagine yourself an Enterprise company with global presense. This company has over an 1000 branches globally and two datacenters and all are on Meraki. The branches are equipped with a Meraki MX68 and larger brachens with an MX84. In the datacenter there is an redundant pair of MX450. Now this customer wants to move all of its workloads from it’s on-premise datacenter to Azure. 

To extend the Meraki SD-WAN experience to Azure Meraki has an vMX100 available in the Marketplace. This device is similiar to an Meraki MX100 and once deployed in Azure it shows up as a normal MX in the Meraki dashboard.The vMX100 has similiar specs as the MX100. It can do 500Mbps VPN throughput and can support up to 250 concurrent site-to-site tunnels. 

Here is the first challenge. A single vMX can never support the 1000 branches. An simple solution would be to deploy multiple vMX nodes in Azure and by using the Meraki templates distrubte the braches over the hubs. Also by deploying a vMX in an regional Azure hub you can distribute the load and benifit from Azure’s features to enhance the expercience your the branches. 

So a 1000 branches, 250 VPN tunnels per MX, a bit of growth would mean 5 vMX nodes, isn’t it? NO

Because the branches are not equally distributed over the different regions. Out of the 1000 branches, there are 800 located in Europe, 275 in France, 150 in Germany, 50 in Netherlands, 225 Scandinave and 100 South of Europe. Asia has 150 branches and the US 50.

With these numbers and to account for future growth you are ending up with at least 7 nodes.  1 for the US, 1 for Asia, 1 for South of Europe, 1 for Scandinave, 1 for Germany and the Netherlands together and 2 for France. 

With two nodes in France it will introduce an second challenge. Routing. The vMX is deployed in one-armed concentrator mode and there is no support to do dynamic routing with for example Azure VPN Gateway. For Azure to route the traffic to the correct vMX, static routes for each branch must be defined, pointing to the inside IP of the vMX. This is easy to achive when you run 10 branches and all branches can be aggreated into a single supernet but in this senario where there are 275 branches spread over 2 vMX it becomes a nightmare to either manage the static routes in Azure or network assignment for the branches. Either way it will increase operational complexity. 

The third challenge is the redundancy or in more detail, the lack of dynamic failover. For an enterprise company where IT is critical to business operations you want to design for failure and preferably also automatic. Simply solution would be to deploy a second vMX in an different Azure region but due to the static routing from Azure to the vMX, dynamic failover is not simply to achieve. Even when it is possible to build in dynamic failover with the help of scripting you still end up with 14 vMX nodes.

 All in All, Azure vMX is a good solution for small and medium companies but for large scale deployment sthere are some challenges which are hard or even impossible to solve. Recently Microsoft Azure and Meraki have annoucned “Cisco Meraki branch to Azure Virtual WAN”. This solution allows branches to establish an IPsec S2S VPN to the Azure VPN Gateway and counter the challenges faced above.

In my next blog I’ll talk about more on how to intergrate Meraki with Azure Virtual Wan.