I'm looking at Meraki as an SD-WAN solution to replace our existing VPN solution. We are moving towards a cloud first approach and use Microsoft Azure extensively along with a couple of on-premise data centres.
One of the requirements is resilience in Azure for the VPN termination. There doesn't appear to be any Meraki documentation around the vMX100 and resilience. Is High Availability possible in any form? e.g. 2 vMX100 in the same VNET (Active/Passive, cold standby, fast manual recovery?). If HA is not possible now, is this on the road map and when?
The next requirement is throughput, 500Mbps VPN throughput for the vMX100 in Azure is pretty good for branch site traffic, however is a larger vMX going to be available at some point and when? While the vMX100 would cope with most of our small/medium branches, using it to connect to our on-premise data centres for application-to-application type traffic would likely saturate 500Mbps and drag down user performance, so need more VPN throughput.
I'm not so familiar with Azure, most of my time is spent in Amazon AWS.
In Amazon I would deploy your redundant servers into two different availability zones (effectively you can think of this as just two different subnets). I would use a vMX to service the first subnet, and a second vMX to service the second subnet.
For example, if it was Exchange you could put a client access server into each subnet. If one vMX failed then the clients would fail over to the second unit and the second CAS server.
In this case, both the the vMX would be active/active. So if you spread the load nicely you'll end up with a potential Gigabit/s of throughput.
Also if you really are pumping such large volumes of data between your on-premise DC's and Azure you should consider getting an Azure ExpressRoute connection instead, and leave the vMX(s) for the branches to use.
Thanks for your response Philip.
Load Balancing subnets might be an option but as static routing is used in Azure (UDRs) this might be a bit cumbersome to route branch x sites to one MX gateway subnet and branch y to another MX gateway subnet. We have 20+ subnets in Azure each with their own routing table attached.
With regards to traffic volume, we have a security requirement to encrypt over any transit medium (Internet or private circuit e.g. Expressroute), so Expressroute doesn't really provide us with any added value as we have decent sized Internet circuits with low latency to Azure, the limitation would be the encryption device at the Azure end. We have a similar throughput issue with our current Checkpoint deployment so this isn't a dig at Meraki.
Is it possible to have multiple auto-VPNs? For example, so we could have auto-VPN 1 for branch traffic to Azure vMX1 and auto-VPN 2 for DC traffic to Azure vMX2. Effectively using auto-VPNs as separate routing domains.
On the Meraki side you can have all the branches prefer one vMX and the DC prefer the other. You would just need to be careful with the return in Azure.
@Aousien i was, but unfortunately it was not using Meraki.
With regards to HA in Azure, not many SD-WAN vendors have a solution or if they do its pretty poor. An alternative would be to use Azure Virtual WAN which is resilient and hook into your SD-WAN (if supported, e.g Citrix, VeloCloud, Silverpeak etc).
With regards to throughput often the limitation is the size of the VM. 500Mbps for the Meraki vMX-100 is really good
With regards to IKEv2 support. Its not available by default but Meraki can open it up to you on request. I'm not sure if you have to be a large customer or justify it but it is possible.
I am a Meraki fan so hopefully i will get to deploy a Meraki SD-WAN at some point. Still my pet peeve is lack of SSL inspection. As most traffic is now SSL the IPS/AMP etc will become increasingly useless if it cant see inside the packet.
>what's the best way to configure the returned traffic in Azure ?
Seriously, use AWS. It allows you to have seperate route tables per subnet - which makes this trivial.
I've also been tossing up using AWS Lamba, which allows you to run little scripts in a serverless fashion, to detect a VMX failure and dynamically update the AWS route table in use based on a failure case (easier than updating actual routes - just swap the whole route table for a "DR" table in the event of a failure - then you can still manage all the routing in the GUI).
Once thing that also frustrates me in Azure is that you can't have seperate DHCP options per subnet, only for the whole network. Grrr.
@PhilipDAth How we can place 2nd VMX-100 in azure along with existing Vmx 100 in the same region which can provide throughput of 1Gbps.
Or how we can configure as a separate Vmx 100 in the same region and advertise some existing subnets of Vmx100 to this in order to avoid bottleneck of 500 Mbps of single Vmx100.
You would need to use the dual active head end design.