Would this global Meraki AutoVPN design work? The hub site US1 (2MXs HA in routed mode) is bridged to a DMVPN and MPLS network on the LAN side through static routes. Summary routes are injected on the routers in the hub (US1) and advertised from there.
1 DMVPN hub (US1)
1 MPLS hub (US1)
4 Meraki AutoVPN hubs
40 Spoke sites across the globe
US1 172.16.1.0/24 (summary route 172.16.0.0/16 advertised)
A few more questions:
- We have MPLS and DMVPN in every site (with Cisco equipment). We have HSRP configured in each site to make the DMVPN network the primary WAN link and MPLS the backup. How do we setup something similar with the Meraki AutoVPN as primary and the MPLS or DMVPN network as backup? Can you configure HSRP, GLBP or VRRP between the Meraki MX's and a Cisco router?
- If we want to use a dynamic protocol which protocol would be recommended? I've read that BGP has been tested much longer than OSPF for AUTOVPN. Would that work to share routes with neighbors (MPLS or DMVPN) on the LAN side too?
- Can you setup a site to site VPN between an external non meraki peer and one of the spoke site in the AUTOVPN mesh and advertise the external routes in the AUTOVPN mesh?
A few answers...
- The MXs run VRRP, but this is only for communication between an active and a standby MX configured as a HA pair. There isn't support for VRRP, MSRP, GLBP between an MX and another device such as a Cisco router.
- The MXs have limited support for routing protocols to other systems. They support OSPF (advertise only) and BGP, but this is primarily for when the MX is in VPN concentrator mode at a head-end (e.g. at a DC) to pass routes into the data centre.
- You can set up the MX to establish a route to a non-Meraki peer, but this will not be advertised over the AutoVPN. By default when you configure a third-party VPN every MX in the organization will try to establish a VPN to the peer. This then means every MX has a path to that location, but it does mean the creation of multiple peers on the third-party device - you can control which MXs try to establish the tunnels.
If you are trying to establish something similar to your current DMVPN and MPLS set-up then you would essentially create an SD-WAN solution with the Meraki kit and steer traffic down the paths you want. If you want redundant devices, as well as redundant paths, at each site then you will need two MX devices (although you only need one license) and you will need to connect links to WAN1 and WAN2 on both devices.
Can you setup a site to site VPN between a non meraki peer and a spoke (as opposed to a hub)?
And if you do not want to have a peer connection from the external non meraki peer to every peer in the AUTOVPN organization is there a way you can allow the sites in your organization to route to this non meraki external peer?
Yes, you can setup a site-to-site VPN with a non-Meraki peer with a spoke - it makes no difference whether the MX is a hub or spoke for AutoVPN.
If you want the destination behind the non-Meraki peer to be available to all sites, without building a tunnel to all sites, there is no way to do this using the same Meraki MXs that are establishing the AutoVPN. Your best approach would be a another VPN termination (either Meraki or third-party) which can then advertise those routes back into the Meraki AutoVPN infrastructure.
(Personally, if you can do without the Meraki Dashboard for this one function, I’d go with the third-party device to give yourself some flexibility).
Does it make sense to have regional hubs in the above design? For example if you have 2 branch offices in Asia and you have to send traffic between the branch offices would traffic have to traverse through the head office or can I assume traffic will go through the nearest hub to get to the other branch office?
Or there any advantages or disadvantages to having more hubs.
Traffic between hubs will travel direct, for spokes you list which hubs the spoke connects to and it uses them in order, always using the first hub if it is available.
If you had a hub in the UK, a spoke in New Zealand and a spoke in Australia, the traffic from New Zealand to Australia would all go via the UK and back. If all 3 were hubs then the traffic would go direct.
Therefore it is better to have a hub in each region, or if you don't have too many sites, make them all hubs.
You need to understand what your traffic flows are to build the best design. As @cmr stated having spokes in NZ and Australia and a hub in the UK could leave you with VoIP traffic going ‘the long way’, and ultimately a poor user experience.
If you only have a small number of locations then you might be better off with a single central hub, and then configure the other sites as either hubs or spokes depending on what the traffic flow is likely to be. There is no ‘automatic’ choice of which hub to go via in the Meraki solution, it’s all on predefined preferences which are used based on availability.