

Use the debug ip mpacket command on the nearest upstream router, with the detail or acl argument for granularity. If you do not observe any traffic, check receiver signaling. The command output shows the traffic flow statistics for each (S,G) pair. Use the show ip mroute count and show ip mroute active commands to check the first upstream router or switch to see if it sees multicast packets from the source. Use the show ip igmp interface interface-name command to see the interface TTL threshold value. Any packet with a TTL value of 1, or less than the TTL threshold set by the interface with the ip multicast ttl-threshold command, is dropped and the "bad hop-count" counter is increased by one. To verify, use the show ip traffic command and look for an increase in the value of the "bad hop count" counter. If the application sends packets with a TTL value less than 1, you should see the traffic dropped at the first upstream router. Use the show ip igmp groups interface-name command to check the upstream router to see if it received a join membership report at the interface directly connected to source.Ĭheck the TTL value in the application sourcing packets it should be greater than 1. If it is not, check for misconfiguration or bugs in the host stack and application. First, check the interface counters (if you are on a UNIX system, use the netstat command) on the source host to see if it is sending packets. Check Source Packet FlowĬomplete these steps to determine if the source is actually sourcing the packets and inserting the correct packet fields:Ĭheck the interface counters on the host.

The next subsections detail the troubleshooting tools you can use to check and fix common problems. This table helps verify each piece of troubleshooting information by checking that each section of the table is working correctly: The signaling protocol is used to setup and tear down the multicast sessions (such as PIM dense mode, PIM sparse mode, and DVMRP), and packet flow is the actual sending, replicating, and receiving of the multicast packets between the source and receiver, based on the forwarding table created by the signaling process.

When you troubleshoot multicast networks, it is good to consider the signaling protocol used in the network and packet flow. Refer to Cisco Technical Tips Conventions for more information on document conventions. If your network is live, make sure that you understand the potential impact of any command. All of the devices used in this document started with a cleared (default) configuration. The information in this document was created from the devices in a specific lab environment.
MULTICAST PING TOOL SOFTWARE
This document is not restricted to specific software and hardware versions. There are no specific requirements for this document. If you understand the various command line interface tools and the key information fields in their output, it helps you troubleshoot multicast networks. This document explains different tools and techniques for troubleshooting multicast networks.
