《 IP組播故障排除指南》

輸入某些進一步的debug命令：

ip22-72a#debug ip mpacket 224.1.1.1 
*Jan 14 09:45:32.972: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.020: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.072: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface 
*Jan 14 09:45:33.120: IP: s=10.1.1.1 (Ethernet3/1) 
d=224.1.1.1 len 60, not RPF interface

資料包在E3/1上進入，這是正確的。但是，它們會被丟棄，因為單播路由表不使用該介面進行RPF檢查。

注意：調試資料包是危險的。資料包調試會觸發組播資料包的處理交換，這會佔用大量CPU。此外，資料包調試會生成巨大的輸出，由於向控制檯埠輸出的速度緩慢，導致路由器完全掛起。在調試資料包之前，必須特別注意停用到控制檯的日誌輸出並啟用到記憶體緩衝區的日誌記錄。為此，需配置no logging console 和logging buffered debugging。可以使用show logging命令檢視調試結果。

可能的修正

您可以更改單播路由表以滿足此要求，也可以增加靜態mroute，強制組播到RPF從特定介面發出，而不管單播路由表是什麼狀態。增加靜態mroute：

ip22-72a(config)#ip mroute 10.1.1.1 255.255.255.255 10.2.1.1

此靜態mroute說明，要到達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中的傳送資料包數增加了，並且HostA收到資料包。

ip22-72a#show ip mroute 224.1.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 (*, 224.1.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, 224.1.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 224.1.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: 224.1.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 224.1.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: 224.1.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 224.1.1.1 *Jan 14 10:18:29.951: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:29.999: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward *Jan 14 10:18:30.051: IP: s=10.1.1.1 (Ethernet3/1) d=224.1.1.1 (Ethernet3/2) len 60, mforward

由於源的TTL設定，路由器不會將組播資料包轉發到主機

本節針對因為存留時間(TTL)值減至零而無法轉送的IP多點傳送封包這一常見問題，提供解決方案。這是一個常見的問題，因為有許多多播應用。這些組播應用主要針對LAN使用而設計，因此將TTL設定為低值甚至1。以下列網路圖表作為範例。 

主要針對LAN用途設計的組播應用示例

診斷問題

在上圖中，路由器A不會將資料包從源轉發到直接連線的路由器B。檢視路由器A的  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 (*, 224.1.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 

您可以忽略輸出中的224.0.1.40，因為所有路由器都加入此自動RP發現組。但是，沒有列出224.1.1.1的源。除了「*， 224.1.1.1」以外，您無法看到「10.1.1.1， 224.1.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地址。

使用show ip pim interface命令檢查介面是否配置了PIM：

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 

也許接收方沒有傳送組224.1.1.1的任何Internet組管理協定(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 224.1.1.1 Ethernet1/2 00:30:02 00:02:45 10.3.1.2 

224.1.1.1已加入E1/2，這沒問題。

PIM密集模式是一種泛洪和修剪協定，因此沒有連線，但有移植。由於路由器B尚未收到來自路由器A的泛洪，因此它不知道將嫁接傳送到何處。

您可以使用嗅探器捕捉和 show ip traffic  命令進行檢查以檢視是否是TTL問題：

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 (*, 224.1.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, 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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將資料包從Ethernet0/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 224.1.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=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.762: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.1.1 len 60, threshold denied *Jan 17 09:04:08.814: IP: s=10.1.1.1 (Ethernet0/0) d=224.1.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，但這並不表示不會傳送大於TTL 15的任何內容。事實上，事實恰恰相反。應用程式傳送時的TTL為15。當它到達路由器75a時，組播資料包的TTL小於15。

ip multicast ttl-threshold <value>命令意味著TTL低於指定閾值（本例中為15）的任何資料包都不會進行轉發。此命令通常用於提供邊界以防止內部組播流量從內部網中流出。

可能的修正

請使用ip multicast ttl-threshold <value>命令的no形式刪除命令（這將恢復預設TTL閾值0），或者降低TTL閾值以便能夠傳遞流量。

多個等價路徑會導致不想要的RPF行為

本部分說明到達組播源的等價路徑如何導致不想要的RPF行為。本文還介紹了如何配置IP組播以避免此行為。以下網路圖為例。

組播源的等價路徑會導致不想要的RPF行為

診斷問題

在圖中，路由器75b具有返回源(10.1.1.1)的三個等價路徑，並且它選擇了您不想作為首選鏈路的鏈路作為RPF鏈路。

當面臨到源的多條等價路徑時，IP組播會選擇具有最高IP地址的PIM鄰居的介面作為傳入介面，然後向其他鏈路上的PIM鄰居傳送修剪。

可能的修正

為了更改IP組播選擇的介面作為其傳入介面，您可以執行以下操作之一：

• 僅在希望組播流經的介面上配置PIM，這意味著您將失去組播冗餘。

• 更改子網，使最高的IP地址位於要作為主組播鏈路的鏈路上。

• 建立指向首選組播介面的靜態組播路由(mroute)，這意味著您將失去組播冗餘。

例如，建立了靜態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 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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組播資料流之前，請配置每個資料包的CEF負載均衡，否則GRE資料包無法每個資料包進行負載均衡。有關在組播環境中載入共用的其他方法，請參閱透過ECMP載入IP組播資料流。

配置IP組播以在所有可用等價路徑間實現負載均衡

在圖中，路由器75b具有返回源(10.1.1.1)的三個等價路徑。您想要在所有三個鏈路上對組播流量進行負載均衡。

可能的修正

如多個等價路徑導致不需要的RPF行為部分所述，獨立多播協定(PIM)只為RPF檢查選擇一個介面並放棄其他介面。這意味著不會執行負載均衡。為了進行負載均衡，您需要從冗餘鏈路中刪除PIM，並在路由器75a和路由器75b之間建立隧道。然後，您可以在鏈路級別進行負載均衡，IP透過隧道運行。

以下是通道的組態。

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

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 224.1.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 (*, 224.1.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, 224.1.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 224.1.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 (*, 224.1.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, 224.1.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 (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 00:56:15: %PIM-6-INVALID_RP_JOIN: Received (*, 224.1.1.1) Join from 10.1.6.2 for invalid RP 10.1.5.4 

Cisco IOS Software System Error Messages（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多播路由命令中，該命令宣告「要配置路由器以接受指定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 pim accept-rp語句中的IP地址，如下所示：

變更此陳述式：

ip pim accept-rp 10.2.2.2 8

為此：

ip pim accept-rp 10.1.5.4 8

您還可以更改語句以接受自動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是否是224.1.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#

224.1.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加入資料包。檢查下游路由器為什麼將加入傳送到router2，而非：

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#

如您所見，router3具有靜態配置的RP資訊並指向router2，這是不正確的。這解釋了為什麼router3向router2傳送RP-Join。

可能的修正

將router2設為224.1.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#

收到重複的多播資料包流

原因1

當兩台路由器在密集模式下配置時，會收到重複的組播資料包。在密集模式下，裝置會定期泛洪流。在泛洪後，它會修剪出不需要蒸汽的介面。兩個路由器也透過斷言過程確定誰是轉發者。每次計時器關閉時，就會發生這種情況，直到此過程完成，兩台路由器都會轉發資料流。這將導致應用程式接收重複的多播流。

可能的修正1

如果為其中一台路由器配置了多播路由，並將另一台路由器配置為上游的RP，則可以解決此問題。對其進行配置，以便在資料流進入路由器之前將資料流轉換為稀疏模式。這樣可以防止重複的資料包到達應用程式。確保沒有重複的資料包到達終端主機不是網路責任的一部分。處理重複的資料包並忽略不需要的資料，是應用程式職責的一部分。

原因2

此問題可能發生在Cisco Catalyst 6500交換機中，這些交換機配置為出口組播複製模式，可透過移除和重新插入任何板卡[OIR]來觸發。在OIR之後，Fabric Port Of Exit [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漏洞ID CSCeg28814影響的版本，以便永久解決問題。

注意：只有已註冊的思科使用者才能訪問思科內部工具和錯誤資訊。

原因3

如果終端主機或伺服器上的接收端縮放(RSS)設定已停用，也會發生此問題。

可能的修正3

RSS設定可加快多個CPU之間的資料傳輸速度。在終端主機或伺服器上啟用RSS設定。

為什麼組播資料包被丟棄？

原因1

當多播流量流動時，您可能會在介面上看到過多的刷新和輸入資料包丟棄。您可以使用show interface命令檢查流量。

Switch#show interface gigabitethernet 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 <group-name>命令時，將進行進程交換。如果組播資料包在任何介面上進行了進程交換，它將佔用更多CPU，因為它會強制所有資料包在該組中進行進程交換。您可以運行 show buffers input-interface 命令並檢查異常大小。

Switch#show buffers input-interface gigabitethernet 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 <group-name>命令，而不使用ip igmp join-group <group-name>命令。

注意：由於先前的問題，您可能會看到大約90%的CPU使用率較高。當您使用這些可能的修正程式解決問題時，CPU會恢復正常。

相關資訊

• 使用CLI工具排除組播網路故障
• 組播快速入門配置指南

• 啟用ECMP多點傳送負載分割 

• IP多點傳送技術支援
• IP路由協定支援
• Cisco技術支援與下載