How to deploy Meraki SD WAN over MPLS?

As one of the first cloud-managed, orchestration-based routing platforms, Cisco Meraki was in a prime position to have an SD WAN offering from the beginning. Unlike a lot of other companies, when Meraki started rolling out SD WAN capabilities in its software, it did not force you to purchase new hardware.

All current MX series security appliances support SD WAN capabilities through a second uplink connection. While SD WAN is typically thought of as being used only with the Internet, Meraki’s SD WAN works equally well over higher-quality MPLS links too.

All Cisco Meraki devices must have a connection to the Internet for management. Unlike some other platforms, Meraki does not have a local on-premises management offering. This means even infrastructure devices like Meraki wireless access points that do not participate directly in providing client reachability to the Internet must still have Internet access themselves to be managed. Cisco does provide an extensive list of addresses and ports, though, so that you can lock these connections down with a firewall for enhanced security.

The management Internet connection is an important consideration when deploying Cisco Meraki SD WAN over MPLS connections. When you subscribe to an MPLS Layer 3 VPN service, Internet access is usually not included unless purchased as an additional service. Most often, MPLS L3VPN links are purchased strictly with site-to-site traffic in mind and a centralised Internet access model is used.

Sometimes Internet access can be purchased from your MPLS provider and delivered as a separate physical interface or VLAN that connects to your customer premises equipment (CPE) such as a Meraki MX appliance. Less commonly, Internet access may also be injected directly into the L3VPN through a carrier-provided default route or some form of centralised firewall service.

SD WAN with Cisco Meraki supports two uplinks. Both uplinks could be MPLS L3VPN connections, as long as at least one of them has some form of reachability to the Internet, but the most common deployment scenario of Meraki SD WAN over MPLS is with a single direct Internet connection and a single MPLS link. Without SD WAN, the MPLS link is used as a traditional routed connection across your network. You can specify which routes are reachable through the MPLS L3VPN with either static routing, or by using a routing protocol such as BGP.

When you configure SD WAN to be used with your MPLS link, an AutoVPN tunnel is established across the MPLS L3VPN to your other Meraki MX appliances in accordance with your configured topology. The default AutoVPN topology is full mesh with each MX appliance establishing a direct tunnel to all other MX appliances. Beyond a few sites, this presents scaling and efficiency limitations, so most companies that deploy Meraki SD WAN do so in a hub-and-spoke model where connectivity is centralised and potentially regionalised as well, depending on the size of the deployment.

With Cisco Meraki SD WAN, two AutoVPN tunnels are used, one per uplink, and traffic is distributed across both links simultaneously according to the defined traffic policy. For instance, there is a built-in policy called “Best for VoIP” where all real-time voice traffic is automatically sent on the link that has the best characteristics for successful voice traffic, such as low latency and jitter. In the context of using SD WAN with MPLS links, you have a much better chance of the MPLS link performing better than a general Internet link when it comes to voice traffic in particular.

Most MPLS links are backed by a service level agreement (SLA) which guarantees a specific minimum level of performance. General Internet connections may have some level of guarantee in the form of availability (or uptime), but not with general performance due to the unpredictable nature of the Internet. This is why SLA-backed MPLS is still a very popular choice when network traffic must be delivered within specific constraints.

Larger SD WAN deployments usually involve datacentres and possible regionalised hubs. For these kinds of deployments, Cisco recommends using larger appliances capable of higher tunnel accounts deployed in what is known as “one-armed VPN concentrator” mode. With this configuration, the MX appliance does not connect to the Internet directly but terminates all of the AutoVPN sessions from the branch offices through a centralised Internet connection along with a connection to the MPLS L3VPN service.

Cisco Meraki MX appliances also support high availability device pairs, with one device active and the other in standby mode. Datacentres have physical infrastructures designed with redundancy and high-availability in mind, which makes the one-armed scenario possible. With this design, each Meraki MX appliance shares the IP address used for the VPN concentrator endpoint but uses the Virtual Router Redundancy Protocol (VRRP) so that only one device is active at a time and serving clients.

Deploying Cisco Meraki SD WAN over an MPLS link gives you the benefits of SD WAN with the added performance of MPLS. Network traffic automatically uses the best link based on policy, and you have very fast failover when one of the links becomes unavailable. The Meraki MX appliance constantly evaluates and verifies the AutoVPN connections by sending a 100-byte test packet once every second. Performance characteristics such as packet loss, delay, and jitter are constantly measured, and traffic profiles are adjusted accordingly so that your network traffic has the best chance of reaching the other end of the AutoVPN tunnel intact and on time.

One final advantage of deploying SD WAN using an Internet link and an MPLS L3VPN connection is that you can send general Internet-bound traffic directly over the Internet link instead of forcing it to traverse the MPLS connection. The Meraki MX appliance is first and foremost a security appliance and whitelisting certain Internet destinations for local Internet breakout is a good way to balance performance and send only your most important, time-critical traffic over the MPLS link. For example, if your organisation uses a trusted cloud-based software platform like Microsoft Office 365, it may be better to send that traffic directly to the Internet instead of using MPLS. Likewise, traffic destined to internal file servers should probably travel over the MPLS link, but with SD WAN you have instant failover should one of the two paths become unavailable or degraded.