- 產品與解決方案
- 行業解決方案
- 服務
- 支持
- 合作夥伴
- 關於我們
09-IPv6組播路由與轉發配置
本章節下載： 09-IPv6組播路由與轉發配置 (345.05 KB)
每個IPv6組播路由協議都有一個自身的路由表，綜合成一個總的IPv6組播路由表，由一係列（S，G）和（*，G）表項組成，即由組播源S向IPv6組播組G發送IPv6組播數據的IPv6組播路由信息。其中最優IPv6組播路由下發到IPv6組播轉發表中，控製IPv6組播數據的轉發。IPv6組播傳輸路徑上的設備根據IPv6組播轉發表轉發IPv6組播數據的同時還需執行RPF（Reverse Path Forwarding，逆向路徑轉發）機製確保IPv6組播數據沿正確路徑傳輸。
IPv6組播路由協議在創建和維護IPv6組播路由表項時，運用了RPF（Reverse Path Forwarding，逆向路徑轉發）檢查機製，以確保IPv6組播數據能夠沿正確的路徑傳輸，同時還能避免由於各種原因而造成的環路。
執行RPF檢查的過程如下：
(1) 首先，以“報文源”的IPv6地址為目的地址，分別從IPv6單播路由表和IPv6 MBGP路由表中各選出一條最優路由。
根據IPv6組播報文傳輸的具體情況不同，“報文源”所代表的具體含義也不同：
· 如果當前報文沿從組播源到接收者或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組播配置指導”中的“IPv6 PIM”。
(2) 然後，從這些最優路由中再選出一條作為RPF路由。選取規則如下：
· 如果配置了按照最長匹配選擇路由，則：
¡ 選擇前綴長度最長的路由。
¡ 如果前綴長度相同，則選擇路由優先級最高的路由。
¡ 如果路由優先級也相同，則按照IPv6 MBGP路由、IPv6單播路由的順序進行選擇。
¡ 如果存在等價路由，則選擇下一跳的IPv6地址較大者。
· 如果沒有配置按照最長匹配選擇路由，則：
¡ 選擇路由優先級最高的路由。
¡ 如果路由優先級相同，則按照IPv6 MBGP路由、IPv6單播路由的順序進行選擇。
¡ 如果存在等價路由，則選擇下一跳的IPv6地址較大者。
RPF路由中包含有RPF接口和RPF鄰居的信息，不論RPF路由為IPv6單播路由還是IPv6 MBGP路由，該路由表項的出接口都是RPF接口，下一跳都是RPF鄰居。
(3) 最後，判斷報文實際到達的接口與RPF接口是否相同：
· 相同，RPF檢查通過。
· 不同，RPF檢查失敗。
對每一個收到的IPv6組播數據報文都進行RPF檢查會給設備帶來較大負擔，而利用IPv6組播轉發表可以解決這個問題。在建立IPv6組播路由和轉發表時，會把IPv6組播數據報文（S，G）的RPF接口記錄為（S，G）表項的入接口。當設備收到IPv6組播數據報文（S，G）後，查找IPv6組播轉發表：
· 如果IPv6組播轉發表中不存在（S，G）表項，則對該報文執行RPF檢查，將其RPF接口作為入接口，結合相關路由信息創建相應的表項，並下發到IPv6組播轉發表中：
¡ 若該報文實際到達的接口正是其RPF接口，則RPF檢查通過，向所有的出接口轉發該報文；
¡ 若該報文實際到達的接口不是其RPF接口，則RPF檢查失敗，丟棄該報文。
· 如果IPv6組播轉發表中已存在（S，G）表項，且該報文實際到達的接口與入接口相匹配，則向所有的出接口轉發該報文。
· 如果IPv6組播轉發表中已存在（S，G）表項，但該報文實際到達的接口與入接口不匹配，則對此報文執行RPF檢查：
¡ 若其RPF接口與入接口一致，則說明（S，G）表項正確，丟棄這個來自錯誤路徑的報文；
¡ 若其RPF接口與入接口不符，則說明（S，G）表項已過時，於是把入接口更新為RPF接口。如果該報文實際到達的接口正是其RPF接口，則向所有的出接口轉發該報文，否則將其丟棄。
圖1-1 RPF檢查過程
如圖1-1所示，假設網絡中IPv6單播路由暢通，未配置IPv6 MBGP。IPv6組播報文（S，G）沿從組播源（Source）到接收者（Receiver）的SPT進行傳輸。假定Device C上的IPv6組播轉發表中已存在（S，G）表項，其記錄的入接口為Port A：
· 如果該IPv6組播報文從接口Port A到達Device C，與（S，G）表項的入接口相匹配，則向所有的出接口轉發該報文。
· 如果該IPv6組播報文從接口Port B到達Device C，與（S，G）表項的入接口不匹配，則對其執行RPF檢查：通過查找IPv6單播路由表發現到達Source的出接口（即RPF接口）是Port A，與（S，G）表項的入接口一致。這說明（S，G）表項是正確的，該報文來自錯誤的路徑，RPF檢查失敗，於是丟棄該報文。
網絡中可能存在不支持IPv6組播協議的設備，從IPv6組播源發出的IPv6組播數據沿IPv6組播設備逐跳轉發，當下一跳設備不支持IPv6組播協議時，IPv6組播轉發路徑將被阻斷。而通過在處於IPv6單播網段兩端的IPv6組播設備之間建立隧道，則可以實現跨IPv6單播網段的IPv6組播數據轉發。
圖1-2 使用隧道傳輸IPv6組播數據
如圖1-2所示，在IPv6組播設備Device A和Device B之間建立隧道。Device A將IPv6組播數據封裝在IPv6單播報文中，通過IPv6單播設備轉發至隧道另一端的Device B，再由Device B將IPv6單播報文頭剝掉後繼續進行IPv6組播傳輸。
IPv6組播數據暫不支持通過6to4隧道進行傳輸。
IPv6 Mtrace功能可以用來跟蹤IPv6組播數據在組播網絡中經過的路徑。
· LHR（Last-hop Router，最後一跳路由器）：在指定組播網絡中，如果某路由器有一個接口的IPv6地址與指定目的端IPv6地址在同一個網段內，且能夠向該網段轉發特定的組播流，則稱該路由器為最後一跳路由器。
· FHR（First-hop Router，第一跳路由器）：與組播源直連的路由器。
· Client（客戶端）：觸發組播路徑跟蹤的路由器。
(1) 客戶端向指定目的端發送最大TTL的查詢報文（Query Message）。
(2) 最後一跳路由器收到查詢報文後，在該報文上添加本地轉發信息，將其轉換成請求報文（Request Message），並向上遊鄰居轉發該請求報文。
(3) 路徑中的每台路由器都在收到的請求報文後添加本地轉發信息，並向上遊鄰居發送。
(4) 第一跳路由器在收到請求報文後，同樣添加本地轉發信息，然後將其報文類型改為回應報文（Reply Message），向客戶端發送。
(5) 客戶端收到回應報文後解析其中的轉發信息並顯示該信息。
IPv6組播路由與轉發配置任務如下：
(1) 使能IPv6組播路由
(2) （可選）配置按照最長匹配選擇RPF路由
(3) （可選）配置 IPv6組播負載分擔
(4) （可選）配置IPv6組播轉發邊界
(5) （可選）配置IPv6組播路徑跟蹤功能
(6) （可選）配置緩存未知IPv6組播數據報文的最大數目
在配置IPv6組播路由與轉發之前，需配置任一IPv6單播路由協議，實現域內網絡層互通。
在公網實例或VPN實例中配置各項三層IPv6組播功能之前，必須先在該實例中使能IPv6組播路由。
(1) 進入係統視圖。
system-view
(2) 使能IPv6組播路由，並進入IPv6 MRIB（Multicast Routing Information Base，組播路由信息庫）視圖。
ipv6 multicast routing [ vpn-instance vpn-instance-name ]
缺省情況下，IPv6組播路由處於關閉狀態。
在未配置按照最長匹配選擇RPF路由之前，RPF檢查以最優路由作為RPF路由。在配置按照最長匹配選擇RPF路由之後，RPF檢查將按照最長匹配選擇RPF路由。有關RPF路由選擇的詳細介紹，請參見“1.1.1 1. RPF檢查過程”。
system-view
(2) 進入IPv6 MRIB視圖。
ipv6 multicast routing [ vpn-instance vpn-instance-name ]
(3) 配置按照最長匹配選擇RPF路由。
longest-match
缺省情況下，選擇路由優先級最高的路由作為RPF路由。
用戶通過配置根據組播源或組播源組進行IPv6組播流量的負載分擔，可以優化存在多條IPv6組播數據流時的網絡流量。
本命令對IPv6雙向PIM不生效。
(1) 進入係統視圖。
system-view
(2) 進入IPv6 MRIB視圖。
ipv6 multicast routing [ vpn-instance vpn-instance-name ]
(3) 配置對IPv6組播流量進行負載分擔。
load-splitting { balance | source | source-group | ucmp }
缺省情況下，不對IPv6組播流量進行負載分擔。
IPv6組播信息在網絡中的轉發並不是漫無邊際的，每個IPv6組播組對應的IPv6組播信息都必須在確定的範圍內傳遞。IPv6組播轉發邊界可以限製IPv6組播協議報文的收發，為指定範圍或Scope值的IPv6組播組劃定了邊界條件。如果IPv6組播報文的目的地址與邊界條件匹配，就停止轉發。當在一個接口上配置了IPv6組播轉發邊界後，將不能從該接口轉發IPv6組播報文（包括本機發出的IPv6組播報文），並丟棄該接口接收到的IPv6組播報文。
本配置不需要使能IPv6組播路由。
(1) 進入係統視圖。
system-view
(2) 進入接口視圖。
interface interface-type interface-number
(3) 配置IPv6組播轉發邊界。
ipv6 multicast boundary { ipv6-group-address prefix-length | scope { scope-id | admin-local | global | organization-local | site-local } }
缺省情況下，接口上未配置任何IPv6組播組的轉發邊界。
跟蹤路徑上所有設備必須配置相同的UDP端口號，並保證UDP端口號沒有被其他業務使用。
(1) 進入係統視圖。
system-view
(2) （可選）配置IPv6 Mtrace服務使用的UDP端口號。
ipv6 mtrace-service port number
缺省情況下，IPv6 Mtrace服務使用的UDP端口號為10240。
(3) 利用IPv6 Mtrace功能跟蹤IPv6組播數據的傳輸路徑。
mtrace v2 ipv6 [ vpn-instance vpn-instance-name ] { source-address | group-address } * [ destination address | port number | wait-time time | max-hop count ] * [ verbose ]
本命令指定的端口號與上一條命令配置的UDP端口號相同。
接收到IPv6組播數據報文後，如果沒有查找到對應的IPv6組播轉發表項，則設備會緩存該報文。若在一定時間內建立了該報文對應的IPv6組播轉發表項，則轉發該報文，以確保在組播轉發表項建立的過程中不會丟棄匹配該表項的組播報文。
可以通過以下兩種方式控製設備緩存的未知IPv6組播數據報文數目：
· 設置對於同一個（S，G）表項，可緩存的最大未知IPv6組播數據報文數目。
· 設置內存中可緩存的未知IPv6組播數據報文的最大數目。
建議配置ipv6 multicast forwarding-table cache-unknown total的值要遠遠大於ipv6 multicast forwarding-table cache-unknown per-entry配置的值。
(1) 進入係統視圖。
system-view
(2) 設置對於同一個（S，G）表項，可緩存的最大未知IPv6組播數據報文數目。
ipv6 multicast forwarding-table cache-unknown per-entry per-entry-limit
缺省情況下，對於同一個（S，G）表項，可緩存的最大未知IPv6組播數據報文數目為1。
(3) 設置內存中可緩存的未知IPv6組播數據報文的最大數目。
ipv6 multicast forwarding-table cache-unknown total total-limit
缺省情況下，內存中可緩存的未知IPv6組播數據報文的最大數目為1024。
可在任意視圖下執行以下命令：
· 顯示IPv6 MRIB維護的接口信息。
display ipv6 mrib [ vpn-instance vpn-instance-name ] interface [ interface-type interface-number ]
· 顯示IPv6組播邊界的信息。
display ipv6 multicast [ vpn-instance vpn-instance-name ] boundary { group [ ipv6-group-address [ prefix-length ] ] | scope [ scope-id ] } [ interface interface-type interface-number ]
· 顯示IPv6組播轉發的DF信息。
display ipv6 multicast [ vpn-instance vpn-instance-name ] forwarding df-info [ ipv6-rp-address ] [ verbose ] [ slot slot-number ]
· 顯示IPv6組播源的RPF信息。
display ipv6 multicast [ vpn-instance vpn-instance-name ] rpf-info ipv6-source-address [ ipv6-group-address ]
可在任意視圖下執行以下命令：
display ipv6 multicast [ vpn-instance vpn-instance-name ] routing-table [ ipv6-source-address [ prefix-length ] | ipv6-group-address [ prefix-length ] | incoming-interface interface-type interface-number | outgoing-interface { exclude | include | match } interface-type interface-number ] *
可在任意視圖下執行以下命令：
· 顯示IPv6組播轉發表的信息。
display ipv6 multicast [ vpn-instance vpn-instance-name ] forwarding-table [ ipv6-source-address [ prefix-length ] | ipv6-group-address [ prefix-length ] | incoming-interface interface-type interface-number | outgoing-interface { exclude | include | match } interface-type interface-number | slot slot-number | statistics ] *
· 顯示IPv6組播轉發表的DF列表信息。
display ipv6 multicast [ vpn-instance vpn-instance-name ] forwarding-table df-list [ ipv6-group-address ] [ verbose ] [ slot slot-number ]
· 清除IPv6組播路由表或IPv6組播轉發表中的信息，可能導致IPv6組播信息無法正常傳輸。
· 清除IPv6組播路由表中的路由表項後，IPv6組播轉發表中的相應表項也將隨之刪除。
· 清除IPv6組播轉發表中的轉發表項後，IPv6組播路由表中的相應表項也將隨之刪除。
請在用戶視圖下執行以下命令：
· 清除IPv6組播轉發表中的轉發項。
reset ipv6 multicast [ vpn-instance vpn-instance-name ] forwarding-table { { ipv6-source-address [ prefix-length ] | ipv6-group-address [ prefix-length ] | incoming-interface { interface-type interface-number } } * | all }
· 清除IPv6組播路由表中的路由項。
reset ipv6 multicast [ vpn-instance vpn-instance-name ] routing-table { { ipv6-source-address [ prefix-length ] | ipv6-group-address [ prefix-length ] | incoming-interface interface-type interface-number } * | all }
可在任意視圖下執行以下命令，顯示IPv6組播轉發的事件統計信息。
display ipv6 multicast [ vpn-instance vpn-instance-name ] forwarding event [ slot slot-number ]
請在用戶視圖下執行以下命令，清除組播轉發的事件統計信息。
reset ipv6 multicast [ vpn-instance vpn-instance-name ] forwarding event
不同款型規格的資料略有差異, 詳細信息請向具體銷售和400谘詢。H3C保留在沒有任何通知或提示的情況下對資料內容進行修改的權利!
支持
