Well, as mentioned, we are going to use class maps in order to create our cues,
but we want
to be able to modularly use these to create policy maps.
And the policy maps are going to sort of be a template of sorts that go onto an
interface
and allow that interface to define its cues.
So if we say we want four different cues here, one, two, three, and four, well
then at that
point, the interface itself will use four cues.
As we've defined, whatever that looks like. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
As we've defined, whatever that looks like.
And so again, class maps focusing on the cues and specifically the match
statements which
define which traffic goes into which one of those cues.
But now that we've created the matching, it's time to shift focus here and look
at the actual
policy that we're deploying against the different cues.
So what types of policies are we looking at?
Well as we've mentioned, we want to be able to define whether a cue operates
with priority
bias.
And we need to simply know, are we going to apply this as a strict priority? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we need to simply know, are we going to apply this as a strict priority?
Or are we going to apply this in a safer way as a relative priority cue?
And that just means that it's not going to be strictly priority based.
Instead, we're going to still take turns, we're going to play nice, but
relative to the
other cues, we absolutely have some amount of priority.
We can also look at bandwidth reservations.
And this is going to be one of the most important parts of defining a proper WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And this is going to be one of the most important parts of defining a proper
policy.
The bandwidth reservation is going to, as we'll see, be able to be specified in
a lot
of different ways.
And what's interesting about this is I can apply this policy to two different
interfaces.
And this interface down here might be one gigabit per second and the interface
up here
might be 100 megabits per second.
So this is kind of curious because if I reserve, let's say, 10 megabits per
second in a cue,
well, that's a massive amount of the bandwidth for this interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
well, that's a massive amount of the bandwidth for this interface.
But it's almost nothing on a one gigabit per second interface.
And so we might find that we want to go percentage based, which is certainly
possible, but can
almost create the opposite problem, which is that, hey, I want to reserve, let
's say,
10% of 100 megabits per second for voice, well, that's reserving 10 megabit per
second, which
is a lot of bandwidth for voice already.
And if I say 10% of a gig, well, holy smokes now, we're talking about 100 megab WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And if I say 10% of a gig, well, holy smokes now, we're talking about 100 megab
its per
second for voice.
So it's one of the challenges for sure in creating real world QOS policies is
making sure
that our policies are going to map properly.
And even though Cisco does allow us to be so modular as to add a policy map to
different
interface types, in a real world situation, we're probably going to want to
make sure
we have policy maps defined on a per speed per interface type of situation.
So it's something to keep in mind. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it's something to keep in mind.
And yeah, in the real world, we might see less 100 meg and more one gig versus
10 gig
or maybe even a multi gig type of situation on catalyst switches, which is two
and a half
and five gigabits per second.
So either way, we've got other policies that we might end up deploying here.
For example, the conversation we had around policing and shaping, this is going
to be
a configuration that goes into our policies, which are put into the policy maps
.
We also want to specify our congestion avoidance thresholds, specifically for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We also want to specify our congestion avoidance thresholds, specifically for
weighted random
early detect red with the W there, we're going to need to define these
thresholds.
And because of this, we're going to want to have a place to do it.
Well, that's going to be in the policy map as well.
We can also define things like the queue length, the different devices that we
're configuring,
they only have so much buffer space.
And so maybe we want to shorten a queue or lengthen a queue. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And so maybe we want to shorten a queue or lengthen a queue.
And regardless of whether or not we're out of buffer space, just defining the
queue length
can change the way that our end user experiences are impacted.
And having a longer queue length doesn't necessarily mean that they actually
have a better experience
for what it's worth.
And then we might also want to look at some kind of option like remarking
packets.
And we talked about remarking our tags here within the context of policing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And we talked about remarking our tags here within the context of policing.
Like maybe you sent me too much traffic, so I'm going to inflict a discipline
or punishment,
I suppose, by remarking the packets.
Well, I can actually remark regardless of whether or not there's a policing
violation.
So packet could come in with one tag, a tag of 10, and it could leave with a
tag of 12,
something like that.
Maybe this makes sense at organizational boundaries.
If we acquired an organization and they're using different tags than us, then
we might
want to translate the tags as they come across a specific interface. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
want to translate the tags as they come across a specific interface.
So these are just some examples and probably the most common examples of
policies that
we want to deploy.
And again, the policies are going to be put into our policy map.
Now in a standard configuration, we're certainly going to have multiple class
maps because
we need multiple queues.
We might only have a single policy map on a device, because maybe that policy
is good
for all of the interfaces.
But because of the modular nature, again, I could define a second policy map WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But because of the modular nature, again, I could define a second policy map
here, use
the same class maps in this different policy map and apply it to a different
set of interfaces.
So we've got modularity stacked on top of modularity, and that's something that
we just
need to kind of keep in mind here as far as how all of this configuration comes
together.
So what's this going to look like?
Well, we'll jump onto the CLI here in a moment, but essentially what we're
going to do is
we're going to specify a policy map by name.
So whatever our policy name is going to end up being, and then we're going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So whatever our policy name is going to end up being, and then we're going to
use the
class command.
The class command allows me to specify which queue that I want to build here on
the policy
map.
And because we are matching based on tags, the order might or shouldn't really
matter
here, but in case we have any kind of conflict with matching, we might want to
pay attention
to that.
Either way, we're going to specify the class option here, and then we're going
to specify
the class map name.
So let's say that we want to match that or use, we want to create a priority WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So let's say that we want to match that or use, we want to create a priority
queue using
the one we made before, which was like DSCP_EF, for example.
So that could be the class map name that we specify here.
Now, notice we're not saying class map, we're just saying class.
In fact, if we say class map, then Cisco iOS tries to outsmart us and take us
back outside
of the policy map configuration that can get a little confusing if we're not
paying
attention.
So bear that in mind.
Once we've specified our class, now we get taken in and we can specify policies WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Once we've specified our class, now we get taken in and we can specify policies
.
So I could use, for example, the priority command to say, you know, I want to
make this a priority
queue and I want to limit it to 100 kilobits per second.
So a lot of our bandwidth configurations are going to be applied in terms of
kilobits per
second.
So if I wanted 100k, it'd be just 100 there.
If I wanted a megabit per second, well, I need to specify 1000, because it's
1000 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
1000
kilobits per second.
I can also use the bandwidth command here, which will allow me to do bandwidth
reservations
outside of a priority configuration.
And we've got some other options here as well.
But our focus right now is going to be on just building out a set of queues
that have
certain levels of prior or different levels of priority, as well as bandwidth
reservations.
Now remember what I said earlier about the class default, I don't have to
specify class WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specify class
default here.
But if I want to apply policy to it, then I'm certainly going to have to
remember this
exists on its own.
It already exists within a policy map that I create.
But what if I want to add some bandwidth reservations to the class default?
That's usually recommended.
I mean, Cisco recommends it.
And we definitely want to make sure that the bulk of our traffic in the network
is getting
some amount of bandwidth reservation.
So we might reserve something like 25% of the bandwidth on a link that might WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we might reserve something like 25% of the bandwidth on a link that might
actually
be very important in our environment.
And that is typically what we see with a lot of organizational QoS policies is
that the
class default does get 25% of the bandwidth.
Just keep in mind that this is going to contain all unmatched traffic.
And yes, that does mean DSCP zero in most cases, but it doesn't mean only DSCP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And yes, that does mean DSCP zero in most cases, but it doesn't mean only DSCP
zero.
This is my only two Qs that I created, well, then EF is going to go here, but
AF41 is going
to go here into the class default because I didn't build a Q or at least I didn
't apply
a Q to the policy map that specifies and matches this specific tag.
So all the assured forwarding PHBs for hot behaviors, those are going to filter
down
to the class default in this configuration because we truly only have one other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to the class default in this configuration because we truly only have one other
Q.
So just keep that in mind when we're evaluating configurations that the class
default isn't
just DSCP zero is all of the unmatched traffic.
And by the way, a lot of conversations around QoS will typically refer to this
as the best
effort queue.
So we can expect to hear that as well.
Now one thing we can do within the class default that we can't with anybody
else is remember
we can leave it as a FIFO queue or we can configure it with FairQ, which is a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
we can leave it as a FIFO queue or we can configure it with FairQ, which is a
reference
here to weighted fair queuing.
Weighted fair queuing is what we'll recall allows every traffic flow to have
its own mini
queue within the best effort queue here.
And this allows us to make sure that those traffic flows are treated fairly and
one traffic
flow can't just completely dominate the queue.
So this is a pretty common configuration as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So this is a pretty common configuration as well.
Now lastly, just as part of this conversation, we want to talk about service
policy.
So my service policy is going to take my policy map and map it to an interface
as we've said
several times.
But importantly, it actually is going to be specified as either an input or an
output
direction.
Now output is almost always where we're going to apply QoS policy because we
have more queues
going in an outbound direction. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
going in an outbound direction.
And that's usually where all the interesting things are happening because a
device that
brings traffic in the input queue is usually pretty short.
And there's not a whole lot that we need to worry about on the input queue side
of things,
although we certainly can't apply policy maps in the input direction.
Instead, usually our focus is going to be on the outbound direction because all
of this
traffic coming into a device might all get funneled to a single interface.
And now we have lots of packets queued up and ready to go. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And now we have lots of packets queued up and ready to go.
So that's why we want multiple queues in the outbound direction.
So syntax wise, we're going to say service dash policy.
And then we're going to say input or output.
And then we're going to have the policy map name specified.
So that is what we're trying to accomplish here.
We're trying to create that set of queues that has a bunch of policies WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
We're trying to create that set of queues that has a bunch of policies
associated with
it.
So we're going to create a policy map, apply it to an interface, including the
direction,
using the service policy.
And so at this point, it's time to jump onto the CLI and see it all in action.