WEBVTT 1 00:00.000 --> 00:03.360 Well, like with some of our other reviews, we're going to go through 2 00:03.360 --> 00:08.720 Equiz together and I'm not going to pause the video between the question and 3 00:08.720 --> 00:09.120 the 4 00:09.120 --> 00:14.320 solution. And so go ahead and pause the video yourself to make sure that you 5 00:14.320 --> 00:18.800 understand what is being asked as well as what the answer is. And then hit the 6 00:18.800 --> 00:21.440 play button to review the question together or at that point if you know 7 00:21.440 --> 00:24.400 the answer you can probably just skip ahead to the next question as well. 8 00:24.400 --> 00:29.080 Whatever works best for you but just make sure that as we go through these that 9 00:29.080 --> 00:32.280 you're taking some good notes because the purpose of the quiz is not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 9 00:29.080 --> 00:32.280 you're taking some good notes because the purpose of the quiz is not 10 00:32.280 --> 00:32.760 necessarily 11 00:32.760 --> 00:36.520 to get everything right. If I'm getting everything right then that's great 12 00:36.520 --> 00:40.520 because it means that I understand things but it's also good to recognize the 13 00:40.520 --> 00:44.600 things that I don't understand, identify those areas of weakness. And then at 14 00:44.600 --> 00:44.760 the 15 00:44.760 --> 00:49.800 bottom of every quiz question here we have the source skill name. So if there's 16 00:49.800 --> 00:49.960 a 17 00:49.960 --> 00:53.480 question that trips you up be sure to go back to that skill and review those 18 00:53.480 --> 00:56.680 concepts to make sure we've got it all down before moving on 19 00:56.680 --> 01:01.640 beyond quality of service. So we've got eight questions in this quiz video. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:56.680 --> 01:01.640 beyond quality of service. So we've got eight questions in this quiz video. 20 01:01.640 --> 01:05.560 This is the first one and the question is this what are two properties of the 21 01:05.560 --> 01:11.560 diff-serve QOS model used in modern networks. So this is going all the way 22 01:11.560 --> 01:14.600 back to the very basics of quality of service and the idea 23 01:14.600 --> 01:18.680 is that we want to prioritize certain traffic flows as they go across the 24 01:18.680 --> 01:24.280 network. And we had two different models that we saw being developed. One was 25 01:24.280 --> 01:28.760 integrated services or into serve and the other is differentiated services 26 01:28.760 --> 01:29.000 which 27 01:29.000 --> 01:33.560 is diff-serve. So this diff-serve is being compared to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 27 01:29.000 --> 01:33.560 is diff-serve. So this diff-serve is being compared to 28 01:33.560 --> 01:38.600 in-serve and in-serve was trying to replicate that 29 01:38.600 --> 01:44.280 circuit-switched type of network concept from way back in the day where we'd 30 01:44.280 --> 01:44.440 get 31 01:44.440 --> 01:48.920 a dedicated circuit which the good news there is that I don't have to 32 01:48.920 --> 01:52.600 worry about competing packets. The bad news is not very efficient which led 33 01:52.600 --> 01:56.920 us to packet-switched networks. So int-serve is trying to say hey let's go 34 01:56.920 --> 02:00.920 back to that concept where we reserve bandwidth for the entire WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 34 01:56.920 --> 02:00.920 back to that concept where we reserve bandwidth for the entire 35 02:00.920 --> 02:04.040 length of the path from the very beginning to the very end and if there's 36 02:04.040 --> 02:08.120 any device in the middle that can't provide that bandwidth reservation 37 02:08.120 --> 02:13.480 then we cannot move forward with that traffic prioritization and 38 02:13.480 --> 02:17.960 reservation. And we're going to use the RSVP protocol in order to 39 02:17.960 --> 02:22.440 enable the int-serve model which also means we're not using RSVP for 40 02:22.440 --> 02:26.200 diff-serve. Instead what we're doing is we're going to be looking 41 02:26.200 --> 02:31.240 at interface based bandwidth reservations and they're going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 41 02:26.200 --> 02:31.240 at interface based bandwidth reservations and they're going to be 42 02:31.240 --> 02:36.920 relying on packet-based marketing and queuing. So BND are going to be our two 43 02:36.920 --> 02:40.680 answers here. We are again trying to make sure we understand the 44 02:40.680 --> 02:43.720 difference between int-serve and diff-serve and also understand that 45 02:43.720 --> 02:50.440 diff-serve relies on the concept of this marking of my packets. I guess I 46 02:50.440 --> 02:55.160 should have gotten out of the way. There we go. So it's differentiating 47 02:55.160 --> 02:59.400 from int-serve in that we're going to use marking so I'm going to tag my 48 02:59.400 --> 03:03.560 packets with DSVP or IP precedence or class of service WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 48 02:59.400 --> 03:03.560 packets with DSVP or IP precedence or class of service 49 03:03.560 --> 03:08.360 and based on that marking I'm going to place those packets into queues 50 03:08.360 --> 03:11.880 and then every interface itself will manage its bandwidth 51 03:11.880 --> 03:15.080 reservations. I cannot do something end-to-end 52 03:15.080 --> 03:19.960 with diff-serve. So that's the downside is I'm going to respect the 53 03:19.960 --> 03:23.480 reservation on this interface but I'm going to send it to a device 54 03:23.480 --> 03:27.720 and hope that that device is also going to respect the reservation. 55 03:27.720 --> 03:32.280 But the reservation is based on that device's configuration and this device WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 03:27.720 --> 03:32.280 But the reservation is based on that device's configuration and this device 56 03:32.280 --> 03:37.640 on the left has no power to enforce that on the other device. 57 03:37.640 --> 03:41.080 So again let's make sure we understand the difference between these two models 58 03:41.080 --> 03:45.800 moving forward. All right question number two what are the 59 03:45.800 --> 03:50.040 Cisco recommended thresholds for voice over IP traffic for each of the 60 03:50.040 --> 03:53.320 following metrics. So we want to make sure that for 61 03:53.320 --> 03:58.200 voice over IP traffic that we are hitting these metrics and specific 62 03:58.200 --> 04:02.360 values and thresholds but we want to make sure we also understand what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 62 03:58.200 --> 04:02.360 values and thresholds but we want to make sure we also understand what 63 04:02.360 --> 04:06.600 each one of these metrics means and so latency is just going to be the 64 04:06.600 --> 04:09.480 delay that it takes how long does it take a packet to 65 04:09.480 --> 04:13.480 get across to the other side and we have a difference between 66 04:13.480 --> 04:17.560 one-way latency as well as what we call round trip time so keep that in mind. 67 04:17.560 --> 04:21.400 Is it the amount of time it takes me to get to one side or is it the amount of 68 04:21.400 --> 04:25.080 time that it takes for the return traffic to get back. 69 04:25.080 --> 04:28.920 When I'm doing a ping from one device to another usually I'm looking at round 70 04:28.920 --> 04:32.600 trip time because I know the time that I sent the packet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 04:28.920 --> 04:32.600 trip time because I know the time that I sent the packet 71 04:32.600 --> 04:35.560 I know how long it took to get a response back. 72 04:35.560 --> 04:39.400 So when we're talking about latency with voice over IP in this threshold 73 04:39.400 --> 04:45.240 Cisco says we want a one-way latency of 150 milliseconds 74 04:45.240 --> 04:49.000 and as we talked about that's kind of interesting because if I do a ping 75 04:49.000 --> 04:54.120 and I see hey I've got a 250 millisecond round trip time we might say okay good 76 04:54.120 --> 04:58.520 so I divide that in half and we know that that's 125 milliseconds 77 04:58.520 --> 05:01.480 per way and therefore it looks like we hit that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 04:58.520 --> 05:01.480 per way and therefore it looks like we hit that. 78 05:01.480 --> 05:04.680 Except it's not always fair to say we're just going to divide 79 05:04.680 --> 05:09.240 that in half. This could get broken down so it's 160 milliseconds 80 05:09.240 --> 05:13.160 one way and 90 milliseconds coming back which means we did 81 05:13.160 --> 05:19.880 actually break the one-way recommendation from Cisco 82 05:19.880 --> 05:23.240 in that we exceeded 150 milliseconds so keep that in mind 83 05:23.240 --> 05:27.080 when we're doing real-world testing but Cisco does recommend a one-way 84 05:27.080 --> 05:31.800 latency of 150 milliseconds. Jitter is the difference WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 84 05:27.080 --> 05:31.800 latency of 150 milliseconds. Jitter is the difference 85 05:31.800 --> 05:36.760 between delay so if I have a latency of 100 milliseconds 86 05:36.760 --> 05:40.280 and then the next time I check I'm at 150 milliseconds 87 05:40.280 --> 05:45.480 well we've just increased by 50 milliseconds of delay and so that causes 88 05:45.480 --> 05:50.200 some well for lack of better words it causes jitter on the network 89 05:50.200 --> 05:54.280 and so we want to take the average of the differences as we're hopping up and 90 05:54.280 --> 05:59.960 down and up and down and Cisco wants us to keep jitter below 30 milliseconds. 91 05:59.960 --> 06:05.160 Yes jitter is measured by milliseconds and we did some math earlier WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 91 05:59.960 --> 06:05.160 Yes jitter is measured by milliseconds and we did some math earlier 92 06:05.160 --> 06:09.320 in this skill the describe quality of service skill to make sure we understand 93 06:09.320 --> 06:13.480 how that works but 30 milliseconds is the recommendation there 94 06:13.480 --> 06:17.720 for packet loss Cisco wants us to keep this below 1% packet loss for voice 95 06:17.720 --> 06:21.720 over IP traffic. Packet loss is simply how many packets 96 06:21.720 --> 06:25.320 of the hundred that I sent made it to the other side as long as 99 out of 100 97 06:25.320 --> 06:29.240 or making it that's great on local area networks that's usually not a 98 06:29.240 --> 06:32.360 problem when we go to wide area networks and VPNs WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 06:29.240 --> 06:32.360 problem when we go to wide area networks and VPNs 99 06:32.360 --> 06:36.440 packet loss can become a much bigger concern. 100 06:36.440 --> 06:39.880 All right question number three how many bits are used for each of these 101 06:39.880 --> 06:43.000 marking methods we absolutely must understand the 102 06:43.000 --> 06:47.240 difference between these marking methods. Class of service this exists at layer 103 06:47.240 --> 06:51.080 two it's going to be part not just part of the ethernet frame but 104 06:51.080 --> 06:58.120 specifically it's going to be part of that 802.1q or really 802.1p 105 06:58.120 --> 07:02.600 header because we're going to ride those existing WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 105 06:58.120 --> 07:02.600 header because we're going to ride those existing 106 07:02.600 --> 07:06.360 bits and bytes because the ethernet header only really had room for source 107 07:06.360 --> 07:11.400 and destination address as well as the ether type and therefore if we want to 108 07:11.400 --> 07:15.080 include a VLAN tag well then we need this additional 109 07:15.080 --> 07:18.840 header those four bytes and that's great in all except that's 110 07:18.840 --> 07:22.520 where we're going to put our class of service bits as well and specifically 111 07:22.520 --> 07:26.760 there are three bits in here two to the third power that means we have 112 07:26.760 --> 07:29.800 eight different values between zero and seven and 113 07:29.800 --> 07:34.920 importantly if I am sending my traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 113 07:29.800 --> 07:34.920 importantly if I am sending my traffic 114 07:34.920 --> 07:38.840 tagged via a trunk to the switch and then it 115 07:38.840 --> 07:42.520 fords that packet out an interface that's in access mode 116 07:42.520 --> 07:48.120 remember that my cos tag is officially lost in the same way that if a router 117 07:48.120 --> 07:51.640 were to take this in and send it out a non- 118 07:51.640 --> 07:55.480 ethernet serial line like a t1 or an e1. 119 07:55.480 --> 07:59.800 At that point I'm not running ethernet anymore and so I've lost the cos tag 120 07:59.800 --> 08:04.280 cos is specific to ethernet and specific to trunking WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 120 07:59.800 --> 08:04.280 cos is specific to ethernet and specific to trunking 121 08:04.280 --> 08:08.280 so it's useful in layer two environments and it gets heavily used it's not a 122 08:08.280 --> 08:10.600 legacy concept we need to understand how classes 123 08:10.600 --> 08:14.040 service works what is a legacy concept is 124 08:14.040 --> 08:18.600 IP precedence because as we draw the line in the sand and say this is layer two 125 08:18.600 --> 08:22.760 we do say you know we could use some layer three because layer three 126 08:22.760 --> 08:27.320 specifically ipv4 and ipv6 that lasts end to end 127 08:27.320 --> 08:31.000 it doesn't matter if i'm going across an access port or a trunk port i keep my WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 08:27.320 --> 08:31.000 it doesn't matter if i'm going across an access port or a trunk port i keep my 128 08:31.000 --> 08:35.400 ip header and i don't need any extra bits and bytes to make it happen like 129 08:35.400 --> 08:39.240 the ethernet header requires so it's just always there 130 08:39.240 --> 08:43.400 so ip precedence is what we started with this 131 08:43.400 --> 08:48.680 is also three bits and therefore ranges from zero to seven 132 08:48.680 --> 08:52.520 but eventually we decided as we explored that we needed more bits for 133 08:52.520 --> 08:55.560 that we wanted the ability to have a lot more 134 08:55.560 --> 08:59.080 what we call per-hop behaviors or phb's and 135 08:59.080 --> 09:04.200 be ability to define different traffic types and therefore dscp built on ip WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 135 08:59.080 --> 09:04.200 be ability to define different traffic types and therefore dscp built on ip 136 09:04.200 --> 09:08.440 precedence we took the ip precedence bits 137 09:08.440 --> 09:12.280 though that's not useful it there we go of three bits 138 09:12.280 --> 09:16.200 and then we added three more bits over here 139 09:16.200 --> 09:21.480 and the total amount or the total of six bits 140 09:21.480 --> 09:27.160 rather is known as dscp because we have six bits that's two to the sixth power 141 09:27.160 --> 09:31.880 that means we have from zero to 63 for a total of 64 values WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 141 09:27.160 --> 09:31.880 that means we have from zero to 63 for a total of 64 values 142 09:31.880 --> 09:34.840 so let's make sure again that we understand the difference in these 143 09:34.840 --> 09:37.960 different marking types especially when it comes to something like 144 09:37.960 --> 09:40.520 class of service and when it's used and when it's not 145 09:40.520 --> 09:44.760 as well as how dscp and ip precedence relate to one another within the ipv4 146 09:44.760 --> 09:49.800 and ipv6 headers well speaking of per-hop behaviors 147 09:49.800 --> 09:54.280 here is a question identify the phb that aligns with each of the following 148 09:54.280 --> 09:58.280 purposes so phb's what's going on here well we just 149 09:58.280 --> 10:02.760 said that dscp has values from zero to 63 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 149 09:58.280 --> 10:02.760 said that dscp has values from zero to 63 150 10:02.760 --> 10:07.320 and that's a whole lot of numbers from a human perspective having 64 different 151 10:07.320 --> 10:13.560 potential classes of traffic flow is number one a lot of traffic flows 152 10:13.560 --> 10:19.160 but number two if i have organization a here an organization b over here 153 10:19.160 --> 10:23.240 uh what am i using for critical traffic on this side and what am i 154 10:23.240 --> 10:26.920 using for critical traffic on that side voice over ip 155 10:26.920 --> 10:32.040 non-voice over ip and we could say well these two organizations don't have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 155 10:26.920 --> 10:32.040 non-voice over ip and we could say well these two organizations don't have 156 10:32.040 --> 10:35.640 networks between them and so it doesn't matter and that's not a bad argument to 157 10:35.640 --> 10:39.960 make except that we as it folks tend to 158 10:39.960 --> 10:44.840 move around from one organization to another we tend to be consultants that 159 10:44.840 --> 10:49.560 service multiple organizations and generally speaking having standards 160 10:49.560 --> 10:53.000 that we can all agree on is good for everyone involved 161 10:53.000 --> 10:57.400 so those standards resulted in us defining some per-hop behaviors we took 162 10:57.400 --> 11:03.160 some not all but some of these decimal values and we turn them into WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 162 10:57.400 --> 11:03.160 some not all but some of these decimal values and we turn them into 163 11:03.160 --> 11:07.560 per-hop behaviors things like class selector so we might have class 164 11:07.560 --> 11:11.720 selector five or something like that and then we have assured forwarding and 165 11:11.720 --> 11:14.440 we've got all kinds of assured forwarding values from 166 11:14.440 --> 11:21.080 you know 11 to 12 to 13 but then we also have 21 and 22 and 23 and then 167 11:21.080 --> 11:26.440 31 etc etc and then the big one that we talk about often is expedited 168 11:26.440 --> 11:30.440 forwarding which is going to be reserved for voice over ip WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 168 11:26.440 --> 11:30.440 forwarding which is going to be reserved for voice over ip 169 11:30.440 --> 11:34.760 specifically so let's take a look at our options down here so we're going to 170 11:34.760 --> 11:38.520 go through all of these first of all a per-hop behavior that matches with 171 11:38.520 --> 11:42.360 ip precedence three well this has to do with the fact 172 11:42.360 --> 11:48.040 i'll write this down here that ip precedence is those first three bits 173 11:48.040 --> 11:51.880 and then dscp uses another three bits over here 174 11:51.880 --> 11:57.080 so if we're going to only use ip precedence bits that means that 175 11:57.080 --> 12:02.040 means that these must all be set to zero and therefore we're only going to be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 175 11:57.080 --> 12:02.040 means that these must all be set to zero and therefore we're only going to be 176 12:02.040 --> 12:06.200 looking at if we say a three here three from a 177 12:06.200 --> 12:11.400 binary perspective is zero one zero that's i said that wrong it's zero one one 178 12:11.400 --> 12:16.600 there you go that's three so if ip precedence is zero one one 179 12:16.600 --> 12:21.160 we want a per-hop behavior that aligns with this and this is exactly what 180 12:21.160 --> 12:26.040 class selector is all about class selector is supposed to match 181 12:26.040 --> 12:31.320 when ip precedence bits are used and when these extra three bits are not WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 181 12:26.040 --> 12:31.320 when ip precedence bits are used and when these extra three bits are not 182 12:31.320 --> 12:37.080 used as part of our dscp so simply put ip precedence three 183 12:37.080 --> 12:40.840 here is going to match with class selector three so that would be our 184 12:40.840 --> 12:46.120 answer is class selector three be here and see are tied together it's the 185 12:46.120 --> 12:49.800 assured forwarding we're talking about priority versus drop percentage 186 12:49.800 --> 12:54.360 so when we recall having assured forwarding value of let's say 187 12:54.360 --> 13:00.040 twenty two this first value is the priority and the second WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 187 12:54.360 --> 13:00.040 twenty two this first value is the priority and the second 188 13:00.040 --> 13:05.960 is the drop likelihood we'll call it the drop percentage in this case 189 13:05.960 --> 13:10.280 so we want a high priority but we actually want a low 190 13:10.280 --> 13:14.920 drop priority which means that twenty one is actually better 191 13:14.920 --> 13:20.760 so to speak greater than something like twenty two or twenty four 192 13:20.760 --> 13:24.520 and the reason for this i don't know why it's a 24 there 193 13:24.520 --> 13:30.440 uh af 21 is better than 22 which is better than 23 there we go that makes WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 193 13:24.520 --> 13:30.440 uh af 21 is better than 22 which is better than 23 there we go that makes 194 13:30.440 --> 13:33.800 more sense why is that because 23 has the 195 13:33.800 --> 13:40.040 highest drop likelihood whereas 21 here that second number is the lowest 196 13:40.040 --> 13:47.160 drop likelihood yet if i have an af 31 this number here the higher the 197 13:47.160 --> 13:50.120 better so it's kind of weird the higher the better in the first one 198 13:50.120 --> 13:55.240 the lower the better in the second one so when you say the highest af priority 199 13:55.240 --> 14:00.280 the highest priority is going to be four we only have a range of one to four WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 199 13:55.240 --> 14:00.280 the highest priority is going to be four we only have a range of one to four 200 14:00.280 --> 14:03.880 for assured forwarding so the lowest in c here the 201 14:03.880 --> 14:08.520 lowest priority would be have a one there but we need two numbers and that's 202 14:08.520 --> 14:13.480 the the drop priority so the drop percentage so b here the lowest drop 203 14:13.480 --> 14:18.280 percentage would be a one so af 41 for b and then the highest drop 204 14:18.280 --> 14:22.680 percentage that ranges from one to three so that would be af 13 205 14:22.680 --> 14:26.280 and then lastly matches with voice over ip traffic that is always going to be 206 14:26.280 --> 14:26.440 our 207 14:26.440 --> 14:31.080 expedited forwarding value so understand how these phb's tied WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 207 14:26.440 --> 14:31.080 expedited forwarding value so understand how these phb's tied 208 14:31.080 --> 14:35.960 together and when we use each one all right question number five we're 209 14:35.960 --> 14:38.840 halfway done what are the decimal values that align to the 210 14:38.840 --> 14:44.040 following per hot behaviors so this is a whole conversation of making 211 14:44.040 --> 14:47.960 sure we can take these per hot behaviors these 212 14:47.960 --> 14:52.040 mix of letters and numbers and turn them into decimal values 213 14:52.040 --> 14:57.320 so with cs5 remember we're only using those first three bits and therefore 214 14:57.320 --> 15:00.840 is this a pretty straightforward class selector WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 214 14:57.320 --> 15:00.840 is this a pretty straightforward class selector 215 15:00.840 --> 15:05.560 is just an 8x multiplier and that has to do with the way the bits are aligned 216 15:05.560 --> 15:09.640 and we covered that but in the end when we have a question like this our focus 217 15:09.640 --> 15:12.920 is do we know the math as long as we know the math we can 218 15:12.920 --> 15:17.160 make this happen pretty simply because class selector five i just multiply it 219 15:17.160 --> 15:21.560 by eight and that is a decimal value of 40 pretty 220 15:21.560 --> 15:27.080 straightforward af 13 and 42 these are going to require a 221 15:27.080 --> 15:35.000 new equation which is that 8x plus 2y where x is the priority and y is the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 221 15:27.080 --> 15:35.000 new equation which is that 8x plus 2y where x is the priority and y is the 222 15:35.000 --> 15:39.640 drop so in other words if i have af 13 here it 223 15:39.640 --> 15:44.040 would be eight times one that'd be the first number 224 15:44.040 --> 15:48.440 plus two times three that'd be the second number 225 15:48.440 --> 15:53.000 and the reason why this equation works once again same as class selector has 226 15:53.000 --> 15:57.320 to do with where the bits are aligned within the header and we talked about 227 15:57.320 --> 16:02.840 that early on so this is eight this is six so this would be a value of 14 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 227 15:57.320 --> 16:02.840 that early on so this is eight this is six so this would be a value of 14 228 16:02.840 --> 16:06.920 don't allow ourselves to get mixed up with the fact that yeah 13 is 14 229 16:06.920 --> 16:11.320 or anything like that that's just coincidence sometimes they end up 230 16:11.320 --> 16:13.320 being the same number sometimes they're off 231 16:13.320 --> 16:18.360 just a little bit but this is just a you know almost like a name that we're 232 16:18.360 --> 16:21.720 giving it and this is the actual decimal value 233 16:21.720 --> 16:26.200 based on the binary bits so same equation here we're going to do 234 16:26.200 --> 16:33.960 eight this time times four and then this is two so two times two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 234 16:26.200 --> 16:33.960 eight this time times four and then this is two so two times two 235 16:33.960 --> 16:39.960 and so that's 32 and this is four 32 plus four is 36 236 16:39.960 --> 16:44.040 lastly expedited forwarding doesn't give us any numbers or equations which is 237 16:44.040 --> 16:47.240 kind of nice but it does require us to memorize it 238 16:47.240 --> 16:51.960 and simply put expedited forwarding is a decimal value of 46 239 16:51.960 --> 16:56.040 so always keep in mind how exactly to do this remember 240 16:56.040 --> 16:59.320 these two equations can be very instrumental in performing these 241 16:59.320 --> 17:03.160 decimal conversions all right next question how are WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 241 16:59.320 --> 17:03.160 decimal conversions all right next question how are 242 17:03.160 --> 17:06.680 packets classified when using weighted fair queuing 243 17:06.680 --> 17:11.400 choose two so weighted fair queuing was an early adopt or early 244 17:11.400 --> 17:14.440 queuing method that sesco came up with and it's something we still can use 245 17:14.440 --> 17:17.400 today in modern networks especially within 246 17:17.400 --> 17:22.280 cb wfqq's so let's not get this mixed up sisco has class based 247 17:22.280 --> 17:27.080 weighted fair queuing and this is what we use that mqc 248 17:27.080 --> 17:31.480 iosac configuration for we configure all of our cues we can configure WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 248 17:27.080 --> 17:31.480 iosac configuration for we configure all of our cues we can configure 249 17:31.480 --> 17:36.040 a low latency queue all of this is how we do the class 250 17:36.040 --> 17:40.840 class maps and policy maps etc but when we talk about weighted fair queuing 251 17:40.840 --> 17:44.040 weighted fair queuing is a much more automated 252 17:44.040 --> 17:48.520 method for performing queuing and servicing of packets 253 17:48.520 --> 17:51.800 it's automated based on two parameters first of all 254 17:51.800 --> 17:55.560 it's going to be looking at the packet size 255 17:55.560 --> 17:59.320 that's important because we're going to have the ability to put 256 17:59.320 --> 18:03.080 small packets into more higher priority queues WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 256 17:59.320 --> 18:03.080 small packets into more higher priority queues 257 18:03.080 --> 18:06.040 and the primary reason for this is because voiceover ip 258 18:06.040 --> 18:10.040 is very small packet sizes the other thing we're going to take a look at 259 18:10.040 --> 18:14.520 is the traffic flow and truly what happens here is we sort of have this 260 18:14.520 --> 18:18.040 dividing line in the sand where you have small and large packets 261 18:18.040 --> 18:23.640 and then the sesco device is just going to observe a traffic flow and place 262 18:23.640 --> 18:29.000 each flow into its own queue within one of these 263 18:29.000 --> 18:32.600 areas or regions if you want to call it that so the small packets are going to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 263 18:29.000 --> 18:32.600 areas or regions if you want to call it that so the small packets are going to 264 18:32.600 --> 18:33.160 be 265 18:33.160 --> 18:37.080 serviced at a greater rate than the large packets but again the beautiful 266 18:37.080 --> 18:39.880 thing about this is i as the administrator 267 18:39.880 --> 18:43.320 it can just rely on the automated nature of identifying things 268 18:43.320 --> 18:47.720 by traffic flow as well as packet size 269 18:47.720 --> 18:52.040 all right interesting question here uh we've got an llq that low latency queue 270 18:52.040 --> 18:56.920 it's been configured on an interface and 10% of the link bandwidth is reserved 271 18:56.920 --> 19:01.240 that's an important part of all of this an llq packet is arrives is probably a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 271 18:56.920 --> 19:01.240 that's an important part of all of this an llq packet is arrives is probably a 272 19:01.240 --> 19:04.840 voiceover ip packet and the link is congested 273 19:04.840 --> 19:09.880 in what situation will the packet be sent over packets in the other 274 19:09.880 --> 19:13.880 queues so our temptation here might be to say oh 275 19:13.880 --> 19:18.920 the low latency queue this is a strict priority packet and therefore it'll 276 19:18.920 --> 19:22.280 always get sent out but here's the question is it 277 19:22.280 --> 19:26.440 a strict priority queue strict priority says i don't care 278 19:26.440 --> 19:30.600 about any kind of limits i'm just going to send a packet WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 278 19:26.440 --> 19:30.600 about any kind of limits i'm just going to send a packet 279 19:30.600 --> 19:34.600 that any packet that lands in the strict priority queue i'm going to send it 280 19:34.600 --> 19:38.440 ahead of other queues which risks starving those other queues 281 19:38.440 --> 19:41.880 well llq is designed to get around this and as a result 282 19:41.880 --> 19:47.480 we can deploy this with strict priority however if we add 283 19:47.480 --> 19:52.360 a reservation to a low latency queue that reservation 284 19:52.360 --> 19:56.120 actually becomes a restriction and as a result in our case 285 19:56.120 --> 20:01.160 it's not a strict priority queue so in what situation will the packet be WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 285 19:56.120 --> 20:01.160 it's not a strict priority queue so in what situation will the packet be 286 20:01.160 --> 20:04.760 sent over packets in the other queues it's going to be 287 20:04.760 --> 20:10.520 c it depends on the bandwidth consumption because if we've hit our 10% of link 288 20:10.520 --> 20:13.720 bandwidth then we're not going to send that packet ahead of the other ones 289 20:13.720 --> 20:20.280 even though it's in the llq but if it has not consumed 10% then it will be sent 290 20:20.280 --> 20:23.160 out immediately ahead of the other queues so 291 20:23.160 --> 20:28.200 little in cq attempts to find a balance between the concept of the strict 292 20:28.200 --> 20:31.880 priority queue but also not just treat voice over IP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 292 20:28.200 --> 20:31.880 priority queue but also not just treat voice over IP 293 20:31.880 --> 20:37.240 packets as any other packet all right last question here what does 294 20:37.240 --> 20:43.080 weighted random early detect consider that random early detect does not 295 20:43.080 --> 20:48.760 so yeah we probably call this w red or red i know w's are sometimes silent in 296 20:48.760 --> 20:51.960 front of an r so we can't just call it red and red but 297 20:51.960 --> 20:57.000 either way the answer here is going to be the packet tag 298 20:57.000 --> 21:01.640 weighted random early detect is weighted meaning that i can look at the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 298 20:57.000 --> 21:01.640 weighted random early detect is weighted meaning that i can look at the 299 21:01.640 --> 21:05.880 the tag of a packet and random early detect doesn't actually 300 21:05.880 --> 21:10.040 do that uh both are very useful they both aim to 301 21:10.040 --> 21:13.720 accomplish something similar but weighted random early detect just has that 302 21:13.720 --> 21:18.200 better capability as far as being able to prioritize certain packets over 303 21:18.200 --> 21:21.000 others within the same queue