Consider now that I have a WAN edge and in my environment, maybe I've got two
service providers, A and B, and naturally I'm going to have a connection into
each which allows for a lot of redundancy.
Well, that's great and all for the sake of redundancy.
But what about load balancing?
How do we usually do this in a traditional WAN environment?
Well, traditionally what we would do is we would simply set this up as active
and standby.
Could we get complicated and add a bunch of configuration and attempt to load
balance?
Absolutely, we could.
But the level of complexity involved with that is one of the downsides to
traditional WANs.
And most organizations, at least in my experience, especially when I was
deploying and consulting, was if we had two WAN circuits, they were active
standby in its entirety.
And the reason for this, again, is because of the need for simplicity and the
fact that even if one network operator is able to set all of this up, if they
happen to leave the organization, they were usually the only ones who knew how
it worked.
And so it's not a good thing to try to make it work active active unless we
have a robust infrastructure and process in place in order to make it happen.
So that's great and I'll accept what now if this was a 20 meg MPLS circuit, and
over here this was actually a 100 meg internet circuit, and we were using DMVPN
in order to secure the internet circuit and use it as a backup WAN connection.
Well, that's great and I'll accept again, we have much reduced bandwidth on the
left for the sake of reliability and consistency.
That's what MPLS delivers, in most cases.
Meanwhile, we've got all of this bandwidth sitting over here in pure standby
operation.
That is very painful, and not only is it painful, it's actually very expensive
to try to cost justify.
Fortunately, 100 meg internet circuits, depending on where you live in the
world, are not too expensive.
I mean, internet is pretty cheap these days.
But if this was something like another 20 meg MPLS circuit, or for that matter,
if we said, "Hey, we don't want to just pay for a 20 meg MPLS circuit and not
use it, so let's just make this 10 megabits."
Well, that at least is cheaper, but now in the event of a failover, we're going
to have a whole lot less bandwidth.
And so it made for very painful conversations as far as how exactly we're going
to take advantage of the fact that we've got all of this bandwidth sitting here
, and we're paying for it.
And yet, we know for simplicity's sake that it's running in active standby.
So that is the traditional WAN environment.
Fortunately, with SD WAN, we are going to make it so that we can load balance
across these different active links.
The advantage of SD WAN is that we can still make this a simple architecture,
because this is going to be handled via our manager.
We get in and set a policy and essentially say, "Hey, I want to load balance in
a particular fashion."
And that policy becomes configuration without the admin being involved.
So all I have to do is the network administrator is get onto my manager and
select the load balancing option, and the policy just automatically gets
deployed.
So that is, again, a huge benefit of SD WAN is simply allowing us to log into
the manager and configure a policy and allow the network to figure out how
exactly it's going to deploy the configuration.
And naturally, we're also trusting that it does actually work, but the solution
wouldn't be very popular if it didn't actually work all the time.
Worth noting within the SD WAN world, we can load balance up to eight links.
For most of us, two was plenty, but we could go to three or four depending on
the criticality of the site, especially if we're deploying a bunch of internet
circuits.
We could deploy three, four, five internet circuits for redundancy, I suppose.
But again, it's good to know what the max is in case we happen to hit that, or
maybe at a minimum, we can feel secure and knowing that if we have three links,
we're talking about a fourth link that we can still handle that because we can
go all the way up to eight.
So end of the conversation, right?
Well, there's a whole lot of space over here, so probably not the end of the
conversation.
We actually have quite a few load balancing options for to be specific that we
're going to want to consider, because sure, we could just do standard active
active load balancing.
Active active load balancing is going to allow us to balance things evenly.
This is an even distribution of traffic. And furthermore, very importantly,
this is considered from a per session perspective.
So keep in mind, if I've got two upstream connections or three or four, either
way, we'll just say two for simplicity sake.
If I've got, let's say, 10 sessions that come through, and we're talking about
network flows of traffic here.
10 of these coming in, well, we're going to put five out one way, and we're
going to put five out the other way, because we're load balancing per session.
Now, each one of these flows on the left could be very strong flows, and the
one on the right could be very small, like 100 kilobits per second versus meg
abit per second flows.
So this could be a bad thing from the perspective of, you know, maybe we get
very unlucky with how the sessions balance out.
However, law of averages suggests that probably this is going to be roughly the
same bandwidth going in each direction, but don't be surprised if we log in and
we see that this side is consuming 65% versus 35% or something like that.
It's not going to be exact from a bandwidth perspective, that's for sure. So
that's active active load balancing. We can also use active active weighted
load balancing.
Think about our earlier example. Over on the left, we said that we've got a 20
meg circuit and a 100 meg circuit. Would we want to evenly load balance across
those?
Probably not. We've got five times the amount of bandwidth on the right as we
do on the left, and if we're evenly load balancing, we might well peek out the
MPLS before we peek out the Internet circuit, and then we've just got all of
this Internet bandwidth, and we're not taking advantage of it.
Active active weighted, as the name implies, allows us to weight some of the
links. So we might say that this is going to be, well, first of all, it's going
to be an uneven distribution, and once again, this is per session.
But now we can maybe say something like, let's put five times the sessions on
one side, so every five sessions that get put onto the Internet circuit put one
session onto the load balance, or onto the MPLS side.
And so we're doing an uneven, unequal level of load balancing, which actually
is a good thing because it matches the bandwidth available. So those are two
more common policies, especially from the perspective of just trying to evenly
consume bandwidth.
But again, we're talking about SD WAN. SD WAN has the ability to play more
complex architectures in a way that doesn't require complexity from an
administrator configuration perspective.
And so what else could we do here if we get clever? Well, what we can do is we
can start to become application aware.
So everything up here is just raw traffic consideration. But now we've got a
few options that are going to consider the fact that we've got specific
applications going through.
For example, did I mention voice over IP anywhere in this conversation? I did
not.
We have an MPLS circuit on one side, we have an Internet circuit on the other
side, and we would never want to send voice over IP traffic across the Internet
circuit, depending on our organizational policies.
And so we want to consider the application in a lot of situations.
So first of all, we can actually go back to the concept of active standby.
But active standby is from a pinning perspective. What do we mean by that?
Well, once again, we've got our two circuits, and we say voice over IP should
always use this link. Let's call it the MPLS link.
So because I'm making a policy for voice over IP, I would say always use this
link that's your active, and then if that goes down, then use the other link as
a standby.
Because we'd still want to fail over, we just don't in a normal situation want
the voice over IP traffic to get load balanced. We wouldn't want that.
Always use one link over the other. So this is configured on a per application
basis.
And we're going to have to worry about identifying traffic flows, which we'll
talk about here in a moment.
So that's the first application aware policy. The second one is going to use
that phrase I just used application aware, as is known as application aware
service level agreement or SLA.
This takes it one step further. Again, it's configured per application.
But now remember what we just talked about with BFD, how we can track link
quality? This is going to be notice, not pinning. We're not pinning anything.
We are going to stay dynamic.
And we're going to consider the metrics of a link. So now we have the situation
where I do want voice over IP still to use the MPLS, but to borrow my phrase,
what if it's having a bad day?
What if we have hundreds of milliseconds of delay on the left link here, this
MPLS circuit? And meanwhile, the Internet circuit is actually humming along.
I mean, why do we not want to use the Internet circuit for voice over IP? Pot
entially because of the delay that we expect on the other side there on the
Internet side.
Well, if the Internet is fine, we say, hey, this is actually in good shape,
then, well, and likewise, or conversely, the MPLS circuit is not in good shape.
Well, let's go ahead and swing voice over IP over. That's exactly what
application aware SLA is all about. We're going to set our thresholds for when
a circuit is considered to be impaired.
And again, like we said, it's really easy to tell when a circuit is down. It's
much harder to change our policies when it's simply impaired.
Well, now we have that capability and we can use application aware SLA from a
load balancing perspective in order to make that happen.
And again, we've got the control over things from a per application perspective
in order to set this up.
So last question is, how do we perform application identification? In the end,
we have two options. The first option is known as six tuple matching.
Remember that concept of a flow, if a specific flow is coming through here,
then we would want to figure out which link to send it on.
Well, the way we tell a flow apart is by looking inside the packet and seeing
which packets more or less are coming from the same source and going to the
same destination and using the same other fields, such as my DSCP or my TCP and
UDP port.
So the six tuple we're going to use to identify a particular specific
application is going to be source and destination IP. So that's two.
Then I'm going to use source and destination port. That's two more. So we've
got four listed now. Then we've got our DSCP, which is especially going to help
us out if this is voiced over IP traffic.
And then lastly, we have the protocol number.
If all six of these match the what we're looking for, then we can tell that it
's part of a specific application. Again, voiceover IP being one of these, but
other applications, if they're all being used specifically in a particular way,
all of these other things should match.
Now, the second way that we can do this is to simply use an embedded Cisco
feature, which is known as deep packet inspection or DPI. This is on the built
into the edges. They can actually just go into a packet, look at it, run it
against the database.
And it's aware of thousands of applications. Very simple and easy to set up and
identify applications much more granularly, but nothing comes without a catch.
This is going to require a license.
So it costs extra money in order to deploy, but it is going to improve our
ability to identify applications and deploy specific policies against them.