SDWAN Link Aggregation

This article is designed to give you a very basic view of how SDWAN can optimize underlay connections to make the most efficient use of what you are paying for.

So, you may not know me but just know I love SDWAN bells and whistles of all varieties. There are some really cool vendor specific ones out there today.  

I wouldn’t exactly call this a bell or a whistle though. I might say something more like “foundational”. Foundational because this is one of those core concepts that makes SDWAN such a viable solution. My other articles always point to the two main concepts behind SDWAN which are insights and control. Those two concepts together bring us efficiency. 

Let’s take a quick minute to dive into link aggregation. The idea is to use multiple links to act or function as one for resiliency and efficiency.

Typically when we talk about link aggregation, we might be using a protocol at the layer 2 level like LACP or PAGP where we set up a port channel between two devices like you see below. 

Our next option is to use layer 3 routing protocols that have some sort of load balancing capabilities in them such as OSPF, EIGRP, or BGP. 

But even these only get us a small amount of control because we are looking at only a few metrics which are usually centered around IP address and protocol with the exception of BGP of course.

This picture shows a few different connections coming into the SDROUTER from the outside world. I have included speeds for reference. 

Now that we have a visual, let’s take a look at some of the most common ways to use all of our connections or AGGREGATE!!! them.

Fail-over

The first way to capitalize on the many connections is by making one a primary and the others fail-overs. Just by looking at the speeds in the diagram we might draw the conclusion that one of these connections might be considered our “primary” connection. And that would be the cable modem in this scenario given that is has a 500mbps download speed. 

Our first thought might be to route our traffic over that highest bandwidth link and use the lowest as a fail-over. And that’s not a bad thought at all. Just a little too easy if you ask me. However, this is very popular; doing it the “old school” way with one of your connections just sitting idly for most of the time. You can set up SDWAN to operate in this way but its not the most efficient use of our bandwidth. 

But that’s really it. You can set one or many connections to primary, secondary, and tertiary fail-over connections so that you only experience a very slight hiccup if one of the links goes down.

The big glaring issue here is that we have several connections not even being used unless the first one fails.

So how do we fix that…?

Load Balancing

When you see the words load balancing, you probably already know that its nothing new. This has existed in routed networks for a long time. But as we learned earlier, the way routers handle load balancing is typically designed around IP address and protocol. 

Often, this is what aggregation looks like in today’s networks with a non-SDWAN router: 

Some sort of load-balancing using an IP hashing algorithm. This will essentially establish sessions with the next link in the hash. This simplest version of that is for the sessions to ping-pong back and forth ultimately using the entire bandwidth up as evenly as possible even though all of the links aren’t the same when it comes to speed, latency, jitter etc…

Here’s a visual example with two different connections and two different end users that have traffic destined for the Internet…

In the image to the right you can see the red traffic coming from user 1 and the blue traffic coming from user 2.

The red traffic arrives first and is sent out of the first connection.

The blue traffic arrives second and is sent out of the second connection.

If there were a third connection, that would be sent out the first connection again. That pattern continues until the bandwidth is consumed.

This is referred to as ‘flow based’ because the flow from the first user is always going to use that first connection. When a new flow starts, it will pick the next link in the list.

The point here is that we are using both links. It’s not very granular but hey, they are being used!

Now that we’ve got that out of the way…

SDWAN aggregation looks a lot different because we have more insights(DUH!). There are some applications that my business uses that I want to give precedence to. For example, we could steer business-critical apps over the link that always has latency under 30ms and packet loss less than 1%. You see, I have identified that these apps work best in those conditions so at this point I really don’t care what link is being used as long as those requirements are met.

Here is that same picture using applications to pick the connection instead of using ‘what user arrives first’ logic :

Expanding on our earlier example, I have chosen that our business needs to prioritize salesforce and phone traffic to be specific.

Everything else like twitter, instagram and facebook should go out my lower quality connection since those apps are not business critical.

This means that if the cable modem dips below that latency and packet loss requirement I put in place, salesforce and phone traffic will switch to the DSL connection seamlessly.

I think it’s pretty obvious why this is more efficient but let’s just make sure we are on the same page.

• Both connections are being used, all the time, regardless of their speed (unless of course they are down)

• There is still a failover of traffic (the traffic can failover to the other connection if it’s not meeting the latency and jitter perameters instead of the link just being down)

• All of this is being monitored constantly so that if the cable modem returns to normal operation, the critical traffic will switch back to that connection automatically

• I was able to pick specific applications to prioritize over everything else instead of just IP or protocol
  

Final Thoughts:

I don’t know about you but I think I will use the software defined router as my go-to edge device here. It all comes back to insights and control. Being super granular about what applications are traversing my network has allowed me to steer them intelligently over the best available circuit. And I will add, very easily too. Most of the SDWAN GUI’s allow me to pick from a drop down list of predefined apps like the ones I mentioned to create these policies with little to no resistance at all.

The whole point is that with an end goal in mind, we are able to accomplish everything we need quickly with the most efficient use of bandwidth.

Thanks for reading!