WEBVTT 0:00:03.420000 --> 0:00:08.760000 Welcome to this video, which continues with our review of QUS concepts. 0:00:08.760000 --> 0:00:11.980000 Here I'm going to review and do a refresher of congestion avoidance with 0:00:11.980000 --> 0:00:14.600000 policing and shaping. 0:00:14.600000 --> 0:00:19.240000 So here are the topics we are going to cover. 0:00:19.240000 --> 0:00:23.000000 So first of all, what is this term of congestion avoidance? 0:00:23.000000 --> 0:00:27.140000 So like it says, it's just a term used to define a set of features that 0:00:27.140000 --> 0:00:29.900000 tend to prevent cues from becoming congested. 0:00:29.900000 --> 0:00:31.520000 Let's do a refresher here. 0:00:31.520000 --> 0:00:37.920000 We know that every interface on a router or switch, that before, so there's 0:00:37.920000 --> 0:00:42.420000 basically two types of memory they're associated to an interface. 0:00:42.420000 --> 0:00:46.540000 The first type of memory is something called a transmit ring. 0:00:46.540000 --> 0:00:48.020000 Don't have to know the details of that. 0:00:48.020000 --> 0:00:51.220000 Just know it's a very small piece of memory that's directly attached to 0:00:51.220000 --> 0:00:52.600000 the interface itself. 0:00:52.600000 --> 0:00:56.680000 So if there's no congestion at all, if the moment the CPU or the forwarding 0:00:56.680000 --> 0:01:00.460000 engine says, okay, I'm going to forward this packet of this frame to this 0:01:00.460000 --> 0:01:04.040000 interface. If there's no congestion, that packet of frame just gets onto 0:01:04.040000 --> 0:01:07.840000 the transmit ring, which is a piece of memory directly connected here, 0:01:07.840000 --> 0:01:12.000000 stays in that transmit ring for like a picosecond or microsecond and there 0:01:12.000000 --> 0:01:13.640000 it goes. It's out. 0:01:13.640000 --> 0:01:18.660000 Now if that transmit ring gets filled up, because it's not very big, there's 0:01:18.660000 --> 0:01:23.880000 not a lot of stuff there, if that transmit ring is big enough to let that 0:01:23.880000 --> 0:01:25.580000 interface go at line rate. 0:01:25.580000 --> 0:01:29.380000 So if this interface was like a fast Ethernet interface, which is supposed 0:01:29.380000 --> 0:01:33.960000 to be capable of 100 million bits per second, that transmit ring that 0:01:33.960000 --> 0:01:40.960000 memory is capable of storing frames and sending them out up to about 100 0:01:40.960000 --> 0:01:44.780000 million bits per second, which is fast Ethernet speed. 0:01:44.780000 --> 0:01:50.080000 But let's say that on the receiving side, I've got 20 or 30 inbound interfaces, 0:01:50.080000 --> 0:02:00.600000 which and all this data is supposed to go out this one fast Ethernet interface. 0:02:00.600000 --> 0:02:05.140000 Well, it's coming in much faster than 100 megabits per second when we 0:02:05.140000 --> 0:02:09.840000 add it all up. And so that transmit ring will get completely full. 0:02:09.840000 --> 0:02:11.420000 If you get it's still coming in. 0:02:11.420000 --> 0:02:14.460000 So now we have another set of memory attached to that interface, which 0:02:14.460000 --> 0:02:16.920000 is called a Q, a memory Q. 0:02:16.920000 --> 0:02:20.740000 That's much bigger and that's where we can put all the extra stuff. 0:02:20.740000 --> 0:02:23.660000 Now that's cause going to cause a little bit of delay because we, you 0:02:23.660000 --> 0:02:27.240000 know, as the transmit ring frees up something to transmit, it'll grab 0:02:27.240000 --> 0:02:31.160000 the next frame from the queue, put in a transmit ring and there it goes. 0:02:31.160000 --> 0:02:38.280000 Now, if the stuff coming in stops, dies down, then our, and if our queue 0:02:38.280000 --> 0:02:42.700000 doesn't get 100% full, well, there will be a little bit of delay there. 0:02:42.700000 --> 0:02:46.220000 But at least we know that everything in that queue will eventually get 0:02:46.220000 --> 0:02:49.800000 out. The transmit ring will pull transmit, pull transmit, and eventually 0:02:49.800000 --> 0:02:52.280000 the transmit ring will say, okay, the queue is empty. 0:02:52.280000 --> 0:02:54.500000 There's nothing left in there anymore. 0:02:54.500000 --> 0:03:00.360000 But the problem is congestion, this term congestion really involves where 0:03:00.360000 --> 0:03:05.600000 stuff keeps coming in at a massive rate to where that queue, that second 0:03:05.600000 --> 0:03:08.860000 piece of memory gets completely full. 0:03:08.860000 --> 0:03:14.200000 At that point, it's game over because now as a frame or a pack, it comes 0:03:14.200000 --> 0:03:17.360000 in and the CPU with the forwarding engine says, oh, I need to send it 0:03:17.360000 --> 0:03:18.260000 to that interface. 0:03:18.260000 --> 0:03:20.980000 The interface will say, sorry, I've got no place to put it. 0:03:20.980000 --> 0:03:25.260000 My transmit ring is frantically trying to put stuff out and the queue, 0:03:25.260000 --> 0:03:28.120000 our secondary holding area is full. 0:03:28.120000 --> 0:03:29.040000 No place to put it. 0:03:29.040000 --> 0:03:30.980000 So now we have to drop it. 0:03:30.980000 --> 0:03:33.980000 We have to drop that inbound packet of frames so we got no place to store 0:03:33.980000 --> 0:03:36.640000 it. That's what we want to avoid. 0:03:36.640000 --> 0:03:38.540000 So congestion avoidance says this. 0:03:38.540000 --> 0:03:44.400000 It says, okay, if that scenario happens, now I have to think about what 0:03:44.400000 --> 0:03:48.200000 types of traffic, what classes of traffic are coming in. 0:03:48.200000 --> 0:03:49.560000 It's probably a whole bunch of stuff. 0:03:49.560000 --> 0:03:52.580000 Some of the traffic coming in might be voiceover IP. 0:03:52.580000 --> 0:03:56.460000 Some of the stuff coming in might be telnet or web browsing. 0:03:56.460000 --> 0:04:03.440000 All right. Well, before that queue gets 100% full, is there something 0:04:03.440000 --> 0:04:08.560000 I could maybe do preemptively to prevent that from happening? 0:04:08.560000 --> 0:04:13.920000 Is there something I could do to prevent the queue from getting 100% full 0:04:13.920000 --> 0:04:18.240000 by maybe preemptively dropping packets either before they get into the 0:04:18.240000 --> 0:04:22.920000 queue at all or after they get into the queue, dropping them there so 0:04:22.920000 --> 0:04:27.080000 that there's always a little bit of room set aside for my really mission 0:04:27.080000 --> 0:04:28.640000 critical traffic. 0:04:28.640000 --> 0:04:33.160000 That's what congestion avoidance is all about, trying to avoid that queue 0:04:33.160000 --> 0:04:34.760000 from getting congested. 0:04:34.760000 --> 0:04:39.360000 Now this can be done in three places depending on what hardware platform 0:04:39.360000 --> 0:04:40.600000 we're talking about. 0:04:40.600000 --> 0:04:42.360000 We could do it on the ingress queue. 0:04:42.360000 --> 0:04:46.680000 We could say, hey, as stuff is coming in, let's drop it on the in because 0:04:46.680000 --> 0:04:51.600000 not only do interfaces have transmit queues, they also have ingress queues. 0:04:51.600000 --> 0:04:56.020000 As something comes in, ideally the moment something comes in, we could 0:04:56.020000 --> 0:04:59.280000 immediately send it to the forwarding engine or the CPU to look up that 0:04:59.280000 --> 0:05:01.560000 frame. But that's not always the case. 0:05:01.560000 --> 0:05:05.280000 Because if we have tons of interfaces, all receiving stuff at the same 0:05:05.280000 --> 0:05:08.860000 time, that forwarding engine, that piece of hardware that looks things 0:05:08.860000 --> 0:05:13.120000 up can only handle one frame or one at a time. 0:05:13.120000 --> 0:05:16.940000 Now it does that very, very fast and like millions or hundreds of millions 0:05:16.940000 --> 0:05:21.480000 of packets per second, but still packets could be coming in even faster 0:05:21.480000 --> 0:05:25.920000 than the forwarding engine can get them, in which case we have an ingress 0:05:25.920000 --> 0:05:27.620000 or a receive queue. 0:05:27.620000 --> 0:05:30.020000 So I could drop my stuff right there. 0:05:30.020000 --> 0:05:33.620000 I could say, hey, let's just start dropping stuff preemptively on the 0:05:33.620000 --> 0:05:37.660000 receive queue so the transmit queue never gets congested. 0:05:37.660000 --> 0:05:40.280000 I could do that. 0:05:40.280000 --> 0:05:42.440000 Most platforms don't allow you to do that. 0:05:42.440000 --> 0:05:45.500000 Most platforms do the last two methods. 0:05:45.500000 --> 0:05:48.180000 You can either do it at the forwarding engine itself. 0:05:48.180000 --> 0:05:52.000000 So you can tell the forwarding engine, hey, keep a record of every packet 0:05:52.000000 --> 0:05:54.700000 or frame that comes in that needs to be looked up. 0:05:54.700000 --> 0:06:00.420000 And if the packets are of this type, like if they are TFTP traffic, which 0:06:00.420000 --> 0:06:05.140000 is UDP based, or let's do something like multicast video, multicast video 0:06:05.140000 --> 0:06:09.020000 is UDP based and it comes in very, very fast and hard and it uses up a 0:06:09.020000 --> 0:06:10.200000 lot of bandwidth. 0:06:10.200000 --> 0:06:13.820000 So we could tell the forwarding engine, hey, when you see that, keep a 0:06:13.820000 --> 0:06:15.640000 record, keep a tally of it. 0:06:15.640000 --> 0:06:20.520000 Now, if that multicast video comes in and it exceeds a certain threshold, 0:06:20.520000 --> 0:06:22.440000 let's just delete it at the forwarding engine. 0:06:22.440000 --> 0:06:25.780000 Let's not even send it to the outbound queue, which is starting to have 0:06:25.780000 --> 0:06:28.960000 problems. Let's just delete it right up here on the part of the switch 0:06:28.960000 --> 0:06:32.360000 or router that's looking it up and delete it right there. 0:06:32.360000 --> 0:06:34.860000 That's called policing. 0:06:34.860000 --> 0:06:37.440000 Or we could do it on an egress queue itself. 0:06:37.440000 --> 0:06:40.340000 We could do something called queuing and shaping. 0:06:40.340000 --> 0:06:45.920000 Now, queuing and shaping, unfortunately, doesn't really involve congestion 0:06:45.920000 --> 0:06:50.460000 avoidance. By the time it gets to the queue, it's a little bit too late 0:06:50.460000 --> 0:06:51.880000 if you're going to do queuing and shaping. 0:06:51.880000 --> 0:06:53.360000 But let's just talk about these. 0:06:53.360000 --> 0:06:57.340000 So the rest of this presentation here is really just giving you an idea 0:06:57.340000 --> 0:07:03.880000 of when you are in between them. 0:07:03.880000 --> 0:07:05.960000 What are they actually doing? 0:07:05.960000 --> 0:07:14.900000 Okay. So typically, let's say I contract with an ISP. 0:07:14.900000 --> 0:07:18.940000 Let's say I'm the customer, you are the ISP, my router is going to connect 0:07:18.940000 --> 0:07:21.360000 over a WAN to your router. 0:07:21.360000 --> 0:07:29.100000 So and let's say that I've got a 100 meg link to you, whatever that is 0:07:29.100000 --> 0:07:33.660000 physically, but I can transmit up to 100 megabits per second to you. 0:07:33.660000 --> 0:07:36.160000 So let's say that's my absolute fastest rate. 0:07:36.160000 --> 0:07:42.180000 Now, as part of my contract negotiations with you, the ISP, one of the 0:07:42.180000 --> 0:07:45.100000 things you're going to ask me right up front is you're going to ask me, 0:07:45.100000 --> 0:07:47.280000 okay, what physical line rate do you want? 0:07:47.280000 --> 0:07:49.640000 What kind of line do you want to run to your business? 0:07:49.640000 --> 0:07:53.400000 We can run you a 40 meg link for this price. 0:07:53.400000 --> 0:07:55.640000 We can run you a 100 meg link for this price. 0:07:55.640000 --> 0:07:58.320000 We can run you a gig link for like this price. 0:07:58.320000 --> 0:08:00.060000 So I get to choose that. 0:08:00.060000 --> 0:08:01.940000 So let's say I selected a 100 meg link. 0:08:01.940000 --> 0:08:06.120000 That's the maximum line rate I want run to my business. 0:08:06.120000 --> 0:08:09.760000 Okay. Now here's the next thing you, the ISP, you're going to ask me. 0:08:09.760000 --> 0:08:16.300000 You're going to say, okay, another component of your monthly bill is how 0:08:16.300000 --> 0:08:19.880000 much do you want of that 100 megabits per second, which is the maximum 0:08:19.880000 --> 0:08:23.780000 you could send us, do you want us to guarantee you, so you're the ISP 0:08:23.780000 --> 0:08:29.340000 now. Okay, our network is shared with hundreds of thousands of other customers 0:08:29.340000 --> 0:08:33.140000 and we have to, you know, we've got links that are shared with all sorts 0:08:33.140000 --> 0:08:38.080000 of people. So we need to know as you're sending us data, Keith, Keith 0:08:38.080000 --> 0:08:42.760000 company, what's the maximum amount of data across this 100 meg link you 0:08:42.760000 --> 0:08:48.200000 want us to guarantee we will never drop even in peak times of congestion, 0:08:48.200000 --> 0:08:50.740000 we will never drop this much traffic. 0:08:50.740000 --> 0:08:53.640000 Now if I said, hey, 100 bags, right? 0:08:53.640000 --> 0:08:55.560000 I got a 100 meg link here. 0:08:55.560000 --> 0:08:58.660000 I want to guarantee that if I send you the full 100 meg at any point in 0:08:58.660000 --> 0:09:00.940000 time, you will never drop it. 0:09:00.940000 --> 0:09:04.560000 Well, that's going to make my bill really, really big, right? 0:09:04.560000 --> 0:09:07.980000 Because now they have to go in and make sure that in their infrastructure, 0:09:07.980000 --> 0:09:12.340000 they can assure me of always getting my 100 meg through regardless of 0:09:12.340000 --> 0:09:16.000000 how much congestion they may or may not be having at any given time. 0:09:16.000000 --> 0:09:20.400000 But if I tell them, oh, you know what, most of the time, I'm not really 0:09:20.400000 --> 0:09:23.080000 going to need the full 100 meg to you. 0:09:23.080000 --> 0:09:27.600000 So I really only need maybe 20 megs to be guaranteed. 0:09:27.600000 --> 0:09:31.660000 I do on a daily basis, I will on average be sending at least 20 megs upstream 0:09:31.660000 --> 0:09:33.680000 to you, service provider. 0:09:33.680000 --> 0:09:36.320000 So I need you to guarantee me that much. 0:09:36.320000 --> 0:09:38.260000 Well, that will reduce my bill, right? 0:09:38.260000 --> 0:09:42.380000 Because even though my physical line rate is capable of 100 megs, I'm 0:09:42.380000 --> 0:09:44.880000 telling you, I don't need that most of the time. 0:09:44.880000 --> 0:09:47.820000 I just need you to guarantee me 20 megs. 0:09:47.820000 --> 0:09:53.080000 So once we've identified that, that is what's called our contracted rate 0:09:53.080000 --> 0:09:55.000000 or our committed information rate. 0:09:55.000000 --> 0:09:58.720000 You are committing to me, and I will pay you this on a certain amount 0:09:58.720000 --> 0:10:02.420000 every single month, you are committing to me that if I send you up to 0:10:02.420000 --> 0:10:07.620000 a consistent 20 megabits per second, you will get that through your network. 0:10:07.620000 --> 0:10:10.580000 It will reach the destination and none of those packets will be dropped, 0:10:10.580000 --> 0:10:14.080000 no matter how bad your network might get. 0:10:14.080000 --> 0:10:16.860000 That's the committed information rate. 0:10:16.860000 --> 0:10:20.360000 Okay. So now we say, how do we enforce that? 0:10:20.360000 --> 0:10:26.120000 What's to stop me from sending you over the next day or two 50 megabits 0:10:26.120000 --> 0:10:28.240000 per second or 75 megabits per second? 0:10:28.240000 --> 0:10:30.860000 And what are you going to do about it if I do? 0:10:30.860000 --> 0:10:35.480000 Well, on your side, you will probably take my ingress traffic, the traffic 0:10:35.480000 --> 0:10:36.580000 that's coming to you. 0:10:36.580000 --> 0:10:39.780000 So that's considered ingress from your perspective, and you will police 0:10:39.780000 --> 0:10:44.660000 it. Police it simply means you are monitoring my traffic as long as my 0:10:44.660000 --> 0:10:48.740000 traffic is from zero to 20 megs, it goes through, no problem. 0:10:48.740000 --> 0:10:53.140000 If it's above 20 megs, now we have an issue. 0:10:53.140000 --> 0:10:56.520000 So traffic that is conforming, in other words, traffic that I send you 0:10:56.520000 --> 0:11:02.180000 that's from zero to 20 is usually just folded on. 0:11:02.180000 --> 0:11:04.120000 Traffic that is nonconforming. 0:11:04.120000 --> 0:11:06.560000 So if I send you stuff that's above 20 megs, guess what? 0:11:06.560000 --> 0:11:07.780000 I am breaking my contract. 0:11:07.780000 --> 0:11:08.960000 And what are you going to do about it? 0:11:08.960000 --> 0:11:10.460000 You're going to drop it. 0:11:10.460000 --> 0:11:12.920000 That's the typical behavior that a policeer will do. 0:11:12.920000 --> 0:11:14.620000 So you will set up a policeer on your side. 0:11:14.620000 --> 0:11:19.140000 So this is a QUS feature, a QUS command you'll do when your router is 0:11:19.140000 --> 0:11:22.800000 connected to me and your QUS policeer will be monitoring my traffic and 0:11:22.800000 --> 0:11:26.160000 it will be configured that anything that's received greater than 20 megabits 0:11:26.160000 --> 0:11:29.480000 per second, destroy it, kill that packet. 0:11:29.480000 --> 0:11:33.700000 Alternatively, you could mark it down. 0:11:33.700000 --> 0:11:38.620000 And that was, what does that mean? 0:11:38.620000 --> 0:11:42.340000 Maybe those packets have a variety of markings in the toss byte or in 0:11:42.340000 --> 0:11:44.120000 the traffic selector byte, right? 0:11:44.120000 --> 0:11:48.240000 I'm using different IP precedence values, different DSCP values. 0:11:48.240000 --> 0:11:51.920000 Well, if it's conforming, if it's from zero to 20, you'll just pass it 0:11:51.920000 --> 0:11:55.400000 on through. And whatever those markings are, you won't touch them. 0:11:55.400000 --> 0:11:57.260000 You'll just leave them alone. 0:11:57.260000 --> 0:12:01.320000 Another option that they could do, this would be part of my contract, 0:12:01.320000 --> 0:12:05.000000 is they could say, hey, here's what we're going to do. 0:12:05.000000 --> 0:12:11.460000 Anything from 20 megabits to 30 megabits per second, we'll let that through. 0:12:11.460000 --> 0:12:16.340000 But if that's marked with a non-zero number, like some IP precedence value 0:12:16.340000 --> 0:12:20.440000 that's not zero or a DSCP value that's not zero, we will mark it down 0:12:20.440000 --> 0:12:22.940000 to zero. So just be aware of that. 0:12:22.940000 --> 0:12:27.340000 If you go above 20 megs up to like maybe 30 megs, we'll probably let it 0:12:27.340000 --> 0:12:29.680000 through, but whatever markings you put on there are gone. 0:12:29.680000 --> 0:12:31.100000 We're going to reset it. 0:12:31.100000 --> 0:12:34.880000 And then they might say anything above 30 megs, we're just going to kill 0:12:34.880000 --> 0:12:36.880000 that entirely. We're just going to kill it. 0:12:36.880000 --> 0:12:40.000000 So those are the two actions that a policeer can do. 0:12:40.000000 --> 0:12:44.840000 A policeer could set a certain rate and say everything above that rate 0:12:44.840000 --> 0:12:50.440000 is just drop destroyed or like what's called a two rate per policeer. 0:12:50.440000 --> 0:12:54.100000 Typically says, okay, at rate number one, when you reach that, anything 0:12:54.100000 --> 0:12:57.880000 from rate number one to rate number two, we're going to drop the markings 0:12:57.880000 --> 0:12:59.920000 down. We're just going to reset to zero. 0:12:59.920000 --> 0:13:03.200000 Everything above rate number two, we're going to destroy it. 0:13:03.200000 --> 0:13:04.380000 We're going to kill it. 0:13:04.380000 --> 0:13:10.920000 Now, for me, the customer, everything I send to you from my perspective 0:13:10.920000 --> 0:13:13.980000 is important. I don't want anything dropped. 0:13:13.980000 --> 0:13:18.600000 So what if on my back end, so here comes into my LAN, my LAN interface, 0:13:18.600000 --> 0:13:23.840000 my ethernet interface, I'm getting stuff at like 150 megs, I contracted 0:13:23.840000 --> 0:13:25.500000 what I say, 20 megs with you. 0:13:25.500000 --> 0:13:29.800000 So here I'm receiving in, let's say 25 megs per second. 0:13:29.800000 --> 0:13:34.680000 I say, oh, this concerns me because if I send 25 megs per second to you, 0:13:34.680000 --> 0:13:36.700000 you might drop that excess five. 0:13:36.700000 --> 0:13:39.540000 Well, what I could do is I could say, all right, on my outbound interface, 0:13:39.540000 --> 0:13:43.800000 my egress interface, I'm going to configure something called a traffic 0:13:43.800000 --> 0:13:46.380000 shaper, traffic shaping. 0:13:46.380000 --> 0:13:49.980000 And what a shaper does is my shaper, just like your policeer monitors 0:13:49.980000 --> 0:13:53.360000 traffic and says, but it does a different action. 0:13:53.360000 --> 0:13:57.300000 So your policeer traffic that hits a threshold and above is destroyed 0:13:57.300000 --> 0:14:02.120000 is killed. My shaper might have that same threshold, 20 megs per second. 0:14:02.120000 --> 0:14:03.680000 But here's the difference. 0:14:03.680000 --> 0:14:07.640000 On the outbound interface, my shaper says, okay, any traffic I get that's 0:14:07.640000 --> 0:14:10.780000 more than 20 megs per second, hold it back. 0:14:10.780000 --> 0:14:11.940000 Don't transmit it. 0:14:11.940000 --> 0:14:16.220000 Just put it in the outbound queue, delayed a little bit, and then play 0:14:16.220000 --> 0:14:19.120000 it out later. But make sure that what I'm sending to you is consistently 0:14:19.120000 --> 0:14:21.360000 at 20 megs or more. 0:14:21.360000 --> 0:14:25.740000 If I've got more than that to send, just delay it and smooth everything 0:14:25.740000 --> 0:14:29.720000 out. So that's what traffic shaping does. 0:14:29.720000 --> 0:14:33.540000 So that's the main difference between policing and shaping. 0:14:33.540000 --> 0:14:36.340000 They both have a level that you set. 0:14:36.340000 --> 0:14:40.320000 The difference is the police or anything above that level, one of two 0:14:40.320000 --> 0:14:41.580000 things is going to happen. 0:14:41.580000 --> 0:14:45.160000 Either that stuff is going to be completely destroyed or it might be marked 0:14:45.160000 --> 0:14:49.660000 down. Whatever the DSCP or presence was marked down to zero. 0:14:49.660000 --> 0:14:53.160000 The traffic shaper, anything above that level, we're just not going to 0:14:53.160000 --> 0:14:56.800000 transmit. We're just going to hold it back and store it in a buffer in 0:14:56.800000 --> 0:14:59.680000 a queue for later on when we can transmit it. 0:14:59.680000 --> 0:15:04.340000 Now, you don't have to know any configuration commands for the CCNA when 0:15:04.340000 --> 0:15:05.540000 it comes to QOS. 0:15:05.540000 --> 0:15:08.040000 You just need to know these theoretical concepts. 0:15:08.040000 --> 0:15:10.820000 But just to give you a little bit more visibility into this, here's an 0:15:10.820000 --> 0:15:14.660000 example of a sample policeer. 0:15:14.660000 --> 0:15:21.680000 So in this particular output, we have said, okay, when traffic matches 0:15:21.680000 --> 0:15:25.720000 an IP precedence of three, what are we going to do to it? 0:15:25.720000 --> 0:15:28.520000 Well, we're going to police it at, now, like I said, 20 megs per second, 0:15:28.520000 --> 0:15:30.860000 right? So this is rate in bits per second. 0:15:30.860000 --> 0:15:33.500000 So that would be a pretty big number. 0:15:33.500000 --> 0:15:39.440000 That would be 20 million if I've done my math, right? 0:15:39.440000 --> 0:15:42.580000 So police, CIR, 20 million. 0:15:42.580000 --> 0:15:47.500000 And then we could say, all right, what's the, so that's the contracted 0:15:47.500000 --> 0:15:52.780000 rate. So if I have a two level police, I could say, all right, remember 0:15:52.780000 --> 0:15:55.580000 how I said that from 20 megs to 30 megs? 0:15:55.580000 --> 0:15:56.960000 We're going to allow it through. 0:15:56.960000 --> 0:15:58.980000 So this is being done on the ISP now. 0:15:58.980000 --> 0:16:00.360000 This is being done on the ISP's router. 0:16:00.360000 --> 0:16:05.660000 He says, okay, the peak information rate might be 30 megs per second. 0:16:05.660000 --> 0:16:08.520000 Of course, there wouldn't be commas in here, but you get the idea. 0:16:08.520000 --> 0:16:13.680000 All right, conform dash action probably transmit, right? 0:16:13.680000 --> 0:16:17.860000 So that's everything from zero up to 200 million. 0:16:17.860000 --> 0:16:23.420000 Exceed dash action is what's going to happen between 20 million and 30 0:16:23.420000 --> 0:16:26.740000 million. Exceed dash action, we're going to mark it down. 0:16:26.740000 --> 0:16:30.020000 We're going to set the precedence, we're going to transmit it and set 0:16:30.020000 --> 0:16:32.580000 the precedence to zero. 0:16:32.580000 --> 0:16:36.020000 Violate action is stuff that's above 30 million. 0:16:36.020000 --> 0:16:37.840000 We're going to drop that. 0:16:37.840000 --> 0:16:41.400000 So that's sort of how the police are works. 0:16:41.400000 --> 0:16:44.380000 And there's different ways of configuring police or there's different 0:16:44.380000 --> 0:16:48.120000 methods of doing it, but you get the sort of general idea right here. 0:16:48.120000 --> 0:16:52.820000 And then we would apply that to the interface on inbound traffic. 0:16:52.820000 --> 0:17:01.000000 So from the ISP side. 0:17:01.000000 --> 0:17:09.340000 So on routers, police are typically applied on the ingress side. 0:17:09.340000 --> 0:17:13.440000 And shapers are usually done on the egress to the ISP. 0:17:13.440000 --> 0:17:16.640000 If we're dealing with switches, most switches at least Cisco switches 0:17:16.640000 --> 0:17:18.720000 do not support traffic shaping. 0:17:18.720000 --> 0:17:21.300000 They do allow you to configure policing, but they don't allow you to do 0:17:21.300000 --> 0:17:22.200000 traffic shaping. 0:17:22.200000 --> 0:17:24.300000 So traffic shaping is what you want. 0:17:24.300000 --> 0:17:27.380000 You'll probably want to have a router do that. 0:17:27.380000 --> 0:17:31.000000 And here's an example of traffic shaping. 0:17:31.000000 --> 0:17:35.280000 So here we are saying, all right. 0:17:35.280000 --> 0:17:39.280000 Under my precedent zero traffic. 0:17:39.280000 --> 0:17:40.620000 I want to shape it. 0:17:40.620000 --> 0:17:45.680000 So for example, maybe I want to shape it to an average of 20 million bits 0:17:45.680000 --> 0:17:55.340000 per second. So that concludes this video, which is a review of traffic 0:17:55.340000 --> 0:17:57.300000 shaping and traffic policing.