No PIM deep dive would be complete without at least talking about the
defunct all but deprecated sparse‑dense mode. I won't spend a lot of time
covering it because there's actually very little to cover, but I think
simply omitting it would be a mistake.
PIM sparse‑dense mode was developed with the idea of being
able to get the best of both worlds.
Some groups, which needed to run in dense mode, could flood
multicast while the lion's share of traffic could work in a sparse
mode manner and leverage a rendezvous point.
In practice, the real use case for PIM sparse‑dense mode was a proprietary
dynamic RP discovery solution called Auto‑RP. Auto‑RP is a solution to
allow dynamic RP discovery that was developed before the PIMv2 standard
introduced bootstrap router. Instead of a bootstrap router, Auto‑RP uses
what's called a mapping agent.
The mapping agent serves the same function as the BSR, to collect candidate
RP advertisements and then elect and advertise a winner.
Auto‑RP has a problem to overcome, however. Because it was developed when
there was no native mechanism to allow PIM routers to learn about the
mapping agent like BSR, every PIM router instead tunes to the RP
announcement dense mode group, 224.0.1.40. We've seen this in previous
demonstrations when looking at the mroute table. When a candidate RP wants
to announce its candidacy,
it has no idea what the mapping agent IP address is, so it sends its candidate
advertisement to a reserved dense mode group, 224.0.1.39. Only mapping agents
and candidate RPs are listening to this group.
But because it's dense mode, it's flooded everywhere.
In this way, a mapping agent learns about candidate RPs and what multicast
groups they will cover. When the mapping agent selects a winner,
it floods that RP information to the 224.0.1.40 dense mode group,
so all the other PIM routers learn about the RP.
The Auto‑RP feature is still widely used today,
but enhancements to the code have made PIM sparse‑dense mode
largely irrelevant. Recall that dense mode is an inefficient and
sometimes dangerous method of sending multicast traffic, as it
can result in routing loops.
The addition of commands like Auto‑RP listener have allowed more selective
use of groups without the need for dense mode flooding.
Another reason PIM sparse‑dense mode was deprecated was if any group
wasn't covered by an RP due to misconfiguration or RP failure, those
groups would instead be flooded via dense mode.
This behavior is usually not desired.
In short,
sparse‑dense mode combines uncertainty and unpredictability and offers no real
value in a common network where Auto‑RP now works fine with sparse mode only.
Outside of very corner cases, it's not recommended, as it can cause more
problems than it solves. In this module, we talked about the basic operation
of a PIM sparse mode deployment.
We saw demonstrations of the entire process, starting with the
election of a rendezvous point using bootstrap router.
Then we saw the generation of multicast traffic and
signaling for it by a receiver.
We also saw a demonstration of the PIM join process used to build multi‑cast
flows and a PIM assert to optimize the flow in certain corner case situations.
We then moved on to analyze the PIM packets relevant to the deployment,
starting with the candidate RP advertisement and bootstrap, the PIM register
and register stop, the shortest path switchover from shared tree to source
tree, and the PIM assert packet.
We finished with a quick detour to talk about the legacy PIM sparse‑dense mode and Cisco proprietary Auto‑RP solution.