WEBVTT 0:00:03.160000 --> 0:00:06.520000 Hello and welcome to this video, which is one of a series of videos, which 0:00:06.520000 --> 0:00:11.200000 is going to give you a review and refresher of quality of service features 0:00:11.200000 --> 0:00:16.840000 and concepts as pertains to the CCNA 200-301 exam. 0:00:16.840000 --> 0:00:20.880000 So we're going to start with the concept of classification and marking 0:00:20.880000 --> 0:00:24.860000 with QUS. Now, once again, I'm assuming that by the time you get to this 0:00:24.860000 --> 0:00:28.740000 video series, this bootcamp series, you've already gone through several 0:00:28.740000 --> 0:00:33.720000 other courses pertaining to the CCNA, one of which relates to QUS. 0:00:33.720000 --> 0:00:36.180000 So this is really a review for you. 0:00:36.180000 --> 0:00:42.120000 So let's start with what is classification, types of classification, and 0:00:42.120000 --> 0:00:43.480000 then we're going to go through that. 0:00:43.480000 --> 0:00:44.980000 All right, so what is classification? 0:00:44.980000 --> 0:00:48.480000 So in the world of QOS, here's your objective. 0:00:48.480000 --> 0:00:54.260000 You have identified, or you can predict, one or more points in your network, 0:00:54.260000 --> 0:00:58.020000 and by point, I mean interfaces in your network, that have gotten, or 0:00:58.020000 --> 0:01:00.120000 you think will get congested. 0:01:00.120000 --> 0:01:03.920000 Congestant, meaning there's so much traffic trying to leave that interface. 0:01:03.920000 --> 0:01:07.280000 That interface does not have enough bandwidth to transmit everything it 0:01:07.280000 --> 0:01:08.080000 wants to transmit. 0:01:08.080000 --> 0:01:12.360000 So it has to store stuff in memory buffers, and then at the worst case, 0:01:12.360000 --> 0:01:16.600000 if the congestion is persistent and doesn't slow down, those memory buffers 0:01:16.600000 --> 0:01:18.400000 ultimately get full. 0:01:18.400000 --> 0:01:21.540000 And now, any other packets that come into that router or switch that need 0:01:21.540000 --> 0:01:25.020000 to go out, that one interface, have to be dropped, because we have no 0:01:25.020000 --> 0:01:27.840000 more memory buffers to store those packets. 0:01:27.840000 --> 0:01:34.000000 So the idea behind QOS is that if you don't have QOS and that type of 0:01:34.000000 --> 0:01:36.760000 thing happens, you don't know what's going to be dropped. 0:01:36.760000 --> 0:01:40.140000 It could be your voice traffic, your data, your video, your mission critical, 0:01:40.140000 --> 0:01:41.960000 you have no control over that. 0:01:41.960000 --> 0:01:45.400000 So we want to give a little predictability and control, and that's what 0:01:45.400000 --> 0:01:47.240000 QOS is all about. 0:01:47.240000 --> 0:01:51.200000 And the first step of that is identifying your traffic, saying, so you 0:01:51.200000 --> 0:01:54.980000 would start in your mind in the design process, thinking to yourself, 0:01:54.980000 --> 0:01:57.820000 okay, how do I want to classify your traffic? 0:01:57.820000 --> 0:02:01.700000 So in my mind, I might come up with some ideas like, all right, well, 0:02:01.700000 --> 0:02:04.800000 my voice over IP is mission critical to me. 0:02:04.800000 --> 0:02:08.800000 If my IP phones go down or my IP phones get choppy, that's going to affect 0:02:08.800000 --> 0:02:12.920000 sales, which is going to affect my bottom line, my bottom dollar. 0:02:12.920000 --> 0:02:17.760000 So I want my IP traffic, my voice over IP, to have the highest priority. 0:02:17.760000 --> 0:02:21.520000 Then let's start making some other classifications of traffic like, okay, 0:02:21.520000 --> 0:02:24.340000 maybe my DNS traffic is second importance. 0:02:24.340000 --> 0:02:28.560000 Maybe my file servers are third importance and so on and so forth. 0:02:28.560000 --> 0:02:32.960000 So now you've come up in your mind about different types of traffic that's 0:02:32.960000 --> 0:02:36.220000 going to be going through those congested interfaces and you've sort of 0:02:36.220000 --> 0:02:37.740000 classified them. 0:02:37.740000 --> 0:02:43.160000 Now what you need to do is you need to translate what's in your head into 0:02:43.160000 --> 0:02:47.400000 the Cisco iOS command line into the routers and switches so they can properly 0:02:47.400000 --> 0:02:49.180000 identify the traffic as well. 0:02:49.180000 --> 0:02:53.800000 And then they can do something, they can do different QOS actions to different 0:02:53.800000 --> 0:02:56.300000 categories of traffic. 0:02:56.300000 --> 0:03:01.140000 So we must divide traffic into classes and a class of traffic will receive 0:03:01.140000 --> 0:03:02.560000 the same type of QOS treatment. 0:03:02.560000 --> 0:03:07.740000 So for example, voice over IP traffic might be defined as a class of traffic. 0:03:07.740000 --> 0:03:13.220000 And then once we identify, all right, how can I let the router or switch 0:03:13.220000 --> 0:03:17.320000 know that this packet you're looking at right now is voice over IP and 0:03:17.320000 --> 0:03:18.840000 this one is not. 0:03:18.840000 --> 0:03:24.160000 Well, what's distinctive about a voice over IP packet is it the UDP port 0:03:24.160000 --> 0:03:26.280000 number? Is it something else? 0:03:26.280000 --> 0:03:29.860000 So once you can identify that, you can tell the router switch. 0:03:29.860000 --> 0:03:33.380000 This is what I want you to look for like via an access list or something. 0:03:33.380000 --> 0:03:37.660000 And when you spot this, this belongs in the voice over IP class. 0:03:37.660000 --> 0:03:42.360000 Now I want you to apply these QOS characteristics or policies to that 0:03:42.360000 --> 0:03:44.080000 class of traffic. 0:03:44.080000 --> 0:03:48.480000 So we need to analyze the packets to differentiate flows and classification 0:03:48.480000 --> 0:03:53.040000 features. QOS features that are defined as classification features. 0:03:53.040000 --> 0:03:54.060000 That's what they do. 0:03:54.060000 --> 0:03:57.440000 They give us that ability to differentiate the traffic. 0:03:57.440000 --> 0:04:02.000000 I would say they give the router switch the ability to differentiate traffic. 0:04:02.000000 --> 0:04:05.700000 Just like you know in your mind how you want to differentiate traffic. 0:04:05.700000 --> 0:04:11.600000 Okay. So typically speaking. 0:04:11.600000 --> 0:04:16.220000 Step number one in QOS on your on your. 0:04:16.220000 --> 0:04:20.740000 Like access layer devices is to see all the packets coming in that all 0:04:20.740000 --> 0:04:25.820000 look the same and then inspect each one of those packets to identify what 0:04:25.820000 --> 0:04:28.420000 class of traffic that packet belongs to. 0:04:28.420000 --> 0:04:32.440000 Now that process of inspecting a packet looking deep into a packet, maybe 0:04:32.440000 --> 0:04:36.240000 be looking in the data of the of the packet, the body for certain characteristics 0:04:36.240000 --> 0:04:38.780000 can be fairly CPU intensive. 0:04:38.780000 --> 0:04:43.120000 So we don't want every router, every switch along the path from source 0:04:43.120000 --> 0:04:45.440000 to destination to have to do that. 0:04:45.440000 --> 0:04:49.580000 We really only want one device, usually the access layer, maybe one or 0:04:49.580000 --> 0:04:52.840000 two devices in from that to do that process. 0:04:52.840000 --> 0:04:57.500000 At that point, once that device has said, Oh, based on the access list 0:04:57.500000 --> 0:05:01.380000 or based on this other feature I'm using, that's voice over IP. 0:05:01.380000 --> 0:05:02.740000 That's DNS traffic. 0:05:02.740000 --> 0:05:04.100000 You know, that's telnet. 0:05:04.100000 --> 0:05:07.540000 Once it's done that and made that classification. 0:05:07.540000 --> 0:05:09.320000 Now we basically want to apply. 0:05:09.320000 --> 0:05:11.400000 I could say the word tag. 0:05:11.400000 --> 0:05:16.160000 We want to tag that traffic with an easy number to spot so that other 0:05:16.160000 --> 0:05:17.280000 devices further upstream. 0:05:17.280000 --> 0:05:19.840000 They don't have to do that deep packet inspection. 0:05:19.840000 --> 0:05:22.620000 They can say, Oh, I see a number on there. 0:05:22.620000 --> 0:05:25.140000 Number five. Well with number five. 0:05:25.140000 --> 0:05:28.200000 Now, you know as a network administrator that number five is because that 0:05:28.200000 --> 0:05:32.320000 first device. Recognize the voice over IP traffic and assign the number 0:05:32.320000 --> 0:05:36.840000 five to that. Number three, that first device recognized telnet traffic 0:05:36.840000 --> 0:05:38.680000 and assign the number three to that. 0:05:38.680000 --> 0:05:42.420000 So all other subsequent routers and switches, all they have to do is look 0:05:42.420000 --> 0:05:44.600000 for that number to do whatever QS policy. 0:05:44.600000 --> 0:05:46.320000 They're going to do. 0:05:46.320000 --> 0:05:49.660000 So that's what we're talking about when we talk about marking here. 0:05:49.660000 --> 0:05:53.700000 Marking a packet is simply putting some number in there, some indicator 0:05:53.700000 --> 0:05:58.020000 about the relative importance of this traffic or what class it belongs 0:05:58.020000 --> 0:06:04.240000 to. So the most common ways of classifying traffic. 0:06:04.240000 --> 0:06:08.860000 So what we're talking about here is when the traffic comes into a device 0:06:08.860000 --> 0:06:10.860000 like a router or a switch or a firewall. 0:06:10.860000 --> 0:06:15.040000 What are the most common methods that device will use to say, Oh, this 0:06:15.040000 --> 0:06:19.180000 traffic, I need to apply this particular QS policy to. 0:06:19.180000 --> 0:06:21.320000 Oh, this traffic over here is different. 0:06:21.320000 --> 0:06:23.980000 I need to apply a different QS policy to that. 0:06:23.980000 --> 0:06:25.420000 Well, the traffic might come in. 0:06:25.420000 --> 0:06:27.420000 It might already be pre marked. 0:06:27.420000 --> 0:06:31.600000 For example, some end devices like IP phones will already take your voice 0:06:31.600000 --> 0:06:35.620000 over IP packets and apply a marking to it right there as they're creating 0:06:35.620000 --> 0:06:37.640000 that voice over IP traffic. 0:06:37.640000 --> 0:06:40.360000 So the traffic might already be marked. 0:06:40.360000 --> 0:06:44.840000 It might be as something as simple as the layer three address where it 0:06:44.840000 --> 0:06:48.220000 came from, where it's going or maybe TCP UDP port numbers. 0:06:48.220000 --> 0:06:51.360000 Might be some sort of application signature. 0:06:51.360000 --> 0:06:54.400000 Sometimes we have features that will look deep inside of a packet, look 0:06:54.400000 --> 0:06:58.760000 into the date of a packet and maybe look for a certain URL or certain, 0:06:58.760000 --> 0:07:02.900000 you know, structure of data say, aha, that's what I'm looking for that 0:07:02.900000 --> 0:07:04.300000 matches what I'm looking for. 0:07:04.300000 --> 0:07:08.680000 So there's lots of different ways to do classification. 0:07:08.680000 --> 0:07:12.940000 Okay, so let's differentiate between layer two and layer three classification. 0:07:12.940000 --> 0:07:14.760000 So if I'm a switch. 0:07:14.760000 --> 0:07:20.060000 Or even a router and an Ethernet frame is coming into me and I want to 0:07:20.060000 --> 0:07:23.880000 be able to look at just the layer two headers of every Ethernet frame 0:07:23.880000 --> 0:07:26.900000 and say, ah, that is an at frame is carrying this is carrying voice. 0:07:26.900000 --> 0:07:29.440000 Ah, that is an at frame is carrying this is carrying. 0:07:29.440000 --> 0:07:37.280000 Tell that. How can we do that? 0:07:37.280000 --> 0:07:37.980000 What are the different ways to do that? 0:07:37.980000 --> 0:07:43.160000 Well, the problem we have is if you think about the layer two, Ethernet 0:07:43.160000 --> 0:07:45.440000 header your standard Ethernet header. 0:07:45.440000 --> 0:07:48.120000 All you have so traffic is going this way. 0:07:48.120000 --> 0:07:52.420000 All right, your very first field is going to be a preamble. 0:07:52.420000 --> 0:07:57.300000 Which is just going to be a static unchanging pattern of zeros and ones. 0:07:57.300000 --> 0:07:59.140000 We can't touch that. 0:07:59.140000 --> 0:08:05.020000 And then after that, we're going to have the destination MAC address. 0:08:05.020000 --> 0:08:07.440000 Followed by the source MAC address. 0:08:07.440000 --> 0:08:11.900000 Followed by an ether type. 0:08:11.900000 --> 0:08:15.840000 And then then we're done. 0:08:15.840000 --> 0:08:20.440000 Then the rest of it beyond that is your your layer three information. 0:08:20.440000 --> 0:08:24.440000 Now what I've just drawn right there is an Ethernet two header, which 0:08:24.440000 --> 0:08:28.140000 all IPV four and all IPV six packets carry. 0:08:28.140000 --> 0:08:32.560000 So there's really nothing in there that a receiving device can look at 0:08:32.560000 --> 0:08:35.760000 and say. Oh, yeah, I see a marking here. 0:08:35.760000 --> 0:08:40.040000 There's there's some number or some valid field that indicates what this 0:08:40.040000 --> 0:08:45.320000 is. So if we want to actually mark layer two traffic. 0:08:45.320000 --> 0:08:50.760000 The only way we can do that is by adding a field and this takes us right 0:08:50.760000 --> 0:08:54.600000 back to the concept of VLAN tagging, which is what trunks do. 0:08:54.600000 --> 0:08:59.920000 So layer two classification can only happen on VLAN trunks. 0:08:59.920000 --> 0:09:03.460000 Because whether you're doing ISL, which you're probably not doing that 0:09:03.460000 --> 0:09:05.780000 Cisco's proprietary way of doing trunking. 0:09:05.780000 --> 0:09:08.200000 Or whether you're doing the, you know, pretty much what everybody else 0:09:08.200000 --> 0:09:10.840000 does, the standard way of 802.1 Q. 0:09:10.840000 --> 0:09:16.480000 Both of those methods add additional headers or additional fields to your 0:09:16.480000 --> 0:09:20.620000 Ethernet frame. And one of those fields and both types is used for the 0:09:20.620000 --> 0:09:22.240000 priority or the marking of traffic. 0:09:22.240000 --> 0:09:26.900000 So if you're doing ISL, ISL takes your original frame. 0:09:26.900000 --> 0:09:29.580000 So right there, that's where your normal Ethernet header ends with your 0:09:29.580000 --> 0:09:33.900000 preamble. And it puts a new ISL header in front of that. 0:09:33.900000 --> 0:09:37.900000 The ISL header has a lot of stuff in it, but one of those fields. 0:09:37.900000 --> 0:09:45.680000 Is called the ISL user field and that has three bits of priority. 0:09:45.680000 --> 0:09:48.480000 Probably not going to see that most likely what you're going to see is 0:09:48.480000 --> 0:09:53.680000 an Ethernet frame doing 802.1 Q on a trunk, in which case, as we know 0:09:53.680000 --> 0:09:59.340000 as a review, 802.1 Q puts a tag in there and has three bits of a user 0:09:59.340000 --> 0:10:05.200000 priority field. So if you want to do some sort of marking at layer two 0:10:05.200000 --> 0:10:10.460000 on your access layer device, your access layer device could say, okay, 0:10:10.460000 --> 0:10:15.420000 here came in a frame that's got something in it and using an access list 0:10:15.420000 --> 0:10:18.500000 or something like that, I just identified this as being voice over IP 0:10:18.500000 --> 0:10:20.400000 traffic. Let's just say. 0:10:20.400000 --> 0:10:25.640000 So now that device, that switch, I'm going to trunk this to a router. 0:10:25.640000 --> 0:10:28.780000 Or I'm going to send this over a trunk to another switch. 0:10:28.780000 --> 0:10:33.040000 And if you're doing layer two classification, as we apply that .1 Q tag 0:10:33.040000 --> 0:10:36.660000 or the ISL header, now we're going to say, oh, if it's voice over IP, 0:10:36.660000 --> 0:10:39.100000 we're going to go into that user priority field, which is normally just 0:10:39.100000 --> 0:10:42.280000 0 0 0, that's the default for all traffic. 0:10:42.280000 --> 0:10:47.000000 Instead, I'm going to put a non zero number in there, like 101 or something 0:10:47.000000 --> 0:10:50.400000 like that. And then the next device, the router switches on the other 0:10:50.400000 --> 0:10:55.040000 side of that VLAN trunk can be configured to look for tags, look for that 0:10:55.040000 --> 0:11:00.180000 user priority field and apply different Qs policies based on what number 0:11:00.180000 --> 0:11:02.640000 it sees inside that field. 0:11:02.640000 --> 0:11:07.380000 So when you're doing your marking that way by using VLAN tags, we call 0:11:07.380000 --> 0:11:11.000000 that class of service or costs. 0:11:11.000000 --> 0:11:15.120000 So if you ever see that term in a document or a white paper class of service, 0:11:15.120000 --> 0:11:16.620000 that's what it's referring to. 0:11:16.620000 --> 0:11:23.160000 That's doing markings at layer two by utilizing most likely, 802.1 Q tags. 0:11:23.160000 --> 0:11:28.860000 Now the problem with 802.1 Q tags is they're only relevant from this device 0:11:28.860000 --> 0:11:35.660000 to this device. So switch a can insert a dot one Q tag, put in a user 0:11:35.660000 --> 0:11:39.920000 priority field of a non zero number like four or six, which can help switch 0:11:39.920000 --> 0:11:45.760000 B, but switch B then he's going to strip that tag off before he forwards 0:11:45.760000 --> 0:11:47.500000 it out another port. 0:11:47.500000 --> 0:11:50.880000 Now he might when switch B says, oh, I need to forward this frame. 0:11:50.880000 --> 0:11:59.700000 I just received out port 0 slash one. 0:11:59.700000 --> 0:11:59.920000 So if you want to do a new product, you want to do a new product, or if 0:11:59.920000 --> 0:11:59.920000 you want to do that, you want to do a new product, you want to do a new 0:11:59.920000 --> 0:12:02.220000 product, but it's not going to another switch or another router. 0:12:02.220000 --> 0:12:06.200000 But be that as it may switch B is going to apply a whole new tag to that 0:12:06.200000 --> 0:12:08.980000 frame when sending it out another trunk. 0:12:08.980000 --> 0:12:12.460000 And certainly if the if the egress port is not a trunk, if it's an access 0:12:12.460000 --> 0:12:16.940000 port or routed port, now we don't have any tags anymore. 0:12:16.940000 --> 0:12:21.040000 So this is only really good for when you want to do Qs from this device 0:12:21.040000 --> 0:12:23.420000 to this device. This is not a good method. 0:12:23.420000 --> 0:12:28.020000 If you want some access layer device to apply a tag that will carry through 0:12:28.020000 --> 0:12:32.440000 to the next router, the router behind that, you know, 10 routers deep. 0:12:32.440000 --> 0:12:34.140000 This is not the way you want to do that. 0:12:34.140000 --> 0:12:37.580000 So if you want to apply some sort of a marking that will be persistent 0:12:37.580000 --> 0:12:41.620000 as it goes through the entire network, then we most likely want to do 0:12:41.620000 --> 0:12:44.200000 some sort of layer three classification. 0:12:44.200000 --> 0:12:48.240000 And here we can use another existing field, which is the type of service 0:12:48.240000 --> 0:12:52.760000 byte. Now in IPv4, it's called the type of service. 0:12:52.760000 --> 0:12:55.180000 In IPv6, it's called traffic class. 0:12:55.180000 --> 0:13:01.100000 But either way, these fields were purpose built to give us some bits we 0:13:01.100000 --> 0:13:05.900000 can use to indicate the relative priority of a packet to tag a packet. 0:13:05.900000 --> 0:13:11.080000 Normally by default, every IP before or IPv6 packet, regardless of what 0:13:11.080000 --> 0:13:15.100000 it's carrying, voice, data, video, we'll have the type of service bit 0:13:15.100000 --> 0:13:17.840000 or byte all zeroed out. 0:13:17.840000 --> 0:13:19.180000 So here's another thing you can do. 0:13:19.180000 --> 0:13:22.540000 You can go into a router switch and say, hey, using an access list or 0:13:22.540000 --> 0:13:25.220000 using some other method, identify that traffic. 0:13:25.220000 --> 0:13:29.580000 Once you've identified that traffic as voice, for example, go into the 0:13:29.580000 --> 0:13:35.340000 type of service byte for IPv4 or go into the traffic class field. 0:13:35.340000 --> 0:13:40.120000 For IPv6 and change it to a nonzero number, change it to the number four, 0:13:40.120000 --> 0:13:43.220000 the number five or something along those lines. 0:13:43.220000 --> 0:13:48.480000 So that's the much more common way of marking traffic and identifying 0:13:48.480000 --> 0:13:54.440000 different flows or different classes of traffic is by modifying that field. 0:13:54.440000 --> 0:13:58.720000 And what we'll see in the next video is that that field can be interpreted 0:13:58.720000 --> 0:14:00.780000 in one of two ways. 0:14:00.780000 --> 0:14:04.840000 So the older way was something called IP precedence, where we said, okay, 0:14:04.840000 --> 0:14:09.540000 of that entire byte type of service or traffic class of the entire byte, 0:14:09.540000 --> 0:14:13.940000 a few of the bits on the front end, I can use for marking, I can use for 0:14:13.940000 --> 0:14:17.940000 putting a number in there to identify the class of the traffic. 0:14:17.940000 --> 0:14:21.460000 With IP precedence of the site's IP precedence. 0:14:21.460000 --> 0:14:24.720000 And then the newer way, well, newer, it's been out for a couple of decades 0:14:24.720000 --> 0:14:28.960000 now, but the newer way was something called DSCP, which allowed to use 0:14:28.960000 --> 0:14:33.720000 many more bits within that field, which gave you a lot more variations 0:14:33.720000 --> 0:14:41.460000 in the quantity of numbers you could put into that field. 0:14:41.460000 --> 0:14:44.400000 All right, and the last thing I want to talk about here in just this overview 0:14:44.400000 --> 0:14:47.520000 is something called trust boundaries. 0:14:47.520000 --> 0:14:55.260000 So if I am an access layer networking device, I'm a switch, I'm a router, 0:14:55.260000 --> 0:14:57.960000 and I'm directly connected to some end user. 0:14:57.960000 --> 0:15:01.560000 Okay, I'm connected to a laptop or a PC or a server. 0:15:01.560000 --> 0:15:06.920000 If a packet comes into me, and I noticed that the type of service byte 0:15:06.920000 --> 0:15:11.280000 or the traffic class field has already been populated with a non zero 0:15:11.280000 --> 0:15:16.500000 number. Now I have to say, okay, wait a second. 0:15:16.500000 --> 0:15:22.220000 The network, usually the network devices are controlled by your network 0:15:22.220000 --> 0:15:27.880000 administrators, your trusted people, hopefully that you've hired to run 0:15:27.880000 --> 0:15:30.520000 your network and to come up with an implement. 0:15:30.520000 --> 0:15:35.280000 Good sound logical policies that are going to be in that network. 0:15:35.280000 --> 0:15:41.240000 So if a router switch is going to mark a packet, that's probably okay 0:15:41.240000 --> 0:15:44.860000 because some network administrator got into that device, configured it 0:15:44.860000 --> 0:15:48.120000 using a well thought out policy and design. 0:15:48.120000 --> 0:15:52.740000 And so whatever marking that router switch applies is probably safe, hopefully, 0:15:52.740000 --> 0:15:55.300000 unless someone's hacked into our router switch. 0:15:55.300000 --> 0:15:58.980000 But we don't really have a lot of control over what our end users are 0:15:58.980000 --> 0:16:04.500000 doing. So some server or laptop or PC, when it's generating a packet from 0:16:04.500000 --> 0:16:08.980000 scratch, if somebody on that laptop, for example, went into their registry 0:16:08.980000 --> 0:16:14.020000 editor and they changed their registry to pre mark packets. 0:16:14.020000 --> 0:16:15.920000 Do they know what they were doing? 0:16:15.920000 --> 0:16:18.980000 Do we trust their reasoning behind that? 0:16:18.980000 --> 0:16:22.640000 Are they trying to do something sneaky and maybe, you know, we don't know 0:16:22.640000 --> 0:16:24.360000 what they're doing? 0:16:24.360000 --> 0:16:29.460000 So with QSP have this concept of trust boundaries, where we say, okay, 0:16:29.460000 --> 0:16:32.700000 interfaces typically leading to end devices. 0:16:32.700000 --> 0:16:35.920000 Do we trust those interfaces from a QS perspective? 0:16:35.920000 --> 0:16:40.520000 If the answer is yes, then that means, okay, an end user can mark their 0:16:40.520000 --> 0:16:41.760000 packets if they want to. 0:16:41.760000 --> 0:16:45.380000 And when it comes into the first networking device, we'll leave it alone. 0:16:45.380000 --> 0:16:48.120000 We'll trust that marking and we'll look at that and we'll apply QS policies 0:16:48.120000 --> 0:16:50.700000 based on what that end user did. 0:16:50.700000 --> 0:16:55.180000 Most of the time, you don't trust those devices. 0:16:55.180000 --> 0:16:59.860000 So at least on switches anyway, switches have this concept that when you 0:16:59.860000 --> 0:17:04.380000 enable QOS, a lot of them, not necessarily all of them, but a lot of them 0:17:04.380000 --> 0:17:10.100000 by default, instantly mark all their ports as untrusted ports, which means 0:17:10.100000 --> 0:17:15.120000 that if a user's data comes in that's pre marked, that port will reset 0:17:15.120000 --> 0:17:18.980000 those markings back down to the default of zero. 0:17:18.980000 --> 0:17:23.320000 So it'll sort of thwart or circumvent whatever the end user was trying 0:17:23.320000 --> 0:17:28.020000 to do. And then of course you can go on to interfaces if you want to and 0:17:28.020000 --> 0:17:29.720000 mark them as trusted. 0:17:29.720000 --> 0:17:34.500000 But usually you want the markings to be applied by a networking device, 0:17:34.500000 --> 0:17:38.520000 not by an end user device. 0:17:38.520000 --> 0:17:41.440000 So that's what the concept of a trust boundary is. 0:17:41.440000 --> 0:17:45.400000 It's like, okay, beyond this periphery here, beyond this periphery of 0:17:45.400000 --> 0:17:50.100000 ports, anything outside of that, if anything outside that periphery marks 0:17:50.100000 --> 0:17:52.180000 a packet, we don't trust it. 0:17:52.180000 --> 0:17:53.540000 We don't know why they did it. 0:17:53.540000 --> 0:17:56.960000 So once it hits our periphery, our trusted boundary, we're going to reset 0:17:56.960000 --> 0:18:01.540000 it back to zero, or maybe we'll mark it to what we think it should be. 0:18:01.540000 --> 0:18:04.280000 That's what a trust boundary is. 0:18:04.280000 --> 0:18:08.620000 All right, so that concludes this video, which was an introduction to 0:18:08.620000 --> 0:18:11.500000 the concept of classification and marking.