Home > Architectures and Best Practices > Cisco Meraki Best Practice Design > Best Practice Design - MX Security and SD-WAN

Best Practice Design - MX Security and SD-WAN

Table of contents
  1. General MX Best Practices
  2. Deployment Options
    1. Routed (NAT) Mode
      1. NAT Mode Features
      2. NAT Mode Considerations
    2. Passthrough/VPN Concentrator Mode
      1. Passthrough/VPN Concentrator Mode Features
      2. Passthrough/VPN Concentrator Considerations
  3. Redundancy and High Availability
    1. High Availability and Redundant WAN Connections
    2. High Availability (HA) Pair
  4. Cisco Meraki MX Networking
    1. Addressing and VLANs
    2. Routing and Layer 3 Connectivity
  5. MX Security Functionality
    1. Layer 3 Firewall Rules
    2. Layer 7 Firewall Rules
    3. Port Forwarding and NAT Rules
      1. Port Forwarding Rules
      2. 1:1 and 1:Many NAT Rules
      3. 1:Many NAT Rules
    4. Advanced Malware Protection (AMP)
    5. Intrusion Detection and Prevention (IDS/IPS)
    6. IP Source Address Spoofing Protection
  6. Site to Site VPN
    1. Meraki Auto VPN
      1. Auto VPN Hub and Spoke Operation
  7. Client VPN
  8. SD-WAN & Traffic Shaping
    1. Uplink Configuration
    2. Uplink Selection
    3. SD-WAN Policies
    4. Global Bandwidth Limits
    5. Traffic Shaping Rules
    6. Meraki Auto VPN
      1. Auto VPN Best Practices
        1. Auto VPN at the Branch
        2. Auto VPN at the Data Center
      2. Datacenter Redundancy (DC-DC Failover)
        1. Topology
        2. Behavior
        3. MX IP Assignment
      3. MX Data Center Routing
        1. Failover Times
        2. Configuring OSPF Route Advertisement
        3. BGP and Auto VPN
      4. Auto VPN Technology Deep Dive
        1. Dashboard & Cloud
        2. VPN Registry
        3. Uplink Health Monitoring
      5. VPN Registry
      6. Auto VPN Routing
      7. High Availability
        1. Hardware Redundancy in VPN Concentrator Mode
        2. HW Redundancy in NAT mode
        3. DC-DC Failover - Hub/Data Center Redundancy (Disaster Recovery)
      8. Supported VPN Architectures
        1. VPN Topologies
          1. Split Tunnel
          2. Full Tunnel  
          3. Hub and Spoke
        2. Standard Hub & Spoke
        3. VPN Mesh
        4. Regional Hub & Spoke
        5. Hierarchical Hub & Spoke
      9. China Auto VPN
        1. China Auto VPN Architecture
    7. Meraki SD-WAN
        1. What is SD-WAN?
        2. Key Concepts
          1. Concentrator Mode
          2. One-Armed Concentrator
          3. NAT Mode Concentrator 
          4. VPN Topology
          5. Split Tunnel
          6. Full Tunnel 
          7. Hub and Spoke
          8. VPN Mesh
          9. Datacenter Redundancy (DC-DC Failover)
          10. Warm Spare (High Availability) for VPN concentrators
        3. Connection Monitor
        4. SD-WAN Technologies
          1. Dual-Active VPN Uplinks
          2. Policy-Based Routing (PbR)
          3. Dynamic Path Selection
          4. Performance Probes
        5. High-Level Architecture
          1. SD-WAN Objectives
          2. Example Topology
          3. High Level Traffic Flow
        6. Failover Times
      1. Datacenter Deployment
        1. Deploying a One-Armed Concentrator
          1. Example Topology
          2. Dashboard Configuration
          3. NAT Traversal
          4. Adding Warm Spare
          5. Warm Spare Topology
          6. Behaviour
          7. Dashboard Configuration
          8. Configuring OSPF Route Advertisement
          9. Behaviour
          10. Dashboard Configuration
        2. Other Datacenter Configuration
          1. MX IP Assignment
          2. Upstream Considerations
          3. Routing
          4. Firewall Considerations
        3. Datacenter Redundancy (DC-DC Failover)
      2. Branch Deployment
        1. Configuring AutoVPN at the Branch
          1. Prerequisites
          2. WAN Interface Configuration
          3. Subnet Configuration
          4. Configuring AutoVPN
          5. Configuring Hub and Spoke VPN
          6. Hub Priorities
          7. Configuring Allowed Networks
          8. NAT Traversal
        2. Adding Performance and Policy Rules
          1. Best for VoIP
          2. Load Balance Video
          3. PbR with Performance Failover for Web traffic
          4. Layer 7 Classification
          5. Best for VoIP
      3. FAQ
        1. Does the MX support unencrypted AutoVPN tunnels?
        2. If traffic is encrypted, what about QoS or DSCP tags?
        3. Can a non-Meraki device be used as a VPN hub?
        4. How does this inter-operate with IWAN using Cisco ISR routers?
        5. Is dual active AutoVPN available over a 3G or 4G modem?
        6. How does SD-WAN inter-operate with warm spare (HA) at the branch?
      4. References
        1. Auto VPN White Paper
        2. SD-WAN page
      5. Appendix
        1. Appendix 1: Detailed traffic flow for PbR and dynamic path selection
          1. Complete Flowchart
          2. Decision Point 1: Can we establish Tunnels over both uplinks?
          3. Decision Point 2: Are performance rules for dynamic path selection defined?
          4. Decision Point 3: Are PbR rules defined?
          5. Decision Point 4: Is VPN load balancing configured?
    8. MX Templates Best Practices
      1. Planning a Template Deployment for MX
      2. Template Networks
      3. Configuration
        1. Creating a Template Network
        2. Template VLAN Configuration
        3. Template Static Routes
        4. Template Firewall Rules
        5. Template SD-WAN Policies
        6. Local Overrides
        7. DHCP Exceptions
        8. Forwarding Rules Overrides
        9. Templates with MXs of Different Port Counts
      4. Performing MX Templates Firmware Upgrades
      5. MX Replacement Walkthrough

General MX Best Practices

With the increasing popularity and demand for SD-WAN architecture, planning and designing a secure and highly functional network can be a challenging task. With cloud technology on the rise, and an increase in the amount of user data in modern networks, it is no easy task to plan and accommodate, while maintaining overall security. The Cisco Meraki MX security appliances allow for high-end performance with a robust feature set to provide an easy to manage security solution for environments of any size. From small form factor teleworker gateways to powerful datacenter appliances, the Cisco Meraki MX allows for flexibility and functionality of network operations. 

 

For branch offices that require communication to the corporate network, remote employees on the go that need to view important documents on public networks, or administrators that require increased control over client devices, Software Defined Networking is an ever-growing key component of the modern data network. Typically this requires tedious interaction and configurations to ensure full functionality for end users and client devices, as well as constant monitoring. Due to the fact that Cisco Meraki security appliances are managed completely with the Meraki cloud, all of this can be done with our intuitive online dashboard. The dashboard provides the in-depth visibility needed for the modern network with integrated monitoring tools.  

To find more in-depth information on what model of the Cisco Meraki MX best suits your needs, please refer to the MX sizing guide.

Deployment Options

The Cisco Meraki MX security appliance has a number of deployment options to meet the needs of your network and infrastructure. Whether as the main edge firewall for your network, or as a concentrator device in your data center, the MX security appliance can be easily integrated. The operational modes of the MX can be found on the Cisco Meraki dashboard under Security & SD-WAN > Configure > Addressing and VLANs.


Screen Shot 2019-07-15 at 12.26.38 PM.png

Routed (NAT) Mode

Routed mode on a Cisco Meraki MX is best used when the security appliance will be connecting directly to your internet demarcation point. When this is the case, the MX will have a public IP address that is issued by the internet service provider. The MX will also be the device handling the routing for clients to the internet, and any other networks configured for the device to communicate to.  This mode is optimal for networking environments that require a security appliance with Layer 3 networking capabilities.


clipboard_e075a8827e62e52274cc02019c35fd89c.png

NAT Mode Considerations

  • A Cisco Meraki MX security appliance operating in NAT mode is best deployed when its WAN connection is directly connected to the ISP handoff
  • An MX can operate in NAT mode if it is behind another Layer 3 device that is also performing NAT, but you may run into complications with Meraki cloud connectivity, as well as some features such as Meraki Auto VPN

Passthrough/VPN Concentrator Mode

Passthrough mode on a Cisco Meraki MX configures the appliance as a Layer 2 bridge for the network.  The MX in this mode will not perform any routing or any network translations for clients on the network.  Passthrough/Concentrator Mode is best used when there is an existing Layer 3 device upstream handling network routing functions.  The MX in this instance would still act as a security appliance, but with less functionality for Layer 3 networking.

The recommended use case for the MX security appliance in passthrough mode is when it is acting as a VPN Concentrator for the Cisco Meraki Auto VPN feature.  Passthrough/VPN Concentrator mode ensures easy integration into an existing network that may already have layer 3 functionality and edge security in place.  With this mode, a Cisco Meraki MX security appliance can be integrated into the existing topology and allow for seamless site to site communication with minimal configuration needed.

MX as VPN Concentrator Green.png

Passthrough/VPN Concentrator Considerations

  • The Cisco Meraki MX will not perform layer functions such as NAT or routing.
  • An MX in passthrough/VPN concentrator mode will act as a layer 2 firewall that will integrate into the existing LAN with a layer 3 routing appliance upstream.
  • VPN destined traffic will need to be directed to the MX security appliance for effective routing to the VPN endpoint. As such, static routes on other Layer 3 capable devices may be needed for full VPN functionality.
  • MX appliances in passthrough are able to allow IPv6 traffic to pass across the existing LAN if the traffic flows through the MX.

Redundancy and High Availability

With the network being a vital tool and resource for today's business operations, it is essential that network functionality and connectivity remain as consistent as possible. Planning for high availability in your network infrastructure is critical. Cisco Meraki MX security appliances allow for easy and seamless configuration and design of a highly available network. To ensure the maximum amount of uptime for your network, MX security appliances include a number of capabilities for a redundant design. These capabilities include the ability to form a High Availability (HA) pair, as well as multiple internet uplink ports with automatic failover functionality.

High Availability and Redundant WAN Connections

The recommended deployment to ensure the most possible uptime is an environment that combines two high availability paired MX appliances with multiple Internet Service Provider connections. In this architecture, there is full redundancy to minimize the possible downtime in the event of a failure in either an appliance or a service provider. 

 

recommended_HA_design.png

High Availability (HA) Pair

When deploying two MX security appliances in high availability (HA), it is recommended to have the management traffic for HA traverse via a downstream connection to a layer 2 switch, and to not have a dedicated HA cable connected between the two appliances. The reason for this is because there is an increased potential for a spanning-tree loop if the MX appliances are also connected to the same layer 2 switch. The best topology is to have the MX appliances connected to the same downstream Layer 2 switch.

 

MX HA Pair (1).png
 

NOTE: The MX generates and sends VRRP heartbeats across all configured VLANs. For best high availability behavior, it is recommended to have all VLANs allowed on the downstream connections to the switches that are connecting the MX HA pair.  It is also recommended that any downstream switches that may be passing the VRRP traffic are configured to be aware of all the VLANs configured on the MX security appliance.

 

For more information on HA configuration with VRRP on the Meraki MX, see the knowledge base document MX Warm Spare - HA Pair.

For more information on MX layer 2 connectivity, see the knowledge base document MX Layer 2 Functionality.

Cisco Meraki MX Networking

When planning and designing a network, an important consideration is whether the client and end-user devices should be on the same network or subnet. In most cases, having multiple subnets in your deployment is recommended, as it adds a layer of security against potentially malicious devices or users. This is especially recommended if you are planning on having a guest network set up. The MX security appliance is capable of supporting multiple subnets or VLANs so the user networks can be separated out.  

Addressing and VLANs

The best practice for planning and configuring a network is to have multiple VLANs for different traffic uses cases. This is especially recommended for separation of networks that will be hosting employee data and networks providing guest access. This is a critical consideration to ensure the maximum possible security for your networking environment. Using multiple VLANs for different use cases will also decrease the amount of broadcast traffic within the same subnet. When designing and configuring multiple VLANs, it is generally recommended to create the subnet to be sized for the necessary amount of devices intended to be in that particular network. Generally, networks with /24 subnet masks are large enough for common deployments, while also providing room for expansion and simple subnetting scalability if more VLANs are to be added. However, it is always best to consider the needs of your deployment when planning your subnets, as some deployments may require larger addressing spaces.

 

MX VLANs.png

 

For more information on enabling and configuring VLANs please see our knowledge base document Configuring VLANs on the MX Security Appliance.

Routing and Layer 3 Connectivity

In certain deployments, the MX security appliance may not be the only device performing layer 3 functions for the entirety of the data network. Examples of this can be a deployment where the MX acts as the internet edge gateway while layer 3 routing is performed on downstream devices, or where another layer 3 capable device is added into the existing routing topology. If this is the case, then the MX security appliance must have static routes configured to allow for effective communication to the other layer 3 destinations in the network. The other layer 3 devices must also have static routes in place to the MX. 

In the example below, an MX is set up as an Internet edge firewall, with the rest of the layer 3 routing taking place on a downstream switch stack. With this configuration, it is best to have a single subnet configured between the MX and the other layer 3 device, to minimize the amount of traffic and routing that will be taking place as well as to keep routing consistency. This single subnet will act as a transit VLAN for all routing that is to take place between the two layer 3 endpoints in the topology. 

 

MX to L3 Switch.png

For more information on MX routing and layer 3 connectivity, please refer to the documents MX and MS Basic Layer 3 Topology and MX Routing Behavior

MX Security Functionality

The MX security appliance allows for simple yet effective security for your networks and deployments with the numerous security functions it has to offer. Configuring advanced security policies and features ensures a protected environment for your deployment. The MX has the following services and configuration options for security functionality:

  • Layer 3 Stateful Firewall
  • Layer 7 Firewall functionality
  • Port Forwarding and NAT
  • Advanced Malware Protection (Advanced Security License)
  • Intrusion Detection and Prevention Services (Advanced Security License)
  • IP Source Address Spoofing Protection

Layer 3 Firewall Rules

The MX security appliance allows for custom outbound firewall rules to be configured to ensure precise and granular control over which networks are able to communicate with one another.  The MX security appliance is a stateful firewall, meaning that all inbound connections are blocked unless they have either originated from within the MX or a forwarding rule is configured.  

By default, all VLANs configured on the MX security appliance will be able to communicate with one another.  If there are VLANs you wish to not be able to pass traffic between, firewall rules will need to be configured.  It is best practice to restrict the amount of traffic that can travel between subnets that are not closely related.  For example, it is recommended to create firewall rules to block all traffic from a VLAN that may be used for guest access from being able to contact other VLANs used for business operations.  

 

Block data to guest.png

 

Additionally, if there are internal users that need internet access, but should be blocked from accessing a certain site or IP address, the firewall rules can be configured with IPs or URLs as the destinations. The use case for this is if you know of a website the users in that VLAN should not access.

 

Block VLAN access to site.png

NOTE: The layer 3 firewall rules configured will be processed in top-down order.  If traffic matches a rule in the list, the MX will no longer process any further rules for that traffic.  

Layer 7 Firewall Rules

Best practice design for Layer 7 rules is to ensure that the category you have selected to block does not fall under the traffic flow for applications you may use.  For example, if you choose to block the category for "File Sharing," and you block all options, you may cause a disruption in service for an application such as Microsoft OneDrive.  It is best to try and configure Layer 7 rules as granular as possible, to avoid such scenarios.

Using Layer 7 firewall rules for blocking traffic based on countries also has its caveats as well.  While it may seem more secure to block all countries other than the one the MX is located in, this can cause issues with traffic flows to certain resources that may actually be necessary for daily operations.  Certain webpages and web applications can be hosted in a country not being blocked, but they may pull supplementary data or resources from a server located in a country that is being blocked by the MX appliance.  As a result, certain aspects may not function as intended or may fail to function altogether.  It is essential to only block countries with a Layer 7 rule if you know traffic from this country is malicious in nature.  

For more information on MX layer 7 rules please refer to the knowledge base documents for the MX Firewall Settings and Creating a Layer 7 Firewall Rule

Port Forwarding and NAT Rules

Due to the nature of the Cisco Meraki MX, all inbound traffic that did not originate from within the networks configured on the appliance will be dropped by default. This is because the MX security appliance is a stateful firewall, so the MX must be aware of or expecting incoming traffic.  For connections that originate from outside of the MX and need to be allowed in, either a port forwarding rule or a NAT rule can be configured to permit this traffic.  

Port Forwarding Rules

It is important to plan out your port forwarding rules accordingly with the traffic you are planning to let in behind the firewall. The best configuration for port forwarding rules is to plan for as narrow of a scope as possible.  Only create port forwarding rules for subsequent connections on ports that are necessary.  It is also not recommended to create port forwarding rules with "Any" for the allowed remote IP ranges.  The appropriate use-case for having the parameter "Any" in the allowed remote IP field is if you have a web server behind the MX.  If a web server is in use for the port forwarding rule, it is best to use an obscure port range for the public ports configured, as common web ports can lead to potential vulnerabilities. 

 

clipboard_ec95d3416d8ea94f47ea849bee13a3907.png

 

1:1 and 1:Many NAT Rules

A 1:1 rule enables traffic destined for a particular public IP address to be forwarded to a particular internal host or hosts.  This is similar in nature to a port forward, but in this case the traffic is being sent to another public IP address that is not the IP of the MX WAN interface.  This is best used when there are multiple public IP addresses available, and you do not wish to have internet-based traffic for a web server destined to the public IP of the WAN interface on the MX.  If a 1:1 NAT rule is configured for other services that are not for a web facing server, then it is best practices to limit the range of ports being used, as well as the range of remote IPs for the connection.

 

1 to 1 NAT example.png

 

clipboard_e41ee8613a1dd8bdf3d95256e5d2ee033.png

 

1:Many NAT Rules

In some instances, particularly if the number of public IPs available to you are limited, a 1:Many NAT rule can be put in place.  This is also very similar to a port forwarding rule, but again the public IP address that traffic is destined to determines how the Cisco Meraki MX security appliance handles the traffic.  If traffic destined for that specific IP address comes in on a particular public port, then the MX security appliance will forward the traffic to an internal host based on said port.  This enables the ability to use a single public IP address for multiple services.  This also allows for a concise deployment so there are not multiple public IPs required. 

 

clipboard_e15fe67b4d5848a49228de4d7d684cfc4.png

 

Advanced Malware Protection (AMP)

Advanced Malware Protection (AMP) is an adaptive and powerful tool that is incorporated on the Cisco Meraki MX security appliance with the Advanced Security license.  AMP scans and inspects HTTP downloads that are moving through the MX security appliance.  The MX then takes action based on the threat intelligence it receives from the AMP cloud.  If a download matches a known signature from the AMP cloud, then the security appliance will block the download.  With an MX security appliance, it is highly recommended to have AMP enabled and functioning so your networking environment is secure and safe from attacks. 

For more information about AMP,  please refer to the knowledge base documents Advanced Malware Protection (AMP) and Threat Protection

Intrusion Detection and Prevention (IDS/IPS)

With the Advanced Security license, Intrusion Detection and Prevention (IDS/IPS) enables the MX security appliance to inspect all incoming and outgoing traffic that is being routed internally and externally in the networking environment. IDS/IPS searches for various signature-based attacks as traffic flows through the security appliance. This is achieved with the various rules and signatures that are in the SNORT® intrusion detection engine. This enables the MX to detect malicious traffic and not only provides alerts that a known signature was detected, but also take action against that threat and prevent it from doing harm on the network. To ensure a secure and stable networking environment, it is recommended to have Intrusion Detection and Prevention services enabled and operating on the MX.  

For more information on IDS/IPS, please refer to the knowledge base document Threat Protection

IP Source Address Spoofing Protection

IP Source Address Spoofing Protection is a security mechanism on the Cisco Meraki MX that enables protection from malicious users on the network from impersonating other hosts and attempting to bypass security restrictions.  The MX uses several methods of traffic verification to ensure client data is authentic and not spoofed by a malicious attacker.  It is recommended to have this feature set to the mode "Block" so malicious IP spoofing events are mitigated on the network by the MX security appliance as soon as they are identified. There is the option to have the mode set to "Log" but this will not provide protection against these types of attacks, but rather just alert that malicious traffic of this nature has been detected. 

 

IP Source sppofing prot.png

 

If you would like more information about this feature on the MX security appliance, please see the knowledge document IP Source Address Spoofing Protection

Site to Site VPN

When connectivity and intercommunication is needed between different networks that are separated geographically, a site to site VPN tunnel is the best solution. The MX security appliance is equipped with all the necessary functionality for VPN tunnel communication between sites and networks.  The SD-WAN capabilities of the MX security appliance allow for other MX devices in the same Cisco Meraki organization to easily establish VPN tunnels to one another with a quick and simple configuration. This is achieved with the Cisco Meraki Auto VPN.

Meraki Auto VPN

The MX security appliance allows for simple and seamless integration and configuration of VPN tunnels among sites.  This is achieved with Meraki's proprietary Auto VPN functionality that allows for simple and fast configuration of site to site VPN tunnels.  Additionally, Auto VPN enables maximum uptime of the site-to-site tunnels with congruent VPN tunnels on all available WAN interfaces. VPN tunnels are built actively on all WAN interfaces on the MX that can reach the Meraki cloud.  This allows for dynamic failover and built-in redundancy with no extra configuration needed.  It is recommended to use Meraki Auto VPN between MX security appliances for essential inter-site communication. Note that Auto VPN can only be used for Meraki to Meraki communications, for Meraki devices in the same Meraki dashboard organization. Separate Meraki dashboard organizations generally represent separate SD-WAN environments.

MX Auto VPN Green.png

Auto VPN Hub and Spoke Operation

The Auto VPN feature allows an MX security appliance to operate as either a hub or a spoke in the VPN topology. An MX configured as a hub will build a VPN tunnel to every MX that is operating as a hub and each spoke that the hub is configured as the hub appliance.  Spoke devices will build tunnels only to MX appliances they have configured as hubs, and not to other spoke sites.  It is important to take this behavior into consideration, as configuring each MX appliance as a spoke can cause a degradation of service in large deployments.  

 

MX VPN Hub and Spoke.png

 

It is recommended to have a Cisco Meraki MX security appliance configured as a hub if it is essential for all other security appliances configured in the VPN topology to have communication to networks on the hub appliance.  Typically this is effective for MX appliances at locations where there are a large number of resources for business operations, such as at the corporate office or a datacenter.  

Hub and Spoke example.png

Client VPN

The MX security appliance includes the option to configure client VPN functionality for remote users that require access to resources hosted in your data network.  The client VPN feature allows those users to establish a secure connection to the MX security appliance from their device as long as they have a valid internet connection.  Though it is not required for full client VPN functionality, the client VPN feature has increased functionality and ease of use when it is deployed with a policy encompassed with Cisco Meraki Systems Manager installed on the user's remote device.  Meraki Systems Manager allows for a dynamic policy to be remotely pushed to the client device so the client VPN functionality is seamlessly integrated on the end device without end-user configuration.  

It is highly recommended to deploy and use the client VPN feature with the use of a Systems Manager policy, as this allows for a better experience for end-users as they will not have to do any sort of configuration on their end.  This is exceedingly useful in the event that the end-user's client VPN service is having issues connecting to the MX security appliance.  This allows administrators the ability to effectively troubleshoot the issue without needing the end-user to engage in the technical troubleshooting process; creating a more simple end customer experience. 

 

Client SM VPN Example.png

For more information about the Client VPN feature, please see the following knowledge base documents:

SD-WAN & Traffic Shaping

The Cisco Meraki MX security appliance includes a multitude of built-in SD-WAN functions that are easy to deploy and configure.  This allows you to have built-in monitoring and simple configuration with an easy and intuitive interface.  

Under the SD-WAN settings, the uplink connections for the MX security appliance can be configured to best fit the needs of your networking environment.  The uplink bandwidth limit can be configured and changed to best fit the requirements of the connection with your internet service provider.  It is best practice to set the throughput bandwidth to the highest possible amount based on your bandwidth set by your provider as to avoid potentially saturating the connection.  

For uplink monitoring, it is recommended to configure multiple uplink statistic test IPs on the Meraki dashboard.  This is exceptionally useful for troubleshooting purposes, as it allows the dashboard to collect and monitor data on certain connections specified.  A few examples of connections to monitor would be a general connection to the internet (Google's 8.8.8.8 is configured by default), the connection to your service provider gateway, and the connection to any remote sites that may be participating in site to site VPN tunneling. 

Another feature of the functionality that the MX includes is automatic security list updates for features such as AMP, IDS/IPS, and content URL filtering.  These lists can be configured to check for changes in security rules on an hourly, daily, or weekly basis.  The best practice to ensure your environment stays secure is to have this interval set to check the security lists hourly.  The frequency of updates can be changed per each WAN uplink, including the cellular uplink as well.  

 

clipboard_ea6eb5334c9e59e41e2e4945e3ee3241b.png

 

Included with the SD-WAN options is the ability to have the MX route traffic to different uplinks depending on certain scenarios. Uplink selection enables the ability of policy-based routing on the MX, which uses flow preferences for specific traffic as it heads out the WAN connection. With this tool, it is recommended to have the uplink connections be set to load balance the traffic if applicable. This is best used if there are redundant internet connections that have similar bandwidth capabilities.  

With flow preferences based on the source traffic, it is easy to shape traffic to best fit the nature of the network traffic as it transverses to the WAN connection. An example of what a flow preference may be used for is guest traffic.  To allow for a consistent and stable connection the more cost-effective secondary WAN connection can be configured to handle guest related traffic. 


Uplink selection.png

SD-WAN Policies

SD-WAN policies can be configured to control and modify the flows for specific VPN traffic. With multiple WAN uplinks, the MX will proactively build multiple tunnels with each available WAN interface.  In the case where there are redundant WAN connections on the security appliance, traffic flows based on the type of traffic traversing the VPN connections can also be configured to allow for best performance. Custom policies set to desired preferences can be set to ensure traffic flows take the appropriate path based on your environment.  If a WAN connection that normally handles traffic such as file transfers begins to have performance issues, the Cisco Meraki MX can dynamically change the VPN connection to an alternative WAN uplink. This is done with custom policies or predetermined policies on the dashboard. It is encouraged to configure said policies in your deployment to best fit the needs based on the nature of the traffic and the capabilities of the WAN connections available on the MX

If you do have questions about what policies are best for your deployment, you can always reach out to either a Meraki Sales Engineer or your Meraki partner for a consultation on what best fits your needs.


SDWAN policies.png

 

Global Bandwidth Limits

In larger deployments, bandwidth limits for end-user devices can to be put in place to ensure the uplinks do not become saturated. This largely depends on the type of traffic that is seen from users, how many users are on the network, as well as the throughput capabilities of the MX security appliance and the uplinks. With more substantial deployments where there are a large number of clients, it is recommended to set a bandwidth limit on all traffic. The amount of bandwidth required per client can vary depending on the type of traffic seen in the networking environment.  

Speedburst is an option to allow clients a short window of time to exceed the bandwidth limit configured to allow, for example, a large file to transfer faster. This is a useful feature if there are users that will be handling and uploading large files frequently on the network. Speedburst is a recommended feature to enable, with the caveat that it should only be used if there are not a large number of clients that will need high amounts of bandwidth at the same time. If there are a select few users or devices that require moments of higher bandwidth then Speedburst is recommended.

  

Screen Shot 2019-07-18 at 3.22.47 PM.png

Traffic Shaping Rules

Different types of traffic require different priorities on the network.  The MX is able to prioritize and shape traffic on the local network based on the traffic type.  The Meraki dashboard offers default traffic shaping rules that best fit the needs for most deployments.  These default rules ensure best performance for local voice traffic, software updates for end client devices, and collaboration applications.  It is recommended to enable these default traffic shaping rules on the MX as it allows for simple and fast configuration for the best performance of network traffic.


Traffic Shaping rules default.png

Meraki Auto VPN

Auto VPN Best Practices

The best practices listed here focus on the most common deployment scenario, but is not intended to preclude the use of alternative topologies. The recommended SD-WAN architecture for most deployments is as follows:

 

  • MX at the datacenter deployed as a one-armed concentrator

  • Warm spare/High Availability at the datacenter

  • OSPF route advertisement for scalable upstream connectivity to connected VPN subnets

  • Datacenter redundancy

  • Split tunnel VPN from the branches and remote offices

  • Dual WAN uplinks at all branches and remote offices

Auto VPN at the Branch

Before configuring and building Auto VPN tunnels, there are several configuration steps that should be reviewed.

 

WAN Interface Configuration

While automatic uplink configuration via DHCP is sufficient in many cases, some deployments may require manual uplink configuration of the MX security appliance at the branch. The procedure for assigning static IP addresses to WAN interfaces can be found in our MX IP assignment documentation.

 

Some MX models have only one dedicated Internet port and require a LAN port be configured to act as a secondary Internet port via the device local status page if two uplink connections are required. MX models that require reconfiguring a LAN port as a secondary Internet port currently include the MX64 line, MX67 line, and MX100 devices. This can also be verified per-model in our installation guides online. This configuration change can be performed on the device local status page on the Configure tab.

 

Subnet Configuration

Auto VPN allows for the addition and removal of subnets from the Auto VPN topology with a few clicks. The appropriate subnets should be configured before proceeding with the site-to-site VPN configuration.

 

Hub Priorities

Hub priority is based on the position of individual hubs in the list from top to bottom. The first hub has the highest priority, the second hub the second highest priority, and so on. Traffic destined for subnets advertised from multiple hubs will be sent to the highest priority hub that a) is advertising the subnet and b) currently has a working VPN connection with the spoke. Traffic to subnets advertised by only one hub is sent directly to that hub.

 

Configuring Allowed Networks

To allow a particular subnet to communicate across the VPN, locate the local networks section in the Site-to-site VPN page. The list of subnets is populated from the configured local subnets and static routes in the Addressing & VLANs page, as well as the Client VPN subnet if one is configured.

 

To allow a subnet to use the VPN, set the Use VPN drop-down to yes for that subnet.

Auto VPN at the Data Center

Deploying a One-Armed Concentrator

A one-armed concentrator is the recommended datacenter design choice for an SD-WAN deployment. The following diagram shows an example of a datacenter topology with a one-armed concentrator:

1.png

 

NAT Traversal

Whether to use Manual or Automatic NAT traversal is an important consideration for the VPN concentrator.

 

Use manual NAT traversal when:

  • There is an unfriendly NAT upstream

  • Stringent firewall rules are in place to control what traffic is allowed to ingress or egress the datacenter

  • It is important to know which port remote sites will use to communicate with the VPN concentrator

 

If manual NAT traversal is selected, it is highly recommended that the VPN concentrator be assigned a static IP address. Manual NAT traversal is intended for configurations when all traffic for a specified port can be forward to the VPN concentrator.

 

Use automatic NAT traversal when:

  • None of the conditions listed above that would require manual NAT traversal exist

 

If automatic NAT traversal is selected, the MX will automatically select a high numbered UDP port to source Auto VPN traffic from. The VPN concentrator will reach out to the remote sites using this port, creating a stateful flow mapping in the upstream firewall that will also allow traffic initiated from the remote side through to the VPN concentrator without the need for a separate inbound firewall rule.

Datacenter Redundancy (DC-DC Failover)

Meraki MX Security Appliances support datacenter to datacenter redundancy via our DC-DC failover implementation. The same steps used above can also be used to deploy one-armed concentrators at one or more additional data centers. For further information about VPN failover behavior and route prioritization, refer to our DC-DC Failover documentation.

This section outlines the steps required to configure and implement warm spare high availability (HA) for an MX Security Appliance operating in VPN concentrator mode.

Topology

The following is an example of a topology that leverages an HA configuration for VPN concentrators:

 

2.png

Behavior

When configured for high availability (HA), one MX is active, serving as the master, and the other MX operates in a passive, standby capacity. The VRRP protocol is leveraged to achieve failover. Check out our MX Warm Spare documentation for more information.

MX IP Assignment

In the datacenter, an MX Security Appliance can operate using a static IP address or an address from DHCP. MX appliances will attempt to pull DHCP addresses by default. It is highly recommended to assign static IP addresses to VPN concentrators.

 

Uplink IPs

Use Uplink IPs is selected by default for new network setups. In order to properly communicate in HA, VPN concentrator MXs must be set to use the virtual IP (vIP).

 

Virtual IP (vIP)

Virtual IP is an addressing option that uses an additional (third) IP address that is shared by the HA MXs. In this configuration, the MXs will send their cloud controller communications via their uplink IPs, but other traffic will be sent and received by the shared virtual IP address.

MX Data Center Routing

The MX acting as a VPN concentrator in the datacenter will be terminating remote subnets into the datacenter. In order for bi-directional communication to take place, the upstream network must have routes for the remote subnets that point back to the MX acting as the VPN concentrator.

 

If OSPF route advertisement is not being used, static routes directing traffic destined for remote VPN subnets to the MX VPN concentrator must be configured in the upstream routing infrastructure.

 

If OSPF route advertisement is enabled, upstream routers will learn routes to connected VPN subnets dynamically.

Failover Times

There are several important failover timeframes to be aware of:

 

Service

Failover Time

Failback Time

Auto VPN Tunnels

30-40 seconds

30-40 seconds

DC-DC Failover

20-30 seconds

20-30 seconds

Dynamic Path Selection

Up to 30 seconds

Up to 30 seconds

Warm Spare

30 seconds or less

30 seconds or less

WAN connectivity

300 seconds or less

15-30 seconds

Configuring OSPF Route Advertisement

MX Security Appliances acting in VPN concentrator mode support advertising routes to connected VPN subnets via OSPF. This functionality is not available on MX devices operating in NAT mode.

An MX VPN concentrator with OSPF route advertisement enabled will only advertise routes via OSPF; it will not learn OSPF routes.

 

When spoke sites are connected to the VPN concentrator, the routes to spoke sites are advertised using an LS Update message. These routes are advertised as type 2 external routes.

BGP and Auto VPN

BGP VPNs are utilized for Data Center Failover and load sharing. This is accomplished by placing VPN Concentrators at each Data Center. Each VPN Concentrator will utilize BGP with DC edge devices. BGP is utilized for its scalability and tuning capabilities.

 

More information about implementing BGP and its use cases can be found in our BGP documentation.

Auto VPN Technology Deep Dive

The MX Security Appliance makes use of several types of outbound communication. Configuration of the upstream firewall may be required to allow this communication.

Dashboard & Cloud

The MX Security Appliance is a cloud managed networking device. As such, it is important to ensure that the necessary firewall policies are in place to allow for monitoring and configuration via the Meraki dashboard. The relevant destination ports and IP addresses can be found under the Help > Firewall Info page in the dashboard.

VPN Registry

Meraki's Auto VPN technology leverages a cloud-based registry service to orchestrate VPN connectivity. In order for successful Auto VPN connections to establish, the upstream firewall must allow the VPN concentrator to communicate with the VPN registry service. The relevant destination ports and IP addresses may vary by region, and can be found under the Help > Firewall Info page in the dashboard.

The MX also performs periodic uplink health checks by reaching out to well-known Internet destinations using common protocols. The full behavior is outlined here. In order to allow for proper uplink monitoring, the following communications must also be allowed:

  • DNS test to canireachthe.net

  • Internet test to icmp.canireachthe.net

VPN Registry

In order to participate in Auto VPN an MX device must register with the Meraki VPN registry. The VPN registry is a cloud-based system that stores data needed to connect all MX devices into an orchestrated VPN system. The VPN registry is always on and always updating in the case of a connection failure. This means no manual intervention is needed in the case of reboots, new public IP addresses hardware failovers etc. The VPN registry stores the following information for each MX:

  • Subnets (for creating the VPN route table)

  • Uplink IP (public or private)

  • Public IP

The process for adding a new MX into an infrastructure is as follows:

  1. A new MX reports its uplink IP address(es) and shared subnets to the registry

  2. The information is propagated to the other MXs in the infrastructure

  3. The MX establishes the proper VPN tunnels

    1. The MX will try the registry-reported private uplink IP of the peer first

    2. If a connection to the private uplink IP of the peer fails, the MX will try the public uplink IP of its peer

 

3.png

Auto VPN Routing

The VPN Registry stores the relevant information including, local routes participating in VPN for a particular Meraki Auto VPN infrastructure.  In the case of a failure, additional VPN device, or hub change the system automatically reconverges without any end user interaction. By updating all VPN routes to all devices in the system Auto VPN acts like a routing protocol and converges the system to maintain stability.

High Availability

 

 

Key use case

Cost consideration

Failover time

HW Redundancy

Mitigate an MX HW failure using 2 devices on the same broadcast domain

Two devices are required but only a single license

Less than 30 seconds (for hardware failover, not necessarily VPN failover)

DC DC Failover

Mitigate any problem that could prevent a spoke from reaching its primary hub

Two devices and two licenses are required

Between 30 seconds and 5 minutes (SD-WAN allows for faster failover)

Hardware Redundancy in VPN Concentrator Mode

MX VPN Concentrator warm spare is used to provide high availability for a Meraki Auto VPN head-end appliance. Each concentrator has its own IP address to exchange management traffic with the Meraki Cloud. However, the concentrators also share a virtual IP address that is used for non-management communication.

 

4.png

 

MX VPN Concentrator - Warm Spare Setup

Before deploying MXs as one-arm VPN concentrators, place them into Passthrough or VPN Concentrator mode on the Addressing and VLANs page. In one-armed VPN concentrator mode, the units in the pair are connected to the network "only" via their respective ‘Internet’ ports. Make sure they are NOT connected directly via their LAN ports. Each MX must be within the same IP subnet and able to communicate with each other, as well as with the Meraki dashboard. Only VPN traffic is routed to the MX, and both ingress and egress packets are sent through the same interface.

 

MX VPN Concentrator - Virtual IP Assignment

The virtual IP address (vIP) is shared by both the primary and warm spare VPN concentrator. VPN traffic is sent to the vIP rather than the physical IP addresses of the individual concentrators. The virtual IP is configured by navigating to Security appliance > Appliance status when a warm spare is configured. It must be in the same subnet as the IP addresses of both appliances, and it must be unique. It cannot be the same as either the primary or warm spare's IP address.

The two concentrators share health information over the network via the VRRP protocol. Failure detection does not depend on connectivity to the Internet/Meraki dashboard.

 

MX VPN Concentrator - Failure Detection

In the event that the primary unit fails, the warm spare will assume the primary role until the original primary is back online. When the primary VPN concentrator is back online and the spare begins receiving VRRP heartbeats again, the warm spare concentrator will relinquish the active role back to the primary concentrator. The total time for failure detection, failover to the warm spare concentrator, and ability to start processing VPN packets is typically less than 30 seconds.

 

MX Warm Spare Alerting

There are a number of options available in the Meraki dashboard for email alerts to be sent when certain network or device events occur, such as when a warm spare transition occurs. This is a recommended configuration option and allows a network administrator to be informed in the event of a failover.

The event, “A warm spare failover occurs,” sends an email if the primary MX of a High Availability pair fails over to the spare, or vice-versa.

 

This alert and others, can be referenced in our article on Configuring Network Alerts in Dashboard.

 

If you are having difficulties getting warm spare to function as expected, please refer to our MX Warm Spare - High Availability Pair document.

 

HW Redundancy in NAT mode

MX NAT Mode – Warm Spare

MX NAT Mode Warm Spare is used to provide redundancy for internet connectivity and appliance services when an MX Security Appliance is being used as a NAT gateway.

 

MX NAT Mode - Warm Spare Setup

In NAT mode, the units in the HA pair are connected to the ISP or ISPs via their respective Internet ports, and the internal networks are connected via the LAN ports.

 

WAN configuration: Each appliance must have its own IP address to exchange management traffic with the Meraki cloud. If the primary appliance is using a secondary uplink, the secondary uplink should also be in place on the warm spare. A shared virtual IP, while not required, will significantly reduce the impact of a failover on clients whose traffic is passing through the appliance. Virtual IPs can be configured for both uplinks.

 

LAN configuration: LAN IP addresses are configured based on the Appliance IPs in any configured VLANs. No virtual IPs are required on the LAN.

 

Additional warm spare configuration details can be found in our article, MX Warm Spare - High Availability Pair.

 

MX NAT Mode - Virtual IP Assignment

Virtual IP addresses (vPs) are shared by both the primary and warm spare appliance. Inbound and outbound traffic uses this address to maintain the same IP address during a failover to reduce disruption. The virtual IPs are configured on the Security Appliance > Monitor > Appliance status page. If two uplinks are configured, a vIP can be configured for each uplink. Each vIP must be in the same subnet as the IP addresses of the appliance uplink it is configured for, and it must be unique. It cannot be the same as either the primary or warm spare's IP address.

 

MX NAT Mode - Failure Detection

There are two failure detection methods for NAT mode warm spare. Failure detection does not depend on connectivity to the Internet / Meraki dashboard.

WAN Failover: WAN monitoring is performed using the same internet connectivity tests that are used for uplink failover. If the primary appliance does not have a valid Internet connection based on these tests, it will stop sending VRRP heartbeats which will result in a failover. When uplink connectivity on the original primary appliance is restored and the warm spare begins receiving VRRP heartbeats again, it will relinquish the active role back to the primary appliance.

LAN Failover: The two appliances share health information over the network via the VRRP protocol. These VRRP heartbeats occur at layer 2 and are performed on all configured VLANs. If no advertisements reach the spare on any VLAN, it will trigger a failover. When the warm spare begins receiving VRRP heartbeats again, it will relinquish the active role back to the primary appliance.

 

MX NAT Mode – DHCP Synchronisation

The MXs in a NAT mode high availability pair exchange DHCP state information over the LAN. This prevents a DHCP IP address from being handed out to a client after a failover if it has already been assigned to another client prior to the failover.

 

DC-DC Failover - Hub/Data Center Redundancy (Disaster Recovery)

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

 

5.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 or VPN Mesh topology

  • Split or full tunnel configuration

 

Operation and Failover

Deploying one or more MXs to act as VPN concentrators in additional data centers provides greater redundancy for critical network services. In a dual- or multi-datacenter configuration, identical subnets are advertised from each datacenter with a VPN concentrator mode MX.

 

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 unique to a particular hub, traffic will be routed directly to that hub. For subnets that are advertised from multiple hubs, spoke sites will send traffic to the highest priority hub that is reachable.

 

When an MX Security Appliance is configured to connect to multiple VPN concentrators advertising the same subnets, the routes to those subnets become tracked. Hello messages are periodically sent across the tunnels from the remote site to the VPN hubs to monitor connectivity. If the tunnel to the highest priority hub goes down, the route is removed from the route table and traffic is routed to the next highest priority hub that is reachable. This route failover operation only applies when identical routes are advertised from multiple Auto VPN hubs.

 

Concentrator Priority

When multiple VPN hubs are configured for an organization, the concentrator priority can be configured for the organization. This concentrator priority setting determines the order in which VPN mesh peers will prefer to connect to subnets advertised by multiple VPN concentrators.

This setting does not apply to remote sites configured as VPN spokes.

 

Other Datacenter Considerations

When implementing an DC-DC architecture, a warm spare concentrator configuration (see warm spare section above) and OSPF route advertisement should always be taken into consideration for MXs acting as VPN concentrators in a datacenter. Additionally, route flow logic should be considered for all applications in the deployment environment to ensure availability requirements are met. To assist with better understanding DC-initiated flows, please refer below.

 

Supported VPN Architectures

VPN Topologies

There are several options available for the structure of the VPN deployment.

Split Tunnel

In this configuration, branches will only send traffic across the VPN if it is destined for a specific subnet that is being advertised by another MX in the same dashboard organization. The remaining traffic will be checked against other available routes, such as static LAN routes and third-party VPN routes, and if not matched will be NATed and sent out from the branch MX unencrypted.

 

6.png

Full Tunnel  

In full tunnel mode all traffic that the branch or remote office does not have another route to is sent to a VPN hub.

 

7.png

Hub and Spoke

In a hub and spoke configuration, the MX security appliances at the branches and remote offices connect directly to specific MX appliances and will not form tunnels to other MX or Z1 devices in the organization. Communication between branch sites or remote offices is available through the configured VPN hubs. This is the recommended VPN topology for most SD-WAN deployments.

  • Hub and Spoke - 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 would be 12 + 1200 = 1212

 

Standard Hub & Spoke

 

8.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. It is strongly recommended that this model is the 1st, 2nd and 3rd option when designing a network. Only if the deployment has an exceptionally strong requirement should one of the following hub and spoke derivatives be considered.

VPN Mesh

It is also possible to use a VPN mesh configuration in an SD-WAN deployment.

 

In a mesh configuration, an MX appliance at the branch or remote office is configured to connect directly to any other MXs in the organization that are also in mesh mode, as well as any spoke MXs that are configured to use it as a hub.

  • Full Mesh - 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 196 tunnels from  the number of VPN peers for a single MX (49) multiplied by the number of VPN tunnels between each peer (4), in this case, we would need 50 MX100s as a minimum.

 

Inline Hub, Hub & Spoke

 

9.png

 

How it works:

Mostly the same as standard hub and spoke, with the exception that the hub is inline (i.e. in NAT mode) for the traffic flows egressing to the Internet from the MPLS/private network.  This works by leveraging the ‘form VPN on LAN’ functionality, in which the VPN tunnel from either RS-A & RS-B with ‘form’ on the LAN interface of the hub MX as opposed to ‘looping back’ over the WAN interface.

 

When should it be used?

This is used when the customer wants to leverage the advanced security features of the MX but does not have the budget to stretch to an additional dedicated (non-Auto VPN) MX perimeter device.  As such, this model should only come up in price sensitive deals, our preference should be to solve this problem commercially as opposed to technically, as it makes technical and logical sense to segment the use functions of security and VPN termination from one another.  However, this model can also be used in DMZ deployments too, in which the customer wants to route VPN traffic flows via alternative interfaces (than the WAN ports) directly from the MX.

 

Regional Hub & Spoke

 

10.png

 

How it works:

Again, this is exactly the same from a configuration perspective as a standard hub and spoke, however it allows for the introduction of regionalization for customers with interstate and/or international scale and range. The remote sites have a regional hub configured and a specific (multiple potentially) data center hub too. This allows for both greater scale and regional breakout.

This deployment model is extremely useful when voice traffic is in play (e.g. no need to go through Germany to make a local phone call in France)

 

When should it be used?

There are multiple reasons that could direct you toward a regional design, the most likely is to help with tunnel count scaling, as this approach limits the number of tunnels on hub MXs.  Also, if allows for lower capacity regional hub MXs to be specified. The second reason is likely due to process, either company or due to the geography of the customer; as customers have traditionally geographically segmented their businesses, and hence networks. As there is typically little value in facilitating direct communication between a remote site in the Americas to a hub site in east Asia (without a specific business case), additional such connectivity is typically costly. This approach allows customers to duplicate that regionalisation with the Meraki Auto VPN.

 

Hierarchical Hub & Spoke

 

11.png

 

How it works:

This is broadly similar to the standard hub and spoke with the exception that, with assistance from Meraki support, the customer can selectively break various tunnel connections. This results in separate virtual groups within the Auto VPN domain.

 

When should it be used?

Almost never. However, edge cases do exist in which customers essential operate as managed service providers for their customers and require some form of logical segmentation of the various elements of their business (to extend the analogy, their customers).  This is sometimes an issue in ISO27001 compliant customers with poorly (from our perspective) information security management systems (ISMS) boundaries. This is an emergency solution and it is typically better to avoid such designs than it is to implement the above. As such, it is ONLY included for completeness.

China Auto VPN

With regulatory constraints imposed by the Chinese government, specific architecture requirements are needed to deploy and interconnect the Auto VPN domain within China to the rest of the world.

Secure VPN technology provides the most cost-effective connectivity under most circumstances. Chinese regulations have placed restrictions affecting VPN technologies across international borders. For enterprises to achieve cross border connections, there are two options.

 

  1. The enterprise can directly lease international dedicated lines from the 3 Chinese telecom carriers (China Telecom, China Mobile, China Unicom) in China.

  2. Additionally, the enterprise can directly delegate a foreign telecom carrier with a presence in China to rent the international dedicated line (including VPN) from the 3 Chinese telecom carriers, and connect the corporate private network and equipment.

Note: The above cross-border connection methods must be used only for internal data exchange and office use. (Current as of 3 February 2018, subject to further regulatory developments.)

 

All devices located within mainland China will connect to Meraki China servers also located within China. Currently, only enterprise licensing is available for MX devices located within China.

China Auto VPN Architecture

 

12.png

 

In the above diagram, we are utilizing Meraki Auto VPN to connect the enterprise sites inside China. The above diagram also demonstrates the Chinese government approved dedicated circuits connecting the Chinese parts of the enterprise to the rest of the global enterprise. Dynamic routing such as BGP or OSPF can be utilized to exchange routing information between the domains.

Meraki SD-WAN

All Cisco Meraki security appliances are equipped with SD-WAN capabilities that enable administrators to maximize network resiliency and bandwidth efficiency. This guide introduces the various components of Meraki SD-WAN and the possible ways in which to deploy a Meraki AutoVPN architecture to leverage SD-WAN functionality, with a focus on the recommended deployment architecture.

What is SD-WAN?

Software-defined WAN (SD-WAN) is a suite of features designed to allow the network to dynamically adjust to changing WAN conditions without the need for manual intervention by the network administrator. By providing granular control over how certain traffic types respond to changes in WAN availability and performance, SD-WAN can ensure optimal performance for critical applications and help to avoid disruptions of highly performance-sensitive traffic, such as VoIP. Additionally, SD-WAN can be a scalable and often much cheaper alternative to traditional WAN circuits like MPLS lines.

Key Concepts

Before deploying SD-WAN, it is important to understand several key concepts.

Concentrator Mode

All MXs can be configured in either NAT or VPN concentrator mode. There are important considerations for both modes. For more detailed information on concentrator modes, click here.

One-Armed Concentrator

In this mode, the MX is configured with a single Ethernet connection to the upstream network. All traffic will be sent and received on this interface. This is the recommended configuration for MX appliances serving as VPN termination points into the datacenter.

NAT Mode Concentrator 

It is also possible to take advantage of the SD-WAN feature set with an MX configured in NAT mode acting as the VPN termination point in the datacenter. 

VPN Topology

There are several topology options available for VPN deployment.

Split Tunnel

In this configuration, branches will only send traffic across the VPN if it is destined for a specific subnet that is being advertised by another MX in the same Dashboard organization. The remaining traffic will be checked against other available routes, such as static LAN routes and third-party VPN routes, and if not matched will be NATed to MX WAN IP address and sent out of WAN interface of the branch MX, unencrypted.

Full Tunnel 

In full tunnel mode all traffic that the branch or remote office does not have another route to is sent to a VPN hub.

Hub and Spoke

In a hub and spoke configuration, the MX security appliances at the branches and remote offices connect directly to specific MX appliances and will not form tunnels to other MX or Z1 devices in the organization. Communication between branch sites or remote offices is available through the configured VPN hubs. This is the recommended VPN topology for most SD-WAN deployments.

VPN Mesh

It is also possible to use a VPN "mesh" configuration in an SD-WAN deployment.

 

In a mesh configuration, an MX appliance at the branch or remote office is configured to connect directly to any other MXs in the organization that are also in mesh mode, as well as any spoke MXs that are configured to use it as a hub.

Datacenter Redundancy (DC-DC Failover)

Deploying one or more MXs to act as VPN concentrators in additional datacenters provides greater redundancy for critical network services. In a dual- or multi-datacenter configuration, identical subnets can be advertised from each datacenter with a VPN concentrator mode MX. 

 

In a DC-DC failover design, a spoke site will form VPN tunnels to all VPN hubs that are configured for that site. For subnets that are unique to a particular hub, traffic will be routed directly to that hub so long as tunnels between the spoke and hub are established successfully. For subnets that are advertised from multiple hubs, spokes sites will send traffic to the highest priority hub that is reachable.

Warm Spare (High Availability) for VPN concentrators

When configured for high availability (HA), one MX serves as the master unit and the other MX operates as a spare. All traffic flows through the master MX, while the spare operates as an added layer of redundancy in the event of failure.

 

Failover between MXs in an HA configuration leverages VRRP heartbeat packets. These heartbeat packets are sent from the Primary MX to the Secondary MX out the singular uplink in order to indicate that the Primary is online and functioning properly. As long as the Secondary is receiving these heartbeat packets, it functions in the spare state. If the Secondary stops receiving these heartbeat packets, it will assume that the Primary is offline and will transition into the master state. In order to receive these heartbeats, both VPN concentrator MXs should have uplinks on the same subnet within the datacenter.

 

Only one MX license is required for the HA pair, as only a single device is in full operation at any given time.

Connection Monitor

Connection monitor is an uplink monitoring engine built into every MX Security Appliance. The mechanics of the engine are described in this article

SD-WAN Technologies

The Meraki SD-WAN implementation is comprised of several key features, built atop our AutoVPN technology.

Prior to the SD-WAN release, Auto VPN tunnels would only form only over a single interface. With the SD-WAN release, it is now possible to form concurrent AutoVPN tunnels over both Internet interfaces of the MX.

 

The ability to form and send traffic over VPN tunnels on both interfaces significantly increases the flexibility of traffic path and routing decisions in AutoVPN deployments. In addition to providing administrators with the ability to load balance VPN traffic across multiple links, it also allows them to leverage the additional path to the datacenter in a variety of ways using the built-in Policy-based Routing and dynamic path selection capabilities of the MX.

Policy-Based Routing (PbR)

Policy-based Routing allows an administrator to configure preferred VPN paths for different traffic flows based on their source and destination IPs and ports.

Dynamic Path Selection

Dynamic path selection allows a network administrator to configure performance criteria for different types of traffic. Path decisions are then made on a per-flow basis based on which of the available VPN tunnels meet these criteria, determined by using packet loss, latency, and jitter metrics that are automatically gathered by the MX.

Performance Probes

Performance-based decisions rely on an accurate and consistent stream of information about current WAN conditions in order to ensure that the optimal path is used for each traffic flow. This information is collected via the use of performance probes.

 

The performance probe is a small payload (approximately 100 bytes) of UDP data sent over all established VPN tunnels every 1 second. MX appliances track the rate of successful responses and the time that elapses before receiving a response. This data allows the MX to determine the packet loss, latency, and jitter over each VPN tunnel in order to make the necessary performance-based decisions.

High-Level Architecture

This guide focuses on the most common deployment scenario but is not intended to preclude the use of alternative topologies. The recommended SD-WAN architecture for most deployments is as follows:

 

  • MX at the datacenter deployed as a one-armed concentrator.
  • Warm spare/High Availability at the datacenter.
  • OSPF route advertisement for scalable upstream connectivity to connected VPN subnets.
  • Datacenter redundancy
  • Split tunnel VPN from the branches and remote offices
  • Dual WAN uplinks at all branches and remote offices
SD-WAN Objectives

This guide focuses on two key SD-WAN objectives:

  • Redundancy for critical network services

  • Dynamic selection of the optimal path for VoIP traffic

Example Topology

The following topology demonstrates a fully featured SD-WAN deployment, including DC-DC failover for the redundancy.
 

iwan-topo.png

 

Both tunnels from a branch or remote office location terminate at the single interface used on the one-armed concentrator.

High Level Traffic Flow

The decisions for path selection for VPN traffic are made based on a few key decision points:

  • Whether VPN tunnels can be established on both interfaces
  • Whether dynamic path selection rules are configured
  • Whether Policy-based Routing rules are configured
  • Whether load balancing is enabled

If tunnels are established on both interfaces, dynamic path selection is used to determine which paths meet the minimum performance criteria for particular traffic flow. Those paths are then evaluated against the policy-based routing and load balancing configurations.

 

For a more detailed description of traffic flow with an SD-WAN configuration, please see the appendix.

Failover Times

There are several important failover timeframes to be aware of:

 

Service Failover Time Failback Time
AutoVPN Tunnels 30-40 seconds 30-40 seconds
DC-DC Failover 20-30 seconds 20-30 seconds
Dynamic path selection Up to 30 seconds Up to 30 seconds
Warm Spare 30 seconds or less 30 seconds or less
WAN connectivity 300 seconds or less 15-30 seconds

Datacenter Deployment

This section will outline the configuration and implementation of the SD-WAN architecture in the datacenter.

Deploying a One-Armed Concentrator
Example Topology

A one-armed concentrator is the recommended datacenter design choice for an SD-WAN deployment. The following diagram shows an example of a datacenter topology with a one-armed concentrator:

Screen Shot 2015-12-11 at 1.37.53 PM.png

Dashboard Configuration

The Cisco Meraki Dashboard configuration can be done either before or after bringing the unit online.

 

  1. Begin by configuring the MX to operate in VPN Concentrator mode. This setting is found on the Security & SD-WAN > Configure > Addressing & VLANs page. The MX will be set to operate in Routed mode by default.
     

new addressing & vlans page - passthrough mode.PNG

 

  1. Next, configure the Site-to-Site VPN parameters. This setting is found on the Security & SD-WAN > Configure > Site-to-site VPN page.

  2. Begin by setting the type to "Hub (Mesh)."
  3. Configure the local networks that are accessible upstream of this VPN concentrator.
    1. For the Name, specify a descriptive title for the subnet.

    2. For the Subnet, specify the subnet to be advertised to other AutoVPN peers using CIDR notation

  4. NAT traversal can be set to either automatic or manual. See below for more details on these two options.

  5. An example screenshot is included below:

       hub mesh local networks new screenshot.PNG

NAT Traversal

Whether to use Manual or Automatic NAT traversal is an important consideration for the VPN concentrator.

 

Use manual NAT traversal when:

  • There is an unfriendly NAT upstream
  • Stringent firewall rules are in place to control what traffic is allowed to ingress or egress the datacenter
  • It is important to know which port remote sites will use to communicate with the VPN concentrator

 

If manual NAT traversal is selected, it is highly recommended that the VPN concentrator be assigned a static IP address. Manual NAT traversal is intended for configurations when all traffic for a specified port can be forward to the VPN concentrator.

 

Use automatic NAT traversal when:

  • None of the conditions listed above that would require manual NAT traversal exist

 

If automatic NAT traversal is selected, the MX will automatically select a high numbered UDP port to source AutoVPN traffic from. The VPN concentrator will reach out to the remote sites using this port, creating a stateful flow mapping in the upstream firewall that will also allow traffic initiated from the remote side through to the VPN concentrator without the need for a separate inbound firewall rule.

Adding Warm Spare

This section outlines the steps required to configure and implement warm spare (HA) for an MX Security Appliance operating in VPN concentrator mode.

Warm Spare Topology

The following is an example of a topology that leverages an HA configuration for VPN concentrators:

Screen Shot 2015-12-11 at 1.37.30 PM.png

Behaviour

When configured for high availability (HA), one MX is active, serving as the master, and the other MX operates in a passive, standby capacity. The VRRP protocol is leveraged to achieve failover. Please see here for more information.

Dashboard Configuration

High availability on MX Security appliances requires a second MX of the same model. The HA implementation is active/passive and will require the second MX also be connected and online for proper functionality. For more detailed information about MX warm spare, please see here.

 

High availability (also known as a warm spare) can be configured from Security & SD-WAN > Monitor > Appliance status. Begin by clicking "Configure warm spare" and then "Enabled". Next, enter the serial number of the warm spare MX or select one from the drop-down menu. Finally, select whether to use MX uplink IPs or virtual uplink IPs.

 

Uplink IPs

Use Uplink IPs is selected by default for new network setups. In order to properly communicate in HA, VPN concentrator MXs must be set to use the virtual IP (VIP).

 

Virtual IP (VIP)

The virtual uplink IPs option uses an additional IP address that is shared by the HA MXs. In this configuration, the MXs will send their cloud controller communications via their uplink IPs, but other traffic will be sent and received by the shared virtual IP address. 

 

new warm spare configuration.PNG

Configuring OSPF Route Advertisement

MX Security Appliances acting in VPN concentrator mode support advertising routes to connected VPN subnets via OSPF. This functionality is not available on MX devices operating in NAT mode.

Behaviour

An MX VPN concentrator with OSPF route advertisement enabled will only advertise routes via OSPF; it will not learn OSPF routes.

 

When spoke sites are connected to the VPN concentrator, the routes to spokes sites are advertised using an LS Update message. These routes are advertised as type 2 external routes.

Dashboard Configuration

In order to configure OSPF route advertisement, navigate to the Security & SD-WAN > Configure > Site-to-Site VPN page. From this page:

  • Set Advertise remote routes to Enabled
  • Configure the Router ID
  • Configure the Area ID
  • Adjust the Cost, if desired
  • Adjust the Hello timer, if needed
  • Adjust the Dead timer, if needed
  • Enable and configure MD5 authentication, if needed

 

iwan-3.PNG

 

Other Datacenter Configuration
MX IP Assignment

In the datacenter, an MX Security Appliance can operate using a static IP address or an address from DHCP. MX appliances will attempt to pull DHCP addresses by default. It is highly recommended to assign static IP addresses to VPN concentrators.

 

Static IP assignment can be configured via the device local status page.

The local status page can also be used to configure VLAN tagging on the uplink of the MX. It is important to take note of the following scenarios:

  • If the upstream port is configured as an access port, VLAN tagging should not be enabled.
  • If the port upstream is configured as a trunk port and the MX should communicate on the native or default VLAN, VLAN tagging should be left as disabled.
  • If the port upstream is configured as a trunk and the MX should communicate on a VLAN other than the native or default VLAN, VLAN tagging should be configured for the appropriate VLAN ID.
Upstream Considerations

This section discusses configuration considerations for other components of the datacenter network.

Routing

The MX acting as a VPN concentrator in the datacenter will be terminating remote subnets into the datacenter. In order for bi-directional communication to take place, the upstream network must have routes for the remote subnets that point back to the MX acting as the VPN concentrator.

 

If OSPF route advertisement is not being used, static routes directing traffic destined for remote VPN subnets to the MX VPN concentrator must be configured in the upstream routing infrastructure.

If OSPF route advertisement is enabled, upstream routers will learn routes to connected VPN subnets dynamically.

Firewall Considerations

The MX Security Appliance makes use of several types of outbound communication. Configuration of the upstream firewall may be required to allow this communication.

 

Dashboard & Cloud

The MX Security Appliance is a cloud managed networking device. As such, it is important to ensure that the necessary firewall policies are in place to allow for monitoring and configuration via the Cisco Meraki Dashboard. The relevant destination ports and IP addresses can be found under the Help > Firewall Info page in the Dashboard.

 

VPN Registry

Cisco Meraki's AutoVPN technology leverages a cloud-based registry service to orchestrate VPN connectivity. In order for successful AutoVPN connections to establish, the upstream firewall mush to allow the VPN concentrator to communicate with the VPN registry service. The relevant destination ports and IP addresses can be found under the Help > Firewall Info page in the Dashboard.

 

Uplink Health Monitoring

The MX also performs periodic uplink health checks by reaching out to well-known Internet destinations using common protocols. The full behavior is outlined here. In order to allow for proper uplink monitoring, the following communications must also be allowed:

  • ICMP to 8.8.8.8 (Google's public DNS service)
  • HTTP port 80
  • DNS to the MX's configured DNS server(s)
Datacenter Redundancy (DC-DC Failover)

Cisco Meraki MX Security Appliances support datacenter to datacenter redundancy via our DC-DC failover implementation. The same steps used above can also be used to deploy one-armed concentrators at one or more additional datacenters. For further information about VPN failover behavior and route prioritization, please review this article.

Branch Deployment

This section will outline the configuration and implementation of the SD-WAN architecture in the branch.

Configuring AutoVPN at the Branch
Prerequisites

Before configuring and building AutoVPN tunnels, there are several configuration steps that should be reviewed.

WAN Interface Configuration

While automatic uplink configuration via DHCP is sufficient in many cases, some deployments may require manual uplink configuration of the MX security appliance at the branch. The procedure for assigning static IP addresses to WAN interfaces can be found here.

 

Some MX models have only one dedicated Internet port and require a LAN port be configured to act as a secondary Internet port via the device local status page if two uplink connections are required. This configuration change can be performed on the device local status page on the Configure tab.

Subnet Configuration

AutoVPN allows for the addition and removal of subnets from the AutoVPN topology with a few clicks. The appropriate subnets should be configured before proceeding with the site-to-site VPN configuration.

 

Begin by configuring the subnets to be used at the branch from the Security & SD-WAN > Configure > Addressing & VLANs page.

 

new addressing & vlans page - routing.PNG

 

By default, a single subnet is generated for the MX network, with VLANs disabled. In this configuration, a single subnet and any necessary static routes can be configured without the need to manage VLAN configurations.

 

If multiple subnets are required or VLANs are desired, the Use VLANs box should be ticked. This allows for the creation of multiple VLANs, as well as allowing for VLAN settings to be configured on a per-port basis.

Configuring AutoVPN

Once the subnets have been configured, Cisco Meraki's AutoVPN can be configured via the Security & SD-WAN > Configure > Site-to-site VPN page in Dashboard.

Configuring Hub and Spoke VPN

From the Security & SD-WAN > Configure > Site-to-Site VPN page: 

  • Select Spoke for the type
  • Under Hubs, select Add a hub
  • To connect to additional hubs, select Add a hub and select the VPN concentrator configured in the datacenter deployment steps.
  • Additional hubs can be added using the Add a hub link

 

s2s vpn new page spoke.PNG

Hub Priorities

Hub priority is based on the position of individual hubs in the list from top to bottom. The first hub has the highest priority, the second hub the second highest priority, and so on. Traffic destined for subnets advertised from multiple hubs will be sent to the highest priority hub that a) is advertising the subnet and b) currently has a working VPN connection with the spoke. Traffic to subnets advertised by only one hub is sent directly to that hub.

Configuring Allowed Networks

To allow a particular subnet to communicate across the VPN, locate the local networks section in the Site-to-site VPN page. The list of subnets is populated from the configured local subnets and static routes in the Addressing & VLANs page, as well as the Client VPN subnet if one is configured.

 

To allow a subnet to use the VPN, set the Use VPN drop-down to yes for that subnet.

NAT Traversal

Please refer to the datacenter deployment steps here for more information on NAT Traversal options.

Adding Performance and Policy Rules

Rules for routing of VPN traffic can be configured on the Security & SD-WAN > Configure > SD-WAN & traffic shaping page in the dashboard.

 

Settings to configure Policy-based Routing (PbR) and dynamic path selection are found under the SD-WAN policies heading.

sd-wan & traffic shaping page - new.PNG

 

The following sections contain guidance on configuring several example rules.

Best for VoIP

One of the most common uses of traffic optimization is for VoIP traffic, which is very sensitive to loss, latency, and jitter. The Cisco Meraki MX has a default performance rule in place for VoIP traffic, Best for VoIP.

 

To configure this rule, click Add a preference under the VPN traffic section.

new vpn performance class rules.PNG 

 

In the Uplink selection policy dialogue, select Custom expressions, then UDP as the protocol and enter the appropriate source and destination IP address and ports for the traffic filter. Select the Best for VoIP policy for the preferred uplink, then save the changes.

 

This rule will evaluate the loss, latency, and jitter of established VPN tunnels and send flows matching the configured traffic filter over the optimal VPN path for VoIP traffic, based on the current network conditions.

Load Balance Video

Video traffic is increasingly prevalent as technologies like Cisco video conferencing continue to be adopted and integrated into everyday business operations. This branch site will leverage another pre-built performance rule for video streaming and will load balance traffic across both Internet uplinks to take full advantage of available bandwidth.

 

To configure this, click Add a preference under the VPN traffic section.

Screen Shot 2015-12-03 at 8.09.44 PM.png

 

In the Uplink selection policy dialogue, select UDP as the protocol and enter the appropriate source and destination IP address and ports for the traffic filter. For the policy, select Load balance for the Preferred uplink. Next, set the policy to only apply on uplinks that meet the Video streaming performance category. Finally, save the changes.

 

This policy monitors loss, latency, and jitter over VPN tunnels and will load balance flows matching the traffic filter across VPN tunnels that match the video streaming performance criteria.

PbR with Performance Failover for Web traffic

Web traffic is another common type of traffic that a network administrator may wish to optimize or control. This branch will leverage a PbR rule to send web traffic over VPN tunnels formed on the WAN 1 interface, but only if that matches a custom-configured performance class.

 

To configure this, select Create a new custom performance class under the Custom performance classes section.

new custom performance classes.PNG

 

In the Name field, enter a descriptive title for this custom class. Specify the maximum latency, jitter, and packet loss allowed for this traffic filter. This branch will use a "Web" custom rule based on a maximum loss threshold. Then, save the changes.

 

Next, click Add a preference" under the VPN traffic section.

web vpn custom class new.PNG

 

In the Uplink selection policy dialogue, select TCP as the protocol and enter in the appropriate source and destination IP address and ports for the traffic filter. For the policy, select WAN1 for the Preferred uplink. Next, configure the rule such that web traffic will Failover if there is Poor performance. For the Performance class, select "Web". Then, save the changes.

 

This rule will evaluate the packet loss of established VPN tunnels and send flows matching the traffic filter out of the preferred uplink. If the loss, latency, or jitter thresholds in the "Web" performance rule are exceeded, traffic can fail over to tunnels on WAN2 (assuming they meet the configured performance criteria).

Layer 7 Classification
Best for VoIP

To configure this rule, click Add a preference under the VPN traffic section.

 

In the uplink selection policy dialogue, click Add+ to configure a new traffic filter. From the filter selection menu, click the VoIP & video conferencing category and then select the desired layer 7 rules. This example will use the SIP (Voice) rule.

 

Then, select the Best for VoIP performance class for the preferred uplink and save the changes. This rule will evaluate the loss, latency, and jitter of established VPN tunnels and send flows matching the configured traffic filter over the optimal VPN path for VoIP traffic, based on the current network conditions.

FAQ

Does the MX support unencrypted AutoVPN tunnels?

No, currently AutoVPN always uses AES-128 encryption for VPN tunnels.

If traffic is encrypted, what about QoS or DSCP tags?

Both QoS and DSCP tags are maintained within the encapsulated traffic and are copied over to the IPsec header.

Can a non-Meraki device be used as a VPN hub?

While it is possible to establish VPN connections between Meraki and non-Meraki devices using standard IPsec VPN, SD-WAN requires that all hub and spoke devices be Meraki MXs.

How does this inter-operate with IWAN using Cisco ISR routers?

Both products use similar, but distinct, underlying tunnelling technologies (DMVPN vs. AutoVPN). A typical hybrid solution may entail using ISR devices at larger sites and MX devices at smaller offices or branches. This will require dedicated IWAN concentration for ISR, as well as a separate SD-WAN head-end for MXs, at the datacenter.

Is dual active AutoVPN available over a 3G or 4G modem?

No, 3G or 4G modem cannot be used for this purpose. While the MX supports a range of 3G and 4G modem options, cellular uplinks are currently used only to ensure availability in the event of WAN failure and cannot be used for load balancing in conjunction with an active wired WAN connection or VPN failover scenarios.  

How does SD-WAN inter-operate with warm spare (HA) at the branch?

SD-WAN can be deployed on branch MX appliances configured in a warm spare capacity, however, only the master MX will build AutoVPN tunnels and route VPN traffic.

References

Please see the following references for supplemental information.

Auto VPN White Paper

For further information on how Cisco Meraki's AutoVPN technology functions, please see this article

SD-WAN page

For further information on SD-WAN availability, please see our SD-WAN page.

Appendix

Appendix 1: Detailed traffic flow for PbR and dynamic path selection
Complete Flowchart

The following flowchart breaks down the path selection logic of Meraki SD-WAN. This flowchart will be broken down in more detail in the subsequent sections.

Screen Shot 2015-12-11 at 12.35.54 PM.png

Decision Point 1: Can we establish Tunnels over both uplinks?

The very first evaluation point in SD-WAN traffic flow is whether the MX has active AutoVPN tunnels established over both interfaces.

Screen Shot 2015-12-11 at 12.20.34 PM (1).png

When VPN tunnels are not successfully established over both interfaces, traffic is forwarded over the uplink where VPN tunnels are successfully established.

Screen Shot 2015-12-11 at 12.21.07 PM (1).png

If we can establish tunnels on both interfaces, processing proceeds to the next decision point.

 

Decision Point 2: Are performance rules for dynamic path selection defined?

If we can establish tunnels on both uplinks, the MX appliance will then check to see if any dynamic path selection rules are defined.

 

If dynamic path selection rules are defined, we evaluate each tunnel to determine which satisfy those rules.

Screen Shot 2015-12-11 at 12.21.25 PM (1).png

If only one VPN path satisfies our performance requirements, traffic will be sent along that VPN path. The MX will not evaluate PbR rules if only one VPN path meets the performance rules for dynamic path selection.

Screen Shot 2015-12-11 at 12.21.38 PM (1).png

 

If there are multiple VPN paths that satisfy our dynamic path selection requirements or if there are no paths that satisfy the requirements, or if no dynamic path selection rules have been configured, PbR rules will be evaluated.

 

Screen Shot 2015-12-11 at 12.21.52 PM (1).png

After performance rules for dynamic path selection decisions are performed, the MX evaluates the next decision point.

Decision Point 3: Are PbR rules defined?

After checking dynamic path selection rules, the MX security appliance will evaluate PbR rules if multiple or no paths satisfied the performance requirements.

 

If a flow matches a configured PbR rule, then traffic will be sent using the configured path preference.

Screen Shot 2015-12-11 at 12.22.01 PM (1).png

If the flow does not match a configured PbR rule, then traffic logically progresses to the next decision point.

 

Decision Point 4: Is VPN load balancing configured?

After evaluating dynamic path selection and PbR rules, the MX Security appliance will evaluate whether VPN load balancing has been enabled.

Screen Shot 2015-12-11 at 12.22.07 PM (1).png

If VPN load balancing has not been enabled, traffic will be sent over a tunnel formed on the primary Internet interface. Which Internet interface is the primary can be configured from the Security & SD-WAN > Configure > SD-WAN & traffic shaping page in Dashboard.

Screen Shot 2015-12-11 at 12.22.20 PM (1).png

If load balancing is enabled, flows will be load balanced across tunnels formed over both uplinks.

Screen Shot 2015-12-11 at 12.22.29 PM (1).png

VPN load balancing uses the same load balancing methods as the MX's uplink load balancing. Flows are sent out in a round robin fashion with weighting based on the bandwidth specified for each uplink.

MX Templates Best Practices

As a network deployment grows to span multiple sites, managing individual devices can become highly cumbersome and unnecessary. To help alleviate these operating costs, the Meraki MX Security Appliance offers the use of templates to quickly roll out new site deployments and make changes in bulk.

This guide will outline how to create and use MX templates in the dashboard.

It should be noted that service providers or deployments that rely heavily on network management via API are encouraged to consider cloning networks instead of using templates, as the API options available for cloning currently provide more granular control than the API options available for templates.

Planning a Template Deployment for MX

Before rolling out a template deployment (or enabling templates on a production network), it may be helpful to plan the "units" that make up your deployments. This involves asking questions such as:

  • What are my sites? (e.g. retail location, school, branch office, etc.)

  • Are the MXs going to be in HA?

  • Do I need local overrides?

Template Networks

A "site" in network deployment terms is usually the same as a "network" in dashboard terms; each site gets their own dashboard network. As such, when planning multiple sites to be configured the same way, they will share a template network.

A template network is a network configuration that is shared by multiple sites/networks. Individual site networks can be bound to a template network, so changes to the template will trickle down to all bound sites. A new network can also be created based on a template, making it easy to spin-up new sites of the same type.

When planning a template deployment, you should have one template network for each type of site.

Configuration

The following sections walk through configuration and use of MX templates in the dashboard.

Creating a Template Network

As outlined above, a template network should be created for each type of site to be deployed.

To create a template network:

  1. In the dashboard, navigate to Organization > Monitor > Configuration templates

  2. Click Create a new template

  3. Select a descriptive name for your template. If this is a completely new template, select Create new and MX template.

    • If this template should be based on an existing network, select Copy settings from and an existing Security appliance network.

  4. Click Add:

 

MX Template.png

 

  1. If you would like to bind existing networks to this new template, select those networks as Target networks and click Bind. Otherwise, click Close.

Template VLAN Configuration
  1. In the dashboard, navigate to Security Appliance > Addressing & VLANs > Routing > Subnets

  2. Click on Use VLANs and then Add VLAN

  3. Select a descriptive name for your VLAN

  4. Choose whether the subnetting should be the same or unique for every network bound to this template.

    • If same is chosen, all the networks bound to the template will share the exact same subnet. This is not eligible for site-to-site VPNs.

    • If unique is chosen, each network bound to the template will get a unique subnet based on the configured options. The MX does not support local VLAN overrides on templates.

      • Subnets are assigned randomly to each network bound to the template.

 

VLAN.png

 

For more information about template IP range VLAN allocation, reference our article on Managing Networks with Configuration Templates.

Template Static Routes
  1. In the dashboard, navigate to Security Appliance > Addressing & VLANs > Routing > Static Routes

  2. Click on Add Static Route

  3. Select a descriptive name for your static route

  4. Specify the subnet that is reached via the static route

  5. Indicate the IP address of the device that connects the MX Security Appliance to this route

  6. Choose the condition that controls when this route will be used

 

Please note that only VLANs using the ‘same’ subnetting can be validated against for configuration templates. If the local VLAN subnetting is set to Unique, static routes cannot be configured on the template.

 

Template Firewall Rules

When configuring layer 3 firewall rules, CIDR notation, as well as the VLAN name, can be used. The VLAN name is used when the entire subnet needs to be specified whereas CIDR notation is used when more flexibility is needed to specify the subnets.

 

  1. Go to Security appliance > Configure > Firewall > Layer 3, click Add a rule

  2. Choose the policy, specify if the rule matched should be allowed or denied

  3. Select the protocol to match in outbound traffic

  4. Specify the IP address or range using CIDR notation to match the outbound traffic. Note that also the name of the VLAN can be chosen as well

  5. Choose the Src/dst port to match in outbound traffic

 

Screen Shot 2018-07-06 at 12.05.59 PM.png

Template SD-WAN Policies
  1. Go to Security appliance > Configure > Traffic shaping > Flow preferences, and click Add a preference

  2. In the Definition field click Add +.

  3. The Custom expressions field should appear first. In the text field, choose the protocol and then specify the Source address where 192.168.0.0/16 or ‘Default’ is your private subnet range. If it is only desired to shape one particular host, use the Host button to specify the host address. Click the Add + button again when finished.

  4. Choose the preferred uplink, failover method, and performance class then click Save changes.

 

Screen Shot 2018-07-06 at 12.18.46 PM.png

 

Screen Shot 2018-07-06 at 12.24.48 PM.png

Local Overrides

Once an MX Security Appliance network has been bound to a template, some options can still be configured normally through the dashboard. Any local configuration changes made directly on the MX network will override the template configuration.

In the example below, the bound MX was directly configured to have a custom Default VLAN. This change can be made in the template network, under Security Appliance > Configure > Addressing & VLANs:

 

Screen Shot 2018-07-06 at 12.57.08 PM.png

 

If a network is removed from a template, local overrides will automatically be lost as well as any template related configuration. The MX will automatically get the configuration from the network it is on.

 

Note: Auto VPN hubs should not be added to templates at all. It is not possible to configure an MX as a spoke with exit hub that is part of a template.

Note: Static Route and Unique local VLAN overrides are not supported at this moment for MX networks bound to templates.

 

DHCP Exceptions

The Meraki MX appliance provide a fully-featured DHCP service which can be enabled and configured on each VLAN individually. When bound to a template, local overrides can be made to the DHCP configurations under Security appliance > Configure > DHCP.

 

Screen Shot 2018-07-06 at 1.28.40 PM.png

 

Forwarding Rules Overrides

To override forwarding rules, navigate under Security appliance > Configure > Firewall > Forwarding rules overrides.
 

Screen Shot 2018-07-06 at 2.03.39 PM.png

Templates with MXs of Different Port Counts

Port numbering can differ between MX models, which can cause confusion when assigning a configuration to a specific port number in a template. For example, a configuration on LAN 2 in a template doesn't affect any ports on an MX65.

This table outlines template port numbers and their corresponding physical port on some MX models (red fields indicate ports used for secondary WAN connections):

  Model Z1 Z3 MX60 MX64/W MX65/W MX67/C/W MX68/W/CW MX70 MX80 MX84 MX90 MX100 MX400
  #WAN_Ports 1 1 1 1 2 1 2 2 1 2 1 1 2
  #LAN_Ports 4 5 4 4 10 4 10 4 4 8 8 8 2(+)*
  #Fiber_Ports                   2 2 2  
    Physical Ports
  WAN1 Internet   Internet Internet Internet1 Internet Internet1 Internet1 Internet Internet1 Internet Internet Internet1
  WAN2         Internet2   Internet2 Internet2   Internet2     Internet2

Dashboard Label

LAN 2 1 1 1 1   2     2   2 2  
LAN 3 2 2 2 2 3 3 3 1 3 3 3 3 1
LAN 4 3 3 3 3 4 4 4 2 4 4 4 4 2
LAN 5 4 4 4 4 5 5 5 3 5 5 5 5  
LAN 6   5(PoE)     6   6 4   6 6 6  
LAN 7         7   7     7 7 7  
LAN 8         8   8     8 8 8  
LAN 9         9   9     9 9 9  
LAN 10         10   10     10 8(SFP) 10(SFP)  
LAN 11         11(PoE+)   11(PoE+)     11(SFP) 9(SFP) 11(SFP)  
LAN 12         12(PoE+)   12(PoE+)     12(SFP)      

* (+) : Model is capable of being modified to include additional LAN ports by installing interface modules

You can toggle the LAN2 port between LAN and Internet, through Uplink configuration under the Local status tab on the Local Status Page.

Performing MX Templates Firmware Upgrades

Firmware upgrades scheduled on the template will automatically be applied on the child networks’ network local timezone.

 

As a best practice, make sure that each MX has the correct local time zone configuration under Security Appliance > Monitor > Appliance Status.

 

Screen Shot 2018-07-06 at 1.10.17 PM.png

 

MX Replacement Walkthrough

Below are instructions for how to copy configurations from a failed MX bound to a template.

  1. On the Organization > Configure > Inventory page, claim the new MX and then add the new MX to the existing network.

  2. Navigate to the network that has the faulty MX and remove it under Security Appliance > Monitor > Appliance Status > Remove appliance from network

  3. Add the replacement MX to the same network by navigating to Network-wide > Configure > Add devices

  4. Select the network and click on Add devices.

 

For more information on replacing an MX, refer to our MX Cold Swap article.

 

Last modified

Tags

Classifications

This page has no classifications.

Explore the Product

Click to Learn More

Article ID

ID: 7127

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