Table Of Contents
Monitoring and Maintaining IP Multicast
Prerequisites for Monitoring and Maintaining IP Multicast
How to Monitor and Maintain IP Multicast
Displaying Multicast Peers, Packet Rates, and Loss Information, and Tracing a Path
Displaying IP Multicast System and Network Statistics
Clearing IP Multicast Routing Table or Caches
Monitoring IP Multicast Delivery Using IP Multicast Heartbeat
Advertising Multicast Multimedia Sessions Using SAP Listener
Session Announcement Protocol (SAP)
Disabling Fast Switching of IP Multicast
Fast Switching of IP Multicast
Enabling PIM MIB Extensions for IP Multicast
Benefits of PIM MIB Extensions
Restrictions for PIM MIB Extensions
Configuration Examples for Monitoring and Maintaining IP Multicast
Generating Notifications That PIM Is Enabled: Example
Feature Information for Monitoring and Maintaining IP Multicast
Monitoring and Maintaining IP Multicast
This module describes many ways to monitor and maintain an IP multicast network, such as
•
displaying which neighboring multicast routers are peering with the local router
•
displaying multicast packet rates and loss information
•
tracing the path from a source to a destination branch for a multicast distribution tree
•
displaying the contents of the IP multicast routing table, information about interfaces configured for PIM, the PIM neighbors discovered by the router, and contents of the IP fast-switching cache
•
clearing caches, tables, and databases
•
monitoring the delivery of IP multicast packets and being alerted if the delivery fails to meet certain parameters (IP multicast heartbeat)
•
using session description and announcement protocols and applications to assist the advertisement of multicast multimedia conferences and other multicast sessions and communicating the relevant session setup information to prospective participants (SAP listener support)
•
storing IP multicast packet headers in a cache and displaying them to find out information such as who is sending IP multicast packets to what groups and any multicast forwarding loops in your network
•
using managed objects to remotely monitor and configure PIM using Simple Network Management Protocol (SNMP)
•
disabling fast switching of IP multicast in order to log debug messages
Module History
This module was first published on May 2, 2005, and last updated on May 2, 2005.
Finding Feature Information in This Module
Not all features may be supported in your Cisco IOS software release. Use the "Feature Information for Monitoring and Maintaining IP Multicast" section to find information about feature support and configuration.
Contents
•
Prerequisites for Monitoring and Maintaining IP Multicast
•
How to Monitor and Maintain IP Multicast
•
Configuration Examples for Monitoring and Maintaining IP Multicast
•
Feature Information for Monitoring and Maintaining IP Multicast
Prerequisites for Monitoring and Maintaining IP Multicast
•
Before performing the tasks in this module, you should be familiar with the concepts described in the "IP Multicast Technology Overview" module.
•
You must also have enabled IP multicast and have Protocol Independent Multicast (PIM) configured and running on your network. Refer to the "Configuring Basic IP Multicast" module.
How to Monitor and Maintain IP Multicast
This section contains the following procedures:
•
Displaying Multicast Peers, Packet Rates, and Loss Information, and Tracing a Path (optional)
•
Displaying IP Multicast System and Network Statistics (optional)
•
Clearing IP Multicast Routing Table or Caches (optional)
•
Monitoring IP Multicast Delivery Using IP Multicast Heartbeat (optional)
•
Advertising Multicast Multimedia Sessions Using SAP Listener (optional)
•
Storing IP Multicast Headers (optional)
•
Disabling Fast Switching of IP Multicast (optional)
•
Enabling PIM MIB Extensions for IP Multicast (optional)
Displaying Multicast Peers, Packet Rates, and Loss Information, and Tracing a Path
Monitor IP multicast routing when you want to know which neighboring multicast routers are peering with the local router, what the multicast packet rates and loss information are, or when you want to trace the path from a source to a destination branch for a multicast distribution tree.
SUMMARY STEPS
1.
enable
2.
mrinfo [host-name | host-address] [source-address | interface]
3.
mstat {source-name | source-address} [destination-name | destination-address] [group-name | group-address]
4.
mtrace {source-name | source-address} [destination-name | destination-address] [group-name | group-address]
DETAILED STEPS
Examples
The following is sample output from the mrinfo command:
Router# mrinfo192.31.7.37 (labs-allcompany) [version cisco 12.3] [flags: PMSA]:192.31.7.37 -> 192.31.7.34 (lab-southwest) [1/0/pim]192.31.7.37 -> 192.31.7.47 (lab-northwest) [1/0/pim]192.31.7.37 -> 192.31.7.44 (lab-southeast) [1/0/pim]131.119.26.10 -> 131.119.26.9 (lab-northeast) [1/32/pim]The following is sample output from the mstat command in user EXEC mode:
Router> mstat labs-in-china 172.16.0.1 224.0.255.255Type escape sequence to abort.Mtrace from 172.16.0.0 to 172.16.0.10 via group 224.0.255.255>From source (labs-in-china) to destination (labs-in-africa)Waiting to accumulate statistics......Results after 10 seconds:Source Response Dest Packet Statistics For Only For Traffic172.16.0.0 172.16.0.10 All Multicast Traffic From 172.16.0.0| __/ rtt 48 ms Lost/Sent = Pct Rate To 224.0.255.255v / hop 48 ms --------------------- --------------------172.16.0.1 labs-in-england| ^ ttl 1v | hop 31 ms 0/12 = 0% 1 pps 0/1 = --% 0 pps172.16.0.2172.16.0.3 infolabs.com| ^ ttl 2v | hop -17 ms -735/12 = --% 1 pps 0/1 = --% 0 pps172.16.0.4172.16.0.5 infolabs2.com| ^ ttl 3v | hop -21 ms -678/23 = --% 2 pps 0/1 = --% 0 pps172.16.0.6172.16.0.7 infolabs3.com| ^ ttl 4v | hop 5 ms 605/639 = 95% 63 pps 1/1 = --% 0 pps172.16.0.8172.16.0.9 infolabs.cisco.com| \__ ttl 5v \ hop 0 ms 4 0 pps 0 0 pps172.16.0.0 172.16.0.10Receiver Query SourceThe following is sample output from the mtrace command in user EXEC mode:
Router> mtrace 172.16.0.0 172.16.0.10 239.254.254.254Type escape sequence to abort.Mtrace from 172.16.0.0 to 172.16.0.10 via group 239.254.254.254From source (?) to destination (?)Querying full reverse path...0 172.16.0.10-1 172.16.0.8 PIM thresh^ 0 0 ms-2 172.16.0.6 PIM thresh^ 0 2 ms-3 172.16.0.5 PIM thresh^ 0 894 ms-4 172.16.0.3 PIM thresh^ 0 893 ms-5 172.16.0.2 PIM thresh^ 0 894 ms-6 172.16.0.1 PIM thresh^ 0 893 msDisplaying IP Multicast System and Network Statistics
Display IP multicast system statistics to show the contents of the IP multicast routing table, information about interfaces configured for PIM, the PIM neighbors discovered by the router, contents of the IP fast-switching cache, and the contents of the circular cache header buffer.
SUMMARY STEPS
1.
enable
2.
ping [group-name | group-address]
3.
show ip mroute [group-address | group-name] [source-address | source-name] [type number] [summary] [count] [active kbps]
4.
show ip pim interface [type number] [df | count] [rp-address] [detail]
5.
show ip pim neighbor [type number]
6.
show ip mcache [group-address | group-name] [source-address | source-name]
7.
show ip mpacket [group-address | group-name] [source-address | source-name] [detail]
8.
show ip pim rp [mapping | metric] [rp-address]
9.
show ip rpf {source-address | source-name} [metric]
DETAILED STEPS
Examples
show ip mroute
The following is sample output from the show ip mroute command for a router operating in sparse mode:
Router# show ip mrouteIP Multicast Routing TableFlags: 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 - Candidate for MSDP Advertisement,U - URD, I - Received Source Specific Host Report, Z - Multicast Tunnel,Y - Joined MDT-data group, y - Sending to MDT-data groupTimers: Uptime/ExpiresInterface state: Interface, Next-Hop, State/Mode(*, 224.0.255.3), uptime 5:29:15, RP is 192.168.37.2, flags: SCIncoming interface: Tunnel0, RPF neighbor 10.3.35.1, DvmrpOutgoing interface list:Ethernet0, Forward/Sparse, 5:29:15/0:02:57(192.168.46.0/24, 224.0.255.3), uptime 5:29:15, expires 0:02:59, flags: CIncoming interface: Tunnel0, RPF neighbor 10.3.35.1Outgoing interface list:Ethernet0, Forward/Sparse, 5:29:15/0:02:57show ip pim interface
The following is sample output from the show ip pim interface command when an interface is specified:
Router# show ip pim interface Ethernet1/0Address Interface Ver/ Nbr Query DR DRMode Count Intvl Prior172.16.1.4 Ethernet1/0 v2/S 1 100 ms 1 172.16.1.4show ip mcache
The following is sample output from the show ip mcache privileged EXEC command when multicast distributed switching (MDS) is in effect:
Router# show ip mcacheIP Multicast Fast-Switching Cache(*, 239.2.3.4), Fddi3/0/0, Last used: mdsTunnel3 MAC Header: 5000602F9C150000603E473F60AAAA030000000800 (Fddi3/0/0)Tunnel0 MAC Header: 5000602F9C150000603E473F60AAAA030000000800 (Fddi3/0/0)Tunnel1 MAC Header: 5000602F9C150000603E473F60AAAA030000000800 (Fddi3/0/0)show ip mpacket
The following is sample output from the show ip mpacket command with the group-name argument:
Router# show ip mpacket smallgroupIP Multicast Header Cache - entry count:6, next index: 7Key: id/ttl timestamp (name) source groupD782/117 206416.908 (company1.company.com) 192.168.228.10 224.5.6.77302/113 206417.908 (school.edu) 172.16.2.17 224.5.6.76CB2/114 206417.412 (company2.company.com) 172.16.19.40 224.5.6.7D782/117 206417.868 (company1.company.com) 192.168.228.10 224.5.6.7E2E9/123 206418.488 (company3.com) 239.1.8.10 224.5.6.71CA7/127 206418.544 (company4.company.com) 192.168.6.10 224.5.6.7The following is sample output from the show ip pim rp command:
Router# show ip pim rpGroup:227.7.7.7, RP:10.10.0.2, v2, v1, next RP-reachable in 00:00:48show ip pim rp
The following is sample output from the show ip pim rp command when the mapping keyword is specified:
Router# show ip pim rp mappingPIM Group-to-RP MappingsThis system is an RP (Auto-RP)This system is an RP-mapping agentGroup(s) 227.0.0.0/8RP 10.10.0.2 (?), v2v1, bidirInfo source:10.10.0.2 (?), via Auto-RPUptime:00:01:42, expires:00:00:32Group(s) 228.0.0.0/8RP 10.10.0.3 (?), v2v1, bidirInfo source:10.10.0.3 (?), via Auto-RPUptime:00:01:26, expires:00:00:34Group(s) 229.0.0.0/8RP 10.10.0.5 (mcast1.cisco.com), v2v1, bidirInfo source:10.10.0.5 (mcast1.cisco.com), via Auto-RPUptime:00:00:52, expires:00:00:37Group(s) (-)230.0.0.0/8RP 10.10.0.5 (mcast1.cisco.com), v2v1, bidirInfo source:10.10.0.5 (mcast1.cisco.com), via Auto-RPUptime:00:00:52, expires:00:00:37The following is sample output from the show ip pim rp command when the metric keyword is specified:
Router# show ip pim rp metricRP Address Metric Pref Metric Flags RPF Type Interface10.10.0.2 0 0 L unicast Loopback010.10.0.3 90 409600 L unicast Ethernet3/310.10.0.5 90 435200 L unicast Ethernet3/3show ip rpf
The following is sample output from the show ip rpf command:
Router# show ip rpf 172.16.10.13RPF information for host1 (172.16.10.13)RPF interface: BRI0RPF neighbor: sj1.cisco.com (172.16.121.10)RPF route/mask: 172.16.0.0/255.255.0.0RPF type: unicastRPF recursion count: 0Doing distance-preferred lookups across tablesThe following is sample output from the show ip rpf command when the metric keyword is specified:
Router# show ip rpf 172.16.10.13 metricRPF information for host1.cisco.com (172.16.10.13)RPF interface: BRI0RPF neighbor: neighbor.cisco.com (172.16.121.10)RPF route/mask: 172.16.0.0/255.255.0.0RPF type: unicastRPF recursion count: 0Doing distance-preferred lookups across tablesMetric preference: 110Metric: 11Clearing IP Multicast Routing Table or Caches
Clear IP multicast caches and tables to delete entries from the IP multicast routing table, the Auto-RP cache, the IGMP cache, and the caches of Catalyst switches. When these entries are cleared, the information is refreshed by being relearned, thus eliminating any incorrect entries.
SUMMARY STEPS
1.
enable
2.
clear ip mroute {* | group-name [source-name | source-address] | group-address [source-name | source-address]}
3.
clear ip pim auto-rp rp-address
4.
clear ip mcache
5.
clear ip igmp group [group-name | group-address | interface-type interface-number]
6.
clear ip cgmp [interface-type interface-number]
DETAILED STEPS
Monitoring IP Multicast Delivery Using IP Multicast Heartbeat
The IP multicast heartbeat feature provides a way to monitor the status of IP multicast delivery and be informed when the delivery fails (via Simple Network Management Protocol [SNMP] traps).
IP Multicast Heartbeat
The IP Multicast Heartbeat feature enables you to monitor the delivery of IP multicast packets and to be alerted if the delivery fails to meet certain parameters.
Although you could alternatively use MRM to monitor IP multicast, you can perform the following tasks with IP multicast heartbeat that you cannot perform with MRM:
•
Generate an SNMP trap
•
Monitor a production multicast stream
When IP multicast heartbeat is enabled, the router monitors IP multicast packets destined for a particular multicast group at a particular interval. If the number of packets observed is less than a configured minimum amount, the router sends an SNMP trap to a specified network management station to indicate a loss of heartbeat exception.
The ip multicast heartbeat command does not create a heartbeat if there is no existing multicast forwarding state for group in the router. This command will not create a multicast forwarding state in the router. Use the ip igmp static-group command on the router or on a downstream router to force forwarding of IP multicast traffic. Use the snmp-server host ipmulticast command to enable the sending of IP multicast traps to specific receiver hosts. Use the debug ip mhbeat command to debug the Multicast Heartbeat feature.
SNMP Notifications
A key feature of SNMP is the ability to generate notifications from an SNMP agent. These notifications do not require that requests be sent from the SNMP manager. Unsolicited (asynchronous) notifications can be generated as traps or inform requests. Traps are messages alerting the SNMP manager to a condition on the network. Inform requests (informs) are traps that include a request for confirmation of receipt from the SNMP manager. Notifications can indicate improper user authentication, restarts, the closing of a connection, loss of connection to a neighbor router, or other significant events.
Traps are less reliable than informs because the receiver does not send any acknowledgment when it receives a trap. The sender cannot determine if the trap was received. An SNMP manager that receives an inform request acknowledges the message with an SNMP response protocol data unit (PDU). If the manager does not receive an inform request, it does not send a response. If the sender never receives a response, the inform request can be sent again. Thus, informs are more likely to reach their intended destination.
However, traps are often preferred because informs consume more resources in the router and in the network. Unlike a trap, which is discarded as soon as it is sent, an inform request must be held in memory until a response is received or the request times out. Also, traps are sent only once, while an inform may be retried several times. The retries increase traffic and contribute to a higher overhead on the network. Thus, traps and inform requests provide a trade-off between reliability and resources. If it is important that the SNMP manager receives every notification, use inform requests. However, if you are concerned about traffic on your network or memory in the router and you need not receive every notification, use traps.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip multicast-routing
4.
snmp-server host {hostname | ip-address} [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}] community-string [udp-port port] [notification-type]
5.
snmp-server enable traps ipmulticast
6.
ip multicast heartbeat group-address minimum-number window-size interval
DETAILED STEPS
Examples
The following example shows how to monitor IP multicast packets forwarded through this router to group address 244.1.1.1. If no packet for this group is received in a 10-second interval, an SNMP trap will be sent to the SNMP management station with the IP address of 224.1.0.1.
!ip multicast-routing!snmp-server host 224.1.0.1 traps publicsnmp-server enable traps ipmulticastip multicast heartbeat ethernet0 224.1.1.1 1 1 10Advertising Multicast Multimedia Sessions Using SAP Listener
Enable SAP listener support when you want to use session description and announcement protocols and applications to assist the advertisement of multicast multimedia conferences and other multicast sessions and to communicate the relevant session setup information to prospective participants.
Session Announcement Protocol (SAP)
Session Announcement Protocol (SAP) listener support is needed to use session description and announcement protocols and applications to assist the advertisement of multicast multimedia conferences and other multicast sessions and to communicate the relevant session setup information to prospective participants.
Sessions are described by the Session Description Protocol (SDP), which is defined in RFC 2327. SDP provides a formatted, textual description of session properties (for example, contact information, session lifetime, and the media) being used in the session (for example, audio, video, and whiteboard) with their specific attributes such as time-to-live (TTL) scope, group address, and User Datagram Protocol (UDP) port number.
Many multimedia applications rely on SDP for session descriptions. However, they may use different methods to disseminate these session descriptions. For example, IP/TV relies on the web to disseminate session descriptions to participants. In this example, participants must know of a web server that provides the session information.
MBONE applications (for example, vic, vat, and wb) and other applications rely on multicast session information sent throughout the network. In these cases, SAP is used to transport the SDP session announcements. SAP Version 2 uses the well-known session directory multicast group 224.2.127.254 to disseminate SDP session descriptions for global scope sessions and group 239.255.255.255 for administrative scope sessions.
Note
The Session Directory (SDR) application is commonly used to send and receive SDP/SAP session announcements.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip sap cache-timeout minutes
4.
interface type number
5.
ip sap listen
6.
end
7.
clear ip sap [group-address | "session-name"]
8.
show ip sap [group-address | "session-name" | detail]
DETAILED STEPS
Examples
The following example enables a router to listen to session directory announcements and changes the SAP cache timeout to 30 minutes.
ip multicast routingip sap cache-timeout 30interface loopback 0ip address 10.0.0.51 255.255.255.0ip pim sparse-dense modeip sap listenThe following is sample output from the show ip sap command for a session using multicast group 224.2.197.250:
Router# show ip sap 224.2.197.250SAP Cache - 198 entriesSession Name: Session1Description: This broadcast is brought to you courtesy of Name1.Group: 0.0.0.0, ttl: 0, Contiguous allocation: 1Lifetime: from 10:00:00 PDT Jul 4 1999 until 10:00:00 PDT Aug 1 1999Uptime: 4d05h, Last Heard: 00:01:40Announcement source: 128.102.84.134Created by: sample 3136541828 3139561476 IN IP4 128.102.84.134Phone number: Sample Digital Video Lab (555) 555-5555Email: email1 <name@email.com>URL: http://url.com/Media: audio 20890 RTP/AVP 0Media group: 224.2.197.250, ttl: 127Attribute: ptime:40Media: video 62806 RTP/AVP 31Media group: 224.2.190.243, ttl: 127Storing IP Multicast Headers
You can store IP multicast packet headers in a cache and then display them to determine any of the following information:
•
Who is sending IP multicast packets to what groups
•
Interpacket delay
•
Duplicate IP multicast packets (if any)
•
Multicast forwarding loops in your network (if any)
•
Scope of the group
•
UDP port numbers
•
Packet length
Perform this task if you need any of the information listed above.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
ip multicast cache-headers [rtp]
4.
exit
5.
show ip mpacket [group-address | group-name] [source-address | source-name] [detail]
DETAILED STEPS
Examples
The following is sample output from the show ip mpacket command for the group named "smallgroup."
Router# show ip mpacket smallgroupIP Multicast Header Cache - entry count:6, next index: 7Key: id/ttl timestamp (name) source groupD782/117 206416.908 (company1.company.com) 192.168.228.10 224.5.6.77302/113 206417.908 (school.edu) 172.16.2.17 224.5.6.76CB2/114 206417.412 (company2.company.com) 172.16.19.40 224.5.6.7D782/117 206417.868 (company1.company.com) 192.168.228.10 224.5.6.7E2E9/123 206418.488 (company3.com) 239.1.8.10 224.5.6.71CA7/127 206418.544 (company4.company.com) 192.168.6.10 224.5.6.7Disabling Fast Switching of IP Multicast
Disable fast switching if you want to log debug messages, because when fast switching is enabled, debug messages are not logged.
You might also want to disable fast switching, which places the router in process switching, if packets are not reaching their destinations. If fast switching is disabled and packets are reaching their destinations, then switching may be the cause.
Fast Switching of IP Multicast
Fast switching of IP multicast packets is enabled by default on all interfaces (including generic routing encapsulation [GRE] and DVMRP tunnels), with one exception: It is disabled and not supported over X.25 encapsulated interfaces. The following are properties of fast switching:
•
If fast switching is disabled on an incoming interface for a multicast routing table entry, the packet is sent at process level for all interfaces in the outgoing interface list.
•
If fast switching is disabled on an outgoing interface for a multicast routing table entry, the packet is process-level switched for that interface, but may be fast switched for other interfaces in the outgoing interface list.
•
When fast switching is enabled, debug messages are not logged.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
interface type number
4.
no ip pim mroute-cache
DETAILED STEPS
Enabling PIM MIB Extensions for IP Multicast
PIM MIB extensions for IP multicast introduce support in Cisco IOS software for the CISCO-PIM-MIB, which is an extension of RFC 2934 and an enhancement to the former Cisco implementation of the PIM MIB.
PIM MIB Extensions
Protocol Independent Multicast (PIM) is an IP multicast routing protocol used for routing multicast data packets to multicast groups. RFC 2934 defines the PIM for IPv4 MIB, which describes managed objects that enable users to remotely monitor and configure PIM using Simple Network Management Protocol (SNMP).
PIM MIB extensions introduce the following new classes of PIM notifications:
•
neighbor-change—This notification results from the following conditions:
–
When a router's PIM interface is disabled or enabled (using the ip pim command in interface configuration mode)
–
When a router's PIM neighbor adjacency expires or is established (defined in RFC 2934)
•
rp-mapping-change—This notification results from a change in the rendezvous point (RP) mapping information due to either Auto-RP or bootstrap router (BSR) messages.
•
invalid-pim-message—This notification results from the following conditions:
–
When an invalid (*, G) Join or Prune message is received by the device (for example, when a router receives a Join or Prune message for which the RP specified in the packet is not the RP for the multicast group)
–
When an invalid PIM register message is received by the device (for example, when a router receives a register message from a multicast group for which it is not the RP)
Benefits of PIM MIB Extensions
PIM MIB extensions have the following benefits:
•
Allow users to identify changes in the multicast topology of their network by detecting changes in the RP mapping.
•
Provide traps to monitor the PIM protocol on PIM-enabled interfaces.
•
Help users identify routing issues when multicast neighbor adjacencies expire or are established on a multicast interface.
•
Enable users to monitor RP configuration errors (for example, errors due to flapping in dynamic RP allocation protocols like Auto-RP).
Restrictions for PIM MIB Extensions
The following MIB tables are not supported in Cisco IOS software:
•
pimIpMRouteTable
•
pimIpMRouteNextHopTable
•
The pimInterfaceVersion object was removed from RFC 2934 and, therefore, is no longer supported in Cisco IOS software.
SUMMARY STEPS
1.
enable
2.
configure terminal
3.
snmp-server enable traps pim [neighbor-change | rp-mapping-change | invalid-pim-message]
4.
snmp-server host host-address [traps | informs] community-string pim
DETAILED STEPS
Configuration Examples for Monitoring and Maintaining IP Multicast
This section provides the following configuration example:
•
Generating Notifications That PIM Is Enabled: Example
Generating Notifications That PIM Is Enabled: Example
The following example shows how to configure a router to generate notifications indicating that a PIM interface of the router has been enabled. The first line configures PIM traps to be sent as SNMP v2c traps to the host with IP address 10.0.0.1. The second line configures the router to send the neighbor-change class of notification to the host.
snmp-server host 10.0.0.1 traps version 2c public pimsnmp-server enable traps pim neighbor-changeinterface ethernet0/0ip pim sparse-dense-modeAdditional References
The following sections provide references related to monitoring and maintaining IP multicast.
Related Documents
Related Topic Document TitleIP multicast SNMP notifications
"Configuring SNMP Support" module
IP multicast commands: complete command syntax, command mode, defaults, usage guidelines, and examples
MIBs
MIBs MIBs Link•
CISCO-IPMROUTE-MIB
•
MSDP-MIB
•
IGMP-STD-MIB
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
Technical Assistance
Feature Information for Monitoring and Maintaining IP Multicast
Table 1 lists the features in this module and provides links to specific configuration information. Only features that were introduced or modified in Cisco IOS Releases 12.2(1) or 12.0(3)S or later appear in the table.
Not all commands may be available in your Cisco IOS software release. For details on when support for specific commands was introduced, see the command reference documents.
If you are looking for information on a feature in this technology that is not documented here, see the "Configuring IP Multicast Roadmap".
Cisco IOS software images are specific to a Cisco IOS software release, a feature set, and a platform. Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator (http://www.cisco.com/go/fn). You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Note
Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS software release train also support that feature.
Table 1 Feature Information for Monitoring and Maintaining IP Multicast
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2005-2008 Cisco Systems, Inc. All rights reserved.


