WEBVTT 00:00:00.000 --> 00:00:07.000 Time for some quality of service, folks. QOS. So what exactly is quality of service? Well, it is a feature we have available to us. Why do we have this feature? Because not all packets are created equal. You know, you and I all know that we, us, downloading a movie on company time is far more important than any CEO on a voice over IP call. So it's imperative that we make sure that we have this feature available to us. So let's take a look at how we can make sure that we have this feature available to us. 00:00:30.000 --> 00:00:59.000 So it's imperative that we ensure that we prioritize the packets that are being used to download the movie. You paying attention? It's kind of backwards there, isn't it? No. We all know that the CEO on a voice over IP call is way more important than us downloading a movie on company time using company equipment. But the thing is, is our network devices don't know that, right? They don't know the difference between the CEO on a voice over IP call and someone downloading a movie. 00:00:59.000 --> 00:01:21.000 And so they treat, these network devices treat all of our traffic the exact same way. They use a best effort method. So whatever order you arrive on the device is the order you're processed in. So whatever order you arrive is the order you're processed in. That's best effort. And we got first in, first out type of scenario there. 00:01:21.000 --> 00:01:50.000 The thing is, is that all these packets are not equal. They're all different. And therefore, quality of service gives us the ability to differentiate between these different packet types and then prioritize certain packet types over others. When you think about our data traffic, typically that's TCP traffic. So it might be smooth or bursty or benign or greedy. It's drop insensitive when it's TCP based, that traffic. It's delay insensitive when it's TCP, meaning we can drop it. 00:01:50.000 --> 00:02:19.000 We can delay it. It's not a big deal because TCP can retransmit if we drop it and TCP can hang on for a bit. It's not in a hurry when communication is happening. So we can have a little bit of delay when it comes to that TCP traffic. But then something like voice traffic is the complete opposite. It is hyper delicate. It's hypersensitive. It's UDP based. Therefore, it can't be retransmitted. If it can't be retransmitted, it can't be dropped. 00:02:19.000 --> 00:02:35.000 It can't be delayed because if it's delayed, it destroys the voice conversation that's going on between two people or more people in a conference, that is. So the traffic, the network has to be smooth. And that way there we can support that voice traffic. 00:02:35.000 --> 00:02:52.000 But when you got voice traffic and data traffic competing for the exact same links, the same devices, well, things can go wrong, terribly wrong. And typically voice is going to suffer before your TCP traffic suffers unless you step in and make sure things are being done right. 00:02:52.000 --> 00:03:16.000 When it comes to video, it really depends on the type of video, folks. But typically video is bursty, greedy, drop sensitive, delay sensitive. It is UDP based. But we have to realize that video comes in really two different categories. We have a real time video, things like our video that's going to be part of our conferences, video that's part of our Zoom calls, our Skype calls, different things like that. 00:03:16.000 --> 00:03:37.000 But then you also have video that is being downloaded, is being buffered. For example, when you go to YouTube or you go to Netflix or you go to Disney Plus or Amazon Prime and you're watching those videos, those videos are essentially being downloaded to your device into a buffer and then you're watching that movie or watching that video. 00:03:38.000 --> 00:04:02.000 And as long as you are not watching it faster than it is being downloaded, then you are always staying within that buffer and not catching up to the end of the buffer, meaning that you are going to have a perfect experience. And so it doesn't really matter what the network traffic is like or the networks like in that case, as long as you are not faster than the video being downloaded. 00:04:03.000 --> 00:04:17.000 But when it comes to real time traffic, you don't have that buffer. Whatever is sent to you is being processed and shown to you right away. So there's no buffer. It's real time. So the difference here between real time and non real time video is really what we're talking about in this case. 00:04:17.000 --> 00:04:37.000 So the real time video is really going to need to be treated almost like voice. Where the non real time video is not going to be treated like voice because it doesn't have to be, but it's not going to be treated like data either because we still need to kind of prioritize that or we could end up with a poor viewing experience with that particular video. 00:04:38.000 --> 00:04:58.000 So voice and video are sensitive in nature, with voice being the most sensitive and real time video streaming conferencing applications being the second most sensitive. But when you think about it and compare it to TCP, TCP can be retransmitted, whereas voice and video definitely can't be retransmitted because if they were retransmitted, it would mess the whole conversation up. 00:04:59.000 --> 00:05:14.000 So when does quality of service actually kick in to help us out with all of this? Quality of service kicks in when there is congestion. That's right. So if all of a sudden stuff's coming in faster than it can be processed and sent out, that's when quality of service has to kick in. 00:05:15.000 --> 00:05:35.000 Because quality of service is going to define what gets to move to the front of the line, what gets to be expedited, what's going to have to be delayed, what's going to have to be dropped. So that way there the voice traffic is not negatively affected by this congestion. So typically what's going to happen is the TCP traffic is the one that's going to take the hit more than any other type of traffic in your environment. 00:05:36.000 --> 00:05:59.000 So if all of a sudden you're having excessive jitter, you're having excessive bandwidth related packet loss, maybe you are seeing that you have some interface saturation in your environment, then quality of service needs to be implemented in strategic areas. So that way there you can ensure that voice is not being negatively affected. The real time video is not being negatively affected. 00:06:00.000 --> 00:06:20.000 So it doesn't matter if it's traffic in your network or entering your network or leaving your network or crossing a WAN interface. If the network interface is congested, it's saturated. It makes sense to have quality of service policies applied because when we're dealing with voice traffic specifically, we want to meet certain requirements. 00:06:20.000 --> 00:06:38.000 We want to make sure that the delay from mouth to ear is less than 150 milliseconds one way. We want to make sure the jitter is less than 30 milliseconds. We want to make sure the packet loss is less than 1%. So in order to achieve that, we are going to have to ensure that we are prioritizing those voice packets over all other types of traffic. 00:06:39.000 --> 00:07:03.000 So what is bandwidth, by the way? In case you need to recall some of these terms and definitions on the exam, the amount of data that can be transmitted over the link is bandwidth. Delay is the amount of time it takes traffic to traverse the link. So the latency, there's another way to say delay and latency about the same thing. Amount of time it takes traffic to traverse the link. Jitter is the variation time it takes over a link due to queuing. And loss is the amount of traffic dropped in transit due to congestion. 00:07:04.000 --> 00:07:07.000 So you may or may not need to recall these on the certification exam. So know them. 00:07:07.000 --> 00:07:25.000 Now, when it comes to our devices, we have devices that are best effort first in, first out by default. That's what they are. So all of our end user devices, our phones, our PCs, everything that's going on are going to be fighting for the bandwidth. 00:07:26.000 --> 00:07:48.000 And all the traffic is treated the exact same way. It's treated equally. So we are queuing information up. And as information gets queued and backed up and slowed down, then that's when we are going to start having problems. So congestion is when those queues are backing up. Those buffers are backing up on our device. Why? Because we can't process the information as fast as it's arriving or as fast as it needs to be sent. 00:07:49.000 --> 00:08:09.000 So even once we process it, it might be sitting in an output queue. But if we can't send it on the link because the link is backed up, well, then what does that mean? It means that it's stuck in the queue. So we could be stuck in an input queue. You could be stuck in an output queue. And as a result of that, we are going to have various parts of our network that start to suffer. 00:08:10.000 --> 00:08:33.000 Voice typically is the first that's going to start suffering because that's where the human beings actually experience it right then and there. Whereas TCP, we don't really see TCP suffering. It just means that it might take seven minutes to download something instead of six and a half minutes. Well, those extra 30 seconds, we probably didn't even notice them go by because we were doing something else or talking to somebody at the exact same time. 00:08:34.000 --> 00:08:54.000 So the important thing here is to realize that QoS is kicking in. It's kicking in when the congestion happens. So if we didn't have congestion, is QoS kicking in? The answer to that is no. If we are able to process and forward as fast as traffic is arriving, then QoS does not have to kick in. 00:08:55.000 --> 00:09:19.000 Let me repeat that. If nothing is backing up in the queue, meaning that we are receiving and processing and sending at line rate as fast as we possibly can and nothing is stuck in the queue, then first in first out because you're in, you're out, you're in, you're out, you're in, you're out, you're in, nobody's waiting, nothing's waiting. Therefore, QoS doesn't have to do anything. 00:09:20.000 --> 00:09:25.000 So QoS is there to help us and save us when congestion occurs. 00:09:26.000 --> 00:09:36.000 So does that mean if I wasn't so cheap, I could simply forget about QoS? Pretty much. What do you mean? 00:09:37.000 --> 00:09:54.000 Well, if I had deep pockets, I had unlimited money, could I not buy the best Cisco gear that exists with the highest interfaces all the time, the most bandwidth on an interface-by-interface basis? Sure. 00:09:55.000 --> 00:09:59.000 And then I would probably more than likely be forwarding traffic faster than it ever arrives. 00:10:00.000 --> 00:10:02.000 One terabyte links for all. 00:10:06.000 --> 00:10:12.000 And for the longest time, there would be no issues with voice, video, data, nothing. 00:10:16.000 --> 00:10:21.000 But we don't have that much money. So QoS is the next best thing. 00:10:21.000 --> 00:10:31.000 So with that in mind, we need to know about things like classification, marking, congestion management, traffic policing, traffic shaping, weighted random early detection for the certification exam. 00:10:34.000 --> 00:10:36.000 A lot of this is a repeat of CCNA, folks. 00:10:40.000 --> 00:10:41.000 Get you ready for Encore. 00:10:44.000 --> 00:10:46.000 So let's begin here by talking about classification. 00:10:46.000 --> 00:10:49.000 If you're following along with the slides or anything, I'm going to be jumping around in the slides. 00:10:50.000 --> 00:10:51.000 So classification first. 00:10:52.000 --> 00:11:00.000 So classification is all about identifying within the chassis the different types of traffic. 00:11:01.000 --> 00:11:10.000 So we need to have a way to look at that packet, look at that frame, and ultimately determine what is it. 00:11:11.000 --> 00:11:16.000 Are you voice? Are you video? Are you data? Are you control plane? What are you? 00:11:17.000 --> 00:11:21.000 That's one of the primary fundamental aspects of QoS. 00:11:22.000 --> 00:11:25.000 If you can't classify what that traffic is, then you can't QoS it. 00:11:27.000 --> 00:11:30.000 So when we classify traffic, it could be based on the type of application. 00:11:31.000 --> 00:11:32.000 It could be based on the source or destination IP address. 00:11:33.000 --> 00:11:34.000 It could be based on simply the incoming interface. 00:11:35.000 --> 00:11:36.000 It could be based on what? 00:11:37.000 --> 00:11:39.000 Class of service values in Ethernet headers. 00:11:40.000 --> 00:11:42.000 Type of service values in packets. 00:11:43.000 --> 00:11:45.000 Type of service values in packets. 00:11:46.000 --> 00:11:48.000 Type of service values in packets. 00:11:48.000 --> 00:11:50.000 Type of service values in packet headers. 00:11:51.000 --> 00:11:53.000 The IP precedence or the DSCP values. 00:11:54.000 --> 00:11:58.000 It could be an MPLS, EXP value, and an MPLS header. 00:11:59.000 --> 00:12:01.000 So let's just go take a peek at our headers right now. 00:12:02.000 --> 00:12:03.000 So there is our packet header. 00:12:04.000 --> 00:12:06.000 Service type field. 00:12:07.000 --> 00:12:17.000 We could have a marking in there that classifies it as voice, video, data, control traffic, 00:12:18.000 --> 00:12:22.000 other traffic, best effort traffic, right? 00:12:23.000 --> 00:12:25.000 Type of service type field in our packet. 00:12:26.000 --> 00:12:27.000 But then down here, what do we have? 00:12:28.000 --> 00:12:31.000 We have our class of service field that would be in our 802.1Q tags. 00:12:32.000 --> 00:12:39.000 So frames don't have the ability to be classified unless they have an 802.1Q tag. 00:12:40.000 --> 00:12:44.000 So any frames without a tag are just going to be treated best effort. 00:12:44.000 --> 00:12:51.000 Whereas if they have a tag, then we could prioritize them, classify them, apply quality of service to them. 00:12:52.000 --> 00:12:53.000 That would be the class of service field. 00:12:54.000 --> 00:13:02.000 So now your TOS, DSCP, COS field, your TID for wireless, and the MPLS, EXP value for MPLS, 00:13:03.000 --> 00:13:11.000 those are all examples of ways that we can classify our traffic based on markings that exist in our headers already. 00:13:12.000 --> 00:13:17.000 But then we can also just simply base our classification on things like access control lists. 00:13:18.000 --> 00:13:23.000 So we could have an access control list applied on our device, 00:13:24.000 --> 00:13:28.000 and that access control list says if the traffic is coming from this source, going to this destination, 00:13:29.000 --> 00:13:33.000 or maybe just this source range, or any source range going to a particular destination, 00:13:34.000 --> 00:13:39.000 or maybe if it has these particular values or these port numbers, 00:13:39.000 --> 00:13:42.000 or this protocol in use, everything that we can specify in an ACL. 00:13:43.000 --> 00:13:48.000 If it has these particular parameters associated with it based on the ACL, 00:13:49.000 --> 00:13:55.000 then classify it as voice, or video, or data, or best effort, or whatever you want to classify it as. 00:13:56.000 --> 00:14:02.000 In addition, we have ways to look at the actual application data in the packets 00:14:03.000 --> 00:14:06.000 using something like NBAR, network-based application recognition. 00:14:06.000 --> 00:14:14.000 Look at layers 4, 5, 6, 7, and we can identify that by examining the payload of the actual application 00:14:15.000 --> 00:14:17.000 based on what a signature database that exists. 00:14:18.000 --> 00:14:20.000 So just different ways to classify our traffic. 00:14:21.000 --> 00:14:24.000 So where are we going to want to classify? 00:14:25.000 --> 00:14:27.000 Well, we're going to want to classify everywhere. Everywhere. 00:14:28.000 --> 00:14:32.000 Why? Because I want to make sure that this device can classify the traffic to apply quality of service. 00:14:32.000 --> 00:14:34.000 I want to make sure this device can classify the traffic to apply quality of service. 00:14:35.000 --> 00:14:37.000 I want to make sure this device can classify the traffic to apply quality of service. 00:14:38.000 --> 00:14:41.000 I want to make sure this device can classify the traffic to apply quality of service, and so on and so forth. 00:14:42.000 --> 00:14:47.000 So all of my networking devices have to have the ability to classify, to identify, 00:14:48.000 --> 00:14:50.000 hey, what type of traffic are you? 00:14:51.000 --> 00:14:54.000 All right, so now let's talk about marking. 00:14:55.000 --> 00:14:56.000 So what is marking? 00:14:57.000 --> 00:14:59.000 Well, I already gave you an example of marking. 00:14:59.000 --> 00:15:06.000 That would be information that is inside of our packet header or our frame header. 00:15:07.000 --> 00:15:18.000 And marking is the ability to modify or alter that value in the packet header or in the frame header, 00:15:19.000 --> 00:15:21.000 the 802.1Q frame header. 00:15:22.000 --> 00:15:28.000 So going back to this slide right here, marking is about changing the value that's in there. 00:15:29.000 --> 00:15:31.000 Marking is about changing the COS values that's there. 00:15:32.000 --> 00:15:33.000 Marking is about changing the TID value. 00:15:34.000 --> 00:15:36.000 Marking is about changing the MPLS EXP value. 00:15:37.000 --> 00:15:39.000 So by default, that would be empty. 00:15:40.000 --> 00:15:42.000 It would be blank. It would be best effort. 00:15:43.000 --> 00:15:45.000 And so marking would be, hey, I've identified this as voice. 00:15:46.000 --> 00:15:47.000 Let me put the voice value in there. 00:15:48.000 --> 00:15:50.000 With COS, for example, by default, it would be zero. 00:15:51.000 --> 00:15:52.000 But then it's like, hey, it's voice. 00:15:53.000 --> 00:15:55.000 Let's put a COS value of five in there to represent our voice traffic. 00:15:56.000 --> 00:16:01.000 So marking is a way for us to modify the actual header information. 00:16:02.000 --> 00:16:05.000 And then when it's marked, we can use that for classification purposes. 00:16:06.000 --> 00:16:08.000 So the deal is you can classify. 00:16:09.000 --> 00:16:10.000 Once you figure it out, you can mark. 00:16:11.000 --> 00:16:17.000 So if you are not classifying based on this information, you have the ability to classify and mark. 00:16:18.000 --> 00:16:20.000 But if you're classifying based on this information and this is the right information, 00:16:20.000 --> 00:16:24.000 then you don't have to mark because you're just classifying based on already existing markings. 00:16:25.000 --> 00:16:26.000 So what does that mean? 00:16:27.000 --> 00:16:30.000 It means that when it comes to classification and marking, there's a time and a place to do each of them. 00:16:31.000 --> 00:16:32.000 So like we said, we're going to classify everywhere. 00:16:33.000 --> 00:16:38.000 I want to classify, classify, classify, classify, classify, classify, classify, classify. 00:16:39.000 --> 00:16:43.000 Because as I am classifying everywhere in my environment, I have the ability to identify, 00:16:44.000 --> 00:16:46.000 are you this type of traffic or are you that type of traffic? 00:16:47.000 --> 00:16:48.000 But the thing is we don't want to mark everywhere. 00:16:48.000 --> 00:16:49.000 Because what is marking? 00:16:50.000 --> 00:16:51.000 Marking is altering, altering. 00:16:52.000 --> 00:16:56.000 So the deal is, is we want to mark as close to the entry point of that environment as possible. 00:16:57.000 --> 00:17:02.000 So for example, as the traffic's coming in, we can classify and mark, classify and mark. 00:17:03.000 --> 00:17:04.000 But over here, I just want to classify. 00:17:05.000 --> 00:17:09.000 I do not want to classify and mark there because there's no need to mark. 00:17:10.000 --> 00:17:14.000 I'm going to use the markings to classify, but I'm not going to mark again 00:17:15.000 --> 00:17:18.000 because there's already markings in the header information. 00:17:19.000 --> 00:17:22.000 On the way in, classify and mark. 00:17:23.000 --> 00:17:24.000 On the way in, classify and mark. 00:17:25.000 --> 00:17:27.000 But if the traffic's going this way, then I only want to classify. 00:17:28.000 --> 00:17:29.000 I don't need to mark it again, right? 00:17:30.000 --> 00:17:33.000 Just classify it as it's going through over to my devices down here. 00:17:34.000 --> 00:17:35.000 So classify and mark in here. 00:17:36.000 --> 00:17:39.000 I might have to mark coming in, but if the traffic's going this way, as an example, 00:17:39.000 --> 00:17:44.000 well, classify and mark here, and then just classify, classify, classify, classify on the way out. 00:17:45.000 --> 00:17:48.000 So we want to make sure that we are minimizing the amount of marking we're doing 00:17:49.000 --> 00:17:50.000 because marking is resource intensive. 00:17:51.000 --> 00:17:55.000 Anytime you have to modify the packet, CPU has to get involved. 00:17:56.000 --> 00:18:01.000 Now, in higher end devices, we can mark and do things like that 00:18:02.000 --> 00:18:06.000 based on our TCAM tables and so on and so forth, which is great. 00:18:06.000 --> 00:18:11.000 But still, we want to ensure that we are minimizing the amount of marking in our environment. 00:18:12.000 --> 00:18:17.000 So typically marking the entry and exit points, classifying everywhere 00:18:18.000 --> 00:18:21.000 is typically the way that we are going to perform these two different items. 00:18:22.000 --> 00:18:25.000 So classification and marking, know that stuff for the certification exam. 00:18:26.000 --> 00:18:30.000 Definitely make sure you know, folks, those different marking options. 00:18:31.000 --> 00:18:33.000 Like I said, TOS, COS, DSCP, those are all layer three. 00:18:33.000 --> 00:18:35.000 You got MPLS experimental for MPLS. 00:18:36.000 --> 00:18:37.000 You got TID for wireless. 00:18:38.000 --> 00:18:39.000 You got COS for layer two frames. 00:18:40.000 --> 00:18:42.000 Make sure you know that. 00:18:43.000 --> 00:18:47.000 Let's talk about traffic policing and traffic shaping right now. 00:18:48.000 --> 00:18:50.000 So traffic policing is all about what? 00:18:51.000 --> 00:18:53.000 Marking or dropping excessive traffic. 00:18:54.000 --> 00:18:56.000 Marking or dropping excessive traffic. 00:18:57.000 --> 00:19:01.000 So if we have traffic that is not behaving, 00:19:01.000 --> 00:19:03.000 it's exceeding what we wanted to. 00:19:04.000 --> 00:19:08.000 And as a result of it exceeding its rates, its bandwidth, its rates, 00:19:09.000 --> 00:19:12.000 it is now causing potential congestion on the network. 00:19:13.000 --> 00:19:14.000 Well, then we might want to police that traffic. 00:19:15.000 --> 00:19:19.000 We might want to drop that excess traffic that is causing problems. 00:19:20.000 --> 00:19:24.000 So we would then drop it, which would, 00:19:25.000 --> 00:19:28.000 if it's TCP-based traffic, cause TCP retransmissions. 00:19:28.000 --> 00:19:31.000 And as a result, it does not introduce any type of delay 00:19:32.000 --> 00:19:33.000 or does not introduce any type of jitter. 00:19:34.000 --> 00:19:36.000 Because what I always want to remember is that delay and jitter 00:19:37.000 --> 00:19:38.000 is based on that packet. 00:19:39.000 --> 00:19:40.000 If I drop it, is the packet gone? Yes. 00:19:41.000 --> 00:19:42.000 So there's no more delay. 00:19:43.000 --> 00:19:44.000 There's no more jitter because it's gone, right? 00:19:45.000 --> 00:19:46.000 Keep that in mind. 00:19:47.000 --> 00:19:48.000 So it doesn't introduce delay or jitter because the packet is gone. 00:19:49.000 --> 00:19:51.000 So when we're dropping those TCP packets, 00:19:52.000 --> 00:19:54.000 base packets, I should say, TCP-based packets, 00:19:55.000 --> 00:19:57.000 we got no delay or jitter introduced 00:19:58.000 --> 00:19:59.000 because the packet is gone. 00:20:00.000 --> 00:20:01.000 And typically, we're going to try to police 00:20:02.000 --> 00:20:03.000 as near the source as possible. 00:20:04.000 --> 00:20:05.000 So that way, our traffic's not going all the way near the end 00:20:06.000 --> 00:20:07.000 to just get dropped. 00:20:08.000 --> 00:20:10.000 We try to drop it as near the source as we possibly can. 00:20:11.000 --> 00:20:12.000 Now, how does that compare to something like traffic shaping? 00:20:13.000 --> 00:20:14.000 Well, traffic shaping is really about what? 00:20:15.000 --> 00:20:17.000 It's really about buffering and queuing packets 00:20:18.000 --> 00:20:19.000 and slowing packets down that have exceeded 00:20:20.000 --> 00:20:21.000 a certain committed information rate. 00:20:22.000 --> 00:20:27.000 So we can simply hold on to that packet longer. 00:20:29.000 --> 00:20:30.000 In our buffer. 00:20:31.000 --> 00:20:33.000 And then when is the most appropriate time to send it? 00:20:34.000 --> 00:20:35.000 Or when it is the most appropriate time to send it, 00:20:36.000 --> 00:20:37.000 we go ahead and we send it at that point in time. 00:20:38.000 --> 00:20:39.000 So this will introduce delay and jitter 00:20:40.000 --> 00:20:41.000 because the packet still exists, the packet's still alive, 00:20:42.000 --> 00:20:43.000 but we're hanging on to it. 00:20:44.000 --> 00:20:45.000 And when we hang on to it, that introduces delay. 00:20:46.000 --> 00:20:47.000 And based on the variation in delay, 00:20:48.000 --> 00:20:50.000 then that introduces jitter as well. 00:20:51.000 --> 00:20:53.000 So remember that shaping buffers and queues packets 00:20:54.000 --> 00:20:56.000 above a certain committed information rate for us, 00:20:56.000 --> 00:21:00.000 whereas policing drops packets above the committed rate 00:21:01.000 --> 00:21:03.000 and helps you control the max rate of traffic 00:21:04.000 --> 00:21:07.000 that is received or sent on any given interface. 00:21:08.000 --> 00:21:10.000 So here's an example of what it might look like for us. 00:21:11.000 --> 00:21:13.000 So in this case here, you can see as we're policing, 00:21:14.000 --> 00:21:16.000 the traffic rate will definitely change 00:21:17.000 --> 00:21:18.000 because as we drop, the traffic rate goes down, 00:21:19.000 --> 00:21:20.000 then it comes back up, we drop, it goes down, 00:21:21.000 --> 00:21:22.000 it comes back up, we drop, it goes down, 00:21:23.000 --> 00:21:24.000 it comes back up, whereas shaping, 00:21:24.000 --> 00:21:26.000 you see how shaping shapes it out for us? 00:21:27.000 --> 00:21:29.000 It ensures that we meet a certain level. 00:21:30.000 --> 00:21:31.000 So in this case, we said we're exceeding 00:21:32.000 --> 00:21:34.000 the committed information rate, so we drop everything that exceeds, 00:21:35.000 --> 00:21:39.000 whereas in this case, we slow down everything that exceeds instead. 00:21:40.000 --> 00:21:42.000 So that line would be our committed information rate line. 00:21:43.000 --> 00:21:44.000 We're dropping, dropping, dropping, dropping, 00:21:45.000 --> 00:21:46.000 so retransmit, retransmit, and so on and so forth, 00:21:47.000 --> 00:21:48.000 whereas over here, we're just hanging on to it longer, 00:21:49.000 --> 00:21:52.000 so we're shaping it so it conforms to that speed we want. 00:21:52.000 --> 00:21:54.000 So really important things for you to remember here, folks. 00:21:55.000 --> 00:21:57.000 Please, please, please make sure you are well aware 00:21:58.000 --> 00:22:01.000 of policing and shaping in this particular case. 00:22:07.000 --> 00:22:09.000 So back to here, let's talk about congestion management now. 00:22:10.000 --> 00:22:14.000 So congestion management is a way that we can now 00:22:15.000 --> 00:22:19.000 divvy up our device in a virtualized way 00:22:20.000 --> 00:22:22.000 by creating queues, so that way there, 00:22:23.000 --> 00:22:25.000 we can manage how traffic is handled 00:22:26.000 --> 00:22:28.000 when the congestion actually starts to occur. 00:22:29.000 --> 00:22:33.000 So think about our device. 00:22:34.000 --> 00:22:36.000 By default, it's first in, first out, 00:22:37.000 --> 00:22:38.000 so you have all these packets arriving, 00:22:39.000 --> 00:22:40.000 and this is our queue right here. 00:22:41.000 --> 00:22:42.000 We have all these packets in our queue, 00:22:43.000 --> 00:22:45.000 and first in, first out, first, next, next, next, next, next, 00:22:46.000 --> 00:22:47.000 like you see here, and away you go. 00:22:47.000 --> 00:22:48.000 So we're processing in that order, 00:22:49.000 --> 00:22:52.000 but what if these ones here, 00:22:53.000 --> 00:22:57.000 what if these were voice, 00:23:01.000 --> 00:23:04.000 and these were video, and this was all data, 00:23:05.000 --> 00:23:06.000 and these are like 1,500 bytes, 00:23:07.000 --> 00:23:08.000 and these are more like 200. 00:23:09.000 --> 00:23:10.000 There's a big difference there. 00:23:11.000 --> 00:23:12.000 This definitely would have a negative effect 00:23:13.000 --> 00:23:14.000 on that voice traffic. 00:23:14.000 --> 00:23:17.000 So instead, with our congestion management 00:23:18.000 --> 00:23:21.000 and our queues, we can create queues, 00:23:22.000 --> 00:23:26.000 and therefore now we can put voice, video, data, 00:23:27.000 --> 00:23:28.000 everything else as an example. 00:23:29.000 --> 00:23:31.000 So we have now a queuing system 00:23:32.000 --> 00:23:33.000 that has a classifier, 00:23:34.000 --> 00:23:35.000 and that classifier is going to help us 00:23:36.000 --> 00:23:37.000 choose what traffic is placed in each queue. 00:23:38.000 --> 00:23:39.000 So by being able to classify that traffic, 00:23:40.000 --> 00:23:41.000 oh, your voice traffic, 00:23:42.000 --> 00:23:43.000 based on our classification we're doing, 00:23:44.000 --> 00:23:45.000 then you go in this queue. 00:23:46.000 --> 00:23:48.000 Oh, your video traffic, you go in here. 00:23:49.000 --> 00:23:50.000 Oh, your data traffic, you go in here. 00:23:51.000 --> 00:23:52.000 So by simply looking at the headers 00:23:53.000 --> 00:23:54.000 that are already in our packets and our frames, 00:23:55.000 --> 00:23:56.000 our devices are going to know 00:23:57.000 --> 00:23:58.000 which queue do you belong to. 00:23:59.000 --> 00:24:00.000 And then we need to set up our schedule. 00:24:01.000 --> 00:24:02.000 Our schedule performs what? 00:24:03.000 --> 00:24:04.000 The prioritization that we need. 00:24:05.000 --> 00:24:06.000 So how much from this queue, 00:24:07.000 --> 00:24:08.000 how much from this queue, 00:24:09.000 --> 00:24:10.000 how much from this queue, 00:24:11.000 --> 00:24:12.000 like what order, at what speed, 00:24:13.000 --> 00:24:15.000 and we do all this using something called the MQC 00:24:16.000 --> 00:24:17.000 that we'll talk about here momentarily. 00:24:18.000 --> 00:24:19.000 The MQC, 00:24:20.000 --> 00:24:23.000 Modular Quality of Service Command Line Interface. 00:24:24.000 --> 00:24:25.000 So we use the MQC, 00:24:26.000 --> 00:24:27.000 and then we use what we call the service policy 00:24:28.000 --> 00:24:29.000 to apply it to our interfaces. 00:24:37.000 --> 00:24:39.000 So I put together a little chart here 00:24:40.000 --> 00:24:41.000 for some of the different queuing options 00:24:42.000 --> 00:24:43.000 that we have, folks, 00:24:44.000 --> 00:24:46.000 to help you get ready for the certification exam. 00:24:49.000 --> 00:24:50.000 First in, first out 00:24:51.000 --> 00:24:52.000 is our default queuing option. 00:24:53.000 --> 00:24:54.000 If there's no congestion, 00:24:55.000 --> 00:24:56.000 we are using first in, first out. 00:24:57.000 --> 00:24:58.000 Let's be very clear about that. 00:24:59.000 --> 00:25:00.000 Default queuing method 00:25:01.000 --> 00:25:02.000 where packets are processed and forwarded 00:25:03.000 --> 00:25:05.000 out an interface in the order they arrive 00:25:06.000 --> 00:25:08.000 without any specific prioritization. 00:25:09.000 --> 00:25:10.000 If you choose to implement 00:25:11.000 --> 00:25:12.000 a different queuing strategy, 00:25:13.000 --> 00:25:14.000 like priority queuing, 00:25:15.000 --> 00:25:16.000 what does that mean? 00:25:17.000 --> 00:25:18.000 What are you actually getting 00:25:19.000 --> 00:25:20.000 if you use priority queuing? 00:25:21.000 --> 00:25:22.000 So priority queuing allows you 00:25:23.000 --> 00:25:25.000 to have four priority-based queues. 00:25:27.000 --> 00:25:29.000 I wonder why Raymond has highlighted stuff 00:25:30.000 --> 00:25:32.000 and italicized stuff 00:25:33.000 --> 00:25:34.000 and underlined stuff. 00:25:35.000 --> 00:25:36.000 So four priority-based queues. 00:25:38.000 --> 00:25:39.000 And you'll see here 00:25:40.000 --> 00:25:42.000 that there's a different priority level assigned 00:25:44.000 --> 00:25:46.000 to each of those different queues 00:25:47.000 --> 00:25:48.000 based on our traffic classes. 00:25:50.000 --> 00:25:51.000 So, for example, 00:25:52.000 --> 00:25:53.000 you're going to have a high-priority queue 00:25:54.000 --> 00:25:55.000 for high-priority traffic. 00:25:56.000 --> 00:25:57.000 So your high-priority queue 00:25:58.000 --> 00:25:59.000 has your voice traffic in it. 00:26:00.000 --> 00:26:01.000 And all of that is going to be forwarded 00:26:02.000 --> 00:26:03.000 ahead of the interface. 00:26:04.000 --> 00:26:06.000 To the other lower-priority traffic. 00:26:07.000 --> 00:26:08.000 So you've got four queues. 00:26:09.000 --> 00:26:10.000 So one, two, three, four. 00:26:11.000 --> 00:26:12.000 One's the best, for example, 00:26:13.000 --> 00:26:14.000 with voice in one, 00:26:15.000 --> 00:26:16.000 maybe video in two, 00:26:17.000 --> 00:26:18.000 maybe data in three. 00:26:19.000 --> 00:26:20.000 It's a simple strategy, 00:26:21.000 --> 00:26:22.000 priority queuing. 00:26:23.000 --> 00:26:24.000 Custom queuing, 00:26:25.000 --> 00:26:26.000 let's go down to the bottom, 00:26:27.000 --> 00:26:28.000 allows you to configure 00:26:29.000 --> 00:26:30.000 a specific number of queues 00:26:31.000 --> 00:26:32.000 and allocate bandwidth 00:26:32.000 --> 00:26:33.000 to each queue manually. 00:26:34.000 --> 00:26:35.000 So you could set up, for example, 00:26:36.000 --> 00:26:37.000 let's say you wanted 16 queues. 00:26:38.000 --> 00:26:39.000 And then for each of those queues, 00:26:40.000 --> 00:26:41.000 set up specific bandwidth values, 00:26:42.000 --> 00:26:43.000 bandwidth requirements 00:26:44.000 --> 00:26:45.000 for each and every single one of those queues. 00:26:48.000 --> 00:26:50.000 So you can specify the number of bytes 00:26:51.000 --> 00:26:52.000 in a specific queue 00:26:53.000 --> 00:26:54.000 that should be dealt with 00:26:55.000 --> 00:26:56.000 before working on the next queue. 00:26:57.000 --> 00:26:58.000 So you could say, 00:26:59.000 --> 00:27:00.000 okay, my top queue, 00:27:00.000 --> 00:27:01.000 which is going to have my voice traffic, 00:27:02.000 --> 00:27:03.000 I want these many bytes processed 00:27:04.000 --> 00:27:05.000 before you move on to the next. 00:27:06.000 --> 00:27:07.000 However, if you turn around 00:27:08.000 --> 00:27:09.000 and you process everything that's in there 00:27:10.000 --> 00:27:11.000 and there's nothing else, 00:27:12.000 --> 00:27:13.000 then go on to the next anyways. 00:27:14.000 --> 00:27:15.000 And then once you've done that one, 00:27:16.000 --> 00:27:17.000 then go on to the next, 00:27:18.000 --> 00:27:19.000 then go on to the next, 00:27:20.000 --> 00:27:21.000 then go on to the next, 00:27:22.000 --> 00:27:23.000 then back to the top. 00:27:24.000 --> 00:27:25.000 So we're just going through them, 00:27:26.000 --> 00:27:27.000 going through them, right? 00:27:28.000 --> 00:27:29.000 And based on the amount of bandwidth, 00:27:30.000 --> 00:27:31.000 you're going to be able to do that. 00:27:32.000 --> 00:27:33.000 All right, next one on our list here 00:27:34.000 --> 00:27:35.000 I want to talk about. 00:27:36.000 --> 00:27:37.000 So we've covered this one, 00:27:38.000 --> 00:27:39.000 we've covered this one, 00:27:40.000 --> 00:27:41.000 we've covered this one. 00:27:42.000 --> 00:27:43.000 Okay, let's talk about weighted-fair queuing now. 00:27:44.000 --> 00:27:45.000 So weighted-fair queuing is classified 00:27:46.000 --> 00:27:47.000 as a flow-based queuing method 00:27:48.000 --> 00:27:49.000 that uses store-and-forward queues 00:27:50.000 --> 00:27:51.000 and allocates bandwidth. 00:27:52.000 --> 00:27:53.000 So this one was bytes, 00:27:54.000 --> 00:27:55.000 and this one is bandwidth 00:27:56.000 --> 00:27:57.000 proportionally to different flows 00:27:58.000 --> 00:27:59.000 based on a weight system 00:28:00.000 --> 00:28:01.000 and weighted-fair queuing 00:28:02.000 --> 00:28:03.000 takes weighted-fair queuing 00:28:04.000 --> 00:28:05.000 a step further. 00:28:06.000 --> 00:28:08.000 And it allows you to define traffic classes 00:28:09.000 --> 00:28:10.000 based on various criteria. 00:28:11.000 --> 00:28:12.000 So you can then allocate bandwidth 00:28:13.000 --> 00:28:14.000 and apply your policies 00:28:15.000 --> 00:28:16.000 to each and every single different class 00:28:17.000 --> 00:28:18.000 that you have. 00:28:19.000 --> 00:28:20.000 In addition, with weighted-fair queuing, 00:28:21.000 --> 00:28:22.000 this is a good one, 00:28:23.000 --> 00:28:24.000 you have the LLQ, the low-latency queue, 00:28:25.000 --> 00:28:26.000 low-latency queue, 00:28:27.000 --> 00:28:28.000 provides guaranteed bandwidth. 00:28:28.000 --> 00:28:29.000 Guaranteed bandwidth. 00:28:30.000 --> 00:28:31.000 Your LLQ provides guaranteed bandwidth 00:28:32.000 --> 00:28:33.000 and strict priority servicing 00:28:34.000 --> 00:28:35.000 to a specified class of traffic 00:28:36.000 --> 00:28:37.000 such as voice. 00:28:38.000 --> 00:28:39.000 So with weighted-fair queuing, 00:28:40.000 --> 00:28:41.000 you are going to put your voice traffic 00:28:42.000 --> 00:28:43.000 in the LLQ, the low-latency queue, 00:28:44.000 --> 00:28:45.000 so that way there, in the end, 00:28:46.000 --> 00:28:47.000 it has the guaranteed bandwidth 00:28:48.000 --> 00:28:49.000 that it needs, that voice traffic. 00:28:50.000 --> 00:28:51.000 So a lot of good information here for you. 00:28:52.000 --> 00:28:53.000 You don't have to be an expert 00:28:54.000 --> 00:28:55.000 with each and every single one of these queues 00:28:56.000 --> 00:28:57.000 for the certification exam, 00:28:58.000 --> 00:28:59.000 but you do get through 00:29:00.000 --> 00:29:01.000 the queuing questions that may, 00:29:02.000 --> 00:29:03.000 if they do show up 00:29:04.000 --> 00:29:05.000 on the certification exam. 00:29:08.000 --> 00:29:09.000 All right, back to this page here. 00:29:10.000 --> 00:29:11.000 We got last on our list here, 00:29:12.000 --> 00:29:13.000 WRED, 00:29:14.000 --> 00:29:15.000 Weighted Random Early Detection, 00:29:16.000 --> 00:29:17.000 W-R-E-D, 00:29:18.000 --> 00:29:21.000 a technique for congestion avoidance. 00:29:22.000 --> 00:29:23.000 So what is happening here 00:29:24.000 --> 00:29:25.000 with weighted random early detection? 00:29:26.000 --> 00:29:27.000 So it's a congestion avoidance feature 00:29:28.000 --> 00:29:29.000 that gives us the ability 00:29:30.000 --> 00:29:31.000 to selectively drop packets 00:29:32.000 --> 00:29:33.000 based on an assigned weight. 00:29:34.000 --> 00:29:35.000 Why do I want to do this? 00:29:36.000 --> 00:29:37.000 I want to do this so I can help prevent congestion 00:29:38.000 --> 00:29:40.000 by discarding lower-priority packets first. 00:29:41.000 --> 00:29:42.000 So what you need to realize 00:29:43.000 --> 00:29:44.000 is that you have your queue on your device. 00:29:46.000 --> 00:29:47.000 So if you have your queue on your device, 00:29:50.000 --> 00:29:52.000 and packets are backing up in the queue, 00:29:54.000 --> 00:29:55.000 what happens if the queue 00:29:56.000 --> 00:29:57.000 becomes 100% full? 00:29:58.000 --> 00:29:59.000 Well then, what happens to all these packets 00:30:00.000 --> 00:30:01.000 that are trying to get in? 00:30:02.000 --> 00:30:03.000 They get what is called tail drop. 00:30:04.000 --> 00:30:05.000 Tail drop. 00:30:07.000 --> 00:30:08.000 Why this is the tail of our queue. 00:30:11.000 --> 00:30:12.000 So all of the queuing strategies 00:30:13.000 --> 00:30:14.000 we just talked about, 00:30:15.000 --> 00:30:16.000 they're really for the head. 00:30:17.000 --> 00:30:18.000 The head of our queue, it's called. 00:30:19.000 --> 00:30:20.000 So based on the head of our queue, 00:30:21.000 --> 00:30:22.000 how do we organize everything 00:30:23.000 --> 00:30:24.000 at the head of our queue 00:30:25.000 --> 00:30:26.000 to make sure we get things prioritized and through? 00:30:26.000 --> 00:30:27.000 So at the head of the queue, 00:30:28.000 --> 00:30:29.000 we could still experience tail drop, 00:30:30.000 --> 00:30:31.000 even though at the head of the queue 00:30:32.000 --> 00:30:33.000 we have our queuing strategy. 00:30:34.000 --> 00:30:35.000 And so we want to stop this tail drop from happening 00:30:36.000 --> 00:30:37.000 because if voice packets are being dropped, 00:30:38.000 --> 00:30:39.000 that's no good. 00:30:40.000 --> 00:30:41.000 If real-time video packets are being dropped, 00:30:42.000 --> 00:30:43.000 that's no good. 00:30:44.000 --> 00:30:45.000 So this queue is being filled up. 00:30:46.000 --> 00:30:49.000 So what weighted random early detection does for us 00:30:50.000 --> 00:30:51.000 is it has the ability to, 00:30:52.000 --> 00:30:54.000 let me erase some of this first, 00:30:54.000 --> 00:30:56.000 so it has the ability to monitor the queue. 00:30:57.000 --> 00:30:59.000 And as it's monitoring the queue, 00:31:00.000 --> 00:31:01.000 all right, we're filling up. 00:31:02.000 --> 00:31:03.000 So based on the fact we're like 25% full, 00:31:04.000 --> 00:31:05.000 let's go ahead and drop 00:31:06.000 --> 00:31:08.000 X number of TCP packets out of here. 00:31:09.000 --> 00:31:10.000 There you go. 00:31:11.000 --> 00:31:14.000 So it's dropped X number of 1500 byte TCP packets 00:31:15.000 --> 00:31:16.000 out of there, freeing up some space. 00:31:17.000 --> 00:31:18.000 So now we're no longer 25% full. 00:31:19.000 --> 00:31:20.000 We are now maybe 15% full. 00:31:21.000 --> 00:31:23.000 So we just freed up a little bit of space. 00:31:24.000 --> 00:31:25.000 So hopefully that little bit of space now 00:31:26.000 --> 00:31:27.000 gets filled in with some voice packets, 00:31:28.000 --> 00:31:29.000 maybe some other things, 00:31:30.000 --> 00:31:31.000 and we don't get back to 25%. 00:31:32.000 --> 00:31:33.000 But let's say we got back to 25%, 00:31:34.000 --> 00:31:35.000 drop a little bit more. 00:31:36.000 --> 00:31:37.000 But what if all of a sudden it filled up to 50%? 00:31:38.000 --> 00:31:39.000 Well, then we're going to be more aggressive. 00:31:40.000 --> 00:31:41.000 We're going to drop maybe twice as many, 00:31:42.000 --> 00:31:43.000 1500 byte TCP packets. 00:31:44.000 --> 00:31:45.000 What if we get even more? 00:31:46.000 --> 00:31:47.000 Well, then maybe we'll drop even like 00:31:48.000 --> 00:31:49.000 maybe quadruple the amount 00:31:50.000 --> 00:31:51.000 or five times the amount or six times the amount 00:31:52.000 --> 00:31:53.000 of TCP base packets. 00:31:54.000 --> 00:31:58.000 Drop those packets that could be retransmitted. 00:31:59.000 --> 00:32:03.000 Drop those TCP large 1500 byte packets 00:32:04.000 --> 00:32:05.000 that could be retransmitted. 00:32:06.000 --> 00:32:07.000 So that way we're freeing up space 00:32:08.000 --> 00:32:09.000 for what, the voice packets to come in 00:32:10.000 --> 00:32:11.000 so they never get tail dropped, 00:32:12.000 --> 00:32:13.000 those voice packets. 00:32:14.000 --> 00:32:15.000 So it's a congestion avoidance feature. 00:32:16.000 --> 00:32:17.000 So that way when our queue is filling up, 00:32:18.000 --> 00:32:19.000 it can determine which packets are high priority 00:32:20.000 --> 00:32:21.000 and which packets are low priority, 00:32:22.000 --> 00:32:23.000 and then drop those low priority packets, 00:32:24.000 --> 00:32:26.000 those 1500 byte TCP packets as an example. 00:32:31.000 --> 00:32:32.000 MQC. 00:32:33.000 --> 00:32:34.000 What is the MQC, 00:32:35.000 --> 00:32:36.000 modular quality of service command line interface? 00:32:37.000 --> 00:32:41.000 So the MQC allows us to build a construct, 00:32:42.000 --> 00:32:43.000 a structure that's going to implement 00:32:44.000 --> 00:32:45.000 the quality of service for us. 00:32:46.000 --> 00:32:50.000 And I'm not going to go through the MQC here 00:32:51.000 --> 00:32:52.000 and show you how to create a class map 00:32:52.000 --> 00:32:54.000 or a policy map or a service policy for QoS. 00:32:55.000 --> 00:32:56.000 And the only reason why is because 00:32:57.000 --> 00:32:58.000 it is not exam relevant. 00:32:59.000 --> 00:33:01.000 And knowing the MQC is used is important, 00:33:02.000 --> 00:33:06.000 but not the actual MQC construct for QoS. 00:33:07.000 --> 00:33:08.000 Now, policy-based routing, 00:33:09.000 --> 00:33:10.000 we talked about the MQC. 00:33:11.000 --> 00:33:12.000 You remember that in policy-based routing? 00:33:13.000 --> 00:33:14.000 If you haven't watched the policy-based routing videos yet, 00:33:15.000 --> 00:33:16.000 we talked about the MQC there. 00:33:17.000 --> 00:33:18.000 And I talked about class map, policy map, 00:33:19.000 --> 00:33:20.000 service policy, and we applied the 00:33:21.000 --> 00:33:23.000 policy, the service policy, 00:33:24.000 --> 00:33:25.000 or the policy map, I should say, 00:33:26.000 --> 00:33:28.000 to the control plane interface. 00:33:29.000 --> 00:33:31.000 Did I say policy-based routing? 00:33:32.000 --> 00:33:33.000 I meant control plane policing. 00:33:34.000 --> 00:33:37.000 So, not policy-based routing, 00:33:38.000 --> 00:33:39.000 control plane policing videos. 00:33:40.000 --> 00:33:41.000 Do you remember those control plane policing videos 00:33:42.000 --> 00:33:43.000 that you went through earlier? 00:33:44.000 --> 00:33:45.000 If not, go watch them later. 00:33:46.000 --> 00:33:47.000 But we talked about the MQC for control plane policing, 00:33:48.000 --> 00:33:49.000 that's what it was, 00:33:50.000 --> 00:33:51.000 class map, policy map, service map. 00:33:52.000 --> 00:33:53.000 So, same idea, 00:33:54.000 --> 00:33:55.000 but now instead of dealing with it 00:33:56.000 --> 00:33:57.000 from a security standpoint, 00:33:58.000 --> 00:33:59.000 you'd be dealing with it from a quality of service standpoint, 00:34:00.000 --> 00:34:01.000 and you'd be dealing with, 00:34:02.000 --> 00:34:03.000 well, how much of this bandwidth for this queue, 00:34:04.000 --> 00:34:05.000 how much bytes for this queue, 00:34:06.000 --> 00:34:07.000 and so on and so forth as you're using it. 00:34:08.000 --> 00:34:09.000 So, the class map is used 00:34:10.000 --> 00:34:11.000 to identify the traffic to match. 00:34:12.000 --> 00:34:13.000 So, match the voice traffic, 00:34:14.000 --> 00:34:15.000 match the data traffic, 00:34:16.000 --> 00:34:17.000 match the video traffic, 00:34:18.000 --> 00:34:19.000 match this traffic type, 00:34:20.000 --> 00:34:21.000 and management traffic as well, 00:34:22.000 --> 00:34:23.000 and control traffic and everything else. 00:34:24.000 --> 00:34:25.000 And then the policy map 00:34:26.000 --> 00:34:27.000 is going to be what you use 00:34:28.000 --> 00:34:30.000 to define or create your scheduler. 00:34:31.000 --> 00:34:32.000 So, what happens here now 00:34:33.000 --> 00:34:34.000 is you are in your policy map saying, 00:34:35.000 --> 00:34:37.000 okay, so if it matches that class map, 00:34:38.000 --> 00:34:41.000 then I want you to give it 00:34:42.000 --> 00:34:43.000 this amount of bandwidth, 00:34:44.000 --> 00:34:45.000 or I want you to police it this way, 00:34:46.000 --> 00:34:47.000 or so on and so forth. 00:34:48.000 --> 00:34:49.000 So, that's where you're setting the actual values 00:34:50.000 --> 00:34:51.000 when it comes to how you treat 00:34:52.000 --> 00:34:53.000 that traffic in the policy map. 00:34:54.000 --> 00:34:55.000 So, if you have class maps 00:34:56.000 --> 00:34:57.000 for your management traffic, 00:34:58.000 --> 00:34:59.000 your control traffic, your data traffic, 00:35:00.000 --> 00:35:01.000 your voice traffic, your video traffic, 00:35:02.000 --> 00:35:03.000 then in your policy map, 00:35:04.000 --> 00:35:05.000 you're going to be specifying different policies 00:35:06.000 --> 00:35:07.000 for each and every single one of those classes. 00:35:08.000 --> 00:35:09.000 And then once that's all said and done, 00:35:10.000 --> 00:35:11.000 you can apply the policy map to the interface, 00:35:12.000 --> 00:35:15.000 and we call that our service policy. 00:35:16.000 --> 00:35:18.000 So, the service policy applied to the interface, 00:35:18.000 --> 00:35:19.000 so that way we can apply the QoS policy 00:35:20.000 --> 00:35:21.000 to that device's interface. 00:35:22.000 --> 00:35:23.000 The policy map defines our schedule, 00:35:24.000 --> 00:35:26.000 and our class map defines our traffic. 00:35:27.000 --> 00:35:28.000 That's what I want you to know 00:35:29.000 --> 00:35:30.000 for the certification exam. 00:35:31.000 --> 00:35:32.000 All right, so that's our QoS coverage, folks, 00:35:33.000 --> 00:35:34.000 for Encore. 00:35:35.000 --> 00:35:36.000 If you want to know more about QoS, 00:35:37.000 --> 00:35:38.000 then it's best to take a collaboration course 00:35:39.000 --> 00:35:40.000 where you're going to be covering things 00:35:41.000 --> 00:35:45.000 like voice and video in your environment. 00:35:46.000 --> 00:35:47.000 So, it'd be best to take 00:35:48.000 --> 00:35:49.000 one of those courses 00:35:50.000 --> 00:35:51.000 to get into the actual voice, video, 00:35:52.000 --> 00:35:53.000 and then more importantly, 00:35:54.000 --> 00:35:55.000 the quality of service that goes along 00:35:56.000 --> 00:35:57.000 with those in the environment. 00:35:58.000 --> 00:35:59.000 All right, so, for the exam, 00:36:00.000 --> 00:36:02.000 be sure to know classification, 00:36:03.000 --> 00:36:05.000 marking, policing, shaping, 00:36:06.000 --> 00:36:08.000 congestion avoidance, congestion management. 00:36:09.000 --> 00:36:10.000 Know the terms and definitions 00:36:11.000 --> 00:36:12.000 that we covered earlier on. 00:36:13.000 --> 00:36:14.000 Know why you want to use quality of service. 00:36:15.000 --> 00:36:16.000 Know where you want to classify, 00:36:16.000 --> 00:36:17.000 where you want to mark why, 00:36:18.000 --> 00:36:19.000 because those are the things 00:36:20.000 --> 00:36:21.000 that could be a simple multiple choice question, 00:36:22.000 --> 00:36:23.000 or maybe even a drag and drop, folks, 00:36:24.000 --> 00:36:25.000 that is going to test you on 00:36:26.000 --> 00:36:27.000 do you understand at a very, very, 00:36:28.000 --> 00:36:29.000 very fundamental high level 00:36:30.000 --> 00:36:31.000 what QoS is and what all these things are. 00:36:32.000 --> 00:36:33.000 So, same thing with your queuing strategies. 00:36:34.000 --> 00:36:35.000 Just having a basic understanding 00:36:36.000 --> 00:36:37.000 of those queuing strategies 00:36:38.000 --> 00:36:39.000 and what each of those can kind of do for you 00:36:40.000 --> 00:36:41.000 is what you want to get ready for 00:36:42.000 --> 00:36:43.000 for the certification exam.