Debugging Multicast Routing

Problem

You want to use debug functions to isolate problem with multicast forwarding.

Solution

Cisco routers have several useful debug features that you can use to isolate multicast problems. The first is a general command that shows how the router maintains its multicast routing tables when it hears from sources and group members:

Router#debug ip mrouting

You can watch the actual multicast packets for a particular group using the command:

Router#debug ip mpacket 239.5.5.55

And the other commonly useful multicast debug command looks specifically at IGMP information:

Router#debug ip igmp

 

Discussion

As with all debugging commands, you need to be extremely careful because sometimes the sheer volume of the output can overwhelm the router. So it is usually wise to try these commands one at a time, and disable all debugging with the command undebug all before trying the next command.

The first debug command, debug ip mrouting, shows how the router creates, updates, and deletes multicast routing information:

Router#terminal monitor
Router#debug ip mrouting
IP multicast routing debugging is on
Router#
17:20:27: MRT: Create (192.168.5.1/32, 239.5.5.55), RPF Ethernet0/0.0.0.0, PC 0x33A89D8
17:20:43: MRT: Update (*, 224.0.1.40), RPF Null, PC 0x339F96C
17:20:49: MRT: Delete (192.168.3.2/32, 224.0.1.39), PC 0x33AB26A
17:21:43: MRT: Update (*, 224.0.1.40), RPF Null, PC 0x339F96C
17:21:49: MRT: Create (192.168.3.2/32, 224.0.1.39), RPF Ethernet0/192.168.5.1, PC 0x33A89D8
17:22:13: MRT: Delete (*, 224.0.1.1), PC 0x33AB26A
17:22:24: MRT: Create (*, 224.0.1.1), RPF Null, PC 0x33A8890
17:22:46: MRT: Update (*, 224.0.1.40), RPF Null, PC 0x339F96C
17:22:46: MRT: Update (*, 224.0.1.40), RPF Null, PC 0x339F96C

In this example, the first line creates a group entry for 239.5.5.55 with the source 192.168.5.1 in response to receiving a multicast packet from this source. You can also see a number of entries here for the Auto-RP groups, 224.0.1.39 and 224.0.1.39. These are the result of routers chatting amongst themselves to ensure that a stable RP exists for the network.

The next command, debug ip mpacket, shows individual multicast packets. Looking at packet-level debug traces is always particularly dangerous because of the possibility of overwhelming the router. In this example, we have asked the router to show only the group 239.5.5.55, which we have used as an example throughout this chapter:

Router#debug ip mpacket 239.5.5.55
IP multicast packets debugging is on for group 239.5.5.55
May 10 16:18:40.870: IP: s=192.168.5.2 (Ethernet1) d=239.5.5.55 (TokenRing0) len
 114, mforward
May 10 16:18:40.874: IP: s=192.168.5.2 (Ethernet1) d=239.5.5.55 (Ethernet0) len
114, mforward
May 10 16:18:40.878: IP: s=192.168.5.2 (TokenRing0) d=239.5.5.55 len 122, not RP
F interface
May 10 16:18:40.890: IP: s=192.168.254.5 (TokenRing0) d=239.5.5.55 (Ethernet1) l
en 122, mforward
May 10 16:18:40.890: IP: s=192.168.254.5 (TokenRing0) d=239.5.5.55 (Ethernet0) l
en 122, mforward

As you can see, a packet was received on interface Ethernet1 with the source address of 192.168.5.2 for this group. The router immediately turned around and forwarded this packet to interface TokenRing0 and Ethernet0. A short time later, it received another packet for this group with the same source address from TokenRing0. However it doesn't forward this packet along because it was not received on the RPF interface. That is, the router looks in its routing table and realizes that this is not the way that it should have received this packet, so it drops it to avoid loops.

The router then receives a multicast packet for this same group on interface TokenRing0, but this time with a source address of 192.168.254.5. It forwards this packet over to both Ethernet1 and Ethernet0.

It is important to note that this command tells you nothing about group membership. If devices join or leave this group, you will not see them this way. To do that, you need to look at the output of debug ip igmp:

Router#debug ip igmp 
IGMP debugging is on
17:34:17: IGMP: Send v2 Query on Ethernet0 to 224.0.0.1
17:34:18: IGMP: Send v2 Query on Ethernet1 to 224.0.0.1
17:34:18: IGMP: Set report delay time to 8.6 seconds for 224.0.1.40 on Ethernet1
17:34:18: IGMP: Send v2 Query on TokenRing0 to 224.0.0.1
17:34:19: IGMP: Received v2 Report from 192.168.1.104 (Ethernet0) for 239.5.5.55
17:34:21: IGMP: Received v2 Report from 192.168.5.2 (Ethernet1) or 224.0.1.40
17:34:21: IGMP: Cancel report for 224.0.1.40 on Ethernet1
17:34:23: IGMP: Received v2 Report from 192.168.3.2 (TokenRing0) for 239.5.5.55
17:34:24: IGMP: Received v2 Report from 192.168.3.2 (TokenRing0) for 224.0.1.39
17:34:25: IGMP: Received v2 Report from 192.168.3.2 (TokenRing0) for 224.0.1.1
17:34:26: IGMP: Received v2 Report from 192.168.1.100 (Ethernet0) for 239.255.255.250
17:34:27: IGMP: Received v2 Report from 192.168.1.104 (Ethernet0) for 239.5.5.55
17:34:32: IGMP: Received v2 Report from 192.168.1.104 (Ethernet0) for 239.5.5.55

This debug trace shows a couple of interesting events buried in a whole lot of router-to-router multicast chatter, so you have to look carefully at the group addresses to makes sure that you're seeing the interesting data. The group 224.0.0.1 is the All Systems group, which is used for local segment chatter. It is rarely interesting for multicast routing because it is intended to be purely local, and all multicast capable devices are always members. The groups 224.0.1.39 and 224.0.1.40 are used by the Auto-RP protocol to allow routers to share information about the PIM-SM RPs for the network.

So, unless you are trying to debug an Auto-RP problem, the only really interesting information in this trace are the entries for the groups 239.5.5.55 and 239.255.255.250. The device 192.168.1.104 has joined the first group, and sends several IGMP Report packets to make sure that it has successfully joined that group. The device 192.168.1.100, on the other hand, has been a member of 239.255.255.250 for some time, and it sends only a single packet to ensure that it will continue to receive this group.

A short time later, the device 192.168.1.104 leaves the group 239.5.5.55, as shown in the following trace:

17:34:54: IGMP: Received Leave from 192.168.1.104 (Ethernet0) for 239.5.5.55
17:34:54: IGMP: Send v2 Query on Ethernet0 to 239.5.5.55
17:34:55: IGMP: Send v2 Query on Ethernet0 to 239.5.5.55
17:34:57: IGMP: Deleting 239.5.5.55 on Ethernet0

Since this was the last known member of this group on this segment, the router responds to the IGMP Leave message with an IGMP Query. It tries twice to see if there are still any other devices interested in continuing to see this group, and then deletes it.