So here's our goal. If we are going to perform a QOS configuration, we need to
be able to
configure a number of Qs that's going to go onto an interface. And we need to
also identify
the traffic that's coming into it. So this is our classification here. And we
're usually
going to use our DSCP tags or COS tags in order to identify our traffic. But we
could
actually use access control lists as well. So we could identify traffic sourced WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
actually use access control lists as well. So we could identify traffic sourced
from
a particular IP address and put it into a queue in the same way that we can
identify
traffic based on the tags. But it's not just about creating the cues. I mean,
yeah, we've
got to create all of the cues that are going to be put onto the interface. But
we also
have to identify the policies that are going to be in place. And there are
quite a few
policies to talk about in this skill, we're going to focus on our bandwidth and
our priority
organization status of these different cues. Now the way this works is we are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
organization status of these different cues. Now the way this works is we are
going to
create a template of sorts. So call this our QOS template here, and we'll learn
that this
is called a policy map. And we're going to look at a device like a switch or a
router.
And this device has a lot of different interfaces on it. Maybe it has gig 00
gig 01 0 2 0 3
something like that. And so what we can do is we can take this one policy map,
this one
set of policies, and put it onto as many of these interfaces as we desire, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
set of policies, and put it onto as many of these interfaces as we desire,
maybe three
or even all four of these interfaces on this device. So it's a modular concept.
I can not
only create a bunch of Q definitions here. So these are the cues over on this
side. But
I could also actually create a different policy. So this is a completely
different policy here.
But I take these cues as I've defined them by how I identify traffic. And I can WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But I take these cues as I've defined them by how I identify traffic. And I can
put them
into different policies and map those policies to different interfaces, maybe
instead of mapping
this upper policy to gig 03, I map this policy instead. So this configuration
that we're
going to need is going to need to be modular. And it's going to need to be
something that
is very simple for us to use. And so in order to create a configuration along
these lines,
this is where Cisco created the concept of the modular. So there's that keyword
modular WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
modular
QOS CLI, which feels like a little bit of a mouthful. We simply refer to this
as MQC.
And yes, it's a pretty common term to refer to as I know with the first time I
learned
it, I said to myself, okay, that's great. That's what Cisco wants to call it.
But believe
it or not, this term does get tossed around quite a bit. It's not just
something that
Cisco tossed out there hoping it would catch on. So MQC is kind of a big deal
when it comes
to configuring quality of service on a lot of Cisco platforms. We're talking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to configuring quality of service on a lot of Cisco platforms. We're talking
about configuration
on catalyst devices, but also configuration on Nexus devices, as well as the
classic ISRs
and ASRs. And the list goes on. I mean, Cisco uses MQC across a lot of
different platforms.
Now importantly, under the hood, a catalyst switch and a Nexus switch, and
these routers,
they have completely different architectures. They support different numbers of
queues. They
support different policies. Some might be able to do policing in ways that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
support different policies. Some might be able to do policing in ways that
others can't,
for example. And yet we're going to use MQC for the configuration across all of
those
platforms. So really nice for us for learning, because we can learn one set of
configurations,
and by and large, with maybe a couple of exceptions, we can use that knowledge
on any
of these platforms. But we do need to recognize that what we're able to do
might be a little
bit different based on the platform. Now MQC consists of three different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
bit different based on the platform. Now MQC consists of three different
primary configurations.
We're going to configure class maps. And the class maps, I'll just say class
map here,
this defines a queue. And specifically, it's going to allow us to match our
traffic or
classify our traffic into different queues. But having a handful of queues
doesn't mean
a whole lot, we've got to put them into a structure and assign policy to them.
And that
is the responsibility of the policy map. The policy map is going to aggregate WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
is the responsibility of the policy map. The policy map is going to aggregate
those queues
together, like we have drawn up up there. And we are also going to apply, well,
as the
name implies, our policy against all of these different queues. So bandwidth
reservations,
priority status, all of the things we mentioned. And then lastly, we have a
configuration,
which is service policy. And the service policy is how we're going to map, we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
which is service policy. And the service policy is how we're going to map, we
'll do
it like this, we're going to map our policy map to specific interfaces. And all
three
of these are very important parts of the process, with the bulk of the
configuration admittedly
being done with the first two, but the service policy is important as well. So
with that said,
let's take a look at class maps. So class maps, as we just said, are
responsible for
defining queues. This defines a queue based on the matching of the traffic. So WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
defining queues. This defines a queue based on the matching of the traffic. So
we want
to be able to match traffic. And as we said, we can do this a number of
different ways.
Now, usually we're going to look at class of service or DSCP. But we can also
look
at IP precedence. And we can even use that access control list like we
mentioned. So
again, sourcing traffic from a particular IP address, maybe all of that traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
again, sourcing traffic from a particular IP address, maybe all of that traffic
goes
into a particular queue, something along those lines. But an important part of
this is we're
not actually applying any policy, we are simply creating the queues themselves.
And as I
said earlier, a handful of queues doesn't mean a whole lot on their own. But
that is
the starting point that we need to look at. Now importantly, when it comes to
matching,
we can look at a couple of options, we can do a match against multiple
parameters in the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
parameters in the
form of a match any, or a match all. This is defined at the class map level.
And we're
essentially going to say something like, Hey, I'm going to create a class map
here, I want
to match a bunch of AF, AF, 41, 42, 43, I want to match all of those. And so I
want to match
again, these three different tags. So let's match all three of these. Well, if
I were
to say match all, that's a problem, because a packet can only have a single tag WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
to say match all, that's a problem, because a packet can only have a single tag
, I can
match all three of these tags. So instead, I want to use match any in order to
match against
three different tags. So I we can support multiple parameters. So multiple
match statements
is going to be supported on a class map. But then that's going to have to be
determined
in some fashion by our policy that says, Hey, are we going to match all of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
in some fashion by our policy that says, Hey, are we going to match all of
these in order
to put them into the queue? Or can we match any of the parameters? So kind of a
programmability
and in a programmability or type of situation with regards to the class map
configuration.
Now we can also perform match statements, but we can also have match not
statements as well.
So we could say, Hey, don't match, I don't know, AF 32, I don't know, it is
just something
along those lines, like we could, we could do a match not against an access WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
along those lines, like we could, we could do a match not against an access
control list.
And then we could say, Hey, yeah, put all of these packets into these queues,
if they
have the tags, but we don't want to match specific traffic within that context.
So that's especially
going to matter when we're looking at matching any versus matching all. So let
's keep that in mind.
Now lastly, there is a queue, a very important queue that does not get a class
map configuration.
And that is a queue known as class default. The class default queue is going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And that is a queue known as class default. The class default queue is going to
be an automatic
part of every policy map. Because of this, we don't actually have to configure
it ourselves
using a class map. So there is no class map configuration. In fact, we'll see
that if we try
to punch in a class map with that name class default, the system will reject us
because that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
because that
queue is effectively created by the system itself. So this is an overview of
not only MQC, but the
start of our MQC configuration, which involves the class map. From here, let's
go ahead and dive
in and take a look at it at the CLI.