When troubleshooting multicast routing, the primary concern is the source address. Multicast has a concept of Reverse Path Forwarding check (RPF check). When a multicast packet arrives on an interface, the RPF process checks to ensure that this incoming interface is the outgoing interface used by unicast routing to reach the source of the multicast packet. This RPF check process prevents loops. Multicast routing does not forward a packet unless the source of the packet passes a reverse path forwarding (RPF) check. Once a packet passes this RPF check, multicast routing forwards the packet based only upon the destination address.
Like unicast routing, multicast routing has several available protocols, such as Protocol Independent Multicast dense mode (PIM-DM), PIM sparse mode (PIM-SM), Distance Vector Multicast Routing Protocol (DVMRP), Multicast Border Gateway Protocol (MBGP), and Multicast Source Discovery Protocol (MSDP). The case studies in this document walk you through the process of troubleshooting various problems. You will see which commands are used to quickly pinpoint the problem and learn how to resolve it. The case studies listed here are generic across the protocols, except where noted.
This section provides a solution to the common problem of an IP multicast Reverse Path Forwarding (RPF) failure. This network diagram is used as an example.
In the figure above, multicast packets come into E0/0 of Router 75a from a server whose IP address is 1.1.1.1 and sends to group 224.1.1.1. This is known as an (S,G) or (1.1.1.1, 224.1.1.1).
Hosts directly connected to Router 75a receive the multicast feed, but hosts directly connected to Router 72a do not. First, issue the show ip mroute 224.1.1.1 command to see what is going on with Router 75a. This command examines the multicast route (mroute) for the group address 224.1.1.1:
|
|
75a#<strong>show ip mroute 224.1.1.1</strong> |
|
|
IP Multicast Routing Table Flags: D - Dense, S - Sparse, 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 |
|
|
Interface state: Interface, Next-Hop or VCD, State/Mode |
|
|
(*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D |
|
|
Incoming interface: Null, RPF nbr 0.0.0.0 |
|
|
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 |
|
|
(1.1.1.1, 224.1.1.1), 00:01:23/00:03:00, flags: TA |
|
|
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0 |
|
|
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00 |
Since the router is running PIM dense mode (we know it is dense mode because of the D flag), ignore the *,G entry and focus on the S,G entry. This entry tells you that the multicast packets are sourced from a server whose address is 1.1.1.1, which sends to a multicast group of 224.1.1.1. The packets are coming in the Ethernet0/0 interface and are forwarded out the Ethernet0/1 interface. This is a perfect scenario.
Issue the show ip pim neighbor command to see whether Router 72a is showing the upstream router (75a) as a PIM neighbor:
|
|
ip22-72a#<strong>show ip pim neighbor</strong> |
|
|
PIM Neighbor Table Neighbor Address Interface |
|
|
Uptime Expires Ver Mode 2.1.1.1 |
|
|
Ethernet3/1 2d00h 00:01:15 v2 |
From the show ip pim neighbor command output, the PIM neighborship look good.
Use this show ip mroute command to see whether Router 72a has good mroute:
|
|
ip22-72a#<strong>show ip mroute 224.1.1.1</strong> |
|
|
IP 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 group |
|
|
Outgoing interface flags: H - Hardware switched, A - Assert winner |
|
|
Interface state: Interface, Next-Hop or VCD, State/Mode |
|
|
(*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC |
|
|
Incoming interface: Null, RPF nbr 0.0.0.0 |
|
|
Ethernet3/1, Forward/Dense, 00:10:42/00:00:00 |
|
|
Ethernet3/2, Forward/Dense, 00:10:42/00:00:00 (1.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags: |
|
|
<strong>Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0</strong> |
|
|
Ethernet3/1, Forward/Dense, 00:01:10/00:00:00 |
|
|
Ethernet3/2, Forward/Dense, 00:00:16/00:00:00 ip22-72a# |
You can see from the show ip mroute 224.1.1.1 command that the incoming interface is Ethernet2/0, while Etheret3/1 is expected.
Issue the show ip mroute 224.1.1.1 count command to see if any multicast traffic for this group arrives to the Router 72a and what happens next:
|
|
ip22-72a#<strong>show ip mroute 224.1.1.1 count</strong> |
|
|
IP Multicast Statistics3 routes using 2032 bytes of memory |
|
|
2 groups, 0.50 average sources per group |
|
|
Forwarding Counts: Pkt Count/Pkts per second/Avg |
|
|
Pkt Size/Kilobits per second |
|
|
<strong>Other counts: Total/RPF failed/Other drops(OIF-null,rate-limit etc)</strong> |
|
|
Group: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471 |
|
|
Source: 1.1.1.1/32, Forwarding: 0/0/0/0, <strong>Other: 471/471/0</strong>ip22-72a# |
You can see from the Other counts that traffic gets dropped due to RPF failure: total 471 drops, due to RPF failure – 471…
Issue the show ip rpf <source> command to see if there is an RPF error:
|
|
ip22-72a#<strong>show ip rpf 1.1.1.1</strong> |
|
|
RPF information for ? (1.1.1.1) |
|
|
RPF interface: Ethernet2/0 |
|
|
RPF neighbor: ? (0.0.0.0) |
|
|
RPF route/mask: 1.1.1.1/32 |
|
|
RPF type: unicast (static) |
|
|
Doing distance-preferred lookups across tables |
Cisco IOS® calculates the RPF interface in this way. Possible sources of RPF information are Unicast Routing Table, MBGP routing table, DVMRP routing table and Static Mroute table. When you calculate the RPF interface, primarily administrative distance is used to determine exactly which source of information the RPF calculation is based on. The specific rules are:
-
All preceding sources of RPF data are searched for a match on the source IP address. When using Shared Trees, the RP address is used instead of the source address.
-
If more than one matching route is found, the route with the lowest administrative distance is used.
-
If the admin distances are equal, then this order of preference is used:
-
Static mroutes
-
DVMRP routes
-
MBGP routes
-
Unicast routes
-
If multiple entries for a route occur within the same route table, the longest match route is used.
The show ip rpf 1.1.1.1 command output shows the RPF interface being E2/0, but the incoming interface should be E3/1.
Issue the show ip route 1.1.1.1 command to see why the RPF interface is different from what was expected.
|
|
ip22-72a#<strong>show ip route 1.1.1.1</strong> |
|
|
Routing entry for 1.1.1.1/32 |
|
|
Known via "static", distance 1, metric 0 (connected) |
|
|
Routing Descriptor Blocks: * directly connected, via Ethernet2/0 |
|
|
Route metric is 0, traffic share count is 1 |
You can see from this show ip route 1.1.1.1 command output that there is a static /32 route, which makes the wrong interface to be chosen as RPF interface.
Issue some further debug commands:
|
|
ip22-72a#<strong>debug ip mpacket 224.1.1.1</strong> |
|
|
*Jan 14 09:45:32.972: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface |
|
|
*Jan 14 09:45:33.020: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface |
|
|
*Jan 14 09:45:33.072: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface |
|
|
*Jan 14 09:45:33.120: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 len 60, not RPF interface |
The packets are coming in on E3/1, which is correct. However, they are being dropped because that is not the interface the unicast routing table uses for the RPF check.
Note: Debugging packets is dangerous. Pakcet debugging triggers process switching of the multicast pakcets, which is CPU intensive. Also, packet debugging can produce huge output which can hang the router completely due to slow output to the console port. Befor debugging packet, special care must be taken to disable logging output to the console, and enable logging to the memory buffer. In order to achieve this, configure no logging console and logging buffered debugging. The results of the debug can be seen with the show logging command.
You can either change the unicast routing table to satisfy this requirement or you can add a static mroute to force multicast to RPF out a particular interface, regardless of what the unicast routing table states. Add a static mroute:
|
|
ip22-72a(config)#<strong>ip mroute 1.1.1.1 255.255.255.255 2.1.1.1</strong> |
This static mroute states that to get to the address 1.1.1.1, for RPF, use 2.1.1.1 as the next hop, which is out interface E3/1.
|
|
ip22-72a#<strong>show ip rpf 1.1.1.1</strong> |
|
|
RPF information for ? (1.1.1.1) |
|
|
RPF interface: Ethernet3/1 |
|
|
RPF neighbor: ? (2.1.1.1) |
|
|
RPF route/mask: 1.1.1.1/32 |
|
|
Doing distance-preferred lookups across tables |
|
|
The output of show ip mroute and debug ip mpacket looks good, |
|
|
the number of sent packets in the show ip mroute count increases and HostA receives packets. |
|
|
ip22-72a#show ip mroute 224.1.1.1 <br />IP Multicast Routing Table <br />Flags: D - Dense, S - Sparse, C - Connected, L - Local, P - Pruned <br /> R - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT <br /> M - MSDP created entry, X - Proxy Join Timer Running <br /> A - Advertised via MSDP <br />Timers: Uptime/Expires <br />Interface state: Interface, Next-Hop or VCD, State/Mode |
|
|
(*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC <br /> Incoming interface: Null, RPF nbr 0.0.0.0 <br /> Outgoing interface list: <br /> Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00 <br /> Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00 |
|
|
(1.1.1.1, 224.1.1.1), 00:00:48/00:02:59, flags: CTA <br /> Incoming interface: Ethernet3/1, RPF nbr 2.1.1.1, Mroute <br /> Outgoing interface list: <br /> Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00 |
|
|
ip22-72a#show ip mroute 224.1.1.1 count<br />IP Multicast Statistics<br />3 routes using 2378 bytes of memory<br />2 groups, 0.50 average sources per group<br />Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second<br />Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)<br /> <br />Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019<br /> Source: 1.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0<br /> <br />ip22-72a#show ip mroute 224.1.1.1 count<br />IP Multicast Statistics<br />3 routes using 2378 bytes of memory<br />2 groups, 0.50 average sources per group<br />Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second<br />Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)<br /> <br />Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026<br /> Source: 1.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0<br />ip22-72a#<br /> |
|
|
ip22-72a#debug ip mpacket 224.1.1.1 <br />*Jan 14 10:18:29.951: IP: s=1.1.1.1 (Ethernet3/1) <br />d=224.1.1.1 (Ethernet3/2) len 60, mforward <br />*Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) <br />d=224.1.1.1 (Ethernet3/2) len 60, mforward <br />*Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) <br />d=224.1.1.1 (Ethernet3/2) len 60, mforward |
文章评论