So what we're going to do in the lab is we're going to set it up so that our host at site 11
is basically, we're going to pretend like it's generating only voice over IP traffic.
So we're going to apply an application aware routing policy that takes traffic from that host.
That's how we're going to identify it. Again, we don't have real applications running in the lab.
We just basically have pings. And so any traffic coming from that host, we're going to treat it
like it's voice over IP. And we're going to find that it will use the MPLS link first.
And if there's performance problems, then it will fail over to the internet link. And we'll find
that other traffic is load balanced, whereas that is no longer load balanced. It's going to be using
our application aware routing policy. And the cool thing is we're going to actually demonstrate
that using a traffic simulator that's built into our SD-WAN to a manager here.
So we're logged into manager, and we're going to go to configuration and go to policies.
And again, we're going to be creating a centralized policy. We've got a bunch of
centralized policies here. Our custom topology, if you're proceeding through this course sequentially,
you might already have this in place like I do. We have the option to deactivate it here. We'll
just replace it later with a different topology. But again, keep in mind that a centralized policy
has a lot of subcomponents. It has a topology in there. It has a VPN membership policy. It's
going to have application aware routing. And so we've got to make sure that when we create a
policy to push out, because we get one that has everything in there that we desire. So in our case,
we will replace the custom topology with this application aware routing one,
just because we're going to create a new centralized policy rather than modifying
the existing one. So let's go ahead and do that. We're going to click on add policy here.
And as always, we get placed into this creating groups of interest section. And right at the top
here, we're going to find application lists. So this application list is what we talked about
here. I'm going to see, for example, that I've got a list called app bulk data, and it's got FTP
and FTP data in there, which is cool. We also have Google apps. And if I click on this entries right
here, I can see all of the different apps that Cisco has placed into this application list.
So again, these are individual applications, and then they belong to an application list called
Google apps. Notice there's Google apps, Google workspace, Microsoft apps, real time applications,
and including SIP and RTP and skinny. Those are all protocols we might see in use in the voice
over IP world. And so Cisco gives us a lot of not only applications defined in here,
but also application lists that are a collection of these applications. So that's important to
recognize that those are there. Now, for our purposes, we're going to create a prefix list.
And our prefix list here, actually, we're going to do a data prefix list. So we're going to create
a new data prefix list. We're going to call this host at site 11. So we'll just call this host 11
might as well. And then the IP address for this host is 10.10.11.50. And it's a slash 32. So again,
we're going to use this to identify our call it an application with air quotes. But it's essentially
saying that this is a this is what we're going to use to apply to our application aware routing
policy. Now we're not done because we also need to create an SLA class. Again, this is the big one
that we're going to want to use Cisco or that we're going to need to create. Cisco has given
us quite a few options here, such as best effort and bulk data. And we'll see that our three metrics
are, whoops, I didn't mean to do that. Oh, well, loss, latency and jitter. So what percentage of
packets can experience loss, what the latency is, what the jitter. And so we see that for voice and
video, for example, that we can have up to a 2% packet loss, 300 millisecond latency, and a 60
millisecond jitter. Jitter is very important in the voice over IP world. We then have real time
applications, which are even a step above. And we might even want to apply this policy to our voice
over IP traffic. For our purposes in the lab, we're going to create a new class list. And we'll
just call this VoIP or voice over IP. And we'll go ahead and say something like a loss of 1%,
latency of 50 milliseconds. That's very strict. Jitter of 15 milliseconds. And then we also have
this interesting option for fallback best tunnel. So one thing we need to be aware of is that when
performance drops, Cisco's SD-WAN architecture needs to know what do we do with our application
now that performance doesn't meet the SLA class requirements. In other words, I'm on the MPLS link,
we've just experienced a loss of 2%. So what do we do with this? The default behavior is to say,
okay, I'm just going to load balance this across all the remaining links, because as long as those
links are not, or maybe I should say it like this, as long as all the other links are meeting
the same performance levels, they will be eligible for me to load balance across them. And for the
most part, that's perfectly fine. But if I wanted to, I could say, hey, find the next best tunnel.
And then I create based on, there we go. So I check this box and I set a criteria for the order
of operations. Basically, do I care more about loss than jitter? Do I even care about jitter?
Do I only care about loss or latency? And then I set my variance based on that and basically saying
how much better does it need to be than other tunnels to be considered? So that's the idea of
an SLA class fallback option. But again, if we don't set a fallback option, it will just load
balance across all of the eligible links that exist. And that's usually good enough. So I'm
going to click add here. So now we have created a data prefix list. We've created an SLA class.
It is now time to scroll down and click next. Now again, I'm creating a centralized policy.
This is my opportunity to add a topology, to add a VPN membership policy, but I'm not going to do
those things. I'm just going to click next. And now we're taken to configure traffic rules. We've
been skipping this step, but now it's time for us to take a look at it because right here is
application aware routing. So I can add a policy. Now, if I already have created a policy, I can
import it. Otherwise I can create this and we'll just create a brand new one here and apply it. So
we're going to create this policy. We'll call it VoIP AAR. And it's AAR for voice over IP.
And again, this is going to feel like a route map or, you know, at least similar to the custom
control policy we created. I'm going to add a sequence type. Remember before with a custom
topology, it would say, well, what type do you want? Do you want a route policy? Do you want a
TLOG policy? But we only have one option here. It's an app route. So it just adds it in for us.
And now I can add a sequence rule. And now we have the match action concept here that we've had in
the past. So what am I going to match on? Well, traditionally we'd probably apply the match to
an application or an application list, but I can scroll all the way over here. So I could match on
DSCP, for example, match on specific protocols, ports, destination source ports, but I can also
do destination. Whoops, not destination. That's not the right one. Source data prefix. Let's clear
out the destination. Now we're going to say, again, we're applying this to edge 11. We're
saying any traffic we get in from host 11. So there we go. We picked host 11. That's what we're going
to match on. So we're going to pretend like that's just cranking out voice over IP packets.
Now I'm going to click on action. And now I get to pick what action I want. And again,
the proper thing to do here is to select an SLA class. So I'm going to pick this and let's go and
scroll down and take a look at this. So from the class list, I can pick one of Cisco's or I can
pick the one that I configured voice over IP here. I can take my preferred color to say, hey, which
link do I prefer? I'm going to select MPLS. So my preferred color is to use MPLS. And if I had the
option or if I'd configured the fallback, I could click this. But if I try to save this, it'll say,
hey, wait a second. This SLA class doesn't actually support that. So we're just going to
leave this on load balance. So if the SLA is not met, by the way, this is a really interesting
option. We can say, you know what, even though the link is still up, even though 98% of our
traffic is going through, let's just drop the traffic. That would be if we have built in,
you know, like application level failover. Like I've got a server at this site and if it's not
working, I just want to stop sending traffic because another server somewhere else will pick
it up, that application level redundancy. So there might be some use cases for that, but just be
aware of what's happening. If we click that link again, we're just going to say load balance across
all the remaining links. And remember, even though there's this big blue button down here
saying to save, we need to save match and actions first. So again, this looks very familiar to what
we've done before. We have a match, whoops, a set of match conditions here. We have our actions,
which is matching against an SLA class. And that is how we put together our sequence rule.
Now I could create more sequence rules here. I could have additional applications and other SLA
classes. So all of that would go into this application aware or really application route
policy, if that's what I desire. There is a default action over here. Notice that we're
basically saying that we're not doing anything. We're not matching against an SLA class, but I
could click edit here and I could say, Hey, let's just do a catch all for all the rest of my traffic
I'm not matching. I could match it to an SLA class list if I wanted to, but we're just going to say,
no, we're not going to worry about it. Just treat all other traffic as if we're not paying
attention to the performance of a link. So now I'm going to save this application aware policy.
And now this policy is here included in this centralized policy. As with all the other things
that we've talked about, we can manage individual application aware routing policies using those
custom options at the top. And we could delete them there if we end up not using certain policies.
So from here, I'm going to click next. And now we named the centralized policy. I'm not sure why we
do that at the end, but we're going to call this, I don't know, something like centralized policy AAR.
And then this would be a policy with AAR. All right. So now we're not done yet because we've
got to click down here and say application aware routing. Remember, we have to apply a site list
and a VPN list, just like we do with our topologies and such. I'm going to click this
and I'm going to add a site list here that says we're applying this to site 11 edges.
And this is going to impact VPN 10 traffic. So now, again, lots of blue buttons down here,
like it says save, but I do have to remember to click add here to get them into the list.
And now I can click save policy. So I have now created a centralized policy. It has AAR inside
of it. The only thing left to do now is to activate it. So I'm going to activate this list,
but again, or this policy, but just keep in mind, I'm going to disable this policy.
So we should expect to see a bunch of our configuration being removed. When I look at
the controller and I look at the config diff here and scroll down, we're going to find that we're
removed. Well, first of all, let's look at what we're adding. We're adding an SLA class with the
metrics that we defined. We're defining an app route policy, again, matching this VPN list.
And then with the sequences that we said, we're matching against this data prefix list. And then
we're setting the action to use a preferred color and an SLA class that we have defined.
There's our VPN list. Now here's where we're starting to remove things. Remember,
we had a TLOC list in place for our custom topology and such. So that policy is truly
getting removed and we're putting in the new policy. So here's everything that's being removed,
which is expected. So I'm going to say activate, and we would expect this to get pushed out to
our SD-WAN controller or our vSmart. And then it's going to push it out to the new policy
down to our edge devices. Again, vManage or our manager, we're configuring this here and it pushes
that policy via NetConf to the SD-WAN controller. It's that API that's really used between network
devices. But the controller is not pushing config down via NetConf. It does everything via OMP.
And so again, it's not pushing control plane information via route types. Instead,
it's embedding that configuration into an OMP update message. Kind of interesting there.
All right. So now let's go ahead and verify. How are we going to verify this?
Well, SD-WAN's manager interface here has a really cool traffic simulator that we haven't used yet.
We go to monitor, and then we're going to take a look at our devices.
And from here, I can click on one of our devices like Edge 11. And when I scroll all the way down,
I'm going to find a troubleshooting link. So I'm going to click that. And then we get these options
here. Oops, let's clear that. Where it says over here on the right traffic, I can simulate flows.
This is kind of cool. It's going to allow us to, we could change device here if we wanted to,
but it's going to allow us to enter a bunch of information and see what happens.
So let's pretend like we're at Edge 11 here on VPN 10. And my source interface,
I'm receiving this traffic. And the source IP address, let's say, is our host. Now,
the destination IP address, we'll just say that we're sending it somewhere at site 12,
so the .50 host there. And we can leave application blank since we used a prefix list.
So I'm just going to say simulate this and notice what happens. Okay. So this host sends traffic
and it's going to use MPLS. Kind of interesting. Okay. That's great. But what does it look like
if it comes in from a different IP address? Like what if it's coming in from like a .60,
something that doesn't match our prefix list? Well, at this point it gets load balanced between
the two. So there's a big difference here. We see that our normal traffic, if we want to call it
it coming from that host, is only using MPLS so long as the performance is good. So it appears
that our policy is working, which is great news indeed.