1
00:00:00,000 --> 00:00:03,458
[AUDIO LOGO]

2
00:00:03,458 --> 00:00:07,910

3
00:00:07,910 --> 00:00:11,690
So next, let's talk about
reverse path forwarding

4
00:00:11,690 --> 00:00:13,190
in some more detail.

5
00:00:13,190 --> 00:00:16,280
Now, the idea behind
reverse path forwarding

6
00:00:16,280 --> 00:00:18,860
is we simply want to
make sure that when

7
00:00:18,860 --> 00:00:21,380
traffic arrives at
the router, it's

8
00:00:21,380 --> 00:00:23,580
on the appropriate interface.

9
00:00:23,580 --> 00:00:26,340
And what does the
appropriate interface mean?

10
00:00:26,340 --> 00:00:29,240
Well, it means the
interface that router

11
00:00:29,240 --> 00:00:33,740
would use to go back to
the source address based

12
00:00:33,740 --> 00:00:35,480
on its IGP.

13
00:00:35,480 --> 00:00:38,930
Now, the IGP here
can be anything.

14
00:00:38,930 --> 00:00:42,230
We can use OSPF, EIGRP, RIP.

15
00:00:42,230 --> 00:00:47,090
It doesn't matter what the
underlying IGP is, it simply

16
00:00:47,090 --> 00:00:51,830
looks to that to learn the
egress interface to get back

17
00:00:51,830 --> 00:00:53,120
to the source.

18
00:00:53,120 --> 00:00:57,560
If that traffic is not
arriving on the RPF interface,

19
00:00:57,560 --> 00:01:01,320
the router will discard
the multicast traffic.

20
00:01:01,320 --> 00:01:04,680
Now, we use this
for two purposes.

21
00:01:04,680 --> 00:01:07,740
The first purpose is
for loop prevention.

22
00:01:07,740 --> 00:01:10,068
And as we jump into
our discussion,

23
00:01:10,068 --> 00:01:11,610
I'll show you what
that problem would

24
00:01:11,610 --> 00:01:15,870
be if we allowed PIM to
just go unchecked and not

25
00:01:15,870 --> 00:01:17,680
do the RPF check.

26
00:01:17,680 --> 00:01:20,610
The other thing we
use it for is so

27
00:01:20,610 --> 00:01:25,440
that PIM knows which way to
send the join messages once it

28
00:01:25,440 --> 00:01:27,550
does know the source.

29
00:01:27,550 --> 00:01:30,660
Now, again, this is going
to vary a little bit how

30
00:01:30,660 --> 00:01:33,480
it's completely implemented
between sparse mode

31
00:01:33,480 --> 00:01:34,750
and dense mode.

32
00:01:34,750 --> 00:01:36,270
So once again,
this is just going

33
00:01:36,270 --> 00:01:39,150
to be discussing RPF
checks, in general.

34
00:01:39,150 --> 00:01:41,610
We'll talk about them
in a little more detail

35
00:01:41,610 --> 00:01:45,990
as we get into dense mode versus
sparse mode in our upcoming

36
00:01:45,990 --> 00:01:46,810
videos.

37
00:01:46,810 --> 00:01:49,470
So for now, let's just
jump in and take a look

38
00:01:49,470 --> 00:01:52,950
at how RPF checks work
and what their job is

39
00:01:52,950 --> 00:01:56,880
in the multicast environment.

40
00:01:56,880 --> 00:02:00,020
So let's just start off with a
quick discussion of our diagram

41
00:02:00,020 --> 00:02:00,530
here.

42
00:02:00,530 --> 00:02:05,180
First, we have a source over
here, its address is 10.1.1.1,

43
00:02:05,180 --> 00:02:07,670
although that's not going
to be incredibly important.

44
00:02:07,670 --> 00:02:10,289
But for the beginning
of our discussion,

45
00:02:10,289 --> 00:02:13,100
we're going to consider
all of the link costs

46
00:02:13,100 --> 00:02:16,910
here to be 10, which sort
of means we're either

47
00:02:16,910 --> 00:02:19,340
running OSPF or IS-IS.

48
00:02:19,340 --> 00:02:21,230
Since we're dealing
with a cost, we'll

49
00:02:21,230 --> 00:02:22,970
say that we're running OSPF.

50
00:02:22,970 --> 00:02:27,180
Once again, I will point out
that the IGP doesn't matter.

51
00:02:27,180 --> 00:02:32,210
This could be RIP and hop count,
this could be EIGRP and its

52
00:02:32,210 --> 00:02:35,690
custom metric, or
again, IS-IS, OSPF--

53
00:02:35,690 --> 00:02:38,160
the IGP doesn't matter.

54
00:02:38,160 --> 00:02:40,130
Now, as we jump
into our discussion

55
00:02:40,130 --> 00:02:41,690
here on reverse
path forwarding, we

56
00:02:41,690 --> 00:02:45,440
are sort of going to approach
this from the dense mode

57
00:02:45,440 --> 00:02:50,090
perspective because that's where
the biggest problem exists.

58
00:02:50,090 --> 00:02:52,590
Does sparse mode
still use RPF checks?

59
00:02:52,590 --> 00:02:54,630
Yes, it does.

60
00:02:54,630 --> 00:02:58,070
But not quite to the extent
that dense mode does.

61
00:02:58,070 --> 00:02:59,820
So as we're going
through this discussion,

62
00:02:59,820 --> 00:03:02,040
understand that this lends
itself a little bit more

63
00:03:02,040 --> 00:03:03,370
to dense mode.

64
00:03:03,370 --> 00:03:05,740
So let's talk
about what happens.

65
00:03:05,740 --> 00:03:10,230
Our source starts up and starts
sending multicast traffic

66
00:03:10,230 --> 00:03:12,010
onto the network.

67
00:03:12,010 --> 00:03:16,410
Now, the rule of PIM, and
again, particularly dense mode

68
00:03:16,410 --> 00:03:22,020
is that by default, all
interfaces are on the oil.

69
00:03:22,020 --> 00:03:26,970
So all interfaces, except
the interface it arrived on.

70
00:03:26,970 --> 00:03:30,580
We will forward this
multicast traffic out,

71
00:03:30,580 --> 00:03:37,230
so to say router 3, router 4,
router 2 is going to get it.

72
00:03:37,230 --> 00:03:39,010
So far so good.

73
00:03:39,010 --> 00:03:40,930
We don't have a problem yet.

74
00:03:40,930 --> 00:03:43,340
But let's take a look,
for example, at router 3.

75
00:03:43,340 --> 00:03:47,640
Router 3 takes this,
forwards it to its client,

76
00:03:47,640 --> 00:03:49,470
by the way, that's
a good thing, that's

77
00:03:49,470 --> 00:03:51,390
what we're running
multicast for.

78
00:03:51,390 --> 00:03:53,880
But here's where the
problem starts coming in--

79
00:03:53,880 --> 00:03:57,190
it now forwards it to router 2.

80
00:03:57,190 --> 00:04:02,140
OK, well, router 2 now has
two copies of the frame,

81
00:04:02,140 --> 00:04:05,140
but we'll leave that out of
the discussion even for now.

82
00:04:05,140 --> 00:04:08,140
Let's talk about the
first copy that showed up,

83
00:04:08,140 --> 00:04:11,304
router 2 would have also
sent that back to router 3.

84
00:04:11,304 --> 00:04:14,590
Router 2 would have sent
that down to router 4.

85
00:04:14,590 --> 00:04:17,390
Router 4 now got two
copies of the frame.

86
00:04:17,390 --> 00:04:19,810
Now it's going to send
a copy to router 5,

87
00:04:19,810 --> 00:04:21,250
and router 5, of
course, is going

88
00:04:21,250 --> 00:04:24,940
to send that to its client, and
all of that is perfectly fine.

89
00:04:24,940 --> 00:04:27,190
Router 4 also sends
it to its client--

90
00:04:27,190 --> 00:04:29,480
again, perfectly fine.

91
00:04:29,480 --> 00:04:32,830
But once again,
router 4 is also going

92
00:04:32,830 --> 00:04:34,990
to send it back up to router 1.

93
00:04:34,990 --> 00:04:37,060
And here's where the
problems really come in.

94
00:04:37,060 --> 00:04:39,310
I mean, you can already see
that there's loops here.

95
00:04:39,310 --> 00:04:45,085
Router 1 just got this packet,
sends it back to the source.

96
00:04:45,085 --> 00:04:46,960
Well, the source sure
as heck doesn't want it

97
00:04:46,960 --> 00:04:49,750
again, but worse yet,
goes ahead and sends

98
00:04:49,750 --> 00:04:51,850
it back over to router 2 again.

99
00:04:51,850 --> 00:04:53,950
Well, router 2 just got
it, so it goes ahead

100
00:04:53,950 --> 00:04:55,550
and sends it back
down to router 4,

101
00:04:55,550 --> 00:04:58,070
router 4 sends it back
down to its client again,

102
00:04:58,070 --> 00:04:59,780
sends it over to router 5 again.

103
00:04:59,780 --> 00:05:02,600
Router 5 sends it down
to its client again.

104
00:05:02,600 --> 00:05:05,270
Router 2 also sends it
down to router again.

105
00:05:05,270 --> 00:05:07,100
Router 3 sends it
to its client again,

106
00:05:07,100 --> 00:05:09,050
sends it back up
to router 1 again.

107
00:05:09,050 --> 00:05:11,040
I think we get the idea.

108
00:05:11,040 --> 00:05:15,650
This is the problem with
the general principle

109
00:05:15,650 --> 00:05:18,110
that when PIM gets
traffic on an interface,

110
00:05:18,110 --> 00:05:20,420
it forwards it
out all interfaces

111
00:05:20,420 --> 00:05:22,670
except the one that arrived on.

112
00:05:22,670 --> 00:05:26,370
That is not enough
to prevent loops.

113
00:05:26,370 --> 00:05:28,940
So now let's bring
in our topic--

114
00:05:28,940 --> 00:05:33,690
the Reverse Path Forwarding
check, or the RPF check.

115
00:05:33,690 --> 00:05:36,980
So let's clean this
up and start again.

116
00:05:36,980 --> 00:05:38,780
Now, we are going to
make the assumption

117
00:05:38,780 --> 00:05:41,090
as we start that
everybody already

118
00:05:41,090 --> 00:05:43,250
knows the source address.

119
00:05:43,250 --> 00:05:47,520
That the S,G entries already
exist on all the routers.

120
00:05:47,520 --> 00:05:49,670
Now, again, we'll discuss
how that happens more

121
00:05:49,670 --> 00:05:52,530
in the upcoming videos on
dense mode and sparse mode.

122
00:05:52,530 --> 00:05:54,800
But for now, they already know.

123
00:05:54,800 --> 00:05:59,270
So since they know that
the source is 10.1.1.1.

124
00:05:59,270 --> 00:06:01,310
Each of these
routers individually

125
00:06:01,310 --> 00:06:03,140
will look to their
own routing table

126
00:06:03,140 --> 00:06:06,620
and choose which
interface they would use

127
00:06:06,620 --> 00:06:09,180
to go back towards that source.

128
00:06:09,180 --> 00:06:13,430
Now, on router 1, that's clearly
going to be this interface.

129
00:06:13,430 --> 00:06:16,670
On router, once again,
fairly straight forward,

130
00:06:16,670 --> 00:06:17,990
that would be this interface.

131
00:06:17,990 --> 00:06:21,290
Remember, all of our
links right now cost 10.

132
00:06:21,290 --> 00:06:22,820
We'll be changing
that in a minute

133
00:06:22,820 --> 00:06:24,180
just to see what happens.

134
00:06:24,180 --> 00:06:27,300
But for right now,
all the links cost 10.

135
00:06:27,300 --> 00:06:30,710
So this would be the RPF
interface on router 2.

136
00:06:30,710 --> 00:06:34,130
This would be the RPF
interface on router 4.

137
00:06:34,130 --> 00:06:38,420
This would be the RPF
interface on router 5.

138
00:06:38,420 --> 00:06:41,900
Now that we've established
the RPF interfaces,

139
00:06:41,900 --> 00:06:44,520
let's talk about our
traffic flow again.

140
00:06:44,520 --> 00:06:49,580
So once again, the source starts
up, sends this to router 1.

141
00:06:49,580 --> 00:06:53,270
First thing, did it arrive
on an RPF interface?

142
00:06:53,270 --> 00:06:54,200
Yes.

143
00:06:54,200 --> 00:06:56,330
So we accept the traffic.

144
00:06:56,330 --> 00:06:58,280
The traffic is allowed in.

145
00:06:58,280 --> 00:07:01,640
And we'll say the same as we
did before, we forwarded out

146
00:07:01,640 --> 00:07:03,600
all PIM-enabled interfaces.

147
00:07:03,600 --> 00:07:06,260
Now, again, that's more
dense mode behavior,

148
00:07:06,260 --> 00:07:09,230
sparse mode wouldn't do
that, it maintains an oil

149
00:07:09,230 --> 00:07:10,490
a little more efficiently.

150
00:07:10,490 --> 00:07:14,280
But for now, we forward it
out all those interfaces.

151
00:07:14,280 --> 00:07:19,040
So we send it to router
3, we send it to router 4,

152
00:07:19,040 --> 00:07:21,320
we send it to router 2.

153
00:07:21,320 --> 00:07:25,620
So each of these then
look for their RPF check.

154
00:07:25,620 --> 00:07:29,510
And of course, router
3 passes the RPF check,

155
00:07:29,510 --> 00:07:33,230
so does router 2,
so does router 4.

156
00:07:33,230 --> 00:07:37,340
Well, once again, just like
before, router 3 forwards it

157
00:07:37,340 --> 00:07:39,770
to its client, that's fine.

158
00:07:39,770 --> 00:07:43,700
Router 4 forwards it to
its client, that's fine.

159
00:07:43,700 --> 00:07:47,270
Router 4 forwards
it to router 5--

160
00:07:47,270 --> 00:07:50,390
again, RPF check passes.

161
00:07:50,390 --> 00:07:54,630
Router 5 accepts the traffic,
forwards it to this client.

162
00:07:54,630 --> 00:07:59,090
So far so good, but let's go
back to our looping problem.

163
00:07:59,090 --> 00:08:03,410
Router 4 also sends this
back up to router 2.

164
00:08:03,410 --> 00:08:08,910
But on router 2, it did not
arrive at an RPF interface.

165
00:08:08,910 --> 00:08:12,410
Therefore, this traffic
will be discarded.

166
00:08:12,410 --> 00:08:16,970
When router 2 got it, it tried
to send it down to router 4.

167
00:08:16,970 --> 00:08:20,990
Once again, that's
not the RPF interface.

168
00:08:20,990 --> 00:08:23,914
Router 2 would have tried
to send it to router 3,

169
00:08:23,914 --> 00:08:26,540
not the RPF interface.

170
00:08:26,540 --> 00:08:29,750
Router 3 would have tried
to send it to router 2,

171
00:08:29,750 --> 00:08:32,100
not the RPF interface.

172
00:08:32,100 --> 00:08:35,549
So here we can see the loops
trying to form, so to speak,

173
00:08:35,549 --> 00:08:38,270
but being blocked
by the RPF check.

174
00:08:38,270 --> 00:08:41,750
And since the RPF check is
blocking all this traffic where

175
00:08:41,750 --> 00:08:44,360
we showed, none of
these loops form,

176
00:08:44,360 --> 00:08:47,120
we're not getting duplicate
packets on clients,

177
00:08:47,120 --> 00:08:49,550
and we don't have
traffic that's going

178
00:08:49,550 --> 00:08:51,960
to be looping indefinitely.

179
00:08:51,960 --> 00:08:55,020
So that's simply how
the RPF check works.

180
00:08:55,020 --> 00:08:57,340
But what if we were to
change one of these costs?

181
00:08:57,340 --> 00:09:01,030
What if we were to say that
this link over here the cost

182
00:09:01,030 --> 00:09:03,070
changes to 30?

183
00:09:03,070 --> 00:09:07,070
That means that this is no
longer the RPF interface.

184
00:09:07,070 --> 00:09:09,970
So this would no
longer pass the check,

185
00:09:09,970 --> 00:09:13,780
therefore this traffic
would be blocked.

186
00:09:13,780 --> 00:09:16,330
And in fact, everything
happening on this connection

187
00:09:16,330 --> 00:09:19,390
right here is going to
change because now what's

188
00:09:19,390 --> 00:09:25,275
going to happen is this becomes
the interface on router 3

189
00:09:25,275 --> 00:09:27,550
now, which means it
will no longer send

190
00:09:27,550 --> 00:09:31,270
the traffic out that way, but
the traffic being forwarded

191
00:09:31,270 --> 00:09:35,860
from router 2 down to router
3 will now pass the RPF check

192
00:09:35,860 --> 00:09:39,040
and that becomes the link
that we're now using.

193
00:09:39,040 --> 00:09:42,820
Now, once again, we will try
to send the traffic up this way

194
00:09:42,820 --> 00:09:45,550
to router 1, where
it's not the RPF

195
00:09:45,550 --> 00:09:47,900
check so we block it over here.

196
00:09:47,900 --> 00:09:49,990
So really what
happened is we just

197
00:09:49,990 --> 00:09:54,250
moved which interface is the
RPF interface, which interface

198
00:09:54,250 --> 00:09:59,230
is trying to create a loop, but
being blocked by the RPF check.

199
00:09:59,230 --> 00:10:02,720
But overall, this is
how the RPF check works,

200
00:10:02,720 --> 00:10:05,560
and we'll see this in
action as we move forward

201
00:10:05,560 --> 00:10:10,280
through talking more about
dense mode and sparse mode.

202
00:10:10,280 --> 00:10:13,330
So in this video, we
jumped in and took a look

203
00:10:13,330 --> 00:10:17,410
at the RPF check, or the
Reverse Path Forwarding check.

204
00:10:17,410 --> 00:10:23,320
As a reminder, this uses the IGP
regardless of what IGP it is,

205
00:10:23,320 --> 00:10:27,730
which by the way, is why this
is called Protocol Independent

206
00:10:27,730 --> 00:10:32,350
Multicast because it doesn't
matter what the IGP is.

207
00:10:32,350 --> 00:10:36,070
We used OSPF in our example,
could have just as easily been

208
00:10:36,070 --> 00:10:40,000
EIGRP, IS-IS, RIP,
even static routes--

209
00:10:40,000 --> 00:10:41,470
it doesn't matter.

210
00:10:41,470 --> 00:10:44,260
Because all we're doing
is looking to the IGP

211
00:10:44,260 --> 00:10:49,330
to find what interface we would
use to go back to the source

212
00:10:49,330 --> 00:10:52,410
if we were going to send
traffic to the source.

213
00:10:52,410 --> 00:10:54,250
Doesn't mean we're
going to, we're

214
00:10:54,250 --> 00:10:56,050
just using that as our check.

215
00:10:56,050 --> 00:10:59,080
Then that becomes
the RPF interface

216
00:10:59,080 --> 00:11:02,050
and that's the
interface that, A, we

217
00:11:02,050 --> 00:11:06,400
will accept multicast
traffic on for that source,

218
00:11:06,400 --> 00:11:11,480
and B, that is the interface
we would send PIM join messages

219
00:11:11,480 --> 00:11:16,230
out if we were trying to do
a join towards that source.

220
00:11:16,230 --> 00:11:18,080
So again, those
are the two things

221
00:11:18,080 --> 00:11:20,660
that we're using
this RPF check for.

222
00:11:20,660 --> 00:11:24,410
Now, this will get used a
little bit more in dense mode

223
00:11:24,410 --> 00:11:28,280
than in sparse mode as far as
the loop prevention mechanism,

224
00:11:28,280 --> 00:11:32,640
but it gets used for the
join messages either way.

225
00:11:32,640 --> 00:11:36,260
So the next thing we have
to do is take a closer look

226
00:11:36,260 --> 00:11:39,620
at dense mode and
sparse mode, and we'll

227
00:11:39,620 --> 00:11:41,600
be starting with dense mode--

228
00:11:41,600 --> 00:11:43,530
that's what we're going
to be hitting next.

229
00:11:43,530 --> 00:11:46,760
Until then, I hope this has
been informative for you,

230
00:11:46,760 --> 00:11:49,930
and I'd like to thank
you for viewing.

231
00:11:49,930 --> 00:11:53,000