AutoVPN Design

hmc250000
Getting noticed

AutoVPN Design

Meraki VPN AutoVPN.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

Subnets:
US1 172.16.1.0/24 (summary route 172.16.0.0/16 advertised)
US2 172.16.2.0/24
US3 172.16.3.0/24
US4 172.16.4.0/24
Europe1 172.16.100.0/24
Europe2 172.16.101.0/24
Europe3 172.16.102.0/24
Europe4 172.16.103.0/24

10 Replies 10
ww
Kind of a big deal
Kind of a big deal

Looks fine to me

Bruce
Kind of a big deal

Yep, don’t see why it can’t work. As always the devil is in the detail, but at a high-level it looks fine.

hmc250000
Getting noticed

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?

Bruce
Kind of a big deal

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.

hmc250000
Getting noticed

 

 

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?

 

Bruce
Kind of a big deal

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).

hmc250000
Getting noticed

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. 

cmr
Kind of a big deal
Kind of a big deal

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.

If my answer solves your problem please click Accept as Solution so others can benefit from it.
Bruce
Kind of a big deal

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.

hmc250000
Getting noticed

Would it make sense to have a backup hub (for traffic between the autovpn mesh and DMVPN) in the above scenario? 

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels