WEBVTT

1
00:00.000 --> 00:06.500
So here's our goal. If we are going to perform a QOS configuration, we need to

2
00:06.500 --> 00:07.480
be able to

3
00:07.480 --> 00:14.080
configure a number of Qs that's going to go onto an interface. And we need to

4
00:14.080 --> 00:15.760
also identify

5
00:15.760 --> 00:20.410
the traffic that's coming into it. So this is our classification here. And we

6
00:20.410 --> 00:20.680
're usually

7
00:20.680 --> 00:27.580
going to use our DSCP tags or COS tags in order to identify our traffic. But we

8
00:27.580 --> 00:27.780
could

9
00:27.780 --> 00:32.470
actually use access control lists as well. So we could identify traffic sourced
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

9
00:27.780 --> 00:32.470
actually use access control lists as well. So we could identify traffic sourced

10
00:32.470 --> 00:32.840
from

11
00:32.840 --> 00:36.780
a particular IP address and put it into a queue in the same way that we can

12
00:36.780 --> 00:37.420
identify

13
00:37.420 --> 00:41.760
traffic based on the tags. But it's not just about creating the cues. I mean,

14
00:41.760 --> 00:42.080
yeah, we've

15
00:42.080 --> 00:46.360
got to create all of the cues that are going to be put onto the interface. But

16
00:46.360 --> 00:46.800
we also

17
00:46.800 --> 00:51.770
have to identify the policies that are going to be in place. And there are

18
00:51.770 --> 00:52.040
quite a few

19
00:52.040 --> 00:56.470
policies to talk about in this skill, we're going to focus on our bandwidth and

20
00:56.470 --> 00:57.560
our priority

21
00:57.560 --> 01:03.810
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

21
00:57.560 --> 01:03.810
organization status of these different cues. Now the way this works is we are

22
01:03.810 --> 01:04.320
going to

23
01:04.320 --> 01:10.120
create a template of sorts. So call this our QOS template here, and we'll learn

24
01:10.120 --> 01:10.720
that this

25
01:10.720 --> 01:15.910
is called a policy map. And we're going to look at a device like a switch or a

26
01:15.910 --> 01:16.760
router.

27
01:16.760 --> 01:22.320
And this device has a lot of different interfaces on it. Maybe it has gig 00

28
01:22.320 --> 01:24.040
gig 01 0 2 0 3

29
01:24.040 --> 01:29.040
something like that. And so what we can do is we can take this one policy map,

30
01:29.040 --> 01:29.680
this one

31
01:29.680 --> 01:35.200
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

31
01:29.680 --> 01:35.200
set of policies, and put it onto as many of these interfaces as we desire,

32
01:35.200 --> 01:35.920
maybe three

33
01:35.920 --> 01:42.380
or even all four of these interfaces on this device. So it's a modular concept.

34
01:42.380 --> 01:43.040
I can not

35
01:43.040 --> 01:48.170
only create a bunch of Q definitions here. So these are the cues over on this

36
01:48.170 --> 01:48.840
side. But

37
01:48.840 --> 01:53.470
I could also actually create a different policy. So this is a completely

38
01:53.470 --> 01:55.480
different policy here.

39
01:55.480 --> 02:00.370
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

39
01:55.480 --> 02:00.370
But I take these cues as I've defined them by how I identify traffic. And I can

40
02:00.370 --> 02:01.000
put them

41
02:01.000 --> 02:05.310
into different policies and map those policies to different interfaces, maybe

42
02:05.310 --> 02:06.280
instead of mapping

43
02:06.280 --> 02:12.570
this upper policy to gig 03, I map this policy instead. So this configuration

44
02:12.570 --> 02:13.200
that we're

45
02:13.200 --> 02:17.280
going to need is going to need to be modular. And it's going to need to be

46
02:17.280 --> 02:17.960
something that

47
02:17.960 --> 02:22.680
is very simple for us to use. And so in order to create a configuration along

48
02:22.680 --> 02:24.000
these lines,

49
02:24.000 --> 02:29.860
this is where Cisco created the concept of the modular. So there's that keyword

50
02:29.860 --> 02:30.480
modular
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

50
02:29.860 --> 02:30.480
modular

51
02:30.480 --> 02:36.980
QOS CLI, which feels like a little bit of a mouthful. We simply refer to this

52
02:36.980 --> 02:38.920
as MQC.

53
02:38.920 --> 02:42.360
And yes, it's a pretty common term to refer to as I know with the first time I

54
02:42.360 --> 02:42.880
learned

55
02:42.880 --> 02:46.570
it, I said to myself, okay, that's great. That's what Cisco wants to call it.

56
02:46.570 --> 02:47.080
But believe

57
02:47.080 --> 02:51.120
it or not, this term does get tossed around quite a bit. It's not just

58
02:51.120 --> 02:51.720
something that

59
02:51.720 --> 02:55.990
Cisco tossed out there hoping it would catch on. So MQC is kind of a big deal

60
02:55.990 --> 02:56.800
when it comes

61
02:56.800 --> 03:01.910
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

61
02:56.800 --> 03:01.910
to configuring quality of service on a lot of Cisco platforms. We're talking

62
03:01.910 --> 03:03.120
about configuration

63
03:03.120 --> 03:09.060
on catalyst devices, but also configuration on Nexus devices, as well as the

64
03:09.060 --> 03:10.600
classic ISRs

65
03:10.600 --> 03:16.380
and ASRs. And the list goes on. I mean, Cisco uses MQC across a lot of

66
03:16.380 --> 03:18.600
different platforms.

67
03:18.600 --> 03:23.800
Now importantly, under the hood, a catalyst switch and a Nexus switch, and

68
03:23.800 --> 03:24.880
these routers,

69
03:24.880 --> 03:28.370
they have completely different architectures. They support different numbers of

70
03:28.370 --> 03:28.880
queues. They

71
03:28.880 --> 03:33.540
support different policies. Some might be able to do policing in ways that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
03:28.880 --> 03:33.540
support different policies. Some might be able to do policing in ways that

72
03:33.540 --> 03:34.520
others can't,

73
03:34.520 --> 03:38.920
for example. And yet we're going to use MQC for the configuration across all of

74
03:38.920 --> 03:39.320
those

75
03:39.320 --> 03:44.290
platforms. So really nice for us for learning, because we can learn one set of

76
03:44.290 --> 03:45.600
configurations,

77
03:45.600 --> 03:51.300
and by and large, with maybe a couple of exceptions, we can use that knowledge

78
03:51.300 --> 03:51.840
on any

79
03:51.840 --> 03:56.270
of these platforms. But we do need to recognize that what we're able to do

80
03:56.270 --> 03:57.360
might be a little

81
03:57.360 --> 04:03.480
bit different based on the platform. Now MQC consists of three different
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

81
03:57.360 --> 04:03.480
bit different based on the platform. Now MQC consists of three different

82
04:03.480 --> 04:05.840
primary configurations.

83
04:05.840 --> 04:11.960
We're going to configure class maps. And the class maps, I'll just say class

84
04:11.960 --> 04:12.560
map here,

85
04:12.560 --> 04:17.560
this defines a queue. And specifically, it's going to allow us to match our

86
04:17.560 --> 04:18.360
traffic or

87
04:18.360 --> 04:22.980
classify our traffic into different queues. But having a handful of queues

88
04:22.980 --> 04:23.840
doesn't mean

89
04:23.840 --> 04:28.520
a whole lot, we've got to put them into a structure and assign policy to them.

90
04:28.520 --> 04:29.080
And that

91
04:29.080 --> 04:33.590
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

91
04:29.080 --> 04:33.590
is the responsibility of the policy map. The policy map is going to aggregate

92
04:33.590 --> 04:34.360
those queues

93
04:34.360 --> 04:40.760
together, like we have drawn up up there. And we are also going to apply, well,

94
04:40.760 --> 04:41.360
as the

95
04:41.360 --> 04:46.540
name implies, our policy against all of these different queues. So bandwidth

96
04:46.540 --> 04:47.600
reservations,

97
04:47.600 --> 04:53.370
priority status, all of the things we mentioned. And then lastly, we have a

98
04:53.370 --> 04:54.680
configuration,

99
04:54.680 --> 05:00.970
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

99
04:54.680 --> 05:00.970
which is service policy. And the service policy is how we're going to map, we

100
05:00.970 --> 05:01.280
'll do

101
05:01.280 --> 05:10.460
it like this, we're going to map our policy map to specific interfaces. And all

102
05:10.460 --> 05:10.600
three

103
05:10.600 --> 05:14.680
of these are very important parts of the process, with the bulk of the

104
05:14.680 --> 05:16.160
configuration admittedly

105
05:16.160 --> 05:20.840
being done with the first two, but the service policy is important as well. So

106
05:20.840 --> 05:21.960
with that said,

107
05:21.960 --> 05:27.420
let's take a look at class maps. So class maps, as we just said, are

108
05:27.420 --> 05:28.840
responsible for

109
05:28.840 --> 05:36.330
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

109
05:28.840 --> 05:36.330
defining queues. This defines a queue based on the matching of the traffic. So

110
05:36.330 --> 05:36.800
we want

111
05:36.800 --> 05:42.670
to be able to match traffic. And as we said, we can do this a number of

112
05:42.670 --> 05:44.320
different ways.

113
05:44.320 --> 05:49.840
Now, usually we're going to look at class of service or DSCP. But we can also

114
05:49.840 --> 05:50.280
look

115
05:50.280 --> 05:55.260
at IP precedence. And we can even use that access control list like we

116
05:55.260 --> 05:56.840
mentioned. So

117
05:56.840 --> 06:01.310
again, sourcing traffic from a particular IP address, maybe all of that traffic
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
05:56.840 --> 06:01.310
again, sourcing traffic from a particular IP address, maybe all of that traffic

118
06:01.310 --> 06:01.600
goes

119
06:01.600 --> 06:06.110
into a particular queue, something along those lines. But an important part of

120
06:06.110 --> 06:06.680
this is we're

121
06:06.680 --> 06:12.380
not actually applying any policy, we are simply creating the queues themselves.

122
06:12.380 --> 06:12.840
And as I

123
06:12.840 --> 06:17.010
said earlier, a handful of queues doesn't mean a whole lot on their own. But

124
06:17.010 --> 06:17.480
that is

125
06:17.480 --> 06:22.200
the starting point that we need to look at. Now importantly, when it comes to

126
06:22.200 --> 06:23.000
matching,

127
06:23.000 --> 06:29.270
we can look at a couple of options, we can do a match against multiple

128
06:29.270 --> 06:30.720
parameters in the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

128
06:29.270 --> 06:30.720
parameters in the

129
06:30.720 --> 06:38.570
form of a match any, or a match all. This is defined at the class map level.

130
06:38.570 --> 06:38.920
And we're

131
06:38.920 --> 06:42.880
essentially going to say something like, Hey, I'm going to create a class map

132
06:42.880 --> 06:43.560
here, I want

133
06:43.560 --> 06:50.820
to match a bunch of AF, AF, 41, 42, 43, I want to match all of those. And so I

134
06:50.820 --> 06:52.920
want to match

135
06:52.920 --> 06:58.690
again, these three different tags. So let's match all three of these. Well, if

136
06:58.690 --> 06:59.480
I were

137
06:59.480 --> 07:05.300
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

137
06:59.480 --> 07:05.300
to say match all, that's a problem, because a packet can only have a single tag

138
07:05.300 --> 07:05.760
, I can

139
07:05.760 --> 07:12.010
match all three of these tags. So instead, I want to use match any in order to

140
07:12.010 --> 07:13.480
match against

141
07:13.480 --> 07:20.160
three different tags. So I we can support multiple parameters. So multiple

142
07:20.160 --> 07:22.320
match statements

143
07:22.320 --> 07:27.430
is going to be supported on a class map. But then that's going to have to be

144
07:27.430 --> 07:28.400
determined

145
07:28.400 --> 07:32.450
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

145
07:28.400 --> 07:32.450
in some fashion by our policy that says, Hey, are we going to match all of

146
07:32.450 --> 07:33.200
these in order

147
07:33.200 --> 07:37.980
to put them into the queue? Or can we match any of the parameters? So kind of a

148
07:37.980 --> 07:39.200
programmability

149
07:39.200 --> 07:44.280
and in a programmability or type of situation with regards to the class map

150
07:44.280 --> 07:45.680
configuration.

151
07:45.680 --> 07:50.430
Now we can also perform match statements, but we can also have match not

152
07:50.430 --> 07:52.800
statements as well.

153
07:52.800 --> 07:57.950
So we could say, Hey, don't match, I don't know, AF 32, I don't know, it is

154
07:57.950 --> 07:59.040
just something

155
07:59.040 --> 08:02.050
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

155
07:59.040 --> 08:02.050
along those lines, like we could, we could do a match not against an access

156
08:02.050 --> 08:02.960
control list.

157
08:02.960 --> 08:07.370
And then we could say, Hey, yeah, put all of these packets into these queues,

158
08:07.370 --> 08:07.840
if they

159
08:07.840 --> 08:14.260
have the tags, but we don't want to match specific traffic within that context.

160
08:14.260 --> 08:14.880
So that's especially

161
08:14.880 --> 08:18.420
going to matter when we're looking at matching any versus matching all. So let

162
08:18.420 --> 08:19.280
's keep that in mind.

163
08:19.280 --> 08:27.820
Now lastly, there is a queue, a very important queue that does not get a class

164
08:27.820 --> 08:29.360
map configuration.

165
08:29.360 --> 08:35.640
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

165
08:29.360 --> 08:35.640
And that is a queue known as class default. The class default queue is going to

166
08:35.640 --> 08:36.960
be an automatic

167
08:37.760 --> 08:46.880
part of every policy map. Because of this, we don't actually have to configure

168
08:46.880 --> 08:47.680
it ourselves

169
08:47.680 --> 08:54.030
using a class map. So there is no class map configuration. In fact, we'll see

170
08:54.030 --> 08:54.560
that if we try

171
08:54.560 --> 08:59.730
to punch in a class map with that name class default, the system will reject us

172
08:59.730 --> 09:00.160
because that
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

172
08:59.730 --> 09:00.160
because that

173
09:00.160 --> 09:06.310
queue is effectively created by the system itself. So this is an overview of

174
09:06.310 --> 09:08.240
not only MQC, but the

175
09:08.240 --> 09:12.070
start of our MQC configuration, which involves the class map. From here, let's

176
09:12.070 --> 09:12.960
go ahead and dive

177
09:12.960 --> 09:15.280
in and take a look at it at the CLI.