WEBVTT

1
00:00.000 --> 00:05.160
So we're gonna call the issue with policing and why we have it.

2
00:05.160 --> 00:10.350
The idea here is maybe we're a service provider and we have a router upstream

3
00:10.350 --> 00:12.920
from a customer

4
00:12.920 --> 00:16.920
and we want to make sure that we are limiting their bandwidth on this link.

5
00:16.920 --> 00:20.810
Now this link, I've drawn it almost like it's a serial link here, but this

6
00:20.810 --> 00:21.560
could just be

7
00:21.560 --> 00:25.720
a straight up one gigabit per second ethernet handoff.

8
00:25.720 --> 00:31.600
But the customer only paid for 600 megabits per second, something like that.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

8
00:25.720 --> 00:31.600
But the customer only paid for 600 megabits per second, something like that.

9
00:31.600 --> 00:34.730
Naturally I can't set an ethernet speed to anything other than what's

10
00:34.730 --> 00:36.160
established as

11
00:36.160 --> 00:42.710
a specified speed, like 1 gig, 2.5 gig, 100 meg, and 600 meg is just not one of

12
00:42.710 --> 00:43.200
those

13
00:43.200 --> 00:44.280
options.

14
00:44.280 --> 00:48.080
So what I do is I establish a policeor.

15
00:48.080 --> 00:51.160
This is built on my MQC policy.

16
00:51.160 --> 00:58.280
I apply it to this interface and I limit it to 600 megabits per second.

17
00:58.280 --> 01:03.950
But as we've said before, it's very difficult to just track data traffic flow
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

17
00:58.280 --> 01:03.950
But as we've said before, it's very difficult to just track data traffic flow

18
01:03.950 --> 01:04.920
here and say

19
01:04.920 --> 01:10.360
that, okay, this packet is in clear violation of 600 megabits per second.

20
01:10.360 --> 01:15.670
And the reason is because this megabits per second is not a number that exists

21
01:15.670 --> 01:16.200
at any

22
01:16.200 --> 01:17.400
given time.

23
01:17.400 --> 01:23.800
And we're talking about bits over seconds.

24
01:23.800 --> 01:27.400
And so the question is, how many seconds are we talking about here?

25
01:27.400 --> 01:32.580
If I look at your bits over the course of one millisecond, well, that means
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

25
01:27.400 --> 01:32.580
If I look at your bits over the course of one millisecond, well, that means

26
01:32.580 --> 01:33.360
that it's

27
01:33.360 --> 01:36.830
going to have a very different measurement than if I measure this out over

28
01:36.830 --> 01:37.960
several seconds.

29
01:37.960 --> 01:43.660
And so we want a fair way to evaluate whether or not you're abiding by the

30
01:43.660 --> 01:45.400
policing policy.

31
01:45.400 --> 01:49.280
And that leads us to the token bucket methodology.

32
01:49.280 --> 01:53.080
So what we want to do here is explore how exactly we're going to take our token

33
01:53.080 --> 01:53.560
bucket

34
01:53.560 --> 01:58.040
method and translate it over to configuration.

35
01:58.040 --> 02:02.520
So recall how exactly our token bucket system works.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

35
01:58.040 --> 02:02.520
So recall how exactly our token bucket system works.

36
02:02.520 --> 02:06.810
The idea here is that we want to limit you by your rate, but we also want to

37
02:06.810 --> 02:07.640
understand

38
02:07.640 --> 02:12.680
that there's not a super fair way of measuring this where we all agree on

39
02:12.680 --> 02:13.640
exactly what, you

40
02:13.640 --> 02:15.680
know, what that means.

41
02:15.680 --> 02:20.880
Again, we all would maybe have different ideas of what average time we should

42
02:20.880 --> 02:21.720
use here.

43
02:21.720 --> 02:26.610
And so instead we're going to come up with something that does provide a firm

44
02:26.610 --> 02:27.000
answer.

45
02:27.000 --> 02:31.840
And so we're going to have a rate of tokens.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

45
02:27.000 --> 02:31.840
And so we're going to have a rate of tokens.

46
02:31.840 --> 02:34.600
We collect these tokens in what we call a bucket.

47
02:34.600 --> 02:40.600
Naturally, this is just a bunch of bits inside of the rowdy router or switch

48
02:40.600 --> 02:41.560
system.

49
02:41.560 --> 02:47.160
It's not a physical bucket or anything like that, but it's just a tracking of

50
02:47.160 --> 02:47.920
how many

51
02:47.920 --> 02:49.600
packets were allowed to send.

52
02:49.600 --> 02:55.400
And importantly, each one of these tokens is actually equal to one byte.

53
02:55.400 --> 03:01.000
So yes, larger packets do require more tokens because if a token matched up to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

53
02:55.400 --> 03:01.000
So yes, larger packets do require more tokens because if a token matched up to

54
03:01.000 --> 03:01.880
a packet,

55
03:01.880 --> 03:05.400
then a smaller package would consume our tokens at the same rate as larger

56
03:05.400 --> 03:06.320
packets and that

57
03:06.320 --> 03:08.120
wouldn't make any sense.

58
03:08.120 --> 03:15.640
We fill this token bucket at a particular rate.

59
03:15.640 --> 03:20.160
This rate is known as the committed information rate or the CIR.

60
03:20.160 --> 03:24.220
And this is an important term because we're going to use this as part of our

61
03:24.220 --> 03:25.560
CLI configuration.

62
03:25.560 --> 03:33.880
So again, that stands for the committed information rate.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

62
03:25.560 --> 03:33.880
So again, that stands for the committed information rate.

63
03:33.880 --> 03:40.130
And so when packets come through here, if we have a packet that wants to be

64
03:40.130 --> 03:40.840
sent, and

65
03:40.840 --> 03:47.090
let's say it's 600 bytes in size, well, I'm going to attempt to consume 600

66
03:47.090 --> 03:47.960
tokens.

67
03:47.960 --> 03:52.720
So if I have 600 tokens to consume, I will consume those.

68
03:52.720 --> 03:54.800
I will say, all right, we are good to go.

69
03:54.800 --> 04:00.120
And then this falls into that category of a conforming packet.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

69
03:54.800 --> 04:00.120
And then this falls into that category of a conforming packet.

70
04:00.120 --> 04:03.670
Whereas if a packet comes through and it could be smaller than 600, it could be

71
04:03.670 --> 04:05.520
400 bytes.

72
04:05.520 --> 04:09.520
But maybe that 600 byte packet consumed all of our tokens.

73
04:09.520 --> 04:15.720
And so we say, all right, well, we don't actually have 400 tokens.

74
04:15.720 --> 04:20.960
And so we're going to categorize this as an exceeding packet.

75
04:20.960 --> 04:24.200
Now the action here is up to us.

76
04:24.200 --> 04:28.870
I can use actions as we've said, such as transmit or allow this packet to go

77
04:28.870 --> 04:29.720
through.

78
04:29.720 --> 04:32.120
I can drop the packet.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

78
04:29.720 --> 04:32.120
I can drop the packet.

79
04:32.120 --> 04:36.200
And so usually we have conforming as a transmit action, exceeding as a drop

80
04:36.200 --> 04:36.880
action.

81
04:36.880 --> 04:41.520
But we can actually remark the packet and transmit it as well.

82
04:41.520 --> 04:45.310
So this is sort of a a punishment option to say, we're going to send this

83
04:45.310 --> 04:46.440
packet, but

84
04:46.440 --> 04:50.000
we're going to make it more likely that this packet gets dropped down the line.

85
04:50.000 --> 04:52.840
And so we'll remark it and send it.

86
04:52.840 --> 04:56.080
So we're going to send it for right now, but it might get dropped later.

87
04:56.080 --> 04:58.400
That's usually what we're talking about with this.

88
04:58.400 --> 05:03.240
And I will say with the standard token bucket system, where we have two stat
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

88
04:58.400 --> 05:03.240
And I will say with the standard token bucket system, where we have two stat

89
05:03.240 --> 05:04.720
uses, conform

90
05:04.720 --> 05:08.800
and exceed, we're usually going to match those up to transmit and drop.

91
05:08.800 --> 05:12.300
There's not a whole lot of situations where we would remark the exceeding

92
05:12.300 --> 05:13.320
traffic, because

93
05:13.320 --> 05:18.260
in that situation, we would not have the option to drop traffic, since we only

94
05:18.260 --> 05:19.520
have two different

95
05:19.520 --> 05:21.360
statuses.

96
05:21.360 --> 05:22.880
Now here's a question for us.

97
05:22.880 --> 05:26.200
Why have this bucket at all?

98
05:26.200 --> 05:28.280
Why have the token bucket?

99
05:28.280 --> 05:33.950
Why not just more or less, why not just say that, hey, this rate is going to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

99
05:28.280 --> 05:33.950
Why not just more or less, why not just say that, hey, this rate is going to

100
05:33.950 --> 05:34.800
allow me to

101
05:34.800 --> 05:37.720
send so many packets at once?

102
05:37.720 --> 05:43.680
Well the reason for this is because we are going to have a size for our token

103
05:43.680 --> 05:44.480
bucket,

104
05:44.480 --> 05:46.880
and this size is going to be measured in bytes.

105
05:46.880 --> 05:54.080
And so this provides a number of bytes that sort of like a buffer.

106
05:54.080 --> 05:59.920
And this buffer is intended to allow us to burst by sending more traffic than

107
05:59.920 --> 06:00.560
let's say
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

107
05:59.920 --> 06:00.560
let's say

108
06:00.560 --> 06:06.920
the 600 megabits per second that we signed up to have here.

109
06:06.920 --> 06:10.620
Since we can configure the size of the bucket, that means that if we have a

110
06:10.620 --> 06:11.600
smaller bucket,

111
06:11.600 --> 06:13.360
we allow for smaller bursts.

112
06:13.360 --> 06:16.560
If we have larger bucket, we allow for greater bursts.

113
06:16.560 --> 06:22.730
But naturally, if I'm filling this bucket, let's say at 600 megabits per second

114
06:22.730 --> 06:23.040
, and

115
06:23.040 --> 06:29.160
I'm sending packets here at about 600 megabits per second, I'm maxing it out,

116
06:29.160 --> 06:29.720
well any amount

117
06:29.720 --> 06:35.650
of bursting will deplete the bucket and as long as one token basically goes in
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

117
06:29.720 --> 06:35.650
of bursting will deplete the bucket and as long as one token basically goes in

118
06:35.650 --> 06:35.880
and then

119
06:35.880 --> 06:40.830
immediately comes out, if that's the rate at which I'm sending packets, then

120
06:40.830 --> 06:41.520
this bucket

121
06:41.520 --> 06:43.840
isn't going to fill up anytime soon.

122
06:43.840 --> 06:48.190
We really have to see a lull in traffic, basically we go down to like 400 or

123
06:48.190 --> 06:49.480
300 megabits per

124
06:49.480 --> 06:53.880
second for a while, and that'll allow the bucket to fill back up.

125
06:53.880 --> 06:57.590
So kind of an interesting mechanism when we put it all together and see kind of

126
06:57.590 --> 06:57.800
how it

127
06:57.800 --> 07:02.720
all works here, but this is the basic set of mechanisms for the token bucket.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

127
06:57.800 --> 07:02.720
all works here, but this is the basic set of mechanisms for the token bucket.

128
07:02.720 --> 07:06.460
We especially need to pay attention to a few things when it comes to our

129
07:06.460 --> 07:07.520
configuration.

130
07:07.520 --> 07:11.840
We have to pay attention to this CIR, the committed information rate.

131
07:11.840 --> 07:15.200
We have to pay attention to the size of the token bucket.

132
07:15.200 --> 07:19.890
We have a phrase for this, we call this the committed burst or BC, and we'll

133
07:19.890 --> 07:20.520
see later

134
07:20.520 --> 07:25.590
there's a BE as well, so we need to keep those straight, but BC for right now

135
07:25.590 --> 07:26.360
is going to

136
07:26.360 --> 07:27.520
be important.

137
07:27.520 --> 07:32.020
We also are going to need to pay attention to the fact that this action is not
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

137
07:27.520 --> 07:32.020
We also are going to need to pay attention to the fact that this action is not

138
07:32.020 --> 07:33.020
predefined.

139
07:33.020 --> 07:35.320
We have to decide what action to take.

140
07:35.320 --> 07:41.440
The token bucket system only gives us a status for a particular packet.

141
07:41.440 --> 07:46.680
It gives up to us whether we're going to drop or remark those packets.

142
07:46.680 --> 07:52.150
So when we look at the configuration at the CLI, we're going to perform this

143
07:52.150 --> 07:53.400
configuration

144
07:53.400 --> 07:57.640
under a policy map, and then under a class.

145
07:57.640 --> 08:01.660
So whatever class this is, a lot of cases we're going to apply policing to the
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

145
07:57.640 --> 08:01.660
So whatever class this is, a lot of cases we're going to apply policing to the

146
08:01.660 --> 08:02.200
default

147
08:02.200 --> 08:03.200
class.

148
08:03.200 --> 08:08.400
So this might be, for example, class default in our configurations.

149
08:08.400 --> 08:12.980
But if we're policing individual tags at different rates, then we might see

150
08:12.980 --> 08:13.960
police are supplied

151
08:13.960 --> 08:17.800
to different classes than just the class default.

152
08:17.800 --> 08:19.160
So keep that in mind as well.

153
08:19.160 --> 08:21.000
But here we get into the syntax.

154
08:21.000 --> 08:24.480
So the syntax is going to involve the word police.

155
08:24.480 --> 08:26.520
That's what kicks us off here.

156
08:26.520 --> 08:30.160
And typically we're going to specify the CIR right away.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

156
08:26.520 --> 08:30.160
And typically we're going to specify the CIR right away.

157
08:30.160 --> 08:33.440
And then we apply that rate, whatever that rate is.

158
08:33.440 --> 08:35.640
So maybe it's 80 kilobits per second.

159
08:35.640 --> 08:38.200
Maybe it's 600 megabits per second.

160
08:38.200 --> 08:44.110
But we're going to apply this as again, the CIR here in our token bucket

161
08:44.110 --> 08:45.600
methodology.

162
08:45.600 --> 08:48.560
From here, we are going to want to assign a BC.

163
08:48.560 --> 08:50.120
So type BC in.

164
08:50.120 --> 08:53.920
And then this is going to be the size of our bucket.

165
08:53.920 --> 08:58.360
Now this is actually an optional configuration.

166
08:58.360 --> 08:59.920
We could just hit enter here.

167
08:59.920 --> 09:02.840
Now if we hit enter, might say, well, does that mean that there's no bucket?
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

167
08:59.920 --> 09:02.840
Now if we hit enter, might say, well, does that mean that there's no bucket?

168
09:02.840 --> 09:07.160
Well, no, actually, there is a default size.

169
09:07.160 --> 09:13.600
But this default size is actually not based on a size but based on a time.

170
09:13.600 --> 09:19.760
It's based on 250 milliseconds of traffic based on this rate.

171
09:19.760 --> 09:22.200
Kind of an interesting situation here.

172
09:22.200 --> 09:31.070
So as an example here, let's just say that we enter a CIR of-- this is just to
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

172
09:22.200 --> 09:31.070
So as an example here, let's just say that we enter a CIR of-- this is just to

173
09:31.070 --> 09:33.640
880 kilobits

174
09:33.640 --> 09:36.480
per second, 80,000 bits per second.

175
09:36.480 --> 09:42.570
So if I'm going to say how much the default BC is, if I just hit enter with

176
09:42.570 --> 09:43.520
this CIR of

177
09:43.520 --> 09:48.840
80 kilobits per second, how big is my token bucket?

178
09:48.840 --> 09:51.520
Well, based on 250 milliseconds, we just do our math.

179
09:51.520 --> 10:01.920
We say 80,000 bits per second times 250 milliseconds, so 0.250 seconds.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

179
09:51.520 --> 10:01.920
We say 80,000 bits per second times 250 milliseconds, so 0.250 seconds.

180
10:01.920 --> 10:06.770
But then we also have to convert bits to bytes because, again, our size is in

181
10:06.770 --> 10:07.480
bytes.

182
10:07.480 --> 10:14.840
So we'd multiply by 8 bits per byte.

183
10:14.840 --> 10:18.250
Little bit of high school math here, but essentially what we do is we could say

184
10:18.250 --> 10:18.840
, OK,

185
10:18.840 --> 10:22.640
well, 80,000 divided by 8, that's going to be 10,000.

186
10:22.640 --> 10:26.680
And then I'm effectively dividing the 10,000 by 4.

187
10:26.680 --> 10:31.320
So this would be 2,500 bytes.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

187
10:26.680 --> 10:31.320
So this would be 2,500 bytes.

188
10:31.320 --> 10:34.360
Somebody can check my math on that, but I believe that's correct.

189
10:34.360 --> 10:41.950
So if I don't specify a BC, the size will be based on the 250 millisecond

190
10:41.950 --> 10:43.280
default.

191
10:43.280 --> 10:49.860
And there is a minimum value of 1,500 bytes, although this could vary by

192
10:49.860 --> 10:51.000
platform.

193
10:51.000 --> 10:52.800
So keep that in mind as well.

194
10:52.800 --> 10:57.980
But if we have a really small CIR of like 8,000 bits per second, or 8 kilobits

195
10:57.980 --> 10:59.120
per second,

196
10:59.120 --> 11:01.200
that would be an extremely small BC.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

196
10:59.120 --> 11:01.200
that would be an extremely small BC.

197
11:01.200 --> 11:04.840
And yeah, the system's not going to go that low.

198
11:04.840 --> 11:08.760
It's going to go down to 1,500 bytes.

199
11:08.760 --> 11:11.600
Now we're not quite done because we have this third thing that we have to pay

200
11:11.600 --> 11:12.160
attention to.

201
11:12.160 --> 11:13.280
We've got our CIR.

202
11:13.280 --> 11:14.800
We've got our BC.

203
11:14.800 --> 11:18.680
And so once I hit Enter, I do my police command again.

204
11:18.680 --> 11:22.720
So something like CIR, whatever, BC, whatever.

205
11:22.720 --> 11:24.240
I could actually keep going here.

206
11:24.240 --> 11:26.040
The syntax is very flexible.

207
11:26.040 --> 11:29.920
I could keep going and say conform action, exceed action.

208
11:29.920 --> 11:31.880
And we'll see this when we're coming up.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

208
11:29.920 --> 11:31.880
And we'll see this when we're coming up.

209
11:31.880 --> 11:34.840
But I can also just hit Enter here.

210
11:34.840 --> 11:39.670
And by hitting Enter, now I enter into a police sub-configuration option, where

211
11:39.670 --> 11:41.120
now I can type

212
11:41.120 --> 11:44.480
out my conform action.

213
11:44.480 --> 11:48.280
And so I could say conform action transmit.

214
11:48.280 --> 11:51.560
And I can say exceed action in here as well.

215
11:51.560 --> 11:58.490
So my exceed, exceed action could just simply be drop, which in this basic

216
11:58.490 --> 11:59.400
token bucket

217
11:59.400 --> 12:03.600
system, that's oftentimes what we are going to go with.
WEBVTT
X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000

217
11:59.400 --> 12:03.600
system, that's oftentimes what we are going to go with.

218
12:03.600 --> 12:06.780
So that's an idea of the system we're trying to build, as well as the

219
12:06.780 --> 12:07.720
configuration it

220
12:07.720 --> 12:08.720
maps to.

221
12:08.720 --> 12:11.040
Let's go ahead and jump on the CLI and see what this looks like.