- In this video we're going to take a look
at how we can configure and apply
a quality of service policy to a Cisco router.
And the way we typically configure quality of service
is using a three-step process.
This is called the MQC process
for Modular Quality of Service Command Line Interface.
So MQC.
The three step process begins with the first step,
which is the creation of class maps.
You might remember from a prior video,
we discussed how Cisco recommended
that we create no more than 11 different categories
of traffic in which to place our traffic?
Well, those categories are created with class maps.
So let's create a few of them here,
let's go into global configuration mode
with the configure terminal and let's create a class map
that's going to match email traffic.
Now, with email traffic, we have different protocols
that will be categorized as email.
We've got POP3, and SMTP, and IMAP, and Microsoft Exchange,
I want to be able to match any of those.
So I'm going to have multiple criteria within this class map
to sight match any of those.
And it's important to know if you're trying to match
on more than one characteristic,
there's some Boolean logic at work here.
Let me show you what I mean
with some context-sensitive help.
We can do either a match all or match any.
And here's a huge point.
The default is match all,
meaning that if I say match POP3, match SMTP, and so on
and so on, in order for a packet to be categorized
in this class map, it would have to match
all of those criteria.
And that's not possible, we can not have a packet
simultaneously be a POP3 packet and an SMTP packet,
what I need to do in a case like this
is to use the other logic of match any.
If I match any single criterion, then the traffic
is going to be placed in this class map,
so I'm going to say class-map, match-any,
and I'm going to give my class map a name of
let's say email.
And you don't have to make it uppercase,
I think that's a best practice to make things
that you create, things that you're giving a name to
within Cisco IOS, I think it's good practice
to make those uppercase, that way when you're
looking through the configuration, you're going to be able
to see something in all uppercase and you're going to say,
oh yeah, that's something that I created.
That's not some sort of a Cisco IOS keyword.
Now, notice I'm in class map configuration mode,
and there are lots of ways that I can match traffic.
I could match based on existing quality of service markings,
I could match based on the ingress interface,
so many things.
But here's my favorite, though, it's match protocol.
And if we give some context-sensitive help here,
you'll see that Cisco IOS automatically knows how
to recognize a plethora of protocols, including
all the different email types that we're looking for.
So what I'm going to do is say, match protocol,
and I'll follow that with POP3,
and I'll give the command again, this time
I'll follow it with SMTP, then we'll do IMAP,
then finally we'll do Exchange.
And we've created our first class map.
And let's exit out of that class map configuration mode.
Let's create another class map for voice traffic,
if we want to give it high priority treatment,
we talked about the low latency queuing approach
where we could put voice and maybe video traffic
in a priority queue that gets to go first,
let's recognize that voice traffic.
I'm going to say class-map, and I'm going to recognize
voice traffic, so I'll call the class map voice.
Now notice, I did not say match any or match all.
And that's because I'm only going to give one match statement.
There's nothing to compare it against, so the Boolean logic
really doesn't matter in a case like this
where I just have a single match statement.
Now I'm going to say I want to match the protocol
of rtp, remember we talked in a previous video about
the real time transport protocol that carries the voice
and also the video media, and we could stop right there,
but this match statement would actually
match voice and video.
If I wanted to just get voice,
I could be specific and say rtp audio.
And let's exit from that class map configuration mode,
and create another class map, I'll say class-map.
And this will be for our more undesirable traffic.
I'll call it our scavenger traffic.
And let's say that we want to recognize maybe
BitTorrent traffic, and yes I know that a lot
of companies use BitTorrent for very legitimate
file transfer purposes, but come on,
some people don't use it for those purposes.
So let's say that in our particular business model
we don't want BitTorrent, or we want to limit it, anyway.
I'm going to say I want to match the protocol of BitTorrent.
And we'll say that that's enough class maps for now.
That was step one of MQC, the creation of class maps.
Let's go onto step two,
which is the creation of a policy map.
In a policy map, we're going to go into policy map
class configuration mode for the different classes
we created, and we're going to say what kind of policy
we want to apply.
So let's create a policy-map statement,
and we'll call the policy map demo.
And if I give context-sensitive help, you'll see
not much happens within policy map configuration mode,
the real magic happens within
policy map class configuration mode.
I'm going to say class followed by one of the class map names
that we just created, let's start with email,
and notice we're now in pmap-c, that's policy map
class configuration mode, and this is where we apply
most of our quality of service policies.
This is where I can turn on policing or shaping,
I could do marking,
I could do class-based weighted fair queuing,
or low latency queuing.
Just about everything can be done,
quality of service wise in this configuration mode.
And for the email traffic, I don't want it to be
priority traffic, but I want to give it a certain
bandwidth guarantee during times of congestion,
and let's say that I decide on 512 kilobits per second.
I'll say bandwidth 512.
Now what that means is during times of congestion
I guarantee that this traffic is going to have
at least 512 kilobits per second of bandwidth
available to it, if it needs that much.
And more, if it needs more, and more is available.
Now let me say that again, I worked really hard
on getting the wording very specific there.
I'm saying with this command that we want to guarantee
that even during times of congestion that this class
of traffic can have at least 512 kilobits per second.
A lot of people think when I type that command in
I'm limiting us to 512 kilobits per second.
That's not the case.
This is my minimum bandwidth guarantee.
But I said I'm going to guarantee that we can have
at least that much if we need it.
If we don't need it, we can let somebody else use it.
Remember, this is not the strict QoS model,
this is the less strict model, this is the DiffServ model.
So if we don't need bandwidth for this class map right now
we can let somebody else have it that might need it.
So we're going to guarantee at least this much
bandwidth if it needs it, and more if it needs more
and more is available.
And now that I've turned on
class-based weighted fair queuing for this class,
I can then optionally turn on
weighted random early detection.
And I say I can now turn it on because before you can
configure weighted RED for a class like this
you first have to either configure class-based
weighted fair queuing, or shaping.
And I've configured class-based weighted fair queuing,
so now I can, if I want to, configure weighted RED.
And to do that, I'll say random-detect,
and if I pressed enter right there, that would
turn on weighted random early detection,
and we talked about the different thresholds
that we have with weighted RED,
we're going to say for a particular priority marking
there's a minimum threshold, let's say it's 20 packets
for a particular marking.
And until the queue depth gets to 20 packets,
then we're not going to be dropping any of those packets
marked with that priority value.
But once we exceed 20 packets in the queue,
then we're going to introduce the possibility of discard.
And that probability that we're going to discard a packet
is going to increase, and increase, and increase,
until we get to a maximum threshold.
And if we surpass that maximum threshold,
there's a 100% probability of discard for that marking.
Now, just by saying random-detect and pressing enter,
it will do what I just described, but it will do it
for the older IP precedence markings that use only
three bits for a marking, not our DSCP markings
which use six bits, which is probably what we're going to
be using today, so it's important that we,
in most cases, say DSCP-based.
That's going to apply default minimum and maximum thresholds
to specific DSCP markings.
Let's now configure our voice class.
We'll say class, space, voice.
And I do want this to go first, I want to give it
priority treatment.
I'm going to say priority 256.
And what that says is traffic in this class
gets to go first and it can use as much as 256 kilobits
per second of bandwidth, but no more.
So unlike class-based weighted fair queuing
where we said we can have more if we need more
and more is available, we don't want our priority traffic
to potentially starve out anybody else,
so not only are we saying yeah, you can have as much
as 256 k, you can have no more than that,
because we don't want you to starve anybody else out.
And here, I'm putting voice traffic in a priority queue,
what if I had another class map?
We didn't create it, but what if I had
another class map for video?
For video, I could say priority 512, perhaps.
What would that do?
Would that put it in a different priority queue?
Now here's another huge point.
There is one and only one priority queue.
And if we put both voice and video into a priority queue,
they're sharing the same one and only priority queue
that we have.
All right, let's go into our scavenger traffic now,
the traffic that we're not particularly fond of,
I'll say class scavenger,
and here I want to set a speed limit on how much
bandwidth we can use.
And I can do that with policing or shaping.
Cisco recommends we use policing on higher speed interfaces
and I'm going to be applying this to a gig interface,
so I'll use policing, and we'll say police,
and there's lots of options that we can play with here,
but just the default behavior is this.
The units of measure are in bits per second, by the way,
not in kilobits per second.
I'm going to say police 128,000 bits per second,
so 128 kilobits per second.
And just by pressing enter, without giving
any other parameters, here's what that does by default.
It says that traffic in the scavenger class
that tries to exceed 128 k, it's going to be dropped.
Traffic that does not try to exceed 128 k,
it's going to be allowed.
And that's the creation of policies for
the class maps we created.
By the way, there is another class map
I didn't tell you about.
By default, we've got another class map
called class-default.
It's there by default, we didn't create it,
we cannot delete it, think of it as the catch-all class map,
if we don't specify traffic to go into one of our class maps
then by definition it's going to go into the class-default
class map, so when Cisco says don't create any more
than 11 classes of traffic, we could still have
12 classes of traffic.
The 11 that we create, plus the class-default
that's there by default.
And the best practice recommendation for that
class-default class map is to turn on
something called weighted fair queuing.
Now that's an older queuing mechanism,
but it tries to make sure that no one data flow
takes over and dominates the available bandwidth,
so it's generally good practice to turn that on
within this class that we didn't even create.
And we can go into that class map by saying
class, class-default.
And I'm going to say fair-queue.
That turns on weighted fair queuing.
We've now done step two of MQC
where we've created our policy.
Now let's apply our policy.
Let's go into interface gigabit 0/2,
and we typically apply a policy to an interface,
and the way we do that is say
service-policy, and we can say are we applying this
as traffic is coming into this interface,
or as traffic is leaving the interface?
And it's important to note that some of our quality
of service mechanisms don't work in either direction.
For example, I've configured class-based
weighted fair queuing, and that's only going to work
in the outbound direction.
So I'm going to say, service-policy output,
and the name of my policy was demo.
And we're done.
Now, to verify this there are different verification
commands, you can do a show class-map,
a show policy-map, but my very favorite,
and probably the most powerful command
to do our verification in show policy-map interface,
followed by the interface identifier of where we
applied the policy, we'll say 0/2.
And notice the output that we get.
It tells us the different classes we created,
it tells us how we categorize traffic into those
different classes by matching POP3 or SMTP or so on,
and we can see if we have any traffic, now here
in this demo network I don't have traffic passing through
this interface, but if we did, we would be able to see
actual packet and byte counts, to indicate that traffic
really is being queued into these different queues.
And that's a look at the three step MQC process
for quality of service configuration.