WEBVTT 1 00:00.000 --> 00:07.500 So now that we've created our policy maps, the policy map is going to establish 2 00:07.500 --> 00:07.840 a set 3 00:07.840 --> 00:11.800 of cues that will be mapped to a particular interface. 4 00:11.800 --> 00:16.320 In our situation here, let's say that we've got four different cues. 5 00:16.320 --> 00:22.000 And we know that we can map one of these cues to be a priority cue. 6 00:22.000 --> 00:27.360 And believe it or not, we can actually map a second one of these if we so 7 00:27.360 --> 00:28.320 desire. 8 00:28.320 --> 00:32.510 Now where we want to go with this conversation is talking about our bandwidth WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 8 00:28.320 --> 00:32.510 Now where we want to go with this conversation is talking about our bandwidth 9 00:32.510 --> 00:33.760 reservations. 10 00:33.760 --> 00:38.230 But in order to talk about reserving bandwidth and locking that down for 11 00:38.230 --> 00:39.520 different cues, we've 12 00:39.520 --> 00:42.780 got a lot of different ways of doing that, but we need to establish how many 13 00:42.780 --> 00:43.320 priority 14 00:43.320 --> 00:44.720 cues we have. 15 00:44.720 --> 00:47.360 We can have zero priority cues. 16 00:47.360 --> 00:48.960 We can have one priority cue. 17 00:48.960 --> 00:52.000 This is known as the low latency cue at that point. 18 00:52.000 --> 00:57.080 Or we can even have shared multi-level priority cues. 19 00:57.080 --> 01:02.050 The way this works, if we do multi-level, is we're going to establish two WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:57.080 --> 01:02.050 The way this works, if we do multi-level, is we're going to establish two 20 01:02.050 --> 01:03.400 different priority 21 01:03.400 --> 01:11.560 cues and we are going to configure them for either level one or level two. 22 01:11.560 --> 01:15.000 And what we're doing here is we're establishing a level of hierarchy. 23 01:15.000 --> 01:19.020 In other words, yeah, both of these are technically priority cues and then we 24 01:19.020 --> 01:19.840 have all of the 25 01:19.840 --> 01:23.000 non-priority cues down here. 26 01:23.000 --> 01:27.700 However, if there are packets at the level one cue, then they will take 27 01:27.700 --> 01:28.640 priority over 28 01:28.640 --> 01:30.200 level two. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 28 01:28.640 --> 01:30.200 level two. 29 01:30.200 --> 01:32.730 In the real world, generally what we're going to do here is we're going to 30 01:32.730 --> 01:33.560 place voiceover 31 01:33.560 --> 01:39.560 IP at the level one priority and then maybe video traffic or some other mission 32 01:39.560 --> 01:40.400 critical 33 01:40.400 --> 01:42.760 traffic at level two. 34 01:42.760 --> 01:48.470 Because voiceover IP is very small packets, we really want these to get going, 35 01:48.470 --> 01:49.120 to throw 36 01:49.120 --> 01:52.040 them at the front of the cue and to get them out the gate. 37 01:52.040 --> 01:56.760 We do not want them waiting behind something that is much larger. 38 01:56.760 --> 02:00.540 Like a video packet that might be a thousand bytes or even up to fifteen WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 01:56.760 --> 02:00.540 Like a video packet that might be a thousand bytes or even up to fifteen 39 02:00.540 --> 02:01.960 hundred bytes, 40 02:01.960 --> 02:06.850 voiceover IP packets really don't want to have to wait for that entire large 41 02:06.850 --> 02:07.440 packet 42 02:07.440 --> 02:09.320 to be transmitted. 43 02:09.320 --> 02:14.610 So in our configuration, we can set not just a priority status, but we can also 44 02:14.610 --> 02:15.200 set the 45 02:15.200 --> 02:17.160 level of priority. 46 02:17.160 --> 02:20.830 And if we have two priority cues, then we'd want to absolutely make sure that 47 02:20.830 --> 02:21.400 we build 48 02:21.400 --> 02:25.040 level one and level two appropriately. 49 02:25.040 --> 02:30.760 Now from here, again, we want to be able to talk about bandwidth reservations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 49 02:25.040 --> 02:30.760 Now from here, again, we want to be able to talk about bandwidth reservations. 50 02:30.760 --> 02:38.050 One of the primary benefits of this model is that we can customize fully the 51 02:38.050 --> 02:38.920 cueing, 52 02:38.920 --> 02:41.920 not only from a classification perspective. 53 02:41.920 --> 02:45.400 Remember I can classify my traffic usually based on tags. 54 02:45.400 --> 02:50.540 Again, we've got other options that we explored, but I would assign maybe my EF 55 02:50.540 --> 02:51.320 tags up here 56 02:51.320 --> 02:55.200 my AF4X packets in here. 57 02:55.200 --> 02:58.360 Down here, this would be my class default. 58 02:58.360 --> 03:00.400 And so this would be the catch all. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 58 02:58.360 --> 03:00.400 And so this would be the catch all. 59 03:00.400 --> 03:03.810 And then maybe I have that third cue where, I mean, whatever I'm using in my 60 03:03.810 --> 03:04.760 organization, 61 03:04.760 --> 03:09.550 maybe I put three X and two X traffic in here for assured forwarding, something 62 03:09.550 --> 03:10.240 along those 63 03:10.240 --> 03:11.880 lines. 64 03:11.880 --> 03:16.710 But now I want to be able to place bandwidth reservations and for that matter 65 03:16.710 --> 03:17.320 bandwidth 66 03:17.320 --> 03:21.000 limits for my priority cues. 67 03:21.000 --> 03:25.560 Because in times of congestion, I don't want to send all of my voice and video 68 03:25.560 --> 03:26.160 traffic 69 03:26.160 --> 03:30.480 at the expense of these other cues and never send anything out. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 69 03:26.160 --> 03:30.480 at the expense of these other cues and never send anything out. 70 03:30.480 --> 03:33.750 And so at this point, we're going to use a series of commands, a set of 71 03:33.750 --> 03:34.440 commands in 72 03:34.440 --> 03:37.280 order to perform our bandwidth reservations. 73 03:37.280 --> 03:39.400 Now we already took a look at this briefly. 74 03:39.400 --> 03:44.820 For example, we've got the priority cue or priority command rather that defines 75 03:44.820 --> 03:45.600 the bandwidth 76 03:45.600 --> 03:49.880 we're reserving or really limiting for the priority cue. 77 03:49.880 --> 03:54.800 And then we also have the bandwidth statement. 78 03:54.800 --> 04:01.790 Now when we're specifying a raw value here, we are going to specify this in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 78 03:54.800 --> 04:01.790 Now when we're specifying a raw value here, we are going to specify this in 79 04:01.790 --> 04:02.680 terms of 80 04:02.680 --> 04:04.680 kilobits per second. 81 04:04.680 --> 04:09.080 So I might say 100 kilobits per second for the priority cue. 82 04:09.080 --> 04:13.760 And then for the other cues, maybe I say 25 megabits per second. 83 04:13.760 --> 04:18.410 So I could say like 25,000 in order to define the bandwidth reservation for the 84 04:18.410 --> 04:19.840 other cues. 85 04:19.840 --> 04:23.420 And a lot of our configurations, this is how we're going to find that we 86 04:23.420 --> 04:24.080 perform these 87 04:24.080 --> 04:25.240 configurations. 88 04:25.240 --> 04:26.760 And that's perfectly fine. 89 04:26.760 --> 04:31.380 However, keep in mind that when we're using these raw numbers, it's up to us to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 04:26.760 --> 04:31.380 However, keep in mind that when we're using these raw numbers, it's up to us to 90 04:31.380 --> 04:31.800 do the 91 04:31.800 --> 04:33.360 right math. 92 04:33.360 --> 04:38.180 Now the class default at the bottom, maybe we can use that as sort of that 93 04:38.180 --> 04:38.920 catch all 94 04:38.920 --> 04:44.000 to say we're going to put all of the rest of the bandwidth into that bucket. 95 04:44.000 --> 04:46.000 But we don't have to necessarily do that. 96 04:46.000 --> 04:50.570 Each one of these cues is going to get its own bandwidth reservation and we can 97 04:50.570 --> 04:51.120 put that 98 04:51.120 --> 04:53.000 into class default. 99 04:53.000 --> 04:57.120 And so we might end up reserving, let's say, I don't know, by mistake, we 100 04:57.120 --> 04:58.600 reserve 90 megabits 101 04:58.600 --> 05:03.400 per second out of the 100 megabits per second on the link. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 101 04:58.600 --> 05:03.400 per second out of the 100 megabits per second on the link. 102 05:03.400 --> 05:07.480 And so we are responsible ourselves for doing all the math again, making sure 103 05:07.480 --> 05:08.280 this all adds 104 05:08.280 --> 05:10.040 up appropriately. 105 05:10.040 --> 05:14.160 So in the real world, again, we might see a lot of this. 106 05:14.160 --> 05:19.370 But generally speaking, we might also see us change our method over to be using 107 05:19.370 --> 05:19.760 more 108 05:19.760 --> 05:25.720 of a percentage based methodology. 109 05:25.720 --> 05:29.440 Now there are two ways to perform percentage reservations. 110 05:29.440 --> 05:37.400 One is just again a raw percentage now where I have a total bandwidth of 100%. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 110 05:29.440 --> 05:37.400 One is just again a raw percentage now where I have a total bandwidth of 100%. 111 05:37.400 --> 05:42.380 And so I would say, hey, I want to use my priority queue and I want to reserve 112 05:42.380 --> 05:43.760 10%. 113 05:43.760 --> 05:49.720 So I would specify for my other cues the bandwidth command, but now I'm 114 05:49.720 --> 05:50.840 specifying a 115 05:50.840 --> 05:51.920 percent. 116 05:51.920 --> 05:54.880 So I could say like 35% for one queue. 117 05:54.880 --> 05:57.160 And then we've got two other cues up here. 118 05:57.160 --> 06:01.960 So maybe we do like a 40% and then a 15%. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 05:57.160 --> 06:01.960 So maybe we do like a 40% and then a 15%. 119 06:01.960 --> 06:04.080 And I think that adds up to a hundred 75. 120 06:04.080 --> 06:05.960 Yeah, that looks like a hundred percent. 121 06:05.960 --> 06:08.440 So this would be a valid configuration. 122 06:08.440 --> 06:12.760 But again, we're responsible for making sure that it adds up to a hundred. 123 06:12.760 --> 06:16.320 So ideally, this is supposed to add up to a hundred percent. 124 06:16.320 --> 06:19.520 And if we don't allocate bandwidth or we don't reserve bandwidth, then that 125 06:19.520 --> 06:20.040 bandwidth 126 06:20.040 --> 06:23.040 just goes on reserved. 127 06:23.040 --> 06:31.420 So the other option that we have available to us is a remaining percent command WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 06:23.040 --> 06:31.420 So the other option that we have available to us is a remaining percent command 128 06:31.420 --> 06:31.640 . 129 06:31.640 --> 06:34.120 And this is an interesting concept. 130 06:34.120 --> 06:41.760 So now I could say, hey, I want to use not 25 or 35% bandwidth. 131 06:41.760 --> 06:51.120 And maybe I want to say bandwidth remaining and then 25%. 132 06:51.120 --> 06:53.360 So what are we talking about here? 133 06:53.360 --> 06:56.080 What is remaining percentage? 134 06:56.080 --> 07:04.780 Well, the remaining percentage is going to remove the priority statements from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 134 06:56.080 --> 07:04.780 Well, the remaining percentage is going to remove the priority statements from 135 07:04.780 --> 07:06.440 the bandwidth 136 07:06.440 --> 07:10.960 reserve or reserved from the priority queue, which is kind of interesting. 137 07:10.960 --> 07:15.600 So let's say again, I have a hundred megabit per second link. 138 07:15.600 --> 07:20.670 And I could now say, hey, for my priority queue, I want to reserve 10 megabits 139 07:20.670 --> 07:21.400 per second. 140 07:21.400 --> 07:24.240 So that'd be 10,000 kilobits per second. 141 07:24.240 --> 07:26.520 So this is 10 meg. 142 07:26.520 --> 07:28.080 So how much is left? 143 07:28.080 --> 07:34.680 Well, after the 10 meg, there's going to be 90 remaining or 90 meg left. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 143 07:28.080 --> 07:34.680 Well, after the 10 meg, there's going to be 90 remaining or 90 meg left. 144 07:34.680 --> 07:40.840 So now I can divide that 90 up among the rest of the queues down here. 145 07:40.840 --> 07:45.220 And now I can see a little bit more clearly that maybe each one is supposed to 146 07:45.220 --> 07:46.120 get 25% 147 07:46.120 --> 07:49.060 of the remaining bandwidth. 148 07:49.060 --> 07:53.240 So I could do that type of configuration where this adds up to 100%. 149 07:53.240 --> 07:58.200 Even though we have a priority statement that references a hard bandwidth 150 07:58.200 --> 07:59.040 amount. 151 07:59.040 --> 08:04.020 So these are some configurations that we can use to divide up the bandwidth in WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 151 07:59.040 --> 08:04.020 So these are some configurations that we can use to divide up the bandwidth in 152 08:04.020 --> 08:04.760 a way that 153 08:04.760 --> 08:11.000 makes it so that we have as much control over the bandwidth reservations as 154 08:11.000 --> 08:12.200 possible. 155 08:12.200 --> 08:20.280 Now one last option I'll mention here briefly is we can also use a ratio. 156 08:20.280 --> 08:24.570 This is kind of fun because rather than using percentages and kilobits per 157 08:24.570 --> 08:26.120 second measurements, 158 08:26.120 --> 08:30.820 now I can actually do a ratio among my queues. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 158 08:26.120 --> 08:30.820 now I can actually do a ratio among my queues. 159 08:30.820 --> 08:36.630 So for example, if I have my three queues and I set a ratio of 2 to 1 to 1, 160 08:36.630 --> 08:37.440 well now 161 08:37.440 --> 08:42.050 this queue is going to get twice as much traffic as these other queues for 162 08:42.050 --> 08:43.040 every 1 kilobits 163 08:43.040 --> 08:45.880 per second that these queues are reserved. 164 08:45.880 --> 08:50.600 This queue gets 2 kilobits per second in that ratio order. 165 08:50.600 --> 08:56.600 Meanwhile I could also make a queuing ratio of 4 to 1, 1 for 4 different queues 166 08:56.600 --> 08:56.680 . 167 08:56.680 --> 09:02.270 So now for every 1 kilobit per second of reservation these lower end queues get WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 08:56.680 --> 09:02.270 So now for every 1 kilobit per second of reservation these lower end queues get 168 09:02.270 --> 09:02.520 , this 169 09:02.520 --> 09:06.750 queue gets 2 kilobits per second and this more important, I assume, more 170 09:06.750 --> 09:08.120 important queue 171 09:08.120 --> 09:10.600 gets 4 kilobits per second. 172 09:10.600 --> 09:15.290 So setting this as a ratio is certainly an option as well and if we don't want 173 09:15.290 --> 09:15.640 to mess 174 09:15.640 --> 09:19.990 with percentages and we don't want to mess with hard kilobit per second 175 09:19.990 --> 09:20.760 reservations 176 09:20.760 --> 09:23.360 then maybe a ratio is a good way to go. 177 09:23.360 --> 09:27.040 But as we see here, Cisco gives us lots of options for the configuration of our 178 09:27.040 --> 09:27.640 bandwidth 179 09:27.640 --> 09:32.770 reservations and keep in mind that we do need to define our priority queues as WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 09:27.640 --> 09:32.770 reservations and keep in mind that we do need to define our priority queues as 180 09:32.770 --> 09:33.800 part of this 181 09:33.800 --> 09:38.310 because that's going to tie into any kind of bandwidth percentage remaining 182 09:38.310 --> 09:39.280 configuration 183 09:39.280 --> 09:45.360 and it's also going to turn our bandwidth reservations into hard limits in the 184 09:45.360 --> 09:45.920 event 185 09:45.920 --> 09:51.710 that our link is saturated because we don't want to cause starvation of the 186 09:51.710 --> 09:52.400 other queues.