IP组播故障排除指南
目录
简介
本文介绍 IP 多播的常见问题和解决方案。
先决条件
要求
本文档没有任何特定的要求。
使用的组件
本文档不限于特定的软件和硬件版本。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。
背景信息
当您排除组播路由故障时，主要关注点是源地址。组播具有“逆向转发” (RPF) 检查这一功能。当组播数据包到达接口时，RPF 进程会执行检查以确保此传入接口是单播路由所使用的传出接口，以便访问组播数据包的源。此 RPF 检查进程将防止出现环路。组播路由不会转发数据包，除非数据包的源通过了 RPF 检查。数据包通过此 RPF 检查后，多播路由将仅根据目标地址转发数据包。
与单播路由一样，组播路由也具有多种可用的协议，例如协议无关组播密集模式 (PIM-DM)、PIM 稀疏模式 (PIM-SM)、距离矢量组播路由协议 (DVMRP)、组播边界网关协议 (MBGP) 和组播源发现协议 (MSDP)。本文档中的各案例研究将引导您完成针对各种问题的故障排除过程。您可以看到使用哪些命令来快速查明问题并了解如何解决它。这里列出的案例研究适用于各种协议，除非特别说明。
由于 RPF 故障，路由器未向主机转发多播数据包
本节介绍如何解决常见的 IP 组播 RPF 故障问题。我们以下面的网络图为例。
网络图组播RPF故障示例
在此图中，组播数据包从IP地址为10.1.1.1的服务器进入路由器75a的E0/0并发送到组10.224.1.1。这称为 (S,G) 或 (10.1.1.1, 10.224.1.1)。
诊断问题
直接连接到路由器 75a 的主机将接收该多播馈送，但直接连接到路由器 72a 的主机不会进行接收。首先，输入 show ip mroute 224.1.1.1 命令，检查路由器75a上的活动。该命令将检查组地址 10.224.1.1 的多播路由 (mroute)：
75a#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:01:23/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
(10.1.1.1, 10.224.1.1), 00:01:23/00:03:00, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:23/00:00:00
由于路由器在 PIM 密集模式（D 标志表示路由器处于密集模式）下运行，因此请忽略 *,G 条目并关注 S,G 条目。该条目表明多播数据包来自地址为 10.1.1.1 的服务器并发送到多播组 10.224.1.1。数据包进入以太网接口 0/0，并从以太网接口 0/1 转发出去。这是一个完美的方案。
输入 show ip pim neighbor 命令，以查看路由器72a是否将上游路由器(75a)显示为PIM邻居：
ip22-72a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet3/1 2d00h 00:01:15 v2
从 show ip pim neighbor 命令输出，PIM邻居关系看起来良好。
输入 show ip mroute 命令，查看路由器72a是否具有良好的mroute:
ip22-72a#show ip mroute 10.224.1.1
IP Multicast Routing Table
Flags: 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
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:10:42/stopped, RP 0.0.0.0, flags: DC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:10:42/00:00:00
Ethernet3/2, Forward/Dense, 00:10:42/00:00:00
(10.1.1.1, 10.224.1.1), 00:01:10/00:02:48, flags:
Incoming interface: Ethernet2/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Dense, 00:01:10/00:00:00
Ethernet3/2, Forward/Dense, 00:00:16/00:00:00
ip22-72a#
您可以从 show ip mroute 10.224.1.1 命令传入接口为Ethernet2/0，而预期为Etheret3/1。
输入 show ip mroute 10.224.1.1 count 命令，以便查看此组是否有任何组播流量到达路由器72a以及接下来会发生什么情况：
ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 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
Other counts: Total/RPF failed/Other drops(OIF-null,
rate-limit etc)
Group: 10.224.1.1, Source count: 1, Packets forwarded: 0, Packets received: 471
Source: 10.1.1.1/32, Forwarding: 0/0/0/0, Other: 471/471/0
ip22-72a#
从Other计数中可以看到，流量因RPF故障而丢弃：因RPF故障而丢弃的总数为471 - 471...
输入 show ip rpf 命令查看是否存在RPF错误：
ip22-72a#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet2/0 RPF neighbor: ? (0.0.0.0) RPF route/mask: 10.1.1.1/32 RPF type: unicast (static) RPF recursion count: 0 Doing distance-preferred lookups across tables ip22-72a#
Cisco IOS® 以这种方式计算 RPF 接口。可能的 RPF 信息来源包括单播路由表、MBGP 路由表、DVMRP 路由表和静态 Mroute 表。在计算 RPF 接口时，主要使用管理距离来确定 RPF 计算过程所依据的信息源。具体规则如下：
-
系统会搜索所有以前的RPF数据来源，以查找源IP地址的匹配项。使用共享树时，将使用 RP 地址而不是源地址。
-
如果找到多个匹配路由，则使用管理距离最小的路由。
-
如果管理距离相等，则使用以下优先顺序：
-
静态多播路由
-
DVMRP 路由
-
MBGP 路由
-
单播路由
-
-
如果某个路由在同一个路由表中有多个条目，则使用最长的匹配路由。
此 show ip mroute 224.1.1.1 命令输出显示RPF接口为E2/0，但传入接口必须为E3/1。
输入 show ip mroute 224.1.1.1 命令，以查看RPF接口与预期接口不同的原因。
ip22-72a#show ip route 10.1.1.1 Routing entry for 10.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
从此 show ip route 10.1.1.1 命令的输出中可以看到有一个静态 /32 路由，它导致选择了错误的接口作为 RPF 接口。
进一步输入一些调试命令：
ip22-72a#debug ip mpacket 10.224.1.1 *Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface *Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) d=10.224.1.1 len 60, not RPF interface
数据包在 E3/1 上传入，这是正确的。但是，这些数据包将被丢弃，因为这不是单播路由表用于执行 RPF 检查的接口。
可能的修正
您可以更改单播路由表以满足此要求，也可以添加静态 mroute 以强制组播从特定接口进行 RPF，而不用管单播路由表状态如何。添加静态多播路由：
ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1
此静态路由表明，要到达RPF的地址10.1.1.1，请使用10.2.1.1作为出接口E3/1的下一跳。
ip22-72a#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet3/1 RPF neighbor: ? (10.2.1.1) RPF route/mask: 10.1.1.1/32 RPF type: static mroute RPF recursion count: 0 Doing distance-preferred lookups across tables
的输出 show ip mroute 和 debug ip mpacket 看起来不错，中发送的数据包数量 show ip mroute count 增加，主机A接收数据包。
ip22-72a#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:01:15/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet3/1, Forward/Sparse-Dense, 00:01:15/00:00:00
Ethernet3/2, Forward/Sparse-Dense, 00:00:58/00:00:00
(10.1.1.1, 10.224.1.1), 00:00:48/00:02:59, flags: CTA
Incoming interface: Ethernet3/1, RPF nbr 10.2.1.1, Mroute
Outgoing interface list:
Ethernet3/2, Forward/Sparse-Dense, 00:00:48/00:00:00
ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2378 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 10.224.1.1, Source count: 1, Packets forwarded: 1019, Packets received: 1019
Source: 10.1.1.1/32, Forwarding: 1019/1/100/0, Other: 1019/0/0
ip22-72a#show ip mroute 10.224.1.1 count
IP Multicast Statistics
3 routes using 2378 bytes of memory
2 groups, 0.50 average sources per group
Forwarding Counts: Pkt Count/Pkts per second/Avg Pkt Size/Kilobits per second
Other counts: Total/RPF failed/Other drops(OIF-null, rate-limit etc)
Group: 10.224.1.1, Source count: 1, Packets forwarded: 1026, Packets received: 1026
Source: 10.1.1.1/32, Forwarding: 1026/1/100/0, Other: 1026/0/0
ip22-72a#
ip22-72a#debug ip mpacket 10.224.1.1
*Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
*Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1)
d=10.224.1.1 (Ethernet3/2) len 60, mforward
由于源端 TTL 设置，路由器未向主机转发多播数据包
本节介绍如何解决因生存时间 (TTL) 值递减为零而无法转发 IP 组播数据包这一常见问题。由于多播应用的情况较多，因此这个问题很常见。多播应用主要设计用于 LAN，因此会将 TTL 设置为一个较低的值，甚至为 1。以下面的网络图为例。
主要针对LAN使用设计的组播应用示例
诊断问题
在上图中，路由器A不会将数据包从源转发到直接连接的接收方的路由器B。查看的输出 show ip mroute 命令，以查看组播路由状态：
ROUTERA#show ip mroute
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 00:00:01/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:00:01/00:00:00
(*, 10.224.1.1), 00:00:02/00:02:57, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:00:02/00:00:00
可以忽略输出中的 10.224.0.40，因为所有路由器都加入此 Auto-RP 发现组。但是这里没有为 10.224.1.1 列出源。除“*, 10.224.1.1”外，您还可以看到“10.1.1.1, 10.224.1.1”。
输入 show ip rpf 命令以查看这是否是 RPF 问题：
ROUTERA#show ip rpf 10.1.1.1 RPF information for ? (10.1.1.1) RPF interface: Ethernet0/0 RPF neighbor: ? (0.0.0.0) - directly connected RPF route/mask: 10.1.1.1/24 RPF type: unicast (connected) RPF recursion count: 0 Doing distance-preferred lookups across tables
从输出来看，这不是RPF问题。RPF检查正确指出了E0/0以到达源IP地址。
检查接口上是否配置了PIM和 show ip pim interface 指令：
ROUTERA#show ip pim interface
Address Interface Version/Mode Nbr Query DR
Count Intvl
10.1.1.2 Ethernet0/0 v2/Sparse-Dense 0 30 10.1.1.2
10.2.1.1 Ethernet0/1 v2/Sparse-Dense 2 30 10.2.1.2
输出一切正常，因此这不是问题所在。检查路由器是否识别到任何活动流量 show ip mroute active 指令：
ROUTERA#show ip mroute active Active IP Multicast Sources - sending >= 4 kbps
输出内容表明，路由器无法识别任何活动流量。
ROUTERA#debug ip mpacket IP multicast packets debugging is on
也许接收方不发送组10.224.1.1的任何互联网组管理协议(IGMP)报告（加入）。您可以通过 show ip igmp group 指令：
ROUTERB#show ip igmp group IGMP Connected Group Membership Group Address Interface Uptime Expires Last Reporter 224.0.1.40 Ethernet1/1 00:34:34 never 10.2.1.2 10.224.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2
10.224.1.1已在E1/2上加入，这没问题。
PIM 密集模式是一个泛洪和修剪协议，因此没有加入，但是有嫁接。由于路由器 B 未从路由器 A 接收到泛洪，因此它并不知道向何处发送嫁接。
您可以检查嗅探器捕获是否是TTL问题，也可以通过 show ip traffic 指令：
ROUTERA#show ip traffic
IP statistics:
Rcvd: 248756 total, 1185 local destination
0 format errors, 0 checksum errors, 63744 bad hop count
0 unknown protocol, 0 not a gateway
0 security failures, 0 bad options, 0 with options
输出中显示了 63744 次不良跳数。每次键入此命令时，坏跳计数都将增加。这明确表示，发送方在 TTL 为 1（路由器 A 将其递减为零）的情况下发送数据包。这导致坏跳计数字段不断增加。
可能的修正
要解决此问题，您需要增大 TTL。这要在发送方的应用级别进行设置。有关详细信息，请参阅您的多播应用说明手册。
完成设置后，路由器 A 将如下所示：
ROUTERA#show ip mroute
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:16:32/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 01:16:32/00:00:00
(*, 10.224.1.1), 00:28:42/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:28:42/00:00:00
(10.1.1.1, 10.224.1.1), 00:19:24/00:02:59, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:19:24/00:00:00
这是您希望的输出。
在路由器 B 上，您会看到：
ROUTERB#show ip mroute
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 224.0.1.40), 01:23:57/00:00:00, RP 0.0.0.0, flags: DJCL
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/1, Forward/Sparse-Dense, 01:23:57/00:00:00
(*, 10.224.1.1), 01:19:26/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/1, Forward/Sparse-Dense, 01:19:26/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:19:26/00:00:00
(10.1.1.1, 10.224.1.1), 00:17:46/00:02:59, flags: CTA
Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1
Outgoing interface list:
Ethernet1/2, Forward/Sparse-Dense, 00:17:46/00:00:00
由于路由器的 TTL 阈值，路由器未转发多播数据包
本节介绍如何解决因 TTL 阈值设得过低而使 IP 组播流量无法到达接收方这一常见问题。我们以下面的网络图为例。
TTL阈值太低，因此IP组播流量无法到达接收器
诊断问题
在上图中，接收方无法接收来自源的组播数据包。源设备和路由器75a之间可以有多个路由器。首先查看路由器 75a，因为它直接连接到接收方。
ip22-75a#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:32:05/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:08:17/00:00:00
(10.1.1.1, 10.224.1.1), 00:01:02/00:01:57, flags: CTA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse-Dense, 00:01:02/00:00:00
输出内容显示，路由器 75a 从以太网接口 0/1 转发数据包。为了绝对确保路由器75a转发数据包，请打开 debug 仅用于此源和组播组：
ip22-75a#configure terminal Enter configuration commands, one per line. End with CNTL/Z. ip22-75a(config)#access-list 101 permit udp host 10.1.1.1 host 10.224.1.1 ip22-75a(config)#end ip22-75a#debug ip mpacket 101 IP multicast packets debugging is on for access list 101 ip22-75a# *Jan 17 09:04:08.714: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=10.224.1.1 len 60, threshold denied
此 debug 消息表明路由器75a未转发组播数据包，因为已达到TTL阈值。查看路由器配置，看看是否可以找到原因。下面的输出表明了问题所在：
interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ip pim sparse-dense-mode ip multicast ttl-threshold 15
路由器的 TTL 阈值为 15，但这并不意味着任何大于 15 的 TTL 都不会予以发送。事实恰恰相反。应用是在 TTL 为 15 的情况下发送的。当它到达路由器 75a 时，多播数据包的 TTL 将小于 15。
此 ip multicast ttl-threshold
命令意味着TTL低于指定阈值（在本例中为15）的任何数据包都不会被转发。此命令通常用于提供边界，以防止内部组播流量从内联网流出。
可能的修正
删除 ip multicast ttl-threshold
命令，该命令将恢复为默认的TTL阈值0，或者降低TTL阈值，以便流量通过。
多条等价路径导致意外 RPF 行为
本节介绍组播源的等价路径如何导致意外 RPF 行为。此外，还介绍如何配置 IP 组播以避免此行为。我们以下面的网络图为例。
组播源的等价路径导致不必要的RPF行为
诊断问题
在图中，路由器75b有三条等价路径可返回源(10.1.1.1)，它选择您不希望作为首选链路的链路作为RPF链路。
当面对指向源的多个等价路径时，IP 多播会选择其独立多播协议 (PIM) 邻居具有最高 IP 地址的接口作为传入接口，然后将修剪发送给其他链路上的 PIM 邻居。
可能的修正
要更改 IP 组播选为其传入接口的接口，可采取以下任一项操作：
-
只在希望多播流经的接口上配置 PIM，这意味着要牺牲多播冗余。
-
更改子网，以使最高 IP 地址位于您希望作为多播主链路的链路上。
-
创建一个指出首选组播接口的静态组播路由 (mroute)，这意味着您将失去组播冗余。
为举例说明，我们将创建一个静态多播路由。
在安装静态 mroute 前，此输出中显示，路由表中有源地址 10.1.1.1 的三条等价路由。RPF 信息表明 RPF 接口为 E1/3：
ip22-75b#show ip route 10.1.1.1
Routing entry for 10.1.1.1/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2
Route metric is 20, traffic share count is 1
ip22-75b#show ip rpf 10.1.1.1
RPF information for ? (10.1.1.1)
RPF interface: Ethernet1/3
RPF neighbor: ? (10.4.1.1)
RPF route/mask: 10.1.1.1/24
RPF type: unicast (ospf 1)
RPF recursion count: 0
Doing distance-preferred lookups across tables
ip22-75b#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 01:30:34/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:30:34/00:00:00
Ethernet1/1, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/3, Forward/Sparse-Dense, 00:24:22/00:00:00
(10.1.1.1, 10.224.1.1), 01:30:35/00:02:59, flags: CT
Incoming interface: Ethernet1/3, RPF nbr 10.4.1.1
Outgoing interface list:
Ethernet1/1, Prune/Sparse-Dense, 01:30:35/00:02:32
Ethernet1/4, Forward/Sparse-Dense, 01:30:35/00:00:00
Ethernet1/2, Prune/Sparse-Dense, 00:24:22/00:02:42
配置静态 mroute 后，此输出中显示，RPF 接口已更改为 E1/1：
ip22-75b#configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
ip22-75b(config)#ip mroute 0.0.0.0 0.0.0.0 10.2.1.1
ip22-75b(config)#end
ip22-75b#show ip rpf 10.1.1.1
RPF information for ? (10.1.1.1)
RPF interface: Ethernet1/1
RPF neighbor: ? (10.2.1.1)
RPF route/mask: 10.1.1.1/0
RPF type: static mroute
RPF recursion count: 0
Doing distance-preferred lookups across tables
ip22-75b#show ip route 10.1.1.1
Routing entry for 10.1.1.1/24
Known via "ospf 1", distance 110, metric 20, type intra area
Redistributing via ospf 1
Last update from 10.3.1.1 on Ethernet1/2, 00:26:21 ago
Routing Descriptor Blocks:
* 10.4.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/3
Route metric is 20, traffic share count is 1
10.2.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/1
Route metric is 20, traffic share count is 1
10.3.1.1, from 10.0.119.66, 00:26:21 ago, via Ethernet1/2
Route metric is 20, traffic share count is 1
ip22-75b#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 01:31:29/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:31:29/00:00:00
Ethernet1/1, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/2, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/3, Forward/Sparse-Dense, 00:25:17/00:00:00
(10.1.1.1, 10.224.1.1), 01:31:30/00:02:59, flags: CT
Incoming interface: Ethernet1/1, RPF nbr 10.2.1.1, Mroute
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 01:31:30/00:00:00
Ethernet1/2, Prune/Sparse-Dense, 00:25:17/00:01:47
Ethernet1/3, Prune/Sparse-Dense, 00:00:31/00:02:28
为什么没有在所有可用的等价路径之间进行 IP 多播负载均衡？
本节提供一个解决方案，解决有关如何配置 IP 组播以在所有可用等价路径上实现负载均衡这一常见问题。我们以下面的网络图为例。
配置IP组播以实现所有可用等价路径的负载均衡
在图中，路由器75b具有三个返回源(10.1.1.1)的等价路径。您希望在全部三条链路上均衡多播流量。
可能的修正
如多条等价路径导致意外 RPF 行为一节中所述，协议无关组播 (PIM) 仅会选择一个接口用于进行 RPF 检查，并删除其他接口。这意味着不会进行负载均衡。要进行负载均衡，需要从冗余链路中删除 PIM 并在路由器 75a 与路由器 75b 之间创建一条隧道。然后您可以在链路级别进行负载均衡，并且 IP 将通过隧道运行。
下面是隧道的配置。
| 路由器 75a |
|---|
interface Tunnel0 ip address 10.6.1.1 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet0/0 tunnel destination 10.5.1.1 ! interface Ethernet0/0 ip address 10.1.1.2 255.255.255.0 ip pim sparse-dense-mode ! interface Ethernet0/1 ip address 10.2.1.1 255.255.255.0 ! interface Ethernet0/2 ip address 10.3.1.1 255.255.255.0 ! interface Ethernet0/3 ip address 10.4.1.1 255.255.255.0 |
| 路由器 75b |
|---|
interface Tunnel0 ip address 10.6.1.2 255.255.255.0 ip pim sparse-dense-mode tunnel source Ethernet1/4 tunnel destination 10.1.1.2 ! interface Ethernet1/1 ip address 10.2.1.2 255.255.255.0 ! interface Ethernet1/2 ip address 10.3.1.2 255.255.255.0 ! interface Ethernet1/3 ip address 10.4.1.2 255.255.255.0 ! interface Ethernet1/4 ip address 10.5.1.1 255.255.255.0 ip pim sparse-dense-mode ! ip mroute 0.0.0.0 0.0.0.0 Tunnel0 |
配置隧道后，输入 show ip mroute 命令，以便查看组的组播路由(mroute):
ip22-75a#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 02:40:31/00:02:59, RP 0.0.0.0, flags: D
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00
(10.1.1.1, 10.224.1.1), 02:40:32/00:03:29, flags: TA
Incoming interface: Ethernet0/0, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:20:55/00:00:00
ip22-75b#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 02:42:20/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Tunnel0, Forward/Sparse-Dense, 00:22:53/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 02:42:20/00:00:00
(10.1.1.1, 10.224.1.1), 00:22:53/00:02:59, flags: CT
Incoming interface: Tunnel0, RPF nbr 10.6.1.1, Mroute
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:22:53/00:00:00
为了检查组播数据是否在三条链路上均等地平衡负载，请查看路由器 75a 的接口数据。
传入接口为 9000 位/秒：
ip22-75a#show interface e0/0 . . 5 minute input rate 9000 bits/sec, 20 packets/sec
三个传出接口每个均显示 3000 位/秒：
ip22-75a#show interface e0/1 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/2 . . 5 minute output rate 3000 bits/sec, 7 packets/sec ip22-75a#show interface e0/3 . . 5 minute output rate 3000 bits/sec, 7 packets/sec
在路由器上收到IP组播“INVALID_RP_JOIN”错误消息时
此部分为常见的 IP 多播“INVALID_RP_JOIN”错误消息提供了一个解决方案。
诊断问题 - 第 1 部分
在交汇点 (RP) 上收到此错误消息：
00:55:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 10.224.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4
Cisco IOS软件系统错误消息文档解释了导致此错误的原因：下游PIM路由器发送了共享树的加入消息，此路由器不想接受该消息。这一行为表明此路由器只允许下游路由器加入特定 RP。
怀疑它是过滤设备。您需要查看一下路由器的配置：
interface Ethernet0/0 ip address 10.1.5.4 255.255.255.0 ip pim sparse-dense-mode ! ip pim accept-rp 10.2.2.2 8 ip pim send-rp-announce Ethernet0/0 scope 15 ip pim send-rp-discovery scope 15 ! access-list 8 permit 224.0.0.0 0.255.255.255
什么是 accept-rp 配置中的语句应如何完成？在IP Multicast Routing Commands（IP组播路由命令）中，它指出“要将路由器配置为接受发往指定RP和特定组列表的加入或修剪，请使用 ip pim accept-rp 全局配置命令。要删除这项检查，可使用此命令的 no 格式。”
当您删除 ip pim accept-rp 命令，消息消失。已找到了导致问题的命令，但是如果要在配置中保留该命令，该怎么办？您可以允许错误的RP地址。输入 show ip pim rp mapping 命令查看正确的RP地址：
ip22-75a#show ip pim rp mapping
PIM Group-to-RP Mappings
This system is an RP (Auto-RP)
This system is an RP-mapping agent
Group(s) 224.0.0.0/4
RP 10.1.5.4 (?), v2v1
Info source: 10.1.5.4 (?), via Auto-RP
Uptime: 01:00:48, expires: 00:02:07
根据输出，10.1.5.4是唯一通过自动RP或其他方式获取的RP。然而，此路由器是组 224.0.0.0/4 的唯一 RP。所以， pim accept-rp 配置中的语句错误。
可能的修正
解决方案是更正中的IP地址 ip pim accept-rp 语句如下：
将此语句：
ip pim accept-rp 10.2.2.2 8
执行此更改：
ip pim accept-rp 10.1.5.4 8
您还可以更改语句以接受 auto-rp 缓存中的内容，并确保访问列表（在本示例中为 8）允许必要的组播组范围。示例如下：
ip pim accept-rp auto-rp access-list 8 permit 224.0.0.0 0.255.255.255
诊断问题 - 第 2 部分
此错误消息出现在 router2 上。
router2#
*Aug 12 15:18:17.891:
%PIM-6-INVALID_RP_JOIN: Received (*, 224.0.1.40)
Join from 0.0.0.0 for invalid RP 10.2.1.1
检查router2是否是组10.224.1.1的RP:
router2#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:21:26, expires: 00:02:24
router2#
10.224.1.1 的 RP 是 10.1.1.1。
检查它是否是 router2 的其中一个接口：
router2#show ip interface brief Interface IP-Address OK? Method Status Protocol Ethernet0/0 10.1.1.2 YES NVRAM up up Ethernet1/0 10.2.1.1 YES NVRAM up up Ethernet2/0 unassigned YES NVRAM administratively down down router2#
由于router2不是RP，因此它一定未收到此RP-Join数据包。检查下游路由器为何向router2发送了Join，但不得这样做：
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:24:30, expires: 00:02:16
Group(s): 224.0.0.0/4, Static-Override
RP: 10.2.1.1 (?)
router3#
可以看见，路由器 3 已静态配置了 RP 信息并指向路由器 2，这是不正确的。这解释了路由器 3 将 RP-Join 发送到路由器 2 的原因。
可能的修正
使router2成为组10.224.1.1的RP，或者更改router3的配置，使其引用正确的RP地址。
router3#show run | i rp ip pim rp-address 10.2.1.1 override router3#configure terminal Enter configuration commands, one per line. End with CNTL/Z. router3(config)#no ip pim rp-address 10.2.1.1 override router3(config)#exit router3#
在更正router3的配置后，router3会引用正确的RP地址，错误消息会停止。
router3#show ip pim rp map
PIM Group-to-RP Mappings
Group(s) 224.0.0.0/4
RP 10.1.1.1 (?), v2v1
Info source: 10.1.1.1 (?), elected via Auto-RP
Uptime: 00:30:45, expires: 00:02:02
router3#
CGMP 不能防止多播数据包泛洪
本节介绍当未在特定子网上的所有路由器上启用思科组管理协议 (CGMP) 时出现的意外组播数据包泛洪，以及如何避免此问题。我们以下面的网络图为例。
未启用思科组管理协议(CGMP)
诊断问题
在此图中，Catalyst 5000 交换机 A 中的静态 CAM 表未显示任何已填充的正确端口。配置了 CGMP 的路由器未发送 CGMP 数据包。
CGMP set cgmp enable 命令。 ip cgmp 命令。但是，当R1和R2的接口配置为 show multicast group 命令已发出：
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- Total Number of Entries = 0
此命令的输出必须显示其上配置了CGMP的路由器的每个端口（端口2/3）及其上存在感兴趣的接收器的每个端口（端口2/6）。由于列出了0，因此您可以假设所有端口都会不必要地泛洪组播流量，无论它们是否需要。
观察结果
检查路由器 75a 上是否有任何独立多播协议 (PIM) 邻居：
ip22-75a#show ip pim neighbor PIM Neighbor Table Neighbor Address Interface Uptime Expires Ver Mode 10.2.1.1 Ethernet0/2 00:07:41 00:01:34 v2
此输出内容显示，路由器 75a 能够将路由器 75b 视为通过交换机 A 的有效 PIM 邻居。
现在检查是否在路由器上收到正确的组播路由 (mroute) 信息：
ip22-75a#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:14:55/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:55/00:00:00
(10.1.1.1, 10.224.1.1), 00:14:56/00:02:59, flags: CTA
Incoming interface: Ethernet0/1, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/2, Forward/Sparse-Dense, 00:14:56/00:00:00
输出显示，路由器 75a 将组播数据包从 E0/2 转发到交换机 A。此输出显示，路由器 75b 正确获取并转发组播数据包：
ip22-75b#show ip mroute 10.224.1.1
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
A - Advertised via MSDP
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(*, 10.224.1.1), 00:17:57/00:02:59, RP 0.0.0.0, flags: DJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet1/3, Forward/Sparse-Dense, 00:17:57/00:00:00
Ethernet1/4, Forward/Sparse-Dense, 00:17:57/00:00:00
(10.1.1.1, 10.224.1.1), 00:00:35/00:02:59, flags: CTA
Incoming interface: Ethernet1/3, RPF nbr 10.2.1.2
Outgoing interface list:
Ethernet1/4, Forward/Sparse-Dense, 00:00:35/00:00:00
从Switch A的角度来看，您会看到路由器75a关闭了端口2/3。
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 Total Number of Entries = 1
到目前为止一切正常。输入一些 debug 命令，以了解您能发现什么：
ip22-75a#debug ip cgmp CGMP debugging is on *Feb 8 12:45:22.206: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:45:22.206: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:46:22.234: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:46:22.234: GDA 0000.0000.0000, USA 00d0.ff2f.a002 *Feb 8 12:47:22.262: CGMP: Sending self Join on Ethernet0/2 *Feb 8 12:47:22.262: GDA 0000.0000.0000, USA 00d0.ff2f.a002
在输出中，0000.0000.0000 是全组地址，在路由器发送 CGMP 加入/离开消息时使用，以便交换机可以填充路由器端口。GDA 代表介质访问控制 (MAC) 级别格式的组目的地址。USA 代表单播源地址。这是与所生成的此 CGMP 消息对应的，生成 IGMP 报告的主机的地址。在本例中，这是路由器 75a 接口 E0/2 的 MAC 地址。路由器75a的E0/2的MAC地址与 show interface 命令，如下所示：
ip22-75a#show interface e0/2 Ethernet0/2 is up, line protocol is up Hardware is cxBus Ethernet, address is 00d0.ff2f.a002 (bia 00d0.ff2f.a002)
此外，当您在 debug ip igmp 命令已打开：
*Feb 8 12:51:41.854: IGMP: Received v2 Report from 10.2.1.3 (Ethernet0/2) for 10.224.1.1
然而，随后不会看到来自路由器 75a 的对应 CGMP 数据包。这意味着路由器 75a 会接收 IGMP 报告，但不会生成必要的 CGMP 数据包（用以帮助交换机 A 获知要阻止的端口）。如果路由器 75a 是 IGMP 查询方，则这是所期望的。路由器 75a 的此输出告诉我们为什么没有发生预期行为：
ip22-75a#show ip igmp interface e0/2 Ethernet0/2 is up, line protocol is up Internet address is 10.2.1.2/24 IGMP is enabled on interface Current IGMP version is 2 CGMP is enabled IGMP query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP max query response time is 10 seconds Last member query response interval is 1000 ms Inbound IGMP access group is not set IGMP activity: 3 joins, 1 leaves Multicast routing is enabled on interface Multicast TTL threshold is 0 Multicast designated router (DR) is 10.2.1.2 (this system) IGMP querying router is 10.2.1.1 No multicast groups joined
如果同一子网中有两台路由器，并且您为CGMP配置这两台，则只有一台路由器可以发送CGMP数据包。发送CGMP数据包的路由器是查询路由器的IGMP。这意味着该路由器是启用了 IGMP 的路由器中具有最低单播 IP 地址的路由器。
在本例中，路由器 75a 和路由器 75b 都启用了 IGMP（路由器 75b 成为 IGMP 查询路由器），但是只有路由器 75a 启用了 CGMP。由于路由器 75a 不是 IGMP 查询路由器，因此不会发送 CGMP 数据包。
可能的修正
为了解决此问题，您需要在 IGMP 查询路由器上配置 CGMP。本例中是路由器 75b。首先，打开 debug 路由器75b上的命令：
ip22-75b#conf t Enter configuration commands, one per line. End with CNTL/Z. ip22-75b(config)#int e 1/3 ip22-75b(config-if)#ip cgmp ip22-75b(config-if)#end ip22-75b#debug ip cgmp ip22-75b#debug ip igmp *Feb 8 12:58:42.422: IGMP: Received v2 Report from 10.2.1.3 (Ethernet1/3) for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Received IGMP Report on Ethernet1/3 *Feb 8 12:58:42.422: from 10.2.1.3 for 10.224.1.1 *Feb 8 12:58:42.422: CGMP: Sending Join on Ethernet1/3 *Feb 8 12:58:42.422: GDA 0100.5e01.0101, USA 0030.b655.a859
路由器75b从10.2.1.3收到组10.224.1.1的IGMP报告。随后，它为 10.224.1.1 的等价 MAC 连同 10.2.1.3 意向主机的 MAC 地址 (USA) 向交换机 A 发送一个 CGMP“加入”。交换机 A 知道主机位于哪个端口，因此会将其标记为打开并禁用其他端口。
交换机A上现在必须工作：
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4,2/6 Total Number of Entries = 2
现在情况好多了。10.224.1.1(01-00-5e-01-01-01)数据包仅按预期从交换机A上的端口2/3、2/4和2/6发出。向所有其他端口的泛洪已经停止。现在所列的条目总数也是正确的（为 2）。MAC 地址 01-00-5e-00-01-28 映射自多播地址 224.0.1.40，用于 CGMP“自我加入”。
由于源端/接收端的放置问题，CGMP 不能防止多播数据包泛洪
本节提供一个解决方案，解决有关 Catalyst 交换机将流量泛洪到每个端口而不是仅发送到正确主机这一常见问题。我们以下面的网络图为例。
将流量泛洪到每个端口的Catalyst交换机
诊断问题
在此图中，已正确为路由器 75a 和 75b 以及 Catalyst 5000（交换机 A）配置组播和思科组管理协议 (CGMP)。主机将获取组播流量。但是，交换机 A 上的其他每台主机也是如此。交换机 A 会将流量泛洪到每个端口，这意味着 CGMP 不起作用。
的输出 show multicast group 命令A如下所示：
Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 Total Number of Entries = 1
从输出中可以看到，唯一的组是 224.0.1.40，路由器发送 auto-RP 组的 CGMP 自动加入时使用此组。为什么没有其他组？
可能的修正
要理解此解决方案，您需要了解 CGMP 在特定条件下的行为。已启用 CGMP 的路由器向交换机发送 CGMP 加入，以向交换机通知与特定组播组相关的主机。交换机在其 CAM 表中查找这些主机的 MAC 地址，然后将多播数据包从意向主机的端口转发出去并禁止所有其他端口转发多播数据包。
如果路由器所接收的多播数据包的源位于启用了 CGMP 的相同接口上，则它会从启用了 CGMP 的接口发出 CGMP“自我加入”。
例如，如果源与路由器75a和75b位于同一子网(VLAN)(10.2.1.0/24)中，则CGMP将运行良好。当路由器识别来自源的数据包时，它会向交换机发送CGMP自加入，然后交换机将动态获知路由器所在的端口，并阻止所有其他端口转发组播数据包。
如果路由器所接收的 IGMP 报告的源主机位于启用了 CGMP 的相同接口上，则它会从启用了 CGMP 的接口发出 CGMP“加入”。
另一个示例是如果在此 VLAN 中您有需要的主机的情况。在这种情况下，当启用 CGMP 的路由器从与特定组播组相关的主机收到互联网组管理协议 (IGMP) 报告时，路由器将发送 CGMP 加入。加入将指示需加入的主机的介质访问控制 (MAC) 地址，及这些主机要加入的组。然后，Catalyst 5000将检查其CAM表以查找主机MAC地址，将关联的端口放在组播组列表中，并阻止所有其他不感兴趣的端口。
当源主机和感兴趣的主机位于启用CGMP的子网(VLAN)以外的子网时，情况并非如此。来自源的组播数据包不会触发路由器向交换机发送 CGMP 自动加入。因此，数据包到达交换机后将在 VLAN 中泛洪到各处。此场景将持续到 VLAN 中的某个主机（从交换机上的某个端口传出）发送 IGMP 加入。只有在收到 IGMP 报告后，路由器才会发送 CGMP 数据包，进而导致交换机添加适当主机端口作为转发端口，并禁用（除了路由器端口以外的）所有其他端口。
要使CGMP在此传输类型拓扑中工作，您可以将主机添加到与路由器75a和75b相同的VLAN中，如本网络图所示。
将主机添加到与路由器75a和75b相同的VLAN
也可以将源移到路由器 75a 和 75b 所在的相同子网上，如下面的示例所示。
移动与路由器75a和75b位于同一子网的源
将源移到相同的子网中，然后检查交换机 A 的输出：
Console> (enable) show multicast router CGMP enabled IGMP disabled IGMP fastleave disabled Port Vlan --------- ---------------- 2/3 6 2/4 6 Total Number of Entries = 2 '*' - Configured Console> (enable) Console> (enable) show multicast group CGMP enabled IGMP disabled IGMP fastleave disabled GMRP disabled VLAN Dest MAC/Route Des [CoS] Destination Ports or VCs / [Protocol Type] ---- ------------------ ----- ------------------------------------------- 6 01-00-5e-00-01-28 2/3-4 6 01-00-5e-01-01-01 2/3-4 Total Number of Entries = 2
CGMP 不能防止某些组地址的多播数据包泛洪
本节介绍为何某些组播 IP 地址会导致思科组管理协议 (CGMP) 将组播流量泛洪到局域网 (LAN) 上的所有端口。当使用组播组地址 10.225.0.1 时，CGMP 不起作用。它会将多播流从所有交换机端口泛出并浪费带宽。然而，如果将地址更改为 10.225.1.1，CGMP 将会正常发挥作用。您能使用10.225.0.1吗？因为它不是路由协议的注册地址。
可能的修正
首先，我们必须清楚第 3 层多播地址是如何映射到第 2 层多播地址的。所有 IP 组播帧都使用以 24 位前缀“0x0100.5e”开头的 IEEE MAC 层地址。当将第 3 层地址映射到第 2 层地址时，第 3 层组播地址的低位 23 位将映射到 IEEE MAC 地址的低位 23 位。
另外需要了解的是，IP 组播地址具有 28 位的唯一地址空间（32 位减去内含 1110 D 类前缀的前 4 位）。由于只有 23 位插入到 IEEE MAC 地址中，因此会保留 5 位重叠部分。这意味着多个第 3 层多播地址会映射到相同的第 2 层多播地址。
例如：
10.244.0.1 = 1110 0000.0000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001 10.244.128.0 = 1110 0000.1000 0000.0000 0000.0000 0001 in binary low order 23 bits = 000 0000.0000 0000.0000 0001 hex equivalent = 0 0 0 0 0 1 result of mapping = 0x0100.5e00.0001
请注意，在此示例中，10.244.0.1 和 10.244.128.0 均映射到相同的第 2 层组播地址。
现在您已了解如何将第 3 层组播地址映射到第 2 层组播地址，下面继续说明用于解决此问题的特定解决方案。
交换机 A 将组播数据包泛洪到 224.0.0.x，因为这些地址是链路本地地址，并且您希望确保链路本地地址到达局域网 (LAN) 上的所有设备。Catalyst交换机还将组播数据包泛洪到MAC级别不明确的其他组播地址，224.0.0.x（例如，10.244.0.1和10.225.0.1都映射到0100.5e00.0001）。交换机会将多播数据包泛洪到这些本地链路地址而不管是否启用了 CGMP。
因此，多播应用必须避免使用映射到第 2 层多播地址 0100.5e00.00xx 的 D 类地址，其中 xx 可以是十六进制的 00 到 FF。这包括下列 D 类地址：
224.0.0.x (x = 0 to 255) 225.0.0.x . 239.0.0.x 224.128.0.x (x = 0 to 255) 225.128.0.x . 239.128.0.x
收到重复的多播数据包流
原因 1
当在密集模式下配置了两个路由器时就会收到重复的多播数据包。在密集模式下，设备会定期泛洪流。泛洪后，它会修剪掉不需要流的接口。两个路由器也将经历该确认过程并确定哪一个是转发者。每当计时器关闭时都会发生这种情况，直到此过程完成，两台路由器都会转发数据流。这会导致应用程序收到重复的多播流。
可能的修复方法 1
如果将其中一个路由器配置为多播路由，另一个路由器配置为上游 RP，则可以解决此问题。将其配置为在流进入路由器之前将流转换为稀疏模式。这可以防止重复的数据包抵达应用程序。网络并不负责确保不会有重复的数据包抵达终端主机。应用程序将负责处理重复的数据包并忽略不需要的数据。
原因 2
该问题会在 Cisco Catalyst 6500 交换机中出现，这些交换机配置为出口多播复制模式，可通过移除并重新插入任何板卡 [OIR] 进行触发。在 OIR 后，交换矩阵端口出口 [FPOE] 可能会被错误编程，这可导致数据包被定向到错误的交换矩阵出口通道并被发送到错误的线卡。结果是数据包沿环路返回光纤通道，并且当其在正确的板卡上退出时将重复多次。
C6509#show mls ip multicast capability
Current mode of replication is Egress
Auto replication mode detection is ON
Slot Multicast replication capability
1 Egress
2 Egress
3 Egress
4 Egress
5 Egress
6 Egress
7 Egress
可能的修复方法 2
要解决此问题，可以更改为入口复制模式。在从出口复制模式更改为入口复制模式的过程中会出现流量中断，因为要清除并重新安装快捷方式。
mls ip multicast replication-mode ingress
将Cisco IOS软件升级到不受Cisco Bug ID CSCeg28814影响的版本，以便永久解决问题。
注意：只有注册的思科用户才能访问内部思科工具和漏洞信息。
原因 3
如果禁用终端主机或服务器上的接收端扩展 (RSS) 设置，也会发生此问题。
可能的修复方法 3
RSS 设置有利于在多个 CPU 间快速传输数据。请在终端主机或服务器上启用 RSS 设置。
多播数据包为什么被丢弃？
原因 1
当组播流量流动时，您可能会看到接口上出现过多的刷新和输入丢包现象。您可以使用 show interface 命令。
Switch#show interface gi 1/0
!--- Output suppressed
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
Full-duplex, 1000Mb/s, media type is SX
input flow-control is off, output flow-control is on
Clock mode is auto
ARP type: ARPA, ARP Timeout 04:00:00
Last input 00:00:00, output 00:00:00, output hang never
Last clearing of "show interface" counters never
Input queue: 2/75/0/13370328 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
30 second input rate 195000 bits/sec, 85 packets/sec
30 second output rate 1000 bits/sec, 1 packets/sec
L2 Switched: ucast: 53056 pkt, 4728434 bytes - mcast: 235759386 pkt, 66914376970 bytes
L3 in Switched: ucast: 8714263 pkt, 1815426423 bytes - mcast: 1081138213 pkt,
438000092206 bytes mcast
L3 out Switched: ucast: 4939256 pkt, 790351689 bytes mcast: 0 pkt, 0 bytes
1326976857 packets input, 506833655045 bytes, 0 no buffer
Received 1318209538 broadcasts, 0 runts, 0 giants, 1 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
31643944 packets output, 3124494549 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
0 output buffer failures, 0 output buffers swapped out
可能的修复方法 1
对于发现过大流量的接口，可以将 SPT 值设置为无限。
进行如下配置：
Switch(config-if)#ip pim spt-threshold infinity
原因 2
当您使用 ip igmp join-group
命令，它执行进程交换。如果组播数据包在任何接口上进行进程交换，它会消耗更多CPU，因为它会强制所有数据包进行该组的进程交换。您可以运行 show buffers input-interface 命令并检查异常大小。
Switch#show buffers input-interface gi 1/0 Header DataArea Pool Rcnt Size Link Enc Flags Input Output 437C6EAC 8096AE4 Middl 1 434 7 1 280 Gi1/1 None 437C74B4 8097864 Middl 1 298 7 1 280 Gi1/1 None 437C98E4 809C964 Middl 1 434 7 1 280 Gi1/1 None 437CAAFC 809F1E4 Middl 1 349 7 1 280 Gi1/1 None 437CAE00 809F8A4 Middl 1 519 7 1 280 Gi1/1 None !--- Output suppressed
可能的修复方法 2
您可以使用 ip igmp static-group
命令而不是 ip igmp join-group
命令。
相关信息
修订历史记录
| 版本 | 发布日期 | 备注 |
|---|---|---|
2.0 |
26-May-2023 |
重新认证 |
1.0 |
02-Dec-2013 |
初始版本 |
反馈