Protocol Independent Multicast is the Layer 3 router‑to‑router protocol used
to build the multicast control and data planes. Unlike receiver signaling
like IGMP and MLD, PIM is primarily concerned with ensuring that multicast
routers can receive and forward multicast traffic in a way that avoids loops
and optimizes the traffic flows.
Each implementation of PIM is unique in its approach to
solving the main problem of multicast,
which is how to pair sources with receivers in the most optimal way possible.
This means that there is no default PIM RFC, but instead there are
multiple PIM RFCs, covering different types of PIM deployments.
Here's an updated list of the RFCs and their PIM deployments. By
default, routers aren't paying attention to multicast traffic that
doesn't concern them directly.
If we want multicast data to flow from source to receiver,
we need to turn on the multicast data plane functionality of our routers.
Listed here are the default link local multicast groups for IPv4. Here are the
same groups for IPv6. In IPv6, the scope determines whether it is node local,
link local or even larger. We'll cover scope later when we talk about IPv6
multicast, but here's a small taste.
The FF here signifies a multicast address, and the
02 indicates a link local scope.
Other than that, these are identical to the IPv4 groups, which also
end in 1 for all nodes and 2 for all routers. PIM uses dynamic
neighbor discovery and has its own reserved multicast address
group. Here are the multicast addresses for the all PIM routers
group. Just like before,
the groups are equivalent between IPv4 and IPv6. Because IPv6 uses
hexidecimal addressing, this D is equivalent to 13.
It's important to remember that multicast forwarding is a non‑default
feature, and this means two things: that the feature needs to be
activated on each interface on which we plan to forward multicast
traffic and that any router cannot assume the multicast forwarding
capability of any other router.
Does that sound confusing?
Let's talk about another non‑default feature, dynamic routing
protocols. To dynamically discover neighbors on a link, the routing
protocol usually joins a reserved multicast group for that protocol
and sends its packets to that group.
That group is link local only, but if a neighboring router on
that link is also configured for that routing protocol and is
also using dynamic neighbor discovery,
they will receive each other's multicast packets and build
an adjacency. If that protocol isn't configured or if
dynamic discovery is turned off,
the router isn't tuned to that group and won't respond
to hello packets sent to the group.
PIM adjacencies allow routers to build a multicast control
plane, but instead of sharing routes,
it's focused on multicast state tracking of sources,
receivers, and which interfaces will be involved in
forwarding multicast traffic.
There is a slight disconnect in some vendor implementations in which
PIM can be configured and control plane adjacencies built without the
multicast forwarding feature being active.
Anyone who's ever implemented multicast, this author
included, can probably attest to the frustration of
troubleshooting a multicast flow problem,
only to find that some router in the forwarding path had a PIM adjacency built,
but did not have the multicast forwarding feature enabled.
Let's summarize what we've learned so far.
We started by examining what multicast applications
are and what problems they solve.
We moved on to cover how sources and receivers are at
the heart of any multicast deployment.
Briefly,
we discussed the host to router or receiver signaling using IGMP and
MLD. And last, we discussed the role of router‑to‑router signaling that PIM performs in multicast deployments.