In this demo,
we'll see how the routers extract the RP information from the
multicast group and use that to determine where to forward
PIM joins and multicast streams.
Here, on the last‑hop router, we don't have any rendezvous point configured,
but we will forward the PIM join from the downstream receiver anyway.
Let's look at the mroute table,
and then I'll show the debug where the MLD report is converted to
a PIM join and the RP address is extracted.
This any‑source PIM join is being sent to an embedded RP group.
Notice that despite there being no RP configured on the LHR,
it shows the correct RP address and has used that information determine the
incoming interface and the reverse‑path forward neighbor.
Here we see that the MLD report is now a PIM join with certain flags,
specifically, the RPT bits we talked about in the last video, as well as a
wildcard bit that marked this as an any‑source join. The S is for sparse mode.
This RP address was correctly derived from the group.
Let's go look at the rendezvous point and see if it received
our PIM joins. MCAST1 is the only router that must be
configured with an RP address just so it knows that it should
be servicing the multicast groups.
If we look at the mroute table,
we should see the PIM join from the last‑hop router. Notice, the Outgoing
interface list is based on having received the PIM join, so we know this
was successful all the way up, despite none of the other routers having a
local RP configured or learned.
Next is to look at the first‑hop router. We'll start
generating some traffic and see what the FHR does.
We can see that the S, G was created based on the traffic from the source.
We have an RPF neighbor pointing towards the RP.
If we look at the route mapping, we should get more details.
Here, we see the group map for our embedded RP group. The RP was
successfully extracted and listed, and the info source is embedded, and this is what we expect to see.