1 00:00:08,840 --> 00:00:12,040 So now we've got the shared tree built. 2 00:00:12,040 --> 00:00:17,660 At this point, if the multicast ever starts, once it reaches the RP, it'll 3 00:00:17,660 --> 00:00:22,560 go from router 3 to router 8, router 8 to router 2, and then out to router 4 00:00:22,560 --> 00:00:26,320 1. So we're ready to go. 5 00:00:26,320 --> 00:00:30,920 Okay, so let me, okay, I'll just keep this the way it is for now. 6 00:00:30,920 --> 00:00:34,620 It's starting to get a little cluttered, but I'll do my best here. 7 00:00:34,620 --> 00:00:40,680 Okay, so now, you know, a minute later, an hour later, the source finally 8 00:00:40,680 --> 00:00:43,940 starts up. He starts sending his multicast stream. 9 00:00:43,940 --> 00:00:57,440 So there it is. Router 4 on the back of the head. 10 00:00:57,440 --> 00:01:03,880 What action will router 4 take as a result of receiving this very first 11 00:01:03,880 --> 00:01:05,940 multicast packet? 12 00:01:05,940 --> 00:01:08,540 He's actually going to do a lot of stuff, so there's more than one correct 13 00:01:08,540 --> 00:01:21,240 answer here. Well, before he does anything, you know, the rule of PIM 14 00:01:21,240 --> 00:01:28,000 is that when you receive something, you can't create any PIM packets. 15 00:01:28,000 --> 00:01:33,380 You can't forward any multicast packets until you create state in the 16 00:01:33,380 --> 00:01:37,660 M route table. Without M route state, you can't do anything. 17 00:01:37,660 --> 00:01:41,500 So the first thing that this guy has to do is create M route state. 18 00:01:41,500 --> 00:01:46,160 So he says, okay, well, because I've received actually traffic from the 19 00:01:46,160 --> 00:01:54,060 source, I'm going to create s-coma-g state, which is 4.5.4.5 to 39.999. 20 00:01:54,060 --> 00:01:55,500 So that's our s-coma-g. 21 00:01:55,500 --> 00:02:03,140 Okay, so in this particular case, incoming interface, what's he going 22 00:02:03,140 --> 00:02:12,020 to have as his incoming interface? 23 00:02:12,020 --> 00:02:14,560 Well, it's going to be the interface where this multicast is actually 24 00:02:14,560 --> 00:02:16,360 coming in. Exactly. 25 00:02:16,360 --> 00:02:18,080 Fast ethernet, 0 slash 1. 26 00:02:18,080 --> 00:02:21,700 That's right. So that's what we'll have right here. 27 00:02:21,700 --> 00:02:28,920 What's going to be the RPF neighbor for this entry? 28 00:02:28,920 --> 00:02:34,580 What IP address will we stick in there? 29 00:02:34,580 --> 00:02:41,020 Exactly, Peter. That's right. 30 00:02:41,020 --> 00:02:42,780 He says, look, I'm the last hop router. 31 00:02:42,780 --> 00:02:45,560 I am connected directly to the source. 32 00:02:45,560 --> 00:02:48,400 This didn't come to me by way of any other router. 33 00:02:48,400 --> 00:02:51,280 So the next hop neighbor will be all zeros. 34 00:02:51,280 --> 00:02:54,480 I'm where it starts right here. 35 00:02:54,480 --> 00:02:58,880 Now, right now, what's going to be in the outgoing interface list as he 36 00:02:58,880 --> 00:03:15,800 creates this? Outgoing interface list is going to be null. 37 00:03:15,800 --> 00:03:18,940 Because he's going to say, look, even though I'm receiving this multicast, 38 00:03:18,940 --> 00:03:20,460 nobody's ever asked me for it. 39 00:03:20,460 --> 00:03:24,740 I've never received any kind of IGMP or PIM requests for this. 40 00:03:24,740 --> 00:03:31,760 So it's null. Now, if I did a show IPM route, right now is this all I 41 00:03:31,760 --> 00:03:37,320 would see, this s-energy entry for this state? 42 00:03:37,320 --> 00:03:44,400 You got a 50% chance of getting this right. 43 00:03:44,400 --> 00:03:52,620 Yes or no? No. The answer is, no, this is not all you would see. 44 00:03:52,620 --> 00:03:58,960 Because while routers over here can have star comedies all by themselves, 45 00:03:58,960 --> 00:04:02,700 an s-coma-g cannot be by itself. 46 00:04:02,700 --> 00:04:06,320 An s-coma-g is, you remember that little brother big brother analogy? 47 00:04:06,320 --> 00:04:08,820 I said that the star comedie is the big brother. 48 00:04:08,820 --> 00:04:12,040 He can go out. He can saunter around the neighborhood all by himself. 49 00:04:12,040 --> 00:04:15,100 But the s-coma-g is the little seven-year-old brother. 50 00:04:15,100 --> 00:04:18,240 We don't want him out by himself because something might happen to him. 51 00:04:18,240 --> 00:04:20,960 So he's got to go along with the big brother. 52 00:04:20,960 --> 00:04:25,920 So we got to create the star comedie entry if one does not already exist. 53 00:04:25,920 --> 00:04:29,080 In this case, one did not exist. 54 00:04:29,080 --> 00:04:33,220 So we'll populate that. 55 00:04:33,220 --> 00:04:38,160 Getting a little cluttered here, but I'll try to fit everything in. 56 00:04:38,160 --> 00:04:39,900 Incoming interface will be fast. 57 00:04:39,900 --> 00:04:43,300 Ethernet 0 slash 0 dot 34 because that's the interface that leads to the 58 00:04:43,300 --> 00:04:44,600 rendezvous point. 59 00:04:44,600 --> 00:04:50,040 Our PF neighbor will be 3 dot 4 dot 3 dot 3. 60 00:04:50,040 --> 00:04:55,040 An outgoing interface list, once again, will be null. 61 00:04:55,040 --> 00:04:58,520 Because we only populate the outgoing interface list with something if 62 00:04:58,520 --> 00:05:01,220 we receive a request of some sort. 63 00:05:01,220 --> 00:05:03,520 And we've never received a request. 64 00:05:03,520 --> 00:05:06,260 Okay, so now we've created MROUT STATE. 65 00:05:06,260 --> 00:05:08,740 But we still haven't answered the question, what are we doing with this 66 00:05:08,740 --> 00:05:10,820 very first multicast packet? 67 00:05:10,820 --> 00:05:15,340 Now that the MROUT STATE is created, what are we going to do with that? 68 00:05:15,340 --> 00:05:24,840 We are going to register it. 69 00:05:24,840 --> 00:05:26,020 We're going to send it. 70 00:05:26,020 --> 00:05:31,780 We're going to encapsulate it inside of a PIM register packet. 71 00:05:31,780 --> 00:05:35,800 So here it goes, and that's going to be unicasted. 72 00:05:35,800 --> 00:05:41,420 So let's see if I can do this justice here. 73 00:05:41,420 --> 00:05:51,580 So this is going to be unicasted from R4 down to R3. 74 00:05:51,580 --> 00:05:58,280 And a sniffer trace will say PIM REGISTER. 75 00:05:58,280 --> 00:06:03,580 Now once R3 gets that PIM REGISTER, just like R4 did a whole bunch of 76 00:06:03,580 --> 00:06:06,340 stuff simultaneously when he got the first packet, he created all the 77 00:06:06,340 --> 00:06:10,220 state and he registered it, well R3, he's going to do a whole bunch of 78 00:06:10,220 --> 00:06:13,080 stuff simultaneously once he gets this register. 79 00:06:13,080 --> 00:06:18,280 Because he finally sees the actual source, he can create an S-comaG entry. 80 00:06:18,280 --> 00:06:20,560 I'm not going to sort of run out of room here, so I'm just going to put 81 00:06:20,560 --> 00:06:22,200 just the basics. 82 00:06:22,200 --> 00:06:27,520 4.5.4.5, 2.39.999. 83 00:06:27,520 --> 00:06:32,040 So that is my S-comaG entry. 84 00:06:32,040 --> 00:06:38,100 And if you have any questions about what the incoming interface is or 85 00:06:38,100 --> 00:06:44,180 anything like that, so in this particular S-comaG entry, I'll go ahead 86 00:06:44,180 --> 00:06:48,740 and put this. When he creates it, he'll say, okay, well, if I've already 87 00:06:48,740 --> 00:06:53,620 got an existing star-comaG, it was just hanging around and waiting. 88 00:06:53,620 --> 00:06:56,940 And now I create an S-comaG because I actually see the multicast. 89 00:06:56,940 --> 00:07:00,520 I'll go back to my star-comaG and whatever is in my outgoing interface 90 00:07:00,520 --> 00:07:05,080 list there, I'll copy it into my S-comaG. 91 00:07:05,080 --> 00:07:11,100 The only situation where that would not happen is if by doing so, you 92 00:07:11,100 --> 00:07:14,840 would have a duplicate of where the S-comaG incoming interface is the 93 00:07:14,840 --> 00:07:17,580 same as the outgoing interface list. 94 00:07:17,580 --> 00:07:18,800 You can't have that. 95 00:07:18,800 --> 00:07:21,280 You can't have an interface in the outgoing interface list that's the 96 00:07:21,280 --> 00:07:22,800 same as the incoming interface. 97 00:07:22,800 --> 00:07:24,360 That's against the rules of PIM. 98 00:07:24,360 --> 00:07:30,080 But in this case, we don't have to worry about that. 99 00:07:30,080 --> 00:07:32,540 So somebody in the live audience asked a good question. 100 00:07:32,540 --> 00:07:34,440 They're saying, so that's a unicast message, right? 101 00:07:34,440 --> 00:07:36,020 That PIM register is unicast. 102 00:07:36,020 --> 00:07:41,420 So if I had two or three or four routers between router three and router 103 00:07:41,420 --> 00:07:44,900 four, would they have any multicast state? 104 00:07:44,900 --> 00:07:46,040 No, they wouldn't. 105 00:07:46,040 --> 00:07:48,460 Because if there was any routers in between here, they would just see 106 00:07:48,460 --> 00:07:53,500 a unicast packet with a source address of four, destination of three, 107 00:07:53,500 --> 00:07:54,360 and they would just route it. 108 00:07:54,360 --> 00:07:58,560 Just like they're routing a telnet or a web browser request or an FTP. 109 00:07:58,560 --> 00:08:02,520 So if there were any routers here in between right now, their M route 110 00:08:02,520 --> 00:08:03,800 state would show nothing. 111 00:08:03,800 --> 00:08:06,820 They're not aware that the multicast is actually traveling through them 112 00:08:06,820 --> 00:08:14,440 as a unicast. Okay, so router three creates the S-comaG state, and then 113 00:08:14,440 --> 00:08:18,240 he uses that to actually forward it down the tree. 114 00:08:18,240 --> 00:08:21,560 So he says, okay, I'm going to unencapsulate this register, revealing 115 00:08:21,560 --> 00:08:29,320 the multicast inside, and I'm going to forward it down the tree, and then 116 00:08:29,320 --> 00:08:33,340 router eight, when he gets it, well, that will create S-comaG state in 117 00:08:33,340 --> 00:08:41,700 him. I'll just put that, because we're running out of room. 118 00:08:41,700 --> 00:08:45,600 He will then forward it down the shared tree to router two. 119 00:08:45,600 --> 00:08:47,200 Now let's back up here for a second. 120 00:08:47,200 --> 00:08:50,300 Before I talk about what happens on router two, let's go back to the rendezvous 121 00:08:50,300 --> 00:08:55,980 point. Exactly, Brandon, the pin register is basically a unicast tunnel 122 00:08:55,980 --> 00:08:58,640 for the multicast packet. 123 00:08:58,640 --> 00:09:03,120 Actually, it's kind of interesting that you bring that up. 124 00:09:03,120 --> 00:09:08,500 Once you go onto router and you very first configure the RP on him, you 125 00:09:08,500 --> 00:09:12,660 tell him who the RP is, check this out. 126 00:09:12,660 --> 00:09:15,540 I'll just go, it doesn't really matter which router I pick, but all for 127 00:09:15,540 --> 00:09:18,100 the sake of purposes, I'll go to router four. 128 00:09:18,100 --> 00:09:26,020 Look at this. It actually creates a tunnel interface. 129 00:09:26,020 --> 00:09:33,440 Yeah, and if you do show interface tunnel zero, it actually says, pem 130 00:09:33,440 --> 00:09:35,400 register tunnel. 131 00:09:35,400 --> 00:09:40,400 Every router will have that, because at any given time a router never 132 00:09:40,400 --> 00:09:43,120 knows, am I going to need to register? 133 00:09:43,120 --> 00:09:45,840 Is there ever going to be a multicast that hits me that I'm going to need 134 00:09:45,840 --> 00:09:47,360 to register to the RP? 135 00:09:47,360 --> 00:09:53,160 So as soon as a router knows who the RP is, it dynamically creates this 136 00:09:53,160 --> 00:09:54,440 register tunnel. 137 00:09:54,440 --> 00:09:57,820 So it's ready and waiting to be used in case it ever needs to register 138 00:09:57,820 --> 00:10:00,900 anything. Yeah, so that's pretty cool. 139 00:10:00,900 --> 00:10:07,880 Okay, so router three, he has just forwarded the multicast packet down. 140 00:10:07,880 --> 00:10:12,760 Now I mentioned that the problem with these register packets is, it consumes 141 00:10:12,760 --> 00:10:17,360 a little bit more CPU resources in the router who is doing the registering, 142 00:10:17,360 --> 00:10:22,720 the router who is unencapsulating or deencapsulating the register. 143 00:10:22,720 --> 00:10:25,920 So router three says, okay, I don't want to keep receiving these register 144 00:10:25,920 --> 00:10:28,580 packets if this is making me work extra hard. 145 00:10:28,580 --> 00:10:33,680 I would prefer just to receive the native multicast as it is, pure multicast. 146 00:10:33,680 --> 00:10:37,900 He says, so in order to do that, I got to let my upstream neighbors know 147 00:10:37,900 --> 00:10:42,500 in the direction of the shortest path tree that that's what I want. 148 00:10:42,500 --> 00:10:47,720 So router three says, okay, now that I got this s-comage state, and according 149 00:10:47,720 --> 00:10:53,460 to me, my shortest path tree is interface fast-eath and at zero zero. 150 00:10:53,460 --> 00:10:57,620 Right, he says, when I do an RPF lookup on the source, four, five, four, 151 00:10:57,620 --> 00:11:01,660 five, my RPF lookup says my shortest path is going out fast-eath and at 152 00:11:01,660 --> 00:11:08,240 zero zero. So router three will then send another kind of PIM packet. 153 00:11:08,240 --> 00:11:12,180 What kind of PIM packet will router three send at this point in order 154 00:11:12,180 --> 00:11:23,780 to open up his shortest path? 155 00:11:23,780 --> 00:11:31,820 He will send a PIM s-comagee join, an s-comagee join. 156 00:11:31,820 --> 00:11:35,280 And if there were any routers in the middle here between these two guys 157 00:11:35,280 --> 00:11:40,360 who did not previously have any multicast state because the register was 158 00:11:40,360 --> 00:11:43,900 just transparently going through them, if there were any routers, let's 159 00:11:43,900 --> 00:11:47,140 just put a fake one right here for the time being, let's just say router 160 00:11:47,140 --> 00:11:49,500 x was right here. 161 00:11:49,500 --> 00:11:56,200 Now upon receipt of this s-comagee join, router x would create s-comagee 162 00:11:56,200 --> 00:11:59,140 state in his m-route table. 163 00:11:59,140 --> 00:12:03,940 And he would create star-comagee state because the s-comagee can't live 164 00:12:03,940 --> 00:12:07,400 by itself. It's too scared to go walking out there in the world by itself. 165 00:12:07,400 --> 00:12:09,020 It's got to have big brother along with him. 166 00:12:09,020 --> 00:12:12,040 So it creates star -comagee state also. 167 00:12:12,040 --> 00:12:16,780 And then he would forward the s-comagee upstream and eventually it would 168 00:12:16,780 --> 00:12:18,500 reach router four. 169 00:12:18,500 --> 00:12:23,280 Once router four receives this s-comagee he says, oh, somebody is actually 170 00:12:23,280 --> 00:12:25,400 asking me for this multicast. 171 00:12:25,400 --> 00:12:33,100 So now in my s-comagee entry, I can remove my null outgoing interface 172 00:12:33,100 --> 00:12:38,960 and I will replace it with the interface where I just received the request, 173 00:12:38,960 --> 00:12:45,040 the s-comagee request, which is fast-eathonet00.34. 174 00:12:45,040 --> 00:12:50,800 That now gives router four permission to start forwarding the multicast 175 00:12:50,800 --> 00:12:55,620 natively down fast-eathonet00.34. 176 00:12:55,620 --> 00:13:04,340 But remember, when that s-comagee join came in, router four doesn't necessarily 177 00:13:04,340 --> 00:13:08,120 know that it was because the rendezvous point initiated it. 178 00:13:08,120 --> 00:13:10,140 He doesn't necessarily know that. 179 00:13:10,140 --> 00:13:13,440 All he knows is that there's a downstream neighbor who wants to open up 180 00:13:13,440 --> 00:13:17,820 the multicast. So router four says, okay, I'll send the multicast in his 181 00:13:17,820 --> 00:13:22,840 pure native form down this link, but I don't know if the rendezvous point 182 00:13:22,840 --> 00:13:24,780 has even received my register. 183 00:13:24,780 --> 00:13:26,740 Because remember, it's not like TCP. 184 00:13:26,740 --> 00:13:28,400 There's no acknowledgments or anything here. 185 00:13:28,400 --> 00:13:31,800 When router four sent the register he just sent it out into the void and 186 00:13:31,800 --> 00:13:35,400 he had no idea if the RP actually got it or not. 187 00:13:35,400 --> 00:13:39,420 So he says, well, in addition to sending the multicast in his native form 188 00:13:39,420 --> 00:13:44,340 down this way to router X, I also need to keep on registering. 189 00:13:44,340 --> 00:13:45,620 I can't stop that. 190 00:13:45,620 --> 00:13:48,720 Because until the rendezvous point confirms that he's received my register, 191 00:13:48,720 --> 00:13:50,220 I got to keep going. 192 00:13:50,220 --> 00:13:55,580 So now the multicast is coming down this tree and router three gets two 193 00:13:55,580 --> 00:14:00,520 copies of it. He gets the native multicast because now this path has been 194 00:14:00,520 --> 00:14:06,060 opened up. And he receives that exact same multicast packet encapsulated 195 00:14:06,060 --> 00:14:08,120 inside of a register. 196 00:14:08,120 --> 00:14:10,980 Now, router three says, okay, great. 197 00:14:10,980 --> 00:14:14,860 I know that my shortest path to the source is working. 198 00:14:14,860 --> 00:14:16,380 I know it's opened up. 199 00:14:16,380 --> 00:14:19,880 Because if it wasn't working, I would not have received the normal multicast, 200 00:14:19,880 --> 00:14:21,780 the real native multicast. 201 00:14:21,780 --> 00:14:25,100 He says, so since I got the real multicast, which he continues to forward 202 00:14:25,100 --> 00:14:30,940 downstream, he says, now I can send a register stop message. 203 00:14:30,940 --> 00:14:36,280 Which I'm totally running out of room here, but he can send a PIM register 204 00:14:36,280 --> 00:14:43,620 stop. And that, just like it says, that will cause router four to stop 205 00:14:43,620 --> 00:14:47,820 registering. And now he will just send the native multicast in his pure 206 00:14:47,820 --> 00:14:52,620 form down to router three and away it will go. 207 00:14:52,620 --> 00:14:56,040 Now, I mentioned when the very first multicast packet, when that first 208 00:14:56,040 --> 00:15:00,820 registration was unencapsulated, deencapsulated, and eventually made its 209 00:15:00,820 --> 00:15:03,320 way to router two, I said, let's pause for a second. 210 00:15:03,320 --> 00:15:05,320 Let's go back to the rendezvous point because router two is going to do 211 00:15:05,320 --> 00:15:06,380 a bunch of stuff. 212 00:15:06,380 --> 00:15:08,840 So let's sort of go back in time. 213 00:15:08,840 --> 00:15:12,820 Let's flip the clock back just like a second or two to when that very 214 00:15:12,820 --> 00:15:15,840 first multicast packet hit router two. 215 00:15:15,840 --> 00:15:17,120 Well, guess what? 216 00:15:17,120 --> 00:15:26,300 Router two, when he gets it, he creates S, comma G state, because now 217 00:15:26,300 --> 00:15:28,100 he's seen the packet. 218 00:15:28,100 --> 00:15:32,840 And he says, okay, he goes back to his star, comma G entry, and he sees 219 00:15:32,840 --> 00:15:35,640 a little flag in there. 220 00:15:35,640 --> 00:15:42,240 The C flag, which says, oh, I remember I created the star, comma G state 221 00:15:42,240 --> 00:15:46,320 because a directly connected, that's what the C stands for, a directly 222 00:15:46,320 --> 00:15:49,580 connected receiver asked me for this multicast. 223 00:15:49,580 --> 00:15:51,300 I got a membership report. 224 00:15:51,300 --> 00:15:55,700 So he says, that means I am what PIM calls a leaf router. 225 00:15:55,700 --> 00:15:57,900 I'm at the end of the branch. 226 00:15:57,900 --> 00:16:03,140 And because I am a leaf router, I have the authority to open up the shortest 227 00:16:03,140 --> 00:16:08,960 path tree. For myself, I can move away from the shared tree and try to 228 00:16:08,960 --> 00:16:12,020 get these packets in a more efficient manner. 229 00:16:12,020 --> 00:16:15,640 So if we assume here that this serial link is actually the shortest path 230 00:16:15,640 --> 00:16:19,960 tree from router two's perspective, he's basically going to do the exact 231 00:16:19,960 --> 00:16:22,460 same thing that rendezvous point did. 232 00:16:22,460 --> 00:16:29,100 He's going to send an S, comma G join upstream. 233 00:16:29,100 --> 00:16:36,560 And when router four gets that, he will in his outgoing interface list 234 00:16:36,560 --> 00:16:43,600 now add serial 010 to that outgoing interface. 235 00:16:43,600 --> 00:16:47,960 And now the native multicast will start flowing down this way. 236 00:16:47,960 --> 00:16:53,580 Once router two gets that native multicast, he now says, okay, awesome. 237 00:16:53,580 --> 00:16:56,920 I'm now getting the native multicast on my shortest path tree. 238 00:16:56,920 --> 00:17:02,020 But hmm, I'm also getting copies of that packet down the shared tree. 239 00:17:02,020 --> 00:17:04,620 I don't need those packets down the shared tree anymore. 240 00:17:04,620 --> 00:17:05,780 I don't want those. 241 00:17:05,780 --> 00:17:12,240 So review question, what does router two do in order to try to stop the 242 00:17:12,240 --> 00:17:17,540 packets from coming down the shared tree? 243 00:17:17,540 --> 00:17:29,200 That's right. He sends a PIM prune message. 244 00:17:29,200 --> 00:17:34,300 Exactly a PIM prune message, which is the exact same format as a PIM join 245 00:17:34,300 --> 00:17:38,480 message. Just instead of saying number of groups joined, it says number 246 00:17:38,480 --> 00:17:40,440 of groups pruned. 247 00:17:40,440 --> 00:17:45,520 So he sends a PIM prune. 248 00:17:45,520 --> 00:17:51,480 In this particular case, he'll actually have the source, 4.5.4.5. 249 00:17:51,480 --> 00:17:54,500 He'll have the group. 250 00:17:54,500 --> 00:18:00,920 But inside there, he'll have the RP bit set, which tells his upstream 251 00:18:00,920 --> 00:18:04,660 neighbor, hey, don't forward this to the source. 252 00:18:04,660 --> 00:18:07,180 Even though I'm listing the source's address here, that's not where this 253 00:18:07,180 --> 00:18:09,000 message is ultimately going. 254 00:18:09,000 --> 00:18:11,760 I need you to forward this to the rendezvous point. 255 00:18:11,760 --> 00:18:16,060 So then router eight will prune off zero slash one from his outgoing interface 256 00:18:16,060 --> 00:18:22,880 list. He'll create a prune message, which he'll then send up to router 257 00:18:22,880 --> 00:18:28,180 three. Router three will then prune off his outgoing interface list. 258 00:18:28,180 --> 00:18:34,780 And now router three will say, okay, well, nobody needs the multicast 259 00:18:34,780 --> 00:18:38,820 for me anymore. I have no more interfaces in my outgoing interface list. 260 00:18:38,820 --> 00:18:40,140 So guess what he'll do? 261 00:18:40,140 --> 00:18:43,300 He'll send a prune up towards the source. 262 00:18:43,300 --> 00:18:47,460 And so eventually, after just like a second or two, the traffic will no 263 00:18:47,460 --> 00:18:51,200 longer, he'll stop going through the rendezvous point, and it will only 264 00:18:51,200 --> 00:18:57,140 be going down the source path tree directly to router two. 265 00:18:57,140 --> 00:19:02,560 So what questions do you have? 266 00:19:02,560 --> 00:19:06,740 That completes my review of this process in the live audience. 267 00:19:06,740 --> 00:19:22,160 Do you have any questions? 268 00:19:22,160 --> 00:19:23,900 Peter asks a good question. 269 00:19:23,900 --> 00:19:26,460 He says, hey, I remember something called a null register. 270 00:19:26,460 --> 00:19:29,640 Who sends that and under what conditions is it sent? 271 00:19:29,640 --> 00:19:32,540 Okay, so here we are in the present. 272 00:19:32,540 --> 00:19:36,460 Right now, the multicast is hitting router four, and the only outgoing 273 00:19:36,460 --> 00:19:42,300 interface that router four has is serial zero slash one size zero. 274 00:19:42,300 --> 00:19:45,320 So he's sending it down directly that way. 275 00:19:45,320 --> 00:19:51,520 But router four, he says, well, every few seconds he has his thought. 276 00:19:51,520 --> 00:19:55,900 Router four, every few seconds, says, well, there's a possibility that 277 00:19:55,900 --> 00:20:01,160 somebody else in the last few seconds may have joined the stream and sent 278 00:20:01,160 --> 00:20:03,740 their request to the rendezvous point. 279 00:20:03,740 --> 00:20:06,360 And maybe the rendezvous point sitting there right now, twiddling his 280 00:20:06,360 --> 00:20:09,300 thumb saying, man, I wish that stream would start because I've got somebody 281 00:20:09,300 --> 00:20:10,800 new who wants it. 282 00:20:10,800 --> 00:20:13,680 But remember, the rendezvous point may have forgotten about the stream. 283 00:20:13,680 --> 00:20:15,800 He may have no state anymore. 284 00:20:15,800 --> 00:20:20,560 So when somebody else joined it, that created new star, comma G state 285 00:20:20,560 --> 00:20:22,060 and the rendezvous point. 286 00:20:22,060 --> 00:20:25,600 But he forgot about his previous S, comma G state. 287 00:20:25,600 --> 00:20:30,140 That's gone. So router four says, just in case that may have happened, 288 00:20:30,140 --> 00:20:32,160 I'm going to send a null register. 289 00:20:32,160 --> 00:20:33,540 It's about every five seconds. 290 00:20:33,540 --> 00:20:36,240 Every five seconds or so, I'm going to send a null register down to router 291 00:20:36,240 --> 00:20:40,900 three, which doesn't actually have the multicast packet inside of it. 292 00:20:40,900 --> 00:20:43,420 It just basically says, hey, rendezvous point. 293 00:20:43,420 --> 00:20:47,920 Just want to remind you that I've got this multicast stream going. 294 00:20:47,920 --> 00:20:49,840 I'm forwarding it to other people. 295 00:20:49,840 --> 00:20:53,840 And if you want it, you might want to ask me for it. 296 00:20:53,840 --> 00:20:55,460 So that's what a null register is. 297 00:20:55,460 --> 00:20:57,240 It goes out every five seconds. 298 00:20:57,240 --> 00:21:00,820 It's generated by router four because he's the one that's directly connected 299 00:21:00,820 --> 00:21:04,760 to the source. And it's his way of reminding the rendezvous point, hey, 300 00:21:04,760 --> 00:21:05,880 do you want this? 301 00:21:05,880 --> 00:21:10,060 Now, if the rendezvous point does want it, he'll send an S, comma G join 302 00:21:10,060 --> 00:21:12,400 to reopen that path. 303 00:21:12,400 --> 00:21:16,800 If the rendezvous point doesn't want it, he'll send another register stop. 304 00:21:16,800 --> 00:21:18,080 He'll say, I don't need this. 305 00:21:18,080 --> 00:21:19,080 And so that'll happen. 306 00:21:19,080 --> 00:21:20,600 Every five seconds. 307 00:21:20,600 --> 00:21:25,940 So yeah, that null register is always generated by the first hop router. 308 00:21:25,940 --> 00:21:30,820 The router that's directly connected to the multicast source. 309 00:21:30,820 --> 00:21:35,420 Are there any other questions? 310 00:21:35,420 --> 00:21:43,240 And yes, Josh asked a good question. 311 00:21:43,240 --> 00:21:46,920 He said, going back to router two, when router two switched over to the 312 00:21:46,920 --> 00:21:49,840 shortest path, just Josh just wants confirmation. 313 00:21:49,840 --> 00:21:51,080 He's absolutely correct. 314 00:21:51,080 --> 00:21:54,380 The way that the router determines the shortest path is once he looks 315 00:21:54,380 --> 00:21:58,620 at the source address of that multicast, which in this case is four, five, 316 00:21:58,620 --> 00:21:59,460 four, five, five, four. 317 00:21:59,460 --> 00:22:01,500 He does an RPF check. 318 00:22:01,500 --> 00:22:04,620 He goes into his unicast routing table and says, what's the best route 319 00:22:04,620 --> 00:22:07,580 I have back to that source? 320 00:22:07,580 --> 00:22:12,180 And he might have a static route or an EI-JRP route or an OSPF route. 321 00:22:12,180 --> 00:22:15,360 But in this case, he had some kind of a route that said the best way to 322 00:22:15,360 --> 00:22:19,920 get back to the four, five, four network is via serial 010. 323 00:22:19,920 --> 00:22:22,860 So that's how he determined what his shortest path would be.