本文檔介紹自動RP如何在帶NX-OS的Cisco Nexus 9000上工作,以及如何驗證組播操作並排除故障。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
組播是一種一對多通訊模型,其中源向多個感興趣的接收方傳送單個通訊流。網路不是為每個目標建立單獨的副本,而是僅在轉發路徑分支的位置複製流量。這使得組播比廣播或重複的單播傳輸更有效。在IPv4中,多點傳播流量使用來自224.0.0.0/4範圍的目的地位址。
PIM稀疏模式是運行NX-OS的Cisco Nexus交換機支援的組播路由模型。只有在明確瞭解了接收者的興趣後,它才會轉發流量。在任意源組播設計中,接收方最初加入朝向交匯點的共用樹,源向該RP註冊。流量開始流動後,最後一跳路由器可以從共用樹移動到最短路徑樹到源路徑。
定義組播中使用的術語非常重要,因為準確的故障排除取決於瞭解控制平面事件、路由條目和轉發決策是如何表示的。清除術語有助於正確解釋命令輸出,區分共用樹和源樹行為,並確定每個組播元件在端到端轉發過程中的作用。
| 字詞 | 定義 |
|---|---|
| 組播組地址 | 224.0.0.0/4範圍內用於標識組播組的IPv4目標地址。 |
| 來源位址 | 將流量傳輸到組播組的傳送方的單播IP地址。 |
| mroute | 定義組或源組組合的組播流量處理方式的組播路由條目。 |
| IIF | 傳入介面。組播流量預期到達的介面。 |
| OIF | 傳出介面。用於向接收方或下游鄰居轉發組播流量的介面。 |
| 石油 | 傳出介面清單。與組播路由條目關聯的傳出介面集。 |
| RPF | 反向路徑轉發。檢驗組播流量是否基於通向源或RP的單點傳播路由到達正確的介面。 |
| MDT | 組播分發樹。將組播流量從源傳送到所有接收者的邏輯樹。 |
| RPT | RP樹,也稱為共用樹。它將接收器連線到RP並以(*,G)表示。 |
| SPT | 最短路徑樹,也稱為源樹。它直接將接收器連線到源,並由(S,G)表示。 |
| FHR | 第一跳路由器。組播路由器直接連線到源,負責向RP註冊源。 |
| LHR | 最後一跳路由器。組播路由器直接連線到接收者,負責通過IGMP學習接收者興趣後建立組播狀態。 |
| RP | 會合點。最初在ASM和PIM稀疏模式中用於連線源和接收器的邏輯會議點。 |
| ASM | 任意來源多點傳送。一種組播模型,其中接收機加入一個組時不需要預先指定源。 |
瞭解眾所周知的保留組播地址非常重要,因為組播故障排除取決於快速確定哪個控制協定正在使用給定的目標組,以及流量在網路中起什麼作用。這些地址有助於區分正常協定操作與異常行為,並且更容易驗證IGMP、PIM和自動RP交換。具體而言,對於自動RP,要識別的最重要組是224.0.1.39(RP-Announce)和224.0.1.40(RP-Discovery),因為它們包含允許路由器瞭解動態RP對映的資訊。
| 組播地址 | 目的 |
|---|---|
| 224.0.0.1 | 本地子網上的所有主機 |
| 224.0.0.2 | 本地子網上的所有路由器 |
| 224.0.0.13 | 所有PIM路由器 |
| 224.0.0.22 | IGMPv3消息 |
| 224.0.1.39 | Cisco RP-Announce消息由自動RP使用 |
| 224.0.1.40 | 自動RP使用的Cisco RP-Discovery消息 |
自動RP是一種思科機制,用於協定無關組播稀疏模式,用於在組播域中動態發現和分發集結點(RP)資訊。它通過使用基於組播的控制平面消息來通告、選擇和學習RP到組的對映,從而無需進行靜態RP配置。其主要元件是候選RP和對映代理,候選RP為特定組範圍提供RP服務,對映代理收集候選並確定每個組的活動RP。
當每個候選RP定期向224.0.1.39傳送RP-Announce消息(包括其IP地址、優先順序和支援的組播組範圍)時,該過程開始。這些消息使用NX-OS中的自動RP偵聽程式在整個網路中泛洪,確保所有對映代理甚至在網路完全以稀疏模式運行之前都接收它們。
對映代理會偵聽這些通告,構建候選RP資料庫,並對每個組執行確定性選擇過程(通常是最高優先順序,然後是最高IP地址)。 選擇最佳的RP後,對映代理生成RP發現消息並將其傳送到224.0.1.40,向域中的所有路由器通告最終的RP到組的對映。
所有PIM路由器都會收到RP-Discovery消息並將對映安裝到其本地RP表中。利用此資訊,最後一跳路由器(連線到接收器)向選定RP傳送PIM加入消息以構建共用樹(RPT),而第一跳路由器(連線到源)將組播流量封裝在PIM註冊消息中,以通知RP有關活動源的資訊。
當流量通過RP時,路由器可以選擇使用額外的PIM加入/修整信令直接從共用樹(RPT)切換到最短路徑樹(SPT)。在此過程中,自動RP通過週期性控制消息不斷刷新對映,從而確保了可復原性和自動適應拓撲或RP更改。
PIM稀疏模式下的自動RP操作(控制平面工作流)
基於ECMP的多路徑轉發功能預設啟用,允許組播流量使用等價路徑進行負載均衡。
支援使用IPsec AH-MD5的PIM鄰居身份驗證。
PIM監聽不可用。
自動RP為PIM稀疏模式組播環境提供動態RP發現和集中RP對映分佈。它無需在每個組播路由器上進行靜態RP配置,降低了操作複雜性,並提高了組播可擴充性。自動RP還支援多個RP候選,從而啟用自動RP故障切換和冗餘。此機制有助於維持一致的組播轉發行為,簡化網路擴展,並允許組播路由器自動獲知域中的RP資訊。
自動RP中的選擇過程是確定性的,主要基於IP地址。與其他通訊協定(例如PIMv2 BSR)不同,自動RP不使用可設定的「優先順序」值;相反,它依賴於IP地址層次結構來解決衝突。
在自動RP中,多個對映代理可以在同一個網路中共存以實現冗餘。沒有正式的選舉程式,一個選舉關閉,另一個選舉開啟;所有裝置在技術上均處於活動狀態。但是,網路中的交換機必須決定信任哪些資訊。
此過程由對映代理在偵聽來自候選的所有RP-Announce消息(傳送到組224.0.1.39)後執行。
當對映代理收到同一組播組的多個候選時,它按順序應用以下規則:
規則A:最長字首匹配(最具體掩碼)
如果候選通告重疊範圍,則MA會將組分配給通告最小範圍(最長子網掩碼)的RP。
規則B:最高IP地址(分路器)
如果兩個或多個候選者通告的組範圍完全相同,則對映代理只能選擇一個。
雖然本文的重點是使用PIM的第3層組播,但第2層行為在故障排除和總體設計中起著至關重要的作用。在第2層,裝置使用MAC地址(分配給網路介面的48位識別符號)進行通訊,組播流量需要特定的MAC編址方案來將其與單播和廣播流量區分開來。
IPv4組播MAC地址是使用保留字首「01:00:5E」從第3層組播組地址派生的。但是,IP組播地址中只有23位對映到MAC地址,這將產生32:1的重疊,這意味著多達32個不同的組播IP組可以對映到同一個MAC地址。因此,偵聽給定組播MAC地址的主機可以接收多個組播組的流量,即使它們只對其中一個組感興趣。例如,224.1.1.1、225.1.1.1、226.1.1.1、227.1.1.1、228.1.1.1等。
這種重疊對網路效率和故障排除有直接影響。由於完全基於MAC地址的第2層轉發決策無法區分重疊的組播組,因此交換機可以向主機傳輸不必要的流量。然後,這些主機必須依靠高層過濾(IP/IGMP)來丟棄不需要的資料包,從而消耗CPU和緩衝區資源。
在Cisco Nexus NX-OS中,此限制通過IGMP監聽行為得以緩解。預設情況下,IGMP監聽執行基於IP的查詢,而不是僅支援MAC的轉發,即使多個組播組共用同一個MAC地址,交換機也能做出更精確的轉發決策。這顯著提高了第2層的效率並減少了不必要的流量傳輸。
本部分提供自動RP配置的詳細說明,並且使用簡單的實現作為參考。在此設定中,組播源通過vPC連線到兩個Nexus交換機,以向接收器傳輸流量。在本設計中,N9K-1和N9K-2同時充當RP候選和對映代理。
注意:vPC埠通道不支援PIM鄰居。
組播流量
相同的配置有FHR-2。
FHR-1# show running-config pim feature pim ip pim auto-rp forward listen interface Vlan1 ip pim sparse-mode interface Ethernet1/1 ip pim sparse-mode interface Ethernet1/3 ip pim sparse-mode
| 指令 | 目的/說明 |
|---|---|
| 功能pim | 在交換機上啟用PIM(協定無關組播)進程。 |
| ip pim auto-rp forward listen | 啟用自動RP偵聽程式。這允許交換機接收和轉發自動RP控制消息(224.0.1.39和224.0.1.40),即使交換機尚不知道RP的身份。 |
| ip pim sparse-mode | 在特定介面上啟用PIM稀疏模式。在此模式下,組播流量僅轉發到已通過PIM加入消息明確請求組播流量的網段。 |
N9K-1# show running-config pim feature pim ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15 ip pim auto-rp mapping-agent loopback1 interface loopback0 ip pim sparse-mode interface loopback1 ip pim sparse-mode interface Ethernet1/3 ip pim sparse-mode interface Ethernet1/4 ip pim sparse-mode interface Ethernet1/49 ip pim sparse-mode
下表提供了N9K-1的PIM配置的詳細技術細分。此配置在N9K-2上複製。兩台交換機均配置有雙重角色,既充當組播域的RP候選者,又充當對映代理。
| 指令 | 詳細技術說明 |
|---|---|
| 功能pim | 功能啟用:在Nexus交換機上全域性啟用協定無關組播(PIM)引擎。 |
| ip pim auto-rp rp-candidate loopback0 group-list 224.10.20.0/24 interval 15 | RP候選角色:將此交換機配置為「志願」作為集結點(RP)。 來源:使用loopback0 IP地址 範圍:它提供處理組播組範圍224.10.20.0/24的功能。 Interval:每15秒向對映代理傳送「通告」消息。保持計時器是此值的三倍。 |
| ip pim auto-rp mapping-agent loopback1 | 對映代理角色:將交換機配置為自動RP過程的「管理員」。 功能:它偵聽所有RP候選者,解決衝突(使用最高的IP地址作為連線中斷器),並向網路其餘部分廣播「發現」消息,通知他們活動RP是誰。 |
| interface loopback0 / loopback1 | 邏輯介面:在這些介面上啟用PIM,因為它們作為RP候選和對映代理角色的源IP。它們必須通過單播路由表從所有PIM路由器到達。 |
| interface Ethernet1/3, 1/4, 1/49 | 物理轉發:在物理埠上啟用PIM稀疏模式。這允許交換機與其他路由器形成PIM鄰居鄰接關係並通過這些特定鏈路轉發組播流量。 |
| ip pim sparse-mode | 操作模式:已應用於上面的所有介面。它確保組播流量僅傳送到通過PIM加入消息明確請求組播流量的接收器,從而防止不必要的網路泛洪。 |
PIM鄰居和OSPF區域0
N9K-1 — OSPF配置
N9K-1(config)# show running-config ospf feature ospf router ospf UNDERLAY router-id 10.2.0.1 interface loopback0 ip router ospf UNDERLAY area 0.0.0.0 interface loopback1 ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/3 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/4 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/49 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0
FHR-1 — OSPF配置
FHR-1(config)# show running-config ospf feature ospf router ospf UNDERLAY interface Vlan1 ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/1 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/3 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0
LHR - OSPF配置
LHR(config)# show running-config ospf feature ospf router ospf UNDERLAY interface Vlan2 ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/49 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0 interface Ethernet1/50 ip ospf network point-to-point ip router ospf UNDERLAY area 0.0.0.0
在分析組播行為之前,必須驗證單播底層(OSPF區域0)是否完全可操作。組播控制平面協定(如PIM和自動RP)依賴於單播可達性才能正常工作。
第一個驗證步驟是確認來源和接收者(或其最接近的第3層網關:FHR和LHR)可訪問。
在拓撲中:
FHR-1/FHR-2最→於組播源(10.150.1.37 - VLAN 1)
LHR最→於組播接收器(192.168.2.37 - VLAN 2)
1.執行ICMP可達性測試,測試範圍包括:
FHR ↔ LHR
FHR接↔器子網(VLAN 2網關)
LHR↔源子網(VLAN 1網關)
2.驗證路由表中的源和接收器可達性。對於vPC部署,確保兩個Nexus對等點之間的一致性。請注意,接收方具有ECMP路徑,而來源可透過第2層連線。
FHR-1 — 路由到源
FHR-1# show ip route 10.150.1.37
10.150.1.37/32, ubest/mbest: 1/0, attached
*via 10.150.1.37, Vlan1, [250/0], 06:57:19, am
FHR-1 — 到接收方的路由
FHR-1# show ip route 192.168.2.37
192.168.2.0/24, ubest/mbest: 2/0
*via 10.4.0.6, Eth1/3, [110/45], 04:11:08, ospf-UNDERLAY, intra
*via 10.4.0.10, Eth1/1, [110/45], 04:11:08, ospf-UNDERLAY, intra
FHR-2 — 路由到源
FHR-2# show ip route 10.150.1.37
10.150.1.37/32, ubest/mbest: 1/0, attached
*via 10.150.1.37, Vlan1, [250/0], 07:03:45, am
FHR-2 — 到接收方的路由
FHR-2# show ip route 192.168.2.37
192.168.2.0/24, ubest/mbest: 2/0
*via 10.4.0.13, Eth1/3, [110/45], 04:16:16, ospf-UNDERLAY, intra
*via 10.4.0.18, Eth1/4, [110/45], 04:16:16, ospf-UNDERLAY, intra
LHR — 路由到源
LHR(config)# show ip route 10.150.1.37
10.150.1.0/24, ubest/mbest: 2/0
*via 10.4.0.22, Eth1/49, [110/45], 04:14:52, ospf-UNDERLAY, intra
*via 10.4.0.26, Eth1/50, [110/45], 04:14:52, ospf-UNDERLAY, intra
LHR — 到接收方的路由
LHR(config)# show ip route 192.168.2.37
192.168.2.37/32, ubest/mbest: 1/0, attached
*via 192.168.2.37, Vlan2, [250/0], 06:47:21, am
此測試失敗強烈表明存在底層問題。
沒有單播可達性,組播無法正常工作,因為:
PIM鄰居依賴單播路由
RP(環回)地址必須可訪問
RPF(反向路徑轉發)檢查取決於路由表
成功的ping並不能保證組播可以工作,因為:
在阻止組播時可以允許ICMP
PIM或自動RP仍可能配置錯誤
提示:在分析自動RP、PIM鄰接關係或RP選擇之前,請始終確保底層路由域是穩定、一致且完全可到達的端到端路由域。
下一步是明確確定轉發組播流量時涉及的每台裝置的角色。這是強制性的步驟,因為組播故障排除完全取決於瞭解整個拓撲中的流量和預期行為。
至少必須確定以下要素:
多點傳送來源:10.150.1.37(VLAN 1)
組播組(G):224.10.20.10
接收者:192.168.2.37(VLAN 2)
第一躍點路由器(FHR):FHR-1/FHR-2(最靠近源)
最後一跳路由器(LHR):LHR(最靠近接收器)
此外,還需要確定控制平面角色:
RP候選項:N9K-1和N9K-2(Loopback0)
對映代理:N9K-1和N9K-2(Loopback1)
要進行組播故障排除,必須提供詳細的網路拓撲。其中包括:
物理連線(裝置之間使用的介面)
邏輯拓撲(VLAN、路由鏈路、vPC關係)
使用的路由協定(本設計中的OSPF區域0)
路由域邊界(單IGP與混合協定(如OSPF、EIGRP或BGP)
用於RP和對映代理角色的環回介面
啟用PIM的介面和鄰居關係
從源FHR到RP→LHR→收器→精確→徑
哪些裝置負責:
正在傳送PIM暫存器(FHR)
建築(*,G)或(S,G)樹(LHR)
通告RP資訊(對映代理)
路由(OSPF)如何確保可達性:
源子網
接收器子網
RP環回地址
注意:沒有清晰拓撲的組播故障排除等同於無可見性的調試,這會導致錯誤的假設和誤診。
下一步是根據每台裝置在組播拓撲中的角色,驗證是否正確配置了自動RP。這包括確認:
RP候選(N9K-1 / N9K-2)已正確配置為將其Loopback0通告為組播組範圍的RP。
對映代理(N9K-1 / N9K-2)配置為收集RP-Announce消息並使用Loopback1生成RP-Discovery消息。
FHR和LHR在所有相關介面上啟用了PIM稀疏模式以參與自動RP和接收RP對映。
確保為PIM稀疏模式啟用所有必需介面(包括環回和路由鏈路),並且不存在會阻止RP-Announce(224.0.1.39)和RP-Discovery(224.0.1.40)消息交換的缺少配置,這一點至關重要。
附註:N9K-1和N9K-2配置為組播域內的RP-Candidates和對映代理。
注意:任何缺失或不一致的自動RP配置都會阻止路由器學習RP,從而導致組播流量無法正確轉發。
第一個驗證步驟是確認所有預期的PIM鄰居都正確建立了組播拓撲。
N9K-1 — 驗證PIM鄰居
N9K-1# show ip pim neighbor
PIM Neighbor Status for VRF "default"
Neighbor Interface Uptime Expires DR Bidir- BFD ECMP Redirect
Priority Capable State Capable
10.4.0.5 Ethernet1/3 23:19:45 00:01:20 1 yes n/a no
10.4.0.14 Ethernet1/4 23:19:45 00:01:38 1 yes n/a no
10.4.0.21 Ethernet1/49 23:19:45 00:01:38 1 yes n/a no
N9K-2 — 驗證PIM鄰居
N9K-2# show ip pim neighbor
PIM Neighbor Status for VRF "default"
Neighbor Interface Uptime Expires DR Bidir- BFD ECMP Redirect
Priority Capable State Capable
10.4.0.9 Ethernet1/3 23:21:18 00:01:29 1 yes n/a no
10.4.0.17 Ethernet1/4 23:21:18 00:01:23 1 yes n/a no
10.4.0.25 Ethernet1/49 23:21:18 00:01:44 1 yes n/a no
驗證點
在以下拓撲中:
下一步是確認所有參與自動RP的介面均已啟用PIM。
此驗證對以下各項特別重要:
N9K-1 — 驗證PIM介面
N9K-1# show ip pim interface brief
PIM Interface Status for VRF "default"
Interface IP Address PIM DR Address Neighbor Border
Count Interface
Ethernet1/3 10.4.0.6 10.4.0.6 1 no
Ethernet1/4 10.4.0.13 10.4.0.14 1 no
Ethernet1/49 10.4.0.22 10.4.0.22 1 no
loopback0 10.2.0.1 10.2.0.1 0 no
loopback1 10.2.1.5 10.2.1.5 0 no
N9K-2 — 驗證PIM介面
N9K-2# show ip pim interface brief
PIM Interface Status for VRF "default"
Interface IP Address PIM DR Address Neighbor Border
Count Interface
Ethernet1/3 10.4.0.10 10.4.0.10 1 no
Ethernet1/4 10.4.0.18 10.4.0.18 1 no
Ethernet1/49 10.4.0.26 10.4.0.26 1 no
loopback0 10.2.0.4 10.2.0.4 0 no
loopback1 10.2.1.4 10.2.1.4 0 no
驗證點:
環回角色分配:
| 裝置 | 功能 | 回送 |
|---|---|---|
| N9K-1 | RP候選 | 10.2.0.1 |
| N9K-1 | 對映代理 | 10.2.1.5 |
| N9K-2 | RP候選 | 10.2.0.4 |
| N9K-2 | 對映代理 | 10.2.1.4 |
環回正確地顯示為活動PIM介面,即使它們不構成PIM鄰居。之所以會出現此行為,是因為環回介面不直接建立組播鄰接關係。
這些環回的存在證實:
此命令可驗證:
N9K-1 — RP資訊
N9K-1# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5*, next Discovery message in: 00:00:39 BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None RP: 10.2.0.1*, (0), uptime: 22:18:44 priority: 255, RP-source: 10.2.0.1 (A), group ranges: 224.10.20.0/24 , expires: 00:00:37 (A) RP: 10.2.0.4, (0), uptime: 23:00:32 priority: 255, RP-source: 10.2.0.4 (A), group ranges: 224.10.20.0/24 , expires: 00:00:44 (A)
逐行說明
BSR已禁用
BSR disabled
這確認:
此拓撲中應出現此行為。
自動RP RPA:10.2.1.5*
Auto-RP RPA: 10.2.1.5*
這意味著:
中的下一條發現消息
next Discovery message in: 00:00:39
如果此計時器凍結或意外過期,則自動RP通告無法正確傳播。
策略欄位
BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None
第一個RP條目
RP: 10.2.0.1*, (0),
這確認N9K-1已配置為RP-Candidate。
正常運行時間和優先順序
uptime: 22:18:44 priority: 255,
RP源
RP-source: 10.2.0.1 (A),
組範圍
224.10.20.0/24
第二個RP條目
RP: 10.2.0.4, (0),
N9K-2 — RP資訊
N9K-2# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5, uptime: 22:19:10, expires: 00:02:28 RP: 10.2.0.4*, (0), uptime: 23:14:14 priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24 , expires: 00:02:28 (A)
N9K-2的主要區別
Auto-RP RPA: 10.2.1.5
重要RP差異
RP-source: 10.2.1.5 (A),
這確認:
Auto-RP使用兩種不同的組播控制平面功能:
在PIM稀疏模式環境中驗證組播操作時,瞭解這些函式如何互動至關重要。
在以下拓撲中:
RP候選操作
RP-Candidate將自身通告為一個或多個組播組範圍的有效Rendezvous Point。
每個RP候選定期將自動RP通告消息傳送到:
這些公告包括:
在以下拓撲中:
N9K-1 — RP候選資訊
N9K-1# show ip pim rp <snip>
RP: 10.2.0.1*, (0),
uptime: 23:11:22 priority: 255,
RP-source: 10.2.0.1 (A),
group ranges:
224.10.20.0/24 , expires: 00:00:38 (A)
RP: 10.2.0.4, (0),
uptime: 23:53:09 priority: 255,
RP-source: 10.2.0.4 (A),
group ranges:
224.10.20.0/24 , expires: 00:00:43 (A)
N9K-2 — RP候選資訊
N9K-2# show ip pim rp <snip>
RP: 10.2.0.4*, (0),
uptime: 1d00h priority: 255,
RP-source: 10.2.1.5 (A),
group ranges:
224.10.20.0/24 , expires: 00:02:52 (A)
兩台裝置通告相同的組播組範圍:
兩個RP候選還使用:
這一點非常重要,因為自動RP在RP選擇期間使用優先順序和RP地址。
主動對映代理標識
對映代理從以下邏輯開始為組播組選擇活動RP:
在以下拓撲中:
因為兩個RP候選具有相同的優先順序:
因此:
選定的RP驗證
N9K-2 — 選定的RP
N9K-2# show ip pim rp <snip> RP: 10.2.0.4*, (0), uptime: 23:14:14 priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24
為什麼N9K-1仍顯示兩個RP條目
在N9K-1上:
N9K-1# show ip pim rp <snip> RP: 10.2.0.1*, (0), RP: 10.2.0.4, (0),
出現此行為是意料之中的,因為:
注意:在對映代理上,必須顯示同一組播域內的所有RP候選項。如果缺少任何RP-Candidate,請通過向來自對映代理IP地址(通常是環回介面)的RP-Candidate IP地址傳送ping來驗證可達性。
參與PIM稀疏模式域的所有組播路由器必須保持穩定的IP可達性,以便:
此驗證至關重要,因為PIM稀疏模式依賴於單播路由,以便:
如果到RP或對映代理的可達性失敗:
路由表必須包含通向以下目標的穩定單播路由:
路由必須保持連續安裝狀態,並且不會出現路由擺動或過度重新收斂事件。
驗證:
FHR-1 — 到RP候選10.2.0.1的路由
FHR-1# show ip route 10.2.0.1
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.1/32, ubest/mbest: 1/0
*via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-1 — 到RP候選10.2.0.4的路由
FHR-1# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-1 — 到對映代理10.2.1.5的路由
FHR-1# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.6, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-1 — 到對映代理10.2.1.4的路由
FHR-1# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.10, Eth1/1, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — 到RP候選10.2.0.1的路由
FHR-2# show ip route 10.2.0.1
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.1/32, ubest/mbest: 1/0
*via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — 到RP候選10.2.0.4的路由
FHR-2# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — 到對映代理10.2.1.5的路由
FHR-2# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.13, Eth1/3, [110/5], 1d02h, ospf-UNDERLAY, intra
FHR-2 — 到對映代理10.2.1.4的路由
FHR-2# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.18, Eth1/4, [110/5], 1d02h, ospf-UNDERLAY, intra
LHR — 到RP候選10.2.0.1的路由
LHR# show ip route 10.2.0.1
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.1/32, ubest/mbest: 1/0
*via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra
LHR — 到RP候選10.2.0.4的路由
LHR# show ip route 10.2.0.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.0.4/32, ubest/mbest: 1/0
*via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra
LHR — 到對映代理10.2.1.5的路由
LHR# show ip route 10.2.1.5
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.5/32, ubest/mbest: 1/0
*via 10.4.0.22, Eth1/49, [110/2], 1d02h, ospf-UNDERLAY, intra
LHR — 到對映代理10.2.1.4的路由
LHR# show ip route 10.2.1.4
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
10.2.1.4/32, ubest/mbest: 1/0
*via 10.4.0.26, Eth1/50, [110/2], 1d02h, ospf-UNDERLAY, intra
驗證路由表後,驗證端到端IP可達性,以便:
ping的來源必須是:
此驗證非常重要,因為組播路由器會在以下過程中使用這些源地址:
提示:如果使用未編號的介面(其中多個第3層介面共用來自環回介面的同一IP地址),可達性驗證會變得更簡單,因為單個源IP地址可以一致使用。
| 裝置 | 來源 IP | 目的地 | 功能 | 結果 |
|---|---|---|---|---|
| FHR-1 | 10.4.0.5 | 10.2.0.1 | RP候選 | 成功 |
| FHR-1 | 10.4.0.5 | 10.2.0.4 | RP候選 | 成功 |
| FHR-1 | 10.4.0.5 | 10.2.1.5 | 對映代理 | 成功 |
| FHR-1 | 10.4.0.5 | 10.2.1.4 | 對映代理 | 成功 |
| FHR-2 | 10.4.0.9 | 10.2.0.1 | RP候選 | 成功 |
| FHR-2 | 10.4.0.9 | 10.2.0.4 | RP候選 | 成功 |
| FHR-2 | 10.4.0.9 | 10.2.1.5 | 對映代理 | 成功 |
| FHR-2 | 10.4.0.9 | 10.2.1.4 | 對映代理 | 成功 |
| LHR | 10.4.0.5 | 10.2.0.1 | RP候選 | 成功 |
| LHR | 10.4.0.5 | 10.2.0.4 | RP候選 | 成功 |
| LHR | 10.4.0.5 | 10.2.1.5 | 對映代理 | 成功 |
| LHR | 10.4.0.5 | 10.2.1.4 | 對映代理 | 成功 |
下一個驗證步驟是驗證:
在驗證組播轉發狀態之前,檢驗所有組播路由器是否都獲取了正在驗證的組播組的預期RP。
此步驟至關重要,因為:
在以下拓撲中:
FHR-1 — 驗證獲知的RP
FHR-1# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:30 BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None RP: 10.2.0.4, (0), uptime: 1d03h priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24 , expires: 00:02:30 (A)
FHR-2 — 驗證獲知的RP
FHR-2# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:15 BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None RP: 10.2.0.4, (0), uptime: 1d03h priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24 , expires: 00:02:15 (A)
LHR — 驗證獲知的RP
LHR# show ip pim rp PIM RP Status Information for VRF "default" BSR disabled Auto-RP RPA: 10.2.1.5, uptime: 1d02h, expires: 00:02:07 BSR RP Candidate policy: None BSR RP policy: None Auto-RP Announce policy: None Auto-RP Discovery policy: None RP: 10.2.0.4, (0), uptime: 1d03h priority: 255, RP-source: 10.2.1.5 (A), group ranges: 224.10.20.0/24 , expires: 00:02:07 (A)
RP學習分析
輸出確認:
出現此行為是意料之中的,因為:
在這個階段,組播控制平面運行正常,所有路由器都具有一致的224.10.20.0/24 RP對映
下一步是在組播流量傳輸開始之前驗證組播路由表。
在此情況中:
此狀態很重要,因為它驗證:
FHR-1 — 組播路由表
FHR-1# show ip mroute IP Multicast Routing Table for VRF "default" (*, 232.0.0.0/8), uptime: 23:07:34, pim ip Incoming interface: Null, RPF nbr: 0.0.0.0 Outgoing interface list: (count: 0)
FHR-2 — 組播路由表
FHR-2# show ip mroute IP Multicast Routing Table for VRF "default" (*, 232.0.0.0/8), uptime: 23:07:37, pim ip Incoming interface: Null, RPF nbr: 0.0.0.0 Outgoing interface list: (count: 0)
FHR組播狀態分析
FHR尚未包含:
出現此行為是意料之中的,因為:
唯一的組播條目是:
這對應於預設的SSM範圍,並由系統自動安裝。
需要以下值:
此條目不表示活動的組播轉發。
LHR — 組播路由表
LHR# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 224.10.20.10/32), uptime: 23:07:39, igmp ip pim
Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
Outgoing interface list: (count: 1)
Vlan2, uptime: 23:07:39, igmp
(*, 232.0.0.0/8), uptime: 23:07:39, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
LHR組播狀態分析
與FHR不同,LHR包含一個活動的(*,G)條目,用於:
出現此行為是意料之中的,因為:
組播路由表確認:
這表示:
在此階段:
N9K-1 — 對映代理組播路由表
N9K-1# show ip mroute IP Multicast Routing Table for VRF "default" (*, 232.0.0.0/8), uptime: 1d03h, pim ip Incoming interface: Null, RPF nbr: 0.0.0.0 Outgoing interface list: (count: 0)
對映代理組播狀態分析
N9K-1僅作為對映代理運行,不參與224.10.20.10的組播轉發
因此,預期會缺少(*, G)entrie和(S, G)條目。
對映代理僅分發RP對映資訊,並不一定參與組播資料轉發,除非組播流量直接流經裝置。
N9K-2 — RP組播路由表
N9K-2# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 224.10.20.10/32), uptime: 1d01h, pim ip
Incoming interface: loopback0, RPF nbr: 10.2.0.4
Outgoing interface list: (count: 1)
Ethernet1/49, uptime: 1d01h, pim
(*, 232.0.0.0/8), uptime: 1d03h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
RP組播狀態分析
N9K-2用作以下對象的活動RP:
因此,RP包含224.10.20.10的共用樹(*,G)狀態
需要以下值:
這表示:
在此階段:
組播流量傳輸開始後,組播路由表將從共用樹狀態轉換到活動源特定轉發狀態。
在此情況中:
vPC組播注意事項
組播源通過FHR-1和FHR-2形成的vPC域進行連線。
由於源通過vPC成員port-channel進行連線:
在此特定情況中:
FHR-1 — 組播路由表
FHR-1# show ip mroute IP Multicast Routing Table for VRF "default" (10.150.1.37/32, 224.10.20.10/32), uptime: 00:03:58, ip pim Incoming interface: Vlan1, RPF nbr: 10.150.1.37 Outgoing interface list: (count: 0) (*, 232.0.0.0/8), uptime: 1d00h, pim ip Incoming interface: Null, RPF nbr: 0.0.0.0 Outgoing interface list: (count: 0)
FHR-1 — vPC角色
FHR-1# show vpc role vPC Role status ---------------------------------------------------- vPC role : primary <<< Dual Active Detection Status : 0 vPC system-mac : 00:23:04:ee:be:01 vPC system-priority : 32667 vPC local system-mac : 00:6b:f1:84:02:97 vPC local role-priority : 32667 vPC local config role-priority : 32667 vPC peer system-mac : 6c:b2:ae:ee:5a:97 vPC peer role-priority : 32667 vPC peer config role-priority : 32667
FHR-1組播狀態分析
FHR-1包含一個活動的(S,G)條目,用於:
組播路由條目確認:
之所以會出現此行為,是因為組播流未針對出站轉發向FHR-1雜湊。
因此:
FHR-2 — 組播路由表
FHR-2# show ip mroute
IP Multicast Routing Table for VRF "default"
(10.150.1.37/32, 224.10.20.10/32), uptime: 00:16:35, ip pim
Incoming interface: Vlan1, RPF nbr: 10.150.1.37
Outgoing interface list: (count: 1)
Ethernet1/3, uptime: 00:16:35, pim
(*, 232.0.0.0/8), uptime: 1d00h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
FHR-2 — vPC角色
FHR-2# show vpc role vPC Role status ---------------------------------------------------- vPC role : secondary <<< Dual Active Detection Status : 0 vPC system-mac : 00:23:04:ee:be:01 vPC system-priority : 32667 vPC local system-mac : 6c:b2:ae:ee:5a:97 vPC local role-priority : 32667 vPC local config role-priority : 32667 vPC peer system-mac : 00:6b:f1:84:02:97 vPC peer role-priority : 32667 vPC peer config role-priority : 32667
FHR-2組播狀態分析
與FHR-1不同,FHR-2包含:
這表示:
ECMP和組播轉發行為
傳出介面Ethernet1/3匹配通向接收方192.168.2.37的單播路由表
FHR-2 — 到組播接收器的路由
FHR-2# show ip route 192.168.2.37
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>
192.168.2.0/24, ubest/mbest: 2/0
*via 10.4.0.13, Eth1/3, [110/45], 1d02h, ospf-UNDERLAY, intra
*via 10.4.0.18, Eth1/4, [110/45], 1d02h, ospf-UNDERLAY, intra
FHR-2包含通向組播接收器子網的兩條等價路由:
這確認:
雖然存在兩條等價路由,但組播轉發對每個組播流使用單個RPF路徑。
在此拓撲中,組播流使用:
此行為與之前觀察到的組播路由表相匹配:
(10.150.1.37/32, 224.10.20.10/32)
Outgoing interface list:
Ethernet1/3
vPC操作角色對組播轉發行為的影響不同:
在以下拓撲中:
兩台Nexus交換機都可以:
但是:
這一區別很重要,因為:
因此:
LHR — 組播路由表
LHR# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 224.10.20.10/32), uptime: 1d00h, igmp ip pim
Incoming interface: Ethernet1/50, RPF nbr: 10.4.0.26
Outgoing interface list: (count: 1)
Vlan2, uptime: 1d00h, igmp
(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:31, ip mrib pim
Incoming interface: Ethernet1/49, RPF nbr: 10.4.0.22
Outgoing interface list: (count: 1)
Vlan2, uptime: 00:06:31, mrib
(*, 232.0.0.0/8), uptime: 1d00h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
LHR現在包含兩者:
這確認:
(S,G)條目確認:
此行為確認成功:
N9K-1 — 中轉組播路由表
N9K-1# show ip mroute
IP Multicast Routing Table for VRF "default"
(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:42, pim ip
Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.14
Outgoing interface list: (count: 1)
Ethernet1/49, uptime: 00:06:42, pim
(*, 232.0.0.0/8), uptime: 1d04h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
N9K-1傳輸狀態分析
N9K-1充當活動組播流的傳輸組播路由器。
組播路由條目確認:
這確認成功:
N9K-2 — RP組播路由表
N9K-2# show ip mroute
IP Multicast Routing Table for VRF "default"
(*, 224.10.20.10/32), uptime: 1d02h, pim ip
Incoming interface: loopback0, RPF nbr: 10.2.0.4
Outgoing interface list: (count: 1)
Ethernet1/49, uptime: 1d02h, pim
(10.150.1.37/32, 224.10.20.10/32), uptime: 00:06:50, ip pim mrib
Incoming interface: Ethernet1/4, RPF nbr: 10.4.0.17, internal
Outgoing interface list: (count: 0)
(*, 232.0.0.0/8), uptime: 1d04h, pim ip
Incoming interface: Null, RPF nbr: 0.0.0.0
Outgoing interface list: (count: 0)
N9K-2作為組播組的活動RP運行。
RP包含兩者:
預計(S,G)條目中沒有傳出介面,原因是:
命令清單提供在運行NX-OS的Cisco Nexus 9000系列交換機上執行適當的根本原因分析(RCA)或組播運行狀況診斷所需的最低建議組播資料收集。這些輸出捕獲組播控制平面狀態、MRIB程式設計、轉發資訊、vPC運行狀態和硬體轉發詳細資訊。但是,根據故障情況仍可能需要其他資訊。例如,組播資料包丟失、間歇性流量丟棄、資料包複製問題、硬體轉發不一致或亂序組播轉發通常需要使用Ethanalyzer、SPAN或硬體級捕獲在Nexus交換機上直接捕獲資料包。類似地,瞬時RPF不一致、ECMP轉發更改、ASIC程式設計失敗或IGMP抑制事件也可能發生,而不會生成永久日誌。
因此,將show tech輸出與資料包捕獲和轉發驗證結合使用可顯著改善診斷準確性和RCA品質。雖然此資訊為組播故障排除提供了強大的操作基線,但它不能保證始終僅從這些輸出中識別RCA。某些組播故障需要額外的故障排除、即時流量分析、硬體級驗證、拓撲關聯或擴展資料包捕獲來查明確切的根本原因。
提示:在工作和非工作期間收集此資訊可清晰地從Nexus的角度快速瞭解問題的出現方式,並顯著提高了確定根本原因的能力。
N9K-1# show tech-support multicast >> bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
N9K-1# show tech-support details >> bootflash:$(SWITCHNAME)-sh-tech-det.txt
N9K-1# show tech-support vpc >> bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
N9K-1# show tech-support forwarding multicast >> bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
N9K-1# show tech-support forwarding l3 multicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
N9K-1# show tech-support forwarding l3 unicast detail vdc-all >> bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt
生成show tech檔案後,將它們整合到單個TAR歸檔中,用於匯出和分析。命令是單行。
N9K-1# tar create bootflash:$(SWITCHNAME)-multicast-logs
bootflash:$(SWITCHNAME)-sh-tech-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-det.txt
bootflash:$(SWITCHNAME)-sh-tech-vpc.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-multicast.txt
bootflash:$(SWITCHNAME)-sh-tech-fwd-l3-unicast-det.txt
匯出單個TAR歸檔可以簡化:
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
1.0 |
13-May-2026
|
初始版本 |