This demo is going to show a very uncommon issue that occurs based on having a
shared segment with different preferred paths for the (*,G) any‑source joined
towards the RP and the (S,G) join towards the source.
The PIM Assert affects a shared segment where the best path to
a rendezvous point is through one router,
but the best path to the source itself is through another.
Remembering the PIM sparse mode process should help make this problem clear.
In this topology, MCAST4 is the designated router for the segment,
so it will be the router elected to forward PIM joins towards the RP.
When a router downstream from MCAST5 signals an interest in multicast,
and MCAST5 forwards the any‑source (*,G) PIM join,
that is forwarded to the DR to be forwarded to the RP.
When the PIM join reaches the rendezvous point and the source is learned,
traffic begins flowing down the outgoing interface list back to MCAST5.
So far this is normal.
When MCAST5 learns the source IP,
it needs to send an (S,G) PIM join towards the source.
In this specific case,
we've adjusted the metrics so that the path to the
source is best reached through MCAST3.
MCAST5 will send the PIM join upstream,
but MCAST3 will Assert that it's better positioned to deliver that traffic.
Via a PIM Assert message,
MCAST3 will become the functional DR for this flow and
activate its outgoing interface list,
sending on the (S,G) PIM join upstream to the source.
MCAST4 will receive a Prune message from MCAST5,
and ultimately the optimal delivery path will be through the
different router attached to the shared segment.
When we start, MCAST5 has received the downstream PIM join from the LHR,
or last hop router, and has forwarded it towards the RP.
There's no source traffic at this point.
Let's check some assumptions about how the flow of traffic stands.
If we look at MCAST5 mroute table, we can see the (*,G) entry.
We can see that this is a sparse mode any‑source joined.
The rendezvous point is 1.1.1.1.
The incoming interface is gig 1, which is that shared segment.
The RPF,
or reverse‑path forward neighbor is the designated
router for the segment MCAST4.
The outgoing interface list is facing downstream towards the last hop router.
Let's look upstream at MCAST4.
It's the same story here.
We have a PIM join forwarded up to the rendezvous
point out of the incoming interface,
and the outgoing interface points downstream to the shared segment.
What about MCAST3?
Well, it looks like there's nothing at all here.
Before we start traffic and see what happens,
we'll turn on the PIM debugs on all the routers.
Okay,
remember that the path to the multicast source will be preferred to
MCAST3 from the shared segment so that when MCAST5 learns about the
source and sends that (S,G) PIM join,
MCAST3 will Assert its better path to the source and take over the forwarding.
As you can see, we get an (S,G) join from MCAST5 for the source,
after which MCAST3 forwards the (S,G) join upstream and
adds gig 1 to its outgoing interface list.
It also sends the PIM Assert message onto the shared segment.
At the same time,
MCAST4 was delivering multicast over the shared
tree through the rendezvous point,
and we see that triggered PIM Prune message from MCAST5 to MCAST4.
Let's check the mroute table on all 3 routers.
MCAST3 has the (S,G) entry and is actively delivering
traffic out of its outgoing interface list.
Notice the A here, which shows that this is the result of a PIM Assert.
MCAST4 has the (S,G) entry also,
but notice the outgoing interface list shows null.
This is because when MCAST3 won the PIM Assert,
MCAST4 removed gig 1 from its own OIL.
MCAST5 shows the (S,G) and the upstream neighbor as MCAST3.
The T flag shows that it's on the source tree of the shortest path.
We'll see PIM Assert packets in more detail when we start analyzing the packet captures.