A huge advantage that Cisco's SD-WAN solution gives us is this concept of what we call
Application Aware Routing. And we do see this abbreviated as AAR.
But it's time to talk about what exactly this feature is and what big advantage it actually provides.
And a lot of what we're going to be talking about here has to do with the concept of a service level agreement or an SLA.
So what happens here in most networking topologies when we've got redundant paths is that let's say we've got a PC here
and we know that we've got maybe an upstream path to each one of these routers.
Maybe we're running HSRP and each one of them has some kind of upstream circuit.
So in our case, maybe these are wide area network circuits.
And so let's say that we're taking this primary path for our communications.
And we know that we're running some kind of routing protocol. Maybe it's an IGP, maybe it's BGP, something like that.
Yeah, EIGRP or OSPF would be IGPs.
But either way, we know that this routing protocol is going to be really good at recognizing if this link goes down to make sure that we fail over to the other link.
That part is taken care of for us. We're in really good shape thanks to this routing protocol.
Something this routing protocol doesn't do a really great job of is when we're recognizing when we have some kind of network impairment.
Here, this link becomes impaired.
What are we talking about with impaired?
Well, the performance is down. And so usually it comes down to something like we have loss on the line.
Maybe we have some extra latency.
So if this is a WAN circuit to a service provider, maybe its router upstream is overloaded.
It's dropping packets like crazy, something along those lines.
Jitter is essentially when latency goes from high to low to high to low.
If latency is constant, even if it's a little bit longer than we want, it's usually tolerable.
But if we're on a video call or a voice call and the latency is just going up and down and up and down, that really does cause a lot of problems.
So this concept of impairment is not addressed by our routing protocols like EIGRP and OSPF and even BGP.
So what happens in this scenario is we're going to continue to use this link even though it's really not a great experience for our end user and the end user ends up suffering.
Now Cisco, in the world of iOS XE, they have a solution for this known as IPSLA.
Again, SLA stands for service level agreement.
The idea here is that we're establishing a set of metrics that we want to abide by.
It's almost like I'm entering into a contract with somebody.
I'm establishing a service level agreement.
And if you don't abide by this, if you don't give me the quality that I'm signing up for, then I'm going to take my services elsewhere.
Well, same concept here.
If this link isn't giving me what I want, then I'm going to take my service or my, well, yeah, I'm sure I'm going to take my traffic to this other link.
And IPSLA does exactly this.
And let's say that I fall below a certain metric.
Well, at this point, I'm going to trigger some kind of failover.
So that's cool that Cisco has this in iOS XE.
But as we know, Cisco's SD-WAN product was actually developed by a completely different company who didn't have access to this solution.
So Viptela doesn't have access or didn't have access to IPSLA.
Instead, they developed Application Aware Routing.
And Application Aware Routing is sort of, in the end, going to have the same results as IPSLA in that it allows us to switch off of a link when it's in an impaired state but it's not actually down.
But it's going to operate in a little bit of a different fashion.
It's going to take advantage of the SD-WAN architecture.
And when we really dive into the SD-WAN architecture, we know that we're running bidirectional forwarding detection or BFD under the hood.
So what exactly does this look like?
Well, if I have a router here, an edge device, and I have another edge device over here, we know that we're running a tunnel this way and we're running a tunnel this way over, let's say, two different infrastructures.
And inside of this tunnel, I am running BFD.
Now, our focus on BFD has been to detect outages very, very quickly.
So we have outage detection. Great.
That is exactly what we're getting over in the legacy side of things by running routing protocols across our wide area network links.
But we know that in SD-WAN, we're not really doing that.
Instead, we are running BFD that sends very fast probes that very quickly detect an outage.
Namely, we can use it to track these metrics over here that we keep referring to.
Furthermore, because of the SD-WAN architecture, it's not just BFD.
It's also the fact that we have so many tunnels.
We have lots of redundant paths, and so there should be the possibility in most cases that we have a higher performing link somewhere on this edge.
We drew it with two tunnels here, but we might actually have crisscross here.
So we've got tunnels that are going back and forth this way, and certainly we might have dual edge sites,
and we might want to go through a different edge altogether.
So what we're going to do is we're going to deploy an application-aware routing policy,
and this policy is going to go here.
It's going to be distributed onto the edge, and so it's going to recognize when a certain application comes in that's critical.
For example, let's say it's voice over IP.
That happens to be one of the most common scenarios of identifying an application that needs special treatment.
So this policy is going to recognize when this application comes in, and it's going to, first of all, pick a preferred link.
So this is choice number one, but because we're listening to BFD,
and we might recognize that things fall below a certain threshold, which is what this policy defines for us,
We're going to define thresholds as part of our application-aware routing policy,
and if those thresholds aren't met, then we can redirect out a backup link.
So what type of policy is application-aware routing?
Well, we just said it's impacting data plane traffic.
As a result, it is certainly a data policy.
But is it centralized or localized?
Well, this has to do with whether or not the controller is involved, and indeed, in our case, the controller is actually involved.
We, as the admins, will push a policy to the controller via manager,
and this will get pushed out to all of the different edges and get those policies installed.
As a result, this is actually a centralized data policy.
We don't see a whole lot of centralized data policies because things like access control lists are localized.
They're a per-edge type of policy.
But in our case, this is a centralized data policy.
I'm creating just one policy, and I'm pushing it out to all of my edges,
and we'll see how that's configured coming up here as we jump into the lab.
Now, I want to end here with just a real-world application for this because, on the surface, yeah, okay, this is really cool.
My voice over IP can take whichever link is going to be best, but in most cases, if this is, let's say, MPLS,
it's probably usually going to be relying on MPLS, and then that once every two or three years when MPLS isn't quite behaving well,
there's a problem with the service provider, then we might rely on the Internet instead for a brief time.
But this actually goes beyond this exact topology that we have had in our lab where we have an MPLS link and an Internet link.
But it's that 1% of the time that is a big problem, especially if it's in the middle of the working day or whatever the situation is,
and as a result, we don't want to put voice over IP over an Internet tunnel because of this problem here.
But what if I can switch back and forth dynamically when I'm having a problem on an Internet link?
And what if I also had two Internet links?
This is where Viptela and now Cisco from an SD-WAN perspective have been going to customers and saying,
hey, rather than having an Internet circuit and an MPLS circuit, why don't we run two Internet circuits,
as high quality of Internet circuits as we can from two completely different service providers,
and now we can run voice over IP over this connection.
We'd say, well, whoa, whoa, whoa, we're never supposed to run over the Internet.
But again, if this Internet is 99% good and this Internet circuit is 99% good,
the amount of times where they're both having problems, as long as they're completely different service providers,
it's going to be a really rare day, almost as rare as this MPLS and Internet situation.
And so now we could actually leverage both of these via application-aware routing,
and not only for voice over IP, but for other critical traffic, whatever that traffic looks like for our organization.
At a minimum, video conferencing and such would fall into there and other real-time applications.
But in the end, we can actually save a bunch of money, reduce our costs,
because an Internet circuit is immensely cheaper compared to an MPLS circuit.
Now, is this the right fit for every organization? Absolutely not.
Definitely not coming in here and providing free consulting.
I'm just providing a little bit of context around how this works in the real world,
because a lot of organizations do choose to go this route,
which gives us many different options, and the application-aware routing component
makes it so that our applications will always use the highest performing link.