In this demo,
we'll focus on how the multicast state tracking and traffic flow
differs from other implementations of PIM.
We'll start with the IGMP and PIM join at the last hop router and
then do the same from the first hop router.
We'll also look at the router providing the RP link and see how
traffic flows up and down the shared tree.
As a refresher, this is our lab environment.
As we're using bidirectional PIM,
we'll have two sources and two receivers in this demo so we can see
how BIDIR‑PIM treats traffic flows for scaling.
First, we'll just verify that both ends are sending in any source IGMP report.
The LHR here is getting the report, and here's the PIM join.
This mroute table looks very different than the ones we've seen so far.
We'll spend some time with that after we verify the
same setup on the other side.
Remember that though the hostname says LHR and FHR,
that both routers have sources and receivers attached,
so they're pulling double duty.
This looks good.
Now to check the mroute table.
There's a PIM join here that wasn't in prior implementations,
and that's the *,G entry for the whole multicast range.
The reason this is here is because we carved the whole
range to act as a bidirectional PIM group.
If we were more selective,
we'd see a *,G just for the groups running in BiDir mode.
This entry has a B flag, which indicates it's a BIDIR‑PIM join.
There's no outgoing interface list here because no receivers
have sent a report for that particular *,G.
What we see instead is the PIM join that was sent for 239.3.2.1.
That entry does have an OIL built based on having received an IGMP report.
Notice that one of the outgoing interface entries
is the Bidir‑Upstream interface.
Traffic from a source will always be forwarded in
this matter towards the RP link,
and it will flow back downstream based on what PIM joins were built to the RP.
Let's look at the RP now.
The PIM join for the multicast group has reached the RP from both sides,
Gig3 facing the LHR router and Gig1 facing the FHR router.
If only one side were talking,
this would have just one outgoing interface aside from the
ever present PIM Bidir‑Upstream interface.
While the Loopback99 link is configured as the closest link to the phantom RP,
the PIM joins have come far enough.
Traffic forwarded from both sources up the Bidir‑Upstream interface get to
this router and then flow downward according to the OIL.
This is a bit of a brain buster to understand,
especially with how different it is from other PIM
implementations we've covered already.
The main things to remember are that the DF election is like spanning tree
and that the RP can be a link instead of an actual router, and only shared trees exist in BIDIR‑PIM because we don't track sources.