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的組播組。資料包進入Ethernet0/0介面，然後從Ethernet0/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是否具有良好路由：
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#
您可以從其他計數中看到由於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路由表和靜態路由表。計算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介面。
輸入一些進一步的debug指令：
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檢查的介面。
可能的修正
您可以更改單播路由表以滿足此要求，也可以新增靜態路由，強制組播到RPF通過特定介面，而不管單播路由表處於什麼狀態。新增靜態mroute:
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不會將資料包從源(S)轉發到直接連線的路由器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，因為所有路由器都加入此自動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將其減少為零。這會導致bad hop count欄位的增加。
可能的修正
為了解決此問題，您需要增加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
輸出顯示Router 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 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 消息表明，由於已達到TTL閾值，路由器75a沒有轉發組播資料包。檢視路由器配置，瞭解是否能找到原因。此輸出顯示了罪魁禍首：
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
command表示不轉發TTL小於指定閾值（在本例中為15）的任何資料包。此命令通常用於提供邊界以防止內部組播流量從Intranet中漂出。
可能的修正
或者刪除 ip multicast ttl-threshold
命令時，請使用此命令的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 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
設定靜態路由後，您會看到以下輸出中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)的等價路徑。您想要在所有三條鏈路上對組播流量進行負載均衡。
可能的修正
正如您在Multiple Equal Cost Paths Result Unwanted RPF Behavior部分中所看到的，協定無關組播(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 Software System Error Messages文檔說明了導致此錯誤的原因：下游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中，它指出「要將路由器配置為接受以指定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 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是否為組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，但不得這樣做：
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將RP-Join傳送到router2。
可能的修正
使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)時，如何會發生不需要的多點傳播封包泛濫，以及如何避免此問題。以下網路圖為例。
未啟用Cisco Group Management Protocol(CGMP)
診斷問題
在圖中，Catalyst 5000交換機A中的靜態CAM表未顯示任何已填充的正確埠。配置了CGMP的路由器不傳送CGMP資料包。
CGMP已正確配置為 set cgmp enable 命令時，交換器A和 ip cgmp 命令。但是，在以下情況下，交換機A上看不到組播組： 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能夠通過交換機A將路由器75b視為有效的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。此輸出顯示Router 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
從交換機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知道要阻塞哪些埠。如果是IGMP查詢器，則路由器75a會收到此要求。路由器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.224.1.1的10.2.1.3的IGMP報告。隨後，它會向交換機A傳送一個CGMP加入，該加入的交換機A的MAC對等值為10.224.1.1，且相關主機的MAC地址(USA)為10.2.1.3。交換機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，路由器在傳送自動RP組的CGMP自連線時使用該組。為什麼沒有其他團體？
可能的修正
為了瞭解該解決方案，您需要瞭解CGMP在特定條件下的行為方式。啟用CGMP的路由器將CGMP加入傳送到交換機，以通知交換機對特定組播組感興趣的主機。交換機在其CAM表中查詢這些主機的MAC地址，然後將組播資料包從具有相關主機的埠轉發出去，並阻止所有其他埠轉發組播資料包。
如果路由器收到來自其（路由器）已啟用CGMP的同一介面上的源的多播資料包，則該路由器會將CGMP自加入從已啟用CGMP的介面發出。
例如，如果源地址與路由器75a和75b位於同一個子網(VLAN)(10.2.1.0/24)上，則CGMP將工作正常。路由器在識別來自源的資料包時，會向交換機傳送CGMP自加入，然後交換機將動態獲知路由器所在的埠，並阻止所有其他埠轉發組播資料包。
如果路由器收到來自其啟用了CGMP的介面上的一台主機的IGMP報告，則該路由器會將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位址會導致Cisco群組管理通訊協定(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位）。由於IEEE MAC地址中只插入了23位，因此還剩下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交換器也會將多點傳播封包湧向其他多點傳播位址，這些位址在224.0.0.x的情況下是MAC層級不明的（例如，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錯誤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 |
初始版本 |
意見