BGP MPLS/VPN technolgy (part 1)

来源:互联网 发布:方维直播源码漏洞 编辑:程序博客网 时间:2024/04/28 15:48

BGP-4的多协议扩展

 1.1 RFC2858的介绍

原有BGP协议系统源自RFC1771:边界网关协议-4。可以用于转发IPv4协议的信息,但是在新型网络技术的应用(如MPLS/VPN)中,原有的BGP-4协议承载路由信息的时候,无法达到期望的目标,为此,作为对BGP-4的扩充,IETF发布了RFC2858,使得新型的MP-BGP协议能够支持多种网络协议(如IPv6IPX等)。这种协议扩展是向后兼容的,即支持MP-BGP的路由器可以和不支持MP-BGP的路由器同时工作。

RFC1771中规定的BGP-4协议报文中,仅仅有三部分内容是IPv4协议系统所指定的:Next-HopAggregatorNLRI。为了使BGP-4协议能够支持多种网络层协议的路由信息,只有两种能力是必须被添加到协议中的:

(a)通过Next-Hop信息连接某种特定网络层协议的能力;

(b)通过NLRI连接某种特定网络层协议的能力。

为了识别多种网络层协议中的协议实体,本文档使用了如RFC1700中定义的Address Family概念。

在原有BGP-4协议系统中,路径属性是包含在Update报文中的,不论Update报文转发的路由信息中包含了NLRI信息或者只有Withdrawn信息。对于MP-BGP来说,它认为下一跳信息(为Next-Hop属性所提供)仅仅在与目的地址可达信息的通告连接中有意义,在目的地不可达的情况(撤销路由信息-Withdrawn)下是没有什么意义的。所以目的地可达信息的通告应该和与之相关的下一跳信息的通告相关联,而目的地可达信息的通告应该与撤销路由信息的通告隔离开来。[kernix1] 

为了提供向后兼容性,也为了使向BGP-4扩展多协议能力的简约化,RFC2858定义了两个新的路径属性:Multiprotocol Reachable NLRI(MP_REACH_NLRI)Multiprotocol Unreachable NLRI(MP_UNREACH_NLRI)

第一个属性(MP_REACH_NLRI)是用来承载聚集了可达目的地信息与提供转发这些可达目的地信息的下一跳信息的组。第二个属性(MP_UNREACH_NLRI)可以承载目的地不可达信息的组。这两种属性均为可选非转发的。如果BGP speaker不提供多协议支持能力[kernix2] ,那就只是简单的忽略带有这些属性的信息,同样也不会将这些信息传递给别的BGP speaker

1.1.1 MP_REACH_NLRI属性

       此属性类型码为14,是一个可选非转发属性,用于以下场合:

(a)    通告一个可用路由给邻居;

(b)    允许一个路由器通告它的网络层地址,网络层地址就像下一跳信息一样用来指示被列在MP_NLRI属性的网络层可达信息域中的目的地。

(c)    准许一个给定的路由器报告存在于本地系统中的部分或者全部附属子网点信息(Subnetwork Points of AttachmentSNPAs

MP_REACH_NLRI属性编码结构如下所示:

 

 

Address Family Identifier (2 octets)

Subsequent Address Family Identifier (1 octet)

Length of Next Hop Network Address (1 octet)

Network Address of Next Hop (variable)

Number of SNPAs (1 octet)

Length of first SNPA(1 octet)

First SNPA (variable)

Length of second SNPA (1 octet)

Second SNPA (variable)

……

Length of Last SNPA (1 octet)

Last SNPA (variable)

Network Layer Reachability Information (variable)

MP_REACH_NLRI属性的编码示意图

介绍每一个字段的用法与意义如下:

Address Family Identifier(地址族标识)

           这个字段携带网络层协议与网络地址的连接标识。目前这个字段定义的值在RFC1700中指定(参见Address Family Numbers部分)。

Subsequent Address Family Identifier(并发地址族标识)[kernix3] 

           本字段携带包含在属性中的网络层可达信息(NLRI)类型的补充信息。

     Length of Next Hop Network Address(下一跳地址长度)

           一个字节长度的下一跳地址长度字段,表明了下一跳地址的长度。

       Network Address of Next Hop(下一跳地址)

            本字段长度可变,包含了到达目的系统的下一个路由器的地址。

       Number of SNPAsSNPA的数目)

一个字节,包含了SNPA的确切数目,如果为0值则表明在这个属性里面包括没有任何SNPA

Length of Nth SNPA(第NSNPA的长度)

           一个字节长度,表示了“下一跳信息中第NSNPA”的长度。

    Nth SNPA of Next Hop(第NSNPA

可变长度区域,包含了由“Network Address of Next Hop”域指定地址的路由器的一个SNPA。区域的长度为整数个字节,即对SNPA的长度半值(半个字节)进行向上取整;如果SNPA包含了奇数个半字 节,那么对该值进行全零的半字节补齐。

Network Layer Reachability Information(网络层可达信息)

可变长度区域,列出了将在本属性中被通告的可用路由的NLRI信息。当并发地址族标识(Subsequent Address Family Identifier)域被设置为RFC2858中定义的某个值时,所有NLRI将会按照“NLRI encoding”中指定的方式进行编码处理。

       Next-Hop信息包含在MP_REACH_NLRI属性中,当通告一个MP_REACH_NLRI属性到一个外部“对端”时,路由器将设置本地地址为此路由的Next-Hop

如果一条路由是由某个BGP speaker发起的,那么它不能通告一个“对端”的地址到下一跳“对端”。BGP speaker也不能接受一条将自己认为是下一跳的路由(以免出现路由环路)。

BGP speaker通告路由到一个内部“对端”的时候,它不能修改这条路由的下一跳信息。当BGP speaker接收一条经由内部链路的路由时,如果包含在这个属性中的下一跳地址与本地以及远程BGP speaker是在同一子网,那么它就有可能转发数据包到下一跳。

携带MP_REACH_NLRI属性的UPDATE消息必须同样携带ORIGINAS_PATH属性(存在于EBGPIBGP交换中)。而且,在IBGP交换这样一个消息时,还必须携带LOCAL_PREF属性。如果这个消息时来自于外部“对端”,本地系统应该检查在AS_PAHT属性最左边标记的AS是否与发送这个消息的“对端”的AS号码相等。否则本地系统应该发送携带错误码为UPDATE消息出错的NOTIFICATION消息,错误子码应该设置为错误AS_PATHMalformed AS_PATH)。

拥有MP_REACH_NLRI属性的Update报文中不再承载原来的那种NLRI,也不再拥有NEXT-HOP属性,如果一个路由器接受到报文中包含由NEXT-HOP属性,也应该将其忽略。

1.1.2 MP_UNREACH_NLRI属性

       此属性类型码为15,是一个可选非转发属性,用于撤销多个不可用路由的场合:

       属性字段示意如下

 

Address Family Identifier (2 octets)

Subsequent Address Family Identifier (1 octet)

Withdrawn Routes (variable)

MP_UNREACH_NLRI属性结构示意

各个字段的用法与含义如下:

Address Family Identifier(地址族标识)

本字段携带与下层NLRI相关的网络层协议标识。目前这个字段定义的值在RFC1700中指定(参见Address Family Numbers部分)。

Subsequent Address Family Identifier(并发地址族标识)

              本字段携带包含在属性中的网络层可达信息(NLRI)类型的补充信息。

Withdrawn Routes(撤销路由)

可变长度区域。列出将要被从服务中撤销的路由的NLRI。当并发地址族标识域被设置为本文档定义的某个值,每条NLRI都按照“NLRI encoding”一节中指定的方式进行编码处理。

包含有MP_UNREACH_NRLI属性的UPDATE消息并不被要求携带其他路径属性。

1.1.3 NLRI Encoding处理

网络层可达信息被编码成一个或者若干个类似于的二元组,描述如下:

 

Length (1 octet)

Prefix (variable)

 

每个字段域的用法和意义如下所示:               

    Length(长度)

           Length字段按位指出地址前缀的长度。如果是全零,那么表示匹配所有地址。

    Prefix(前缀)[kernix4] 

            Prefix字段包含一个地址前缀,按位补齐成完整字节。填充位不影响前缀的真实值。

1.1.4 错误处理

       如果收到来自一个邻居的包含MP_REACH_NLRI或者MP_UNREACH_NLRI属性    Update消息,而且这个BGP speaker确定这个属性是不正确的,那么BGP speaker应该删除从这个AFI/SAFI值与携带错误MP_REACH_NLRI或者MP_UNREACH_NLRI属性一样的邻居收到的所有BGP路由。在BGP回话持续时间中若是收到这种Update消息,那么BGP speaker应该忽略所有在会话中收到的错误AFI/SAFI并发路由。

       另外,如果收到这种Update消息,BGP speaker可能会中止BGP会话过程。MOTIFICATION消息的指示的错误码、错误子码分别设为“Update Message Error”和“Optional Attribute Error”。

1.1.5使用BGP能力通告(Capability Advertisement)

       应用了多协议扩展的BGP speaker应该使用能力通告过程[BGP-CAP]来测定speaker是否能够和一个特定对端使用多协议扩展的方法。

       能力可选参数域的设置为:Capability Code被设置为1(指明多协议扩展能力)。Capability Length被设置为4

       Capability值域定义如下:

 

AFI(2 Octets)

Res.(1 Octet)

SAFI(1 Octet)

 

AFI  地址族标识符(16位),编码方式同多协议扩展中所设置。

     Res.  保留(8位)区域。发送方应当设其值为0,接收方则忽略它。

     SAFI 并发地址族标识符(8位),编码方式同多协议扩展中所设置。

为了能够在一对BGP speaker之间为特定双向交换路由信息,每个BGP speaker都应该通告对方(通过能力通告机制):我支持这种特别的路由!

1.2 针对BGP/MPLS VPN所进行的扩展方案

1.2.1 BGP/MPLS VPN概述

RFC 2547bis定义了一种机制,允许服务供应商使用自己的IP骨干,为客户提供VPN服务。RFC 2547bis VPN也称为BGP/MPLS VPN,因为它使用BGPVPN路由信息分布到供应商的骨干中,并使用MPLSVPN流量从一个站点转发到另一个站点上。

这种方法的主要目标是:

l         极大地简化服务,即使客户缺乏IP路由经验,客户仍可以使用这些服务

l         实现极高的服务扩充能力和灵活性,便于大规模部署

l         允许服务供应商自己或由服务供应商和客户一道创建VPN的策略

l         允许服务供应商提供关键增值服务,以提高客户忠诚度

对于BGP/MPLS VPN的架构,IETF设立了专门的drift进行讨论,最新的成果在draft-ietf-ppvpn-rfc2547bis-01中,此drift发布于20035月,其中大部分操作应该可以设立为标准。

对于BGP/MPLS VPN的详细介绍及其部署请查看RFC2547bis。本文中只介绍与MP-BGP相关的部分。

1.2.2 VPN-IPv4地址结构

       VPN客户经常管理自己的网络,并使用RFC 1918专用地址空间。如果客户没有使用全球唯一的IP地址,那么可以使用相同的32IPv4地址,识别不同VPN中的不同系统,这会导致路由困难,因为BGP假设它携带的每个IPv4地址都是全球唯一的。为了解决这个问题,BGP/MPLS VPN支持一种机制,通过使用VPN-IPv4地址家族及部署多协议BGP扩展(MP-BGP),把非唯一的IP地址转换成全球唯一的地址。

       重叠地址空间提出的一个挑战是,如果传统BGP看到同一个IPv4地址前缀有两条不同的路由(前缀被分配给不同VPN中的系统)BGP将像仅有一条路由一样处理前缀。结果,有一个VPN系统是不可达的。解决这个问题要求一种机制,允许BGP消除前缀歧义,这样就可以安装两条到达该地址的完全不同的路由,每个VPN一条。通过定义VPN-IPv4地址家族,RFC 2547bis支持这种功能。

       VPN-IPv4地址一共12字节,包括8字节的RD(Route Distinguisher)4字节的IPv4地址前缀。下图说明了VPN-IPv4地址结构:

VPN-IPv4地址结构

       8字节的RD2字节的类型字段和8字节的值字段构成,值字段的解释取决于类型字段的值,目前类型字段定义了三种值:012

(1)    当类型字段值为0时,值字段由两个子字段组成:

l         管理者子字段:2字节

l         分配编号子字段:4字节

管理者子字段必须包含一个自治系统编号(ASN),如果这个ASN取自公共ASN空间,它必须由适当的权威机构分配;分配编号子字段包含一个编号,这个编号取自企业所管理的编号空间,而企业已经由适当的权威机构分配管理者字段所指定的ASN

(2)    当类型字段值为1时,值字段也由两个子字段组成:

l         管理者子字段:4字节

l         分配编号子字段:2字节

管理者子字段必须包含一个IP地址,如果这个IP地址取自公共的IP地址空间,它必须由一个适当的权威机构分配;分配编号子字段包含一个编号,这个编号取自企业所管理的编号空间,而企业已经分配了管理者子字段所指定的IP地址。

(3)    当类型字段值为2时,两个子字段的结构如下:

l         管理者子字段:4字节

l         分配编码子字段:2字节

管理者子字段包含4字节长度的BGP-AS4[kernix5] 号,如果这个ASN取自公共ASN空间,它必须由适当的权威机构分配;分配编号子字段包含一个编号,这个编号取自企业所管理的编号空间,而企业已经由适当的权威机构分配管理者字段所指定的ASN

       RD的这种结构保证提供VPN主干网服务的服务提供者能够生成唯一的RD,但是这种RD本身没有特别意义。

1.2.3 MP-BGPVPN-IPv4的支持

       PE之间建立了初始VRFLSP之后,他们各自向自己的BGP“对端”公告路由信心。在公告路由信息时,先将路由的IPv4地址前缀转换成VPN-IPv4地址前缀格式,VPN-IPv4地址前缀中的RD在配置VRF时指定。PE在向BGP“对端”公告路由信息的时候,每条路由(MP-BGP路由)中应包含如下内容:

l         路由的VPN-IPv4地址前缀(8字节RD4字节IPv4地址前缀

l         PE自身的IP地址作为路由的MP-BGP下一跳LSR地址,由于MP-BGP要求下一跳LSR地址采用相同的地址格式,所以MP-BGP下一跳LSR地址的格式为RD=0VPN-IPv4地址

l         PE分配给该路由的标签

l         包含该路由的VRF的输出路由目标(RT),该输出路由目标作为该路由的一个地址属性[kernix6] 

l         有可能[kernix7] 包含该路由的ORIGINAS_PATH属性

VPN-IPv4地址前缀结构在前面已经描述过,他将被编码后封装在MP_REACH_NLRINLRI字段里面。

BGP多协议扩展编码NLRIAFI字段值为1(因为和NLRI相关联的网络层协议仍然是IP),表明承载VPN-IPv4地址。

同时MP-BGP路由还需要承载PE分配给该路由的标签,这个标签同样也封装在NLRI字段里面,这样改进了RFC2858中的NLRI Encoding格式,转换成一个格式的三元组。根据RFC3107Carrying Label Information in BGP-4)的描述,可以携带一个或者多个Label,每个标签都只有3个字节长度,高20位承载标签值,低4位中3位被保留,最后一位S位)设置为1时标识已经到达标签栈栈底。(此时的标签编码格式略不同于标准的MPLS标签,不需要包含TTL字段

MP-BGP承载Label的时候,MP_REACH_NLRISAFI字段用于指出属性携带有Label信息(SAFI的值设置为4)。

PE可能分发出现在VRF中的所有路由,也可能现对这些路由进行聚合,然后分发聚合的路由。假定PE已经对路由R分配了标签L,并且通过BGP分发了这种标签映射,当路由RVRF中多条路由聚合后产生的路由,PE通过查找相应的VRF才能最终确定如何转发该报文,报文所携带的标签用于确定查找最终路由的VRF,标签信息库反映了标签和VRF的对应关系;如果R不是一条聚合路由,标签信息库中直接给出报文的输出接口及链路层封装类型,这种情况下,不需要再查找VRF

综合前面两点,NLRI Encoding的最后格式应当为:

Length(1 Octet)

Label(3 Octets)

……

Type Filed(2 Octets)

Value Filed(6 Octets)

IPv4 Prefix(8 Octets)

针对VPN-IPv4NLRI Encoding

如果是在MP_UNREACH_NLRI属性中,因为是适应withdrawn路由,所以按照RFC3017的规定,把Label值设置为0x800000。当然,终止BGP会话的时候将撤销所有以前公布的路由。

1.2.4 BGP/MPLS VPN网络运行示例

       首先看下面的拓扑结构,展示了一个BGP/MPLS VPN网络。

       四个CE路由器接入两个处于不同位置的VPNPE1PE2之间由MPLS骨干网络连接,在PE1PE2之间除了MPLS特有的LSP(标签交换路径)之外,还通过MP-BGP建立peer对等关系,用于发布VPN-IPv4路由。

       整个网络拓扑架设好之后,前期配置工作如下:

l         第一步工作是配置VRFPE1PE2针对连接CE的端口为每个VPN建立VRF,保证VPN的信息的安全性。

l         第二步配置任务是BGP,即在PE1PE2之间配置MP-BGP协议,这个协议可以保证VPN-IPv4路由的正确分发。

l         第三步工作是建立LSPPE1PE2MPLS骨干网络中的其他P路由器通过LDP协议,请求获取一条LSP,在PE1PE2之间建立一条交换路径,其间所有数据包都按照MPLS的标签交换模式进行转发。

l         第四步配置CEPE之间的IGP路由协议(一般采用OSPF即可),以便VPN中的路由可以通告给PE

下图展示了一个IBGP/MPLS VPN网络的运行示意图

协议配置好之后,整个网络正常工作,其中路由分发流程如下:

l         假定CE1中通告一条路由R(表明VPN1_1可达),这条路由通过CE1PE1之间的IGP协议被通告给PE1

l         PE1学习到路由R这条路由应该带有VPN标记)之后,将其放入为VPN1而设立的VRF1,同时PE1R分配一个“内层”标签L

l         BGP协议将从VRF1中读取路由R,并将其转换为带有标签LVPN-IPv4路由R’,然后把R’封装到MP_REACH_NLRI属性中,同时将RT信息封装到Community属性中。

l         BGP协议把PE自身在MPLS网络中的地址设置为VPN-IPv4路由R’的下一跳。

l         PE1通过LDP协议为通告路由R’Update消息打上标签L’,通过LSPR’转发到MPLS网络的另一端PE2,根据“倒数第二跳弹出”机制,在PE2上得到带有R’路由的BGP Update报文。

l         通过MP-BGP协议去掉报头,得到的路由信息为带有标签LVPN-IPv4路由R’

l         通过在PE2VRF映射机制,为标签L进行VRF1的映射,即把R’路由进行解析后还原为路由R(此路由的下一跳为PE1),装入VRF1的路由表中。

l         PE2CE3之间运行的IGP协议会将PE2VRF1路由表中的路由进行重发布,CE2将学到关于VPN 1_1的路由。

至此,VPN 1_2中的主机将可以通过CE2学到的关于VPN 1_1的路由向VPN 1_1中的主机发送数据。而VPN2中的路由分发过程与之类似。

       下面介绍报文转发流程[kernix8] ,以VPN 1_2中的主机向VPN 1_1中主机发送一个数据包为例:

l         此时CE3已经学习到了达到VPN 1_1的路由,VPN 1_2中的主机发送的数据包到达CE3的时候,CE3通过查找IP转发表,将其转发至PE2

l         PE2接收到数据包之后,查找VRF1的转发表,找到对应的一项之后为其打上通过路由R携带过来的“内层”标签L

l         PE2通过R得知转发这个数据包的下一跳是PE1LDP则为数据包打上外层标签,然后通过LSP传送到PE1

l         PE1接收到带有“内层”标签L的数据包,根据标签承载的输出接口和相应的链路层封装类型,发送给相应的CE1;如果R是经过聚合的路由,那么查找VRF1L是与VRF1有映射关系的)中的转发表,找到其对应转发目标应该是CE1

l         数据包被去掉内层标签L之后转发至CE1,然后由CE1转发至相应的VPN 1_1中的主机。

VPN2中的数据转发过程与之类似。

对于MP-BGP而言,需要考虑的只是路由通告过程,数据转发过程的具体细节(如分配内层标签、为数据包粘贴上内层标签等)由MPLS内部实现。

1.2.5 不同Service Provider之间的互连[kernix9] 

       当某个VPN的两个节点分别连接在两个不同的自治系统上,和该VPN相连接的两个PE之间将无法维持IBGP连接,这些PE和公共的路由反射器之间也无法维持IBGP连接,此时就需要一些利用EBGP分发VPN-IPv4路由的方法。

       EBGP分发路由的方法有几种,我们希望采用的是多跳EBGP在源、目的AS之间分发VPN-IPv4路由 

       在这个过程中,VPN-IPv4路由既不由ASBR维持,也不由ASBR分发,ASBR只是为AS内部的每个PE维持32位粘贴有标签的IPv4地址[kernix10] ,并用BGP将这些路由分发到其他AS,位于任何中转ASASBR将传输这些32位的粘贴标签的IPv4路由,这样,最终将在入口和出口PE之间建立LSP,位于不同的ASPE之间可以建立“多跳”EBGP连接,并经由这些连接交换VPN-IPv4路由。

       如果AS中任何一个P路由器都知道PE32位的IPv4地址所对应的路由,一切都能正常动作。如果P路由器并不知道指向PE的路由,这个过程要求入口PE在报文的标签栈中压入三个标签

l         栈底标签由出口PE分配,对应特定VRF中报文的目的地址

l         中间标签由ASBR分配,对应于指向入口PE的路由

l         栈顶标签由入口PEIGP下一跳路由器分配,对应指向ASBR的路由。

在这样的情况下,AS内部的P路由器应当维护IGP路由,而不能完全封装路由信息在标签交换里面。报文的入口PE和出口PE之间同样必须存在LSP

为了改善可扩充性,属于不同AS的路由反射器之间建立“多跳”EBGP连接,而PE只需要和同一AS中的路由反射器之间建立IBGP连接。


 [kernix1]这段话的意思应该结合下面的两种新增加属性来看:可达信息中包含Next-Hop属性,而撤销路由信息中无须包含(因为用不到)

 [kernix2]需要在OPEN报文中通告这种能力。

 [kernix3]定义成下面几个常量:

1-网络层可达信息用于单播转发。

2-网络层可达信息用于多播转发。

3-网络层可达信息既可用于单播也可用于多播转发。

同样适用于撤销路由信息。

 [kernix4]MP-BGP应用到MPLS/VPN部署中的时候,此Prefix有更多编码处理。

 [kernix5]详情参见"BGP Support for Four-Octet AS Number

   Space", Jan 2003, draft-ietf-idr-as4bytes-06.txt

 [kernix6]包含在扩展Community属性中进行转发

 [kernix7]MP_UNREACH_NLRI属性就不需要这些

 [kernix8]此处介绍的给予MPLS的三层VPN,没有涉及到复杂的类似于ISP作为MPLS网络服务用户的情况

 [kernix9]此实现的具体实现不属于本文档的考虑范围,本文档只考虑PE在同一AS

 [kernix10]这个地址是为ASBR建立MP-EBGP而存在的