IGMP snooping
IGMP snooping is the process of listening to Internet Group Management Protocol (IGMP) network traffic to control delivery of IP multicasts. Network switches with IGMP snooping listen in on the IGMP conversation between hosts and routers and maintain a map of which links need which IP multicast transmission. Multicasts may be filtered from the links which do not need them, conserving bandwidth on those links.
IGMP snooping is described in an informational IETF RFC but affects bridging operations, the purview of the IEEE. Because of a lack of an authoritative standard, the process may operate differently on different equipment.
Purpose
A switch will, by default, flood multicast traffic to all the ports in a broadcast domain (or the VLAN equivalent). Multicast can cause unnecessary load on host devices by requiring them to process packets they have not solicited. When purposefully exploited, this can form the basis of a denial-of-service attack. IGMP snooping is designed to prevent hosts on a local network from receiving traffic for a multicast group they have not explicitly joined. It provides switches with a mechanism to prune multicast traffic from links that do not contain a multicast listener (an IGMP client).
Essentially, IGMP snooping is a layer 2 optimization for the layer 3 IGMP. IGMP snooping takes place internally on switches and is not a protocol feature.
IGMP snooping allows a switch to only forward multicast traffic to the links that have solicited them. Snooping is therefore especially useful for bandwidth-intensive IP multicast applications such as IPTV.
Standard status
IGMP snooping, although an important technique, overlaps two standards organizations, namely IEEE which standardizes Ethernet switches, and IETF which standardizes IP multicast. This means that there is no clear standards body responsible for this technique. This is why RFC 4541 on IGMP snooping carries only an informational status,[1] despite actually being referred to in other standards work, such as RFC 4903, as normative.
Implementations options
IGMP querier
In order for IGMP, and thus IGMP snooping, to function, a multicast router must exist on the network and generate IGMP queries. Without a querier IGMP membership reporting may be incomplete and the tables associating member ports and multicast groups are potentially incomplete and snooping will not work reliably. Some IGMP snooping implementations include full querier capability.
IGMPv2 and IGMPv3 contain provision for selecting a querier when multiple are available. The querier with the lowest IP address is given the role.[2][3]
IGMP general queries from the querier must be unconditionally forwarded by all switches involved in IGMP snooping.[1]
Proxy reporting
IGMP snooping with proxy reporting or report suppression actively filters IGMP packets in order to reduce load on the multicast router.[1] Joins and leaves heading upstream to the router are filtered so that only the minimal quantity of information is sent. The switch is trying to ensure the router only has a single report for the group, regardless of how many active listeners there are. If there are two active listeners in a group and the first one leaves, then the switch determines that the router does not need this information since it does not affect the status of the group from the router's point of view. The next time there is a routine query from the router the switch will forward the reply from the remaining host. In the presence of proxy reporting, the router will generally only know about the most recently joined member of the group.
See also
- Multicast Listener Discovery – provides IGMP functions for IPv6
References
- M. Christensen; K. Kimball; F. Solensky (May 2006). Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches. IETF. doi:10.17487/RFC4541. RFC 4541.
- W. Fenner (November 1997). Internet Group Management Protocol, Version 2. IETF. doi:10.17487/RFC2236. RFC 2236.
- B. Cain; et al. (October 2002). Internet Group Management Protocol, Version 3. IETF. doi:10.17487/RFC3376. RFC 3376.