You want to use debug functions to isolate a problem with multicast forwarding.
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 following command:
Router#debug ip mpacket 239.5.5.55
The other commonly useful multicast debug command looks at IGMP information:
Router#debug ip igmp
As with all debugging commands, you need to be extremely careful because sometimes the sheer volume of the output can overwhelm the router. 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:
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 the TokenRing0 and Ethernet0 interfaces. A short time later, it received another packet for this group with the same source address from TokenRing0. However it didn't forward this packet along because it was not received on the RPF interface. That is, the router looked in its routing table, realized that this was not the way that it should have received this packet, and dropped it to avoid loops.
The router then receives a multicast packet for this same group on interface TokenRing0, but this time it has a source address of 192.168.254.5. It forwards this packet 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 make 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 group information in this trace is for 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 joined successfully. The device 192.168.1.100, on the other hand, has been a member of 239.255.255.250 for some time and 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, then deletes it.
 |
|
|
| Top |