Cisco IP Multicast IGMP Configuration Guide
Cisco IP Multicast IGMP Configuration Guide
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL STATEMENTS,
INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT SHIPPED WITH
THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY,
CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB's public domain version
of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS" WITH ALL FAULTS.
CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING, WITHOUT
LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS
HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
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.
Cisco and the Cisco logo are trademarks or registered trademarks of Cisco and/or its affiliates in the U.S. and other countries. To view a list of Cisco trademarks, go to this URL: https:/
/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. (1721R)
Enabling RGMP 96
Verifying RGMP Configuration 97
Monitoring and Maintaining RGMP 97
Configuration Examples for RGMP 99
RGMP Configuration Example 99
Additional References 100
Feature Information for Router-Port Group Management Protocol 102
Feature Information
Use Cisco Feature Navigator to find information about feature support, platform support, and Cisco software
image support. An account on Cisco.com is not required.
Related References
• Cisco IOS Command References, All Releases
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 table.
Use Cisco Feature Navigator to find information about platform support and Cisco software image support.
To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
• Only when the last host in a virtual LAN (VLAN) has left the multicast group does forwarding of the
traffic of this group into the VLAN revert to no ports on the forwarding switch.
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:
• Configure only the interface for IGMPv2 and use IGMP v3lite and URD.
• Enable IGMPv3 and accept the higher leave latencies through the CGMP switch.
Hosts identify group memberships by sending IGMP messages to their local multicast device. Under IGMP,
devices listen to IGMP messages and periodically send out queries to discover which groups are active or
inactive on a particular subnet.
Note By default, enabling a PIM on an interface enables IGMPv2 on that device. IGMPv2 was designed to be
as backward compatible with IGMPv1 as possible. To accomplish this backward compatibility, RFC 2236
defined special interoperability rules. If your network contains legacy IGMPv1 hosts, you should be
familiar with these operability rules. For more information about IGMPv1 and IGMPv2 interoperability,
see RFC 2236, Internet Group Management Protocol, Version 2 .
The query and membership report messages in IGMPv2 are identical to the IGMPv1 messages with two
exceptions:
• IGMPv2 query messages are broken into two categories: general queries (identical to IGMPv1 queries)
and group-specific queries.
• IGMPv1 membership reports and IGMPv2 membership reports have different IGMP type codes.
IGMPv2 also enhances IGMP by providing support for the following capabilities:
• Querier election process--Provides the capability for IGMPv2 devices to elect the IGMP querier without
having to rely on the multicast routing protocol to perform the process.
• Maximum Response Time field--A new field in query messages permits the IGMP querier to specify
the maximum query-response time. This field permits the tuning of the query-response process to control
response burstiness and to fine-tune leave latencies.
• Group-Specific Query messages--Permits the IGMP querier to perform the query operation on a specific
group instead of all groups.
• Leave-Group messages--Provides hosts with a method of notifying devices on the network that they
wish to leave the group.
Unlike IGMPv1, in which the DR and the IGMP querier are typically the same device, in IGMPv2 the two
functions are decoupled. The DR and the IGMP querier are selected based on different criteria and may be
different devices on the same subnet. The DR is the device with the highest IP address on the subnet, whereas
the IGMP querier is the device with the lowest IP address.
Query messages are used to elect the IGMP querier as follows:
1 When IGMPv2 devices start, they each multicast a general query message to the all-systems group address
of 224.0.0.1 with their interface address in the source IP address field of the message.
2 When an IGMPv2 device receives a general query message, the device compares the source IP address in
the message with its own interface address. The device with the lowest IP address on the subnet is elected
the IGMP querier.
3 All devices (excluding the querier) start the query timer, which is reset whenever a general query message
is received from the IGMP querier. If the query timer expires, it is assumed that the IGMP querier has
gone down, and the election process is performed again to elect a new IGMP querier.
• When a host wants to join a group excluding particular sources, it sends an IGMPv3 membership report
to 224.0.0.22 excluding those sources in the EXCLUDE list.
Note If some IGMPv3 hosts on a LAN wish to exclude a source and others wish to include the source, then the
device will send traffic for the source on the LAN (that is, inclusion trumps exclusion in this situation).
• IGMPv2 leave-group messages are destined to the address 224.0.0.2 (all devices on a subnet).
• IGMPv3 membership reports are destined to the address 224.0.0.22; all IGMPv3-capable multicast
devices must listen to this address.
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.
Note The permit and deny statements equivalent to (*, G) are permit host 0.0.0.0 host group-address and 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 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 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.
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.
The figure below illustrates a sample topology that shows two UDLR scenarios:
• Traditional UDL routing scenario--A UDL device with directly connected receivers.
• IGMP proxy scenario--UDL device without directly connected receivers.
Note IGMP UDLs are needed on the upstream and downstream devices.
Scenario 1--Traditional UDLR Scenario (UDL Device with Directly Connected Receivers)
For scenario 1, no IGMP proxy mechanism is needed. In this scenario, the following sequence of events
occurs:
1 User 2 sends an IGMP membership report requesting interest in group G.
2 Router B receives the IGMP membership report, adds a forwarding entry for group G on LAN B, and
proxies the IGMP report to Router A, which is the UDLR upstream device.
Scenario 2--IGMP Proxy Scenario (UDL Device without Directly Connected Receivers)
For scenario 2, the IGMP proxy mechanism is needed to enable hosts that are not directly connected to a
downstream device to join a multicast group sourced from an upstream network. In this scenario, the following
sequence of events occurs:
1 User 1 sends an IGMP membership report requesting interest in group G.
2 Router C sends a PIM Join message hop-by-hop to the RP (Router B).
3 Router B receives the PIM Join message and adds a forwarding entry for group G on LAN B.
4 Router B periodically checks its mroute table and proxies the IGMP membership report to its upstream
UDL device across the Internet link.
5 Router A creates and maintains a forwarding entry on the unidirectional link (UDL).
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 device, 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 Because PIM messages are not forwarded upstream, each downstream network and the upstream network
have a separate domain.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. Do one of the following:
• ip igmp join-group group-address
• ip igmp static-group {* | group-address [source source-address]}
5. end
6. show ip igmp interface [interface-type interface-number]
DETAILED STEPS
Example:
device# configure terminal
Step 4 Do one of the following: The first sample shows how to configure an interface on the device
to join the specified group.
• ip igmp join-group group-address
With this method, the device accepts the multicast packets in addition
• ip igmp static-group {* | group-address to forwarding them. Accepting the multicast packets prevents the
[source source-address]} device from fast switching.
The second example shows how to configure static group
membership entries on an interface. With this method, the device
Example:
does not accept the packets itself, but only forwards them. Hence,
device(config-if)# ip igmp join-group this method allows fast switching. The outgoing interface appears
225.2.2.2 in the IGMP cache, but the device itself is not a member, as
evidenced by lack of an “L” (local) flag in the multicast route entry
Example:
device(config-if)# ip igmp static-group
225.2.2.2
Example:
device#(config-if)# end
Step 6 show ip igmp interface [interface-type (Optional) Displays multicast-related information about an interface.
interface-number]
Example:
device# show ip igmp interface
SUMMARY STEPS
1. enable
2. configure terminal
3. ip multicast-routing [distributed]
4. ip pim ssm {default | range access-list}
5. ip access-list extended access-list -name
6. deny igmp source source-wildcard destination destination-wildcard [igmp-type] [precedence precedence]
[tos tos] [log] [time-range time-range-name] [fragments]
7. permit igmp source source-wildcard destination destination-wildcard [igmp-type] [precedence
precedence] [tos tos] [log] [time-range time-range-name] [fragments]
8. exit
9. interface type number
10. ip igmp access-group access-list
11. ip pim sparse-mode
12. Repeat Steps 1 through 11 on all interfaces that require access control of SSM channel membership.
13. ip igmp version 3
14. Repeat Step 13 on all host-facing interfaces.
15. end
DETAILED STEPS
Example:
Device# configure terminal
Step 5 ip access-list extended access-list -name Specifies an extended named IP access list.
Example:
Device(config)# ip access-list extended
mygroup
Step 6 deny igmp source source-wildcard destination (Optional) Filters the specified source address or group address
destination-wildcard [igmp-type] [precedence from the IGMP report, thereby restricting hosts on a subnet
precedence] [tos tos] [log] [time-range from membership to the (S, G) channel.
time-range-name] [fragments]
• Repeat this step to restrict hosts on a subnet membership
to other (S, G) channels. (These sources should be more
Example: specific than a subsequent permit statement because any
Device(config-ext-nacl)# deny igmp host sources or groups not specifically permitted are denied.)
10.1.2.3 any
• Remember that the access list ends in an implicit deny
statement.
• This example shows how to create a deny statement that
filters all groups for source 10.1.2.3, which effectively
denies the source.
Step 8 exit Exits the current configuration session and returns to global
configuration mode.
Example:
Device(config-ext-nacl)# exit
Step 9 interface type number Selects an interface that is connected to hosts on which IGMPv3
can be enabled.
Example:
Device(config)# interface ethernet 0
Step 10 ip igmp access-group access-list Applies the specified access list to IGMP reports.
Example:
Device(config-if)# ip igmp access-group
mygroup
Example:
Device(config-if)# end
When enabling PIM on the interfaces for the IGMP proxy scenario, keep in mind the following guidelines:
• • Use PIM sparse mode (PIM-SM) when the interface is operating in a sparse-mode region and you
are running static RP, bootstrap (BSR), or Auto-RP with the Auto-RP listener capability.
• Use PIM sparse-dense mode when the interface is running in a sparse-dense mode region and you
are running Auto-RP without the Auto-RP listener capability.
• Use PIM dense mode (PIM-DM) for this step when the interface is operating in dense mode and
is, thus, participating in a dense-mode region.
• Use PIM-DM with the proxy-register capability when the interface is receiving source traffic from
a dense-mode region that needs to reach receivers that are in a sparse-mode region.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip igmp unidirectional-link
5. end
DETAILED STEPS
Example:
Device# configure terminal
Step 5 end Ends the current configuration session and returns to privileged
EXEC mode.
Example:
Device(config-if)# end
Configuring the Downstream UDL Device for IGMP UDLR with IGMP Proxy Support
Perform this task to configure the downstream UDL device for IGMP UDLR with IGMP proxy support.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip igmp unidirectional-link
5. exit
6. interface type number
7. ip igmp mroute-proxy type number
8. exit
9. interface type number
10. ip igmp helper-address udl interface-type interface-number
11. ip igmp proxy-service
12. end
13. show ip igmp interface
14. show ip igmp udlr
DETAILED STEPS
Example:
Device# configure terminal
Step 4 ip igmp unidirectional-link Configures IGMP on the interface to be unidirectional for IGMP UDLR.
Example:
Device(config-if)# ip igmp
unidirectional-link
Example:
Device(config-if)# exit
Step 7 ip igmp mroute-proxy type number Enables IGMP report forwarding of proxied (*, G) multicast static route
(mroute) entries.
Example: • This step is performed to enable the forwarding of IGMP reports to
Device(config-if)# ip igmp a proxy service interface for all (*, G) forwarding entries in the
mroute-proxy loopback 0 multicast forwarding table.
• In this example, the ip igmp mroute-proxy command is configured
on Gigabit Ethernet interface 1/0/0 to request that IGMP reports be
sent to loopback interface 0 for all groups in the mroute table that are
forwarded to Gigabit Ethernet interface 1/0/0.
Step 8 exit Exits interface configuration mode and returns to global configuration mode.
Example:
Device(config-if)# exit
Step 9 interface type number Enters interface configuration mode for the specified interface.
• In this example, loopback interface 0 is specified.
Example:
Device(config)# interface loopback
0
Step 12 end Ends the current configuration session and returns to privileged EXEC
mode.
Example:
Device(config-if)# end
Step 13 show ip igmp interface (Optional) Displays multicast-related information about an interface.
Example:
Device# show ip igmp interface
Step 14 show ip igmp udlr (Optional) Displays UDLR information for directly connected multicast
groups on interfaces that have a UDL helper address configured.
Example:
Device# show ip igmp udlr
In this example, Fast Ethernet interface 0/0/0 on the device is configured to join the group 225.2.2.2:
interface FastEthernet0/0/0
ip igmp join-group 225.2.2.2
The following example shows how to configure a device to forward multicast traffic in the absence of directly
connected IGMP hosts using the ip igmp static-group command. With this method, the device 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 device 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/0:
interface FastEthernet0/1/0
ip igmp static-group 225.2.2.2
Note Keep in mind that access lists are very flexible: there are many combinations of permit and deny statements
one could use in an access list to filter multicast traffic. The examples in this section simply provide a few
examples of how it can be done.
Additional References
The following sections provide references related to customizing IGMP.
Related Documents
Basic IP multicast concepts, configuration tasks, and “ Configuring Basic IP Multicast ” or “Configuring
examples IP Multicast in IPv6 Networks” module
Standard/RFC Title
RFC 1112 Host extensions for IP multicasting
MIBs
Technical Assistance
Description Link
The Cisco Support and Documentation website http://www.cisco.com/cisco/web/support/index.html
provides online resources to download documentation,
software, and tools. Use these resources to install and
configure the software and to troubleshoot and resolve
technical issues with Cisco products and technologies.
Access to most tools on the Cisco Support and
Documentation website requires a Cisco.com user ID
and password.
UDLR Tunnel ARP and IGMP Cisco IOS XE Release 3.8S This feature enables ARP over a
Proxy unidirectional link, and overcomes
the existing limitation of requiring
downstream multicast receivers to
be directly connected to the
unidirectional link downstream
router.
IGMPv3
Internet Group Management Protocol (IGMP) is the protocol used by IPv4 devices to report their IP multicast
group memberships to neighboring multicast devices. Version 3 (v3) of IGMP adds support for source filtering.
Source filtering enables a multicast receiver host to signal from which groups it wants to receive multicast
traffic, and from which sources this traffic is expected. That information may be used by multicast routing
protocols to avoid delivering multicast packets from specific sources to networks where there are no interested
receivers.
In addition, IGMPv3 supports the link local address 224.0.0.22, which is the destination IP address for IGMPv3
membership reports; all IGMPv3-capable multicast devices must listen to this address. RFC 3376 defines
IGMPv3.
Note For more information about IGMPv3 group record types and membership reports, see RFC 3376, Internet
Group Management Protocol, Version 3 .
Note If the ip igmp join-group command is configured for a group and source and IGMPv3 is not configured
on the interface, (S, G) state will be created but no IGMPv3 membership reports will be sent.
Perform this task to add INCLUDE mode capability to the IGMPv3 host stack for SSM groups
.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip igmp version 3
5. ip igmp join-group group - address source source - address
6. end
7. show ip igmp groups detail
DETAILED STEPS
Example:
Device# configure terminal
Step 3 interface type number Enters interface configuration mode. The specified interface
must be connected to hosts.
Example:
Device(config)# interface FastEthernet 1
Example:
Device(config-if)# ip igmp version 3
Step 5 ip igmp join-group group - address source Configures the interface to join the specified (S, G) channel
source - address and enables the device to provide INCLUDE mode capability
for the (S, G) channel .
Example: Note Repeat this step for each channel to be configured
Device(config-if)# ip igmp join-group with the INCLUDE mode capability.
232.2.2.2 source 10.1.1.1
Example:
Device(config-if)# end
Step 7 show ip igmp groups detail Displays directly-connected multicast groups that were
learned through IGMP.
Example:
Device# show ip igmp groups detail
interface FastEthernet0/0/0
ip igmp join-group 232.2.2.2 source 10.1.1.1
ip igmp join-group 232.2.2.2 source 10.5.5.5
ip igmp join-group 232.2.2.2 source 10.5.5.6
ip igmp join-group 232.2.2.4 source 10.5.5.5
ip igmp join-group 232.2.2.4 source 10.5.5.6
ip igmp version 3
Based on the configuration presented in the preceding 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:
*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 GigabitEthernet0/0/0
Additional References
Related Documents
Standard/RFC Title
RFC 3376 Internet Group Management Protocol, Version 3
MIBs
Technical Assistance
Description Link
The Cisco Support and Documentation website http://www.cisco.com/cisco/web/support/index.html
provides online resources to download documentation,
software, and tools. Use these resources to install and
configure the software and to troubleshoot and resolve
technical issues with Cisco products and technologies.
Access to most tools on the Cisco Support and
Documentation website requires a Cisco.com user ID
and password.
The IGMP Static Group Range Support feature introduces the capability to configure group ranges in class
maps and attach class maps to the interface.
Unlike QoS class maps, which are defined by specifying numerous match criteria, IGMP static group class
maps are defined by specifying multicast groups entries (group addresses, group ranges, SSM channels, and
SSM channel ranges). Also, IGMP static group range class maps are not configured in traffic policies. Rather,
the ip ignmp static-group command has been extended to support IGMP static group ranges.
Once a class map is attached to an interface, all group entries defined in the class map become statically
connected members on the interface and are added to the IGMP cache and IP multicast route (mroute) table.
The class-map type multicast-flows command is used to enter multicast-flows class map configuration mode
to create or modify an IGMP static group class map.
Unlike QoS class maps, which are defined by specifying numerous match criteria, IGMP static group class
maps are defined by specifying multicast groups entries (group addresses, group ranges, SSM channels, and
SSM channel ranges). The following forms of the group command are entered from multicast-flows class
map configuration mode to define group entries to associate with the class map:
• group group-address
Defines a group address to be associated with an IGMP static group class map.
Defines a range of group addresses to be associated with an IGMP static group class map.
• group group-address source source-address
Defines an SSM channel to be associated with an IGMP static group class map.
• group group-address to group-address source source-address
Defines a range of SSM channels to be associated with an IGMP static group class map.
Unlike QoS class maps, IGMP static group range class maps are not configured in traffic policies. Rather, the
ip igmp static-group command has been extended to support IGMP static group ranges. After creating an
IGMP static group class map, you can attach the class map to interfaces using the ip igmp static-group
command with the class-mapkeyword and class-map-name argument. Once a class map is attached to an
interface, all group entries defined in the class map become statically connected members on the interface
and are added to the IGMP cache and IP multicast route (mroute) table.
SUMMARY STEPS
1. enable
2. configure terminal
3. class-map type multicast-flows class-map-name
4. group group-address [to group-address] [source source-address]
5. exit
6. Repeat Steps 3 to 5 to create additional class maps.
7. interface type number
8. ip igmp static-group class-map class-map-name
9. ip igmp static-group *
10. end
DETAILED STEPS
Example:
Device# configure terminal
Step 3 class-map type multicast-flows class-map-name Enters multicast-flows class map configuration mode to create
or modify an IGMP static group class map.
Example:
Device(config)# class-map type
multicast-flows static1
Step 4 group group-address [to group-address] [source Defines the group entries to be associated with the class map.
source-address]
• Repeat this step to associate additional group entires to
the class map being configured.
Example:
Device(config-mcast-flows-cmap)# group
232.1.1.7 to 232.1.1.20
Example:
Device(config)# interface FastEthernet 0/1
Step 8 ip igmp static-group class-map class-map-name Attaches an IGMP static group class map to the interface.
Example:
Device(config-if)# ip igmp static-group
class-map static1
Step 9 ip igmp static-group * (Optional) Places the interface into all created multicast route
(mroute) entries.
Example: • Depending on your Cisco software release, this step is
Device(config-if)# ip igmp static-group * required if the interface of a last hop device does not
have any PIM neighbors and does not have a receiver.
See the ip igmp static-group command in the Cisco
IOS IP Multicast Command Reference.
SUMMARY STEPS
DETAILED STEPS
Example:
Device# show ip igmp static-group class-map
Class-map static1
Group address range 228.8.8.7 to 228.8.8.9
Group address 232.8.8.7, source address 10.1.1.10
Interfaces using the classmap:
Loopback0
Class-map static
Group address range 232.7.7.7 to 232.7.7.9, source address 10.1.1.10
Group address 227.7.7.7
Group address range 227.7.7.7 to 227.7.7.9
Group address 232.7.7.7, source address 10.1.1.10
Interfaces using the classmap:
FastEthernet3/1
The following is sample output from the show ip igmp static-group class-mapcommand with the interface keyword:
Example:
Device# show ip igmp static-group class-map interface
Loopback0
Class-map attached: static1
FastEthernet3/1
Class-map attached: static
The following is sample output from the show ip igmp static-group class-mapcommand with the interface keyword
and type number arguments:
Example:
Device# show ip igmp static-group class-map interface FastEthernet 3/1
FastEthernet3/1
Class-map attached: static
Example:
device# show ip igmp groups
Example:
Device# show ip mroute
Class-map static
Group address range 227.7.7.7 to 227.7.7.9
Group address 232.7.7.7, source address 10.1.1.10
Group address range 232.7.7.7 to 232.7.7.9, source address 10.1.1.10
Group address 227.7.7.7
Interfaces using the classmap:
FastEthernet3/1
The following is sample output from the show ip igmp groups command. In this example, the command is
issued to confirm that the group entries defined in the class map named static (the class map configured in
the Example: Configuring IGMP Static Group Support, on page 42 section) were added to the IGMP cache.
Additional References
Related Documents
Standard/RFC Title
RFC 2933 Internet Group Management Protocol MIB
MIBs
Technical Assistance
Description Link
The Cisco Support and Documentation website http://www.cisco.com/cisco/web/support/index.html
provides online resources to download documentation,
software, and tools. Use these resources to install and
configure the software and to troubleshoot and resolve
technical issues with Cisco products and technologies.
Access to most tools on the Cisco Support and
Documentation website requires a Cisco.com user ID
and password.
Before you can configure and use SSM mapping with DNS lookups, you need to add records to a running
DNS server. If you do not already have a DNS server running, you need to install one.
The Cisco IOS XE software does not provide for DNS server functionality. You may want to use a product
such as Cisco Network Registrar (CNR).
• Enable IGMPv3 with care on the last hop router when you rely solely on SSM mapping as a transition
solution for full SSM. When both SSM mapping and IGMPv3 are enabled, the router will send out
IGMPv3 membership query messages instead of IGMPv3 membership messages. If the receiver hosts
that are to be supported with SSM mapping can only support IGMPv1 or IGMPv2, then enabling SSM
mapping on an interface with IGMPv3 is fine. IGMPv3 membership query messages will be interpreted
as IGMPv1 or IGMPv2 queries and the host will continue to report with IGMPv1 or IGMPv2 reports.
However, when both SSM mapping and IGMPv3 are enabled and the hosts already support IGMPv3
(but not SSM), then they will start to send IGMPv3 group reports. These IGMPv3 group reports are not
supported with SSM mapping and the router will not correctly associate sources with these reports.
SSM Components
SSM is a datagram delivery model that best supports one-to-many applications, also known as broadcast
applications. SSM is a core networking technology for the Cisco implementation of IP multicast solutions
targeted for audio and video broadcast application environments and is described in RFC 3569. The following
two components together support the implementation of SSM:
• Protocol Independent Multicast source-specific mode (PIM-SSM)
• Internet Group Management Protocol Version 3 (IGMPv3)
Protocol Independent Multicast (PIM) SSM, or PIM-SSM, is the routing protocol that supports the
implementation of SSM and is derived from PIM sparse mode (PIM-SM). IGMP is the Internet Engineering
Task Force (IETF) standards track protocol used for hosts to signal multicast group membership to routers.
IGMP Version 3 supports source filtering, which is required for SSM. IGMP For SSM to run with IGMPv3,
SSM must be supported in the router, the host where the application is running, and the application itself.
• The prevention against DoS attacks is an important factor for Internet broadcast services because, with
their exposure to a large number of receivers, they are the most common targets for such attacks.
• The ease of installation and operation of SSM makes it ideal for network operators, especially in those
cases where content needs to be forwarded between multiple independent PIM domains (because there
is no need to manage MSDP for SSM between PIM domains).
IGMP v3lite is a solution for application developers that allows immediate development of SSM receiver
applications switching to IGMPv3 as soon as it becomes available.
For more information about IGMP v3lite, see the “ Configuring Source Specific Multicast ” module.
URD is an SSM transition solution for content providers and content aggregators that allows them to deploy
receiver applications that are not yet SSM enabled (through support for IGMPv3) by enabling the receiving
applications to be started and controlled through a web browser.
For more information about URD, see the see the “ Configuring Source Specific Multicast ” module.
SSM mapping supports SSM transition in cases where neither URD nor IGMP v3lite are available, or when
supporting SSM on the end system is impossible or unwanted due to administrative or technical reasons.
SSM mapping provides an SSM transition solution for hosts and applications that meet those conditions.
In a typical STB deployment, each TV channel uses one separate IP multicast group and has one active server
host sending the TV channel. A single server may of course send multiple TV channels, but each to a different
group. In this network environment, if a router receives an IGMPv1 or IGMPv2 membership report for a
particular group G, the report implicitly addresses the well-known TV server for the TV channel associated
with the multicast group.
SSM mapping introduces a means for the last hop router to discover sources sending to groups. When SSM
mapping is configured, if a router receives an IGMPv1 or IGMPv2 membership report for a particular group
G, the router translates this report into one or more (S, G) channel memberships for the well-known sources
associated with this group.
Note As is the case for the other SSM transition solutions (URD and IGMP v3lite), SSM mapping only needs
to be configured on the last hop router connected to receivers. No support is needed on any other routers
in the network. SSM mapping, in addition, is fully compatible with IGMPv3, IGMP v3lite, and URD.
When the router receives an IGMPv1 or IGMPv2 membership report for group G, the router uses SSM mapping
to determine one or more source IP addresses for group G. SSM mapping then translates the membership
report as an IGMPv3 report INCLUDE (G, [S1, G], [S2, G]...[Sn, G] and continues as if it had received an
IGMPv3 report. The router then sends out PIM joins toward (S1, G) to (Sn, G) and continues to be joined to
these groups as long as it continues to receive the IGMPv1 or IGMPv2 membership reports and as long as
the SSM mapping for the group remains the same. SSM mapping, thus, enables you to leverage SSM for
video delivery to legacy STBs that do not support IGMPv3 or for applications that do not take advantage of
the IGMPv3 host stack.
SSM mapping enables the last hop router to determine the source addresses either by a statically configured
table on the router or by consulting a DNS server. When the statically configured table is changed, or when
the DNS mapping changes, the router will leave the current sources associated with the joined groups.
name and uses the returned IP addresses as the source addresses associated with this group. SSM mapping
supports up to 20 sources for each group. The router joins all sources configured for a group.
The SSM mapping mechanism that enables the last hop router to join multiple sources for a group can be used
to provide source redundancy for a TV broadcast. In this context, the redundancy is provided by the last hop
router using SSM mapping to join two video sources simultaneously for the same TV channel. However, to
prevent the last hop router from duplicating the video traffic, it is necessary that the video sources utilize a
server-side switchover mechanism where one video source is active while the other backup video source is
passive. The passive source waits until an active source failure is detected before sending the video traffic for
the TV channel. The server-side switchover mechanism, thus, ensures that only one of the servers is actively
sending the video traffic for the TV channel.
To look up one or more source addresses for a group G that includes G1, G2, G3, and G4, the following DNS
resource records (RRs) must be configured on the DNS server:
IN A source-address-2
IN A source-address-n
The multicast-domain argument is a configurable DNS prefix. The default DNS prefix is in-addr.arpa. You
should only use the default prefix when your installation is either separate from the internet or if the group
names that you map are global scope group addresses (RFC 2770 type addresses that you configure for SSM)
that you own.
The timeout argument configures the length of time for which the router performing SSM mapping will cache
the DNS lookup. This argument is optional and defaults to the timeout of the zone in which this entry is
configured. The timeout indicates how long the router will keep the current mapping before querying the DNS
server for this group. The timeout is derived from the cache time of the DNS RR entry and can be configured
for each group/source entry on the DNS server. You can configure this time for larger values if you want to
minimize the number of DNS queries generated by the router. Configure this time for a low value if you want
to be able to quickly update all routers with new source addresses.
Note Refer to your DNS server documentation for more information about configuring DNS RRs.
To configure DNS-based SSM mapping in the software, you must configure a few global commands but no
per-channel specific configuration is needed. There is no change to the configuration for SSM mapping if
additional channels are added. When DNS-based SSM mapping is configured, the mappings are handled
entirely by one or more DNS servers. All DNS techniques for configuration and redundancy management
can be applied to the entries needed for DNS-based SSM mapping.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip igmp ssm-map enable
4. no ip igmp ssm-map query dns
5. ip igmp ssm-map static access-list source-address
6. Repeat Step 5 to configure additional static SSM mappings, if required.
7. end
8. show running-config
9. copy running-config start-up config
DETAILED STEPS
Example:
Device# configure terminal
Step 3 ip igmp ssm-map enable Enables SSM mapping for groups in the configured SSM range.
Note By default, this command enables DNS-based SSM
Example: mapping.
Device(config)# ip igmp ssm-map enable
Step 4 no ip igmp ssm-map query dns (Optional) Disables DNS-based SSM mapping.
Note Disable DNS-based SSM mapping if you only want to rely
Example: on static SSM mapping. By default, the ip igmp ssm-map
Device(config)# no ip igmp ssm-map query command enables DNS-based SSM mapping.
dns
Example:
Device# show running-config
Step 9 copy running-config start-up config (Optional) Saves your entries in the configuration file.
Example:
Device# copy running-config start-up
config
What to Do Next
Proceed to the Configuring DNS-Based SSM Mapping (CLI), on page 55 or to the Verifying SSM Mapping
Configuration and Operation, on page 58.
SUMMARY STEPS
1. enable
2. configure terminal
3. ip igmp ssm-map enable
4. ip igmp ssm-map query dns
5. ip domain multicast domain-prefix
6. ipname-server server-address1 [server-address2server-address6]
7. Repeat Step 6 to configure additional DNS servers for redundancy, if required.
8. end
9. show running-config
10. copy running-config startup-config
DETAILED STEPS
Example:
Device# configure terminal
Step 3 ip igmp ssm-map enable Enables SSM mapping for groups in a configured SSM range.
Example:
Device(config)# ip igmp ssm-map enable
Step 4 ip igmp ssm-map query dns (Optional) Enables DNS-based SSM mapping.
• By default, the ip igmp ssm-map command enables
Example: DNS-based SSM mapping. Only the noform of this
Device(config)# ip igmp ssm-map query dns
command is saved to the running configuration.
Example:
Device(config)# ip name-server 10.48.81.21
Example:
Device(config-if)# end
Example:
Device# show running-config
Step 10 copy running-config startup-config (Optional) Saves your entries in the configuration file.
Example:
Device# copy running-config startup-config
What to Do Next
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip igmp static-group group-address source ssm-map
DETAILED STEPS
Example:
Router# configure terminal
Step 3 interface type number Selects an interface on which to statically forward traffic for a multicast
group using SSM mapping and enters interface configuration mode.
Example: Note Static forwarding of traffic with SSM mapping works with
Router(config)# interface either DNS-based SSM mapping or statically-configured SSM
gigabitethernet 1/0/0 mapping.
Step 4 ip igmp static-group group-address source Configures SSM mapping to be used to statically forward a (S, G)
ssm-map channel out of the interface.
• Use this command if you want to statically forward SSM traffic
Example: for certain groups, but you want to use DNS-based SSM mapping
Router(config-if)# ip igmp static-group to determine the source addresses of the channels.
232.1.2.1 source ssm-map
What to Do Next
Proceed to the Verifying SSM Mapping Configuration and Operation, on page 58.
SUMMARY STEPS
1. enable
2. show ip igmp ssm-mapping
3. show ip igmp ssm-mapping group-address
4. show ip igmp groups [group-name | group-address | interface-type interface-number] [detail]
5. show host
6. debug ip igmp group-address
DETAILED STEPS
Step 1 enable
Enables privileged EXEC mode. Enter your password if prompted.
Example:
Device> enable
Example:
Device# show ip igmp ssm-mapping
SSM Mapping : Enabled
DNS Lookup : Enabled
Mcast domain : ssm-map.cisco.com
Name servers : 10.0.0.3
10.0.0.4
Example:
Device# show ip igmp ssm-mapping 232.1.1.4
Group address: 232.1.1.4
Database : DNS
DNS name : 4.1.1.232.ssm-map.cisco.com
Expire time : 860000
Source list : 172.16.8.5
: 172.16.8.6
(Optional) Displays the multicast groups with receivers that are directly connected to the router and that were learned
through IGMP.
The following is sample output from the show ip igmp groups command with the group-address argument and detail
keyword. In this example the “M” flag indicates that SSM mapping is configured.
Example:
Device# show ip igmp group 232.1.1.4 detail
Interface: GigabitEthernet2/0/0
Group: 232.1.1.4 SSM
Uptime: 00:03:20
Group mode: INCLUDE
Last reporter: 0.0.0.0
CSR Grp Exp: 00:02:59
Group source list: (C - Cisco Src Report, U - URD, R - Remote,
S - Static, M - SSM Mapping)
Source Address Uptime v3 Exp CSR Exp Fwd Flags
172.16.8.3 00:03:20 stopped 00:02:59 Yes CM
172.16.8.4 00:03:20 stopped 00:02:59 Yes CM
172.16.8.5 00:03:20 stopped 00:02:59 Yes CM
172.16.8.6 00:03:20 stopped 00:02:59 Yes CM
Example:
Device# show host
Default domain is cisco.com
Name/address lookup uses domain service
Name servers are 10.48.81.21
Codes: UN - unknown, EX - expired, OK - OK, ?? - revalidate
temp - temporary, perm - permanent
NA - Not Applicable None - Not defined
Host Port Flags Age Type Address(es)
10.0.0.0.ssm-map.cisco.c None (temp, OK) 0 IP 172.16.8.5
172.16.8.6
172.16.8.3
172.16.8.4
Example:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using STATIC.
The following is sample output from the debug ip igmp command when DNS-based SSM mapping is enabled. The
following output indicates that a DNS lookup has succeeded:
Example:
IGMP(0): Convert IGMPv2 report (*,232.1.2.3) to IGMPv3 with 2 source(s) using DNS.
The following is sample output from the debug ip igmp command when DNS-based SSM mapping is enabled and a
DNS lookup has failed:
IGMP(0): DNS source lookup failed for (*, 232.1.2.3), IGMPv2 report failed
Note Address assignment in the global SSM range 232.0.0.0/8 should be random. If you copy parts or all of
this sample configuration, make sure to select a random address range but not 232.1.1.x as shown in this
example. Using a random address range minimizes the possibility of address collision and may prevent
conflicts when other SSM content is imported while SSM mapping is used.
!
no ip domain lookup
ip domain multicast ssm.map.cisco.com
ip name-server 10.48.81.21
!
!
ip multicast-routing distributed
ip igmp ssm-map enable
ip igmp ssm-map static 10 172.16.8.10
ip igmp ssm-map static 11 172.16.8.11
!
!
.
.
.
!
interface GigabitEthernet0/0/0
description Sample IGMP Interface Configuration for SSM-Mapping Example
ip address 10.20.1.2 255.0.0.0
ip pim sparse-mode
ip igmp last-member-query-interval 100
ip igmp static-group 232.1.2.1 source ssm-map
ip igmp version 3
ip igmp explicit-tracking
ip igmp limit 2
ip igmp v3lite
ip urd
!
.
.
.
!
ip pim ssm default
!
access-list 10 permit 232.1.2.10
access-list 11 permit 232.1.2.0 0.0.0.255
!
This table describes the significant commands shown in the SSM mapping configuration example.
Command Description
no ip domain lookup Disables IP DNS-based hostname-to-address
translation.
Note The no ip domain-list command is shown
in the configuration only to demonstrate that
disabling IP DNS-based hostname-to-address
translation does not conflict with configuring
SSM mapping. If this command is enabled,
the Cisco IOS XE software will try to resolve
unknown strings as hostnames.
ip domain multicast ssm-map.cisco.com Specifies ssm-map.cisco.com as the domain prefix
for SSM mapping.
ip igmp ssm-map static 10 172.16.8.10 Configures the groups permitted by ACL 10 to use
source address 172.16.8.10.
• In this example, ACL 10 permits all groups in
the 232.1.2.0/25 range except 232.1.2.10.
ip igmp ssm-map static 11 172.16.8.11 Configures the groups permitted by ACL 11 to use
source address 172.16.8.11.
• In this example, ACL 11 permits group
232.1.2.10.
ip igmp last-member-query-interval 100 Reduces the leave latency for IGMPv2 hosts.
Note This command is not required for
configuring SSM mapping; however,
configuring this command can be beneficial
for IGMPv2 hosts relying on SSM mapping.
Command Description
ip igmp static-group 232.1.2.1 source ssm-map Configures SSM mapping to be used to determine the
sources associated with group 232.1.2.1. The resulting
(S, G) channels are statically forwarded.
access-list 10 permit 232.1.2.10 access-list 11 Configures the ACLs to be used for static SSM
permit 232.1.2.0 0.0.0.255 mapping.
Note These are the ACLs that are referenced by
the ip igmp ssm-map static commands in
this configuration example.
Note Network Registrar version 8.0 and later support import BIND 8 format definitions.
Additional References
Related Documents
Cisco IOS IP multicast commands: complete Cisco IOS IP Multicast Command Reference
command syntax, command mode, defaults, command
history, usage guidelines, and examples
Standards
Standards Title
No new or modified standards are supported by this --
feature, and support for existing standards has not
been modified by this feature.
MIBs
RFCs
RFCs Title
RFC 2365 Administratively Scoped IP Multicast
Technical Assistance
Description Link
The Cisco Support website provides extensive online http://www.cisco.com/cisco/web/support/index.html
resources, including documentation and tools for
troubleshooting and resolving technical issues with
Cisco products and technologies.
To receive security and technical information about
your products, you can subscribe to various services,
such as the Product Alert Tool (accessed from Field
Notices), the Cisco Technical Services Newsletter,
and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website
requires a Cisco.com user ID and password.
IGMP Snooping
Multicast traffic becomes flooded because a device usually learns MAC addresses by looking into the source
address field of all the frames that it receives. A multicast MAC address is never used as the source address
for a packet. Such addresses do not appear in the MAC address table, and the device has no method for learning
them.
IP Multicast Internet Group Management Protocol (IGMP), which runs at Layer 3 on a multicast device,
generates Layer 3 IGMP queries in subnets where the multicast traffic must be routed. IGMP (on a device)
sends out periodic general IGMP queries.
IGMP Snooping is an Ethernet Virtual Circuit (EVC)-based feature set. EVC decouples the concept of VLAN
and broadcast domain. An EVC is an end-to-end representation of a single instance of a Layer 2 service being
offered by a provider. In the Cisco EVC framework, bridge domains are made up of one or more Layer 2
interfaces known as service instances. A service instance is the instantiation of an EVC on a given port on a
given device. A service instance is associated with a bridge domain based on the configuration.
Traditionally, a VLAN is a broadcast domain, and physical ports are assigned to VLANs as access ports; the
VLAN tag in a packet received by a trunk port is the same number as the internal VLAN broadcast domain.
With EVC, an Ethernet Flow Point (EFP) is configured and associated with a broadcast domain. The VLAN
tag is used to identify the EFP only and is no longer used to identify the broadcast domain.
When you enable EVC-based IGMP snooping on a bridge domain, the bridge domain interface responds at
Layer 2 to the IGMP queries with only one IGMP join request per Layer 2 multicast group. Each bridge
domain represents a Layer 2 broadcast domain. The bridge domain interface creates one entry per subnet in
the Layer 2 forwarding table for each Layer 2 multicast group from which it receives an IGMP join request.
All hosts interested in this multicast traffic send IGMP join requests and are added to the forwarding table
entry. During a Layer 2 lookup on a bridge domain to which the bridge domain interface belongs, the bridge
domain forwards the packets to the correct EFP. When the bridge domain interface hears the IGMP Leave
group message from a host, it removes the table entry of the host.
Layer 2 multicast groups learned through IGMP snooping are dynamic. However, you can statically configure
Layer 2 multicast groups. If you specify group membership for a multicast group address statically, your static
setting supersedes any automatic manipulation by IGMP snooping. Multicast group membership lists can
consist of both user-defined and IGMP snooping-learned-settings.
• If IGMP snooping is configured on a Bridge Domain with OTV enabled, then the IGMP snooping
process limits the multicast traffic. In this scenario, the snooping tables are populated.
• If IGMP snooping is configured on a Bridge Domain without OTV, the IGMP snooping process does
not limit multicast traffic. In this scenario, the snooping tables are not populated and the multicast traffic
floods the entire VLAN.
1. enable
2. configure terminal
3. ip igmp snooping
4. bridge-domain bridge-id
5. ip igmp snooping
6. end
DETAILED STEPS
Example:
Device# configure terminal
Step 3 ip igmp snooping Globally enables IGMP snooping after it has been disabled.
Example:
Device(config)# ip igmp snooping
Example:
Device(config)# bridge-domain 100
Step 5 ip igmp snooping (Optional) Enables IGMP snooping on the bridge domain
interface being configured.
Example: • Required only if IGMP snooping was previously
Device(config-bdomain)# ip igmp snooping
explicitly disabled on the specified bridge domain.
Example:
Device(config-bdomain)# end
SUMMARY STEPS
1. enable
2. configure terminal
3. ip igmp snooping robustness-variable variable
4. ip igmp snooping tcn query solicit
5. ip igmp snooping tcn flood query count count
6. ip igmp snooping report-suppression
7. ip igmp snooping explicit-tracking-limit limit
8. ip igmp snooping last-member-query-count count
9. ip igmp snooping last-member-query-interval interval
10. ip igmp snooping check { ttl | rtr-alert-option }
11. exit
DETAILED STEPS
Example:
Device# configure terminal
Step 3 ip igmp snooping robustness-variable variable (Optional) Configures IGMP snooping robustness
variable.
Example:
Device(config)# ip igmp snooping
robustness-variable 3
Step 4 ip igmp snooping tcn query solicit (Optional) Enables device to send TCN query solicitation
even if it is not the spanning-tree root.
Example:
Device(config)# ip igmp snooping tcn query solicit
Step 5 ip igmp snooping tcn flood query count count (Optional) Configures the TCN flood query count for
IGMP snooping.
Example:
Device(config)# ip igmp snooping tcn flood query
count 4
Step 7 ip igmp snooping explicit-tracking-limit limit (Optional) Limits the number of reports in the IGMP
snooping explicit-tracking database.
Example:
Device(config)# ip igmp snooping
explicit-tracking-limit 200
Step 8 ip igmp snooping last-member-query-count count (Optional) Configures how often Internet Group
Management Protocol (IGMP) snooping will send query
Example: messages in response to receiving an IGMP leave
Device (config)# ip igmp snooping message. The default is 2 milliseconds.
last-member-query-count 5
Step 9 ip igmp snooping last-member-query-interval interval (Optional) Configures the length of time after which the
group record is deleted if no reports are received. The
Example: default is 1000 milliseconds.
Device (config)# ip igmp snooping
last-member-query-interval 200
Step 10 ip igmp snooping check { ttl | rtr-alert-option } (Optional) Enforces IGMP snooping check.
Example:
Device (config)# ip igmp snooping check ttl
SUMMARY STEPS
1. enable
2. configure terminal
3. bridge-domain bridge-id
4. ip igmp snooping immediate-leave
5. ip igmp snooping robustness-variable variable
6. ip igmp snooping report-suppression
7. ip igmp snooping explicit-tracking
8. ip igmp snooping explicit-tracking-limit limit
9. ip igmp snooping last-member-query-count count
10. ip igmp snooping last-member-query-interval interval
11. ip igmp snooping access-group {acl-number | acl-name}
12. ip igmp snooping limit num [except {acl-number | acl-name}]
13. ip igmp snooping minimum-version {2 | 3}
14. ip igmp snooping check { ttl | rtr-alert-option }
15. ip igmp snooping static source source-address interface port-type port-number
16. end
DETAILED STEPS
Example:
Device# configure terminal
Example:
Device(config)# bridge-domain 100
Step 6 ip igmp snooping report-suppression (Optional) Enables report suppression for all hosts on
the bridge domain interface.
Example:
Device(config-bdomain)# ip igmp snooping
report-suppression
Step 7 ip igmp snooping explicit-tracking (Optional) Enables IGMP snooping explicit tracking.
Explicit tracking is enabled by default.
Example:
Device(config-bdomain)# ip igmp snooping
explicit-tracking
Step 8 ip igmp snooping explicit-tracking-limit limit (Optional) Limits the number of reports in the IGMP
snooping explicit-tracking database.
Example:
Device(config-bdomain)# ip igmp snooping
explicit-tracking-limit 200
Step 9 ip igmp snooping last-member-query-count count (Optional) Configures the interval for snooping query
messages sent in response to receiving an IGMP leave
Example: message. The default is 2 milliseconds.
Device(config-bdomain)# ip igmp snooping
last-member-query-count 5 Note When both immediate-leave processing and
the query count are configured, fast-leave
processing takes precedence.
Step 10 ip igmp snooping last-member-query-interval interval (Optional) Configures the length of time after which
the group record is deleted if no reports are received.
Example: The default is 1000 milliseconds.
Device(config-bdomain)# ip igmp snooping
last-member-query-interval 2000
Step 11 ip igmp snooping access-group {acl-number | acl-name} Configures ACL-based filtering on a bridge domain.
Example:
Device(config-bdomain)# ip igmp snooping
access-group 1300
Example:
Device(config-bdomain)# ip igmp snooping 4400 except
test1
Example:
Device(config-bdomain)# ip igmp snooping
minimum-version 2
Step 14 ip igmp snooping check { ttl | rtr-alert-option } (Optional) Enforces IGMP snooping check.
Example:
Device(config-bdomain)# ip igmp snooping check ttl
Step 15 ip igmp snooping static source source-address interface (Optional) Configures a host statically for a Layer 2
port-type port-number LAN port.
Example:
Device(config-bdomain)# ip igmp snooping static
source 192.0.2.1 interface gigbitethernet 1/1/1
Example:
Device(config-bdomain)# end
Configuring an EFP
Perform this task to configure IGMP snooping features on an EFP.
SUMMARY STEPS
1. enable
2. configure terminal
3. router-guard ip multicast efps
4. interface type number
5. service instance id ethernet
6. router-guard multicast
7. ip igmp snooping tcn flood
8. ip igmp snooping access-group {acl-number | acl-name}
9. ip igmp snooping limit num [except {acl-number | acl-name}]
10. end
DETAILED STEPS
Example:
Device# configure terminal
Step 3 router-guard ip multicast efps (Optional) Enables the router guard for all EFPs.
Example:
Device(config)# router-guard ip multicast efps
Step 4 interface type number (Optional) Specifies the bridge domain interface to
be configured.
Example:
Device(config)# interface BDI100
Example:
Device(config-if-srv)# router-guard multicast
Step 7 ip igmp snooping tcn flood (Optional) Disables TCN flooding on an EFP. TCN
flooding is enabled by default.
Example:
Device(config-if-srv)# no ip igmp snooping tcn flood
Step 8 ip igmp snooping access-group {acl-number | acl-name} (Optional) Configures ACL-based filtering on an
EFP.
Example:
Device(config-if-srv)# ip igmp snooping access-group
44
Step 9 ip igmp snooping limit num [except {acl-number | (Optional) Limits the number of IGMP groups or
acl-name}] channels allowed on an EFP.
Example:
Device(config-if-srv)# ip igmp snooping limit 1300
except test1
Example:
Device(config-if-srv)# end
1. enable
2. show igmp snooping [count [bd bd-id]]
3. show igmp snooping groups bd bd-id [ count | ip-address [verbose] [hosts | sources | summary ]]
4. show igmp snooping membership bd bd-id
5. show igmp snooping mrouter [bd bd-id]
6. show igmp snooping counters [bd bd-id]
DETAILED STEPS
Step 2 show igmp snooping [count [bd bd-id]] Displays configuration for IGMP snooping, globally
or by bridge domain.
Example:
Device(config)# show igmp snooping
Step 3 show igmp snooping groups bd bd-id [ count | ip-address Displays snooping information for groups by bridge
[verbose] [hosts | sources | summary ]] domain.
Example:
Device(config)# show igmp snooping groups bd 100
Step 4 show igmp snooping membership bd bd-id Displays IGMPv3 host membership information.
Example:
Device(config)# show igmp snooping membership bd 100
Step 5 show igmp snooping mrouter [bd bd-id] Displays multicast ports, globally or by bridge
domain.
Example:
Device(config)# show igmp snooping mrouter
Step 6 show igmp snooping counters [bd bd-id] Displays IGMP snooping counters, globally or by
bridge domain.
Example:
Device(config)# show snooping counters
Additional References
Related Documents
Configuring the ASR 1000 series router Cisco ASR 1000 Series
Aggregation Services Routers
Configuration Guides
Technical Assistance
Description Link
The Cisco Support and Documentation website http://www.cisco.com/cisco/web/support/index.html
provides online resources to download documentation,
software, and tools. Use these resources to install and
configure the software and to troubleshoot and resolve
technical issues with Cisco products and technologies.
Access to most tools on the Cisco Support and
Documentation website requires a Cisco.com user ID
and password.
The Layer 2 switches are designed so that several destination MAC addresses could be assigned to a single
physical port. This design allows switches to be connected in a hierarchy and also allows many multicast
destination addresses to be forwarded out a single port.
The device port also is added to the entry for the multicast group. Multicast device must listen to all multicast
traffic for every group because IGMP control messages are also sent as multicast traffic. The rest of the
multicast traffic is forwarded using the CAM table with the new entries created by CGMP.
IGMP Snooping
IGMP snooping is an IP multicast constraining mechanism that runs on a Layer 2 LAN switch. IGMP snooping
requires the LAN switch to examine, or “snoop,” some Layer 3 information (IGMP Join/Leave messages) in
the IGMP packets sent between the hosts and the router. When the switch receives the IGMP host report from
a host for a particular multicast group, the switch adds the port number of the host to the associated multicast
table entry. When the switch hears the IGMP Leave group message from a host, the switch removes the table
entry of the host.
Because IGMP control messages are sent as multicast packets, they are indistinguishable from multicast data
at Layer 2. A switch running IGMP snooping must examine every multicast data packet to determine if it
contains any pertinent IGMP control information. IGMP snooping implemented on a low-end switch with a
slow CPU could have a severe performance impact when data is sent at high rates. The solution is to implement
IGMP snooping on high-end switches with special application-specific integrated circuits (ASICs) that can
perform the IGMP checks in hardware. CGMP is a better option for low-end switches without special hardware.
Enabling CGMP
CGMP is a protocol used on devices connected to Catalyst switches to perform tasks similar to those performed
by IGMP. CGMP is necessary because the Catalyst switch cannot distinguish between IP multicast data
packets and IGMP report messages, which are both at the MAC level and are addressed to the same group
address.
Note • CGMP should be enabled only on 802 or ATM media, or LAN emulation (LANE) over ATM.
• CGMP should be enabled only on devices connected to Catalyst switches.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip cgmp [proxy | router-only]
5. end
6. clear ip cgmp [interface-type interface-number]
DETAILED STEPS
Example:
Device# configure terminal
Step 3 interface type number Selects an interface that is connected to hosts on which IGMPv3 can
be enabled.
Example:
Device(config)# interface ethernet 1
Step 4 ip cgmp [proxy | router-only] Enables CGMP on an interface of a device connected to a Cisco
Catalyst 5000 family switch.
Example: • The proxy keyword enables the CGMP proxy function. When
Device(config-if)# ip cgmp proxy enabled, any device that is not CGMP-capable will be advertised
by the proxy router. The proxy router advertises the existence
of other non-CGMP-capable devices by sending a CGMP Join
message with the MAC address of the non-CGMP-capable device
and group address of 0000.0000.0000.
Step 5 end Ends the current configuration session and returns to EXEC mode.
Example:
Device(config-if)# end
Step 6 clear ip cgmp [interface-type (Optional) Clears all group entries from the caches of Catalyst switches.
interface-number]
Example:
Device# clear ip cgmp
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip rgmp
5. end
6. debug ip rgmp
7. show ip igmp interface
DETAILED STEPS
Example:
Device# configure terminal
Example:
Device(config)# interface ethernet 1
Step 5 end Ends the current configuration session and returns to EXEC
mode.
Example:
Device(config-if)# end
interface GigabitEthernet1
ip address 192.168.50.11 255.255.255.0
ip pim dense-mode
ip cgmp
ip multicast-routing
ip pim sparse-mode
interface ethernet 0
ip rgmp
Additional References
The following sections provide references related to constraining IP multicast in a switched Ethernet network.
Related Documents
MIBs
Technical Assistance
Description Link
Technical Assistance Center (TAC) home page, http://www.cisco.com/public/support/tac/home.shtml
containing 30,000 pages of searchable technical
content, including links to products, technologies,
solutions, technical tips, and tools. Registered
Cisco.com users can log in from this page to access
even more content.
• IP multicast
• PIM in sparse mode, sparse-dense mode, source specific mode, or bidirectional mode
If your router is in a bidirectional group, make sure to enable RGMP only on interfaces that do not function
as a designated forwarder (DF). If you enable RGMP on an interface that functions as a DF, the interface will
not forward multicast packets up the bidirectional shared tree to the rendezvous point (RP).
You must have the following features enabled on your switch:
• IP multicast
• IGMP snooping
Note Refer to the Catalyst switch software documentation for RGMP switch configuration tasks and command
information.
The figure shows where these protocols operate within the IP multicast environment.
Note CGMP and RGMP cannot interoperate on the same switched network. If RGMP is enabled on a switch
or router interface, CGMP is automatically disabled on that switch or router interface; if CGMP is enabled
on a switch or router interface, RGMP is automatically disabled on that switch or router interface.
RGMP Overview
RGMP enables a router to communicate to a switch the IP multicast group for which the router would like to
receive or forward traffic. RGMP is designed for switched Ethernet backbone networks running PIM sparse
mode (PIM-SM) or sparse-dense mode.
Note RGMP-enabled switches and router interfaces in a switched network support directly connected,
multicast-enabled hosts that receive multicast traffic. RGMP-enabled switches and router interfaces in a
switched network do not support directly connected, multicast-enabled hosts that source multicast traffic.
A multicast-enabled host can be a PC, a workstation, or a multicast application running in a router.
The figure shows a switched Ethernet backbone network running PIM in sparse mode, RGMP, and IGMP
snooping.
In the figure, the sources for the two different multicast groups (the source for group A and the source for
group B) send traffic into the same switched network. Without RGMP, traffic from source A is unnecessarily
flooded from switch A to switch B, then to router B and router D. Also, traffic from source B is unnecessarily
flooded from switch B to switch A, then to router A and router C. With RGMP enabled on all routers and
switches in this network, traffic from source A would not flood router B and router D. Also, traffic from
source B would not flood router A and router C. Traffic from both sources would still flood the link between
switch A and switch B. Flooding over this link would still occur because RGMP does not restrict traffic on
links toward other RGMP-enabled switches with routers behind them.
By restricting unwanted multicast traffic in a switched network, RGMP increases the available bandwidth for
all other multicast traffic in the network and saves the processing resources of the routers.
The figure shows the RGMP messages sent between an RGMP-enabled router and an RGMP-enabled switch.
The router sends simultaneous PIM hello (or a PIM query message if PIM Version 1 is configured) and RGMP
hello messages to the switch. The PIM hello message is used to locate neighboring PIM routers. The RGMP
hello message instructs the switch to restrict all multicast traffic on the interface from which the switch received
the RGMP hello message.
Note RGMP messages are sent to the multicast address 224.0.0.25, which is the local-link multicast address
reserved by the Internet Assigned Numbers Authority (IANA) for sending IP multicast traffic from routers
to switches. If RGMP is not enabled on both the router and the switch, the switch automatically forwards
all multicast traffic out the interface from which the switch received the PIM hello message.
The router sends the switch an RGMP join <G> message (where G is the multicast group address) when the
router wants to receive traffic for a specific multicast group. The RGMP join message instructs the switch to
forward multicast traffic for group <G> out the interface from which the switch received the RGMP hello
message.
Note The router sends the switch an RGMP join <G> message for a multicast group even if the router is only
forwarding traffic for the multicast group into a switched network. By joining a specific multicast group,
the router can determine if another router is also forwarding traffic for the multicast group into the same
switched network. If two routers are forwarding traffic for a specific multicast group into the same switched
network, the two routers use the PIM assert mechanism to determine which router should continue
forwarding the multicast traffic into the network.
The router sends the switch an RGMP leave <G> message when the router wants to stop receiving traffic for
a specific multicast group. The RGMP leave message instructs the switch to stop forwarding the multicast
traffic on the port from which the switch received the PIM and RGMP hello messages.
Note An RGMP-enabled router cannot send an RGMP leave <G> message until the router does not receive or
forward traffic from any source for a specific multicast group (if multiple sources exist for a specific
multicast group).
The router sends the switch an RGMP bye message when RGMP is disabled on the router. The RGMP bye
message instructs the switch to forward the router all IP multicast traffic on the port from which the switch
received the PIM and RGMP hello messages, as long as the switch continues to receive PIM hello messages
on the port.
Enabling RGMP
To enable RGMP, use the following commands on all routers in your network beginning in global configuration
mode:
Note CGMP and RGMP cannot interoperate on the same switched network. If RGMP is enabled on a switch
or router interface, CGMP is automatically disabled on that switch or router interface; if CGMP is enabled
on a switch or router interface, RGMP is automatically disabled on that switch or router interface.
SUMMARY STEPS
DETAILED STEPS
What to Do Next
See the "RGMP_Configuration_Example" section for an example of how to configure RGMP.
Note If RGMP is not enabled on an interface, no RGMP information is displayed in the show ip igmp interface
command output for that interface.
Command Purpose
Logs debug messages sent by an RGMP-enabled
Router# debug ip rgmp
router.
Using the command without arguments logs RGMP
Join <G> and RGMP leave <G> messages for all
multicast groups configured on the router. Using the
command with arguments logs RGMP join <G> and
RGMP leave <G> messages for the specified group.
The figure shows the debug messages that are logged by an RGMP-enabled router as the router sends RGMP
join <G> and RGMP leave <G> messages to an RGMP-enabled switch.
Router A Configuration
ip routing
ip multicast-routing distributed
interface gigabitethernet 1/0/0
ip address 10.0.0.1 255.0.0.0
ip pim sparse-dense-mode
no shutdown
interface gigabitethernet 1/1/0
ip address 10.1.0.1 255.0.0.0
ip pim sparse-dense-mode
ip rgmp
no shutdown
Router B Configuration
ip routing
ip multicast-routing distributed
interface gigabitethernet 1/0/0
ip address 10.2.0.1 255.0.0.0
ip pim sparse-dense-mode
no shutdown
Router C Configuration
ip routing
ip multicast-routing distributed
interface gigabitethernet 1/0/0
ip address 10.4.0.1 255.0.0.0
ip pim sparse-dense-mode
no shutdown
interface gigabitethernet 1/1/0
ip address 10.5.0.1 255.0.0.0
ip pim sparse-dense-mode
ip rgmp
no shutdown
Router D Configuration
ip routing
ip multicast-routing distributed
interface gigabitethernet 1/0/0
ip address 10.6.0.1 255.0.0.0
ip pim sparse-dense-mode
no shutdown
interface gigabitethernet 1/1/0
ip address 10.7.0.1 255.0.0.0
ip pim sparse-dense-mode
ip rgmp
no shutdown
Switch A Configuration
Switch B Configuration
Additional References
The following sections provide references related to RGMP.
Related Documents
IP multicast commands: complete command syntax, Cisco IOS IP Multicast Command Reference
command mode, defaults, command history, usage
guidelines, and examples
Standards
Standard Title
No new or modified standards are supported by this --
feature, and support for existing standards has not
been modified by this feature.
MIBs
RFCs
RFC Title
No new or modified RFCs are supported by this --
feature, and support for existing standards has not
been modified by this feature.
Technical Assistance
Description Link
The Cisco Support website provides extensive online http://www.cisco.com/techsupport
resources, including documentation and tools for
troubleshooting and resolving technical issues with
Cisco products and technologies.
To receive security and technical information about
your products, you can subscribe to various services,
such as the Product Alert Tool (accessed from Field
Notices), the Cisco Technical Services Newsletter,
and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website
requires a Cisco.com user ID and password.
UDLR Overview
Both unicast and multicast routing protocols forward data on interfaces from which they have received routing
control information. This model requires a bidirectional link. However, some network links are unidirectional.
For networks that are unidirectional (such as broadcast satellite links), a method of communication that allows
for control information to operate in a unidirectional environment is necessary. (Note that IGMP is not a
routing protocol.)
Specifically, in unicast routing, when a router receives an update message on an interface for a prefix, it
forwards data for destinations that match that prefix out that same interface. This is the case in distance vector
routing protocols. Similarly, in multicast routing, when a router receives a Join message for a multicast group
on an interface, it forwards copies of data destined for that group out that same interface. Based on these
principles, unicast and multicast routing protocols cannot be supported over UDLs without the use of UDLR.
UDLR is designed to enable the operation of routing protocols over UDLs without changing the routing
protocols themselves.
UDLR enables a router to emulate the behavior of a bidirectional link for IP operations over UDLs. UDLR
has three complementary mechanisms for bidirectional link emulation, which are described in the following
sections:
• UDLR Tunnel--A mechanism for routing unicast and multicast traffic.
• Internet Group Management Protocol (IGMP) UDLR--Mechanism for routing multicast traffic. This
method scales well for many broadcast satellite links.
• IGMP Proxy--Mechanism for routing multicast traffic.
You can use each mechanism independently or in conjunction with the others. IGMP proxy is described in
the “ Customizing IGMP ” module.
UDLR Tunnel
The UDLR tunnel mechanism enables IP and its associated unicast and multicast routing protocols to treat
the unidirectional link (UDL) as being logically bidirectional. A packet that is destined on a receive-only
interface is picked up by the UDLR tunnel mechanism and sent to an upstream router using a generic routing
encapsulation (GRE) tunnel. The control traffic flows in the opposite direction of the user data flow. When
the upstream router receives this packet, the UDLR tunnel mechanism makes it appear that the packet was
received on a send-only interface on the UDL.
The purpose of the unidirectional GRE tunnel is to move control packets from a downstream node to an
upstream node. The one-way tunnel is mapped to a one-way interface (that goes in the opposite direction).
Mapping is performed at the link layer, so the one-way interface appears bidirectional. When the upstream
node receives packets over the tunnel, it must make the upper-layer protocols act as if the packets were received
on the send-capable UDL.
A UDLR tunnel supports the following functionality:
• Address Resolution Protocol (ARP) and Next Hop Resolution Protocol (NHRP) over a UDL
• Emulation of bidirectional links for all IP traffic (as opposed to only control-only broadcast/multicast
traffic)
• Support for IP GRE multipoint at a receive-only tunnel
Note A UDL router can have many routing peers (for example, routers interconnected via a broadcast satellite
link). As with bidirectional links, the number of peer routers a router has must be kept relatively small to
limit the volume of routing updates that must be processed. For multicast operation, we recommend using
the IGMP UDLR mechanism when interconnecting more than 20 routers.
IGMP UDLR
In addition to a UDLR tunnel, another mechanism that enables support of multicast routing protocols over
UDLs is using IP multicast routing with IGMP, which accommodates UDLR. This mechanism scales well
for many broadcast satellite links.
With IGMP UDLR, an upstream router sends periodic queries for members on the UDL. The queries include
a unicast address of the router that is not the unicast address of the unidirectional interface. The downstream
routers forward IGMP reports received from directly connected members (on interfaces configured to helper
forward IGMP reports) to the upstream router. The upstream router adds the unidirectional interface to the
(*, G) outgoing interface list, thereby enabling multicast packets to be forwarded down the UDL.
In a large enterprise network, it is not possible to be able to receive IP multicast traffic via satellite and forward
the traffic throughout the network. This limitation exists because receiving hosts must be directly connected
to the downstream router. However, you can use the IGMP proxy mechanism to overcome this limitation.
Refer to the “ Customizing IGMP ” module for more information on this mechanism.
• On the upstream router, where the UDL can only send, you must configure the tunnel to receive. When
packets are received over the tunnel, the upper-layer protocols treat the packet as though it is received
over the unidirectional, send-only interface.
• On the downstream router, where the UDL can only receive, you must configure the tunnel to send.
When packets are sent by upper-layer protocols over the interface, they will be redirected and sent over
this GRE tunnel.
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. interface tunnel number
5. tunnel udlr receive-only type number
6. tunnel source {ip-address | type number}
7. tunnel destination {hostname| ip-address}
8. Move to the downstream router.
9. enable
10. configure terminal
11. interface type number
12. interface tunnel number
13. tunnel udlr send-only type number
14. tunnel source {ip-address | type number}
15. tunnel destination {hostname| ip-address}
16. tunnel udlr address-resolution
DETAILED STEPS
Example:
Router# configure terminal
Example:
Router(config)# interface gigabitethernet 0/0/0
Example:
Router(config-if)# interface tunnel 0
Step 5 tunnel udlr receive-only type number Configures the UDLR tunnel.
• Use the same type and number values as the
Example: unidirectional send-only interface type and number
Router(config-if)# tunnel udlr receive-only values specified with the interface type number
fastethernet 0/0/0 command in Step 3.
Step 6 tunnel source {ip-address | type number} Configures the tunnel source.
Example:
Router(config-if)# tunnel source 10.3.4.5
Example:
Router(config-if)# tunnel destination 10.8.2.3
Example:
Router# configure terminal
Example:
Router(config)# interface gigabitethernet 0/0/0
Example:
Router(config-if)# interface tunnel 0
Step 13 tunnel udlr send-only type number Configures the UDLR tunnel.
• Use the same type and number values as the
Example: unidirectional receive-only interface type and
Router(config-if)# tunnel udlr send-only ethernet number values specified with the interface type
0 number command in Step 3.
Step 14 tunnel source {ip-address | type number} Configures the tunnel source.
Example:
Router(config-if)# tunnel source 11.8.2.3
Example:
Router(config-if)# tunnel destination 10.3.4.5
Step 16 tunnel udlr address-resolution Enables the forwarding of ARP and NHRP.
Example:
Router(config-if)# tunnel udlr address-resolution
SUMMARY STEPS
1. enable
2. configure terminal
3. interface type number
4. ip igmp unidirectional-link
5. Move to the downstream router.
6. enable
7. configure terminal
8. ip multicast default-rpf-distance distance
9. interface type number
10. ip igmp unidirectional-link
11. ip igmp helper-address udl type number
12. exit
13. show ip igmp udlr [group-name| group-address | type number]
DETAILED STEPS
Example:
Router# configure terminal
Example:
Router(config)# interface gigabitethernet
0/1/1
Example:
Router(config-if)# ip igmp
unidirectional-link
Example:
Router# configure terminal
Step 8 ip multicast default-rpf-distance distance (Optional) Sets the distance for the default RPF interface.
By default, the distance for the default reverse path forwarding
Example: (RPF) interface is 15. Any explicit sources learned by routing
Router# ip multicast default-rpf-distance protocols will take preference if their distance is less than the
10 distance configured by the ip multicast default-rpf-distance
command. Use this command on downstream routers if you want
some sources to use RPF to reach the UDLR link and others to
use the terrestrial paths.
• If you want IGMP to prefer the UDL, set the distance to be
less than the distances of the unicast routing protocols.
• If you want IGMP to prefer the non-UDL, set the distance
to be greater than the distances of the unicast routing
protocols.
Example:
Router(config)# interface gigabitethernet
0/0/0
Example:
Router(config-if)# ip igmp
unidirectional-link
Step 11 ip igmp helper-address udl type number Configures the interface to be an IGMP helper.
• Use this command on every downstream router, on every
Example: interface to specify the type and number values that identify
Router(config-if)# ip igmp helper-address the UDL interface.
udl ethernet 0
Example:
Router(config-if)# exit
Step 13 show ip igmp udlr [group-name| group-address (Optional) Displays UDLR information for directly connected
| type number] multicast groups on interfaces that have a UDL helper address
configured.
Example:
Router(config)# show ip igmp udlr
Router A Configuration
ip multicast-routing
!
! Serial0/0/0 has send-only capability
!
interface serial 0/0/0
encapsulation hdlc
ip address 10.1.0.1 255.255.0.0
ip pim sparse-dense-mode
!
! Configure tunnel as receive-only UDLR tunnel.
!
interface tunnel 0
tunnel source 10.20.0.1
tunnel destination 10.41.0.2
tunnel udlr receive-only serial 0/0/0
!
! Configure OSPF.
!
router ospf
network 10.0.0.0 0.255.255.255 area 0
Router B Configuration
ip multicast-routing
!
! Serial1 has receive-only capability
!
interface serial 1/0/0
encapsulation hdlc
ip address 10.1.0.2 255.255.0.0
ip pim sparse-dense-mode
!
! Configure tunnel as send-only UDLR tunnel.
!
interface tunnel 0
tunnel source 10.41.0.2
tunnel destination 10.20.0.1
tunnel udlr send-only serial 1/0/0
tunnel udlr address-resolution
!
! Configure OSPF.
!
router ospf
network 10.0.0.0 0.255.255.255 area 0
Note Configuring PIM on the back channel interfaces on the uplink router and downlink router is optional.
All routers on a UDL must have the same subnet address. If all routers on a UDL cannot have the same subnet
address, the upstream router must be configured with secondary addresses to match all the subnets that the
downstream routers are attached to.
ip multicast-routing
!
! Interface that source is attached to
!
interface gigabitethernet 0/0/0
description Typical IP multicast enabled interface
ip address 12.0.0.1 255.0.0.0
ip pim sparse-dense-mode
!
! Back channel
!
interface gigabitethernet 1/0/0
description Back channel which has connectivity to downlink-rtr
ip address 11.0.0.1 255.0.0.0
ip pim sparse-dense-mode
!
! Unidirectional link
!
interface serial 0/0/0
description Unidirectional to downlink-rtr
ip address 10.0.0.1 255.0.0.0
ip pim sparse-dense-mode
ip igmp unidirectional-link
no keepalive
ip multicast-routing
!
! Interface that receiver is attached to, configure for IGMP reports to be
! helpered for the unidirectional interface.
!
interface gigabitethernet 0/0/0
description Typical IP multicast-enabled interface
ip address 14.0.0.2 255.0.0.0
ip pim sparse-dense-mode
ip igmp helper-address udl serial 0/0/0
!
! Back channel
!
interface gigabitethernet 1/0/0
description Back channel that has connectivity to downlink-rtr
ip address 13.0.0.2 255.0.0.0
ip pim sparse-dense-mode
!
! Unidirectional link
!
interface serial 0/0/0
description Unidirectional to uplink-rtr
ip address 10.0.0.2 255.0.0.0
ip pim sparse-dense-mode
ip igmp unidirectional-link
no keepalive
Upstream Configuration
ip multicast-routing
!
interface Tunnel0
ip address 9.1.89.97 255.255.255.252
no ip directed-broadcast
tunnel source 9.1.89.97
tunnel mode gre multipoint
tunnel key 5
tunnel udlr receive-only GigabitEthernet2/3/0
!
interface GigabitEthernet2/0/0
no ip address
shutdown
!
! user network
interface GigabitEthernet2/1/0
ip address 9.1.89.1 255.255.255.240
no ip directed-broadcast
ip pim dense-mode
ip cgmp
fair-queue 64 256 128
no cdp enable
ip rsvp bandwidth 1000 100
!
interface GigabitEthernet2/2/0
ip address 9.1.95.1 255.255.255.240
no ip directed-broadcast
!
! physical send-only interface
interface GigabitEthernet2/3/0
Downstream Configuration
ip multicast-routing
!
interface Loopback0
ip address 9.1.90.161 255.255.255.252
ip pim sparse-mode
ip igmp helper-address udl GigabitEthernet2/3/0
ip igmp proxy-service
!
interface Tunnel0
ip address 9.1.90.97 255.255.255.252
ip access-group 120 out
no ip directed-broadcast
no ip mroute-cache
tunnel source 9.1.90.97
tunnel destination 9.1.89.97
tunnel key 5
tunnel udlr send-only GigabitEthernet2/3/0
tunnel udlr address-resolution
!
interface GigabitEthernet2/0/0
no ip address
no ip directed-broadcast
shutdown
no cdp enable
!
! user network
interface GigabitEthernet2/1/0
ip address 9.1.90.1 255.255.255.240
no ip directed-broadcast
ip pim sparse-mode
ip igmp mroute-proxy Loopback0
no cdp enable
!
! Backchannel
interface GigabitEthernet2/2/0
ip address 9.1.95.3 255.255.255.240
no ip directed-broadcast
no cdp enable
!
! physical receive-only interface
interface GigabitEthernet2/3/0
ip address 9.1.92.99 255.255.255.240
no ip directed-broadcast
ip pim sparse-mode
ip igmp unidirectional-link
no keepalive
no cdp enable
!
router ospf 1
network 9.1.90.0 0.0.0.255 area 1
network 9.1.92.96 0.0.0.15 area 1
!
ip classless
ip route 0.0.0.0 0.0.0.0 9.1.95.1
Additional References
Related Documents
MIBs
Technical Assistance
Description Link
The Cisco Support website provides extensive online http://www.cisco.com/techsupport
resources, including documentation and tools for
troubleshooting and resolving technical issues with
Cisco products and technologies.
To receive security and technical information about
your products, you can subscribe to various services,
such as the Product Alert Tool (accessed from Field
Notices), the Cisco Technical Services Newsletter,
and Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website
requires a Cisco.com user ID and password.
Table 10: Feature Information for Configuring IP Multicast over Unidirectional Links