Comes here often


Hi All!


I'm going to implement Meraki SD-WAN for our globally wide Customer. There will be about 40 MX boxes spread across the world. Also there will be some servers inside the MS Azure


Could anyone provide some HLD draft according to best practices or experience? 


Is it a good idea to use all physical locations as  spokes and put vMX appliance per region in Azure so vMX will act as hub.


If don't please provide some alternatives.


Thank you! 

9 Replies 9
Kind of a big deal

HLD draft?  Will the client sites need to talk to each other or just back to the hubs?

If this was helpful click the Kudo button below
If my reply solved your issue, please mark it as a solution.
Kind of a big deal
Kind of a big deal

First warning; you can not do AutoVPN in/out of China.  So if you have any sites in China speak to a Meraki SE about the special design required here.


You will want to use physical devices at spokes.  This will allow you to use multiple Internet circuits much easier.


You can only use a vMX in Azure, so that choice is easy.


Check out this MX sizing guide:



Check out this CVD (Cisco Validated Design) for SDWAN:


We've already defined device models. Only physical boxes will be installed on remote locations (Z3 for teleworkers, MX64, MX84 and MX100 for rest of locations)

There is only one site in China and it is under discussion. We might just set regular IPsec between China and Azure. Major part of sites will have dual ISP

Very few traffic will be spoke-to-spoke that's why I don't need to have hubs on remote sites. 


Does anybody know how AutoVPN calculates path on full-mesh. Is it utilizing Dijkstra or  only hop count?


HLD: https://gyazo.com/b6be42bb9d0e37d09b3a7e85986cfe37


>Does anybody know how AutoVPN calculates path on full-mesh. Is it utilizing Dijkstra or  only hop count?


That is a mute point.  In a full mesh everything talks directly to everything else.  There is nothing to calculate.


When it is not a full mesh (aka hub and spoke) then when you configure the spoke you tell it which hubs to use and the priority of those hubs.  It uses the hubs in the priority that you specify,

The question is the further one.

Please refer to design here: https://gyazo.com/5baf27bac2a4740eb308a276a12fa935

I'm wondering about traffic from Tokio to Oslo. 

Which path will be used in such case? Tokio -> vMX2 Asia -> vMX3 EU -> Oslo or Tokio -> vMX1 US -> vMX2 Asia -> vMX3 EU -> Oslo

In case of using even RIP it becomes clear. What about AutoVPN? 


Anyway does this design seem to be the perfect one? 

I'm about 90% sure in this case it is simply based on hop count (like with RIP).  If an MX has more than one link then you can use SDN, and then it can also be based on latency and packet loss.

There are several right answers and it "just depends".


With 40 spokes and using 3 x vMX for hubs; I think I would just connect every spoke to every hub.  Then no spoke is dependent on just a single hub for its connectivity.

You sure you cant use AutoVPN in China? Its working fine for us...? 😕

Kind of a big deal
Kind of a big deal

There is some info about operating in China.



On the whole, AutoVPN in and out of China is not guaranteed to work - and it may not continue to work beyond the end of this year.  Any new MX being deployed is now connected to the Chinese hosted version of Meraki, which does not have connectivity to the version used in the rest of the world.  You are expected to get a private WAN circuit between the rest of the world and China.


Also note that if you are operating an MX in China using AutoVPN to a location outside of China you should seek legal advise inside of China to determine if you are now breaking the law.  Otherwise you may be exposing the people working in China for you to considerable risk.


I also know that this year, 2018, was a transitional year.  You may find by the end of the year you have be forced to migrate to the Chinese version of Meraki.  I don't know.  Perhaps open a case with support to ask them what will happen to your Chinese devices.

Get notified when there are additional replies to this discussion.