Troubleshooting IP Multicast Connectivity

Troubleshooting IP Multicast Connectivity
Multicast can be a difficult protocol to troubleshoot. However, a few basic tools (mostly show
commands) can provide enough information for you to verify that connectivity is active or to
determine whether other steps, such as debugging, are needed to troubleshoot the problem.
If you do need to debug a multicast-enabled interface, you must first disable the multicast fast
switching on the interface. This is done so that the debug messages can be logged. The command
to disable fast switching is no ip mroute-cache. The standard unicast fast (or other forms of)
switching can be left enabled.
You are familiar with the troubleshooting tools for unicast connectivity, Ping and
Traceroute. Well, these tools are also available for troubleshooting multicast connectivity.
There is one minor difference, though: multicast requires a special version of traceroute�"
called mtrace, or “multicast-traceroute.”
Ping After a device on the network becomes a member of a group, it can be identified by its
layer 3 multicast address as well as the layer 2 MAC address. Because the device has an active
address on its interface, it can respond to ICMP request packets. Here is an example:
Terry_3640#ping
Protocol [ip]:
Target IP address: 224.2.143.55
Repeat count [1]: 5
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 224.2.143.55, timeout is 2 seconds:
.!!!!
Terry_3640#
This tool can be used to verify connectivity among RPs or other multicast routers.
mtrace Cisco also provides a multicast Traceroute tool. The multicast version of Traceroute
is somewhat different from the unicast version. The complete syntax for mtrace is mtrace
source_ip destination_ip group. The source_ip is the unicast IP address for the source
of the multicast group. The destination_ip is used when following the forwarding path
established by the source or shared tree distribution toward a unicast destination. The group
option is used to establish the tree for the specified group. If no destination or group options are
specified, the mtrace will work from the incoming multicast interfaces back toward the multicast
source. Here are a few samples of the command and its output:
Jack_3640#mtrace 198.32.163.74
Type escape sequence to abort.
Mtrace from 198.32.163.74 to 172.16.25.9 via RPF
From source (blaster.oregon-gigapop.net) to destination (?)
Querying full reverse path...
0 172.16.25.9
-1 172.16.25.9 PIM/MBGP [198.32.163.0/24]
-2 172.16.25.10 PIM/MBGP [198.32.163.0/24]
-3 ogig-den.oregon-gigapop.net (198.32.163.13) [AS 4600]
PIM [198.32.163.64/26]
-4 0car-0gw.oregon-gigapop.net (198.32.163.26) [AS 4600]
PIM [198.32.163.64/26]
-5 blaster.oregon-gigapop.net (198.32.163.74)
Jack_3640#
Jack_3640#mtrace 198.32.163.74 224.2.243.55
Type escape sequence to abort.
Mtrace from 198.32.163.74 to 172.16.25.9 via group 224.2.243.55
From source (blaster.oregon-gigapop.net) to destination (?)
Querying full reverse path...
0 172.16.25.9
-1 172.16.25.9 PIM/MBGP Reached RP/Core [198.32.163.0/24]
-2 172.16.25.10 PIM/MBGP Reached RP/Core [198.32.163.0/24]
-3 ogig-den.oregon-gigapop.net (198.32.163.13) [AS 4600]
PIM Reached RP/Core [198.32.163.64/26]
-4 0car-0gw.oregon-gigapop.net (198.32.163.26) [AS 4600]
PIM [198.32.163.64/26]
Jack_3640#
As you can see, the outputs differ very little, but it is important to see how the paths are established.
From the first sample output, no group or destination was specified, so the router strictly
used RPF to calculate the path from the source to the router. In the other output, a group
address was specified. This caused the router to specifically use the existing forwarding tree for
group 224.2.243.55 to get back to the router.
These tools can be useful to determine connectivity as well as the effectiveness of the placement
of RPs and multicast sources. There are other show commands that can aid you as well,
but they are not related to the topic of this chapter.