MX Routing Behavior

Directly Connected

Directly connected routes are subnets defined in the Security & SD-WAN > Configure > Addressing & VLANs page of Dashboard. This is true of configurations leveraging a number of VLANs defined on an MX, or those that utilize a single subnet configuration with VLANs disabled.

 

Static routes are not directly connected.

Client VPN 

The client VPN subnet is configured under the Security & SD-WAN > Configure > Client VPN page of Dashboard. There is only ever a single client VPN subnet on an individual MX network.

 

While client VPN utilizes the IPsec protocol to form a secure tunnel with the end device, the client VPN subnet is treated differently from routes to non-Meraki VPN peers.

Static Routes

Static routes are configured on the Security & SD-WAN > Configure > Addressing & VLANs page of Dashboard. Configuration of static routes is only possible while the MX is operating in Routed mode.

Static routes are used to communicate with subnets or VLANs that are not defined or "owned" by the MX, but are reachable through another layer 3 device on the network. Static routes require a next hop IP address be specified within the scope of a configured VLAN or subnet to be able to successfully route traffic to another layer 3 device.

Static routes are used to define subnets accessible through the LAN of the MX.

Auto VPN

Cisco Meraki's Auto VPN can be configured on the Security & SD-WAN > Configure > Site-to-site VPN page of Dashboard. Auto VPN is a layer 3, IPsec-based site-to-site VPN. The mechanics are outlined in this white paper.

 

An MX Security Appliance configured to participate in an Auto VPN topology will automatically create routes for subnets included in the Auto VPN topology.

Non-Meraki VPN Peers (Other IPsec)

Non-Meraki VPN peers are configured on the Security & SD-WAN > Configure > Site-to-site VPN page of Dashboard. These VPN peers are connected to using IPsec. If an MX is configured to establish a VPN with a non-Meraki VPN peer, the MX will also have routes to the private subnets defined for that VPN peer. If a full tunnel is required, both peers must configure a private subnet of 0.0.0.0/0 as its private subnet for the IPsec SAs to be created successfully.

NAT

The MX Security Appliance can be configured to operate in Routed mode, from the Security & SD-WAN > Configure > Addressing & VLANs page of Dashboard. When in Routed mode, the MX can be configured with multiple LAN subnets and static routes. If a route for a particular subnet does not exist on the MX then in this mode, the traffic is NATed and sent out across an Ethernet connection into one of the Internet interfaces, or out a cellular connection.

Overlapping Routes

Route priority dictates how traffic is routed when multiple routes exist to the same subnet. However, overlapping routes that are not identical are also present in many deployments. In this case, the most specific route will be used.

Static Route Tracking

Static routes can be configured with three different availability settings:

• Always active
• Active while the next hop responds to ping
• Active while host responds to ping

If the static route is always active, the configured static route will always be maintained in the routing table.

When a route is configured as "Active while the next hop responds to ping", or "Active while a host responds to ping", the MX tracks the route. If the MX stops receiving ping responses for a period of time, the route will be removed from the routing table. The route is re-added when responses are received again.

The route tracking mechanism only has local significance, which means, that the status of the route doesn't influence whether the route is advertised or not and it won't affect the routing on the remote end of the VPN. 

Datacenter Redundancy (DC-DC Failover)

A DC-DC failover configuration is defined by the following characteristics:

• Multiple MXs are configured in VPN concentrator mode on the Security & SD-WAN > Configure > Addressing & VLANs page of Dashboard
• The VPN concentrator mode MXs are configured to advertise the same upstream subnet(s) via the Security & SD-WAN > Configure > Site-to-site VPN page in Dashboard
• The VPN concentrator mode MXs are configured as Auto VPN hubs for spoke MXs if a hub & spoke topology is being used

 

In this configuration, multiple routes exist to the same subnet and the routes are the same type (Auto VPN). Since route priority and matching on the most specific route cannot be used to determine which Auto VPN route should be used, the concentrator priority is used as a tie breaker.

 

In a DC-DC failover configuration, Auto VPN traffic to subnets advertised from multiple concentrators is routed to the highest priority VPN concentrator that is reachable. VPN Concentrator priority is defined on the Security & SD-WAN > Configure > Site-to-site VPN page in Dashboard.

 

 

When an MX Security Appliance is configured to connect to multiple VPN concentrators advertising identical subnets, the routes to those subnets become tracked. Hello messages are periodically sent across the tunnel 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.

MPLS Failover to Auto VPN

This article describes the configuration and failover behavior for a configuration that leverages MPLS failover to Auto VPN tunnels.

DC-DC Failover

The following section provides an explanation of how VPN routing functions in a configuration where multiple VPN hubs are configured in a DC-DC failover topology.

Multiple Overlapping Routes

Consider the following example:

• One branch
• A static route for the 172.16.0.0/12 subnet to MPLS
• Static routes to other downstream subnets of 172.16.30.0/24, 192.168.20.0/25
• Auto VPN tunnels to two Datacenters, DC1 and DC2
• DC1 is configured to advertise subnets of 10.1.10.0/24 and 172.16.10.0/24
• DC2 is configured to advertise subnets of 10.1.10.0/24 and 172.16.0.0/12
• An IPsec VPN connection to a non-Meraki VPN peer is also present
• The non-Meraki VPN peer has 172.16.45.0/24, 192.168.20.0/25, and 192.168.0.0/16

 

 

The following table represents the routes presented to the branch MX in this configuration:

 

Subnet	Route Type	Hub Priority
10.1.10.0/24 (DC1)	Auto VPN	1
10.1.10.0/24 (DC2)	Auto VPN	2
172.16.0.0/12	Static	N/A - Not an Auto VPN route
172.16.0.0/12 (DC2)	Auto VPN	2
172.16.10.0/24 (DC1)	Auto VPN	1
172.16.30.0/24	Static	N/A - Not an Auto VPN route
172.16.45.0/24	Non-Meraki VPN Peer	N/A - Not an Auto VPN route
192.168.0.0/16	Non-Meraki VPN Peer	N/A - Not an Auto VPN route
192.168.20.0/25	Static	N/A - Not an Auto VPN route
192.168.20.0/25	Non-Meraki VPN Peer	N/A - Not an Auto VPN route

How is traffic routed given the above configuration?

 

If traffic is sent to 10.1.10.1

The MX sends this traffic to DC1. DC1 has a higher priority than DC2, so traffic for the subnet advertised from both concentrators is sent to DC1. If a VPN connection cannot be established to DC1, then this traffic is routed to DC2.

 

If traffic is sent to 172.16.0.1

The MX has both a static and Auto VPN route for this subnet. Since static routes have a higher priority than Auto VPN routes, traffic will be sent using the static route.

If route tracking has been configured on the static route, when the MX stops receiving ping responses for the static route it will be removed from the routing table. In this scenario, the only remaining route is the Auto VPN route and traffic will be sent to DC2.

 

If traffic is sent to 172.16.10.1

The MX has multiple routes for 172.16.0.0/12, but a more specific Auto VPN route for the 172.16.10.0/24 subnet is available. Traffic will be sent to DC1 using the more specific route. 

 

If traffic is sent to 172.16.30.1

The MX has multiple routes for 172.16.0.0/12, but a more specific static route for the 172.16.30.0/24 subnet is available. Traffic will be sent using the more specific static route.

If route tracking has been configured on the static route, when the MX stops receiving ping responses for the static route it will be removed from the routing table. In this scenario, traffic will be routed using the available 172.16.0.0/12 routes. As static routes have a higher priority than Auto VPN routes, traffic will be sent using the static route.

If the static route for 172.16.0.0/12 has also been removed via route tracking, then the Auto VPN route will be used and traffic is sent to DC2.

 

If traffic is sent to 172.16.45.1

The MX has multiple routes for 172.16.0.0/12, but a more specific route for the 172.16.45.0/24 subnet is available via the non-Meraki VPN peer. Traffic will be sent using the more specific route from the non-Meraki VPN peer.

 

If traffic is sent to 192.168.0.1

The MX has a route available for 192.168.0.0/16 via a non-Meraki VPN peer. Traffic will be sent to the non-Meraki VPN peer.

 

If traffic is sent to 192.168.20.1

The MX has multiple routes for 192.168.20.0/25, as well as a route for 192.168.0.0/16. The more specific 192.168.20.0/25 routes will be used over the /16 route available from the non-Meraki VPN peer. As static routes have a higher priority than routes from non-Meraki VPN peers, traffic will be sent using the static route.

If route tracking has been configured on the static route, when the MX stops receiving ping responses for the static route it will be removed from the routing table. In this scenario, traffic would be sent to the remaining 192.168.20.0/25 route available via the non-Meraki VPN peer.

Auto VPN and Non-Meraki VPN peers

An MX Security Appliance can establish tunnels to both Auto VPN and Non-Meraki VPN peers. The MX will send traffic to those VPN peers using the principles discussed above. However, an MX that builds tunnels to both Auto VPN and Non-Meraki VPN peers, will not route traffic between the non-Meraki VPN peers and other Auto VPN peers.

Spoke-to-Spoke Communication

All MX Security Appliances joined to an Auto VPN topology will receive routes for all other subnets joined to the Auto VPN topology. In a hub and spoke topology, a spoke MX will receive routes to communicate with other spoke sites with a next hop of their configured VPN hub(s). The VPN hubs will then route between spoke sites.

 

To prevent certain traffic from entering the VPN, site-to-site VPN firewall rules can be configured on the Security & SD-WAN > Configure > Site-to-site VPN page in Dashboard.

Use of Default Routes and Exit Hubs

Hubs and spokes utilizing full-tunnel (exit hub or default route) Auto VPN configurations will not fail over to a secondary default route without manual intervention if Auto VPN connectivity is disrupted between the peers (with the exception of DC-DC failover.) For example, if a spoke is experiencing connectivity problems to a hub that is configured as the default route traffic can be lost as the security appliance will not failover to the unencrypted WAN.

Routed Mode and Auto VPN

You can only advertise the same subnet from more than one appliance if all appliances advertising that subnet are in Passthrough or VPN Concentrator mode. All subnets advertised from an appliance in Routed mode must be unique within the Auto VPN topology.

Private Subnet Configuration on Multiple Non-Meraki VPN Peers

When two or more non-Meraki VPN peers are configured identical or overlapping private subnets, you will be prompted with a message alerting you of the overlapping or identical subnets that must be confirmed before saving changes. The messages describe the following routing behavior:

• When two subnets overlap, IP traffic will be routed to the most specific subnet.
• When two subnets directly conflict, IP routing behavior will be undefined. This can be avoided by configuring the Availability column with different network tags to ensure that no security appliances have peers with conflicting IP subnets.

An example screenshot and confirmation message can be found below: