Are you ready for our first IPv6 demo?
Let's explore how MLDv1 works in our network.
This is our first IPv6 demo, but fortunately,
MLDv1 is very similar to IGMPv2, and the only differences here are syntactic.
The logic is identical.
First, I'll show the configuration on the client.
It is currently joining FF08::1 and FF08::2,
2 organization local multicast groups.
Let's go to R1 so we can enable MLD debugs.
On R1, I will limit our debugging to FF08::1,
just to keep the chatter down, much like I did for IGMPv2.
Unfortunately, when we limit debugging this way,
Cisco iOS doesn't show the general query.
Trust me, it does get sent.
Even if you don't trust me, we will see it in the packet capture soon.
Okay, after the router sends the general query,
we receive an MLDv1 report from the link local address FE80::4,
which is the Globomantics client.
The report message is joining group FF08::1.
The multicast routing information base, or MRIB,
is a synonym for multicast routing table,
which we saw in the IGMP debugging.
The MRIB is successfully updated according to these debugs.
How can we confirm if R1 is properly processing these
groups in addition to the debug?
I'll use a show command similar to the IGMP ones, except specific for MLD.
We see both FF08::1 and FF08::2 here, both reported by the Globomantics client.
Looks good to me.
Let's quickly test the MLDv1 done mechanism,
which operates like the IGMPv2 leave mechanism.
I'll enable debugging again on R1,
then swing over to the Globomantics client and remove the MLD join for FF08::1.
We are back on R1 to examine the debugs.
We see that a leave was received, which is a slight misnomer,
since we know the message is technically called a done message within MLD.
Either way, the done message was for group FF08::1.
The router response, as expected, with a few group-specific queries,
to ask other clients, does anyone else want traffic for group FF08::1?
When it receives no reply,
it purges the MRIB of this multicast state and stops sending traffic to the client LAN segment.