06-IP Multicast Configuration Guide

HomeSupportConfigure & DeployConfiguration GuidesH3C S12500-X & S12500X-AF Switch Series Configuration Guides(R115x)-6W10206-IP Multicast Configuration Guide
04-IGMP configuration
Title Size Download
04-IGMP configuration 223.65 KB

Configuring IGMP

Overview

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

IGMP has three versions:

·          IGMPv1 (defined by RFC 1112).

·          IGMPv2 (defined by RFC 2236).

·          IGMPv3 (defined by RFC 3376).

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

The term "interface" in this chapter collectively refers to VLAN interfaces and Layer 3 Ethernet interfaces. You can set an Ethernet port as a Layer 3 interface by using the port link-mode route command (see Layer 2—LAN Switching Configuration Guide).

IGMPv1 overview

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

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

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

Figure 1 IGMP queries and reports

 

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

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

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

3.        After receiving a query message, Host B or Host C (the host whose delay timer expires first) sends an IGMP report to G1 to announce its membership for G1. This example assumes that Host B sends the report message.

After receiving the report from Host B, Host C suppresses its own report for G1. Because Router A and Router B already know that G1 has at least one member host on the local subnet, other members do not need to report their memberships. This IGMP report suppression mechanism helps reduce traffic on the local subnet.

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

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

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

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

IGMPv2 enhancements

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

Querier election mechanism

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

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

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

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

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

"Leave group" mechanism

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

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

1.        The host sends a leave message (with the destination of 224.0.0.2) to all routers on the local subnet.

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

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

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

IGMPv3 enhancements

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

Enhancements in control capability of hosts

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

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

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

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

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

 

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

When IGMPv3 runs between the hosts and routers, Host B can explicitly express that it needs to receive the multicast data that Source 1 sends to the multicast group G (denoted as (S1, G)). It also can explicitly express that it does not want to receive the multicast data that Source 2 sends to multicast group G (denoted as (S2, G)). Finally, only multicast data from Source 1 is delivered to Host B.

Enhancements in query and report capabilities

·          Query message carrying the source addresses

Compatible with IGMPv1 and IGMPv2, IGMPv3 supports general queries and group-specific queries. In addition, it introduces group-and-source-specific queries.

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

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

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

·          Reports containing multiple group records

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

Group records include the following categories:

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

¡  IS_EX—The source filtering mode is Exclude. The report sender requests the multicast data from any sources except those defined in the multicast source address 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 field contains a list of additional sources from which the receiver wants to obtain data. If the current filtering mode is Include, these sources are added to the INCLUDE source address list. If the current filtering mode is Exclude, these sources are deleted from the EXCLUDE source address list.

¡  BLOCK—The Source Address field contains a list of the sources from which the receiver no longer wants to obtain data. If the current filtering mode is Include, these sources are deleted from the INCLUDE source address list. If the current filtering mode is Exclude, these sources are added to the EXCLUDE source address list.

IGMP support for VPNs

IGMP maintains group memberships on a per-interface base. After receiving an IGMP message on an interface, IGMP processes the packet within the VPN to which the interface belongs. IGMP only communicates with other multicast protocols within the same VPN 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

IGMP configuration task list

Tasks at a glance

Configuring basic IGMP features:

·         (Required.) Enabling IGMP

·         (Optional.) Specifying an IGMP version

·         (Optional.) Configuring a static group member

·         (Optional.) Configuring a multicast group policy

(Optional.) Enabling fast-leave processing

 

Configuring basic IGMP features

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

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

·          Configure PIM.

·          Determine the IGMP version.

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

·          Determine the ACL used in the multicast group policy.

Enabling IGMP

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

To enable IGMP:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enable IP multicast routing and enter MRIB view.

multicast routing [ vpn-instance vpn-instance-name ]

By default, IP multicast is disabled.

3.       Return to system view.

quit

N/A

4.       Enter interface view.

interface interface-type interface-number

N/A

5.       Enable IGMP.

igmp enable

By default, IGMP is disabled.

 

Specifying an IGMP version

Because the protocol packets of different IGMP versions are different in structures and types, you must specify the same IGMP version for all routers on the same subnet. Otherwise, IGMP cannot operate correctly.

To specify an IGMP version:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Specify an IGMP version.

igmp version version-number

The default setting is IGMPv2.

 

Configuring a static group member

You can configure an interface as a static member of a multicast group. Then, the interface can receive multicast data addressed to that multicast group.

When you complete or cancel this configuration on an interface, the interface does not send an unsolicited IGMP report or leave message. This is because the interface is not a real member host of the multicast group.

A static group member does not respond to IGMP queries.

The interface to be configured as a static member interface has the following restrictions:

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

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

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

To configure an interface as a static group member:

 

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

igmp static-group group-address [ source source-address ]

By default, an interface is not a static member of any multicast group or multicast source and group.

 

Configuring a multicast group policy

This feature enables an interface to filter IGMP reports by using an ACL that specifies multicast groups and the optional sources. It is used to control the multicast groups that the hosts attached to an interface can join.

This feature does not take effect on static member interfaces because static member interfaces do not send IGMP reports.

To configure a multicast group policy:

 

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

igmp group-policy acl-number [ version-number ]

By default, no multicast group policy exists. Hosts attached to the interface can join any multicast groups.

 

Enabling fast-leave processing

This feature enables the IGMP querier to send a leave notification directly to the upstream without sending IGMP group-specific queries or IGMP group-and-source-specific queries after receiving a leave message. This reduces leave latency and preserves the network bandwidth.

The fast-leave processing configuration is effective only when the device runs IGMPv2 or IGMPv3.

To enable fast-leave processing:

 

Step

Command

Remarks

1.       Enter system view.

system-view

N/A

2.       Enter interface view.

interface interface-type interface-number

N/A

3.       Enable fast-leave processing.

igmp fast-leave [ group-policy acl-number ]

By default, fast-leave processing is disabled.

 

Displaying and maintaining IGMP

CAUTION:

The reset igmp group command might cause multicast data transmission failures.

 

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

 

Task

Command

Display IGMP group information.

display igmp [ vpn-instance vpn-instance-name ] group [ group-address | interface interface-type interface-number ] [ static | verbose ]

Display IGMP information.

display igmp[ vpn-instance vpn-instance-name ] interface [ interface-type interface-number ] [ host ] [ verbose ]

Clear dynamic IGMP group entries.

reset igmp [ 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 } ] ] } }

 

IGMP configuration example

Network requirements

As shown in Figure 3:

·          VOD streams are sent to receiver hosts in multicast.

·          Receiver hosts of different organizations form stub networks N1 and N2. Host A and Host C are receiver hosts in N1 and N2, respectively.

·          IGMPv2 runs between Switch A and N1, and between the other two switches and N2.

·          Switch A acts as the IGMP querier in N1. Switch B acts as the IGMP querier in N2 because it has a lower IP address.

Configure the switches to achieve the following goals:

·          The hosts in N1 join only multicast group 224.1.1.1.

·          The hosts in N2 can join any multicast groups.

Figure 3 Network diagram

 

 

Configuration procedure

1.        Assign an IP address and subnet mask to each interface according to Figure 3. (Details not shown.)

2.        Configure OSPF on the PIM network to make sure the following conditions are met: (Details not shown.)

¡  The switches are interoperable at the network layer.

¡  The switches can update their routing information.

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

# On Switch A, enable IP multicast routing.

<SwitchA> system-view

[SwitchA] multicast routing

[SwitchA-mrib] quit

# Enable IGMP on the receiver-side interface (VLAN-interface 100).

[SwitchA] interface vlan-interface 100

[SwitchA-Vlan-interface100] igmp enable

[SwitchA-Vlan-interface100] quit

# Enable PIM-DM on VLAN-interface 101.

[SwitchA] interface vlan-interface 101

[SwitchA-Vlan-interface101] pim dm

[SwitchA-Vlan-interface101] quit

# On Switch B, enable IP multicast routing.

<SwitchB> system-view

[SwitchB] multicast routing

[SwitchB-mrib] quit

# Enable IGMP on the receiver-side interface (VLAN-interface 200).

[SwitchB] interface vlan-interface 200

[SwitchB-Vlan-interface200] igmp enable

[SwitchB-Vlan-interface200] quit

# Enable PIM-DM on VLAN-interface 201.

[SwitchB] interface vlan-interface 201

[SwitchB-Vlan-interface201] pim dm

[SwitchB-Vlan-interface201] quit

# On Switch C, enable IP multicast routing.

<SwitchC> system-view

[SwitchC] multicast routing

[SwitchC-mrib] quit

# Enable IGMP on the receiver-side interface (VLAN-interface 200).

[SwitchC] interface vlan-interface 200

[SwitchC-Vlan-interface200] igmp enable

[SwitchC-Vlan-interface200] quit

# Enable PIM-DM on VLAN-interface 202.

[SwitchC] interface vlan-interface 202

[SwitchC-Vlan-interface202] pim dm

[SwitchC-Vlan-interface202] quit

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

[SwitchA] acl number 2001

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

[SwitchA-acl-basic-2001] quit

[SwitchA] interface vlan-interface 100

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

[SwitchA-Vlan-interface100] quit

Verifying the configuration

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

[SwitchB] display igmp interface vlan-interface 200

 Vlan-interface200(10.110.2.1):

   IGMP is enabled.

   IGMP version: 2

   Query interval for IGMP: 125s

   Other querier present time for IGMP: 255s

   Maximum query response time for IGMP: 10s

   Querier for IGMP: 10.110.2.1 (This router)

  IGMP groups reported in total: 1

Troubleshooting IGMP

No membership information on the receiver-side router

Symptom

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

Solution

To resolve the problem:

1.        Use the display igmp interface command to verify that the networking, interface connection, and IP address configuration are correct.

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

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

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

5.        If the problem persists, contact H3C Support.

Inconsistent membership information on the routers on the same subnet

Symptom

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

Solution

To resolve the problem:

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

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

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

4.        If the problem persists, contact H3C Support.

  • Cloud & AI
  • InterConnect
  • Intelligent Computing
  • Security
  • SMB Products
  • Intelligent Terminal Products
  • Product Support Services
  • Technical Service Solutions
All Services
  • Resource Center
  • Policy
  • Online Help
All Support
  • Become a Partner
  • Partner Resources
  • Partner Business Management
All Partners
  • Profile
  • News & Events
  • Online Exhibition Center
  • Contact Us
All About Us
新华三官网