WEBVTT 00:00:00.000 --> 00:00:08.600 All right, so now let's talk about multicast because it really is a high-level overview. 00:00:08.600 --> 00:00:12.160 And you might get one or two questions on the exam on multicast, so don't overprepare 00:00:12.160 --> 00:00:13.160 for this. 00:00:13.160 --> 00:00:16.680 But if I presented it to you and I've shown it to you and I've talked about it, at least 00:00:16.680 --> 00:00:20.760 make sure you know the terms, make sure you know the definitions, make sure you know what 00:00:20.760 --> 00:00:24.280 they're used for so that way there you can answer questions on a certification exam. 00:00:24.280 --> 00:00:29.660 All right, so before we get to terms and definitions, I have to really make sure we understand the 00:00:29.660 --> 00:00:34.500 difference between unicast and multicast and give you a few real-world examples because 00:00:34.500 --> 00:00:43.380 a lot of us don't realize what multicast truly is, and we think that a lot of things we use 00:00:43.380 --> 00:00:46.660 and do are multicast when in actuality they're not, right? 00:00:46.660 --> 00:00:48.419 Comes up in my classes all the time. 00:00:48.419 --> 00:00:54.299 So let's first of all identify the difference between unicast and multicast communication. 00:00:54.299 --> 00:00:58.459 So let's say we have a server here, and let's focus on unicast right now. 00:00:58.459 --> 00:01:04.779 If I had a video on this server, if I had a video on that server, and this PC wanted 00:01:04.779 --> 00:01:07.940 to watch that video, unicast, what do we do? 00:01:07.940 --> 00:01:13.540 We go, we double-click on whatever the video image is or the video is so we can go ahead 00:01:13.540 --> 00:01:15.940 and watch it, and we watch it. 00:01:15.940 --> 00:01:23.900 That will produce a stream from here to here so we can watch, unicast, right? 00:01:23.900 --> 00:01:29.820 It's no different than if you go to a website and want to open an image or download a text 00:01:29.820 --> 00:01:32.580 document, right? 00:01:32.580 --> 00:01:34.699 Everything you do, that's unicast. 00:01:34.699 --> 00:01:36.739 So you want to open an image, you open it up. 00:01:36.739 --> 00:01:38.500 That's a unicast stream. 00:01:38.500 --> 00:01:43.699 You want to open a Word doc, review it on a file server, that would be a unicast stream. 00:01:43.699 --> 00:01:48.099 So for every person that clicks on that, every person that uses it, that's an individual 00:01:48.099 --> 00:01:50.480 stream of communication that's happening. 00:01:50.480 --> 00:01:54.480 So when PC3 comes along and says, oh, I want to watch that video, they go ahead, they click 00:01:54.480 --> 00:01:56.279 on it, they get to watch the video. 00:01:56.279 --> 00:02:02.879 Now for every single instance of communication, the server basically makes a different connection 00:02:02.879 --> 00:02:09.679 to those users, and the server is going to then show you the video individually. 00:02:09.679 --> 00:02:13.339 So PC1 is watching it individually, PC3 is watching it individually. 00:02:13.339 --> 00:02:14.339 What does that mean? 00:02:14.339 --> 00:02:18.080 It means that we can start it, we can stop it, we can pause it, we can do anything we 00:02:18.080 --> 00:02:23.479 want to do with it, because that is specifically for us at that very specific moment in time. 00:02:23.479 --> 00:02:28.399 So just to let you know, Netflix is not multicast. 00:02:28.399 --> 00:02:30.880 Netflix is unicast, okay? 00:02:30.880 --> 00:02:39.240 YouTube is unicast, Disney Plus is unicast, Amazon Prime is unicast, all of that stuff 00:02:39.240 --> 00:02:41.479 is unicast, why? 00:02:41.479 --> 00:02:48.440 Because when I want to watch something, I open up my account, I open up my app, I click 00:02:48.440 --> 00:02:55.639 on it, and I watch what I want to watch, when I want to watch it. 00:02:55.639 --> 00:03:00.160 And then you watch what you want to watch when you want to watch it, and if you want 00:03:00.160 --> 00:03:04.360 to pause it and go to the bathroom, you absolutely can, and that doesn't affect me, it doesn't 00:03:04.360 --> 00:03:09.399 affect anybody else, that is unicast. 00:03:09.399 --> 00:03:13.839 But think about it, if there's a million people watching that show, then there's a 00:03:13.839 --> 00:03:22.960 million different streams, there's a million different instances of that video playing. 00:03:22.960 --> 00:03:25.479 Now you might be saying, well, so why not multicast? 00:03:25.479 --> 00:03:27.220 Because it's the internet. 00:03:27.220 --> 00:03:32.279 For multicast to be used on the internet, that means every single service provider is 00:03:32.279 --> 00:03:37.160 going to have to get together and build a massive, giant multicast network to make that 00:03:37.160 --> 00:03:38.160 work. 00:03:39.160 --> 00:03:47.039 When we use multicast, we have to realize that you are now bound, essentially, by when 00:03:47.039 --> 00:03:52.360 the server is streaming it, versus when you want to watch it. 00:03:52.360 --> 00:03:59.720 So for example, if I say this is streaming at 1pm, out it goes, and if you're not watching 00:03:59.720 --> 00:04:04.399 it at 1pm, then you miss out. 00:04:04.399 --> 00:04:07.919 That's the difference between unicast and multicast, right? 00:04:07.960 --> 00:04:10.240 It's like broadcast television, right? 00:04:10.240 --> 00:04:14.000 It's like broadcast television back in the day, just a little bit different, because 00:04:14.000 --> 00:04:20.600 with broadcast television, we would broadcast to every single TV in that television provider's 00:04:20.600 --> 00:04:24.559 network, and then with your little knob, or your little flicker, or whatever you had at 00:04:24.559 --> 00:04:29.720 the time, on broadcast television, you would then tell your TV, I want to watch that. 00:04:29.720 --> 00:04:35.839 But your TV was getting every single stream all at the exact same time. 00:04:35.839 --> 00:04:43.399 But with multicast now, you actually tell the network what you want to join, what you 00:04:43.399 --> 00:04:44.920 want to watch. 00:04:44.920 --> 00:04:55.799 So modern day television, where you have thousands of channels, 4k, that is multicast within 00:04:55.799 --> 00:04:58.160 the service provider's network, right? 00:04:58.160 --> 00:05:02.920 It's not over the internet, it's over their multicast network that's using the same cable 00:05:02.920 --> 00:05:07.119 as your internet connection, but they're like different virtual networks in there, 00:05:07.119 --> 00:05:09.920 ones for the multicast stream for your TV, essentially. 00:05:09.920 --> 00:05:14.839 So when it's all said and done, when you want to watch, let's say, NFL football on Sunday, 00:05:14.839 --> 00:05:21.420 you know it's playing at, let's say, 1 o'clock, 1 in the afternoon, 1pm is kickoff time, Eastern. 00:05:21.420 --> 00:05:22.559 So what do you do? 00:05:22.559 --> 00:05:28.799 You go ahead and you click on that at 1 o'clock, and then you get to watch the stream. 00:05:28.799 --> 00:05:29.799 Now could you pause it? 00:05:29.799 --> 00:05:32.600 Yes, but that's only if you have a PVR or a DVR. 00:05:33.279 --> 00:05:37.480 If you didn't have that, you have no choice but to watch that stream at that moment in time. 00:05:38.480 --> 00:05:42.519 Right, so a PVR or DVR is only recording the multicast stream for you, so that way there 00:05:42.519 --> 00:05:46.920 you can rewind, pause, do whatever you want, and then catch up after the fact, that's all 00:05:46.920 --> 00:05:47.920 it's doing for you. 00:05:47.920 --> 00:05:51.880 But that multicast stream is going, and if you're not tuned in, you're not getting it. 00:05:54.880 --> 00:05:57.880 All right? 00:05:58.160 --> 00:06:04.279 So yes, typical television is multicast, on demand is unicast, essentially you can put 00:06:04.279 --> 00:06:05.279 it that way. 00:06:05.279 --> 00:06:06.279 All right? 00:06:06.279 --> 00:06:10.720 Because for it to be on demand, you need to be able to start it and stop it when you want 00:06:10.720 --> 00:06:12.799 to, not when they're streaming it. 00:06:12.799 --> 00:06:18.040 So even with your television provider, if you are watching it live, right then and there, 00:06:18.040 --> 00:06:19.040 that's your multicast stream. 00:06:19.040 --> 00:06:23.600 But if you're watching it later as a recording, on demand, playback, whatever they have as 00:06:23.600 --> 00:06:26.660 an additional feature, that would be unicast at that point in time as well. 00:06:27.440 --> 00:06:30.859 So typically they offer both nowadays, because that's what people want. 00:06:30.859 --> 00:06:33.859 If I missed it live, I want to go ahead and watch it. 00:06:33.859 --> 00:06:41.920 So the great thing about multicast is the extreme reduction in bandwidth. 00:06:41.920 --> 00:06:43.859 So think about an audio. 00:06:43.859 --> 00:06:47.500 If we had, for example, music on hold. 00:06:47.500 --> 00:06:56.619 If music on hold for voice over IP was unicast, as you can see, the number of people on hold 00:06:57.480 --> 00:07:05.140 the audio stream would significantly consume more and more traffic depending on the number 00:07:05.140 --> 00:07:06.820 of people on hold. 00:07:06.820 --> 00:07:12.559 So a hundred people on hold increases our traffic. 00:07:12.559 --> 00:07:14.420 But look at the multicast stream. 00:07:14.420 --> 00:07:20.700 A hundred people on hold with a multicast stream doesn't change the bandwidth. 00:07:20.700 --> 00:07:22.559 It's the same. 00:07:22.559 --> 00:07:25.059 It's the same. 00:07:25.059 --> 00:07:27.100 And why is that? 00:07:27.100 --> 00:07:32.540 Because there's only one stream going out, and then everybody's tapping into it. 00:07:32.540 --> 00:07:38.619 Whereas with unicast, everybody has their own stream all the way back to the server. 00:07:38.619 --> 00:07:44.959 Whereas a multicast, everybody's sharing the same stream when it's all said and done. 00:07:44.959 --> 00:07:47.059 So what does that mean for multicast? 00:07:47.059 --> 00:07:49.700 You need to have a network that can support this. 00:07:49.700 --> 00:07:53.420 That's why you don't see it used all over the internet, because the ISPs are not going 00:07:53.420 --> 00:07:58.660 to come together and build a nice, cohesive, wonderful multicast network that can be consumed 00:07:58.660 --> 00:07:59.660 by all. 00:07:59.660 --> 00:08:01.859 Because who's going to make the money off of that, right? 00:08:01.859 --> 00:08:05.859 They're going to constantly be in court over stuff like that. 00:08:05.859 --> 00:08:07.420 So it all starts with what? 00:08:07.420 --> 00:08:10.859 Making sure you have what is called multicast groups. 00:08:10.859 --> 00:08:18.260 So a multicast group, for example, 239.0.0.5. 00:08:18.260 --> 00:08:21.220 A multicast group is an IP address. 00:08:21.220 --> 00:08:27.220 And that specific IP address is associated with something very specific. 00:08:27.220 --> 00:08:33.979 So for example, if we just use a typical modern-day television company, they might have, for example, 00:08:33.979 --> 00:08:38.479 channel 621 is a certain multicast group address. 00:08:38.479 --> 00:08:42.219 Channel 632 is a certain multicast group address. 00:08:42.219 --> 00:08:44.539 Channel 6 is a different multicast group. 00:08:44.539 --> 00:08:50.659 So when you click on the guide and you say, I want this channel, you are basically telling 00:08:50.659 --> 00:09:01.820 the network you want the stream for that particular group. 00:09:01.820 --> 00:09:06.859 Now when it comes to multicast addressing, there are many different ranges of multicast 00:09:06.859 --> 00:09:07.859 addresses. 00:09:07.859 --> 00:09:13.460 Remember, when we had our OSPF discussion, we did 224.0.0.5 and 6. 00:09:13.460 --> 00:09:15.940 And then for EIGRP, we have 224.0.0.10. 00:09:16.940 --> 00:09:21.900 Remember I said those were non-routable multicast addresses, meaning they're not even routable 00:09:21.900 --> 00:09:23.380 inside your network, outside your network. 00:09:23.380 --> 00:09:26.260 It says right here, look at this, non-routable. 00:09:26.260 --> 00:09:27.880 These are for local subnetworks. 00:09:27.880 --> 00:09:30.940 So that's why it makes sense to use those for EIGRP and OSPF. 00:09:30.940 --> 00:09:35.940 So you're not going to use those for multicast streaming, as an example. 00:09:35.940 --> 00:09:39.940 And if you notice here, there's some that are reserved for internet control, ad hoc 00:09:39.940 --> 00:09:44.719 blocks, source-specific multicast, glop addressing, not exam relevant. 00:09:44.719 --> 00:09:50.119 But you'll see here that typically the 239 range, administratively scoped, is what would 00:09:50.119 --> 00:09:53.919 be utilized for multicast networks for streaming services. 00:09:53.919 --> 00:09:55.479 When I say streaming, I don't mean Netflix, remember. 00:09:55.479 --> 00:10:02.640 I mean streaming inside your corporate environment, videos, audio, whatever it needs to be. 00:10:02.640 --> 00:10:07.760 And when I say stream, I mean like continuous streaming of stuff that if you're not tuned 00:10:07.760 --> 00:10:11.320 in at this particular time, you don't get to watch it or listen to it. 00:10:11.320 --> 00:10:13.039 Music on hold's a good example, right? 00:10:13.039 --> 00:10:16.799 When you're on hold, you just pick up wherever that music is. 00:10:16.799 --> 00:10:19.679 You don't get – you don't start at the beginning of that audio file. 00:10:19.679 --> 00:10:23.039 You just pick up wherever that music is when you're put on hold. 00:10:29.039 --> 00:10:31.119 So typically, we'll be in this range down here. 00:10:31.119 --> 00:10:34.479 But if you're using source-specific multicast, then you'll be in this range right here. 00:10:34.479 --> 00:10:37.039 We'll talk about source-specific multicast a little later. 00:10:38.039 --> 00:10:45.039 So, the range is from 224 for multicast all the way up to 239, 255, 255, 255. 00:10:45.039 --> 00:10:50.039 So, you would have to create your groups in order to make this work. 00:10:50.039 --> 00:10:52.039 Now, you're not going to have to create groups on the exam. 00:10:52.039 --> 00:10:53.039 That's perfectly fine. 00:10:53.039 --> 00:10:57.039 But then your apps and services are going to have to be designed for those particular groups. 00:10:57.039 --> 00:11:01.039 For example, we'd have to have an app on this, right? 00:11:01.039 --> 00:11:07.039 Either a web app or a desktop-related app. 00:11:07.039 --> 00:11:09.039 So, it could be an app that's in the web browser. 00:11:09.039 --> 00:11:10.039 It could be an app that's on the desktop. 00:11:10.039 --> 00:11:14.039 Whatever it is, that gives us the ability to pick and choose our multicast group. 00:11:14.039 --> 00:11:17.039 So, on the phone, you put the hold button or you're put on hold. 00:11:17.039 --> 00:11:21.039 It automatically then joins you to that particular multicast group. 00:11:21.039 --> 00:11:29.039 So, let's say this button right here, this button is linked to 239.0.0.5 in that actual app. 00:11:31.039 --> 00:11:38.039 So, whenever I push that button or maybe the whole app is associated with that group maybe, right? 00:11:38.039 --> 00:11:40.039 It really all depends on how you've developed it. 00:11:40.039 --> 00:11:43.039 But in the end, what it does is it triggers you. 00:11:43.039 --> 00:11:50.039 It triggers you to send out a message that then modifies what's happening here. 00:11:50.039 --> 00:12:00.039 That's right. I said modifies what's happening here for you to get your stream. 00:12:00.039 --> 00:12:10.039 It's the network that changes to deliver your stream when we deal with multicast. 00:12:10.039 --> 00:12:13.039 So, think about your television right now. 00:12:13.039 --> 00:12:19.039 And you're using a guided television service from your service provider. 00:12:19.039 --> 00:12:23.039 And you want to watch, let's say, channel 621. 00:12:23.039 --> 00:12:26.039 Let's say, let's just pretend that, ooh, the golf channel. 00:12:26.039 --> 00:12:29.039 No one else in your neighborhood likes golf. 00:12:29.039 --> 00:12:31.039 They hate golf. 00:12:31.039 --> 00:12:33.039 So, nobody's ever watching it. 00:12:33.039 --> 00:12:35.039 What would that mean in that particular case? 00:12:35.039 --> 00:12:38.039 Let's say this is your entire neighborhood. 00:12:38.039 --> 00:12:40.039 This is your neighborhood. 00:12:40.039 --> 00:12:44.039 All of these are TVs. 00:12:44.039 --> 00:12:52.039 Then that means the stream, if nobody's watching golf channel, the stream is never coming to your neighborhood. 00:12:52.039 --> 00:12:58.039 But then as soon as you click on this, channel 621, what does that do? 00:12:58.039 --> 00:13:04.039 It triggers a message to be sent, which ultimately then forces the network, 00:13:04.039 --> 00:13:14.039 the network to send the stream down to you. 00:13:14.039 --> 00:13:19.039 And now let's say your neighbor down the road turns around and they're like, 00:13:19.039 --> 00:13:22.039 oh, I don't really like golf, but there's nothing else on TV, 00:13:22.039 --> 00:13:24.039 so I'm going to go to channel 621 and watch golf today. 00:13:24.039 --> 00:13:28.039 They push the button, and then what happens? 00:13:28.039 --> 00:13:31.039 They send out a message, but great news, the stream's already here. 00:13:31.039 --> 00:13:32.039 The stream's already here. 00:13:32.039 --> 00:13:33.039 So, what does that mean? 00:13:33.039 --> 00:13:35.039 Just send it from here. 00:13:35.039 --> 00:13:36.039 Just send it from here. 00:13:36.039 --> 00:13:37.039 That's it. 00:13:37.039 --> 00:13:38.039 Done. 00:13:38.039 --> 00:13:41.039 So, notice that the bandwidth has not changed here. 00:13:41.039 --> 00:13:43.039 The bandwidth is steady. 00:13:43.039 --> 00:13:48.039 The only thing here is we've had to duplicate it and send it down to the TVs as an example. 00:13:48.039 --> 00:13:49.039 That's it. 00:13:49.039 --> 00:13:53.039 I'm just trying to give you a real-world example of what multicast does for us. 00:13:53.039 --> 00:13:56.039 So, in your environment, if you have videos you want to stream all day long 00:13:56.039 --> 00:13:59.039 or you have audio you want to stream all day long, 00:13:59.039 --> 00:14:03.039 and it's not something that a user has to start or stop from the beginning 00:14:03.039 --> 00:14:06.039 or anything like that, then multicast might be the thing you want to do in the environment 00:14:06.039 --> 00:14:10.039 to make sure that that audio and video is not consuming more bandwidth 00:14:10.039 --> 00:14:14.039 than you absolutely want it to when it's all said and done. 00:14:14.039 --> 00:14:20.039 So, protocols used by multicast that you need to know for the exam are IGMP and PIM. 00:14:20.039 --> 00:14:26.039 IGMP is what? 00:14:26.039 --> 00:14:33.039 It's used between hosts and what does it say there? 00:14:33.039 --> 00:14:35.039 Routers. 00:14:35.039 --> 00:14:38.039 Hosts and routers. 00:14:38.039 --> 00:14:42.039 IGMP stands for Internet Group Management Protocol. 00:14:42.039 --> 00:14:44.039 Internet Group Management Protocol. 00:14:44.039 --> 00:14:46.039 And it's used between what? 00:14:46.039 --> 00:14:47.039 Hosts and routers. 00:14:47.039 --> 00:14:48.039 Remember that for the exam. 00:14:48.039 --> 00:14:49.039 Hosts and routers. 00:14:49.039 --> 00:14:50.039 What is a host? 00:14:50.039 --> 00:14:51.039 Your PCs. 00:14:51.039 --> 00:14:52.039 What is the router? 00:14:52.039 --> 00:15:02.039 The default gateway. 00:15:02.039 --> 00:15:04.039 So, we would be running IGMP here. 00:15:04.039 --> 00:15:08.039 So, for example, we would be running IGMP in here. 00:15:08.039 --> 00:15:11.039 We would be running IGMP in here. 00:15:11.039 --> 00:15:12.039 That's where we would be running it. 00:15:12.039 --> 00:15:14.039 It wouldn't be running in here. 00:15:14.039 --> 00:15:18.039 It would be running here. 00:15:18.039 --> 00:15:24.039 And so, with IGMP now, we are going to be able to communicate between our hosts 00:15:24.039 --> 00:15:29.039 and our routers so that way we can join, leave, or remain in a group. 00:15:29.039 --> 00:15:31.039 Join, leave, or remain in a group. 00:15:31.039 --> 00:15:34.039 Remember that. 00:15:34.039 --> 00:15:36.039 Your goal here is to be able to describe multicast protocols. 00:15:36.039 --> 00:15:39.039 That's what we're doing right now for the exam. 00:15:39.039 --> 00:15:44.039 So, for example, here's my default gateway. 00:15:44.039 --> 00:15:48.039 Remember, we have redundant default gateways, so let's get that out of the way first. 00:15:48.039 --> 00:15:55.039 If I have more than one default gateway like we have here, one of them has to be elected 00:15:55.039 --> 00:16:00.039 as the overseer of this IGMP environment. 00:16:00.039 --> 00:16:02.039 So, we definitely want to line this up with who? 00:16:02.039 --> 00:16:03.039 We want to line this up with our default gateway. 00:16:03.039 --> 00:16:05.039 We want to line this up with our what? 00:16:05.039 --> 00:16:09.039 Our spanning tree protocol root bridge as an example. 00:16:09.039 --> 00:16:19.039 So, in this case, it's going to be this one here. 00:16:19.039 --> 00:16:23.039 And so, this is the one that's going to be responsible for everything, and this will be its backup 00:16:23.039 --> 00:16:26.039 when it's all said and done. 00:16:26.039 --> 00:16:30.039 Remember, you don't have to configure this or verify this or set this up, any of this. 00:16:30.039 --> 00:16:37.039 It's about understanding that we are going to have to have one and only one device responsible 00:16:37.039 --> 00:16:44.039 for IGMP in that environment, even if there's multiple gateways. 00:16:44.039 --> 00:16:48.039 And by default, it'll be the one with the lower interface IP address, but obviously, 00:16:48.039 --> 00:16:51.039 it's something that you can manipulate if you want to manually. 00:16:51.039 --> 00:16:59.039 We call this also the IGMP query, courier? 00:16:59.039 --> 00:17:05.040 Yes, courier, the IGMP courier. 00:17:05.040 --> 00:17:11.040 So, your client, whenever you open the app, click something, whatever it is. 00:17:11.040 --> 00:17:13.040 Let's say you want to join this group. 00:17:13.040 --> 00:17:14.040 How do you know you're joining that group? 00:17:14.040 --> 00:17:15.040 You don't. 00:17:15.040 --> 00:17:18.040 What you know is you want to watch this, you want to listen to that, you want to do this, 00:17:18.040 --> 00:17:21.040 and the app is telling you what you have access to. 00:17:21.040 --> 00:17:23.040 And remember, this is already streaming. 00:17:23.040 --> 00:17:24.040 How far? 00:17:24.040 --> 00:17:28.040 Well, if nobody's using it, then it's only streaming this far. 00:17:28.040 --> 00:17:30.040 That's it. 00:17:30.040 --> 00:17:33.040 But let's say somebody down here is already watching it, then it's streaming over here 00:17:33.040 --> 00:17:37.040 potentially right now. 00:17:37.040 --> 00:17:38.040 So, it really depends. 00:17:38.040 --> 00:17:40.040 Is anybody watching it or not? 00:17:40.040 --> 00:17:41.040 Nobody's watching it? 00:17:41.040 --> 00:17:45.040 Then the stream only goes as far as its own default gateway. 00:17:45.040 --> 00:17:48.040 If people are watching it, then it's already throughout the environment. 00:17:48.040 --> 00:17:49.040 So, you want to join? 00:17:49.040 --> 00:17:50.040 What do you do? 00:17:50.040 --> 00:17:52.040 You send an IGMP report. 00:17:52.040 --> 00:18:00.040 So, to join, you send what is called an IGMP report. 00:18:00.040 --> 00:18:05.040 So, what I'm doing is I'm sending this message out, and it's a non-routable message, meaning 00:18:05.040 --> 00:18:11.040 that it only stays within my subnet, my VLAN, my broadcast domain. 00:18:11.040 --> 00:18:12.040 And then what's going to happen? 00:18:12.040 --> 00:18:16.040 Well, this is the router that's responsible for joining me to groups and doing all of 00:18:16.040 --> 00:18:18.040 that stuff right now. 00:18:18.040 --> 00:18:20.040 So, it eventually gets to that device. 00:18:20.040 --> 00:18:24.040 And again, right, if that's the root bridge, that's our active forwarder, it makes sense 00:18:24.040 --> 00:18:28.040 to line this up because traffic's going to flow this way for that subnet, that VLAN, 00:18:28.040 --> 00:18:29.040 that broadcast domain. 00:18:29.040 --> 00:18:35.040 So, we want to make sure that it's not doing something like this in order to get there. 00:18:35.040 --> 00:18:39.040 So, again, your Layer 2 network has to be designed properly to make sure we get the 00:18:39.040 --> 00:18:46.040 best performance out of all of this stuff. 00:18:46.040 --> 00:18:53.040 Now, once that happens, this router, if the stream is already coming to it, it'll then 00:18:53.040 --> 00:18:56.040 just send the stream down to that user. 00:18:56.040 --> 00:19:00.040 If the stream's not already coming to it, then it has to use PIM. 00:19:00.040 --> 00:19:04.040 So, PIM, that we'll talk about later, is used up here. 00:19:04.040 --> 00:19:07.040 So, IGMP is only used here, as we said. 00:19:07.040 --> 00:19:10.040 PIM's used up here. 00:19:10.040 --> 00:19:14.040 And now, I'm not talking about PIM particles, all right, if you're a Marvel MCU fan or any 00:19:14.040 --> 00:19:19.040 type of Marvel fan, and not PIM particles, all right, just protocol independent multicast 00:19:19.040 --> 00:19:22.040 PIM. 00:19:23.040 --> 00:19:29.040 So, PIM would then be used from here to here in order to get the stream down to DSW1. 00:19:29.040 --> 00:19:35.040 So, let's say the stream now comes down here. 00:19:35.040 --> 00:19:37.040 So, IGMP's in here. 00:19:37.040 --> 00:19:39.040 Important for your exam. 00:19:39.040 --> 00:19:42.040 All right, so now, what happens now? 00:19:42.040 --> 00:19:49.040 Well, the stream can now go down to the user. 00:19:49.040 --> 00:19:55.040 Anytime you want to leave the group, maybe you close the app, you hit X, anything like 00:19:55.040 --> 00:19:59.040 that, then you automatically send an IGMP leave. 00:19:59.040 --> 00:20:01.040 Obviously, you have to be coded to do that. 00:20:01.040 --> 00:20:05.040 If you're not coded to do that, probably in the app, then it's not going to happen, okay? 00:20:05.040 --> 00:20:21.040 So, join is an IGMP report, and to leave, it is an IGMP leave. 00:20:21.040 --> 00:20:26.040 So, when I want to leave a group, I'll send up my message. 00:20:26.040 --> 00:20:32.040 The default gateway gets it. 00:20:32.040 --> 00:20:34.040 And then, what's going to happen? 00:20:34.040 --> 00:20:38.040 Well, the default gateway is not going to stop the stream, because you have to remember 00:20:38.040 --> 00:20:42.040 that the stream is coming down to here, and then I'm branched off of that. 00:20:42.040 --> 00:20:47.040 So, if the default gateway stops the stream, then that means anybody else down here would 00:20:47.040 --> 00:20:50.040 no longer get the stream as well. 00:20:50.040 --> 00:20:52.040 So, DSW1 has to be careful here. 00:20:52.040 --> 00:20:57.040 Remember, it's called the IGMP querier, and that's called that for a reason, because now 00:20:57.040 --> 00:20:58.040 it has to query. 00:20:59.040 --> 00:21:08.040 It has to send out a message, a query message, asking if anyone else still needs the stream 00:21:08.040 --> 00:21:09.040 for that group. 00:21:09.040 --> 00:21:16.040 So, when I say I'm leaving 239005, when the router gets it, it then has to send a message 00:21:16.040 --> 00:21:21.040 saying anybody else still need the stream for 239005. 00:21:21.040 --> 00:21:25.040 If no one responds, then I cut the stream off. 00:21:29.040 --> 00:21:34.040 If at least one device responds, then I don't cut the stream off, which means the stream 00:21:34.040 --> 00:21:36.040 will keep going down to here. 00:21:36.040 --> 00:21:39.040 But the thing is, is you no longer have the app open. 00:21:39.040 --> 00:21:40.040 You've closed the app. 00:21:40.040 --> 00:21:41.040 You're done with it. 00:21:41.040 --> 00:21:42.040 What does that mean? 00:21:42.040 --> 00:21:46.040 It means you're not going to get it anymore, because the switch down here is going to make 00:21:46.040 --> 00:21:50.040 sure you don't get it anymore by adjusting its multicast table. 00:21:52.040 --> 00:22:05.040 Periodically, the querier is going to send out IGMP queries, periodically, just to ask, 00:22:05.040 --> 00:22:07.040 hey, anybody down here still need a stream? 00:22:07.040 --> 00:22:08.040 Anybody down here? 00:22:08.040 --> 00:22:09.040 Why? 00:22:09.040 --> 00:22:15.040 Because there is never, there is never a, there's no table or anything, for example, 00:22:15.040 --> 00:22:19.040 on DSW1 that says, oh, I'm sending a stream to so and so and so and so and so and so and 00:22:19.040 --> 00:22:24.040 so in that particular regard, meaning I'm not keeping track of stateful streams, as 00:22:24.040 --> 00:22:25.040 an example. 00:22:25.040 --> 00:22:30.040 So because of that, I have to query every so often to determine if there's anyone out 00:22:30.040 --> 00:22:33.040 there that still needs the stream. 00:22:33.040 --> 00:22:35.040 And if nobody responds, then I'll stop the stream. 00:22:35.040 --> 00:22:38.040 But if one device at least responds, then I'll keep the stream up and running. 00:22:38.040 --> 00:22:42.040 This is also important, because if there's ever a failure of the network down here, if 00:22:42.040 --> 00:22:46.040 there's ever a failure, then that means no leave messages would have been sent, which 00:22:46.040 --> 00:22:51.040 means the router is going to keep sending messages, because it doesn't know otherwise. 00:22:51.040 --> 00:22:57.040 So if it sends out a query periodically, and there's a network disaster down here somewhere, 00:22:57.040 --> 00:23:03.040 then it will at least know, oh, nobody's responded, I can stop the stream now. 00:23:03.040 --> 00:23:06.040 So these are the little things I want you to remember for the certification exam when 00:23:06.040 --> 00:23:13.040 it comes to IGMP joins, so the IGMP report, the query, and the leave message. 00:23:14.040 --> 00:23:20.040 Now, we have two versions that you can utilize today for IGMP, version 2 and version 3. 00:23:20.040 --> 00:23:28.040 The main thing I want you to remember about the difference between these two is in regards 00:23:28.040 --> 00:23:37.040 to your ability to specify a source of the stream or not to be able to specify the source 00:23:37.040 --> 00:23:39.040 of the stream. 00:23:39.040 --> 00:23:46.040 With IGMP v2, you cannot specify the source of a stream. 00:23:46.040 --> 00:23:56.040 With IGMP v2, it's known as star comma G, so that's source comma destination. 00:23:56.040 --> 00:24:07.040 So star in this case equals any source, and then G equals the group number, meaning that 00:24:07.040 --> 00:24:18.040 when I send out my IGMP message using IGMP version 2, it would be star comma 239.0.0.5. 00:24:18.040 --> 00:24:27.040 So any source that is providing that particular stream for 239.0.0.5. 00:24:27.040 --> 00:24:32.040 Now, if you notice here, I have two servers, so that means I could end up with a stream 00:24:32.040 --> 00:24:37.040 from either of those two servers, and in reality, that's fine. 00:24:37.040 --> 00:24:40.040 Nothing wrong with that. 00:24:40.040 --> 00:24:49.040 But the question now is, what if there's a rogue device over here? 00:24:49.040 --> 00:25:00.040 Somebody managed to set up a rogue server that is streaming inappropriate content. 00:25:00.040 --> 00:25:06.040 Let's say its address is 10.0.120.5. 00:25:06.040 --> 00:25:10.040 It's streaming inappropriate content. 00:25:10.040 --> 00:25:16.040 Well, then that means because it says star for any source, and it's streaming inappropriate 00:25:16.040 --> 00:25:24.040 content for 239.0.0.5, is it possible that some of the users are going to end up with 00:25:25.040 --> 00:25:32.040 the inappropriate content if we're using IGMP v2? 00:25:32.040 --> 00:25:39.040 Of course, because you're saying any source providing that stream. 00:25:39.040 --> 00:25:44.040 So whatever one you get is what you get. 00:25:44.040 --> 00:25:50.040 So there is a lack of security, as you can see in this particular case. 00:25:50.040 --> 00:25:56.040 And anybody who introduces a rogue server streaming for that group could ultimately 00:25:56.040 --> 00:26:01.040 interfere with our stream. 00:26:01.040 --> 00:26:17.040 With IGMP v3, you'll see here that we can do what is called source-specific multicast. 00:26:17.040 --> 00:26:21.040 So we have the opportunity to do the same thing that we saw here, but we have the opportunity 00:26:21.040 --> 00:26:23.040 to do this as well now. 00:26:23.040 --> 00:26:25.040 So IGMP v3 is the better option. 00:26:25.040 --> 00:26:28.040 And it is not compatible with v2. 00:26:28.040 --> 00:26:32.040 It's not compatible with v1, which I don't even have listed here because you don't really 00:26:32.040 --> 00:26:33.040 want to use v1. 00:26:33.040 --> 00:26:36.040 But IGMP v2 is compatible with v1. 00:26:36.040 --> 00:26:40.040 So v1 and v2 are compatible, but v3 is not compatible with any of them. 00:26:40.040 --> 00:26:44.040 Remember that. 00:26:44.040 --> 00:26:47.040 But in this case here, s, g. 00:26:47.040 --> 00:26:48.040 So what does that mean? 00:26:48.040 --> 00:26:50.040 It means we can be very specific. 00:26:50.040 --> 00:26:55.040 So s equals specific source. 00:26:55.040 --> 00:26:59.040 And g equals group number. 00:26:59.040 --> 00:27:00.040 So what does that mean? 00:27:00.040 --> 00:27:10.040 It means that when you click on something, now we could have 10.0.100.18 as the source, 00:27:10.040 --> 00:27:14.040 with the group being 239.0.0.5. 00:27:14.040 --> 00:27:20.040 So now if this stream is actually there sending out, I'm not going to get it because it's 00:27:20.040 --> 00:27:23.040 source-specific multicast. 00:27:23.040 --> 00:27:28.040 So if you're ever asked which is more secure, it's IGMP v3 because why? 00:27:28.040 --> 00:27:35.040 Source-specific multicast. 00:27:35.040 --> 00:27:38.040 Now, there are other things about it too, but it's way beyond the scope of the course 00:27:38.040 --> 00:27:39.040 and certification exam, folks. 00:27:39.040 --> 00:27:44.040 And you would learn all about the intricate details of all of this stuff in multicast 00:27:44.040 --> 00:27:50.040 courses, which are large courses in and of themselves. 00:27:50.040 --> 00:27:56.040 Lastly, what I want to point out to you is that your switch, by default, doesn't understand 00:27:56.040 --> 00:27:59.040 the difference between multicast and broadcast. 00:27:59.040 --> 00:28:03.040 It thinks they are the exact same. 00:28:03.040 --> 00:28:04.040 So what does that mean? 00:28:04.040 --> 00:28:07.040 It means when a multicast message comes down, it gets flooded out all ports except the port 00:28:07.040 --> 00:28:13.040 it came in on in that subnet, in that VLAN, in that broadcast domain, just like broadcast 00:28:13.040 --> 00:28:18.040 traffic and unknown unicast traffic. 00:28:18.040 --> 00:28:21.040 So you can think of this as unknown traffic. 00:28:21.040 --> 00:28:24.040 So it gets flooded out all ports except the port it came in on. 00:28:24.040 --> 00:28:30.040 We don't want that because what that means is that if somebody wants the stream, then 00:28:30.040 --> 00:28:35.040 everybody automatically gets it, whether you have the app open or not, which means your 00:28:35.040 --> 00:28:40.040 PC has to constantly get those multicast frames, process them, and discard them, discard 00:28:40.040 --> 00:28:46.040 them, discard them, discard them, which results in your CPU on your PC having to do work that 00:28:46.040 --> 00:28:48.040 you don't want it to do. 00:28:48.040 --> 00:28:54.040 So that would absolutely increase the bandwidth and resource consumption of your PC's CPU. 00:28:54.040 --> 00:28:59.040 So what you need to do is you need to make sure that you have the ability to filter that 00:28:59.040 --> 00:29:01.040 multicast traffic on your access layer switches. 00:29:02.040 --> 00:29:05.040 And that's where IGMP snooping comes into play. 00:29:05.040 --> 00:29:12.040 So with IGMP snooping, when you turn it on, you are snooping, sniffing out multicast packets. 00:29:12.040 --> 00:29:19.040 So when you realize that an IGMP report message, a join message comes in, then you'll have 00:29:19.040 --> 00:29:25.040 the ability to make a note in your multicast table that the traffic only goes out this 00:29:25.040 --> 00:29:27.040 way right now for that. 00:29:27.040 --> 00:29:28.040 It doesn't go out anywhere else. 00:29:28.040 --> 00:29:32.040 And then if this PC joins, then you know that you're going to want to send it out this way 00:29:32.040 --> 00:29:33.040 as well. 00:29:33.040 --> 00:29:38.040 And then when the leave message comes, then you can remove that so it no longer goes that 00:29:38.040 --> 00:29:39.040 way. 00:29:39.040 --> 00:29:44.040 So the IGMP snooping feature permits the switch to forward multicast frames for them instead 00:29:44.040 --> 00:29:49.040 of flooding them, and therefore reduce bandwidth consumption for your multicast stream to the 00:29:49.040 --> 00:29:50.040 end users. 00:29:52.040 --> 00:29:54.040 All right, so that's just IGMP. 00:29:54.040 --> 00:29:59.040 Now we want to talk about PIMP, Protocol Independent Multicast, so you can pick it out of the 00:29:59.040 --> 00:30:01.040 lineup on the certification exam. 00:30:01.040 --> 00:30:03.040 So you already know the difference between the two, right? 00:30:03.040 --> 00:30:07.040 We said IGMP works between the PCs and their default gateway. 00:30:07.040 --> 00:30:10.040 So for example, IGMP would be running here. 00:30:10.040 --> 00:30:14.040 But PIMP, PIMP would be running, for example, 00:30:21.040 --> 00:30:22.040 I'll have to draw this. 00:30:22.040 --> 00:30:23.040 Did you get the picture? 00:30:23.040 --> 00:30:28.040 On every other router interface, that goes to another router. 00:30:28.040 --> 00:30:33.040 So I'm running PIMP here, here, here, here, here, here, here. 00:30:33.040 --> 00:30:36.040 I'm running PIMP here, here, here, here, here, here, here. 00:30:36.040 --> 00:30:38.040 That's a better way to represent it. 00:30:38.040 --> 00:30:40.040 I'm running PIMP in all of those places. 00:30:40.040 --> 00:30:41.040 Why? 00:30:41.040 --> 00:30:48.040 So we can build what is called our multicast tree, used by our routers to build the multicast 00:30:48.040 --> 00:30:49.040 tree. 00:30:49.040 --> 00:30:50.040 Remember that. 00:30:50.040 --> 00:30:52.040 And the multicast tree is going to be used to what? 00:30:52.040 --> 00:30:54.040 Forward multicast stream through the network. 00:30:54.040 --> 00:30:57.040 Now, let's be clear about something here as well. 00:30:57.040 --> 00:31:04.040 You still have to have an underlying dynamic routing protocol for unicast traffic running. 00:31:04.040 --> 00:31:08.040 OSPF, EIGRP, ISAS is an example. 00:31:08.040 --> 00:31:14.040 You need to have full, full, full unicast connectivity with your dynamic routing protocols 00:31:14.040 --> 00:31:17.040 before you can even set up multicast. 00:31:17.040 --> 00:31:21.040 Because multicast PIMP just runs on top of everything. 00:31:21.040 --> 00:31:28.040 And the decisions PIMP typically makes is going to be based on what? 00:31:28.040 --> 00:31:33.040 The underlying decisions that your dynamic routing protocols have already made. 00:31:33.040 --> 00:31:36.040 Or your static routing has already made. 00:31:36.040 --> 00:31:43.040 So essentially, you need to have a fully developed network using static routing, dynamic routing 00:31:43.040 --> 00:31:48.040 underneath, so that way their PIMP can do its job. 00:31:48.040 --> 00:31:54.040 So the multicast table is essentially going to be built based on what your unicast protocols 00:31:54.040 --> 00:32:00.040 have already decided about the best, quickest, shortest way to forward traffic. 00:32:00.040 --> 00:32:04.040 So PIMP runs on top of all that stuff. 00:32:04.040 --> 00:32:07.040 So PIMP has different modes, and you'll be able to have to pick them out of the lineup 00:32:07.040 --> 00:32:13.040 of the exam potentially. 00:32:13.040 --> 00:32:16.040 Dense mode, sparse mode, sparse dense mode, and bidirectional. 00:32:16.040 --> 00:32:20.040 So basically, what I have on the slides is going to help you prepare for the exam. 00:32:20.040 --> 00:32:21.040 So what is dense mode? 00:32:21.040 --> 00:32:25.040 First and foremost, we call it one to many. 00:32:25.040 --> 00:32:27.040 One to many, which means what? 00:32:27.040 --> 00:32:30.040 One source going to many different devices. 00:32:30.040 --> 00:32:33.040 So one source here, server here. 00:32:33.040 --> 00:32:34.040 That's my server. 00:32:34.040 --> 00:32:35.040 That's my source. 00:32:35.040 --> 00:32:39.040 And then you've got many, many, many, many different clients that want that stream, that 00:32:39.040 --> 00:32:40.040 multicast stream. 00:32:40.040 --> 00:32:42.040 It is a push model. 00:32:42.040 --> 00:32:43.040 Remember that. 00:32:43.040 --> 00:32:44.040 Push model. 00:32:44.040 --> 00:32:46.040 If you don't know that, don't sit for the exam. 00:32:46.040 --> 00:32:48.040 A push model that what? 00:32:48.040 --> 00:32:53.040 Floods multicast to every corner of the network, regardless of users wanting the stream or 00:32:53.040 --> 00:32:54.040 not. 00:32:54.040 --> 00:32:55.040 This is how it starts up. 00:32:55.040 --> 00:33:01.040 So when I start this multicast stream up, what's going to happen with PIMP is that it's 00:33:01.040 --> 00:33:03.040 going to flood that stream everywhere. 00:33:03.040 --> 00:33:08.040 It's going to flood it everywhere to all the routers with PIMP. 00:33:08.040 --> 00:33:09.040 So it's not going to go right down to the users. 00:33:09.040 --> 00:33:12.040 It's going to go right to the edge routers. 00:33:12.040 --> 00:33:20.040 Or right to the edge, I should say, of those environments to those routers. 00:33:20.040 --> 00:33:25.040 But it's not going to go into the IGMP environment. 00:33:25.040 --> 00:33:26.040 All right. 00:33:26.040 --> 00:33:27.040 So there you go. 00:33:27.040 --> 00:33:28.040 It's going to start there. 00:33:28.040 --> 00:33:29.040 Beautiful. 00:33:29.040 --> 00:33:32.040 So this is essentially what's going to happen here in the beginning. 00:33:32.040 --> 00:33:34.040 We push it out. 00:33:34.040 --> 00:33:41.040 And then what has to happen, the routers are going to build the tree backwards, backwards, 00:33:41.040 --> 00:33:44.040 backwards, backwards, backwards. 00:33:44.040 --> 00:33:49.040 So let's say there is somebody here that wants the stream. 00:33:49.040 --> 00:33:53.040 And there is somebody here that wants the stream. 00:33:53.040 --> 00:33:54.040 What does that mean? 00:33:54.040 --> 00:33:56.040 It means this router is like, well, nobody wants the stream. 00:33:56.040 --> 00:34:00.040 So using PIMP, they're going to stop that from happening. 00:34:00.040 --> 00:34:02.040 Nobody here wants it. 00:34:02.040 --> 00:34:04.040 So that'll be removed. 00:34:04.040 --> 00:34:06.040 Nobody over here wants it. 00:34:06.040 --> 00:34:07.040 So this can be removed. 00:34:07.040 --> 00:34:09.040 Nobody over here wants it. 00:34:09.040 --> 00:34:10.040 So this can be removed. 00:34:10.040 --> 00:34:12.040 Nobody in here wants it. 00:34:12.040 --> 00:34:13.040 So that can be removed. 00:34:13.040 --> 00:34:14.040 Nobody there. 00:34:14.040 --> 00:34:16.040 So that can be removed. 00:34:16.040 --> 00:34:17.040 All right. 00:34:17.040 --> 00:34:18.040 Now we have our tree. 00:34:18.040 --> 00:34:23.040 So our tree looks like this right now. 00:34:23.040 --> 00:34:25.040 And then let's say somebody else wants it here after. 00:34:25.040 --> 00:34:26.040 Well, that's easy. 00:34:26.040 --> 00:34:28.040 I send my IGMP message. 00:34:28.040 --> 00:34:30.040 PIMP tells this router who tells this router. 00:34:30.040 --> 00:34:33.040 And then they send the stream from there down to here. 00:34:33.040 --> 00:34:35.040 So that's the job of PIMP. 00:34:35.040 --> 00:34:38.040 And so dense mode is flood and prune. 00:34:38.040 --> 00:34:39.040 Remember that. 00:34:39.040 --> 00:34:42.040 Flood it out and then prune back. 00:34:42.040 --> 00:34:45.040 It was the very first version of multicast. 00:34:45.040 --> 00:34:52.040 So really great for environments where you have large amounts of receivers everywhere that need this stream. 00:34:52.040 --> 00:34:57.040 The basic assumption behind dense mode is that everyone wants this, 00:34:57.040 --> 00:35:02.040 or more than 50% of the users out there need this stream. 00:35:02.040 --> 00:35:09.040 So we might as well just get it as fast as we can to all the different destinations that are out there where the users live. 00:35:09.040 --> 00:35:12.040 And then whoever doesn't need it will just pull back from there. 00:35:12.040 --> 00:35:25.040 So that way there we can just get it out there as fast as possible. 00:35:25.040 --> 00:35:28.040 So sparse mode is the complete opposite. 00:35:28.040 --> 00:35:33.040 So sparse mode is still one of many, but it's a pull model. 00:35:33.040 --> 00:35:39.040 And it's going to deliver the multicast streams to only those networks with end users that have requested the stream. 00:35:39.040 --> 00:35:41.040 So, for example, here's your server. 00:35:41.040 --> 00:35:43.040 The stream only goes this far. 00:35:43.040 --> 00:35:47.040 Remember, with flood and prune, the stream goes all the way there and then gets pulled back. 00:35:47.040 --> 00:35:49.040 With sparse mode, that's it. 00:35:49.040 --> 00:35:50.040 Boom. 00:35:50.040 --> 00:35:51.040 There's your stream. 00:35:51.040 --> 00:35:53.040 Until people start asking for it. 00:35:53.040 --> 00:35:55.040 So let's say you have your user here. 00:35:55.040 --> 00:35:57.040 I ask for it using IGMP. 00:35:57.040 --> 00:36:08.040 PIM is then used to tell this router, who then tells this router, who then sends the stream. 00:36:08.040 --> 00:36:11.040 And so then all of a sudden there's a user here that comes online. 00:36:11.040 --> 00:36:13.040 I use IGMP to tell this router. 00:36:13.040 --> 00:36:15.040 This router uses PIM to tell this router. 00:36:15.040 --> 00:36:16.040 There you go. 00:36:16.040 --> 00:36:19.040 The stream is now there. 00:36:19.040 --> 00:36:22.040 And so on and so forth. 00:36:22.040 --> 00:36:32.040 So from the beginning, the very beginning, we just start the stream and it doesn't go anywhere unless people are asking for it. 00:36:32.040 --> 00:36:37.040 So in this particular case, it's really good for those environments where your users are sparse. 00:36:37.040 --> 00:36:43.040 Only a few users need it here sometimes, over here sometimes, over here sometimes, over here sometimes. 00:36:43.040 --> 00:36:51.040 And as a result, when they want it, they're going to have to request for it and ask it. 00:36:51.040 --> 00:36:58.040 Now, with that in mind, sometimes sparse mode is not going to perform as well as we want it to. 00:36:58.040 --> 00:37:01.040 And the reason why is because of how your network is set up. 00:37:02.040 --> 00:37:11.040 Wherever your streamer is, your source is, that's typically far off somewhere, like in the corner of your data center, let's say, as an example. 00:37:11.040 --> 00:37:16.040 And the data center resources are not necessarily really close to the users. 00:37:16.040 --> 00:37:28.040 So if you think about all the users down here in this part of the environment, it could take a while for them to start getting that stream when they want it because it's so far away. 00:37:28.040 --> 00:37:31.040 Whereas with flood and prune, it was flooded everywhere. 00:37:31.040 --> 00:37:34.040 With dense mode, everybody got it, right? 00:37:34.040 --> 00:37:37.040 It was everywhere, so it was really easy, really quick. 00:37:37.040 --> 00:37:39.040 But in this case, it could be slow. 00:37:39.040 --> 00:37:41.040 We call it spin-up time. 00:37:41.040 --> 00:37:42.040 It could be slow here. 00:37:42.040 --> 00:37:46.040 So instead, what we do is we have the rendezvous point. 00:37:46.040 --> 00:37:49.040 The rendezvous point is going to be some centralized router. 00:37:49.040 --> 00:37:50.040 This is important for the example. 00:37:50.040 --> 00:37:59.040 The rendezvous point is going to be some centralized router that we have that is going to be the meeting place for sparse mode. 00:37:59.040 --> 00:38:02.040 What does that mean? 00:38:02.040 --> 00:38:10.040 It means that our source traffic is always going to be sent to the rendezvous point whether it needs it or not. 00:38:10.040 --> 00:38:12.040 So let's say it's being sent. 00:38:12.040 --> 00:38:16.040 Let's just say for fun it's being sent this way. 00:38:17.040 --> 00:38:21.040 So the rendezvous point is always getting the stream. 00:38:21.040 --> 00:38:23.040 And so now what does that mean? 00:38:23.040 --> 00:38:30.040 It means anybody in our environment who needs that stream, let's say you have a user here. 00:38:30.040 --> 00:38:32.040 They send their IGMP query. 00:38:32.040 --> 00:38:40.040 This router is going to contact the rendezvous point indicating that it needs the stream. 00:38:40.040 --> 00:38:47.040 The stream is then going to be sent down to the user from the rendezvous point. 00:38:47.040 --> 00:38:55.040 So build trees based on requests is the key for sparse mode. 00:38:55.040 --> 00:38:59.040 However, this is suboptimal, isn't it, folks? 00:38:59.040 --> 00:39:00.040 You see that path? 00:39:00.040 --> 00:39:02.040 Very suboptimal. 00:39:02.040 --> 00:39:09.040 The great thing about PIM with rendezvous points is that the rendezvous point is for what purpose? 00:39:09.040 --> 00:39:18.040 To basically just set up the initial connection, the communication. 00:39:18.040 --> 00:39:29.040 It is only needed to start that session for the client between the source and the receiver. 00:39:29.040 --> 00:39:36.040 In this case, is there a shorter path that could be used for the stream? 00:39:36.040 --> 00:39:38.040 Yes, there is. 00:39:38.040 --> 00:39:49.040 What happens automatically now is that the network will adjust and will start sending the stream this way as well now. 00:39:49.040 --> 00:39:53.040 And this can be removed. 00:39:53.040 --> 00:39:57.040 So you see how the tree was built on the fly now. 00:39:57.040 --> 00:40:02.040 So the rendezvous point, remember, this is only needed to start a new session between the sources and receivers. 00:40:02.040 --> 00:40:12.040 And if there's a shorter path, a better way to go, the network will adjust and change for multicast so the stream can go. 00:40:12.040 --> 00:40:17.040 Keep that in mind for the certification exam. 00:40:17.040 --> 00:40:20.040 All right, so now you know dense mode, you know sparse mode. 00:40:20.040 --> 00:40:21.040 You know the keywords. 00:40:21.040 --> 00:40:22.040 You know the buzzwords. 00:40:22.040 --> 00:40:25.040 You know what the rendezvous point is. 00:40:25.040 --> 00:40:27.040 Sparse dense mode is a combination of two. 00:40:27.040 --> 00:40:36.040 Just think about a scenario where part of your network you want to flood and prune because there's a lot of users down there that need the multicast stream. 00:40:36.040 --> 00:40:38.040 Flood and prune instead. 00:40:38.040 --> 00:40:40.040 And there's another part of your network that is sparse. 00:40:40.040 --> 00:40:41.040 Well, then you can do both. 00:40:41.040 --> 00:40:48.040 Sparse dense mode, pull or push model based on the group requirements. 00:40:48.040 --> 00:40:55.040 So any scenario on the exam that says you have a few users that need the multicast stream, your answer is sparse mode. 00:40:55.040 --> 00:40:59.040 Where they said you have lots and lots of users that need, that's dense mode you're going to use. 00:40:59.040 --> 00:41:04.040 If they say you have a combination and different parts of your network, that's sparse dense mode, okay? 00:41:04.040 --> 00:41:07.040 Keep it as simple as that for the certification exam. 00:41:07.040 --> 00:41:12.040 Now, the last one here, bidirectional, is different. 00:41:12.040 --> 00:41:13.040 It really is. 00:41:13.040 --> 00:41:14.040 Why? 00:41:14.040 --> 00:41:17.040 Just think about, first of all, what's happening with all the other three. 00:41:17.040 --> 00:41:22.040 The other three have a very specific source, and then you have a multitude of receivers. 00:41:22.040 --> 00:41:32.040 So, for example, for every multicast stream I would have a different source, a different group address, so 239.001, 239.002, 239.003, right? 00:41:32.040 --> 00:41:39.040 Every single source would have a different stream, a different address, and then I have all my users, right? 00:41:39.040 --> 00:41:40.040 And what happens? 00:41:40.040 --> 00:41:42.040 We stream from there to whoever needs it. 00:41:43.040 --> 00:41:51.040 Bidirectional is when you have many, many, many sources and many, many receivers all communicating with each other. 00:41:51.040 --> 00:41:59.040 Think of, for example, like an in-house video conferencing solution, right? 00:41:59.040 --> 00:42:03.040 If I'm an in-house video conferencing solution, then what happens? 00:42:03.040 --> 00:42:07.040 We're all senders and we're all receivers all at the exact same time. 00:42:07.040 --> 00:42:10.040 So you don't just have one sender and a bunch of receivers. 00:42:10.040 --> 00:42:15.040 Everyone's a sender and everyone's a receiver all at the exact same time, right? 00:42:15.040 --> 00:42:17.040 Don't think that's Zoom. 00:42:17.040 --> 00:42:18.040 No, Zoom is not that. 00:42:18.040 --> 00:42:20.040 Microsoft Teams is not that. 00:42:20.040 --> 00:42:24.040 Skype is not that, right? 00:42:24.040 --> 00:42:25.040 Why? 00:42:25.040 --> 00:42:29.040 Because in that case, we're using unicast for that. 00:42:29.040 --> 00:42:37.040 We're not using multicast for those types of scenarios, and there's typically a centralized server in play for those communications. 00:42:41.040 --> 00:43:00.040 But any scenario where they're talking about needing a solution for multicast whereby many senders and many receivers all exist for one group, many senders in a group, many receivers in a group, think bidirectional. 00:43:00.040 --> 00:43:03.040 And it's a pull model designed for many to many applications. 00:43:04.040 --> 00:43:09.040 Now, some of your environments are going to have what? 00:43:09.040 --> 00:43:16.040 You are going to have multiple PIM domains, PIM sparse mode domains, I should say. 00:43:16.040 --> 00:43:19.040 So when you have multiple PIM sparse mode domains, what does that mean? 00:43:19.040 --> 00:43:21.040 You have a multicast tree here. 00:43:21.040 --> 00:43:23.040 You have a different multicast tree here. 00:43:23.040 --> 00:43:25.040 You have a different multicast tree here. 00:43:25.040 --> 00:43:27.040 That is a possibility. 00:43:28.040 --> 00:43:35.040 And as a result of that, how could you have these different trees actually connect together? 00:43:35.040 --> 00:43:44.040 Well, that is where you use PIM MSDP, Multicast Source Discovery Protocol. 00:43:44.040 --> 00:43:54.040 And what happens here is that the rendezvous points are going to be linked together, essentially. 00:43:57.040 --> 00:44:04.040 So I have different PIM environments, PIM sparse mode environments, each with their own rendezvous points. 00:44:04.040 --> 00:44:20.040 And so now what happens is I could be here as a receiver, but the source could be in a totally different tree by me understanding how to get there through this rendezvous point over to the other rendezvous point into that environment to get that. 00:44:20.040 --> 00:44:37.040 So on the exam, if there is any scenario that talks about you having multiple PIM sparse mode domains, therefore you have multiple rendezvous points, therefore you have two totally separate trees, you use Multicast Source Discovery Protocol, so that way there you can interconnect those two environments together. 00:44:37.040 --> 00:44:39.040 And that uses what? 00:44:39.040 --> 00:44:44.040 BGP in order to accomplish it. 00:44:45.040 --> 00:44:50.040 All right, so the rendezvous points will exchange source information with other rendezvous points in other domains. 00:44:50.040 --> 00:44:52.040 That's what you need to know. 00:44:52.040 --> 00:44:58.040 All right, now PIM reverse path forwarding, what does that mean? 00:44:58.040 --> 00:45:00.040 So this is just a safety check. 00:45:00.040 --> 00:45:02.040 That's all it is, a safety check. 00:45:02.040 --> 00:45:11.040 So anytime you see PIM RPF, reverse path forwarding, it is a check. 00:45:11.040 --> 00:45:13.040 A check for what? 00:45:13.040 --> 00:45:28.040 A check to make sure that the path is loop free. 00:45:28.040 --> 00:45:30.040 It's loop free. 00:45:30.040 --> 00:45:32.040 It's to prevent multicast loops. 00:45:32.040 --> 00:45:37.040 Because the last thing we want, for example, is our traffic to, let's say, I'll just do this. 00:45:37.040 --> 00:45:39.040 Loop, right? 00:45:39.040 --> 00:45:41.040 We don't want this to happen ever. 00:45:42.040 --> 00:45:43.040 Because that would be bad. 00:45:43.040 --> 00:45:45.040 That should never happen. 00:45:45.040 --> 00:45:50.040 Our tree should start at the source and end at the users, and it should never loop back on itself, ever. 00:45:53.040 --> 00:46:08.040 So the PIM reverse path forwarding feature is going to be used to check what? 00:46:09.040 --> 00:46:31.040 To check that the multicast packet that was received on an interface is valid in relation to our unicast routing table. 00:46:32.040 --> 00:46:34.040 Yes. 00:46:34.040 --> 00:46:35.040 What does that mean? 00:46:35.040 --> 00:46:36.040 Okay. 00:46:36.040 --> 00:46:45.040 So let's say a multicast packet arrives in this interface, and it's destined for here. 00:46:45.040 --> 00:46:58.040 With this check, the router says, I just received that multicast packet from source 10.0.100.1. 00:46:59.040 --> 00:47:06.040 Based on my unicast routing table, is that the way I go to get there? 00:47:06.040 --> 00:47:13.040 If the answer is yes, then I'm allowed to forward that down to where it needs to go. 00:47:13.040 --> 00:47:19.040 If the answer is no, then I have to drop that packet. 00:47:19.040 --> 00:47:24.040 Because if the answer is no, then we could have a routing loop on our hands. 00:47:25.040 --> 00:47:27.040 And we don't want the tree to cause a routing loop. 00:47:27.040 --> 00:47:29.040 So here's an example of that. 00:47:29.040 --> 00:47:34.040 Let's say we receive the packet this way. 00:47:38.040 --> 00:47:49.040 And so I check, is this the way I go to get to this address right here, based on my unicast routing table? 00:47:49.040 --> 00:47:52.040 Based on my unicast routing table. 00:47:52.040 --> 00:47:56.040 Let's say the unicast routing table is pointing this way. 00:47:58.040 --> 00:48:03.040 If the unicast routing table is pointing that way, then I drop it because that tree is not right. 00:48:10.040 --> 00:48:12.040 That's all this does. 00:48:12.040 --> 00:48:17.040 Source address of incoming multicast packet is checked against the unicast routing table. 00:48:17.040 --> 00:48:18.040 Make sure you know that. 00:48:18.040 --> 00:48:19.040 Why? 00:48:19.040 --> 00:48:20.040 To prevent loops. 00:48:22.040 --> 00:48:24.040 Alright, so that is IGMP. 00:48:24.040 --> 00:48:26.040 That is PIM for the certification exam. 00:48:26.040 --> 00:48:29.040 Now you know how the magic happens in multicasting. 00:48:29.040 --> 00:48:34.040 You've got a lot of different terms and definitions that you'll want to know for the certification exam.