1 00:00:08,320 --> 00:00:13,520 Okay, so before we get into the nitty gritty details of PIM as a multicast 2 00:00:13,520 --> 00:00:17,920 routing protocol, let's look at a real high level of what are multicast 3 00:00:17,920 --> 00:00:22,100 routing protocols, why do we need them, what problem were they designed 4 00:00:22,100 --> 00:00:28,500 to solve. So we know that we got this concept of sources and receivers, 5 00:00:28,500 --> 00:00:31,880 the source being some server out there that's pumping out multicast traffic 6 00:00:31,880 --> 00:00:35,740 and hitting your router, that router is dropping it because there's no 7 00:00:35,740 --> 00:00:38,000 idea where it's supposed to go. 8 00:00:38,000 --> 00:00:41,380 And at the other end of the network, you got your receivers, your laptops, 9 00:00:41,380 --> 00:00:45,760 your PCs that want that multicast traffic, but their default gateway has 10 00:00:45,760 --> 00:00:47,300 no idea where the source is. 11 00:00:47,300 --> 00:00:49,720 So how do we connect the two? 12 00:00:49,720 --> 00:00:54,140 And that is the whole reason why we need multicast routing protocols to 13 00:00:54,140 --> 00:00:58,140 build that branch, to connect them, to build this multicast distribution 14 00:00:58,140 --> 00:01:04,360 tree. So we need to create that tree. 15 00:01:04,360 --> 00:01:07,580 And I talked in the previous video that we've got two basic high level 16 00:01:07,580 --> 00:01:09,160 ways of doing that. 17 00:01:09,160 --> 00:01:13,380 One method, which is called the push model, which is used in dense mode 18 00:01:13,380 --> 00:01:17,440 protocols, simply means let's just flood the network with that multicast 19 00:01:17,440 --> 00:01:21,700 traffic. You'll definitely get down to the receivers and all the other 20 00:01:21,700 --> 00:01:26,460 branches of the tree where it'll be up to the routers to prune off those 21 00:01:26,460 --> 00:01:30,080 branches to say, hey, upstream router, stop sending that to me. 22 00:01:30,080 --> 00:01:34,220 I don't have anybody downstream for me who actually wants it. 23 00:01:34,220 --> 00:01:40,280 The other model is sparse mode, which means, OK, once the receivers indicate 24 00:01:40,280 --> 00:01:44,900 their interest to the default gateway, the default gateway now has to 25 00:01:44,900 --> 00:01:48,520 trigger some sort of multicast join message saying, OK, I'm going to send 26 00:01:48,520 --> 00:01:51,400 a message upstream saying, hey, router up above me. 27 00:01:51,400 --> 00:01:56,100 If you ever get this message, this multicast stream, I'm down here. 28 00:01:56,100 --> 00:02:01,820 I want that. The question then becomes, OK, well, where does your default 29 00:02:01,820 --> 00:02:03,120 gateway send that? 30 00:02:03,120 --> 00:02:08,020 Because maybe he's got five or six routers sitting upstream from him. 31 00:02:08,020 --> 00:02:10,760 Which one does he send this join to? 32 00:02:10,760 --> 00:02:15,620 So in order to answer that, and here's a good analogy I came up with. 33 00:02:15,620 --> 00:02:18,600 Think about dating, right? 34 00:02:18,600 --> 00:02:21,540 Guys and girls dating trying to find each other. 35 00:02:21,540 --> 00:02:27,880 So a dense mode protocol would sort of be like, you're the guy, you walk 36 00:02:27,880 --> 00:02:31,460 into a nightclub, and in order to find your perfect mate, you just walk 37 00:02:31,460 --> 00:02:34,580 up to every single girl that's here saying, hey, I love you. 38 00:02:34,580 --> 00:02:35,660 Would you like to marry me? 39 00:02:35,660 --> 00:02:37,380 I love you. Would you like to marry me? 40 00:02:37,380 --> 00:02:40,220 Of course, you get slapped like multiple times that you're doing that. 41 00:02:40,220 --> 00:02:43,120 But hopefully, eventually, you'll find your receiver, right? 42 00:02:43,120 --> 00:02:46,180 The far corner there, the girl who's drinking a lot of beer, she'll say, 43 00:02:46,180 --> 00:02:47,400 yeah, I want to marry you. 44 00:02:47,400 --> 00:02:49,980 And so now you found your receiver. 45 00:02:49,980 --> 00:02:50,680 You're the source. 46 00:02:50,680 --> 00:02:51,300 She's the receiver. 47 00:02:51,300 --> 00:02:54,160 You had to go through everybody else first and get pruned back. 48 00:02:54,160 --> 00:02:56,820 But eventually, you found who you were looking for. 49 00:02:56,820 --> 00:02:59,040 That's like a dense mode protocol. 50 00:02:59,040 --> 00:03:02,680 A sparse mode protocol is like, instead of doing that and risking all 51 00:03:02,680 --> 00:03:06,140 that rejection, you use a dating service. 52 00:03:06,140 --> 00:03:09,660 So you've got this intermediary company called a dating service, you know, 53 00:03:09,660 --> 00:03:15,140 whatever, eharmony.com or whatever the big one is these days. 54 00:03:15,140 --> 00:03:19,540 And the source, you, you go to the dating service and you create a profile. 55 00:03:19,540 --> 00:03:21,260 And you say, hey, this is me. 56 00:03:21,260 --> 00:03:22,400 I'm so wonderful and great. 57 00:03:22,400 --> 00:03:23,900 I make $5 million a year. 58 00:03:23,900 --> 00:03:24,880 I drive a Ferrari. 59 00:03:24,880 --> 00:03:26,160 Please marry me. 60 00:03:26,160 --> 00:03:28,340 Right? So you post your thing there at the dating service. 61 00:03:28,340 --> 00:03:31,800 The receivers, well, you know, of all the 50 million women who are using 62 00:03:31,800 --> 00:03:35,180 that dating service, there might be three of them that go to that dating 63 00:03:35,180 --> 00:03:38,020 service and say, oh, yeah, that's exactly what I'm looking for. 64 00:03:38,020 --> 00:03:38,800 He's kind of a jerk. 65 00:03:38,800 --> 00:03:39,600 He's got a lot of money. 66 00:03:39,600 --> 00:03:40,920 He's got a Ferrari. 67 00:03:40,920 --> 00:03:41,640 I'll like that guy. 68 00:03:41,640 --> 00:03:45,140 And so the two of you meet up through the dating service and initially 69 00:03:45,140 --> 00:03:47,700 you can't talk to each other, right? 70 00:03:47,700 --> 00:03:50,340 Initially the dating service says, no, you know, to make sure this guy 71 00:03:50,340 --> 00:03:53,420 is not a stalker and she's not crazy, you know, we're not going to let 72 00:03:53,420 --> 00:03:56,380 you guys exchange phone numbers and addresses and stuff. 73 00:03:56,380 --> 00:03:59,740 You're going to have to use our chat system and our email system to talk 74 00:03:59,740 --> 00:04:03,900 to each other. But eventually after you've exchanged messages through 75 00:04:03,900 --> 00:04:07,580 the dating service, now you can learn where each other lives. 76 00:04:07,580 --> 00:04:10,120 You can exchange phone numbers and you can stop using them. 77 00:04:10,120 --> 00:04:12,460 You can communicate directly. 78 00:04:12,460 --> 00:04:15,160 That's how sparse mode protocols work. 79 00:04:15,160 --> 00:04:19,080 With sparse mode protocols, you've got some router sitting somewhere in 80 00:04:19,080 --> 00:04:23,180 your network that serves like that dating service functionality. 81 00:04:23,180 --> 00:04:28,200 And so the receivers, once your laptop sends the IGMP message to the router, 82 00:04:28,200 --> 00:04:32,880 your default gateway, your default gateway says, hmm, okay, I know I got 83 00:04:32,880 --> 00:04:40,060 a receiver here, have no idea where the source is. 84 00:04:40,060 --> 00:04:44,720 receiver wants. But I do know where the dating service is in the terms 85 00:04:44,720 --> 00:04:48,700 of a multicast routing protocol, that dating service is what we call a 86 00:04:48,700 --> 00:04:51,160 rendezvous point, an RP. 87 00:04:51,160 --> 00:04:54,660 So there's some router in the network that all the routers running multicast 88 00:04:54,660 --> 00:04:57,380 know that guy is the guy we go to. 89 00:04:57,380 --> 00:04:59,460 That is the rendezvous point. 90 00:04:59,460 --> 00:05:03,060 So now your router will say, okay, I'm going to create something called 91 00:05:03,060 --> 00:05:05,380 a join, a multicast join message. 92 00:05:05,380 --> 00:05:09,520 And I'll send it in the direction of the rendezvous point saying, hey, 93 00:05:09,520 --> 00:05:12,520 I got a guy down here who's looking for this group. 94 00:05:12,520 --> 00:05:17,460 And so eventually that join makes its way up to the rendezvous point. 95 00:05:17,460 --> 00:05:20,900 Now the source may not have started yet, but the rendezvous point now 96 00:05:20,900 --> 00:05:25,000 has built a branch down the tree from the rendezvous point down through 97 00:05:25,000 --> 00:05:27,120 these routers down to your default gateway. 98 00:05:27,120 --> 00:05:32,320 We've now opened up a path so that if the multicast does start, it's got 99 00:05:32,320 --> 00:05:34,240 a direction that it can flow. 100 00:05:34,240 --> 00:05:38,040 Now the source, the source starts up, the server. 101 00:05:38,040 --> 00:05:41,900 So that server starts sending its multicast and it's hitting its router, 102 00:05:41,900 --> 00:05:45,580 some router connected to that segment, is being pounded on the back of 103 00:05:45,580 --> 00:05:47,580 the head with this multicast traffic. 104 00:05:47,580 --> 00:05:50,440 Once again, that router way up there in the other corner of the network 105 00:05:50,440 --> 00:05:55,300 says, I've never heard from any receivers, but I know where the dating 106 00:05:55,300 --> 00:06:03,540 service is. I know where the rendezvous point is. 107 00:06:03,540 --> 00:06:07,080 And we'll go into more details about this, but basically encapsulates 108 00:06:07,080 --> 00:06:12,500 it in unicast. It takes that multicast packet, wraps it inside of a unicast 109 00:06:12,500 --> 00:06:16,500 header and unicasts it to the rendezvous point. 110 00:06:16,500 --> 00:06:20,920 Once the rendezvous point gets it, he unencapsulates it, says, oh, here's 111 00:06:20,920 --> 00:06:24,240 multicast. Oh, yeah, I know where this goes because I received a join 112 00:06:24,240 --> 00:06:27,360 for this and he sends it down the tree. 113 00:06:27,360 --> 00:06:31,020 So that's how in sparse mode protocols we initially connect them, right? 114 00:06:31,020 --> 00:06:33,460 That rendezvous point is the dating service. 115 00:06:33,460 --> 00:06:37,460 But just like in my analogy, you don't want the source and the receiver 116 00:06:37,460 --> 00:06:41,360 constantly going through the rendezvous point to talk to each other. 117 00:06:41,360 --> 00:06:43,400 It's not necessarily efficient, right? 118 00:06:43,400 --> 00:06:49,980 What if that receiver is in Florida, the source is in North Carolina, 119 00:06:49,980 --> 00:06:52,680 but the rendezvous point is in California? 120 00:06:52,680 --> 00:06:55,700 Well, in that traffic's going way out of the way to get to the rendezvous 121 00:06:55,700 --> 00:07:00,300 point and back. There's a much shorter path directly between the source 122 00:07:00,300 --> 00:07:02,140 and the receiver. 123 00:07:02,140 --> 00:07:06,080 But we had to get that multicast going first before we could discover 124 00:07:06,080 --> 00:07:10,320 where it's coming from, that it's coming from North Carolina. 125 00:07:10,320 --> 00:07:13,280 And now the Rogers can switch over to that path. 126 00:07:13,280 --> 00:07:15,060 They can say, OK, thank you, dating service. 127 00:07:15,060 --> 00:07:16,380 Thank you, rendezvous point. 128 00:07:16,380 --> 00:07:17,760 Don't need you anymore. 129 00:07:17,760 --> 00:07:20,240 Now I know exactly where the source is. 130 00:07:20,240 --> 00:07:24,040 We can get the traffic directly from him and we can switch over to that 131 00:07:24,040 --> 00:07:29,360 path. So that's a real high level of how sparse mode protocols work. 132 00:07:29,360 --> 00:07:33,540 We have to join with the rendezvous point first, express our interest, 133 00:07:33,540 --> 00:07:35,440 build that branch. 134 00:07:35,440 --> 00:07:39,680 The traffic has to start going to the rendezvous point and then it switches 135 00:07:39,680 --> 00:07:44,620 over so it's going directly between the source and the receiver, rendezvous 136 00:07:44,620 --> 00:07:49,260 point's not even part of the equation anymore. 137 00:07:49,260 --> 00:07:56,680 So sparse mode protocols use something called core based trees or RP trees 138 00:07:56,680 --> 00:07:58,500 because we've got a rendezvous point. 139 00:07:58,500 --> 00:08:01,140 So the rendezvous point is the core of the tree. 140 00:08:01,140 --> 00:08:05,620 Everybody starts by going to him and then it switches away from him pretty 141 00:08:05,620 --> 00:08:16,700 quickly. OK, so RPF in case you're not familiar with, of course, RPF could 142 00:08:16,700 --> 00:08:16,880 switch over to the tree. 143 00:08:16,880 --> 00:08:20,780 It's a lot of different things but in this particular case it stands for 144 00:08:20,780 --> 00:08:23,260 reverse path forwarding. 145 00:08:23,260 --> 00:08:27,060 Now think about unicast traffic. 146 00:08:27,060 --> 00:08:29,840 Let's steer away from multicast for a second. 147 00:08:29,840 --> 00:08:36,720 A router receives a unicast packet going to some destination 9.9.9.9. 148 00:08:36,720 --> 00:08:38,560 What does the router do? 149 00:08:38,560 --> 00:08:43,420 The router says, OK, I'm going to look at that destination IP address, 150 00:08:43,420 --> 00:08:47,920 go into my routing table and see if I have some sort of a route that tells 151 00:08:47,920 --> 00:08:49,940 me where that destination is. 152 00:08:49,940 --> 00:08:54,740 Normally in order to route that pack in order to get it on its way, does 153 00:08:54,740 --> 00:08:58,060 the router care about the source of that packet? 154 00:08:58,060 --> 00:09:01,320 No, you could care less what that source address is. 155 00:09:01,320 --> 00:09:05,260 As a matter of fact, you could put 0, 0, 0, 0 as the source, the router 156 00:09:05,260 --> 00:09:09,220 wouldn't care. In order to route that packet all it cares about is the 157 00:09:09,220 --> 00:09:13,920 destination. Now certainly you could implement access lists and other 158 00:09:13,920 --> 00:09:17,120 stuff like that to force him to look at the source. 159 00:09:17,120 --> 00:09:20,580 And you can actually implement something called RPF as well. 160 00:09:20,580 --> 00:09:25,720 For example, what if I, you know, let's say my laptop right now is sitting 161 00:09:25,720 --> 00:09:32,120 on the 11 network, 11.something, so I've had an 11 address, 11.555. 162 00:09:32,120 --> 00:09:34,820 That's the address of my laptop. 163 00:09:34,820 --> 00:09:38,280 And I discover, I find out through the grapevine that I'm going to be 164 00:09:38,280 --> 00:09:41,080 laid off today. I say, what? 165 00:09:41,080 --> 00:09:43,260 Man, I put in all sorts of years with this company. 166 00:09:43,260 --> 00:09:44,340 I've worked overtime. 167 00:09:44,340 --> 00:09:46,520 I've sacrificed my children for this company. 168 00:09:46,520 --> 00:09:47,560 They're going to lay me off. 169 00:09:47,560 --> 00:09:49,260 That really ticks me off. 170 00:09:49,260 --> 00:09:50,440 So I say, you know what? 171 00:09:50,440 --> 00:09:56,140 Before I go, I know what the IP address is of my company's web server. 172 00:09:56,140 --> 00:10:00,000 It's 77777. So I'm a little, I'm savvy enough. 173 00:10:00,000 --> 00:10:00,560 I say, you know what? 174 00:10:00,560 --> 00:10:01,720 I'm going to bring down that server. 175 00:10:01,720 --> 00:10:05,040 I'm going to slam that server with, I don't know, some kind of traffic. 176 00:10:05,040 --> 00:10:07,300 Maybe TCP sync requests, right? 177 00:10:07,300 --> 00:10:11,080 I'm just going to slam it with 5 million TCP syncs every second. 178 00:10:11,080 --> 00:10:12,440 Bring it down. So ha ha ha. 179 00:10:12,440 --> 00:10:13,540 You want to lay me off? 180 00:10:13,540 --> 00:10:15,780 I'm going to make you guys lose millions of dollars over the next couple 181 00:10:15,780 --> 00:10:18,100 of hours while your server's down. 182 00:10:18,100 --> 00:10:22,240 Well, if I decide to do that, I don't want people tracing those packets 183 00:10:22,240 --> 00:10:23,580 back to me, right? 184 00:10:23,580 --> 00:10:27,360 Because not only will I get laid off, now I'll be in a jail cell with 185 00:10:27,360 --> 00:10:29,060 someone I'm not particularly fond of. 186 00:10:29,060 --> 00:10:30,280 So I don't want that. 187 00:10:30,280 --> 00:10:34,080 So I say, hmm, if I'm going to send those TCP sync requests to that server 188 00:10:34,080 --> 00:10:37,480 to try to overwhelm it, I want to make sure that the source address is 189 00:10:37,480 --> 00:10:41,160 not me. I don't want to be 11555, which is me. 190 00:10:41,160 --> 00:10:44,940 I want to spoof that source address to look like something else. 191 00:10:44,940 --> 00:10:49,000 So if they find those packets, they'll never know it came from me. 192 00:10:49,000 --> 00:10:53,000 So I'll give it a fake IP address because I know when those packets hit 193 00:10:53,000 --> 00:11:00,260 the routers, the routers don't care what the source address is. 194 00:11:00,260 --> 00:11:02,260 And it'll crash. 195 00:11:02,260 --> 00:11:06,960 Well, if I'm the network administrator, one thing I can do to prevent 196 00:11:06,960 --> 00:11:12,540 people from doing that is I can use what's called unicast RPF checking, 197 00:11:12,540 --> 00:11:16,740 which means when a packet comes into an interface on a router, before 198 00:11:16,740 --> 00:11:21,460 I even look at the destination address, I'm going to look at the source 199 00:11:21,460 --> 00:11:25,440 address, and I'm going to ask myself a very simple question. 200 00:11:25,440 --> 00:11:31,180 That source address, if I was to go back in the reverse direction towards 201 00:11:31,180 --> 00:11:36,280 that source, would I use this interface where it just came in? 202 00:11:36,280 --> 00:11:38,480 Now, I'm sitting here. 203 00:11:38,480 --> 00:11:44,100 I'm 11.555. I've intentionally changed the source address of my packet 204 00:11:44,100 --> 00:11:49,320 to something completely fake, like 12, 12, 12, 12. 205 00:11:49,320 --> 00:11:51,060 Well, it came in this interface. 206 00:11:51,060 --> 00:11:53,580 It came in fast Ethan at 00 on the router. 207 00:11:53,580 --> 00:11:57,720 According to this router's routing table, he says, to get to the 12, 12 208 00:11:57,720 --> 00:12:01,120 network, I wouldn't go fast Ethan at 00. 209 00:12:01,120 --> 00:12:03,740 I'd go out serial 11. 210 00:12:03,740 --> 00:12:08,120 So if that network administrator has configured unicast RPF checking in 211 00:12:08,120 --> 00:12:11,260 the router, the router will say, there's something wrong with this packet. 212 00:12:11,260 --> 00:12:15,660 According to my reverse path, I would not go this way to get to 12. 213 00:12:15,660 --> 00:12:16,700 I would go this way. 214 00:12:16,700 --> 00:12:21,280 The packet came in the wrong interface, and it would be dropped. 215 00:12:21,280 --> 00:12:22,340 It would be discarded. 216 00:12:22,340 --> 00:12:25,760 And so now my server would never get that packet. 217 00:12:25,760 --> 00:12:27,980 It would never harm the server. 218 00:12:27,980 --> 00:12:29,900 That's not on by default. 219 00:12:29,900 --> 00:12:33,580 Unicast RPF checking is something you have to enable if you want to do 220 00:12:33,580 --> 00:12:36,840 that. Well, how does that relate to this? 221 00:12:36,840 --> 00:12:43,420 When you enable multicast, multicast routing protocols do RPF checks on 222 00:12:43,420 --> 00:12:45,780 the source by default. 223 00:12:45,780 --> 00:12:48,140 As a matter of fact, you can't stop them from doing that. 224 00:12:48,140 --> 00:12:50,400 They do that. Now, why do they do that? 225 00:12:50,400 --> 00:12:52,940 They do it for loop detection. 226 00:12:52,940 --> 00:12:56,240 The idea is when a multicast packet comes in, you don't want to just circle 227 00:12:56,240 --> 00:12:58,600 around the network forever. 228 00:12:58,600 --> 00:13:04,280 So what the routers do is they say, okay, router's running sparse mode 229 00:13:04,280 --> 00:13:08,840 protocols. So if I'm a router sitting in a network, let's just say I'm 230 00:13:08,840 --> 00:13:09,700 the default gateway. 231 00:13:09,700 --> 00:13:14,020 I'm the gateway connected to this receiver, to my laptop right here. 232 00:13:14,020 --> 00:13:18,800 And I've just been informed via IGMP that this receiver wants to receive 233 00:13:18,800 --> 00:13:22,240 some multicast. 239-777. 234 00:13:22,240 --> 00:13:27,780 Let's just draw this to make this clear. 235 00:13:27,780 --> 00:13:39,460 Okay. So, here is, oh, hold on just a second. 236 00:13:39,460 --> 00:13:42,820 I'll just do it this way then. 237 00:13:42,820 --> 00:13:47,540 Here is my receiver right here as a square. 238 00:13:47,540 --> 00:13:50,920 We'll put that as a little R. 239 00:13:50,920 --> 00:13:58,180 And here is the default gateway that he's connected to. 240 00:13:58,180 --> 00:14:01,940 Default gateway. 241 00:14:01,940 --> 00:14:08,900 And he's got several interfaces leading upstream. 242 00:14:08,900 --> 00:14:14,720 We'll just say interface one, two, and three. 243 00:14:14,720 --> 00:14:16,320 Doesn't matter what they are. 244 00:14:16,320 --> 00:14:19,840 Fast ethernet serial, it's irrelevant for this discussion. 245 00:14:19,840 --> 00:14:27,300 Now, this router has just received an IGMP membership report from the 246 00:14:27,300 --> 00:14:39,060 receiver. And that receiver wants to get the traffic for 239-777. 247 00:14:39,060 --> 00:14:41,740 That's the group he wants to participate in. 248 00:14:41,740 --> 00:14:46,020 Now, this router is running a sparse mode routing protocol. 249 00:14:46,020 --> 00:14:47,280 So we'll just say it's PIM. 250 00:14:47,280 --> 00:14:51,420 It's running the protocol independent multicast routing protocol. 251 00:14:51,420 --> 00:14:54,120 So as part of PIM, in order to get PIM to work, he says, okay, I know 252 00:14:54,120 --> 00:14:55,420 there's some router somewhere. 253 00:14:55,420 --> 00:15:00,660 We'll call it way out here, which is my rendezvous point. 254 00:15:00,660 --> 00:15:04,140 And so I've got to let the rendezvous point know that I've got a receiver 255 00:15:04,140 --> 00:15:05,860 down here who wants this. 256 00:15:05,860 --> 00:15:10,240 So let's say this rendezvous point is 8888. 257 00:15:10,240 --> 00:15:14,580 So this router, he says, okay, I know. 258 00:15:14,580 --> 00:15:17,400 Let's just do a little thought bubble here. 259 00:15:17,400 --> 00:15:22,220 He says, I know that the PIM RP is 8888. 260 00:15:22,220 --> 00:15:26,960 Now, he says, okay, how do I get to the PIM RP? 261 00:15:26,960 --> 00:15:30,260 Now, this is where he uses his unicast routing protocol. 262 00:15:30,260 --> 00:15:35,100 I've mentioned a few times that multicast routing works hand in hand with 263 00:15:35,100 --> 00:15:36,920 your unicast routing protocol. 264 00:15:36,920 --> 00:15:39,560 So he says, okay, let me go into my routing table. 265 00:15:39,560 --> 00:15:42,980 And according to my routing table, I've got an EI-JRP route that says 266 00:15:42,980 --> 00:15:49,800 to the get to the 8.8 network, it's via interface 2. 267 00:15:49,800 --> 00:15:56,920 So he sends a PIM join out interface 2. 268 00:15:56,920 --> 00:16:04,620 And eventually, that PIM join works its way through the network and gets 269 00:16:04,620 --> 00:16:06,420 up to the rendezvous point. 270 00:16:06,420 --> 00:16:09,840 So this is now the shared tree, right? 271 00:16:09,840 --> 00:16:14,600 This is the tree going from the rendezvous point down to the default gateway. 272 00:16:14,600 --> 00:16:19,960 Now, this default gateway, because he's running PIMS sparse mode, he says, 273 00:16:19,960 --> 00:16:27,080 okay, I expect that when the multicast does start, whenever it starts, 274 00:16:27,080 --> 00:16:31,260 it should come down from the rendezvous point. 275 00:16:31,260 --> 00:16:35,640 So let's say the multicast does start, and here it comes. 276 00:16:35,640 --> 00:16:38,680 Here it comes down this way. 277 00:16:38,680 --> 00:16:44,540 So the source is 7777. 278 00:16:44,540 --> 00:16:48,660 The destination is 239.777. 279 00:16:48,660 --> 00:16:54,700 Well, because this guy's running PIMS sparse mode, he does an RPF check. 280 00:16:54,700 --> 00:16:55,660 But here's how it works. 281 00:16:55,660 --> 00:17:01,200 He says, well, because I expected this multicast to come by way of the 282 00:17:01,200 --> 00:17:06,740 rendezvous point, he says, what interface should it have come in on? 283 00:17:06,740 --> 00:17:10,820 Well, according to my routing table, to get to the rendezvous point, I 284 00:17:10,820 --> 00:17:12,540 go via interface 2. 285 00:17:12,540 --> 00:17:16,860 Huh, this multicast did not come down from the rendezvous point. 286 00:17:16,860 --> 00:17:19,000 It did not come from interface 2. 287 00:17:19,000 --> 00:17:21,820 So guess what? I'm going to kill it. 288 00:17:21,820 --> 00:17:24,240 This is an RPF failure. 289 00:17:24,240 --> 00:17:29,080 It did not come down what we call the shared tree, the tree that is shared 290 00:17:29,080 --> 00:17:31,620 between the rendezvous point and this default gateway. 291 00:17:31,620 --> 00:17:35,460 It just failed the RPF check. 292 00:17:35,460 --> 00:17:38,740 Now let's say it had come down this way. 293 00:17:38,740 --> 00:17:41,820 Okay, so it came down the correct path. 294 00:17:41,820 --> 00:17:43,960 The RPF check would succeed. 295 00:17:43,960 --> 00:17:48,020 It would pass. He'd say, okay, I am interested in this group, and it did 296 00:17:48,020 --> 00:17:52,640 come in on the correct interface, on interface 2, which is the interface 297 00:17:52,640 --> 00:17:55,100 leading to the RP. 298 00:17:55,100 --> 00:17:56,760 Now something interesting happens. 299 00:17:56,760 --> 00:17:58,480 So let's just go ahead and put this back in here. 300 00:17:58,480 --> 00:18:04,080 Source was 777. Destination was 239.777. 301 00:18:04,080 --> 00:18:09,460 Okay, so he can forward that multicast to the client, to the receiver. 302 00:18:09,460 --> 00:18:14,760 Now for the very first time, this router says, oh, finally, I know who 303 00:18:14,760 --> 00:18:21,480 the source is. The actual address of the server is 777. 304 00:18:21,480 --> 00:18:25,860 Now PIMS-SPAR-SMO says, okay, I could continue to get this from the rendezvous 305 00:18:25,860 --> 00:18:28,640 point, but is there a better path? 306 00:18:28,640 --> 00:18:32,880 Is there actually a shorter path to get to that source that would be more 307 00:18:32,880 --> 00:18:36,900 efficient? So he goes back to his routing table. 308 00:18:36,900 --> 00:18:42,140 He says, okay, now let me do an RPF lookup on that. 309 00:18:42,140 --> 00:18:48,060 And he says, oh, lo and behold, I've got a route that matches that, that 310 00:18:48,060 --> 00:18:49,880 I learned via EIGRP. 311 00:18:49,880 --> 00:18:52,620 Once again, it could be learned via RIP or OSPF. 312 00:18:52,620 --> 00:18:58,240 We don't care. He says, that's via interface 1. 313 00:18:58,240 --> 00:19:00,740 So now PIM does something special. 314 00:19:00,740 --> 00:19:04,940 He sends another PIM join out this way. 315 00:19:04,940 --> 00:19:09,720 We're going to get in all the details of this. 316 00:19:09,720 --> 00:19:17,340 And he says, this is for source 777 destination 239.777. 317 00:19:17,340 --> 00:19:21,820 And that PIM join goes all the way up. 318 00:19:21,820 --> 00:19:25,960 And let's say the source is right here. 319 00:19:25,960 --> 00:19:31,360 That's actually where the server is. 320 00:19:31,360 --> 00:19:34,540 And there have been a bunch of routers in the middle. 321 00:19:34,540 --> 00:19:36,000 So here was a router. 322 00:19:36,000 --> 00:19:37,760 Here's a router. 323 00:19:37,760 --> 00:19:38,940 And here's a router. 324 00:19:38,940 --> 00:19:41,000 And they're all connected like this. 325 00:19:41,000 --> 00:19:47,760 Assuming that all these routers know how to get to the 777 network, that 326 00:19:47,760 --> 00:19:52,620 special PIM join would have gone all the way up and finally made it to 327 00:19:52,620 --> 00:19:55,560 this router that's connected to the source. 328 00:19:55,560 --> 00:19:59,240 And that has now opened up the shortest path tree. 329 00:19:59,240 --> 00:20:00,780 Notice we've got two different trees here. 330 00:20:00,780 --> 00:20:04,520 We've got the blue one and the green one. 331 00:20:04,520 --> 00:20:08,560 And the blue point down to the default gateway was called the shared tree 332 00:20:08,560 --> 00:20:11,280 or sometimes called the RP tree. 333 00:20:11,280 --> 00:20:14,400 You might sometimes see the acronym RPT. 334 00:20:14,400 --> 00:20:19,240 That worked, but it might not be the most efficient path. 335 00:20:19,240 --> 00:20:23,720 This green tree is the shortest path tree. 336 00:20:23,720 --> 00:20:28,320 But we didn't know what that was until we knew where the source was until 337 00:20:28,320 --> 00:20:31,140 we got our very first multicast packet. 338 00:20:31,140 --> 00:20:35,360 And so now that we've opened up that tree, now the router says, okay, 339 00:20:35,360 --> 00:20:42,380 at this point, for a slight moment in time, the next time I get the multicast 340 00:20:42,380 --> 00:20:45,660 packet, it could come from one of two places. 341 00:20:45,660 --> 00:20:50,200 I will accept it on interface two because it might still be coming from 342 00:20:50,200 --> 00:20:51,800 the rendezvous point. 343 00:20:51,800 --> 00:20:55,680 And now if it comes on interface one, I will also accept it because I 344 00:20:55,680 --> 00:20:57,000 tried to open up this path. 345 00:20:57,000 --> 00:21:01,560 I intentionally tried to open up this path hoping that the multicast traffic 346 00:21:01,560 --> 00:21:04,100 will come down this way. 347 00:21:04,100 --> 00:21:09,320 So now if the multicast comes on interface three, that'll be an RPF failure. 348 00:21:09,320 --> 00:21:12,660 Because the router says, hey, interface three, that's not the shared tree 349 00:21:12,660 --> 00:21:16,180 and it's not the shortest path tree. 350 00:21:16,180 --> 00:21:20,720 But it comes down either one of these, it'll pass the RPF check. 351 00:21:20,720 --> 00:21:25,920 And once the multicast actually starts flowing and coming in on interface 352 00:21:25,920 --> 00:21:30,500 number one, now the default gateway will say, great! 353 00:21:30,500 --> 00:21:33,940 I'm getting the multicast traffic via the most efficient way possible 354 00:21:33,940 --> 00:21:36,260 via the shortest path tree. 355 00:21:36,260 --> 00:21:39,340 I don't need to get it from the rendezvous point anymore. 356 00:21:39,340 --> 00:21:44,380 So he'll actually send a PIM prune message up this way, which will prune 357 00:21:44,380 --> 00:21:51,460 off this tree. And now the multicast will be flowing down the shortest 358 00:21:51,460 --> 00:21:56,100 path tree until the receiver no longer wants it. 359 00:21:56,100 --> 00:21:59,760 So that's a real high level of how PIM sparse mode works. 360 00:21:59,760 --> 00:22:04,280 But I did all that to show you that RPF checks are happening. 361 00:22:04,280 --> 00:22:09,860 It all depends on where the router expects to get the multicast from. 362 00:22:09,860 --> 00:22:13,480 If he's expecting it to come from the rendezvous point, he's going to 363 00:22:13,480 --> 00:22:17,860 say, look, the rendezvous point lives on interface one or interface seven, 364 00:22:17,860 --> 00:22:20,640 and he learns that by his routing protocol. 365 00:22:20,640 --> 00:22:24,280 That's where I expect to get the multicast initially. 366 00:22:24,280 --> 00:22:27,800 If it comes from any other interface, I'm going to kill it. 367 00:22:27,800 --> 00:22:28,820 I'm going to drop it. 368 00:22:28,820 --> 00:22:31,340 It wasn't supposed to come that way. 369 00:22:31,340 --> 00:22:34,880 But once he knows what the source is and he tries to open up that shortest 370 00:22:34,880 --> 00:22:39,500 path tree, now the RPF will succeed. 371 00:22:39,500 --> 00:22:46,420 It will pass if the multicast comes down the shortest path tree. 372 00:22:46,420 --> 00:22:51,840 So how do we determine the correct ingress interface? 373 00:22:51,840 --> 00:22:56,480 How do we make sure that the RPF succeeds or passes based on the type 374 00:22:56,480 --> 00:22:58,800 of tree that we're expecting? 375 00:22:58,800 --> 00:23:02,460 Are we expecting it to come down the core tree, otherwise known as the 376 00:23:02,460 --> 00:23:09,940 RP tree? Or are we expecting that traffic to come down the source tree? 377 00:23:09,940 --> 00:23:16,400 Now, may be dependent on the specific IGP type. 378 00:23:16,400 --> 00:23:18,620 What am I talking about there? 379 00:23:18,620 --> 00:23:21,980 PIM is not the only multicast routing protocol. 380 00:23:21,980 --> 00:23:22,800 There are other ones. 381 00:23:22,800 --> 00:23:27,120 For example, MOSPF, multicast OSPF. 382 00:23:27,120 --> 00:23:31,440 You can probably guess if I'm using multicast OSPF in order to figure 383 00:23:31,440 --> 00:23:35,140 out what the correct interface is to go to the RP, or the correct interface 384 00:23:35,140 --> 00:23:39,480 to go to the source, it relies on OSPF routes. 385 00:23:39,480 --> 00:23:44,120 MOSPF cannot do RPF checking based on RIP or EIGRP. 386 00:23:44,120 --> 00:23:50,500 It needs OSPF. There's another one called DVMRP, Distance Vector Multicast 387 00:23:50,500 --> 00:23:51,940 Routing Protocol. 388 00:23:51,940 --> 00:23:53,120 That one's kind of weird. 389 00:23:53,120 --> 00:23:59,660 It actually builds its own separate unicast table just to do RPF checks. 390 00:23:59,660 --> 00:24:01,140 The DVMRP table. 391 00:24:01,140 --> 00:24:02,920 It doesn't use anything else. 392 00:24:02,920 --> 00:24:08,720 The wonderful thing about PIM, Protocol Independent Multicast. 393 00:24:08,720 --> 00:24:13,000 The Protocol Independent means PIM says, I don't care. 394 00:24:13,000 --> 00:24:16,100 When I do an RPF check, I'm going to go into the routing table. 395 00:24:16,100 --> 00:24:19,960 I don't care if I can find a route that's a static route, connected route, 396 00:24:19,960 --> 00:24:21,540 EIGRP, RIP, OSPF. 397 00:24:21,540 --> 00:24:27,160 I don't care. As long as I can find something in order to do my RPF checking, 398 00:24:27,160 --> 00:24:32,040 I'll be happy. That's why PIM is so popular because it allows you to use 399 00:24:32,040 --> 00:24:35,100 whatever IGP routing protocol you want. 400 00:24:35,100 --> 00:24:36,860 It's not dependent on that.