1 00:00:08,460 --> 00:00:12,500 So, up to this point in time in the previous videos, we've talked about 2 00:00:12,500 --> 00:00:18,280 how the shared tree is built, all the way up to the rendezvous point and 3 00:00:18,280 --> 00:00:19,760 then stopping there. 4 00:00:19,760 --> 00:00:22,720 And then the last video we talked about, okay, once that source, that 5 00:00:22,720 --> 00:00:27,040 server, starts sending out its multicast traffic, the very first router 6 00:00:27,040 --> 00:00:30,960 it's connected to, which you would consider the default gateway for the 7 00:00:30,960 --> 00:00:36,960 source, will take those multicast packets and register them with the PIM 8 00:00:36,960 --> 00:00:38,160 rendezvous point. 9 00:00:38,160 --> 00:00:41,020 And we talked about how that's basically taking the multicast packets 10 00:00:41,020 --> 00:00:45,800 and wrapping them inside of a PIM header and then wrapping them inside 11 00:00:45,800 --> 00:00:51,340 of a unicast IP header from the router to the RP. 12 00:00:51,340 --> 00:00:58,220 So now we're going to look at joining the shortest path tree. 13 00:00:58,220 --> 00:01:05,960 Now recall, I mentioned this in the other video that each router has its 14 00:01:05,960 --> 00:01:10,460 own perspective on what the shortest path tree is, right? 15 00:01:10,460 --> 00:01:14,460 As soon as a router receives a multicast packet, all of a sudden it has 16 00:01:14,460 --> 00:01:18,320 this awakening, it says aha, this is what I've been looking for and now 17 00:01:18,320 --> 00:01:21,840 I know the critical component I didn't know before. 18 00:01:21,840 --> 00:01:23,520 I know who the source is. 19 00:01:23,520 --> 00:01:29,000 So that router, excuse me, then doesn't RP up look up. 20 00:01:29,000 --> 00:01:33,160 It goes into its unicast routing table and says, for me, what's the shortest 21 00:01:33,160 --> 00:01:35,500 path back to that source? 22 00:01:35,500 --> 00:01:39,520 Now that might lead you to ask the question, okay, so does that mean that 23 00:01:39,520 --> 00:01:43,940 anywhere along the tree from the source all the way down to the receiver, 24 00:01:43,940 --> 00:01:48,220 if there's any branches anywhere that branch off and is actually shortest 25 00:01:48,220 --> 00:01:52,000 path, does that mean that any router anywhere along that path is allowed 26 00:01:52,000 --> 00:01:56,180 to switch over to the shortest path tree and leave that core tree and 27 00:01:56,180 --> 00:01:57,980 leave the rendezvous points tree? 28 00:01:57,980 --> 00:02:00,560 Not quite. And so we're going to talk about that here. 29 00:02:00,560 --> 00:02:05,780 But in this particular situation, the rendezvous point does have permission 30 00:02:05,780 --> 00:02:09,240 to do that because remember at this point, the rendezvous point is receiving 31 00:02:09,240 --> 00:02:13,800 register packets, which is causing his CPU to work a little bit harder 32 00:02:13,800 --> 00:02:19,940 than it should. Normally, what we really want is when a multicast packet 33 00:02:19,940 --> 00:02:25,140 comes in, we just want to look up the entry in the mRout table and forward 34 00:02:25,140 --> 00:02:28,720 it on its way. As a matter of fact, if you're running SEP, Cisco Express 35 00:02:28,720 --> 00:02:32,440 Forwarding, you can even do all that without potentially interrupting 36 00:02:32,440 --> 00:02:36,100 the CPU at all, like for example, on switches. 37 00:02:36,100 --> 00:02:40,640 If you've got a multi-layer switch with T cams and forwarding A6 and forwarding 38 00:02:40,640 --> 00:02:46,720 engines and stuff, the CPU and the switch is doing all the PIM processing. 39 00:02:46,720 --> 00:02:51,280 So when you PIM joins, PIM prunes, PIM register packets, they have to 40 00:02:51,280 --> 00:02:53,740 go up to the CPU to be processed. 41 00:02:53,740 --> 00:02:58,240 So if that multi-layer switch, which is sort of acting like a router, 42 00:02:58,240 --> 00:03:02,800 is receiving tons of register packets, that's all going to a CPU. 43 00:03:02,800 --> 00:03:06,620 Whereas if that was just coming in as native multicast, that could all 44 00:03:06,620 --> 00:03:10,420 be handled in hardware on his T cams and his A6 and stuff and it would 45 00:03:10,420 --> 00:03:14,700 never even bother the CPU, never even be seen by the CPU. 46 00:03:14,700 --> 00:03:17,300 So ideally, that's what we want. 47 00:03:17,300 --> 00:03:22,460 So we want to stop this registration process as quickly as we can so we 48 00:03:22,460 --> 00:03:24,440 don't have to do all that extra work. 49 00:03:24,440 --> 00:03:29,660 So we mentioned that the way that that's going to happen is that the PIM 50 00:03:29,660 --> 00:03:38,380 RP is going to send a join message called an s, g join upstream to open 51 00:03:38,380 --> 00:03:42,020 up his own shortest path. 52 00:03:42,020 --> 00:03:44,920 And that's his way of saying, okay, I want to open it up so the multicast 53 00:03:44,920 --> 00:03:47,360 can flow down in its native form. 54 00:03:47,360 --> 00:03:51,580 Once that starts happening and I see that, I've confirmed that, then the 55 00:03:51,580 --> 00:03:53,780 RP says stop the register. 56 00:03:53,780 --> 00:03:54,840 I don't want that anymore. 57 00:03:54,840 --> 00:03:57,940 Stop doing the registration process and he actually sends a PIM register 58 00:03:57,940 --> 00:04:00,520 stop. We talked about that. 59 00:04:00,520 --> 00:04:05,000 Now, I know it's also in this particular case, R2 is joining the shortest 60 00:04:05,000 --> 00:04:09,580 path tree. Now, let me go back to my original drawing here for a moment. 61 00:04:09,580 --> 00:04:14,980 This is what our current topology is like. 62 00:04:14,980 --> 00:04:23,840 Now, I know as I intentionally designed this so that R8 would be able 63 00:04:23,840 --> 00:04:28,800 to get directly to router four without going to router three. 64 00:04:28,800 --> 00:04:35,660 So one might look at this and say, okay, so I would assume then that when 65 00:04:35,660 --> 00:04:39,260 the first multicast packet, when the first register packet, the first 66 00:04:39,260 --> 00:04:46,080 register packet comes downstream to router three and router three de encapsulates 67 00:04:46,080 --> 00:04:50,620 that and sends it as a native multicast down to router eight, not only 68 00:04:50,620 --> 00:04:55,340 would router three send his join upstream trying to join his shortest 69 00:04:55,340 --> 00:05:00,300 path tree, wouldn't we expect router eight to do that as well? 70 00:05:00,300 --> 00:05:04,620 I mean, after all, router eight now knows who the source is and he should 71 00:05:04,620 --> 00:05:08,140 look in his routing table and say, oh, wait, I got this BAM straight connection 72 00:05:08,140 --> 00:05:10,520 over here to the source. 73 00:05:10,520 --> 00:05:12,560 That's my shortest path. 74 00:05:12,560 --> 00:05:17,540 Wouldn't we expect him to also join the shortest path tree? 75 00:05:17,540 --> 00:05:19,200 Well, we're going to take a look at this in a sniffer trace. 76 00:05:19,200 --> 00:05:22,500 I'll tell you exactly what the RFC says. 77 00:05:22,500 --> 00:05:29,160 The RFC for PIMS sparse mode says that the only people that are allowed 78 00:05:29,160 --> 00:05:34,980 to switch over from a shared tree to a shortest path tree are either number 79 00:05:34,980 --> 00:05:39,740 one, the rendezvous point, like we've been talking about, or the last 80 00:05:39,740 --> 00:05:44,580 hop router. In other words, the router that's directly connected to the 81 00:05:44,580 --> 00:05:49,200 receiver. So according to the RFC, in this particular diagram, router 82 00:05:49,200 --> 00:05:53,800 eight would not be allowed to initiate that process. 83 00:05:53,800 --> 00:05:58,100 He would have to receive the multicast on the shared tree and then just 84 00:05:58,100 --> 00:06:02,060 continue to pass it along downstream to router two. 85 00:06:02,060 --> 00:06:05,500 And because router two is directly connected to the receiver, remember, 86 00:06:05,500 --> 00:06:09,700 we saw that with a little C flag because he received the membership report, 87 00:06:09,700 --> 00:06:14,820 that means it would be his responsibility to connect over to the shortest 88 00:06:14,820 --> 00:06:19,220 path tree, not router eight's responsibility. 89 00:06:19,220 --> 00:06:21,760 So we'll actually take a look at that in a sniffer trace and see if that's 90 00:06:21,760 --> 00:06:24,460 true because we know that sometimes with Cisco routers and stuff, they 91 00:06:24,460 --> 00:06:26,660 don't exactly follow the RFC. 92 00:06:26,660 --> 00:06:28,620 So let's see if that's going to happen. 93 00:06:28,620 --> 00:06:33,120 But before we do that, just don't want to jump ahead here. 94 00:06:33,120 --> 00:06:39,400 And by the way, this router two in the RFC, you might see it term two 95 00:06:39,400 --> 00:06:39,880 different thing. 96 00:06:39,880 --> 00:06:44,300 I've seen it called last hop router and I've also seen it termed leaf 97 00:06:44,300 --> 00:06:47,040 routers. It's like a leaf at the edge of the tree. 98 00:06:47,040 --> 00:06:49,640 It goes, the tree goes no further than that. 99 00:06:49,640 --> 00:06:53,660 So they'll call leaf routers or last hop routers. 100 00:06:53,660 --> 00:07:02,020 Okay, so this is a review of what we already talked about. 101 00:07:02,020 --> 00:07:04,800 So I don't need to go in there. 102 00:07:04,800 --> 00:07:09,840 And I've mentioned how S, G joins are used to open up the shortest path 103 00:07:09,840 --> 00:07:13,860 tree. And you'll see that acronym S P T all the time when talking about 104 00:07:13,860 --> 00:07:16,280 PIM, shortest path tree. 105 00:07:16,280 --> 00:07:21,060 So what triggers an S, G join? 106 00:07:21,060 --> 00:07:26,260 Well, there's once again multiple things that could trigger it. 107 00:07:26,260 --> 00:07:30,980 If you happen to be the rendezvous point and you receive a multicast packet 108 00:07:30,980 --> 00:07:35,920 and a register, that's going to trigger you to send out an S, G join. 109 00:07:35,920 --> 00:07:38,460 Because as a rendezvous point, you're going to want to open up your shortest 110 00:07:38,460 --> 00:07:41,260 path. So that's one thing that could trigger it. 111 00:07:41,260 --> 00:07:42,800 What's another thing? 112 00:07:42,800 --> 00:07:49,120 Like we talked about, if you are a leaf router when you receive the multicast 113 00:07:49,120 --> 00:07:52,440 packet. Now this also raises an interesting point. 114 00:07:52,440 --> 00:07:59,460 So you might wonder, well, does the leaf router do that immediately? 115 00:07:59,460 --> 00:08:04,800 Only after he receives 10 packets or receives a certain bits per second. 116 00:08:04,800 --> 00:08:07,400 You know, when does the leaf router decide to do that? 117 00:08:07,400 --> 00:08:10,860 The actual RFC doesn't define that. 118 00:08:10,860 --> 00:08:15,820 The actual RFC for PIMS Farsmo just says the leaf router may, he doesn't 119 00:08:15,820 --> 00:08:17,160 even have to do it. 120 00:08:17,160 --> 00:08:22,100 The leaf router may switch over to the shortest path tree once a certain 121 00:08:22,100 --> 00:08:24,640 threshold is reached. 122 00:08:24,640 --> 00:08:25,780 That's all it says. 123 00:08:25,780 --> 00:08:28,400 Now how do Cisco routers actually do it? 124 00:08:28,400 --> 00:08:33,040 The threshold for Cisco routers is one packet, just one. 125 00:08:33,040 --> 00:08:36,920 So when the very first multicast packet reaches router two and router 126 00:08:36,920 --> 00:08:41,380 two very first learns what that source address is, that is his trigger 127 00:08:41,380 --> 00:08:44,480 to say, okay, do I have a shorter path? 128 00:08:44,480 --> 00:08:49,040 Let me join it. So that's the threshold on Cisco routers. 129 00:08:49,040 --> 00:08:51,980 Now you might say, do I have another option? 130 00:08:51,980 --> 00:08:53,120 Is there something else I can do? 131 00:08:53,120 --> 00:08:56,560 Let me show you what the command is to modify that behavior. 132 00:08:56,560 --> 00:08:59,160 You don't have a lot of options. 133 00:08:59,160 --> 00:09:02,300 Really, there's only two. 134 00:09:02,300 --> 00:09:05,160 Only two options you have available to you. 135 00:09:05,160 --> 00:09:08,420 So I'll go on the leaf router here. 136 00:09:08,420 --> 00:09:11,020 And the command is IP PIM. 137 00:09:11,020 --> 00:09:18,580 And then it is SPT threshold. 138 00:09:18,580 --> 00:09:20,920 So Shores path threshold. 139 00:09:20,920 --> 00:09:23,640 And you only got two options. 140 00:09:23,640 --> 00:09:30,060 Zero, which is the default, or infinity, which means never switch over 141 00:09:30,060 --> 00:09:31,500 to the shortest path. 142 00:09:31,500 --> 00:09:35,220 That's it. Nothing in the middle. 143 00:09:35,220 --> 00:09:41,960 So you can decide for yourself under what circumstances you might want 144 00:09:41,960 --> 00:09:44,040 to select infinity. 145 00:09:44,040 --> 00:09:52,440 But the default is switch over as soon as you receive the very first packet. 146 00:09:52,440 --> 00:09:55,600 What state do they create in the M route table? 147 00:09:55,600 --> 00:09:59,640 Okay, so if I go back to my router here, let's just go ahead and use this 148 00:09:59,640 --> 00:10:04,380 guy. Show IP M route. 149 00:10:04,380 --> 00:10:12,520 Okay, so so far we have our star, comma G entry. 150 00:10:12,520 --> 00:10:19,300 Now the star, comma G entry is built based on the shared tree. 151 00:10:19,300 --> 00:10:24,360 Where the only thing we know is the rendezvous point. 152 00:10:24,360 --> 00:10:27,620 And how to get to the rendezvous point. 153 00:10:27,620 --> 00:10:34,600 So if multicast packets start flowing down the shared tree, this is the 154 00:10:34,600 --> 00:10:40,080 construct that we're going to use to forward those multicast packets. 155 00:10:40,080 --> 00:10:44,580 Now you say, well, if the multicast actually starts flowing and we now 156 00:10:44,580 --> 00:10:48,720 know the source, are we also going to use this? 157 00:10:48,720 --> 00:10:50,640 Well, look at a couple things here. 158 00:10:50,640 --> 00:10:54,320 Number one, incoming interface. 159 00:10:54,320 --> 00:10:56,160 An RPF neighbor. 160 00:10:56,160 --> 00:11:01,140 This is all based on our knowledge of the rendezvous point. 161 00:11:01,140 --> 00:11:07,280 If I'm actually receiving the real multicast data, this wouldn't be relevant, 162 00:11:07,280 --> 00:11:11,600 right? Because the incoming interface and the RPF neighbor to get to the 163 00:11:11,600 --> 00:11:15,340 actual source itself might not be this. 164 00:11:15,340 --> 00:11:17,260 It might be something different. 165 00:11:17,260 --> 00:11:23,260 Also, I wouldn't need a star here anymore because now I would know what 166 00:11:23,260 --> 00:11:25,220 the source address is. 167 00:11:25,220 --> 00:11:31,040 So the moment a router actually receives the very first multicast packet, 168 00:11:31,040 --> 00:11:38,120 it creates a second entry in here, which is called an S, comma G entry. 169 00:11:38,120 --> 00:11:39,320 So let's go ahead and do that. 170 00:11:39,320 --> 00:11:40,880 Let's start at the stream. 171 00:11:40,880 --> 00:11:54,680 Basically do my ping again. 172 00:11:54,680 --> 00:12:00,120 Okay. And actually I have to go to router eight because during the break, 173 00:12:00,120 --> 00:12:05,400 I added something in here that might potentially screw up our demonstration. 174 00:12:05,400 --> 00:12:18,960 So I just want to get rid of that. 175 00:12:18,960 --> 00:12:21,380 Okay, so let's look over here at router two now. 176 00:12:21,380 --> 00:12:23,800 Show IP, M route. 177 00:12:23,800 --> 00:12:32,300 So here we see what's called an S, comma G, M route entry. 178 00:12:32,300 --> 00:12:38,200 S because hey, we actually know who the source is right there. 179 00:12:38,200 --> 00:12:43,500 So the incoming interface and the RPF neighbor is actually relevant now 180 00:12:43,500 --> 00:12:47,540 to the source, not to the rendezvous point. 181 00:12:47,540 --> 00:12:56,000 Now my particular topology, I actually made it so that on R2, he would 182 00:12:56,000 --> 00:13:00,540 prefer this serial link to get to R4 rather than these fast ethernet links. 183 00:13:00,540 --> 00:13:04,920 I just did that by manipulating EIGRP and using offset lists and stuff 184 00:13:04,920 --> 00:13:09,640 like that. But R2 says okay, to get to the four five network, this is 185 00:13:09,640 --> 00:13:11,260 the preferred path. 186 00:13:11,260 --> 00:13:15,660 And once again, I can just check that, show IP RPF, four dot five dot 187 00:13:15,660 --> 00:13:22,100 four dot five. And it says, I prefer to use serial zero one zero, and 188 00:13:22,100 --> 00:13:25,140 that's via EIGRP 100. 189 00:13:25,140 --> 00:13:28,700 So that's what we use as the incoming interface. 190 00:13:28,700 --> 00:13:34,180 And the RPF neighbor is, well, like it sounds, the next top neighbor going 191 00:13:34,180 --> 00:13:36,140 up that direction. 192 00:13:36,140 --> 00:13:45,320 Now when there's a lot of rules surrounding this that we have to go through. 193 00:13:45,320 --> 00:13:57,900 So number one, when an S, comma G is first formed, it basically just takes 194 00:13:57,900 --> 00:14:02,700 whatever is in the outgoing interface list of the star, comma G, and just 195 00:14:02,700 --> 00:14:05,140 copies it down here. 196 00:14:05,140 --> 00:14:06,800 So normally they're the same. 197 00:14:06,800 --> 00:14:10,600 There's one circumstance where that's not going to happen. 198 00:14:10,600 --> 00:14:16,620 There's a rule of PIM, and this actually exists for both the star, comma 199 00:14:16,620 --> 00:14:21,000 G and the S, comma G, that says you can never have your incoming interface 200 00:14:21,000 --> 00:14:24,060 in the outgoing interface list. 201 00:14:24,060 --> 00:14:28,160 In other words, your incoming interface can't be the same as your outgoing 202 00:14:28,160 --> 00:14:34,560 interface. So if you see in the outgoing interface list null, meaning 203 00:14:34,560 --> 00:14:38,540 nothing, that could be why. 204 00:14:38,540 --> 00:14:41,440 But in this case, we don't have to worry about that. 205 00:14:41,440 --> 00:14:44,980 So the incoming interface is serial zero one zero, and he just copied 206 00:14:44,980 --> 00:14:55,700 this down here. Okay, what does the J mean? 207 00:14:55,700 --> 00:15:02,200 The J flag means I have sent a join in this direction. 208 00:15:02,200 --> 00:15:06,120 So in this particular case, because this is the shortest path tree, that 209 00:15:06,120 --> 00:15:13,540 means I have sent an S, comma G join up the shortest path tree. 210 00:15:13,540 --> 00:15:20,240 Now the J flag by itself is not proof that we've actually received any 211 00:15:20,240 --> 00:15:23,860 multicast data from that direction. 212 00:15:23,860 --> 00:15:34,000 All it means is that we've tried to open up that direction. 213 00:15:34,000 --> 00:15:39,160 What we would normally want to see after the J flag, and I'm going to 214 00:15:39,160 --> 00:15:44,900 investigate this here, would be the T flag. 215 00:15:44,900 --> 00:15:49,940 Normally we'd see the T flag after the J flag, and the T flag actually 216 00:15:49,940 --> 00:15:57,100 means I've received actual multicast data from the shortest path tree. 217 00:15:57,100 --> 00:16:00,200 Now, why are we not seeing that in this particular case? 218 00:16:00,200 --> 00:16:02,180 Well, let's do a little bit of troubleshooting here. 219 00:16:02,180 --> 00:16:09,420 We know that in order to receive multicast traffic in this direction, 220 00:16:09,420 --> 00:16:14,640 we need to have PIM right here. 221 00:16:14,640 --> 00:16:18,460 Okay, so question number one, does router two have a PIM neighbor on serial 222 00:16:18,460 --> 00:16:22,680 zero one zero? If he has a PIM neighbor, then that's proof that we actually 223 00:16:22,680 --> 00:16:25,320 have enabled PIM on router four. 224 00:16:25,320 --> 00:16:30,420 So let's see, show IP PIM neighbor. 225 00:16:30,420 --> 00:16:32,360 And he does not. 226 00:16:32,360 --> 00:16:37,180 All right, so we've only got a neighbor on fast Ethan at zero one. 227 00:16:37,180 --> 00:16:41,520 We do not have it on the serial, so that's why we're not receiving traffic 228 00:16:41,520 --> 00:16:47,400 that way. So let's take a look at router four. 229 00:16:47,400 --> 00:16:56,380 Yes, and Peter just to validate, you really need to see the T flag in 230 00:16:56,380 --> 00:17:01,180 this entry here to verify that you've received multicast traffic down 231 00:17:01,180 --> 00:17:03,340 the shortest path tree. 232 00:17:03,340 --> 00:17:08,140 All the J flag means is I've attempted to join that tree, but we don't 233 00:17:08,140 --> 00:17:08,880 know if it's working yet. 234 00:17:08,880 --> 00:17:12,340 And this particular case is clearly not working because I don't even have 235 00:17:12,340 --> 00:17:15,600 a neighbor on that interface. 236 00:17:15,600 --> 00:17:21,360 So why not? Let's go to router four. 237 00:17:21,360 --> 00:17:25,160 Show run interface serial zero one zero. 238 00:17:25,160 --> 00:17:26,260 And there we go. 239 00:17:26,260 --> 00:17:28,120 I did not enable PIM on that interface. 240 00:17:28,120 --> 00:17:40,340 So that explains that. 241 00:17:40,340 --> 00:17:44,400 Okay, is the ping still going or is it done? 242 00:17:44,400 --> 00:17:45,960 Yep, still going. 243 00:17:45,960 --> 00:17:51,920 So now let's go to router two. 244 00:17:51,920 --> 00:17:54,080 And there we go. 245 00:17:54,080 --> 00:17:55,840 Now we've got the T flag. 246 00:17:55,840 --> 00:18:00,500 That's good. So that means we have actually started receiving multicast 247 00:18:00,500 --> 00:18:16,640 traffic from the shortest path tree. 248 00:18:16,640 --> 00:18:21,240 Okay. And just for in the event that you're watching this recording and 249 00:18:21,240 --> 00:18:26,200 you skipped over the previous section on PIM registers, in that particular 250 00:18:26,200 --> 00:18:30,560 section I did a snipper trace of a PIM S, let's just take a look at that 251 00:18:30,560 --> 00:18:42,780 real quick. So this is what an S, G join looks like. 252 00:18:42,780 --> 00:18:47,700 It still goes out as a multicast using the same PIM destination address 253 00:18:47,700 --> 00:18:52,000 of 2240013. So it's hop by hop. 254 00:18:52,000 --> 00:18:56,320 So the source address will change hop by hop by hop. 255 00:18:56,320 --> 00:19:00,500 And in the body of the PIM message, it's type three, once again, join 256 00:19:00,500 --> 00:19:05,540 prune. Upstream neighbor, who is this going to? 257 00:19:05,540 --> 00:19:09,820 Who's my RPF neighbor I'm sending this to? 258 00:19:09,820 --> 00:19:12,600 And it'll say, number of joins, how many groups am I joining? 259 00:19:12,600 --> 00:19:20,320 So what really differentiates a star, G join from an S, G join are the 260 00:19:20,320 --> 00:19:23,200 flags right here. 261 00:19:23,200 --> 00:19:30,480 We saw in the star, G join that in addition to the S bit, we had the W 262 00:19:30,480 --> 00:19:33,420 bit and the R bit. 263 00:19:33,420 --> 00:19:38,580 The W bit was the wild card bit, meaning I don't know what the source 264 00:19:38,580 --> 00:19:40,100 of the stream is. 265 00:19:40,100 --> 00:19:44,700 So this IP address, if the W was here, that would mean this IP address 266 00:19:44,700 --> 00:19:47,120 is the rendezvous point. 267 00:19:47,120 --> 00:19:51,840 But based on the fact that the W is missing, that means this is actually 268 00:19:51,840 --> 00:19:54,920 the IP address of the source of the stream itself. 269 00:19:54,920 --> 00:19:59,200 Also, the R bit is missing. 270 00:19:59,200 --> 00:20:02,140 The R bit is what's called the RP bit. 271 00:20:02,140 --> 00:20:05,600 If you actually look in the PIM specification, it's called the RP bit. 272 00:20:05,600 --> 00:20:10,420 And that would mean this message, whether it's a prune or a join, is going 273 00:20:10,420 --> 00:20:14,780 up the RP tree. It's going up the shared tree towards the rendezvous point. 274 00:20:14,780 --> 00:20:17,700 Once again, that's missing here, because this is not going up the shared 275 00:20:17,700 --> 00:20:22,140 tree. This is destined to go up the shortest path tree. 276 00:20:22,140 --> 00:20:27,280 So other than that, they look fundamentally the same, a star, G join and 277 00:20:27,280 --> 00:20:29,440 an S, G join. The body looks the same. 278 00:20:29,440 --> 00:20:31,660 You really have to look at the flags here to see. 279 00:20:31,660 --> 00:20:35,380 Is the W in the R bit here or are they missing? 280 00:20:35,380 --> 00:20:40,700 That's what differentiates the two. 281 00:20:40,700 --> 00:20:49,040 Now, I mentioned that one of the things that could cause S, G state in 282 00:20:49,040 --> 00:20:55,300 the router is if you're actually receiving the multicast traffic itself. 283 00:20:55,300 --> 00:20:58,660 There's another situation that could cause this. 284 00:20:58,660 --> 00:21:08,860 If you receive an S, G join from a downstream router, for example, let's 285 00:21:08,860 --> 00:21:11,900 not use this one. 286 00:21:11,900 --> 00:21:23,040 Let's say, for example, that we have this situation. 287 00:21:23,040 --> 00:21:34,280 This guy's the RP. 288 00:21:34,280 --> 00:21:40,040 We'll just call this guy router one, router two, and router three. 289 00:21:40,040 --> 00:21:58,400 We'll put our receiver right here, and we'll put our source right here. 290 00:21:58,400 --> 00:22:04,420 All right, so we know that initially once the multicast very first starts 291 00:22:04,420 --> 00:22:10,400 flowing, it's going to go in this direction to the rendezvous point, down 292 00:22:10,400 --> 00:22:13,020 the shared tree, and then to the receiver. 293 00:22:13,020 --> 00:22:17,660 So right now, router two has no state at all. 294 00:22:17,660 --> 00:22:19,620 He has no M route state for the stream. 295 00:22:19,620 --> 00:22:23,720 Nobody has ever asked him for it, either IGMP or PIM. 296 00:22:23,720 --> 00:22:26,540 So if he did show IPM route, we'd see nothing. 297 00:22:26,540 --> 00:22:29,620 Nothing related to the stream. 298 00:22:29,620 --> 00:22:36,360 But when router one is trying to join the shortest path, if we presume 299 00:22:36,360 --> 00:22:50,480 that this is the shortest path, he'll send a PIM S, G join upstream. 300 00:22:50,480 --> 00:22:55,040 And like we saw in the body of the message, he'll say neighbor router 301 00:22:55,040 --> 00:22:59,780 two, router two's IP address, and then he'll give the source and the destination, 302 00:22:59,780 --> 00:23:00,880 right? He'll give the source of the stream. 303 00:23:00,880 --> 00:23:04,460 Let's just say that this is xxx. 304 00:23:04,460 --> 00:23:13,640 He'll have in here source equals xxx, group equals, you know, whatever 305 00:23:13,640 --> 00:23:21,600 it is. So now even though router two initially had no M route state at 306 00:23:21,600 --> 00:23:29,820 all, once he gets this S, G join, that will actually create S, G state 307 00:23:29,820 --> 00:23:32,420 in his M route table. 308 00:23:32,420 --> 00:23:36,340 And then he'll be able to then create his own S, G join and send it up 309 00:23:36,340 --> 00:23:42,400 this way. One other key component, you might be tested on this on some