IGMP

IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Hosts identify the multicast groups they wish to join by sending IGMP messages to their local multicast router.

IGMP is always the language spoken between hosts and routers when it comes to IP multicast.

IGMP messages are encapsulated in IP headers like ICMP (with a protocol number of 2), but unlike ICMP the messages are limited to the local data link. This is guaranteed as the TTL in the IP header is always set to 1.

There are versions 1, 2 , and 3 of IGMP. In IOS you can change the version with the command ip igmp version.

We will see later that IGMP version 2 is enabled by default when PIM is enabled on a router interface.

IGMP Version 1

In Version 1 of IGMP, the following two types of IGMP messages exist:

  • Membership query
  • Membership report

Multicast reports are sent out by individual hosts indicating their interest to join a particular multicast group. The TCP/IP stack running on a host automatically sends the IGMP Membership report when an application opens a multicast socket.

Multicast sessions are identified in the routers by a (source, group) pair of addresses, where the source is the unicast address of the session’s originator, and the group is the multicast group address. If the local multicast router does not already have knowledge of the multicast session the host wants to join, it sends a request upstream toward the source. The data stream is received, and the router begins forwarding the stream onto the subnet of the host that requested membership.

The destination address of the Membership Report message’s IP header is the group address, and the message also contains the group address. To ensure that the local router receives the unsolicited Membership Report, the host sends one or two more duplicate reports separated by a short interval. RFC 2236 recommends an interval of 10 seconds.

The router periodically sends out an IGMP membership query to verify that at least one host on the subnet is still interested in receiving traffic directed to that group. Each query contains a value called the Max Response Time, which is always 10 seconds in IGMPv1. (specified in units of tenths of a second). When a host receives a query, it sets a delay timer to a random value between 0 and the Max Response Time. If the timer expires, the host responds to the query with one Membership Report for each group to which it belongs.

Because the destination of the Membership Report is the group address, other group members that might be on the subnet hear the report in addition to the router. If the host receives a Membership Report for a group before its delay timer expires, it does not send a Membership Report for that group. In this way, the router is informed of the presence of at least one group member on the subnet, without all members flooding the subnet with Reports.

When there is no reply to three consecutive IGMP membership queries, the router times out the group and stops forwarding traffic directed toward that group.

IGMPv1 uses only 1 type of Router Query:

  • General Query

There is no Group-Specific Query like we will see in IGMPv2 since there is no host Leave Group message.

IGMP Version 2

IGMPv2 is backward compatible with Version 1. There are three message types in IGMPv2 that hosts use compared to the one host message types in version 1.

  • Version 1 membership report
  • Version 2 membership report
  • Leave group

Hosts use Version 1 and Version 2 memberships reports as well as leave group messages. Routers use the Membership query message type.

The main difference between version 1 and version 2 is the Leave Group message in version 2. The leave group message allows a host to explicitly inform a router that it is leaving a multicast group. This reduces the leave latency as compared to version 1 with the result being that unnecessary traffic is stopped much sooner.

When a host leaves a group, it notifies the local router with a Leave Group message. The message contains the address of the group being left, but unlike Membership Report messages, the Leave Group message is addressed to the “all routers on this subnet” address of 224.0.0.2. This is because only the multicast routers on the subnet need to know that the host is leaving; other group members do not.

RFC 2236 recommends that a Leave Group message be sent only if the leaving member was the last host to send a Membership Report in response to a query. As the next section explains, the local router always responds to a Leave Group message by querying for remaining group members. If group members other than the “last responder” leave quietly, the router continues forwarding the session and does not send a query. As a result, a little bandwidth is saved.

IGMPv2 has two messages that routers generate:

  • General Query
  • Group-Specific Query

The General Query is the message with which the router polls each of its subnets to discover if group members are present and to detect when there are no members of a group left on a subnet. By default, the queries are sent every 60 seconds; the default can be changed to any value between 0 and 65535 seconds with the statement ip igmp query-interval. Remember that the query will contain a host interval called the Max Response Time. In IGMPv1 it was set hard to 10 seconds. In IGMPv2, it can be changed with the command ip igmp query-max-response-time.

The General Query message is sent to the “all systems on this subnet” multicast address of 224.0.0.1 and does not contain a reference to any specific group. As a result, the single message polls for Reports from members of all groups that might be active on the subnet. The router tracks known groups and the interfaces attached to subnets with active members, and can be seen with the command show ip igmp groups.

When there is no reply to three consecutive IGMP membership queries, the router times out the group and stops forwarding traffic directed toward that group.

A Group-Specific Query is used when a router receives a Leave Group message to see if there are any multicast receivers still using the group address from which the Leave Group messsage noted. Unlike a General Query message, a Group-Specific Query does contain the group multicast address and is sent to the group multicast address.

If the Group-Specific Query were to become lost or corrupted, a remaining group member on the subnet might not send a Report. As a result, the router would incorrectly conclude that no group members are on the subnet and stop forwarding the session packets. To protect against this eventuality, the router sends two Group-Specific Queries, separated by a 1-second interval known as the Last Member Query interval.

When a multicast-enabled router first becomes active on a subnet, it assumes that it is the Querier — the router responsible for sending all General and Group-Specific Queries to the subnet—and immediately sends a General Query.

This action serves both to quickly discover the group members active on the subnet and also alerts other multicast routers that may be on the subnet. When there are multiple routers, the rule for electing the Querier is simple: The router whose connected interface has the lowest IP address is the Querier. So when the existing router on the subnet hears the General Query from the new router, it checks the source address. If the address is lower than its own IP address, it relinquishes the role of Querier to the new router. If its own IP address is lower, it continues sending queries. When the new router receives one of these queries, it sees that the old router has a lower IP address and becomes a Non-Querier. Note that for IGMPv1 there is no Querier election process. Instead, the IP multicast routing protocol on the subnet elects a designated router.

If the Non-Querier does not hear queries from the Querier within a certain period of time known as the Other Querier Present Interval, it concludes that the Querier is no longer present and assumes that role. IOS has a default Other Querier Present Interval of twice the Query Interval, or 120 seconds, and can be changed with the statement ip igmp querier-timeout.

All versions of IGMP are backwards compatible. If a mixture of Version 1 and Version 2 members are on the same subnet, the Version 2 members treat both Version 1 and Version 2 Membership reports the same when determining whether to suppress their own Membership Reports. That is, if a Version 2 member hears a Query from the router and subsequently hears a Version 1 Membership Report for its group before its own delay timer expires, it does not send a Membership Report. Version 1 hosts, however, ignore Version 2 messages. Therefore, if a Version 2 Membership Report is sent for a group first, the Version 1 member also sends a report when its delay timer expires. This does not cause problems for the Version 2 host and is important for the Version 2 router so that it is aware of the presence of Version 1 group members.

If a host is running Version 2 and the local router is running Version 1, the IGMPv1 router ignores the Version 2 messages. So when a Version 2 host receives a Version 1 query, it responds with Version 1 Membership Reports. The IGMPv1 query also does not specify a Max Response Time, so the IGMPv2 host uses the fixed Version 1 period of 10 seconds. The host may or may not send Leave Group messages in the presence of Version 1 routers; the IGMPv1 router does not recognize Leave Group messages and ignores them.

If a Version 2 router receives a Version 1 Membership Report, it treats all members of the group as if they are running Version 1. The router ignores Leave Group messages and hence does not send Group-Specific Queries that the Version 1 members would ignore. Instead it sets a timer, known as the Old Host Present Timer. The period of the timer is the same value as the Group Membership Interval. Whenever a new Version 1 Membership Report is received, the timer is reset; if the timer expires, the router concludes that there are no more Version 1 members of the group on the subnet and reverts to Version 2 messages and procedures.

If Version 1 and Version 2 routers exist on the same subnet, the Version 1 router does not participate in the Querier election process. Because of this, the Version 2 router must behave as a Version 1 router for consistency. There is no automatic conversion to Version 1; the Version 2 router must be manually configured with the ip igmp version 1 statement.

The Router Alert option is set on the IP header of IGMPv2 messages. The Router Alter option is not set with IGMPv1 messages.

IGMP Version 3

IGMPv3 officially obsoletes IGMPv2; however, version 2 is still widely used as of this writing and is still the IOS default, so you need to understand both versions.

IGMPv3 adds support for “source filtering,” which enables a multicast receiver host to signal to a router the groups from which it wants to receive multicast traffic, and from which sources this traffic is expected. This is accomplished with only two message types:

  • Version 3 membership query
  • Version 3 membership report

Version 3 supports both an INCLUDE mode and an EXCLUDE mode in which hosts announce which multicast groups they wish to receive traffic and those from which they do not wish to receive traffic.

The filtering capabilities make ICMPv3 especially suited for Source-Specific Multicast.

Here are some other changes from IGMPv2:

  • The Max Response Time variable in Query messages has an exponential range, changing the maximum from 25.5 seconds to approximately 53 minutes.
  • Report messages are sent to the well-known IGMP multicast address 224.0.0.22 to help with IGMP snooping.
  • Report messages can contain multiple group records.