There are many situations in which getting rid of MPLS altogether is not possible. For example, a company may have a long-term MPLS service contract that has an expensive exit clause, a site may have limited last mile options, or a site may have specific design requirements calling for MPLS. Whatever the case may be, MPLS connectivity can still be leveraged as a WAN transport for Meraki SD-WAN. Starting in MX13, when Auto VPN traffic traverses the MPLS network, the VPN packet headers have copies of the DSCP tags of the payload inside. Thereby, your MPLS carrier may still honor its service level agreements (SLAs) and commitment to your contract without having to decrypt or know what the traffic is inside the VPN tunnel.
When connecting an MPLS WAN, there are a few things to bear in mind:
• The WAN interface of the MX still needs to reach the cloud for communications such as updating the VPN registry for Auto VPN.
• You need to configure a static IP address on the WAN of the MX, just like you would do with a traditional router.
• The usual BGP exchange has now moved, and the routing will be more centralized with an MX hub.
Unpacking the previous observations, the Internet connectivity can be provided through an Internet breakout on the MPLS network itself, or it can happen via the MPLS network, through the data center, and out to the world via a firewall and border router. Traditional MPLS networks tend to assign a static address and use it for BGP exchange with the MPLS network. When the MX is added, you still configure the static address, so it has connectivity via the MPLS network. No BGP exchange takes place there, but at the hub MX instead. In other words, an Auto VPN overlay is created over the MPLS network, carrying the routes to the hub, where they get distributed into the network core. This centralizes and optimizes the routing because it happens in one place (assuming one hub for illustration purposes) instead of happening at every site. This simplifies deployments and reduces the time required to set up new sites.
The following are two additional advanced design features to consider:
• VPN exclusions: VPN exclusions are great for intelligently separating traffic to go straight to the Internet (e.g., SaaS traffic) for direct Internet access (DIA) links. However, you must consider what the behavior will be for this traffic when it gets put on the MPLS network. Is a default route advertised? Will the traffic be allowed to exit to the Internet? Where will it exit? While not a showstopper, you must consider the flow of traffic when this is put into play.
• No-NAT: No-NAT can be enabled by Meraki Support for the MPLS WAN link. However, be aware that no dynamic routing is available on the WAN interface (at the time of writing). Therefore, the MPLS provider needs to have a static route that points to prefixes behind the MX via the static address on the WAN.
As you can see, adding SD-WAN capabilities is viable with traditional MPLS as a WAN link. There are a few design considerations to be aware of, but it offers choice and flexibility in how and where to leverage it. MPLS is here to stay for a little while longer.