In this demo, we'll see the PIM‑DM flood and prune process.
We'll see how flooding makes routers aware of the sources,
how multicast routers with no receivers stop the flow of multicast, and how
the routers that do have receivers keep the traffic flowing.
We're going to send traffic from our source server to the multicast
group 239.3.2.1, and watch what happens in the network.
We have one interested receiver connected to the Last Hop Router. And
while the receiver has sent an IGMP report to the LHR, it's not aware
of any sources sending to that group yet.
Before we send any traffic, we can see that LHR's mroute table
has a *,G entry for the multicast group.
The receiver has sent in any source IGMP report for the group, and the LHR
is now waiting to learn of a source sending to that group so it can deliver
the traffic out of its alchemy interface list.
If we look further upstream, MCAST5 will be in the
forwarding passed to this receiver.
MCAST5 has no entries in its multicast routing table for the group.
This is because in PIM‑DM, PIM joins are not forwarded up towards the source.
It also doesn't have any S, G entry because multicast
traffic hasn't been flooded yet.
MCAST3 will not end up being in the path of traffic delivery, so it's a
good candidate to see what happens when a router completely prunes
itself from the stream. Verifying quickly,
we can see that there is no multicast state for the group in MCAST3 either.
Now let's turn on some PIM debugs for both routers so we
can see the difference in behavior.
Alright, and now it's time to send some traffic and then inspect the debugs.
We see a PIM assert in this debug, but we haven't talked about that yet.
The PIM assert will be covered in far more detail later.
But for now, it's just important to know that in dense mode, the PIM
assert is a message that allows metrics to the source to be compared
for each PIM neighbor on the segment.
Based on that comparison,
the function of DR can change to the closest router for that specific
source and group pair. In this case, because MCAST3 has the exact same
metric to the downstream segment as MCAST4, and MCAST4's IP address is
higher, the assert was lost.
This triggers MCAST3 to send a prune message to the segment,
as it will not be delivering multicast.
Looking through the other interfaces in the debug,
we see a repeat of this behavior from other routers and on other interfaces.
Each router sent traffic on every interface that was not the RPF
incoming interface to the source, and now each router must send prunes
to the others to stop the traffic delivery because otherwise the
outgoing interface list stays active.
We don't see the interface gigabit 3 in this debug
because if we check the enroute table,
we see the gig 3 was the incoming interface.
There's more here, specifically around MCAST5 response to
seeing the prune method on the shared segment.
But for that, we should go to MCAST5 itself.
I'll skip most of the repetition and focus on what
matters most from the MCAST5 perspective.
If MCAST5 does nothing,
the upstream DR MCAST4 will prune the segment from the outgoing
interface list so it sets a timer waiting to see if anyone else on the
segment will send a join first. And then it sends its own PIM join,
asking to keep the interface active on MCAST4's OIL, essentially
overriding the prune message from MCAST3.
This is because it did not receive a PIM prune from
the Last Hop Router downstream.
Since MCAST5 still has active interfaces on its OIL,
it needs to keep the multicast forwarding.
This is an uncommon situation you shouldn't see in the real world as much
these days. We don't often have multiple routers attached to multi‑access
segments, so it's less likely to run into situations where routers disagree
on what segments should receive multicast.
However, when it does happen, it can be very hard to troubleshoot without knowing how it works.