1 00:00:08,320 --> 00:00:11,100 All right, so let's see here. 2 00:00:11,100 --> 00:00:15,700 So we want to see the registration process. 3 00:00:15,700 --> 00:00:22,900 The easiest way to create multicast traffic is simply to do a multicast 4 00:00:22,900 --> 00:00:25,160 ping. And actually this will be easy. 5 00:00:25,160 --> 00:00:31,140 The reason I was hesitating is because, for example, if I did a multicast 6 00:00:31,140 --> 00:00:37,800 ping from router 4, when you initiate a multicast ping from a router, 7 00:00:37,800 --> 00:00:43,400 he will actually send out that multicast packet, that multicast ICMP packet 8 00:00:43,400 --> 00:00:48,700 on every single interface he has that has PIM enabled. 9 00:00:48,700 --> 00:00:51,420 I mean, he doesn't even bother to check M-route state or anything. 10 00:00:51,420 --> 00:00:54,160 He does copies it and sends it out every single packet. 11 00:00:54,160 --> 00:00:55,460 And I didn't want that. 12 00:00:55,460 --> 00:00:57,740 But in this case, I don't have to worry about because on router 5, he 13 00:00:57,740 --> 00:00:59,680 only has one interface anyway. 14 00:00:59,680 --> 00:01:02,340 So let's see here. 15 00:01:02,340 --> 00:01:06,300 We want to capture the... 16 00:01:06,300 --> 00:01:10,880 So this is going to be the multicast packet. 17 00:01:10,880 --> 00:01:15,540 It's going to come down this way. 18 00:01:15,540 --> 00:01:20,580 And we want to see that multicast packet as it's encapsulated in a PIM 19 00:01:20,580 --> 00:01:33,020 register. And then we also want to see as soon as the RP gets that, we 20 00:01:33,020 --> 00:01:43,240 want to see him send a PIM-S-G join to open up his shortest path. 21 00:01:43,240 --> 00:01:48,100 Then we'll see the actual multicast itself flowing down in its native 22 00:01:48,100 --> 00:01:55,740 form. And then lastly, we want to see the RP once he gets that, sending 23 00:01:55,740 --> 00:01:57,680 a PIM register stop. 24 00:01:57,680 --> 00:02:02,920 Because that's going to be the process. 25 00:02:02,920 --> 00:02:06,500 So in order to do that, let's see here. 26 00:02:06,500 --> 00:02:13,260 Why don't I just capture everything going in and out of router 3's fast 27 00:02:13,260 --> 00:02:22,740 ethernet 00. So router 3 is fast ethernet 00 is port 0 slash 5 on the 28 00:02:22,740 --> 00:02:39,740 switch. Alright, yep, 0 slash 5. 29 00:02:39,740 --> 00:02:41,140 Okay, so we should be ready. 30 00:02:41,140 --> 00:02:45,080 So let me go now to the source. 31 00:02:45,080 --> 00:02:50,440 And I think it's 999 is what I'm using. 32 00:02:50,440 --> 00:02:56,060 And I'll repeat that 100 times just to keep it going for a while. 33 00:02:56,060 --> 00:03:05,120 And let's start the sniffer trace. 34 00:03:05,120 --> 00:03:07,920 Okay, there we go. 35 00:03:07,920 --> 00:03:11,240 That was enough. 36 00:03:11,240 --> 00:03:14,600 Okay, so here is the register. 37 00:03:14,600 --> 00:03:21,020 So we don't actually see the, because I'm only capturing on, let's go 38 00:03:21,020 --> 00:03:25,280 back to this. Because I'm only capturing on data coming in and out of 39 00:03:25,280 --> 00:03:28,620 00, we didn't actually see the native multicast as it came in to router 40 00:03:28,620 --> 00:03:31,880 4. But we do see the register message. 41 00:03:31,880 --> 00:03:35,440 So here it is, PIM register. 42 00:03:35,440 --> 00:03:41,720 So this is the IP address 4545. 43 00:03:41,720 --> 00:03:44,460 Let's just check here. 44 00:03:44,460 --> 00:03:47,780 Router 4 should be doing the registering not router 5. 45 00:03:47,780 --> 00:03:52,660 Let me just check router 5 here for a second. 46 00:03:52,660 --> 00:04:00,580 Well, let's see, this is interesting, but there's an easy way to check 47 00:04:00,580 --> 00:04:05,200 this. So the source address is actually coming from the source itself 48 00:04:05,200 --> 00:04:12,680 4545. But is it really coming from him or did router 4 just shove that 49 00:04:12,680 --> 00:04:16,900 in there? Well, we can check this by checking the source MAC address of 50 00:04:16,900 --> 00:04:21,060 this frame to see who it really came from. 51 00:04:21,060 --> 00:04:28,300 So the source MAC address came from 8C B6. 52 00:04:28,300 --> 00:04:43,140 8C B6. So did that really come from FastEthernet01 and R5? 53 00:04:43,140 --> 00:04:48,440 No, it did not because he is 8E0051. 54 00:04:48,440 --> 00:04:50,840 So if we go to router 4. 55 00:04:50,840 --> 00:05:02,900 Oops, not show run, show interface. 56 00:05:02,900 --> 00:05:05,520 FastEthernet00.34. 57 00:05:05,520 --> 00:05:09,500 There we go. 8C B6. 58 00:05:09,500 --> 00:05:12,120 So this is interesting, look at this. 59 00:05:12,120 --> 00:05:18,180 So when the native multicast hit router 4, when he encapsulates that in 60 00:05:18,180 --> 00:05:22,480 a register message, hold on a second. 61 00:05:22,480 --> 00:05:25,980 I think this is a weirdness of actually, I think I remember this is a 62 00:05:25,980 --> 00:05:30,720 weirdness of wire shark, not actually the snipper. 63 00:05:30,720 --> 00:05:33,280 Yeah, here we go. 64 00:05:33,280 --> 00:05:35,780 Okay, not sure why wire shark doesn't like this. 65 00:05:35,780 --> 00:05:39,600 Up here in the main window, it says it's coming from 4.5. 66 00:05:39,600 --> 00:05:46,060 If you actually look in the body of it, here in the IP header, it is coming 67 00:05:46,060 --> 00:05:52,780 from router 4. So I'm not sure why the discrepancy here between how it 68 00:05:52,780 --> 00:05:57,020 displays it. But so here's my IP header. 69 00:05:57,020 --> 00:06:03,100 So it's coming from router 4, going to the rendezvous point, router 3, 70 00:06:03,100 --> 00:06:10,220 and then behind the IP header, is our PIM header. 71 00:06:10,220 --> 00:06:17,740 So type number 1, which is a register packet. 72 00:06:17,740 --> 00:06:25,600 And then you can see here there's just a couple of flags, and then here's 73 00:06:25,600 --> 00:06:31,360 actually the multicast packet inside of it. 74 00:06:31,360 --> 00:06:40,540 Coming from the source, going to the group, and just a couple of things 75 00:06:40,540 --> 00:06:42,480 about this in the event that you're curious. 76 00:06:42,480 --> 00:06:45,240 I'll talk about null register as the very last thing in this particular 77 00:06:45,240 --> 00:06:51,840 video. But this thing here called border, what's that all about? 78 00:06:51,840 --> 00:06:59,400 It says no. There's a feature that you can use in PIM sparse mode called 79 00:06:59,400 --> 00:07:02,920 a border router, or a PIM border router. 80 00:07:02,920 --> 00:07:07,120 That is, and honestly I'm not sure how frequently this is used in the 81 00:07:07,120 --> 00:07:12,360 real world, but for example, if I had a router, then on one side was doing 82 00:07:12,360 --> 00:07:20,420 something that's not PIM. 83 00:07:20,420 --> 00:07:23,560 So we're doing a piece and doing PIM on the other interface. 84 00:07:23,560 --> 00:07:25,960 And we want the multicast to flow through. 85 00:07:25,960 --> 00:07:29,260 That would be considered a PIM border router. 86 00:07:29,260 --> 00:07:33,180 In that particular case, if that router sent a register, that one bit 87 00:07:33,180 --> 00:07:37,800 there, that flag bit, would be set to a 1, saying that yes, he is a border 88 00:07:37,800 --> 00:07:41,440 router. But we're not doing that weird kind of thing here, so he's saying 89 00:07:41,440 --> 00:07:43,740 no, he's not a border router. 90 00:07:43,740 --> 00:07:51,420 So there's our register, pretty simple basic PIM header, and then just 91 00:07:51,420 --> 00:07:53,700 the actual multicast inside of it. 92 00:07:53,700 --> 00:08:00,140 And then according to our whiteboard, we said once that came down, the 93 00:08:00,140 --> 00:08:04,420 rendezvous point should then attempt to open up his shortest path tree 94 00:08:04,420 --> 00:08:13,000 by sending an S, G join. 95 00:08:13,000 --> 00:08:16,860 So, let's see here. 96 00:08:16,860 --> 00:08:23,580 That is probably this right here, PIM joins, let's see here. 97 00:08:23,580 --> 00:08:30,320 It's coming, the source address is coming from our rendezvous point, 343, 98 00:08:30,320 --> 00:08:31,380 that's router 3. 99 00:08:31,380 --> 00:08:40,140 It's going to the PIM address of 2240013. 100 00:08:40,140 --> 00:08:44,100 Type code 3 for join. 101 00:08:44,100 --> 00:08:49,640 Now notice, what makes this different than a star, join? 102 00:08:49,640 --> 00:08:51,400 Well, a couple of things. 103 00:08:51,400 --> 00:08:54,180 Number one, number of joins one. 104 00:08:54,180 --> 00:08:58,140 Remember we saw these flags here of SW and R? 105 00:08:58,140 --> 00:09:00,580 Well, we don't see that this time. 106 00:09:00,580 --> 00:09:07,940 The R meant the RP bit was set, meaning this particular join needed to 107 00:09:07,940 --> 00:09:09,660 go up the shared tree. 108 00:09:09,660 --> 00:09:12,300 The ultimate destination was the rendezvous point. 109 00:09:12,300 --> 00:09:14,600 Well, we don't see that here. 110 00:09:14,600 --> 00:09:17,860 The W bit was set mean the wild card bit. 111 00:09:17,860 --> 00:09:22,220 The wild card bit meant that, okay, when you look at this address, this 112 00:09:22,220 --> 00:09:24,600 address is the address of the rendezvous point. 113 00:09:24,600 --> 00:09:27,120 Well, here we don't see that. 114 00:09:27,120 --> 00:09:31,620 The wild card bit is not set, meaning that this is actually the address 115 00:09:31,620 --> 00:09:38,400 of the source. So, it looks sort of like a star, join, but only until 116 00:09:38,400 --> 00:09:41,800 you dig into the guts of it and you see what flags are here or what flags 117 00:09:41,800 --> 00:09:48,160 are not here, can you actually tell whether it's a star, or an S, join. 118 00:09:48,160 --> 00:09:50,900 And this case is an S, join. 119 00:09:50,900 --> 00:09:54,380 So he says, okay, upstream neighbor, so this is router four. 120 00:09:54,380 --> 00:10:00,780 He says, this is going to you, and I'm trying to join this source and 121 00:10:00,780 --> 00:10:12,420 this group. Okay, so there is the S, join. 122 00:10:12,420 --> 00:10:19,200 And then once that S, join is received, that should have put this sub 123 00:10:19,200 --> 00:10:24,240 -interface into the outgoing interface list of router four. 124 00:10:24,240 --> 00:10:30,820 And then the native multicast should have come down, and we should have 125 00:10:30,820 --> 00:10:35,220 received two copies of it, one in a register packet and one in the native 126 00:10:35,220 --> 00:10:36,340 multicast itself. 127 00:10:36,340 --> 00:10:37,820 So let's see if we saw that. 128 00:10:37,820 --> 00:10:48,440 So here is our join, and it looks like, okay, so right here, here is the 129 00:10:48,440 --> 00:10:52,240 native multicast, notice there's no PIM in here. 130 00:10:52,240 --> 00:10:57,320 Source is actually the source, here's the native multicast, and then right 131 00:10:57,320 --> 00:11:05,600 behind that is a PIM register. 132 00:11:05,600 --> 00:11:09,040 And here's an interesting question, are they actually the exact same packet 133 00:11:09,040 --> 00:11:14,580 copied? Well, let's see here, in the actual native multicast, in the IP 134 00:11:14,580 --> 00:11:19,960 header, we have an identification of 0, 0, 0, 1. 135 00:11:19,960 --> 00:11:24,640 Remember, normally each individual IP packet has a unique identification 136 00:11:24,640 --> 00:11:28,880 field. Let's see here, what about the register packet? 137 00:11:28,880 --> 00:11:33,740 Has the exact same ID, so yes, these are duplicates of the same packet. 138 00:11:33,740 --> 00:11:44,880 All right, and so once we saw that, then we see down here, router three, 139 00:11:44,880 --> 00:11:50,440 which is the RP saying register stop, saying I don't want registers anymore. 140 00:11:50,440 --> 00:11:57,280 So right here in the PIM body, type code two, register stop, and he says 141 00:11:57,280 --> 00:12:01,060 I'm stopping for this source and this group. 142 00:12:01,060 --> 00:12:09,840 Now there was one other field in the register that I sort of skipped over 143 00:12:09,840 --> 00:12:19,940 a flag that I didn't talk about, which was this right here, the null register 144 00:12:19,940 --> 00:12:21,320 flag, what is that? 145 00:12:21,320 --> 00:12:26,680 In this particular case, the null register is set to no, it's off, but 146 00:12:26,680 --> 00:12:32,880 when would it be on and why would we use it? 147 00:12:32,880 --> 00:12:42,260 So, let's say, let's draw something here for a moment, and we can actually 148 00:12:42,260 --> 00:12:47,280 use this as an example. 149 00:12:47,280 --> 00:12:53,780 Let's say that our receiver was down here, and initially the multicast 150 00:12:53,780 --> 00:12:58,440 flow was flowing through the shared tree through the RP, but we know that 151 00:12:58,440 --> 00:13:00,800 within a short amount of time, and we're going to look at this in the 152 00:13:00,800 --> 00:13:15,400 next section, we're going to switch over from the shared tree and the 153 00:13:15,400 --> 00:13:22,940 traffic is no longer going to the RP, this has been, oops, not that, this 154 00:13:22,940 --> 00:13:29,640 interface has been pruned off, let's just get rid of all this stuff, and 155 00:13:29,640 --> 00:13:36,100 now the traffic is flowing in its pure native form this way down the shortest 156 00:13:36,100 --> 00:13:38,580 path tree to the receiver. 157 00:13:38,580 --> 00:13:43,300 Okay, so the multicast is going, it's going, it's going, it's fine, it's 158 00:13:43,300 --> 00:13:50,280 going well. But what happens if 10, 15, 20 minutes later, this happens? 159 00:13:50,280 --> 00:13:57,600 We have another receiver who joins our topology, and he wants the exact 160 00:13:57,600 --> 00:14:02,620 same stream, so he sends an IGMP membership report. 161 00:14:02,620 --> 00:14:13,620 That kicks off a PIM star-coma-G join, which creates star-coma-G state 162 00:14:13,620 --> 00:14:19,980 in the RP, and the RP just sits here, waiting, and waiting, and waiting. 163 00:14:19,980 --> 00:14:23,500 Because after all, router Z has no reason to forward this multicast traffic 164 00:14:23,500 --> 00:14:27,300 to the RP, right, the RP pruned off this interface. 165 00:14:27,300 --> 00:14:32,140 Once the traffic starts going down the shortest path tree, we receive 166 00:14:32,140 --> 00:14:36,240 some prunes up this way, and the RP was told, hey, we don't need you anymore, 167 00:14:36,240 --> 00:14:39,040 we don't need the traffic from you. 168 00:14:39,040 --> 00:14:44,020 And when the RP heard that, he said, okay, I guess I don't need it anymore, 169 00:14:44,020 --> 00:14:48,100 nobody else wants it from me, so the RP pruned off this link. 170 00:14:48,100 --> 00:14:50,760 So that happened a long time ago. 171 00:14:50,760 --> 00:14:57,300 Now somebody is asking the RP for this traffic again, but he's not getting 172 00:14:57,300 --> 00:15:03,700 it. This is where the null register can come into play. 173 00:15:03,700 --> 00:15:10,640 So let's talk about the null register. 174 00:15:10,640 --> 00:15:15,300 So we know that after a while the RP may forget about that flow. 175 00:15:15,300 --> 00:15:17,160 It went through him originally. 176 00:15:17,160 --> 00:15:21,280 He prunes it off because he doesn't need it anymore, and he forgets about 177 00:15:21,280 --> 00:15:31,420 it. So what's going to happen here is this, the router that's connected 178 00:15:31,420 --> 00:15:35,580 to the source, router 4 says, well, I've been sending this multicast for 179 00:15:35,580 --> 00:15:40,500 a while. There's a chance that maybe the RP needs it. 180 00:15:40,500 --> 00:15:44,140 Hey, maybe somebody else wants to receive this traffic. 181 00:15:44,140 --> 00:15:47,880 Maybe I should let the RP know that it's still going. 182 00:15:47,880 --> 00:15:56,660 Well, we could take the next packet and register it with the RP. 183 00:15:56,660 --> 00:15:58,460 That would work. 184 00:15:58,460 --> 00:16:02,180 But instead the desires of PIM said, well, I don't want to keep bothering 185 00:16:02,180 --> 00:16:05,160 the RP with this registration, because maybe he's got nobody. 186 00:16:05,160 --> 00:16:09,560 Maybe nobody that he knows of actually wants this traffic. 187 00:16:09,560 --> 00:16:17,820 So instead what happens is every few seconds, router 4 sends what's called 188 00:16:17,820 --> 00:16:22,800 a null register to the rendezvous point. 189 00:16:22,800 --> 00:16:25,480 What is a null register? 190 00:16:25,480 --> 00:16:29,580 It basically looks exactly like a normal register packet, but it doesn't 191 00:16:29,580 --> 00:16:32,080 have any multicast data inside of it. 192 00:16:32,080 --> 00:16:39,140 So if we go back to our sniffer trace, a null register would say type 193 00:16:39,140 --> 00:16:51,680 1 register, and it would have information in here about the source and 194 00:16:51,680 --> 00:16:54,860 the group. But there would be no body. 195 00:16:54,860 --> 00:16:56,980 There would be no multicast data inside of it. 196 00:16:56,980 --> 00:16:58,980 It would be a much smaller packet. 197 00:16:58,980 --> 00:17:02,680 And the null register flag would be set to a 1. 198 00:17:02,680 --> 00:17:08,380 And this is the way that this router here could say, hey, RP just wants 199 00:17:08,380 --> 00:17:11,720 you to know, I still know about this flow. 200 00:17:11,720 --> 00:17:13,540 It's still going through me. 201 00:17:13,540 --> 00:17:17,420 So if you want it, you better tell me. 202 00:17:17,420 --> 00:17:21,300 And then once the router got, once the RP got that null register, he's 203 00:17:21,300 --> 00:17:22,520 saying, oh, goody, goody. 204 00:17:22,520 --> 00:17:25,460 I've been waiting to hear about that traffic, because somebody asked me 205 00:17:25,460 --> 00:17:30,380 for it. So now the RP could once again send an S-comaG join to open up 206 00:17:30,380 --> 00:17:36,520 this path, and the traffic could start flowing down this direction. 207 00:17:36,520 --> 00:17:40,880 So that's what a null register is. 208 00:17:40,880 --> 00:17:43,680 And these are sent every five seconds. 209 00:17:43,680 --> 00:17:47,120 This is called the probe time. 210 00:17:47,120 --> 00:17:51,680 So every five seconds, the router that's closest to the source, if the 211 00:17:51,680 --> 00:17:55,200 source is still going, if it's still pumping out the multicast, we'll 212 00:17:55,200 --> 00:17:58,380 send out every five seconds these null registers to the RP, just reminding 213 00:17:58,380 --> 00:18:01,720 the RP that this traffic exists. 214 00:18:01,720 --> 00:18:06,480 Because maybe during the last five seconds, a new receiver joined to the 215 00:18:06,480 --> 00:18:09,440 RP, and maybe the RP wants that traffic again.