1 00:00:08,860 --> 00:00:12,380 Okay, so the multicast Mac, remember we're talking about a destination 2 00:00:12,380 --> 00:00:18,460 Mac address, is partially derived from the actual multicast IP address 3 00:00:18,460 --> 00:00:20,840 that sits above it at the networking layer. 4 00:00:20,840 --> 00:00:26,520 So these are the two reserved OUIs you should look for for multicast. 5 00:00:26,520 --> 00:00:30,160 If you ever see an Ethernet frame that's going to a destination starting 6 00:00:30,160 --> 00:00:36,780 out with 01005E, that should make you say aha, that frame is carrying 7 00:00:36,780 --> 00:00:40,520 an IP version 4 multicast packet. 8 00:00:40,520 --> 00:00:46,280 So that's the OUI that's reserved for IPv4 multicast data. 9 00:00:46,280 --> 00:00:52,220 And then if you ever see anything going to 33333, that is reserved for 10 00:00:52,220 --> 00:00:55,260 IPv6 multicasts. 11 00:00:55,260 --> 00:00:59,180 Okay, so let's talk a little bit about how do we actually derive stuff. 12 00:00:59,180 --> 00:01:00,880 First of all, let's start with IPv6. 13 00:01:00,880 --> 00:01:04,360 IPv6 is real easy, and then I'll go back to IPv4. 14 00:01:04,360 --> 00:01:09,640 Let's say that my multicast IPv6 address, I'll just make something up 15 00:01:09,640 --> 00:01:19,340 here. Let's say it was going to FF0E, so this is a global multicast, and 16 00:01:19,340 --> 00:01:36,300 let's just say 11111, and then AAAA, BBBB, CCC, let's see, 1, 2, 3, 4, 17 00:01:36,300 --> 00:01:39,060 5, I need three more. 18 00:01:39,060 --> 00:01:47,780 And then 2222, 777, 1, 2, 3, 4, 5, 6, 7, then we'll just do the last octet, 19 00:01:47,780 --> 00:01:53,700 sort of run DDD. 20 00:01:53,700 --> 00:02:00,760 Okay, all we're going to do is when the multicast source generates this 21 00:02:00,760 --> 00:02:06,380 address as the destination address at layer three, after that when he's 22 00:02:06,380 --> 00:02:11,080 creating his Ethernet frame, all he's going to do is take the last 32 23 00:02:11,080 --> 00:02:19,100 bits, which in this case is 777 and DDDD, and he's going to put that right 24 00:02:19,100 --> 00:02:21,180 here, where these X's are. 25 00:02:21,180 --> 00:02:26,380 So at layer two, the Ethernet frame will be destined to 333 colon 777 26 00:02:26,380 --> 00:02:32,020 colon DDDD. So that's pretty easy. 27 00:02:32,020 --> 00:02:36,400 Just remember the last 32 bits of the IPv6 multicast address are directly 28 00:02:36,400 --> 00:02:42,420 mapped to the last 32 bits of the Ethernet frame's destination MAC address. 29 00:02:42,420 --> 00:02:47,400 Now, in the world of IPv4, this is kind of a nightmare to map this. 30 00:02:47,400 --> 00:02:50,580 So just bear with me here, if you haven't had your coffee, you might want 31 00:02:50,580 --> 00:02:54,660 to take a big chug of it at this point, because this typically makes people's 32 00:02:54,660 --> 00:02:55,620 eyes glaze over. 33 00:02:55,620 --> 00:02:58,960 But we're going to go ahead and go through it because I think you ought 34 00:02:58,960 --> 00:03:08,780 to know it. So, first of all, my multicast MAC address we know at layer 35 00:03:08,780 --> 00:03:21,920 two is 01005E. And now you might think, okay, well that's half of the 36 00:03:21,920 --> 00:03:25,200 address, right? A MAC address is 48 bits long. 37 00:03:25,200 --> 00:03:30,380 This is half. So you might think, okay, I've got 24 bits left to map. 38 00:03:30,380 --> 00:03:32,720 Well, not quite. 39 00:03:32,720 --> 00:03:37,640 If I convert this into binary for the rest of it, just some of it, the 40 00:03:37,640 --> 00:03:42,380 very next bit has to be a zero. 41 00:03:42,380 --> 00:03:52,620 And then you've got 12345678 colon 12345678. 42 00:03:52,620 --> 00:03:54,380 I'll just do that. 43 00:03:54,380 --> 00:04:00,580 Colon 12345678. I'm running out of space, but you get the idea. 44 00:04:00,580 --> 00:04:05,580 So of my remaining 24 bits, I really only have 23 bits. 45 00:04:05,580 --> 00:04:09,520 This one here has to be zeroed out. 46 00:04:09,520 --> 00:04:12,320 And if you're ever looking at that and you're wondering what? 47 00:04:12,320 --> 00:04:14,180 Well, that makes no sense. 48 00:04:14,180 --> 00:04:16,000 I'll tell you what, there's an interesting story. 49 00:04:16,000 --> 00:04:18,640 I'm not going to get into the story, but this is what you should Google 50 00:04:18,640 --> 00:04:21,980 to find out why did they end up doing it like this? 51 00:04:21,980 --> 00:04:24,800 Google this. Google the name Steve. 52 00:04:24,800 --> 00:04:34,380 Last name, Deering. 53 00:04:34,380 --> 00:04:36,880 Multicast Mac. Google that. 54 00:04:36,880 --> 00:04:39,780 Steve Deering Multicast Mac. 55 00:04:39,780 --> 00:04:42,480 And you'll be able to find an interesting story about Steve Deering was 56 00:04:42,480 --> 00:04:45,040 one of the original pioneers of multicast. 57 00:04:45,040 --> 00:04:47,160 He did a lot of the initial work on this. 58 00:04:47,160 --> 00:04:49,880 And you'll find an interesting story about back when he was a grad student, 59 00:04:49,880 --> 00:04:54,720 a little interaction he had with his professor that had to do with money, 60 00:04:54,720 --> 00:04:59,100 and it ended up with this weird thing right here, with only 23 bits being 61 00:04:59,100 --> 00:05:04,440 available. Okay, so how do we map the multicast IP address? 62 00:05:04,440 --> 00:05:09,700 Well, if you can keep this in mind, now it should be pretty easy. 63 00:05:09,700 --> 00:05:14,420 Just take the last 23 bits of the multicast IP address and map it here. 64 00:05:14,420 --> 00:05:20,180 So let's say my multicast IP address is 239. 65 00:05:20,180 --> 00:05:29,420 Well no matter what the first octet is, whether 224 up to 239, it's always 66 00:05:29,420 --> 00:05:31,660 going to map down to 5e, right? 67 00:05:31,660 --> 00:05:34,400 Because that octet is sort of canceled out, it's always going to become 68 00:05:34,400 --> 00:05:39,600 5e. And now let's say I had a multicast stream that was 239. 69 00:05:39,600 --> 00:05:43,300 let's just make it easy. 70 00:05:43,300 --> 00:05:48,360 1.1.1. That's my multicast IP address. 71 00:05:48,360 --> 00:05:54,480 Well the resulting multicast MAC address would be 01005e, and these bits 72 00:05:54,480 --> 00:05:56,040 would be mapped right here. 73 00:05:56,040 --> 00:06:01,620 So it'd be 01005e, 1111. 74 00:06:01,620 --> 00:06:06,860 Well what if I had 225.1.1? 75 00:06:06,860 --> 00:06:11,320 It would be the exact same thing. 76 00:06:11,320 --> 00:06:14,400 0111, they would all map to the same multicast MAC. 77 00:06:14,400 --> 00:06:15,700 So let's add this up for a second. 78 00:06:15,700 --> 00:06:21,860 If you just do some quick math, if we start at 224 and we go up to 239, 79 00:06:21,860 --> 00:06:25,440 how many unique numbers is that? 80 00:06:25,440 --> 00:06:30,440 I'll tell you right now, that's a total of 16 unique numbers. 81 00:06:30,440 --> 00:06:35,100 From 224 up to 239 is 16 combinations of bytes. 82 00:06:35,100 --> 00:06:42,440 So right off the bat, we've got 16 multicast IPV4 addresses which will 83 00:06:42,440 --> 00:06:47,120 all map down to the exact same multicast MAC. 84 00:06:47,120 --> 00:06:50,220 But it gets even better than that. 85 00:06:50,220 --> 00:06:59,520 Because not only will 239.111 map down to this, but 239.129.11. 86 00:06:59,520 --> 00:07:04,520 Because remember, this 8 bit, this bit that's normally mapped to the 128 87 00:07:04,520 --> 00:07:07,720 bit, always has to be a zero. 88 00:07:07,720 --> 00:07:12,240 So even if in the IPV4 address that bit is turned on, we have to turn 89 00:07:12,240 --> 00:07:14,920 it off right here. 90 00:07:14,920 --> 00:07:22,380 So 239.111 and 239.111 will also map to the same thing. 91 00:07:22,380 --> 00:07:27,560 Anytime the 128 bit is turned on in this third octet, it's going to drop 92 00:07:27,560 --> 00:07:30,600 out because it's got to be a zero right here. 93 00:07:30,600 --> 00:07:35,260 So that means for each one of these 16 combinations, there's two combinations 94 00:07:35,260 --> 00:07:45,080 that also map. For example, 224.111 and 224.129.11, both mapped to the 95 00:07:45,080 --> 00:07:46,540 exact same thing. 96 00:07:46,540 --> 00:07:56,460 227.1.5.5, 227.129.5 mapped to the exact same thing. 97 00:07:56,460 --> 00:08:03,620 So in reality, we've got 16 numbers in the first octet and two numbers 98 00:08:03,620 --> 00:08:05,760 in the second octet. 99 00:08:05,760 --> 00:08:09,060 So we really have 32. 100 00:08:09,060 --> 00:08:14,440 So for every single multicast MAC address, so if I show you, for example, 101 00:08:14,440 --> 00:08:17,700 this one, let's get rid of Steve Deering's name right here. 102 00:08:17,700 --> 00:08:21,360 I'm sure he would love to see it up on this presentation, but sorry, Steve, 103 00:08:21,360 --> 00:08:23,600 we're going to get rid of it temporarily. 104 00:08:23,600 --> 00:08:41,740 So if I gave you this multicast MAC address, 01005E, oops, not 5.2, 5E. 105 00:08:41,740 --> 00:08:52,480 And then I said, let's just say, 7.1 .1, let me do one, let's do colons. 106 00:08:52,480 --> 00:08:58,500 So much for keeping things consistent, let's see here. 107 00:08:58,500 --> 00:09:01,380 Let's do colons over here too. 108 00:09:01,380 --> 00:09:11,140 Okay so if I was to ask you, what is the multicast IPv4 address that ended 109 00:09:11,140 --> 00:09:15,820 up resulting in this multicast MAC address? 110 00:09:15,820 --> 00:09:19,960 Your answer would have to be 32 unique numbers. 111 00:09:19,960 --> 00:09:25,080 Because you'd say, well Keith, the first octet could have been anything 112 00:09:25,080 --> 00:09:30,840 from 224 all the way down to 239. 113 00:09:30,840 --> 00:09:37,940 And then the second octet could have been the number 7, or it could be 114 00:09:37,940 --> 00:09:50,920 128 plus 7, which would be 135.1.1. 115 00:09:50,920 --> 00:10:01,020 So 224.7.135, 225.7.135, 226.7.135, 111.1. 116 00:10:01,020 --> 00:10:02,780 Would all map to this? 117 00:10:02,780 --> 00:10:09,200 So that gives us 32 multicast IP addresses that map to the same multicast 118 00:10:09,200 --> 00:10:16,680 MAC address. Now at this point you might be wondering, wow, okay, interesting 119 00:10:16,680 --> 00:10:21,500 mathematical exercise, but where is the real world relevance to this? 120 00:10:21,500 --> 00:10:23,460 Where is the relevance? 121 00:10:23,460 --> 00:10:26,180 Well let me paint a picture for you. 122 00:10:26,180 --> 00:10:28,480 Let's say, let's take this. 123 00:10:28,480 --> 00:10:38,600 Let's say that I have 4 laptops. 124 00:10:38,600 --> 00:10:41,800 Let's just say 3, 3 laptops since I'm running out of room here. 125 00:10:41,800 --> 00:10:45,900 Okay, and we'll make it real simple here. 126 00:10:45,900 --> 00:10:55,180 They're connected to a hub, which in turn is connected to a multicast 127 00:10:55,180 --> 00:10:59,960 server. Of course you would never see this in real life, but you'll get 128 00:10:59,960 --> 00:11:02,560 the idea behind this once I start here. 129 00:11:02,560 --> 00:11:08,360 So we'll just say PCA, B, and C. 130 00:11:08,360 --> 00:11:13,940 And let's say this multicast server is going to be sending out 3 unique 131 00:11:13,940 --> 00:11:15,440 streams of traffic. 132 00:11:15,440 --> 00:11:23,820 We've got 225.2.1.1. 133 00:11:23,820 --> 00:11:31,020 We've got 239.130.1.1. 134 00:11:31,020 --> 00:11:35,540 And we've got 232. 135 00:11:35,540 --> 00:11:45,220 Well we shouldn't be using, well you'll get the idea, 232.2.1.1. 136 00:11:45,220 --> 00:11:50,020 And let's say that all of these are high definition streams. 137 00:11:50,020 --> 00:11:54,940 Each one is 5 megabits per second. 138 00:11:54,940 --> 00:11:58,700 If you actually receive it, you'll be receiving 5 megabits per second. 139 00:11:58,700 --> 00:12:03,580 Okay, so these streams are going now. 140 00:12:03,580 --> 00:12:08,440 All three streams are leaving this server simultaneously. 141 00:12:08,440 --> 00:12:12,000 If PC, let's just start with PCC. 142 00:12:12,000 --> 00:12:20,140 If PCC says look, the only one I'm interested in is 225.2.1.1. 143 00:12:20,140 --> 00:12:21,320 So what does he do? 144 00:12:21,320 --> 00:12:22,860 He goes to his ethernet Nik card. 145 00:12:22,860 --> 00:12:25,460 He says okay, ethernet Nik card, this is what I want you to look for. 146 00:12:25,460 --> 00:12:32,200 If you've ever seen ethernet frame that starts out with 0.01, 0.05e, 0 147 00:12:32,200 --> 00:12:41,500 .2, 0.1, 0.1, I want you to pick that up and send it to my processor for 148 00:12:41,500 --> 00:12:46,960 processing. The moment he does that, and he programs his Nik card to look 149 00:12:46,960 --> 00:12:51,480 at that, all of a sudden his laptop just starts going haywire. 150 00:12:51,480 --> 00:12:57,020 His video screen is just pixelated, you can't see anything, it doesn't 151 00:12:57,020 --> 00:13:00,700 make any sense. Not only that, he's trying to download his emails and 152 00:13:00,700 --> 00:13:03,700 it's taken forever to download his emails, he might even be connecting 153 00:13:03,700 --> 00:13:06,640 and disconnecting, connecting and disconnecting from his email server. 154 00:13:06,640 --> 00:13:09,440 It's like his laptop is just being slammed. 155 00:13:09,440 --> 00:13:10,700 What's going on? 156 00:13:10,700 --> 00:13:15,700 At this point, because all three of these streams map to the exact same 157 00:13:15,700 --> 00:13:22,240 layer two MAC address, we now have three streams coming down and his Nik 158 00:13:22,240 --> 00:13:26,900 card is picking up all of them because at layer two, they all look the 159 00:13:26,900 --> 00:13:30,920 same. His ethernet card can't distinguish the layer three addresses because 160 00:13:30,920 --> 00:13:31,920 it doesn't do that. 161 00:13:31,920 --> 00:13:33,840 It's just a layer two ethernet card. 162 00:13:33,840 --> 00:13:39,280 So all three of these streams, a total of 15 megs of traffic is being 163 00:13:39,280 --> 00:13:44,700 directed to this guy's central processing unit and his CPU has to now 164 00:13:44,700 --> 00:13:50,820 toss or discard 10 megs of that so it can only see the five megs that 165 00:13:50,820 --> 00:13:55,060 it want. Well his CPU is probably going to have a real hard time receiving 166 00:13:55,060 --> 00:14:00,240 a consistent 15 megs of inbound traffic and trying to discard two thirds 167 00:14:00,240 --> 00:14:02,220 of that, 10 megs of it. 168 00:14:02,220 --> 00:14:05,000 And that's the problem with the 32 to one overlap. 169 00:14:05,000 --> 00:14:07,900 Now this is not the receiver's fault. 170 00:14:07,900 --> 00:14:10,760 This is the fault of the person who set up this multicast server in the 171 00:14:10,760 --> 00:14:15,160 first place. When you're, if you ever are in a situation where you are 172 00:14:15,160 --> 00:14:20,760 the multicast administrator and it's going to be your job to come up with 173 00:14:20,760 --> 00:14:25,100 the multicast IP addresses for each one of the multicast streams, it's 174 00:14:25,100 --> 00:14:29,080 your job to be aware of this and make sure that these video streams don't 175 00:14:29,080 --> 00:14:33,060 overlap. And it might say, well Keith, is there an easy way to figure 176 00:14:33,060 --> 00:14:34,580 that out? Sure there is. 177 00:14:34,580 --> 00:14:39,140 Just make sure that of every single multicast stream that the last two 178 00:14:39,140 --> 00:14:41,920 octets are never the same. 179 00:14:41,920 --> 00:14:44,780 Now technically we could go into the third octet as well but if you know 180 00:14:44,780 --> 00:14:49,960 that these last 16 bits are always unique, your multicast MAC addresses 181 00:14:49,960 --> 00:14:55,580 will always be unique because these last 16 bits map down one for one 182 00:14:55,580 --> 00:14:58,520 down to the multicast MAC address at layer two. 183 00:14:58,520 --> 00:15:02,740 So just make those unique and you'll never have this 32 to one overlap 184 00:15:02,740 --> 00:15:05,120 problem ever again. 185 00:15:05,120 --> 00:15:14,220 So that is how you recognize multicast IP and multicast MAC addresses. 186 00:15:14,220 --> 00:15:22,280 Now I've talked a little bit about what do routers do with multicast frames. 187 00:15:22,280 --> 00:15:25,980 I said when a router receives in a multicast frame, first thing it says 188 00:15:25,980 --> 00:15:28,180 is, is this something I need to process? 189 00:15:28,180 --> 00:15:32,120 Because it might be an EIGRP hello or an OSPF hello or something like 190 00:15:32,120 --> 00:15:35,180 that in which case I'll say, ah, I'm programmed to look for this. 191 00:15:35,180 --> 00:15:37,980 Let me send it to my CPU for processing. 192 00:15:37,980 --> 00:15:40,060 Which stop and pause for a moment. 193 00:15:40,060 --> 00:15:41,020 Think about this. 194 00:15:41,020 --> 00:15:47,680 Imagine that you are a router, okay, and you are programmed to do EIGRP, 195 00:15:47,680 --> 00:15:51,760 alright? So you are listening specifically for Ethernet frames coming 196 00:15:51,760 --> 00:15:58,820 in going to 01005E, 0000A, right? 197 00:15:58,820 --> 00:16:05,700 Because that would map to 10, 2240010 maps down to 00A at layer two. 198 00:16:05,700 --> 00:16:08,440 So here every once in a while you're expecting as a router you say, okay, 199 00:16:08,440 --> 00:16:11,660 well, you know, EIGRP shouldn't be that chatty, right? 200 00:16:11,660 --> 00:16:15,280 In a nice stable environment, every five or ten seconds or so you should 201 00:16:15,280 --> 00:16:19,720 be receiving an EIGRP hello packet, going to that multicast Mac, and then 202 00:16:19,720 --> 00:16:24,400 you process it. Now what if somebody who doesn't know anything about EIGRP 203 00:16:24,400 --> 00:16:29,060 but they do know multicast sets up their multicast high definition video 204 00:16:29,060 --> 00:16:34,360 stream, which is going at seven megabits per second, and they select, 205 00:16:34,360 --> 00:16:41,920 I don't know, 239.0010 as the destination dress. 206 00:16:41,920 --> 00:16:46,740 Guess what? At layer two that high definition video stream will map to 207 00:16:46,740 --> 00:16:50,620 the exact same Mac address that EIGRP is using. 208 00:16:50,620 --> 00:16:53,200 And now all of a sudden your router instead of only getting one packet 209 00:16:53,200 --> 00:16:57,420 every five or ten seconds is getting thousands of packets every single 210 00:16:57,420 --> 00:17:00,300 second going to this layer to address. 211 00:17:00,300 --> 00:17:03,400 You can bet that router is not going to be too happy about that. 212 00:17:03,400 --> 00:17:07,220 It might even crash because it has to take all that traffic directed to 213 00:17:07,220 --> 00:17:13,640 the CPU to be not EIGRP. 214 00:17:13,640 --> 00:17:18,200 I need to discard that to be able to isolate the little EIGRP hello that's 215 00:17:18,200 --> 00:17:20,320 still coming in every five seconds or so. 216 00:17:20,320 --> 00:17:23,200 So be aware of that. 217 00:17:23,200 --> 00:17:25,640 Now what do switches do when receiving multicast? 218 00:17:25,640 --> 00:17:30,760 Well, if you're just talking about pure layer two, switches flood multicast 219 00:17:30,760 --> 00:17:34,280 because how does a switch know where to forward something? 220 00:17:34,280 --> 00:17:42,280 Well, when Ethernet frame comes in, what does a switch do? 221 00:17:42,280 --> 00:17:46,160 It learns that into the MAC address table, sometimes called the CAM table, 222 00:17:46,160 --> 00:17:49,520 right? So that's how the switch populates the CAM table, the MAC address 223 00:17:49,520 --> 00:17:52,120 table based on source MAC addresses. 224 00:17:52,120 --> 00:17:57,580 Well, are multicast MAC addresses ever seen in the source of an Ethernet 225 00:17:57,580 --> 00:17:59,640 frame? No they're not. 226 00:17:59,640 --> 00:18:00,620 At least they shouldn't be. 227 00:18:00,620 --> 00:18:02,080 That would be illegal. 228 00:18:02,080 --> 00:18:06,840 So because a multicast MAC address only shows up in the destination, by 229 00:18:06,840 --> 00:18:11,140 default, a switch has no way of learning it because it's not in the source. 230 00:18:11,140 --> 00:18:14,320 So what do switches do when they receive an Ethernet frame and they look 231 00:18:14,320 --> 00:18:16,880 at the destination and there's no match in the table? 232 00:18:16,880 --> 00:18:20,100 They flood it. That's what they do. 233 00:18:20,100 --> 00:18:24,180 So the default behavior of many switches is to flood multicast. 234 00:18:24,180 --> 00:18:27,920 Now we'll see when we get into the topic of IGMP snooping that changes