In this demo,
I'll demonstrate how to get IPv6 multicast running in our lab
with PIM any‑source multicast. I'll configure the receiver
using Multicast Listener Discovery,
then send traffic to the multicast group from the source.
We'll check the multicast state in the rendezvous point at the end. The
process for any‑source multicast hasn't changed at all.
For the demo, we already have an RP defined and
shared using the bootstrap router.
This will focus on how to configure receivers, sources, and check the
multicast state in case anyone wants to test in their own lab. To get
this started, we can configure the receiver.
We are only running IPv6 addressing in this lab, as you can see here. We'll send
an MLD report for this multicast group and then jump over to the last hop router
to verify it was received. Here on the last hop router, we'll just look for that
MLD report to have been received, and it looks like it was. Since the LHR is
aware of the rendezvous point,
we should have a reasonable expectation that the PIM Join was forwarded, but
our next stop should be to check. Looking at the IPv6 mroute table, we do see
an any‑source PIM Join for the multicast group here.
I'm using the admin‑local scope because of the size of my multicast deployment.
There's no source sending yet, so we'll send traffic next.
Once again, the source doesn't have to participate in
multicast control plane at all.
It can simply send traffic to the group and rely on the
network to handle its delivery. When we ping using IPv6, we
need to specify the source interface.
Okay,
we got replies from the receiver, so we know the multicast is
working. Now to check the LHR and see if we swapped from the shared
tree to the source tree. And here we are,
the LHR has learned the source and joined the shortest path tree.
This behavior is exactly like the IPv4 version of PIM
any‑source multicast. In the next section, we'll tackle a way to select an RP that is entirely unique to IPv6.