Next,
I'll demonstrate the basic IGMPv2 join in leave
processes in the Globomantics network.
In the previous module, we saw the basic query and join process with IGMPv1.
The comparable IGMPv2 process is very similar,
so I'll skip the repetitive steps.
You can trust me that the Globomantics client is still requesting
multicast on groups 239.1 .1 .1 and 239.2 .2 .2.
I'll enable IGMP debugging on R1 using the same
command demonstrated in the IGMPv1 demo,
so we can see the membership queries and reports.
Well, this looks familiar.
The IGMP querier sends an IGMPv2 general query and the client
response with a membership report for group 239.1 .1 .1.
The main difference here honestly is the v2 text instead of v1.
The process is generally the same,
although we will later see how the packet formats differ a bit.
Let's quickly confirm that the router has properly
accounted for these membership reports.
Okay, we see both 239.1 .1 .1 and 239.2 .2 .2 here; that's a good sign.
Now let's do something more exciting and exercise IGMPv2's secret weapon.
I'll swing over to the Globomantics client and delete
the IGMP join for group 239.1 .1 .1.
I will re-enble debugging on R1 to capture the result.
Okay, swinging back to R1 now,
we see a leave message from the Globomantics client for group 239.1 .1 .1.
The router immediately replies with an IGMPv2
group-specific query for 239.1 .1 .1, which asks the question,
okay, I know 10.1 .4 .4 doesn't want this traffic anymore,
but does anyone else?
The router may send a few of these queries just to
ensure the clients get the message.
Receiving no replies,
the router purges 239.1 .1 .1 from the client LAN interface,
thus stopping all multicast flow. Let's dig into the magic of the leave message next.