1
00:00:07,980 --> 00:00:12,560
 In the last video, we looked in pretty
 great detail about what the process

2
00:00:12,560 --> 00:00:16,460
 is used when we're creating the shared
 tree, how the IGMPM membership

3
00:00:16,460 --> 00:00:21,780
 report received by the default gateway
 kicks off a PIM, what we call star,

4
00:00:21,780 --> 00:00:27,420
 G-join, which works its way up hop
 by hop to the rendezvous point.

5
00:00:27,420 --> 00:00:31,940
 And we saw how as that happens, each
 router from the router, the default

6
00:00:31,940 --> 00:00:35,260
 gateway who received the membership
 report, and then each router along

7
00:00:35,260 --> 00:00:39,740
 the path that receives the star, G
-join up until the rendezvous point,

8
00:00:39,740 --> 00:00:44,440
 that created what we called star, G-em
 route state in our multicast routing

9
00:00:44,440 --> 00:00:55,380
 table. So once we have that star, G
-em route state, which is, I don't

10
00:00:55,380 --> 00:00:59,080
 care what the source is, once it starts
 hitting that rendezvous point,

11
00:00:59,080 --> 00:01:03,420
 we've got an open connection, an open path,
 all the way down to the receiver.

12
00:01:03,420 --> 00:01:06,820
 And that's based on what was shown
 in the outgoing interface list.

13
00:01:06,820 --> 00:01:13,180
 Okay, so now let's actually start the
 multicast and see what happens there.

14
00:01:13,180 --> 00:01:19,800
 So the green dash line in this particular
 case indicates the shared tree

15
00:01:19,800 --> 00:01:21,140
 that's already opened.

16
00:01:21,140 --> 00:01:26,180
 Now I'm not showing R8 here, but we
 know that R8 is between these two.

17
00:01:26,180 --> 00:01:30,160
 Now the source is going to start.

18
00:01:30,160 --> 00:01:34,700
 And what we're going to see is when
 R4 receives those native multicast

19
00:01:34,700 --> 00:01:39,840
 packets from the source, he's going
 to say, huh, I got a problem here.

20
00:01:39,840 --> 00:01:46,820
 Because I'm only allowed to forward
 these native multicast packets if

21
00:01:46,820 --> 00:01:51,820
 I have some entry in my M route table
 that has an interface in the outgoing

22
00:01:51,820 --> 00:01:56,960
 interface list. But he's going to say,
 nobody's ever asked me for this.

23
00:01:56,960 --> 00:02:00,140
 I've never received any
 IGMP membership reports.

24
00:02:00,140 --> 00:02:03,060
 I've never received any
 PIM joins from anybody.

25
00:02:03,060 --> 00:02:05,820
 So I've got no place to send this.

26
00:02:05,820 --> 00:02:08,140
 And yet there might be
 receivers out there.

27
00:02:08,140 --> 00:02:09,600
 So what do I do?

28
00:02:09,600 --> 00:02:12,940
 Well, with PIM sparse mode, what he's
 going to do is he's going to take

29
00:02:12,940 --> 00:02:19,280
 that multicast packet and he's going to
 encapsulate it inside of a unicast.

30
00:02:19,280 --> 00:02:22,520
 And this is going to be
 inside of a PIM packet.

31
00:02:22,520 --> 00:02:27,300
 So there's going to be another type of
 a PIM packet called a PIM register.

32
00:02:27,300 --> 00:02:29,120
 And that's what we're
 going to look at next.

33
00:02:29,120 --> 00:02:31,640
 So the PIM register
 actually carries.

34
00:02:31,640 --> 00:02:36,600
 It's a unicast packet, unicast
 it from R4 directly to the RP.

35
00:02:36,600 --> 00:02:39,200
 So we'll see the source
 addresses R4.

36
00:02:39,200 --> 00:02:42,240
 The destination address
 is the rendezvous point.

37
00:02:42,240 --> 00:02:45,920
 The PIM type will be a new
 type called register.

38
00:02:45,920 --> 00:02:51,240
 And in the body of that will actually
 be our multicast data.

39
00:02:51,240 --> 00:02:55,840
 And when the rendezvous point gets that,
 he will de encapsulate it, revealing

40
00:02:55,840 --> 00:02:57,780
 the multicast packet.

41
00:02:57,780 --> 00:03:01,840
 And then the RP will say, okay,
 do I have state for this?

42
00:03:01,840 --> 00:03:04,020
 Has anybody ever asked
 me for this?

43
00:03:04,020 --> 00:03:07,200
 Well, in this case, you'll say yes,
 because our shared tree is already

44
00:03:07,200 --> 00:03:08,740
 ready and waiting.

45
00:03:08,740 --> 00:03:11,460
 So he'll forward that
 down the shared tree.

46
00:03:11,460 --> 00:03:15,220
 So that's how our multicast will initially
 start by registering down this

47
00:03:15,220 --> 00:03:26,920
 way. So now that could continue
 potentially indefinitely.

48
00:03:26,920 --> 00:03:28,600
 Right? I mean, it works.

49
00:03:28,600 --> 00:03:31,640
 It gets the multicast from
 the source to the receiver.

50
00:03:31,640 --> 00:03:38,240
 But it's asking that router connected
 to the source and the RP to work

51
00:03:38,240 --> 00:03:42,940
 a little extra hard to wrap this thing
 into a unicast and to unwrap it

52
00:03:42,940 --> 00:03:45,360
 from the unicast on the other end.

53
00:03:45,360 --> 00:03:50,440
 So although it works, it's consuming
 a little bit more CPU resources.

54
00:03:50,440 --> 00:03:54,040
 And certainly if we had dozens or hundreds
 of multicast streams doing

55
00:03:54,040 --> 00:04:05,320
 this, that might potentially be bad
 on the RP who's multicast inside.

56
00:04:05,320 --> 00:04:08,500
 So what's going to happen?

57
00:04:08,500 --> 00:04:13,940
 And we'll see this in the next segment
 in more detail, is when the rendezvous

58
00:04:13,940 --> 00:04:18,400
 point gets this pin register packet,
 he's actually going to do a couple

59
00:04:18,400 --> 00:04:20,260
 of things simultaneously.

60
00:04:20,260 --> 00:04:23,640
 Number one, he's going to unwrap it,
 forward it down the shared tree.

61
00:04:23,640 --> 00:04:25,320
 We already talked about that.

62
00:04:25,320 --> 00:04:36,140
 Next thing the rendezvous point is this
 multicast in its pure native form.

63
00:04:36,140 --> 00:04:38,600
 So I can just forward it
 according to my m-route.

64
00:04:38,600 --> 00:04:41,700
 So I don't have to keep pestering
 my CPU with it.

65
00:04:41,700 --> 00:04:43,000
 See, how do I do that?

66
00:04:43,000 --> 00:04:46,540
 Well, I know that my upstream neighbor
 is only going to forward it to

67
00:04:46,540 --> 00:04:48,980
 me if I ask him for it.

68
00:04:48,980 --> 00:04:53,160
 So the RP will actually send a
 join message to his neighbor.

69
00:04:53,160 --> 00:04:57,560
 But this is not a star-comedy join because
 he actually knows the source.

70
00:04:57,560 --> 00:05:01,040
 When this first multicast comes in,
 he says, oh, I know who the source

71
00:05:01,040 --> 00:05:07,240
 is, 4.5.4.5. So he's going to send
 what's called an S, G join.

72
00:05:07,240 --> 00:05:11,280
 When we see in the snipper trace, it's
 the exact same format as a star

73
00:05:11,280 --> 00:05:15,600
-comedy join, except it lists the source
 address in there and a couple

74
00:05:15,600 --> 00:05:17,800
 of the flags are different
 as well.

75
00:05:17,800 --> 00:05:24,440
 And that opens up the shortest path
 tree from the rendezvous point to

76
00:05:24,440 --> 00:05:29,120
 the source. Because remember, we talked
 about how there's potentially

77
00:05:29,120 --> 00:05:32,080
 multiple shared trees, right?

78
00:05:32,080 --> 00:05:35,240
 If I'm a rendezvous point and there's
 50 different receivers spread out

79
00:05:35,240 --> 00:05:38,940
 through the network, there could
 be 50 different shared trees.

80
00:05:38,940 --> 00:05:44,020
 Well, similarly, the concept of a shortest
 path tree is from an individual

81
00:05:44,020 --> 00:05:45,880
 router's perspective.

82
00:05:45,880 --> 00:05:49,700
 My shortest path to get to that source
 is a router might be different

83
00:05:49,700 --> 00:05:54,700
 than your shortest path to get
 to that very same source.

84
00:05:54,700 --> 00:05:57,360
 So the rendezvous point, when he gets
 this register packet, he's going

85
00:05:57,360 --> 00:06:02,820
 to say, I want to open up my shortest
 path to get to that source.

86
00:06:02,820 --> 00:06:06,140
 Because once it's open, these
 registers will stop.

87
00:06:06,140 --> 00:06:09,900
 I'll start getting the pure multicast
 in its native form.

88
00:06:09,900 --> 00:06:15,180
 So as soon as the register comes in,
 in addition to forwarding it down

89
00:06:15,180 --> 00:06:23,900
 this way, this RP is going to send, let
 me expand this a little bit, he's

90
00:06:23,900 --> 00:06:34,200
 going to send an s,
 G join upstream.

91
00:06:34,200 --> 00:06:39,960
 And that will, in R4, that will add
 fast e-sign at zero, zero into his

92
00:06:39,960 --> 00:06:42,320
 outgoing interface list.

93
00:06:42,320 --> 00:06:45,600
 Now our four will say, Oh, great.

94
00:06:45,600 --> 00:06:50,200
 Okay, now I can start forwarding the
 multicast downstream in its pure

95
00:06:50,200 --> 00:06:55,180
 native form. But guess what, he's
 going to keep registering.

96
00:06:55,180 --> 00:06:59,540
 So now we're going to get two copies
 of these multicast packets on the

97
00:06:59,540 --> 00:07:03,400
 RP. We're going to get the native
 multicast coming down.

98
00:07:03,400 --> 00:07:08,560
 And we're going to get another copy of
 that inside this pin register packet.

99
00:07:08,560 --> 00:07:14,380
 Now you might say, why
 did that happen?

100
00:07:14,380 --> 00:07:18,360
 Why does an R4 just
 stop at that point?

101
00:07:18,360 --> 00:07:20,600
 Well, here's why.

102
00:07:20,600 --> 00:07:24,600
 In this particular topology, it doesn't
 really describe it very well.

103
00:07:24,600 --> 00:07:40,480
 But imagine if I had this.

104
00:07:40,480 --> 00:07:44,140
 Okay, so imagine if, you
 know, here's my source.

105
00:07:44,140 --> 00:08:00,640
 Okay, and we've got router X,
 and we've got the PIM RP.

106
00:08:00,640 --> 00:08:02,740
 And this is router five.

107
00:08:02,740 --> 00:08:08,800
 Okay, so here my source is sending
 its multicast to router five.

108
00:08:08,800 --> 00:08:13,700
 Router five is then taking that
 multicast and registering it.

109
00:08:13,700 --> 00:08:20,020
 See if I can sort of draw something
 here to indicate that.

110
00:08:20,020 --> 00:08:23,060
 So that's the registration.

111
00:08:23,060 --> 00:08:34,020
 And now router five
 gets an s, g join.

112
00:08:34,020 --> 00:08:38,940
 So the source is, let's see here,
 what's the guy's source?

113
00:08:38,940 --> 00:08:41,740
 4.5.4.5 in my particular example.

114
00:08:41,740 --> 00:08:45,280
 So he says, okay, here
 is a PIM join.

115
00:08:45,280 --> 00:08:51,320
 And it'll actually list the
 source and the group.

116
00:08:51,320 --> 00:09:06,140
 Okay, well, when this comes in, if
 there was, how do I phrase this?

117
00:09:06,140 --> 00:09:08,960
 Actually, here's a better example.

118
00:09:08,960 --> 00:09:16,180
 Put a router right
 here in the middle.

119
00:09:16,180 --> 00:09:21,680
 Okay, so these PIM messages all
 have a time to live of one.

120
00:09:21,680 --> 00:09:26,020
 Right, we saw how the PIM star comma
 g join went out to the same multicast

121
00:09:26,020 --> 00:09:30,200
 address as the hello, 2240013.

122
00:09:30,200 --> 00:09:33,360
 Now I didn't really point it out in
 the sniffer trace, but just like the

123
00:09:33,360 --> 00:09:44,720
 PIM hello has a time to live of one,
 PIM joins and let's say his address

124
00:09:44,720 --> 00:09:55,220
 is 55555. When the PIM join is going
 right here, in the actual IP header,

125
00:09:55,220 --> 00:10:01,160
 the source is going to be
 coming from that guy.

126
00:10:01,160 --> 00:10:06,060
 And the destination is
 going to be like that.

127
00:10:06,060 --> 00:10:09,120
 Well, actually it's going
 to be the router.

128
00:10:09,120 --> 00:10:11,820
 This guy right here, 4.5.4.4.

129
00:10:11,820 --> 00:10:18,040
 Let's just say that, let's just say
 he's router 4 to make it simple.

130
00:10:18,040 --> 00:10:24,100
 So there's not necessarily any way
 for router 4 to know that this join

131
00:10:24,100 --> 00:10:28,800
 actually originated at the
 RP because it's hop by hop.

132
00:10:28,800 --> 00:10:43,360
 When the RP first sent it, the RP sent
 it to router Z because he s comma

133
00:10:43,360 --> 00:10:48,720
 g join had the same
 information in it.

134
00:10:48,720 --> 00:10:51,700
 Source was 4.5.4.5.

135
00:10:51,700 --> 00:10:56,500
 Group was 239.999.

136
00:10:56,500 --> 00:11:04,380
 And the packet here had an IP source
 of the RP and the destination of

137
00:11:04,380 --> 00:11:12,800
 router 4. Let's put
 this right here.

138
00:11:12,800 --> 00:11:18,440
 Actually, no, it had destination of
 router Z because it's hop by hop.

139
00:11:18,440 --> 00:11:22,540
 It's one hop only.

140
00:11:22,540 --> 00:11:27,040
 IP source is RP.

141
00:11:27,040 --> 00:11:32,480
 Destination equals router Z.

142
00:11:32,480 --> 00:11:36,820
 So he sent this s comma g join because
 the RP said, okay, I know who the

143
00:11:36,820 --> 00:11:44,580
 source is. My next top
 neighbor is router Z.

144
00:11:44,580 --> 00:11:49,440
 So I'm going to send a PIM s comma
 g join to that neighbor saying, hey

145
00:11:49,440 --> 00:11:52,140
 neighbor, can you open
 up this path for me?

146
00:11:52,140 --> 00:11:55,660
 Then when router Z gets it,
 he does the same thing.

147
00:11:55,660 --> 00:11:59,660
 He says, my sure is path to
 the source is router 4.

148
00:11:59,660 --> 00:12:04,360
 So I'm going to create a PIM s comma
 g join and send it to router 4.

149
00:12:04,360 --> 00:12:07,520
 So that opens up as it goes
 along the path here.

150
00:12:07,520 --> 00:12:11,120
 This interface is opened up in
 the outgoing interface list.

151
00:12:11,120 --> 00:12:14,460
 This interface is opened up in
 the outgoing interface list.

152
00:12:14,460 --> 00:12:19,600
 But when router 4 gets this, he has
 no idea that the reason he's getting

153
00:12:19,600 --> 00:12:23,600
 it is because the RP
 started the process.

154
00:12:23,600 --> 00:12:27,120
 All he knows is he got an s
 comma g join for router Z.

155
00:12:27,120 --> 00:12:32,080
 He has no idea why router
 Z sent that to him.

156
00:12:32,080 --> 00:12:36,360
 Only this router Z got it,
 that router Z initiated it.

157
00:12:36,360 --> 00:12:41,400
 So he says, well, router Z sent me
 this s comma g join, but I'm in the

158
00:12:41,400 --> 00:12:43,120
 process of registering.

159
00:12:43,120 --> 00:12:44,780
 The two are totally different.

160
00:12:44,780 --> 00:12:48,700
 Just because one guy sent me a join doesn't
 mean I should stop the registration

161
00:12:48,700 --> 00:12:51,300
 process with another guy.

162
00:12:51,300 --> 00:12:54,380
 I'm still going to keep on registering
 because I haven't heard from the

163
00:12:54,380 --> 00:13:05,700
 RP yet. All I've heard from is router
 Z, the RP would get two copies of

164
00:13:05,700 --> 00:13:06,900
 the same packet.

165
00:13:06,900 --> 00:13:09,880
 When the multicast packet starts flowing
 down, it'll flow down natively

166
00:13:09,880 --> 00:13:15,240
 from 4 to Z to RP because this
 path has now been opened up.

167
00:13:15,240 --> 00:13:19,240
 And at the same time, when router 4 got
 that multicast packet, he created

168
00:13:19,240 --> 00:13:25,240
 a copy of it and it encapsulated it
 in unicast and unicasted it directly

169
00:13:25,240 --> 00:13:31,700
 to the RP. So now the RP says,
 huh, okay, great news.

170
00:13:31,700 --> 00:13:37,400
 I just received the real multicast packet
 in its pure native form on my

171
00:13:37,400 --> 00:13:38,840
 shortest path tree.

172
00:13:38,840 --> 00:13:42,160
 I now know that my shortest
 path to the source is open.

173
00:13:42,160 --> 00:13:44,340
 It's flowing. It's working.

174
00:13:44,340 --> 00:13:47,240
 He says, I don't need these
 register messages anymore.

175
00:13:47,240 --> 00:13:50,380
 That's making me work
 harder than I need to.

176
00:13:50,380 --> 00:14:00,520
 So the RP will actually send what's
 called a PIM register stop message

177
00:14:00,520 --> 00:14:05,060
 to router 4. That's what
 router 4 is looking for.

178
00:14:05,060 --> 00:14:09,820
 That will cause him to actually
 stop the registration process.

179
00:14:09,820 --> 00:14:14,320
 So I know that in this diagram,
 it wasn't entirely clear.

180
00:14:14,320 --> 00:14:22,400
 You might have said, okay, well, when
 the app is going to stop the register,

181
00:14:22,400 --> 00:14:23,860
 I want to show you no.

182
00:14:23,860 --> 00:14:28,920
 That's not. The registration will keep
 going until the RP explicitly says,

183
00:14:28,920 --> 00:14:32,900
 please stop. I don't want to
 see these registers anymore.

184
00:14:32,900 --> 00:14:40,100
 So he uses a register stop
 message to switch over.

185
00:14:40,100 --> 00:14:44,780
 Actually, he doesn't use it to switch
 over to his shortest path tree.

186
00:14:44,780 --> 00:14:50,500
 He does it after his shortest path
 tree has already been open.

187
00:14:50,500 --> 00:15:05,720
 So actually, I'm willing
 to change that.

188
00:15:05,720 --> 00:15:10,380
 There, the RP uses register stop messages
 after its shortest path tree

189
00:15:10,380 --> 00:15:17,480
 is confirmed and open.

190
00:15:17,480 --> 00:15:20,320
 So that is the PIM registration
 process.

191
00:15:20,320 --> 00:15:26,420
 So let's go ahead and take a look
 at that and see how that works.

192
00:15:26,420 --> 00:15:32,340
 So I think right now, our shared
 tree is currently open.

193
00:15:32,340 --> 00:15:35,280
 Let's just confirm, let's go to router
 3 to RP and make sure he still

194
00:15:35,280 --> 00:15:46,720
 has a star, entry.

195
00:15:46,720 --> 00:15:48,680
 Oh, okay, he doesn't.

196
00:15:48,680 --> 00:15:53,640
 Let's go back to our source,
 our receiver here.

197
00:15:53,640 --> 00:16:11,540
 Okay, that's why, because
 he's not joined the group.

198
00:16:11,540 --> 00:16:14,500
 Okay, so now we should have it.

199
00:16:14,500 --> 00:16:23,440
 Okay, so there is our star, entry.

200
00:16:23,440 --> 00:16:27,680
 And also, as far as these timers are
 concerned, this timer here is like

201
00:16:27,680 --> 00:16:28,900
 the lifetime of this.

202
00:16:28,900 --> 00:16:30,620
 This will keep counting down.

203
00:16:30,620 --> 00:16:35,240
 And if this ever counts down to zero,
 that means I'm going to remove this

204
00:16:35,240 --> 00:16:38,580
 interface from the outgoing
 interface list.

205
00:16:38,580 --> 00:16:43,640
 But we know that as long as that receiver
 is still active, as long as

206
00:16:43,640 --> 00:16:48,120
 there's still queries going out and
 reports going back, router 2 every

207
00:16:48,120 --> 00:16:54,420
 60 seconds, we'll send another star,
 join up here to refresh that state.

208
00:16:54,420 --> 00:16:59,720
 And router 8 will also sit when he
 gets that, we'll send his own star,

209
00:16:59,720 --> 00:17:02,780
 join to refresh that state.

210
00:17:02,780 --> 00:17:12,280
 So for example, right
 now we're down to 233.

211
00:17:12,280 --> 00:17:14,080
 And it's back up.

212
00:17:14,080 --> 00:17:19,580
 See, so we started at three
 minutes and 23 seconds.

213
00:17:19,580 --> 00:17:24,520
 And we went down to
 about a minute.

214
00:17:24,520 --> 00:17:27,980
 And then we didn't see it, but in the
 background, he received a star,

215
00:17:27,980 --> 00:17:31,500
 how much he joined a refresh,
 and it went back up to this.

216
00:17:31,500 --> 00:17:38,740
 This here, this timer, is how long
 this interface in total has been in

217
00:17:38,740 --> 00:17:40,220
 the outgoing interface list.

218
00:17:40,220 --> 00:17:44,100
 So it's been a minute and four seconds
 since we very first received our

219
00:17:44,100 --> 00:17:51,160
 first star, join which caused this m
-route entry to be created originally.

220
00:17:51,160 --> 00:17:53,940
 So this time we'll just
 keep increasing.