WEBVTT 1 00:00.000 --> 00:03.120 So as a reminder, here is our game plan right here. 2 00:03.120 --> 00:06.960 And we already have R1, R2, and R3 configured. 3 00:06.960 --> 00:09.120 So our attention is going to be right here on R4. 4 00:09.120 --> 00:10.620 So a couple of things we'll need to do. 5 00:10.620 --> 00:13.800 Number one, we'll want to enable IP multicast routing. 6 00:13.800 --> 00:17.760 And syntax for that is IP multicast routing with the little 7 00:17.760 --> 00:19.520 hyphen between multicast and routing. 8 00:19.520 --> 00:20.960 So that's done in global config. 9 00:20.960 --> 00:26.240 So we'll do that first over on R4 and then we'll enable PIM in sparse mode 10 00:26.240 --> 00:29.240 on each of its interfaces, which would be gig two zero, fast. 11 00:29.240 --> 00:31.240 We'll see that four slash one and gig one zero. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 11 00:29.240 --> 00:31.240 We'll see that four slash one and gig one zero. 12 00:31.240 --> 00:34.040 So the syntax there to be IP PIM sparse mode. 13 00:34.040 --> 00:38.560 And then last but not least, we also want to make sure that R4 knows where 14 00:38.560 --> 00:41.720 the root or the trunk of the tree is over here at R2, the rendezvous point. 15 00:41.720 --> 00:44.120 So we're also going to use the command in global config. 16 00:44.120 --> 00:47.680 In fact, I'll put it right here under IP multicast routing, which is also in 17 00:47.680 --> 00:47.960 global 18 00:47.960 --> 00:52.640 config, we'll have the command IP PIM RP dash address. 19 00:52.640 --> 00:55.850 And then we'll put the loopback address here of R2, which is two dot two dot 20 00:55.850 --> 00:56.520 two dot two. 21 00:56.520 --> 00:57.240 And boom. 22 00:57.320 --> 01:01.160 Another thing that happens once we do this configuration is that I GMP is WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 22 00:57.320 --> 01:01.160 Another thing that happens once we do this configuration is that I GMP is 23 01:01.160 --> 01:03.040 enabled on those interfaces by default. 24 01:03.040 --> 01:07.480 So if we have a client, for example, out here and it does a joint request for a 25 01:07.480 --> 01:11.720 multicast group, this router using I GMP can say, okay, great. 26 01:11.720 --> 01:12.600 I know that you want it. 27 01:12.600 --> 01:16.280 And if I have it, I'll forward it to you also periodically with I GMP, these 28 01:16.280 --> 01:19.720 routers can query their network segments just to make sure there's at least one 29 01:19.720 --> 01:22.760 device on that network segment that still needs that multicast group. 30 01:22.760 --> 01:26.080 And if it doesn't, it can go ahead and prune off that outgoing interface and 31 01:26.080 --> 01:27.520 not bother wasting bandwidth. 32 01:27.520 --> 01:31.040 And again, that's the benefit of using sparse mode, only forwarding traffic WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:27.520 --> 01:31.040 And again, that's the benefit of using sparse mode, only forwarding traffic 33 01:31.040 --> 01:31.200 down 34 01:31.200 --> 01:33.360 into devices and entities that need it. 35 01:33.360 --> 01:38.000 So that in mind, let's head over to R4 and let's configure multicast routing on 36 01:38.000 --> 01:38.480 R4. 37 01:38.480 --> 01:42.010 So here's our playground and also at the very tail end of this set of videos, I 38 01:42.010 --> 01:42.120 'm 39 01:42.120 --> 01:45.040 going to give you a hands-on lab so you can do the practice on your own. 40 01:45.040 --> 01:48.280 So for now, let's go ahead and verify our topology. 41 01:48.280 --> 01:50.480 So we are configuring R4. 42 01:50.480 --> 01:51.280 Fantastic. 43 01:51.280 --> 01:55.560 And to get to the console of any of these routers as well as the switch, we're 44 01:55.560 --> 01:59.040 going to go ahead and double click right here on server one dash nug. 45 01:59.040 --> 02:02.120 So we'll give that a double click, give that a moment to initialize and there's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 45 01:59.040 --> 02:02.120 So we'll give that a double click, give that a moment to initialize and there's 46 02:02.120 --> 02:03.160 our console interfaces. 47 02:03.160 --> 02:07.370 So there's our one, our two, our three, our four and just to verify it real 48 02:07.370 --> 02:07.560 quick, 49 02:07.560 --> 02:10.840 let's just verify that R2 is already configured. 50 02:10.840 --> 02:13.200 So let's go to R2 just as a sanity check. 51 02:13.200 --> 02:16.000 Let's do a show IP PIM interface. 52 02:16.000 --> 02:18.640 And sure enough, all of its interfaces are enabled for PIM. 53 02:18.640 --> 02:22.680 And let's also show IP, IGMP interface. 54 02:22.880 --> 02:26.440 And because PIM is enabled on the interfaces, IGMP should be as well. 55 02:26.440 --> 02:30.120 So here's gig zero zero that's enabled for IGMP. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 55 02:26.440 --> 02:30.120 So here's gig zero zero that's enabled for IGMP. 56 02:30.120 --> 02:34.720 And showing right here the version, which is version two and which multicast 57 02:34.720 --> 02:36.640 groups have been joined on the interface. 58 02:36.640 --> 02:41.160 So this multicast group here is used by a process called auto RP where it can 59 02:41.160 --> 02:42.880 automatically decide on the rendezvous point. 60 02:42.880 --> 02:46.320 In our case, we're manually configuring a rendezvous point. 61 02:46.320 --> 02:51.480 So here if we did a show IP PIM RP or rendezvous point is showing us the 62 02:51.480 --> 02:53.800 rendezvous point is at 2222. 63 02:53.800 --> 02:57.760 And that's for this multicast group right here as well as for this 64 02:57.760 --> 02:59.080 multicast group right here. 65 02:59.080 --> 03:02.870 And because this is the only rendezvous point that we have, our two, any new WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 65 02:59.080 --> 03:02.870 And because this is the only rendezvous point that we have, our two, any new 66 03:02.870 --> 03:03.240 groups 67 03:03.240 --> 03:06.000 are also going to use the same root or trunk of the tree. 68 03:06.000 --> 03:10.200 So we went over to R1, for example, and we did a show IP PIM RP and press 69 03:10.200 --> 03:10.560 center. 70 03:10.560 --> 03:14.720 Once again, it's going to indicate that same root or trunk of the tree, which 71 03:14.720 --> 03:15.680 is 2222. 72 03:15.680 --> 03:18.440 And in R4, we haven't yet configured that. 73 03:18.440 --> 03:22.080 So let's go ahead and configure R4 for multicast routing. 74 03:22.080 --> 03:24.280 So we'll start off by, in fact, let's do this. 75 03:24.280 --> 03:27.920 We'll do a show IP PIM interface and it shouldn't have any. 76 03:27.920 --> 03:30.880 And we'll do a show IP PIM RP and again, nothing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 76 03:27.920 --> 03:30.880 And we'll do a show IP PIM RP and again, nothing. 77 03:30.880 --> 03:33.240 So there's no multicast configured whatsoever. 78 03:33.240 --> 03:37.360 So on R4, we'll go into configuration mode and we use the command IP multicast 79 03:37.360 --> 03:39.640 routing to enable multicast routing. 80 03:39.640 --> 03:45.560 Then let's specify the PIM rendezvous point address with IP PIM RP dash address 81 03:45.560 --> 03:45.560 . 82 03:45.560 --> 03:47.040 And that is going to be 2.2.2. 83 03:47.040 --> 03:52.440 And this tunnel right here is a logical tunnel between R4, which is right here. 84 03:52.440 --> 03:54.760 And the rendezvous point, which is R2. 85 03:54.760 --> 03:56.520 And it's going to use that logical tunnel. 86 03:56.520 --> 03:59.640 If it needs a forward traffic that it sees, multicast traffic that it sees, 87 03:59.640 --> 04:02.200 as it forwards it over to the rendezvous point. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 87 03:59.640 --> 04:02.200 as it forwards it over to the rendezvous point. 88 04:02.200 --> 04:03.560 So currently it says this down. 89 04:03.560 --> 04:07.120 And that's because we don't have any interfaces yet enabled for PIM. 90 04:07.120 --> 04:08.320 And that's our next step. 91 04:08.320 --> 04:11.380 So we're going to go to interface and let's take a look at our interfaces real 92 04:11.380 --> 04:11.600 quick. 93 04:11.600 --> 04:16.860 We wanted to do interface gig 1, 0, gig 2, 0 and FA 4/1 and enable 94 04:16.860 --> 04:18.960 all of them for PIM sparse mode. 95 04:18.960 --> 04:25.160 So let's do interface range for a gigabit 1/0, gig 2/0, comma. 96 04:25.160 --> 04:26.660 And what was the other one? 97 04:26.660 --> 04:27.860 Let's take a look. 98 04:27.860 --> 04:29.960 It is FA 4/1. 99 04:29.960 --> 04:31.760 So we'll do FA 4/1. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 99 04:29.960 --> 04:31.760 So we'll do FA 4/1. 100 04:31.760 --> 04:35.760 And now in interface range configuration mode, we use the command IP, PIM 101 04:35.760 --> 04:37.560 sparse mode and press center. 102 04:37.560 --> 04:43.860 And we have some PIM messages here regarding DRs. 103 04:43.860 --> 04:46.160 Now these are not the same as the DRs for OSP off. 104 04:46.160 --> 04:48.260 These are DRs for PIM. 105 04:48.260 --> 04:50.360 It also indicates here that we have a couple of neighbors. 106 04:50.360 --> 04:56.080 So this means that our 4 has a neighbor ship with our 3 and also has a neighbor 107 04:56.080 --> 04:59.860 ship over with our 2 based on these two messages right here. 108 04:59.860 --> 05:03.890 So now if we did a show IP, I GMP interface, it's going to show us the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 108 04:59.860 --> 05:03.890 So now if we did a show IP, I GMP interface, it's going to show us the 109 05:03.890 --> 05:05.860 interfaces that are enabled for I GMP. 110 05:05.860 --> 05:09.060 And that's as a result of enabling PIM on those interfaces. 111 05:09.060 --> 05:12.060 So the space bar is going to go through the interfaces involved. 112 05:12.060 --> 05:16.960 And if you did a show IP PIM neighbor that gives details on our neighbors. 113 05:16.960 --> 05:21.140 So off of our FA 4/1 interface, we have a neighbor that's R2 based on that last 114 05:21.140 --> 05:21.560 octet. 115 05:21.560 --> 05:25.060 And off of our gig 1/0 interface, we have a neighbor based on that last octet. 116 05:25.060 --> 05:26.060 That's R3. 117 05:26.060 --> 05:30.560 Now if we go to R2, which is our rendezvous point, let's go ahead and hop over WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 117 05:26.060 --> 05:30.560 Now if we go to R2, which is our rendezvous point, let's go ahead and hop over 118 05:30.560 --> 05:31.060 there. 119 05:31.060 --> 05:34.060 Here we do a show IPM route press center. 120 05:34.060 --> 05:37.060 And that's going to show us the multicast routing table. 121 05:37.060 --> 05:40.410 And although there's a lot of information here, here's the key parts I'd like 122 05:40.410 --> 05:41.560 you to pay attention to. 123 05:41.560 --> 05:46.060 It has information regarding multicast streams that it has seen. 124 05:46.060 --> 05:49.990 And some of these multicast groups, which are by default, are there to support 125 05:49.990 --> 05:52.060 a feature called auto RP. 126 05:52.060 --> 05:57.560 So at the moment, R2 knows about this destination group 224.0.1.40. 127 05:57.560 --> 06:00.560 It knows about this one 239, 255, etc. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 05:57.560 --> 06:00.560 It knows about this one 239, 255, etc. 128 06:00.560 --> 06:05.700 But it doesn't know anything about a multicast group based on our game plan 129 06:05.700 --> 06:08.560 like 224.67.83. 130 06:08.560 --> 06:10.560 So as a test, if you and I went over to R4. 131 06:10.560 --> 06:15.560 And we did a ping to 224.67.8.3. 132 06:15.560 --> 06:19.560 We sourced it from gig 2.0, which is the 23.1.2.4 address. 133 06:19.560 --> 06:23.560 We would then see that combination here in the multicast table on R2. 134 06:23.560 --> 06:27.830 Because even though R4 is sourcing that traffic, when it sees that traffic, it 135 06:27.830 --> 06:29.560 's going to go ahead and forward it to the rendezvous point, 136 06:29.560 --> 06:32.560 who's then going to build it as part of its multicast routing table. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 136 06:29.560 --> 06:32.560 who's then going to build it as part of its multicast routing table. 137 06:32.560 --> 06:34.560 So let's verify that next. 138 06:34.560 --> 06:41.560 So we'll go over to R4 and on R4, let's do a ping to 224.1.2. 139 06:41.560 --> 06:42.560 That's the wrong address. 140 06:42.560 --> 06:45.560 Based on our plan, let's take a look at our plan for a moment. 141 06:45.560 --> 06:49.560 Our multicast address is going to be 224.67.8.3. 142 06:49.560 --> 06:52.560 That's our group that we're going to send the traffic to. 143 06:52.560 --> 06:54.560 So with that in mind, let's do exactly that. 144 06:54.560 --> 06:56.560 224.67.8.3. 145 06:56.560 --> 07:00.900 Let's go ahead and also source this from the gig 2.0 interface address, which WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 145 06:56.560 --> 07:00.900 Let's go ahead and also source this from the gig 2.0 interface address, which 146 07:00.900 --> 07:02.560 is 23.1.2.4. 147 07:02.560 --> 07:05.560 So let's go ahead and actually let's verify that as well. 148 07:05.560 --> 07:08.560 Let's do a show IP interface brief just to confirm. 149 07:08.560 --> 07:12.560 So that's the address right there associated with the gig 2.0 interface. 150 07:12.560 --> 07:14.560 So do I ping? 151 07:14.560 --> 07:16.560 It doesn't really matter what content we send. 152 07:16.560 --> 07:18.560 We can send ping requests that would work. 153 07:18.560 --> 07:23.750 Or if you had a multicast application that was literally sending a stream that 154 07:23.750 --> 07:24.560 people could watch and view. 155 07:24.560 --> 07:28.740 All we're really concerned about here is the routing of that multicast traffic 156 07:28.740 --> 07:29.560 at layer 3. 157 07:29.560 --> 07:33.560 So ping to 224.67.8.3. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 157 07:29.560 --> 07:33.560 So ping to 224.67.8.3. 158 07:33.560 --> 07:35.560 And we'll source that from this interface. 159 07:35.560 --> 07:38.560 And let's go ahead and copy paste that to make it real easy. 160 07:38.560 --> 07:40.560 And we'll source it from that interface and press enter. 161 07:40.560 --> 07:42.560 So boom, we've done it now. 162 07:42.560 --> 07:43.560 It sent one packet. 163 07:43.560 --> 07:44.560 There was no response. 164 07:44.560 --> 07:49.560 And that's because no one on this multicast network is joined that group yet. 165 07:49.560 --> 07:53.560 So in our four, we simulated creating a multicast stream. 166 07:53.560 --> 07:56.560 And now if we go back to R2, check this out a moment ago. 167 07:56.560 --> 08:01.050 When we use this command show IPM route, it didn't have any information about a WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 167 07:56.560 --> 08:01.050 When we use this command show IPM route, it didn't have any information about a 168 08:01.050 --> 08:08.560 source of 23.1.2.4 and a destination of multicast group 224.67.8.3. 169 08:08.560 --> 08:12.110 But now we have the upper key for a refresh and go down a little bit, check it 170 08:12.110 --> 08:12.560 out. 171 08:12.560 --> 08:16.560 It learned about this multicast group 224.67.8.3. 172 08:16.560 --> 08:22.540 And it also knows the source of that is the IP address interface of gig 2.0 173 08:22.540 --> 08:23.560 over on R4. 174 08:23.560 --> 08:27.020 So that means the root of the tree, the trunk of the tree has received this, 175 08:27.020 --> 08:27.560 but check it out. 176 08:27.560 --> 08:29.560 It's not yet forwarding it anywhere. 177 08:29.560 --> 08:31.560 And that's because we're in sparse mode. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 177 08:29.560 --> 08:31.560 And that's because we're in sparse mode. 178 08:31.560 --> 08:35.560 And in sparse mode, the routers are not going to forward that multicast stream 179 08:35.560 --> 08:37.560 unless they have a reason to. 180 08:37.560 --> 08:39.560 So here's what you and I get to do in the next video. 181 08:39.560 --> 08:43.840 In the next video, what we'll do is we'll go down to R1 and we'll have this 182 08:43.840 --> 08:48.560 interface down in R1, the gig 2.0 interface join that multicast group. 183 08:48.560 --> 08:53.920 And as a result, it can send that join request via PIM up to R2, who's the 184 08:53.920 --> 08:54.560 trunk of the tree. 185 08:54.560 --> 08:57.190 And at that moment, R2 is going to say, "You know what? I need to start 186 08:57.190 --> 08:58.560 forwarding that traffic." 187 08:58.560 --> 09:02.030 So we'll continue this conversation with that demonstration in the very next WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 187 08:58.560 --> 09:02.030 So we'll continue this conversation with that demonstration in the very next 188 09:02.030 --> 09:02.560 video. 189 09:02.560 --> 09:04.560 So I'll see you there in just a moment.