IP组播故障排除指南

内容前言前提条件需求 使用的组件 惯例背景信息由于 RPF 故障，路由器未向主机转发多播数据包诊断问题 可能的修正由于源端 TTL 设置，路由器未向主机转发多播数据包诊断问题 可能的修正由于路由器的 TTL 阈值，路由器未转发多播数据包诊断问题 可能的修正 多个成本相等的路径造成多余的返回路径转发行为诊断问题可能的修正 为什么没有在所有可用的等价路径之间进行 IP 多播负载均衡？ 可能的修正为什么在路由器上收到IP多播“INVALID_RP_JOIN”错误消息? 诊断问题 - 第 1 部分诊断问题 - 第 2 部分CGMP 不能防止多播数据包泛洪诊断问题 观察 可能的修正由于源端/接收端的放置问题，CGMP不能防止多播数据包泛洪诊断问题可能的修正CGMP 不能防止某些组地址的多播数据包泛洪可能的修正收到重复的多播数据包流原因 1可能的修复方法 1原因 2可能的修复方法 2 原因 3可能的修复方法 3多播数据包为什么被丢弃?原因 1可能的修复方法 1原因 2可能的修复方法 2前言本文介绍 IP 多播的常见问题和解决方案前提条件需求本文档没有任何特定的要求使用的组件本文档不限于特定的软件和硬件版本惯例有关文档规则的详细信息，请参阅 Cisco 技术提示规则。背景信息在排除多播路由故障时，最主要的问题是源地址。多播有一个反向路径转发检查(RPF检查) 的概念。当多播数据包到达某个接口时，RPF进程将检查以确保此传入接口是单播路由用于 抵达多播数据包源的传出接口。 此 RPF 检查进程将防止出现环路。 组播路由不转发数据包， 除非数据包的source通过反向路径转发(RPF)检查。数据包通过此RPF检查后，多播路由 将仅根据目标地址转发数据包。类似单播路由，组播路由有几份可用的协议，例如独立于协议的组播密集模式(PIM-DM)，PIM 稀疏模式(PIM-SM)，距离矢量组播路由协议(DVMRP)、组播边界网关协议(MBGP)和组播源发现 协议(MSDP)。本文将通过案例研究详细介绍各种问题的解决过程。您将了解用于迅速查明 问题的命令并学习如何解决问题。 这里列出的案例研究适用于各种协议，除非特别说明。由于 RPF 故障，路由器未向主机转发多播数据包此部分提供一解决方案给IP多播反向路径转发(RPF)失败的常见问题。我们以下面的网络图 为例。2.1.1.1Host ASourceRouter 72aSending to 224.1.1.1在上图中，多播数据包从 IP 地址为 1.1.1.1 的服务器进入路由器 75a 的 E0/0 并发送到 组 224.1.1.1 。 这称为 (S,G) 或 (1.1.1.1, 224.1.1.1) 。诊断问题直接连接到路由器 75a 的主机将接收该多播馈送，但直接连接到路由器 72a 的主机不会进 行接收。 首先，发出 show ip mroute 224.1.1.1 命令查看路由器 75a 的状况。 该命令将 检查组地址 224.1.1.1 的多播路由 (mroute)：75a#show ip mroute 224.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - PrunedR - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPT M - MSDP created entry, X - Proxy Join Timer RunningA - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: DIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list: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: TAIncoming interface: Ethernet0/0, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00由于该路由器运行的是PIM密集模式协议(D标志表明这是密集模式)，因此请忽略*,G条 目而只关注 S,G 条目。 该条目表明多播数据包来自地址为 1.1.1.1 的服务器并发送到多播 组 224.1.1.1。 数据包在 Ethernet0/0 接口传入并在 Ethernet0/1 接口转发出去。 这是 一个完美的方案。发出 show ip pim neighbor 命令以查看路由器 72a 是否将上游路由器 (75a) 显示为 PIM 邻居：ip22-72a#show ip pim neighborPIM Neighbor TableNeighbor AddressInterfaceUptimeExpiresVerMode2.1.1.1Ethernet3/12d00h00:01:15v2从 show ip pim neighbor 命令的输出看， PIM 邻居看起来一切正常。使用 show ip mroute 命令查看路由器 72a 是否具有良好的多播路由：ip22-72a#show ip mroute 224.1.1.1IP Multicast Routing Table Flags:D-Dense,S-Sparse,B-BidirGroup,s-SSMGroup,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 TunnelY - Joined MDT-data group, y - Sending to MDT-data groupOutgoing interface flags: H - Hardware switched, A - Assert winner Timers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DCIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet3/1, Forward/Dense, 00:10:42/00:00:00Ethernet3/2, Forward/Dense, 00:10:42/00:00:00(1.1.1.1, 224.1.1.1), 00:01:10/00:02:48, flags:Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0Outgoing interface list:Ethernet3/1, Forward/Dense, 00:01:10/00:00:00Ethernet3/2, Forward/Dense, 00:00:16/00:00:00ip22-72a#通过 show ip mroute 224.1.1.1 命令可以发现，传入接口为 Ethernet2/0 而不是预期的 Etheret3/1。发出 show ip mroute 224.1.1.1 count 命令以查看该组是否有任何多播流量抵达路由器 72a 以及接下来发生的情况：ip22-72a#show ip mroute 224.1.1.1 countIP Multicast Statistics3 routes using 2032 bytes of memory2 groups, 0.50 average sources per groupForwarding Counts: Pkt Count/Pkts per second/AvgPkt Size/Kilobits per secondOther counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)Group: 224.1.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471Source: 1.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0 ip22-72a#从 Other 计数中可以看到流量由于 RPF 故障而被丢弃： total 471 drops, due to RPF failure - 471发出 show ip rpf 命令以查看是否有 RPF 错误：ip22-72a#show ip rpf 1.1.1.1RPF information for ? (1.1.1.1)RPF interface: Ethernet2/0RPF neighbor: ? (0.0.0.0)RPF route/mask: 1.1.1.1/32RPF type: unicast (static)RPF recursion count: 0Doing distance-preferred lookups across tables ip22-72a#Cisco IOS以这种方式计算RPF接口。RPF信息的可能源包括单播路由表、MBGP路由表、 DVMRP 路由表和静态多播路由表。计算 RPF 接口时，主要使用管理距离确定 RPF 计算所基 于的信息源。 具体规则如下：在所有以前的RPF数据源中搜索源IP地址的匹配项。如果使用共享树，则使用RP地 址而不是源地址。如果找到多个匹配路由，则使用管理距离最短的路由。 如果管理距离相等，则使用以下优先顺序：1. 静态多播路由2. DVMRP 路由3. MBGP 路由4. 单播路由 如果某个路由在同一个路由表中有多个条目，则使用最长的匹配路由。show ip rpf 1.1.1.1命令输出表明RPF接口为E2/0,但传入接口应该是E3/1。发出 show ip route 1.1.1.1 命令以查看 RPF 接口为什么与预期接口不同。ip22-72a#show ip route 1.1.1.1Routing entry for 1.1.1.1/32Known via static, distance 1, metric 0 (connected)Routing Descriptor Blocks:* directly connected, via Ethernet2/0Route metric is 0, traffic share count is 1从此 show ip route 1.1.1.1 命令的输出中可以看到有一个静态 /32 路由,它导致选择了 错误的接口作为 RPF 接口。发出某些 debug 命令进行进一步调试：ip22-72a#debug ip mpacket 224.1.1.1*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数据包自 E3/1 传入,这是正确的。 然而,由于这不是单播路由表用于进行 RPF 检查的接 口,因此出现掉包。注意： 调试数据包具有一定危险。 数据包调试会触发非常占用 CPU 资源的多播数据包交 换进程。 此外,数据包调试还会产生大量输出,由于向控制台端口输出过慢,从而可能导致 将路由器完全挂起。 在调试数据包之前,切记要禁用向控制台的日志输出,并启用将日志输 出到内存缓冲区。 为此,需配置 nologgingconsole 和 logging buffered debugging 。 可 以使用 show logging 命令查看调试结果。可能的修正您可以更改单播路由表以满足此要求,也可以添加静态多播路由以强制多播的 RPF 使用特定 接口,而不管单播路由表的设置如何。 添加静态多播路由：ip22-72a(config)#ip mroute 1.1.1.1 255.255.255.255 2.1.1.1 此静态多播路由表明，要到达地址 1.1.1.1，RPF 将使用 2.1.1.1 作为下一跳，其传出接口 为 E3/1 。ip22-72a#show ip rpf 1.1.1.1RPF information for ? (1.1.1.1)RPF interface: Ethernet3/1RPF neighbor: ? (2.1.1.1)RPF route/mask: 1.1.1.1/32RPF type: static mrouteRPF recursion count: 0Doing distance-preferred lookups across tablesshow ip mroute 和 debug ip mpacket 的输出一切正常，show ip mroute count 中的发送 数据包数增加了，并且 HostA 收到数据包。ip22-72a#show ip mroute 224.1.1.1IP Multicast Routing TableFlags: 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 A - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJCIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00Ethernet3/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: CTAIncoming interface: Ethernet3/1, RPF nbr 2.1.1.1, MrouteOutgoing interface list:Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00ip22-72a#show ip mroute 224.1.1.1 countIP Multicast Statistics3 routes using 2378 bytes of memory2 groups, 0.50 average sources per groupForwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per secondOther counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)Group: 224.1.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019Source: 1.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0ip22-72a#show ip mroute 224.1.1.1 countIP Multicast Statistics3 routes using 2378 bytes of memory2 groups, 0.50 average sources per groupForwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per secondOther counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)Group: 224.1.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026Source: 1.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0 ip22-72a#ip22-72a#debug ip mpacket 224.1.1.1*Jan 14 10:18:29.951: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward*Jan 14 10:18:29.999: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward*Jan 14 10:18:30.051: IP: s=1.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward由于源端 TTL 设置，路由器未向主机转发多播数据包 因为存活时间(TTL)值消耗到零，此部分提供一解决方案给IP多播数据包常见问题不转发的。 由于多播应用的情况较多，因此这个问题很常见。多播应用主要设计用于LAN,因此会将TTL 设置为一个较低的值，甚至为 1。 我们以下面的网络图为例。SourceSending to 224.1.1.1诊断问题在上图中，路由器 A 并不将来自源的数据包转发至路由器 B 所直接连接的接收方。查看路 由器 A 的 show ip mroute 命令的输出以检查多播路由状态：ROUTERA#show ip mrouteIP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - PrunedR - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPTM - MSDP created entry, X - Proxy Join Timer RunningA - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCLIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00(*, 224.1.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: DIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00您可以忽略上述输出中的 224.0.1.40，因为所有路由器都会加入此自动 RP 发现组。 但是 这里没有为 224.1.1.1 列出源。 除了“*, 224.1.1.1”外，您还应当看到“1.1.1.1, 224.1.1.1”。发出show ip rpf命令发现它是否是反向路径转发(RPF)发货：ROUTERA#show ip rpf 1.1.1.1RPF information for ? (1.1.1.1)RPF interface: Ethernet0/0RPF neighbor: ? (0.0.0.0) - directly connectedRPF route/mask: 1.1.1.0/24RPF type: unicast (connected)RPF recursion count: 0Doing distance-preferred lookups across tables从上面的输出可以看出这不是 RPF 问题。 RPF 检查正确表明 E0/0 对应于源 IP 地址。使用 show ip pim interface 命令检查接口是否配置了 PIM：ROUTERA#show ip pim interfaceAddressDRInterface1.1.1.2Ethernet0/01.1.1.22.1.1.1Ethernet0/12.1.1.2Version/ModeNbrQueryCountIntvlv2/Sparse-Dense030v2/Sparse-Dense230输出一切正常，因此这不是问题所在。 使用 show ip mroute active 命令检查路由器是否 识别出任何活动流量：ROUTERA#show ip mroute activeActive IP Multicast Sources - sending = 4 kbps根据上面的输出，路由器并未识别出任何活动流量。ROUTERA#debug ip mpacketIP multicast packets debugging is on或许接收方没有发送任何互联网组管理协议(IGMP)报告(加入)组的224.1.1.1。您可以使用 show ip igmp group 命令检查它：ROUTERB#show ip igmp group IGMP Connected Group MembershipGroup AddressReporter224.0.1.40224.1.1.1InterfaceEthernet1/1Ethernet1/2Uptime00:34:3400:30:02Expiresnever00:02:45Last2.1.1.23.1.1.2224.1.1.1 已在 E1/2 加入，这是正确的。PIM 密集模式是一个泛洪和修剪协议，因此没有加入，但是有嫁接。 由于路由器 B 未从路 由器 A 接收到泛洪，因此它并不知道向何处发送嫁接。您可以使用嗅探器捕捉和 show ip traffic 命令进行检查以查看是否是 TTL 问题：ROUTERA#show ip trafficIP statistics:Rcvd: 248756 total, 1185 local destination0 format errors, 0 checksum errors, 63744 bad hop count0 unknown protocol, 0 not a gateway0 security failures, 0 bad options, 0 with options 上面的输出显示有 63744 个坏跳计数。 每次键入此命令时，坏跳计数都将增加。 这是一个 强烈信号，表明发送方使用 TTL=1 发送数据包，而路由器 A 将其衰减为零。 这导致坏跳计 数字段不断增加。可能的修正要解决此问题，需要增加 TTL。 这要在发送方的应用级别进行设置。 有关详细信息，请参 阅您的多播应用说明手册。完成设置后，路由器 A 将如下所示：ROUTERA#show ip mrouteIP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - PrunedR - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPTM - MSDP created entry, X - Proxy Join Timer RunningA - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCLIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00(*, 224.1.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: DIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00(1.1.1.1, 224.1.1.1), 00:19:24/00:02:59, flags: TAIncoming interface: Ethernet0/0, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00这是您希望的输出。在路由器 B 上，您会看到：ROUTERB#show ip mrouteIP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - PrunedR - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPTM - MSDP created entry, X - Proxy Join Timer RunningA - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCLIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00(*, 224.1.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJCIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00(1.1.1.1, 224.1.1.1), 00:17:46/00:02:59, flags: CTAIncoming interface: Ethernet1/1, RPF nbr 2.1.1.1Outgoing interface list:Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00由于路由器的 TTL 阈值，路由器未转发多播数据包此部分为常见的由于 TTL 阈值设置过低而导致 IP 多播流量未能到达接收方的问题提供了 一个解决方案。 我们以下面的网络图为例。诊断问题在上图中，接收方未收到来自源的多播数据包。 在源和路由器 75a 之间可能有多个路由器 首先查看路由器75a，因为它直接连接到接收方。ip22-75a#show ip mroute 224.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - PrunedR - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPTM - MSDP created entry, X - Proxy Join Timer RunningA - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJCIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00(1.1.1.1, 224.1.1.1), 00:01:02/00:01:57, flags: CTAIncoming interface: Ethernet0/0, RPF nbr 0.0.0.0 Outgoing interface list:Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00上面的输出表明，路由器 75a 将数据包从 Ethernet0/1 转出。 要绝对确定路由器 75a 是 否转发了数据包，请只为此源和多播组执行 debug：ip22-75a#configure terminalEnter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 1.1.1.1 host 224.1.1.1 ip22-75a(config)#endip22-75a#debug ip mpacket 101IP multicast packets debugging is on for access list 101 ip22-75a#*Jan 17 09:04:08.714: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied*Jan 17 09:04:08.762: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied*Jan 17 09:04:08.814: IP: s=1.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied上面的 debug 消息表明路由器 75a 并未转发多播数据包，因为已达 TTL 阈值。 检查路由 器配置以查看是否能找到原因。 下面的输出表明了问题所在：interface Ethernet0/1ip address 2.1.1.1 255.255.255.0ip pim sparse-dense-modeip multicast ttl-threshold 15路由器的 TTL 阈值为 15，但这并不意味着任何大于 15 的 TTL 都不会予以发送。 事实恰 恰相反。 该应用使用 TTL 15 进行发送。 当它到达路由器 75a 时，多播数据包的 TTL 将 小于 15。ip multicast ttl-threshold 命令意味着 TTL 低于指定阈值（本例中为 15）的任 何数据包都不会进行转发。 该命令通常用于提供一个界限，以防止内部多播流量流到 Intranet 以外。可能的修正可以使用 ip multicast ttl-threshold 命令的 no 格式删除该命令，这将恢复默 认 TTL 阈值 0 ；也可以降低 TTL 阈值以便能够传递流量。多个成本相等的路径造成多余的返回路径转发行为 这区分显示组播源的等价路径如何能引起不需要的回程路径转发（RPF）行为。此外还会说明 如何配置 IP 多播以避免这种行为。 我们以下面的网络图为例。诊断问题在上图中，路由器 75b 有三个等价路径返回到源 （1.1.1.1），并且它选择的 RPF 首选链路 并不是您所希望的。当面对指向源的多个等价路径时，IP多播会选择其独立多播协议（PIM）邻居具有最高IP 地址的接口作为传入接口，然后将修剪发送给其他链路上的 PIM 邻居。可能的修正要更改 IP 多播选择作为其传入接口的接口，可执行下列操作之一：只在希望多播流经的接口上配置PIM,这意味着要牺牲多播冗余。更改子网，以使最高IP地址位于您希望作为多播主链路的链路上。创建一个从所需多播接口传出的静态多播路由（mroute），这意味着要牺牲多播冗余。为举例说明，我们将创建一个静态多播路由。在安装静态多播路由之前，您会在下面的输出中看到路由表为源地址 1.1.1.1 提供了三个等 价路由。 RPF 信息表明 RPF 接口为 E1/3：ip22-75b#show ip route 1.1.1.1Routing entry for 1.1.1.0/24Known via ospf 1, distance 110, metric 20, type intra area Redistributing via ospf 1Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks:* 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3Route metric is 20, traffic share count is 12.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1Route metric is 20, traffic share count is 13.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2Route metric is 20, traffic share count is 1ip22-75b#show ip rpf 1.1.1.1RPF information for ? (1.1.1.1)RPF interface: Ethernet1/3RPF neighbor: ? (4.1.1.1)RPF route/mask: 1.1.1.0/24RPF type: unicast (ospf 1)RPF recursion count: 0Doing distance-preferred lookups across tablesip22-75b#show ip mroute 224.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - PrunedR - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPTM - MSDP created entry, X - Proxy Join Timer RunningA - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode(*, 224.1.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJCIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00(1.1.1.1, 224.1.1.1), 01:30:35/00:02:59, flags: CTIncoming interface: Ethernet1/3, RPF nbr 4.1.1.1Outgoing interface list:Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32 Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42配置了静态多播路由后，您会在此输出中看到 RPF 接口已更改为 E1/1：ip22-75b#configure terminalEnter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 2.1.1.1 ip22-75b(config)#endip22-75b#show ip rpf 1.1.1.1RPF information for ? (1.1.1.1)RPF interface: Ethernet1/1RPF neighbor: ? (2.1.1.1)RPF route/mask: 1.1.1.1/0RPF type: static mrouteRPF recursion count: 0Doing distance-preferred lookups across tablesip22-75b#show ip route 1.1.1.1Routing entry for 1.1.1.0/24Known via ospf 1, distance 110, metric 20, type intra area Redistributing via ospf 1Last update from 3.1.1.1 on Ethernet1/2, 00:26:21 ago Routing Descriptor Blocks:* 4.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3 Route metric is 20, traffic share count is 12.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1 Route metric is 20, traffic share count is 13.1.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2 Route metric is 20, traffic share count is 1ip22-75b#show ip mroute 224.1.1.1IP Multicast Routing TableFlags: D - Dense, S - Sparse, C - Connected, L - Local, P - PrunedR - RP-bit set, F - Register flag, T - SPT-bit set, J - Join SPTM - MSDP created entry, X - Proxy Join Timer RunningA - Advertised via MSDPTimers: Uptime/ExpiresInterface state: Interface, Next-Hop or VCD, State/Mode (*, 224.1.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJCIncoming interface: Null, RPF nbr 0.0.0.0Outgoing interface list:Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00(1.1.1.1, 224.1.1.1), 01:31:30/00:02:59, flags: CTIncoming interface: Ethernet1/1, RPF nbr 2.1.1.1, Mroute Outgoing interface list:Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28为什么没有在所有可用的等价路径之间进行 IP 多播负载均衡？ 此部分为配置 IP 多播以便在所有可用等价路径上均衡负载的常见问题提供了一个解决方 案。 我们以下面的网络图为例。在上图中，路由器 75b 有三个等价路径返回到源 (1.1.1.1)。 您希望在全部三条链路上均 衡多播流量。可能的修正如同您在多条相等成本路径看到了请导致以上不需要的返回路径转发行为的部分，独立于协 议的组播(PIM)只选择回程路径转发(RPF)检查的一个接口并且修剪其他。这意味着不会进行 负载均衡。 要进行负载均衡，需要从冗余链路中删除 PIM 并在路由器 75a 与路由器 75b 之 间创建一条隧道。 然后您可以在链路级别进行负载均衡，并且 IP 将通过隧道运行。面是隧道的配置。路由器75a interface TunnelOip address 6.1.1.1 255.255.255.0 ip pim sparse-dense-modetunnel source Ethernet0/0tu nnel des tination 5.1.1.1 interface Ethernet0/0ip address 1.1.1.2 255.25