As a TCP/IP protocol responsible for IP multicast group member management, the Internet Group Management Protocol (IGMP) is used by IP hosts to establish and maintain their multicast group memberships to immediately neighboring multicast routers.

IGMP Versions

So far, there are three IGMP versions:

l IGMPv1 (documented in RFC 1112)

l IGMPv2 (documented in RFC 2236)

l IGMPv3 (documented in RFC 3376)

All IGMP versions support the Any-Source Multicast (ASM) model. In addition to support of the ASM model, IGMPv3 can be directly deployed to implement the Source-Specific Multicast (SSM) model, while IGMPv1 and IGMPv2 need to work with the IGMP SSM mapping function to implement the SSM model.

For more information about the ASM and SSM models, see Multicast Overview of the IP Multicast Volume.

Introduction to IGMPv1

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

Of multiple multicast routers on the same subnet, all the routers can hear IGMP membership report messages (often referred to as reports) from hosts, but only one router is needed for sending IGMP query messages (often referred to as queries). So, a querier election mechanism is required to determine which router will act as the IGMP querier on the subnet.

In IGMPv1, the designated router (DR) elected by the working multicast routing protocol (such as PIM) serves as the IGMP querier.

For more information about DR, refer to PIM Configuration in the IP Multicast Volume.

Figure 1-1 IGMP queries and reports

Assume that Host B and Host C are expected to receive multicast data addressed to multicast group G1, while Host A is expected to receive multicast data addressed to G2, as shown in Figure 1-1. The following describes how the hosts join the multicast groups and the IGMP querier (Router B in the figure) maintains the multicast group memberships:

1) The hosts send unsolicited IGMP reports to the addresses of the multicast groups that 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) Upon receiving a query message, Host B or Host C (the delay timer of whichever expires first) sends an IGMP report to the multicast group address of G1, to announce its membership for G1. Assume it is Host B that sends the report message. Upon hearing the report from Host B, Host C, which is on the same subnet with Host B, suppresses its own report for G1, because the IGMP routers (Router A and Router B) already know that at least one host on the local subnet is interested in G1. This mechanism, known as IGMP report suppression applied on hosts, helps reduce traffic on the local subnet.

4) At the same time, because Host A is interested in G2, it sends a report to the multicast group address of G2.

5) Through the above-mentioned query/report process, the IGMP routers learn that members of G1 and G2 are attached to the local subnet, and the multicast routing protocol (PIM for example) running on the routers generates (*, G1) and (*, G2) multicast forwarding entries, which will be the basis for subsequent multicast forwarding, where * represents any multicast source.

6) When the multicast data addressed to G1 or G2 reaches an IGMP router, because the (*, G1) and (*, G2) multicast forwarding entries exist on the IGMP router, the router forwards the multicast data to the local subnet, and then the receivers on the subnet receive the data.

As IGMPv1 does not specifically define a Leave Group message, upon leaving a multicast group, an IGMPv1 host stops sending reports to the address of the multicast group it listened to. If no member of a multicast group exists on the subnet, the IGMP router will not receive any report addressed to that multicast group, so the routers will delete the multicast forwarding entries for that multicast group after a period of time.

Enhancements in IGMPv2

Compared 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 on the same subnet.

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

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

2) Upon hearing 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 other IGMPv2 routers become non-queriers.

3) All the non-queriers start a timer, known as “other querier present timer”. If a router receives an IGMP query from the querier before the timer expires, it resets this timer; otherwise, it assumes 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 router. The multicast router relies on host response timeout to know whether a group no longer has members. This adds to the leave latency.

In IGMPv2, on the other hand, when a host leaves a multicast group:

1) This host sends a Leave Group message (often referred to as leave message) to all routers (the destination address is 224.0.0.2) on the local subnet.

2) Upon receiving the leave message, the querier sends a configurable number of group-specific queries to the group being left. The destination address field and group address field of the message are both filled with the address of the multicast group being queried.

3) One of the remaining members, if any on the subnet, of the group being queried should send a membership report within the maximum response time set in the query messages.

4) If the querier receives a membership report for the group within the maximum response time, it will maintain the memberships of the group; otherwise, the querier will assume that no hosts on the subnet are still interested in multicast traffic to that group and will stop maintaining the memberships of the group.

Enhancements in IGMPv3

Built upon and being compatible with IGMPv1 and IGMPv2, IGMPv3 provides hosts with enhanced control capabilities and provides enhancements of query and report messages.

Enhancements in control capability of hosts

IGMPv3 has introduced source filtering modes (Include and Exclude), so that a host can specify a list of sources it expect or does not expect multicast data from when it joins a multicast group:

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

l If it does not expect 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 1-2, the network comprises two multicast sources, Source 1 (S1) and Source 2 (S2), both of which can send multicast data to multicast group G. Host B is interested only in the multicast data that Source 1 sends to G but not in the data from Source 2.

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

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

When IGMPv3 is running between the hosts and routers, Host B can explicitly express its interest in the multicast data Source 1 sends to multicast group G (denoted as (S1, G)), rather than the multicast data Source 2 sends to multicast group G (denoted as (S2, G)). Thus, only multicast data from Source 1 will be delivered to Host B.

Enhancements in query and report capabilities

1) Query message carrying the source addresses

IGMPv3 supports not only general queries (feature of IGMPv1) and group-specific queries (feature of IGMPv2), but also group-and-source-specific queries.

l A general query does not carry a group address, nor a source address;

l A group-specific query carries a group address, but no source address;

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

2) 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 record types include:

l IS_IN: The source filtering mode is Include, namely, the report sender requests the multicast data from only the sources defined in the specified multicast source list.

l IS_EX: The source filtering mode is Exclude, namely, the report sender requests the multicast data from any sources but those defined in the specified multicast source list.

l TO_IN: The filtering mode has changed from Exclude to Include.

l TO_EX: The filtering mode has changed from Include to Exclude.

l ALLOW: The Source Address fields in this Group Record contain a list of the additional sources that the system wishes to hear from, for packets sent to the specified multicast address. If the change was to an Include source list, these are the addresses that were added to the list; if the change was to an Exclude source list, these are the addresses that were deleted from the list.

l BLOCK: indicates that the Source Address fields in this Group Record contain a list of the sources that the system no longer wishes to hear from, for packets sent to the specified multicast address. If the change was to an Include source list, these are the addresses that were deleted from the list; if the change was to an Exclude source list, these are the addresses that were added to the list.

IGMP SSM Mapping

The IGMP SSM mapping feature allows you to configure static IGMP SSM mappings on the last hop router to provide SSM support for receiver hosts running IGMPv1 or IGMPv2. The SSM model assumes that the last hop router is aware of the desired multicast sources when receivers join multicast groups.

l When a host running IGMPv3 joins a multicast group, it can explicitly specify one or more multicast sources in its IGMPv3 report.

l A host running IGMPv1 or IGMPv2, however, cannot specify multicast source addresses in its report. In this case, you need to configure the IGMP SSM mapping feature to translate the (*, G) information in the IGMPv1 or IGMPv2 report into (G, INCLUDE, (S1, S2...)) information.

Figure 1-3 Network diagram for IGMP SSM mapping

As shown in Figure 1-3, on an SSM network, Host A, Host B and Host C are running IGMPv1, IGMPv2 and IGMPv3 respectively. To provide SSM service for all the hosts while it is infeasible to run IGMPv3 on Host A and Host B, you need to configure the IGMP SSM mapping feature on Router A.

With the IGMP SSM mapping feature configured, when Router A receives an IGMPv1 or IGMPv2 report, it checks the multicast group address G carried in the message:

l If G is not in the SSM group range, Router A cannot provide the SSM service but the ASM service.

l If G is in the SSM group range but no IGMP SSM mappings corresponding to the multicast group G have been configured on Router A, Router A cannot provide SSM service and drops the message.

l If G is in the SSM group range and the IGMP SSM mappings have been configured on Router A for multicast group G, Router A translates the (*, G) information in the IGMP report into (G, INCLUDE, (S1, S2...)) information based on the configured IGMP SSM mappings and provides SSM service accordingly.

l The IGMP SSM mapping feature does not process IGMPv3 reports.

l For more information about the SSM group range, refer to PIM Configuration in the IP Multicast Volume.

Multi-Instance IGMP

While IGMP maintains group memberships on a per-interface base, IGMP in a VPN instance handles protocol packets based on the VPN instance on the interface. Upon receiving an IGMP packet, the router determines the instance to which the message belongs and handles the message within the instance. If IGMP running in a VPN instance needs to exchange information with another multicast protocol, the router informs the other multicast protocol only within the VPN instance.

Protocols and Standards

The following documents describe different IGMP versions:

l RFC 1112: Host Extensions for IP Multicasting

l RFC 2236: Internet Group Management Protocol, Version 2

l RFC 3376: Internet Group Management Protocol, Version 3

IGMP Configuration Task List

Complete these tasks to configure IGMP:

Task		Remarks
Configuring Basic Functions of IGMP	Enabling IGMP	Required
	Configuring IGMP Versions	Optional
	Configuring Static Joining	Optional
	Configuring a Multicast Group Filter	Optional
Adjusting IGMP Performance	Configuring IGMP Message Options	Optional
	Configuring IGMP Query and Response Parameters	Optional
	Configuring IGMP Fast Leave Processing	Optional
Configuring IGMP SSM Mapping	Enabling SSM Mapping	Optional
Configuring IGMP SSM Mapping	Configuring SSM Mappings	Optional

l Configurations performed in IGMP view are effective on all interfaces, while configurations performed in interface view are effective on the current interface only.

l If a feature is not configured for an interface in interface view, the global configuration performed in IGMP view will apply to that interface. If a feature is configured in both IGMP view and interface view, the configuration performed in interface view will be given priority.

Configuring Basic Functions of IGMP

Configuration Prerequisites

Before configuring the basic functions of IGMP, complete the following tasks:

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

l Configure PIM-DM or PIM-SM

Before configuring the basic functions of IGMP, prepare the following data:

l IGMP version

l Multicast group and multicast source addresses for static group member configuration

l ACL rule for multicast group filtering

Enabling IGMP

First, IGMP must be enabled on the interface on which the multicast group memberships are to be established and maintained.

Enabling IGMP in the public instance

Follow these steps to enable IGMP in the public instance:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enable IP multicast routing	multicast routing-enable	Required Disabled by default
Enter interface view	interface interface-type interface-number	—
Enable IGMP	igmp enable	Required Disabled by default

Enabling IGMP in a VPN instance

Follow these steps to enable IGMP in a VPN instance:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Create a VPN instance and enter VPN instance view	ip vpn-instance vpn-instance-name	—
Configure an RD for the VPN instance	route-distinguisher route-distinguisher	Required No RD is configured by default.
Enable IP multicast routing	multicast routing-enable	Required Disabled by default
Enter interface view	interface interface-type interface-number	—
Associate the current interface with the VPN instance	ip binding vpn-instance vpn-instance-name	Required No VPN instance is associated with an interface by default.
Enable IGMP	igmp enable	Required Disabled by default

l For details about the ip vpn-instance, route-distinguisher and ip binding vpn-instance commands, see MPLS L3VPN Commands in the MPLS Volume.

l For details about the multicast routing-table command, see Multicast Routing and Forwarding Commands in the IP Multicast Volume.

Configuring IGMP Versions

Because the protocol packets of different IGMP versions vary in structure and type, the same IGMP version should be configured for all routers on the same subnet before IGMP can work properly.

Configuring an IGMP version globally

Follow these steps to configure an IGMP version globally:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter public instance IGMP view or VPN instance IGMP view	igmp [ vpn-instance vpn-instance-name ]	—
Configure an IGMP version globally	version version-number	Optional IGMPv2 by default

Configuring an IGMP version on an interface

Follow these steps to configure an IGMP version on an interface:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure an IGMP version on the interface	igmp version version-number	Optional IGMPv2 by default

Configuring Static Joining

After an interface is configured as a static member of a multicast group or a multicast source and group, it will act as a virtual member of the multicast group to receive multicast data addressed to that multicast group for the purpose of testing multicast data forwarding.

Follow these steps to configure an interface as a statically connected member of a multicast group or a multicast source and group:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure the interface as a static member of a multicast group or a multicast source and group	igmp static-group group-address [ source source-address ]	Required An interface is not a static member of any multicast group or multicast source and group by default.

l Before you can configure an interface of a PIM-SM device as a static member of a multicast group or a multicast source and group, if the interface is PIM-SM enabled, it must be a PIM-SM DR; if this interface is IGMP enabled but not PIM-SM enabled, it must be an IGMP querier. For more information about PIM-SM and a DR, refer to PIM Configuration in the IP Multicast Volume.

l As a static member of a multicast group or a multicast source and group, the interface does not respond to the queries from the IGMP querier, nor does it send an unsolicited IGMP membership report or an IGMP leave group message when it joins or leaves a multicast group or a multicast source and group. In other words, the interface will not become a real member of the multicast group or the multicast source and group.

Configuring a Multicast Group Filter

To restrict the hosts on the network attached to an interface from joining certain multicast groups, you can set an ACL rule on the interface as a packet filter that limits the range of multicast groups the interface serves.

Follow these steps to configure a multicast group filter:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure a multicast group filter	igmp group-policy acl-number [ version-number ]	Required No multicast group filter configured by default

Adjusting IGMP Performance

For the configuration tasks described in this section:

l Configurations performed in IGMP view are effective on all interfaces, while configurations performed in interface view are effective on the current interface only.

l If the same feature is configured in both IGMP view and interface view, the configuration performed in interface view is given priority, regardless of the configuration sequence.

Configuration Prerequisites

Before adjusting IGMP performance, complete the following tasks:

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

l Configure basic functions of IGMP

Before adjusting IGMP performance, prepare the following data:

l Startup query interval

l Startup query count

l IGMP general query interval

l IGMP querier’s robustness variable

l Maximum response time for IGMP general queries

l IGMP last-member query interval

l Other querier present interval

Configuring IGMP Message Options

IGMP queries include group-specific queries and group-and-source-specific queries, and multicast groups change dynamically, so a device cannot maintain the information for all multicast sources and groups, For this reason, when receiving a multicast packet but unable to locate the outgoing interface for the destination multicast group, an IGMP router needs to leverage the Router-Alert option to pass the multicast packet to the upper-layer protocol for processing. For details about the Router-Alert option, refer to RFC 2113.

An IGMP message is processed differently depending on whether it carries the Router-Alert option in the IP header:

l By default, for the consideration of compatibility, the device does not check the Router-Alert option, namely it processes all the IGMP messages it received. In this case, IGMP messages are directly passed to the upper layer protocol, no matter whether the IGMP messages carry the Router-Alert option or not.

l To enhance the device performance and avoid unnecessary costs, and also for the consideration of protocol security, you can configure the device to discard IGMP messages that do not carry the Router-Alert option.

Configuring IGMP packet options globally

Follow these steps to configure IGMP packet options globally:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter public instance IGMP view or VPN instance IGMP view	igmp [ vpn-instance vpn-instance-name ]	—
Configure the router to discard any IGMP message that does not carry the Router-Alert option	require-router-alert	Optional By default, the device does not check the Router-Alert option.
Enable insertion of the Router-Alert option into IGMP messages	send-router-alert	Optional By default, IGMP messages carry the Router-Alert option.

Configuring IGMP packet options on an interface

Follow these steps to configure IGMP packet options on an interface:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure the interface to discard any IGMP message that does not carry the Router-Alert option	igmp require-router-alert	Optional By default, the device does not check the Router-Alert option.
Enable insertion of the Router-Alert option into IGMP messages	igmp send-router-alert	Optional By default, IGMP messages carry the Router-Alert option.

Configuring IGMP Query and Response Parameters

On startup, the IGMP querier sends “startup query count” IGMP general queries at the “startup query interval”, which is 1/4 of the “IGMP query interval”.

The IGMP querier periodically sends IGMP general queries at the “IGMP query interval” to determine whether any multicast group member exists on the network. You can tune the IGMP general query interval based on actual condition of the network.

Upon receiving an IGMP leave message, the IGMP querier sends “last member query count” IGMP group-specific queries at the “IGMP last member query interval”. IGMP is robust to “robustness variable minus 1” packet losses on a network. Therefore, a greater value of the robustness variable makes the IGMP querier “more robust”, but results in a longer multicast group timeout time.

Upon receiving an IGMP query (general query or group-specific query), a host starts a delay timer for each multicast group it has joined. This timer is initialized to a random value in the range of 0 to the maximum response time, which is derived from the Max Response Time field in the IGMP query. When the timer value comes down to 0, the host sends an IGMP report to the corresponding multicast group.

An appropriate setting of the maximum response time for IGMP queries allows hosts to respond to queries quickly and avoids bursts of IGMP traffic on the network caused by reports simultaneously sent by a large number of hosts when the corresponding timers expires simultaneously.

l For IGMP general queries, you can configure the maximum response time to fill their Max Response time field.

l For IGMP group-specific queries, you can configure the IGMP last member query interval to fill their Max Response time field. Namely, for IGMP group-specific queries, the maximum response time equals the IGMP last member query interval.

When multiple multicast routers exist on the same subnet, the IGMP querier is responsible for sending IGMP queries. If a non-querier router receives no IGMP query from the querier within the “other querier present interval”, it will assume the querier to have expired and a new querier election process is launched; otherwise, the non-querier router will reset its “other querier present timer”.

Configuring IGMP query and response parameters globally

Follow these steps to configure IGMP query and response parameters globally:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter public instance IGMP view or VPN instance IGMP view	igmp [ vpn-instance vpn-instance-name ]	—
Configure the startup query interval	startup-query-interval interval	Optional For the system default, see “Note” below.
Configure the startup query count	startup-query-count value	Optional For the system default, see “Note” below.
Configure the IGMP query interval	timer query interval	Optional 60 seconds by default
Configure the IGMP querier robustness variable	robust-count robust-value	Optional 2 by default
Configure the maximum response time for IGMP general queries	max-response-time interval	Optional 10 seconds by default
Configure the IGMP last member query interval	last-member-query-interval interval	Optional 1 second by default
Configure the other querier present interval	timer other-querier-present interval	Optional For the system default, see “Note” below.

Configuring IGMP query and response parameters on an interface

Follow these steps to configure IGMP query and response parameters on an interface:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Configure the startup query interval	igmp startup-query-interval interval	Optional For the system default, see “Note” below.
Configure the startup query count	igmp startup-query-count value	Optional For the system default, see “Note” below.
Configure the IGMP query interval	igmp timer query interval	Optional 60 seconds by default
Configure the IGMP querier robustness variable	igmp robust-count robust-value	Optional 2 by default
Configure the maximum response time for IGMP general queries	igmp max-response-time interval	Optional 10 seconds by default
Configure the IGMP last member query interval	igmp last-member-query-interval interval	Optional 1 second by default
Configure the other querier present interval	igmp timer other-querier-present interval	Optional For the system default, see “Note” below.

l If not statically configured, the startup query interval is 1/4 of the “IGMP query interval”. By default, the IGMP query interval is 60 seconds, so the startup query interval = 60 / 4 = 15 (seconds).

l If not statically configured, the startup query count is set to the IGMP querier robustness variable. By default, the IGMP querier robustness variable is 2, so the startup query count is also 2.

l If not statically configured, the other querier present interval is [ IGMP query interval ] times [ IGMP robustness variable ] plus [ maximum response time for IGMP general queries ] divided by two. The default values of these three parameters are 60 (seconds), 2 and 10 (seconds) respectively, so the other querier present interval = 60 × 2 + 10 / 2 = 125 (seconds).

l If statically configured, the startup query interval, the startup query count, and the other querier present interval take the configured values.

l Make sure that the other querier present interval is greater than the IGMP query interval; otherwise the IGMP querier may change frequently on the network.

l Make sure that the IGMP query interval is greater than the maximum response time for IGMP general queries; otherwise, multicast group members may be wrongly removed.

l The configurations of the maximum response time for IGMP general queries, the IGMP last member query interval and the IGMP other querier present interval are effective only for IGMPv2 or IGMPv3.

Configuring IGMP Fast Leave Processing

IGMP fast leave processing is implemented by IGMP Snooping. For details, refer to IGMP Snooping Configuration in the IP Multicast Volume.

Configuring IGMP SSM Mapping

Due to some possible restrictions, some receiver hosts on an SSM network may run IGMPv1 or IGMPv2. To provide SSM service support for these receiver hosts, you need to configure the IGMP mapping feature on the last hop router.

Configuration Prerequisites

Before configuring the IGMP SSM mapping feature, complete the following tasks:

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

l Configure basic functions of IGMP.

Enabling SSM Mapping

Follow these steps to enable the IGMP SSM mapping feature:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter interface view	interface interface-type interface-number	—
Enable the IGMP SSM mapping feature	igmp ssm-mapping enable	Required Disabled by default

To ensure SSM service for all hosts on a subnet, regardless of the IGMP version running on the hosts, enable IGMPv3 on the interface that forwards multicast traffic onto the subnet.

Configuring SSM Mappings

By performing this configuration multiple times, you can map a multicast group to different multicast sources.

Follow these steps to configure an IGMP SSM mapping:

To do…	Use the command…	Remarks
Enter system view	system-view	—
Enter public instance or VPN instance IGMP view	igmp [ vpn-instance vpn-instance-name ]	—
Configure an IGMP SSM mapping	ssm-mapping group-address { mask \| mask-length } source-address	Required No IGMP mappings are configured by default.

If IGMPv3 is enabled on a VLAN interface of a switch that supports both IGMP Snooping and IGMP, and if a port in that VLAN is configured as a simulated host, the simulated host will send IGMPv3 reports even if you did not specify a multicast source when configuring simulated joining with the igmp-snooping host-join command. In this case, the corresponding multicast group will not be created based on the configured IGMP SSM mappings. For details about the igmp-snooping host-join command, refer to IGMP Snooping Commands in the IP Multicast Volume.

Displaying and Maintaining IGMP

To do...	Use the command...
View IGMP multicast group information	display igmp [ all-instance \| vpn-instance vpn-instance-name ] group [ group-address \| interface interface-type interface-number ] [ static \| verbose ]	Available in any view
View layer 2 port information about IGMP multicast groups	display igmp group port-info [ vlan vlan-id ] [ slot slot-number ] [ verbose ]	Available in any view
View layer 2 port information about IGMP multicast groups		Available in any view
View IGMP configuration and operation information	display igmp [ all-instance \| vpn-instance vpn-instance-name ] interface [ interface-type interface-number ] [ verbose ]	Available in any view
View information in the IGMP routing table	display igmp [ all-instance \| vpn-instance vpn-instance-name ] routing-table [ source-address [ mask { mask \| mask-length } ] \| group-address [ mask { mask \| mask-length } ] ] *	Available in any view
View IGMP SSM mappings	display igmp [ all-instance \| vpn-instance vpn-instance-name ] ssm-mapping group-address	Available in any view
View the multicast group information created from IGMPv1 and IGMPv2 reports based on the configured IGMP SSM mappings	display igmp [ all-instance \| vpn-instance vpn-instance-name ] ssm-mapping group [ group-address \| interface interface-type interface-number ] [ verbose ]	Available in any view
Clear IGMP multicast group information	reset igmp [ all-instance \| vpn-instance vpn-instance-name ] group { all \| interface interface-type interface-number { all \| group-address [ mask { mask \| mask-length } ] [ source-address [ mask { mask \| mask-length } ] ] } }	Available in user view
Clear layer 2 port information about IGMP multicast groups	reset igmp group port-info { all \| group-address } [ vlan vlan-id ]	Available in user view
Clear IGMP SSM mappings	reset igmp [ all-instance \| vpn-instance vpn-instance-name ] ssm-mapping group { all \| interface interface-type interface-number { all \| group-address [ mask { mask \| mask-length } ] [ source-address [ mask { mask \| mask-length } ] ] } }	Available in user view

l The reset igmp group command cannot clear the IGMP multicast group information of static joins.

l The reset igmp group port-info command cannot clear Layer 2 port information about IGMP multicast groups of static joins.

The reset igmp group command may cause an interruption of receivers’ reception of multicast data.

IGMP Configuration Examples

Basic IGMP Functions Configuration Example

Network requirements

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

l Switch A in the PIM network connects to N1, and both Switch B and Switch C connect to N2.

l Switch A connects to N1 through VLAN-interface 100, and to other devices in the PIM network through VLAN-interface 101.

l Switch B and Switch C connect to N2 through their respective VLAN-interface 200, and to other devices in the PIM network through VLAN-interface 201 and VLAN-interface 202 respectively.

l IGMPv2 is required between Switch A and N1. IGMPv2 is also required between the other two switches and N2, Switch B serves as the IGMP querier in N2 because its IP address is lower.

Network diagram

Figure 1-4 Network diagram for basic IGMP functions configuration

Configuration procedure

1) Configure IP addresses and unicast routing

Configure the IP address and subnet mask of each interface as per Figure 1-4. The detailed configuration steps are omitted here.

Configure the OSPF protocol for interoperation on the PIM network. Ensure the network-layer interoperation on the PIM network and dynamic update of routing information among the switches through a unicast routing protocol. The detailed configuration steps are omitted here.

2) Enable IP multicast routing, and enable PIM-DM and IGMP

# Enable IP multicast routing on Switch A, enable PIM-DM on each interface, and enable IGMP on VLAN-interface 100.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] pim dm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim dm

[SwitchA-Vlan-interface101] quit

# Enable IP multicast routing on Switch B, enable PIM-DM on each interface, and enable IGMP on VLAN-interface 200.

<SwitchB> system-view

[SwitchB] multicast routing-enable

[SwitchB] interface vlan-interface 200

[SwitchB-Vlan-interface200] igmp enable

[SwitchB-Vlan-interface200] pim dm

[SwitchB-Vlan-interface200] quit

[SwitchB] interface vlan-interface 201

[SwitchB-Vlan-interface201] pim dm

[SwitchB-Vlan-interface201] quit

# Enable IP multicast routing on Switch C, enable PIM-DM on each interface, and enable IGMP on VLAN-interface 200.

<SwitchC> system-view

[SwitchC] multicast routing-enable

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] igmp enable

[SwitchC-Vlan-interface200] pim dm

[SwitchC-Vlan-interface200] quit

[SwitchC] interface vlan-interface 202

[SwitchC-Vlan-interface202] pim dm

[SwitchC-Vlan-interface202] quit

3) Verify the configuration

Carry out the display igmp interface command to view the IGMP configuration and operation status on each switch interface. For example:

# View IGMP information on VLAN-interface 200 of Switch B.

[SwitchB] display igmp interface vlan-interface 200

Vlan-interface200(10.110.2.1):

IGMP is enabled

Current IGMP version is 2

Value of query interval for IGMP(in seconds): 60

Value of other querier present interval for IGMP(in seconds): 125

Value of maximum query response time for IGMP(in seconds): 10

Querier for IGMP: 10.110.2.1 (this router)

Total 1 IGMP Group reported

SSM Mapping Configuration Example

Network requirements

l On the PIM-SSM network shown in Figure 1-5, the receiver host receives VOD information through multicast. The receiver host runs IGMPv2, so it cannot specify the expected multicast sources in its membership reports.

l It is required to configure the IGMP SSM mapping feature on Switch D so that the receiver host will receive multicast data from Source 1 and Source 3 only.

Network diagram

Figure 1-5 Network diagram for IGMP SSM mapping configuration

Device	Interface	IP address	Device	Interface	IP address
Source 1	—	133.133.1.1/24	Source 3	—	133.133.3.1/24
Source 2	—	133.133.2.1/24	Receiver	—	133.133.4.1/24
Switch A	Vlan-int100	133.133.1.2/24	Switch C	Vlan-int300	133.133.3.2/24
	Vlan-int101	192.168.1.1/24		Vlan-int103	192.168.3.1/24
	Vlan-int104	192.168.4.2/24		Vlan-int102	192.168.2.2/24
Switch B	Vlan-int200	133.133.2.2/24	Switch D	Vlan-int400	133.133.4.2/24
	Vlan-int101	192.168.1.2/24		Vlan-int103	192.168.3.2/24
	Vlan-int102	192.168.2.1/24		Vlan-int104	192.168.4.1/24

Configuration procedure

1) Configure IP addresses and unicast routing

Configure the IP address and subnet mask of each interface as per Figure 1-5. The detailed configuration steps are omitted here.

Configure OSPF for interoperability among the switches. Ensure the network-layer interoperation on the PIM-SSM network and dynamic update of routing information among the switches through a unicast routing protocol. The detailed configuration steps are omitted here.

2) Enable IP multicast routing, enable PIM-SM on each interface, and enable IGMP and IGMP SSM mapping on the host-side interface.

# Enable IP multicast routing on Switch D, enable PIM-SM on each interface, and enable IGMPv3 and IGMP SSM mapping on VLAN-interface 400.

<SwitchD> system-view

[SwitchD] multicast routing-enable

[SwitchD] interface vlan-interface 400

[SwitchD-Vlan-interface400] igmp enable

[SwitchD-Vlan-interface400] igmp version 3

[SwitchD-Vlan-interface400] igmp ssm-mapping enable

[SwitchD-Vlan-interface400] pim sm

[SwitchD-Vlan-interface400] quit

[SwitchD] interface vlan-interface 103

[SwitchD-Vlan-interface103] pim sm

[SwitchD-Vlan-interface103] quit

[SwitchD] interface vlan-interface 104

[SwitchD-Vlan-interface104] pim sm

[SwitchD-Vlan-interface104] quit

# Enable IP multicast routing on Switch A, and enable PIM-SM on each interface.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] pim sm

[SwitchA-Vlan-interface100] quit

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim sm

[SwitchA-Vlan-interface101] quit

[SwitchA] interface vlan-interface 104

[SwitchA-Vlan-interface104] pim sm

[SwitchA-Vlan-interface104] quit

The configuration on Switch B and Switch C is similar to that on Switch A.

3) Configure the SSM group range

# Configure the SSM group range 232.1.1.0/24 on Switch D.

[SwitchD] acl number 2000

[SwitchD-acl-basic-2000] rule permit source 232.1.1.0 0.0.0.255

[SwitchD-acl-basic-2000] quit

[SwitchD] pim

[SwitchD-pim] ssm-policy 2000

[SwitchD-pim] quit

The configuration on Switch A, Switch B and Switch C is similar to that on Switch D.

4) Configure IGMP SSM mappings

# Configure IGMP SSM mappings on Switch D.

[SwitchD] igmp

[SwitchD-igmp] ssm-mapping 232.1.1.0 24 133.133.1.1

[SwitchD-igmp] ssm-mapping 232.1.1.0 24 133.133.3.1

[SwitchD-igmp] quit

5) Verify the configuration

Use the display igmp ssm-mapping command to view the IGMP SSM mappings on the switch.

# View the IGMP SSM mapping information for multicast group 232.1.1.1 on Switch D.

[SwitchD] display igmp ssm-mapping 232.1.1.1

VPN-Instance: public net

Group: 232.1.1.1

Source list:

133.133.1.1

133.133.3.1

Use the display igmp ssm-mapping group command to view the multicast group information created based on the configured IGMP SSM mappings.

# View the IGMP multicast group information created based on the IGMP SSM mappings on Switch D.

[SwitchD] display igmp ssm-mapping group

Total 1 IGMP SSM-mapping Group(s).

Interface group report information of VPN-Instance: public net

Vlan-interface400(133.133.4.2):

Total 1 IGMP SSM-mapping Group reported

Group Address Last Reporter Uptime Expires

232.1.1.1 133.133.4.1 00:02:04 off

Use the display pim routing-table command to view the PIM routing table information on each switch.

# View the PIM routing table information on Switch D.

[SwitchD] display pim routing-table

VPN-Instance: public net

Total 0 (*, G) entry; 2 (S, G) entry

(133.133.1.1, 232.1.1.1)

RP: 192.168.4.1 _

Protocol: pim-ssm, Flag:

UpTime: 00:13:25

Upstream interface: Vlan-interface104

Upstream neighbor: 192.168.4.2

RPF prime neighbor: 192.168.4.2

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface400

Protocol: igmp, UpTime: 00:13:25, Expires: -

(133.133.3.1, 232.1.1.1)

RP: 192.168.4.1 _

Protocol: pim-ssm, Flag:

UpTime: 00:13:25

Upstream interface: Vlan-interface103

Upstream neighbor: 192.168.3.1

RPF prime neighbor: 192.168.3.1

Downstream interface(s) information:

Total number of downstreams: 1

1: Vlan-interface400

Protocol: igmp, UpTime: 00:13:25, Expires: -

Troubleshooting IGMP

No Membership Information on the Receiver-Side Router

Symptom

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

Analysis

l 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.

l Multicast routing must be enabled on the router, and IGMP must be enabled on the interface connecting to the host.

l If the IGMP version on the router interface is lower than that on the host, the router will not be able to recognize the IGMP report from the host.

l If the igmp group-policy command has been configured on the interface, the interface cannot receive report messages that fail to pass filtering.

Solution

1) Check that the networking, interface connection, and IP address configuration are correct. Check the interface information with the display igmp interface command. If there is no information output, the interface is in an abnormal state. This is usually because you have configured the shutdown command on the interface, the interface is not properly connected, or the IP address configuration is not correctly done.

2) Check that multicast routing is enabled. Carry out the display current-configuration command to check whether the multicast routing-enable command has been executed. If not, carry out the multicast routing-enable command in system view to enable IP multicast routing. In addition, check that IGMP is enabled on the corresponding interfaces.

3) Check the IGMP version on the interface. You can use the display igmp interface command to check whether the IGMP version on the interface is lower than that on the host.

4) Check that no ACL rule has been configured to restrict the host from joining the multicast group G. Carry out the display current-configuration interface command to check whether the igmp group-policy command has been executed. If the host is restricted from joining the multicast group G, the ACL rule must be modified to allow receiving the reports for the multicast group G.

Inconsistent Memberships on Routers on the Same Subnet

Symptom

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

Analysis

l A router running IGMP maintains multiple parameters for each interface, and these parameters influence one another, forming very complicated relationships. Inconsistent IGMP interface parameter configurations for routers on the same subnet will surely result in inconsistency of memberships.

l In addition, although an IGMP router is compatible with a host that is running a different IGMP version, all routers on the same subnet must run the same version of IGMP. Inconsistent IGMP versions running on routers on the same subnet will also lead to inconsistency of IGMP memberships.

Solution

1) Check the IGMP configuration. Carry out the display current-configuration command to view the IGMP configuration information on the interfaces.

2) Carry out the display igmp interface command on all routers on the same subnet to check the IGMP-related timer settings. Make sure that the settings are consistent on all the routers.

3) Use the display igmp interface command to check whether all the routers on the same subnet are running the same version of IGMP.

04-IP Multicast Volume

IGMP Overview

Querier election mechanism

“Leave group” mechanism

Enhancements in control capability of hosts

Enhancements in query and report capabilities

IGMP Configuration Task List

Configuring Basic Functions of IGMP

Enabling IGMP

Enabling IGMP in the public instance

Enabling IGMP in a VPN instance

Configuring IGMP Versions

Configuring an IGMP version globally

Configuring an IGMP version on an interface

Configuring Static Joining

Configuring a Multicast Group Filter

Adjusting IGMP Performance

Configuring IGMP Message Options

Configuring IGMP packet options globally

Configuring IGMP packet options on an interface

Configuring IGMP Query and Response Parameters

Configuring IGMP query and response parameters globally

Configuring IGMP query and response parameters on an interface

Configuring IGMP Fast Leave Processing

Configuring IGMP SSM Mapping

IGMP Configuration Examples

Network requirements

Network diagram

Configuration procedure

SSM Mapping Configuration Example

Network requirements

Network diagram

Configuration procedure

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Cloud & AI

InterConnect

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Resources

Partner Business Management

Company Information

News & Events

Contact Us