SD WAN vs MPLS

Two technologies enter the arena but only one will be victorious!

Not exactly…

And really, do we have to keep pinning these two up against each other? Does it really have to be one versus the other?

Is SDWAN really designed as a replacement for legacy WAN connections such as MPLS? Is MPLS even legacy?!

So many questions!  But let’s think of this from a different perspective…

If you recall from my SDWAN underlay article, MPLS can actually be one of many underlay options that SDWAN can leverage. So why can’t we just use both together in perfect harmony forever instead of making them duel to the death?

Short answer: WE CAN!!!

I talk quite a bit about how SDWAN is revolutionary in many ways. The most important of which is its impact on business functions and how that can help the Network Engineer.

So, let’s just rename this post to something a bit more appropriate like

“SDWAN with MPLS: a match made in heaven”

Looking at the below topology, you can see that we have two different underlay connections connected to our SD router. One of which is our standard Internet connection that comes from our cable modem and the other is an MPLS connection.

If you replaced the SD router with just a standard edge router, this would be a very common set up. Perhaps the business is using the cable modem connection as what we call “local internet breakout” which is appropriately named given that the internet is broken out locally and does not traverse the MPLS. Again though, this is not uncommon in a world without SDWAN and exists all over the place today.

What’s different here?

Enter the two pillars of SDWAN, Insights and Control.

First, this is really just another form of SDWAN link aggregation. We know from link aggregation that it doesn’t really matter what the underlay is because my SDWAN appliance can monitor those links and do dynamic traffic forwarding based off those metrics. The main difference when using MPLS as an underlay is that the MPLS is going to give us all those guaranteed metrics around uptime, latency, packet loss, and jitter.

Here’s my idea -  Let’s augment that MPLS connection with a software defined router and some extra bandwidth. This way we can use the MPLS for only super critical business traffic. We will then free up the MPLS bandwidth so it has some breathing room. We will get a VPN tunnel that runs in parallel to the MPLS – should the MPLS fail, we will reroute those business-critical apps over that VPN. Lastly, we will make anything that is destined for the internet just leave right out the cable modem.

SDWAN will allow us to accomplish this using the insights and control.

With a traditional setup, we have some ‘static’ rules and maybe even some policy routing allowing us to use both the MPLS and the local internet connection. This is great but it isn’t the most efficient way of using all of the links at our disposal.

I talk about this all the time. The problem is not that you can’t use an MPLS connection along with a standard Internet connection at every one of your locations. The problem is that we have to do a lot of configuring that won’t be as granular (application signatures) which in turn won’t ultimately get us to efficiently use everything we pay for.

Here is a harmonious scenario where we have MPLS and we decide to aggregate using an SDWAN router and a standard cable internet connection:

You can see here that there are three different logical paths for the traffic to take(represented by the dotted lines). These paths are predefined in the SDROUTER using applications signatures. I have configured the SD Router so that all of my current MPLS traffic needs to use the ‘Main VPN” that you see in green. This way, nothing has changed from what I was using my MPLS for previously. What a seamless transition!

What I did add however, is the backup VPN connection that is ready to go, should the MPLS stop performing the way I want it to. Notice that I didn’t say that the MPLS had to be “DOWN” for the backup VPN to be utilized. Remember that I can set parameters around packet loss and jitter for instance in most SDWAN deployments. If that MPLS connection starts actin’ silly on me, something is already preconfigured to take over without a hiccup. The last piece of the puzzle is the traffic destined for the Internet. I have just sent that straight out the cable modem and it will not traverse any VPN’s.

NEAT!!!!!!!!

Extra bonus: This scenario allows us to use every megabit we pay for pretty much all of the time. Cool!

The point here is that we often make these two technologies compete with each other. What you can gain from the examples is a completely opposite view.

As you have seen, SDWAN is great at augmentation. And that’s ok - some scenarios require us to use our tools differently that you may have originally thought.

One of the great things about being an Engineer is getting to solve complex scenarios where we use our tools to solve our problems in any number of scenarios. I hope my examples have shined some new light on how we can use some of these newer tools in harmony with our current networks.

So, who wins in the MPLS vs. SDWAN showdown???

Neither! Ok… well, both!

Thanks for reading!

p.s. if you like it, share it!