So, how exactly does AAR, or Application Aware Routing, come together?
Well, we'll start with BFD, mentioning this again.
Bidirectional Forwarding Detection, this is what allows us to figure out what the performance of a link is.
Remember, BFD is running probes across a tunnel, and it's running it at a certain rate.
And so, we are paying attention to the fact that we've got these keepalives.
And if we drop a keepalive, then maybe the link is down, but then we get another keepalive, we say, okay, good, the link is up.
But what if we start tracking these keepalive messages?
Well, now, if we're tracking the keepalives, first of all, we expect keepalives to come in certain increments.
And so, if we don't get one, this contributes to loss, our first primary metric that we care greatly about.
Second of all, what if it's coming in increments, but all of a sudden, one of these messages takes a lot longer to show up,
and then kind of the next one comes, and then it's a long time to show up, and then the next one comes.
So, now, we recognize that we have latency on this link.
We're starting to see that it takes longer, on average, for these probes, these keepalives, to show up.
And furthermore, we can measure jitter, because jitter is just the change of latency over time.
So, BFD is absolutely at the heart of this.
We're going to rely on our BFD communications inside of our tunnels, which is all configured by default,
but that is how we're measuring our components from an AAR perspective.
Now, next, we have to start looking at the different objects that we have to pay attention to and create,
and we're going to need to talk about app routes, and this is usually hyphenated like this.
The app route is what gets pushed down from the controller to our edge device to install the policy.
Now, we might sit here and say, okay, well, that's great, except we already covered a lot of information about OMP,
such as the fact that there are exactly three route types.
We have the OMP routes, or the V routes, and then we also have the TLOC routes and the service routes.
But those are the only three route types, so is this now a fourth route type?
And the answer is no, this is not actually an OMP route.
Remember, this is something that's impacting the data plane, not the control plane.
And so we are pushing, essentially, config down to this device, and that's what the app route is.
It contains the configuration of what we pushed to the controller from our end on the manager side.
So how does it push it down?
Well, it does actually use OMP.
That's the interesting thing about this.
It's embedded into OMP updates, but because it's just configuration,
it's not something that we have to provide routing information for.
So make sure that we walk away from this conversation understanding we're not changing the rules to say that there are three OMP route types,
but we are using OMP to send the app routes down.
Yeah, I don't like this word route in here from that perspective because it feels like we are passing routes,
but there is a distinction to be made there.
Just remember that at the end of the day, this is going to be a centralized data policy that we're pushing to all of our edges.
So the centralized part because it's coming from the controller, the data part because it's impacting the data plane operations.
Now, next, we need to talk about how we actually configure application-aware routing.
These are kind of happening behind the scenes.
We don't need to directly configure anything here.
It's just understanding how this is actually functioning.
But when it comes to our configuration, we are going to need to become familiar with an application list.
So we're familiar with all these list types, VPN list, site list, TLOC list, color list, all these things.
But now we have an app list.
And really what we're saying here is that we need to identify the traffic types as a packet comes in.
So we've said that if a particular application like voice over IP or maybe some other sensitive application type is coming in,
that we want to treat it a certain way.
I want to send it out this way, but if performance falls, then I want to send it out this way.
So number one, here's our backup link.
And that's all great.
That looks really great in a chalkboarding session.
How does the edge know which application just came in?
Traditionally in our networking, all of our routing, it's only going to look at layer three information, which is really the IP addresses.
It's not going to go deeper than that.
It's just going to find out what the destination IP address is.
And, you know, even in our edge scenario, we'd encapsulate it and send it off.
So clearly we need to go deeper than layer three information in order to figure out what type of application is embedded in this packet.
Now Cisco's SD-WAN solution here gives us two options.
First of all, we can define an application by way of what we call a six tuple matching.
So the six tuple means that we're looking at six different parameters.
Those parameters are going to be source and destination IP address.
That would be two of these.
And then source and destination port.
That would be two more.
So now we're up to four.
And then the DSCP value, which is quality of service, as well as the protocol number.
So we're looking at these six different, these being two here, but we've got six different parameters.
And what we're essentially saying is that if two packets come in and they have all of the exact same information here, the source and destination IP address are the same, meaning it's the same host talking to the same destination on the same port,
meaning it probably has to do with the same application as well.
But let's go even deeper.
It's the same DSCP value.
That would especially be relevant for voice over IP and such.
And then the same protocol number.
All of that ties together to say that, yeah, this is probably tied to the same application.
But it is still a little bit of a, you know, we're probably going to see some overlaps at various times.
So the second option that we have is known as deep packet inspection or DPI.
So this goes, DPI is embedded on edges and it's aware of thousands of applications.
And it can very quickly identify it based on signatures and all the secret sauce that they use basically in order to identify what application a packet probably belongs to.
So the good news is that it's far more granular than the six tuple method.
So that's a good thing.
The bad news is that we actually need an additional license in order to use this.
Maybe I'll draw that as an up arrow for an advantage and a down arrow for a disadvantage.
So we do have to pay a little extra to get this from Cisco, but it usually is a really good idea to do that if we have a very large scale infrastructure.
If we don't have a large scale infrastructure or we're just really firing this up for the first time, we're not sure if we really need it.
Then we can certainly rely on the six tuple method.
Now, when we get into the configuration, we're going to find that an application list is sort of like a container and it contains a bunch of applications.
The idea here is that I want to treat all of these with the same policy.
So if I have a bunch of, let's say, Google applications, so maybe there's a Google list here, then these would maybe be all of the different Google applications that our SD-WAN architecture is able to pick up on.
And then we would apply a policy to our Google application list.
So again, we'll see that in more details here coming up, but be aware that an application list consists of applications that are identified by one of these two methods.
And by the way, first of all, Cisco provides a list of well-known applications.
And second of all, we can create custom applications as well, especially if we have homegrown applications with in-house developers.
But on the off chance that we're using something that Cisco just doesn't provide, then we can add it in as well.
Now, the last piece to this puzzle is the SLA class.
And this is probably the object we're going to spend the most time as admins configuring, because the SLA class is where we define all of our thresholds.
We keep talking about pushing an application-aware policy down that defines thresholds and tells the edge when to send.
So is a, let's say a 1% loss, is that bad enough that we need to fail over?
What about a 2% loss?
What about 30 milliseconds of latency?
Is that fine?
What if it's 50 milliseconds?
We as admins have to define these thresholds, and we do it as part of an SLA class.
This is actually part of the group of interest configuration, which doesn't fit quite cleanly into that phrase group of interest.
But it is where we're going to configure it inside of the manager UI.
Also keep in mind that when we're talking about these thresholds, it always has to do with these three thresholds over here.
We don't have a list of 17 different metrics.
Instead, we just have loss, latency, and jitter thresholds that we're going to want to define.
What does the structure of this end up looking like?
What it ends up looking like is we're going to create our app route policy.
The app route policy is going to be part of a centralized policy.
The more that we spend time in the lab, I suppose, configuring different policies, then we start to figure out how this all comes together.
We've got a centralized policy as a container, and we might throw a topology policy into the centralized policy.
We could throw a VPN membership policy in here.
Now I can throw an application route policy or an application-aware routing policy into the centralized policy.
If we create a brand-new centralized policy and deploy it, and we include application-aware routing, but we don't include the topology,
then the topology isn't going to be enforced.
Only the application route policy will actually be enforced.
If we want all of this together, it's got to go into one centralized policy because we get exactly one of these in the entire environment
because that's the policy that our SD-WAN controllers are pushing down.
This is just a small part of an overall centralized policy in the same way that the topology and VPN membership policies work.
When we open up this app route policy, we're going to find that this has the same structure of having match and action statements.
Just like we allude this or we relate this back to our route map concept, but a lot of these policies that we've created,
especially when we think about custom policies and various things, those all have these match action statements.
Matching, in the real world, we're going to match on our application lists.
That's the goal here. We want to match policy against specific applications.
In our lab environment, we can also do something as simple as identifying a prefix list.
That's what we'll do in our lab environment since we don't have real applications running in the lab.
At least I don't in my lab. Maybe you do in yours.
We can use any number of methods for identifying traffic here, and that's exactly what the match is supposed to be.
The action is going to point us to the SLA class, which effectively tells us,
hey, on this type of traffic, match these types of thresholds.
We'll have a failover option included in this that we'll talk about when we look at the configuration itself.
We also have to, in the end, apply this to a site list, and we have to apply it to a VPN list,
so that we know which sites are getting this as well as which VPNs are going to be impacted.
Those are also going to be part of the configuration, but that happens at the very end of our policy creation.
This is an overview of how Application-Aware Routing comes together.
What I would recommend is after we jump into the lab environment, maybe come back to this,
and now that we've got the configuration in mind of how it comes together,
this conversation starts to make even more sense to feed into each other
as far as understanding how exactly Application-Aware Routing comes together,
not just from a configuration and structure perspective,
but also what's happening on the back end in order to make it all happen.