Table of Contents

Chapter 1 IGMP Configuration. 1-1

1.1 IGMP Overview. 1-1

1.1.1 IGMP Versions. 1-1

1.1.2 Work Mechanism of IGMPv1. 1-2

1.1.3 Enhancements Provided by IGMPv2. 1-3

1.1.4 Enhancements in IGMPv3. 1-4

1.1.5 Protocols and Standards. 1-6

1.2 Configuring IGMP. 1-6

1.3 Configuring Basic Functions of IGMP. 1-7

1.3.1 Configuration Prerequisites. 1-7

1.3.2 Enabling IGMP. 1-7

1.3.3 Configuring IGMP Versions. 1-8

1.3.4 Configuring Static Joining. 1-9

1.3.5 Configuring a Multicast Group Filter 1-9

1.4 Configuring IGMP Performance Parameters. 1-10

1.4.1 Configuration Prerequisites. 1-10

1.4.2 Configuring IGMP Message Options. 1-11

1.4.3 Configuring IGMP Query and Response Parameters. 1-12

1.4.4 Configuring IGMP Fast Leave. 1-15

1.5 Displaying and Maintaining IGMP. 1-16

1.6 IGMP Configuration Examples. 1-17

1.7 Troubleshooting IGMP. 1-19

1.7.1 No Member Information on the Receiver-Side Device. 1-19

1.7.2 Inconsistent Memberships on Devices on the Same Subnet 1-20

 

Chapter 1  IGMP Configuration

When configuring IGMP, go to the following sections for the information you are interested in:

l           IGMP Overview

l           Configuring IGMP

l           Configuring Basic Functions of IGMP

l           Configuring IGMP Performance Parameters

l           Displaying and Maintaining IGMP

l           IGMP Configuration Examples

l           Troubleshooting IGMP

 

 

1.1  IGMP Overview

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.

1.1.1  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, IGMPv3 provides support to the Source-Specific Multicast (SSM) model.

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

1.1.2  Work Mechanism of 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 a multicast routing protocol (such as PIM) serves as the IGMP querier, which sends periodical IGMP queries.

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

1.1.3  Enhancements Provided by IGMPv2

Compared with IGMPv1, IGMPv2 provides the querier election mechanism and Leave Group mechanism.

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

II. “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 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.

1.1.4  Enhancements in IGMPv3

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

I. Enhancements in control capability of hosts

In addition to group-specific queries, 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 a designated multicast source. When a host joins a multicast group:

l           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, ……).

l           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 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, rather than the multicast data Source 2 sends to multicast group G. Thus, only multicast data from Source 1 will be delivered to Host B.

 

 

II. 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 an uncertain number of source addresses.

Group record types include:

l           Current-state record: Current-state record: The current-state record reports the current reception state of the interface on which the report is sent. The state can be either Include (the interface has a filter mode of Include for the specified multicast address list) or Exclude (the interface has a filter mode of Exclude for the specified multicast address list).

l           Filter-mode-change record: A filter-mode-change record indicates that the interface filter mode has changed from Include to Exclude or from Include to Exclude for the specified multicast address list.

l           Source-list-change record: A source-list-change record indicates that new source addresses are allowed or old source addresses are blocked.

1.1.5  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

1.2  Configuring IGMP

Complete these tasks to configure IGMP:

Task		Remarks
IGMP Configuration	Enabling IGMP	Required
	Configuring IGMP Versions	Optional
	Configuring Static Joining	Optional
	Configuring a Multicast Group Filter	Optional
Configuring IGMP Performance Parameters	Configuring IGMP Message Options	Optional
	Configuring IGMP Query and Response Parameters	Optional
	Configuring IGMP Fast Leave	Optional

 

 

1.3  Configuring Basic Functions of IGMP

1.3.1  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

1.3.2  Enabling IGMP

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

Follow these steps to enable IGMP:

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

 

 

1.3.3  Configuring IGMP Versions

Because messages vary with different IGMP versions, the same IGMP version should be configured for all devices on the same subnet before IGMP can work properly.

I. 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 IGMP view	igmp	—
Configure an IGMP version globally	version version-number	Optional IGMPv2 by default

 

II. 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 VLAN/POS interface view	interface interface-type interface-number	—
Configure an IGMP version on the interface	igmp version version-number	Optional IGMPv2 by default

 

 

1.3.4  Configuring Static Joining

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

Before you can configure an interface of a PIM-SM device as a static member of a multicast 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.

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

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

 

 

1.3.5  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 that the interface serves.

Follow these steps to configure a multicast group filter:

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

 

 

1.4  Configuring IGMP Performance Parameters

 

 

1.4.1  Configuration Prerequisites

Before configuring IGMP performance parameters, 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 configuring IGMP performance parameters, prepare the following data:

l           IGMP general query interval

l           IGMP querier robustness variable

l           Maximum response time for IGMP general queries

l           Other querier present interval

l           IGMP last-member query interval

1.4.2  Configuring IGMP Message Options

As there are IGMP group-specific and group-and-source-specific queries, and multicast groups change dynamically, a device cannot join all multicast groups. Therefore, 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 Router-Alert, refer to RFC 2113.

Depending on whether an IGMP message carries the Router-Alert option in the IP header, the device processes the message differently.

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

I. 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 IGMP view	igmp	—
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
Enable the insertion of the Router-Alert option into IGMP messages	send-router-alert	Optional By default, IGMP messages carry the Router-Alert option

 

II. 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 VLAN/POS 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
Enable the insertion of the Router-Alert option into IGMP messages	igmp send-router-alert	Optional By default, IGMP messages carry the Router-Alert option

 

1.4.3  Configuring IGMP Query and Response Parameters

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

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”. 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”. Both startup query count and last member query count are set to the IGMP querier robustness variable.

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 before the “other querier present interval” timer expires, 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 interval” timer.

I. 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 IGMP view	igmp	—
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

 

II. 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 VLAN/POS interface view	interface interface-type interface-number	—
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 lastmember-queryinterval interval	Optional 1 second by default
Configure the IGMP last-member query count	igmp robust-count robust-value	Optional 2 times by default
Configure the other querier present interval	igmp timer other-querier-present interval	Optional For the system default, see “Note” below

 

 

 

1.4.4  Configuring IGMP Fast Leave

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 the fast leave function enabled, after an IGMP querier receives a leave message from a host, it will not send IGMP group-specific queries to the group being left; instead, it will send a leave notification to the upstream. As a result, the leave latency is reduced on one hand, and the network bandwidth is saved on the other.

I. Configuring IGMP fast leave globally

Follow these steps to enable IGMP fast leave globally:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter IGMP view	igmp	—
Enable IGMP fast leave processing	fast-leave [ group-policy acl-number ]	Required Disabled by default

 

II. Configuring IGMP fast leave processing on an interface

Follow these steps to configure IGMP fast leave processing on an interface:

To do...	Use the command...	Remarks
Enter system view	system-view	—
Enter POS interface view	interface interface-type interface-number	—
Enable IGMP fast leave processing	igmp fast-leave [ group-policy acl-number ]	Required Disabled by default

 

 

 

1.5  Displaying and Maintaining IGMP

To do...	Use the command...	Remarks
View IGMP multicast group information	display igmp 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-id ] [ verbose ]	Available in any view
View IGMP configuration and running information on the interface	display igmp interface [ interface-type interface-number ] [ verbose ]	Available in any view
View information in the IGMP routing table	display igmp routing-table [ group-address [ mask { mask | mask-length } ] | source-address [ mask { mask | mask-length } ] ] *	Available in any view
Clear IGMP multicast group information	reset igmp group { all | interface interface-type interface-number { all | group-address [ mask { mask | mask-length } ] [ source-address [ mask { mask | mask-length } ] ] } }	Available in user view

 

 

1.6  IGMP Configuration Examples

I. Network requirements

l           Receivers receive VOD information through the multicast mode. 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-DM 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-DM 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-DM network through Vlan-interface 201 and Vlan-interface 202 respectively.

l           IGMPv2 is required between Switch A and N1. IGMPv2 is required between the other two switches and N2, with Switch B as the IGMP querier.

II. Network diagram

Figure 1-3 Network diagram for IGMP configuration

III. Configuration procedure

 

 

1)         Configure IP addresses and unicast routing.

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

Configure the OSPF protocol for interoperation among the switches. Ensure the network-layer interoperation among Switch A, Switch B and Switch C on the PIM-DM 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 IGMP on the host-side interfaces.

# Enable IP multicast routing on Switch A, and enable IGMP (version 2) and PIM-DM on Vlan-interface 100.

<SwitchA> system-view

[SwitchA] multicast routing-enable

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] igmp version 2

[SwitchA-Vlan-interface100] pim dm

[SwitchA-Vlan-interface100] quit

# Enable IP multicast routing on Switch B, and enable IGMP (version 2) and PIM-DM on Vlan-interface 200.

<SwitchB> system-view

[SwitchB] multicast routing-enable

[SwitchB] interface vlan-interface 200

[SwitchB-Vlan-interface200] igmp enable

[SwitchB-Vlan-interface200] igmp version 2

[SwitchB-Vlan-interface200] pim dm

[SwitchB-Vlan-interface200] quit

# Enable IP multicast routing on Switch C, and enable IGMP (version 2) and PIM-DM on Vlan-interface 200.

<SwitchC> system-view

[SwitchC] multicast routing-enable

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] igmp enable

[SwitchC-Vlan-interface200] igmp version 2

[SwitchC-Vlan-interface200] pim dm

[SwitchC-Vlan-interface200] quit

3)         Verify the configuration

Carry out the display igmp interface command to view the IGMP configuration and running 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

1.7  Troubleshooting IGMP

1.7.1  No Member Information on the Receiver-Side Device

I. Symptom

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

II. Analysis

l           The correctness of networking and interface connections directly affects the generation of group member information.

l           Multicast routing must be enabled on the device.

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

III. Solution

1)         Check that the networking is correct and interface connections are correct.

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.

3)         Check that the interface is in normal state and the correct IP address has been configured. Carry out the display igmp interface command to view the interface information. If no interface information is output, this means the interface is abnormal. Typically this is because the shutdown command has been executed on the interface, or the interface connection is incorrect, or no correct IP address has been configured on the interface.

4)         Check that no ACL rule has been configured on the POS interface 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.

1.7.2  Inconsistent Memberships on Devices on the Same Subnet

I. Symptom

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

II. Analysis

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

l           In addition, although IGMP routers are compatible with hosts, all devices on the same subnet must run the same version of IGMP. Inconsistent IGMP versions running on devices on the same subnet will also lead to inconsistency of IGMP memberships.

III. 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 devices 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 the devices are running the same version of IGMP.