L3VPN多实例路由协议

2018年7月1日22:45:07 发表评论 575 views

1.    路由协议的多实例

所谓路由协议的多实例,就是指在一个独立的VRF接口表和路由表上,运行一个与这个VRF相配套的路由协议。因此,在同一台路由器上公网以及不同VRF里路由协议的实例之间相互隔离,配置、功能上都是基本独立的。从理论上讲,任何路由协议都可以支持多实例,我们常见的路由协议RIP、OSPF、BGP等都支持多实例。

一般情况下,路由协议的多实例使用在PE上,即MPLS VPN这个场合下。为了实现MPLS VPN的功能,PE上的路由协议多实例需要与MP-IBGP路由协议交互。RIP、BGP等路由协议的多实例和MP-IBGP的交互,其实就是复杂一点的引用关系,即MP-IBGP将VRF中RIP、BGP多实例里面的路由加上RD变成VPN-IPv4路由引入MP-IBGP,同时携带诸如私网标签、RT LIST这些属性。对端PE再将VPN-IPv4路由的RD去掉,根据RT LIST引入不同VRF的RIP、BGP多实例里即可。配置上也是使用“引入”这样的命令来实现交互的。这个交互过程前面已经讲过,不再赘述。OSPF和MP-IBGP的交互相对复杂,后面专门讲述。

另外,大家会有疑问,路由协议的多实例和VRF这些东西只能用在MPLS VPN体系里面么?当然不是,VRF和路由协议的多实例完全可以作为一种手段,将一个路由器分割为多个路由器。这种应用我们也称之为MultiCe,它和MPLS VPN没有关系,即多实例中的路由不需要引入MP-BGP,也不需要为这些路由分配相应的私网标签、RT LIST等等,只是简单的将路由器划分,建立独立的路由表、接口表、以及对应的路由实例。

2.    OSPF多实例与MPLS VPN

OSPF路由协议的多实例要复杂一些,这是因为OSPF路由协议本身追求尽善尽美的特点,决定了它应用在MPLS VPN体系中能够提供更丰富、安全的使用方式。

我们将OSPF多实例在MPLS VPN里面的应用,简称为OSPF VPN。

          2.1简单的OSPF VPN应用

  

L3VPN多实例路由协议

1:简单的OSPF多实例在MPLS VPN中的应用

从路由层面上讲,普通路由协议的多实例应用在MPLS VPN体系中,仅仅是引入关系。如果OSPF这样简单应用也是可以的,那么从MP-BGP中插入VRF的时候,只是相当于PE上的OSPF实例引入了MP-BGP路由,因此只能将原站点的OSPF区域内路由还原成ASE等外部路由的让其他站点学习。

1中,研发部门在北京的CE和PE运行OSPF路由协议,那么在PE上看到的10.0.0.0/16这条路由自然是一个OSPF的区域内路由;如果CE上引入了50.0.0.0/16这条直连路由,那么在北京PE的OSPF多实例看来50.0.0.0/16这条路由是ASE路由。但是不管怎样,这两条路由被MP-IBGP携带到上海的PE并引入OSPF多实例的时候,都变成了两条ASE的LSA发布给所有上海站点的其他设备,因此上海的CE以及其他设备学到这两条路由都变成了ASE路由。

这是无法忍受的,因为OSPF能够支持多种多样的路由类型,一个公司的VPN网络,怎能够将ASE路由和OSPF内部路由混淆呢?为了使得路由的优先级及其他属性在MP-IBGP传输时不丢失,就必须随着路由携带更多的MP-BGP属性。

          2.2  OSPF VPN的解构和扩展团体属性

为了保证OSPF路由属性(路由的类别、路由的COST、所属区域等等)在MP-IBGP传输时不丢失,自然是携带的信息越多越好。但是无论如何都不可能将远端站点的拓扑还原,因为那样就意味着要同步LSDB,也就是说即使两个站点的OSPF配置成了一个区域,也无法沟通拓扑,只能通过MP-IBGP沟通路由。相互直接沟通路由的路由算法,也就是DV算法,在OSPF体系中是存在的,即区域间路由和外部路由。那么,可以说,如果OSPF多实例不去伪造拓扑,那么通过MP-IBGP传递而来的OSPF路由最多只能还原成区域间的OSPF路由。

L3VPN多实例路由协议

2:OSPF VPN的三层体系

因此,OSPF多实例在MPLS VPN体系中仿佛变成了以上的三层构架,即各个站点里面可以有骨干区域,但是运营商网络部分像是一个更高层的骨干区域——Super BackBone Area,而PE就是这个Super BackBone Area的边界路由器,可以叫它Super ABR。

Super ABR在把站点内的普通区域或者骨干区域的路由注入到Super BackBone Area的同时,也会把Super BackBone Area区域内的路由注入到站点的普通区域或者骨干区域,根据原来路由类别的不同,还原成区域间路由或者ASE路由,这就是所谓的OSPF的三层结构。在普通的OSPF两层构架之上增加了一个Super BackBone Area,虽然这个Super BackBone Area里只是通过MP-IBGP传输路由。

OSPF VPN中常用的扩展团体属性下面列举并介绍一下,相关格式以及详细定义请见RFC: OSPF XXXX as the PE/CE Protocol in BGP/MPLS VPNs。

l  OSPF Domain ID:必选属性

OSPF Domain ID是一个在OSPF VPN中新增的概念,其目的就是将各个站点的OSPF实例划分到一个OSPF域内。我们知道,通常情况下的OSPF域是一个连通的整体,域内都是OSPF的内部路由(区域内路由或者区域间路由),域外的路由只能是ASE或NSSA这种路由,它们的优先级较低。

而在MPLS VPN体系中,所有站点的OSPF路由都会通过MP-IBGP到达任意一个站点,如果看到原有路由类别就是OSPF内部路由,就一律还原成3类LSA,还原成区域间路由,显然变成了所有站点都在一个OSPF域内了。

为了增加控制,每个站点的OSPF都必须配置一个域ID,域ID相同的站点之间,路由可以还原成OSPF内部路由(只能是区域间路由),而域ID不相同的站点之间,路由只能还原成ASE或NSSA路由,即来自不同的域的路由按照OSPF外部路由对待。

按照前文中RFC的要求,每个站点配置的域ID可以是个列表,路由注入MP-BGP的时候只携带其中的主域ID,在目的端通过一套匹配的过程,来决定他们是不是在一个域内。

l  Area Number:必选属性

Area number即原路由所在的区域号。对于一般的路由类型来说,这个Area number是是意义不大的,因为不论两个站点的OSPF是不是一个区域,路由最多也只能还原成3类LSA。

但是对于Sham Link Endpoint Address类型的路由,Area number是有用的,因为Sham Link是跨越运营商公网的一条区域内链路, Sham Link的两端要在一个区域内才能建立Sham Link连接。有关Sham Link的相关技术,后面会专门讲述。

l  OSPF路由类型:必选属性

就是源站点OSPF路由的类别,目的站点的PE会根据路由的这个属性,来决定还原成什么样的LSA,其主要取值有:

1、2 :区域内路由,具体是1或2取决于路由来自Router Lsa还是Network LSA

:区域间路由

   :ASE外部路由

   :NSSA外部路由

129  :Sham Link 端点地址路由(Sham Link Endpoint Address),Sham Link建立所使用的。

l  OSPF Ruter ID:可选属性

Router ID作为一个可选属性,被MP-BGP携带到对端站点并无太多实际作用,因为不管对端PE将MP-BGP还原成3类或者5、7类LSA,其Router ID都是对端PE的Router ID,相应的对端PE也会变成ABR或者ASBR。

          2.3  CE双归属与BackDoor链路

CE的双归属是指一个CE同时连接到两个PE上,做上行备份。而BackDoor链路,指的是一个VPN的不同站点间,除了通过共网连接以外,还有一条后门链路备份连接。这两种连接方式有其共同点,都是一个用户的网络连接到了多个PE上,如图:

L3VPN多实例路由协议

3:CE双归属与BackDoor链路

如图3所示,蓝色部分研发部门的CE设备即连接到了两个PE上,互为备份,称之为CE的双归属;而红色的后门链路,却将财务部门在北京和上海的站点连为一体,与公网的联接互为备份,称之为BackDoor链路。这种组网增强了网络的稳定性,但同是也为OSPF VPN的应用带来了麻烦。OSPF本身是没有环路的,区域内路由计算通过SPF运算天然的解决了此问题,区域间路由计算通过区域的二层结构解决,外部路由通过携带引入者的Router ID解决,等等。但是由于MPLS VPN体系中,路由信息经过骨干网以后有丢失和转变的情况,导致路由环路的产生。

2.3.1      外部路由的VPN Tag

外部路由避免路由环路的主要方式,就是在ASE LSA泛洪的整个过程中不更改其发布者的Router ID。但是当PE将私网路由还原成ASE LSA到OSPF多实例的时候,这些LSA的Adv Router ID就变成了PE上这个OSPF实例的Router ID,最初这条路由的引入者的信息丢掉了,这条路由变成是PE上这个OSPF实例引入的路由了。这也不太会引入什么问题,但是如果网络里面有CE双归属与BackDoor链路这种组网的话,就有了问题。

L3VPN多实例路由协议

4 ASE路由的VPN Tag

如上图所示,右边的CE设备引入了外部路由,并被PE3插入到MP-IBGP中传播给所有的PE,那么PE1和PE2都会产生相应的ASE LSA发布给CE,同样都会从CE那里学习到对方产生的ASE路由。这样就带来了混乱,两个PE上就要做一下路由的优选,即从站点内部学来的OSPF ASE路由和插入VPN的BGP路由之间作一个优选。假设PE 1上,优选了PE2引入的OSPF ASE路由,那么它就会收回自己产生的ASE LSA,反而将这条路由注入到MP-IBGP中。PE3收到这条MP-IBGP路由以后可能优选这条路由或者优选本地的ASE路由,不管怎样,都会造成路由的震荡或者带来路由环路的隐患。

因此,为了避免这种情况,PE上在将MP-IBGP路由还原成ASE LSA的时候,将产生一个VPN Tag携带在ASE LSA的Tag字段里。如果PE收到的ASE LSA的VPN Tag和本地OSPF实例的VPN Tag一致,此LSA就不参与路由计算。这个VPN Tag一般来源于MP-IBGP的AS号,因为所有的PE都在一个BGP域中,因此AS号码是一样的,生成的VPN Tag也是一样的,这样就避免了上述情况的发生。VPN Tag是可以配置的。

2.3.2      区域间路由的Down Bit

同样,如果有CE双归属或者BackDoor链路这种组网的时候,将MP-IBGP路由还原成3类LSA,不做相应处理也是一样危险的。因此在PE产生3类LSA的时候都在LSA中设置Down Bit,PE如果收到的3类LSA携带了Down Bit就不参与路由计算。

          2.4  OSPF VPN中的区域零

在站点内部署OSPF是要非常关注骨干区域部署的方法,否则会造成PE还原的远端站点的私网路由不能被所有设备学到。这是因为OSPF的如下设计决定的:

1.ABR设备只计算骨干区域内的3类LSA

2.ABR只会将骨干区域内的3类LSA转发到非骨干区

L3VPN多实例路由协议

5 OSPF VPN的区域零部署

因此如图5所示,当PE将MP-IBGP携带来的私网路由还原成3类LSA的时候,CE设备就不能够学习到这些路由,因为CE设备作为ABR,它只计算区域零里面的3类LSA,而PE还原的3类LSA都在Area 1里面。同时,最左边的C设备也学不到这些路由,因为CE设备也不会将PE产生的3类LSA从非骨干区域转换到骨干区域里。

要记住以下口诀:尽量不要在站点内部属骨干区域;如果站点内部署骨干区域,那么PE和CE之间的链路只能在区域零里;在CE双归属或者BackDoor链路的情况下,最好所有的链路都在区域零,否则备份功能可能有问题。   

          2.5  Sham-Link概述

上面提到了,通过MP-IBGP携带私网路由的方式,只是传递路由,而且会丢失很多路由的信息,到达对端PE后的还原工作也只是尽力而为式的引入,并不能真正的使得OSPF的拓扑信息得到沟通。那么能不能做到各个站点的OSPF能够真正连通呢,只要各站点间的OSPF之间有一条跨过公网的链路即可,这就是Sham-Link。

L3VPN多实例路由协议

OSPF Sham-Link

Sham-link就应该像一条正常的OSPF链路一样,有自己的OSPF接口,能够互相发送OSPF协议报文,建立邻居,传送LSDB等等,同时作为Router Lsa的一部分参与到路由计算中。Sham-link存在于两个PE之间,而且最好各个PE之间的Sham-link是全连接的,这样携带私网路由的工作就可以由Sham-link完成,但是MP-IBGP并非不再需要了,它依然要用来携带Sham-Link端点路由。

每个站点都需要通过配置指定Sham-link在哪个区域,所有的PE上Sham-link端点都应配置在一个区域内。同时也要配置自己的Sham-Link端点路由,此路由会被MP-IBGP携带到每个PE上,这个路由的扩展团体属性中说明了它是Sham-Link端点类型的路由,因此每个PE都很清楚它的Sham-link对端有哪些,发往这些Sham-Link端点路由的OSPF报文,就自然地通过PE间的MPLS隧道到达对端PE,到达了对端Sham-Link的接口上,完成了报文的交互、LSDB的交互、邻居的建立。这也称作Sham-link的自配置,也就是说只需要在所有PE上指定自己的Sham-Link端点路由,那么Sham-link的全连接就应该能够自动的建立起来,完成OSPF的路由交互。因此,如果配置了Sham-link,那么在PE配置中,MP-BGP就不需要配置引入OSPF多实例的路由,反之,OSPF多实例也不需要配置引入MP-BGP的路由。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: