IGMPv2 brings some major improvements to the IGMP protocol family,
and this module focuses specifically on this new version and its new features.
In the previous module, we learned the basics of IP multicast.
What I did not stress are the problems with IGMPv1.
I'll begin by explaining the drivers for IGMPv2's creation.
Then, I'll detail how these critical new features work with simple flow diagrams.
Next,
we'll head into a live demonstration to see these new features in our network.
Given that IGMPv2 introduces some new packets,
we will explore those in detail using Wireshark.
Let's start with a small IGMPv1 problem.
Because IGMPv1 relies on existing multicast routing
protocols to determine which router is responsible for
sending queries onto LAN segments,
there is not much consistency in production environments.
Sometimes you end up with multiple routers sending queries at the same time.
Let's see how it works.
Like the PIM overview in the last module,
I'll use blue arrows for signaling and orange for traffic flow.
Both routers on the LAN send IGMP queries onto the network,
certainly questionable practice.
Two of the three clients are interested in multicast and respond
with IGMP membership reports or join messages.
Multicast flows back down through one of the routers,
typically the one closer to the source.
The fact that the other router issued a query has no operational
relevance and only creates unnecessary chatter.
Also, each client now has to reply to twice as many queries.
Now onto bigger problems.
IGMPv1 only defined two messages, a join and a query.
What happens when a client turns the computer off?
Suppose there is only one client currently viewing the fitness program.
The client then powers down her laptop.
The multicast flow continues until the multicast state timer expires,
often several minutes.
After that expiration, the traffic finally stops flowing. The client has no way to inform the router that it no longer wants multicast.