I'll show how the leave message works to quickly cut
off multicast on the live network.
I want to quickly demonstrate multicast flow again,
except this time I'll highlight the power of the IGMPv2 leave message.
I've rejoined the Globomantics client to group 239.1 .1 .1 already,
so multicast should be functional.
I'll start a long ICMP ping test to check multicast flow.
Okay, we see replies from the Globomantics client,
just like we did in the IGMPv1 traffic flow demo.
Let's jump over to R1 and verify packets are increasing.
So far, so good.
Everything works.
Now let's leave group 239.1 .1 .1 on the client.
To do that, I'll use the no command we saw earlier.
Now let's jump to the server.
Those ICMP test packets should not be getting replies anymore.
As expected, we see only periods, which means request timed out in Cisco iOS.
The multicast isn't flowing anymore because it doesn't need to.
We can confirm by checking the counters on R1 once more.
Let's issue this same command as earlier a few times
and see if there are any changes.
The packet counters are frozen at 60, implying that 60 packets were sent,
and they have since stopped.
It looks like the IGMPv2 leave message did its job correctly.
To wrap up, let's quickly compare the versions of IGMP covered so far.
I don't like to recite RFC specs in my courses,
but I will add them here for quick reference.
IGMPv1 had no way to signal disinterest in a group,
but IGMPv2 added the leave group message.
This reduces the leave latency,
or time between a client leaving a group and the router knowing it.
IGMPv1 defined only a general query to ask who wants multicast,
while IGMPv2 offered group-specific queries to ask who wants multicast on
a specific group in response to leave group messages.
IGMPv1 zeroed out the IGMP code field,
but IGMPv2 repurposed it to constrain clients on a tight
time window when replying to queries.
All in all, IGMPv2 was a widely deployed protocol in its day for good reason. In the next module, we'll explore how it can be improved even more.