WEBVTT 0:00:03.000000 --> 0:00:08.240000 Hello and welcome to this video on classification and marking. 0:00:08.240000 --> 0:00:12.160000 In this video I'm going to define what is meant by the term classification 0:00:12.160000 --> 0:00:15.060000 as far as QOS is concerned. 0:00:15.060000 --> 0:00:19.620000 We're going to look at how to classify layer two traffic, methods of classification 0:00:19.620000 --> 0:00:23.820000 at layer three. I'm going to give you a brief overview of something called 0:00:23.820000 --> 0:00:30.980000 end bar, and we're going to finish with something called trust boundaries. 0:00:30.980000 --> 0:00:34.200000 All right, so what is classification? 0:00:34.200000 --> 0:00:37.100000 So if you've watched any of my other videos or videos from other instructors 0:00:37.100000 --> 0:00:40.600000 on quality of service, you know that the first thing you have to do before 0:00:40.600000 --> 0:00:45.300000 you even configure anything is you, as a network engineer, have to define 0:00:45.300000 --> 0:00:48.100000 what traffic is important to you. 0:00:48.100000 --> 0:00:52.080000 In other words, what traffic you want to have special handling when there 0:00:52.080000 --> 0:00:55.200000 are times of congestion throughout your network. 0:00:55.200000 --> 0:00:58.960000 Now here's the thing, you might be able to answer that question or define 0:00:58.960000 --> 0:01:02.040000 that, but how does the router know that? 0:01:02.040000 --> 0:01:06.300000 So classification is implementing some sort of feature that translates 0:01:06.300000 --> 0:01:09.980000 what's in your head to what the router knows. 0:01:09.980000 --> 0:01:13.940000 So the first step that you have to do as the engineer is to divide your 0:01:13.940000 --> 0:01:19.580000 traffic into classes, and a class of traffic will receive a certain type 0:01:19.580000 --> 0:01:22.900000 of QOS traffic, or QOS treatment, I should say. 0:01:22.900000 --> 0:01:29.140000 So for example, classes might be low priority, high priority, and then 0:01:29.140000 --> 0:01:33.140000 you get to decide how you want your low priority traffic to be handled, 0:01:33.140000 --> 0:01:36.800000 and all the traffic that falls into that criteria gets handled the exact 0:01:36.800000 --> 0:01:41.680000 same way, versus a different type of behavior that's acted upon for your 0:01:41.680000 --> 0:01:44.820000 high priority traffic. 0:01:44.820000 --> 0:01:50.200000 So what a classification feature does is it analyzes every packet that 0:01:50.200000 --> 0:01:54.680000 comes in and tries to differentiate it and say, okay, what criteria does 0:01:54.680000 --> 0:01:59.420000 this fall into? And there's many different ways of classifying traffic, 0:01:59.420000 --> 0:02:01.780000 and we're going to take a look at some of those. 0:02:01.780000 --> 0:02:05.760000 So classification features are identification features. 0:02:05.760000 --> 0:02:10.000000 They're not actually going to necessarily do anything to the traffic, 0:02:10.000000 --> 0:02:13.000000 or modify it, or slow it down, or speed it up. 0:02:13.000000 --> 0:02:19.700000 Their objective is to identify it and categorize the traffic. 0:02:19.700000 --> 0:02:26.940000 Okay, so one of the primary things that normally goes along with a classification 0:02:26.940000 --> 0:02:32.260000 feature, a primary action that is typically done, is what's called marking, 0:02:32.260000 --> 0:02:36.800000 where once the classification feature looks at a packet and says, okay, 0:02:36.800000 --> 0:02:39.480000 it belongs in this category right here. 0:02:39.480000 --> 0:02:41.960000 That category might be low priority. 0:02:41.960000 --> 0:02:44.260000 That category might be voice. 0:02:44.260000 --> 0:02:47.720000 That category might be low latency traffic. 0:02:47.720000 --> 0:02:51.180000 Whatever the category is that you've defined, once the traffic is identified 0:02:51.180000 --> 0:02:54.220000 as belonging to that category, it's marked in some way. 0:02:54.220000 --> 0:02:59.560000 In other words, we apply some sort of a label or a value or a number to 0:02:59.560000 --> 0:03:04.340000 that traffic so that other subsequent network devices, like routers, switches, 0:03:04.340000 --> 0:03:09.200000 and firewalls, can then look at that marking and perform some action based 0:03:09.200000 --> 0:03:15.900000 on it. So there's three real high level ways of classifying traffic without 0:03:15.900000 --> 0:03:19.000000 necessarily getting to the names of specific features. 0:03:19.000000 --> 0:03:23.100000 So you can classify traffic based on markings. 0:03:23.100000 --> 0:03:27.220000 So what this would be talking about is traffic that has already been marked 0:03:27.220000 --> 0:03:28.560000 by something else. 0:03:28.560000 --> 0:03:32.580000 So for example, let's say that traffic has already gone through your network 0:03:32.580000 --> 0:03:37.780000 a little bit, some switch or router on the outer edge, classify the traffic 0:03:37.780000 --> 0:03:42.280000 into a category like voice or video or data, and apply to marking to it. 0:03:42.280000 --> 0:03:46.280000 Apply maybe a label giving it a number of three or five or something like 0:03:46.280000 --> 0:03:51.340000 that. Well, another router switch further on down the line, when it's 0:03:51.340000 --> 0:03:54.700000 doing classification, it could look for that number. 0:03:54.700000 --> 0:04:00.180000 It could look for that existing marking that was previously applied. 0:04:00.180000 --> 0:04:02.380000 It could be based on addressing. 0:04:02.380000 --> 0:04:05.660000 This is a very common way for edge devices at the edge of the network 0:04:05.660000 --> 0:04:09.920000 to distinguish traffic, is based on the source or destination address 0:04:09.920000 --> 0:04:11.840000 of where the traffic came from. 0:04:11.840000 --> 0:04:14.320000 Or maybe when we're talking about addressing, we're not necessarily talking 0:04:14.320000 --> 0:04:18.860000 about layer two or layer three addresses, but the addresses of port numbers, 0:04:18.860000 --> 0:04:21.740000 like the telnet port number or the HTTP port number. 0:04:21.740000 --> 0:04:26.380000 That would be a very common way of classifying traffic at the edge of 0:04:26.380000 --> 0:04:31.300000 your network. We can also do it based on application signatures. 0:04:31.300000 --> 0:04:36.080000 In other words, how the traffic behaves, or maybe something unique in 0:04:36.080000 --> 0:04:40.200000 the payload of that traffic will identify it as a certain application 0:04:40.200000 --> 0:04:44.120000 of traffic. So these are sort of three high level ways that we can distinguish 0:04:44.120000 --> 0:04:48.740000 one type of traffic from another and put it into the categories that we've 0:04:48.740000 --> 0:04:53.040000 defined. So let's go through each one of these, starting with layer two 0:04:53.040000 --> 0:04:58.040000 classification. So with layer two classification, you really can't do 0:04:58.040000 --> 0:05:04.000000 that unless an Ethernet frame is being carried on an 802.1 queue or an 0:05:04.000000 --> 0:05:07.060000 older Cisco proprietary ISL trunk. 0:05:07.060000 --> 0:05:11.680000 So what we're looking at here with layer two classification is, as a frame 0:05:11.680000 --> 0:05:17.580000 comes in, trying to find some sort of number or value in that frame that 0:05:17.580000 --> 0:05:22.900000 distinguishes it as being relatively a higher or lower priority than subsequent 0:05:22.900000 --> 0:05:26.560000 frames that have come in before it or will come in after it. 0:05:26.560000 --> 0:05:30.300000 Now, if you know the structure of how an Ethernet frame is put together, 0:05:30.300000 --> 0:05:32.900000 you know there is no such number by default. 0:05:32.900000 --> 0:05:36.820000 So when your laptop or PC creates an Ethernet frame, there's no priority 0:05:36.820000 --> 0:05:38.880000 field in there. It doesn't exist. 0:05:38.880000 --> 0:05:42.700000 But if that frame is going across a VLAN trunk, like from a router to 0:05:42.700000 --> 0:05:46.820000 a switch or from one switch to another, VLAN trunking mechanisms, like 0:05:46.820000 --> 0:05:51.640000 we've seen here 802.1 queue in ISL, they append some additional headers 0:05:51.640000 --> 0:05:55.580000 to that frame, and both of them, when they append a header, there's a 0:05:55.580000 --> 0:05:58.060000 priority field in that header. 0:05:58.060000 --> 0:06:02.940000 So 802.1 queue is much more popular than ISL, but you can see here in 0:06:02.940000 --> 0:06:07.460000 both. So at the top, we've got the ISL header, and you can see that the 0:06:07.460000 --> 0:06:10.960000 ISL header has got a lot of fields in it, but one of those fields is a 0:06:10.960000 --> 0:06:16.920000 priority field, and the 802.1 queue tag is down below, and you can see 0:06:16.920000 --> 0:06:19.040000 that also has a priority field. 0:06:19.040000 --> 0:06:24.040000 Now, when you manipulate that priority field, when you say, oh, okay, 0:06:24.040000 --> 0:06:30.940000 this Ethernet frame has a priority of two or three or one in it, technically 0:06:30.940000 --> 0:06:35.920000 what we call that is class of service or costs as we see it right here. 0:06:35.920000 --> 0:06:40.340000 So if somebody says, hey, in order to classify or identify traffic in 0:06:40.340000 --> 0:06:44.840000 my network, I'm relying on costs to do that, what they're really saying 0:06:44.840000 --> 0:06:49.100000 is they're not looking at anything layer three and above. 0:06:49.100000 --> 0:06:53.260000 All they're looking at is the ISL or the 802.1 queue header, and they're 0:06:53.260000 --> 0:06:56.880000 looking for the presence of this field to identify the priority of the 0:06:56.880000 --> 0:07:02.980000 frame. Now, this is not used that much because these tags and headers 0:07:02.980000 --> 0:07:09.180000 used by ISL and 802.1 queue are only relevant from one switch to another. 0:07:09.180000 --> 0:07:17.980000 In other words, if I have switch one right here, switch two right here, 0:07:17.980000 --> 0:07:26.260000 and switch three right here, well, yes, when a frame is going across this 0:07:26.260000 --> 0:07:32.200000 trunk from switch one to switch two, switch one certainly has the ability 0:07:32.200000 --> 0:07:38.920000 to add in this .1 queue tag and then to modify the user priority bits. 0:07:38.920000 --> 0:07:42.200000 But whatever he does those user priority bits, that's simply for switch 0:07:42.200000 --> 0:07:47.180000 two's benefit. Once switch two gets it, as part of his forwarding process, 0:07:47.180000 --> 0:07:51.580000 he's going to strip off that .1 queue tag, and then if he forwards it 0:07:51.580000 --> 0:07:56.140000 down to switch three, the original .1 queue tag is no longer preserved. 0:07:56.140000 --> 0:08:01.060000 So if you want to do costs, that's something you have to configure on 0:08:01.060000 --> 0:08:05.740000 every single switch end to end because those markings are not preserved. 0:08:05.740000 --> 0:08:10.200000 It's stripped off on each and every switch and then a new tag has to be 0:08:10.200000 --> 0:08:16.200000 applied. So for that reason, layer two costs is not used as much as the 0:08:16.200000 --> 0:08:19.540000 next one, which is layer three classification. 0:08:19.540000 --> 0:08:27.320000 Now, this is probably used 85, 90% of the time to classify traffic because 0:08:27.320000 --> 0:08:34.300000 both IPv4 and IPv6 have built into their headers fields for prioritizing 0:08:34.300000 --> 0:08:38.500000 traffic. Whether or not you use those fields, they're all there already. 0:08:38.500000 --> 0:08:43.220000 So with IPv4, we have the type of service field right there, and with 0:08:43.220000 --> 0:08:46.620000 IPv6, we have the traffic class fields. 0:08:46.620000 --> 0:08:51.180000 Now, normally if you don't do anything special, whenever your laptop creates 0:08:51.180000 --> 0:08:55.160000 an IPv4 and IPv6 packet, those fields would just be populated with all 0:08:55.160000 --> 0:08:58.960000 zeros, which would be basically like the default traffic. 0:08:58.960000 --> 0:09:03.340000 Everything is zero by default, but you can populate those fields with 0:09:03.340000 --> 0:09:08.780000 other numbers to give relatively higher or lower priority to your traffic. 0:09:08.780000 --> 0:09:11.140000 And we're going to look at that coming up. 0:09:11.140000 --> 0:09:18.020000 Now, sometimes traffic, you want to categorize it based on the type of 0:09:18.020000 --> 0:09:21.060000 application that created that traffic. 0:09:21.060000 --> 0:09:25.940000 Now, if that application uses consistent TCP or UDP port numbers that 0:09:25.940000 --> 0:09:29.720000 are predictable, that never change, you could do it there too. 0:09:29.720000 --> 0:09:34.060000 You could classify the traffic based on that TCP or UDP port number. 0:09:34.060000 --> 0:09:37.500000 And then based on the TCP or UDP port number, you could go back and mark 0:09:37.500000 --> 0:09:38.820000 these fields right here. 0:09:38.820000 --> 0:09:44.100000 You could say, okay, if I see TCP port number 23, I know that's Telnet, 0:09:44.100000 --> 0:09:47.960000 so I'm going to go into my router switch and have it look for Telnet traffic, 0:09:47.960000 --> 0:09:50.440000 and when it sees it, I'm going to have it go into the traffic. 0:09:50.440000 --> 0:09:53.840000 So, the type of service or the traffic class fields and change that from 0:09:53.840000 --> 0:09:58.460000 a zero to something higher, so it gets preferential treatment. 0:09:58.460000 --> 0:10:03.700000 But what about some applications that don't have predictable port numbers? 0:10:03.700000 --> 0:10:07.700000 There are some applications that use dynamically negotiated port numbers 0:10:07.700000 --> 0:10:10.280000 that you can't really predict in advance. 0:10:10.280000 --> 0:10:14.180000 And the only way you could recognize that traffic is based on the body 0:10:14.180000 --> 0:10:15.580000 of the IP packet. 0:10:15.580000 --> 0:10:20.320000 Something about the data itself would give a clue as to what that application 0:10:20.320000 --> 0:10:25.560000 was. And for that, we'd use something called network based application 0:10:25.560000 --> 0:10:28.900000 recognition or N-Bar. 0:10:28.900000 --> 0:10:32.520000 So, like I said, most protocols can be identified by well known layer 0:10:32.520000 --> 0:10:36.080000 three or layer four numbers, but some protocols can't. 0:10:36.080000 --> 0:10:39.920000 They use dynamic numbers, and this is what N-Bar is good for. 0:10:39.920000 --> 0:10:44.700000 N-Bar can actually look at the data payload, and by looking for signatures 0:10:44.700000 --> 0:10:48.720000 saying, okay, if the data payload has this shape and form, if it's got 0:10:48.720000 --> 0:10:53.600000 these particular characters inside of it, I know this particular application 0:10:53.600000 --> 0:10:55.520000 must have created that. 0:10:55.520000 --> 0:10:59.840000 Then N-Bar can report back and say, here's the application, and now we 0:10:59.840000 --> 0:11:00.900000 can mark that traffic. 0:11:00.900000 --> 0:11:04.500000 Now we can go into the TOS field and change it to some other number besides 0:11:04.500000 --> 0:11:10.920000 zero. So N-Bar as it says supports a recognition of a large quantity of 0:11:10.920000 --> 0:11:14.200000 protocols. For example, like this says, one example, you could use it 0:11:14.200000 --> 0:11:18.560000 to match on a URL name or word or phrase within the URL. 0:11:18.560000 --> 0:11:22.700000 That's clearly within the payload of a packet in order to spot that. 0:11:22.700000 --> 0:11:27.760000 Now this is implemented by the central processing unit of a device. 0:11:27.760000 --> 0:11:31.300000 So while this is something you could find on routers, a lot of switches 0:11:31.300000 --> 0:11:36.580000 don't support N-Bar as a classification mechanism. 0:11:36.580000 --> 0:11:40.520000 And the last thing I want to talk about in this particular video is just 0:11:40.520000 --> 0:11:44.620000 sort of a conceptual thing is something called a trust boundary. 0:11:44.620000 --> 0:11:50.540000 Now most host devices like your tablets, your smartphones, your laptops, 0:11:50.540000 --> 0:11:56.960000 your PCs, every single packet that's pumped out of that host doesn't have 0:11:56.960000 --> 0:11:57.140000 a lot of information. 0:11:57.140000 --> 0:12:00.940000 Or they all have the same default marking of zero. 0:12:00.940000 --> 0:12:05.060000 But it is possible, for example in Windows, to go into your Windows registry 0:12:05.060000 --> 0:12:10.800000 and change it so that packets leaving your laptop have a pre-marked field. 0:12:10.800000 --> 0:12:14.360000 You could go into Windows and say, hey, every packet that leaves my laptop, 0:12:14.360000 --> 0:12:19.160000 I want you to go into that TOS byte of the IPv4 header. 0:12:19.160000 --> 0:12:23.320000 Instead of having it be zero, let's have it be four or five. 0:12:23.320000 --> 0:12:28.540000 And if you do that, the hope, your hope is that the network is already 0:12:28.540000 --> 0:12:30.680000 configured for quality of service. 0:12:30.680000 --> 0:12:33.840000 It will see that number and they'll say, oh, I'm going to give that pathic 0:12:33.840000 --> 0:12:36.820000 preferential treatment because it's not zero. 0:12:36.820000 --> 0:12:38.740000 It's a higher number. 0:12:38.740000 --> 0:12:40.620000 But here's the thing. 0:12:40.620000 --> 0:12:42.980000 Do we really trust those devices? 0:12:42.980000 --> 0:12:46.800000 Do we trust our end user devices to mark the packets? 0:12:46.800000 --> 0:12:51.460000 Probably not. So we need to implement what's called QUS trust boundaries, 0:12:51.460000 --> 0:12:57.000000 which like it says, is a logical point in the network beyond that point. 0:12:57.000000 --> 0:12:59.360000 We don't trust any markings. 0:12:59.360000 --> 0:13:06.300000 So on switches, when you enable QUS on switches at a global high-level 0:13:06.300000 --> 0:13:11.440000 command, by default, all the ports in that switch become untrusted from 0:13:11.440000 --> 0:13:12.840000 a QUS perspective. 0:13:12.840000 --> 0:13:13.760000 What does that mean? 0:13:13.760000 --> 0:13:18.080000 Well, that means that if an Ethernet frame comes in any of those ports, 0:13:18.080000 --> 0:13:21.960000 and that Ethernet frame is already pre -marked in some way, like it comes 0:13:21.960000 --> 0:13:26.840000 in and it's already got a .1Q tag with a non-zero priority, or it comes 0:13:26.840000 --> 0:13:31.440000 in as an IP packet and it's got a non -zero TOS byte, we don't trust it. 0:13:31.440000 --> 0:13:36.160000 So we will set it back to zero because we only want our network infrastructure 0:13:36.160000 --> 0:13:39.980000 devices marking packets and raising these numbers. 0:13:39.980000 --> 0:13:42.180000 We don't want the hosts doing it. 0:13:42.180000 --> 0:13:44.800000 So that's what a trust boundary is in QUS. 0:13:44.800000 --> 0:13:49.940000 Some artificial perimeter that on the inside of the perimeter are the 0:13:49.940000 --> 0:13:54.040000 networking devices we have, and those are allowed to classify and mark 0:13:54.040000 --> 0:13:58.440000 packets. On the outside of that perimeter, that leads to our hosts. 0:13:58.440000 --> 0:14:00.020000 We don't want them doing it. 0:14:00.020000 --> 0:14:03.280000 And if they do mark the packet, we're just going to set it back to zero 0:14:03.280000 --> 0:14:05.780000 and they will have wasted their time. 0:14:05.780000 --> 0:14:09.280000 So that concludes this particular video. 0:14:09.280000 --> 0:14:10.080000 Thank you for watching.