組播VPN技術白皮書

關鍵詞:組播,VPNMDMTIRPF

    要:組播VPN是一項在現有BGP/MPLS IP VPN基礎上支持組播業務的技術,該技術通過對私網組播報文進行封裝,並將其由各Site間建立的組播隧道進行傳遞,以完成組播數據在私網之間的傳送。本文介紹了組播VPN的基本概念、實現方案和典型組網應用。

縮略語:

縮略語

英文全名

中文解釋

BGP

Border Gateway Protocol

邊界網關協議

BSR

BootStrap Router

自舉路由器

CE Device

Customer Edge Device

CE設備

CNI

Customer Network Interface

私網接口

C-BSR

Candidate-BSR

候選BSR

C-RP

Candidate-RP

候選RP

GRE

Generic Routing Encapsulation

通用路由封裝

IGMP

Internet Group Management Protocol

互聯網組管理協議

ISP

Internet service provider

互聯網服務提供商

MD

Multicast Domain

組播域

MDT

Multicast Distribution Tree

組播分發樹

MPLS

Multiprotocol Label Switching

多協議標簽交換

MSDP

Multicast Source Discovery Protocol

組播源發現協議

MT

Multicast Tunnel

組播隧道

MTI

Multicast Tunnel Interface

組播隧道接口

MVRF

Multicast VRF

同時支持單播和組播的VRF

NBMA

Non-Broadcast Multi-Access

非廣播多點可達

P Device

Provider Device

P設備

PE Device

Provider Edge Device

PE設備

PNI

Provider Network Interface

公網接口

PIM-DM

Protocol Independent Multicast-Dense Mode

協議無關組播—密集模式

PIM-SM

Protocol Independent Multicast-Spare Mode

協議無關組播—稀疏模式

RP

Rendezvous Point

彙集點

RPF

Reverse Path Forwarding

逆向路徑轉發

RPT

Rendezvous Point Tree

共享樹

Share-MDT

Share-Multicast Distribution Tree

共享組播分發樹

SPT

Shortest Path Tree

最短路徑樹

Switch-MDT

Switch-Multicast Distribution Tree

切換組播分發樹

VPN

Virtual Private Network

虛擬專用網

VRF

VPN Routing and Forwarding

VPN路由與轉發

 



概述

1.1  產生背景

IP組播的應用越來越廣泛,很多行業開始將其作為應用的解決方案。同時VPN技術在企業網中的應用也越來越普及,在目前的電子政務網、電力數據等企業網絡中,幾乎都是基於BGP/MPLS IP VPN的架構,通過將不同部分劃分到不同的VPN中以實現部門間的數據隔離。同樣地,對部門內部的視頻會議、數據共享等組播業務也需要實現VPN隔離,因此就有了組播VPN日益緊迫的需求。但在RFC 4364中隻提出了針對單播VPN業務的解決方案,並沒有對組播VPN業務的開展給出具體規劃或建議。因此如何在VPN環境中應用組播技術,成為需要解決的重要問題之一。

ISP希望能夠利用BGP/MPLS IP VPN本身的構架為用戶提供組播VPN業務,該方案應具備可擴展性,並充分利用骨幹網自身的組播能力;VPN用戶希望每個SiteCE隻與相應的PE建立PIM鄰居關係,而與遠端SiteCE無關,用戶網絡不需要為使用組播VPN而更改其配置,用戶現有的組播應用方案(如PIM模式、RP位置、RP發現機製等)不受影響。除此以外,在BGP/MPLS IP VPN網絡內開展組播業務還需解決以下幾方麵的問題:

(1)        私網地址空間重疊。由於BGP/MPLS IP VPN網絡允許各VPN的私網地址空間重疊,因此不同VPN用戶所使用的組播源和組播組地址可能是重疊的,PE需要能夠將私網組播數據正確地轉發給同一VPN內的用戶。

(2)        公網支持組播功能。私網組播數據除了在私網內進行組播轉發外,如果在公網中也能進行組播轉發,將使公網的數據負載大大減少,從而節約帶寬。

(3)        在公網對私網組播數據進行RPF檢查。組播數據的轉發模式與單播不同,要根據組播源地址和入接口對組播數據進行RPF檢查,隻有通過檢查才能被轉發。而在BGP/MPLS IP VPN網絡中,由於公網中的P設備無法獲得私網路由,因此不能直接對私網組播數據進行轉發。

(4)        私網組播數據實現按需發送。一個VPN由多個Site構成,每個Site連接到不同的PE,但並非每個Site都需要組播數據,因此如果私網組播數據通過公網時隻流向那些有需求的PE,將會減少PE的負荷。

(5)        對現有網絡改造小。目前,BGP/MPLS IP VPN網絡已被廣泛應用,要在現有網絡基礎上開展組播業務,應對現有網絡進行最小的改造,盡量使用現有設備的功能實現對組播VPN的支持,以降低網絡建設成本。

為了解決在BGP/MPLS IP VPN網絡中運營組播業務所麵臨的這些挑戰,IETF製訂了相關草案——draft-rosen-vpn-mcast,在該草案的曆史版本中曾提出過組播VPN的三種解決方案:MD方案、VPN-IP PIM方案和基於PIM NBMA技術的MD方案,這三種方案優缺點的比較如1所示。

表1 各方案優缺點比較

方案

優點

缺點

MD方案

l      PIM狀態受控

l      骨幹網穩定

l      利用骨幹網的組播能力,不需升級P

l      組播流量泛洪到所有的PE,高速流會增加PE的負擔

VPN-IP PIM方案

l      骨幹網使用組播

l      VPN內無組播,則骨幹網也不會生成組播狀態

l      組播路由最優,組播流量隻到達有需要的PE

l      組播狀態表規模不可控,無法保證骨幹網穩定性

l      需修改PEPPIM機製,增加組播標簽支持

基於PIM NBMA技術的MD方案

l      骨幹網無PIM狀態

l      組播流量在PE上進行複製,導致PE過載

l      不需要的組播流量對骨幹網增加額外負擔

 

1.2  技術優點

在以上三種解決方案的較量中,MD方案最終脫穎而出,成為當前的主流解決方案——其缺點可以通過為高速流按需創建獨立的隧道來修正。在最新的草案draft-rosen-vpn-mcast-08,已將其它兩個方案刪除。MD方案之所以成為唯一被保留下來的解決方案,主要原因如下:

(1)        MD方案最大的優點是對現有網絡升級簡單,僅需升級PE即可,無需對CEP進行升級或修改其配置,也就是說MD方案對CEP是透明的。骨幹網不必知道特定VPN內有多少個組播組的業務,於是骨幹網的穩定性得到了保證。

(2)        MD方案利用公網自身的組播轉發能力,解決了RPF檢查問題。通過在PE將私網組播數據包封裝成公網組播數據包,然後利用公網固有的組播轉發能力實現私網組播數據在公網的組播轉發。

(3)        MD方案為ISP提供了控製手段,方便骨幹網絡的規劃和控製。ISP對自己的骨幹網具有獨立的控製權,而不需要關注VPN內部的業務信息。

(4)        MD方案支持所有的PIM模式,而且骨幹網與VPN中的PIM模式相互獨立,使ISPVPN用戶可以選擇和保留各自的PIM模式。

MD方案基於現有的MPLS VPN架構,升級簡單、兼容性好,是VPN支持組播的必然趨勢。

MD VPN技術實現

2.1  MD VPN概述

顧名思義MD是一個集合,它由一些相互間可以收發組播數據的VRF組成——我們將每個VPN實例獨立維護的單播路由轉發表稱為VRF,相應地稱支持組播業務的VRFMVRF,它同時維護單播和組播路由轉發表。不同的MVRF加入到同一個MD中,通過MD內自動建立的MT將這些MVRF連接在一起,實現了不同Site之間的組播業務互通,從而形成了一個組播VPN網絡。

在同一MD中建立的PE間的隧道稱為MT,它用於在多個MVRF之間傳輸組播協議和數據報文。對於MVRF來說,MT就像是一個多路訪問的LAN網絡,同一MD內的各MVRF通過MTI接入這個網絡中。

如同一個VRF隻能屬於一個VPN,一個MVRF也隻能屬於一個MD。每個MD會被分配一個獨立的組播地址,稱為Share-GroupShare-Group是一個MD的標誌,在骨幹網中是唯一的,不同MDShare-Group必須不同。當兩個MVRF之間通信時,C-PacketGRE方式被封裝在P-Packet裏通過MT進行傳輸,P-Packet的源地址為PE用來建立BGP連接所使用的接口IP地址,目的地址為Share-Group

&  說明:

為了描述方便,我們將骨幹網的屬性用“P-”來表示,將MVRF實例化的屬性用“C-”來表示。譬如,本文中將VPN中的組播協議報文稱為C-Control-Packet、組播數據報文稱為C-Data-Packet,二者統稱C-Packet;而骨幹網中的組播協議報文則稱為P-Control-Packet、組播數據報文稱為P-Data-Packet,二者統稱P-Packet

 

MD方案的基本思想是:在骨幹網中為每個VPN維護一棵稱為Share-MDT的組播轉發樹。來自VPN中任一Site的組播報文(包括協議和數據報文)都會沿著Share-MDT被轉發給屬於該MD的所有PEPE收到組播報文後,如果其MVRF內有該組播組的接收者,則繼續向CE轉發;否則將其丟棄。

圖1 MD VPN解決方案示意圖

1所示,三個MVRF屬於同一MD,各MVRF之間已通過配置和協議交互建立起了MTC-Packet在源PE(如PE 1)處被封裝在P-Packet中,並通過MT到達另一SitePE:如果某PE(如PE 2)的MVRF內有接收者,則該PE將剝掉P-Packet的報文頭還原成C-Packet轉發給其CE;如果某PE(如PE 3)的MVRF內沒有接收者,P-Packet將被該PE直接丟棄。

由上可以看出,MD方案存在一個重要的缺點:在骨幹網中,組播數據將沿Share-MDT轉發給MD內的所有MVRF,即使某些MVRF並未連接有該組播組的接收者。這將導致大量帶寬被無謂地消耗,而且當PE連接有多個MVRF時,這些無用的組播數據流也會給PE增加不小的負擔。為此,MD方案提出一個權衡組播路由優化與可擴展性的折中方案:對於流量較小的組播業務,仍使用Share-MDT;而對於流量較大的組播業務,則為其單獨分配一棵稱為Switch-MDT的組播分發樹,將組播數據以Switch-Group為目的地址沿Switch-MDT轉發給那些真正有接收需求的PE

2.2  Share-MDT

2.2.1  Share-MDT的建立

Share-MDTMD方案最基本的思想,它是一棵建立在同一VPN內所有PE之間的組播分發樹,各MVRF間交互的所有組播協議和數據報文都通過由這棵分發樹所形成的MT進行轉發。Share-MDT將一直存在於骨幹網中,而不論骨幹網或者VPN中是否有實際的組播業務。

&  說明:

l      Share-MDT的組播源地址就是PE用來與其它PE建立IBGP連接的接口IP地址。這個是必須的,因為後續的RPF檢查需要依據這個接口IP地址。

l      Share-MDT的組播組地址是預先規劃好的(即Share-Group),由管理員在每個MVRF上進行配置。屬於同一MD的所有MVRF上所配置的組地址必須相同,而分屬不同MDMVRF上所配置的組地址則必須不同。

 

圖2 Share-MDT的建立過程

2所示,以骨幹網中運行PIM-SM為例,Share-MDT創建的具體過程如下:

l              當在PE 1MVRF上配置Share-Group之後,PE 1就會向骨幹網RP發起(*Share-Group)加入,並在骨幹網沿途各設備上創建(*Share-Group)表項。PE 2PE 3的加入過程與此類似。

l              當在PE 1MVRF上配置PIM之後,PIM協議會周期性地組播PIM Hello消息,PE 1將其封裝成P-Data-Packet並向骨幹網RP發起注冊,以IBGP接口地址S為組播源地址、Share-Group為組播組地址,在骨幹網沿途各設備上創建(SShare-Group)表項。PE 2PE 3的注冊過程與此類似。

最終,在MD中形成一棵以RP為根,PE 1PE 2PE 3為葉的RPT,以及連接各PERP的三棵相互獨立的SPT,並由這些RPTSPT共同構成Share-MDT

2.2.2  PIM鄰居關係

3所示,在MD方案中存在以下三種PIM鄰居關係:

l              PE-P鄰居關係:PE通過骨幹網中的PIMP建立的PIM鄰居關係。

l              PE-CE鄰居關係:PE通過其MVRF中的PIMCE建立的PIM鄰居關係。

l              PE-PE鄰居關係:本地PE與遠端PE通過各自MVRF中的PIM建立的PIM鄰居關係。

圖3 PIM鄰居關係示意圖

MD方案中,骨幹網中的PIM用於在PE之間建立MT以及為骨幹網提供非VPN的組播服務;而MVRF中的PIM則用於在PECE之間建立PIM鄰居關係以及在各PE之間通過MT建立PIM鄰居關係,前者用以創建MVRF自有的組播路由轉發表和發現本VPN內的RP信息,後者用以發現RPF鄰居和檢測對端PEPIM能力。

2.2.3  PE上的接口類型

當在VRF上使能了組播路由功能後,MVRF就創建完畢了。PIMIGMPMSDP等組播協議都可以在MVRF內啟動和工作,每個MVRF隻包含本VPN內的組播路由轉發信息。MT的創建會使全局路由轉發表(以下簡稱全局MVRF)創建(*G)或者(SG)組播路由表項。MVRF中的(*G)和(SG)表項會將MTI包含在入接口或出接口列表中。對於一個PE來說,我們可以為其定義以下三類接口:

l              PNI:是指PE上連接P設備的接口。從PNI收發的報文使用全局MVRF進行路由,全局MVRF中保存的是骨幹網的路由轉發信息。

l              CNI:是指PE上連接CE設備的接口。從CNI收發的報文使用該接口所屬的MVRF進行路由,MVRF中保存的是該Site的私網路由轉發信息。

l              MTI:是PE上的虛擬接口,當配置完Share-MDTPIMIBGP連接也建立起來之後,MTI就已自動創建並up起來了。MTI就是MT的入/出口,也相當於MD的入/出口。在MVRF看來,MT就像一個LAN網絡,所有MVRF都通過MTI接入到這個網絡中。由於MTI隻收發組播報文而不處理單播報文,這就要求進行RPF檢查時采用其它方法。

2.2.4  MVRFRPF檢查

RPF檢查是PIM協議重要的組成部分,PIM使用單播路由表來確定RPF信息,包括用於報文RPF檢查的RPF接口信息和用於PIM加入/剪枝消息的RPF鄰居信息。MVRFRPF檢查有以下兩種應用場景:

1. 使用全局MVRF進行RPF檢查

PE使用全局MVRF進行RPF檢查時,其情形與不存在組播VPN時完全一樣。如4所示,此時Share-MDT尚未建立起來,PE 2對來自P的組播報文進行RPF檢查時,RPF接口為PE 2PNI接口Serial2/1RPF鄰居為P

圖4 使用全局MVRF進行RPF檢查

2. 使用MVRF進行RPF檢查

PE使用MVRF進行RPF檢查時,又可分為以下兩種情況:

(1)        RPF接口屬於同一MVRF。這種情形也與不存在組播VPN時完全一樣。如5所示,PE 1對來自CE 1的組播報文進行RPF檢查時,RPF接口為PE 1CNI接口Ethernet1/1RPF鄰居為CE 1

圖5 RPF接口屬於同一MVRF

(2)        RPF接口屬於全局MVRF。這種情況下組播報文來自遠端MVRF,由於每個MVRF中隻有一個MTI,它就是指向組播源的RPF接口。若某遠端PE既是本地PE到達組播源的BGP路由的下一跳,又是本地PEPIM鄰居,則該遠端PE就是本地PERPF鄰居。如6所示,此時Share-MDT已建立完畢,PE 1通過MT發送組播報文給PE 2,當PE 2對該報文進行RPF檢查時,RPF接口為PE 2MTI接口MTunnel0RPF鄰居為PE 1

圖6 RPF接口屬於全局MVRF

2.2.5  Share-MDT的數據轉發

Share-MDT建立完畢之後,就可以在VPN中進行對組播數據的傳遞了。我們分以下兩種情況來介紹組播數據通過Share-MDT轉發的過程:

1. 組播源與接收者處於同一MVRF

當組播源與接收者處於同一MVRF時,隻需在MVRF內部進行協議交互與數據轉發,其情形與不存在組播VPN時一樣。

圖7 組播源與接收者處於同一MVRF

7所示,CE 1連接組播源SCE 2連接組播組G的接收者。PE 1收到來自CE 2PIM加入消息後,將接口Ethernet1/2加入到(*G)表項的出接口列表中,而將接口Ethernet1/1作為該表項的入接口。組播數據從CE 1發送到PE 1,再由PE 1轉發給CE 2

2. 組播源與接收者處於不同MVRF

當組播源與接收者處於同一VPN的不同MVRF時,需要跨MVRF進行協議交互與數據轉發。

圖8 組播源與接收者處於不同MVRF

8所示,VPN內部使用PIM-SMCE 1為該VPN內的RPCE 1連接組播源SCE 2連接組播組G的接收者。CE 2RPCE 1)發送PIM加入消息,PE 2將其封裝成P-Packet並沿Share-MDT發送給MD內的所有PEPE 3解封裝後發現本MVRF內沒有RP,便將其丟棄;PE 1解封裝後發現本MVRF內有RP,於是將還原後的PIM加入消息向CE 1轉發,同時將MTunnel0加入到(*G)表項的出接口列表中。CE 1收到PIM加入消息後,將組播數據(SG)轉發給PE 1PE 1將其封裝成P-Packet並沿Share-MDT發送給MD內的所有PEPE 3解封裝後發現本MVRF內沒有G的接收者,便將其丟棄;PE 2解封裝後發現本MVRF內有G的接收者,於是將還原後的組播數據向CE 2轉發。

2.3  Switch-MDT

Share-MDT最大的優點是骨幹網上的組播狀態穩定,而最大的缺點則是帶寬利用率低:當組播流量較大時,無用的組播流會消耗Share-MDT上那些並無接收者的分支上的寶貴帶寬。

針對這個問題,MD方案提出了Switch-MDT解決方案:在組播源所在PE上設置一定閾值,當該PE檢測到組播數據的轉發速率達到閾值時將新建一棵Switch-MDT,隻有對這個組播數據感興趣的PE才會加入這棵新樹。切換完成後,組播數據將不再以Share-Group、而改以Switch-Group為目的地址沿Switch-MDT被轉發給那些真正有接收需求的PE

&  說明:

Switch-MDT所使用的組地址Switch-Group也是預先分配的。一個Share-Group唯一確定一個Switch-Group-Pool以備進行Switch-MDT切換,在進行Switch-MDT切換時,從Switch-Group-Pool中選取一個空閑的地址作為Switch-Group

 

2.3.1  Switch-MDT切換消息

Switch-MDT切換消息是一種UDP報文,它攜帶有組播源地址、組播組地址和Switch-Group地址。當發起Switch-MDT切換時,它將被封裝在P-Packet中,由源PESwitch-Interval為間隔(缺省為60秒)周期性地通過Share-MDT發送給同一MD的所有PE224.0.0.13)。源PE將一直發送Switch-MDT切換消息,直至組播數據的轉發速率低於了閾值,希望接收該組播數據的PE在收到該消息後將發送PIM加入消息以加入Switch-MDT。此後,當這些PESwitch-Timeout時間內(缺省為180秒)都沒有收到新的Switch-MDT切換消息,其為Switch-MDT創建的組播轉發表項將會被老化刪除。

未連接有接收者的PE在收到Switch-MDT切換消息後不會加入Switch-MDT,但會緩存該消息,以減少將來有接收者時加入Switch-MDT的延時。

2.3.2  Switch-DelaySwitch-Holddown

當組播流量達到或超過閾值、源PE發出Switch-MDT切換消息Switch-Delay時間(缺省為5秒)之後,組播業務才開始通過Switch-MDT發送,這樣就為下遊PE預留出了加入Switch-MDT的時間,以避免切換過程中數據的丟失。

此後,如果組播流量低於了閾值,源PE也不會馬上切換回Share-MDT,而是隻有組播流量在Switch-Holddown時間(缺省為60秒)內一直低於閾值,才切換回Share-MDT,這樣就可以避免切換振蕩。

2.3.3  Switch-MDT切換過程

圖9 Switch-MDT切換

9所示,Switch-MDT切換的具體過程如下:

(1)        PE(如PE 1)周期性地檢測組播數據的轉發速率,一旦滿足切換條件就從Switch-Group-Pool中選擇一個空閑的Switch-Group地址,沿Share-MDT向下遊所有PE發送Switch-MDT切換消息。

(2)        下遊PE收到該消息後,檢查本MVRF內是否有該組播數據的接收者:若有(如PE 2)則向PE 1發送PIM加入消息以加入組地址為Switch-Group地址的Switch-MDT;若沒有(如PE 3)則將該消息緩存起來,以便有接收者時能及時加入Switch-MDT

(3)        PE 1發送Switch-MDT切換消息Switch-Delay時間後,組播數據的傳輸就會從Share-MDT切換到Switch-MDT上了。

2.4  ASMD VPN

2.4.1  ASMD VPN的難題

由於RFC 4364提供了跨越AS的三種單播VPN解決方案:VRF-to-VRF連接方式、EBGP連接方式和Multi-Hop EBGP連接方式,因此MD VPN自然也必須支持這三種解決方案,能夠跨越AS建立起MDT。建立跨ASMDT需要關注以下幾個方麵:

l              PEMVRF內進行RPF檢查時,RPF鄰居必須是遠端PE,而不能是ASBR。因為純粹的ASBR上不會配置MVRF,因而不會建立MT,不會參與MD的任何活動,也無法接收和處理發往MDPIM消息。

l              ASBR在傳播BGP更新報文時會改寫VPNv4路由前綴的下一跳屬性,使到組播源的下一跳鄰居變成了ASBR,而不再是產生該前綴的遠端PE

l              P隻維護AS內部的IGP路由信息,不會有到達其它ASPE的路由信息,除非通過引入BGP路由,否則無法處理去往其它ASPEPIM消息。

l              ASBR未必會有關於其它ASPE的單播路由,所以也不能處理去往其它ASPEPIM消息。

現在我們來分析一下跨AS的三種單播VPN解決方案分別對MD方案的要求:

l              VRF-to-VRF連接方式中,ASBR上配置VRF,並擔任PE的角色,所以MDT隻需建立在各AS內部,不存在處理域間MDT和進行RPF檢查的問題。當組播流到達本ASASBRMVRF之後,將作為組播源進入相鄰ASASBRMVRF。由於不需要建立跨ASMDT,因此不需要更改協議。這種方式唯一的缺點就是其固有的不可擴展性——當VPN很多時,配置的工作量將是可怕的。

l              EBGP連接方式中,ASBR上不配置VRF,所以報文在AS間轉發時必須進行封裝,也就是說需要建立跨域的MDT,而關於其它ASPE的路由信息在本AS的路由器上也未必擁有,P不知道關於其它ASPE的路由信息,於是建立跨ASMDT就缺少基本的支持;ASBR保存了所有VPNv4路由並修改了BGP的下一跳屬性,因此PE在組播VPN內部的RPF檢查也失去了遠端PE的信息。

l              Multi-Hop EBGP連接方式也存在著EBGP連接方式所具備的大部分缺點,但唯一不同的是,Multi-Hop EBGP連接方式保留了VPNv4路由的BGP的下一跳信息,這有助於PE在組播VPN內部進行RPF檢查。

因此,建立跨ASMD VPN必須解決RPF鄰居以及建立跨ASMDTPIM消息的傳遞問題。

2.4.2  ASMD VPN解決方案

由前麵的分析可知,VRF-to-VRF連接方式和Multi-Hop EBGP連接方式為兩種目前可實現的越跨ASMD VPN解決方案。當VPN內的節點通過不同的AS連接時,可以通過VRF-to-VRFMulti-hop EBGP的連接方式建立跨ASVPN

1. VRF-to-VRF連接方式

10所示,VPN跨越了AS 1AS 2兩個自治係統,PE 3PE 4分別是AS 1AS 2ASBRPE 3PE 4通過各自的VPN實例相連,並互把對方視為CE設備。

 

圖10 VRF-to-VRF連接方式示意圖

PE(如PE 1)去往另一ASCE(如CE 2)的單播路由下一跳是本ASASBR(如PE 3),也就是說VPN通過ASBR進行了轉接。通過這種方式實現MD方案,需要在兩個AS裏分別建立MD。兩個MDShare-Group可以相同,也可以不同,組播數據在這兩個MD之間的傳遞通過ASBR進行轉接。

2. Multi-hop EBGP連接方式

11所示,VPN跨越了AS 1AS 2兩個自治係統,PE 3PE 4分別是AS 1AS 2ASBRPE 3PE 4通過各自的公網實例相連,並互把對方視為P設備。

圖11 Multi-hop EBGP連接方式示意圖

PE(如PE 1)去往另一ASCE(如CE 2)的單播路由下一跳是對方ASPE(如PE 2),PE之間通過建立Multi-hop EBGP對等體關係把本AS內的VPN路由傳送到對方AS。通過這種方式實現MD方案,在兩個AS裏隻能建立一個MD,組播數據在這兩個AS之間的傳遞通過域間組播實現。

典型組網應用

3.1  ASMD VPN

圖12 ASMD VPN組網圖

12所示,在同一AS中存在VPN aVPN b這兩個VPN,各VPN中有不同的組播源和接收者。公網中運行OSPFMPLS,各PECE之間運行RIP,並在各PE間建立BGP對等體連接以傳遞私網路由。

開展AS內的VPN組播業務,需要在所有設備的公網實例和VPN實例中分別使能IP組播路由;在PECE連有接收者的接口上使能IGMP;在各設備的所有公、私網接口上均使能PIM-SM,並分別為公網和各VPN選取合適的C-BSRC-RP。此外,還需要為VPN aVPN b選取各自不同的Share-Group地址以及Switch-Group-Pool範圍。

3.2  ASMD VPN

圖13 ASMD VPN組網圖

13所示,在兩個AS中各存在VPN aVPN b這兩個VPN,各VPN中有不同的組播源和接收者。在各AS內分別運行OSPFMPLS,各PECE之間運行OSPF,並在所有PE間建立BGP對等體連接以傳遞私網路由。

開展跨ASVPN組播業務,需要在所有設備的公網實例和VPN實例中分別使能IP組播路由;在CE連有接收者的接口上使能IGMP;在處於ASBR位置的PE 2PE 3之間建立MSDP對等體連接;在各設備的所有公、私網接口上均使能PIM-SM,並分別為各AS內的公網以及各VPN選取合適的C-BSRC-RP。此外,還需要為VPN aVPN b選取各自不同的Share-Group地址以及Switch-Group-Pool範圍。

參考文獻

l              RFC 4364BGP/MPLS IP Virtual Private Networks (VPNs)

l              draft-rosen-vpn-mcast-08Multicast in MPLS/BGP IP VPNs

 

 

Copyright ©2008 杭州華三通信技術有限公司 版權所有,保留一切權利。

非經本公司書麵許可,任何單位和個人不得擅自摘抄、複製本文檔內容的部分或全部,並不得以任何形式傳播。

本文檔中的信息可能變動,恕不另行通知。

附件下載

聯係我們