1 00:00:00,000 --> 00:00:03,960 [AUDIO LOGO] 2 00:00:03,960 --> 00:00:07,930 3 00:00:07,930 --> 00:00:10,090 So now it's time to jump in and take 4 00:00:10,090 --> 00:00:12,910 a look at our PIM operational models, 5 00:00:12,910 --> 00:00:15,100 starting with dense mode. 6 00:00:15,100 --> 00:00:18,340 Now, the basic idea behind dense mode 7 00:00:18,340 --> 00:00:22,660 is the assumption is everybody on the network wants 8 00:00:22,660 --> 00:00:24,820 this multicast traffic. 9 00:00:24,820 --> 00:00:27,760 And therefore, we are going to flood the traffic 10 00:00:27,760 --> 00:00:29,060 through our network. 11 00:00:29,060 --> 00:00:33,400 And then the devices that don't want it can tell us 12 00:00:33,400 --> 00:00:34,510 that they don't want it. 13 00:00:34,510 --> 00:00:36,700 And we will prune the traffic back 14 00:00:36,700 --> 00:00:38,600 from that part of the tree. 15 00:00:38,600 --> 00:00:40,870 So that's the basic idea. 16 00:00:40,870 --> 00:00:43,570 That also sort of makes it a little bit obvious, 17 00:00:43,570 --> 00:00:47,950 I hope, why this is also referred to as flood and prune. 18 00:00:47,950 --> 00:00:52,310 Now, while it's flooding that traffic, guess what. 19 00:00:52,310 --> 00:00:56,170 Everybody learns the S comma G entry. 20 00:00:56,170 --> 00:00:58,690 So remember one of our fundamental principles 21 00:00:58,690 --> 00:01:00,040 here with PIM. 22 00:01:00,040 --> 00:01:02,410 We need to find the source. 23 00:01:02,410 --> 00:01:04,269 Well, in the case of dense mode, we're 24 00:01:04,269 --> 00:01:07,060 going to find that source by simply flooding 25 00:01:07,060 --> 00:01:09,960 the traffic to all the routers. 26 00:01:09,960 --> 00:01:12,100 Just like that, they know the source. 27 00:01:12,100 --> 00:01:13,110 There's no secret. 28 00:01:13,110 --> 00:01:15,120 There's no magic formula. 29 00:01:15,120 --> 00:01:17,610 We simply flood the traffic everywhere. 30 00:01:17,610 --> 00:01:20,460 Everybody learns the S comma G. Those 31 00:01:20,460 --> 00:01:22,410 that want the traffic keep it. 32 00:01:22,410 --> 00:01:24,600 Those that don't prune it. 33 00:01:24,600 --> 00:01:27,090 And through the pruning process is 34 00:01:27,090 --> 00:01:29,530 how we actually form the tree. 35 00:01:29,530 --> 00:01:31,860 Now, the tree itself, of course, would just 36 00:01:31,860 --> 00:01:34,960 be everything everywhere by default. 37 00:01:34,960 --> 00:01:37,980 So by default here, all interfaces 38 00:01:37,980 --> 00:01:39,610 are going to be on the OIL. 39 00:01:39,610 --> 00:01:43,770 So let's jump into our diagram and map this out 40 00:01:43,770 --> 00:01:46,800 and take a look at how dense mode operation works. 41 00:01:46,800 --> 00:01:49,360 Now, this isn't very popular. 42 00:01:49,360 --> 00:01:51,390 However, I will point out one thing. 43 00:01:51,390 --> 00:01:55,920 One advantage that dense mode does have over sparse mode 44 00:01:55,920 --> 00:01:59,440 is it is very simple to implement. 45 00:01:59,440 --> 00:02:03,820 And from that perspective, it sort of takes care of itself. 46 00:02:03,820 --> 00:02:07,750 So we might get a lot of traffic places we don't want it. 47 00:02:07,750 --> 00:02:10,660 However, it is a very simple operation. 48 00:02:10,660 --> 00:02:13,330 So let's go ahead and jump in and take a look 49 00:02:13,330 --> 00:02:18,190 at how dense mode actually works on our network. 50 00:02:18,190 --> 00:02:20,640 So as we start our dense mode discussion, 51 00:02:20,640 --> 00:02:24,240 keep in mind that we're going to be using the same link costs 52 00:02:24,240 --> 00:02:27,250 that we used for our RPF video. 53 00:02:27,250 --> 00:02:29,590 We're just going to say that they're all a cost of 10. 54 00:02:29,590 --> 00:02:31,290 So they're all equal. 55 00:02:31,290 --> 00:02:35,910 The RPF interfaces are indicated by the red dots. 56 00:02:35,910 --> 00:02:37,590 Those are already on here. 57 00:02:37,590 --> 00:02:40,440 Now, keep in mind, the routers will calculate this 58 00:02:40,440 --> 00:02:42,240 as they get the information. 59 00:02:42,240 --> 00:02:44,370 But I've just already marked them on here. 60 00:02:44,370 --> 00:02:47,370 The OILs, or the Outbound Interface Lists, 61 00:02:47,370 --> 00:02:50,830 will indicate those interfaces as we go. 62 00:02:50,830 --> 00:02:55,980 Also, we're going to be using the source of 10.1.1.1 63 00:02:55,980 --> 00:03:02,670 with the group 224.1.1.1, making our S comma G entry 64 00:03:02,670 --> 00:03:07,980 the 10.1.1.1 comma 224.1.1.1. 65 00:03:07,980 --> 00:03:11,880 And of course, remember that one of PIM's main jobs 66 00:03:11,880 --> 00:03:14,830 is for everybody to learn the source. 67 00:03:14,830 --> 00:03:16,830 So we need to learn the source. 68 00:03:16,830 --> 00:03:19,700 And we need to build the tree. 69 00:03:19,700 --> 00:03:21,700 So let's jump in and talk about how 70 00:03:21,700 --> 00:03:24,110 dense mode accomplishes this. 71 00:03:24,110 --> 00:03:26,170 So the first thing that's going to happen 72 00:03:26,170 --> 00:03:30,580 is the source is going to start sending multicast traffic 73 00:03:30,580 --> 00:03:32,200 onto the network. 74 00:03:32,200 --> 00:03:36,730 As soon as this happens, the traffic hits router 1. 75 00:03:36,730 --> 00:03:40,270 Router 1, of course, does an RPF check. 76 00:03:40,270 --> 00:03:44,560 This is going to pass because it's a connected interface 77 00:03:44,560 --> 00:03:45,760 on router 1. 78 00:03:45,760 --> 00:03:49,360 So that's going to be a real quick, easy RPF check. 79 00:03:49,360 --> 00:03:52,330 The traffic is accepted by router 1. 80 00:03:52,330 --> 00:03:54,550 And then it's going to send it out all 81 00:03:54,550 --> 00:03:58,150 of the interfaces except the one that it arrived on, 82 00:03:58,150 --> 00:04:02,470 which means that all of these interfaces on router 1, 83 00:04:02,470 --> 00:04:06,190 to begin with, are going to be on the OIL. 84 00:04:06,190 --> 00:04:08,500 Of course, the other thing it's going to do 85 00:04:08,500 --> 00:04:13,090 is create the S comma G entry because we have now 86 00:04:13,090 --> 00:04:14,260 seen the traffic. 87 00:04:14,260 --> 00:04:16,000 We've looked at the IP headers. 88 00:04:16,000 --> 00:04:19,480 And we know the source and the group 89 00:04:19,480 --> 00:04:21,890 that this multicast is using. 90 00:04:21,890 --> 00:04:24,490 So that's what's going to happen on router 1. 91 00:04:24,490 --> 00:04:30,820 And then it forwards the traffic to router 3, to router 4, 92 00:04:30,820 --> 00:04:32,740 and to router 2. 93 00:04:32,740 --> 00:04:35,004 So let's start with router 3. 94 00:04:35,004 --> 00:04:37,450 Router 3 gets this traffic. 95 00:04:37,450 --> 00:04:41,080 It of course arrives on this interface. 96 00:04:41,080 --> 00:04:43,660 And of course, as soon as it gets the traffic, 97 00:04:43,660 --> 00:04:47,080 it's going to create an S comma G entry. 98 00:04:47,080 --> 00:04:50,470 We now know where the source and group are. 99 00:04:50,470 --> 00:04:52,960 Now that we know where the source is, 100 00:04:52,960 --> 00:04:57,910 we can do our RPF check, realize that it did in fact 101 00:04:57,910 --> 00:05:00,950 come in on the RPF interface. 102 00:05:00,950 --> 00:05:03,250 So that traffic should be accepted. 103 00:05:03,250 --> 00:05:05,890 And then we look at our OIL. 104 00:05:05,890 --> 00:05:08,530 So as we said, the default is it's going 105 00:05:08,530 --> 00:05:10,640 to send it out all interfaces. 106 00:05:10,640 --> 00:05:13,300 So it's going to send it out these two interfaces. 107 00:05:13,300 --> 00:05:16,690 And the traffic is going to get to the client 108 00:05:16,690 --> 00:05:19,900 and up to router 2. 109 00:05:19,900 --> 00:05:24,290 Now, of course, on router 2, that is not an RPF interface. 110 00:05:24,290 --> 00:05:26,870 So that traffic will be discarded. 111 00:05:26,870 --> 00:05:29,740 So when this traffic does arrive on router 2, 112 00:05:29,740 --> 00:05:33,790 it's of course going to make the S comma G entry in its table 113 00:05:33,790 --> 00:05:34,940 as well. 114 00:05:34,940 --> 00:05:37,630 And it's going to then forward the traffic 115 00:05:37,630 --> 00:05:41,650 out the interfaces on its OIL, which again, by default, is 116 00:05:41,650 --> 00:05:43,040 all of them. 117 00:05:43,040 --> 00:05:46,840 So it will then forward the traffic down to router 3. 118 00:05:46,840 --> 00:05:50,030 Of course, that's not on the RPF interface. 119 00:05:50,030 --> 00:05:51,820 So that will be discarded. 120 00:05:51,820 --> 00:05:55,150 And it will forward it down to router 4-- 121 00:05:55,150 --> 00:06:00,310 also not on the RPF interface, so also going to be discarded. 122 00:06:00,310 --> 00:06:02,500 That's what router 2 is going to do. 123 00:06:02,500 --> 00:06:05,800 When router 4 receives the flow from router 1, 124 00:06:05,800 --> 00:06:10,210 it's again going to make an S comma G entry and forward 125 00:06:10,210 --> 00:06:13,600 the traffic out all of the interfaces on its OIL. 126 00:06:13,600 --> 00:06:18,130 That would be this interface up here, this one down here, 127 00:06:18,130 --> 00:06:21,400 and the interface towards router 5. 128 00:06:21,400 --> 00:06:26,110 So the traffic going up to router 2, of course, not an RPF 129 00:06:26,110 --> 00:06:27,020 interface. 130 00:06:27,020 --> 00:06:29,600 So that traffic is going to be discarded. 131 00:06:29,600 --> 00:06:32,650 The traffic of course goes down to the client. 132 00:06:32,650 --> 00:06:37,300 And the traffic is going to show up on router 5. 133 00:06:37,300 --> 00:06:41,500 Router 5 of course makes its S comma G entry, 134 00:06:41,500 --> 00:06:44,200 does the RPF check, realizes the traffic 135 00:06:44,200 --> 00:06:45,970 arrived at the correct interface, 136 00:06:45,970 --> 00:06:50,590 and therefore forwards it out the interfaces on its OIL. 137 00:06:50,590 --> 00:06:54,420 And the traffic arrives at this client. 138 00:06:54,420 --> 00:06:58,760 So remember that PIM has two jobs on our network. 139 00:06:58,760 --> 00:07:02,610 The first is to find the source. 140 00:07:02,610 --> 00:07:04,290 Well, look at all of our routers. 141 00:07:04,290 --> 00:07:07,570 They all have an S comma G entry. 142 00:07:07,570 --> 00:07:10,020 How do they have that S comma G entry? 143 00:07:10,020 --> 00:07:12,570 Because they saw the traffic. 144 00:07:12,570 --> 00:07:16,530 Dense mode's method of getting the S comma G 145 00:07:16,530 --> 00:07:19,890 entry onto all of the routers is simply 146 00:07:19,890 --> 00:07:22,360 to flood it through the network. 147 00:07:22,360 --> 00:07:25,630 And then the routers that don't need it, 148 00:07:25,630 --> 00:07:30,450 such as router 2 in our example, will then prune that back. 149 00:07:30,450 --> 00:07:32,280 That's of course why this is also 150 00:07:32,280 --> 00:07:35,400 referred to as flood and prune. 151 00:07:35,400 --> 00:07:39,040 So let's go ahead and talk about the maintenance of the tree. 152 00:07:39,040 --> 00:07:41,790 So what happens here if we don't have 153 00:07:41,790 --> 00:07:45,210 anybody who wants the traffic, such as on router 2? 154 00:07:45,210 --> 00:07:46,840 Let's take a look. 155 00:07:46,840 --> 00:07:51,930 So how do we know that router 2 doesn't have any clients? 156 00:07:51,930 --> 00:07:53,670 Well, before we can address that, 157 00:07:53,670 --> 00:07:58,800 we almost have to talk about how routers 3, 4, and 5 know 158 00:07:58,800 --> 00:08:00,940 that they do have clients. 159 00:08:00,940 --> 00:08:03,280 One thing we haven't talked about here 160 00:08:03,280 --> 00:08:05,950 is that the clients are going to have 161 00:08:05,950 --> 00:08:10,510 to have sent an IGMP report message up 162 00:08:10,510 --> 00:08:13,870 to their last-hop router here, telling them 163 00:08:13,870 --> 00:08:17,210 that they're actually interested in this traffic. 164 00:08:17,210 --> 00:08:22,490 Now, again, the traffic will get sent at first on these devices. 165 00:08:22,490 --> 00:08:25,390 But if they don't get an IGMP report message, 166 00:08:25,390 --> 00:08:30,200 routers 3, 4, and 5 would also think they have no clients. 167 00:08:30,200 --> 00:08:33,460 So for the moment, they do, although we may address 168 00:08:33,460 --> 00:08:35,150 that in just a moment as well. 169 00:08:35,150 --> 00:08:37,210 But take a look at router 2. 170 00:08:37,210 --> 00:08:43,520 Router 2 has nobody sending an IGMP report message. 171 00:08:43,520 --> 00:08:49,960 It also has nobody sending a PIM join message. 172 00:08:49,960 --> 00:08:54,670 Now, how do we know that it's not getting an IGMP join? 173 00:08:54,670 --> 00:09:00,287 Well, it's quite simply because the interfaces on routers 3 174 00:09:00,287 --> 00:09:08,350 and 4 that are facing router 2 are not the RPF interfaces. 175 00:09:08,350 --> 00:09:12,910 Remember that PIM joins will only ever 176 00:09:12,910 --> 00:09:16,370 be sent out RPF interfaces. 177 00:09:16,370 --> 00:09:19,270 So the joins would go this way. 178 00:09:19,270 --> 00:09:22,030 Just for completeness, router 5 would have sent one 179 00:09:22,030 --> 00:09:23,600 to router 4 as well. 180 00:09:23,600 --> 00:09:26,425 And initially, router 2 would have sent a join 181 00:09:26,425 --> 00:09:28,340 to router 1 as well. 182 00:09:28,340 --> 00:09:30,310 This is the building the tree. 183 00:09:30,310 --> 00:09:34,240 But nobody sent one to router 2. 184 00:09:34,240 --> 00:09:36,260 So what happens then? 185 00:09:36,260 --> 00:09:40,000 Well, what's going to happen is all of this traffic 186 00:09:40,000 --> 00:09:41,420 is going to stop. 187 00:09:41,420 --> 00:09:44,956 This is going to be removed from the OIL on router 3 188 00:09:44,956 --> 00:09:50,180 because it didn't get a join from router 2 either. 189 00:09:50,180 --> 00:09:54,670 So for the same reasons, router 3 and router 2 190 00:09:54,670 --> 00:09:58,780 stop this traffic, remove the interfaces from the OIL 191 00:09:58,780 --> 00:10:01,750 because they have no clients, and they 192 00:10:01,750 --> 00:10:05,050 have no downstream multicast routers. 193 00:10:05,050 --> 00:10:09,040 We know this because we didn't receive a join message. 194 00:10:09,040 --> 00:10:13,150 Remember, the default is to initially flood. 195 00:10:13,150 --> 00:10:16,120 But now that we know we have no downstream routers 196 00:10:16,120 --> 00:10:18,220 and we know that we have no clients, 197 00:10:18,220 --> 00:10:20,110 we're going to prune this. 198 00:10:20,110 --> 00:10:21,970 And that's exactly what's going to happen 199 00:10:21,970 --> 00:10:26,840 on this link over here on router 4 to router 2 as well. 200 00:10:26,840 --> 00:10:29,650 So all of this gets pruned back. 201 00:10:29,650 --> 00:10:34,810 However, we still have this situation on router 2 202 00:10:34,810 --> 00:10:39,830 where it has no either downstream routers or clients. 203 00:10:39,830 --> 00:10:42,620 So far, we've just said that about a link. 204 00:10:42,620 --> 00:10:45,820 Well, we can say that about router 2, in general. 205 00:10:45,820 --> 00:10:47,890 It has no clients. 206 00:10:47,890 --> 00:10:52,340 There's no reason router 2 should be getting this traffic. 207 00:10:52,340 --> 00:10:54,970 So now what's going to happen, since it 208 00:10:54,970 --> 00:10:56,920 doesn't have any of that information, 209 00:10:56,920 --> 00:11:03,430 is we are going to change this PIM join to a prune message. 210 00:11:03,430 --> 00:11:07,660 Router 2 says to router 1, I no longer need this 211 00:11:07,660 --> 00:11:10,240 because I have no clients. 212 00:11:10,240 --> 00:11:12,880 Router 1 says, OK, you're the boss. 213 00:11:12,880 --> 00:11:15,730 If you don't need it, I won't send it. 214 00:11:15,730 --> 00:11:17,260 All of this is torn down. 215 00:11:17,260 --> 00:11:21,280 Router 1 removes that interface from its OIL. 216 00:11:21,280 --> 00:11:24,430 And now we have a steady-state tree, 217 00:11:24,430 --> 00:11:27,610 where only the traffic is going where it needs to. 218 00:11:27,610 --> 00:11:30,010 But here's the cool thing. 219 00:11:30,010 --> 00:11:35,170 Router 2 still has the S comma G entry. 220 00:11:35,170 --> 00:11:38,650 Since it still has that entry, if all 221 00:11:38,650 --> 00:11:43,270 of a sudden a client were to come on and send an IGMP report 222 00:11:43,270 --> 00:11:46,000 message, saying, yes, I do want this, 223 00:11:46,000 --> 00:11:49,330 router 2 can just go right to its S comma G entry 224 00:11:49,330 --> 00:11:54,970 and immediately send a join over to router 1, saying, hey, 225 00:11:54,970 --> 00:11:57,400 you know that traffic I pruned? 226 00:11:57,400 --> 00:12:01,030 Yeah, it turns out I actually need it because a client just 227 00:12:01,030 --> 00:12:02,460 came online. 228 00:12:02,460 --> 00:12:07,250 So the important thing here is even though router 2 has pruned 229 00:12:07,250 --> 00:12:10,550 this, it still maintains the S comma G 230 00:12:10,550 --> 00:12:14,000 entry until it times out. 231 00:12:14,000 --> 00:12:17,990 Now, as long as this source is still running, 232 00:12:17,990 --> 00:12:21,770 as long as we are still sending traffic over here, 233 00:12:21,770 --> 00:12:25,580 we need router 2 to keep this S comma G entry. 234 00:12:25,580 --> 00:12:29,570 So before it times out, what's going to happen 235 00:12:29,570 --> 00:12:33,200 is at some point, router 1 will send the traffic over 236 00:12:33,200 --> 00:12:37,220 to router 2 again, refreshing the S comma G entry. 237 00:12:37,220 --> 00:12:40,130 Of course, if router 2 still has no clients, 238 00:12:40,130 --> 00:12:41,990 it will once again prune it. 239 00:12:41,990 --> 00:12:43,970 That traffic will stop again. 240 00:12:43,970 --> 00:12:47,150 And we will maintain our steady-state tree. 241 00:12:47,150 --> 00:12:49,640 But this is how all of this operates 242 00:12:49,640 --> 00:12:51,690 in dense mode operation. 243 00:12:51,690 --> 00:12:55,040 So hopefully, it's really clear why this is 244 00:12:55,040 --> 00:12:57,590 referred to as flood and prune. 245 00:12:57,590 --> 00:13:00,080 We use flooding to build the tree. 246 00:13:00,080 --> 00:13:03,930 We use pruning to trim it back in areas we don't need it. 247 00:13:03,930 --> 00:13:07,950 And then occasionally, we flood and prune again just 248 00:13:07,950 --> 00:13:12,660 to maintain the S comma G entries on the routers. 249 00:13:12,660 --> 00:13:17,810 So in this video, we took a look at dense mode operation, 250 00:13:17,810 --> 00:13:20,570 also known as flood and prune. 251 00:13:20,570 --> 00:13:23,660 And hopefully, we can see through this entire discussion 252 00:13:23,660 --> 00:13:27,200 why it's called flood and prune because we use our flooding 253 00:13:27,200 --> 00:13:28,610 to build the tree. 254 00:13:28,610 --> 00:13:31,220 We use pruning to trim it back where 255 00:13:31,220 --> 00:13:32,750 we don't need the traffic. 256 00:13:32,750 --> 00:13:37,080 And then occasionally, we have to flood and prune again. 257 00:13:37,080 --> 00:13:42,560 This is not a very efficient model in most environments. 258 00:13:42,560 --> 00:13:46,820 The assumption here is that all the routers and all the clients 259 00:13:46,820 --> 00:13:49,020 want the multicast traffic. 260 00:13:49,020 --> 00:13:51,540 And if they don't, they'll prune it back. 261 00:13:51,540 --> 00:13:53,990 But then every once in a while-- the default's 262 00:13:53,990 --> 00:13:56,900 3 minutes-- it will flood it again. 263 00:13:56,900 --> 00:13:59,340 And we have to do this all over again. 264 00:13:59,340 --> 00:14:02,330 So again, it's not the most efficient model, 265 00:14:02,330 --> 00:14:06,200 particularly if we have a low density 266 00:14:06,200 --> 00:14:10,220 of clients who actually want a particular multicast group. 267 00:14:10,220 --> 00:14:14,250 If it was a true statement that all the computers want this, 268 00:14:14,250 --> 00:14:17,770 well, then dense mode would probably be just fine. 269 00:14:17,770 --> 00:14:20,250 But the reality is in most environments, 270 00:14:20,250 --> 00:14:22,210 that's not the case. 271 00:14:22,210 --> 00:14:25,530 We're going to have a small group of computers, clients, 272 00:14:25,530 --> 00:14:27,600 receivers, whatever we want to call them, 273 00:14:27,600 --> 00:14:30,690 that actually want to receive the multicast traffic. 274 00:14:30,690 --> 00:14:33,510 And in that situation, sparse mode 275 00:14:33,510 --> 00:14:36,492 is going to handle this far more efficiently. 276 00:14:36,492 --> 00:14:37,950 And that's exactly what we're going 277 00:14:37,950 --> 00:14:41,110 to look at in more detail coming up next. 278 00:14:41,110 --> 00:14:44,550 Until then, I hope this has been informative for you, 279 00:14:44,550 --> 00:14:47,750 and I'd like to thank you for viewing. 280 00:14:47,750 --> 00:14:51,000