WEBVTT 0:00:02.880000 --> 0:00:07.260000 Hello and welcome to this video titled, congestion avoidance with policing 0:00:07.260000 --> 0:00:14.160000 and shaping. In this video I'm going to cover an overview of what is meant 0:00:14.160000 --> 0:00:18.520000 by the term or phrase congestion avoidance. 0:00:18.520000 --> 0:00:20.820000 And by the time we're done with this video you'll understand what these 0:00:20.820000 --> 0:00:25.500000 terms mean of policing, shaping and markdown. 0:00:25.500000 --> 0:00:30.180000 And I'll compare the differences between policing and shaping. 0:00:30.180000 --> 0:00:35.400000 So what is congestion avoidance? 0:00:35.400000 --> 0:00:40.100000 So we know that the whole reason why we need quality of service in the 0:00:40.100000 --> 0:00:43.720000 first place is to deal with links that are congested. 0:00:43.720000 --> 0:00:47.620000 If there was no congestion anywhere in any interface we wouldn't need 0:00:47.620000 --> 0:00:51.800000 QoS. As soon as the packet came in it'd go right out, it wouldn't delay, 0:00:51.800000 --> 0:00:53.720000 it wouldn't be dropped, we'd have no problems. 0:00:53.720000 --> 0:00:57.940000 But the problem is there is congestion in networks and unfortunately a 0:00:57.940000 --> 0:01:01.200000 lot of times you don't know where that congestion is going to be. 0:01:01.200000 --> 0:01:06.460000 So congestion avoidance is really talking about it's a general term used 0:01:06.460000 --> 0:01:10.840000 to define a set of features that attempt to prevent cues from becoming 0:01:10.840000 --> 0:01:16.500000 congested. So this is our overall objective here is that if I have a situation 0:01:16.500000 --> 0:01:24.980000 like this where I have a whole bunch of input ports, maybe these are ports 0:01:24.980000 --> 0:01:28.800000 leading to hosts, maybe ports leading to other parts of my network, they're 0:01:28.800000 --> 0:01:32.600000 all coming into this device and all the traffic that's coming in those 0:01:32.600000 --> 0:01:37.660000 ports is being funneled out one egress port. 0:01:37.660000 --> 0:01:42.700000 Well this egress port might get congested because it just can't put those 0:01:42.700000 --> 0:01:45.420000 things out on the wire fast enough. 0:01:45.420000 --> 0:01:49.040000 And if I allow all those things to be directed to this egress port and 0:01:49.040000 --> 0:01:52.500000 these are my memory buffers right here, those memory buffers could get 0:01:52.500000 --> 0:01:56.600000 full. And I have no choice but to start dropping packets because I got 0:01:56.600000 --> 0:01:58.620000 no place left to put them. 0:01:58.620000 --> 0:02:01.740000 So congestion avoidance like it says is a bunch of features that say hey 0:02:01.740000 --> 0:02:07.100000 you know what, let's try to stop these packets or maybe some of these 0:02:07.100000 --> 0:02:11.180000 packets from getting into this queue in the first place, maybe the low 0:02:11.180000 --> 0:02:15.880000 priority, the stuff that's of lesser importance to us to always make sure 0:02:15.880000 --> 0:02:21.720000 there's some room in that queue for the higher priority stuff. 0:02:21.720000 --> 0:02:24.580000 And that's what we're talking about right here. 0:02:24.580000 --> 0:02:26.560000 So where would you do this? 0:02:26.560000 --> 0:02:30.320000 Well there's three general places depending on your platform and depending 0:02:30.320000 --> 0:02:34.180000 on what architecture have that will allow you to do this. 0:02:34.180000 --> 0:02:44.300000 Number one, we could do it on the ingress interface queue, on the ingress 0:02:44.300000 --> 0:02:54.320000 interface if these are all of my ingress ports and that's my one egress 0:02:54.320000 --> 0:02:58.640000 port. Well we know that each one of these ingress ports is also going 0:02:58.640000 --> 0:03:03.080000 to have some memory, some queues and buffers for storing things. 0:03:03.080000 --> 0:03:08.680000 So one thing we could do is we could say alright, well let's monitor that 0:03:08.680000 --> 0:03:14.380000 and if this thing right here for this one port, fast ether zero slash 0:03:14.380000 --> 0:03:18.420000 one, if that gets above a certain threshold, if that memory gets to like 0:03:18.420000 --> 0:03:23.900000 80% full, let's just start preemptively dropping one out of every 10 packets 0:03:23.900000 --> 0:03:28.080000 before it even gets in there, just drop it as it arrives at the switch 0:03:28.080000 --> 0:03:33.440000 or router. Or let's maybe delay some of the traffic, you know normally 0:03:33.440000 --> 0:03:37.100000 once it gets into that ingress queue it'd be looked up in microseconds 0:03:37.100000 --> 0:03:39.840000 and then forwarded to the egress queue. 0:03:39.840000 --> 0:03:42.020000 Well let's not do that. 0:03:42.020000 --> 0:03:45.900000 Let's take some of those packets and just hold them back for a few milliseconds, 0:03:45.900000 --> 0:03:49.960000 have some artificial delay induced in there to hopefully prevent this 0:03:49.960000 --> 0:03:53.080000 guy from getting overwhelmed and congested. 0:03:53.080000 --> 0:03:56.180000 So that's performing it at the ingress queue level. 0:03:56.180000 --> 0:04:01.240000 Another place, we could actually do it at the forwarding engine. 0:04:01.240000 --> 0:04:05.780000 We could say okay, as the forwarding engine is receiving all these packets 0:04:05.780000 --> 0:04:10.180000 for look up, let's have the forwarding engine count them as they come 0:04:10.180000 --> 0:04:12.380000 in, see what kind of rate they're coming in. 0:04:12.380000 --> 0:04:17.020000 As long as they come in you know above a predefined threshold like at 0:04:17.020000 --> 0:04:21.380000 five megabits per second or lower, we'll forward them to the outbound 0:04:21.380000 --> 0:04:23.060000 interface and let them go. 0:04:23.060000 --> 0:04:27.240000 But if they come in above that threshold, anything that's above that line, 0:04:27.240000 --> 0:04:29.320000 we're going to kill them, we're going to drop them. 0:04:29.320000 --> 0:04:33.080000 Once again we're trying to preemptively prevent that egress queue from 0:04:33.080000 --> 0:04:33.980000 getting filled up. 0:04:33.980000 --> 0:04:39.620000 Now the forwarding engine is doing it using something called policing. 0:04:39.620000 --> 0:04:43.940000 Or technically we could try to do it at the egress queue itself. 0:04:43.940000 --> 0:04:52.240000 This is not a very good way of, well let me pause and take a step back 0:04:52.240000 --> 0:04:57.280000 on that. You can do it the egress queue with the egress queue. 0:04:57.280000 --> 0:05:03.320000 What you could say is if this is my switch right here and here's all my 0:05:03.320000 --> 0:05:07.260000 ingress ports, and this could also drive a router too, and this is my 0:05:07.260000 --> 0:05:12.360000 egress port where stuff is being transmitted, and this is my memory buffer. 0:05:12.360000 --> 0:05:22.980000 Now in the world of QoS, typically what you would find is that most of 0:05:22.980000 --> 0:05:27.620000 your traffic is your default traffic, your low important traffic. 0:05:27.620000 --> 0:05:32.600000 Like people just browsing the web, you know, every once in a while that 0:05:32.600000 --> 0:05:35.300000 stuff gets dropped, not a big deal. 0:05:35.300000 --> 0:05:38.760000 Your high priority traffic is like your voice, okay? 0:05:38.760000 --> 0:05:42.220000 But in the scheme of things, if we look at the sum total of all packets 0:05:42.220000 --> 0:05:46.400000 going through your network, your voice packets are a small percentage. 0:05:46.400000 --> 0:05:50.860000 Your voice packets are maybe like 5 % of all the packets going through 0:05:50.860000 --> 0:05:53.000000 your network if that. 0:05:53.000000 --> 0:05:56.700000 So keeping that in mind, we could say, well here's what we're going to 0:05:56.700000 --> 0:06:01.020000 do. If we just let everything go about as normal, we didn't touch it, 0:06:01.020000 --> 0:06:05.280000 this queue could get potentially filled up, and what would probably fill 0:06:05.280000 --> 0:06:07.840000 it? Would it be our voice packets are filling it up? 0:06:07.840000 --> 0:06:11.640000 Probably not. It'd be our low important stuff, like people who are doing 0:06:11.640000 --> 0:06:16.480000 YouTube or people who are, you know, uploading files to Dropbox or stuff, 0:06:16.480000 --> 0:06:20.160000 stuff that's not as critical as our voice traffic. 0:06:20.160000 --> 0:06:24.160000 So in order to prevent this thing from getting filled to the point when 0:06:24.160000 --> 0:06:28.400000 a voice packet does come in, uh oh, there's no place for it, drop. 0:06:28.400000 --> 0:06:31.700000 In order to prevent that, we could actually go to the egress queue and 0:06:31.700000 --> 0:06:36.620000 we could say, all right, let's set some thresholds there in the egress 0:06:36.620000 --> 0:06:41.300000 queue. Let's tell this egress queue here that, you know, if you get to 0:06:41.300000 --> 0:06:47.340000 40% full, why don't you start dropping maybe one out of every 10 frames 0:06:47.340000 --> 0:06:51.080000 it comes in? You know, even if you got all this space right here, start 0:06:51.080000 --> 0:06:53.880000 dropping one out of every 10 frames anyway. 0:06:53.880000 --> 0:06:59.020000 And if you get to like 75% full, let's start dropping like six out of 0:06:59.020000 --> 0:07:00.180000 every 10 frames. 0:07:00.180000 --> 0:07:04.160000 You see the objective, the purpose behind this is we're desperately trying 0:07:04.160000 --> 0:07:08.660000 to reserve some room so that when a voice packet does come or whatever 0:07:08.660000 --> 0:07:13.940000 it is that you define as being important to you, we have room for it. 0:07:13.940000 --> 0:07:18.820000 So we could do it on the egress queue as well to try to prevent the congestion 0:07:18.820000 --> 0:07:23.520000 from happening. So those are the three different places. 0:07:23.520000 --> 0:07:28.940000 Now let's just do some terminology here to wrap up this video, policing, 0:07:28.940000 --> 0:07:30.500000 shaping, and markdown. 0:07:30.500000 --> 0:07:34.300000 And my objective here in this particular video is not to go into all the 0:07:34.300000 --> 0:07:38.900000 gory details of how these features are configured, your various options 0:07:38.900000 --> 0:07:40.940000 and gotchas and caveats. 0:07:40.940000 --> 0:07:44.300000 That is for a much more advanced level series and we actually here at 0:07:44.300000 --> 0:07:49.160000 INE have a lot of videos that do go into that level of detail. 0:07:49.160000 --> 0:07:52.980000 So after this, after you've been introduced to these features, if you 0:07:52.980000 --> 0:07:57.740000 want that type of knowledge, please go back to our website, my.ini.com 0:07:57.740000 --> 0:08:00.960000 and you'll find some more advanced QS videos that go into that level of 0:08:00.960000 --> 0:08:05.080000 detail. So for here, I want to sort of help you define what is meant by 0:08:05.080000 --> 0:08:08.100000 these terms, policing, shaping, and markdown. 0:08:08.100000 --> 0:08:15.120000 Okay. So this type of thing is these features are typically implemented 0:08:15.120000 --> 0:08:20.260000 between your edge router at the edge of your network and the ISPs router 0:08:20.260000 --> 0:08:22.240000 at the other end of that connection. 0:08:22.240000 --> 0:08:25.060000 So between you and your service provider, it's providing you internet 0:08:25.060000 --> 0:08:30.820000 service. Now, when you set up that connection with your ISP, one of the 0:08:30.820000 --> 0:08:33.340000 things they're going to ask you and this is going to directly affect your 0:08:33.340000 --> 0:08:38.660000 monthly bill is how much speed or how much bandwidth you need. 0:08:38.660000 --> 0:08:43.080000 I mean, clearly they might have the capability of running a fiber optic 0:08:43.080000 --> 0:08:46.240000 cable to you. They'll give you a 100 gigabits per second. 0:08:46.240000 --> 0:08:49.720000 Of course, they're going to charge you like $5,000 a month for something 0:08:49.720000 --> 0:08:54.820000 like that. And if your company doesn't need even a fraction of that, why 0:08:54.820000 --> 0:08:56.240000 would you pay for that? 0:08:56.240000 --> 0:09:00.660000 So they're going to ask you something like what kind of contracted rate, 0:09:00.660000 --> 0:09:04.560000 what kind of committed information rate do you need from us? 0:09:04.560000 --> 0:09:08.380000 Because we can run a cable to you that's capable of supporting out of 0:09:08.380000 --> 0:09:10.300000 this world speeds. 0:09:10.300000 --> 0:09:12.460000 What do you actually need? 0:09:12.460000 --> 0:09:15.980000 So you're going to negotiate that with them and negotiate a contracted 0:09:15.980000 --> 0:09:18.100000 rate called a CIR. 0:09:18.100000 --> 0:09:22.480000 Now, once that's agreed upon between the two of you, it's up to both of 0:09:22.480000 --> 0:09:24.320000 you to enforce that. 0:09:24.320000 --> 0:09:28.700000 You see, on their end, for the ISP, they're saying, okay, that customer 0:09:28.700000 --> 0:09:32.220000 better not send us any more than what we've agreed to. 0:09:32.220000 --> 0:09:35.960000 If we've agreed to a committed information rate of like maybe 100 megabits 0:09:35.960000 --> 0:09:40.880000 per second, and they start sending us 300 megabits per second, that's 0:09:40.880000 --> 0:09:41.860000 going to be a problem. 0:09:41.860000 --> 0:09:45.760000 Because we've got tens of thousands of other customers are also using 0:09:45.760000 --> 0:09:49.720000 our network. In order to figure out how many routers we need to have, 0:09:49.720000 --> 0:09:53.160000 what type of links we need to have, we need to have some predictability 0:09:53.160000 --> 0:09:55.020000 here as far as what's going through our network. 0:09:55.020000 --> 0:09:58.300000 And if all of our customers are agreeing to one thing, but actually doing 0:09:58.300000 --> 0:10:03.040000 something else, that's going to be hard to maintain satisfaction with 0:10:03.040000 --> 0:10:04.700000 all of our customers. 0:10:04.700000 --> 0:10:09.360000 So on the ISP side, they will do what's called policing. 0:10:09.360000 --> 0:10:14.760000 In other words, they will measure your traffic as it's coming in to them. 0:10:14.760000 --> 0:10:18.040000 And if you've agreed to a committed information rate of, let's say, 50 0:10:18.040000 --> 0:10:21.820000 megabits per second or whatever it is that you want, they will have a 0:10:21.820000 --> 0:10:24.780000 police or setup that's monitoring that rate. 0:10:24.780000 --> 0:10:29.660000 As long as you send them traffic that is up to but not including 50 meg, 0:10:29.660000 --> 0:10:33.140000 if you stay beneath that rate, you're good. 0:10:33.140000 --> 0:10:36.780000 They'll allow your traffic through, they won't change it in any way, and 0:10:36.780000 --> 0:10:38.740000 you're happy as a clam. 0:10:38.740000 --> 0:10:42.660000 Now, if you start sending them traffic that's above that, what does the 0:10:42.660000 --> 0:10:48.620000 police or do? Well, that is considered what's called non-conforming traffic. 0:10:48.620000 --> 0:10:51.060000 And policeors can do one of two things. 0:10:51.060000 --> 0:10:54.120000 Usually what they do is they drop the traffic. 0:10:54.120000 --> 0:10:58.280000 They say, hey, look, we're billing you $100 a month based on the agreement 0:10:58.280000 --> 0:11:02.360000 that we would do 50 megabits per second, and you're going above that. 0:11:02.360000 --> 0:11:05.420000 So chances are very likely that their police will say, hey, any traffic 0:11:05.420000 --> 0:11:10.200000 you send us inbound that's more than 50 meg, kill it, it's done, dead 0:11:10.200000 --> 0:11:15.580000 on arrival. Now, an alternative action they could do is mark down the 0:11:15.580000 --> 0:11:21.060000 traffic. So for example, if the traffic you're sending them has some DSCP, 0:11:21.060000 --> 0:11:26.320000 some, I should say some non-default DSCP or IP precedence value, because 0:11:26.320000 --> 0:11:30.760000 normally the defaults are zero, and you can't mark it down into a negative 0:11:30.760000 --> 0:11:32.740000 number. That's the lowest you can get. 0:11:32.740000 --> 0:11:37.660000 But if you were sending into the ISP traffic with higher than zero, their 0:11:37.660000 --> 0:11:43.180000 police or could take that traffic above the rate, let it go through, but 0:11:43.180000 --> 0:11:45.180000 just mark it down to zero again. 0:11:45.180000 --> 0:11:47.940000 Basically negating the priority of your traffic. 0:11:47.940000 --> 0:11:49.700000 Chances are they're probably not going to do that. 0:11:49.700000 --> 0:11:53.960000 They're just going to kill it, but a police can do either or of those 0:11:53.960000 --> 0:11:57.160000 things. Now, what about from you? 0:11:57.160000 --> 0:12:00.180000 You're the customer on your end, like this says here. 0:12:00.180000 --> 0:12:02.380000 You don't want your traffic dropped. 0:12:02.380000 --> 0:12:06.820000 So let's say that I'm the customer router and I'm facing you, you are 0:12:06.820000 --> 0:12:08.680000 the ISP, I'm the customer. 0:12:08.680000 --> 0:12:12.220000 Now on the back of my head here, I'm getting traffic hitting me at like 0:12:12.220000 --> 0:12:14.400000 55 megabits per second. 0:12:14.400000 --> 0:12:16.080000 Trying to go to the internet. 0:12:16.080000 --> 0:12:18.520000 And I think, uh-oh, okay, let's see here. 0:12:18.520000 --> 0:12:22.000000 We've got a defined, we've got a committed information rate of 50 megs. 0:12:22.000000 --> 0:12:25.680000 That's all I can send to you, but what I'm getting inbound is more than 0:12:25.680000 --> 0:12:28.100000 that. 55 megabits per second. 0:12:28.100000 --> 0:12:32.800000 Well, certainly I could police as well, but from my perspective, all of 0:12:32.800000 --> 0:12:34.340000 my traffic is important. 0:12:34.340000 --> 0:12:35.580000 I think it is anyway. 0:12:35.580000 --> 0:12:36.500000 I think everything's important. 0:12:36.500000 --> 0:12:37.920000 I don't want to drop anything. 0:12:37.920000 --> 0:12:42.000000 So on my side, I could implement another quality of service feature called 0:12:42.000000 --> 0:12:44.060000 traffic shaping. 0:12:44.060000 --> 0:12:47.780000 What traffic shaping says, it says, okay, here's what I'm going to do. 0:12:47.780000 --> 0:12:52.900000 Hopefully, this traffic that's coming in at 55 megabits per second is 0:12:52.900000 --> 0:12:56.000000 just temporary. In other words, there's just a little glitch in time where 0:12:56.000000 --> 0:12:59.200000 it's like, boop, really far, really high, and it's not like consistently 0:12:59.200000 --> 0:13:01.320000 coming in that fast. 0:13:01.320000 --> 0:13:05.720000 So just for a few moments, a few seconds, traffic is hitting me on the 0:13:05.720000 --> 0:13:08.160000 back of the head at 55 megabits per second. 0:13:08.160000 --> 0:13:09.300000 Here's what I can do. 0:13:09.300000 --> 0:13:15.240000 I will play it out to you, the ISP, at our negotiated rate of 50 megabits 0:13:15.240000 --> 0:13:18.840000 per second. What am I going to do with the excess traffic? 0:13:18.840000 --> 0:13:21.600000 I'll buffer it. I'll hold on to it, memory. 0:13:21.600000 --> 0:13:26.440000 I'll delay it. And then I'll play it out when I can, as long as I don't 0:13:26.440000 --> 0:13:28.440000 go above 50 megabits per second. 0:13:28.440000 --> 0:13:32.440000 So that's what's called traffic shaping, is where it might be coming in 0:13:32.440000 --> 0:13:36.460000 at this rate, fast, slow, fast, slow, but it's going out at a consistent 0:13:36.460000 --> 0:13:39.660000 rate, and that's what the traffic shaper does. 0:13:39.660000 --> 0:13:42.920000 It says, okay, any excess traffic, I'll just hold it back, and then I'll 0:13:42.920000 --> 0:13:47.120000 play it out again when I can. 0:13:47.120000 --> 0:13:52.280000 So shaping is typically done on the egress interface leading to the ISP. 0:13:52.280000 --> 0:13:55.620000 So hopefully, now, you have a good idea as to what the differences are 0:13:55.620000 --> 0:13:57.960000 between policing and shaping. 0:13:57.960000 --> 0:13:59.960000 Both of them set a threshold. 0:13:59.960000 --> 0:14:02.880000 Both of them set some level, and they start monitoring traffic either 0:14:02.880000 --> 0:14:05.160000 inbound or outbound. 0:14:05.160000 --> 0:14:08.240000 But what the difference is, is what they do to the traffic that goes above 0:14:08.240000 --> 0:14:11.960000 that threshold. Policing typically says, you're dead. 0:14:11.960000 --> 0:14:13.540000 Any traffic above that level? 0:14:13.540000 --> 0:14:15.340000 Kill it. Don't deal with it. 0:14:15.340000 --> 0:14:18.700000 Traffic shaping says, okay, any traffic above that level, I'm just going 0:14:18.700000 --> 0:14:23.500000 to set it aside, and then I'll play it out again later when I can. 0:14:23.500000 --> 0:14:28.940000 Now, this here is an example of a policing command, one of several you 0:14:28.940000 --> 0:14:31.160000 could do in a Cisco router. 0:14:31.160000 --> 0:14:34.460000 And my purpose here is not to go over how to configure this, but I just 0:14:34.460000 --> 0:14:38.320000 want to draw your attention to a little bit about how this works. 0:14:38.320000 --> 0:14:45.880000 Like, for example, we are matching some traffic, and the class of the 0:14:45.880000 --> 0:14:49.720000 traffic, we've just given it a name of press three. 0:14:49.720000 --> 0:14:54.680000 Probably traffic with an IP precedence of three would be my guess, but 0:14:54.680000 --> 0:14:58.600000 that's just a descriptive name, press three, that could be anything. 0:14:58.600000 --> 0:15:02.120000 But the point is, we're matching a class of traffic. 0:15:02.120000 --> 0:15:06.660000 Now what we're going to do is we're going to monitor that traffic with 0:15:06.660000 --> 0:15:11.640000 a policeor. So the policeor, we say, okay, what is the committed information 0:15:11.640000 --> 0:15:22.760000 rate? Let's say it was 50,000, 50,000 bits per second, okay, with a peak 0:15:22.760000 --> 0:15:26.900000 information rate of 75,000. 0:15:26.900000 --> 0:15:29.040000 All right, so what does this mean? 0:15:29.040000 --> 0:15:33.000000 That means, okay, so let's do it like this. 0:15:33.000000 --> 0:15:40.000000 So my peak is 75,000 bits per second, and I got another level just below 0:15:40.000000 --> 0:15:42.220000 that, which is 50,000. 0:15:42.220000 --> 0:15:47.200000 Bits per second, okay, so this is what my policeor is monitoring. 0:15:47.200000 --> 0:15:50.160000 Now here's what the police is going to do. 0:15:50.160000 --> 0:15:52.180000 Conform action, what does that mean? 0:15:52.180000 --> 0:15:57.580000 That means for all this traffic, all the traffic that is below 50,000 0:15:57.580000 --> 0:16:00.360000 bits per second, and that's just an example number. 0:16:00.360000 --> 0:16:01.900000 So what am I going to do with that traffic? 0:16:01.900000 --> 0:16:04.040000 Well, typically you would just transmit it. 0:16:04.040000 --> 0:16:07.840000 Just let it go through, don't touch it, don't mess around with it. 0:16:07.840000 --> 0:16:14.280000 Okay, what about the traffic that falls in this area right here? 0:16:14.280000 --> 0:16:20.840000 So it is exceeding my committed information rate, but it hasn't reached 0:16:20.840000 --> 0:16:24.880000 yet my peak information rate. 0:16:24.880000 --> 0:16:27.040000 Well, that is my exceed action. 0:16:27.040000 --> 0:16:34.020000 In this case, I'm saying, okay, let's set the precedence to zero and transmit 0:16:34.020000 --> 0:16:39.580000 it. So between these two lines, we'll still let it go out, but if that 0:16:39.580000 --> 0:16:44.480000 traffic came in with some non-zero precedence level or non-zero DSCP level, 0:16:44.480000 --> 0:16:47.740000 we're just going to set it back to the default of zero, and then we're 0:16:47.740000 --> 0:16:49.180000 going to send it out. 0:16:49.180000 --> 0:16:55.220000 Now, what about traffic that is above this line right here? 0:16:55.220000 --> 0:16:57.900000 Well, that is above my peak information rate. 0:16:57.900000 --> 0:17:02.180000 Now that's my violate action, I am dropping it. 0:17:02.180000 --> 0:17:06.720000 So you can see this particular police is doing two actions in one. 0:17:06.720000 --> 0:17:11.060000 For some traffic, it's completely killing it, it's dropping it. 0:17:11.060000 --> 0:17:16.260000 For other traffic, it's allowing it through, but just marking it down. 0:17:16.260000 --> 0:17:20.140000 So that's just an example configuration of how a policeer could work. 0:17:20.140000 --> 0:17:27.860000 As far as traffic shaping is concerned, okay, so just a little comparison 0:17:27.860000 --> 0:17:34.420000 here. Like it says here, policeers can be applied on ingress or egress. 0:17:34.420000 --> 0:17:38.460000 In other words, for traffic being received or traffic we're about to transmit 0:17:38.460000 --> 0:17:43.580000 out, usually it's done on the ingress. 0:17:43.580000 --> 0:17:50.000000 And like I said, typically ISPs will use policeers and you, the customer, 0:17:50.000000 --> 0:17:53.620000 will use a shaper on the egress side. 0:17:53.620000 --> 0:17:57.080000 Most Cisco switches do not support traffic shaping. 0:17:57.080000 --> 0:17:58.740000 This is a little caveat right there. 0:17:58.740000 --> 0:18:01.680000 And I want to conclude this video with just a sample configuration of 0:18:01.680000 --> 0:18:03.240000 traffic shaping. 0:18:03.240000 --> 0:18:06.800000 Like we did traffic policing, here is traffic shaping. 0:18:06.800000 --> 0:18:12.280000 So without going too much into the details here, once again we're matching 0:18:12.280000 --> 0:18:13.780000 on some class of traffic. 0:18:13.780000 --> 0:18:16.700000 This time it's got a different name, press zero. 0:18:16.700000 --> 0:18:20.000000 And this time we're applying traffic shaping to it. 0:18:20.000000 --> 0:18:25.700000 And we can say shape average in bits per second. 0:18:25.700000 --> 0:18:34.580000 So in my previous example, if the ISP and myself had negotiated a committed 0:18:34.580000 --> 0:18:38.960000 information rate of 50 megabits per second, I could say shape average 0:18:38.960000 --> 0:18:43.460000 50,000, that'd be in bits per second. 0:18:43.460000 --> 0:18:46.540000 Or you see here, I can also add these things if I wanted to. 0:18:46.540000 --> 0:18:52.040000 So instead I could say shape average 50m. 0:18:52.040000 --> 0:18:57.780000 And because this is using the shape command, anything that hits this egress 0:18:57.780000 --> 0:19:01.740000 interface that's faster than that will be buffered. 0:19:01.740000 --> 0:19:06.400000 And this interface will only send out traffic at up to 50 megabits per 0:19:06.400000 --> 0:19:13.260000 second. So that concludes this video on the differences between traffic 0:19:13.260000 --> 0:19:15.720000 shaping, policing and markdown. 0:19:15.720000 --> 0:19:17.020000 Thank you for watching.