In some deployment scenarios, an MPLS VPN connection is used to provide connectivity between sites for internal traffic. Additional redundancy can be added to these scenarios by utilizing a Cisco Meraki MX security appliance and the site-to-site auto-VPN feature, to provide failover of routes from the MPLS VPN to the Meraki auto-VPN over the internet. In the event the MPLS VPN link becomes unavailable, traffic can be routed over the site-to-site VPN in order to maintain uptime for users and services.
For more information on how to use MX security appliances with an MPLS connection as the primary internet uplink, please consult the article on site-to-site VPN over MPLS.
The configuration for MPLS to VPN failover operates as a simple route failover. Assuming there is a VPN tunnel established between the two MXes, redundant static routes are configured on either side, where the route points clients toward the MPLS connection as a means to reach the other side's subnet. Dashboard will prioritize a static route over a VPN route, so clients will be directed over the MPLS link via the static route, until the MPLS link fails - at that time, clients will be directed over the AutoVPN tunnel instead.
The following sections outline an example topology and post-configuration failover behavior for that topology:
In the example topology below, two sites with MX security appliances are connected over an MPLS connection, as well as the Meraki site-to-site auto-VPN. The MPLS links are connected to LAN interfaces to prevent NATing of traffic and allow for static routes. Traffic will be configured to utilize the MPLS connection, until a failure occurs, in which case the traffic will be sent over the Meraki auto-VPN.
In Dashboard, the static route will be configured as "Active as long as a device on the other side responds to ping." In this configuration, ICMP pings will occur every 3 seconds to the target IP indicated (either the next hop IP or an IP in the remote subnet). If 5 of these pings consecutively fail (15 seconds), the route will be marked as inactive, causing the auto-VPN route to take precedence and begin to handle any relevant traffic.
If the target IP then responds to 3 consecutive pings (9 seconds), the connection will be marked as active again and take precedence over the auto-VPN route. This is to prevent a route from flapping if it comes back online, but is unreliable.
In the diagram below, this behavior is illustrated:
- Traffic proceeds normally over the static route via the LAN connection to the other location using the MPLS VPN.
- After 5 consecutive connectivity tests fail, the static route is marked as inactive.
- Traffic is then routed over the Meraki site-to-site auto-VPN.
- Once 3 consecutive connectivity tests pass for the MPLS link, the static route will be marked as active, and traffic be routed over that connection.
The following sections outline how to configure static routes to point over the MPLS connection, and set them to fail over to the VPN tunnel.
Note: This configuration assumes that a Meraki AutoVPN tunnel is established between the two MXes. For more information on how to configure and use Meraki AutoVPN, please refer to our documentation.
In order to setup failover, duplicate routes will need to be created for any remote networks that should be reachable over the MPLS VPN and the Meraki auto-VPN. The order in which these two routes are added doesn't matter.
The following image indicates the left MX's route table (located under Security appliance > Monitor > Route table), prior to configuring the duplicate route:
Next, configure the static route that will direct traffic over the MPLS connection. This route will be treated with higher priority than the VPN route. The MPLS connection must be through a LAN port on the MX, and not connected to the Internet port. In this example, it is assumed that a VLAN has already been created that is used for the MPLS connection, as illustrated in the topology.
- Navigate to Security appliance > Configure > Addressing & VLANs
- Under Routes, click Add a static route
Note: If there is no "Routes" section, but there is a "Static LAN routes" section, the MX network will need to be upgraded to the latest firmware version.
- Enter the required information:
Enabled: Leave as "Yes" to use the route
Name: A friendly name to represent this route
Subnet: The subnet, in CIDR notation, that this route is for
Next hop IP: The IP address that is the next hop gateway for traffic to this subnet. This must be on a local subnet.
Active: Determines under what conditions this static route should be considered active. For failover to function, this cannot be "Always".
If choosing "While next hop responds to ping", the MX will check against the Next hop IP specified.
If choosing "While host responds to ping", the host provided must be in the subnet entered above.
In VPN: If the static route should be included in the site-to-site VPN. When configuring failover, leave this as No.
- Click Update to save
- Click Save changes to apply
As long as the Active criteria for the route are being met, the route will remain active, and will be treated with higher priority than a VPN route for the same subnet. It is important to remember that more specific routes are treated with greater priority than less specific ones. So if a VPN subnet exists that is more specific than the configured static route, the VPN subnet will be used, even if the static route is active.
The following image indicates the left MX's route table, after adding the duplicate route:
In the event it becomes desirable to have traffic for a given subnet use the auto-VPN as opposed to the MPLS link, when connectivity tests are not failing, the static route to the MPLS link can be manually marked as inactive.
In order to mark the static route as inactive:
- Click on the static route under Routes
- Change Enabled to No
- Click Update
- Click Save changes
Route is currently disconnected
If the Connectivity column appears as a red circle with an X and indicates that the "Route is currently disconnected", verify that the Active criteria is being met. The next hop IP, or designated host, must be responding to pings (ICMP Echo Requests). Make sure that there are no firewall rules on the device or along the path that would be preventing this traffic from proceeding in both directions.
The MPLS link is down, but traffic never uses the Auto-VPN
This may be the result of either a lack of auto-VPN connectivity, or the redundant static route being set to always active. Under Security appliance > Monitor > Route table, ensure that the Status field for the redundant Meraki VPN route is green. For the redundant static route, ensure that the Active criteria under Security appliance > Configure > Addressing and VLANs is set to something other than "Always". If always active, the route will not be automatically removed if the MPLS connection goes down.
Also verify that the Next hop IP and, if applicable, the Host IP to ping are correct. If they are incorrect, but responding to pings, the route will still be marked as active. Even if the traffic is being routed to the wrong location.
The MPLS link is up, but traffic always uses the Auto-VPN
Verify that the Connectivity for the static route is green and connected. If it is, make sure that the Auto-VPN route is not more specific than the static route. Traffic will always be sent over the most specific active route. For the failover function to operate as described, the auto-VPN route and static route should have the same subnet and subnet mask (in CIDR notation). As an example, if a static route existed for 10.0.0.0/8 but an auto-VPN route existed for 10.0.0.0/24, the auto-VPN route would always be used for traffic bound to the 10.0.0.0/24 subnet, even if the static route was active.
IP address is not on a configured subnet
Verify that the Next hop IP is correct and within one of the existing local subnets. The next hop IP cannot be out the internet interface or over another static route.
Static LAN route subnets cannot have the same subnet
Make sure that there is not already a static route servicing the subnet that is being configured. There cannot be two static routes for the same exact subnet.
In the event a static route or VPN route is created that overlaps with an existing route, the configuration will be accepted, but the most specific active route will be used. As an example, if a static route existed for 10.0.0.0/8 but an auto-VPN route existed for 10.0.0.0/24, the auto-VPN route would always be used for traffic bound to the 10.0.0.0/24 subnet, even if the static route was active.
Static LAN route conflicts with remote VPN subnet on non-Meraki peer
MPLS to VPN failover can only be configured using these instructions with Meraki VPN peers.