Up until now,
we've talked about multicast at a high level and the basics of the PIM protocol.
Now it's time to get specific with the different implementations of PIM,
starting with the legacy dense mode.
In this module, we'll cover the following topics,
the basic operation of PIM dense mode.
After that,
we'll see some command line demonstrations of how PIM
dense mode works in a real network,
as well as how new multicast receivers are added after the
flood and prune process takes place.
Finally, we'll analyze packet captures, showing a PIM join and prune packet,
as well as a PIM Graft and GraftAck packet.
Globomantics is looking to extend its multicast deployment
to one of the smaller and older offices,
which also doubles as a warehouse.
This location has employees who are ready to take
advantage of the new streaming concerts perk,
but there are some challenges.
The Globomantics network at this location is a bit outdated and
needs to use a legacy implementation of multicast.
Luckily,
there was space to house a server in the warehouse
to stream the concert locally.
And while the networking equipment is older,
it conforms to the Globomantics design standard.
This will make developing a solution easier.
Let's look at how the legacy implementation of multicast PIM
dense mode will work in this location.
In all implementations of multicast, the same basic question needs an answer.
How do we pair sources and receivers?
Every PIM mode handles it differently.
In PIM dense mode,
the answer is to take the multicast traffic from every source and flood it
into the network so that all PIM routers become aware of it.
If there are interested receivers,
the PIM routers will simply allow the traffic to flow along the outgoing
interface list from the source to the receiver and take no action.
If there are no downstream receivers,
each PIM router will forward a PIM join prune upstream with the prune flag set
in order to tell the next router to stop sending the traffic.
When all the prune messages have been sent and all the PIM routers have
an OIL only for the receivers that want the traffic,
optimal delivery has been achieved.
This method of multicast delivery is clearly subpar
from an optimization standpoint.
Every 3 minutes,
any PIM router with an objective source will flood the
traffic along every interface downstream except the one on
which it receives the traffic.
In the case of a router that has no active IGMP and
MLD reports for that *,G entry,
it will send a PIM join prune from its incoming interface
upstream to the next router with the prune flag set.
When the upstream router receives this message,
it removes that downstream interface from the OIL and sets a prune timer.
Until that time runs out or until a downstream router sends
a message upstream signaling interest,
no multicast traffic will be delivered to it.
In PIM dense mode,
the PIM join message is generally not used upstream to signal interest in
multicast because the flood mechanism makes it unnecessary.
It's only used in one specific use case,
to override the prune message of another router on the same segment.
If MCAST3 and MCAST5 both have receivers and the receiver
attached to MCAST5 leaves the group,
MCAST5 will send a PIM prune message upstream to
MCAST4 to stop the multicast flow.
When MCAST3 sees this,
it sends a PIM join to override the behavior and keep traffic flowing.
The PIM Graft message is generated when a receiver signals interest in
multicast for a particular group that has been learned before,
but pruned.
The graft is functionally like the PIM join, but with an important difference.
A PIM Graft message expects to receive an
acknowledgement from an upstream router,
whereas a PIM join is just forwarded towards the source.
The GraftAck message from an upstream router is how the downstream
router knows that the upstream flow will be restarted,
and it will be able to forward on its own OIL.
The reason a GraftAck is needed in this case is because the upstream flow
was previously cut off and will remain that way until timers expire and
traffic is reflooded without a graft message.
With other implementations of PIM that use the PIM join,
there is no such expectation.
The GraftAck message is how any router knows that its upstream
request to cancel the prune timer was successful.
If there's no GraftAck within a timer, another will be sent.
Originally,
the flood and prune method by which dense mode works would have to be refreshed
every 3 minutes by again flooding the multicast traffic everywhere and each
router reissuing the prune message to stop the flow.
An optimization introduced with PIMv2 allows PIM to skip the reflooding step
by refreshing the prune timers on routers downstream from the source via a
state refresh message sent by the First Hop Router.
In the last module, we looked at a PIM Hello packet.
And option 21 was the State‑Refresh option.
These days, the State‑Refresh is a default setting,
but it can be toggled on or off for backwards compatibility. And option 21 simply signals the router's capability to its neighbors.