组播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 杭州华三通信技术有限公司 版权所有,保留一切权利。

非经本公司书面许可,任何单位和个人不得擅自摘抄、复制本文档内容的部分或全部,并不得以任何形式传播。

本文档中的信息可能变动,恕不另行通知。

附件下载

联系我们