Configuring IGMP· 1

Overview·· 1

IGMPv1 overview·· 1

IGMPv2 enhancements 2

IGMPv3 enhancements 3

Protocols and standards 5

IGMP configuration task list 5

Configuring basic IGMP functions 5

Enabling IGMP· 5

Specifying the IGMP version· 6

Configuring an interface as a static member interface· 6

Configuring a multicast group filter 7

Adjusting IGMP performance· 7

Enabling IGMP fast-leave processing· 7

Displaying and maintaining IGMP· 8

IGMP configuration examples 8

Network requirements 8

Configuration procedure· 9

Verifying the configuration· 10

Troubleshooting IGMP· 10

No membership information on the receiver-side router 10

Inconsistent membership information on the routers on the same subnet 11

 

Overview

Internet Group Management Protocol (IGMP) establishes and maintains the multicast group memberships between a Layer 3 multicast device and its directly connected hosts.

IGMP has three versions:

·           IGMPv1 (defined by RFC 1112)

·           IGMPv2 (defined by RFC 2236)

·           IGMPv3 (defined by RFC 3376)

All IGMP versions support the ASM model. In addition to the ASM model, IGMPv3 can directly implement the SSM model. IGMPv1 and IGMPv2 must work with the IGMP SSM mapping function to implement the SSM model. For more information about the ASM and SSM models, see "Multicast overview."

IGMPv1 overview

IGMPv1 manages multicast group memberships based on the query and response mechanism.

All routers that run IGMP on the same subnet can get IGMP membership report messages (often called "reports") from hosts, but the subnet needs only one router to act as the IGMP querier to send IGMP query messages (often called "queries"). The querier election mechanism determines which router acts as the IGMP querier on the subnet.

In IGMPv1, the designated router (DR) elected by the multicast routing protocol (such as PIM) serves as the IGMP querier. For more information about DR, see "Configuring PIM."

Figure 1 IGMP queries and reports

 

As shown in Figure 1, Host B and Host C are interested in the multicast data addressed to the multicast group G1, and Host A is interested in the multicast data addressed to G2. The following process describes how the hosts join the multicast groups and how the IGMP querier (Router B in Figure 1) maintains the multicast group memberships:

1.      The hosts send unsolicited IGMP reports to the multicast groups they want to join without having to wait for the IGMP queries from the IGMP querier.

2.      The IGMP querier periodically multicasts IGMP queries (with the destination address of 224.0.0.1) to all hosts and routers on the local subnet.

3.      After receiving a query message, Host B or Host C (the host whose delay timer expires first) sends an IGMP report to the multicast group G1 to announce its membership for G1. This example assumes that Host B sends the report message. After receiving the report from Host B, Host C suppresses its own report for G1 because the IGMP routers (Router A and Router B) already know that G1 has at least one member host on the local subnet. This IGMP report suppression mechanism helps reduce traffic on the local subnet.

4.      At the same time, Host A sends a report to the multicast group G2 after receiving a query message.

5.      Through the query and response process, the IGMP routers (Router A and Router B) determine that the local subnet has members of G1 and G2, and the multicast routing protocol (PIM, for example) on the routers generates (*, G1) and (*, G2) multicast forwarding entries, where asterisk (*) represents any multicast source. These entries are the basis for subsequent multicast forwarding.

6.      When the multicast data addressed to G1 or G2 reaches an IGMP router, the router looks up the multicast forwarding table and forwards the multicast data to the local subnet based on the (*, G1) or (*, G2) entry. Then, the receivers on the subnet can receive the data.

IGMPv1 does not define a leave group message (often called a "leave message"). When an IGMPv1 host is leaving a multicast group, it stops sending reports to that multicast group. If the subnet has no members for a multicast group, the IGMP routers will not receive any report addressed to that multicast group. In this case, the routers clear the information for that multicast group after a period of time.

IGMPv2 enhancements

Backwards-compatible with IGMPv1, IGMPv2 has introduced a querier election mechanism and a leave-group mechanism.

Querier election mechanism

In IGMPv1, the DR elected by the Layer 3 multicast routing protocol (such as PIM) serves as the querier among multiple routers that run IGMP on the same subnet.

IGMPv2 introduced an independent querier election mechanism. The querier election process is as follows:

1.      Initially, every IGMPv2 router assumes itself to be the querier and sends IGMP general query messages (often called "general queries") to all hosts and routers on the local subnet. The destination address is 224.0.0.1.

2.      After receiving a general query, every IGMPv2 router compares the source IP address of the query message with its own interface address. After comparison, the router with the lowest IP address wins the querier election and all the other IGMPv2 routers become non-queriers.

3.      All the non-queriers start a timer, known as an "other querier present timer." If a router receives an IGMP query from the querier before the timer expires, it resets this timer. Otherwise, it considers the querier to have timed out and initiates a new querier election process.

"Leave group" mechanism

In IGMPv1, when a host leaves a multicast group, it does not send any notification to the multicast routers. The multicast routers determine whether a group has members by using the maximum response delay. This adds to the leave latency.

In IGMPv2, when a host leaves a multicast group, the following process occurs:

1.      The host sends a leave message to all routers on the local subnet. The destination address is 224.0.0.2.

2.      After receiving the leave message, the querier sends a configurable number of group-specific queries to the group that the host is leaving. Both the destination address field and the group address field of the message are the address of the multicast group that is being queried.

3.      One of the remaining members (if any on the subnet) of the group should send a membership report within the maximum response delay advertised in the query messages.

4.      If the querier receives a membership report for the group before the maximum response delay timer expires, it maintains the memberships for the group. Otherwise, the querier assumes that the local subnet has no member hosts for the group and stops maintaining the memberships for the group.

IGMPv3 enhancements

IGMPv3 is based on and is compatible with IGMPv1 and IGMPv2. It provides hosts with enhanced control capabilities and provides enhancements of query and report messages.

Enhancements in control capability of hosts

IGMPv3 introduced two source filtering modes (Include and Exclude). These modes allow a host to join a designated multicast group and to choose whether to receive or reject multicast data from a designated multicast source. When a host joins a multicast group, one of the following occurs:

·           If the host expects to receive multicast data from specific sources like S1, S2, …, it sends a report with the Filter-Mode denoted as "Include Sources (S1, S2, …)."

·           If the host expects to reject multicast data from specific sources like S1, S2, …, it sends a report with the Filter-Mode denoted as "Exclude Sources (S1, S2, …)".

 

 

As shown in Figure 2, the network comprises two multicast sources, Source 1 (S1) and Source 2 (S2), both of which can send multicast data to the multicast group G. Host B is interested in the multicast data that Source 1 sends to G but not in the data from Source 2.

Figure 2 Flow paths of source-and-group-specific multicast traffic

 

In IGMPv1 or IGMPv2, Host B cannot select multicast sources when it joins the multicast group G, and multicast streams from both Source 1 and Source 2 flow to Host B whether or not it needs them.

When IGMPv3 runs between the hosts and routers, Host B can explicitly express that it needs to receive the multicast data that Source 1 sends to the multicast group G (denoted as (S1, G)), rather than the multicast data that Source 2 sends to multicast group G (denoted as (S2, G)). Only multicast data from Source 1 is delivered to Host B.

Enhancements in query and report capabilities

·           Query message carrying the source addresses

IGMPv3 is compatible with IGMPv1 and IGMPv2 and supports general queries and group-specific queries. It also introduces group-and-source-specific queries.

¡  A general query does not carry a group address or a source address.

¡  A group-specific query carries a group address, but no source address.

¡  A group-and-source-specific query carries a group address and one or more source addresses.

·           Reports containing multiple group records

Unlike an IGMPv1 or IGMPv2 report message, an IGMPv3 report message is destined to 224.0.0.22 and contains one or more group records. Each group record contains a multicast group address and a multicast source address list.

Group records include the following categories:

¡  IS_IN—The source filtering mode is Include. The report sender requests the multicast data from only the sources defined in the specified multicast source list.

¡  IS_EX—The source filtering mode is Exclude. The report sender requests the multicast data from any sources except those defined in the specified multicast source list.

¡  TO_IN—The filtering mode has changed from Exclude to Include.

¡  TO_EX—The filtering mode has changed from Include to Exclude.

¡  ALLOW—The Source Address fields in this group record contain a list of the additional sources from which the system wants to obtain data for packets sent to the specified multicast address. If the change was to an Include source list, these sources are the addresses that were added to the list. If the change was to an Exclude source list, these sources are the addresses that were deleted from the list.

¡  BLOCK—The Source Address fields in this group record contain a list of the sources from which the system no longer wants to obtain data for packets sent to the specified multicast address. If the change was to an Include source list, these sources are the addresses that were deleted from the list. If the change was to an Exclude source list, these sources are the addresses that were added to the list.

Protocols and standards

·           RFC 1112, Host Extensions for IP Multicasting

·           RFC 2236, Internet Group Management Protocol, Version 2

·           RFC 3376, Internet Group Management Protocol, Version 3

IGMP configuration task list

 

 

Configuring basic IGMP functions

Before you configure basic IGMP functions, complete the following tasks:

·           Configure any unicast routing protocol so that all devices are interoperable at the network layer.

·           Configure PIM.

·           Determine the IGMP version.

·           Determine the multicast group and multicast source addresses for static group member configuration.

·           Determine the ACL for multicast group filtering.

Enabling IGMP

To configure IGMP, enable IGMP on the interface where the multicast group memberships are established and maintained.

To enable IGMP:

 

 

Specifying the IGMP version

Because the protocol packets of different IGMP versions vary in structure and type, specify the same IGMP version for all routers on the same subnet. Otherwise, IGMP cannot work properly.

To specify an IGMP version:

 

 

Configuring an interface as a static member interface

You can configure an interface as a static member of a multicast group or a multicast source and group, so that the interface can receive multicast data addressed to that multicast group for the purpose of testing multicast data forwarding.

Configuration guidelines

·           A static member interface has the following restrictions:

¡  If the interface is IGMP and PIM-SM enabled, it must be a PIM-SM DR.

¡  If the interface is IGMP enabled but not PIM-SM enabled, it must be an IGMP querier.

For more information about PIM-SM and DR, see "Configuring PIM."

·           A static member interface does not respond to queries that the IGMP querier sends. When you configure an interface as a static member or cancel this configuration on the interface, the interface does not send any IGMP report or IGMP leave message without a request. This is because the interface is not a real member of the multicast group or the multicast source and group.

Configuration procedure

To configure an interface as a static member interface:

 

 

Configuring a multicast group filter

To restrict the hosts on the network attached to an interface from joining certain multicast groups, you can specify an ACL on the interface as a packet filter so that the interface maintains only the multicast groups that match the criteria.

To configure a multicast group filter:

 

 

 

Adjusting IGMP performance

Before adjusting IGMP performance, complete the following tasks:

·           Configure any unicast routing protocol so that all devices are interoperable at the network layer.

·           Configure basic IGMP functions.

Enabling IGMP fast-leave processing

In some applications, such as ADSL dial-up networking, only one multicast receiver host is attached to an interface of the IGMP querier. To allow fast response to the leave messages of the host when it switches frequently from one multicast group to another, you can enable fast-leave processing on the IGMP querier.

With IGMP fast-leave processing enabled, after receiving an IGMP leave message from a host, the IGMP querier directly sends a leave notification to the upstream without sending IGMP group-specific queries or IGMP group-and-source-specific queries. This reduces leave latency and preserves the network bandwidth.

The IGMP fast-leave processing configuration is effective only if the device is running IGMPv2 or IGMPv3.

To enable IGMP fast-leave processing:

 

 

Displaying and maintaining IGMP  

 

 

Execute display commands in any view and reset command in user view.

 

 

 

IGMP configuration examples

 

 

Network requirements

Receiver hosts receive VOD information through multicast. Receivers of different organizations form stub networks N1 and N2. Host A and Host C are receivers in N1 and N2, respectively.

IGMPv2 runs between Switch A and N1, and between the other two switches and N2. Switch A acts as the IGMP querier in N1. Switch B acts as the IGMP querier in N2 because it has a lower IP address. One switch of the three acts as the C-BSR and the C-RP.

The hosts in N1 can join only the multicast group 224.1.1.1. The hosts in N2 can join any multicast groups.

Figure 3 Network diagram

 

 

Configuration procedure

1.      Assign the IP address and subnet mask to each interface as shown in Figure 3. (Details not shown.)

2.      Configure OSPF on the PIM network to make sure the network-layer is interoperable on the PIM network and the routing information among the switches can be dynamically updated. (Details not shown.)

3.      Configure a switch as the C-BSR and the C-RP. (Details not shown.)

For the configuration procedures, see "Configuring PIM."

4.      Enable IP multicast routing, and enable IGMP and PIM-SM:

# On Switch A, enable IP multicast routing globally, enable IGMP on VLAN-interface 100, and enable PIM-SM on each interface.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] pim sm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim sm

[SwitchA-Vlan-interface101] quit

# On Switch B, enable IP multicast routing globally, enable IGMP on VLAN-interface 200, and enable PIM-SM on each interface.

<SwitchB> system-view

[SwitchB] multicast routing-enable

[SwitchB] interface vlan-interface 200

[SwitchB-Vlan-interface200] igmp enable

[SwitchB-Vlan-interface200] pim sm

[SwitchB-Vlan-interface200] quit

[SwitchB] interface vlan-interface 201

[SwitchB-Vlan-interface201] pim sm

[SwitchB-Vlan-interface201] quit

# On Switch C, enable IP multicast routing globally, enable IGMP on VLAN-interface 200, and enable PIM-SM on each interface.

<SwitchC> system-view

[SwitchC] multicast routing-enable

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] igmp enable

[SwitchC-Vlan-interface200] pim sm

[SwitchC-Vlan-interface200] quit

[SwitchC] interface vlan-interface 202

[SwitchC-Vlan-interface202] pim sm

[SwitchC-Vlan-interface202] quit

5.      Configure a multicast group filter on Switch A so that the hosts connected to VLAN-interface 100 can join the multicast group 224.1.1.1 only.

[SwitchA] acl number 2001

[SwitchA-acl-basic-2001] rule permit source 224.1.1.1 0

[SwitchA-acl-basic-2001] quit

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp group-policy 2001

[SwitchA-Vlan-interface100] quit

Verifying the configuration

Display IGMP information on VLAN-interface 200 of Switch B.

[SwitchB] display igmp interface vlan-interface 200

Interface information

 Vlan-interface200(10.110.2.1):

   IGMP is enabled.

   IGMP version: 2

   Query interval for IGMP: 125s

   Other querier present time for IGMP: 255s

   Maximum query response time for IGMP: 10s

   Querier for IGMP: 10.110.2.1 (This router)

  IGMP groups reported in total: 1

Troubleshooting IGMP

No membership information on the receiver-side router

Symptom

When a host sends a report for joining the multicast group G, no membership information of the multicast group G exists on the router closest to that host.

Analysis

·           The correctness of networking and interface connections and whether the protocol layer of the interface is up directly affect the generation of group membership information.

·           Multicast routing must be enabled on the router. IGMP must be enabled on the interface that connects to the host.

·           If the IGMP version on the router interface is lower than that on the host, the router cannot recognize the IGMP report from the host.

·           If you have configured the igmp group-policy command on the interface, the interface cannot receive report messages that failed to pass filtering.

Solution

1.      Use the display igmp interface command to verify that the networking, interface connection, and IP address configuration are correct. If the command does not produce output, the interface is in an abnormal state. The reason might be that you have configured the shutdown command on the interface, the interface is not properly connected, or the IP address configuration is not correctly completed.

2.      Use the display current-configuration command to verify that multicast routing is enabled. If it is not enabled, use the multicast routing-enable command in system view to enable IP multicast routing. In addition, verify that IGMP is enabled on the associated interfaces.

3.      Use the display igmp interface command to verify that the IGMP version on the interface is lower than that on the host.

4.      Use the display current-configuration interface command to verify that no ACL rule has been configured to filter out the reports sent by the host to the multicast group G.

Inconsistent membership information on the routers on the same subnet

Symptom

Different memberships are maintained on different IGMP routers on the same subnet.

Analysis

·           A router running IGMP maintains multiple parameters for each interface. Inconsistent IGMP interface parameter configurations for routers on the same subnet will result in inconsistency of memberships.

·           In addition, although IGMP routers are partially compatible with hosts that separately run different versions of IGMP, all routers on the same subnet must run the same version of IGMP. Inconsistent IGMP versions running on routers on the same subnet leads to inconsistency of IGMP memberships.

Solution

1.      Use the display current-configuration command to verify the IGMP information on the interfaces.

2.      Use the display igmp interface command on all routers on the same subnet to verify the IGMP-related timer settings. Make sure the settings are consistent on all the routers.

3.      Use the display igmp interface command to verify that all the routers on the same subnet are running the same IGMP version.