Internet Group Management Protocol

explains how multicast receivers join multicast groups to start receiving multicast traffic using IGMPv2 or IGMPv3. It also describes how multicast flooding on L2 switches is prevented using a feature called IGMP snooping.

The protocol that receivers use to join multicast groups.
When a receiver wants to receive a specific multicast feed, it sends an IGMP join using the multicast IP group address for that feed. The receiver reprograms its interface to accept the multicast MAC group address that correlates to the group address. For example, a PC could send a join to 239.255.1.1 and would reprogram its NIC to receive 01:00:5E:7F:01:01.
IGMP must be supported by receivers and the router interfaces facing the receivers.
Three versions of IGMP exist. IGMPv1, which is old and rarely used. RFC 2236 defines IGMPv2, which is common in most multicast networks, and RFC 3376 defines IGMPv3, which is used by SSM. Only IGMPv2 and IGMPv3 are described in this chapter.

Version 2 Message Format

This message is encapsulated in an IP packet with a protocol number of 2. Messages are sent with the IP router alert option set, which indicates that the packets should be examined more closely. IGMP packets are sent with a TTL of 1 so that packets are processed by the local router and not forwarded by any router. The Type field describes five different types of IGMP messages used by routers and receivers.

Version 2 Message Format – Type Field Messages

Five different types of IGMP messages used by routers and receivers:

Version 2 membership report (type value 0x16) is a message type also commonly referred to as an IGMP join; used by receivers to join a multicast group or to respond to a local router’s membership query message.
Version 1 membership report (type value 0x12) is used by receivers for backward compatibility with IGMPv1.
Version 2 leave group (type value 0x17) is used by receivers to indicate they want to stop receiving multicast traffic for a group they joined.
General membership query (type value 0x11) is periodically sent to the all-hosts group address 224.0.0.1 to see whether there are any receivers in the attached subnet. It sets the group address field to 0.0.0.0.
Group specific query (type value 0x11) is sent in response to a leave group message to the group address the receiver requested to leave. The group address is the destination IP address of the IP packet and the group address field.

Version 2 Message Format – Other Fields

Max response time – This field is set only in general and group-specific membership query messages (type value 0x11). It specifies the maximum allowed time before sending a responding report in units of one-tenth of a second. In all other messages, it is set to 0x00 by the sender and ignored by receivers.
Checksum – This field is the 16-bit 1s complement of the 1s complement sum of the IGMP message. This is the standard checksum algorithm used by TCP/IP.
Group address – This field is set to 0.0.0.0 in general query messages and is set to the group address in group-specific messages. Membership report messages carry the address of the group being reported in this field; group leave messages carry the address of the group being left in this field.

Version 2 Messages

When a receiver wants to receive a multicast stream, it sends an unsolicited membership report, commonly referred to as an IGMP join, to the local router for the group it wants to join (for example, 239.1.1.1). The local router then sends this request upstream toward the source using a PIM join message. When the local router starts receiving the multicast stream, it forwards it downstream to the subnet where the receiver that requested it resides.
The router then starts periodically sending general membership query messages into the subnet, to the all-hosts group address 224.0.0.1, to see whether any members are in the attached subnet. The general query message contains a max response time field that is set to 10 seconds by default.
In response to this query, receivers set an internal random timer between 0 and 10 seconds. When the timer expires, receivers send membership reports (join message) for each group they belong to. If a receiver receives another receiver’s report (join message) for one of the groups it belongs to while it has a timer running, it stops its timer for the specified group and does not send a report (join); this is meant to suppress duplicate reports (join messages).

Version 2 Messages

When a receiver wants to leave a group, if it was the last receiver to respond to a query, it sends a leave group message to the all-routers group address 224.0.0.2. Otherwise, it can leave quietly because there must be another receiver in the subnet.
When the leave group message is received by the router, it follows with a specific membership query to the group multicast address to determine whether there are any receivers interested in the group remaining in the subnet. If there are none, the router removes the IGMP state for that group.
If there is more than one router in a LAN segment, an IGMP querier election takes place to determine which router will be the querier. IGMPv2 routers send general membership query messages with their interface address as the source IP address and destined to the 224.0.0.1 multicast address.
When an IGMPv2 router receives such a message, it checks the source IP address and compares it to its own interface IP address. The router with the lowest interface IP address in the LAN subnet is elected as the IGMP querier.

Version 3

In IGMPv2, when a receiver sends a membership report to join a multicast group. It does not specify which source it would like to receive multicast traffic from.
IGMPv3 adds support for multicast source filtering, giving the receivers the capability to pick the source they wish to accept multicast traffic. IGMPv3 supports all IGMPv2’s IGMP message types and is backward compatible with IGMPv2.
IGMPv3 added new fields to the IGMP membership query and introduced a new IGMP message type called Version 3 membership report to support source filtering in the following two modes:
Include mode – The receiver announces membership to a multicast group address and provides a list of source addresses (the include list) from which it wants to receive traffic.
Exclude mode – The receiver announces membership to a multicast group address and provides a list of source addresses (the exclude list) from which it does not want to receive traffic. The receiver then receives traffic only from sources whose IP addresses are not listed on the exclude list.

IGMP Snooping

In the case of multicast traffic, a multicast MAC address is never used as a source MAC address. Switches treat multicast MAC addresses as unknown frames and flood them out all ports. All workstations then process these frames. It is then up to the workstations to select interested frames for processing and select the frames that should be discarded. The flooding of multicast traffic on a switch wastes bandwidth utilization on each LAN segment. Cisco switches use two methods to reduce multicast flooding on a LAN segment:

IGMP snooping
Static MAC address entries

IGMP snooping, is the most widely used method and works by examining IGMP joins sent by receivers and maintaining a table of interfaces to IGMP joins. When the switch receives a multicast frame destined for a multicast group, it forwards the packet only out the ports where IGMP joins were received for that specific multicast group.
Figure 13-10 illustrates A and C sending IGMP joins to 239.255.1.1, which translates to the multicast MAC address 01:00:5E:7F:01:01. Switch 1 has IGMP snooping enabled and populates the MAC address table with this information.

Figure 13-11 illustrates the source sending traffic to 239.255.1.1(01:00:5E:7F:01:01).
Switch 1 receives this traffic, and it forwards it out only the g0/0 and g0/2 interfaces because those are the only ports that received IGMP joins for that group.
A multicast static entry can also be manually programmed into the MAC address table, but this is not a scalable solution because it cannot react dynamically to changes. For this reason, it is not a recommended approach.

Other useful information:

Join the conversation