IGMP

This module describes how to configure the Internet Management Group Protocol (IGMP) communications protocol used by hosts and adjacent devices on IP networks to establish multicast group memberships.

Finding Feature Information

Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module.

Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

Information About IGMP

Role of the Internet Group Management Protocol

IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Enabling PIM on an interface also enables IGMP. IGMP provides a means to automatically control and limit the flow of multicast traffic throughout your network with the use of special multicast queriers and hosts.

  • A querier is a network device, such as a router, that sends query messages to discover which network devices are members of a given multicast group.
  • A host is a receiver, including routers, that sends report messages (in response to query messages) to inform the querier of a host membership. Hosts use IGMP messages to join and leave multicast groups.

Hosts identify group memberships by sending IGMP messages to their local multicast device. Under IGMP, devices listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet.

IGMP Version Differences

There are three versions of IGMP, as defined by Request for Comments (RFC) documents of the Internet Engineering Task Force (IETF). IGMPv2 improves over IGMPv1 by adding the ability for a host to signal desire to leave a multicast group and IGMPv3 improves over IGMPv2 mainly by adding the ability to listen to multicast originating from a set of source IP addresses only.

Table 1 IGMP Versions

IGMP Version

Description

IGMPv1

Provides the basic query-response mechanism that allows the multicast device to determine which multicast groups are active and other processes that enable hosts to join and leave a multicast group. RFC 1112 defines the IGMPv1 host extensions for IP multicasting.

IGMPv2

Extends IGMP, allowing such capabilities as the IGMP leave process, group-specific queries, and an explicit maximum response time field. IGMPv2 also adds the capability for devices to elect the IGMP querier without dependence on the multicast protocol to perform this task. RFC 2236 defines IGMPv2.

IGMPv3

Provides for source filtering, which enables a multicast receiver host to signal to a device which groups it wants to receive multicast traffic from, and from which sources this traffic is expected. In addition, IGMPv3 supports the link local address 224.0.0.22, which is the destination IP address for IGMPv3 membership reports; all IGMPv3-capable multicast devices must listen to this address. RFC 3376 defines IGMPv3.


Note

By default, enabling a PIM on an interface enables IGMPv2 on that device. IGMPv2 was designed to be as backward compatible with IGMPv1 as possible. To accomplish this backward compatibility, RFC 2236 defined special interoperability rules. If your network contains legacy IGMPv1 hosts, you should be familiar with these operability rules. For more information about IGMPv1 and IGMPv2 interoperability, see RFC 2236, Internet Group Management Protocol, Version 2 .

Devices That Run IGMPv1

IGMPv1 devices send IGMP queries to the “all-hosts” multicast address of 224.0.0.1 to solicit multicast groups with active multicast receivers. The multicast receivers also can send IGMP reports to the device to notify it that they are interested in receiving a particular multicast stream. Hosts can send the report asynchronously or in response to the IGMP queries sent by the device. If more than one multicast receiver exists for the same multicast group, only one of these hosts sends an IGMP report message; the other hosts suppress their report messages.

In IGMPv1, there is no election of an IGMP querier. If more than one device on the segment exists, all the devices send periodic IGMP queries. IGMPv1 has no special mechanism by which the hosts can leave the group. If the hosts are no longer interested in receiving multicast packets for a particular group, they simply do not reply to the IGMP query packets sent from the device. The device continues sending query packets. If the device does not hear a response in three IGMP queries, the group times out and the device stops sending multicast packets on the segment for the group. If the host later wants to receive multicast packets after the timeout period, the host simply sends a new IGMP join to the device, and the device begins to forward the multicast packet again.

If there are multiple devices on a LAN, a designated router (DR) must be elected to avoid duplicating multicast traffic for connected hosts. PIM devices follow an election process to select a DR. The PIM device with the highest IP address becomes the DR.

The DR is responsible for the following tasks:

  • Sending PIM register and PIM Join and Prune messages toward the rendezvous point (RP) to inform it about host group membership.
  • Sending IGMP host-query messages.
  • Sending host-query messages by default every 60 seconds in order to keep the IGMP overhead on hosts and networks very low.

Devices That Run IGMPv2

IGMPv2 improves the query messaging capabilities of IGMPv1.

The query and membership report messages in IGMPv2 are identical to the IGMPv1 messages with two exceptions:

  • IGMPv2 query messages are broken into two categories: general queries (identical to IGMPv1 queries) and group-specific queries.
  • IGMPv1 membership reports and IGMPv2 membership reports have different IGMP type codes.

IGMPv2 also enhances IGMP by providing support for the following capabilities:

  • Querier election process--Provides the capability for IGMPv2 devices to elect the IGMP querier without having to rely on the multicast routing protocol to perform the process.
  • Maximum Response Time field--A new field in query messages permits the IGMP querier to specify the maximum query-response time. This field permits the tuning of the query-response process to control response burstiness and to fine-tune leave latencies.
  • Group-Specific Query messages--Permits the IGMP querier to perform the query operation on a specific group instead of all groups.
  • Leave-Group messages--Provides hosts with a method of notifying devices on the network that they wish to leave the group.

Unlike IGMPv1, in which the DR and the IGMP querier are typically the same device, in IGMPv2 the two functions are decoupled. The DR and the IGMP querier are selected based on different criteria and may be different devices on the same subnet. The DR is the device with the highest IP address on the subnet, whereas the IGMP querier is the device with the lowest IP address.

Query messages are used to elect the IGMP querier as follows:

  1. When IGMPv2 devices start, they each multicast a general query message to the all-systems group address of 224.0.0.1 with their interface address in the source IP address field of the message.
  2. When an IGMPv2 device receives a general query message, the device compares the source IP address in the message with its own interface address. The device with the lowest IP address on the subnet is elected the IGMP querier.
  3. All devices (excluding the querier) start the query timer, which is reset whenever a general query message is received from the IGMP querier. If the query timer expires, it is assumed that the IGMP querier has gone down, and the election process is performed again to elect a new IGMP querier.

By default, the timer is two times the query interval.

Devices Running IGMPv3

IGMPv3 adds support for source filtering, which enables a multicast receiver host to signal to a device which groups it wants to receive multicast traffic from, and from which sources this traffic is expected. This membership information enables the software to forward traffic only from those sources from which receivers requested the traffic.

IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMPv3, receivers signal membership to a multicast group in the following two modes:

  • INCLUDE mode--In this mode, the receiver announces membership to a group and provides a list of IP addresses (the INCLUDE list) from which it wants to receive traffic.
  • EXCLUDE mode--In this mode, the receiver announces membership to a group and provides a list of IP addresses (the EXCLUDE list) from which it does not want to receive traffic. In other words, the host wants to receive traffic only from sources whose IP addresses are not listed in the EXCLUDE list. To receive traffic from all sources, like in the case of the Internet Standard Multicast (ISM) service model, a host expresses EXCLUDE mode membership with an empty EXCLUDE list.

IGMPv3 is the industry-designated standard protocol for hosts to signal channel subscriptions in an SSM network environment. For SSM to rely on IGMPv3, IGMPv3 must be available in the network stack portion of the operating systems running on the last hop devices and hosts and be used by the applications running on those hosts.

In IGMPv3, hosts send their membership reports to 224.0.0.22; all IGMPv3 devices, therefore, must listen to this address. Hosts, however, do not listen or respond to 224.0.0.22; they only send their reports to that address. In addition, in IGMPv3, there is no membership report suppression because IGMPv3 hosts do not listen to the reports sent by other hosts. Therefore, when a general query is sent out, all hosts on the wire respond.

IGMP Join Process

When a host wants to join a multicast group, the host sends one or more unsolicited membership reports for the multicast group it wants to join. The IGMP join process is the same for IGMPv1 and IGMPv2 hosts.

In IGMPv3, the join process for hosts proceeds as follows:

  • When a hosts wants to join a group, it sends an IGMPv3 membership report to 224.0.0.22 with an empty EXCLUDE list.
  • When a host wants to join a specific channel, it sends an IGMPv3 membership report to 224.0.0.22 with the address of the specific source included in the INCLUDE list.
  • When a host wants to join a group excluding particular sources, it sends an IGMPv3 membership report to 224.0.0.22 excluding those sources in the EXCLUDE list.

Note

If some IGMPv3 hosts on a LAN wish to exclude a source and others wish to include the source, then the device will send traffic for the source on the LAN (that is, inclusion trumps exclusion in this situation).

IGMP Leave Process

The method that hosts use to leave a group varies depending on the version of IGMP in operation.

IGMPv1 Leave Process

There is no leave-group message in IGMPv1 to notify the devices on the subnet that a host no longer wants to receive the multicast traffic from a specific group. The host simply stops processing traffic for the multicast group and ceases responding to IGMP queries with IGMP membership reports for the group. As a result, the only way IGMPv1 devices know that there are no longer any active receivers for a particular multicast group on a subnet is when the devices stop receiving membership reports. To facilitate this process, IGMPv1 devices associate a countdown timer with an IGMP group on a subnet. When a membership report is received for the group on the subnet, the timer is reset. For IGMPv1 devices, this timeout interval is typically three times the query interval (3 minutes). This timeout interval means that the device may continue to forward multicast traffic onto the subnet for up to 3 minutes after all hosts have left the multicast group.

IGMPv2 Leave Process

IGMPv2 incorporates a leave-group message that provides the means for a host to indicate that it wishes to stop receiving multicast traffic for a specific group. When an IGMPv2 host leaves a multicast group, if it was the last host to respond to a query with a membership report for that group, it sends a leave-group message to the all-devices multicast group (224.0.0.2).

IGMPv3 Leave Process

IGMPv3 enhances the leave process by introducing the capability for a host to stop receiving traffic from a particular group, source, or channel in IGMP by including or excluding sources, groups, or channels in IGMPv3 membership reports.

IGMP Multicast Addresses

IP multicast traffic uses group addresses, which are Class D IP addresses. The high-order four bits of a Class D address are 1110. Therefore, host group addresses can be in the range 224.0.0.0 to 239.255.255.255.

Multicast addresses in the range 224.0.0.0 to 224.0.0.255 are reserved for use by routing protocols and other network control traffic. The address 224.0.0.0 is guaranteed not to be assigned to any group.

IGMP packets are transmitted using IP multicast group addresses as follows:

  • IGMP general queries are destined to the address 224.0.0.1 (all systems on a subnet).
  • IGMP group-specific queries are destined to the group IP address for which the device is querying.
  • IGMP group membership reports are destined to the group IP address for which the device is reporting.
  • IGMPv2 leave-group messages are destined to the address 224.0.0.2 (all devices on a subnet).
  • IGMPv3 membership reports are destined to the address 224.0.0.22; all IGMPv3-capable multicast devices must listen to this address.

How to Configure IGMP

Configuring the Device to Forward Multicast Traffic in the Absence of Directly Connected IGMP Hosts

Perform this optional task to configure the device to forward multicast traffic in the absence of directly connected IGMP hosts.

SUMMARY STEPS

    1.    enable

    2.    configure terminal

    3.    interface type number

    4.    Do one of the following:

    • ip igmp join-group group-address
    • ip igmp static-group {* | group-address [source source-address]}

    5.    end

    6.    show ip igmp interface [interface-type interface-number]


DETAILED STEPS
      Command or Action Purpose
    Step 1 enable


    Example: 
    Device> enable
     

    Enables privileged EXEC mode.

    • Enter your password if prompted.
     
    Step 2 configure terminal


    Example: 
    Device# configure terminal
     

    Enters global configuration mode.

     
    Step 3 interface type number


    Example: 
    Device(config)# interface gigabitethernet 1
     

    Enters interface configuration mode.

    • For the type and number arguments, specify an interface that is connected to hosts.
     
    Step 4 Do one of the following:
    • ip igmp join-group group-address
    • ip igmp static-group {* | group-address [source source-address]}


    Example: 
    Device(config-if)# ip igmp join-group 225.2.2.2


    Example: 
    Device(config-if)# ip igmp static-group 225.2.2.2
     
    The first sample shows how to configure an interface on the device to join the specified group.
    • With this method, the device accepts the multicast packets in addition to forwarding them. Accepting the multicast packets prevents the device from fast switching.
    The second example shows how to configure static group membership entries on an interface.
    • With this method, the device does not accept the packets itself, but only forwards them. Hence, this method allows fast switching. The outgoing interface appears in the IGMP cache, but the device itself is not a member, as evidenced by lack of an “L” (local) flag in the multicast route entry.
     
    Step 5 end


    Example: 
    Device(config-if)# end
     

    Returns to privileged EXEC mode.

     
    Step 6 show ip igmp interface [interface-type interface-number]


    Example: 
    Device# show ip igmp interface
     

    (Optional) Displays multicast-related information about an interface.

     

    Controlling Access to an SSM Network Using IGMP Extended Access Lists

    Perform this optional task to control access to an SSM network by using an IGMP extended access list that filters SSM traffic based on source address, group address, or both.

    SUMMARY STEPS

      1.    enable

      2.    configure terminal

      3.    ip multicast-routing [distributed]

      4.    ip pim ssm {default | range access-list}

      5.    ip access-list extended access-list -name

      6.    deny igmp source source-wildcard destination destination-wildcard [igmp-type] [precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]

      7.    permit igmp source source-wildcard destination destination-wildcard [igmp-type] [precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]

      8.    exit

      9.    interface type number

      10.    ip igmp access-group access-list

      11.    ip pim sparse-mode

      12.    Repeat Steps 1 through 11 on all interfaces that require access control of SSM channel membership.

      13.    ip igmp version 3

      14.    Repeat Step 13 on all host-facing interfaces.

      15.    end


    DETAILED STEPS
        Command or Action Purpose
      Step 1 enable


      Example: 
      Device> enable
       

      Enables privileged EXEC mode.

      • Enter your password if prompted.
       
      Step 2 configure terminal


      Example: 
      Device# configure terminal
       

      Enters global configuration mode.

       
      Step 3 ip multicast-routing [distributed]


      Example: 
      Device(config)# ip multicast-routing distributed
       

      Enables IP multicast routing.

      • The distributed keyword is required for IPv4 multicast..
       
      Step 4 ip pim ssm {default | range access-list}


      Example: 
      Device(config)# ip pim ssm default
       

      Configures SSM service.

      • The default keyword defines the SSM range access list as 232/8.
      • The range keyword specifies the standard IP access list number or name that defines the SSM range.
       
      Step 5 ip access-list extended access-list -name


      Example: 
      Device(config)# ip access-list extended mygroup
       

      Specifies an extended named IP access list.

       
      Step 6 deny igmp source source-wildcard destination destination-wildcard [igmp-type] [precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]


      Example: 
      Device(config-ext-nacl)# deny igmp host 10.1.2.3 any
       

      (Optional) Filters the specified source address or group address from the IGMP report, thereby restricting hosts on a subnet from membership to the (S, G) channel.

      • Repeat this step to restrict hosts on a subnet membership to other (S, G) channels. (These sources should be more specific than a subsequent permit statement because any sources or groups not specifically permitted are denied.)
      • Remember that the access list ends in an implicit deny statement.
      • This example shows how to create a deny statement that filters all groups for source 10.1.2.3, which effectively denies the source.
       
      Step 7 permit igmp source source-wildcard destination destination-wildcard [igmp-type] [precedence precedence] [tos tos] [log] [time-range time-range-name] [fragments]


      Example: 
      Device(config-ext-nacl)# permit igmp any any
       

      Allows a source address or group address in an IGMP report to pass the IP access list.

      • You must have at least one permit statement in an access list.
      • Repeat this step to allow other sources to pass the IP access list.
      • This example shows how to allow group membership to sources and groups not denied by prior deny statements.
       
      Step 8 exit


      Example: 
      Device(config-ext-nacl)# exit
       

      Exits the current configuration session and returns to global configuration mode.

       
      Step 9 interface type number

      Example: 
      Device(config)# interface ethernet 0
       

      Selects an interface that is connected to hosts on which IGMPv3 can be enabled.

       
      Step 10 ip igmp access-group access-list


      Example: 
      Device(config-if)# ip igmp access-group mygroup
       

      Applies the specified access list to IGMP reports.

       
      Step 11 ip pim sparse-mode


      Example: 
      Device(config-if)# ip pim sparse-mode
       

      Enables PIM-SM on the interface.

      Note   

      You must use sparse mode.

       
      Step 12 Repeat Steps 1 through 11 on all interfaces that require access control of SSM channel membership.  

      --

       
      Step 13 ip igmp version 3


      Example: 
      Device(config-if)# ip igmp version 3
       

      Enables IGMPv3 on this interface. The default version of IGMP is IGMP version 2. Version 3 is required by SSM.

       
      Step 14 Repeat Step 13 on all host-facing interfaces.  

      --

       
      Step 15 end


      Example: 
      Device(config-if)# end
       

      Returns to privileged EXEC mode.

       

      Configuratio Examples for IGMP

      Example: Configuring the Device to Forward Multicast Traffic in the Absence of Directly Connected IGMP Hosts

      The following example shows how to configure a device to forward multicast traffic in the absence of directly connected IGMP hosts using the ip igmp join-group command. With this method, the device accepts the multicast packets in addition to forwarding them. Accepting the multicast packets prevents the device from fast switching.

      In this example, Fast Ethernet interface 0/0/0 on the device is configured to join the group 225.2.2.2: 

      interface FastEthernet0/0/0
 ip igmp join-group 225.2.2.2

      The following example shows how to configure a device to forward multicast traffic in the absence of directly connected IGMP hosts using the ip igmp static-group command. With this method, the device does not accept the packets itself, but only forwards them. Hence, this method allows fast switching. The outgoing interface appears in the IGMP cache, but the device itself is not a member, as evidenced by lack of an “L” (local) flag in the multicast route entry.

      In this example, static group membership entries for group 225.2.2.2 are configured on Fast Ethernet interface 0/1/0: 

      interface FastEthernet0/1/0
 ip igmp static-group 225.2.2.2

      Controlling Access to an SSM Network Using IGMP Extended Access Lists

      This section contains the following configuration examples for controlling access to an SSM network using IGMP extended access lists:


      Note

      Keep in mind that access lists are very flexible: there are many combinations of permit and deny statements one could use in an access list to filter multicast traffic. The examples in this section simply provide a few examples of how it can be done.

      Example: Denying All States for a Group G

      The following example shows how to deny all states for a group G. In this example, Fast Ethernet interface 0/0/0 is configured to filter all sources for SSM group 232.2.2.2 in IGMPv3 reports, which effectively denies this group. 

      ip access-list extended test1
 deny igmp any host 232.2.2.2
 permit igmp any any
!
interface FastEthernet0/0/0
 ip igmp access-group test1

      Example: Denying All States for a Source S

      The following example shows how to deny all states for a source S. In this example, Gigabit Ethernet interface 1/1/0 is configured to filter all groups for source 10.2.1.32 in IGMPv3 reports, which effectively denies this source. 

      ip access-list extended test2
 deny igmp host 10.2.1.32 any
 permit igmp any any
!
interface GigabitEthernet1/1/0
 ip igmp access-group test2

      Example: Permitting All States for a Group G

      The following example shows how to permit all states for a group G. In this example, Gigabit Ethernet interface 1/2/0 is configured to accept all sources for SSM group 232.1.1.10 in IGMPv3 reports, which effectively accepts this group altogether. 

      ip access-list extended test3
 permit igmp any host 232.1.1.10
!
interface GigabitEthernet1/2/0
 ip igmp access-group test3

      Example: Permitting All States for a Source S

      The following example shows how to permit all states for a source S. In this example, Gigabit Ethernet interface 1/2 is configured to accept all groups for source 10.6.23.32 in IGMPv3 reports, which effectively accepts this source altogether. 

      ip access-list extended test4
 permit igmp host 10.6.23.32 any
!
interface GigabitEthernet1/2/0
 ip igmp access-group test4

      Example: Filtering a Source S for a Group G

      The following example shows how to filter a particular source S for a group G. In this example, Gigabit Ethernet interface 0/3/0 is configured to filter source 232.2.2.2 for SSM group 232.2.30.30 in IGMPv3 reports. 

      ip access-list extended test5
 deny igmp host 10.4.4.4 host 232.2.30.30
 permit igmp any any
!
interface GigabitEthernet0/3/0
 ip igmp access-group test5

      Additional References

      The following sections provide references related to customizing IGMP.

      Related Documents

      Related Topic

      Document Title

      Cisco IOS commands

      Cisco IOS Master Commands List, All Releases

      Cisco IOS IP SLAs commands

      Cisco IOS IP Multicast Command Reference

      Overview of the IP multicast technology area

      “ IP Multicast Technology Overview ” module

      Basic IP multicast concepts, configuration tasks, and examples

      “ Configuring Basic IP Multicast ” or “Configuring IP Multicast in IPv6 Networks” module

      Standards and RFCs

      Standard/RFC

      Title

      RFC 1112

      Host extensions for IP multicasting

      RFC 2236

      Internet Group Management Protocol, Version 2

      RFC 3376

      Internet Group Management Protocol, Version 3

      MIBs

      MIB

      MIBs Link

      No new or modified MIBs are supported by these features, and support for existing MIBs has not been modified by these features.

      To locate and download MIBs for selected platforms, Cisco IOS XE releases, and feature sets, use Cisco MIB Locator found at the following URL:

      http:/​/​www.cisco.com/​go/​mibs

      Technical Assistance

      Description

      Link

      The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.

      http:/​/​www.cisco.com/​cisco/​web/​support/​index.html

      Feature Information for IGMP

      The following table provides release information about the feature or features described in this module. This table lists only the software release that introduced support for a given feature in a given software release train. Unless noted otherwise, subsequent releases of that software release train also support that feature.

      Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/​go/​cfn. An account on Cisco.com is not required.

      Table 2 Feature Information for IGMP

      Feature Name

      Releases

      Feature Information

      IGMP

      —

      Provides the basic query-response mechanism that allows the multicast device to determine which multicast groups are active and other processes that enable hosts to join and leave a multicast group. RFC 1112 defines the IGMPv1 host extensions for IP multicasting.

      IGMP version 2

      12.2(27)SBB

      Cisco IOS XE Release 2.1

      Extends IGMP, allowing such capabilities as the IGMP leave process, group-specific queries, and an explicit maximum response time field. IGMPv2 also adds the capability for routers to elect the IGMP querier without dependence on the multicast protocol to perform this task.

      IGMP version 3

      12.2(27)SBB

      12.4(15)T

      Cisco IOS XE Release 2.1

      Cisco IOS XE Release 3.2SE

      Provides for source filtering, which enables a multicast receiver host to signal to a router which groups it wants to receive multicast traffic from, and from which sources this traffic is expected. In addition, IGMPv3 supports the link local address 224.0.0.22, which is the destination IP address for IGMPv3 membership reports; all IGMPv3-capable multicast routers must listen to this address.