Home > Architectures and Best Practices > Auto VPN Hub Deployment Recommendations

Auto VPN Hub Deployment Recommendations

About This Document

This document provides recommendations for Auto VPN hub deployments.
These recommendations and the suggested deployment configurations have been collected across the Meraki MX install base (covering hundreds of thousands of Auto VPN sites) and have been vetted by the Meraki MX product team.

 

While this document provides a high level overview and emphasizes important considerations, please refer to the online documentation for specific details on how to implement the suggested configurations. Meraki’s 24x7 Support is also available to assist as needed.

 

The Meraki MX Auto VPN technology is versatile and supports many configuration options that are used to address different use cases - many of these are not mentioned here.

 

This document covers the most popular, common and robust Auto VPN hub deployment options.

Datacenter Hub Deployment

Summary

Overview

In order to achieve the maximum possible scale for a Meraki Auto VPN deployment, there is really only one topographical choice - Hub and Spoke (H&S).  This is due to the large number of tunnels a full mesh solution would incur. Remember the 2 formulae for working out the likely tunnel count for both support topologies are as follows:

  • Hub and Spoke - Total Tunnel Count

Total Tunnel Count = (H x (H-1) / 2)xL1+ (S x N)xL2
  • Where H is the number of hubs, S is the number of spokes, N is the number of hubs each spoke has and L is the number of uplinks the MX has (L1 for the hubs, L2 for the spokes).  If each MX has a different number of uplinks, then a sum series, as opposed to a multiplication, will be required.
  • For example, if all MXs have 2 uplinks, we have 4 hubs and 100 spokes, then the total number of VPN tunnels in the organization would be 12 + 1200 = 1212. In this case, each MX spoke will have 8 Auto VPN tunnels established and each MX Hub 200 tunnels.

 

  • Full Mesh - Total Tunnel Count

Total Tunnel Count = ((N x (N-1)) / 2)xL 
  • Where N is the number of MXs and L is the number of uplinks each MX has.
  • For example, if all MXs have 2 uplinks and there are 50 MXs, then the total number of VPN tunnels would be 2450 and every MX would have to be able to support that amount of tunnels (in this case, we would need around 50 MX450s…)

 

There are, however, multiple ways in which we can architect the H&S network such that we achieve greater flexibility. We will illustrate each of these models below.

Standard Hub & Spoke

1.png

How it works:

Utilizing the standard Meraki Auto VPN registry to ascertain how the VPN tunnels configured need to form (i.e. via public address space or via private interface address space) as described in Configuring Site-to-site VPN over MPLS.

 

When should it be used?

Whenever possible is the short answer. It is strongly recommend that this model is the 1st, 2nd and 3rd option when designing with the customer.  Only if the customer has an exceptionally strong requirement should one of the following H&S derivatives be considered.

Configuration - VPN Concentrator

 

Whilst the high-level configuration on a VPN is relatively straightforward, there are a number of potential pitfalls that will be covered here. If more information is required please refer to the definitive guide - VPN Concentrator Deployment Guide.

Global Configuration

It is strongly recommended that all MX Auto VPN hubs are dedicated hubs. As such, the Addressing & VLANs page should look like this:

2.png

VPN Configuration

From the Site-to-site VPN page, we need to set the type to Hub (Mesh), as shown below:

3.png

Hub means form a VPN tunnel to everyone who is also a Hub and any spoke that has you configured as a hub.  Whereas Spoke means to just VPN to the MXs you have configured as Hubs.

Exit Hub

When an MX is configured as a Hub, then an additional config option becomes available: ‘Exit hub’.  This allows you to bind a default route (0/0) to the IPSec security association of that hub in a similar fashion to the ‘Default Route’ option for Spoke MXs.

Local Network Advertisement

It should be known that networks that are accessible from the concentrator MX in the data center and need to be advertised to other hubs and/or spokes MXs need to be defined and advertised.  As shown below:

4.png

In the rare instances that the locally available subnets are not globally unique in the IP schema of the Auto VPN domain, then VPN translation can be enabled such that the entire locally available range can be translated to a unique range, as shown below:

5.png

These options are only to be used in emergencies, as the best solution is always to re-IP the offending range such that duplicates do not exist.

Best practice - it is generally recommended to summarize continuous addressing blocks whenever possible (e.g. 10.0.0.0/8).

For reference, below are the RFC1918 private address blocks:

  • Class A - 10.0.0.0/8
  • Class B - 172.16.0.0/12
  • Class C - 192.168.0.0/16

 

Any additional, more specific subnets contained within these supernets that are available via the advertising hub can/should also be advertised too to affect prioritization among routes.  This also extends to non-RFC1918 traffic that is publically routable that is accessible via the Auto VPN domain.

 

In the case where more complex routing is needed, please refer to the MX routing behavior document for more information.

 

If, as per the above, more than one hub is advertising the same subnet or supernet address ranges, then the priority in which those routes are used by other hub MXs is configured in the Organization-wide settings section, as per the below:

6.png

NAT Traversal

Finally, it is recommended to manually configure NAT traversal when the hub MX in VPN concentrator mode is behind a NAT unfriendly or aggressively timed CG-NAT.

7.png

DC-DC Failover - Hub/DC redundancy (Disaster Recovery)

Summary

  • Configure DC-DC Failover in order to protect against HW failure and DC outage / disaster.

 

Cisco Meraki's MX Datacenter Redundancy (DC-DC Failover) allows for network traffic sent across Auto VPN to failover between multiple geographically distributed datacenters.

8.png

 

DC Failover Architecture

A DC-DC failover architecture is as follows:

  • One-armed VPN concentrators or NAT mode concentrators in each DC
  • A subnet(s) or static route(s) advertised by two or more concentrators
  • Hub & Spoke topologies
  • Split or full tunnel configuration

Operation

Deploying one or more MXs to act as VPN concentrators in additional data centers provides greater redundancy for critical network services.

 

In a DC-DC failover design, a remote site will form VPN tunnels to all configured VPN hubs for the network. For subnets that are advertised from multiple hubs, spokes sites will send traffic to the highest priority hub that is reachable.

Concentrator Priority

Concentrator priority setting determines the order in which VPN mesh peers will prefer to connect to subnets advertised by multiple VPN concentrators.

 

Additional DC-DC integration data can be found in this article.

9.jpg

In a distributed deployment of locations connected via a site-to-site VPN, a network administrator may need to have address translation performed on traffic traversing the site-to-site VPN. A 1:1 subnet translation can be used in cases where multiple locations have the same subnet present, but both need to participate in the site-to-site VPN. Alternatively, administrators may need to conserve IP space for large deployments. For this, 1:M NAT can be used to translate entire subnets into a single IP address that is exported across the site-to-site VPN.

 

For additional information relating to VPN Subnet translation, please refer to this article.

MX Firmware Version

Summary

  • Use the latest GA (may be different per platform)

10.png

The Cisco Meraki Dashboard allows admins to easily schedule and reschedule firmware upgrades on their networks, opt-in to beta firmware releases, view firmware changelog notes, and to set maintenance windows.

 

Users will only be able to upgrade to the general release and beta versions. Information about these versions can be found under Organization > Monitor > Firmware Upgrades.

MX Hub Sizing

Summary

  • Sizing may change based on the traffic blend and other potential factors. It is also changing with the introduction of firmware improvements (the following is for MX 13).
  • These configurations have been tested successfully with retail/restaurant locations deploying 1000-1500 tunnels* per hub with MX250/MX400 (closer to 1000) and MX450/MX600 (closer to 1500).
    • * Not locations, tunnels (think SD-WAN).
  • Voice (and other small packet) traffic is notorious for high performance requirements and may result in a throughput and supported tunnel count that is lower than stated above.

Testing

Summary

  • This section captures key use cases identified to better test the MX in PoC environments.

The proposed topology for testing is detailed below. The Meraki SE and network admin will work together to refine this network architecture in the context of the POC success criteria agreed upon with the business.

11.png

The following tests should be performed:

  • Auto VPN

    • Verify that Auto VPN works correctly on the Cisco Meraki MX Security appliance in a 100% Cisco Meraki environment. Use case is for Internet access, data center access.

    • Ensure that solution works in full VPN and split-tunnelling configurations, delivering a ‘Branch-In-A-Box’ experience.

 

  • Auto VPN Failover

    • Verify that MPLS (or other) fails over to Auto VPN successfully when the MPLS private WAN (or other) path fails. Make sure the MX has access to the Meraki VPN registries.

  • Meraki SD-WAN (MPLS/Internet)

    • Verify that the Meraki SD-WAN service functions as designed and provides support for MPLS and Internet carriage simultaneously.

    • The SD-WAN success relies on Auto VPN working correctly. Always check the communication to the VPN registry, specially when the MX has a DHCP address configured that can change. Each WAN has to reach the registry individually.

    • For more information, refer to our SD-WAN Deployment Guide

 

  • Transport Independence

    • Verify that transport independent links (e.g. MPLS, ADSL, etc) can be concurrently configured to support Auto-VPN overlay networks. Enable and configure multiple diverse uplink on the MX appliance. Configure flow preferences to pin traffic to a particular path, and/or load balancing.

 

  • 3G/4G WAN Failover

    • Verify that a failover USB 3G/4G interface can be installed, enabled and configured on the MX appliance and that traffic can be redirected over this link during a WAN interface failure condition.

 

Last modified

Tags

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 7201

Explore Meraki

You can find out more about Cisco Meraki on our main site, including information on products, contacting sales and finding a vendor.

Explore Meraki

Contact Support

Most questions can be answered by reviewing our documentation, but if you need more help, Cisco Meraki Support is ready to work with you.

Open a Case

Ask the Community

In the Meraki Community, you can keep track of the latest announcements, find answers provided by fellow Meraki users and ask questions of your own.

Visit the Community