WEBVTT 1 00:00.000 --> 00:05.160 Well one of the ways that we can tag our packets is by leveraging class of 2 00:05.160 --> 00:13.660 service which is a layer two mechanism. What do we mean by layer two? Well it's 3 00:13.660 --> 00:19.720 layer two because it's going to go inside of the Ethernet header and this is 4 00:19.720 --> 00:19.960 going 5 00:19.960 --> 00:24.320 to be especially useful for layer two devices. So if we think about layer two 6 00:24.320 --> 00:29.120 switches that can't look beyond the Ethernet header well then we need a way 7 00:29.120 --> 00:34.080 for those devices to classify traffic and so it will rely on the class of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 7 00:29.120 --> 00:34.080 for those devices to classify traffic and so it will rely on the class of 8 00:34.080 --> 00:43.480 service tag. Now class of service is defined by 802.1p which is part of 802.1q. 9 00:43.480 --> 00:49.640 802.1q should sound a little bit familiar because this is Ethernet 10 00:49.640 --> 00:56.160 trunking. So recall how trunking works. We have an Ethernet header so this is 11 00:56.160 --> 00:56.280 the 12 00:56.280 --> 01:02.080 Ethernet header and yeah the rest of the frame is over here this is where the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 12 00:56.280 --> 01:02.080 Ethernet header and yeah the rest of the frame is over here this is where the 13 01:02.080 --> 01:07.840 UTCP and the IP headers are and the payload and all of the things but inside 14 01:07.840 --> 01:12.200 the Ethernet header this is going to be 14 bytes by default. 12 of those bytes 15 01:12.200 --> 01:16.120 are for the address so it's the majority of them source and destination address 16 01:16.120 --> 01:21.160 6 bytes each and then over here we just have two bytes of flags for a type and 17 01:21.160 --> 01:27.200 length. But we see that we don't actually have a spot for a VLAN tag so where 18 01:27.200 --> 01:27.320 does 19 01:27.320 --> 01:33.120 the VLAN tag come from? Well we actually insert an additional four bytes in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 01:27.320 --> 01:33.120 the VLAN tag come from? Well we actually insert an additional four bytes in 20 01:33.120 --> 01:33.400 here 21 01:33.400 --> 01:39.920 and these four bytes are going to be where we have a bunch of extra bits and 22 01:39.920 --> 01:46.080 we use a lot of these for the VLAN ID. The VLAN ID consumes 12 bits and keep in 23 01:46.080 --> 01:51.200 mind that four bytes we get 32 bits and so 12 of those bits are consumed by the 24 01:51.200 --> 01:57.160 VLAN ID. We've got a bunch of other aspects and elements to this header but 25 01:57.160 --> 02:01.440 what we're going to find is that we actually end up having an additional WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 25 01:57.160 --> 02:01.440 what we're going to find is that we actually end up having an additional 26 02:01.440 --> 02:07.480 three bytes in here that are going to be used for class of service. Pretty cool 27 02:07.480 --> 02:07.480 . 28 02:07.480 --> 02:14.960 So we get three bits that can be used to help us tag our packets. So that's the 29 02:14.960 --> 02:19.640 breakdown from a bits and bytes perspective but we just said something 30 02:19.640 --> 02:24.560 very very important and that is that this class of service tag is inserted 31 02:24.560 --> 02:34.640 into the 802.1 queue header. Well if it's only going into this header that gets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 02:24.560 --> 02:34.640 into the 802.1 queue header. Well if it's only going into this header that gets 32 02:34.640 --> 02:39.970 inserted on trunks that has some pretty important implications. First and 33 02:39.970 --> 02:40.400 foremost 34 02:40.400 --> 02:48.830 this is only going to work on trunk links only because a non-trunk doesn't 35 02:48.830 --> 02:49.120 carry 36 02:49.120 --> 02:53.160 this additional header. If we want the additional header to get those four 37 02:53.160 --> 02:58.320 bytes well we have to be talking about a trunk link at that point and that's 38 02:58.320 --> 03:03.120 what's going to get us the COS bits. The other important thing in all of this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 02:58.320 --> 03:03.120 what's going to get us the COS bits. The other important thing in all of this 39 03:03.120 --> 03:03.360 is 40 03:03.360 --> 03:11.720 notice this is also ethernet only. Now in our modern day world we see a lot of 41 03:11.720 --> 03:16.440 ethernet. There's not nearly as much non-ethronet anymore but keep in mind 42 03:16.440 --> 03:20.620 that this is going to impact us if we're talking about win links like T1s and E 43 03:20.620 --> 03:20.880 1s 44 03:20.880 --> 03:27.880 or T3s and E3s. If we have any kind of other mechanism that removes the ether 45 03:27.880 --> 03:28.080 net 46 03:28.080 --> 03:33.800 frame, the ethernet header then we are going to lose those bits. And so we have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 46 03:28.080 --> 03:33.800 frame, the ethernet header then we are going to lose those bits. And so we have 47 03:33.800 --> 03:39.920 to be very careful about using COS because in the end COS is not considered 48 03:39.920 --> 03:45.120 to be an end-to-end mechanism. And the reason it's not considered to be end-to- 49 03:45.120 --> 03:45.520 end 50 03:45.520 --> 03:50.340 is because if either of these aspects aren't true we're going to lose the COS 51 03:50.340 --> 03:57.600 tag. So how do we get an end-to-end tag? Well we're going to talk about the tag 52 03:57.600 --> 04:02.680 option we have in the IP header coming up. But again COS remains important WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 52 03:57.600 --> 04:02.680 option we have in the IP header coming up. But again COS remains important 53 04:02.680 --> 04:03.200 because 54 04:03.200 --> 04:08.920 of these elements. First of all layer two devices are going to heavily rely on 55 04:08.920 --> 04:14.240 COS if it exists. Some layer two devices can't even look into the IP header to 56 04:14.240 --> 04:20.160 look at those layer three tags. The other element to consider is the fact that 57 04:20.160 --> 04:20.400 we 58 04:20.400 --> 04:27.320 use COS in layer two heavy environments. For example the data center. The data 59 04:27.320 --> 04:32.480 center in Cisco Nexus switches are going to be heavily reliant on COS because WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 59 04:27.320 --> 04:32.480 center in Cisco Nexus switches are going to be heavily reliant on COS because 60 04:32.480 --> 04:39.400 their primary purpose is to process a lot. And I mean a lot of layer two 61 04:39.400 --> 04:39.920 traffic. 62 04:39.920 --> 04:44.640 And so in layer two heavy environments COS is still going to come into play. So 63 04:44.640 --> 04:50.240 yeah a lot of our networks are going to rely more on IP tags especially DSCP. 64 04:50.240 --> 04:55.040 But COS continues to be relevant even in the modern network because of these 65 04:55.040 --> 05:01.480 reasons. So what kinds of values can we have with COS? Well again COS is three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 04:55.040 --> 05:01.480 reasons. So what kinds of values can we have with COS? Well again COS is three 66 05:01.480 --> 05:08.040 bits which means that we have a range of zero through seven. So what this 67 05:08.040 --> 05:13.760 typically looks like is that six and seven are going to be reserved. And these 68 05:13.760 --> 05:19.680 are reserved for network traffic. Typically what we see is packets like 69 05:19.680 --> 05:25.600 OSPF and EIGRP. Hello messages those kinds of things might use a COS of six 70 05:25.600 --> 05:31.560 between devices. COS is of seven usually is only used internally to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 05:25.600 --> 05:31.560 between devices. COS is of seven usually is only used internally to 71 05:31.560 --> 05:37.200 devices. So packets frames from one internal process to another might be 72 05:37.200 --> 05:42.440 tagged with a seven because those are probably pretty important. Usually we 73 05:42.440 --> 05:47.400 see the priority level increasing meaning that the higher the number the 74 05:47.400 --> 05:52.440 more important that traffic is. So as we've already mentioned a tag of five at 75 05:52.440 --> 05:55.520 least in the last video I was using that tag of five intentionally because COS 76 05:55.520 --> 05:55.680 of 77 05:55.680 --> 06:02.200 tie COS of five is typically tagged that way for voice over IP traffic. And we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 05:55.680 --> 06:02.200 tie COS of five is typically tagged that way for voice over IP traffic. And we 78 06:02.200 --> 06:07.880 will a lot of times see that for is reserved for video as well. Now again if 79 06:07.880 --> 06:11.600 we're in the data center we're going to find that three is usually used for 80 06:11.600 --> 06:14.920 fiber channel over ethernet traffic. If you're not focused on data center 81 06:14.920 --> 06:18.360 technologies you don't need to worry too much about that. But that's an 82 06:18.360 --> 06:22.760 interesting element because we also see three used in the network side of 83 06:22.760 --> 06:22.960 things 84 06:22.960 --> 06:30.640 for voice over IP control channels. And then from there we might see WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 84 06:22.960 --> 06:30.640 for voice over IP control channels. And then from there we might see 85 06:30.640 --> 06:36.680 something like two reserved for bulk traffic and one for what we call scavenger 86 06:36.680 --> 06:43.480 traffic. That is the traffic that we are supposed to care the least about in 87 06:43.480 --> 06:43.600 our 88 06:43.600 --> 06:53.360 network. And then zero we flag this for being best effort. Yes we still want to 89 06:53.360 --> 06:57.600 deliver service and allow traffic to get through our network if it's tagged 90 06:57.600 --> 06:57.720 with 91 06:57.720 --> 07:02.280 zero. Our internet streaming might be zero or we've got all kinds of different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 06:57.720 --> 07:02.280 zero. Our internet streaming might be zero or we've got all kinds of different 92 07:02.280 --> 07:06.470 traffic types that might be tagged with zero. And that's fine we still want 93 07:06.470 --> 07:06.640 that 94 07:06.640 --> 07:12.520 traffic to get through and to have a decent experience level. But these other 95 07:12.520 --> 07:17.280 traffic types especially real-time applications like voice and video they 96 07:17.280 --> 07:22.480 must have reservations on the network and it has to be prioritized over best 97 07:22.480 --> 07:27.000 effort. But that's not to say best effort can be drowned out and so as we talk 98 07:27.000 --> 07:30.280 more and more about quality of service we're going to find that we will still WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 07:27.000 --> 07:30.280 more and more about quality of service we're going to find that we will still 99 07:30.280 --> 07:35.560 have traffic reservations for best effort. And by the way best effort having a 100 07:35.560 --> 07:35.760 tag 101 07:35.760 --> 07:41.840 of zero this is the default setting for most network interfaces. So unless we 102 07:41.840 --> 07:45.160 explicitly say we want to tag it with something else we can expect our 103 07:45.160 --> 07:48.920 traffic to be tagged with zero.