WEBVTT

1
00:00.000 --> 00:04.280
All right, so all same deal, we're going to have an eight question quiz here

2
00:04.280 --> 00:04.680
and make

3
00:04.680 --> 00:08.290
sure you pause the video appropriately to be able to answer the question

4
00:08.290 --> 00:09.040
yourself.

5
00:09.040 --> 00:12.680
So first up here, an edge router is connected to an upstream service provider

6
00:12.680 --> 00:13.280
router.

7
00:13.280 --> 00:15.280
Just go ahead and sketch that out here.

8
00:15.280 --> 00:20.050
So we've got maybe this is our corporate edge router and this is the service

9
00:20.050 --> 00:21.200
provider and

10
00:21.200 --> 00:27.100
an SLA of 75 megabits per second has been set, which interface will you shaping

11
00:27.100 --> 00:27.600
and which

12
00:27.600 --> 00:29.240
will use policing.

13
00:29.240 --> 00:34.720
So the general idea here is that we don't have an ethernet speed that we could
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

13
00:29.240 --> 00:34.720
So the general idea here is that we don't have an ethernet speed that we could

14
00:34.720 --> 00:35.160
set our

15
00:35.160 --> 00:38.080
interfaces to that matches the SLA.

16
00:38.080 --> 00:42.540
If the SLA happened to be 100 megabits per second and this was a gig link, then

17
00:42.540 --> 00:42.920
we could

18
00:42.920 --> 00:46.320
set the speed to 100 and everybody would be pretty happy with that.

19
00:46.320 --> 00:49.320
But we can't do that with 75 megabits per second.

20
00:49.320 --> 00:52.680
Instead, we're going to have a one gig or 100 meg connection and we're going to

21
00:52.680 --> 00:53.040
have

22
00:53.040 --> 00:54.840
to restrict the bandwidth.

23
00:54.840 --> 01:00.620
So at that point, the service provider is going to use policing and we should
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

23
00:54.840 --> 01:00.620
So at that point, the service provider is going to use policing and we should

24
01:00.620 --> 01:01.760
use shaping.

25
01:01.760 --> 01:06.240
So there's our answer shaping on the corporate router, policing on the service

26
01:06.240 --> 01:07.720
provider router.

27
01:07.720 --> 01:09.280
So what's going on here?

28
01:09.280 --> 01:16.420
Well the policing is going to enforce our SLA and it's going to do that by

29
01:16.420 --> 01:18.000
dropping excess

30
01:18.000 --> 01:19.400
packets.

31
01:19.400 --> 01:23.310
So if I exceed that 75 megabits per second with potentially a little bit of

32
01:23.310 --> 01:23.800
grace in

33
01:23.800 --> 01:25.520
there, we call that bursting traffic.

34
01:25.520 --> 01:28.840
I could burst above it for a short amount of time.

35
01:28.840 --> 01:33.700
And so if I burst above it fine, but ultimately I'm going to eventually run out
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:28.840 --> 01:33.700
And so if I burst above it fine, but ultimately I'm going to eventually run out

36
01:33.700 --> 01:34.480
of grace and

37
01:34.480 --> 01:37.560
I'm going to have my packets start to get dropped.

38
01:37.560 --> 01:41.720
The problem with this is that, yeah, okay, fine, so be it.

39
01:41.720 --> 01:43.080
I'm sending too much traffic.

40
01:43.080 --> 01:44.200
You have to drop it.

41
01:44.200 --> 01:48.560
The problem is that we're going to be indiscriminate about what traffic we drop

42
01:48.560 --> 01:48.840
.

43
01:48.840 --> 01:55.560
We can drop any traffic and the service provider does not care, meaning that

44
01:55.560 --> 01:57.280
voice over IP packets

45
01:57.280 --> 02:02.160
could be dropped when we start to exceed our traffic, our SLA.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
01:57.280 --> 02:02.160
could be dropped when we start to exceed our traffic, our SLA.

46
02:02.160 --> 02:05.750
And so we'd rather say, you know what, yeah, you're supposed to drop our excess

47
02:05.750 --> 02:06.400
traffic,

48
02:06.400 --> 02:11.000
but we want to make sure that you drop absolutely no traffic whatsoever.

49
02:11.000 --> 02:15.200
Instead, I will perform the drops myself.

50
02:15.200 --> 02:20.630
On my end, if I know I'm going to exceed the SLA, and this way I get choice in

51
02:20.630 --> 02:21.600
the matter.

52
02:21.600 --> 02:24.560
So I can keep my voice over IP packets intact.

53
02:24.560 --> 02:29.900
I can intentionally drop my bulk traffic like internet streams and downloads

54
02:29.900 --> 02:31.280
and file transfers
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

54
02:29.900 --> 02:31.280
and file transfers

55
02:31.280 --> 02:34.680
and things like that that aren't latency sensitive.

56
02:34.680 --> 02:39.650
And those packets will get resented in some form or another, whereas voice over

57
02:39.650 --> 02:40.400
IP packets

58
02:40.400 --> 02:41.960
don't get reset.

59
02:41.960 --> 02:46.870
And so I'm going to use shaping in order to accomplish this, which may actually

60
02:46.870 --> 02:47.200
mean

61
02:47.200 --> 02:48.840
I don't have to drop a whole lot.

62
02:48.840 --> 02:53.110
If depending on the ebbs and flows of traffic, I can kind of take that traffic

63
02:53.110 --> 02:53.920
and shape it

64
02:53.920 --> 02:55.320
down.

65
02:55.320 --> 02:59.040
And maybe with enough buffering, I can get all of the packets through.

66
02:59.040 --> 03:02.640
But in times of congestion, I don't get to just not drop any traffic.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

66
02:59.040 --> 03:02.640
But in times of congestion, I don't get to just not drop any traffic.

67
03:02.640 --> 03:04.760
I'm going to have to drop it at that point.

68
03:04.760 --> 03:07.040
I can drop the non critical traffic.

69
03:07.040 --> 03:11.160
So shaping is always an outbound policy.

70
03:11.160 --> 03:15.860
Policing is usually an inbound policy, but it can technically be used outbound

71
03:15.860 --> 03:16.360
in most

72
03:16.360 --> 03:17.720
real world scenarios.

73
03:17.720 --> 03:23.640
We're going to see shaping be our outbound and policing be our inbound types of

74
03:23.640 --> 03:24.760
policies.

75
03:24.760 --> 03:30.320
Next question, what iOS XC command is used to configure the LLQ within a policy
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

75
03:24.760 --> 03:30.320
Next question, what iOS XC command is used to configure the LLQ within a policy

76
03:30.320 --> 03:30.920
map?

77
03:30.920 --> 03:36.150
So something to keep in mind is that we had a challenge in our configure QOS

78
03:36.150 --> 03:37.000
skill that

79
03:37.000 --> 03:39.680
allowed us to log in and perform configurations.

80
03:39.680 --> 03:43.590
So in order to best get our hands back on that, I recommend going back to that

81
03:43.590 --> 03:44.000
skill

82
03:44.000 --> 03:46.560
and performing the challenge there.

83
03:46.560 --> 03:50.230
However, in our case, it does still help to be able to answer questions like

84
03:50.230 --> 03:50.720
this to

85
03:50.720 --> 03:53.540
yeah, we don't have to have every command memorized, but we should have some of

86
03:53.540 --> 03:53.800
the

87
03:53.800 --> 03:56.360
big ones, at least in our minds.

88
03:56.360 --> 04:00.780
And so this one here about a command used to configure LLQ, the difference
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
03:56.360 --> 04:00.780
And so this one here about a command used to configure LLQ, the difference

89
04:00.780 --> 04:01.440
between an

90
04:01.440 --> 04:08.010
LLQ and a normal Q is I'm going to need to perform a bandwidth command with a

91
04:08.010 --> 04:08.280
normal

92
04:08.280 --> 04:15.110
Q. This is how we perform a reservation for, let's say, video traffic or maybe

93
04:15.110 --> 04:15.640
my best

94
04:15.640 --> 04:17.040
effort traffic.

95
04:17.040 --> 04:21.080
But the priority command is what's going to set LLQ.

96
04:21.080 --> 04:24.570
And I can just say priority and hit enter and it becomes a strict priority

97
04:24.570 --> 04:25.240
queue or I

98
04:25.240 --> 04:29.820
can enter like 100 kilobits per second or 100 megabits per second or whatever

99
04:29.820 --> 04:30.280
value I
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
04:29.820 --> 04:30.280
value I

100
04:30.280 --> 04:34.950
want, which then turns into a limit, which prevents the strict priority queue

101
04:34.950 --> 04:35.640
from starving

102
04:35.640 --> 04:37.120
other traffic flows.

103
04:37.120 --> 04:39.760
But be here, that would be our answer.

104
04:39.760 --> 04:46.390
All right, similar question here, which iOS XC command is used to apply an MQC

105
04:46.390 --> 04:47.080
policy

106
04:47.080 --> 04:48.240
to an interface?

107
04:48.240 --> 04:52.040
Well, in order to apply our policy to an interface, that's going to be our

108
04:52.040 --> 04:53.240
service policy.

109
04:53.240 --> 04:54.360
So C is the answer.

110
04:54.360 --> 04:57.240
But we do need to remember how this all comes together.

111
04:57.240 --> 05:02.640
We're going to use class maps in order to perform the classification of the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

111
04:57.240 --> 05:02.640
We're going to use class maps in order to perform the classification of the

112
05:02.640 --> 05:03.720
traffic.

113
05:03.720 --> 05:08.560
And then, so this is classification, which is why we call it a class map, by

114
05:08.560 --> 05:09.200
the way,

115
05:09.200 --> 05:10.840
forming different traffic classes.

116
05:10.840 --> 05:14.880
And then our policies are going to be defined here in the policy map.

117
05:14.880 --> 05:18.840
So not too bad to remember which map is supposed to be used for which.

118
05:18.840 --> 05:24.900
But then I ultimately create this policy map and it consists of multiple class

119
05:24.900 --> 05:25.560
maps with

120
05:25.560 --> 05:27.120
the policies within them.

121
05:27.120 --> 05:30.720
So it sort of becomes this nested type of concept.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

121
05:27.120 --> 05:30.720
So it sort of becomes this nested type of concept.

122
05:30.720 --> 05:34.500
And then I'm going to take this policy map and apply it to an interface using

123
05:34.500 --> 05:35.120
the service

124
05:35.120 --> 05:36.120
policy command.

125
05:36.120 --> 05:39.880
I do have to specify whether it's input or output.

126
05:39.880 --> 05:45.840
But that is how the basic MQC structure comes together within the iOSXE

127
05:45.840 --> 05:47.560
configuration.

128
05:47.560 --> 05:50.080
All right, next up.

129
05:50.080 --> 05:55.180
What two goals here can be achieved by using weighted random early detect for

130
05:55.180 --> 05:56.000
congestion

131
05:56.000 --> 05:58.080
avoidance?

132
05:58.080 --> 06:01.760
Congestion avoidance is a very important aspect of quality of service and it
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

132
05:58.080 --> 06:01.760
Congestion avoidance is a very important aspect of quality of service and it

133
06:01.760 --> 06:02.320
doesn't

134
06:02.320 --> 06:06.930
tend to get as much attention as things like packet marking, classification and

135
06:06.930 --> 06:07.520
queuing

136
06:07.520 --> 06:09.520
and configuration, all these things.

137
06:09.520 --> 06:12.860
But congestion avoidance is very important and we have weighted random early

138
06:12.860 --> 06:13.320
detect as

139
06:13.320 --> 06:18.710
well as the random early detect concepts within the world of quality of service

140
06:18.710 --> 06:18.720
.

141
06:18.720 --> 06:20.160
So what are we trying to do here?

142
06:20.160 --> 06:22.080
I mean, the name is right there.

143
06:22.080 --> 06:25.160
We're trying to avoid congestion.

144
06:25.160 --> 06:26.160
How do we avoid congestion?

145
06:26.160 --> 06:30.460
I mean, wouldn't that be wonderful if we could just avoid congestion everywhere
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
06:26.160 --> 06:30.460
I mean, wouldn't that be wonderful if we could just avoid congestion everywhere

146
06:30.460 --> 06:30.520
?

147
06:30.520 --> 06:36.480
But the idea here is my queue and my buffer for an interface is only so large.

148
06:36.480 --> 06:42.060
And eventually even if I have multiple queues here, I'm going to run out of

149
06:42.060 --> 06:43.240
packet space.

150
06:43.240 --> 06:47.050
And so within a queue, let's say we're approaching the end of the queue here

151
06:47.050 --> 06:48.120
and another packet

152
06:48.120 --> 06:51.640
shows up that's supposed to go into that queue.

153
06:51.640 --> 06:55.400
Well now I am out of space and this packet gets dropped.

154
06:55.400 --> 06:59.180
And this is known as tail drop and it's sort of the default, if we want to call

155
06:59.180 --> 06:59.800
it congestion

156
06:59.800 --> 07:01.960
avoidance, it doesn't really avoid anything.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
06:59.800 --> 07:01.960
avoidance, it doesn't really avoid anything.

157
07:01.960 --> 07:06.680
But it's this default policy that exists within each queue.

158
07:06.680 --> 07:12.530
So instead I can use weighted random early detect and try to drop packets as

159
07:12.530 --> 07:13.480
different

160
07:13.480 --> 07:18.160
thresholds within the queue with a percent chance of being dropped.

161
07:18.160 --> 07:21.060
And this ties back to our shared forwarding to say that hey, you know, if a

162
07:21.060 --> 07:21.920
shared forwarding

163
07:21.920 --> 07:29.070
let's say 2x is going into this queue, well a 23 has a very high probability of

164
07:29.070 --> 07:29.840
getting

165
07:29.840 --> 07:35.000
dropped, whereas 22 is right in the middle and 21 has a low chance of being
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

165
07:29.840 --> 07:35.000
dropped, whereas 22 is right in the middle and 21 has a low chance of being

166
07:35.000 --> 07:35.880
dropped.

167
07:35.880 --> 07:43.110
But they all go into the same queue because they all have a priority value of

168
07:43.110 --> 07:44.240
AF2x.

169
07:44.240 --> 07:48.510
So at that point, I can say, you know, once I pass this threshold, I should

170
07:48.510 --> 07:49.520
start dropping

171
07:49.520 --> 07:53.970
AF23s and once I start, you know, get to this threshold, then I should start

172
07:53.970 --> 07:55.760
dropping AF22s

173
07:55.760 --> 07:59.510
and AF21 shouldn't be dropped until the end and then we've got the ability to

174
07:59.510 --> 08:00.160
kind of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

174
07:59.510 --> 08:00.160
kind of

175
08:00.160 --> 08:04.360
increase our rate of drops throughout the queue.

176
08:04.360 --> 08:08.820
And it's a whole topic of conversation that we looked at in an immense amount

177
08:08.820 --> 08:09.400
of depth

178
08:09.400 --> 08:12.160
down here in this skill.

179
08:12.160 --> 08:15.720
So what is ultimately the purpose of this?

180
08:15.720 --> 08:18.840
Well, as we just said, we want to prevent tail drop.

181
08:18.840 --> 08:24.950
We want to enable us to survive that and therefore our more critical packets

182
08:24.950 --> 08:25.520
like the

183
08:25.520 --> 08:31.040
21s shouldn't just get tail dropped if we have a bunch of 23s in the queue.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

183
08:25.520 --> 08:31.040
21s shouldn't just get tail dropped if we have a bunch of 23s in the queue.

184
08:31.040 --> 08:35.190
And so we're protecting our critical packets from getting tail dropped and that

185
08:35.190 --> 08:35.640
's a big

186
08:35.640 --> 08:37.320
part of it.

187
08:37.320 --> 08:42.760
But what's, but the other aspect of this is it's meant to smooth out my drops

188
08:42.760 --> 08:43.240
and not

189
08:43.240 --> 08:47.320
just, hey, sometimes I fill up and then I drop all the packets.

190
08:47.320 --> 08:52.440
Remember what we said with TCP, it means that I can, we ramp up because of the

191
08:52.440 --> 08:52.720
TCP

192
08:52.720 --> 08:57.520
windows, we ramp up our, our throughput and then all of a sudden we drop a

193
08:57.520 --> 08:58.920
bunch of packets

194
08:58.920 --> 09:03.370
and so TCP windows throttle back and we get this shark fin effect that we just
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

194
08:58.920 --> 09:03.370
and so TCP windows throttle back and we get this shark fin effect that we just

195
09:03.370 --> 09:03.840
kind of

196
09:03.840 --> 09:09.360
keep seeing this, that all TCP devices are responding the exact same way to the

197
09:09.360 --> 09:10.040
traffic

198
09:10.040 --> 09:11.040
drop.

199
09:11.040 --> 09:15.190
This is known as global synchronization and we want to prevent that, which

200
09:15.190 --> 09:15.760
interestingly

201
09:15.760 --> 09:21.260
enough, red without the weighted actually prevents that, but it doesn't do

202
09:21.260 --> 09:22.000
anything

203
09:22.000 --> 09:25.560
to help with the critical packets versus the not critical packets.

204
09:25.560 --> 09:29.480
And this is where weighted random early detect is able to do both.

205
09:29.480 --> 09:32.080
So be an E, those would be our answers.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

205
09:29.480 --> 09:32.080
So be an E, those would be our answers.

206
09:32.080 --> 09:36.630
All right, question five, what does it mean to have a three color policeer as

207
09:36.630 --> 09:37.160
opposed

208
09:37.160 --> 09:38.480
to two color?

209
09:38.480 --> 09:42.050
So policeers can get pretty complicated and we want to keep this within the

210
09:42.050 --> 09:42.680
scope of the

211
09:42.680 --> 09:44.280
course in the exam.

212
09:44.280 --> 09:47.700
And as a result, we're not, we don't need to necessarily have the entire token

213
09:47.700 --> 09:48.120
bucket

214
09:48.120 --> 09:52.930
system completely down pat, but we should understand some basic concepts such

215
09:52.930 --> 09:53.520
as what

216
09:53.520 --> 09:55.840
is a three color versus two color.

217
09:55.840 --> 09:59.440
The idea here is that we're going to support three different outcomes.

218
09:59.440 --> 10:03.400
Remember, we have three different actions that we can take.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

218
09:59.440 --> 10:03.400
Remember, we have three different actions that we can take.

219
10:03.400 --> 10:12.690
We can drop a packet or we can remark a packet or ideally we simply allow the

220
10:12.690 --> 10:14.120
packet to go

221
10:14.120 --> 10:15.320
through.

222
10:15.320 --> 10:19.520
And so if these are three actions, well, that's great and all, do we actually

223
10:19.520 --> 10:20.400
have three

224
10:20.400 --> 10:21.400
different categories?

225
10:21.400 --> 10:25.510
Well, if we have a two color policeer, we really only have two categories, sort

226
10:25.510 --> 10:25.820
of this

227
10:25.820 --> 10:32.570
concept of saying that I've got a rate established here and I'm conforming on
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

227
10:25.820 --> 10:32.570
concept of saying that I've got a rate established here and I'm conforming on

228
10:32.570 --> 10:34.560
this side and I'm

229
10:34.560 --> 10:40.000
exceeding the rate on the other side.

230
10:40.000 --> 10:43.970
But with a three color policeer, I have two rates that committed information

231
10:43.970 --> 10:44.440
rate and

232
10:44.440 --> 10:46.280
the peak information rate.

233
10:46.280 --> 10:48.360
And so now I actually have three categories.

234
10:48.360 --> 10:53.160
I'm conforming or I'm exceeding or I'm violating.

235
10:53.160 --> 10:58.500
And now I can take these actions and match each one up to one of these

236
10:58.500 --> 10:59.880
categories.

237
10:59.880 --> 11:01.280
So that's generally the idea.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

237
10:59.880 --> 11:01.280
So that's generally the idea.

238
11:01.280 --> 11:05.950
Now if I only have two colors, then I can take any one of these usually allows

239
11:05.950 --> 11:06.400
going

240
11:06.400 --> 11:08.960
to go here and maybe I'm just going to remark.

241
11:08.960 --> 11:12.770
I'm not actually going to drop anything with my policeer or maybe I'm not going

242
11:12.770 --> 11:13.280
to remark

243
11:13.280 --> 11:14.720
it, I'm just going to drop it.

244
11:14.720 --> 11:18.020
But either way, we see that we have to choose which action goes to which and a

245
11:18.020 --> 11:18.520
two color

246
11:18.520 --> 11:22.780
whereas three color kind of gives us these three different scenarios, which is

247
11:22.780 --> 11:23.240
likely

248
11:23.240 --> 11:26.720
going to align with the three different actions that we can take.

249
11:26.720 --> 11:31.090
All right, question number six, a three color policeer like we just talked
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

249
11:26.720 --> 11:31.090
All right, question number six, a three color policeer like we just talked

250
11:31.090 --> 11:32.040
about has been

251
11:32.040 --> 11:37.470
deployed onto an interface with that CIR of 50 megabits per second and a PIR of

252
11:37.470 --> 11:38.040
75.

253
11:38.040 --> 11:43.360
If the traffic flows about 70 megabits per second, how is traffic categorized?

254
11:43.360 --> 11:45.680
Well we basically just map this out for us.

255
11:45.680 --> 11:49.520
We've got the CIR of 50 megabits per second.

256
11:49.520 --> 11:53.680
We've got the PIR of 75 megabits per second.

257
11:53.680 --> 11:58.200
And we're suggesting that we're landing somewhere about here, about 70.

258
11:58.200 --> 11:59.800
So where are we?

259
11:59.800 --> 12:01.840
How is it going to be categorized?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

259
11:59.800 --> 12:01.840
How is it going to be categorized?

260
12:01.840 --> 12:07.430
Well in this three color policeer conforming is over on the left, exceeding is

261
12:07.430 --> 12:07.960
between

262
12:07.960 --> 12:11.040
the two and violating is on the right.

263
12:11.040 --> 12:15.680
So we are going to fit into the exceeding category.

264
12:15.680 --> 12:19.200
Notice that those are really the only three pushing was never on the table.

265
12:19.200 --> 12:23.000
All right, question seven, we are almost there.

266
12:23.000 --> 12:28.320
Which iOS XC policeer command is only used for three color policeers?

267
12:28.320 --> 12:34.240
So this is a little bit tricky because BC and CIR, these are definitely part of
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

267
12:28.320 --> 12:34.240
So this is a little bit tricky because BC and CIR, these are definitely part of

268
12:34.240 --> 12:34.520
two

269
12:34.520 --> 12:35.880
color policeers.

270
12:35.880 --> 12:38.040
And so it's not going to be either one of those.

271
12:38.040 --> 12:40.760
It's there for both two color and three color.

272
12:40.760 --> 12:45.620
The question is this excess burst as well as the peak information rate, those

273
12:45.620 --> 12:46.080
are both

274
12:46.080 --> 12:49.120
three color policeer concepts.

275
12:49.120 --> 12:51.160
Only one of them applies here though.

276
12:51.160 --> 12:53.840
And the answer is going to be PIR.

277
12:53.840 --> 13:00.480
Yeah, bird excess, excess burst, BE can actually be used with the three color
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

277
12:53.840 --> 13:00.480
Yeah, bird excess, excess burst, BE can actually be used with the three color

278
13:00.480 --> 13:01.040
policeers.

279
13:01.040 --> 13:05.200
But it can also be used here with the two color policeers.

280
13:05.200 --> 13:12.070
Otherwise if we don't specify it assumes a default value, or but in the end if

281
13:12.070 --> 13:12.880
we are,

282
13:12.880 --> 13:17.440
if we're wanting to configure a three color policeer, we have to specify the P

283
13:17.440 --> 13:18.000
IR and that's

284
13:18.000 --> 13:20.720
the only time it's used.

285
13:20.720 --> 13:24.200
All right, finally last question.

286
13:24.200 --> 13:29.200
We're going to match the wireless user priorities to the below access category.

287
13:29.200 --> 13:32.320
So remember how wireless quality of service works.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

287
13:29.200 --> 13:32.320
So remember how wireless quality of service works.

288
13:32.320 --> 13:36.000
We're not going to use COS and usually we're not going to rely on DSCP.

289
13:36.000 --> 13:39.750
We have a whole new type of category of our tags and that would be user

290
13:39.750 --> 13:40.720
priorities.

291
13:40.720 --> 13:46.300
So these user priorities are going to be three bits, which means it ranges from

292
13:46.300 --> 13:47.920
zero to seven.

293
13:47.920 --> 13:50.640
Furthermore, we don't get to define our own queues.

294
13:50.640 --> 13:53.840
We're not going to use class based weighted fair queuing to define our own.

295
13:53.840 --> 13:57.960
Instead, we're going to use access categories that have been predefined for us.

296
13:57.960 --> 14:03.840
And those would be these four on the left, V.O., V.I., BE and BK.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

296
13:57.960 --> 14:03.840
And those would be these four on the left, V.O., V.I., BE and BK.

297
14:03.840 --> 14:05.200
I did not make those up.

298
14:05.200 --> 14:07.520
Those are what we use in the wireless world.

299
14:07.520 --> 14:10.080
And so we need to understand what they represent.

300
14:10.080 --> 14:15.920
V.O. is voice over IP, V.I. is video, BE is best effort.

301
14:15.920 --> 14:20.800
I don't just say BE here, MBK would be background.

302
14:20.800 --> 14:24.970
And in the networking world, we sometimes refer to this as scavenger class of

303
14:24.970 --> 14:25.680
traffic.

304
14:25.680 --> 14:31.170
So we could look at this from the perspective that if I'm configuring a Cisco
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

304
14:25.680 --> 14:31.170
So we could look at this from the perspective that if I'm configuring a Cisco

305
14:31.170 --> 14:31.600
router, I

306
14:31.600 --> 14:35.520
get to decide which tags go into which queues.

307
14:35.520 --> 14:39.780
If I don't get to do that either with wireless, all of this is kind of set up

308
14:39.780 --> 14:40.400
for me.

309
14:40.400 --> 14:43.880
And so the user priorities are just going to go down the pipe here with a

310
14:43.880 --> 14:44.440
little bit

311
14:44.440 --> 14:45.440
of an exception.

312
14:45.440 --> 14:50.200
So we start at the top, voice over IP gets six and seven.

313
14:50.200 --> 14:54.600
Yes, at the moment, at the time of this video, probably not going to change at

314
14:54.600 --> 14:55.520
this point.

315
14:55.520 --> 15:00.000
We get two tags per queue, which means six and seven are treated identically.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

315
14:55.520 --> 15:00.000
We get two tags per queue, which means six and seven are treated identically.

316
15:00.000 --> 15:03.700
Video would be the next two values, four and five.

317
15:03.700 --> 15:07.920
Best effort we'd say would be the next two, which is three except, it's not

318
15:07.920 --> 15:08.600
three and

319
15:08.600 --> 15:09.600
two.

320
15:09.600 --> 15:14.370
So we're counting down six, seven, five, six and seven, countdown seven, six,

321
15:14.370 --> 15:15.040
five, four,

322
15:15.040 --> 15:16.040
three.

323
15:16.040 --> 15:20.120
But then we actually are also going to include zero.

324
15:20.120 --> 15:21.480
Why are we including zero?

325
15:21.480 --> 15:26.240
Because a no tag or untagged packet is the same thing as a zero.

326
15:26.240 --> 15:29.280
We want to place that into best effort, not into background.

327
15:29.280 --> 15:33.080
So zero must land with best effort, even though we're counting down seven, six,
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

327
15:29.280 --> 15:33.080
So zero must land with best effort, even though we're counting down seven, six,

328
15:33.080 --> 15:33.720
five, four,

329
15:33.720 --> 15:35.320
three.

330
15:35.320 --> 15:39.270
And so there we get three and zero, which means the last two go into background

331
15:39.270 --> 15:39.560
.

332
15:39.560 --> 15:44.620
And the background is scavenger, which again, is sort of a, it's the traffic

333
15:44.620 --> 15:45.200
type that we

334
15:45.200 --> 15:48.320
say in times of congestion, just drop it all.

335
15:48.320 --> 15:49.400
We don't care about it.

336
15:49.400 --> 15:53.200
If it doesn't go through, if it never goes through, that's perfectly fine.

337
15:53.200 --> 15:56.260
And it's up to each organization to define what types of traffic fits into

338
15:56.260 --> 15:57.000
background.

339
15:57.000 --> 16:00.960
So when it comes to wireless, uh, quality of service, this is some of the main
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

339
15:57.000 --> 16:00.960
So when it comes to wireless, uh, quality of service, this is some of the main

340
16:00.960 --> 16:01.520
concepts

341
16:01.520 --> 16:05.760
to try to take away as memorizing the different access categories, as well as

342
16:05.760 --> 16:06.960
the user priorities

343
16:06.960 --> 16:08.080
that belong in each one.