One of the big benefits to having SD-WAN is to be able to improve our
efficiency
around the use of multiple WAN circuits.
Because now we can truly talk about load balancing across these circuits.
In a traditional network, if I have a WAN router at the edge of my network
and I have a WAN circuit here, let's say this is MPLS,
and maybe I just pay for a second circuit just for the sake of redundancy.
So I get another provider here, and this might be, let's just say this is a 100 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I get another provider here, and this might be, let's just say this is a 100
-meg circuit,
and I just go ahead and get a different MPLS provider to give me a 10-meg
circuit much cheaper
and I'm just using this for redundancy.
Well, again, in this traditional environment, usually what I'm focused on here
is turning this into an active standby type of deployment.
All of my user traffic as it comes into the network is going to flow this way
out the active. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
out the active.
And the reason for that is simply put, load balancing is very, very complex.
There's a lot that I have to worry about in the routing space in order to make
this work,
and the other question in all of this is how exactly do we load balance?
Now, traditionally, again, if I have a really small backup circuit like this,
I have 110 total mag of throughput here, and I'm only using 100.
Well, 100 out of 110 isn't all that bad. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Well, 100 out of 110 isn't all that bad.
We could say that we're using the vast majority of our bandwidth,
and naturally we still have the redundancy.
If circuit 1 goes down, we can direct all of that out the MPLS circuit,
and at that point we're at least online, even if we are limping along on much
less bandwidth.
While all of this complexity and questions about how to do it, they go away
when we're talking about
deploying SD-WAN. This is a massive benefit to be able to perform load WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
deploying SD-WAN. This is a massive benefit to be able to perform load
balancing across multiple
WAN circuits, which leads to the ability to leverage all of our bandwidth.
And so now we can truly look at this again from a tunnel perspective,
as saying that I've got choices as traffic comes in to send it out one tunnel
or the other.
And I can make these decisions very simply by getting into V-manage and config
uring policy.
This policy gets pushed down by the V-Smart via OMP, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
This policy gets pushed down by the V-Smart via OMP,
and so now this router knows exactly what to do, and I didn't have to get in
there and do anything
complex from a routing and switching perspective. Now, we still need to ask the
question of how,
how do we go about load balancing this? Because we could just say, "Hey, I'm
going to do a 50/50 split,"
or "wait it based on percentage." So again, maybe I have 100 Meg here and a 10
Meg over here,
and now we can load balance still by setting most of the traffic out the 100, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and now we can load balance still by setting most of the traffic out the 100,
but still send a little bit of traffic out the 10 to take advantage of it.
I will say this from a real world perspective, what we might end up seeing is
that,
in the past, we would not want to spend a bunch of money on 200 Meg circuits
because if one is just
sitting there idle, then I'm wasting that amount of bandwidth. So instead of
what we might see here,
I say, you know, maybe instead of going 100 Meg to get me 100 Meg of throughput
and then 10 Meg
as a backup, which by the way puts me in a really bad situation on the day I WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
as a backup, which by the way puts me in a really bad situation on the day I
have to fail over,
because all of that throughput is now being squeezed into a much smaller
bandwidth circuit.
Usually that means I have to disable some amount of services, but now I could
actually say,
"Alright, let's not do that. Let's do a 75 Meg connection to one and a 75 Meg
connection to another,"
or maybe even a 50 Meg connection. But the idea here is I can still get my 100
Meg of throughput
that I needed by load balancing. In fact, I can get 125 of that 125, which is a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
that I needed by load balancing. In fact, I can get 125 of that 125, which is a
way better ratio,
even than this was, and it gives me more throughput. And it still gives me a
lot of throughput on a
redundancy situation where I actually end up failing one of these links. And so
it does afford
the ability for me to now cost justify a much better backup link, even though
it's not necessarily
backup anymore because I'm actually using it for production traffic. So
regardless, we do stuff WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
regardless, we do stuff
to decide how we're going to load balance it. And so we have four different
options here. We could do
just what's known as active active load balanced, which means that we're just
going to divide our
load between the two circuits. We can also do active active weighted, giving
weight to one over
the other and allowing me to direct more traffic through one of those circuits.
But here's where things
start to get really interesting. We can also do an active standby methodology. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
start to get really interesting. We can also do an active standby methodology.
But this is based
on application and specifically it's called application pinning. What this
means is I might have
application A down here and I'm going to statically pin it to this link and
then application B goes out
this link. So from application A application A is perspective. This is active WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
this link. So from application A application A is perspective. This is active
and this is standby.
But from B's perspective, the right is active and the left is standby. That
should be an S. There we go.
So now if this link goes down, application A can fail over to the other side.
And that's why we call
active standby. Even though we're leveraging both circuits, we're looking at
things specifically from
one application's perspective. Now lastly, this is where it gets really fun. We
can use application WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
can use application
aware load balancing in order to optimize our traffic paths based on the
metrics that we're seeing
via service level agreements or SLAs. Now here's the crazy thing. These method
ologies are not global.
I don't actually get into v-manage and say, okay, this is just how I'm going to
do this. This is
configured per application. So I could have some of my smaller applications WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
configured per application. So I could have some of my smaller applications
just to use something
basic like active active load balancing. But then when it comes to my more
sensitive applications,
maybe I go application aware to make sure that I'm paying attention to the
state of these
WAN circuits so that if there's a problem with one, even though it's online, I
end up failing over.
But here is an interesting question. If I can apply policy on a per application
basis,
like what I have here with application A and application B, well, these packets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
like what I have here with application A and application B, well, these packets
arrive on the
router just like every other packet. So how does the router know which
application is which? Or maybe
I should say which packet belongs to which application? Well, we have several
different ways,
and two different ways of analyzing this. So we have to concern ourselves with
application
identification. The first way to do it is by performing a matching of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
identification. The first way to do it is by performing a matching of
parameters, which is going
to sound familiar because this is actually how we do it with net flow as well,
just with slightly
different parameters. Cisco SD-WAN is going to use a six-touple of information,
meaning we have six
different pieces of information. We're going to extract out of a packet to
figure out and identify
which application it belongs to. So the six-touples going to include source
destination IP address,
source and destination port. So that's four of them, by the way, source and WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
source and destination port. So that's four of them, by the way, source and
destination for each.
Then we look at the DSEP value, which is for QOS, and the protocol number would
be our sixth.
And the idea here is generally speaking, if I have two packets that have the
same information here,
so this packet, packet one and packet two, if they have the same information,
then these are
likely part of the same application. That's what we're hoping. Now it's not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
likely part of the same application. That's what we're hoping. Now it's not
going to be 100%
accurate because you might just happen to be talking to two different servers,
two different applications,
well, same server, but then same port potentially, two different applications.
Maybe it's
netted. There will be situations where we don't quite get as granular with the
application
identification. So as a result, we can also leverage Cisco's deep packet
inspection
or DPI. Deep packet inspection has been around for a long time on Cisco devices WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
or DPI. Deep packet inspection has been around for a long time on Cisco devices
, and it was a
technology that they were able to bring into this whole SD-WAN equation when
they acquired the
solution. And the idea here is that Cisco has a database of thousands of
applications,
and it can look at a packet and perform a level of pattern matching to figure
out which application
it likely belongs to. And this is going to be much more accurate because it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
it likely belongs to. And this is going to be much more accurate because it's
going to look at the
actual application that the traffic belongs to rather than just collecting a
bunch of data and
hoping it's all the same. This also enables a little bit more in the way of
analytics so that we can
take this information, submit it to NetFlow. We can run data queries via REST
APIs,
and there's just a lot more information that we can glean out of this. Now, at
the time of this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
the time of this
video, DPI is a licensed feature, meaning that we have to pay extra for it if
that's what we want.
And so keep that in mind that even though DPI's packet inspection is generally
speaking
superior, we might need to pay a little bit of extra in order to gain access to
it. In the meantime,
if we don't want to pay for that, we can still leverage this 6-Tupel method and
still achieve our
load-downs in goals. Now, the result of all of this is pretty stellar, really, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
load-downs in goals. Now, the result of all of this is pretty stellar, really,
because now we can
identify our links by purpose. We don't have to worry about it just being
primary and secondary
anymore. For example, I could have a high throughput, but a low reliability
circuit like the internet,
and I can send my bulk data needs across it. So we're talking about bulk data.
We're usually talking
about major file transfers, maybe accessing file servers, downloading things, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
about major file transfers, maybe accessing file servers, downloading things,
all of that. I can have
this type of circuit and send those types of applications across that circuit.
Meanwhile, I could
still have that low throughput high reliability circuit type like an MPLS or
something along those
lines, and I could send my voice over IP through that. We don't have to worry
anymore about trying to
deploy complicated source-based routing, policy-based routing policies onto our
routers and making
sure we're managing that everywhere. Instead, I just have to configure this in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
sure we're managing that everywhere. Instead, I just have to configure this in
V-manage as a policy.
And again, thanks to the architecture that exists via the V-Smarts and the OMP
propagation of information,
that policy I define will get pushed out and we will be able to take advantage
of this load-balancing
methodologies.