[AUDIO LOGO]
So now it's time to jump in and take
a look at our PIM operational models,
starting with dense mode.
Now, the basic idea behind dense mode
is the assumption is everybody on the network wants
this multicast traffic.
And therefore, we are going to flood the traffic
through our network.
And then the devices that don't want it can tell us
that they don't want it.
And we will prune the traffic back
from that part of the tree.
So that's the basic idea.
That also sort of makes it a little bit obvious,
I hope, why this is also referred to as flood and prune.
Now, while it's flooding that traffic, guess what.
Everybody learns the S comma G entry.
So remember one of our fundamental principles
here with PIM.
We need to find the source.
Well, in the case of dense mode, we're
going to find that source by simply flooding
the traffic to all the routers.
Just like that, they know the source.
There's no secret.
There's no magic formula.
We simply flood the traffic everywhere.
Everybody learns the S comma G. Those
that want the traffic keep it.
Those that don't prune it.
And through the pruning process is
how we actually form the tree.
Now, the tree itself, of course, would just
be everything everywhere by default.
So by default here, all interfaces
are going to be on the OIL.
So let's jump into our diagram and map this out
and take a look at how dense mode operation works.
Now, this isn't very popular.
However, I will point out one thing.
One advantage that dense mode does have over sparse mode
is it is very simple to implement.
And from that perspective, it sort of takes care of itself.
So we might get a lot of traffic places we don't want it.
However, it is a very simple operation.
So let's go ahead and jump in and take a look
at how dense mode actually works on our network.
So as we start our dense mode discussion,
keep in mind that we're going to be using the same link costs
that we used for our RPF video.
We're just going to say that they're all a cost of 10.
So they're all equal.
The RPF interfaces are indicated by the red dots.
Those are already on here.
Now, keep in mind, the routers will calculate this
as they get the information.
But I've just already marked them on here.
The OILs, or the Outbound Interface Lists,
will indicate those interfaces as we go.
Also, we're going to be using the source of 10.1.1.1
with the group 224.1.1.1, making our S comma G entry
the 10.1.1.1 comma 224.1.1.1.
And of course, remember that one of PIM's main jobs
is for everybody to learn the source.
So we need to learn the source.
And we need to build the tree.
So let's jump in and talk about how
dense mode accomplishes this.
So the first thing that's going to happen
is the source is going to start sending multicast traffic
onto the network.
As soon as this happens, the traffic hits router 1.
Router 1, of course, does an RPF check.
This is going to pass because it's a connected interface
on router 1.
So that's going to be a real quick, easy RPF check.
The traffic is accepted by router 1.
And then it's going to send it out all
of the interfaces except the one that it arrived on,
which means that all of these interfaces on router 1,
to begin with, are going to be on the OIL.
Of course, the other thing it's going to do
is create the S comma G entry because we have now
seen the traffic.
We've looked at the IP headers.
And we know the source and the group
that this multicast is using.
So that's what's going to happen on router 1.
And then it forwards the traffic to router 3, to router 4,
and to router 2.
So let's start with router 3.
Router 3 gets this traffic.
It of course arrives on this interface.
And of course, as soon as it gets the traffic,
it's going to create an S comma G entry.
We now know where the source and group are.
Now that we know where the source is,
we can do our RPF check, realize that it did in fact
come in on the RPF interface.
So that traffic should be accepted.
And then we look at our OIL.
So as we said, the default is it's going
to send it out all interfaces.
So it's going to send it out these two interfaces.
And the traffic is going to get to the client
and up to router 2.
Now, of course, on router 2, that is not an RPF interface.
So that traffic will be discarded.
So when this traffic does arrive on router 2,
it's of course going to make the S comma G entry in its table
as well.
And it's going to then forward the traffic
out the interfaces on its OIL, which again, by default, is
all of them.
So it will then forward the traffic down to router 3.
Of course, that's not on the RPF interface.
So that will be discarded.
And it will forward it down to router 4--
also not on the RPF interface, so also going to be discarded.
That's what router 2 is going to do.
When router 4 receives the flow from router 1,
it's again going to make an S comma G entry and forward
the traffic out all of the interfaces on its OIL.
That would be this interface up here, this one down here,
and the interface towards router 5.
So the traffic going up to router 2, of course, not an RPF
interface.
So that traffic is going to be discarded.
The traffic of course goes down to the client.
And the traffic is going to show up on router 5.
Router 5 of course makes its S comma G entry,
does the RPF check, realizes the traffic
arrived at the correct interface,
and therefore forwards it out the interfaces on its OIL.
And the traffic arrives at this client.
So remember that PIM has two jobs on our network.
The first is to find the source.
Well, look at all of our routers.
They all have an S comma G entry.
How do they have that S comma G entry?
Because they saw the traffic.
Dense mode's method of getting the S comma G
entry onto all of the routers is simply
to flood it through the network.
And then the routers that don't need it,
such as router 2 in our example, will then prune that back.
That's of course why this is also
referred to as flood and prune.
So let's go ahead and talk about the maintenance of the tree.
So what happens here if we don't have
anybody who wants the traffic, such as on router 2?
Let's take a look.
So how do we know that router 2 doesn't have any clients?
Well, before we can address that,
we almost have to talk about how routers 3, 4, and 5 know
that they do have clients.
One thing we haven't talked about here
is that the clients are going to have
to have sent an IGMP report message up
to their last-hop router here, telling them
that they're actually interested in this traffic.
Now, again, the traffic will get sent at first on these devices.
But if they don't get an IGMP report message,
routers 3, 4, and 5 would also think they have no clients.
So for the moment, they do, although we may address
that in just a moment as well.
But take a look at router 2.
Router 2 has nobody sending an IGMP report message.
It also has nobody sending a PIM join message.
Now, how do we know that it's not getting an IGMP join?
Well, it's quite simply because the interfaces on routers 3
and 4 that are facing router 2 are not the RPF interfaces.
Remember that PIM joins will only ever
be sent out RPF interfaces.
So the joins would go this way.
Just for completeness, router 5 would have sent one
to router 4 as well.
And initially, router 2 would have sent a join
to router 1 as well.
This is the building the tree.
But nobody sent one to router 2.
So what happens then?
Well, what's going to happen is all of this traffic
is going to stop.
This is going to be removed from the OIL on router 3
because it didn't get a join from router 2 either.
So for the same reasons, router 3 and router 2
stop this traffic, remove the interfaces from the OIL
because they have no clients, and they
have no downstream multicast routers.
We know this because we didn't receive a join message.
Remember, the default is to initially flood.
But now that we know we have no downstream routers
and we know that we have no clients,
we're going to prune this.
And that's exactly what's going to happen
on this link over here on router 4 to router 2 as well.
So all of this gets pruned back.
However, we still have this situation on router 2
where it has no either downstream routers or clients.
So far, we've just said that about a link.
Well, we can say that about router 2, in general.
It has no clients.
There's no reason router 2 should be getting this traffic.
So now what's going to happen, since it
doesn't have any of that information,
is we are going to change this PIM join to a prune message.
Router 2 says to router 1, I no longer need this
because I have no clients.
Router 1 says, OK, you're the boss.
If you don't need it, I won't send it.
All of this is torn down.
Router 1 removes that interface from its OIL.
And now we have a steady-state tree,
where only the traffic is going where it needs to.
But here's the cool thing.
Router 2 still has the S comma G entry.
Since it still has that entry, if all
of a sudden a client were to come on and send an IGMP report
message, saying, yes, I do want this,
router 2 can just go right to its S comma G entry
and immediately send a join over to router 1, saying, hey,
you know that traffic I pruned?
Yeah, it turns out I actually need it because a client just
came online.
So the important thing here is even though router 2 has pruned
this, it still maintains the S comma G
entry until it times out.
Now, as long as this source is still running,
as long as we are still sending traffic over here,
we need router 2 to keep this S comma G entry.
So before it times out, what's going to happen
is at some point, router 1 will send the traffic over
to router 2 again, refreshing the S comma G entry.
Of course, if router 2 still has no clients,
it will once again prune it.
That traffic will stop again.
And we will maintain our steady-state tree.
But this is how all of this operates
in dense mode operation.
So hopefully, it's really clear why this is
referred to as flood and prune.
We use flooding to build the tree.
We use pruning to trim it back in areas we don't need it.
And then occasionally, we flood and prune again just
to maintain the S comma G entries on the routers.
So in this video, we took a look at dense mode operation,
also known as flood and prune.
And hopefully, we can see through this entire discussion
why it's called flood and prune because we use our flooding
to build the tree.
We use pruning to trim it back where
we don't need the traffic.
And then occasionally, we have to flood and prune again.
This is not a very efficient model in most environments.
The assumption here is that all the routers and all the clients
want the multicast traffic.
And if they don't, they'll prune it back.
But then every once in a while-- the default's
3 minutes-- it will flood it again.
And we have to do this all over again.
So again, it's not the most efficient model,
particularly if we have a low density
of clients who actually want a particular multicast group.
If it was a true statement that all the computers want this,
well, then dense mode would probably be just fine.
But the reality is in most environments,
that's not the case.
We're going to have a small group of computers, clients,
receivers, whatever we want to call them,
that actually want to receive the multicast traffic.
And in that situation, sparse mode
is going to handle this far more efficiently.
And that's exactly what we're going
to look at in more detail coming up next.
Until then, I hope this has been informative for you,
and I'd like to thank you for viewing.