WEBVTT

1
00:00.000 --> 00:05.240
Well, as mentioned, we are going to use class maps in order to create our cues,

2
00:05.240 --> 00:06.040
but we want

3
00:06.040 --> 00:11.760
to be able to modularly use these to create policy maps.

4
00:11.760 --> 00:16.030
And the policy maps are going to sort of be a template of sorts that go onto an

5
00:16.030 --> 00:16.760
interface

6
00:16.760 --> 00:19.520
and allow that interface to define its cues.

7
00:19.520 --> 00:24.460
So if we say we want four different cues here, one, two, three, and four, well

8
00:24.460 --> 00:25.000
then at that

9
00:25.000 --> 00:29.760
point, the interface itself will use four cues.

10
00:29.760 --> 00:32.760
As we've defined, whatever that looks like.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

10
00:29.760 --> 00:32.760
As we've defined, whatever that looks like.

11
00:32.760 --> 00:36.500
And so again, class maps focusing on the cues and specifically the match

12
00:36.500 --> 00:37.320
statements which

13
00:37.320 --> 00:42.480
define which traffic goes into which one of those cues.

14
00:42.480 --> 00:47.140
But now that we've created the matching, it's time to shift focus here and look

15
00:47.140 --> 00:47.960
at the actual

16
00:47.960 --> 00:51.440
policy that we're deploying against the different cues.

17
00:51.440 --> 00:53.760
So what types of policies are we looking at?

18
00:53.760 --> 00:57.420
Well as we've mentioned, we want to be able to define whether a cue operates

19
00:57.420 --> 00:58.200
with priority

20
00:58.200 --> 00:59.200
bias.

21
00:59.200 --> 01:03.680
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

21
00:59.200 --> 01:03.680
And we need to simply know, are we going to apply this as a strict priority?

22
01:03.680 --> 01:11.480
Or are we going to apply this in a safer way as a relative priority cue?

23
01:11.480 --> 01:16.520
And that just means that it's not going to be strictly priority based.

24
01:16.520 --> 01:19.670
Instead, we're going to still take turns, we're going to play nice, but

25
01:19.670 --> 01:20.480
relative to the

26
01:20.480 --> 01:23.840
other cues, we absolutely have some amount of priority.

27
01:23.840 --> 01:26.160
We can also look at bandwidth reservations.

28
01:26.160 --> 01:31.960
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

28
01:26.160 --> 01:31.960
And this is going to be one of the most important parts of defining a proper

29
01:31.960 --> 01:32.920
policy.

30
01:32.920 --> 01:37.610
The bandwidth reservation is going to, as we'll see, be able to be specified in

31
01:37.610 --> 01:37.960
a lot

32
01:37.960 --> 01:39.720
of different ways.

33
01:39.720 --> 01:43.990
And what's interesting about this is I can apply this policy to two different

34
01:43.990 --> 01:45.280
interfaces.

35
01:45.280 --> 01:48.590
And this interface down here might be one gigabit per second and the interface

36
01:48.590 --> 01:49.000
up here

37
01:49.000 --> 01:52.160
might be 100 megabits per second.

38
01:52.160 --> 01:56.680
So this is kind of curious because if I reserve, let's say, 10 megabits per

39
01:56.680 --> 01:57.960
second in a cue,

40
01:57.960 --> 02:02.120
well, that's a massive amount of the bandwidth for this interface.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

40
01:57.960 --> 02:02.120
well, that's a massive amount of the bandwidth for this interface.

41
02:02.120 --> 02:07.120
But it's almost nothing on a one gigabit per second interface.

42
02:07.120 --> 02:10.610
And so we might find that we want to go percentage based, which is certainly

43
02:10.610 --> 02:11.440
possible, but can

44
02:11.440 --> 02:15.370
almost create the opposite problem, which is that, hey, I want to reserve, let

45
02:15.370 --> 02:16.040
's say,

46
02:16.040 --> 02:22.150
10% of 100 megabits per second for voice, well, that's reserving 10 megabit per

47
02:22.150 --> 02:22.920
second, which

48
02:22.920 --> 02:27.240
is a lot of bandwidth for voice already.

49
02:27.240 --> 02:31.570
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

49
02:27.240 --> 02:31.570
And if I say 10% of a gig, well, holy smokes now, we're talking about 100 megab

50
02:31.570 --> 02:32.120
its per

51
02:32.120 --> 02:33.680
second for voice.

52
02:33.680 --> 02:38.680
So it's one of the challenges for sure in creating real world QOS policies is

53
02:38.680 --> 02:39.200
making sure

54
02:39.200 --> 02:41.840
that our policies are going to map properly.

55
02:41.840 --> 02:46.790
And even though Cisco does allow us to be so modular as to add a policy map to

56
02:46.790 --> 02:47.640
different

57
02:47.640 --> 02:51.200
interface types, in a real world situation, we're probably going to want to

58
02:51.200 --> 02:51.720
make sure

59
02:51.720 --> 02:58.280
we have policy maps defined on a per speed per interface type of situation.

60
02:58.280 --> 03:00.920
So it's something to keep in mind.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

60
02:58.280 --> 03:00.920
So it's something to keep in mind.

61
03:00.920 --> 03:05.430
And yeah, in the real world, we might see less 100 meg and more one gig versus

62
03:05.430 --> 03:06.120
10 gig

63
03:06.120 --> 03:10.210
or maybe even a multi gig type of situation on catalyst switches, which is two

64
03:10.210 --> 03:10.760
and a half

65
03:10.760 --> 03:12.920
and five gigabits per second.

66
03:12.920 --> 03:16.040
So either way, we've got other policies that we might end up deploying here.

67
03:16.040 --> 03:21.720
For example, the conversation we had around policing and shaping, this is going

68
03:21.720 --> 03:22.120
to be

69
03:22.120 --> 03:28.850
a configuration that goes into our policies, which are put into the policy maps

70
03:28.850 --> 03:28.880
.

71
03:28.880 --> 03:34.320
We also want to specify our congestion avoidance thresholds, specifically for
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

71
03:28.880 --> 03:34.320
We also want to specify our congestion avoidance thresholds, specifically for

72
03:34.320 --> 03:35.480
weighted random

73
03:35.480 --> 03:41.870
early detect red with the W there, we're going to need to define these

74
03:41.870 --> 03:43.360
thresholds.

75
03:43.360 --> 03:47.280
And because of this, we're going to want to have a place to do it.

76
03:47.280 --> 03:50.000
Well, that's going to be in the policy map as well.

77
03:50.000 --> 03:55.810
We can also define things like the queue length, the different devices that we

78
03:55.810 --> 03:56.840
're configuring,

79
03:56.840 --> 03:58.600
they only have so much buffer space.

80
03:58.600 --> 04:02.640
And so maybe we want to shorten a queue or lengthen a queue.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

80
03:58.600 --> 04:02.640
And so maybe we want to shorten a queue or lengthen a queue.

81
04:02.640 --> 04:06.600
And regardless of whether or not we're out of buffer space, just defining the

82
04:06.600 --> 04:07.360
queue length

83
04:07.360 --> 04:11.880
can change the way that our end user experiences are impacted.

84
04:11.880 --> 04:15.440
And having a longer queue length doesn't necessarily mean that they actually

85
04:15.440 --> 04:17.240
have a better experience

86
04:17.240 --> 04:19.040
for what it's worth.

87
04:19.040 --> 04:23.720
And then we might also want to look at some kind of option like remarking

88
04:23.720 --> 04:24.560
packets.

89
04:24.560 --> 04:31.000
And we talked about remarking our tags here within the context of policing.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

89
04:24.560 --> 04:31.000
And we talked about remarking our tags here within the context of policing.

90
04:31.000 --> 04:35.170
Like maybe you sent me too much traffic, so I'm going to inflict a discipline

91
04:35.170 --> 04:36.120
or punishment,

92
04:36.120 --> 04:38.320
I suppose, by remarking the packets.

93
04:38.320 --> 04:42.640
Well, I can actually remark regardless of whether or not there's a policing

94
04:42.640 --> 04:43.560
violation.

95
04:43.560 --> 04:47.360
So packet could come in with one tag, a tag of 10, and it could leave with a

96
04:47.360 --> 04:48.680
tag of 12,

97
04:48.680 --> 04:49.840
something like that.

98
04:49.840 --> 04:52.440
Maybe this makes sense at organizational boundaries.

99
04:52.440 --> 04:56.400
If we acquired an organization and they're using different tags than us, then

100
04:56.400 --> 04:56.880
we might

101
04:56.880 --> 05:01.360
want to translate the tags as they come across a specific interface.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

101
04:56.880 --> 05:01.360
want to translate the tags as they come across a specific interface.

102
05:01.360 --> 05:04.780
So these are just some examples and probably the most common examples of

103
05:04.780 --> 05:05.520
policies that

104
05:05.520 --> 05:07.200
we want to deploy.

105
05:07.200 --> 05:12.840
And again, the policies are going to be put into our policy map.

106
05:12.840 --> 05:17.400
Now in a standard configuration, we're certainly going to have multiple class

107
05:17.400 --> 05:18.280
maps because

108
05:18.280 --> 05:20.120
we need multiple queues.

109
05:20.120 --> 05:24.790
We might only have a single policy map on a device, because maybe that policy

110
05:24.790 --> 05:25.280
is good

111
05:25.280 --> 05:26.880
for all of the interfaces.

112
05:26.880 --> 05:31.780
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

112
05:26.880 --> 05:31.780
But because of the modular nature, again, I could define a second policy map

113
05:31.780 --> 05:32.320
here, use

114
05:32.320 --> 05:36.610
the same class maps in this different policy map and apply it to a different

115
05:36.610 --> 05:37.920
set of interfaces.

116
05:37.920 --> 05:42.000
So we've got modularity stacked on top of modularity, and that's something that

117
05:42.000 --> 05:42.440
we just

118
05:42.440 --> 05:46.860
need to kind of keep in mind here as far as how all of this configuration comes

119
05:46.860 --> 05:47.760
together.

120
05:47.760 --> 05:49.000
So what's this going to look like?

121
05:49.000 --> 05:52.150
Well, we'll jump onto the CLI here in a moment, but essentially what we're

122
05:52.150 --> 05:53.240
going to do is

123
05:53.240 --> 05:56.640
we're going to specify a policy map by name.

124
05:56.640 --> 06:00.190
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

124
05:56.640 --> 06:00.190
So whatever our policy name is going to end up being, and then we're going to

125
06:00.190 --> 06:00.640
use the

126
06:00.640 --> 06:02.640
class command.

127
06:02.640 --> 06:07.400
The class command allows me to specify which queue that I want to build here on

128
06:07.400 --> 06:08.120
the policy

129
06:08.120 --> 06:09.160
map.

130
06:09.160 --> 06:13.530
And because we are matching based on tags, the order might or shouldn't really

131
06:13.530 --> 06:14.000
matter

132
06:14.000 --> 06:18.210
here, but in case we have any kind of conflict with matching, we might want to

133
06:18.210 --> 06:19.080
pay attention

134
06:19.080 --> 06:20.080
to that.

135
06:20.080 --> 06:23.830
Either way, we're going to specify the class option here, and then we're going

136
06:23.830 --> 06:24.400
to specify

137
06:24.400 --> 06:27.160
the class map name.

138
06:27.160 --> 06:33.330
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

138
06:27.160 --> 06:33.330
So let's say that we want to match that or use, we want to create a priority

139
06:33.330 --> 06:34.400
queue using

140
06:34.400 --> 06:40.040
the one we made before, which was like DSCP_EF, for example.

141
06:40.040 --> 06:43.360
So that could be the class map name that we specify here.

142
06:43.360 --> 06:46.720
Now, notice we're not saying class map, we're just saying class.

143
06:46.720 --> 06:51.800
In fact, if we say class map, then Cisco iOS tries to outsmart us and take us

144
06:51.800 --> 06:52.640
back outside

145
06:52.640 --> 06:55.780
of the policy map configuration that can get a little confusing if we're not

146
06:55.780 --> 06:56.120
paying

147
06:56.120 --> 06:57.120
attention.

148
06:57.120 --> 06:59.480
So bear that in mind.

149
06:59.480 --> 07:03.930
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

149
06:59.480 --> 07:03.930
Once we've specified our class, now we get taken in and we can specify policies

150
07:03.930 --> 07:04.240
.

151
07:04.240 --> 07:09.670
So I could use, for example, the priority command to say, you know, I want to

152
07:09.670 --> 07:10.760
make this a priority

153
07:10.760 --> 07:14.200
queue and I want to limit it to 100 kilobits per second.

154
07:14.200 --> 07:19.530
So a lot of our bandwidth configurations are going to be applied in terms of

155
07:19.530 --> 07:20.440
kilobits per

156
07:20.440 --> 07:21.840
second.

157
07:21.840 --> 07:24.820
So if I wanted 100k, it'd be just 100 there.

158
07:24.820 --> 07:29.880
If I wanted a megabit per second, well, I need to specify 1000, because it's

159
07:29.880 --> 07:30.580
1000
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

159
07:29.880 --> 07:30.580
1000

160
07:30.580 --> 07:32.200
kilobits per second.

161
07:32.200 --> 07:36.210
I can also use the bandwidth command here, which will allow me to do bandwidth

162
07:36.210 --> 07:37.000
reservations

163
07:37.000 --> 07:39.600
outside of a priority configuration.

164
07:39.600 --> 07:41.880
And we've got some other options here as well.

165
07:41.880 --> 07:46.530
But our focus right now is going to be on just building out a set of queues

166
07:46.530 --> 07:47.240
that have

167
07:47.240 --> 07:53.180
certain levels of prior or different levels of priority, as well as bandwidth

168
07:53.180 --> 07:54.600
reservations.

169
07:54.600 --> 07:59.290
Now remember what I said earlier about the class default, I don't have to

170
07:59.290 --> 08:00.320
specify class
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

170
07:59.290 --> 08:00.320
specify class

171
08:00.320 --> 08:02.200
default here.

172
08:02.200 --> 08:05.560
But if I want to apply policy to it, then I'm certainly going to have to

173
08:05.560 --> 08:06.200
remember this

174
08:06.200 --> 08:10.040
exists on its own.

175
08:10.040 --> 08:15.080
It already exists within a policy map that I create.

176
08:15.080 --> 08:18.720
But what if I want to add some bandwidth reservations to the class default?

177
08:18.720 --> 08:20.440
That's usually recommended.

178
08:20.440 --> 08:22.360
I mean, Cisco recommends it.

179
08:22.360 --> 08:26.870
And we definitely want to make sure that the bulk of our traffic in the network

180
08:26.870 --> 08:27.280
is getting

181
08:27.280 --> 08:29.720
some amount of bandwidth reservation.

182
08:29.720 --> 08:34.500
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

182
08:29.720 --> 08:34.500
So we might reserve something like 25% of the bandwidth on a link that might

183
08:34.500 --> 08:35.160
actually

184
08:35.160 --> 08:37.240
be very important in our environment.

185
08:37.240 --> 08:41.630
And that is typically what we see with a lot of organizational QoS policies is

186
08:41.630 --> 08:42.200
that the

187
08:42.200 --> 08:46.160
class default does get 25% of the bandwidth.

188
08:46.160 --> 08:53.320
Just keep in mind that this is going to contain all unmatched traffic.

189
08:53.320 --> 09:00.400
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

189
08:53.320 --> 09:00.400
And yes, that does mean DSCP zero in most cases, but it doesn't mean only DSCP

190
09:00.400 --> 09:01.040
zero.

191
09:01.040 --> 09:09.410
This is my only two Qs that I created, well, then EF is going to go here, but

192
09:09.410 --> 09:10.760
AF41 is going

193
09:10.760 --> 09:14.850
to go here into the class default because I didn't build a Q or at least I didn

194
09:14.850 --> 09:15.440
't apply

195
09:15.440 --> 09:20.680
a Q to the policy map that specifies and matches this specific tag.

196
09:20.680 --> 09:26.300
So all the assured forwarding PHBs for hot behaviors, those are going to filter

197
09:26.300 --> 09:26.720
down

198
09:26.720 --> 09:32.000
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

198
09:26.720 --> 09:32.000
to the class default in this configuration because we truly only have one other

199
09:32.000 --> 09:32.360
Q.

200
09:32.360 --> 09:36.900
So just keep that in mind when we're evaluating configurations that the class

201
09:36.900 --> 09:37.760
default isn't

202
09:37.760 --> 09:42.680
just DSCP zero is all of the unmatched traffic.

203
09:42.680 --> 09:47.540
And by the way, a lot of conversations around QoS will typically refer to this

204
09:47.540 --> 09:48.320
as the best

205
09:48.320 --> 09:51.520
effort queue.

206
09:51.520 --> 09:54.480
So we can expect to hear that as well.

207
09:54.480 --> 09:58.210
Now one thing we can do within the class default that we can't with anybody

208
09:58.210 --> 09:58.840
else is remember

209
09:58.840 --> 10:06.790
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

209
09:58.840 --> 10:06.790
we can leave it as a FIFO queue or we can configure it with FairQ, which is a

210
10:06.790 --> 10:08.040
reference

211
10:08.040 --> 10:11.640
here to weighted fair queuing.

212
10:11.640 --> 10:15.580
Weighted fair queuing is what we'll recall allows every traffic flow to have

213
10:15.580 --> 10:16.280
its own mini

214
10:16.280 --> 10:19.880
queue within the best effort queue here.

215
10:19.880 --> 10:23.780
And this allows us to make sure that those traffic flows are treated fairly and

216
10:23.780 --> 10:24.360
one traffic

217
10:24.360 --> 10:27.240
flow can't just completely dominate the queue.

218
10:27.240 --> 10:30.120
So this is a pretty common configuration as well.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

218
10:27.240 --> 10:30.120
So this is a pretty common configuration as well.

219
10:30.120 --> 10:36.010
Now lastly, just as part of this conversation, we want to talk about service

220
10:36.010 --> 10:36.960
policy.

221
10:36.960 --> 10:43.360
So my service policy is going to take my policy map and map it to an interface

222
10:43.360 --> 10:43.960
as we've said

223
10:43.960 --> 10:45.400
several times.

224
10:45.400 --> 10:51.380
But importantly, it actually is going to be specified as either an input or an

225
10:51.380 --> 10:52.040
output

226
10:52.040 --> 10:53.600
direction.

227
10:53.600 --> 10:58.040
Now output is almost always where we're going to apply QoS policy because we

228
10:58.040 --> 10:58.840
have more queues

229
10:58.840 --> 11:00.880
going in an outbound direction.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

229
10:58.840 --> 11:00.880
going in an outbound direction.

230
11:00.880 --> 11:04.390
And that's usually where all the interesting things are happening because a

231
11:04.390 --> 11:05.040
device that

232
11:05.040 --> 11:09.640
brings traffic in the input queue is usually pretty short.

233
11:09.640 --> 11:12.610
And there's not a whole lot that we need to worry about on the input queue side

234
11:12.610 --> 11:13.240
of things,

235
11:13.240 --> 11:17.360
although we certainly can't apply policy maps in the input direction.

236
11:17.360 --> 11:20.980
Instead, usually our focus is going to be on the outbound direction because all

237
11:20.980 --> 11:21.320
of this

238
11:21.320 --> 11:27.320
traffic coming into a device might all get funneled to a single interface.

239
11:27.320 --> 11:30.480
And now we have lots of packets queued up and ready to go.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

239
11:27.320 --> 11:30.480
And now we have lots of packets queued up and ready to go.

240
11:30.480 --> 11:35.680
So that's why we want multiple queues in the outbound direction.

241
11:35.680 --> 11:41.880
So syntax wise, we're going to say service dash policy.

242
11:41.880 --> 11:48.400
And then we're going to say input or output.

243
11:48.400 --> 11:54.360
And then we're going to have the policy map name specified.

244
11:54.360 --> 11:56.880
So that is what we're trying to accomplish here.

245
11:56.880 --> 12:00.070
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

245
11:56.880 --> 12:00.070
We're trying to create that set of queues that has a bunch of policies

246
12:00.070 --> 12:00.960
associated with

247
12:00.960 --> 12:01.960
it.

248
12:01.960 --> 12:05.200
So we're going to create a policy map, apply it to an interface, including the

249
12:05.200 --> 12:06.120
direction,

250
12:06.120 --> 12:07.640
using the service policy.

251
12:07.640 --> 12:11.000
And so at this point, it's time to jump onto the CLI and see it all in action.