1 00:00:08,380 --> 00:00:11,380 Now we're finally going to get into the moment you've all been waiting 2 00:00:11,380 --> 00:00:16,440 for. We're going to start focusing on protocol independent multicast sparse 3 00:00:16,440 --> 00:00:20,240 mode and then going into the details of how it works. 4 00:00:20,240 --> 00:00:24,380 Now before I go into this and finish up with the PIMS sparse mode section, 5 00:00:24,380 --> 00:00:28,460 which will take us a few hours to do, let me give you a disclaimer. 6 00:00:28,460 --> 00:00:34,900 PIMS sparse mode is a very complex topic, a very complex protocol. 7 00:00:34,900 --> 00:00:40,440 This class is not designed to cover every nitty gritty little detail and 8 00:00:40,440 --> 00:00:45,160 flag and timer and state machine of PIMS sparse mode. 9 00:00:45,160 --> 00:00:48,680 I am going to get pretty deep, but there are a few things that you'll 10 00:00:48,680 --> 00:00:52,060 find in the RFC that I'm not going to cover because that would literally 11 00:00:52,060 --> 00:00:57,240 take probably three full days just to cover everything about PIMS sparse 12 00:00:57,240 --> 00:01:02,080 mode alone. So I think what we're going to cover here should be enough 13 00:01:02,080 --> 00:01:08,820 to get you past any CCIE written or even lab questions I can think of 14 00:01:08,820 --> 00:01:10,580 on PIMS sparse mode. 15 00:01:10,580 --> 00:01:13,940 Might be one or two things that fall off the shelf that I don't cover, 16 00:01:13,940 --> 00:01:17,280 but hopefully you'll be pretty content with the level of depth that we 17 00:01:17,280 --> 00:01:22,800 do get into. So let's go ahead and go into it. 18 00:01:22,800 --> 00:01:25,780 So first of all, before I start, I want to show you what the topologies 19 00:01:25,780 --> 00:01:29,700 are that I'm going to be using as I do my various lab demonstrations and 20 00:01:29,700 --> 00:01:33,620 stuff. So in the event that you want to try to recreate any of this on 21 00:01:33,620 --> 00:01:36,280 your own, you can do so. 22 00:01:36,280 --> 00:01:40,240 So for those of you who are watching the live feed right now, if in the 23 00:01:40,240 --> 00:01:43,600 upper right corner you click on the file section, you will see that there's 24 00:01:43,600 --> 00:01:48,900 a PDF that looks like this, that has the various topologies in it that 25 00:01:48,900 --> 00:01:49,640 I'm going to be using. 26 00:01:49,640 --> 00:01:52,460 So this is actually the physical layout. 27 00:01:52,460 --> 00:01:55,840 Sorry, it looks kind of messy here, but this is the physical layout that 28 00:01:55,840 --> 00:02:01,840 I'm using. You can see I've got a total of eight routers and then a switch. 29 00:02:01,840 --> 00:02:06,160 So in part of the lab, the switch is just purely a layer two switch, and 30 00:02:06,160 --> 00:02:09,620 then in part of the lab I'm actually turning on the routing and multicast 31 00:02:09,620 --> 00:02:14,060 functionality of the switch and using it like a ninth router. 32 00:02:14,060 --> 00:02:16,020 So this is the physical topology. 33 00:02:16,020 --> 00:02:19,680 Now I've also got my laptop connected here so I can capture wire shark 34 00:02:19,680 --> 00:02:21,620 snipper traces and stuff. 35 00:02:21,620 --> 00:02:25,140 And this is actually the logical topology right here. 36 00:02:25,140 --> 00:02:26,680 So this is what we're going to build up. 37 00:02:26,680 --> 00:02:31,540 So router one is actually serving as my receiver as my laptop basically. 38 00:02:31,540 --> 00:02:35,120 Router five is the source, so that's where I'm going to be doing my multicast 39 00:02:35,120 --> 00:02:36,480 pings and stuff. 40 00:02:36,480 --> 00:02:39,900 And then primarily these four routers here in the middle are the ones 41 00:02:39,900 --> 00:02:43,500 where I'm going to be doing all of my multicast demonstrations and examples 42 00:02:43,500 --> 00:02:46,640 and things. There are a couple of additional topologies. 43 00:02:46,640 --> 00:02:51,780 For example, when we get into the auto RP and BSR section, I'll change 44 00:02:51,780 --> 00:02:54,060 over my lab topology to this. 45 00:02:54,060 --> 00:02:59,320 Same physical routers, just a different logical topology. 46 00:02:59,320 --> 00:03:03,060 Okay, so if you are watching this in the recording, let me go back to 47 00:03:03,060 --> 00:03:08,020 this. You may want to take a snapshot of this, you know, using some sort 48 00:03:08,020 --> 00:03:12,320 of snagget or any other snapshot utility so that you can refer back to 49 00:03:12,320 --> 00:03:15,380 this frequently as I am talking about it. 50 00:03:15,380 --> 00:03:18,080 And for those of you watching live, I'd recommend that you open up that 51 00:03:18,080 --> 00:03:22,180 PDF and keep this in front of you at all times. 52 00:03:22,180 --> 00:03:26,420 Okay, and I've also created a whiteboard of that exact same topology, 53 00:03:26,420 --> 00:03:29,820 which is right here. 54 00:03:29,820 --> 00:03:34,140 So I can draw on this and talk about what's going on as we do it. 55 00:03:34,140 --> 00:03:36,400 So that being the case. 56 00:03:36,400 --> 00:03:38,620 Let's talk about PIM. 57 00:03:38,620 --> 00:03:43,280 So PIM, as I mentioned, stands for protocol independent multicast. 58 00:03:43,280 --> 00:03:45,800 Now I already mentioned the reason why they call it protocol independent 59 00:03:45,800 --> 00:03:51,280 is because just like all other multicast routing protocols, it does RPF 60 00:03:51,280 --> 00:03:55,180 checks on the source address of any multicast that come in. 61 00:03:55,180 --> 00:04:00,000 And protocol independent means PIM doesn't care where it finds a matching 62 00:04:00,000 --> 00:04:03,980 route. It doesn't care if it's a rip route, an OSP or a route, even a 63 00:04:03,980 --> 00:04:07,420 static M route doesn't care as long as it can find something. 64 00:04:07,420 --> 00:04:11,900 So that's what means it's protocol independent. 65 00:04:11,900 --> 00:04:16,760 So there are two primary varieties of it, PIM dense mode, which is not 66 00:04:16,760 --> 00:04:20,480 used a whole lot because a lot of people don't like that idea of flooding 67 00:04:20,480 --> 00:04:23,540 their multicast everywhere just to prune it back. 68 00:04:23,540 --> 00:04:24,880 But that's basically what it does. 69 00:04:24,880 --> 00:04:27,700 And there's the RFC forward if you're ever curious. 70 00:04:27,700 --> 00:04:30,660 And then the one we're going to be focusing in on is PIM sparse mode, 71 00:04:30,660 --> 00:04:33,300 which is RFC 4601. 72 00:04:33,300 --> 00:04:35,820 Now that's not the original RFC. 73 00:04:35,820 --> 00:04:38,940 Actually PIM sparse mode came out a long time ago and it's gone through 74 00:04:38,940 --> 00:04:42,280 several iterations and updates of the RFC. 75 00:04:42,280 --> 00:04:45,920 But I do believe that is the most current RFC as of this recording, which 76 00:04:45,920 --> 00:04:49,660 is November 3rd, 2015. 77 00:04:49,660 --> 00:04:54,940 So what's the objective of both? 78 00:04:54,940 --> 00:04:57,920 What we've been talking about, the objective is to build that multicast 79 00:04:57,920 --> 00:05:03,260 distribution tree connecting the source to the receivers so the multicast 80 00:05:03,260 --> 00:05:08,440 can flow down. That's the whole objective behind it. 81 00:05:08,440 --> 00:05:12,180 Okay, so PIM sparse mode, there's the very original RFC, if you want to 82 00:05:12,180 --> 00:05:20,220 look that up, 2117, currently RFC 4601, and it relies on the pole model. 83 00:05:20,220 --> 00:05:22,500 So this is sort of a review of what we've talked about. 84 00:05:22,500 --> 00:05:25,880 So PIM sparse mode relies on the concept of a rendezvous point. 85 00:05:25,880 --> 00:05:29,680 That's sort of like the dating service that I had in my previous analogy. 86 00:05:29,680 --> 00:05:36,120 So when multicast flows from the rendezvous point down to wherever the 87 00:05:36,120 --> 00:05:40,440 various receivers are, we say that that's flowing down the shared tree 88 00:05:40,440 --> 00:05:44,460 or the core tree, also known as the RP tree. 89 00:05:44,460 --> 00:05:47,260 So that's three terms for the exact same thing. 90 00:05:47,260 --> 00:05:50,780 Shared tree, core tree, RP tree. 91 00:05:50,780 --> 00:05:54,040 Basically, it means the same thing as wherever receiver is, that path 92 00:05:54,040 --> 00:05:57,840 from the receiver up to the RP, that is the shared tree. 93 00:05:57,840 --> 00:06:01,780 And that's where the multicast first starts flowing. 94 00:06:01,780 --> 00:06:05,540 And then as it says, once the multicast source is discovered, once the 95 00:06:05,540 --> 00:06:08,860 routers learn what the source address is, they can switch over to the 96 00:06:08,860 --> 00:06:10,780 shortest path tree. 97 00:06:10,780 --> 00:06:14,980 Now sometimes the source path tree might actually be that exact same tree 98 00:06:14,980 --> 00:06:16,180 through the rendezvous point. 99 00:06:16,180 --> 00:06:18,500 It might be through the rendezvous point and up. 100 00:06:18,500 --> 00:06:20,920 Other times it might be something different. 101 00:06:20,920 --> 00:06:22,480 That's all based on the routing protocol. 102 00:06:22,480 --> 00:06:25,000 You know, what does your routing table say? 103 00:06:25,000 --> 00:06:28,180 It is the best way to get to that source. 104 00:06:28,180 --> 00:06:33,760 All right, so let's talk about some versions of PIM. 105 00:06:33,760 --> 00:06:39,440 So the original version of PIM was PIM version 1. 106 00:06:39,440 --> 00:06:44,540 Version 2 has been the de facto standard for a long time. 107 00:06:44,540 --> 00:06:47,220 Where are some similarities? 108 00:06:47,220 --> 00:06:50,060 Well, if you actually did a stiffer trace, the body of the PIM packets 109 00:06:50,060 --> 00:06:53,180 is identical in version 1 and version 2. 110 00:06:53,180 --> 00:06:55,840 You know, the types of messages they carry. 111 00:06:55,840 --> 00:06:57,420 The functionality is the same. 112 00:06:57,420 --> 00:07:00,720 You know, when they send the triggers for certain things is the same. 113 00:07:00,720 --> 00:07:02,700 A couple of main differences though. 114 00:07:02,700 --> 00:07:08,400 So PIM version 1 actually utilized IGMP as the transport protocol. 115 00:07:08,400 --> 00:07:12,260 So right behind the IP header, you'd have an IGMP header and then you'd 116 00:07:12,260 --> 00:07:15,320 have PIM in the body of that packet. 117 00:07:15,320 --> 00:07:19,460 But when PIM version 2 came out, that actually became its own separate 118 00:07:19,460 --> 00:07:23,560 IP protocol. And you'll see it in sniffer traces as IP protocol number 119 00:07:23,560 --> 00:07:28,520 103. So it's no longer relying on IGMP. 120 00:07:28,520 --> 00:07:32,480 The other main difference is that the feature of the PIM bootstrap router, 121 00:07:32,480 --> 00:07:35,960 which we'll get to at the end of these recordings, is only available in 122 00:07:35,960 --> 00:07:43,280 PIM version 2. That's a way of dynamically electing and discovering the 123 00:07:43,280 --> 00:07:44,560 rendezvous point. 124 00:07:44,560 --> 00:07:48,460 In most of my labs here that I'm going to do, I'm going to statically 125 00:07:48,460 --> 00:07:50,460 configure a rendezvous point. 126 00:07:50,460 --> 00:07:55,820 But auto RP and PIM BSR are two different ways where you can dynamically 127 00:07:55,820 --> 00:07:59,660 discover an RP, which a lot of people do. 128 00:07:59,660 --> 00:08:03,200 A couple of additional things. 129 00:08:03,200 --> 00:08:07,220 If you have a router that actually has the capability of doing version 130 00:08:07,220 --> 00:08:13,280 1 or version 2, because the body of the PIM packets is the same, and because 131 00:08:13,280 --> 00:08:16,280 the functionality is the same, you can actually have that router doing 132 00:08:16,280 --> 00:08:20,440 both. But you can't have both on the same interface. 133 00:08:20,440 --> 00:08:23,740 So for example, you have a router who on fast ethernet 1 is doing PIM 134 00:08:23,740 --> 00:08:28,600 version 1, and on fast ethernet 2 is doing PIM version 2, and it will 135 00:08:28,600 --> 00:08:31,440 be able to communicate back and forth. 136 00:08:31,440 --> 00:08:35,520 Most Cisco routers now though, only run PIM version 2, and they won't 137 00:08:35,520 --> 00:08:38,680 even let you change to PIM version 1. 138 00:08:38,680 --> 00:08:42,500 For example, let me give you an example. 139 00:08:42,500 --> 00:08:48,560 Here, in my lab, I'm using a really old Cisco 2500 series router as my 140 00:08:48,560 --> 00:08:51,960 terminal server, as my access server. 141 00:08:51,960 --> 00:08:55,380 And see here, what kind of software is this running? 142 00:08:55,380 --> 00:08:59,220 So this guy's running 1233A software. 143 00:08:59,220 --> 00:09:05,540 And you can see if I go into an interface, let's see here, do show IP 144 00:09:05,540 --> 00:09:13,480 interface brief, interface ethernet 0, and I type IP PIM question mark. 145 00:09:13,480 --> 00:09:15,960 You can see there's a version, right? 146 00:09:15,960 --> 00:09:21,300 IP PIM version, and then I can select, it will default to version 2, but 147 00:09:21,300 --> 00:09:23,500 I can select it back to version 1. 148 00:09:23,500 --> 00:09:27,620 But in most newer devices, for example, if I go to one of my other routers 149 00:09:27,620 --> 00:09:34,740 here, IP PIM, you'll notice that the version is not even option. 150 00:09:34,740 --> 00:09:37,140 You can't even change it back to version 1. 151 00:09:37,140 --> 00:09:43,760 So just a little note there, depending on the software you're running. 152 00:09:43,760 --> 00:09:51,220 And this guy here, in case you're wondering, is running 15.33 software. 153 00:09:51,220 --> 00:09:55,160 So I'm not sure where the cutoff was between where they completely stripped 154 00:09:55,160 --> 00:09:59,980 out PIM V1 functionality, but somewhere between 12.3 and 15.3 is when 155 00:09:59,980 --> 00:10:06,060 they got rid of it. 156 00:10:06,060 --> 00:10:13,620 All right, so PIM has some comparison, some analogies I can make to IGP 157 00:10:13,620 --> 00:10:15,060 routing protocols. 158 00:10:15,060 --> 00:10:21,520 For example, most IGP routing protocols dynamically discover neighbors, 159 00:10:21,520 --> 00:10:25,380 the ascending out multicast packets and sending out periodic hellos. 160 00:10:25,380 --> 00:10:27,300 PIM does that as well. 161 00:10:27,300 --> 00:10:33,960 PIM sends out hello packets, and this is the reserved address of 224.0113. 162 00:10:33,960 --> 00:10:37,760 And yes, if you're ever taking any Cisco test, chances are they'll probably 163 00:10:37,760 --> 00:10:42,440 expect you to have that address memorized. 164 00:10:42,440 --> 00:10:44,600 So those are PIM hello packets. 165 00:10:44,600 --> 00:10:49,380 Unlike OSPF and EIGRP, which send out their hellos pretty frequently, 166 00:10:49,380 --> 00:10:54,300 like every 5 or 10 seconds, PIM hello packets go out every 30 seconds. 167 00:10:54,300 --> 00:10:58,320 So they're not as frequent as IGP routing protocols. 168 00:10:58,320 --> 00:11:04,000 And like an IGP routing protocol, if a hello packet just suddenly stops, 169 00:11:04,000 --> 00:11:08,360 if you don't receive it, you'll declare that neighbor dead. 170 00:11:08,360 --> 00:11:12,760 And similarly, most protocols that rely on some sort of a keep alive or 171 00:11:12,760 --> 00:11:17,180 hello mechanism, usually they all file the same rule. 172 00:11:17,180 --> 00:11:21,400 After three lost keep alive or three hellos are lost, you're done. 173 00:11:21,400 --> 00:11:22,440 Your neighbor is dead. 174 00:11:22,440 --> 00:11:25,280 PIM is the same. 175 00:11:25,280 --> 00:11:28,800 And the information learned via PIM has an expiration time. 176 00:11:28,800 --> 00:11:29,760 That's also similar. 177 00:11:29,760 --> 00:11:33,360 So for example, this is similar to OSPF, right? 178 00:11:33,360 --> 00:11:39,800 So with OSPF, if I learn of an LSA within my area that's describing some 179 00:11:39,800 --> 00:11:43,340 links, that LSA is only good for one hour. 180 00:11:43,340 --> 00:11:45,440 That's the age time of that LSA. 181 00:11:45,440 --> 00:11:50,160 And if the owner of that LSA who originated it does not refresh it before 182 00:11:50,160 --> 00:11:53,440 60 minutes, before an hour, I'm going to age it out. 183 00:11:53,440 --> 00:11:54,740 PIM is sort of like that. 184 00:11:54,740 --> 00:11:59,640 When PIM dynamically discovers multicast routes or dynamically learns 185 00:11:59,640 --> 00:12:02,980 of receivers who've wanted to join, it's not going to keep that information 186 00:12:02,980 --> 00:12:06,020 forever. That stuff will age out after a while. 187 00:12:06,020 --> 00:12:08,500 As a matter of fact, the default time is about three minutes. 188 00:12:08,500 --> 00:12:14,120 Technically, it's 210 seconds, but a lot of people say three minutes. 189 00:12:14,120 --> 00:12:19,180 So PIM has a lot of mechanisms to keep the state refreshed so that won't 190 00:12:19,180 --> 00:12:24,580 happen. Now, where are some differences? 191 00:12:24,580 --> 00:12:26,240 A lot of differences. 192 00:12:26,240 --> 00:12:30,980 Number one, interior gateway protocols only care about destinations, right? 193 00:12:30,980 --> 00:12:32,700 OSPF, EIGRP, RIP. 194 00:12:32,700 --> 00:12:36,180 All they care about is where subnets live, where the destination of the 195 00:12:36,180 --> 00:12:37,940 pack is going to go to. 196 00:12:37,940 --> 00:12:41,320 PIM hears about sources and destinations. 197 00:12:41,320 --> 00:12:45,320 PIM is keeping track of both. 198 00:12:45,320 --> 00:12:46,780 So something else. 199 00:12:46,780 --> 00:12:52,040 So PIM relies on a host, which is your receiver or a source, to trigger 200 00:12:52,040 --> 00:12:55,420 any PIM information exchange. 201 00:12:55,420 --> 00:12:56,700 And this is a little bit different, right? 202 00:12:56,700 --> 00:13:00,880 Your normal IGP routing protocols, what triggers information exchange 203 00:13:00,880 --> 00:13:07,380 is if you bring an interface up and interface goes down, you add a static 204 00:13:07,380 --> 00:13:12,920 route, but it doesn't really rely on hosts or servers in order to exchange 205 00:13:12,920 --> 00:13:14,940 routes or learn of routes. 206 00:13:14,940 --> 00:13:20,380 PIM does. PIM is not going to do anything until a new receiver comes online 207 00:13:20,380 --> 00:13:23,280 or a new source comes online. 208 00:13:23,280 --> 00:13:26,200 Otherwise, PIM will just be sort of idle. 209 00:13:26,200 --> 00:13:30,560 PIM populates its own unique table called the M-route table. 210 00:13:30,560 --> 00:13:33,360 This is short for the multicast routing table. 211 00:13:33,360 --> 00:13:38,700 So we've got our unitcast routing table and our multicast routing table. 212 00:13:38,700 --> 00:13:41,300 One thing also that's very important about this, I mentioned a little 213 00:13:41,300 --> 00:13:43,880 bit earlier, but I will state it again. 214 00:13:43,880 --> 00:13:51,400 So with some routing protocols, let's say you typed into a router, no 215 00:13:51,400 --> 00:13:54,760 IP routing. You do that at the global level. 216 00:13:54,760 --> 00:13:58,740 And then you try to turn on OSPF, let's say. 217 00:13:58,740 --> 00:14:03,220 I've seen some routers that will actually allow you to enable the OSPF 218 00:14:03,220 --> 00:14:09,260 protocol. You'll see it exchange hellos, exchange LSA's, it'll populate 219 00:14:09,260 --> 00:14:13,640 the link state database, but none of that stuff will go into the routing 220 00:14:13,640 --> 00:14:18,240 table. Because if you do no IP routing, it can't populate the routing 221 00:14:18,240 --> 00:14:19,960 table. There is no routing table. 222 00:14:19,960 --> 00:14:22,320 It can't create that table. 223 00:14:22,320 --> 00:14:24,620 So all the stuff can be running in the background, but there's no place 224 00:14:24,620 --> 00:14:26,320 to put that information. 225 00:14:26,320 --> 00:14:27,720 PIM is the same. 226 00:14:27,720 --> 00:14:33,420 With PIM, you can enable PIM on your interfaces and it will learn of neighbors 227 00:14:33,420 --> 00:14:40,080 and it will send, it'll receive, IGMP membership reports and stuff, but 228 00:14:40,080 --> 00:14:45,600 it will not populate the multicast routing table with anything that's 229 00:14:45,600 --> 00:14:49,640 learned unless you enable multicast routing. 230 00:14:49,640 --> 00:14:52,940 So at the global level, the very first thing you have to type in is IP 231 00:14:52,940 --> 00:14:55,140 multicast-routing. 232 00:14:55,140 --> 00:14:57,920 Otherwise enabling PIM is useless. 233 00:14:57,920 --> 00:15:00,020 It won't do anything. 234 00:15:00,020 --> 00:15:04,680 We've already talked about how PIM performs RPF checks by default and 235 00:15:04,680 --> 00:15:06,560 it cannot work alone. 236 00:15:06,560 --> 00:15:11,260 PIM requires something to populate the unicast routing table because of 237 00:15:11,260 --> 00:15:12,940 that bullet I just mentioned. 238 00:15:12,940 --> 00:15:17,500 Can't perform an RPF check if there's no routes in the routing table to 239 00:15:17,500 --> 00:15:20,800 match what you're trying to find. 240 00:15:20,800 --> 00:15:24,480 Now you could do to static routes, but there's got to be something in 241 00:15:24,480 --> 00:15:26,740 the routing table. 242 00:15:26,740 --> 00:15:35,060 So what is the role of a PIM RP? 243 00:15:35,060 --> 00:15:36,980 So we've talked a little bit about this already. 244 00:15:36,980 --> 00:15:41,860 This is the central focus point where when a receiver joins the network 245 00:15:41,860 --> 00:15:46,160 by sending an IBIGMP membership report, that default gateway that's directly 246 00:15:46,160 --> 00:15:50,520 connected to it will send a PIM join up to the rendezvous point. 247 00:15:50,520 --> 00:15:54,360 And this builds the core tree, the shared tree, so it's ready and waiting 248 00:15:54,360 --> 00:15:56,700 for multicast to flow down it. 249 00:15:56,700 --> 00:16:02,260 Similarly, when the multicast source starts sending its multicast data, 250 00:16:02,260 --> 00:16:05,840 the router that it's directly connected to will forward that multicast 251 00:16:05,840 --> 00:16:09,560 data to the rendezvous point to complete the process to connect everything 252 00:16:09,560 --> 00:16:18,420 together. And how does a router know who the RP is? 253 00:16:18,420 --> 00:16:23,420 For our purposes, we're going to statically configure that. 254 00:16:23,420 --> 00:16:26,900 But you can also have routers dynamically determined via things like auto 255 00:16:26,900 --> 00:16:29,680 RP and the PIM bootstrap router.