1 00:00:08,340 --> 00:00:11,320 Okay, so we've already talked a little bit about this concept of the shared 2 00:00:11,320 --> 00:00:16,200 tree, which is the path from the rendezvous point down to wherever the 3 00:00:16,200 --> 00:00:21,360 receivers are. So there's potentially more than one shared tree, right? 4 00:00:21,360 --> 00:00:25,680 If I've got 50 receivers spread throughout my network, I could potentially 5 00:00:25,680 --> 00:00:30,760 have 50 different shared trees, 50 different paths from that RP leading 6 00:00:30,760 --> 00:00:33,620 down to the various receivers where they live. 7 00:00:33,620 --> 00:00:38,100 Let's go into a little bit more detail now about how all of that is built. 8 00:00:38,100 --> 00:00:42,960 So first I'm going to show you some of the initial commands so we can 9 00:00:42,960 --> 00:00:46,040 get this built, and then we're going to go back into the theory and see 10 00:00:46,040 --> 00:00:47,220 how all this stuff works. 11 00:00:47,220 --> 00:00:52,240 So I mentioned multicast routing has to be globally enabled, so IP, multicast, 12 00:00:52,240 --> 00:00:58,880 dash routing. And then PIMS sparse mode must be enabled per interface, 13 00:00:58,880 --> 00:01:04,800 so that's IP PIMS sparse dash mode, and then only one other thing is necessary. 14 00:01:04,800 --> 00:01:06,740 How do you find the rendezvous point? 15 00:01:06,740 --> 00:01:08,420 So we're just going to do it nice and simple. 16 00:01:08,420 --> 00:01:12,660 We're going to statically configure a rendezvous point with the global 17 00:01:12,660 --> 00:01:17,340 command IP PIM RP dash address and then the address. 18 00:01:17,340 --> 00:01:22,420 So what this is doing right here is this is saying any multicast anywhere, 19 00:01:22,420 --> 00:01:28,420 whether it's 224, 239, 228, whatever, they're all going to this one guy, 20 00:01:28,420 --> 00:01:31,720 this one rendezvous point, 777. 21 00:01:31,720 --> 00:01:39,260 Okay, so let's go ahead and start creating this, and then we'll start 22 00:01:39,260 --> 00:01:41,420 talking about it as we go along. 23 00:01:41,420 --> 00:01:49,140 So going back to my diagram right here, as you can see, router three at 24 00:01:49,140 --> 00:01:52,580 the bottom is going to be my RP. 25 00:01:52,580 --> 00:01:57,840 And so I'll just have his address on his spec. 26 00:01:57,840 --> 00:02:01,020 You know, normally you'd probably select a loop back on that router, but 27 00:02:01,020 --> 00:02:03,820 because that's not part of my diagram, I'm just going to choose his address 28 00:02:03,820 --> 00:02:11,620 on fast ethernet 00, so 343, that will be the address of the rendezvous 29 00:02:11,620 --> 00:02:16,000 point. So let me just real quickly here go into these four routers, routers 30 00:02:16,000 --> 00:02:23,580 two, eight, four, and three, and quickly enable them for PIM. 31 00:02:23,580 --> 00:02:34,740 So starting with router two, IP multicast dash routing, interface fast 32 00:02:34,740 --> 00:02:38,220 ethernet zero slash one, that's the interface is going upstream to the 33 00:02:38,220 --> 00:02:48,140 RP, IP PIM, sparse dash mode, and then give him knowledge of who the RP 34 00:02:48,140 --> 00:02:54,040 is, and I'll talk about this whole DR thing coming up, IP PIM, RP dash 35 00:02:54,040 --> 00:02:56,860 address, 3.4.3.3. 36 00:02:56,860 --> 00:03:01,020 Now one other thing, let's take a look back here at our diagram. 37 00:03:01,020 --> 00:03:08,520 What I've just done is I have enabled multicast routing on R2, and I've 38 00:03:08,520 --> 00:03:11,680 enabled PIM on this interface. 39 00:03:11,680 --> 00:03:14,140 I'm probably also going to want to do it on the serial interface, so let's 40 00:03:14,140 --> 00:03:16,900 go ahead and do that as well on serial zero slash one. 41 00:03:16,900 --> 00:03:21,600 But don't forget, you're also going to need to enable it in this particular 42 00:03:21,600 --> 00:03:25,840 case on the interface leading to my receiver. 43 00:03:25,840 --> 00:03:27,760 Now you might say, why do I need that? 44 00:03:27,760 --> 00:03:30,380 I mean, there's no PIM routers in that direction. 45 00:03:30,380 --> 00:03:33,140 He's not going to form any neighbor relationships or anything. 46 00:03:33,140 --> 00:03:34,880 Here's the reason why we need this. 47 00:03:34,880 --> 00:03:40,920 Number one, if you're using PIM sparse mode as your multicast routing 48 00:03:40,920 --> 00:03:47,100 protocol, a router will not be allowed to receive any incoming multicast 49 00:03:47,100 --> 00:03:54,780 or transmit any outgoing multicast on an interface that's not running 50 00:03:54,780 --> 00:04:00,600 PIM. So if I didn't have PIM enabled on fast ethernet zero zero, router 51 00:04:00,600 --> 00:04:04,600 one, my receiver here could be requesting multicast all day long. 52 00:04:04,600 --> 00:04:08,260 It's never going to be forwarded out fast ethernet zero zero. 53 00:04:08,260 --> 00:04:10,420 Here's the other reason. 54 00:04:10,420 --> 00:04:16,400 We've talked about how receivers use IGMP to indicate their interest in 55 00:04:16,400 --> 00:04:21,940 a multicast group to the directly connected router. 56 00:04:21,940 --> 00:04:24,180 Well routers are not running IGMP by default. 57 00:04:24,180 --> 00:04:26,020 They don't listen to that. 58 00:04:26,020 --> 00:04:32,240 But we enable PIM on this interface that also enables IGMP as a byproduct. 59 00:04:32,240 --> 00:04:35,420 So in order for this router to realize that, okay, I need to send queries 60 00:04:35,420 --> 00:04:39,620 every couple minutes and I need to listen to IGMP membership reports, 61 00:04:39,620 --> 00:04:42,840 I need to enable PIM on this interface. 62 00:04:42,840 --> 00:04:51,400 So let's go ahead and do that. 63 00:04:51,400 --> 00:04:58,520 Interface fast ethernet zero zero puts PIM sparse mode on here and interface 64 00:04:58,520 --> 00:05:01,020 serial zero one zero. 65 00:05:01,020 --> 00:05:04,540 Also put PIM on there. 66 00:05:04,540 --> 00:05:16,680 Okay, let's go ahead now go into R3. 67 00:05:16,680 --> 00:05:23,480 Okay, and the rendezvous point himself also needs to know that he is the 68 00:05:23,480 --> 00:05:24,420 rendezvous point. 69 00:05:24,420 --> 00:05:28,040 So I give him the exact same command I give to the other guys. 70 00:05:28,040 --> 00:05:31,300 I say you are the RP and say oh that's my IP address. 71 00:05:31,300 --> 00:05:33,900 Okay, I guess that's my job. 72 00:05:33,900 --> 00:05:48,360 And my RP, he's going to have it on zero zero and zero one. 73 00:05:48,360 --> 00:05:50,520 Okay, that's all I need on that guy. 74 00:05:50,520 --> 00:05:59,620 So I've done R2, R3, let's go on to R8. 75 00:05:59,620 --> 00:06:01,480 Now look at a couple things. 76 00:06:01,480 --> 00:06:06,120 Before I do anything here on R8, show IPM route. 77 00:06:06,120 --> 00:06:09,080 That's the way to check the multicast routing table. 78 00:06:09,080 --> 00:06:13,860 Well, I have not enabled multicast routing yet on this guy. 79 00:06:13,860 --> 00:06:15,600 So there's nothing there. 80 00:06:15,600 --> 00:06:18,100 Absolutely, you know, it's actually kind of interesting that even shows 81 00:06:18,100 --> 00:06:20,800 us the various flags and stuff that will be used. 82 00:06:20,800 --> 00:06:23,920 But right now the multicast routing table does not exist. 83 00:06:23,920 --> 00:06:30,740 If I do show IPPIM interface, I get nothing because I have not enabled 84 00:06:30,740 --> 00:06:35,640 PIM yet. Now, IP multicast dash routing. 85 00:06:35,640 --> 00:06:42,060 Now, if that's all I do, no PIM yet, show IPM route. 86 00:06:42,060 --> 00:06:44,160 Still, doesn't do much. 87 00:06:44,160 --> 00:06:47,640 But now I've enabled this router to populate this table. 88 00:06:47,640 --> 00:06:52,160 He had no way of populating it before without that command. 89 00:06:52,160 --> 00:06:56,180 All right, now let's go ahead and enable it on fast ethernet zero zero 90 00:06:56,180 --> 00:07:14,400 and then my sub interfaces. 91 00:07:14,400 --> 00:07:28,500 And also give him knowledge of who the rendezvous point is. 92 00:07:28,500 --> 00:07:32,140 OK, so now at this point, well, let me just go ahead and finish it off 93 00:07:32,140 --> 00:07:51,560 here. We've got one more router, router four. 94 00:07:51,560 --> 00:07:54,880 So I should not have done that on zero zero because zero zero is a sub 95 00:07:54,880 --> 00:08:22,020 interface. Thirty four and eighty four. 96 00:08:22,020 --> 00:08:30,340 And lastly, let's give him knowledge of IPPIM, RP dash address. 97 00:08:30,340 --> 00:08:42,200 OK, so in this particular router, let's go to somebody in the middle. 98 00:08:42,200 --> 00:08:46,080 Let's go to router eight. 99 00:08:46,080 --> 00:08:51,240 So right now, this guy is running PIM on his interface. 100 00:08:51,240 --> 00:08:55,660 And I can verify that with show IPPIM interface. 101 00:08:55,660 --> 00:09:00,800 And it shows me every interface where I've enabled PIM. 102 00:09:00,800 --> 00:09:03,360 It shows me the version. 103 00:09:03,360 --> 00:09:06,180 S in this case means it's running in sparse mode. 104 00:09:06,180 --> 00:09:09,780 It shows me how many neighbors I've learned. 105 00:09:09,780 --> 00:09:14,140 It sends I'm sending out PIM hellows every 30 seconds. 106 00:09:14,140 --> 00:09:16,580 We'll talk about designated router in a second. 107 00:09:16,580 --> 00:09:21,440 And here are the IP addresses of the PIM designated router, which we'll 108 00:09:21,440 --> 00:09:31,160 get to. If I do show IPM route, now before I hit enter here, this router, 109 00:09:31,160 --> 00:09:37,000 because he's in the middle, he's never going to receive any I GMP because 110 00:09:37,000 --> 00:09:40,580 I GMP only happens between the receiver and his default gateway. 111 00:09:40,580 --> 00:09:43,560 It goes no further than that. 112 00:09:43,560 --> 00:09:46,200 The receiver hasn't asked for anything yet. 113 00:09:46,200 --> 00:09:48,820 He hasn't joined anything. 114 00:09:48,820 --> 00:09:55,140 Let's just make sure that's true before I make a liar out of myself here. 115 00:09:55,140 --> 00:10:01,240 Right, so he has not asked for anything. 116 00:10:01,240 --> 00:10:07,160 So, when I go into, so there have been no I GMP membership reports, therefore 117 00:10:07,160 --> 00:10:10,460 we would expect that there are no PIM joins. 118 00:10:10,460 --> 00:10:13,340 Nobody has asked to join anything yet. 119 00:10:13,340 --> 00:10:15,920 And my source, he hasn't sent anything yet. 120 00:10:15,920 --> 00:10:16,900 Everything's idle. 121 00:10:16,900 --> 00:10:18,680 Nothing has started yet. 122 00:10:18,680 --> 00:10:22,980 So one would expect that my multicast routing table should be blank. 123 00:10:22,980 --> 00:10:27,800 Should be empty, right? 124 00:10:27,800 --> 00:10:31,560 Show IPM route. What is this? 125 00:10:31,560 --> 00:10:34,020 Where did that come from? 126 00:10:34,020 --> 00:10:39,340 Well, later on, as we get to it, when we talk about auto RP, this particular 127 00:10:39,340 --> 00:10:42,640 multicast address is used by auto RP. 128 00:10:42,640 --> 00:10:46,280 This is actually a reserved multicast address used by Cisco's proprietary 129 00:10:46,280 --> 00:10:52,660 auto RP. And Cisco routers, by default, join that group. 130 00:10:52,660 --> 00:10:56,820 So this router is basically saying I'm ready to dynamically learn of who 131 00:10:56,820 --> 00:11:01,520 the RP is, if auto RP is ever invoked. 132 00:11:01,520 --> 00:11:03,900 So that's what that is for when you see that. 133 00:11:03,900 --> 00:11:09,700 Okay, so everything is set up and ready to go now. 134 00:11:09,700 --> 00:11:15,240 Let's keep going with our theory. 135 00:11:15,240 --> 00:11:20,200 So I mentioned that PIM will not allow forwarding or receipt of multicast 136 00:11:20,200 --> 00:11:24,900 traffic on interfaces unless one of two things is true. 137 00:11:24,900 --> 00:11:29,580 Another PIM neighbor has been discovered on that interface or a directly 138 00:11:29,580 --> 00:11:37,660 connected receiver slash source resides on that interface. 139 00:11:37,660 --> 00:11:42,920 So I'm going back to my diagram here as an example. 140 00:11:42,920 --> 00:12:00,620 Let's say that I had enabled PIM on all these interfaces. 141 00:12:00,620 --> 00:12:02,060 Okay, let's say that. 142 00:12:02,060 --> 00:12:06,480 Now notice the interfaces that I haven't circled and I did that on purpose. 143 00:12:06,480 --> 00:12:13,440 I did not enable PIM here on this sub interface or right here. 144 00:12:13,440 --> 00:12:19,220 In this particular case, multicast traffic is never going to flow. 145 00:12:19,220 --> 00:12:24,260 If my receiver sends an IGMP membership report, we've got PIM enabled 146 00:12:24,260 --> 00:12:27,200 on every interface to get up to the RP. 147 00:12:27,200 --> 00:12:29,340 So we actually will form a shared tree. 148 00:12:29,340 --> 00:12:33,800 This branch right here will be ready and waiting to transmit multicast 149 00:12:33,800 --> 00:12:34,880 if it ever happens. 150 00:12:34,880 --> 00:12:36,820 But here's the problem. 151 00:12:36,820 --> 00:12:48,340 If the source starts sending, well, R4 is never going to receive a request 152 00:12:48,340 --> 00:12:50,880 for that traffic. 153 00:12:50,880 --> 00:12:56,140 In order for R4 to natively forward the multicast, just forward on interface, 154 00:12:56,140 --> 00:12:58,160 somebody has to ask him for it. 155 00:12:58,160 --> 00:13:01,140 He has to receive a PIM join. 156 00:13:01,140 --> 00:13:05,160 Well he's not going to receive a PIM join this way because this interface 157 00:13:05,160 --> 00:13:07,100 doesn't have PIM on it. 158 00:13:07,100 --> 00:13:08,340 And he's not going to receive it. 159 00:13:08,340 --> 00:13:12,960 If a PIM join does come in here or here, he's going to drop it because 160 00:13:12,960 --> 00:13:14,700 he doesn't have PIM enable on these interfaces. 161 00:13:14,700 --> 00:13:16,520 He can't receive PIM. 162 00:13:16,520 --> 00:13:21,260 So that's a demonstration of why PIM has to be enabled on both sides of 163 00:13:21,260 --> 00:13:25,540 a link. Also on the interface connected to the receiver and the interface 164 00:13:25,540 --> 00:13:30,220 connected to the source in order to have everything flowing. 165 00:13:30,220 --> 00:13:32,740 So this can be one source of multicast troubleshooting. 166 00:13:32,740 --> 00:13:36,180 If multicast is not flowing somewhere in your network, it could be as 167 00:13:36,180 --> 00:13:41,220 simple as the fact that you forgot to enable PIM on some link somewhere. 168 00:13:41,220 --> 00:13:48,620 Some interface, some sub-interface doesn't have PIM enabled on it. 169 00:13:48,620 --> 00:13:52,300 So PIM Hello packets are used to discover the PIM neighbors. 170 00:13:52,300 --> 00:13:54,460 And if you're watching this recording, I do apologize. 171 00:13:54,460 --> 00:13:58,360 In the previous recording, I misstated the multicast address of those 172 00:13:58,360 --> 00:14:04,580 PIM Hello's. The correct address is 2240013. 173 00:14:04,580 --> 00:14:09,880 So 2240013 is the address that PIM Hello's are sent to. 174 00:14:09,880 --> 00:14:12,680 So let's actually do a snipper trace of those Hello's right now because 175 00:14:12,680 --> 00:14:14,120 we've got PIM enabled. 176 00:14:14,120 --> 00:14:16,160 I'll just pick one right here. 177 00:14:16,160 --> 00:14:20,060 So we know that the actual physical topology in this case is right here. 178 00:14:20,060 --> 00:14:22,940 PIM is enabled on R2, R8, R4. 179 00:14:22,940 --> 00:14:24,520 So let's just do a snipper trace. 180 00:14:24,520 --> 00:14:30,480 I'll capture the Hello's that are coming in on fast ethane at 0 slash 181 00:14:30,480 --> 00:14:32,420 4 on this switch. 182 00:14:32,420 --> 00:14:42,740 So I'm going to use the span feature on the switch to accomplish that. 183 00:14:42,740 --> 00:14:46,600 I'm not really going to go into the details of how to configure span or 184 00:14:46,600 --> 00:14:52,300 what span does because that's not really relevant to this presentation. 185 00:14:52,300 --> 00:14:56,900 Okay, so at this point, anything that's coming in on, let's see here, 186 00:14:56,900 --> 00:14:58,820 I did 0 slash 7. 187 00:14:58,820 --> 00:15:00,580 So that would be right here. 188 00:15:00,580 --> 00:15:06,280 Okay, R4. So when R4 is sending PIM Hello's, we should capture them and 189 00:15:06,280 --> 00:15:09,380 my wire shark should pick them up. 190 00:15:09,380 --> 00:15:17,980 They go out every 30 seconds so we shouldn't have to wait too long. 191 00:15:17,980 --> 00:15:34,560 There we go. So I'm going to use my laptop or a bug with wire shark. 192 00:15:34,560 --> 00:15:39,060 But a lot of times wire shark won't let me press the buttons up here to 193 00:15:39,060 --> 00:15:44,020 stop something. So let's just expand this. 194 00:15:44,020 --> 00:15:49,440 So here is our PIM Hello. 195 00:15:49,440 --> 00:15:56,640 So notice the destination 2240013 and when we map that down to our destination 196 00:15:56,640 --> 00:16:02,600 MAC address 01005E and D is 13. 197 00:16:02,600 --> 00:16:06,100 It's carried in IP. 198 00:16:06,100 --> 00:16:12,400 Has a time to live of 1 because it's only good on the local link. 199 00:16:12,400 --> 00:16:14,580 And it's got a pretty high DSCP. 200 00:16:14,580 --> 00:16:18,900 It's got an IP precedence of 6. 201 00:16:18,900 --> 00:16:21,140 And you can only get higher than that by going to 7. 202 00:16:21,140 --> 00:16:24,240 So as far as priorities concerns, a pretty high priority packet. 203 00:16:24,240 --> 00:16:27,640 Protocol 103 for PIM. 204 00:16:27,640 --> 00:16:35,200 And here we see the source is, in this case, router 8. 205 00:16:35,200 --> 00:16:37,740 It looks like. Router 8. 206 00:16:37,740 --> 00:16:39,320 And destinations PIM. 207 00:16:39,320 --> 00:16:43,720 And then here is actually the PIM body. 208 00:16:43,720 --> 00:16:50,320 PIM version 2, type code is 0, which means it's Hello. 209 00:16:50,320 --> 00:16:52,620 And the option that says the hold time. 210 00:16:52,620 --> 00:16:59,020 So 105 seconds, which is roughly three times the priority, or three times 211 00:16:59,020 --> 00:17:03,780 the interval of the hello time, which is every 30 seconds. 212 00:17:03,780 --> 00:17:07,920 And designated router priority and state refresh capable. 213 00:17:07,920 --> 00:17:10,680 Talk a little bit more about those in just a minute. 214 00:17:10,680 --> 00:17:20,700 But you can see the PIM Hello is pretty simple. 215 00:17:20,700 --> 00:17:23,980 And here you can see they're going out fairly frequently. 216 00:17:23,980 --> 00:17:28,900 So here's the one from router 8. 217 00:17:28,900 --> 00:17:36,400 And it went out at 42.35 seconds. 218 00:17:36,400 --> 00:17:40,040 So if we go roughly 30 seconds more than that, that should be five minutes 219 00:17:40,040 --> 00:17:48,740 and around 15 seconds or so. 220 00:17:48,740 --> 00:17:50,800 And here's the next hello. 221 00:17:50,800 --> 00:17:53,960 About 30 seconds later, five minutes and 12 seconds. 222 00:17:53,960 --> 00:17:57,940 And we'll talk about these other things, join prunes and stuff coming 223 00:17:57,940 --> 00:18:12,680 up. OK, so PIM joins. 224 00:18:12,680 --> 00:18:18,200 As I mentioned, PIM does not add a branch to the tree until someone wishes 225 00:18:18,200 --> 00:18:25,080 to join it. So PIM actually has something called a join packet to do this. 226 00:18:25,080 --> 00:18:28,180 And you'll see in a lot of documentations, they'll reference like two 227 00:18:28,180 --> 00:18:29,700 different kinds of joins. 228 00:18:29,700 --> 00:18:35,900 Something called a star comma g join and an s comma g join. 229 00:18:35,900 --> 00:18:39,120 We're going to get into the gory details of each of these. 230 00:18:39,120 --> 00:18:42,560 For now, I'll just say both of these are the exact same packet. 231 00:18:42,560 --> 00:18:45,980 It's not like there's two different kinds of PIM packets. 232 00:18:45,980 --> 00:18:48,540 They're both carried in the exact same packet. 233 00:18:48,540 --> 00:18:51,780 The only difference is one little field is different between these two. 234 00:18:51,780 --> 00:18:55,740 But this is the fundamental data structure that's used by PIM to send 235 00:18:55,740 --> 00:19:00,040 a message upstream saying, hey neighbor, look at me, I need something. 236 00:19:00,040 --> 00:19:01,480 I need a particular group. 237 00:19:01,480 --> 00:19:03,400 Add me to your tree. 238 00:19:03,400 --> 00:19:13,440 That's the PIM join. 239 00:19:13,440 --> 00:19:17,560 So multicast forwarding is determined by entries in the M route table, 240 00:19:17,560 --> 00:19:19,200 the multicast routing table. 241 00:19:19,200 --> 00:19:23,100 So we call those M routes. 242 00:19:23,100 --> 00:19:26,920 So what would cause these entries to be populated in the table? 243 00:19:26,920 --> 00:19:29,460 Well, one of three things. 244 00:19:29,460 --> 00:19:32,960 Either a router has received a PIM join. 245 00:19:32,960 --> 00:19:38,100 It has received multicast traffic. 246 00:19:38,100 --> 00:19:41,360 Actually, there's four things. 247 00:19:41,360 --> 00:19:45,540 It has received an IGMP membership report. 248 00:19:45,540 --> 00:19:50,000 So let me actually put that in here as well. 249 00:19:50,000 --> 00:20:02,360 There we go. So a router has received PIM joins or an IGMP membership 250 00:20:02,360 --> 00:20:06,640 report. It's received the actual multicast traffic itself. 251 00:20:06,640 --> 00:20:09,980 Or sometimes it can be dynamically or automatically created. 252 00:20:09,980 --> 00:20:16,560 We saw that the 2240140 was in there for auto RP. 253 00:20:16,560 --> 00:20:18,100 And we didn't have to do anything for that. 254 00:20:18,100 --> 00:20:21,300 We didn't actually receive any auto RP traffic that was just dynamically 255 00:20:21,300 --> 00:20:27,080 put in there. So let's just look at the M route table for a moment. 256 00:20:27,080 --> 00:20:32,280 And I'm going to point out some high level bullet points of it. 257 00:20:32,280 --> 00:20:36,420 And then we'll talk a little bit more about some of the details. 258 00:20:36,420 --> 00:20:42,880 So for example, if I go into here, show IPM route is how we see what's 259 00:20:42,880 --> 00:20:47,200 in there. So these are all your flags. 260 00:20:47,200 --> 00:20:52,180 And these flags will show up in various portions of your M route. 261 00:20:52,180 --> 00:20:54,540 So this is, for example, considered an M route. 262 00:20:54,540 --> 00:20:56,380 These four lines right here. 263 00:20:56,380 --> 00:20:59,300 This is indicating a multicast route. 264 00:20:59,300 --> 00:21:02,440 And these flags, we're going to talk about many of these. 265 00:21:02,440 --> 00:21:06,320 Now, a lot of these have nothing to do with PIMS sparse mode. 266 00:21:06,320 --> 00:21:09,460 So I will point out the most common ones that you'll see in PIMS sparse 267 00:21:09,460 --> 00:21:15,220 mode. But some of them like the Z flag and the Y flag that has nothing 268 00:21:15,220 --> 00:21:16,480 to do with PIMS sparse mode. 269 00:21:16,480 --> 00:21:18,760 So we're not going to talk about that. 270 00:21:18,760 --> 00:21:23,420 So you'll see here, so you can see this is your group. 271 00:21:23,420 --> 00:21:24,940 This is the multicast group. 272 00:21:24,940 --> 00:21:27,360 And we'll talk here in just a second what the star means. 273 00:21:27,360 --> 00:21:33,560 Some timers about how long the group has been active, when it will expire. 274 00:21:33,560 --> 00:21:37,340 Information about who the rendezvous point is. 275 00:21:37,340 --> 00:21:42,100 Incoming interface, you know, where do I expect to receive my multicast 276 00:21:42,100 --> 00:21:46,200 traffic? When it comes in to me, which interface will receive it? 277 00:21:46,200 --> 00:21:49,280 And which interfaces will I forward it out of? 278 00:21:49,280 --> 00:21:53,720 Sometimes the outgoing interface list will say no, meaning I have nobody. 279 00:21:53,720 --> 00:21:55,500 Nobody's ever asked me for this traffic. 280 00:21:55,500 --> 00:21:58,360 I've got no place to send it. 281 00:21:58,360 --> 00:22:01,560 So we'll look in more detail at the various timers and things in here 282 00:22:01,560 --> 00:22:11,260 as we go along. So how do we create the shared tree? 283 00:22:11,260 --> 00:22:13,960 Well, number one, you got to know who the rendezvous point is. 284 00:22:13,960 --> 00:22:15,620 You got to know how to get to him. 285 00:22:15,620 --> 00:22:19,640 So if you don't have a route to the rendezvous point, it's not going to 286 00:22:19,640 --> 00:22:20,920 do you much good. 287 00:22:20,920 --> 00:22:26,140 And you have to have at least one request from a multicast receiver. 288 00:22:26,140 --> 00:22:31,640 The multicast receiver, the laptop, the PC, once it sends an IGMP membership 289 00:22:31,640 --> 00:22:35,300 report, that kicks off this whole process. 290 00:22:35,300 --> 00:22:37,560 That's what builds the shared tree. 291 00:22:37,560 --> 00:22:48,500 Okay, so let's go ahead and build a shared tree. 292 00:22:48,500 --> 00:22:51,520 So what we're going to do in this case is I'm going to have my receiver, 293 00:22:51,520 --> 00:22:55,960 which is really a router, but I'm going to have him send an IGMP membership 294 00:22:55,960 --> 00:22:59,040 report for a particular group. 295 00:22:59,040 --> 00:23:02,580 Now let's talk about the process that we're going to see. 296 00:23:02,580 --> 00:23:07,080 And then we'll actually look at this in the lab. 297 00:23:07,080 --> 00:23:16,300 So when R2 receives the membership report, he's suddenly going to be aware 298 00:23:16,300 --> 00:23:19,860 of a source. So let's go ahead and actually do this on the whiteboard 299 00:23:19,860 --> 00:23:26,680 here. So when this guy sends a membership report, let's just come up with 300 00:23:26,680 --> 00:23:33,840 some group. 239.999. 301 00:23:33,840 --> 00:23:40,900 Well, with PIM enabled on fast ethernet 00, router 2 will now realize, 302 00:23:40,900 --> 00:23:44,560 okay, I have a receiver on this interface for this group. 303 00:23:44,560 --> 00:23:52,500 Now notice when this membership report comes in, so there's not going 304 00:23:52,500 --> 00:23:58,700 to be any mention of 4.5.4.5 because nobody knows that he exists at this 305 00:23:58,700 --> 00:24:05,300 point. So when that report comes in, router 2 is now going to create some 306 00:24:05,300 --> 00:24:10,360 state in his M route table, his multicast routing table, and we're going 307 00:24:10,360 --> 00:24:14,460 to call this star, comma, g state. 308 00:24:14,460 --> 00:24:16,000 Why do we call it that? 309 00:24:16,000 --> 00:24:21,540 Well, it's going to be star, comma, g, meaning the star is what's the 310 00:24:21,540 --> 00:24:23,460 IP address of the source? 311 00:24:23,460 --> 00:24:26,880 Well, we don't know what the IP address of the source is. 312 00:24:26,880 --> 00:24:31,520 So we just use a star as a placeholder, which means any source, we don't 313 00:24:31,520 --> 00:24:33,120 care what the source is. 314 00:24:33,120 --> 00:24:37,160 And then g, well, in this particular case, it'll be 239.999. 315 00:24:37,160 --> 00:24:39,700 That is my group. 316 00:24:39,700 --> 00:24:45,500 So you'll see here R2 will now have an M route entry saying star, comma, 317 00:24:45,500 --> 00:24:49,880 239, 999. We call that a star, comma, g entry. 318 00:24:49,880 --> 00:24:54,800 And fasteethanet00 will be placed in the outgoing interface list. 319 00:24:54,800 --> 00:25:00,000 In other words, if I ever receive multicast for this group, I'll send 320 00:25:00,000 --> 00:25:04,380 it outgoing on interface fasteethanet00. 321 00:25:04,380 --> 00:25:11,440 Okay, so once router 2 gets that, he's now going to say, okay, I need 322 00:25:11,440 --> 00:25:16,460 to let the PEM rendezvous point know that I'm down here. 323 00:25:16,460 --> 00:25:21,380 And if he ever gets the multicast at 239.999, he needs to forward it to 324 00:25:21,380 --> 00:25:26,040 me. Now, in this particular case, we've already identified the rendezvous 325 00:25:26,040 --> 00:25:28,380 point as being router 3. 326 00:25:28,380 --> 00:25:34,260 He is the PEM RP. 327 00:25:34,260 --> 00:25:36,800 And all these routers know about that, because I statically configured 328 00:25:36,800 --> 00:25:44,400 them for that. So router 2, in his star, comma, g entry, you'll see that 329 00:25:44,400 --> 00:25:48,260 he'll say that. He'll say, okay, I know that the rendezvous point is 3 330 00:25:48,260 --> 00:25:53,640 .4.3.3. And now he's going to go into his unicast routing table. 331 00:25:53,640 --> 00:25:56,880 He's going to say, how do I get there? 332 00:25:56,880 --> 00:26:08,120 Well, if I go into router 2, there's, if I want to verify that this router 333 00:26:08,120 --> 00:26:12,640 actually can reverse path to the RP, that he knows how to get back to 334 00:26:12,640 --> 00:26:14,200 the RP, there's two ways I could do it. 335 00:26:14,200 --> 00:26:16,940 I could certainly just look at my routing table. 336 00:26:16,940 --> 00:26:17,700 I could do that. 337 00:26:17,700 --> 00:26:25,080 Show IP route. And we can see right here, there is a route to the 343 338 00:26:25,080 --> 00:26:28,360 network, learned via EIGRP. 339 00:26:28,360 --> 00:26:31,860 And so he's going to go out fast ethernet 0 slash 1. 340 00:26:31,860 --> 00:26:37,440 Or if you want to do it the way PEM would do it, you can do show IP RPF 341 00:26:37,440 --> 00:26:43,140 and then type in that IP address. 342 00:26:43,140 --> 00:26:46,340 He says, okay, I know about this. 343 00:26:46,340 --> 00:26:49,820 My interface to get there is fast ethernet 0 1. 344 00:26:49,820 --> 00:26:53,580 My next top neighbor, in other words, the neighbor who told me about this 345 00:26:53,580 --> 00:27:01,060 route is 8288. Here's the actual route I found on my routing table. 346 00:27:01,060 --> 00:27:08,240 And I learned it via EIGRP process 100, EIGRP Autonomous System 100. 347 00:27:08,240 --> 00:27:14,540 So now that he knows that, I go back to my whiteboard here, you'll see 348 00:27:14,540 --> 00:27:20,780 in my star, G entry, he'll place something called an incoming interface. 349 00:27:20,780 --> 00:27:22,160 Incoming interface. 350 00:27:22,160 --> 00:27:26,760 And he'll say, once the RP starts sending me multicast data, because it 351 00:27:26,760 --> 00:27:31,900 shouldn't initially start going down the shared tree from the RP, it should 352 00:27:31,900 --> 00:27:35,040 start coming from fast ethernet 0 slash 1. 353 00:27:35,040 --> 00:27:39,560 Because that's the interface I use to get to the rendezvous point. 354 00:27:39,560 --> 00:27:48,320 And then he'll also say, my neighbor is 8.2 dot 8 dot 8. 355 00:27:48,320 --> 00:27:53,000 Now he's got everything he needs. 356 00:27:53,000 --> 00:27:59,480 So now router 2 will create a PEM join. 357 00:27:59,480 --> 00:28:03,560 And we call this a PEM star, join. 358 00:28:03,560 --> 00:28:08,560 Because just like the IGMP membership report gave no indication of what 359 00:28:08,560 --> 00:28:13,120 the source address is of this multicast stream, this PEM join also gives 360 00:28:13,120 --> 00:28:17,600 no indication of the multicast stream. 361 00:28:17,600 --> 00:28:20,320 And we'll capture that in the snippet trace so you can see it. 362 00:28:20,320 --> 00:28:24,040 Star, 239 dot 999. 363 00:28:24,040 --> 00:28:31,640 And in that star, G join, it'll actually have the IP address of the rendezvous 364 00:28:31,640 --> 00:28:39,660 point. And in that way, router 8 will say, okay, I know where this is 365 00:28:39,660 --> 00:28:41,120 going, this is going to the RP. 366 00:28:41,120 --> 00:28:46,240 So guess what? When router 8 gets that, it's going to create star, G state 367 00:28:46,240 --> 00:28:50,580 in him. Because remember star, G state, this M route state is created 368 00:28:50,580 --> 00:28:57,000 based on either an actual receiver asking for the route, or a downstream 369 00:28:57,000 --> 00:28:58,800 router asking for the route. 370 00:28:58,800 --> 00:29:03,360 If a downstream router sends you a star, G join, it creates the exact 371 00:29:03,360 --> 00:29:06,080 same state as if you actually had a receiver. 372 00:29:06,080 --> 00:29:09,420 Not quite the same, I need some flags in here that are different, but 373 00:29:09,420 --> 00:29:11,200 still creates the state. 374 00:29:11,200 --> 00:29:14,660 So router 8, he'll create a star, G entry. 375 00:29:14,660 --> 00:29:21,340 He knows who the RP is. 376 00:29:21,340 --> 00:29:24,980 He'll do a reverse path lookup, and I'm pretty much assuming that his 377 00:29:24,980 --> 00:29:28,060 reverse path will be 00.83. 378 00:29:28,060 --> 00:29:32,840 Just looking at this diagram, I'm pretty sure that's his fastest path. 379 00:29:32,840 --> 00:29:36,860 And then his next top neighbor will actually be 3.4.3.3. 380 00:29:36,860 --> 00:29:45,840 And once he gets that, he will forward a star, G join up to the RP. 381 00:29:45,840 --> 00:29:49,440 And that will create star, G state in the rendezvous point himself.