|
|
This feature module describes the Source Specific Multicast feature and includes the following sections:
Source specific multicast (SSM) is a datagram delivery model that best supports one-to-many applications, also known as broadcast applications. SSM is the core networking technology for the Cisco implementation of the IP Multicast lite suite of solutions targeted for audio and video broadcast application environments. This feature module introduces the following Cisco IOS components that support SSM:
The Cisco implementation of SSM will soon be deployed with IGMPv3 support. Cisco developed IGMP v3lite and URD to support the deployment of applications utilizing SSM services before the introduction of IGMPv3 into host operating systems.
The current IP multicast infrastructure in the Internet and many enterprise intranets is based on the PIM sparse mode (PIM SM) protocol and Multicast Source Discovery Protocol (MSDP). These protocols have proven to be reliable, extensive, and efficient. However, they are bound to the complexity and functionality limitations of the Internet Standard Multicast (ISM) service model. SSM is an incremental response to these issues associated with ISM and is intended to coexist in the network with the protocols developed for ISM. In general, SSM provides a more advantageous IP multicast service for applications that utilize SSM.
ISM service is defined in RFC 1112. This service consists of the delivery of IP datagrams from any source to a group of receivers called the multicast host group. The datagram traffic for the multicast host group consists of datagrams with an arbitrary IP unicast source address S and the multicast group address G as the IP destination address. Systems will receive this traffic by becoming members of the host group. Membership to a host group simply requires signalling the host group via any version of the IGMP.
In SSM, delivery of datagrams is based on (S, G) channels. Traffic for one (S, G) channel consists of datagrams with an IP unicast source address S and the multicast group address G as the IP destination address. Systems will receive this traffic by becoming members of the (S, G) channel. In both SSM and ISM, no signalling is required to become a source. However, in SSM, receivers must subscribe or unsubscribe to (S, G) channels to receive or not receive traffic from specific sources. In other words, receivers can only receive traffic from (S, G) channels that they are subscribed to, whereas in ISM, receivers need not know the IP addresses of sources from which they receive their traffic.
SSM can coexist with the ISM service by applying the SSM delivery model to a configured subset of the IP multicast group address range. The Internet Assigned Numbers Authority (IANA) has reserved the address range 232.0.0.0 through 232.255.255.255 for SSM applications and protocols. Cisco IOS software allows SSM configuration for an arbitrary subset of the IP multicast address range 224.0.0.0 through 239.255.255.255. When an SSM range is defined, existing IP multicast receiver applications will not receive any traffic when they try to use addresses in the SSM range (unless the application is modified to use explicit (S, G) channel subscription or is SSM enabled via URD).
An established network, in which IP multicast service is based on PIM SM, can support SSM services. SSM can also be deployed alone in a network without the full range of protocols that are required for interdomain PIM SM if only SSM service is needed. If SSM is deployed in a network already configured for PIM SM (Cisco IOS Release 12.0 or later releases is recommended), then only the last hop routers must be upgraded to a Cisco IOS Release 12.1(3)T or later release image that supports SSM. Routers that are not directly connected to receivers can run Cisco IOS Release 12.0 or later releases. In general, these nonlast hop routers must only run PIM SM in the SSM range, and may need additional access control configuration to suppress MSDP signalling, registering, or shared tree operations from occurring within the SSM range.
In Cisco IOS Release 12.1(3)T and later release, the SSM mode of operation is enabled by configuring the SSM range. This configuration has the following effects:
The host side IGMP v3lite software, called Host Side IGMP Library (HSIL), was developed for Cisco by WhiteBarn (now Talarian) and is available for free download by all Cisco customers from its Web site (www.whitebarn.com).
One part of the HSIL is a client library linked to the SSM application. It provides the SSM subset of the IGMPv3 API to the SSM application. This library uses the normal IGMPv1/v2 API toward the operating system kernel to allow receipt of multicast data by the application, and also signals the (S, G) channel subscriptions to an IGMP v3lite server process (which is also part of the HSIL). In the network, this signalling results in both (S, G) channel subscription messages generated by the IGMP v3lite server process and IGMPv1/v2 membership reports generated by the operating system. A Cisco router enabled for IGMP v3lite will correctly interpret this combination as an (S, G) channel subscription.
IGMP v3lite is supported by Cisco only via the API provided by the HSIL, not as a function of the router independent of the HSIL. By default, IGMP v3lite is disabled. When IGMP v3lite is configured on an interface, it will be active only for IP multicast addresses in the SSM range.
Because IGMP v3lite causes normal IGMPv1/v2 messages to be sent by the host, IGMP v3lite is compatible with IGMPv1/v2 snooping and Cisco Group Management Protocol (CGMP).
As soon as the last hop router intercepts both an (S, G) channel subscription encoded in a URD intercept URL and an IGMPv1/v2 membership report for the same multicast group from the receiver application, the last hop router will join toward the (S, G) channel as long as the application maintains the membership for the multicast group G. The URD intercept URL is thus only needed initially to provide the last hop router with the address of the source(s) to join to.
A URD intercept URL has the following syntax:
http://webserver:659/path?group=group&source=source1&...source=sourceN&
The webserver string is the name or IP address to which the URL is targeted. This target need not be the IP address of an existing web server. The exception to this rule is when the web server wants to recognize that the last hop router failed to support the URD mechanism. The numbers 659 indicate the URD port. Port 659 is reserved for Cisco by the IANA for the URD mechanism so that no other applications can use this port.
When the browser of a host encounters a URD intercept URL, it will try to open a TCP connection to the web server on port 659. If the last hop router is enabled for URD on the interface where the router receives the TCP packets from the host, it will intercept all packets for TCP connections destined to port 659 independent of the actual destination address of the TCP connection (for example, independent of the address of the web server). Once intercepted, the last hop router will "speak" (a very simple subset of) HTTP on this TCP connection, emulating a web server. The only HTTP request that the last hop router will understand and reply to is the following GET request:
GET argument HTTP/1.0 argument = /path?group=group&source=source1&...source=sourceN&
When it receives a GET command, the router tries to parse the argument according to this syntax to derive one or more (S, G) channel memberships. The path string of the argument is anything up to, but not including, the first question mark and is ignored. The group and source1 through sourceN strings are the IP addresses of the channels for which this argument is a subscription request. If the argument matches the syntax shown, the router interprets it to be subscriptions for the channels (source1, group) through (sourceN, group).
The router will accept the channel subscription(s) if the following conditions are met:
If the channel subscription is accepted, the router will respond to the TCP connection with the following HTML page format:
HTTP/1.1 200 OK Server:cisco IOS Content-Type:text/html <html> <body> Retrieved URL string successfully </body> </html>
If an error condition occurs, the <body> part of the returned HTML page will carry an appropriate error message. The HTML page is a by-product of the URD mechanism. This returned text may, depending on how the web pages carrying a URD intercept URL are designed, be displayed to the user or be sized so that the actual returned HTML page is invisible.
The primary effect of the URD mechanism is that the router will remember received channel subscriptions and will match them against IGMPv1/v2 group membership reports received by the host. The router will remember a URD (S, G) channel subscription for up to 3 minutes without a matching IGMPv1/v2 group membership report. As soon as the router sees that it has received both an IGMPv1/v2 group membership report for a multicast group G and a URD (S, G) channel subscription for the same group G, it will join the (S, G) channel via PIM SS. The router will then continue to join to the (S, G) channel based only on the presence of a continuing IGMPv1/v2 membership from the host. Thus, one initial URD channel subscription is all that is needed to be added via a web page to enable SSM with URD.
If the last hop router from the receiver host is not enabled for URD, then it will not intercept the HTTP connection toward the web server on port 659. This situation will result in a TCP connection to port 659 on the web server. If no further provisions on the web server are taken, then the user may see a notice (for example, "Connection refused") in the part of the web page reserved for displaying the URD intercept URL (if the web page was designed to show this output). It is also possible to let the web server listen to requests on port 659 and install a Common Gateway Interface (CGI) script that would allow the web server to know if a channel subscription failed (for example, to subsequently return more complex error descriptions to the user).
Because the router returns a Content-Type of text and HTML, the best way to include the URD intercept URL into a web page is to use a frame. By defining the size of the frame, you can also hide the URD intercept URL on the displayed page.
By default, URD is disabled on all interfaces. Because normal IGMPv1/v2 group membership reports are still sent by the application, URD is compatible with IGMPv1/v2 snooping and CGMP.
IP Multicast Address Management Not Required in SSM Range
In the ISM service, applications must acquire a unique IP multicast group address because traffic distribution is based only on the IP multicast group address used. If two applications with different sources and receivers use the same IP multicast group address, then receivers of both applications will receive traffic from the senders of both applications. Even though the receivers, if programmed appropriately, can filter out the unwanted traffic, this situation would cause generally unacceptable levels of unwanted traffic.
Allocating a unique IP multicast group address for an application is still a problem. Most short-lived applications use mechanisms like Session Description Protocol (SDP) and Session Announcement Protocol (SAP) to get a random address, a solution that does not work well with a rising number of applications in the Internet. The best current solution for long-lived applications is described in RFC 2770, which suffers from the restriction that each autonomous system (AS) is limited to only 255 usable IP multicast addresses.
In SSM, traffic from each source is forwarded between routers in the network independent of traffic from other sources. Thus different sources can reuse multicast group addresses in the SSM range.
Legacy Applications Within the SSM Range Restrictions
Existing applications in a network predating SSM will not work within the SSM range, unless they are modified to support (S, G) channel subscriptions, or are enabled via URD. Therefore, enabling SSM in a network may cause problems for existing applications if they use addresses within the designated SSM range.
Address Management Restrictions
Address management is still necessary to some degree when SSM is used with Layer 2 switching mechanisms. CGMP, IGMP snooping, or Router-Ports Group Management Protocol (RGMP) currently support only group-specific filtering, not (S, G) channel-specific filtering. If different receivers in a switched network request different (S, G) channels sharing the same group, then they will not benefit from these existing mechanisms. Instead, both receivers will receive all (S, G) channel traffic (and filter out the unwanted traffic on input). Because of the ability of SSM to reuse the group addresses in the SSM range for many independent applications, this situation can lead to less than expected traffic filtering in a switched network. Therefore, we do not recommend that you initially rely on address reusage within single-application environments. For example, an application service providing a set of television channels should, even with SSM, use a different group for each television (S, G) channel. This setup will guarantee that multiple receivers to different channels within the same application service will never experience traffic aliasing in networks operating with Layer 2 switching.
A note from the IANA about the assignment of the 232/8 address space for SSM protocols and applications can be found at the following location:
The features described in this feature module are based on the following Internet Engineering Task Force (IETF) protocol specification drafts. These documents can be found at ftp://ftpeng.cisco.com/ipmulticast/drafts.
SSM is supported on all Cisco IOS Release 12.1(3)T platforms and later releases.
Standards
No new or modified standards are supported by this feature.
MIBs
No new or modified MIBs are supported by this feature.
For descriptions of supported MIBs and how to use MIBs, see the Cisco MIB web site on CCO at http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml.
RFCs
No new or modified RFCs are supported by this feature.
See the following sections for configuration tasks for SSM. Each task in the list is identified as either optional or required.
| Command | Purpose | |
|---|---|---|
Step 1 | Router(config)#ip pim ssm [default | range access-list] | Defines the SSM range of IP multicast addresses. |
Step 2 | Router(config-if)#or Router(config-if)#ip urd | Enables the acceptance and processing of IGMP v3lite membership reports on an interface. or Enables interception of TCP packets sent to the reserved URD port 659 on an interface and processing of URD channel subscription reports. |
To verify configuration of multicast groups supporting SSM, use the following show commands:
| Command | Purpose |
|---|---|
Router#show ip igmp groups [group-name | group-address | type number] | Displays the specific IGMP v3lite or URD (S, G) entries for which a report is received. |
Router#show ip mroute [group-name | group-address] [source] [summary] [count] [active kbps] | Displays the contents of the IP multicast routing table. |
ip access-list extended no-ssm-range deny ip any 232.0.0.0 0.255.255.255 ! SSM range permit ip any any ! Deny registering in SSM range ip pim accept-register list no-ssm-range ip access-list extended msdp-nono-list deny ip any 232.0.0.0 0.255.255.255 ! SSM Range ! ... ! See ftp://ftpeng.cisco.com/ipmulticast/config-notes/msdp-sa-filter.txt for other SA ! messages that typically need to be filtered. permit ip any any ! Filter generated SA messages in SSM range. This configuration is only needed if there ! are directly connected sources to this router. The "ip pim accept-register" command ! filters remote sources. ip msdp redistribute list msdp-nono-list ! Filter received SA messages in SSM range. "Filtered on receipt" means messages are ! neither processed or forwarded. Needs to be configured for each MSDP peer. ip msdp sa-filter in msdp-peer1 list msdp-nono-list ! ... ip msdp sa-filter in msdp-peerN list msdp-nono-list
This section documents the following new or modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.1 command reference publications.
To enable acceptance and processing of Internet Group Management Version 3 lite (IGMP v3lite) membership reports on an interface, use the ip igmp v3lite interface configuration command. To disable IGMP v3lite, use the no form of this command.
ip igmp v3liteSyntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Interface configuration
Command History
12.1(3)T This command was introduced.
Release
Modification
Usage Guidelines
To use this command, you must define a source specific multicast (SSM) range of IP addresses using the ip pim ssm global configuration command. When IGMP v3lite is enabled, it is supported in the SSM range of addresses only.
Examples
The following example shows how to configure IGMP v3lite on Ethernet interface 3/1:
Router(config)# interface ethernet 3/1 Router(config-if)# ip igmp v3lite
Related Commands
Defines the SSM range of IP multicast addresses.
Command
Description
To define the source specific multicast (SSM) range of IP multicast addresses, use the ip pim ssm global configuration command. To disable the SSM range, use the no form of this command.
ip pim ssm {default | range access-list}
Syntax Description
default (Optional) Defines the SSM range access list to 232/8. range access-list (Optional) Standard IP access list defining the SSM range.
Defaults
Disabled
Command Modes
Global configuration
Command History
12.1(3)T This command was introduced.
Release
Modification
Usage Guidelines
When an SSM range of IP multicast addresses is defined by the ip pim ssm command, no Multicast Source Discovery Protocol (MSDP) Source-Active (SA) messages will be accepted or originated in the SSM range.
Examples
The following example shows how to configure SSM service for the IP address range defined by access list 4:
Router(config)# access-list 4 permit 224.2.151.141 Router(config)# ip pim ssm range 4
Related Commands
Enables the acceptance and processing of IGMP v3lite membership reports on an interface. Enables interception of TCP packets sent to the reserved URD port 659 on an interface and processing of URD channel subscription reports.
Command
Description
To enable interception of TCP packets sent to the reserved URL Rendezvous Directory (URD) port 659 on an interface and processing of URD channel subscription reports, use the ip urd interface configuration command. To disable URD on an interface, use the no form of this command.
ip urdSyntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Interface configuration
Command History
12.1(3)T This command was introduced.
Release
Modification
Usage Guidelines
To use this command, you must define a source specific multicast (SSM) range of IP addresses using the ip pim ssm global configuration command. When URD is enabled, it is supported in the SSM range of addresses only.
URD functionality is available for multicast process switching, fast switching, and distributed fast switching paths.
Examples
The following example shows how to configure URD on Ethernet interface 3/3:
Router(config)# interface ethernet 3/3 Router(config-if)# ip urd
Related Commands
Defines the SSM range of IP multicast addresses.
Command
Description
To display the multicast groups that are directly connected to the router and that were learned via Internet Group Management Protocol (IGMP), use the show ip igmp groups EXEC command.
show ip igmp groups [group-name | group-address | type number]
Syntax Description
group-name (Optional) Name of the multicast group, as defined in the Domain Name System (DNS) hosts table. group-address (Optional) Address of the multicast group. This is a multicast IP address in four-part, dotted notation. type (Optional) Interface type. number (Optional) Interface number.
Command Modes
EXEC
Command History
10.0 This command was introduced. 12.1(3)T Additional fields were added to the output of this command to support the SSM feature.
Release
Modification
Usage Guidelines
If you omit all optional arguments, the show ip igmp groups command displays by group address and interface type and number all directly connected multicast groups.
Examples
The following is sample output from the show ip igmp groups command:
Router# show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.255.1 Ethernet0 18:51:41 0:02:15 198.92.37.192 224.2.226.60 Ethernet0 1:51:31 0:02:17 198.92.37.192 224.2.127.255 Ethernet0 18:51:45 0:02:17 198.92.37.192 226.2.2.2 Ethernet1 18:51:47 never 0.0.0.0 224.2.0.1 Ethernet0 18:51:43 0:02:14 198.92.37.192 225.2.2.2 Ethernet0 18:51:43 0:02:21 198.92.37.33 225.2.2.2 Ethernet1 18:51:47 never 0.0.0.0 225.2.2.4 Ethernet0 18:18:02 0:02:20 198.92.37.192 225.2.2.4 Ethernet1 18:23:32 0:02:55 198.92.36.128
The following is sample output from the show ip igmp groups command, where Internet Group Management Protocol Version 3 lite (IGMP v3lite) is enabled:
Router# show ip igmp groups IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 239.255.255.254 Ethernet3/1 1w0d 00:02:19 172.21.200.159 224.0.1.40 Ethernet3/1 1w0d 00:02:15 172.21.200.1 224.0.1.40 Ethernet3/3 1w0d never 171.69.214.251 224.0.1.1 Ethernet3/1 1w0d 00:02:11 172.21.200.11 224.9.9.2 Ethernet3/1 1w0d 00:02:10 172.21.200.155 232.1.1.1 Ethernet3/1 5d21h 00:02:13 172.21.200.206 Sources: 171.69.214.1 V3 00:02:09 171.69.214.2 V3 00:02:31 232.2.2.2 Ethernet3/1 22:01:45 00:02:10 172.21.200.204 Sources: 171.69.214.2 V3 00:02:22 224.0.1.24 Ethernet3/1 1w0d 00:02:17 172.21.200.159
Table 1 describes the significant fields shown in the output.
| Field | Description |
|---|---|
Group address | Address of the multicast group. |
Interface | Interface through which the group is reachable. |
Uptime | How long in hours, minutes, and seconds this multicast group has been known. |
Expires | How long in hours, minutes, and seconds until the entry is removed from the IGMP groups table. |
Last Reporter | Last host to report being a member of the multicast group. Both IGMP v3lite and URD require a v2-report. If "no v2-report" is displayed in this field, the host must be investigated to determine why it is not sending v2-reports. |
Sources: | List of all sources for a particular multicast group. U indicates that a URD packet has been received. V3 indicates that an IGMP v3lite packet has been received. |
Related Commands
ip igmp query-interval Configures the frequency at which the Cisco IOS software sends IGMP host-query messages.
Command
Description
To display the contents of the IP multicast routing table, use the show ip mroute EXEC command.
show ip mroute [group-name | group-address] [source] [summary] [count] [active kbps]
Syntax Description
group-name | group-address (Optional) IP address, name, or interface of the multicast group as defined in the Domain Name System (DNS) hosts table. source (Optional) IP address or name of a multicast source. summary (Optional) Displays a one-line, abbreviated summary of each entry in the IP multicast routing table. count (Optional) Displays statistics about the group and source, including number of packets, packets per second, average packet size, and bits per second. active kbps (Optional) Displays the rate that active sources are sending to multicast groups. Active sources are those sending at a rate of kbps or higher. The kbps argument defaults to 4 kbps.
Defaults
The show ip mroute command displays all groups and sources.
The show ip mroute active command displays all sources sending at a rate greater than or equal to 4 kbps.
Command Modes
EXEC
Command History
10.0 This command was introduced. 12.1(3)T The U, s, and I flags for source specific multicast (SSM) were introduced.
Release
Modification
Usage Guidelines
If you omit all optional arguments and keywords, the show ip mroute command displays all entries in the IP multicast routing table.
The Cisco IOS software populates the multicast routing table by creating (S, G) entries from (*, G) entries. The star refers to all source addresses, the "S" refers to a single source address, and the "G" is the destination multicast group address. In creating (S, G) entries, the software uses the best path to that destination group found in the unicast routing table (that is, via Reverse Path Forwarding [RPF]).
Examples
The following is sample output from the show ip mroute command for a router operating in dense mode. This command displays the contents of the IP multicast routing table for the multicast group named cbone-audio.
Router# show ip mroute cbone-audio
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 224.0.255.1), uptime 0:57:31, expires 0:02:59, RP is 0.0.0.0, flags: DC
Incoming interface: Null, RPF neighbor 0.0.0.0, Dvmrp
Outgoing interface list:
Ethernet0, Forward/Dense, 0:57:31/0:02:52
Tunnel0, Forward/Dense, 0:56:55/0:01:28
(198.92.37.100/32, 224.0.255.1), uptime 20:20:00, expires 0:02:55, flags: C
Incoming interface: Tunnel0, RPF neighbor 10.20.37.33, Dvmrp
Outgoing interface list:
Ethernet0, Forward/Dense, 20:20:00/0:02:52
The following is sample output from the show ip mroute command for a router operating in sparse mode:
Router# show ip mroute
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 224.0.255.3), uptime 5:29:15, RP is 198.92.37.2, flags: SC
Incoming interface: Tunnel0, RPF neighbor 10.3.35.1, Dvmrp
Outgoing interface list:
Ethernet0, Forward/Sparse, 5:29:15/0:02:57
(198.92.46.0/24, 224.0.255.3), uptime 5:29:15, expires 0:02:59, flags: C
Incoming interface: Tunnel0, RPF neighbor 10.3.35.1
Outgoing interface list:
Ethernet0, Forward/Sparse, 5:29:15/0:02:57
The following is sample output from the show ip mroute command that shows the virtual circuit descriptor (VCD) value, because an ATM interface with PIM multipoint signalling is enabled:
Router# show ip mroute 224.1.1.1
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.1.1.1), 00:03:57/00:02:54, RP 130.4.101.1, flags: SJ
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
ATM0/0, VCD 14, Forward/Sparse, 00:03:57/00:02:53
The following is sample output from the show ip mroute command with the summary keyword:
Router# show ip mroute summary
IP Multicast Routing Table
Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned
R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT
Timers: Uptime/Expires
Interface state: Interface, Next-Hop, State/Mode
(*, 224.255.255.255), 2d16h/00:02:30, RP 171.69.10.13, flags: SJPC
(*, 224.2.127.253), 00:58:18/00:02:00, RP 171.69.10.13, flags: SJC
(*, 224.1.127.255), 00:58:21/00:02:03, RP 171.69.10.13, flags: SJC
(*, 224.2.127.254), 2d16h/00:00:00, RP 171.69.10.13, flags: SJCL
(128.9.160.67/32, 224.2.127.254), 00:02:46/00:00:12, flags: CLJT
(129.48.244.217/32, 224.2.127.254), 00:02:15/00:00:40, flags: CLJT
(130.207.8.33/32, 224.2.127.254), 00:00:25/00:02:32, flags: CLJT
(131.243.2.62/32, 224.2.127.254), 00:00:51/00:02:03, flags: CLJT
(140.173.8.3/32, 224.2.127.254), 00:00:26/00:02:33, flags: CLJT
(171.69.60.189/32, 224.2.127.254), 00:03:47/00:00:46, flags: CLJT
The following is sample output from the show ip mroute command with the active keyword:
Router# show ip mroute active
Active IP Multicast Sources - sending >= 4 kbps
Group: 224.2.127.254, (sdr.cisco.com)
Source: 146.137.28.69 (mbone.ipd.anl.gov)
Rate: 1 pps/4 kbps(1sec), 4 kbps(last 1 secs), 4 kbps(life avg)
Group: 224.2.201.241, ACM 97
Source: 130.129.52.160 (webcast3-e1.acm97.interop.net)
Rate: 9 pps/93 kbps(1sec), 145 kbps(last 20 secs), 85 kbps(life avg)
Group: 224.2.207.215, ACM 97
Source: 130.129.52.160 (webcast3-e1.acm97.interop.net)
Rate: 3 pps/31 kbps(1sec), 63 kbps(last 19 secs), 65 kbps(life avg)
The following is sample output from the show ip mroute command with the count keyword:
Router# show ip mroute count
IP Multicast Statistics - Group count: 8, Average sources per group: 9.87
Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Group: 224.255.255.255, Source count: 0, Group pkt count: 0
RP-tree: 0/0/0/0
Group: 224.2.127.253, Source count: 0, Group pkt count: 0
RP-tree: 0/0/0/0
Group: 224.1.127.255, Source count: 0, Group pkt count: 0
RP-tree: 0/0/0/0
Group: 224.2.127.254, Source count: 9, Group pkt count: 14
RP-tree: 0/0/0/0
Source: 128.2.6.9/32, 2/0/796/0
Source: 128.32.131.87/32, 1/0/616/0
Source: 128.125.51.58/32, 1/0/412/0
Source: 130.207.8.33/32, 1/0/936/0
Source: 131.243.2.62/32, 1/0/750/0
Source: 140.173.8.3/32, 1/0/660/0
Source: 146.137.28.69/32, 1/0/584/0
Source: 171.69.60.189/32, 4/0/447/0
Source: 204.162.119.8/32, 2/0/834/0
Group: 224.0.1.40, Source count: 1, Group pkt count: 3606
RP-tree: 0/0/0/0
Source: 171.69.214.50/32, 3606/0/48/0, RPF Failed: 1203
Group: 224.2.201.241, Source count: 36, Group pkt count: 54152
RP-tree: 7/0/108/0
Source: 13.242.36.83/32, 99/0/123/0
Source: 36.29.1.3/32, 71/0/110/0
Source: 128.9.160.96/32, 505/1/106/0
Source: 128.32.163.170/32, 661/1/88/0
Source: 128.115.31.26/32, 192/0/118/0
Source: 128.146.111.45/32, 500/0/87/0
Source: 128.183.33.134/32, 248/0/119/0
Source: 128.195.7.62/32, 527/0/118/0
Source: 128.223.32.25/32, 554/0/105/0
Source: 128.223.32.151/32, 551/1/125/0
Source: 128.223.156.117/32, 535/1/114/0
Source: 128.223.225.21/32, 582/0/114/0
Source: 129.89.142.50/32, 78/0/127/0
Source: 129.99.50.14/32, 526/0/118/0
Source: 130.129.0.13/32, 522/0/95/0
Source: 130.129.52.160/32, 40839/16/920/161
Source: 130.129.52.161/32, 476/0/97/0
Source: 130.221.224.10/32, 456/0/113/0
Source: 132.146.32.108/32, 9/1/112/0
The following is sample output from the show ip mroute command for a router supporting SSM services:
Router# show ip mroute 232.6.6.6
IP Multicast Routing Table
Flags:D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C -
Connected, L - Local, P - Pruned, R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT, M - MSDP created entry, X - Proxy Join Timer Running, A - Advertised via MSDP, U - URD, I - Received Source Specific Host Report
Outgoing interface flags:H - Hardware switched
Timers:Uptime/Expires
Interface state:Interface, Next-Hop or VCD, State/Mode
(*, 232.6.6.6), 00:01:20/00:02:59, RP 0.0.0.0, flags:sSJP
Incoming interface:Null, RPF nbr 0.0.0.0
Outgoing interface list:Null
(2.2.2.2, 232.6.6.6), 00:01:20/00:02:59, flags:CTI
Incoming interface:Ethernet3/3, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Sparse-Dense, 00:00:36/00:02:35
Table 2 describes the significant fields shown in the output.
| Field | Description | ||
|---|---|---|---|
Flags: | Provides information about the entry. | ||
| Entry is operating in dense mode. | ||
| Entry is operating in sparse mode. | ||
| Indicates that a multicast group is operation in bidirectional mode. | ||
| Indicates that a multicast group is within the SSM range of IP addresses. This flag is reset if the SSM range changes. | ||
| A member of the multicast group is present on the directly connected interface. | ||
| The router itself is a member of the multicast group. | ||
| Route has been pruned. The Cisco IOS software keeps this information so that a downstream member can join the source. | ||
| Indicates that the (S, G) entry is pointing toward the RP. This is typically prune state along the shared tree for a particular source. | ||
| Indicates that the software is registering for a multicast source. | ||
| Indicates that packets have been received on the shortest path source tree. | ||
| For (*, G) entries, indicates that the rate of traffic flowing down the shared tree is exceeding the SPT-Threshold set for the group. (The default SPT-Threshold setting is 0 kbps.) When the J- Join shortest path tree (SPT) flag is set, the next (S, G) packet received down the shared tree triggers an (S, G) join in the direction of the source, thereby causing the router join the source tree. For (S, G) entries, indicates that the entry was created because the SPT-Threshold for the group was exceeded. When the J- Join SPT flag is set for (S, G) entries, the router monitors the traffic rate on the source tree and attempts to switch back to the shared tree for this source if the traffic rate on the source tree falls below the SPT-Threshold of the group for more than 1 minute.
| ||
| Indicates that a (*, G) entry was learned via an MSDP peer. This flag is only applicable for an RP running MSDP. | ||
| Indicates that the proxy join timer is running. This flag is only set for (S, G) entries of an RP or "turnaround" router. A "turnaround" router is located at the intersection of a shared path (*, G) tree and the shortest path from the source to the RP. | ||
| Indicates that an (S, G) entry was advertised via an MSDP peer. This flag is only applicable for an RP running MSDP. | ||
| Indicates that a URD channel subscription report was received for the (S, G) entry. | ||
| Indicates that an (S, G) entry was created by an SSM membership report. This flag is only set on the designated router (DR). | ||
Outgoing interface flags: | Provides information about the entry. | ||
| Indicates that a Multicast Multilayer Switching (MMLS) forwarding path has been established for this entry. | ||
Timers: Uptime/Expires | Uptime indicates per interface how long in hours, minutes, and seconds the entry has been in the IP multicast routing table. Expires indicates per interface how long in hours, minutes, and seconds until the entry will be removed from the IP multicast routing table. | ||
Interface state: | Indicates the state of the incoming or outgoing interface. | ||
| Indicates the type and number of the interface listed in the incoming or outgoing interface list. | ||
| Next hop specifies the IP address of the downstream neighbor. VCD specifies the virtual circuit descriptor number. VCD0 means the group is using the static-map virtual circuit. | ||
| State indicates that packets will either be forwarded, pruned, or null on the interface depending on whether there are restrictions due to access lists or Time To Live (TTL) threshold. Mode indicates whether the interface is operating in dense, sparse, or sparse-dense mode. | ||
(*, 224.0.255.1) and (198.92.37.100/32, 224.0.255.1) | Entry in the IP multicast routing table. The entry consists of the IP address of the source router followed by the IP address of the multicast group. An asterisk (*) in place of the source router indicates all sources. Entries in the first format are referred to as (*, G) or "star comma G" entries. Entries in the second format are referred to as (S, G) or "S comma G" entries. (*, G) entries are used to build (S, G) entries. | ||
RP | Address of the rendezvous point (RP) router. For routers and access servers operating in sparse mode, this address is always 0.0.0.0. | ||
flags: | Information about the entry. | ||
Incoming interface: | Expected interface for a multicast packet from the source. If the packet is not received on this interface, it is discarded. | ||
RPF neighbor | IP address of the upstream router to the source. "Tunneling" indicates that this router is sending data to the RP encapsulated in Register packets. The hexadecimal number in parentheses indicates to which RP it is registering. Each bit indicates a different RP if multiple RPs per group are used. | ||
Dvmrp or Mroute | Indicates if the RPF information is obtained from the Distance Vector Multicast Routing Protocol (DVMRP) routing table or the static mroutes configuration. | ||
Outgoing interface list: | Interfaces through which packets will be forwarded. When the ip pim nbma-mode command is enabled on the interface, the IP address of the Protocol Independent Multicast (PIM) neighbor is also displayed. |
Related Commands
ip multicast-routing Enables IP multicast routing or multicast distributed switching. ip pim Enables PIM on an interface. Defines the SSM range of IP multicast addresses.
Command
Description
This section documents the following new and modified debug commands. All other commands used with this feature are documented in the Cisco IOS Release 12.1 command reference publications.
To display Internet Group Management Protocol (IGMP) packets received and sent, and IGMP-host related events, use the debug ip igmp privileged EXEC command. To disable debugging output, use the no form of this command.
debug ip igmpSyntax Description
This command has no arguments or keywords.
Defaults
None
Command History
10.2 This command was introduced. 12.1(3)T Additional fields were added to the output of this command to support the source specific multicast (SSM) feature.
Release
Modification
Usage Guidelines
This command helps discover whether the IGMP processes are functioning. In general, if IGMP is not working, the router process never discovers that another host is on the network that is configured to receive multicast packets. In dense mode, this situation will result in packets being delivered intermittently (a few every 3 minutes). In sparse mode, packets will never be delivered.
Use this command in conjunction with the debug ip pim and debug ip mrouting commands to observe additional multicast activity and to learn what is happening to the multicast routing process, or why packets are forwarded out of particular interfaces.
Examples
The following is sample output from the debug ip igmp command:
Router# debug ip igmp IGMP: Received Host-Query from 172.24.37.33 (Ethernet1) IGMP: Received Host-Report from 172.24.37.192 (Ethernet1) for 224.0.255.1 IGMP: Received Host-Report from 172.24.37.57 (Ethernet1) for 224.2.127.255 IGMP: Received Host-Report from 172.24.37.33 (Ethernet1) for 225.2.2.2
The messages displayed by the debug ip igmp command show query and report activity received from other routers and multicast group addresses.
The following is sample output from the debug ip igmp command when SSM is enabled. Because IGMP Version 3 lite (IGMP v3lite) requires the host to send IGMP Version 2 (IGMPv2) packets, IGMPv2 host reports also will be displayed in response to the router IGMPv2 queries. If SSM is disabled, the word "ignored" will be displayed in the debug ip igmp command output.
IGMP:Received v3-lite Report from 10.0.119.142 (Ethernet3/3), group count 1 IGMP:Received v3 Group Record from 10.0.119.142 (Ethernet3/3) for 232.10.10.10 IGMP:Update source 1.1.1.1 IGMP:Send v2 Query on Ethernet3/3 to 224.0.0.1 IGMP:Received v2 Report from 10.0.119.142 (Ethernet3/3) for 232.10.10.10 IGMP:Update source 1.1.1.1
Related Commands
debug ip mrm Displays MRM control packet activity. debug ip pim Displays PIM packets received and sent, and PIM-related events.
Command
Description
To display debug messages for URL Rendezvous Directory (URD) channel subscription report processing, use the debug ip urd EXEC command. To disable debugging of URD reports, use the no form of this command.
debug ip urd [hostname | ip-address]
Syntax Description
hostname (Optional) Domain Name System (DNS) name. ip-address (Optional) IP address.
Defaults
If no host name or IP address is specified, all URD reports are debugged.
Command History
12.1(3)T This command was introduced.
Release
Modification
Examples
The following is sample output from the debug ip urd command:
Router# debug ip urd 13:36:25 pdt:URD:Data intercepted from 171.71.225.103 13:36:25 pdt:URD:Enqueued string: '/cgi-bin/error.pl?group=232.16.16.16&port=32620&source=171.69.214.1&li' 13:36:25 pdt:URD:Matched token:group 13:36:25 pdt:URD:Parsed value:232.16.16.16 13:36:25 pdt:URD:Creating IGMP source state for group 232.16.16.16
Posted: Tue Sep 19 18:01:55 PDT 2000
Copyright 1989-2000©Cisco Systems Inc.
