In addition to the previously discussed security features offered by the MX series, MX devices are also capable of performing L3 routing through a number of different configurations, including basic static routing for IPv4 and IPv6, dynamic VPN routing, BGP for IPv4 and IPv6, and OSPFv2 and OSPFv3.
This section briefly covers some of the more impactful aspects to keep in mind when routing with a Meraki security appliance, as well as some additional recommendations. For more detailed information about the implementation and functionality of routing for Meraki security appliances, visit https://documentation.meraki.com and view the article “MX Routing Behavior.”
Route Priority
When planning your routing configuration for a deployment, it’s important to keep in mind how the different route types are prioritized compared to each other. From the perspective of the MX, there are seven different types of routes, each with its own priority relative to the others.
The types of routes and their priority are listed here, with the highest priority listed first and lowest priority listed last:
1. Directly connected/local subnets
2. Client VPN
3. Static routes
4. Auto VPN routes
5. Non-Meraki VPN peers
6. BGP learned routes
7. Default uplink/NAT
For any given traffic destination, the traffic will be routed based on the highest-priority matching route. If there are no more-specific routes that match the destination, then the traffic will be forwarded out the default uplink over the currently active Internet interface. By properly planning and taking advantage of route priorities, you can employ multiple routes to quickly and easily create robust failover mechanisms. When combined with the Meraki SD-WAN solution, discussed in Chapter 6, this can create a powerful failover solution to help ensure minimal downtime for critical applications.
Static Routes
You can configure static routes on a per-device basis directly on the Security & SD-WAN > Addressing & VLANs page under the Static Routes header within the Routing section of the page.
When working with manually configured static routes, there are a few considerations and best practices to keep in mind. Primarily, it’s critical to have a complete picture of the entire routing topology and to configure appropriate return routes for any traffic that would be routed over a static route.
Configuring appropriate return routes is specifically important to prevent an asymmetric routing situation in which traffic is routed from one site via a static route to an internal or MPLS link but return traffic is routed back to that site via a different path, such as over an Auto VPN connection between sites, because the opposing site is missing the appropriate static route for the return traffic.
Additionally, when working with static routes, it’s important to ensure that the appropriate route-tracking mechanism is configured for each route. For each static route configured, there is an Active setting to configure a condition that must be satisfied for the static route to be marked as active or available; the choices are Always, While Next Hop Responds to Ping, and While Host Responds to Ping.
A condition such as the next hop responding to ICMP, or a specific endpoint reachable across the static route responding to ICMP, can be configured for each route to ensure that only static routes that are able to provide appropriate connectivity are marked as active. When combined with the route priorities mentioned previously, this can be used to create a robust failover mechanism that allows a configured static route to be the preferred route for a given destination, such as over an internal or local MPLS link on the LAN, while allowing for failover to either an Auto VPN or non-Meraki VPN peer route in the event connectivity via the static route is lost.