Customizing IGMP
Available Languages
Table Of Contents
Prerequisites for Customizing IGMP
Restrictions for Customizing IGMP
Information About Customizing IGMP
Role of the Internet Group Management Protocol
IGMPv3 - Explicit Tracking Host, Group, and Channel
Benefits of IGMPv3 - Explicit Tracking of Hosts, Groups, and Channels
Restrictions for IGMPv3 - Explicit Tracking of Hosts, Groups, and Channels
Extended ACL Support for IGMP to Support SSM in IPv4
Benefits of Extended Access List Support for IGMP to Support SSM in IPv4
How IGMP Checks an Extended Access List
Configuring the Router to Forward Multicast Traffic in the Absence of Directly Connected IGMP Hosts
Enabling the IGMPv3 Host Stack
Configuring IGMPv3—Explicit Tracking of Hosts, Groups, and Channels
Controlling Access to an SSM Network Using IGMP Extended Access Lists
Configuring the Upstream UDL Router for IGMP UDLR
Configuring the Downstream UDL Router for IGMP UDLR with IGMP Proxy Support
Configuration Examples for Customizing IGMP
Example: Enabling the IGMPv3 Host Stack
Example: Configuring IGMPv3—Explicit Tracking of Hosts, Groups, and Channels
Example: Controlling Access to an SSM Network Using IGMP Extended Access Lists
Example: Denying All States for a Group G
Example: Denying All States for a Source S
Example: Permitting All States for a Group G
Example: Permitting All States for a Source S
Example: Filtering a Source S for a Group G
Example: Configuring an IGMP Proxy
Feature Information for Customizing IGMP
Customizing IGMP
First Published: May 2, 2005Last Updated: September 10, 2010Internet Group Management Protocol (IGMP) is used to dynamically register individual hosts in a multicast group on a particular LAN segment. Enabling Protocol Independent Multicast (PIM) on an interface also enables IGMP operation on that interface.
This module describes ways to customize IGMP, including how to:
•
Configure the router to forward multicast traffic in the absence of directly connected IGMP hosts.
•
•
•
•
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Feature Information for Customizing IGMP" section.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
•
Prerequisites for Customizing IGMP
•
•
Restrictions for Customizing IGMP
Traffic Filtering with Multicast Groups That Are Not Configured in SSM Mode
IGMPv3 membership reports are not utilized by Cisco IOS software to filter or restrict traffic for multicast groups that are not configured in Source Specific Multicast (SSM) mode. Effectively, Cisco IOS software interprets all IGMPv3 membership reports for groups configured in dense, sparse, or bidirectional mode to be group membership reports and forwards traffic from all active sources onto the network.
Interoperability with IGMP Snooping
You must be careful when using IGMPv3 with switches that support and are enabled for IGMP snooping, because IGMPv3 messages are different from the messages used in IGMP Version 1 (IGMPv1) and Version 2 (IGMPv2). If a switch does not recognize IGMPv3 messages, then hosts will not correctly receive traffic if IGMPv3 is being used. In this case, either IGMP snooping may be disabled on the switch or the router may be configured for IGMPv2 on the interface, which would remove the ability to use SSM for host applications that cannot resort to URL Rendezvous Directory (URD) or IGMP v3lite.
Interoperability with CGMP
Networks using Cisco Group Management Protocol (CGMP) will have better group leave behavior if they are configured with IGMPv2 than IGMPv3. If CGMP is used with IGMPv2 and the switch is enabled for the CGMP leave functionality, then traffic to a port joined to a multicast group will be removed from the port shortly after the last member on that port has dropped membership to that group. This fast-leave mechanism is part of IGMPv2 and is specifically supported by the CGMP fast-leave enabled switch.
With IGMPv3, there is currently no CGMP switch support of fast leave. If IGMPv3 is used in a network, CGMP will continue to work, but CGMP fast-leave support is ineffective and the following conditions apply:
•
•
•
This join behavior only applies to multicast groups that actually operate in IGMPv3 mode. If legacy hosts only supporting IGMPv2 are present in the network, then groups will revert to IGMPv2 and fast leave will work for these groups.
If fast leave is needed with CGMP-enabled switches, we recommend that you not enable IGMPv3 but configure IGMPv2 on that interface.
If you want to use SSM, you need IGMPv3 and you have two configuration alternatives, as follows:
•
•
Information About Customizing IGMP
•
•
•
Role of the Internet Group Management Protocol
IGMP is used to dynamically register individual hosts in a multicast group on a particular LAN. Enabling PIM on an interface also enables IGMP. IGMP provides a means to automatically control and limit the flow of multicast traffic throughout your network with the use of special multicast queriers and hosts.
•
•
Hosts identify group memberships by sending IGMP messages to their local multicast router. Under IGMP, routers listen to IGMP messages and periodically send out queries to discover which groups are active or inactive on a particular subnet.
IGMP Version Differences
Table 1 provides high-level descriptions of the three IGMP versions.
Table 1 IGMP Versions
Note
Routers That Run IGMPv1
IGMPv1 routers send IGMP queries to the "all-hosts" multicast address of 224.0.0.1 to solicit multicast groups with active multicast receivers. The multicast receivers also can send IGMP reports to the router to notify it that they are interested in receiving a particular multicast stream. Hosts can send the report asynchronously or in response to the IGMP queries sent by the router. If more than one multicast receiver exists for the same multicast group, only one of these hosts sends an IGMP report message; the other hosts suppress their report messages.
In IGMPv1, there is no election of an IGMP querier. If more than one router on the segment exists, all the routers send periodic IGMP queries. IGMPv1 has no special mechanism by which the hosts can leave the group. If the hosts are no longer interested in receiving multicast packets for a particular group, they simply do not reply to the IGMP query packets sent from the router. The router continues sending query packets. If the router does not hear a response in three IGMP queries, the group times out and the router stops sending multicast packets on the segment for the group. If the host later wants to receive multicast packets after the timeout period, the host simply sends a new IGMP join to the router, and the router begins to forward the multicast packet again.
If there are multiple routers on a LAN, a designated router (DR) must be elected to avoid duplicating multicast traffic for connected hosts. PIM routers follow an election process to select a DR. The PIM router with the highest IP address becomes the DR.
The DR is responsible for the following tasks:
•
•
•
Routers That Run IGMPv2
IGMPv2 improves the query messaging capabilities of IGMPv1.
The query and membership report messages in IGMPv2 are identical to the IGMPv1 messages with two exceptions:
•
•
IGMPv2 also enhances IGMP by providing support for the following capabilities:
•
•
•
•
Unlike IGMPv1, in which the DR and the IGMP querier are typically the same router, in IGMPv2 the two functions are decoupled. The DR and the IGMP querier are selected based on different criteria and may be different routers on the same subnet. The DR is the router with the highest IP address on the subnet, whereas the IGMP querier is the router with the lowest IP address.
Query messages are used to elect the IGMP querier as follows:
1.
2.
3.
By default, the timer is two times the query interval.
Routers Running IGMPv3
IGMPv3 adds support in Cisco IOS software for source filtering, which enables a multicast receiver host to signal to a router which groups it wants to receive multicast traffic from, and from which sources this traffic is expected. This membership information enables Cisco IOS software to forward traffic only from those sources from which receivers requested the traffic.
IGMPv3 supports applications that explicitly signal sources from which they want to receive traffic. With IGMPv3, receivers signal membership to a multicast group in the following two modes:
•
•
IGMPv3 is the industry-designated standard protocol for hosts to signal channel subscriptions in an SSM network environment. For SSM to rely on IGMPv3, IGMPv3 must be available in the network stack portion of the operating systems running on the last hop routers and hosts and be used by the applications running on those hosts.
In IGMPv3, hosts send their membership reports to 224.0.0.22; all IGMPv3 routers, therefore, must listen to this address. Hosts, however, do not listen or respond to 224.0.0.22; they only send their reports to that address. In addition, in IGMPv3, there is no membership report suppression because IGMPv3 hosts do not listen to the reports sent by other hosts. Therefore, when a general query is sent out, all hosts on the wire respond.
IGMP Join Process
When a host wants to join a multicast group, the host sends one or more unsolicited membership reports for the multicast group it wants to join. The IGMP join process is the same for IGMPv1 and IGMPv2 hosts.
In IGMPv3, the join process for hosts proceeds as follows:
•
•
•
Note
IGMP Leave Process
The method that hosts use to leave a group varies depending on the version of IGMP in operation.
IGMPv1 Leave Process
There is no leave-group message in IGMPv1 to notify the routers on the subnet that a host no longer wants to receive the multicast traffic from a specific group. The host simply stops processing traffic for the multicast group and ceases responding to IGMP queries with IGMP membership reports for the group. As a result, the only way IGMPv1 routers know that there are no longer any active receivers for a particular multicast group on a subnet is when the routers stop receiving membership reports. To facilitate this process, IGMPv1 routers associate a countdown timer with an IGMP group on a subnet. When a membership report is received for the group on the subnet, the timer is reset. For IGMPv1 routers, this timeout interval is typically three times the query interval (3 minutes). This timeout interval means that the router may continue to forward multicast traffic onto the subnet for up to 3 minutes after all hosts have left the multicast group.
IGMPv2 Leave Process
IGMPv2 incorporates a leave-group message that provides the means for a host to indicate that it wishes to stop receiving multicast traffic for a specific group. When an IGMPv2 host leaves a multicast group, if it was the last host to respond to a query with a membership report for that group, it sends a leave-group message to the all-routers multicast group (224.0.0.2).
IGMPv3 Leave Process
IGMPv3 enhances the leave process by introducing the capability for a host to stop receiving traffic from a particular group, source, or channel in IGMP by including or excluding sources, groups, or channels in IGMPv3 membership reports.
IGMP Multicast Addresses
IP multicast traffic uses group addresses, which are Class D IP addresses. The high-order four bits of a Class D address are 1110. Therefore, host group addresses can be in the range 224.0.0.0 to 239.255.255.255.
Multicast addresses in the range 224.0.0.0 to 224.0.0.255 are reserved for use by routing protocols and other network control traffic. The address 224.0.0.0 is guaranteed not to be assigned to any group.
IGMP packets are transmitted using IP multicast group addresses as follows:
•
•
•
•
•
IGMPv3 Host Stack
The IGMPv3 Host Stack feature enables routers or switches to function as multicast network endpoints or hosts. The feature adds INCLUDE mode capability to the IGMPv3 host stack for SSM groups. Enabling the IGMPv3 host stack ensures that hosts on a LAN can leverage SSM by enabling the router or switch to initiate IGMPv3 joins, such as in environments where fast channel change is required in a SSM deployments.
In support of the IGMPv3 Host Stack feature, the source keyword and source-address argument were added to the ip igmp join-group command to add INCLUDE mode capability to the IGMPv3 host stack for SSM groups.
Note
When the IGMPv3 Host Stack feature is configured, an IGMPv3 membership report is sent when one of the following events occurs:
•
•
•
Note
IGMPv3 - Explicit Tracking Host, Group, and Channel
The IGMPv3—Explicit Tracking Host, Group, and Channel feature enables a multicast router to explicitly track the membership of all multicast hosts in a particular multiaccess network. This enhancement to the Cisco IOS implementation of IGMPv3 enables the router to track each individual host that is joined to a particular group or channel.
Benefits of IGMPv3 - Explicit Tracking of Hosts, Groups, and Channels
Minimal Leave Latencies
The main benefit of the IGMPv3—Explicit Tracking of Hosts, Groups, and Channels feature is to allow minimal leave latencies when a host leaves a multicast group or channel. A router configured with IGMPv3 and explicit tracking can immediately stop forwarding traffic if the last host to request to receive traffic from the router indicates that it no longer wants to receive traffic. The leave latency is thus bound only by the packet transmission latencies in the multiaccess network and the processing time in the router.
In IGMPv2, when a router receives an IGMP leave message from a host, it must first send an IGMP group-specific query to learn if other hosts on the same multiaccess network are still requesting to receive traffic. If after a specific time (in Cisco IOS software, the default value is approximately 3 seconds) no host replies to the query, the router will then stop forwarding the traffic. This query process is required because, in IGMPv1 and IGMPv2, IGMP membership reports are suppressed if the same report has already been sent by another host in the network. Therefore, it is impossible for the router to reliably know how many hosts on a multiaccess network are requesting to receive traffic.
Faster Channel Changing
In networks where bandwidth is constrained between multicast routers and hosts (such as in DSL deployments), the bandwidth between routers and hosts is typically large enough to sustain, in general, only a limited number of multicast streams to be received in parallel. In these deployments, each host will typically join to only one multicast stream and the overall number of allowed hosts will be limited by the total bandwidth of the link. The effective leave latency in these environments defines the channel change time of the receiver application—a single host cannot receive the new multicast stream before forwarding of the old stream has stopped. If an application tries to change the channel faster than the leave latency, the application will overload the bandwidth of the access network, resulting in a temporary degradation of traffic flow for all hosts. The IGMPv3—Explicit Tracking of Hosts, Groups, and Channels feature allows for minimal leave latencies, and thus allows for fast channel changing capabilities.
Improved Diagnostics Capabilities
The IGMPv3—Explicit Tracking of Hosts, Groups, and Channels feature allows network administrators to easily determine which multicast hosts are joined to which multicast groups or channels.
Restrictions for IGMPv3 - Explicit Tracking of Hosts, Groups, and Channels
No MIB Support
There is no Simple Network Management Protocol (SNMP) MIB to track the IGMP membership of individual hosts. The MIBs supported by Cisco IOS software reflect only the aggregate membership of a particular interface on a router.
No Minimal Leave Latency for Groups with Legacy Hosts
If one or more hosts that supports only IGMPv1 or IGMPv2 are present on a network, the leave latencies for the multicast groups to which those hosts are joined will revert to the leave latencies of the IGMP version of the hosts—approximately 3 seconds for IGMPv2 and up to 180 seconds (3 minutes) for IGMPv1. This condition affects only the multicast groups to which those legacy hosts are actually joined at any given point in time. In addition, the membership reports for these multicast groups sent by IGMPv3 hosts may revert to IGMPv1 or IGMPv2 membership reports, thus disabling explicit tracking of those host memberships.
No Explicit Tracking Support for IGMP v3lite and URD
Explicit tracking of IGMP Version 3 lite (IGMP v3lite) or URL Rendezvous Directory (URD) channel membership reports is not supported in Release 12.0(19)S or earlier releases. In these releases, the leave latency for multicast groups sending traffic to hosts using IGMP v3lite or URD will be determined by the leave latency of the version of IGMP configured on the hosts (for IGMPv3, the leave latency is typically 3 seconds when explicit tracking is not configured).
Extended ACL Support for IGMP to Support SSM in IPv4
The Extended ACL Support for IGMP to Support SSM in IPv4 feature enables IGMPv3 to accommodate extended access lists. IGMPv3 support of extended access lists allows you to leverage an important advantage of SSM in IPv4, that of filtering IGMPv3 reports based on source address, group address, or both.
Benefits of Extended Access List Support for IGMP to Support SSM in IPv4
IGMPv3 accommodates extended access lists, which allow you to leverage an important advantage of SSM in IPv4, that of basing access on source IP address. Prior to this feature, an IGMP access list accepted only a standard access list, allowing membership reports to be filtered based only on multicast group addresses.
IGMPv3 allows multicast receivers not only to join to groups, but to groups including or excluding sources. For appropriate access control, it is therefore necessary to allow filtering of IGMPv3 messages not only by group addresses reported, but by group and source addresses. IGMP extended access lists introduce this functionality. Using SSM with an IGMP extended access list (ACL) allows you to permit or deny source S and group G (S, G) in IGMPv3 reports, thereby filtering IGMPv3 reports based on source address, group address, or source and group address.
Source Addresses in IGMPv3 Reports for ASM Groups
IGMP extended access lists also can be used to permit or filter (deny) traffic based on (0.0.0.0, G), that is, (*, G) in IGMP reports that are non-SSM, such as Any Source Multicast (ASM).
Note
deny host 0.0.0.0 host group group-address, respectively.
Filtering applies to IGMPv3 reports for both ASM and SSM groups, but it is most important for SSM groups because Cisco IOS IP multicast routing ignores source addresses in IGMPv3 reports for ASM groups. Source addresses in IGMPv3 membership reports for ASM groups are stored in the Cisco IOS IGMP cache (as displayed with the show ip igmp membership command), but PIM-based IP multicast routing considers only the ASM groups reported. Therefore, adding filtering for source addresses for ASM groups impacts only the IGMP cache for ASM groups.
How IGMP Checks an Extended Access List
When an IGMP extended access list is referenced in the ip igmp access-group command on an interface, the (S, G) pairs in the permit and deny statements of the extended access list are matched against the (S, G) pair of the IGMP reports received on the interface. For example, if an IGMP report with (S1, S2...Sn, G) is received, first the group (0.0.0.0, G) is checked against the access list statements. The convention (0.0.0.0, G) means (*, G), which is a wildcard source with a multicast group number. If the group is denied, the entire IGMP report is denied. If the group is permitted, each individual (S, G) pair is checked against the access list. Denied sources are taken out of the IGMP report, thereby denying the sources access to the multicast traffic.
IGMP Proxy
An IGMP proxy enables hosts in a unidirectional link routing (UDLR) environment that are not directly connected to a downstream router to join a multicast group sourced from an upstream network.
Figure 1 illustrates a sample topology that shows two UDLR scenarios:
•
•
Note
Figure 1 IGMP Proxy Topology
Scenario 1—Traditional UDLR Scenario (UDL Router with Directly Connected Receivers)
For scenario 1, no IGMP proxy mechanism is needed. In this scenario, the following sequence of events occurs:
1.
2.
3.
4.
Scenario 2—IGMP Proxy Scenario (UDL Router without Directly Connected Receivers)
For scenario 2, the IGMP proxy mechanism is needed to enable hosts that are not directly connected to a downstream router to join a multicast group sourced from an upstream network. In this scenario, the following sequence of events occurs:
1.
2.
3.
4.
5.
In an enterprise network, it is desirable to be able to receive IP multicast traffic via satellite and forward the traffic throughout the network. With unidirectional link routing (UDLR) alone, scenario 2 would not be possible because receiving hosts must be directly connected to the downstream router, Router B. The IGMP proxy mechanism overcomes this limitation by creating an IGMP report for (*, G) entries in the multicast forwarding table. To make this scenario functional, therefore, you must enable IGMP report forwarding of proxied (*, G) multicast static route (mroute) entries (using the ip igmp mroute-proxy command) and enable the mroute proxy service (using the ip igmp proxy-service command) on interfaces leading to PIM-enabled networks with potential members.
Note
How to Customize IGMP
This section contains the following tasks:
•
•
•
•
•
Configuring the Router to Forward Multicast Traffic in the Absence of Directly Connected IGMP Hosts
Perform this optional task to configure the router to forward multicast traffic in the absence of directly connected IGMP hosts.
Sometimes either there is no group member on a network segment or a host cannot report its group membership using IGMP. However, you may want multicast traffic to go to that network segment. The following are two ways to pull multicast traffic down to a network segment:
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Enabling the IGMPv3 Host Stack
Perform this optional task to add INCLUDE mode capability to the IGMPv3 host stack for SSM groups.
Prerequisites
•
•
Restrictions
•
•
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
DETAILED STEPS
Configuring IGMPv3—Explicit Tracking of Hosts, Groups, and Channels
Perform this optional task to enable a multicast router to explicitly track the membership of all multicast hosts in a particular multiaccess network. This enhancement to the Cisco IOS implementation of IGMPv3 enables the router to track each individual host that is joined to a particular group or channel.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Controlling Access to an SSM Network Using IGMP Extended Access Lists
IGMPv3 includes support for source filtering, that is, the ability for a system to report interest in receiving packets only from specific source addresses, or from all but specific source addresses, sent to a particular multicast address.
Perform this optional task to control access to an SSM network by using an IGMP extended access list that filters SSM traffic based on source address, group address, or both.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
DETAILED STEPS
Configuring an IGMP Proxy
Perform this optional task to configure unidirectional link (UDL) routers to use the IGMP proxy mechanism. An IGMP proxy enables hosts in a unidirectional link routing (UDLR) environment that are not directly connected to a downstream router to join a multicast group sourced from an upstream network.
To configure an IGMP proxy, you will need to perform the following tasks:
•
•
Prerequisites
Before configuring an IGMP proxy, ensure that the following conditions exist:
•
•
When enabling PIM on the interfaces for the IGMP proxy scenario, keep in mind the following guidelines:
–
–
–
–
Configuring the Upstream UDL Router for IGMP UDLR
Perform this task to configure the upstream UDL router for IGMP UDLR.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring the Downstream UDL Router for IGMP UDLR with IGMP Proxy Support
Perform this task to configure the downstream UDL router for IGMP UDLR with IGMP proxy support.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
DETAILED STEPS
Configuration Examples for Customizing IGMP
This section provides the following configuration examples:
•
•
•
•
Example: Configuring the Router to Forward Multicast Traffic in the Absence of Directly Connected IGMP Hosts
The following example shows how to configure a router to forward multicast traffic in the absence of directly connected IGMP hosts using the ip igmp join-group command. With this method, the router accepts the multicast packets in addition to forwarding them. Accepting the multicast packets prevents the router from fast switching.
In this example, Fast Ethernet interface 0/0 on the router is configured to join the group 225.2.2.2:
interface FastEthernet0/0ip igmp join-group 225.2.2.2The following example shows how to configure a router to forward multicast traffic in the absence of directly connected IGMP hosts using the ip igmp static-group command. With this method, the router does not accept the packets itself, but only forwards them. Hence, this method allows fast switching. The outgoing interface appears in the IGMP cache, but the router itself is not a member, as evidenced by lack of an "L" (local) flag in the multicast route entry.
In this example, static group membership entries for group 225.2.2.2 are configured on Fast Ethernet interface 0/1:
interface FastEthernet0/0ip igmp static-group 225.2.2.2Example: Enabling the IGMPv3 Host Stack
The following example shows how to add INCLUDE mode capability to the IGMPv3 host stack for SSM groups:
interface FastEthernet0/0ip igmp join-group 232.2.2.2 source 10.1.1.1ip igmp join-group 232.2.2.2 source 10.5.5.5ip igmp join-group 232.2.2.2 source 10.5.5.6ip igmp join-group 232.2.2.4 source 10.5.5.5ip igmp join-group 232.2.2.4 source 10.5.5.6ip igmp version 3Based on the configuration presented in this example, the following is sample output from the debug igmp command. The messages confirm that IGMPv3 membership reports are being sent after IGMPv3 and SSM are enabled:
Router# debug igmp*May 4 23:48:34.251: IGMP(0): Group 232.2.2.2 is now in the SSM range, changing*May 4 23:48:34.251: IGMP(0): Building v3 Report on Ethernet0/0*May 4 23:48:34.251: IGMP(0): Add Group Record for 232.2.2.2, type 5*May 4 23:48:34.251: IGMP(0): Add Source Record 10.1.1.1*May 4 23:48:34.251: IGMP(0): Add Source Record 10.5.5.5*May 4 23:48:34.251: IGMP(0): Add Source Record 10.5.5.6*May 4 23:48:34.251: IGMP(0): Add Group Record for 232.2.2.2, type 6*May 4 23:48:34.251: IGMP(0): No sources to add, group record removed from report*May 4 23:48:34.251: IGMP(0): Send unsolicited v3 Report with 1 group records on FastEthernet0/0*May 4 23:48:34.251: IGMP(0): Group 232.2.2.4 is now in the SSM range, changing*May 4 23:48:34.251: IGMP(0): Building v3 Report on Ethernet0/0*May 4 23:48:34.251: IGMP(0): Add Group Record for 232.2.2.4, type 5*May 4 23:48:34.251: IGMP(0): Add Source Record 10.5.5.5*May 4 23:48:34.251: IGMP(0): Add Source Record 10.5.5.6*May 4 23:48:34.251: IGMP(0): Add Group Record for 232.2.2.4, type 6*May 4 23:48:34.251: IGMP(0): No sources to add, group record removed from report*May 4 23:48:34.251: IGMP(0): Send unsolicited v3 Report with 1 group records on FastEthernet0/0*May 4 23:48:35.231: IGMP(0): Building v3 Report on Ethernet0/0*May 4 23:48:35.231: IGMP(0): Add Group Record for 232.2.2.2, type 5*May 4 23:48:35.231: IGMP(0): Add Source Record 10.1.1.1*May 4 23:48:35.231: IGMP(0): Add Source Record 10.5.5.5*May 4 23:48:35.231: IGMP(0): Add Source Record 10.5.5.6*May 4 23:48:35.231: IGMP(0): Add Group Record for 232.2.2.2, type 6*May 4 23:48:35.231: IGMP(0): No sources to add, group record removed from report*May 4 23:48:35.231: IGMP(0): Send unsolicited v3 Report with 1 group records on FastEthernet0/0*May 4 23:48:35.231: IGMP(0): Building v3 Report on Ethernet0/0*May 4 23:48:35.231: IGMP(0): Add Group Record for 232.2.2.4, type 5*May 4 23:48:35.231: IGMP(0): Add Source Record 10.5.5.5*May 4 23:48:35.231: IGMP(0): Add Source Record 10.5.5.6*May 4 23:48:35.231: IGMP(0): Add Group Record for 232.2.2.4, type 6*May 4 23:48:35.231: IGMP(0): No sources to add, group record removed from report*May 4 23:48:35.231: IGMP(0): Send unsolicited v3 Report with 1 group records on FastEthernet0/0The following is sample output from the show ip igmp groups command with the detail keyword for this configuration example scenario. The show ip igmp groups command can be used to verify that the router has received membership reports for (S, G) channels configured using the ip igmp join group command. When the router is correctly receiving IGMP membership reports for a channel, the "Flags:" output field will display the L and SSM flags.
Router# show ip igmp groups detailFlags: L - Local, U - User, SG - Static Group, VG - Virtual Group,SS - Static Source, VS - Virtual SourceInterface: FastEthernet0/0Group: 232.2.2.2Flags: L SSMUptime: 00:04:12Group mode: INCLUDELast reporter: 10.4.4.7Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static,V - Virtual, Ac - Accounted towards access control limit,M - SSM Mapping, L - Local)Source Address Uptime v3 Exp CSR Exp Fwd Flags10.1.1.1 00:04:10 stopped stopped Yes L10.5.5.5 00:04:12 stopped stopped Yes L10.5.5.6 00:04:12 stopped stopped Yes LInterface: FastEthernet0/0Group: 232.2.2.3Flags: L SSMUptime: 00:04:12Group mode: INCLUDELast reporter: 10.4.4.7Group source list: (C - Cisco Src Report, U - URD, R - Remote, S - Static,V - Virtual, Ac - Accounted towards access control limit,M - SSM Mapping, L - Local)Source Address Uptime v3 Exp CSR Exp Fwd Flags10.5.5.5 00:04:14 stopped stopped Yes L10.5.5.6 00:04:14 stopped stopped Yes LExample: Configuring IGMPv3—Explicit Tracking of Hosts, Groups, and Channels
The following example shows how to enable explicit tracking. The example shows a basic configuration for enabling IP multicast with SSM, IGMPv3, and explicit tracking.
ip multicast-routinginterface ethernet 0description access network to desktop systemsip address 10.1.0.1 255.255.255.0ip pim sparse-dense-modeip mroute-cacheip igmp version 3ip igmp explicit-trackinginterface ethernet 1description backbone interface no connected hostsip address 10.10.0.1 255.255.255.0ip pim sparse-dense-modeip mroute-cacheip pim ssm defaultExample: Controlling Access to an SSM Network Using IGMP Extended Access Lists
This section contains the following configuration examples for controlling access to an SSM network using IGMP extended access lists:
•
•
•
•
•
Note
Example: Denying All States for a Group G
The following example shows how to deny all states for a group G. In this example, FastEthernet interface 0/0 is configured to filter all sources for SSM group 232.2.2.2 in IGMPv3 reports, which effectively denies this group.
ip access-list extended test1deny igmp any host 232.2.2.2permit igmp any any!interface FastEthernet0/0ip igmp access-group test1Example: Denying All States for a Source S
The following example shows how to deny all states for a source S. In this example, Ethernet interface 1/1 is configured to filter all groups for source 10.2.1.32 in IGMPv3 reports, which effectively denies this source.
ip access-list extended test2deny igmp host 10.2.1.32 anypermit igmp any any!interface Ethernet1/1ip igmp access-group test2Example: Permitting All States for a Group G
The following example shows how to permit all states for a group G. In this example, Ethernet interface 1/2 is configured to accept all sources for SSM group 232.1.1.10 in IGMPv3 reports, which effectively accepts this group altogether.
ip access-list extended test3permit igmp any host 232.1.1.10!interface Ethernet1/2ip igmp access-group test3Example: Permitting All States for a Source S
The following example shows how to permit all states for a source S. In this example, Ethernet interface 1/2 is configured to accept all groups for source 10.6.23.32 in IGMPv3 reports, which effectively accepts this source altogether.
ip access-list extended test4permit igmp host 10.6.23.32 any!interface Ethernet1/2ip igmp access-group test4Example: Filtering a Source S for a Group G
The following example shows how to filter a particular source S for a group G. In this example, Ethernet interface 0/3 is configured to filter source 232.2.2.2 for SSM group 232.2.30.30 in IGMPv3 reports.
ip access-list extended test5deny igmp host 10.4.4.4 host 232.2.30.30permit igmp any any!interface Ethernet0/3ip igmp access-group test5Example: Configuring an IGMP Proxy
The following example shows how to configure the upstream UDL router for IGMP UDLR and the downstream UDL router for IGMP UDLR with IGMP proxy support. The IGMP proxy mechanism is needed to enable hosts that are not directly connected to a downstream router to join a multicast group sourced from an upstream network.
The example is based on the topology illustrated in Figure 2. In this example topology, Router A is the upstream router and Router B is the downstream router.
Note
Figure 2 IGMP Proxy Example Topology
Router A Configuration
interface ethernet 0ip address 10.1.1.1 255.255.255.0ip pim dense-mode!interface ethernet 1ip address 10.2.1.1 255.255.255.0ip pim dense-modeip igmp unidirectional-link!interface ethernet 2ip address 10.3.1.1 255.255.255.0Router B Configuration
ip pim rp-address 10.5.1.1 5access-list 5 permit 239.0.0.0 0.255.255.255!interface loopback 0ip address 10.7.1.1 255.255.255.0ip pim dense-modeip igmp helper-address udl ethernet 0ip igmp proxy-service!interface ethernet 0ip address 10.2.1.2 255.255.255.0ip pim dense-modeip igmp unidirectional-link!interface ethernet 1ip address 10.5.1.1 255.255.255.0ip pim sparse-modeip igmp mroute-proxy loopback 0!interface ethernet 2ip address 10.6.1.1 255.255.255.0Additional References
Related Documents
Overview of the IP multicast technology area
"IP Multicast Technology Overview" module
Basic IP multicast concepts, configuration tasks, and examples
"Configuring Basic IP Multicast" module
IGMP UDLR concepts, configuration tasks, and examples
IP multicast commands: complete command syntax, command mode, command history, command defaults, usage guidelines, and examples
Standards
No new or modified standards are supported by these features, and support for existing standards has not been modified by these features.
—
MIBs
RFCs
RFC 1112
Host extensions for IP multicasting
RFC 2236
Internet Group Management Protocol, Version 2
RFC 3376
Internet Group Management Protocol, Version 3
Technical Assistance
Feature Information for Customizing IGMP
Table 2 lists the release history for this feature.
Table 2 lists the features in this module and provides links to specific configuration information.
For information on a feature in this technology that is not documented here, see the "IP Multicast Features Roadmap."
Use Cisco Feature Navigator to find information about platform support and software image support. Cisco Feature Navigator enables you to determine which software images support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note
Table 2 Feature Information for Customizing IGMP
Extended ACL Support for IGMP to Support SSM in IPv4
12.0(19)S
12.3(7)T
12.2(25)S
12.2(27)SBC
12.2(33)SRA
12.2(33)SXH
15.0(1)S
Cisco IOS XE 3.1.0SGThe Extended ACL Support for IGMP to Support SSM in IPv4 feature enables IGMPv3 to accommodate extended access lists. IGMPv3 support of extended access lists allows you to leverage an important advantage of SSM in IPv4, that of filtering IGMPv3 reports based on source address, group address, or both.
The following sections provide information about this feature:
•
•
The following command was introduced by this feature:
ip igmp access-group.IGMPv3 Host Stack
12.3(14)T
12.2(33)SREThe IGMPv3 Host Stack feature enables routers and switches to function as multicast network endpoints or hosts. The feature adds INCLUDE mode capability to the IGMPv3 host stack for SSM groups. Enabling the IGMPv3 host stack ensures that hosts on a LAN can leverage SSM by enabling the router to initiate IGMPv3 joins, such as in environments where fast channel change is required in a SSM deployments.
The following sections provide information about this feature:
•
•
The following command was modified by this feature: ip igmp join-group.
IGMPv3—Explicit Tracking Host, Group, and Channel
12.0(19)S
12.2(8)T
12.2(14)S
15.0(1)S
Cisco IOS XE 3.1.0SGThe IGMPv3—Explicit Tracking Host, Group, and Channel feature enables a multicast router to explicitly track the membership of all multicast hosts in a particular multiaccess network. This enhancement to the Cisco IOS implementation of IGMPv3 enables the router to track each individual host that is joined to a particular group or channel.
The following sections provide information about this feature:
•
•
The following commands were introduced by this feature:
ip igmp explicit-tracking, show ip igmp membership.
Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
© 2005-2010 Cisco Systems, Inc. All rights reserved.
Feedback