WEBVTT 1 00:00.000 --> 00:05.040 The diff-serve model that we just got done talking about involves a series of 2 00:05.040 --> 00:09.800 independent devices that are all configured to deliver a certain level of 3 00:09.800 --> 00:15.180 service to our traffic. So if we have, for example, a voiceover IP packet come 4 00:15.180 --> 00:19.500 through, then we might want to reserve 10% of the network bandwidth for that 5 00:19.500 --> 00:24.400 voiceover IP stream as well as any other voiceover IP streams that happen to be 6 00:24.400 --> 00:28.020 present. And so that's well and good other than we need to make sure that all 7 00:28.020 --> 00:34.380 of these independent devices are properly configured. Now yes, we could have WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 7 00:28.020 --> 00:34.380 of these independent devices are properly configured. Now yes, we could have 8 00:34.380 --> 00:39.080 software that tries to standardize this and push configurations out at the same 9 00:39.080 --> 00:43.020 time. I mean there are ways that we can configure this potentially as a system, 10 00:43.020 --> 00:48.640 but strictly speaking from a diff-serve perspective, we have a little bit of a 11 00:48.640 --> 00:52.840 problem to address even when configuration is synchronized. And that is 12 00:52.840 --> 00:59.080 that as this packet traverses the network, we need to understand that this is a 13 00:59.080 --> 01:04.560 voiceover IP packet. Remember that int-serve model, if we had been using int- WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 13 00:59.080 --> 01:04.560 voiceover IP packet. Remember that int-serve model, if we had been using int- 14 01:04.560 --> 01:04.780 serve, 15 01:04.780 --> 01:10.400 we could have reserved an entire traffic stream, or at least enough bandwidth 16 01:10.400 --> 01:10.500 for 17 01:10.500 --> 01:13.830 this traffic stream throughout the entire network, and that way the network 18 01:13.830 --> 01:14.100 knows 19 01:14.100 --> 01:18.280 that this traffic stream is coming, it can recognize it and treat it 20 01:18.280 --> 01:18.700 accordingly. 21 01:18.700 --> 01:23.520 But with diff-serve because each one of these devices is independent, it needs 22 01:23.520 --> 01:23.840 to 23 01:23.840 --> 01:30.190 perform its own policy enforcement. Again, in this case, reserving 10% of WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 23 01:23.840 --> 01:30.190 perform its own policy enforcement. Again, in this case, reserving 10% of 24 01:30.190 --> 01:30.560 bandwidth 25 01:30.560 --> 01:34.920 and potentially putting that voiceover IP packet into a priority queue and all 26 01:34.920 --> 01:38.560 things we're going to be talking about here as we move forward. And so the 27 01:38.560 --> 01:44.800 question is how does it know whether a packet is a voiceover IP packet? This is 28 01:44.800 --> 01:49.720 the big problem. We need to recognize that this came from a phone and so maybe 29 01:49.720 --> 01:53.440 there's a phone directly connected to this first hop and so we say, "Okay, well 30 01:53.440 --> 01:58.360 traffic coming from the phone must be voiceover IP." But then how does the next 31 01:58.360 --> 02:03.720 device handle this? We need to be able to look at a packet and know what it is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 31 01:58.360 --> 02:03.720 device handle this? We need to be able to look at a packet and know what it is. 32 02:03.720 --> 02:09.520 And yeah, we could unpack the entire packet and look at all of the metadata in 33 02:09.520 --> 02:13.960 here and all the ones and zeros and try to figure out that this is a voiceover 34 02:13.960 --> 02:14.400 IP 35 02:14.400 --> 02:18.360 packet but this is going to require a whole lot of processing power in order 36 02:18.360 --> 02:23.800 to try to figure out and ultimately we don't want to perform guesswork in any 37 02:23.800 --> 02:29.160 sense. We'd rather just explicitly know what types of traffic we're supposed to 38 02:29.160 --> 02:33.200 treat certain ways. And keep in mind that even though voiceover IP is an WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 38 02:29.160 --> 02:33.200 treat certain ways. And keep in mind that even though voiceover IP is an 39 02:33.200 --> 02:38.160 important part of a QOS deployment, it's not the only traffic stream that we 40 02:38.160 --> 02:38.320 want 41 02:38.320 --> 02:42.200 to be able to recognize and enforce policy against. We might have other 42 02:42.200 --> 02:46.760 traffic streams that are going to be given 40% of the bandwidth or whatever 43 02:46.760 --> 02:54.000 the situation is. And so we need a way to identify this packet and so this is 44 02:54.000 --> 03:00.480 going to lead us to that conversation of classification which is ultimately WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 44 02:54.000 --> 03:00.480 going to lead us to that conversation of classification which is ultimately 45 03:00.480 --> 03:09.080 going to rely on marking. Now we might use the formal terms classification and 46 03:09.080 --> 03:13.840 marking. Ultimately classification is just that conversation of identification. 47 03:13.840 --> 03:21.120 How do I know what type of packet this is? That's the question we're trying to 48 03:21.120 --> 03:27.240 answer. And so yeah, there's a lot of different ways we can do that but in our 49 03:27.240 --> 03:33.030 case we're going to use marking which is sometimes referred to as tagging. We WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 49 03:27.240 --> 03:33.030 case we're going to use marking which is sometimes referred to as tagging. We 50 03:33.030 --> 03:33.120 're 51 03:33.120 --> 03:38.760 going to insert a tag into the packet that performs the identification of that 52 03:38.760 --> 03:43.440 packet. So that's why classification and marking as a term are usually stated 53 03:43.440 --> 03:48.640 together. So now what we're going to do is we're going to take this packet and 54 03:48.640 --> 03:55.480 because this is a voiceover IP packet we're going to put a tag inside of this 55 03:55.480 --> 03:59.680 packet. So it's going to include this tag sort of like how we include a VLAN 56 03:59.680 --> 03:59.920 tag 57 03:59.920 --> 04:04.680 into an ethernet header. We're going to insert this a tag into either the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 57 03:59.920 --> 04:04.680 into an ethernet header. We're going to insert this a tag into either the 58 04:04.680 --> 04:11.800 ethernet header or potentially the IPv4 or IPv6 header either way. We have 59 04:11.800 --> 04:15.480 options for both of these. And so this tag is going to perform the 60 04:15.480 --> 04:16.360 identification 61 04:16.360 --> 04:22.440 that says hey this is a voiceover IP packet. So our phone that's going to send 62 04:22.440 --> 04:27.840 this packet is going to insert the tag on for the sake of the rest of the 63 04:27.840 --> 04:28.200 network. 64 04:28.200 --> 04:31.280 That way the network doesn't have to try to figure out what type of packet this WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 64 04:28.200 --> 04:31.280 That way the network doesn't have to try to figure out what type of packet this 65 04:31.280 --> 04:37.760 is it can just look at the tag. So what exactly is this tag? Well the tag is a 66 04:37.760 --> 04:45.480 numerical value and the meaning of the tag is up to us. We've just mentioned 67 04:45.480 --> 04:45.600 this 68 04:45.600 --> 04:50.920 word policy. If I want a router to exert a particular policy enforce a 69 04:50.920 --> 04:56.360 particular policy on a packet well I can look at the tag and that tag can have 70 04:56.360 --> 05:02.350 meaning to me but it's not maybe a value that necessarily has meaning to others WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 70 04:56.360 --> 05:02.350 meaning to me but it's not maybe a value that necessarily has meaning to others 71 05:02.350 --> 05:02.360 . 72 05:02.360 --> 05:08.200 I have to decide what the value of this particular numerical tag is supposed to 73 05:08.200 --> 05:13.760 represent. So what numbers mean what? Well to some extent that's up to us. We 74 05:13.760 --> 05:13.960 can 75 05:13.960 --> 05:20.200 assign a value let's say 5 and we can map that to voiceover IP and we could 76 05:20.200 --> 05:26.120 take something like a value of 2 and map that to bulk traffic. These numerical 77 05:26.120 --> 05:31.280 values can have significance within the network without necessarily meaning the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 77 05:26.120 --> 05:31.280 values can have significance within the network without necessarily meaning the 78 05:31.280 --> 05:36.040 same thing from every network to every network. Now there is some amount of 79 05:36.040 --> 05:42.200 industry standardization to suggest for example that a tag of 5 is going to 80 05:42.200 --> 05:47.600 represent voiceover IP. We'll find a lot of ideas out there about how exactly 81 05:47.600 --> 05:48.000 we 82 05:48.000 --> 05:54.080 should be tagging traffic so that there is a little bit of standardization. But 83 05:54.080 --> 05:59.360 it's not something that is required. I could in my network make it so that we 84 05:59.360 --> 05:59.400 've 85 05:59.400 --> 06:04.320 got a tag of 2 representing bulk traffic but in your network a tag of 2 might WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 85 05:59.400 --> 06:04.320 got a tag of 2 representing bulk traffic but in your network a tag of 2 might 86 06:04.320 --> 06:11.240 represent video traffic. Is that best practice? Well again there's the 87 06:11.240 --> 06:15.480 industry has been standardizing on this for a long time as far as which values 88 06:15.480 --> 06:20.600 should represent what. But the only place is that it's going to ultimately be 89 06:20.600 --> 06:25.280 dictated for us is something like this where a Cisco phone is always going to 90 06:25.280 --> 06:31.280 tag its voiceover IP packets with a tag of 5. So if there's an end device that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 90 06:25.280 --> 06:31.280 tag its voiceover IP packets with a tag of 5. So if there's an end device that 91 06:31.280 --> 06:35.000 sort of enforces the meaning of a particular tag then we should use that 92 06:35.000 --> 06:40.040 tag. Otherwise to some extent it's up to us. Now later on we're going to talk 93 06:40.040 --> 06:44.760 about the concept of per-hot behaviors. These are essentially ways that the 94 06:44.760 --> 06:49.040 industry has said hey if you want a traffic to be treated a particular way 95 06:49.040 --> 06:55.400 like this specific way a high priority a low priority a higher drop priority 96 06:55.400 --> 07:01.160 those kinds of things then they have set aside specific values to mean that. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 96 06:55.400 --> 07:01.160 those kinds of things then they have set aside specific values to mean that. 97 07:01.160 --> 07:01.160 And 98 07:01.160 --> 07:05.720 that's important because if I'm a consultant and I sit down at your in your 99 07:05.720 --> 07:10.160 network and I'm trying to help fix your QOS issues if you are using the 100 07:10.160 --> 07:14.320 industry standard recommendations for your tags then I can help troubleshoot 101 07:14.320 --> 07:18.680 that a lot more. If you just are saying well you know I can use whatever tag I 102 07:18.680 --> 07:24.320 want and so yeah I'll use 5 for voiceover IP but I'm going to set by default 103 07:24.320 --> 07:28.840 everything to use a tag of 1 and I'm going to set video to 0 and all of these 104 07:28.840 --> 07:32.120 things that we don't really see a lot of it's going to be a lot harder for WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 104 07:28.840 --> 07:32.120 things that we don't really see a lot of it's going to be a lot harder for 105 07:32.120 --> 07:36.560 someone like me as a consultant to troubleshoot and if you ever leave your 106 07:36.560 --> 07:40.680 company has to hire somebody else they're going to look at it and say what was 107 07:40.680 --> 07:44.960 this person thinking with deploying video with a tag of 0 for example. So 108 07:44.960 --> 07:48.880 that's why it's important for us to look at the tags that are recommended and 109 07:48.880 --> 07:53.000 again we are going to look at that here inside of this skill as far as which 110 07:53.000 --> 08:00.000 tags mean what kinds of things. But understand that we define the policy we WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 111 08:00.000 --> 08:05.200 are the ones who have to say because of this tag now we're going to enforce a 112 08:05.200 --> 08:11.440 specific policy. Cisco routers are not built in such a way that you know if we 113 08:11.440 --> 08:16.000 receive a tag of 2 for example that's going to treat it automatically in a 114 08:16.000 --> 08:20.680 particular fashion we still have to define that policy even for voiceover IP 115 08:20.680 --> 08:26.320 traffic. Now this classification concept is kind of interesting and raises a 116 08:26.320 --> 08:26.520 big 117 08:26.520 --> 08:33.040 concern because now we have to worry about what the downstream device is. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 117 08:26.520 --> 08:33.040 concern because now we have to worry about what the downstream device is. 118 08:33.040 --> 08:42.320 It's great if we have a switch and I'm connecting to a phone and this phone is 119 08:42.320 --> 08:48.400 tagging its traffic with again a value of 5. So the phone is tagging its 120 08:48.400 --> 08:48.920 traffic 121 08:48.920 --> 08:54.280 and now because of this I place this onto this link with a very high priority. 122 08:54.280 --> 08:59.920 It's high priority we have bandwidth reservations we have all kinds of things 123 08:59.920 --> 09:07.760 going on here when your tag is 5 because 5 means voiceover IP. So that's great WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 123 08:59.920 --> 09:07.760 going on here when your tag is 5 because 5 means voiceover IP. So that's great 124 09:07.760 --> 09:13.960 except what happens if I also have a user with a laptop and this user is 125 09:13.960 --> 09:17.960 smart enough with networking to understand that tags of 5 are usually 126 09:17.960 --> 09:23.240 treated pretty well. Well because this is now a little bit of a malicious user 127 09:23.240 --> 09:27.480 here maybe not necessarily a hacker but somebody who's not really thinking 128 09:27.480 --> 09:32.600 about the good of the network what if they start tagging their traffic with 5 WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 128 09:27.480 --> 09:32.600 about the good of the network what if they start tagging their traffic with 5 129 09:32.600 --> 09:36.280 as well because they want their traffic to be treated with a higher 130 09:36.280 --> 09:40.480 priority level and maybe that's the best case scenario the worst case scenario 131 09:40.480 --> 09:40.560 is 132 09:40.560 --> 09:46.200 it could be somebody who's trying to cause damage to my network and they want 133 09:46.200 --> 09:49.920 to split this bandwidth and take up all the phone bandwidth something along 134 09:49.920 --> 09:50.120 those 135 09:50.120 --> 09:57.560 lines. So this is going to lead us to a conversation about trust and 136 09:57.560 --> 09:58.400 specifically 137 09:58.400 --> 10:03.920 what we're going to call the trust boundary. So the trust boundary basically WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 137 09:58.400 --> 10:03.920 what we're going to call the trust boundary. So the trust boundary basically 138 10:03.920 --> 10:10.400 answers the question of who do we trust and the short answer is we want to 139 10:10.400 --> 10:10.760 trust 140 10:10.760 --> 10:21.360 our network devices and we want to not trust end user devices. So here's what 141 10:21.360 --> 10:27.120 this looks like. We might draw the we are going to draw a trust boundary here 142 10:27.120 --> 10:31.960 to say that we are not going to trust anything down here so this is the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 142 10:27.120 --> 10:31.960 to say that we are not going to trust anything down here so this is the 143 10:31.960 --> 10:40.000 untrusted domain but we are going to include the phone in here because this 144 10:40.000 --> 10:44.800 is part of the trusted domain. I want to trust the phone and I know it's a 145 10:44.800 --> 10:45.080 phone 146 10:45.080 --> 10:49.360 because I have CDP going I can tell it's a phone it's maybe it's a Cisco phone 147 10:49.360 --> 10:54.280 and so I can trust the tags that I'm receiving from it but I'm not going to 148 10:54.280 --> 10:59.640 trust the tags that receive from these other devices. When we receive a packet 149 10:59.640 --> 11:09.360 on an untrusted interface we are going to wipe the tag. This is the behavior WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 149 10:59.640 --> 11:09.360 on an untrusted interface we are going to wipe the tag. This is the behavior 150 11:09.360 --> 11:09.520 that 151 11:09.520 --> 11:13.760 we're looking for. So this tag of five enters into the untrusted domain or 152 11:13.760 --> 11:17.880 enters into the trusted domain from the untrusted domain and the switch is 153 11:17.880 --> 11:18.080 going 154 11:18.080 --> 11:23.440 to wipe it and set that tag to zero. This way regardless of this person's 155 11:23.440 --> 11:28.480 intentions they cannot insert their packets into the cues that are designed 156 11:28.480 --> 11:33.160 for voice over IP traffic. Now one other thing in all of this is we might find WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 156 11:28.480 --> 11:33.160 for voice over IP traffic. Now one other thing in all of this is we might find 157 11:33.160 --> 11:39.360 that we have laptops or PCs for that matter that connect into our phones. 158 11:39.360 --> 11:44.480 The phones are designed for this they have a little tiny switch inside of the 159 11:44.480 --> 11:48.920 phone so that we can bring traffic in and then send it upstream. It makes it so 160 11:48.920 --> 11:54.120 we don't have to make two runs one to the phone and one to the PC. So that's 161 11:54.120 --> 11:57.560 great and all except again look at the trust boundary we want to make sure that 162 11:57.560 --> 12:03.560 this is part of that untrusted domain. So what does that mean? Well what that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 162 11:57.560 --> 12:03.560 this is part of that untrusted domain. So what does that mean? Well what that 163 12:03.560 --> 12:07.880 means is the phone is going to receive a packet and it's going to participate 164 12:07.880 --> 12:08.040 in 165 12:08.040 --> 12:12.800 this trust model and it's going to wipe those tags as they come in. So the tags 166 12:12.800 --> 12:17.560 the classification the marking is going to be under our control. We want to 167 12:17.560 --> 12:17.680 make 168 12:17.680 --> 12:22.160 sure that only our devices are performing tagging that we only trust our own 169 12:22.160 --> 12:28.200 devices and that's going to enable every device hop by hop to look very simply 170 12:28.200 --> 12:33.000 at what that packet is based on the marking and then it can classify that WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 170 12:28.200 --> 12:33.000 at what that packet is based on the marking and then it can classify that 171 12:33.000 --> 12:36.880 packet know that for example it's a voice over IP packet and then we can 172 12:36.880 --> 12:40.640 enforce the proper policy against it.