1
00:00:08,600 --> 00:00:14,560
 We've seen all along that when you do
 show IPM route, it's very possible

2
00:00:14,560 --> 00:00:19,900
 that you might just have a
 star-comagee entry, right?

3
00:00:19,900 --> 00:00:23,620
 So if there's no multicast flowing
 but you've received a star-comagee

4
00:00:23,620 --> 00:00:26,640
 join, you'll have star
-comagee state.

5
00:00:26,640 --> 00:00:28,180
 And so that means I'm ready.

6
00:00:28,180 --> 00:00:30,820
 I'm waiting to forward
 this multicast traffic.

7
00:00:30,820 --> 00:00:33,960
 Somebody has asked me for it.

8
00:00:33,960 --> 00:00:38,600
 An s-comagee entry
 cannot stand alone.

9
00:00:38,600 --> 00:00:40,240
 Cannot stand alone.

10
00:00:40,240 --> 00:00:45,120
 So in other words, when router 2 here
 creates this s-comagee entry, he

11
00:00:45,120 --> 00:00:50,820
 has to also create a star
-comagee entry as well.

12
00:00:50,820 --> 00:00:53,440
 The two have to go together.

13
00:00:53,440 --> 00:00:58,060
 So even though he never got an IGMP
 membership report, even though he

14
00:00:58,060 --> 00:01:03,540
 never got a PIM star-comagee join with
 that wild card bit set, once he

15
00:01:03,540 --> 00:01:08,120
 creates an s-comagee entry, he's got
 to create a star-comagee entry as

16
00:01:08,120 --> 00:01:10,920
 well. They both have to be there.

17
00:01:10,920 --> 00:01:17,120
 So s-comagee, what analogy I sometimes
 use is think of the star-comagee

18
00:01:17,120 --> 00:01:20,860
 as being like the big brother and the
 s-comagee as being like the little

19
00:01:20,860 --> 00:01:24,660
 brother, right? The big brother who's
 15 years old, he can walk out of

20
00:01:24,660 --> 00:01:28,600
 the house and walk around the neighborhood
 and ride his bike all by himself.

21
00:01:28,600 --> 00:01:34,540
 Little brother who is the s-comagee who's
 only 7 years old, he's not allowed

22
00:01:34,540 --> 00:01:37,360
 to do that unless big
 brother goes with him.

23
00:01:37,360 --> 00:01:41,360
 So don't know if they'll help
 you or not, but there you go.

24
00:01:41,360 --> 00:01:49,140
 Also, the once traffic starts flowing
 down the shortest path, it's the

25
00:01:49,140 --> 00:01:53,040
 s-comagee entry that's used to
 actually forward that traffic.

26
00:01:53,040 --> 00:01:56,440
 So what I mean is you'll see the star
-comagee that's got some outgoing

27
00:01:56,440 --> 00:02:00,300
 interface list and you'll see the s-comagee
 that has an outgoing interface

28
00:02:00,300 --> 00:02:05,660
 list. Whatever's in the outgoing interface
 list of the s-comagee, that's

29
00:02:05,660 --> 00:02:06,940
 the important one.

30
00:02:06,940 --> 00:02:09,520
 That's what's used for actually
 forwarding the multicast.

31
00:02:09,520 --> 00:02:14,360
 When it's going down the shortest path,
 if it's going down the shared

32
00:02:14,360 --> 00:02:19,220
 path, then the star-comagee entry is
 what dictates the forwarding of the

33
00:02:19,220 --> 00:02:36,580
 traffic. A couple of additional
 things here I want to mention.

34
00:02:36,580 --> 00:02:45,620
 I don't have a whole lot of redundancy
 in this particular topology here.

35
00:02:45,620 --> 00:02:56,900
 So what if I had something
 like this?

36
00:02:56,900 --> 00:03:00,680
 Let's get rid of this
 line right here.

37
00:03:00,680 --> 00:03:16,360
 Let's say we had a switch and we had two
 neighbors, two upstream neighbors.

38
00:03:16,360 --> 00:03:23,080
 So in other words, actually it's
 not even deal with the switch.

39
00:03:23,080 --> 00:03:27,320
 Let's just put it like this.

40
00:03:27,320 --> 00:03:40,900
 Router one could either use router two
 or router four to get to the source.

41
00:03:40,900 --> 00:03:46,080
 So in this particular diagram, hopefully
 it's very clear that going through

42
00:03:46,080 --> 00:03:50,280
 the rendezvous point is not the shortest
 path because we've got four routers

43
00:03:50,280 --> 00:03:53,440
 to go through to get to the source where
 we can only go through two routers

44
00:03:53,440 --> 00:03:56,220
 if we go through router
 two or router four.

45
00:03:56,220 --> 00:03:59,480
 So the question now is, okay, when router
 one needs to open up his shortest

46
00:03:59,480 --> 00:04:03,620
 path, he's going to say, hmm, I
 have redundant shortest paths.

47
00:04:03,620 --> 00:04:07,600
 I could go via neighbor
 two or neighbor four.

48
00:04:07,600 --> 00:04:10,900
 So the question is, where
 is he going to go?

49
00:04:10,900 --> 00:04:14,260
 Where is he going to
 send his s, g join?

50
00:04:14,260 --> 00:04:18,620
 According to the specification,
 this is what you'll see.

51
00:04:18,620 --> 00:04:21,980
 It's the neighbor that has
 the highest IP address.

52
00:04:21,980 --> 00:04:24,040
 That's basically what
 it boils down to.

53
00:04:24,040 --> 00:04:29,080
 So if this was two dot two dot two dot
 two and this was two dot two dot

54
00:04:29,080 --> 00:04:36,360
 four, then that particular case, the
 s, g join would have gone via router

55
00:04:36,360 --> 00:04:42,360
 four. The neighbor with the highest
 IP address when you have redundant

56
00:04:42,360 --> 00:04:47,460
 paths. That's also the case
 in the shared tree, right?

57
00:04:47,460 --> 00:04:51,000
 If I was a router and I had multiple
 ways to get to the rendezvous point

58
00:04:51,000 --> 00:04:56,440
 and they were all the same EIGRP distance
 or all the same OSPF cost, I

59
00:04:56,440 --> 00:04:59,500
 would choose whichever PIM neighbor
 had the highest IP address.

60
00:04:59,500 --> 00:05:22,560
 That's where I would send my joins
 to get to the rendezvous point.

61
00:05:22,560 --> 00:05:26,440
 So we know that s, g stays created
 but it also must be maintained.

62
00:05:26,440 --> 00:05:30,680
 So this is no different.

63
00:05:30,680 --> 00:05:35,180
 Just like we talked about how in the
 shared tree, once it's built, every

64
00:05:35,180 --> 00:05:38,800
 minute, if I'm a router that's got a
 directly connected receiver, every

65
00:05:38,800 --> 00:05:43,980
 minute I'll send another star, g join
 upstream and so they'll go all the

66
00:05:43,980 --> 00:05:47,740
 way to keep that state refreshed
 along the way.

67
00:05:47,740 --> 00:05:51,020
 Same thing is true of
 the shortest path.

68
00:05:51,020 --> 00:05:55,740
 Every minute, every 60 seconds, routers
 who need that show us path will

69
00:05:55,740 --> 00:06:06,060
 send s, g joins upstream
 to keep it refreshed.

70
00:06:06,060 --> 00:06:09,200
 So when is that s,
 g state deleted?

71
00:06:09,200 --> 00:06:14,140
 Well, if those periodic joins from the
 downstream neighbor stop, so let's

72
00:06:14,140 --> 00:06:20,120
 say that the multicast source was behind
 me and I'm a router, you're a

73
00:06:20,120 --> 00:06:23,240
 router, and I'm your shortest
 path to get to that guy.

74
00:06:23,240 --> 00:06:26,920
 So right now, my outgoing interface
 list is pointing to you.

75
00:06:26,920 --> 00:06:31,260
 You sent me an s, g join
 indicating your interest.

76
00:06:31,260 --> 00:06:33,620
 I put you into the outgoing
 interface list.

77
00:06:33,620 --> 00:06:38,140
 So it's your responsibility every minute
 to send me s, g joins to refresh

78
00:06:38,140 --> 00:06:46,580
 this. But what if there's a switch or
 a hub in the middle of us and your

79
00:06:46,580 --> 00:06:49,900
 connection to that switch
 or hub goes down?

80
00:06:49,900 --> 00:06:52,000
 I don't know that.

81
00:06:52,000 --> 00:06:57,720
 As far as I'm concerned,
 you're still alive.

82
00:06:57,720 --> 00:07:02,300
 Well, so in that particular case, if
 the periodic joins stop, once again,

83
00:07:02,300 --> 00:07:07,340
 that timer of 210 seconds, that's the
 magic number, if after 210 seconds,

84
00:07:07,340 --> 00:07:11,980
 I'm no longer receiving those joins
 from you, then I will delete that

85
00:07:11,980 --> 00:07:13,140
 outgoing interface list.

86
00:07:13,140 --> 00:07:17,260
 Now, once again, in that particular
 situation, most likely what would

87
00:07:17,260 --> 00:07:21,160
 happen is I'd say, well, wait a second,
 I've lost my PIM neighbor, right?

88
00:07:21,160 --> 00:07:25,920
 Because in the case of PIM, you're
 also sending me PIM hellos every 30

89
00:07:25,920 --> 00:07:31,240
 seconds. And if I missed three of those,
 I declare a neighbor to be dead.

90
00:07:31,240 --> 00:07:36,680
 So one would assume that if that link
 between you and the switch went

91
00:07:36,680 --> 00:07:43,600
 down, PIM would detect the lost neighbor
 in, we saw 105 seconds, that

92
00:07:43,600 --> 00:07:50,120
 was that timer, before that
 210 second timer expired.

93
00:07:50,120 --> 00:07:55,400
 I'm not going to test
 that right now.

94
00:07:55,400 --> 00:07:58,360
 But I just want to do you know, according
 to the specification, if the

95
00:07:58,360 --> 00:08:03,880
 periodic joins stop in 210 seconds elapses,
 that's one criteria for removing

96
00:08:03,880 --> 00:08:08,960
 that interface from the
 outgoing interface list.

97
00:08:08,960 --> 00:08:15,540
 If the multicast source stops transmitting,
 once again, 210 seconds later,

98
00:08:15,540 --> 00:08:16,640
 I'll wait, right?

99
00:08:16,640 --> 00:08:20,000
 If the multicast source stops hitting
 me on the back of the head, 210

100
00:08:20,000 --> 00:08:23,000
 seconds later, I will remove
 my outgoing interfaces.

101
00:08:23,000 --> 00:08:26,780
 And that happens for every
 router down along the way.

102
00:08:26,780 --> 00:08:32,240
 So in this particular topology right here,
 if the source stops, 210 seconds

103
00:08:32,240 --> 00:08:41,820
 later, router four will remove his interface
 and router one will remove

104
00:08:41,820 --> 00:08:44,660
 his interface from the outgoing
 interface list.

105
00:08:44,660 --> 00:08:50,300
 Or if you receive a
 PIM prune message.

106
00:08:50,300 --> 00:08:54,980
 So prune message is a way of saying,
 hey, I don't want this anymore.

107
00:08:54,980 --> 00:08:59,980
 Like in this particular case, once
 router one has successfully opened

108
00:08:59,980 --> 00:09:06,260
 up his shortest path tree, he will send
 a prune message up to the rendezvous

109
00:09:06,260 --> 00:09:12,000
 point, saying, I no longer need
 this branch of the tree.

110
00:09:12,000 --> 00:09:13,340
 So we can actually see that.

111
00:09:13,340 --> 00:09:16,800
 I don't think we've actually focused
 on a prune message yet.

112
00:09:16,800 --> 00:09:19,920
 But let's go back to our
 original topology here.

113
00:09:19,920 --> 00:09:26,920
 Now I think router five at this point
 is probably done, sending his pings.

114
00:09:26,920 --> 00:09:32,900
 Yep. Okay. And if 210 seconds has elapsed,
 which it probably has, we should

115
00:09:32,900 --> 00:09:37,840
 no longer see the s, g
 state in any routers.

116
00:09:37,840 --> 00:09:41,040
 Yep, that's gone.

117
00:09:41,040 --> 00:09:46,400
 That's expired. So I'm going to go ahead
 and start it up again, the ping.

118
00:09:46,400 --> 00:09:55,500
 And what we're specifically going to
 be looking for now is once router

119
00:09:55,500 --> 00:10:04,220
 two opens up this path, we should see
 him send a PIM prune to router eight.

120
00:10:04,220 --> 00:10:06,880
 And so let's go ahead and capture that
 prune just to see what it looks

121
00:10:06,880 --> 00:10:15,780
 like. So on router eight, I want zero
 slash one is his incoming interface.

122
00:10:15,780 --> 00:10:48,100
 And according to this, that's going
 to be zero slash two on the switch.

123
00:10:48,100 --> 00:10:51,540
 Okay. So let's get ready.

124
00:10:51,540 --> 00:10:54,720
 I'll go to router five.

125
00:10:54,720 --> 00:11:13,400
 And let's start up
 the snipper trace.

126
00:11:13,400 --> 00:11:16,800
 Okay. This is probably
 the prune right here.

127
00:11:16,800 --> 00:11:22,320
 Let's find out. Yep.

128
00:11:22,320 --> 00:11:25,660
 Number of prunes one.

129
00:11:25,660 --> 00:11:29,660
 So once again, the RP bit is set, meaning
 this is going up the shared

130
00:11:29,660 --> 00:11:32,040
 tree up to the rendezvous point.

131
00:11:32,040 --> 00:11:38,280
 And we're saying I am pruning off
 this source and this group.

132
00:11:38,280 --> 00:11:43,220
 So it's the exact same message format
 as a PIM join, except instead of

133
00:11:43,220 --> 00:12:00,360
 having join, we have prune.

134
00:12:00,360 --> 00:12:04,760
 So we've already talked about how PIM
 prunes use the same format as PIM

135
00:12:04,760 --> 00:12:10,960
 joins used to encourage upstream neighbors
 to stop forwarding multicast

136
00:12:10,960 --> 00:12:17,440
 traffic to us. Now, why does it say
 encourage, why isn't it force the

137
00:12:17,440 --> 00:12:20,560
 upstream neighbor to stop forwarding
 multicast traffic to us?

138
00:12:20,560 --> 00:12:25,380
 Well, here's why.

139
00:12:25,380 --> 00:12:30,420
 If I had this type of situation where
 I had, let's say, let's just make

140
00:12:30,420 --> 00:12:48,400
 it easy, a hub. Okay.

141
00:12:48,400 --> 00:12:50,640
 Let's say this is my RP.

142
00:12:50,640 --> 00:12:55,080
 We have router one, router
 two, and router three.

143
00:12:55,080 --> 00:13:02,840
 I'll connect to the same hub.

144
00:13:02,840 --> 00:13:15,540
 Okay. Let's say that right now both of
 these PCs, PCA and PCB, are multicast

145
00:13:15,540 --> 00:13:18,900
 receivers. And they're both receiving
 the exact same group.

146
00:13:18,900 --> 00:13:23,300
 You know, they're watching the CEO's
 video presentation right now.

147
00:13:23,300 --> 00:13:25,760
 So the multicast is flowing down.

148
00:13:25,760 --> 00:13:32,200
 And in router three, we have
 both star, and state.

149
00:13:32,200 --> 00:13:50,040
 And fast ethernet zero, zero is
 in the outgoing interface list.

150
00:13:50,040 --> 00:14:00,520
 Okay. If all of a sudden receiver A
 sends an IGMP leave message because

151
00:14:00,520 --> 00:14:04,540
 he's no longer interested in that stream,
 that's going to cause router

152
00:14:04,540 --> 00:14:10,720
 one. He's going to say, okay, I'm going
 to delete this interface from

153
00:14:10,720 --> 00:14:12,400
 my outgoing interface list.

154
00:14:12,400 --> 00:14:16,360
 He's going to say, oh, I have no more
 interfaces in my outgoing interface

155
00:14:16,360 --> 00:14:19,340
 list. My outgoing interface
 list is null.

156
00:14:19,340 --> 00:14:22,380
 So that's going to cause him to say,
 all right, I don't need this anymore.

157
00:14:22,380 --> 00:14:27,180
 So he's going to send a PMPRUN message,
 which we just saw in the sniffer

158
00:14:27,180 --> 00:14:31,120
 trace. That's going
 to go into the hub.

159
00:14:31,120 --> 00:14:32,560
 Router two will see it.

160
00:14:32,560 --> 00:14:34,160
 Router three will see it.

161
00:14:34,160 --> 00:14:38,980
 Now if router three immediately removed
 this interface himself, we'd have

162
00:14:38,980 --> 00:14:44,100
 a problem. Because PCB would
 stop getting the stream.

163
00:14:44,100 --> 00:14:45,260
 And he's still interested.

164
00:14:45,260 --> 00:14:47,480
 He's a still and interested
 receiver.

165
00:14:47,480 --> 00:14:53,140
 So the way that PEM works is that in
 this particular case, when router

166
00:14:53,140 --> 00:14:57,800
 three receives this prune, he's actually
 going to wait a few seconds.

167
00:14:57,800 --> 00:15:00,980
 I think it's about five seconds,
 although don't quote me on that.

168
00:15:00,980 --> 00:15:01,560
 But it's a few seconds.

169
00:15:01,560 --> 00:15:06,360
 It's not a very long time because the
 assumption is, hey, if router two

170
00:15:06,360 --> 00:15:09,720
 also saw that prune, what's
 he going to do?

171
00:15:09,720 --> 00:15:11,420
 He's going to say, wait a second.

172
00:15:11,420 --> 00:15:14,200
 I still have somebody
 who's interested.

173
00:15:14,200 --> 00:15:19,060
 And so that will trigger him
 to send another PEM join.

174
00:15:19,060 --> 00:15:22,320
 In this particular case, they'll probably
 be an s-coma-g join because

175
00:15:22,320 --> 00:15:24,000
 he does know the source.

176
00:15:24,000 --> 00:15:27,200
 And so that will override
 the prune.

177
00:15:27,200 --> 00:15:32,180
 And so that will keep this interface
 in the outgoing interface list.

178
00:15:32,180 --> 00:15:35,520
 So that's why we say PEM prunes
 encourage the upstream neighbor.

179
00:15:35,520 --> 00:15:39,860
 Because in this particular case, router
 won't say, oh man, I send a prune,

180
00:15:39,860 --> 00:15:41,700
 but I'm still getting
 that multicast.

181
00:15:41,700 --> 00:15:43,680
 Well, there's really nothing
 he can do about that.

182
00:15:43,680 --> 00:15:47,800
 Every minute he'll continue to send
 a prune and say, hey, please prune

183
00:15:47,800 --> 00:15:52,160
 me. And router two will override that
 by sending note, keep it going,

184
00:15:52,160 --> 00:16:01,560
 keep it going. So that's
 what triggers them.

185
00:16:01,560 --> 00:16:06,840
 A PEM prune is triggered when either
 you receive some sort of a leave

186
00:16:06,840 --> 00:16:12,300
 message from your receiver or if a downstream
 interface just times out,

187
00:16:12,300 --> 00:16:16,640
 right? Maybe the receiver walks away,
 never sends a leave, and eventually

188
00:16:16,640 --> 00:16:21,220
 you, you know, IgMP times out that interface,
 that would trigger a prune

189
00:16:21,220 --> 00:16:27,280
 as well. Or if you receive a prune
 from a downstream neighbor.

190
00:16:27,280 --> 00:16:33,580
 So in this particular case, when router
 B, or when PCB, finally does decide

191
00:16:33,580 --> 00:16:37,260
 that he's done, he doesn't
 want to watch it anymore.

192
00:16:37,260 --> 00:16:44,120
 Well, that will trigger router
 two to send his prune message.

193
00:16:44,120 --> 00:16:55,300
 That will remove this interface from
 the outgoing interface list.

194
00:16:55,300 --> 00:16:58,520
 And now that router three realizes
 that his outgoing interface list is

195
00:16:58,520 --> 00:17:17,140
 null, that will trigger him to send
 his own PEM prune upstream.

196
00:17:17,140 --> 00:17:24,120
 So that pretty much concludes this section
 on talking about joining the

197
00:17:24,120 --> 00:17:25,820
 shortest path tree.

198
00:17:25,820 --> 00:17:28,580
 Oh, there was one other thing we
 want to check before I finished.

199
00:17:28,580 --> 00:17:32,400
 Let me go back. We
 want to check this.

200
00:17:32,400 --> 00:17:39,080
 We want to see, okay, when the multicast
 does start flowing down the shared

201
00:17:39,080 --> 00:17:45,860
 tree, according to the RFC, the very
 first person to switch over has to

202
00:17:45,860 --> 00:17:47,140
 be the leaf router.

203
00:17:47,140 --> 00:17:50,480
 That this intermediary router of router
 eight here, because he has no

204
00:17:50,480 --> 00:17:58,700
 connected receivers, is not allowed
 to do that switchover process.

205
00:17:58,700 --> 00:18:01,200
 So let's see if that
 is indeed true.

206
00:18:01,200 --> 00:18:02,600
 I'm sure it probably is.

207
00:18:02,600 --> 00:18:04,260
 But let's see here.

208
00:18:04,260 --> 00:18:08,040
 How are we going to test that?

209
00:18:08,040 --> 00:18:15,140
 Well, here's what I think
 is going to happen.

210
00:18:15,140 --> 00:18:21,080
 If everything goes according to how
 the RFC says it should go, then when

211
00:18:21,080 --> 00:18:25,700
 router two, the leaf router gets the
 first multicast packet, he should

212
00:18:25,700 --> 00:18:27,500
 join the shortest path tree.

213
00:18:27,500 --> 00:18:34,800
 Once that shortest path tree opens
 up, he should prune router eight.

214
00:18:34,800 --> 00:18:39,340
 Router eight should then send
 a prune or router three.

215
00:18:39,340 --> 00:18:46,900
 So in a sense, we should never see
 an S, G join originated from router

216
00:18:46,900 --> 00:18:51,860
 eight. We should see prunes originated
 from him, but we should not see

217
00:18:51,860 --> 00:18:57,540
 S, G joins originated
 with his IP address.

218
00:18:57,540 --> 00:19:00,720
 So here's how we're
 going to test that.

219
00:19:00,720 --> 00:19:06,560
 Let's just go on the switch to every
 interface that's connected to router

220
00:19:06,560 --> 00:19:12,880
 eight, which is zero two
 and zero thirteen.

221
00:19:12,880 --> 00:19:18,780
 We'll capture all inbound and outbound
 traffic, and we'll see if he ever

222
00:19:18,780 --> 00:19:24,760
 actually sends an S, G join,
 which we should not see.

223
00:19:24,760 --> 00:19:29,200
 All right, so this is done.

224
00:19:29,200 --> 00:19:35,300
 Let's clear out the MROUT
 state, show IP, MROUT.

225
00:19:35,300 --> 00:19:38,680
 Okay, so the S, G state
 has already timed out.

226
00:19:38,680 --> 00:19:42,780
 Let's go to the switch.

227
00:19:42,780 --> 00:19:46,140
 So right now we're monitoring
 zero two.

228
00:19:46,140 --> 00:20:07,200
 We want to add zero thirteen
 to that list.

229
00:20:07,200 --> 00:20:14,020
 All right, let's go
 back to router five.

230
00:20:14,020 --> 00:20:34,360
 Start our snipper trace.

231
00:20:34,360 --> 00:20:39,680
 Okay, so at this point, I'm not seeing
 the multicast go through router

232
00:20:39,680 --> 00:20:45,460
 eight anymore, because right now that's
 all I'm looking at is interfaces

233
00:20:45,460 --> 00:20:48,600
 connected to router eight, and I'm not
 seeing any of the multicast going

234
00:20:48,600 --> 00:20:52,280
 through there. It stopped
 right here.

235
00:20:52,280 --> 00:20:55,280
 So let's see here eight
 two eight two.

236
00:20:55,280 --> 00:21:02,820
 That's router two eight
 four eight eight.

237
00:21:02,820 --> 00:21:11,640
 That is router eight eight
 four eight eight.

238
00:21:11,640 --> 00:21:13,780
 Okay, so what did router
 eight send right there?

239
00:21:13,780 --> 00:21:16,300
 Router eight eight
 four eight eight.

240
00:21:16,300 --> 00:21:18,500
 He sent a prune.

241
00:21:18,500 --> 00:21:24,320
 Okay, so this is him sending a prune
 up the shared tree, and he did that

242
00:21:24,320 --> 00:21:27,240
 in response to the prune
 that he received.

243
00:21:27,240 --> 00:21:31,100
 So this is most likely the
 prune that he received.

244
00:21:31,100 --> 00:21:35,200
 So this is, yep, so this is the prune
 from router two who's connected

245
00:21:35,200 --> 00:21:39,320
 to our receiver who said, hey, look,
 neighbor eight two eight eight.

246
00:21:39,320 --> 00:21:40,980
 I don't need you anymore.

247
00:21:40,980 --> 00:21:44,400
 Let's prune off that shared
 tree between you and me.

248
00:21:44,400 --> 00:21:51,120
 And router eight forwarded that prune
 himself to the rendezvous point.

249
00:21:51,120 --> 00:22:01,720
 So sure enough, we do not see any
 join messages from router eight.

250
00:22:01,720 --> 00:22:07,480
 Here he's joining to the auto
 RP, so that doesn't count.

251
00:22:07,480 --> 00:22:14,360
 So sure enough, that confirms what the
 RFC says, that only the leaf routers

252
00:22:14,360 --> 00:22:18,320
 or last hop routers are allowed
 to join the shortest path tree.