WEBVTT 1 00:00.000 --> 00:04.160 Well, we've brought up a couple of situations that we really need to address. 2 00:04.160 --> 00:08.730 So let's say we have this wireless station and it sends a voiceover IP frame 3 00:08.730 --> 00:09.280 and it sends 4 00:09.280 --> 00:11.400 that frame with a user priority of six. 5 00:11.400 --> 00:16.550 Well, we know once that's received by the access point that it's going to see 6 00:16.550 --> 00:17.240 this user 7 00:17.240 --> 00:22.840 priority of six and translate this over to a DSCP value of, well, we multiply 8 00:22.840 --> 00:23.280 it by 9 00:23.280 --> 00:29.840 eight and it's 48, which is not a good value for our wired network on top of 10 00:29.840 --> 00:30.760 the fact it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:29.840 --> 00:30.760 the fact it's 11 00:30.760 --> 00:33.760 just not the right value for voiceover IP in general. 12 00:33.760 --> 00:39.000 We also have the problem of it just being the situation where we're dishonest. 13 00:39.000 --> 00:44.090 We say, hey, I'm going to send all of my traffic with a user priority of six 14 00:44.090 --> 00:44.960 and that lands 15 00:44.960 --> 00:49.280 on the wired network with a very, very high priority level. 16 00:49.280 --> 00:52.640 So either way we need to address this problem. 17 00:52.640 --> 00:56.040 And so we've got a couple of options that we've mentioned one of them, which is 18 00:56.040 --> 00:56.920 to simply 19 00:56.920 --> 01:00.200 trust the DSCP tag. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 19 00:56.920 --> 01:00.200 trust the DSCP tag. 20 01:00.200 --> 01:04.500 Now this works well for the voiceover IP side of things because when the voice 21 01:04.500 --> 01:05.400 over IP packet 22 01:05.400 --> 01:12.110 is sent, it's going to be sent with a DSCP value that's correct of EF, which is 23 01:12.110 --> 01:13.160 46. 24 01:13.160 --> 01:15.920 But it doesn't help us with the second problem, which is that our wireless 25 01:15.920 --> 01:16.560 stations might 26 01:16.560 --> 01:21.230 be dishonest in sending a DSCP value that, you know, maybe now they're sending 27 01:21.230 --> 01:21.440 all of 28 01:21.440 --> 01:24.280 their bulk traffic with a DSCP of 46. 29 01:24.280 --> 01:28.520 That would really wreck havoc on our voiceover IP network traffic. 30 01:28.520 --> 01:30.600 So that is one solution. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 30 01:28.520 --> 01:30.600 So that is one solution. 31 01:30.600 --> 01:37.920 The other solution is to going to be to use a couple of Cisco catalyst policies 32 01:37.920 --> 01:38.280 that 33 01:38.280 --> 01:44.440 are going to allow us to restrict which DSCP values can end up resulting from a 34 01:44.440 --> 01:45.520 particular 35 01:45.520 --> 01:47.360 communication. 36 01:47.360 --> 01:54.680 So this is going to involve what we call Cisco's precious metals policies or 37 01:54.680 --> 01:56.120 precious metal 38 01:56.120 --> 01:58.120 policies. 39 01:58.120 --> 02:01.880 And sometimes it's just referred to as metal policies as well. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 01:58.120 --> 02:01.880 And sometimes it's just referred to as metal policies as well. 40 02:01.880 --> 02:05.160 So regardless, what are we talking about here? 41 02:05.160 --> 02:08.870 Well, Cisco wireless LAN controllers, they want to simplify our QoS 42 02:08.870 --> 02:10.480 configuration through 43 02:10.480 --> 02:13.200 some important preset policies. 44 02:13.200 --> 02:19.060 So these are preset pre-established on our wireless LAN controllers, which help 45 02:19.060 --> 02:19.400 us to 46 02:19.400 --> 02:21.520 manage our wireless network. 47 02:21.520 --> 02:27.210 And interestingly, they take the form of MQC policies at least on our iOS XE 48 02:27.210 --> 02:29.080 platforms. 49 02:29.080 --> 02:32.640 Cisco wireless LAN controllers have evolved in recent times. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 49 02:29.080 --> 02:32.640 Cisco wireless LAN controllers have evolved in recent times. 50 02:32.640 --> 02:35.920 They're no longer the old arrow, S piece of hardware. 51 02:35.920 --> 02:38.200 Instead they run iOS XE software. 52 02:38.200 --> 02:43.570 And if we're running one of those new catalyst 9800 wireless LAN controllers 53 02:43.570 --> 02:44.400 running iOS 54 02:44.400 --> 02:49.720 XE, we will see in the configuration that they show up as MQC policies, the 55 02:49.720 --> 02:50.600 same types 56 02:50.600 --> 02:57.280 of policies we just looked at with class maps and policy maps and all of that. 57 02:57.280 --> 03:00.450 Now an important question here is why are we calling this a precious metal WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 57 02:57.280 --> 03:00.450 Now an important question here is why are we calling this a precious metal 58 03:00.450 --> 03:00.880 policy or 59 03:00.880 --> 03:02.720 just a metal policy? 60 03:02.720 --> 03:11.410 And that is because these policies take the form of either a bronze policy, 61 03:11.410 --> 03:14.480 silver, gold, 62 03:14.480 --> 03:15.480 or platinum. 63 03:15.480 --> 03:20.040 So there's four different policies and they all take the form and name of one 64 03:20.040 --> 03:20.640 of these 65 03:20.640 --> 03:23.600 precious metals. 66 03:23.600 --> 03:26.500 What we're going to do is we're going to take one of these policies and we're 67 03:26.500 --> 03:28.160 going to apply 68 03:28.160 --> 03:34.160 one of them to our SSID's. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 68 03:28.160 --> 03:34.160 one of them to our SSID's. 69 03:34.160 --> 03:38.640 Now the SSID represents the wireless network on a wireless LAN controller. 70 03:38.640 --> 03:43.690 This is part of a WLAN configuration, which is when we're using our wireless 71 03:43.690 --> 03:44.560 devices over 72 03:44.560 --> 03:46.400 here to communicate to the access point. 73 03:46.400 --> 03:50.790 If I want to join a wireless network, I'm going to look for the SSID that's 74 03:50.790 --> 03:51.720 appropriate 75 03:51.720 --> 03:54.400 and then authenticate and join the network. 76 03:54.400 --> 03:58.760 And so if I have lots of different devices or lots of different SSID's, that is 77 03:58.760 --> 03:59.520 certainly 78 03:59.520 --> 04:00.520 possible. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 78 03:59.520 --> 04:00.520 possible. 79 04:00.520 --> 04:05.920 I could have an access point and I use one SSID to communicate with my laptops 80 04:05.920 --> 04:06.440 and my 81 04:06.440 --> 04:08.160 tablets and things like that. 82 04:08.160 --> 04:14.500 I can have another SSID that I use to map to the wireless phones that exist in 83 04:14.500 --> 04:15.920 my network. 84 04:15.920 --> 04:19.480 So as we might imagine, we want to absolutely enable high prioritization of 85 04:19.480 --> 04:20.240 traffic on one 86 04:20.240 --> 04:22.760 side and maybe not on the other. 87 04:22.760 --> 04:27.500 In a mind that some of these mobile devices might actually have voice over IP 88 04:27.500 --> 04:28.520 capabilities. 89 04:28.520 --> 04:32.890 We might be using soft phones that run on these devices so that can definitely WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 89 04:28.520 --> 04:32.890 We might be using soft phones that run on these devices so that can definitely 90 04:32.890 --> 04:33.280 get a 91 04:33.280 --> 04:34.960 little bit tricky. 92 04:34.960 --> 04:38.480 So let's break these down and we'll see very quickly what their purpose is. 93 04:38.480 --> 04:42.760 If we're looking at the platinum policy, this is going to be used when there's 94 04:42.760 --> 04:43.200 voice 95 04:43.200 --> 04:47.320 over IP packets present. 96 04:47.320 --> 04:54.790 And what it does is it actually maps user priority six and seven to our DSCP of 97 04:54.790 --> 04:55.480 EF. 98 04:55.480 --> 05:00.330 So as that user priority traffic is coming in, it's going to be mapped not to D WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 98 04:55.480 --> 05:00.330 So as that user priority traffic is coming in, it's going to be mapped not to D 99 05:00.330 --> 05:01.120 SCP 48 100 05:01.120 --> 05:04.200 anymore, but to DSCP 46. 101 05:04.200 --> 05:07.860 And for that matter, even use a priority seven, which would have gone to 56, 102 05:07.860 --> 05:08.720 that is now getting 103 05:08.720 --> 05:10.400 mapped properly as well. 104 05:10.400 --> 05:11.640 So that's pretty cool. 105 05:11.640 --> 05:18.350 It also allows video traffic to get mapped to a 41, which is the highest 106 05:18.350 --> 05:19.440 priority of 107 05:19.440 --> 05:23.720 assured forwarding, as we recall, with the lowest chance of getting dropped. 108 05:23.720 --> 05:26.880 So that is what platinum policy allows for. 109 05:26.880 --> 05:29.950 And it basically, when we're looking at these policies, we're going to find 110 05:29.950 --> 05:30.600 that it's really WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 110 05:29.950 --> 05:30.600 that it's really 111 05:30.600 --> 05:32.840 more about what it allows. 112 05:32.840 --> 05:39.730 These different policies are going to allow for different types of traffic to 113 05:39.730 --> 05:40.640 exist. 114 05:40.640 --> 05:43.480 So that's the question is, what are they going to allow? 115 05:43.480 --> 05:46.800 So next up, we have our gold policy. 116 05:46.800 --> 05:53.290 And the gold policy is when we don't have real time services or real time 117 05:53.290 --> 05:54.480 traffic. 118 05:54.480 --> 05:59.920 So this is both voice over IP and video conferencing. 119 05:59.920 --> 06:04.400 Now there's a big difference between video streaming and video conferencing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 119 05:59.920 --> 06:04.400 Now there's a big difference between video streaming and video conferencing. 120 06:04.400 --> 06:09.630 Video conferencing, when we're talking about video here, video conferencing is 121 06:09.630 --> 06:10.480 real time. 122 06:10.480 --> 06:14.770 It's communicating back and forth between two different users, maybe one's on a 123 06:14.770 --> 06:15.240 mobile 124 06:15.240 --> 06:17.200 device, one's on a PC. 125 06:17.200 --> 06:21.560 Regardless of what the situation is, we understand that's real time traffic. 126 06:21.560 --> 06:26.320 And that's going to be important because video conferencing falls into platinum 127 06:26.320 --> 06:26.400 . 128 06:26.400 --> 06:29.280 But then there's video streaming. 129 06:29.280 --> 06:32.040 And video streaming is not real time. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 129 06:29.280 --> 06:32.040 And video streaming is not real time. 130 06:32.040 --> 06:38.060 It involves a server pushing one way down to a PC or a mobile device or just 131 06:38.060 --> 06:38.960 some sort 132 06:38.960 --> 06:40.440 of end user. 133 06:40.440 --> 06:41.960 This is not real time. 134 06:41.960 --> 06:45.880 And therefore we don't need to map it here. 135 06:45.880 --> 06:49.200 But rather we need to map it down here. 136 06:49.200 --> 06:52.620 And so always keep in mind what we're talking about when we say video, we're 137 06:52.620 --> 06:53.320 talking about 138 06:53.320 --> 06:56.640 video conferencing, not video streaming. 139 06:56.640 --> 06:58.760 Video streaming has buffering. 140 06:58.760 --> 07:02.960 We've got all kinds of mechanisms for handling network delays that video conf WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 140 06:58.760 --> 07:02.960 We've got all kinds of mechanisms for handling network delays that video conf 141 07:02.960 --> 07:03.840 erencing can't 142 07:03.840 --> 07:04.840 take advantage of. 143 07:04.840 --> 07:08.640 So with gold, we're not talking about real time voice or video. 144 07:08.640 --> 07:15.920 However, when we're talking about video streaming, that's going to get tagged 145 07:15.920 --> 07:18.000 to AF 41. 146 07:18.000 --> 07:22.450 And this is the max value, meaning if we have these dishonest stations and they 147 07:22.450 --> 07:23.120 're sending 148 07:23.120 --> 07:28.920 things at user priority six, remember, we have no control over how the station 149 07:28.920 --> 07:29.680 performs 150 07:29.680 --> 07:31.320 the transmit. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 150 07:29.680 --> 07:31.320 the transmit. 151 07:31.320 --> 07:35.640 They might well send bulk traffic at a higher priority than they should. 152 07:35.640 --> 07:37.640 And there's not much we can do to stop them. 153 07:37.640 --> 07:41.040 But once it hits the access point, I'm going to send that packet on. 154 07:41.040 --> 07:45.740 At that point, I need to at least protect the wired network. 155 07:45.740 --> 07:48.710 And so if they are sending with a user priority of six, it's going to get 156 07:48.710 --> 07:49.460 mapped all the way 157 07:49.460 --> 07:51.220 down to a 41. 158 07:51.220 --> 07:55.640 So this is why we say what exactly is allowed by these policies. 159 07:55.640 --> 07:59.680 Well, we're going to allow video streaming at 41. 160 07:59.680 --> 08:03.780 And if you're sending me higher level traffic, it will also get mapped to a 41, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 160 07:59.680 --> 08:03.780 And if you're sending me higher level traffic, it will also get mapped to a 41, 161 08:03.780 --> 08:04.280 but we're 162 08:04.280 --> 08:10.530 not allowing anybody to send traffic that gets mapped to my EF that would mess 163 08:10.530 --> 08:11.040 with 164 08:11.040 --> 08:14.920 my voice over IP traffic on the wired side. 165 08:14.920 --> 08:17.440 So then we've got a couple more here. 166 08:17.440 --> 08:26.320 We have silver and silver is going to be intended for my normal network traffic 167 08:26.320 --> 08:26.640 . 168 08:26.640 --> 08:32.880 And this basically sets all traffic to a DSCP of zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 168 08:26.640 --> 08:32.880 And this basically sets all traffic to a DSCP of zero. 169 08:32.880 --> 08:36.580 So again, an SSID like this where we're going out to just normal users, 170 08:36.580 --> 08:37.640 especially maybe 171 08:37.640 --> 08:40.980 guest users, we'd want to set a silver policy. 172 08:40.980 --> 08:45.980 All traffic should be received and put onto the wired network as DSCP zero type 173 08:45.980 --> 08:46.880 of traffic. 174 08:46.880 --> 08:47.960 And then I'm out of space. 175 08:47.960 --> 08:50.360 So I'm going to add bronze over here. 176 08:50.360 --> 08:54.020 Bronze is going to be very similar, except at this point, this is for our 177 08:54.020 --> 08:55.160 scavenger traffic, 178 08:55.160 --> 08:56.840 which we explained earlier. 179 08:56.840 --> 09:03.800 It's the first traffic to drop and all traffic is going to get mapped to a DSCP WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 179 08:56.840 --> 09:03.800 It's the first traffic to drop and all traffic is going to get mapped to a DSCP 180 09:03.800 --> 09:04.960 value here 181 09:04.960 --> 09:10.560 of CS one that class selector one, which is a value of eight. 182 09:10.560 --> 09:13.710 And once again, at first glance, we say, well, that's a higher number than zero 183 09:13.710 --> 09:13.960 . 184 09:13.960 --> 09:19.400 But again, we're reserving that class selector for scavenger traffic. 185 09:19.400 --> 09:23.960 And so it might feel backwards at first, but again, with QOS policies with the 186 09:23.960 --> 09:24.080 fact 187 09:24.080 --> 09:26.240 that we have a scavenger class. 188 09:26.240 --> 09:29.800 We just need something to be worth less than zero. 189 09:29.800 --> 09:31.000 We don't have negative numbers. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 189 09:29.800 --> 09:31.000 We don't have negative numbers. 190 09:31.000 --> 09:32.800 So we can't use negative numbers. 191 09:32.800 --> 09:37.120 And so that's what we've assigned CS one to do for us. 192 09:37.120 --> 09:41.420 Now when we look at configuration and the wireless LAN controller, which is a 193 09:41.420 --> 09:41.560 little 194 09:41.560 --> 09:46.740 bit beyond the scope of what we need to go into here, Cisco's not asking us to 195 09:46.740 --> 09:47.040 go in 196 09:47.040 --> 09:50.700 and configure a bunch of QOS policies, we just need to understand a lot of 197 09:50.700 --> 09:51.720 these concepts. 198 09:51.720 --> 09:56.330 But when we are going into the configuration, we will find that there are e 199 09:56.330 --> 09:57.360 gress policies 200 09:57.360 --> 10:00.040 and there are ingress policies. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 200 09:57.360 --> 10:00.040 and there are ingress policies. 201 10:00.040 --> 10:04.020 And these policies will again take different forms here as far as class maps 202 10:04.020 --> 10:04.680 and policy 203 10:04.680 --> 10:05.680 maps are concerned. 204 10:05.680 --> 10:10.330 There'll be different class maps and policy maps used for these egress and ing 205 10:10.330 --> 10:11.800 ress policies. 206 10:11.800 --> 10:16.290 Specifically, ingress policies are known, for example, as let's just say for 207 10:16.290 --> 10:17.000 platinum, 208 10:17.000 --> 10:23.440 this platinum dash up, whereas egress, this is just known as platinum. 209 10:23.440 --> 10:28.160 So I'm going to have to deploy an egress policy and an ingress policy. 210 10:28.160 --> 10:29.160 These will be separate. 211 10:29.160 --> 10:32.440 And when I use the drop down, I'll see that egress has a platinum as an option. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 211 10:29.160 --> 10:32.440 And when I use the drop down, I'll see that egress has a platinum as an option. 212 10:32.440 --> 10:35.240 Ingress has platinum dash up as an option. 213 10:35.240 --> 10:41.160 And if I go to the actual iOS XC CLI configuration, I'll see these clarified in 214 10:41.160 --> 10:44.120 the MQC policy. 215 10:44.120 --> 10:45.720 So what's the difference between them? 216 10:45.720 --> 10:50.120 Well, egress policies, these assume that we have full control over the tags 217 10:50.120 --> 10:50.880 because we 218 10:50.880 --> 10:51.880 do. 219 10:51.880 --> 10:56.120 If it's an an egress, that means that the packet is coming from the network and 220 10:56.120 --> 10:56.480 it's 221 10:56.480 --> 10:59.200 about to be sent out of this access point. 222 10:59.200 --> 11:03.760 So we have good, valid tags coming from the network. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 222 10:59.200 --> 11:03.760 So we have good, valid tags coming from the network. 223 11:03.760 --> 11:10.830 The platinum up command or configuration, this is intended to fix these issues 224 11:10.830 --> 11:11.320 that 225 11:11.320 --> 11:13.800 we started out by talking about. 226 11:13.800 --> 11:15.200 And we don't have control. 227 11:15.200 --> 11:18.450 We know that we don't have control over the tags as they come into the access 228 11:18.450 --> 11:19.040 points. 229 11:19.040 --> 11:20.240 And so we need to align. 230 11:20.240 --> 11:24.560 We need to wipe the tags in some in some situations. 231 11:24.560 --> 11:26.520 But there are slightly different policies. 232 11:26.520 --> 11:31.040 Meanwhile, if we're looking at an SSID, we usually want to align that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 232 11:26.520 --> 11:31.040 Meanwhile, if we're looking at an SSID, we usually want to align that. 233 11:31.040 --> 11:34.120 And again, it has more to do with what devices are out there. 234 11:34.120 --> 11:39.680 If I have a phone network of phone SSID, I'd want to assign that to platinum. 235 11:39.680 --> 11:44.160 But if I have this SSID and it also has laptops and users on it, well, I have 236 11:44.160 --> 11:45.120 no choice. 237 11:45.120 --> 11:49.720 I have to assign it platinum because of the voice over IP wireless phones. 238 11:49.720 --> 11:53.690 And so keep that in mind as we're thinking about wireless configurations that 239 11:53.690 --> 11:54.120 we almost 240 11:54.120 --> 11:58.560 have to look at the greatest common denominator, so to speak, look at the most 241 11:58.560 --> 11:59.760 critical devices 242 11:59.760 --> 12:04.650 that are on a particular SSID and not the lowest common denominator and then WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 242 11:59.760 --> 12:04.650 that are on a particular SSID and not the lowest common denominator and then 243 12:04.650 --> 12:06.000 assign the policy 244 12:06.000 --> 12:06.640 appropriately.