[AUDIO LOGO]
So now it's time to jump in and take a look at sparse mode
operation.
Now as we've said previously, this
is definitely the preferred way of doing multicast
for most environments.
Because in most environments, the majority of devices
are not going to be multicast receivers.
Therefore, we don't want to make the assumption that everybody
wants this multicast.
We would rather do a pull model, which
is what sparse mode is where we only
forward the traffic to the devices that actually need it.
So to a certain extent, this is the opposite of the dense mode
model where we assume everybody wants it,
and we flood it to the network.
Now in order for this to work, we
are going to have to add an additional component.
And that's called the rendezvous point.
So all of this said, let's go ahead,
and just jump in, and take a look at how this works.
We've updated our diagram just a little bit with some more
information.
So we'll start by going over that
and then talk about the sparse mode operation.
So the first thing that's changed
is, of course, we have configured
router 2 with a loopback 0 interface
with the address 100.1.1.1.
And we've configured this to be the RP or the rendezvous point.
Now one quick thing to note here as we jump in,
every router in the multicast environment
has to know where the RP is.
Now, there are several ways for that to happen.
But that's not part of this discussion.
We will be discussing that in a future skill.
So don't worry about that.
But just be aware that all of the devices know who
or where the RP is.
So there are choices of how we run the RP
and how we learn about the IP.
And those are discussions we will have.
But for right now, let's just go with every router knows who
and where the RP is, in this case, router 2's loopback 0
interface.
Also note that we have two different RPF checks noted
on this particular diagram.
We have an RPF check that's going to be for the source
comma group.
This is, of course, the entry we've been discussing up
to this point.
But notice we have a new one here
called the star comma G entry.
This is referred to as the shared tree.
And this is something we're going to use
with the rendezvous point.
This will make sense as we proceed
through this discussion.
So let's start the same way we did with dense mode.
What happens when the source starts up and begins
sending traffic to router 1?
Well, just like in dense mode, as soon
as this traffic shows up, router 1 does the RPF check.
It passes, and it creates an S,G entry.
This can create an S,G entry because it saw the packet.
And it knows where the source is.
But now, we have a new job that's
the responsibility of the first hop router.
Remember in this example that router 1 is the first hop
router, simply meaning it's closest to the source.
What this job is is now that it knows an S,G,
it sends what's called a PIM register message to router 2.
Now just to be clear, this PIM register message
is simply this multicast packet that
arrived on router 1 being encapsulated into unicast
and sent to router 2.
This is called a PIM register message.
And it uses a PIM register tunnel.
This tunnel is used simply in case--
and, of course, it's not the case in our diagram
but just in case there were other routers
in the path between router 1 and router 2 that
don't know anything about this multicast yet.
They can, of course, forward unicast to the RP address
100.1.1.1.
This address has to be in the IGP.
And it has to be reachable.
So these routers in the middle could forward
the unicast, no problem.
That's why the register message is send unicast to the RP.
Now just like on router 1, as soon as this register message
shows up, router 2 de-encapsulates it
and discovers the S,G. So once again,
the RP is going to get an S,G entry, so far so good.
Now as long as this source continues to send,
we will continue to send these register messages.
As of right now, router 2 does not
have any clients or downstream routers.
And as such, this traffic is going to go nowhere.
Again, it will occasionally send a register message to the RP.
The RP will actually reply with a register stop message.
And again, periodically, this will be redone just to keep
the S,G entry on router 2 fresh.
So it doesn't time out.
But all of this is just to let the RP know where the S,G is
in case a client comes along.
So if there were no clients, this discussion would be over.
But of course, there are clients.
So let's go down and talk about the client side now.
So let's say that our client here off of router 4
sends an IGMP report message to router 4 asking
for this group, 224.1.1.1.
Well, router 4 doesn't know where that is.
So what we're going to do is use this thing called the shared
tree because, again, everybody knows
where the rendezvous point is.
So what router 4 is going to do is
use the RPF for the shared tree, which
is this interface right here.
And it's going to send a PIM join message up to router 2.
It sends it to router 2 because that's all it knows.
Now as soon as router 2 gets this join message,
what it's going to do is it's going to add
this interface to its OIL.
Once that interface is on the OIL,
the de-capsulated multicast from the register message
is going to be sent down to router 4.
This is going to be coming down the shared tree.
Therefore, it passes the RPF check for the shared tree.
And we didn't mention this.
But as soon as we get the IGMP report message,
router 4 would have added this interface to its oil as well.
And therefore, router 4 forwards the traffic down to the client.
Now notice how none of this has affected routers 3 or 5 yet.
Nobody has this traffic.
Those clients haven't actually requested it yet.
So we can see that this is only affecting
the routers that are necessary.
Now, of course, once this traffic shows up,
router 4 has now also learned the S,G entry.
Now the next two things are going
to happen at the same time.
That said, we can't exactly talk about them at the same time.
So we're going to have to go one after the other.
But be aware that these two things happen together.
Now that router 2 actually has an interface on its OIL
because it's forwarding to router 4, it realizes, well,
I have a client now.
So I don't want to keep getting these messages through unicast,
through the register message.
Because this is supposed to be multicast.
It's not supposed to be partially unicast and then
the rest multicast.
It's supposed to be all multicast.
So essentially router 2 says, OK, we're
really going to do this.
I've got clients now.
So what it does, it sends a PIM join message
to router 1 to actually form a tree.
Well, once it gets that, router 1
is going to add this interface to its OIL for this traffic.
As soon as it does that, it's going
to start forwarding the multicast to router 2.
As soon as router 2 receives the multicast,
it's then going to send a register stop
message to router 1 to tell it to stop sending the unicast.
And at that point, all of this is
going to stop, so far so good.
However, there's another thing that happens at the same time
that I mentioned, which is something called the SPT
switch over.
And this is shortest path tree.
Router 4 is going to initiate an SPT switch over as soon as it
gets the first packet and generates this S,G entry.
Router 4, now that it knows the source,
is going to send a join message towards the source.
That's going to be out the RPF interface for the source,
meaning that join is going to go this way to router 1.
Router 1 gets this join message and just like it
did for router 2, it's now going to add this interface
to the OIL.
Once that interface is on the oil then,
of course, the multicast starts going this way to router 4.
This is done because it's more efficient.
If we look at this router 2, the rendezvous point
should not really be in this data path.
Can it be?
Yes.
Is it the most efficient?
No.
So the SPT switch over is done so that our traffic follows
the most efficient path.
So here's the follow up to all of this.
So as we mentioned, the tree to router 2 and the tree
to router 4 are built at the same time.
But as soon as router 4 starts getting the traffic
on the S,G-RPF interface, guess what?
It doesn't need the traffic from router 2 anymore.
So it sends a prune.
As soon as this prune message hits router 2,
router 2 says, OK.
And it removes the interface from its OIL,
stops sending the multicast.
And, of course, that pruned message
only has to be sent once.
Once that's done, guess what router 2 doesn't have anymore?
Router 2 no longer has any clients.
So it doesn't need the multicast tree
from router 1 anymore either.
So what does it do?
It also sends a prune.
Router 1 removes that interface from its oil,
stops sending the multicast.
And router 2 is now out of the data path.
But router 2 still has the S,G. So understand that as soon
as another client comes online--
so this client off of router 3 makes a request,
router 3 is going to go through the same process.
It sends a star comma G join up to router 2.
Router 2 adds the interface to its OIL,
begins sending the multicast down to router
3 who, of course, added this interface to its OIL,
forwards the multicast down to this client.
Now we don't have to talk about all of it again.
Yes, the rendezvous point still would have built its tree.
All that other stuff would have happened.
But we'll skip that part.
I think we get the idea.
But once again, as soon as router 3 gets this traffic,
it again, gets the S,G.
As soon as it gets the S,G, it looks at its best path to get
to the source, realizes that it's directly to router 1 out
that RPF interface.
Because that's the RPF for the S,G,
sends the join to router 1.
Router 1, of course, adds this interface to its OIL
and start sending the multicast down to router 3.
Router 3, once again, prunes the traffic coming from router 2.
Router 2, again, removes this from the oil and tears
down the tree that, again, it would have just built.
But the point in all of this, remember PIM's two jobs;
find the source, build the tree.
Finding the source is done by building the shared
tree to the rendezvous point.
The rendezvous point forwards the traffic
down the shared tree.
The end routers or the last hop routers get the traffic,
learn the S,G, and then initiate an SPT switchover.
Now just for the record, the SPT switchover can be disabled.
You don't have to do the SPT switchover.
But it is enabled by default on Cisco routers.
And it will do this as soon as it receives the first multicast
packet.
And just one final takeaway just so we're very clear,
the RPF check to the address of the rendezvous point is used
for the star comma G. And, of course,
the RPF check to the source is used once we know the source
and we have the S,G.
So these could possibly be two different interfaces.
If we look at routers 3 and 4, they
are two different interfaces.
Of course, in the situation of router 5,
those would be the same interfaces
because it only has one tie-in to the multicast environment.
But overall, this is how PIM sparse mode operates
in our multicast environment.
So in this video, we evaluated sparse mode operation
in our environment.
And as we can see, this is very, very different from dense mode.
By using a rendezvous point and the shared tree,
the main goal here is notice that, for example, router 5,
since its client never actually came online,
it never learned the S,G entry.
It doesn't have to know it.
There's no need.
So we're not forwarding traffic everywhere
like we did in dense mode.
We're only forwarding it to the devices that request it.
Now going through this whole process, you may look at it
and say, well, that whole initial setup, going to the RP
and then switching over with the SPT switch over and all
that, that seemed like maybe it was a little inefficient.
Well, arguably, you could make that there's
a bunch of moving parts there with the register messages
and the register stop messages.
But at the end of the day, even though there's
a little bit of multiple steps, we'll
say, for the setup of this tree, ultimately
it's going to be more efficient than dense mode in most
environments.
So that pretty much sums up everything we
need to discuss in this skill.
That said, we just have a review in the form of a quiz.
And that's what we're going to do next.
Until then, I hope this has been informative for you.
And I'd like to thank you for viewing.