Let's run MLDv2 in our network between the
Globomantics client and its first hop router,
then see what happens.
Because MLDv2 and IGMPv3 are logically equivalent,
I'll show a similar flow for this demonstration,
although we will likely go faster.
The Cisco configuration for IPv6 SSM groups uses an
axis list to enumerate sources,
so let me show the relevant configurations quickly.
I've added a third group,
FF38::3 and organization scoped SSM group from 2 sources,
FC00:10:2:5::5 and FC00:10:2:5::6.
The latter is a fictitious source for demonstration only.
Because Cisco's MLD implementation includes many link local multicast joins,
I'm going to target only the SSM group for this demonstration.
That's the most interesting piece, to be honest.
I'll first enable debugging on R1 to capture any
interesting traffic that comes across.
Let's examine the detailed output.
We still don't see any membership queries sent by R1,
but now we don't even see the membership report sent by the client.
Again, these issues are cosmetic because we know the messages exist.
The debug likely doesn't print them because they are not specific to FF38::3,
but are generic packets.
I just want to point out that the Globomantics router is now aware of two
sources for this specific group ending in ::5 and ::6.
Both have been added to the MRIB successfully.
Now that we have SSM support,
I'll use the detail option to reveal the different group record
modes and specific sources where necessary.
We can clearly see both the ASM groups of FF08::1 and FF08::2,
operating in EXCLUDE mode with no specific sources.
We also see the SSM group of FF38::3 from our 2 Wired
Brain Coffee multicast servers.
This group operates in INCLUDE mode,
only desiring multicast from the specified sources.
Next, I'll remove the sequence 10 access list entry from the client.
This causes the client to send an MLDv2 done message,
although you can probably guess that it isn't a literal done message
based on what we learned about the IGMPv3 leave process.
We have a lot to sort through.
As we saw with MLDv1,
Cisco's MLD debugging doesn't always reveal all the
messages as it did with IGMP.
We don't see the MLDv2 message from the client to router
signaling disinterest in a source group pair,
but we do see all the follow-on actions.
Again, don't worry, we will see this message in the packet captures.
The router sends a few source and group-specific queries right
away for group FF38::3 and source FC00:10:2:5::5,
which we expect.
Cutting through the verbose low-level processing details,
we see that the MRIB state for this source group pair was successfully updated.
Specifically, the state was removed from the MRIB,
indicating that there are no more clients interested in
receiving it on the client LAN segment.
Pretty easy, right? Same exact logic as IGMPv3.