In this module,
we'll be discussing PIM operations that aren't dependent
on a particular mode of implementation.
Topics we'll discuss include what is protocol independence?
How is a multicast best path determined?
How are multicast loops avoided?
There will also be command line demos of establishing PIM neighbors,
as well as demonstrations of how each segment elects a PIM designated router.
Finally, we'll open Wireshark and inspect a PIM Hello packet in detail.
What does it mean to be protocol independent?
In the case of PIM,
what it means is that the best path decisions around
connecting the cast sources with receivers will rely on a
unicast routing table built from anything,
connected routes, static routes, OSPF, BGP,
RIP or even ODR.
All that matters to PIM is that the unicast RIB has routes to
follow and that a best path has been determined.
In a traditional unicast routing environment,
each router makes a routing decision based not on the source IP of the packet,
but on its destination IP.
Every router consults its RIB for the next hop to reach the destination,
and hop by hop, the traffic gets delivered.
Now for source‑based routing, we simply can't think the same way.
Multicast routing is source based.
What that means is that in the case of multicast,
the only thing we know for certain is the source IP.
And to build a multicast flow,
we need to ensure that the routers between the sources and receivers
become aware of where the packets are coming from,
as well as where they are going.
We talked about how IGMP and MLD reports are converted to PIM joins,
but not what a PIM join is or what it does.
A PIM join is the method by which PIM communicates a receiver's
interest in multicast once it leaves the local segment.
PIM is router‑to‑router signaling instead of receiver‑to‑router.
PIM joins use the unicast routing table to determine the best path to
either the source of the multicast traffic or to the router,
which knows about the sources referred to as the rendezvous point.
Which one the PIM join goes to depends on the implementation of PIM,
and we'll cover those more in their respective sections.
To avoid routing loops, multicast utilizes some very simple rules.
For any given source in group pair, commonly referred to as the S,
G,
each router can only have one interface determined to
be the best path to that source.
In a case where a source is either unknown or not requested,
the best path to the rendezvous point will be determined instead.
By default, there is no concept of equal‑cost multipathing, or ECMP.
If multiple paths exist in the unicast RIB,
PIM will pick the interface with the highest PIM neighbor IP address.
There are improvements in newer code among some vendors to enable
load sharing based on some combination of source,
group, and neighbor, but that's beyond the scope of this course.
Whatever interface is chosen as the best path upstream is known as
the incoming interface in multicast terminology,
as it's the interface on which the router expects
to receive the multicast stream.
The PIM joins themselves determine what interfaces are marked
for downstream multicast traffic delivery.
When a router receives either an IGMP MLD report or a
PIM join for the multicast stream,
it adds that interface to what is called the OIL,
or the Outgoing Interface List.
An OIL exists for each multicast group and source pair.
If a source is unknown, it instead tracks the any source PIM join,
as what's called a *,G entry.
The point of an OIL is to establish where the multicast stream will
flow downward from the source towards the receivers.
Each router will wait for a join to determine if there are
any interested receivers downstream, and if so,
they will forward their own PIM join upstream.
The second half of route loop avoidance is the reverse path forwarding check.
This check exists because of the protocol independent nature of multicast.
PIM has no loop avoidance mechanism in its own tables.
It relies entirely on the unicast best path decisions.
The RPF check is a simple piece of logic built into
all multicast forwarding decisions.
When a router receives a multicast packet for delivery downstream,
it consults the unicast RIB.
If the multicast traffic came in on the same interface that
the router would use to reach the source,
the packet is accepted and forwarded.
If the packet is received on a different interface,
that might indicate a multicast routing loop,
and the packet is discarded.
Why might there be disagreement between the incoming interface and
the best path decision of the unicast table?
Let's suppose that some network instability causes the routes to change
the best path to another interface on the router.
Until the unicast best path converges on a new path and the multicast
routing table selects a new incoming interface,
any multicast traffic delivered to the router will be discarded
in case forwarding it might cause a loop.
The RPF check is the last line of defense against multicast forwarding
loops and can also be a major headache to people just learning multicast
and who don't yet understand how it works.
There is a handy command to troubleshoot what the RPF
determination is on each router for a particular source.
We can see the RPF interface, the PIM neighbor IP,
what route was used to make the RPF decision, and the source of that route.