1 00:00:08,400 --> 00:00:11,420 So by this point in the process, if you've been watching these videos 2 00:00:11,420 --> 00:00:15,800 from beginning up until now, we've pretty much covered the vast majority 3 00:00:15,800 --> 00:00:21,340 of the details of the PIM process and how it works in 90% of cases. 4 00:00:21,340 --> 00:00:24,640 But there's still a couple of other details that may have escaped you 5 00:00:24,640 --> 00:00:27,020 that are important to know, and that's what we're going to talk about 6 00:00:27,020 --> 00:00:30,820 now is this concept of designated routers and designated forwarders. 7 00:00:30,820 --> 00:00:35,040 Not really necessary to know if PIMs working perfectly, but in the case 8 00:00:35,040 --> 00:00:37,900 where things aren't working as you expect, you might have to troubleshoot 9 00:00:37,900 --> 00:00:42,960 things, you definitely have to know what these routers are, what purpose 10 00:00:42,960 --> 00:00:48,260 they serve, and why they were elected into these particular roles. 11 00:00:48,260 --> 00:00:50,300 So that being the case. 12 00:00:50,300 --> 00:00:53,820 I have a couple of questions for you. 13 00:00:53,820 --> 00:00:57,240 So if you're watching this as a recording, just think about it, blur it 14 00:00:57,240 --> 00:01:00,200 out your answer verbally, don't be afraid that people in the cubes next 15 00:01:00,200 --> 00:01:03,580 to you might think you're kind of insane, but see if you can answer these 16 00:01:03,580 --> 00:01:06,740 questions. They're basically yes or no questions. 17 00:01:06,740 --> 00:01:10,180 So looking at this diagram right here, we've got our source in the upper 18 00:01:10,180 --> 00:01:15,280 left corner, and we have two receivers, receiver X and receiver Y. 19 00:01:15,280 --> 00:01:20,780 So my first question, let's assume that receiver Y first joins the stream 20 00:01:20,780 --> 00:01:23,760 by sending an IGMP membership report. 21 00:01:23,760 --> 00:01:28,040 Well because routers three and four are both connected to that same LAN 22 00:01:28,040 --> 00:01:30,800 segment, here's my question. 23 00:01:30,800 --> 00:01:33,420 Would it make logical sense? 24 00:01:33,420 --> 00:01:37,540 Would there be a purpose behind both of those routers, routers three and 25 00:01:37,540 --> 00:01:41,720 four, when they both receive that membership report, both of them sending 26 00:01:41,720 --> 00:01:45,980 a star, IG join up to the rendezvous point? 27 00:01:45,980 --> 00:01:51,780 Well, hopefully answered, no, there wouldn't be a purpose behind that. 28 00:01:51,780 --> 00:01:55,880 As a matter of fact, that would be a bad thing because if both of those 29 00:01:55,880 --> 00:02:01,740 routers did do that, they sent joins up this way and up this way, well 30 00:02:01,740 --> 00:02:06,720 guess what? Now when the multicast traffic actually starts happening, 31 00:02:06,720 --> 00:02:11,420 use a different color right here, and starts coming down, well, router 32 00:02:11,420 --> 00:02:14,660 five has two interfaces and is not going interface list. 33 00:02:14,660 --> 00:02:18,400 So he'll copy that multicast traffic and we'll end up having two copies 34 00:02:18,400 --> 00:02:22,600 of the same packet onto LAN C. 35 00:02:22,600 --> 00:02:23,580 We don't want that. 36 00:02:23,580 --> 00:02:27,280 We don't want duplicate copies because who knows how router, how receiver 37 00:02:27,280 --> 00:02:28,720 Y is going to respond to that. 38 00:02:28,720 --> 00:02:32,960 The video might be really choppy, might have like a mirror effect. 39 00:02:32,960 --> 00:02:34,100 We don't want that. 40 00:02:34,100 --> 00:02:37,780 So no, even though two hours in the same LAN we'll see the membership 41 00:02:37,780 --> 00:02:42,840 report, we don't want both of them sending the join upstream to the rendezvous 42 00:02:42,840 --> 00:02:47,360 point. Next question. 43 00:02:47,360 --> 00:02:54,620 The source starts up, sends his very first packet onto LAN A. 44 00:02:54,620 --> 00:02:58,740 Both routers one and routers two see that packet. 45 00:02:58,740 --> 00:03:03,740 Similar question is before, does it make sense for both routers one and 46 00:03:03,740 --> 00:03:09,780 two to register that same packet and send those two registers to the rendezvous 47 00:03:09,780 --> 00:03:16,560 point? Once again, hopefully you said no, doesn't make a lot of sense 48 00:03:16,560 --> 00:03:20,840 because we don't need both of them to do it. 49 00:03:20,840 --> 00:03:23,480 Number one is going to add additional work to the rendezvous point. 50 00:03:23,480 --> 00:03:28,220 Now you're having the rendezvous point work twice as hard to receive and 51 00:03:28,220 --> 00:03:38,480 deencapsulate there's only a need to send one packet down to LAN A. 52 00:03:38,480 --> 00:03:40,720 There's no need to send two. 53 00:03:40,720 --> 00:03:44,320 So once again just like there was no need for both routers to send star, 54 00:03:44,320 --> 00:03:49,600 join, there's no reason both routers one and routers two need to send 55 00:03:49,600 --> 00:03:52,940 register packets to router six. 56 00:03:52,940 --> 00:03:57,400 Only one of them needs to do that. 57 00:03:57,400 --> 00:04:00,140 And last question. 58 00:04:00,140 --> 00:04:02,880 Let's say the multicast is flowing. 59 00:04:02,880 --> 00:04:07,500 So it's going this way down the shared tree. 60 00:04:07,500 --> 00:04:11,240 Now receiver X has also joined that stream. 61 00:04:11,240 --> 00:04:14,900 So it's also going through router two on to LAN B. 62 00:04:14,900 --> 00:04:19,040 And remember routers three and four, they both saw the membership report 63 00:04:19,040 --> 00:04:21,080 from receiver Y. 64 00:04:21,080 --> 00:04:24,640 So router three put this interface in his outgoing interface list. 65 00:04:24,640 --> 00:04:28,220 Router four put this interface in his outgoing interface list. 66 00:04:28,220 --> 00:04:32,440 So router four when he receives the packets, he'll forward it on to LAN 67 00:04:32,440 --> 00:04:38,780 C. When router three sees these packets coming on to LAN B, he will forward 68 00:04:38,780 --> 00:04:42,340 the same packet also on to LAN C. 69 00:04:42,340 --> 00:04:43,960 Do we want that? 70 00:04:43,960 --> 00:04:49,340 No, we don't. Once again we got duplicate multicast packets going on to 71 00:04:49,340 --> 00:04:53,080 LAN C. That's probably not going to make the receiver very happy to see 72 00:04:53,080 --> 00:04:58,700 that. So how do we get away from these problems about multiple routers 73 00:04:58,700 --> 00:05:02,020 sending a join for the same stream and the same LAN? 74 00:05:02,020 --> 00:05:06,620 Multiple routers sending a register for the same stream on the same LAN. 75 00:05:06,620 --> 00:05:10,280 Multiple routers forwarding duplicate packets onto the same LAN. 76 00:05:10,280 --> 00:05:12,900 That's exactly what this segment is about. 77 00:05:12,900 --> 00:05:13,840 How do we avoid that? 78 00:05:13,840 --> 00:05:17,220 Well PIM, fortunately the people who designed PIM were a lot smarter than 79 00:05:17,220 --> 00:05:20,800 me. They thought of these problems in advance and they came up with some 80 00:05:20,800 --> 00:05:26,580 solutions. So how does it work? 81 00:05:26,580 --> 00:05:30,200 Well PIM designated router. 82 00:05:30,200 --> 00:05:33,920 When two routers share the same LAN, one of them will be elected as the 83 00:05:33,920 --> 00:05:35,820 PIM designated router. 84 00:05:35,820 --> 00:05:39,220 This is simply done by an exchange of PIM hellos. 85 00:05:39,220 --> 00:05:42,880 It's sort of like think about spanning tree, if you're familiar with spanning 86 00:05:42,880 --> 00:05:47,720 tree. Are there special election messages to elect the root bridge? 87 00:05:47,720 --> 00:05:52,140 No, right? Spanning tree just uses one format of a BPDU. 88 00:05:52,140 --> 00:05:54,860 That one packet format is used for everything. 89 00:05:54,860 --> 00:05:59,040 So when two switches forward BPDUs to each other, they see each other's 90 00:05:59,040 --> 00:06:03,220 names and one guy says, okay, I know you're the root bridge. 91 00:06:03,220 --> 00:06:05,560 He doesn't actually say that, he thinks it in his mind. 92 00:06:05,560 --> 00:06:07,540 Okay, I lost, he's better than me. 93 00:06:07,540 --> 00:06:10,000 So I'll just think of him as the root bridge. 94 00:06:10,000 --> 00:06:12,800 The other guy over there will say, oh, I saw his packet. 95 00:06:12,800 --> 00:06:14,340 He's not as good as me. 96 00:06:14,340 --> 00:06:18,560 So I'll just be the root bridge and I'll assume that he knows on the root 97 00:06:18,560 --> 00:06:20,800 bridge. Same kind of thing here with PIM. 98 00:06:20,800 --> 00:06:23,160 These routers are exchanging hellos. 99 00:06:23,160 --> 00:06:30,380 When they see each other's hellos on the same LAN, they'll look at their, 100 00:06:30,380 --> 00:06:32,360 well, that's actually two things. 101 00:06:32,360 --> 00:06:34,380 Number one, there's a PIM priority. 102 00:06:34,380 --> 00:06:38,300 So there's an interface priority just like OSPF has an interface priority. 103 00:06:38,300 --> 00:06:42,020 There's a PIM priority that is included inside the hello packet. 104 00:06:42,020 --> 00:06:46,400 So whoever has the highest interface priority, that person will automatically 105 00:06:46,400 --> 00:06:48,920 be elected as the designated router. 106 00:06:48,920 --> 00:06:53,860 If their priorities are the same, which by default they will, then whoever 107 00:06:53,860 --> 00:06:58,400 has the highest IP address will be elected as the designated router. 108 00:06:58,400 --> 00:07:03,780 Okay? So once the designated router is elected, if we go back to our drawing 109 00:07:03,780 --> 00:07:11,920 here, now that solves a couple of the problems that we are looking at. 110 00:07:11,920 --> 00:07:15,080 Numbers of the routers represent their IP addresses. 111 00:07:15,080 --> 00:07:19,020 So router four on LANC has a higher IP address than router three. 112 00:07:19,020 --> 00:07:24,840 So in that particular case, actually I've got a slide that animates all 113 00:07:24,840 --> 00:07:36,340 of this. So in this particular case, let's look at LAN A for a second. 114 00:07:36,340 --> 00:07:40,740 When the multi-cast packet, when the very first multi-cast packet hits 115 00:07:40,740 --> 00:07:45,200 LAN A, only the designated router will be responsible for registering 116 00:07:45,200 --> 00:07:47,560 that packet with the RP. 117 00:07:47,560 --> 00:07:51,420 So in this particular case, which router do you think is going to do that? 118 00:07:51,420 --> 00:07:55,120 Who's going to be the designated router on LAN A? 119 00:07:55,120 --> 00:08:03,280 Well, hopefully you said router one, because router one has the highest 120 00:08:03,280 --> 00:08:07,560 IP address. So he will be the designated router, he will be responsible 121 00:08:07,560 --> 00:08:12,040 for registering those packets. 122 00:08:12,040 --> 00:08:20,520 And on LANC, well, when receiver Y sends his IGMP membership report, both 123 00:08:20,520 --> 00:08:25,320 routers three and routers four will see it, but router four is a designated 124 00:08:25,320 --> 00:08:27,200 router by virtue of his highest IP address. 125 00:08:27,200 --> 00:08:33,840 So he will be the one to send the PIM star, comma G join upstream to the 126 00:08:33,840 --> 00:08:35,140 rendezvous point. 127 00:08:35,140 --> 00:08:40,040 Now that answers two out of the three questions that we had. 128 00:08:40,040 --> 00:08:41,860 So we had three questions. 129 00:08:41,860 --> 00:08:44,980 Remember number one was if two routers see a membership report, which 130 00:08:44,980 --> 00:08:46,900 one sends the join to the RP? 131 00:08:46,900 --> 00:08:49,080 Well, that's the designated router. 132 00:08:49,080 --> 00:08:51,600 So something going to the RP. 133 00:08:51,600 --> 00:08:55,600 Second question was if two routers get the multi-cast packet, who sends 134 00:08:55,600 --> 00:08:57,920 the register to the RP? 135 00:08:57,920 --> 00:09:00,000 That's the designated router. 136 00:09:00,000 --> 00:09:05,000 So remember, designated router, maybe you can think of R in DR as being 137 00:09:05,000 --> 00:09:08,900 this is something responsible for going to the rendezvous point, someone 138 00:09:08,900 --> 00:09:11,840 who's sending something to the rendezvous point. 139 00:09:11,840 --> 00:09:17,660 Now I said that we had one other problem in this scenario, which is that 140 00:09:17,660 --> 00:09:24,160 we had multiple duplicate packets being put onto the same LAN from multiple 141 00:09:24,160 --> 00:09:28,960 routers. And I said it's not the DR's job to figure that out. 142 00:09:28,960 --> 00:09:33,860 That's the job of the designated forwarder. 143 00:09:33,860 --> 00:09:39,060 So if multiple packets, if I've got two or three routers all servicing 144 00:09:39,060 --> 00:09:44,960 the same LAN, and two or more of them are putting the exact same multi 145 00:09:44,960 --> 00:09:50,740 -cast packets onto that LAN, then one of them will be elected as the designated 146 00:09:50,740 --> 00:09:56,380 forwarder. Now that's actually a little bit more complex of a process 147 00:09:56,380 --> 00:10:00,300 than just simply looking at hello packets. 148 00:10:00,300 --> 00:10:06,480 In order to figure that out, there's actually a special PIM message called 149 00:10:06,480 --> 00:10:10,140 the PIM assert. So this is a new message we haven't talked about. 150 00:10:10,140 --> 00:10:14,860 So so far we've talked about the join prune, which is one packet, it just 151 00:10:14,860 --> 00:10:18,240 depends on the body of the packet, whether it's a join or prune, but it's 152 00:10:18,240 --> 00:10:19,980 the same type code in PIM. 153 00:10:19,980 --> 00:10:23,860 We had another type code, which was the hello, and we had a third type 154 00:10:23,860 --> 00:10:26,160 code, which was the register. 155 00:10:26,160 --> 00:10:29,860 And we had a register stop, and now this is another kind. 156 00:10:29,860 --> 00:10:32,840 This is a PIM assert message. 157 00:10:32,840 --> 00:10:37,940 And here's an animation to show basically how this would work. 158 00:10:37,940 --> 00:10:46,960 So in this particular case, the source starts going, and the packets are 159 00:10:46,960 --> 00:10:51,080 going both down the shared tree, so router 4 is putting them onto LAN 160 00:10:51,080 --> 00:10:57,320 C, and router 3 is getting them via LAN B, and so he's also putting them 161 00:10:57,320 --> 00:11:02,440 onto LAN C. So routers 3 and 4 will see these duplicate packets coming 162 00:11:02,440 --> 00:11:03,740 from each other. 163 00:11:03,740 --> 00:11:08,120 They'll realize, hey, this is a bad thing, we need a designated forwarder. 164 00:11:08,120 --> 00:11:14,220 So they'll both send PIM assert messages to each other. 165 00:11:14,220 --> 00:11:19,500 And this particular case, the guy with the lowest IP address will actually 166 00:11:19,500 --> 00:11:22,360 be elected as the designated forwarder. 167 00:11:22,360 --> 00:11:27,380 So once both routers know that router 3 is a designated forwarder, it's 168 00:11:27,380 --> 00:11:32,360 now router 3's job to continue forwarding this multicast onto the LAN. 169 00:11:32,360 --> 00:11:36,900 Router 4 says, okay, I'm not really needed on this LAN anymore, because 170 00:11:36,900 --> 00:11:38,660 it's not my job to forward the packets. 171 00:11:38,660 --> 00:11:44,560 So in his, in response, he'll send a prune message upstream, which will 172 00:11:44,560 --> 00:11:47,720 end up causing that shared tree to be cut off. 173 00:11:47,720 --> 00:11:51,660 And now the multicast will only be forwarded onto LAN C by way of the 174 00:11:51,660 --> 00:11:58,340 designated forwarder, which is router 3. 175 00:11:58,340 --> 00:12:03,340 So that completes this particular topic of the PIM designated router and 176 00:12:03,340 --> 00:12:04,480 designated forwarder. 177 00:12:04,480 --> 00:12:07,980 You can actually see this also when you go into a router. 178 00:12:07,980 --> 00:12:11,480 I don't know if we have any segments here which would warrant a designated 179 00:12:11,480 --> 00:12:14,220 forwarder, but let's just see here. 180 00:12:14,220 --> 00:12:19,580 Show IP PIM neighbor. 181 00:12:19,580 --> 00:12:25,620 Well, here the DR shows you if someone's a designated router or not, so 182 00:12:25,620 --> 00:12:28,960 as you for a particular segment who the designated router is. 183 00:12:28,960 --> 00:12:40,680 And I think we can also do a show IP PIM interface. 184 00:12:40,680 --> 00:12:45,680 This just shows you here who the designated router is once again. 185 00:12:45,680 --> 00:12:50,000 It has a default priority of one, so that's a default priority level on 186 00:12:50,000 --> 00:12:52,620 the interface, but you can change that. 187 00:12:52,620 --> 00:13:07,300 Let's see here. This shows you the particular groups that we've joined 188 00:13:07,300 --> 00:13:14,440 on an interface, the show IP interface command. 189 00:13:14,440 --> 00:13:19,840 I don't know what command we would use. 190 00:13:19,840 --> 00:13:25,120 Or maybe detail. 191 00:13:25,120 --> 00:13:34,040 There we go. It should be in here. 192 00:13:34,040 --> 00:13:39,720 Let's see here. PIM enable the version who the DR is. 193 00:13:39,720 --> 00:13:45,640 State refresh. Yeah, I think the reason why we're not seeing this is because 194 00:13:45,640 --> 00:13:51,760 this would a designated forwarder would only be elected when both routers 195 00:13:51,760 --> 00:13:57,420 see the same multicast packet coming from duplicate packets coming. 196 00:13:57,420 --> 00:14:00,720 But if there's never a situation where duplicate packets are going on 197 00:14:00,720 --> 00:14:04,700 a LAN, there's no need to elect a designated forwarder. 198 00:14:04,700 --> 00:14:08,200 And in my particular topology, I don't think we've had that situation 199 00:14:08,200 --> 00:14:10,940 where a designated forwarder needs to be elected. 200 00:14:10,940 --> 00:14:15,420 I would expect that if there was one, it should be here in the show IP 201 00:14:15,420 --> 00:14:17,580 PIM interface detail output. 202 00:14:17,580 --> 00:14:21,260 Okay, so Josh asks a good question. 203 00:14:21,260 --> 00:14:26,840 Let me go back to the designated router concept. 204 00:14:26,840 --> 00:14:28,460 We had this right here. 205 00:14:28,460 --> 00:14:30,820 Oops. Right there. 206 00:14:30,820 --> 00:14:35,820 So he asks, in this particular case, where router four is a designated 207 00:14:35,820 --> 00:14:38,140 router and router three is not. 208 00:14:38,140 --> 00:14:41,680 He says if the designated router goes down, so if router four crashes 209 00:14:41,680 --> 00:14:47,800 and dies or gets removed, how does router three build or rebuild its multicast 210 00:14:47,800 --> 00:14:49,980 routing table and how long does it take? 211 00:14:49,980 --> 00:14:57,300 Okay, so keep in mind that even though router four is a designated router, 212 00:14:57,300 --> 00:15:03,620 when receiver Y sent his IGMP membership report, both router three and 213 00:15:03,620 --> 00:15:05,580 router four saw it. 214 00:15:05,580 --> 00:15:10,140 So even though router three realizes that it's not his job to join the 215 00:15:10,140 --> 00:15:14,440 shared tree, he's not just going to ignore that report. 216 00:15:14,440 --> 00:15:21,500 He will still create star, state in his M route table just like router 217 00:15:21,500 --> 00:15:26,360 four does. It's just that when he creates that state, he won't do anything 218 00:15:26,360 --> 00:15:42,320 about it. Now if the multicast is currently flowing down this way, down 219 00:15:42,320 --> 00:15:50,240 the shared tree, we would expect that when the very first multicast packet 220 00:15:50,240 --> 00:15:55,780 happens, router four would say I'm the leaf router, so it's my job to 221 00:15:55,780 --> 00:16:00,060 switch over to the shortest path tree with just the receipt of one packet. 222 00:16:00,060 --> 00:16:05,600 So look in this diagram here, router four would say well, from my perspective, 223 00:16:05,600 --> 00:16:10,760 the shortest path is actually via router three. 224 00:16:10,760 --> 00:16:17,980 This is my shortest path tree, going that way, that way, and that way. 225 00:16:17,980 --> 00:16:23,720 So router four will actually create the S, G join and router three will 226 00:16:23,720 --> 00:16:29,860 receive it, so now, actually it's kind of weird here. 227 00:16:29,860 --> 00:16:34,080 When this very first multicast packet hits this wire here, I'm not sure 228 00:16:34,080 --> 00:16:35,200 the timing of things. 229 00:16:35,200 --> 00:16:38,300 We know that router three is going to create S, G state. 230 00:16:38,300 --> 00:16:40,760 I just don't know what will happen first. 231 00:16:40,760 --> 00:16:44,700 Will he see this very first multicast packet and that will create S, G 232 00:16:44,700 --> 00:16:50,880 state? Or will he see the PIM S, G join first and that will create S, 233 00:16:50,880 --> 00:17:05,120 G state? So then he will forward his own S, G join upstream, so after 234 00:17:05,120 --> 00:17:10,240 just one packet coming down within like less than a second, we would expect 235 00:17:10,240 --> 00:17:16,540 the multicast stream to now be coming this way via router three. 236 00:17:16,540 --> 00:17:21,260 And then once router four sees that multicast packet, he'll prune this 237 00:17:21,260 --> 00:17:27,640 off. So even if router four dies, we only really needed him for like one 238 00:17:27,640 --> 00:17:32,100 packet, just to put one packet on to the wire, and then router three did 239 00:17:32,100 --> 00:17:35,480 all the remaining work of opening up the shortest path tree, and now the 240 00:17:35,480 --> 00:17:39,220 packets were being forwarded on to land C, and router four wasn't necessary 241 00:17:39,220 --> 00:17:44,620 anymore. Now, you know, we can get into all sorts of corner cases here 242 00:17:44,620 --> 00:17:50,460 like, okay, well, what if the membership report comes up, both router 243 00:17:50,460 --> 00:17:58,740 three and router four get it, but before router four has a chance to create 244 00:17:58,740 --> 00:18:02,220 the join, he dies. 245 00:18:02,220 --> 00:18:05,080 Right now, that's like real nitty gritty, because we're talking about 246 00:18:05,080 --> 00:18:08,180 less than a second here from the time he receives the membership report 247 00:18:08,180 --> 00:18:12,120 before he has a chance to send up the join.