1
00:00:08,080 --> 00:00:12,180
 So at this point we're pretty much
 done with the theory of PIMS sparse

2
00:00:12,180 --> 00:00:16,320
 mode and before we move into the concepts
 of dynamically discovering RPs

3
00:00:16,320 --> 00:00:21,540
 via auto-RP or the PIM bootstrap router,
 just want to finish up this topic

4
00:00:21,540 --> 00:00:25,000
 of PIMS sparse mode by going
 back to the commands.

5
00:00:25,000 --> 00:00:27,820
 Some of the commands you've already
 seen as I've talked about them and

6
00:00:27,820 --> 00:00:31,180
 displayed them in the lab and some
 of the commands will be new to you.

7
00:00:31,180 --> 00:00:34,340
 I just wanted to show you the most familiar
 ones that you're most likely

8
00:00:34,340 --> 00:00:43,200
 to use. Okay so verifying that
 PIMS sparse mode is working.

9
00:00:43,200 --> 00:00:45,460
 Certainly you can do show
 IP PIM interface.

10
00:00:45,460 --> 00:00:51,680
 I'm going to do each one of
 these as we go along here.

11
00:00:51,680 --> 00:01:01,280
 So show IP PIM interface and as you
 can see it shows you the address of

12
00:01:01,280 --> 00:01:06,580
 your interface. So in this case 454,
 that's actually the address of our

13
00:01:06,580 --> 00:01:08,460
 fours interface.

14
00:01:08,460 --> 00:01:13,380
 So this is confirming basically that
 PIMS is enabled on these interfaces

15
00:01:13,380 --> 00:01:14,780
 with these IP addresses.

16
00:01:14,780 --> 00:01:19,320
 I also shows you what version of PIMS,
 whether you're in sparse or dense

17
00:01:19,320 --> 00:01:24,160
 mode. There's also a mode called sparse
 dense and we'll talk about that

18
00:01:24,160 --> 00:01:27,760
 next when we talk about auto-RP.

19
00:01:27,760 --> 00:01:30,520
 How many neighbors
 you've got if any?

20
00:01:30,520 --> 00:01:36,060
 How often you're sending out PIM Hello
 packets which they call queries

21
00:01:36,060 --> 00:01:40,580
 here. The priority of the designated
 router which is one by default and

22
00:01:40,580 --> 00:01:42,220
 who is the designated router.

23
00:01:42,220 --> 00:01:45,860
 And some interfaces don't need it like
 point-to-point interfaces like

24
00:01:45,860 --> 00:01:50,420
 HDLC and PPP. There is no need for
 a designated router on that kind of

25
00:01:50,420 --> 00:02:03,940
 an interface. Show IP PIM neighbor
 gives you a little bit more detail.

26
00:02:03,940 --> 00:02:07,760
 Namely what you're getting out of
 this one here are these timers.

27
00:02:07,760 --> 00:02:09,980
 How long in total have
 I been neighbors?

28
00:02:09,980 --> 00:02:13,620
 So with this particular neighbor it's been
 almost 22 hours I've been neighbors

29
00:02:13,620 --> 00:02:21,760
 with this guy. And this is showing you
 okay if I lose a Hello, if I don't

30
00:02:21,760 --> 00:02:25,560
 continue getting PIM Hello's in one
 minute and 37 seconds I'm going to

31
00:02:25,560 --> 00:02:27,720
 tear down that neighborship.

32
00:02:27,720 --> 00:02:33,800
 Then we also have show IP PIM RP.

33
00:02:33,800 --> 00:02:39,460
 Now this particular command
 show IP PIM RP.

34
00:02:39,460 --> 00:02:46,220
 This command is really only useful
 if you statically configured an RP

35
00:02:46,220 --> 00:02:48,500
 like I've done up to this point.

36
00:02:48,500 --> 00:02:53,100
 Basically it just confirms that you
 have indeed statically configured

37
00:02:53,100 --> 00:02:59,560
 an RP and what particular groups
 that RP is servicing right now.

38
00:02:59,560 --> 00:03:04,020
 In this case it says expires never
 because it's never going to expire.

39
00:03:04,020 --> 00:03:05,280
 It's a static RP.

40
00:03:05,280 --> 00:03:10,440
 There's no mechanism here to verify
 that the RP actually exists and is

41
00:03:10,440 --> 00:03:16,280
 reachable. This next command
 show IP PIM RP mapping.

42
00:03:16,280 --> 00:03:19,620
 This is really if you're going to be
 using some sort of dynamic discovery

43
00:03:19,620 --> 00:03:24,020
 of the RP like auto RP or PIM BSR.

44
00:03:24,020 --> 00:03:26,560
 This is the command you're going to
 want to use to verify that you've

45
00:03:26,560 --> 00:03:30,920
 actually dynamically learned of an
 RP and what particular groups that

46
00:03:30,920 --> 00:03:32,380
 RP is servicing.

47
00:03:32,380 --> 00:03:39,120
 In this particular case there's
 not a lot of output here.

48
00:03:39,120 --> 00:03:45,040
 It says static, who the RP is and he's
 the RP for every single group but

49
00:03:45,040 --> 00:03:48,880
 you get a lot more output from this
 if we had dynamically learned it via

50
00:03:48,880 --> 00:03:55,360
 auto RP or BSR. We'll look at that coming
 up in the next set of videos.

51
00:03:55,360 --> 00:04:00,660
 Okay, there's some ways to
 modify the behavior of PIM.

52
00:04:00,660 --> 00:04:03,540
 IP PIM accept-register.

53
00:04:03,540 --> 00:04:09,520
 So what this is talking about is by
 default the rendezvous point will

54
00:04:09,520 --> 00:04:12,960
 accept any kind of register message
 that comes in from anybody.

55
00:04:12,960 --> 00:04:16,900
 There's no authorized list of routers
 out there that are authorized to

56
00:04:16,900 --> 00:04:21,040
 register. Any router can register which
 certainly could introduce the

57
00:04:21,040 --> 00:04:22,320
 concept of a rogue router.

58
00:04:22,320 --> 00:04:25,760
 Maybe somebody puts a rogue router
 into the network and intentionally

59
00:04:25,760 --> 00:04:32,440
 hammers the PIM RP with this gobs of
 register messages in an intentional

60
00:04:32,440 --> 00:04:36,240
 attempt to bring down the RP.

61
00:04:36,240 --> 00:04:40,220
 So in this particular command here you
 could say well only RP's, the only,

62
00:04:40,220 --> 00:04:47,420
 yeah, RP only routers connected to sources
 that match this list are actually

63
00:04:47,420 --> 00:04:49,340
 allowed to register with me.

64
00:04:49,340 --> 00:04:52,980
 So if a register comes in from any other
 router you'll just silently discard

65
00:04:52,980 --> 00:05:01,020
 it. IP PIM register rate-limit so if you're
 concerned about even the authorized

66
00:05:01,020 --> 00:05:06,340
 routers out there sending too many registrations,
 too many multicast sessions

67
00:05:06,340 --> 00:05:10,420
 are starting up at the same time, you
 could rate limit it using this command

68
00:05:10,420 --> 00:05:12,300
 here with bits per second.

69
00:05:12,300 --> 00:05:16,100
 IP PIM register-source.

70
00:05:16,100 --> 00:05:19,140
 Now this is a command that you would
 actually do on any router that's

71
00:05:19,140 --> 00:05:22,700
 going to be originating
 the register message.

72
00:05:22,700 --> 00:05:27,780
 Now normally a router when it says okay
 I need to register with the RP.

73
00:05:27,780 --> 00:05:30,700
 What that router will do is he'll go
 into his routing table, he'll do

74
00:05:30,700 --> 00:05:34,960
 an RPF look up and he'll say okay, what's
 the interface I would use, what's

75
00:05:34,960 --> 00:05:39,460
 actually the incoming interface that
 I'd use to get back to the RP?

76
00:05:39,460 --> 00:05:43,540
 He says oh according to my routing table
 my best route to the RP is fast

77
00:05:43,540 --> 00:05:48,180
 Ethernet 00. Well at that point he would
 pull that IP address from fast

78
00:05:48,180 --> 00:05:53,920
 Ethernet 00 and use that as the source
 address for his register messages.

79
00:05:53,920 --> 00:05:57,740
 There may be some scenarios where
 you don't want him to do that.

80
00:05:57,740 --> 00:06:01,700
 That regardless of what interface he
 uses to get to the RP, maybe you

81
00:06:01,700 --> 00:06:05,400
 always want him to use his loop
 back as his source address.

82
00:06:05,400 --> 00:06:12,660
 Well this would be the command that you
 would use to modify that behavior.

83
00:06:12,660 --> 00:06:16,300
 IP PIM, SPT Threshold, not going to talk
 about that, we've already covered

84
00:06:16,300 --> 00:06:21,480
 that I think in quite a lot of detail
 in some of the other videos.

85
00:06:21,480 --> 00:06:27,940
 And IP PIMs sparse
 SG-expiry-timer.

86
00:06:27,940 --> 00:06:38,780
 So what's this talking about?

87
00:06:38,780 --> 00:06:43,740
 It doesn't stay there forever, it has
 to be refreshed, and there's a couple

88
00:06:43,740 --> 00:06:45,600
 of things that could refresh it.

89
00:06:45,600 --> 00:06:50,260
 Every time an actual multicast packet
 arrives that matches that s-coma

90
00:06:50,260 --> 00:06:53,420
-g entry that refreshes the state.

91
00:06:53,420 --> 00:06:58,600
 Or if we know also know that routers,
 even after they've joined the shortest

92
00:06:58,600 --> 00:07:03,940
 path tree, if they still want that multicast,
 they will periodically once

93
00:07:03,940 --> 00:07:08,900
 a minute send out another s-coma-g
 join to refresh the tree, and that

94
00:07:08,900 --> 00:07:13,920
 will also refresh s-coma-g state in
 any router that receives that kind

95
00:07:13,920 --> 00:07:17,480
 of a join. So if that doesn't happen,
 if a router's sitting here with

96
00:07:17,480 --> 00:07:21,960
 an s-coma-g entry and let's say the multicast
 stops, well by default after

97
00:07:21,960 --> 00:07:26,180
 a little bit over three minutes after
 210 seconds that s-coma-g entry

98
00:07:26,180 --> 00:07:28,940
 will vanish, it'll go away.

99
00:07:28,940 --> 00:07:33,660
 Well, maybe you've got some scenario
 where you say, you know what?

100
00:07:33,660 --> 00:07:39,180
 Once the s-coma-g's are created in
 my router, I want it to stay there

101
00:07:39,180 --> 00:07:43,120
 for a long time, even if I
 stop getting the multicast.

102
00:07:43,120 --> 00:07:46,380
 I just don't want to have to keep recreating
 the s-coma-g over and over

103
00:07:46,380 --> 00:07:49,480
 again. I can't really think off the
 top of my head why you'd want to do

104
00:07:49,480 --> 00:07:52,140
 that, but this command would actually
 allow you to do that.

105
00:07:52,140 --> 00:07:54,240
 So that's what this
 is talking about.

106
00:07:54,240 --> 00:08:00,640
 If you set this command to its maximum,
 which is 57,600 seconds, that's

107
00:08:00,640 --> 00:08:02,620
 equal to 16 hours.

108
00:08:02,620 --> 00:08:06,660
 So basically what that's saying is, okay
 once an s-coma-g entry is created,

109
00:08:06,660 --> 00:08:11,440
 even if it's not refreshed, just keep
 it in there for up to 16 hours before

110
00:08:11,440 --> 00:08:16,520
 you expire it. So if you have a situation
 where that would be useful to

111
00:08:16,520 --> 00:08:19,840
 you, that's where that
 command would help.

112
00:08:19,840 --> 00:08:25,480
 And then the last command
 here is IPPIM NBMA-mode.

113
00:08:25,480 --> 00:08:27,040
 So imagine this scenario.

114
00:08:27,040 --> 00:08:29,680
 Actually, let me just go ahead
 and draw it here for a moment.

115
00:08:29,680 --> 00:08:34,220
 Let's say we had a WAN.

116
00:08:34,220 --> 00:08:37,560
 I'll just use frame relay as an example
 because frame relay is used a

117
00:08:37,560 --> 00:08:41,500
 lot on the CCNA and the CCNP.

118
00:08:41,500 --> 00:08:47,120
 And on this WAN we've got
 a hub and spoke scenario.

119
00:08:47,120 --> 00:08:56,240
 Where we've got router A as the hub
 and router B and C as the spokes.

120
00:08:56,240 --> 00:09:04,160
 Okay, so the only way that B and C can
 talk to each other is via router

121
00:09:04,160 --> 00:09:09,320
 A. They don't actually have any frame
 relay PVCs directly to each other.

122
00:09:09,320 --> 00:09:12,200
 Well, we know that like in the case of
 routing protocols, if we were talking

123
00:09:12,200 --> 00:09:17,260
 about OSPF or EIGRP or something, a
 lot of routing protocols, if router

124
00:09:17,260 --> 00:09:22,540
 B, and let's just say that on router
 A, his physical serial interface

125
00:09:22,540 --> 00:09:25,960
 is doing everything.

126
00:09:25,960 --> 00:09:29,320
 Okay, so our IP address is here.

127
00:09:29,320 --> 00:09:30,840
 We don't have any sub-interfaces.

128
00:09:30,840 --> 00:09:32,720
 This is a multi-point interface.

129
00:09:32,720 --> 00:09:38,360
 This is a non-broadcast,
 multi-axis interface.

130
00:09:38,360 --> 00:09:41,300
 Well, in this particular scenario with
 routing protocols, a lot of times

131
00:09:41,300 --> 00:09:43,540
 you'd have to disable
 split horizon, right?

132
00:09:43,540 --> 00:09:45,900
 Because split horizon is the rule that
 says, look, if a routing update

133
00:09:45,900 --> 00:09:50,940
 comes in on serial 0-0, in order to
 prevent routing loops, you are not

134
00:09:50,940 --> 00:09:55,180
 allowed to turn around and reflect
 that route right back out the exact

135
00:09:55,180 --> 00:09:57,620
 same interface where it came in.

136
00:09:57,620 --> 00:10:00,160
 So you'd have to, that split
 horizon prevents that.

137
00:10:00,160 --> 00:10:02,560
 So you'd have to turn
 off split horizon.

138
00:10:02,560 --> 00:10:05,560
 Well, the same kind of thing
 happens here for multicasts.

139
00:10:05,560 --> 00:10:12,600
 And for joins and things like that,
 if a multicast comes in right here,

140
00:10:12,600 --> 00:10:18,460
 or remember, the general rule of PIMS
 says that the incoming interface

141
00:10:18,460 --> 00:10:22,040
 cannot show up in the outgoing
 interface list.

142
00:10:22,040 --> 00:10:26,040
 Well, if that rule was true, then when
 this interface, when the multicast

143
00:10:26,040 --> 00:10:30,240
 came in here on serial 0-0, we would
 not be able to put that exact same

144
00:10:30,240 --> 00:10:34,220
 interface into the outgoing interface
 list, and router C would not be

145
00:10:34,220 --> 00:10:35,900
 able to get that multicast.

146
00:10:35,900 --> 00:10:40,680
 So, in order to allow that, you would
 want to use this command right here

147
00:10:40,680 --> 00:10:44,220
 on that non-broadcast,
 multi-access interface.

148
00:10:44,220 --> 00:10:49,340
 So this is basically sort of like turning
 off split horizon, but for multicast

149
00:10:49,340 --> 00:10:52,240
 traffic. That's what
 that command does.

150
00:10:52,240 --> 00:10:58,140
 And just want to finish up here a little
 bit by just explaining a little

151
00:10:58,140 --> 00:11:01,780
 bit more about the flags that you
 might see in your M route entries.

152
00:11:01,780 --> 00:11:05,080
 We've talked about a lot of these, but
 some of them I have not covered.

153
00:11:05,080 --> 00:11:07,960
 So the C flag. We
 talked about that.

154
00:11:07,960 --> 00:11:11,400
 If you see the C flag, that
 means one of two things.

155
00:11:11,400 --> 00:11:15,660
 Either this router has actually received
 an IGMP membership report, or

156
00:11:15,660 --> 00:11:20,680
 an MLDP listener report, meaning it's
 directly connected to a receiver,

157
00:11:20,680 --> 00:11:22,540
 to a laptop, to a PC.

158
00:11:22,540 --> 00:11:28,540
 Or it's actually gotten the multicast
 packet, and it realizes the source

159
00:11:28,540 --> 00:11:31,340
 of that multicast is directly
 connected to that router.

160
00:11:31,340 --> 00:11:34,140
 So there's a connected receiver
 or a connected source.

161
00:11:34,140 --> 00:11:36,920
 That's what C means.

162
00:11:36,920 --> 00:11:41,460
 The L flag haven't really talked about
 this, but knows how in my particular

163
00:11:41,460 --> 00:11:46,320
 lab, what I did is I took a router,
 router one, and I used that command,

164
00:11:46,320 --> 00:11:49,620
 IGMP join-group on that router.

165
00:11:49,620 --> 00:11:54,440
 And that's how I turned that router into
 a receiver, because routers don't

166
00:11:54,440 --> 00:11:56,400
 normally send out membership
 reports.

167
00:11:56,400 --> 00:11:59,040
 That's the job of laptops and PCs.

168
00:11:59,040 --> 00:12:03,540
 So in order to replicate that
 behavior, I used this command.

169
00:12:03,540 --> 00:12:08,080
 Well, if that router was also running
 PIM, which it's not, then in the

170
00:12:08,080 --> 00:12:12,240
 M-ROT entry it would have had the L
 flag, meaning I'm also a receiver

171
00:12:12,240 --> 00:12:13,160
 of this multicast.

172
00:12:13,160 --> 00:12:15,760
 When the multicast comes in, I'm
 not just going to forward it.

173
00:12:15,760 --> 00:12:18,820
 I'm actually going to send it to my
 CPU for processing, because I want

174
00:12:18,820 --> 00:12:23,740
 to see it. The F flag.

175
00:12:23,740 --> 00:12:27,980
 So this is called the
 PIM register flag.

176
00:12:27,980 --> 00:12:30,580
 Sometimes people get a little bit confused
 on this, because they see the

177
00:12:30,580 --> 00:12:35,060
 F, and they think, oh, that means that
 registration is happening right

178
00:12:35,060 --> 00:12:39,960
 now. And then they do show IPM route,
 show IPM route, they keep doing

179
00:12:39,960 --> 00:12:43,760
 it, and for the next 30-40 seconds, minute
-5 minutes, the F flag is still

180
00:12:43,760 --> 00:12:46,480
 there. And they say,
 oh, I have a problem.

181
00:12:46,480 --> 00:12:50,680
 Registration should only happen for
 a second or two, and then it should

182
00:12:50,680 --> 00:12:54,140
 stop. Why am I still
 seeing the F flag?

183
00:12:54,140 --> 00:12:59,000
 Well, if you actually are in the process
 of registering right now when

184
00:12:59,000 --> 00:13:03,200
 you do this command, you'll actually
 see in the star, G entry the word

185
00:13:03,200 --> 00:13:05,180
 registering. It'll say that.

186
00:13:05,180 --> 00:13:08,300
 So you have the F flag, and
 it'll say, registering.

187
00:13:08,300 --> 00:13:12,400
 Like it says here, if you only see the
 F flag, but you don't see the word

188
00:13:12,400 --> 00:13:17,720
 registering, that means this router
 previously registered this flow.

189
00:13:17,720 --> 00:13:22,000
 It's just sort of like a historical marker
 saying, I successfully registered

190
00:13:22,000 --> 00:13:25,340
 it in the past, but not
 doing that anymore.

191
00:13:25,340 --> 00:13:29,340
 That's what the F flag would mean.

192
00:13:29,340 --> 00:13:35,260
 The J flag. So this means a router has
 attempted to join the respective

193
00:13:35,260 --> 00:13:41,580
 tree. So for example, if you see the
 J flag in the star, G output, you

194
00:13:41,580 --> 00:13:44,760
 might be tempted to think, and I think
 I actually misspoke on this in

195
00:13:44,760 --> 00:13:45,340
 a previous video.

196
00:13:45,340 --> 00:13:48,280
 I think I said, well, when you see
 the J flag, that means this router

197
00:13:48,280 --> 00:13:53,160
 has sent a PIM join up that tree.

198
00:13:53,160 --> 00:13:54,700
 Well, not necessarily.

199
00:13:54,700 --> 00:13:59,400
 What the J flag really means is the
 router wants to join that tree.

200
00:13:59,400 --> 00:14:04,540
 It's not really proof that
 a join actually went out.

201
00:14:04,540 --> 00:14:08,840
 So for example, if you see the J flag
 in the star, G output, that means,

202
00:14:08,840 --> 00:14:14,620
 okay, the router, something triggered
 the router to believe that it needs

203
00:14:14,620 --> 00:14:16,960
 to join the tree.

204
00:14:16,960 --> 00:14:22,200
 And so it needs to create a star, G join
 and send it up that tree towards

205
00:14:22,200 --> 00:14:23,380
 the rendezvous point.

206
00:14:23,380 --> 00:14:25,760
 Now, did it actually
 succeed in that?

207
00:14:25,760 --> 00:14:27,460
 Maybe, maybe not.

208
00:14:27,460 --> 00:14:31,420
 We don't know. The J flag just says
 it knew that it needed to do that.

209
00:14:31,420 --> 00:14:34,700
 Like in one of my previous labs that
 I was doing, if I go back to the

210
00:14:34,700 --> 00:14:41,400
 drawing here for a second,
 let's bring this over here.

211
00:14:41,400 --> 00:14:48,020
 So I had one lab, if you recall, is several
 videos ago where I had forgotten

212
00:14:48,020 --> 00:14:53,080
 to configure PIM on this interface
 right here on R4.

213
00:14:53,080 --> 00:14:57,480
 There was no PIM on here.

214
00:14:57,480 --> 00:15:01,540
 And yet there was PIM on
 this interface of R2.

215
00:15:01,540 --> 00:15:06,800
 And what I noticed was when the multicast
 started flowing down, this guy

216
00:15:06,800 --> 00:15:08,640
 created an S, G, E, and R2.

217
00:15:08,640 --> 00:15:11,720
 And it was the entry for it.

218
00:15:11,720 --> 00:15:16,860
 And it listed serial 010 as
 the incoming interface.

219
00:15:16,860 --> 00:15:20,080
 It said, okay, if the multicast comes
 down the shortest path tree, it

220
00:15:20,080 --> 00:15:22,340
 should come in the serial.

221
00:15:22,340 --> 00:15:25,680
 And it had the J flag.

222
00:15:25,680 --> 00:15:29,840
 And I initially thought, okay, well,
 that means that he sent a join up

223
00:15:29,840 --> 00:15:33,380
 there. But if you remember that video,
 I said, huh, something's missing.

224
00:15:33,380 --> 00:15:40,700
 If multicast traffic is actually really
 flowing down the shortest path

225
00:15:40,700 --> 00:15:45,980
 tree, in addition to the J flag,
 I should also see the T flag.

226
00:15:45,980 --> 00:15:48,820
 And that's the next bullet point
 that's coming up in the slide.

227
00:15:48,820 --> 00:15:54,040
 The T flag indicates I have actually received
 at least one multicast packet

228
00:15:54,040 --> 00:15:56,660
 down the shortest path tree.

229
00:15:56,660 --> 00:15:58,160
 So it's working.

230
00:15:58,160 --> 00:15:58,980
 But I didn't see that.

231
00:15:58,980 --> 00:16:05,280
 In my particular case, all I saw
 was the J flag and not the T.

232
00:16:05,280 --> 00:16:09,180
 And that made me think, okay, so he tried
 to join this tree, but multicast

233
00:16:09,180 --> 00:16:10,300
 isn't flowing down it yet.

234
00:16:10,300 --> 00:16:11,200
 What's going on?

235
00:16:11,200 --> 00:16:15,680
 And that's when I found out that PIM
 was not configured on router 4.

236
00:16:15,680 --> 00:16:21,400
 So I assumed that router 2 had sent
 out his join, but nothing happened

237
00:16:21,400 --> 00:16:24,660
 because on the other side, the
 router couldn't process it.

238
00:16:24,660 --> 00:16:26,560
 But I actually did a little
 bit of debugging.

239
00:16:26,560 --> 00:16:31,380
 It turns out that he realized he
 did not have a PIM neighbor.

240
00:16:31,380 --> 00:16:35,620
 Router 2 realized that even though he
 had PIM on his serial, he had not

241
00:16:35,620 --> 00:16:38,960
 learned of a neighbor on the
 other end of the serial.

242
00:16:38,960 --> 00:16:42,560
 And so when I did a debug, I realized
 that he didn't even create the join

243
00:16:42,560 --> 00:16:45,540
 in the first place because he was smart
 enough to realize, hey, what's

244
00:16:45,540 --> 00:16:50,140
 the point of creating an S-coma G join
 in sending out this link if there's

245
00:16:50,140 --> 00:16:54,280
 nobody at the other end of the link
 to even receive it and process it?

246
00:16:54,280 --> 00:16:58,820
 So that's why I say that J flag simply
 means he wants to join that branch

247
00:16:58,820 --> 00:17:03,840
 of the tree, but whether or not he actually
 succeeded in sending a join,

248
00:17:03,840 --> 00:17:05,900
 you can't tell just by that flag.

249
00:17:05,900 --> 00:17:10,000
 You'd have to do a little bit more
 troubleshooting to figure that out.

250
00:17:10,000 --> 00:17:15,180
 And then, like I said, lastly, we have
 the T flag, which is that's what

251
00:17:15,180 --> 00:17:16,200
 you want to see, right?

252
00:17:16,200 --> 00:17:19,240
 If the T flag is on the shortest
 path three, that's good.

253
00:17:19,240 --> 00:17:22,780
 That means I've actually received at
 least one multicast data packet on

254
00:17:22,780 --> 00:17:24,220
 the shortest path three.

255
00:17:24,220 --> 00:17:29,560
 There's one other flag I want to
 talk about, which is the R flag.

256
00:17:29,560 --> 00:17:31,760
 And this one sort of confused
 me a little bit.

257
00:17:31,760 --> 00:17:34,980
 I had to dig into the RFC and really
 think about it a little bit.

258
00:17:34,980 --> 00:17:43,600
 So the R flag is, you will see this
 only on routers in the shared tree.

259
00:17:43,600 --> 00:17:48,600
 So if you think about the path from
 the leaf router up to the RP, it's

260
00:17:48,600 --> 00:17:56,900
 only somewhere on that path that you'll
 see in a S, G entry, the R flag.

261
00:17:56,900 --> 00:17:58,340
 Now, what's that meaning?

262
00:17:58,340 --> 00:18:01,500
 Let's go back to this
 for a second.

263
00:18:01,500 --> 00:18:12,020
 This one. Okay, so we know that initially,
 once the multicast, if we know

264
00:18:12,020 --> 00:18:17,100
 that this guy is the RP right
 here, oops, what is that?

265
00:18:17,100 --> 00:18:24,440
 Okay. Once the multicast starts flowing
 down here from the RP, it's going

266
00:18:24,440 --> 00:18:27,640
 to go this way, and then it's going
 to go this way, and then it's going

267
00:18:27,640 --> 00:18:32,820
 to go this way. So in router eight
 right here, I'm focusing on him for

268
00:18:32,820 --> 00:18:37,260
 the moment. When he actually gets that
 multicast traffic, he's going to

269
00:18:37,260 --> 00:18:42,980
 have both the star, G, which
 he created a long time ago.

270
00:18:42,980 --> 00:18:45,700
 And then when you see that multicast
 packet, he's going to create an S,

271
00:18:45,700 --> 00:18:52,680
 G as well. And this particular case,
 the outgoing interface list of the

272
00:18:52,680 --> 00:18:58,180
 S, G is going to be fast
 Ethernet zero slash one.

273
00:18:58,180 --> 00:19:00,240
 Okay, good to go.

274
00:19:00,240 --> 00:19:02,780
 But we also know that as soon as router
 two, the leaf router gets that

275
00:19:02,780 --> 00:19:07,220
 very first multicast packet, he's going
 to try to switch over to the shortest

276
00:19:07,220 --> 00:19:12,320
 path tree. And if we assume that he's
 successful, and now he's receiving

277
00:19:12,320 --> 00:19:17,680
 traffic down the SPT, well then we know
 that he's going to send a prune

278
00:19:17,680 --> 00:19:23,300
 message. He's going to send
 what's called an S, G prune.

279
00:19:23,300 --> 00:19:28,500
 And what's that going
 to look like?

280
00:19:28,500 --> 00:19:32,600
 Well, in the body of that prune packet,
 it's going to have the source,

281
00:19:32,600 --> 00:19:34,860
 four dot five dot four dot five.

282
00:19:34,860 --> 00:19:37,960
 It's going to have the
 group, whatever it is.

283
00:19:37,960 --> 00:19:41,680
 And then it's also going
 to have the RP bit.

284
00:19:41,680 --> 00:19:46,160
 This is a flag, the RP bit set.

285
00:19:46,160 --> 00:19:49,100
 That's going to be set to a one.

286
00:19:49,100 --> 00:19:52,680
 And he's going to send
 that to router eight.

287
00:19:52,680 --> 00:19:57,980
 When router eight gets that, he's going
 to say, okay, this prune, because

288
00:19:57,980 --> 00:20:03,280
 it's got the RP bit, means I need
 to prune off this interface.

289
00:20:03,280 --> 00:20:07,920
 So he'll then stop forwarding
 the multicast on that link.

290
00:20:07,920 --> 00:20:14,920
 He'll remove that interface from
 the outgoing interface list.

291
00:20:14,920 --> 00:20:18,940
 And so now that's going
 to end up being null.

292
00:20:18,940 --> 00:20:22,460
 And then he's going to create his own
 prune packet and send it up this

293
00:20:22,460 --> 00:20:28,760
 way, which will then end up
 pruning this off right here.

294
00:20:28,760 --> 00:20:31,800
 So what does it have to
 do with the R flag?

295
00:20:31,800 --> 00:20:36,800
 Well, if I go into router eight's M route
 table after this has been done,

296
00:20:36,800 --> 00:20:44,840
 now we can assume that after this point
 in time, remember if an S, G state

297
00:20:44,840 --> 00:20:48,880
 has an outgoing interface list that's
 nothing, it's empty, null.

298
00:20:48,880 --> 00:20:50,560
 Well, it's got this countdown
 timer, right?

299
00:20:50,560 --> 00:20:52,440
 It's only good for 210 seconds.

300
00:20:52,440 --> 00:20:57,500
 And after 210 seconds, if nobody needs
 to use this, he's going to delete

301
00:20:57,500 --> 00:21:02,300
 it. So let's say I go on router eight
 before that time has expired.

302
00:21:02,300 --> 00:21:07,500
 So right after he's received the prune,
 but before the 210 seconds has

303
00:21:07,500 --> 00:21:13,480
 elapsed, then what I'm going to see
 in this S, G state is the letter R.

304
00:21:13,480 --> 00:21:15,220
 I'll also see a P.

305
00:21:15,220 --> 00:21:19,200
 So he'll say, actually, I think the P
 might come before the R, but basically

306
00:21:19,200 --> 00:21:22,920
 the P will say, this is pruned.

307
00:21:22,920 --> 00:21:24,340
 I'm not using this.

308
00:21:24,340 --> 00:21:25,680
 I've pruned this off.

309
00:21:25,680 --> 00:21:31,360
 And the R will say, I have pruned this
 because somebody downstream from

310
00:21:31,360 --> 00:21:37,640
 me set me an S, G prune with
 the RP bit set to a one.

311
00:21:37,640 --> 00:21:40,100
 Now you're not going to see that
 in the rendezvous point.

312
00:21:40,100 --> 00:21:44,320
 You'll all only see that in
 routers in between here.

313
00:21:44,320 --> 00:21:47,300
 So like router eight, if we had another
 router right here, we'd see it.

314
00:21:47,300 --> 00:21:49,660
 If we had another router
 right here, we'd see it.

315
00:21:49,660 --> 00:21:52,800
 But the routers in the middle who received
 the prune and have forwarded

316
00:21:52,800 --> 00:21:56,460
 it on, they will have an outgoing interface
 list of null, and they'll

317
00:21:56,460 --> 00:21:59,840
 say RP, and notice it's
 only in the S, G entry.

318
00:21:59,840 --> 00:22:04,040
 You're not going to see that in
 the star, G, only the S, G.

319
00:22:04,040 --> 00:22:08,960
 And I can actually replicate that pretty
 easily here, in case you want

320
00:22:08,960 --> 00:22:11,460
 to see it. I'll do the
 exact same thing.

321
00:22:11,460 --> 00:22:17,240
 I'll just go ahead and start the multicast
 stream from router five.

322
00:22:17,240 --> 00:22:20,480
 And by the time I get to router eight,
 like two seconds later, it will

323
00:22:20,480 --> 00:22:22,440
 already be pruned off.

324
00:22:22,440 --> 00:22:30,080
 And you'll see that he actually
 has the R flag in there.

325
00:22:30,080 --> 00:22:32,780
 Let's just do that.

326
00:22:32,780 --> 00:22:38,560
 Let's go over here to router five.

327
00:22:38,560 --> 00:22:46,680
 Let's do our ping.

328
00:22:46,680 --> 00:22:51,220
 Okay, already the stream has been switched
 over, and we can see that in

329
00:22:51,220 --> 00:22:55,640
 router two, the leaf router,
 show IPM route.

330
00:22:55,640 --> 00:23:02,240
 We can see that he's
 got the S, G entry.

331
00:23:02,240 --> 00:23:05,040
 He has joined or attempted
 to join the tree.

332
00:23:05,040 --> 00:23:06,180
 Was he successful?

333
00:23:06,180 --> 00:23:08,480
 Yes, he was successful because
 he's got the T flag.

334
00:23:08,480 --> 00:23:13,360
 He's actually receiving multicast traffic
 down the shortest path tree.

335
00:23:13,360 --> 00:23:16,880
 Now if we go to router eight, who's in
 the middle, who's no longer involved

336
00:23:16,880 --> 00:23:23,600
 in this traffic in any way, he's been
 pruned off, we can see in his S,

337
00:23:23,600 --> 00:23:29,120
 G entry, it says P, it's been pruned,
 and why was it pruned because of

338
00:23:29,120 --> 00:23:34,100
 R? Because we received a pruned message
 with the RP bit, which caused

339
00:23:34,100 --> 00:23:37,860
 our outgoing interface
 list to become no.

340
00:23:37,860 --> 00:23:42,320
 So this now is only going to be good
 for another, well, right now it says

341
00:23:42,320 --> 00:23:43,560
 two minutes and 28 seconds.

342
00:23:43,560 --> 00:23:46,760
 If I do it again, we're going
 to see it counting down.

343
00:23:46,760 --> 00:23:48,260
 Now it's only good
 for two minutes.

344
00:23:48,260 --> 00:23:53,760
 So two minutes from now, this entry will
 vanish, and then this entry will

345
00:23:53,760 --> 00:23:56,900
 also vanish as well because neither
 one of them will be needed at that