In my last post, the first in a series about IP multicast, I tried to make the subject as painless as possible. You see, it’s been my experience that a great many network engineers get very nervous when faced with the prospect of having to work on IP multicast. Why? My guess is that it’s a matter of familiarity and practice. Familiarity is gained through education on the subject and hands-on, deliberate practice.
This post is dedicated to the Internet Group Management Protocol, or IGMP. IGMP v2 is an IETF standard defined in RFC 2236 (v3 is defined by RFC3376). When I refer to IGMP in this post, I am referring to Version 2, and I will annotate when I refer to Version 1 or 3 respectively.
Let’s start at the beginning: IGMP v1 had only two message types, a membership query and a membership report. A host would send out a membership report when it was interested in a particular group, and the router would send out a membership query when it wanted to know if hosts on the LAN were still interested in receiving a group.
This version was not able to efficiently or quickly determine when hosts on the LAN no longer wanted to receive a certain group; the router would send out membership queries for a specific group, and if there was no reply from any of the hosts after three consecutive queries, the router would stop forwarding. That’s pretty wasteful of router CPU cycles.
Since efficiency is a central them in multicast, a new version, v2, was born and set out into the world in RFC2236. Version 2 has four IGMP messages: membership query, version 1 membership report, version 2 membership report, and leave group.
The membership query message is unchanged, with the router sending out the message verifying that at least one host is still interested in each specific group. If multiple hosts on the LAN respond, the router doesn’t listen to any of the responses but the first one it receives. As long as one host is still interested, the group is active on the router.
The membership reports allow the hosts to specify which version (1 or 2) they ‘speak’. This is a backward compatibility function, since some hosts on the LAN might not have gotten the memo about the new IGMP version.
The message that comprises the biggest difference in v1 and v2 is the leave message.
In IP multicast, there are two really important messages, called joins and leaves. You will see these terms a lot, and not only in relation to the IGMP protocol, but also when looking at PIM on a router.
In IGMP v2, the addition of the leave message is in place to reduce the latency between when the last host on a LAN stops wanting to receive traffic from a specific group, to when the router stops forwarding the traffic for that group. You’ll recall that the router waits three consecutive query message cycles before discontinuing forwarding for a specific group. With the leave message, hosts on the LAN can now tell the router that they are not interested in receiving traffic from a specific group any longer. The router, in turn, sends out a group-specific membership query to the LAN, and if no other hosts respond that they still want the group traffic, the router times out the group immediately and the unwanted traffic stops being sent. That’s way more efficient, right? I agree!
IGMP v3 is out there, but I have to be honest here in the interest of full disclosure: I have not used it or worked with it yet.
IGMP v3 adds some majorly cool functionality, in that the host on the LAN can now send a message to the router specifying not only from which group it wants to receive traffic, but also what SOURCE HOST it wants to receive that traffic from. This is referred to as Source-Specific Multicast (SSM) and it is a really major step in the efficiency and even security of IGMP. Being able to say ‘I want that traffic from that source’ is really pretty different from the best-effort nature of IP multicast.
Again, in the interest of full disclosure, I have to admit that I have no idea about what the implementation of IGMP v3 would entail in my network, which is all IGMP v2 (and humming along nicely!).
An unfortunate default behavior of a LAN switch, after all this work to make IGMP efficient, is to flood all the ports on the same LAN with multicast traffic. That is wasteful and undesirable, and leads us to our next topic: IGMP snooping.

IGMP snooping requires the LAN switch to look into each multicast packet and ascertain which host on the LAN is asking to receive which group from the router. The LAN switch can then associate the host’s port to the group it is receiving traffic from. This stops the flooding of the multicast traffic to the rest of the hosts on the LAN.
Beware though: IGMP snooping is processor intensive and can easily cause severe performance issues on lower-end switches.
So, there you have the very over-simplified, high-level view of IGMP. Remember that leave messages are central to IP multicast, and that they are the main enhancement added in IGMP v2. IGMP snooping can be a good thing on a LAN switch, but can also add its own problems by taxing the switch’s resources.
As always, please lab it up if you have questions, and your mileage may vary!
See, that wasn’t so bad now, was it?




Recent Comments