05-組播路由與轉發配置
本章節下載: 05-組播路由與轉發配置 (547.81 KB)
目 錄
1.12.1 利用版本1的Mtrace功能跟蹤組播數據的傳輸路徑
1.12.2 利用版本2的Mtrace功能跟蹤組播數據的傳輸路徑
1.14.4 配置組播FRR中組播流量從備份鏈路回切到主鏈路功能
1.15 配置允許生成組播組地址為239.255.255.250的組播表項
每個組播路由協議都有一個自身的路由表,它們與靜態配置的組播路由綜合成一個總的組播路由表,由一係列(S,G)和(*,G)表項組成,即由組播源S向組播組G發送組播數據的組播路由信息。其中最優組播路由下發到組播轉發表中,控製組播數據的轉發。組播傳輸路徑上的設備根據組播轉發表轉發組播數據的同時還需執行RPF(Reverse Path Forwarding,逆向路徑轉發)機製確保組播數據沿正確路徑傳輸。
組播路由協議在創建和維護組播路由表項時,運用了RPF檢查機製,以確保組播數據能夠沿正確的路徑傳輸,同時還能避免由於各種原因而造成的環路。
執行RPF檢查的過程如下:
(1) 首先,以“報文源”的IP地址為目的地址,分別從單播路由表、MBGP路由表和組播靜態路由表中各選出一條最優路由。
根據組播報文傳輸的具體情況不同,“報文源”所代表的具體含義也不同:
· 如果當前報文沿從組播源到接收者或RP(Rendezvous Point,彙集點)的SPT(Shortest Path Tree,最短路徑樹)進行傳輸,則以組播源為“報文源”進行RPF檢查。
· 如果當前報文沿從RP到接收者的RPT(Rendezvous Point Tree,共享樹)進行傳輸,或者沿從組播源到RP的組播源側RPT進行傳輸,則都以RP為“報文源”進行RPF檢查。
· 如果當前報文為BSR(Bootstrap Router,自舉路由器)報文,沿從BSR到各設備的路徑進行傳輸,則以BSR為“報文源”進行RPF檢查。
有關SPT、RPT、組播源側RPT、RP和BSR的詳細介紹,請參見“IP組播配置指導”中的“PIM”。
(2) 然後,從這些最優路由中再選出一條作為RPF路由。選取規則如下:
· 如果配置了按照最長匹配選擇路由,則:
¡ 選擇掩碼匹配最長的路由。
¡ 如果掩碼相同,則選擇路由優先級最高的路由。
¡ 如果路由優先級也相同,則按照組播靜態路由、MBGP路由、單播路由的順序進行選擇。
¡ 如果存在等價路由,則選擇下一跳的IP地址較大者。
· 如果沒有配置按照最長匹配選擇路由,則:
¡ 選擇路由優先級最高的路由。
¡ 如果路由優先級相同,則按照組播靜態路由、MBGP路由、單播路由的順序進行選擇。
¡ 如果存在等價路由,則選擇下一跳的IP地址較大者。
RPF路由中包含有RPF接口和RPF鄰居的信息:
· 如果RPF路由為單播路由或MBGP路由,則該路由表項的出接口就是RPF接口,下一跳就是RPF鄰居。
· 如果RPF路由為組播靜態路由,則該路由表項中會明確指定RPF接口和RPF鄰居。
(3) 最後,判斷報文實際到達的接口與RPF接口是否相同:
· 相同,RPF檢查通過。
· 不同,RPF檢查失敗。
對每一個收到的組播數據報文都進行RPF檢查會給設備帶來較大負擔,而利用組播轉發表可以解決這個問題。在建立組播路由和轉發表時,會把組播數據報文(S,G)的RPF接口記錄為(S,G)表項的入接口。當設備收到組播數據報文(S,G)後,查找組播轉發表:
· 如果組播轉發表中不存在(S,G)表項,則對該報文執行RPF檢查,將其RPF接口作為入接口,結合相關路由信息創建相應的表項,並下發到組播轉發表中:
¡ 若該報文實際到達的接口正是其RPF接口,則RPF檢查通過,向所有的出接口轉發該報文;
¡ 若該報文實際到達的接口不是其RPF接口,則RPF檢查失敗,丟棄該報文。
· 如果組播轉發表中已存在(S,G)表項,且該報文實際到達的接口與入接口相匹配,則向所有的出接口轉發該報文。
· 如果組播轉發表中已存在(S,G)表項,但該報文實際到達的接口與入接口不匹配,則對此報文執行RPF檢查:
¡ 若其RPF接口與入接口一致,則說明(S,G)表項正確,丟棄這個來自錯誤路徑的報文;
¡ 若其RPF接口與入接口不符,則說明(S,G)表項已過時,於是把入接口更新為RPF接口。如果該報文實際到達的接口正是其RPF接口,則向所有的出接口轉發該報文,否則將其丟棄。
圖1-1 RPF檢查過程
如圖1-1所示,假設網絡中單播路由暢通,未配置MBGP,Device C上也未配置組播靜態路由。組播報文(S,G)沿從組播源(Source)到接收者(Receiver)的SPT進行傳輸。假定Device C上的組播轉發表中已存在(S,G)表項,其記錄的入接口為Port A:
· 如果該組播報文從接口Port A到達Device C,與(S,G)表項的入接口相匹配,則向所有的出接口轉發該報文。
· 如果該組播報文從接口Port B到達Device C,與(S,G)表項的入接口不匹配,則對其執行RPF檢查:通過查找單播路由表發現到達Source的出接口(即RPF接口)是Port A,與(S,G)表項的入接口一致。這說明(S,G)表項是正確的,該報文來自錯誤的路徑,RPF檢查失敗,於是丟棄該報文。
組播靜態路由有兩種主要用途:改變RPF路由和銜接RPF路由。
通常,組播的網絡拓撲結構與單播相同,組播數據的傳輸路徑也與單播相同。可以通過配置組播靜態路由以改變RPF路由,從而為組播數據創建一條與單播不同的傳輸路徑。
圖1-2 改變RPF路由示意圖
如圖1-2所示,當網絡中沒有配置組播靜態路由時,Device C到組播源(Source)的RPF鄰居為Device A,從Source發出的組播信息沿Device A—Device C的路徑傳輸,與單播路徑一致;當在Device C上配置了組播靜態路由,指定從Device C到Source的RPF鄰居為Device B之後,從Source發出的組播信息將改變傳輸路徑,沿Device A—Device B—Device C的新路徑傳輸。
當網絡中的單播路由被阻斷時,由於沒有RPF路由而無法進行包括組播數據在內的數據轉發。可以通過配置組播靜態路由以生成RPF路由,從而創建組播路由表項以指導組播數據的轉發。
圖1-3 銜接RPF路由示意圖
如圖1-3所示,RIP域與OSPF域之間實行單播路由隔離。當網絡中沒有配置組播靜態路由時,OSPF域內的接收者(Receiver)不能收到RIP域內的組播源(Source)所發出的組播信息;當在Device C和Device D上均配置了組播靜態路由,分別指定從Device C到Source的RPF鄰居為Device B、從Device D到Source的RPF鄰居為Device C之後,Receiver便能收到Source發出的組播信息了。
Mtrace功能可以用來跟蹤組播數據在組播網絡中經過的路徑。
· LHR(Last-Hop Router,最後一跳路由器):在指定組播網絡中,如果某路由器有一個接口的IP地址與指定目的端IP地址在同一個網段內,且能夠向該網段轉發特定的組播流,則稱該路由器為最後一跳路由器。
· FHR(First-Hop Router,第一跳路由器):與組播源直連的路由器。
· Client(客戶端):觸發組播路徑跟蹤的路由器。
(1) 客戶端向指定目的端發送最大TTL的查詢報文(Query Message)。
(2) 最後一跳路由器收到查詢報文後,在該報文上添加本地轉發信息,將其轉換成請求報文(Request Message),並向上遊鄰居轉發該請求報文。
(3) 路徑中的每台路由器都在收到的請求報文後添加本地轉發信息,並向上遊鄰居發送。
(4) 第一跳路由器在收到請求報文後,同樣添加本地轉發信息,然後將其報文類型改為回應報文(Reply Message),向客戶端發送。
(5) 客戶端收到回應報文後解析其中的轉發信息並顯示該信息。
如果客戶端在規定的時間內沒有收到回複,跟蹤模式會自動切換成逐跳模式。即發送最大跳數為1的查詢報文,並等待回複。如果在規定時間內收到回複,會繼續發送最大跳數為2的查詢報文。依此類推,發送跳數遞增的查詢報文,直到跟蹤結束。如果路徑中某設備未能在規定時間內回複,則不再繼續發送跳數遞增的查詢報文。
通過ISSU方式對多個成員設備組成的IRF組網環境進行版本升級時,若三層組播路由入接口包含非本設備上的成員端口,在升級過程中重啟該設備無法保證流量不中斷。
組播路由與轉發配置任務如下:
(1) 使能IP組播路由
(2) (可選)配置組播靜態路由
(3) (可選)配置按照最長匹配選擇RPF路由
(4) (可選)配置組播負載分擔
(5) (可選)配置獨立組播轉發模式
(6) (可選)配置IPv4組播流策略
(7) (可選)配置組播轉發邊界
(8) (可選)配置組播路徑跟蹤功能
(9) (可選)配置緩存未知組播數據報文的最大數目
(10) (可選)配置組播FRR
(11) (可選)配置允許生成組播組地址為239.255.255.250的組播表項
(12) (可選)配置組播報文軟轉發複製數量的最大值
在配置組播路由與轉發之前,需配置任一單播路由協議,實現域內網絡層互通。
在公網實例或VPN實例中配置各項三層組播功能之前,必須先在該實例中使能IP組播路由。
(1) 進入係統視圖。
system-view
(2) 使能IP組播路由,並進入MRIB(Multicast Routing Information Base,組播路由信息庫)視圖。
multicast routing [ vpn-instance vpn-instance-name ]
缺省情況下,IP組播路由處於關閉狀態。
通過配置組播靜態路由,可以為來自特定組播源的組播報文指定RPF接口或RPF鄰居。
組播靜態路由僅在所配置的組播設備上生效,不會以任何方式被廣播或者引入給其它設備。
(1) 進入係統視圖。
system-view
(2) 配置組播靜態路由。
ip rpf-route-static [ vpn-instance vpn-instance-name ] source-address { mask-length | mask } { rpf-nbr-address | interface-type interface-number } [ preference preference ]
(3) (可選)刪除所有組播靜態路由。
delete ip rpf-route-static [ vpn-instance vpn-instance-name ]
可以通過undo ip rpf-route-static命令刪除指定的組播靜態路由外,也可以通過delete ip rpf-route-static命令刪除所有的組播靜態路由。
在未配置按照最長匹配選擇RPF路由之前,RPF檢查以最優路由作為RPF路由。在配置按照最長匹配選擇RPF路由之後,RPF檢查將按照最長匹配選擇RPF路由。
有關RPF路由選擇的詳細介紹,請參見“1.1.1 1. RPF檢查過程”。
(1) 進入係統視圖。
system-view
(2) 進入MRIB視圖。
multicast routing [ vpn-instance vpn-instance-name ]
(3) 配置按照最長匹配選擇RPF路由。
longest-match
缺省情況下,選擇路由優先級最高的路由作為RPF路由。
用戶通過配置根據組播源或組播源組進行組播流量的負載分擔,可以優化存在多條組播數據流時的網絡流量。
(1) 進入係統視圖。
system-view
(2) 進入MRIB視圖。
multicast routing [ vpn-instance vpn-instance-name ]
(3) 配置對組播流量進行負載分擔。
load-splitting { balance-ecmp | balance-ucmp | ecmp | flow-ucmp | source | source-group | ucmp }
缺省情況下,不對組播流量進行負載分擔。
在開啟了三層組播的IRF組網中,當聚合接口對應的聚合組的端口分布在兩台不同的成員設備上,且該聚合口同時為組播流量的入接口和出接口時,請將組播轉發模式配置為獨立模式。
當係統工作模式為專家模式時,不支持配置本功能。有關係統工作模式的詳細介紹,請參見“基礎配置指導”中“設備管理”。
本命令隻支持在兩台成員設備組成的IRF係統中配置。
配置完本命令後,請在用戶視圖下通過reset multicast forwarding-table all命令用來清除組播轉發表中所有的轉發項,否則會導致流量轉發異常。
在配置本命令前,需先將全局的聚合負載分擔模式配置為本地轉發優先。有關本地轉發優先的詳細描述,請參見“二層技術-以太網交換”配置指導中的“以太網鏈路聚合”。
(1) 進入係統視圖。
system-view
(2) 配置獨立組播轉發模式。
multicast forwarding-mode independent
缺省情況下,組播轉發模式為共享模式。
當下遊設備與上遊設備之間存在多條等價路由,且組播流量的負載分擔方式為flow-ucmp(通過load-splitting命令配置)時,通過配置IPv4組播流策略,可以指定組播源組符合ACL匹配規則的IPv4組播流預計帶寬。下遊設備在選擇上遊入口設備時,將選擇根據組播流預計帶寬計算得到的組播流帶寬利用率最小的那條的鏈路,如果組播流帶寬利用率相同,則選擇下一跳IP地址大的鏈路。
組播流帶寬利用率=(已使用帶寬+組播流預計帶寬)/(接口總帶寬*(1-單播預留帶寬))。其中:
· 組播流預計帶寬值通過IPv4組播流策略視圖下的bandwidth命令配置。
· 接口總帶寬通過接口視圖下的bandwidth命令配置。
· 單播預留帶寬通過flow-ucmp unicast reserve-bandwidth或multicast flow-ucmp unicast reserve-bandwidth命令配置。
配置本功能的同時,請通過load-splitting命令將組播流量負載分擔方式配置為flow-ucmp,否則本配置不生效。
新增、刪除和修改組播流策略,以及修改組播流策略下的配置,都不會影響已有組播流的選路結果,隻影響新增組播流的選路。因此,在將組播流量負載分擔方式配置為flow-ucmp前,需要規劃並完成組播流策略視圖下的配置和單播預留帶寬比的配置。
鏈路自身帶寬配置變化、等價鏈路數量變化等不影響已有組播流量的選路結果。
組播源側的選路、PIM DM模式選路、PIM SM模式的RPT選路、本地RP選路均不受本配置影響。
當網絡中同時存在IPv4和IPv6組播流量時,請適當提高單播預留帶寬比,以免造成鏈路擁塞。
(1) 進入係統視圖。
system-view
(2) 進入MRIB視圖。
multicast routing [ vpn-instance vpn-instance-name ]
(3) 配置IPv4組播流策略或缺省IPv4組播流策略。
¡ 配置IPv4組播流策略。
flow-policy name policy-name
¡ 配置缺省IPv4組播流策略。
flow-policy default
缺省情況下,不存在IPv4組播流策略。
本功能用來配置IPv4組播流策略生效的組播組範圍。若某個組播源組與某個組播流策略中的ACL規則匹配,則認為該組播源組對應的組播流的預計帶寬值為IPv4組播流策略視圖下bandwidth命令配置的值。
IPv4缺省組播流策略視圖下不支持配置本功能。
(1) 進入係統視圖。
system-view
(2) 進入MRIB視圖。
multicast routing [ vpn-instance vpn-instance-name ]
(3) 進入IPv4組播流策略視圖。
flow-policy { default | name policy-name }
(4) 配置IPv4組播流策略生效的組播源組範圍。
acl { ipv4-acl-number | name ipv4-acl-name }
缺省情況下,未配置IPv4組播流策略生效的組播源組範圍,即IPv4組播流策略對所有的組播源組均不生效。
IPv4組播流預計帶寬的選擇過程如下:
(1) 若IPv4組播流量所屬的組播源組與某個組播流策略中的ACL規則匹配,則該組播流預計帶寬值為IPv4組播流策略視圖下的bandwidth命令配置的值。
(2) 若IPv4組播流量所屬的組播源組沒有與任何組播流策略中的ACL規則匹配,則該組播流預計帶寬值為IPv4缺省組播流策略視圖下的bandwidth命令配置的值。
(3) 若IPv4缺省組播流策略未配置或者IPv4缺省組播流策略視圖下未配置組播流預計帶寬,則認為組播流預計帶寬為0。
(1) 進入係統視圖。
system-view
(2) 進入MRIB視圖。
multicast routing [ vpn-instance vpn-instance-name ]
(3) 進入IPv4組播流策略視圖。
flow-policy { default | name policy-name }
(4) 配置IPv4組播流的預計帶寬。
bandwidth bandwidth { gbps | kbps | mbps }
缺省情況下,未配置IPv4組播流的預計帶寬,預計帶寬為0。
網絡中IPv4單播流量和IPv4組播流量共存,可以通過本功能為IPv4單播流量配置預留帶寬比。根據接口帶寬以及本命令配置的IPv4單播預留帶寬比,可以計算出接口組播流量的可用總帶寬。比如,接口的總帶寬為100Kbps,IPv4單播預留帶寬比為20%(即20Kbps),則接口IPv4組播流量的可用總帶寬為80Kbps。
配置本功能的同時,請通過load-splitting命令將組播流量負載分擔方式配置為flow-ucmp,否則本配置不生效。
flow-ucmp unicast reserve-bandwidth命令與multicast flow-ucmp unicast reserve-bandwidth命令的功能相同,隻是作用範圍不同:MRIB視圖下的全局配置對所有接口都有效,接口視圖下的配置隻對當前接口有效,後者的配置優先級較高。
(1) 進入係統視圖。
system-view
(2) 進入MRIB視圖。
multicast routing [ vpn-instance vpn-instance-name ]
(3) 全局配置IPv4單播流量預留帶寬比。
flow-ucmp unicast reserve-bandwidth percentage
缺省情況下,全局未配置IPv4單播流量預留帶寬比。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 在接口上配置IPv4單播流量預留帶寬比。
multicast flow-ucmp unicast reserve-bandwidth percentage
缺省情況下,未在接口上配置IPv4單播流量預留帶寬比。
組播信息在網絡中的轉發並不是漫無邊際的,每個組播組對應的組播信息都必須在確定的範圍內傳遞。組播轉發邊界可以限製組播協議報文的收發,為指定範圍的組播組劃定了邊界條件。如果組播報文的目的地址與邊界條件匹配,就停止轉發。當在一個接口上配置了組播轉發邊界後,將不能從該接口轉發組播報文(包括本機發出的組播報文)並丟棄該接口接收到的組播報文。
本配置不需要使能IP組播路由。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置組播轉發邊界。
multicast boundary group-address { mask-length | mask }
缺省情況下,接口上未配置任何組播組的轉發邊界。
可在任意視圖下執行本命令,利用版本1的Mtrace功能跟蹤特定的組播數據在組播網絡中所經過的路徑。
mtrace [ v1 ] [ vpn-instance vpn-instance-name ] { source-address | group-address } * [ destination address ] [ verbose ]
跟蹤路徑上所有設備必須配置相同的UDP端口號,並保證UDP端口號沒有被其他業務使用。
(1) 進入係統視圖。
system-view
(2) (可選)配置Mtrace服務使用的UDP端口號。
mtrace-service port number
缺省情況下,Mtrace服務使用的UDP端口號為10240。
(3) 可在任意視圖下執行本命令,利用版本2的Mtrace功能跟蹤特定的組播數據在組播網絡中所經過的路徑信息。
mtrace v2 [ vpn-instance vpn-instance-name ] { source-address | group-address } * [ destination address | port number | wait-time time | max-hop count ] * [ verbose ]
本命令指定的端口號與上一條命令配置的UDP端口號相同。
接收到組播數據報文後,如果沒有查找到對應的組播轉發表項,則設備會緩存該報文。若在一定時間內建立了該報文對應的組播轉發表項,則轉發該報文,以確保在組播轉發表項建立的過程中不會丟棄匹配該表項的組播報文。
可以通過以下兩種方式控製設備緩存的未知組播數據報文數目:
· 設置對於同一個(S,G)表項,可緩存的最大未知組播數據報文數目。
· 設置內存中可緩存的未知組播數據報文的最大數目。
建議配置multicast forwarding-table cache-unknown total的值要遠遠大於multicast forwarding-table cache-unknown per-entry配置的值。
(1) 進入係統視圖。
system-view
(2) 設置對於同一個(S,G)表項,可緩存的最大未知組播數據報文數目。
multicast forwarding-table cache-unknown per-entry per-entry-limit
缺省情況下,對於同一個(S,G)表項,可緩存的最大未知組播數據報文數目為1。
(3) 設置內存中可緩存的未知組播數據報文的最大數目。
multicast forwarding-table cache-unknown total total-limit
缺省情況下,內存中緩存的未知組播數據報文的最大數目為1024。
本功能在絲印前綴為LSCM1的單板上不支持。
當設備上開啟組播FRR(Fast Reroute,快速重路由)功能後,同一個(S,G)表項將會存在主備入接口,同時將會周期性檢測主備入接口的組播流量。當檢測到組播流量未從主入接口到達,表示主入接口存在故障,此時會將該表項的入接口切換到備份入接口。
組播FRR有按表項檢測和按入接口檢測兩種工作模式。在不同的工作模式下,對於主備入接口組播流量的檢測方式不同,具體差異為:
· 按表項檢測模式:在此模式下,當開啟了組播FRR功能後,設備將周期性的針對每條表項進行主備入接口流量的檢測。
· 按入接口檢測模式:在此模式下,當開啟了組播FRR功能後,設備會將主備入接口均相同的組播表項劃分為一組,然後周期性對這組表項進行主備入接口流量的檢測。
目前隻有PIM支持組播FRR。關於PIM FRR的詳細介紹,請參見“IP組播配置指導”中的“PIM”。
(1) 進入係統視圖。
system-view
(2) 配置組播FRR的工作模式。
multicast frr mode [ by-entry | by-iif ]
缺省情況下,組播FRR的工作模式為按表項檢測模式。
當連接組播源的設備發生故障時,為了加快組播業務收斂速度,可以在連接接收者的設備上開啟組播FRR功能。設備上開啟組播FRR功能後,設備將為同一個(S,G)表項保存主備兩個入接口,並周期性檢測主備入接口的組播流量。如果檢測到組播流量未從主入接口到達,則表示主鏈路存在故障,此時連接接收者的設備將選擇接收從備份鏈路發來的組播流量。通過功能,可以配置組播FRR監測主備鏈路狀態的周期。
在配置本功能前,請先通過rpf-frr enable命令開啟公網或私網的組播FRR功能。有關rpf-frr enable命令的詳細介紹,請參見“IP組播命令參考”中的“PIM”。
組播轉發表項較多時,建議將監測主備鏈路狀態的周期調大,避免在短時間內監測過多的組播表項對應的組播流量,導致CPU負載過重;當組播流量速率比較小時,也建議將監測主備鏈路狀態的周期調大,避免監測周期過短監測過於頻繁,造成鏈路故障的誤判。
(1) 進入係統視圖。
system-view
(2) 配置組播FRR監測主備鏈路狀態的周期。
multicast frr monitor cycle monitor-time
缺省情況下,組播FRR監測主備鏈路狀態的周期為200毫秒。
連接接收者的設備上開啟組播FRR功能後,設備檢測到主鏈路發生故障時,設備會選擇接收備份鏈路的組播流量。當主鏈路故障恢複後,可以通過本功能用來配置是否需要將組播流量從備份鏈路切換到主鏈路,以及切換的延遲時間。
在配置本功能前,請先通過rpf-frr enable命令開啟公網或私網的組播FRR功能。有關rpf-frr enable命令的詳細介紹,請參見“IP組播命令參考”中的“PIM”。
建議配置的組播FRR中組播流量從備份鏈路回切到主鏈路的等待時間不要過短,以免在主鏈路完成組播表項建立前,將組播流量回切到主鏈路,導致組播流量轉發失敗。
組播流量回切過程中,可能會導致部分組播業務出現多包或者丟包。在組播業務可靠性要求較高的場景下,建議配置為不回切。
(1) 進入係統視圖。
system-view
(2) 配置組播FRR中組播流量從備份鏈路回切到主鏈路功能。
multicast frr wtr { wtr-time | disable }
缺省情況下,組播FRR中組播流量從備份鏈路回切到主鏈路功能處於開啟狀態,回切的等待時間為600秒。
SSDP(Simple Service Discovery Protocol,簡單服務發現協議)是一種局域網發現協議,它通常使用組播組地址239.255.255.250來進行查找服務。
如果需要使用該組播組地址生成組播表項來為SSDP業務提供支持,可以通過配置本功能,允許在設備上生成組播組地址為239.255.255.250的組播表項。
設備上最終能否成功生成組播組地址為239.255.255.250的組播表項,還將受到igmp group-policy和source-policy命令配置的組播組過濾策略和組播數據過濾策略的影響。如果組播組地址239.255.255.250被組播組過濾策略或組播數據過濾策略中的ACL規則過濾掉了,那麼設備上將無法正常生成239.255.255.250對應的組播表項。
(1) 進入係統視圖。
system-view
(2) 配置允許生成組播組地址為239.255.255.250的組播表項功能。
multicast permit ssdp-group
缺省情況下,設備上不允許生成組播組地址為239.255.255.250的組播表項。
請您在工程師指導下謹慎使用該功能,不要自行配置。
若組播報文軟轉發複製數量的最大值配置過大,會導致CPU占用率過高,影響設備的轉發性能;若配置過小,會導致組播報文轉發出現丟包。
(1) 進入係統視圖。
system-view
(2) 配置組播報文軟轉發複製數量的最大值。
multicast cpu-forwarding max-copy-count count
缺省情況下,組播報文軟轉發複製數量的最大值為5。
執行reset命令清除組播路由表或組播轉發表中的信息,可能導致組播信息無法正常傳輸。
在完成上述配置後,在任意視圖下執行display命令可以顯示配置後組播路由與轉發的信息,通過查看顯示信息驗證配置的效果。
在用戶視圖下執行reset命令可以清除組播路由與轉發的統計信息。
表1-1 組播路由與轉發顯示和維護
操作 |
命令 |
顯示MRIB維護的接口信息 |
display mrib [ vpn-instance vpn-instance-name ] interface [ interface-type interface-number ] |
顯示組播邊界的信息 |
display multicast [ vpn-instance vpn-instance-name ] boundary [ group-address [ mask-length | mask ] ] [ interface interface-type interface-number ] |
顯示組播快速轉發表信息 |
(獨立運行模式) display multicast [ vpn-instance vpn-instance-name ] fast-forwarding cache [ source-address | group-address ] * [ slot slot-number ] (IRF模式) display multicast [ vpn-instance vpn-instance-name ] fast-forwarding cache [ source-address | group-address ] * [chassis chassis-number slot slot-number ] |
顯示組播轉發的事件統計信息 |
(獨立運行模式) display multicast [ vpn-instance vpn-instance-name ] forwarding event [ slot slot-number] (IRF模式) display multicast [ vpn-instance vpn-instance-name ] forwarding event [ chassis chassis-number slot slot-number ] |
顯示組播轉發表的信息 |
(獨立運行模式) display multicast [ vpn-instance vpn-instance-name ] forwarding-table [ source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | incoming-interface interface-type interface-number | outgoing-interface { exclude | include | match } interface-type interface-number | slot slot-number | statistics ] * (IRF模式) display multicast [ vpn-instance vpn-instance-name ] forwarding-table [ source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | chassis chassis-number slot slot-number | incoming-interface interface-type interface-number | outgoing-interface { exclude | include | match } interface-type interface-number | statistics ] * |
顯示組播路由表的信息 |
display multicast [ vpn-instance vpn-instance-name ] routing-table [ source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | incoming-interface interface-type interface-number | outgoing-interface { exclude | include | match } interface-type interface-number ] * |
顯示組播靜態路由表的信息 |
display multicast [ vpn-instance vpn-instance-name ] routing-table static [ source-address { mask-length | mask } ] |
顯示組播源的RPF信息 |
display multicast [ vpn-instance vpn-instance-name ] rpf-info source-address [ group-address ] |
顯示當前組播轉發模式 |
display multicast forwarding-mode |
顯示IPv4組播流策略的信息 |
display multicast [ vpn-instance vpn-instance-name ] flow-policy info [ interface interface-type interface-number | source source-address | group group-address | policy { default | name policy-name } ] * |
清除組播快速轉發表中的轉發項 |
(獨立運行模式) reset multicast [ vpn-instance vpn-instance-name ] fast-forwarding cache { { source-address | group-address } * | all } [ slot slot-number ] (IRF模式) reset multicast [ vpn-instance vpn-instance-name ] fast-forwarding cache { { source-address | group-address } * | all } [ chassis chassis-number slot slot-number ] |
清除組播轉發的事件統計信息 |
reset multicast [ vpn-instance vpn-instance-name ] forwarding event |
清除組播轉發表中的轉發項 |
reset multicast [ vpn-instance vpn-instance-name ] forwarding-table { { source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | incoming-interface { interface-type interface-number } } * | all } |
清除組播路由表中的路由項 |
reset multicast [ vpn-instance vpn-instance-name ] routing-table { { source-address [ mask { mask-length | mask } ] | group-address [ mask { mask-length | mask } ] | incoming-interface interface-type interface-number } * | all } |
· 清除組播路由表中的路由項後,組播轉發表中的相應表項也將隨之刪除。
· 清除組播轉發表中的轉發項後,組播路由表中的相應表項也將隨之刪除。
· 網絡中運行PIM-DM,所有交換機都支持組播功能;
· Switch A、Switch B和Switch C之間運行OSPF協議;
· 通常情況下,Receiver能通過Switch A—Switch B這條與單播路徑相同的路徑接收來自Source的組播信息;
· 要求通過配置,使Receiver能通過Switch A—Switch C—Switch B這條與單播路徑不同的路徑接收來自Source的組播信息。
圖1-4 改變RPF路由配置舉例
按照圖1-4配置各接口的IP地址和掩碼,並在各交換機上配置OSPF協議。
(1) 使能IP組播路由,並使能PIM-DM和IGMP
# 在Switch B上使能IP組播路由,在主機側接口Vlan-interface100上使能IGMP,並在其它接口上使能PIM-DM。
<SwitchB> system-view
[SwitchB] multicast routing
[SwitchB-mrib] quit
[SwitchB] interface vlan-interface 100
[SwitchB-Vlan-interface100] igmp enable
[SwitchB-Vlan-interface100] quit
[SwitchB] interface vlan-interface 101
[SwitchB-Vlan-interface101] pim dm
[SwitchB-Vlan-interface101] quit
[SwitchB] interface vlan-interface 102
[SwitchB-Vlan-interface102] pim dm
[SwitchB-Vlan-interface102] quit
# 在Switch A上使能IP組播路由,並在各接口上使能PIM-DM。
<SwitchA> system-view
[SwitchA] multicast routing
[SwitchA-mrib] quit
[SwitchA] interface vlan-interface 200
[SwitchA-Vlan-interface200] pim dm
[SwitchA-Vlan-interface200] quit
[SwitchA] interface vlan-interface 102
[SwitchA-Vlan-interface102] pim dm
[SwitchA-Vlan-interface102] quit
[SwitchA] interface vlan-interface 103
[SwitchA-Vlan-interface103] pim dm
[SwitchA-Vlan-interface103] quit
Switch C上的配置與Switch A相似,配置過程略。
# 在Switch B上顯示到Source的RPF信息。
[SwitchB] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Vlan-interface102, RPF neighbor: 30.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: igp
Route selection rule: preference-preferred
Load splitting rule: disable
Source AS: 0
C-multicast route target: 0x0000000000000000
Switch B上當前的RPF路由來源於單播路由,RPF鄰居是Switch A。
(2) 配置組播靜態路由
# 在Switch B上配置組播靜態路由,指定到Source的RPF鄰居為Switch C。
[SwitchB] ip rpf-route-static 50.1.1.0 24 20.1.1.2
# 在Switch B上顯示到Source的RPF信息。
[SwitchB] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Vlan-interface101, RPF neighbor: 20.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: multicast static
Route selection rule: preference-preferred
Load splitting rule: disable
Source AS: 0
C-multicast route target: 0x0000000000000000
與配置組播靜態路由前相比,Switch B上的RPF路由已經產生了變化,其來源變為組播靜態路由,RPF鄰居變為Switch C。
· 網絡中運行PIM-DM,所有交換機都支持組播功能;
· Switch B和Switch C之間運行OSPF協議,並與Switch A單播路由隔離;
· 通常情況下,Receiver能接收來自OSPF域內Source 1的組播信息;
· 要求通過配置,使Receiver也可以接收來自OSPF域外Source 2的組播信息。
圖1-5 銜接RPF路由配置組網圖
按照組網圖配置各接口的IP地址和掩碼,並在Switch B和Switch C上配置OSPF協議。
(1) 使能IP組播路由,並使能PIM-DM和IGMP
# 在Switch C上使能IP組播路由,在接口Vlan-interface101上使能PIM-DM,並在主機側接口Vlan-interface100上使能IGMP。
<SwitchC> system-view
[SwitchC] multicast routing
[SwitchC-mrib] quit
[SwitchC] interface vlan-interface 100
[SwitchC-Vlan-interface100] igmp enable
[SwitchC-Vlan-interface100] quit
[SwitchC] interface vlan-interface 101
[SwitchC-Vlan-interface101] pim dm
[SwitchC-Vlan-interface101] quit
# 在Switch A上使能IP組播路由,並在各接口上使能PIM-DM。
<SwitchA> system-view
[SwitchA] multicast routing
[SwitchA-mrib] quit
[SwitchA] interface vlan-interface 300
[SwitchA-Vlan-interface300] pim dm
[SwitchA-Vlan-interface300] quit
[SwitchA] interface vlan-interface 102
[SwitchA-Vlan-interface102] pim dm
[SwitchA-Vlan-interface102] quit
Switch B上的配置與Switch A相似,配置過程略。
# 在Switch B和Switch C上分別顯示到Source 2的RPF信息。
[SwitchB] display multicast rpf-info 50.1.1.100
[SwitchC] display multicast rpf-info 50.1.1.100
沒有顯示信息輸出,說明在Switch B和Switch C上都沒有到Source 2的RPF路由。
(2) 配置組播靜態路由
# 在Switch B上配置組播靜態路由,指定到Source 2的RPF鄰居為Switch A。
[SwitchB] ip rpf-route-static 50.1.1.0 24 30.1.1.2
# 在Switch C上配置組播靜態路由,指定到Source 2的RPF鄰居為Switch B。
[SwitchC] ip rpf-route-static 50.1.1.0 24 20.1.1.2
# 在Switch B和Switch C上分別顯示到Source 2的RPF信息。
[SwitchB] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Vlan-interface102, RPF neighbor: 30.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: multicast static
Route selection rule: preference-preferred
Load splitting rule: disable
Source AS: 0
C-multicast route target: 0x0000000000000000
[SwitchC] display multicast rpf-info 50.1.1.100
RPF information about source 50.1.1.100:
RPF interface: Vlan-interface101, RPF neighbor: 20.1.1.2
Referenced route/mask: 50.1.1.0/24
Referenced route type: multicast static
Route selection rule: preference-preferred
Load splitting rule: disable
Source AS: 0
C-multicast route target: 0x0000000000000000
與配置組播靜態路由前相比,Switch B和Switch C上都有了到Source 2的RPF路由,且其均來源於組播靜態路由。
設備沒有配置動態路由協議,接口的物理狀態與鏈路層協議狀態都顯示為up,但是組播靜態路由失敗。
· 如果沒有正確配置或更新與當前網絡情況相匹配的組播靜態路由,則組播靜態路由表中不存在此路由項;
· 如果查詢到有比組播靜態路由更優的路由,也可能導致組播靜態路由失敗。
(1) 使用display multicast routing-table static命令顯示組播靜態路由表的信息,以確定是否正確配置了對應的路由並存在於組播靜態路由表中。
(2) 檢查組播靜態路由與RPF鄰居相連接口的接口類型,如果不是點到點接口,則RPF鄰居必須使用指定地址的形式配置。
不同款型規格的資料略有差異, 詳細信息請向具體銷售和400谘詢。H3C保留在沒有任何通知或提示的情況下對資料內容進行修改的權利!