1 00:00:11,240 --> 00:00:13,780 Now his star, comedy state. 2 00:00:13,780 --> 00:00:16,380 Let me just go ahead and fill the rest of this out here. 3 00:00:16,380 --> 00:00:21,240 So in router two, his outgoing interface list will say fast ethanet zero 4 00:00:21,240 --> 00:00:24,900 zero because that's where he received the membership report. 5 00:00:24,900 --> 00:00:28,420 So that's where he will forward the multicast traffic when it comes to 6 00:00:28,420 --> 00:00:34,160 him. Router eight, his outgoing interface list will say fast ethanet zero 7 00:00:34,160 --> 00:00:39,760 slash one because he received the PIM join on that interface. 8 00:00:39,760 --> 00:00:47,280 Now, router three, I'm going to skip a couple of fields here. 9 00:00:47,280 --> 00:00:51,080 His outgoing interface list will say fast ethanet zero slash one because 10 00:00:51,080 --> 00:00:53,600 that's where he received the PIM join. 11 00:00:53,600 --> 00:00:58,660 Now in the RP field, you're going to see something rather interesting. 12 00:00:58,660 --> 00:01:03,200 It's going to say that because he is the RP. 13 00:01:03,200 --> 00:01:06,360 That's his way of saying, okay, I know on the rendezvous point. 14 00:01:06,360 --> 00:01:13,200 So that's me. And his incoming interface will say no because he'll say, 15 00:01:13,200 --> 00:01:15,600 hey, I'm the root of the shared tree. 16 00:01:15,600 --> 00:01:19,780 It starts with me. 17 00:01:19,780 --> 00:01:24,740 And his next top, his RPF neighbor will also be all zeros. 18 00:01:24,740 --> 00:01:28,200 But he'll say, look, I don't use any next top neighbor to get to myself. 19 00:01:28,200 --> 00:01:29,060 I'm not psychotic. 20 00:01:29,060 --> 00:01:30,120 I know I'm here. 21 00:01:30,120 --> 00:01:32,560 I know I'm the rendezvous point. 22 00:01:32,560 --> 00:01:33,740 So that's what we'll see. 23 00:01:33,740 --> 00:01:36,860 So let's go ahead and start up this process here. 24 00:01:36,860 --> 00:01:40,900 So I'm going to go ahead and trigger R1 to send the join. 25 00:01:40,900 --> 00:01:43,480 And let's go ahead and start the sniffer trace so we can capture all of 26 00:01:43,480 --> 00:01:50,160 this. So we'll just capture two things. 27 00:01:50,160 --> 00:01:57,000 We'll capture the membership report coming in and the PIM join going from 28 00:01:57,000 --> 00:01:59,380 router two up to router eight. 29 00:01:59,380 --> 00:02:10,640 So to do that, so I want R2, 00 incoming and I want 01 outgoing. 30 00:02:10,640 --> 00:02:18,580 So looking at my diagram here. 31 00:02:18,580 --> 00:02:21,820 Okay, so I'm going to want R2. 32 00:02:21,820 --> 00:02:25,480 So I want 0 slash 3. 33 00:02:25,480 --> 00:02:36,740 Receive and I want 0 slash 1 out. 34 00:02:36,740 --> 00:02:38,560 That's your slash 4. 35 00:02:38,560 --> 00:02:42,300 I'll just do both for those. 36 00:02:42,300 --> 00:03:23,820 So let's go ahead and do that. 37 00:03:23,820 --> 00:03:51,940 Okay. Let's get the sniffer trace all set up and ready to go. 38 00:03:51,940 --> 00:03:58,300 I do not know why wire shark is not letting me press any of the buttons 39 00:03:58,300 --> 00:04:00,580 on the menu here. 40 00:04:00,580 --> 00:04:03,180 This is irritating beyond belief. 41 00:04:03,180 --> 00:04:08,660 There we go. Finally. 42 00:04:08,660 --> 00:04:13,020 Okay. So stop. Here we go. 43 00:04:13,020 --> 00:04:16,940 So now let's go to my receiver. 44 00:04:16,940 --> 00:04:21,540 And you might be wondering how do I get a router to act like a PC? 45 00:04:21,540 --> 00:04:24,040 How do I get him to send an IGMP membership report? 46 00:04:24,040 --> 00:04:25,720 He's not a laptop. 47 00:04:25,720 --> 00:04:29,500 Real easy. So let's see what interface do we want here. 48 00:04:29,500 --> 00:04:33,600 We want fast ethernet 00. 49 00:04:33,600 --> 00:04:40,460 So I just simply type IP, IGMP, join-group. 50 00:04:40,460 --> 00:04:44,260 Oops, got to go to my interface. 51 00:04:44,260 --> 00:04:49,740 Join-group and I'm going to do 239. 52 00:04:49,740 --> 00:04:51,940 Let's see. What have we been doing on my examples here? 53 00:04:51,940 --> 00:05:01,080 9.9.9. Yes. Actually before I do this, I can do a debug. 54 00:05:01,080 --> 00:05:10,600 Okay. IP, IGMP, join -group 239.999. 55 00:05:10,600 --> 00:05:15,520 And there it is. 56 00:05:15,520 --> 00:05:21,240 He sent an IGMP version to report. 57 00:05:21,240 --> 00:05:23,840 However, I don't think I started my snipper trace. 58 00:05:23,840 --> 00:05:26,680 So let's go ahead and just shut that down. 59 00:05:26,680 --> 00:05:34,500 Let's go to R2. Clear out my M-route state. 60 00:05:34,500 --> 00:05:35,620 So I can start from scratch. 61 00:05:35,620 --> 00:05:38,480 Clear IP M-route star. 62 00:05:38,480 --> 00:05:46,620 That clears out all of your M-routs. 63 00:05:46,620 --> 00:05:50,060 Okay, so I'm back to having just the auto-RP M-route. 64 00:05:50,060 --> 00:05:52,840 Let's also do that in R8. 65 00:05:52,840 --> 00:06:02,100 Okay, so let's go back to router one. 66 00:06:02,100 --> 00:06:05,900 And let's start off my snipper trace this time so we can capture all this 67 00:06:05,900 --> 00:06:33,340 good stuff. The IJRP is formed and I think I still have the debug running. 68 00:06:33,340 --> 00:06:51,120 So he received an IJMP query and there he goes. 69 00:06:51,120 --> 00:06:54,700 Okay, so here is the IJMP. 70 00:06:54,700 --> 00:07:00,960 Nope, this is not, this is different. 71 00:07:00,960 --> 00:07:02,420 Let's see here, here it is. 72 00:07:02,420 --> 00:07:11,700 Here's the IJMP membership report from router one. 73 00:07:11,700 --> 00:07:15,160 I should say my receiver. 74 00:07:15,160 --> 00:07:22,840 And you can see here IJMP version two and he's joining the address of 75 00:07:22,840 --> 00:07:31,580 239.999. So the moment that, let's go back here, the moment that router 76 00:07:31,580 --> 00:07:36,140 two got that, he would create a PIM star coma-g join. 77 00:07:36,140 --> 00:07:41,100 And he's going to use his source address of 8.2.8.2. 78 00:07:41,100 --> 00:07:45,620 And that's what we see right here. 79 00:07:45,620 --> 00:07:49,380 So right beneath our membership report, there is the PIM star coma-g join 80 00:07:49,380 --> 00:07:51,740 leaving that router. 81 00:07:51,740 --> 00:07:54,220 We dig into the details here. 82 00:07:54,220 --> 00:07:57,360 So it's type three, remember type zero was the hello. 83 00:07:57,360 --> 00:08:00,120 So type three is the join slash prune. 84 00:08:00,120 --> 00:08:01,520 This is also not a little thing here. 85 00:08:01,520 --> 00:08:05,820 This one message here is used for both joining branches to the tree and 86 00:08:05,820 --> 00:08:10,040 pruning branches off of the tree. 87 00:08:10,040 --> 00:08:12,600 Now we dig into the guts of it. 88 00:08:12,600 --> 00:08:16,720 He says, okay, this is destined for my upstream neighbor. 89 00:08:16,720 --> 00:08:18,900 Now why is that in there? 90 00:08:18,900 --> 00:08:19,560 A couple things. 91 00:08:19,560 --> 00:08:23,520 Notice that this is going out just like the PIM hello is going out to 92 00:08:23,520 --> 00:08:34,240 the multicast address of 2240013. 93 00:08:34,240 --> 00:08:38,060 So let's say that this was actually a shared land and there were other 94 00:08:38,060 --> 00:08:41,340 routers on this land in addition to routers two and eight. 95 00:08:41,340 --> 00:08:43,680 Let's say there was routers X and Y. 96 00:08:43,680 --> 00:08:46,860 Where router two wants all these routers to know, hey, this PIM join I'm 97 00:08:46,860 --> 00:08:50,460 sending is going along the branch to the shared tree, which means it needs 98 00:08:50,460 --> 00:08:52,640 to be headed towards router eight. 99 00:08:52,640 --> 00:08:55,920 So even though he's multicasting, which means any other routers on here 100 00:08:55,920 --> 00:08:56,000 want to be headed towards router eight. 101 00:08:56,000 --> 00:09:00,440 And we'll see it in here because it's got this upstream neighbor address 102 00:09:00,440 --> 00:09:04,300 that ensures that the next router router eight will pay attention to this 103 00:09:04,300 --> 00:09:07,260 and say, oh, okay, this is for me. 104 00:09:07,260 --> 00:09:10,460 And so he says, he says, okay, number of joins. 105 00:09:10,460 --> 00:09:13,100 I am joining one group. 106 00:09:13,100 --> 00:09:16,360 This is the group I'm joining. 107 00:09:16,360 --> 00:09:22,740 And this is the address not of the source, but of the rendezvous point. 108 00:09:22,740 --> 00:09:28,220 The address of the RP. 109 00:09:28,220 --> 00:09:29,600 And we're not pruning anything. 110 00:09:29,600 --> 00:09:30,560 We're not pruning off any branches. 111 00:09:30,560 --> 00:09:33,320 We are joining a branch. 112 00:09:33,320 --> 00:09:39,320 And what else do we have in here? 113 00:09:39,320 --> 00:09:44,200 I think that's all we've got at this point. 114 00:09:44,200 --> 00:09:49,760 I didn't capture anything else. 115 00:09:49,760 --> 00:09:55,240 Okay, so let's take a look at the the m route state in these routers now. 116 00:09:55,240 --> 00:09:58,940 So let's start by going to router two and see if everything matches what 117 00:09:58,940 --> 00:10:01,380 I've drawn right here. 118 00:10:01,380 --> 00:10:10,620 Show IP m route. 119 00:10:10,620 --> 00:10:18,040 Okay, there we go. 120 00:10:18,040 --> 00:10:24,200 So if you see that in your m route in any router, you know one of three 121 00:10:24,200 --> 00:10:26,800 things has happened. 122 00:10:26,800 --> 00:10:28,060 One of three things. 123 00:10:28,060 --> 00:10:31,820 Either you received an I.G.M.P. 124 00:10:31,820 --> 00:10:35,120 membership report from a directly connected receiver. 125 00:10:35,120 --> 00:10:36,640 In this case, that's true. 126 00:10:36,640 --> 00:10:39,560 And we know that because of the C flag. 127 00:10:39,560 --> 00:10:46,180 The C flag meaning I am connected to the receiver who sent me the join, 128 00:10:46,180 --> 00:10:48,580 the membership report that caused this. 129 00:10:48,580 --> 00:10:53,200 The other reason you might have that is because you received a PIM join. 130 00:10:53,200 --> 00:10:58,280 So for example, the C flag right here, when we go to router eight, we're 131 00:10:58,280 --> 00:11:08,700 going to see that exact same star, C, but the C flag will be missing. 132 00:11:08,700 --> 00:11:14,040 See, S means this is a sparse mode entry. 133 00:11:14,040 --> 00:11:16,640 We're running in sparse mode on the interface. 134 00:11:16,640 --> 00:11:20,180 So both, so this is router eight, no C flag. 135 00:11:20,180 --> 00:11:27,320 So this was created because he received the star, PIM join. 136 00:11:27,320 --> 00:11:32,780 Or as this was created, because we received the I.G.M.P. 137 00:11:32,780 --> 00:11:39,040 membership report. 138 00:11:39,040 --> 00:11:43,800 And our RP is designated right here. 139 00:11:43,800 --> 00:11:49,400 343.3. Incoming interface is fast ethernet zero slash one, which is indeed 140 00:11:49,400 --> 00:11:55,240 the interface leading upstream to the rendezvous point. 141 00:11:55,240 --> 00:11:58,220 RPF neighbor 8288. 142 00:11:58,220 --> 00:12:02,160 And we got that because when we did a reverse path lookup to figure out 143 00:12:02,160 --> 00:12:05,160 how do I get to the rendezvous point, we found in the routing table that 144 00:12:05,160 --> 00:12:07,720 this was the guy who was the next top. 145 00:12:07,720 --> 00:12:11,380 Our EIGRP route told us this is the next top. 146 00:12:11,380 --> 00:12:12,860 And outgoing interface list. 147 00:12:12,860 --> 00:12:15,540 This is the interface where we receive the I.G.M.P. 148 00:12:15,540 --> 00:12:26,060 membership report. 149 00:12:26,060 --> 00:12:28,560 And here's what looks like an R8. 150 00:12:28,560 --> 00:12:34,220 Pretty much exactly the same thing except it's missing the C flag. 151 00:12:34,220 --> 00:12:36,680 And now let's look at the difference of what it looks like in the actual 152 00:12:36,680 --> 00:12:49,480 rendezvous point himself. 153 00:12:49,480 --> 00:12:53,060 Okay, so notice he does list himself as the RP. 154 00:12:53,060 --> 00:12:57,560 He says, I know I'm the RP, but his RPF neighbor is all zeros. 155 00:12:57,560 --> 00:13:01,660 He doesn't need to go upstream to reach himself. 156 00:13:01,660 --> 00:13:04,840 And the incoming interface is null. 157 00:13:04,840 --> 00:13:08,520 And outgoing interface fast ethernet 00, he says I'm going to forward 158 00:13:08,520 --> 00:13:10,480 it in sparse mode. 159 00:13:10,480 --> 00:13:18,540 So now our shared tree from one to two to eight to three, this path is 160 00:13:18,540 --> 00:13:22,800 now opened up. So if the multicast starts to flow, it's ready. 161 00:13:22,800 --> 00:13:34,160 The rendezvous point is ready for it. 162 00:13:34,160 --> 00:13:36,840 So we've looked at what M route state they create. 163 00:13:36,840 --> 00:13:42,280 Now just a couple of additional things about these star, G joins. 164 00:13:42,280 --> 00:13:47,720 They're recent every 60 seconds. 165 00:13:47,720 --> 00:13:51,260 Why is that? Well, let's take a look at this again. 166 00:13:51,260 --> 00:13:53,080 My source isn't sending right now. 167 00:13:53,080 --> 00:13:55,460 So there's really no multicast flowing. 168 00:13:55,460 --> 00:13:57,540 We don't know how long it's going to take. 169 00:13:57,540 --> 00:14:01,440 What if it takes, you know, ten minutes for this guy to actually start 170 00:14:01,440 --> 00:14:06,200 up? Maybe this is a multicast stream that our CEO is going to give at 171 00:14:06,200 --> 00:14:07,800 three o'clock today. 172 00:14:07,800 --> 00:14:10,680 And this guy is joining it ten minutes early. 173 00:14:10,680 --> 00:14:14,660 Well, we don't want this thing to time out in this branch of the tree 174 00:14:14,660 --> 00:14:17,520 to eliminate and go away. 175 00:14:17,520 --> 00:14:22,520 So what we know that these things have a three minute timer, after 210 176 00:14:22,520 --> 00:14:27,940 seconds of no activity, these branches will be torn down. 177 00:14:27,940 --> 00:14:30,560 So in order to prevent that, a couple things are happening. 178 00:14:30,560 --> 00:14:35,380 Number one, we know that every 60 seconds are two sending an IGMP query 179 00:14:35,380 --> 00:14:41,140 onto the segment, saying, hey, any receivers down there watching anything? 180 00:14:41,140 --> 00:14:43,620 And Rader one will respond back with a membership report. 181 00:14:43,620 --> 00:14:47,860 So that's keeping this segment open, the exchange of queries and reports 182 00:14:47,860 --> 00:14:55,040 for IGMP. And we know that when the IGMP membership report comes back, 183 00:14:55,040 --> 00:15:02,400 that's going to trigger our two to send another PIM star, G join. 184 00:15:02,400 --> 00:15:06,760 Now, you might be saying, well, what happens if, you know, over the course 185 00:15:06,760 --> 00:15:13,580 of a minute, 25 or 65 membership reports from different receivers all 186 00:15:13,580 --> 00:15:15,760 come in on this interface? 187 00:15:15,760 --> 00:15:19,300 Does that mean that every single time he receives a membership report, 188 00:15:19,300 --> 00:15:21,660 he's going to send out a star, G join? 189 00:15:21,660 --> 00:15:24,240 No, that would be overkill. 190 00:15:24,240 --> 00:15:28,840 So this guy here is going to send out a PIM star, G join to keep the state 191 00:15:28,840 --> 00:15:32,540 refreshed every minute, every 60 seconds. 192 00:15:32,540 --> 00:15:38,540 Now, if he realizes that there's no receivers left, if IGMP times out 193 00:15:38,540 --> 00:15:42,780 or receives a bunch of leaves, and he says, okay, no receivers left, actually, 194 00:15:42,780 --> 00:15:43,840 let's go ahead and take a look at that. 195 00:15:43,840 --> 00:15:44,800 What's he going to do? 196 00:15:44,800 --> 00:15:49,260 So I'm going to go ahead and remove my IGMP command on Rader one. 197 00:15:49,260 --> 00:15:53,700 He should send an IGMP leave, although it's not mandated by the specification, 198 00:15:53,700 --> 00:15:56,680 that's one of those should things. 199 00:15:56,680 --> 00:16:00,880 And when he sends an IGMP leave, we should see Rader two send a PIM prune 200 00:16:00,880 --> 00:16:04,540 message upstream, pruning this branch. 201 00:16:04,540 --> 00:16:06,540 So let's go ahead and do that. 202 00:16:06,540 --> 00:16:22,260 I'll get my receiver ready to go. 203 00:16:22,260 --> 00:16:25,240 Okay, let's start the sniffer trace. 204 00:16:25,240 --> 00:16:39,980 All right, there's my leave group message. 205 00:16:39,980 --> 00:16:41,380 That's what we wanted to see. 206 00:16:41,380 --> 00:16:47,400 Okay, so here is the IGMP leave message. 207 00:16:47,400 --> 00:16:52,180 So it's actually got its own type code and says, I'm leaving this group, 208 00:16:52,180 --> 00:16:57,760 and that kicked off his default gateway to send a prune message. 209 00:16:57,760 --> 00:17:01,200 Notice it's the exact same message as the PIM join, but in this case, 210 00:17:01,200 --> 00:17:06,260 the join is now zero, and the prune is set to a one. 211 00:17:06,260 --> 00:17:13,420 And this says I am pruning off this tree, and I'm letting the rendezvous 212 00:17:13,420 --> 00:17:15,480 point know about that. 213 00:17:15,480 --> 00:17:23,400 By the way, SWR, in case you're wondering what that is, those are actually 214 00:17:23,400 --> 00:17:26,520 some flags within this message. 215 00:17:26,520 --> 00:17:32,020 The R is called the RP bit in this message. 216 00:17:32,020 --> 00:17:36,520 That means this message needs to go up the shared tree towards the rendezvous 217 00:17:36,520 --> 00:17:40,020 point. That's the ultimate destination. 218 00:17:40,020 --> 00:17:43,400 And that's why we actually have the rendezvous points address in this 219 00:17:43,400 --> 00:17:47,340 field right here because of that RP bit. 220 00:17:47,340 --> 00:17:51,460 The W means that's the wild card bit. 221 00:17:51,460 --> 00:17:55,560 That means I don't know what the actual source address is of this multicast 222 00:17:55,560 --> 00:18:00,380 stream. And that's what creates the star, G state in these routers. 223 00:18:00,380 --> 00:18:03,660 That's what creates the star, the wild card bit. 224 00:18:03,660 --> 00:18:06,660 Have no idea who the source is. 225 00:18:06,660 --> 00:18:10,720 And S, meaning this is a sparse mode join. 226 00:18:10,720 --> 00:18:23,340 So that's what those bits mean, those flags. 227 00:18:23,340 --> 00:18:28,020 What if the RPF info to the RP changes? 228 00:18:28,020 --> 00:18:35,900 So we know that there's a possibility that routes could change. 229 00:18:35,900 --> 00:18:40,800 I mean interfaces could go down, new interfaces could come up, and maybe 230 00:18:40,800 --> 00:18:45,600 the EIGRP route that I have to the rendezvous point right now is not going 231 00:18:45,600 --> 00:18:48,920 to be valid a couple of seconds from now. 232 00:18:48,920 --> 00:18:52,740 So how does PIM account for that? 233 00:18:52,740 --> 00:19:04,940 Well PIM has a timer and basically it's a, if you go into the specification, 234 00:19:04,940 --> 00:19:07,560 if you're curious about this, the name of the timer, although you'll never 235 00:19:07,560 --> 00:19:11,420 be tested on this, is called the Random Delay Join Timeout. 236 00:19:11,420 --> 00:19:14,560 Random Delay Join Timeout, for those of you who like to know that kind 237 00:19:14,560 --> 00:19:19,680 of thing. But basically, that's a timeout that says, okay, check to see 238 00:19:19,680 --> 00:19:25,660 if the RPF to either a source or an RP has changed. 239 00:19:25,660 --> 00:19:31,700 And that timer, according to the RFC, should be no more than 4.5 seconds. 240 00:19:31,700 --> 00:19:38,500 So if the RPF to either a known source or the RP changes, routers running 241 00:19:38,500 --> 00:19:43,560 PIMs should detect that within 4.5 seconds or less. 242 00:19:43,560 --> 00:19:47,060 And if they do detect that, then they'll send another join. 243 00:19:47,060 --> 00:19:56,840 They'll send what's called a trigger join up the new path to the RP. 244 00:19:56,840 --> 00:20:01,320 And what deletes this M route state? 245 00:20:01,320 --> 00:20:04,440 Well, we just saw that an IGMP leave came in. 246 00:20:04,440 --> 00:20:07,740 Let's go back to router two. 247 00:20:07,740 --> 00:20:11,540 Show IP M route. 248 00:20:11,540 --> 00:20:16,820 See, it's gone. Now, did it happen immediately? 249 00:20:16,820 --> 00:20:18,680 Well, let's find out. 250 00:20:18,680 --> 00:20:36,900 Let's create the join again. 251 00:20:36,900 --> 00:20:40,520 Okay, so now we have the star common g state. 252 00:20:40,520 --> 00:20:44,500 And we only have one receiver who lives on fast ethernet 00. 253 00:20:44,500 --> 00:20:47,160 Now, let's have that receiver send a leave message and let's see if that 254 00:20:47,160 --> 00:20:49,500 immediately kills the state. 255 00:20:49,500 --> 00:20:53,020 Because at that point, when that leave message comes in, that will remove 256 00:20:53,020 --> 00:20:55,820 this interface from the outgoing interface list. 257 00:20:55,820 --> 00:20:58,160 The outgoing interface list will be null. 258 00:20:58,160 --> 00:21:01,900 And our question is, once the outgoing interface list is null in a star 259 00:21:01,900 --> 00:21:04,480 common g enter, does that mean BAM, POOF? 260 00:21:04,480 --> 00:21:05,900 It's gone immediately? 261 00:21:05,900 --> 00:21:21,680 Or does it stay in there for a little bit of time? 262 00:21:21,680 --> 00:21:23,720 Okay, it's still in there. 263 00:21:23,720 --> 00:21:28,360 Outgoing interface list is null. 264 00:21:28,360 --> 00:21:32,960 And I believe this will be in here for about, let's see, is there a time 265 00:21:32,960 --> 00:21:35,900 it's counting down? 266 00:21:35,900 --> 00:21:37,820 Yep, this timer right here. 267 00:21:37,820 --> 00:21:40,080 Two minutes and 20 seconds. 268 00:21:40,080 --> 00:21:42,060 Now we're down to two minutes and 11 seconds. 269 00:21:42,060 --> 00:21:47,140 And when this timer counts down to zero, one minute and 56 seconds, I'm 270 00:21:47,140 --> 00:21:47,900 not going to wait. 271 00:21:47,900 --> 00:21:52,680 But when it counts down to zero, then this will be expired. 272 00:21:52,680 --> 00:21:59,140 It'll be gone. But notice we now have the P flag, which means our shared 273 00:21:59,140 --> 00:22:04,100 path, our path upstream to the rendezvous point, has been pruned. 274 00:22:04,100 --> 00:22:07,200 I sent a prune message up to the RP. 275 00:22:07,200 --> 00:22:12,880 And that's what indicates it right here. 276 00:22:12,880 --> 00:22:17,400 Also, so in this particular case, we see that this is going to be gone 277 00:22:17,400 --> 00:22:21,060 in two minutes. What if we go to the router in the middle? 278 00:22:21,060 --> 00:22:25,580 Router eight. Because he received that prune. 279 00:22:25,580 --> 00:22:32,580 See? He also pruned it. 280 00:22:32,580 --> 00:22:34,640 And he's also counting down. 281 00:22:34,640 --> 00:22:42,140 So this will count down to zero, and then this will end up being deleted. 282 00:22:42,140 --> 00:22:46,240 Someone asked, do I absolutely have to have a rendezvous point in order 283 00:22:46,240 --> 00:22:50,720 to get the multicast flowing from the source down to the receiver? 284 00:22:50,720 --> 00:22:54,180 The short answer is in PIM sparse mode, yes. 285 00:22:54,180 --> 00:22:58,240 Now if we were doing PIM dense mode, which just floods everything, no, 286 00:22:58,240 --> 00:23:00,040 we wouldn't need an rendezvous point. 287 00:23:00,040 --> 00:23:02,660 But sparse mode is trying to get away from that. 288 00:23:02,660 --> 00:23:05,740 And so if we're not going to flood everything, we've got to have that 289 00:23:05,740 --> 00:23:07,080 rendezvous point. 290 00:23:07,080 --> 00:23:10,440 So what are some things that could break this? 291 00:23:10,440 --> 00:23:14,200 Well, certainly, you know, a rendezvous point has to be configured. 292 00:23:14,200 --> 00:23:17,880 If all the routers know who the rendezvous point is, but the rendezvous 293 00:23:17,880 --> 00:23:21,700 point himself doesn't know that he's supposed to be playing that role, 294 00:23:21,700 --> 00:23:23,880 it's not going to work. 295 00:23:23,880 --> 00:23:26,860 People will be sending joins and stuff to him, but he won't know what 296 00:23:26,860 --> 00:23:29,880 to do with them because he's not the rendezvous point. 297 00:23:29,880 --> 00:23:35,060 If a particular router does not know who the rendezvous point is, that's 298 00:23:35,060 --> 00:23:37,160 going to fail. Now, how would you know that? 299 00:23:37,160 --> 00:23:42,700 Well, as we saw here, when you do show IPM route, let me zoom in on this 300 00:23:42,700 --> 00:23:49,900 a little bit. Every single router, even the RP itself, should have the 301 00:23:49,900 --> 00:23:52,300 IP address of the RP. 302 00:23:52,300 --> 00:23:56,640 If you ever do this command and you see a star, G entry where the RP field 303 00:23:56,640 --> 00:24:00,800 just says 0.0.0.0, that's bad. 304 00:24:00,800 --> 00:24:04,500 That means the router has no knowledge of the rendezvous point. 305 00:24:04,500 --> 00:24:07,940 There could be one out there, but this particular router that you're on 306 00:24:07,940 --> 00:24:09,900 doesn't know who it is. 307 00:24:09,900 --> 00:24:12,240 So that would be bad. 308 00:24:12,240 --> 00:24:17,220 Another thing, not only does the RP have to exist, not only do routers 309 00:24:17,220 --> 00:24:22,940 have to know who he is, but they have to have a valid unicast route to 310 00:24:22,940 --> 00:24:27,080 reach him. What would be an indication that that is failing? 311 00:24:27,080 --> 00:24:33,160 Well, if your incoming interface list is null and RPF neighbor is 0.0 312 00:24:33,160 --> 00:24:34,880 .0. That's your biggest indicator. 313 00:24:34,880 --> 00:24:42,580 If I have an address here, 3, 4, 3, 3, well, for example, let's do this. 314 00:24:42,580 --> 00:24:46,740 Right now, router, let's go to router 2. 315 00:24:46,740 --> 00:24:53,460 Show IPM route. Okay. 316 00:24:53,460 --> 00:24:56,600 So here, we have knowledge of the RP. 317 00:24:56,600 --> 00:25:01,220 Show IP RPF 3.4.3.3. 318 00:25:01,220 --> 00:25:03,920 And we know that he's learned it via EIGRP. 319 00:25:03,920 --> 00:25:05,300 So here's what I'm going to do. 320 00:25:05,300 --> 00:25:08,800 I'm going to shut down this interface on the RP. 321 00:25:08,800 --> 00:25:15,880 I'm basically going to get rid of the route to 3.4.3 on router 3. 322 00:25:15,880 --> 00:25:25,340 Okay. So router 2, show IP route. 323 00:25:25,340 --> 00:25:28,920 That route should disappear from the routing table very shortly. 324 00:25:28,920 --> 00:25:32,780 Still there, but EIGRP should learn that it's gone in just a moment. 325 00:25:32,780 --> 00:25:37,100 I might need to shut it on the other side as well. 326 00:25:37,100 --> 00:25:41,200 Actually, I do because these two routers are connected to a switch. 327 00:25:41,200 --> 00:25:43,440 They're not actually directly connected. 328 00:25:43,440 --> 00:25:46,500 So I'm going to shut down this sub-interface here on... 329 00:25:46,500 --> 00:25:50,460 So let's just do it this way. 330 00:25:50,460 --> 00:25:52,780 So let's go to router 3. 331 00:25:52,780 --> 00:25:58,760 Let's see. Now let's go to router 4. 332 00:25:58,760 --> 00:26:04,500 Interface fast-eathen at 0.0.34. 333 00:26:04,500 --> 00:26:09,000 Shut that down. Okay, so now it is well and truly gone. 334 00:26:09,000 --> 00:26:15,160 And yep, okay, so the 3.4.3 network is gone. 335 00:26:15,160 --> 00:26:21,400 So now when I do show IPM route, you can see he still knows who the RP 336 00:26:21,400 --> 00:26:24,780 is because I statically configured it. 337 00:26:24,780 --> 00:26:27,600 But RPF neighbor is all zeros. 338 00:26:27,600 --> 00:26:30,320 Incoming interface list is null. 339 00:26:30,320 --> 00:26:32,020 Which means I don't know how to get there. 340 00:26:32,020 --> 00:26:35,680 I have no way to get to the rendezvous point. 341 00:26:35,680 --> 00:26:38,900 So for sparse mode, those are the three conditions. 342 00:26:38,900 --> 00:26:40,860 Well, there's more than that, but those are the three main conditions. 343 00:26:40,860 --> 00:26:45,240 RP has to exist, got to have a route to him, and all the routers have 344 00:26:45,240 --> 00:26:49,220 to know who the rendezvous point is. 345 00:26:49,220 --> 00:26:51,360 Let's see here. There's some other questions. 346 00:26:51,360 --> 00:26:55,120 Let's see here. What if R8 itself is the RP as well? 347 00:26:55,120 --> 00:26:57,560 Is the shared tree going to be formed as well? 348 00:26:57,560 --> 00:27:04,020 Yes, so the question here is, what if R8 was the rendezvous point? 349 00:27:04,020 --> 00:27:07,220 Well, in that particular case, then the shared tree would be a lot shorter. 350 00:27:07,220 --> 00:27:11,120 The shared tree would just be this one hop between R8 and R2, and then 351 00:27:11,120 --> 00:27:14,420 from R2 down to the receiver. 352 00:27:14,420 --> 00:27:16,620 What if R2 was the rendezvous point? 353 00:27:16,620 --> 00:27:17,820 You could do that. 354 00:27:17,820 --> 00:27:22,100 Well, then there pretty much wouldn't be a shared tree that if R2 was 355 00:27:22,100 --> 00:27:25,400 the RP, then the shared tree would just be this direct connection here 356 00:27:25,400 --> 00:27:26,920 to the receiver. 357 00:27:26,920 --> 00:27:30,600 So in my particular topology, I intentionally made the rendezvous point 358 00:27:30,600 --> 00:27:34,680 a little bit further away so we could see more distinct hops of what was 359 00:27:34,680 --> 00:27:38,880 going along, but any of these routers could have been the PIM rendezvous