[AUDIO LOGO]
So next, let's talk about reverse path forwarding
in some more detail.
Now, the idea behind reverse path forwarding
is we simply want to make sure that when
traffic arrives at the router, it's
on the appropriate interface.
And what does the appropriate interface mean?
Well, it means the interface that router
would use to go back to the source address based
on its IGP.
Now, the IGP here can be anything.
We can use OSPF, EIGRP, RIP.
It doesn't matter what the underlying IGP is, it simply
looks to that to learn the egress interface to get back
to the source.
If that traffic is not arriving on the RPF interface,
the router will discard the multicast traffic.
Now, we use this for two purposes.
The first purpose is for loop prevention.
And as we jump into our discussion,
I'll show you what that problem would
be if we allowed PIM to just go unchecked and not
do the RPF check.
The other thing we use it for is so
that PIM knows which way to send the join messages once it
does know the source.
Now, again, this is going to vary a little bit how
it's completely implemented between sparse mode
and dense mode.
So once again, this is just going
to be discussing RPF checks, in general.
We'll talk about them in a little more detail
as we get into dense mode versus sparse mode in our upcoming
videos.
So for now, let's just jump in and take a look
at how RPF checks work and what their job is
in the multicast environment.
So let's just start off with a quick discussion of our diagram
here.
First, we have a source over here, its address is 10.1.1.1,
although that's not going to be incredibly important.
But for the beginning of our discussion,
we're going to consider all of the link costs
here to be 10, which sort of means we're either
running OSPF or IS-IS.
Since we're dealing with a cost, we'll
say that we're running OSPF.
Once again, I will point out that the IGP doesn't matter.
This could be RIP and hop count, this could be EIGRP and its
custom metric, or again, IS-IS, OSPF--
the IGP doesn't matter.
Now, as we jump into our discussion
here on reverse path forwarding, we
are sort of going to approach this from the dense mode
perspective because that's where the biggest problem exists.
Does sparse mode still use RPF checks?
Yes, it does.
But not quite to the extent that dense mode does.
So as we're going through this discussion,
understand that this lends itself a little bit more
to dense mode.
So let's talk about what happens.
Our source starts up and starts sending multicast traffic
onto the network.
Now, the rule of PIM, and again, particularly dense mode
is that by default, all interfaces are on the oil.
So all interfaces, except the interface it arrived on.
We will forward this multicast traffic out,
so to say router 3, router 4, router 2 is going to get it.
So far so good.
We don't have a problem yet.
But let's take a look, for example, at router 3.
Router 3 takes this, forwards it to its client,
by the way, that's a good thing, that's
what we're running multicast for.
But here's where the problem starts coming in--
it now forwards it to router 2.
OK, well, router 2 now has two copies of the frame,
but we'll leave that out of the discussion even for now.
Let's talk about the first copy that showed up,
router 2 would have also sent that back to router 3.
Router 2 would have sent that down to router 4.
Router 4 now got two copies of the frame.
Now it's going to send a copy to router 5,
and router 5, of course, is going
to send that to its client, and all of that is perfectly fine.
Router 4 also sends it to its client--
again, perfectly fine.
But once again, router 4 is also going
to send it back up to router 1.
And here's where the problems really come in.
I mean, you can already see that there's loops here.
Router 1 just got this packet, sends it back to the source.
Well, the source sure as heck doesn't want it
again, but worse yet, goes ahead and sends
it back over to router 2 again.
Well, router 2 just got it, so it goes ahead
and sends it back down to router 4,
router 4 sends it back down to its client again,
sends it over to router 5 again.
Router 5 sends it down to its client again.
Router 2 also sends it down to router again.
Router 3 sends it to its client again,
sends it back up to router 1 again.
I think we get the idea.
This is the problem with the general principle
that when PIM gets traffic on an interface,
it forwards it out all interfaces
except the one that arrived on.
That is not enough to prevent loops.
So now let's bring in our topic--
the Reverse Path Forwarding check, or the RPF check.
So let's clean this up and start again.
Now, we are going to make the assumption
as we start that everybody already
knows the source address.
That the S,G entries already exist on all the routers.
Now, again, we'll discuss how that happens more
in the upcoming videos on dense mode and sparse mode.
But for now, they already know.
So since they know that the source is 10.1.1.1.
Each of these routers individually
will look to their own routing table
and choose which interface they would use
to go back towards that source.
Now, on router 1, that's clearly going to be this interface.
On router, once again, fairly straight forward,
that would be this interface.
Remember, all of our links right now cost 10.
We'll be changing that in a minute
just to see what happens.
But for right now, all the links cost 10.
So this would be the RPF interface on router 2.
This would be the RPF interface on router 4.
This would be the RPF interface on router 5.
Now that we've established the RPF interfaces,
let's talk about our traffic flow again.
So once again, the source starts up, sends this to router 1.
First thing, did it arrive on an RPF interface?
Yes.
So we accept the traffic.
The traffic is allowed in.
And we'll say the same as we did before, we forwarded out
all PIM-enabled interfaces.
Now, again, that's more dense mode behavior,
sparse mode wouldn't do that, it maintains an oil
a little more efficiently.
But for now, we forward it out all those interfaces.
So we send it to router 3, we send it to router 4,
we send it to router 2.
So each of these then look for their RPF check.
And of course, router 3 passes the RPF check,
so does router 2, so does router 4.
Well, once again, just like before, router 3 forwards it
to its client, that's fine.
Router 4 forwards it to its client, that's fine.
Router 4 forwards it to router 5--
again, RPF check passes.
Router 5 accepts the traffic, forwards it to this client.
So far so good, but let's go back to our looping problem.
Router 4 also sends this back up to router 2.
But on router 2, it did not arrive at an RPF interface.
Therefore, this traffic will be discarded.
When router 2 got it, it tried to send it down to router 4.
Once again, that's not the RPF interface.
Router 2 would have tried to send it to router 3,
not the RPF interface.
Router 3 would have tried to send it to router 2,
not the RPF interface.
So here we can see the loops trying to form, so to speak,
but being blocked by the RPF check.
And since the RPF check is blocking all this traffic where
we showed, none of these loops form,
we're not getting duplicate packets on clients,
and we don't have traffic that's going
to be looping indefinitely.
So that's simply how the RPF check works.
But what if we were to change one of these costs?
What if we were to say that this link over here the cost
changes to 30?
That means that this is no longer the RPF interface.
So this would no longer pass the check,
therefore this traffic would be blocked.
And in fact, everything happening on this connection
right here is going to change because now what's
going to happen is this becomes the interface on router 3
now, which means it will no longer send
the traffic out that way, but the traffic being forwarded
from router 2 down to router 3 will now pass the RPF check
and that becomes the link that we're now using.
Now, once again, we will try to send the traffic up this way
to router 1, where it's not the RPF
check so we block it over here.
So really what happened is we just
moved which interface is the RPF interface, which interface
is trying to create a loop, but being blocked by the RPF check.
But overall, this is how the RPF check works,
and we'll see this in action as we move forward
through talking more about dense mode and sparse mode.
So in this video, we jumped in and took a look
at the RPF check, or the Reverse Path Forwarding check.
As a reminder, this uses the IGP regardless of what IGP it is,
which by the way, is why this is called Protocol Independent
Multicast because it doesn't matter what the IGP is.
We used OSPF in our example, could have just as easily been
EIGRP, IS-IS, RIP, even static routes--
it doesn't matter.
Because all we're doing is looking to the IGP
to find what interface we would use to go back to the source
if we were going to send traffic to the source.
Doesn't mean we're going to, we're
just using that as our check.
Then that becomes the RPF interface
and that's the interface that, A, we
will accept multicast traffic on for that source,
and B, that is the interface we would send PIM join messages
out if we were trying to do a join towards that source.
So again, those are the two things
that we're using this RPF check for.
Now, this will get used a little bit more in dense mode
than in sparse mode as far as the loop prevention mechanism,
but it gets used for the join messages either way.
So the next thing we have to do is take a closer look
at dense mode and sparse mode, and we'll
be starting with dense mode--
that's what we're going to be hitting next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.