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

IGMP versions

· IGMPv1 (documented in RFC 1112)

· IGMPv2 (documented in RFC 2236)

· IGMPv3 (documented in RFC 3376)

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

NOTE:

For more information about the ASM and SSM models, see the chapter “Multicast overview.”

IGMPv1 overview

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

All the multicast routers on the same subnet can get IGMP membership report messages (often called “reports”) from hosts, but the subnet needs only one router for sending 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 working multicast routing protocol (such as PIM) serves as the IGMP querier.

NOTE:

For more information about DR, see the chapter “Configuring PIM.”

Figure 1 IGMP queries and reports

Assume that Host B and Host C will receive multicast data addressed to multicast group G1, and Host A will receive multicast data addressed to G2, as shown in Figure 1. The following process describes how the hosts join the multicast groups and how 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. After 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 that Host B sends the report message. After receiving the report from Host B, Host C (which is on the same subnet as Host B) suppresses its own report for G1, because the IGMP routers (Router A and Router B) have already known that at least one host on the local subnet is interested in G1. This mechanism (known as “IGMP report suppression”) 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 query/report process, the IGMP routers determine that members of G1 and G2 are attached to the local subnet, and the multicast routing protocol (PIM, for example) that is running on the routers generates (*, G1) and (*, G2) multicast forwarding entries. These entries will be the basis for subsequent multicast forwarding, where asterisk 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.

IGMPv1 does not specifically define a leave group message—often called a “leave message”. When an IGMPv1 host is leaving a multicast group, it stops sending reports to the address of the multicast group that it listened to. If no member exists in a multicast group on the subnet, the IGMP router will not receive any report addressed to that multicast group. In this case, the router will delete the multicast forwarding entries for that multicast group after a period of time.

IGMPv2 enhancements

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.

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

1. Initially, every IGMPv2 router assumes itself as 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 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 determine whether a group has members. This adds to the leave latency.

In IGMPv2, when a host leaves a multicast group, the following steps occur:

1. This 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. The destination address field and group address field of the message are both filled with the address of the multicast group that is being queried.

3. One of the remaining members—if any on the subnet—of the group that is 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.

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 has introduced source filtering modes (Include and Exclude), so that a host not only can join a designated multicast group, but also can specify to receive or reject multicast data from designated multicast sources. When a host joins a multicast group, one of the following situations occurs:

· If it needs 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 it needs 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 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 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 that it needs to receive the multicast data that Source 1 sends to multicast group G (denoted as (S1, G)), rather than the multicast data that 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

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

¡ A general query does not carry a group address, nor 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 record has the following types:

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

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

¡ 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 that the system wants to obtain data from, 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 that the system no longer wants to obtain data from, 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.

IGMP SSM mapping

The IGMP SSM mapping feature enables you to configure static IGMP SSM mappings on the last hop router to provide SSM support for receiver hosts that are running IGMPv1 or IGMPv2. The SSM model assumes that the last hop router has already known the desired multicast sources when receivers join multicast groups.

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

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

Figure 3 Network diagram

As shown in Figure 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 if IGMPv3 is not available on Host A and Host B, you must 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:

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

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

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

NOTE:

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

· For more information about the SSM group range, see the chapter “Configuring PIM.”

IGMP proxying

In some simple tree-shaped topologies, it is not necessary to configure complex multicast routing protocols, such as PIM, on the boundary devices. Instead, you can configure IGMP proxying on these devices. With IGMP proxying configured, the device serves as a proxy for the downstream hosts to send IGMP messages, maintain group memberships, and implement multicast forwarding based on the memberships. In this case, each boundary device is a host but no longer a PIM neighbor to the upstream device.

Figure 4 Network diagram

As shown in Figure 4, the following types of interfaces are defined on an IGMP proxy device:

· Upstream interface—Also called the “proxy interface”. A proxy interface is an interface on which IGMP proxying is configured. It is in the direction toward the root of the multicast forwarding tree. An upstream interface acts as a host that is running IGMP. Therefore, it is also called the “host interface”.

· Downstream interface—An interface that is running IGMP and is not in the direction toward the root of the multicast forwarding tree. A downstream interface acts as a router that is running IGMP. Therefore, it is also called the “router interface”.

A device with IGMP proxying configured maintains a group membership database, which stores the group memberships on all the downstream interfaces. Each entry comprises the multicast address, filter mode, and source list. Such an entry is a collection of members in the same multicast group on each downstream interface.

A proxy device performs host functions on the upstream interface based on the database. It responds to queries according to the information in the database or sends join/leave messages when the database changes. On the other hand, the proxy device performs router functions on the downstream interfaces by participating in the querier election, sending queries, and maintaining memberships based on the reports.

Multi-instance IGMP

IGMP maintains group memberships on a per-interface base. IGMP in an instance handles protocol packets based on the instance on the interface. After 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 an instance needs to exchange information with another multicast protocol, the router informs the other multicast protocol only within the instance.

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

· RFC 4605, Internet Group Management Protocol (IGMP)/Multicast Listener Discovery (MLD)-Based Multicast Forwarding (“IGMP/MLD Proxying”)

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
	Setting the maximum number of multicast groups that an interface can join	Optional
Adjusting IGMP performance	Configuring IGMP message options	Optional
	Configuring IGMP query and response parameters	Optional
	Configuring IGMP fast-leave processing	Optional
	Enabling the IGMP host tracking function	Optional
Configuring IGMP SSM mapping	Enabling SSM mapping	Optional
Configuring IGMP SSM mapping	Configuring SSM mappings	Optional
Configuring IGMP proxying	Enabling IGMP proxying	Optional
Configuring IGMP proxying	Configuring multicast forwarding on a downstream interface	Optional

NOTE:

· In IGMP view, the configuration is effective on all interfaces. In interface view, the configuration is effective on only the current interface.

· If a feature is not configured on an interface in interface view, the global configuration in IGMP view applies to that interface. If a feature is configured in both IGMP view and interface view, the configuration in interface view will be given priority.

Configuring basic functions of IGMP

Configuration prerequisites

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

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

· Configure PIM-DM or PIM-SM.

· Determine the IGMP version.

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

· Determine the ACL rule for multicast group filtering.

· Determine the maximum number of multicast groups that an interface can join.

Enabling IGMP

To configure IGMP, you must enable IGMP on the interface on which the multicast group memberships will be established and maintained.

Enabling IGMP for the public network

To enable IGMP for the public network:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enable IP multicast routing.	multicast routing-enable	Disabled by default
3. Enter interface view.	interface interface-type interface-number	N/A
4. Enable IGMP.	igmp enable	Disabled by default

Enabling IGMP in a VPN instance

To enable IGMP in a VPN instance:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Create a VPN instance and enter VPN instance view.	ip vpn-instance vpn-instance-name	N/A
3. Configure an RD for the VPN instance.	route-distinguisher route-distinguisher	No RD is configured by default.
4. Enable IP multicast routing.	multicast routing-enable	Disabled by default.
5. Enter interface view.	interface interface-type interface-number	N/A
6. Bind the interface with a VPN instance.	ip binding vpn-instance vpn-instance-name	By default, an interface belongs to the public network, and is not bound with any VPN instance.
7. Enable IGMP.	igmp enable	Disabled by default.

NOTE:

· For more information about the ip vpn-instance, route-distinguisher, and ip binding vpn-instance commands, see MPLS Command Reference.

· For more information about the multicast routing-enable command, see IP Multicast Command Reference.

CAUTION:

· Receiver hosts can join multicast groups only if IGMP is enabled on the receiver-side DRs. For more information about DRs, see the chapter “Configuring PIM.”

· IGMP snooping is not allowed in a VLAN after IGMP is enabled on the virtual interface of that VLAN, and vice versa.

Configuring IGMP versions

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

Configuring an IGMP version globally

To configure an IGMP version globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter public network IGMP view or VPN instance IGMP view.	igmp [ vpn-instance vpn-instance-name ]	N/A
3. Configure an IGMP version globally.	version version-number	IGMPv2 by default

Configuring an IGMP version on an interface

To configure an IGMP version on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure an IGMP version on the interface.	igmp version version-number	IGMPv2 by default.

Configuring static joining

After an interface is configured as a static member of a multicast group or a multicast source 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.

To configure an interface as a statically connected member of a multicast group or a multicast source and group:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. 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 ]	An interface is not a static member of any multicast group or multicast source and group by default.

NOTE:

· 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, see the chapter “Configuring PIM.”

· A static member port does not respond to queries from the IGMP querier. When you configure a port as a static member port or remove this configuration on the port, the port does not unsolicitedly send any IGMP report or IGMP leave message. In other words, the port is not 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 so that the interface maintains only the multicast groups the match the criteria.

To configure a multicast group filter:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure a multicast group filter.	igmp group-policy acl-number [ version-number ]	By default, no multicast group filter is configured on this interface. Namely, hosts on the current interface can join any valid multicast group.

NOTE:

· When you use an advanced ACL as a filter, the source address in the ACL rule is the IP address of the multicast source specified in the IGMPv3 reports, rather than the source address of IP packets.

· To configure a multicast group filter on an Ethernet port, use the igmp-snooping group-policy or group-policy (IGMP snooping view) command. For more information, see IP Multicast Command Reference.

· A multicast group filter does not function for statically joined multicast groups on interfaces.

Setting the maximum number of multicast groups that an interface can join

To configure the maximum number of multicast groups an interface can join:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure the maximum number of multicast groups that the interface can join.	igmp group-limit limit	By default, the maximum number of multicast groups that an interface can join depends on the system working mode, that is, 16384 in SPE mode, 32768 in SPC mode, and 16384 in hybrid mode. For more information about the system working mode, see Fundamentals Configuration Guide.

NOTE:

This configuration takes effect in dynamically joined multicast groups but not in the statically configured multicast groups.

Adjusting IGMP performance

NOTE:

For the configuration tasks described in this section:

· In IGMP view, the configuration is effective on all interfaces. In interface view, the configuration is effective on only the current interface.

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

Configuration prerequisites

Before adjusting IGMP performance, complete the following tasks:

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

· Configure basic functions of IGMP.

· Determine the startup query interval.

· Determine the startup query count.

· Determine the IGMP general query interval.

· Determine the IGMP querier’s robustness variable.

· Determine the maximum response time for IGMP general queries.

· Determine the IGMP last-member query interval.

· Determine the 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 an IGMP router receives a multicast packet but cannot locate the outgoing interface for the destination multicast group, it must use the Router-Alert option to pass the multicast packet to the upper-layer protocol for processing. For more information about the Router-Alert option, see RFC 2113.

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

· By default, for the consideration of compatibility, the device does not verify the Router-Alert option. It processes all the IGMP messages that it received. In this case, IGMP messages are directly passed to the upper layer protocol, whether the IGMP messages carry the Router-Alert option or not.

· 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

To configure IGMP packet options globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter public network IGMP view or VPN instance IGMP view.	igmp [ vpn-instance vpn-instance-name ]	N/A
3. Configure the router to discard any IGMP message that does not carry the Router-Alert option.	require-router-alert	By default, the device does not check the Router-Alert option.
4. Enable insertion of the Router-Alert option into IGMP messages.	send-router-alert	By default, IGMP messages carry the Router-Alert option.

Configuring IGMP packet options on an interface

To configure IGMP packet options on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure the interface to discard any IGMP message that does not carry the Router-Alert option.	igmp require-router-alert	By default, the device does not check the Router-Alert option.
4. Enable insertion of the Router-Alert option into IGMP messages.	igmp send-router-alert	By default, IGMP messages carry the Router-Alert option.

Configuring IGMP query and response parameters

On startup, the IGMP querier sends IGMP general queries at the startup query interval, which is one-quarter of the IGMP general query interval. The number of queries, or the startup query count, is user configurable.

After startup, the IGMP querier periodically sends IGMP general queries at the IGMP general query interval to check for multicast group members on the network. You can modify the IGMP general query interval based on actual condition of the network.

The IGMPv2 querier sends IGMP group-specific queries at the IGMP last-member query interval when it receives an IGMP leave message. The IGMPv3 querier sends IGMP group-and-source-specific queries at the IGMP last-member query interval when it receives a multicast group and multicast mapping change report. The number of queries, or the last-member query count, equals the robustness variable—the maximum number of packet retransmissions.

A multicast listening host starts a delay timer for each multicast group it has joined when it receives an IGMP query (general query, group-specific query, or group-and-source-specific query). The timer is initialized to a random value in the range of 0 to the maximum response time derived in the IGMP query. When the timer value decreases to 0, the host sends an IGMP report to the corresponding multicast group.

To speed up the response of hosts to IGMP queries and avoid simultaneous timer expirations causing IGMP report traffic bursts, you must properly set the maximum response time.

· For IGMP general queries, the maximum response time is set by the max-response-time command.

· For IGMP group-specific queries and IGMP group-and-source-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 when the other querier present interval expires, it considers that the querier as having failed and starts a new querier election. Otherwise, the non-querier router resets the other querier present timer.

Configuring IGMP query and response parameters globally

To configure IGMP query and response parameters globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter public network IGMP view or VPN instance IGMP view.	igmp [ vpn-instance vpn-instance-name ]	N/A
3. Configure the IGMP querier’s robustness variable.	robust-count robust-value	2 by default.
4. Configure the startup query interval.	startup-query-interval interval	By default, the startup query interval is 1/4 of the “IGMP general query interval”.
5. Configure the startup query count.	startup-query-count value	By default, the startup query count is set to the IGMP querier’s robustness variable.
6. Configure the IGMP general query interval.	timer query interval	60 seconds by default.
7. Configure the maximum response time for IGMP general queries.	max-response-time interval	10 seconds by default.
8. Configure the IGMP last-member query interval.	last-member-query-interval interval	1 second by default.
9. Configure the other querier present interval.	timer other-querier-present interval	By default, the other querier present interval is [ IGMP general query interval ] × [ IGMP robustness variable ] + [ maximum response time for IGMP general queries ] / 2.

Configuring IGMP query and response parameters on an interface

To configure IGMP query and response parameters on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure the IGMP querier’s robustness variable.	igmp robust-count robust-value	2 by default.
4. Configure the startup query interval.	igmp startup-query-interval interval	By default, the startup query interval is 1/4 of the “IGMP general query interval”.
5. Configure the startup query count.	igmp startup-query-count value	By default, the startup query count is set to the IGMP querier’s robustness variable.
6. Configure the IGMP general query interval.	igmp timer query interval	60 seconds by default.
7. Configure the maximum response time for IGMP general queries.	igmp max-response-time interval	10 seconds by default.
8. Configure the IGMP last member query interval.	igmp last-member-query-interval interval	1 second by default.
9. Configure the other querier present interval.	igmp timer other-querier-present interval	By default, the other querier present interval is [ IGMP general query interval ] × [ IGMP robustness variable ] + [ maximum response time for IGMP general queries ] / 2.

CAUTION:

· Make sure that the other querier present interval is greater than the IGMP general query interval. Otherwise the IGMP querier might change frequently on the network.

· Make sure that the IGMP general query interval is greater than the maximum response time for IGMP general queries. Otherwise, multicast group members might be wrongly removed.

· 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 and IGMPv3.

Configuring IGMP fast-leave processing

In some applications, such as ADSL dial-up networking, only one multicast receiver host is attached to a port 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 IGMP fast-leave processing on the IGMP querier.

With 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. Thus, the leave latency is reduced on one hand, and the network bandwidth is saved on the other hand.

Configuring IGMP fast-leave processing globally

To configure IGMP fast-leave processing globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter public network IGMP view or VPN instance IGMP view.	igmp [ vpn-instance vpn-instance-name ]	N/A
3. Configure IGMP fast-leave processing.	fast-leave [ group-policy acl-number ]	Disabled by default

Configuring IGMP fast-leave processing on an interface

To configure IGMP fast-leave processing on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Configure IGMP fast-leave processing.	igmp fast-leave [ group-policy acl-number ]	Disabled by default

NOTE:

· Configurations made in IGMP view using the fast-leave command are effective for other Layer 3 interfaces than VLAN interfaces.

· To enable fast-leave processing for member ports of a specific VLAN, use the igmp-snooping fast-leave or fast-leave (IGMP snooping view) command. For more information, see IP Multicast Command Reference.

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

Enabling the IGMP host tracking function

With the IGMP host tracking function, the router can record the information of the member hosts that are receiving multicast traffic, including the host IP address, running duration, and timeout time. You can monitor and manage the member hosts according to the recorded information.

Enabling the IGMP host tracking function globally

To enable the IGMP host tracking function globally:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter public network IGMP view/VPN instance IGMP view.	igmp [ vpn-instance vpn-instance-name ]	N/A
3. Enable the IGMP host tracking function globally.	host-tracking	Disabled by default

Enabling the IGMP host tracking function on an interface

To enable the IGMP host tracking function on an interface:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable the IGMP host tracking function on the interface.	igmp host-tracking	Disabled by default

Configuring IGMP SSM mapping

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

Configuration prerequisites

Before you configure the IGMP SSM mapping feature, complete the following tasks:

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

· Configure basic functions of IGMP.

Enabling SSM mapping

To enable the IGMP SSM mapping feature:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable the IGMP SSM mapping feature.	igmp ssm-mapping enable	Disabled by default

NOTE:

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.

To configure an IGMP SSM mapping:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter public network IGMP view or VPN instance IGMP view.	igmp [ vpn-instance vpn-instance-name ]	N/A
3. Configure an IGMP SSM mapping.	ssm-mapping group-address { mask \| mask-length } source-address	No IGMP mappings are configured by default.

CAUTION:

If IGMPv3 is enabled on a VLAN interface, 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 you configure 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 more information about the igmp-snooping host-join command, see IP Multicast Command Reference.

Configuring IGMP proxying

Configuration prerequisites

Before you configure the IGMP proxying feature, complete the following tasks:

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

· Enable IP multicast routing.

Enabling IGMP proxying

You can enable IGMP proxying on the interface in the direction toward the root of the multicast forwarding tree to make the device serve as an IGMP proxy.

To enable IGMP proxying:

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable the IGMP proxying feature.	igmp proxying enable	Disabled by default

NOTE:

· Each device can have only one interface serving as the proxy interface. In scenarios with multiple instances, IGMP proxying is configured on only one interface per instance.

· You cannot enable IGMP on an interface with IGMP proxying enabled. Moreover, only the igmp require-router-alert, igmp send-router-alert, and igmp version commands can take effect on such an interface.

· You cannot enable other multicast routing protocols (such as PIM-DM or PIM-SM) on an interface with IGMP proxying enabled, or vice versa. However, the source-lifetime, source-policy, and ssm-policy commands configured in PIM view can still take effect. In addition, in IGMPv1, the designated router (DR) is elected by the working multicast routing protocol (such as PIM) to serve as the IGMP querier. Therefore, a downstream interface running IGMPv1 cannot be elected as the DR and thus cannot serve as the IGMP querier.

· You cannot enable IGMP proxying on a VLAN interface with IGMP snooping enabled, or vice versa.

Configuring multicast forwarding on a downstream interface

Only queriers can forward multicast traffic but non-queriers have no multicast forwarding capabilities, to avoid duplicate multicast flows. It is the same on IGMP proxy devices. Only the downstream interfaces acting as a querier can forward multicast traffic to downstream hosts.

However, when a downstream interface of a proxy device fails to win the querier election, you must enable multicast forwarding on this interface.

To enable multicast forwarding on a downstream interface

Step	Command	Remarks
1. Enter system view.	system-view	N/A
2. Enter interface view.	interface interface-type interface-number	N/A
3. Enable multicast forwarding on a non-querier downstream interface.	igmp proxying forwarding	Disabled by default

CAUTION:

On a multi-access network with more than one IGMP proxy device, you cannot enable multicast forwarding on any other non-querier downstream interface after one of the downstream interfaces of these IGMP proxy devices has been elected as the querier. Otherwise, duplicate multicast flows might be received on the multi-access network.

Displaying and maintaining IGMP

Task	Command	Remarks
Display IGMP group information.	display igmp [ all-instance \| vpn-instance vpn-instance-name ] group [ group-address \| interface interface-type interface-number ] [ static \| verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the Layer 2 port information of IGMP groups.	display igmp group port-info [ vlan vlan-id ] [ slot slot-number ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about the hosts tracked by IGMP on an interface.	display igmp host interface interface-type interface-number group group-address [ source source-address ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about the hosts tracked by IGMP on the Layer 2 ports (on a distributed device).	display igmp host port-info vlan vlan-id group group-address [ source source-address ] [ vlan vlan-id ] [ slot slot-number ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display IGMP configuration and operation information.	display igmp [ all-instance \| vpn-instance vpn-instance-name ] interface [ interface-type interface-number ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display the information of IGMP proxying groups.	display igmp [ all-instance \| vpn-instance vpn-instance-name ] proxying group [ group-address ] [ verbose ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display 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 } ] \| flags { act \| suc } ] * [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display IGMP SSM mappings.	display igmp [ all-instance \| vpn-instance vpn-instance-name ] ssm-mapping group-address [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display 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 ] [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Display information about the hosts that join the group based on IGMP SSM mappings on an interface.	display igmp ssm-mapping host interface interface-type interface-number group group-address source source-address [ \| { begin \| exclude \| include } regular-expression ]	Available in any view
Remove all the dynamic IGMP group entries of a specified IGMP group or all IGMP groups.	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
Remove all the dynamic Layer 2 port entries of a specified IGMP group or all IGMP 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

NOTE:

· The reset igmp group command cannot remove static IGMP group entries.

· The reset igmp group port-info command cannot remove the static Layer 2 port entries of IGMP groups.

CAUTION:

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

IGMP configuration examples

Basic IGMP functions configuration example

Network requirements

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.

IGMPv2 runs between Router A and N1. IGMPv2 runs between the other two routers and N2. Router B acts as the IGMP querier in N2 because it has a lower IP address.

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

Figure 5 Network diagram

Configuration procedure

1. Assign IP addresses and configure unicast routing:

Assign an IP address and subnet mask of each interface as per Figure 5. (Details not shown)

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 routers through a unicast routing protocol. (Details not shown)

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

# Enable IP multicast routing on Router A, enable PIM-DM on each interface, and enable IGMP on GigabitEthernet 3/1/1.

<RouterA> system-view

[RouterA] multicast routing-enable

[RouterA] interface GigabitEthernet 3/1/1

[RouterA-GigabitEthernet3/1/1] igmp enable

[RouterA-GigabitEthernet3/1/1] pim dm

[RouterA-GigabitEthernet3/1/1] quit

[RouterA] interface pos 5/1/1

[RouterA-Pos5/1/1] pim dm

[RouterA-Pos5/1/1] quit

# Enable IP multicast routing on Router B, enable PIM-DM on each interface, and enable IGMP on GigabitEthernet 3/1/1.

<RouterB> system-view

[RouterB] multicast routing-enable

[RouterB] interface GigabitEthernet 3/1/1

[RouterB-GigabitEthernet3/1/1] igmp enable

[RouterB-GigabitEthernet3/1/1] pim dm

[RouterB-GigabitEthernet3/1/1] quit

[RouterB] interface POS 5/1/1

[RouterB-Pos5/1/1] pim dm

[RouterB-Pos5/1/1] quit

# Enable IP multicast routing on Router C, enable PIM-DM on each interface, and enable IGMP on GigabitEthernet 3/1/1.

<RouterC> system-view

[RouterC] multicast routing-enable

[RouterC] interface GigabitEthernet 3/1/1

[RouterC-GigabitEthernet3/1/1] igmp enable

[RouterC-GigabitEthernet3/1/1] pim dm

[RouterC-GigabitEthernet3/1/1] quit

[RouterC] interface POS 5/1/1

[RouterC-Pos5/1/1] pim dm

[RouterC-Pos5/1/1] quit

3. Configure a multicast group filter:

# Configure a multicast group filter on Router A, so that the hosts connected to GigabitEthernet 3/1/1 can join only multicast group 224.1.1.1.

[RouterA] acl number 2001

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

[RouterA-acl-basic-2001] quit

[RouterA] interface GigabitEthernet 3/1/1

[RouterA-GigabitEthernet3/1/1] igmp group-policy 2001

[RouterA-GigabitEthernet3/1/1] quit

4. Verify the configuration:

# Display IGMP information on GigabitEthernet 3/1/1 of Router B.

[RouterB] display igmp interface GigabitEthernet 3/1/1

GigabitEthernet3/1/1(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

The PIM-SM domain applies both the ASM model and SSM model for multicast delivery. Router D’s GigabitEthernet 3/1/3 serves as the C-BSR and C-RP. The SSM group range is 232.1.1.0/24.

IGMPv3 runs on Router D’s GigabitEthernet 3/1/1. The Receiver host runs IGMPv2, and does not support IGMPv3. Therefore, the Receiver host cannot specify expected multicast sources in its membership reports.

Source 1, Source 2, and Source 3 send multicast packets to multicast groups in the SSM group range. You can configure the IGMP SSM mapping feature on Router D so that the receiver host will receive multicast data from Source 1 and Source 3 only.

Figure 6 Network diagram

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
Router A	GE3/1/1	133.133.1.2/24	Router C	GE3/1/1	133.133.3.2/24
	GE3/1/2	192.168.1.1/24		GE3/1/2	192.168.3.1/24
	GE3/1/3	192.168.4.2/24		GE3/1/3	192.168.2.2/24
Router B	GE3/1/1	133.133.2.2/24	Router D	GE3/1/1	133.133.4.2/24
	GE3/1/2	192.168.1.2/24		GE3/1/2	192.168.3.2/24
	GE3/1/3	192.168.2.1/24		GE3/1/3	192.168.4.1/24

Configuration procedure

1. Assign IP addresses and configure unicast routing:

Assign an IP address and subnet mask for each interface as per Figure 6. (Details not shown)

Configure OSPF for interoperability among the routers. Ensure the network-layer interoperation in the PIM-SM domain and dynamic update of routing information among the routers through a unicast routing protocol. (Details not shown)

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 Router D, enable PIM-SM on each interface and enable IGMPv3 and IGMP SSM mapping on GigabitEthernet 3/1/1.

<RouterD> system-view

[RouterD] multicast routing-enable

[RouterD] interface GigabitEthernet 3/1/1

[RouterD-GigabitEthernet3/1/1] igmp enable

[RouterD-GigabitEthernet3/1/1] igmp version 3

[RouterD-GigabitEthernet3/1/1] igmp ssm-mapping enable

[RouterD-GigabitEthernet3/1/1] pim sm

[RouterD-GigabitEthernet3/1/1] quit

[RouterD] interface GigabitEthernet 3/1/2

[RouterD-GigabitEthernet3/1/2] pim sm

[RouterD-GigabitEthernet3/1/2] quit

[RouterD] interface GigabitEthernet 3/1/3

[RouterD-GigabitEthernet3/1/3] pim sm

[RouterD-GigabitEthernet3/1/3] quit

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

<RouterA> system-view

[RouterA] multicast routing-enable

[RouterA] interface GigabitEthernet 3/1/1

[RouterA-GigabitEthernet3/1/1] pim sm

[RouterA-GigabitEthernet3/1/1] quit

[RouterA] interface GigabitEthernet 3/1/2

[RouterA-GigabitEthernet3/1/2] pim sm

[RouterA-GigabitEthernet3/1/2] quit

[RouterA] interface GigabitEthernet 3/1/3

[RouterA-GigabitEthernet3/1/3] pim sm

[RouterA-GigabitEthernet3/1/3] quit

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

3. Configure a C-BSR and a C-RP:

# Configure C-BSR and C-RP interfaces on Router D.

[RouterD] pim

[RouterD-pim] c-bsr GigabitEthernet 3/1/3

[RouterD-pim] c-rp GigabitEthernet 3/1/3

[RouterD-pim] quit

4. Configure the SSM group range:

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

[RouterD] acl number 2000

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

[RouterD-acl-basic-2000] quit

[RouterD] pim

[RouterD-pim] ssm-policy 2000

[RouterD-pim] quit

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

5. Configure IGMP SSM mappings:

# Configure IGMP SSM mappings on Router D.

[RouterD] igmp

[RouterD-igmp] ssm-mapping 232.1.1.0 24 133.133.1.1

[RouterD-igmp] ssm-mapping 232.1.1.0 24 133.133.3.1

[RouterD-igmp] quit

6. Verify the configuration:

# Display the IGMP SSM mapping information for multicast group 232.1.1.1 on the public network on Router D.

[RouterD] 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

# Display information about the multicast groups created based on the configured IGMP SSM mappings on the public network on Router D.

[RouterD] display igmp ssm-mapping group

Total 1 IGMP SSM-mapping Group(s).

Interface group report information of VPN-Instance: public net

GigabitEthernet3/1/1(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

# Display PIM routing table information on the public network on Router D.

[RouterD] display pim routing-table

Vpn-instance: public net

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

(133.133.1.1, 232.1.1.1)

Protocol: pim-ssm, Flag:

UpTime: 00:13:25

Upstream interface: GigabitEthernet3/1/3

Upstream neighbor: 192.168.4.2

RPF prime neighbor: 192.168.4.2

Downstream interface(s) information:

Total number of downstreams: 1

1: GigabitEthernet3/1/1

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

(133.133.3.1, 232.1.1.1)

Protocol: pim-ssm, Flag:

UpTime: 00:13:25

Upstream interface: GigabitEthernet3/1/2

Upstream neighbor: 192.168.3.1

RPF prime neighbor: 192.168.3.1

Downstream interface(s) information:

Total number of downstreams: 1

1: GigabitEthernet3/1/1

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

IGMP proxying configuration example

Network requirements

PIM-DM runs on the core network. Host A and Host C in the stub network receive VOD information sent to multicast group 224.1.1.1.

Configure the IGMP proxying feature on Router B so that Router B can maintain group memberships and forward multicast traffic without running PIM-DM.

Figure 7 Network diagram

Configuration procedure

1. Assign IP addresses:

Assign an IP address and subnet mask for each interface as per Figure 7. (Details not shown)

2. Enable IP multicast routing, PIM-DM, IGMP, and IGMP proxying:

# Enable IP multicast routing on Router A, PIM-DM on Serial 4/1/9/1:0, and IGMP on GigabitEthernet 3/1/1.

<RouterA> system-view

[RouterA] multicast routing-enable

[RouterA] interface Serial 4/1/9/1:0

[RouterA-Serial4/1/9/1:0] pim dm

[RouterA-Serial4/1/9/1:0] quit

[RouterA] interface GigabitEthernet 3/1/1

[RouterA-GigabitEthernet3/1/1] igmp enable

[RouterA-GigabitEthernet3/1/1] pim dm

[RouterA-GigabitEthernet3/1/1] quit

# Enable IP multicast routing on Router B, IGMP proxying on GigabitEthernet 3/1/1, and IGMP on GigabitEthernet 3/1/2.

<RouterB> system-view

[RouterB] multicast routing-enable

[RouterB] interface GigabitEthernet 3/1/1

[RouterB-GigabitEthernet3/1/1] igmp proxying enable

[RouterB-GigabitEthernet3/1/1] quit

[RouterB] interface GigabitEthernet 3/1/2

[RouterB-GigabitEthernet3/1/2] igmp enable

[RouterB-GigabitEthernet3/1/2] quit

3. Verify the configuration:

# Display IGMP information on GigabitEthernet 3/1/1 of Router B.

[RouterB] display igmp interface GigabitEthernet 3/1/1 verbose

GigabitEthernet3/1/1(192.168.1.2):

IGMP proxy is enabled

Current IGMP version is 2

Multicast routing on this interface: enabled

Require-router-alert: disabled

Version1-querier-present-timer-expiry: 00:00:20

# Display IGMP group information on Router A.

[RouterA] display igmp group

Total 1 IGMP Group(s).

Interface group report information of VPN-Instance: public net

GigabitEthernet3/1/1(192.168.1.1):

Total 1 IGMP Groups reported

Group Address Last Reporter Uptime Expires

224.1.1.1 192.168.1.2 00:02:04 00:01:15

The output shows that IGMP reports from the hosts are forwarded to Router A through the proxy interface, GigabitEthernet 3/1/1 of Router B.

Troubleshooting IGMP

No membership information exists on the receiver-side router

Symptom

When a host sends a report for joining 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, and 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 will not be able to 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 fail 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 no information is output, the interface is in an abnormal state. The reason might be that you have configured the shutdown command on the interface, that the interface is not properly connected, or that the IP address configuration is not correctly completed.

2. Use the display current-configuration command to verify that multicast routing is enabled. If not, use 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. 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 restrict the host from joining the multicast group G. 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.

Membership information is inconsistent on the routers on the same subnet

Symptom

The IGMP routers on the same subnet have different membership information.

Analysis

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

· In addition, although an IGMP router is compatible with a host that is running a different version 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 also leads to inconsistency of IGMP memberships.

Solution

1. Use the display current-configuration command to verify the IGMP configuration 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 that 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 version of IGMP.

07-IP Multicast Configuration Guide

IGMP overview

IGMPv1 overview

IGMPv2 enhancements

Querier election mechanism

“Leave group” mechanism

IGMPv3 enhancements

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 for the public network

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

Setting the maximum number of multicast groups that an interface can join

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 fast-leave processing globally

Configuring IGMP fast-leave processing on an interface

Enabling the IGMP host tracking function

Enabling the IGMP host tracking function globally

Enabling the IGMP host tracking function on an interface

IGMP configuration examples

Network requirements

Configuration procedure

SSM mapping configuration example

Network requirements

Configuration procedure

Network requirements

Configuration procedure

Symptom

Analysis

Solution

Symptom

Analysis

Solution

Intelligent Terminal Products

Product Support Services

Technical Service Solutions

Resource Center

Policy

Online Help

Become a Partner

Partner Policy & Program

Global Learning

Partner Sales Resources

Service Business

Company Information

News & Events

Contact Us