PIM sparse mode is the most prevalent deployment in production networks today,
and it's very complex.
There are a lot of new terms to discuss, so let's get started.
In this module, we will cover the following topics,
the basic operation of PIM sparse mode.
After that,
we'll see some command line demonstrations of how PIM
sparse mode works in a network, starting with the election of a rendezvous point.
We'll generate multicast traffic,
and we'll see the PIM join process that builds the
trench upward towards the source.
We'll also see what happens when the best path changes
from an RP to the source itself.
We'll see a corner case involving switching over to the best path and
changing routers on a shared segment with PIM assert.
Last, we'll examine the PIM packets most important to PIM sparse mode,
the RP advertisement, the PIM register and register stop,
the PIM join, and the PIM assert.
This is the largest module in the course, so let's just take it step by step.
Globomantics is moving on to deploy multicast in its largest branch offices.
These branches have hundreds of users and devices.
We'll look at a small subset of the network,
which follows the corporate design standards and so should look familiar.
Because the whole deployment involves hundreds of devices,
Globomantics needs a PIM deployment that is more efficient than dense mode.
For this explanation, I've removed all but one receiver,
as the other receivers aren't important to the process.
Leveraging what we already know about the rules of multicast,
PIM sparse mode isn't particularly harder than any other PIM deployment.
Once again, like all PIM implementations,
we need to focus on how to pair sources and receivers.
Where PIM dense mode solved this problem by flooding the traffic so
that all PIM routers became aware of the source,
the goal of PIM sparse mode is the opposite,
to forward as little multicast traffic as possible.
To that end, PIM sparse mode leverages the service called the rendezvous point.
The purpose of the rendezvous point is to be essential
service where sources and receivers both forward traffic
to become aware of each other.
Each PIM router, whether the Last Hop Router,
First Hop Router or something in between must agree
on what the RP address will be,
and each will forward its relevant data to that point
using the unicast best path decision.
PIM joins that specify a group and request any source are forwarded toward the
RP to see if any sources are sending to the requested group.
Meanwhile,
First Hop Routers are forwarding their multicast traffic to the
RP to register the source and be findable.
A small, but important point of order for the source registration,
in PIM sparse mode,
each PIM router creates a unicast PIM tunnel to the RP when the RP is defined.
For the router serving as the RP, it creates the tunnel endpoint.
This is important because per the rules of multicast,
a multicast stream can only be forwarded according
to the outgoing interface list.
And without seeing any PIM joins, the First Hop Router will have an empty list.
What ends up happening in the case of a PIM register is that the FHR
sends a PIM register message to the RP and then begins sending the string
to it encapsulated in that PIM unicast tunnel.
The source of the PIM tunnel is the best unicast interface to reach the RP.
And the RP's tunnel source is whatever local interface is
configured with the IP of the RP that everyone is using.
If the RP has not received any PIM joins for any
interested receivers for that multicast group,
it responds to the PIM register with a PIM register stop message.
This sets a timer on the RP and the FHR to wait a while before
continuing to send that traffic stream over the PIM tongue.
If the RP receives a PIM join,
it will send a PIM join towards the FHR to get traffic flowing.
The FHR will add the interface towards the RP to
its own outgoing interface list, then traffic will flow downward to the RP.
Remember from our previous modules that PIM joins are initially converted
from some form of host or router signaling like IGMP or MLD.
From that point,
the interface on which they are received is added to the OIL of a router,
and the join is forwarded out of the incoming interface.
In PIM sparse mode,
the routers don't know the IP of the sources that are sending,
so instead they use the IP of the rendezvous point to determine their
incoming interface and perform any reverse path forward check.
This is commonly known as the shared or any source tree
with the RP as it's target or root.
This makes sense, as if we don't know what the IP of the source is,
we should be forwarding PIM joins to the device that
will receive source registration.
When the OIL, or Outgoing Interface List,
to the RP is completed, we have a complete path back to the interested receivers.
The traffic will flow along each router and path according
to its own OIL built from the PIM joins.
When the traffic is delivered to the Last Hop Router,
something magical will happen.
Now the LHR learns the IP of the source.
The LHR now sends an S, G, or source PIM join directly towards the source.
Because the source IP is now known,
it becomes the target of the unicast best path decision to pick an
incoming interface for the routers along the way.
Note that this PIM join process is separate from the *,G
any‑source PIM join process involving the RP.
And in fact, while this is happening,
the multicast traffic is still flowing down along that shared
tree while the new path is being built.
Once the FHR receives that PIM join,
it will add that downstream interface to its OIL,
and traffic will flow along the new path.
Each receiver will temporarily receive two multicast streams,
one flowing along the *,G shared tree and one from the source via the S,
G source tree.
Each router using the *,G shared tree will send a PIM prune
upstream towards the RP to stop the flow of multicast.
This is traffic optimization because now that the source is known and the S,
G source tree builds, the rest is cleaning up.
If the RP removes all interfaces from its outgoing interface
list due to receiving PIM prune messages,
it will also send its own PIM prune upstream towards the First Hop Router.
If the OIL towards the RP is not using the same interface
as the one on which it received the S, G source join,
the FHR will prune that interface,
and the optimal traffic flow has been achieved.
The end state of any‑source multicast is the same as dense mode multicast,
an optimal multicast traffic flow based on the best path between sources and interested receivers.