VRF技术白皮书Word格式文档下载.doc

VRF技术白皮书Word格式文档下载.doc

《VRF技术白皮书Word格式文档下载.doc》由会员分享，可在线阅读，更多相关《VRF技术白皮书Word格式文档下载.doc（10页珍藏版）》请在冰豆网上搜索。

MPLSL2VPN和MPLSL3VPN。

本文介绍的VRF特性是MPLSVPN中经常使用的技术，中文含义为VPN路由转发实例。

鉴于VRF与MPLSVPN密切相关，下面首先对MPLSVPN作简要介绍。

图1是一个典型的MPLSL3VPN的组网图，运营商通过自己的IP/MPLS核心网络为BLUE和YELLOW两个客户提供VPN服务。

SITE1和SITE3分别为VPNBLUE的两个站点，SITE2和SITE4分别为VPNYELLOW的两个站点。

VPNBLUE两个站点内的主机可以互访，但不能访问VPNYELLOW内的主机。

同样，VPNYELLOW两个站点内的主机可以互访，但不能访问VPNBLUE内的主机。

从而实现了两个VPN间的逻辑划分和安全隔离。

CE设备的作用是把用户网络连接到PE，与PE交互VPN用户路由信息：

向PE发布本地路由并从PE学习远端站点路由。

PE作用是向直连的CE学习路由，然后通过IBGP与其他PE交换所学的VPN路由。

PE设备负责VPN业务的接入。

P设备是运营商网络中不与CE直接相连的设备，只要支持MPLS转发，并不能感知到VPN的存在。

图1

上面组网中VPN的设计思想是很巧妙的，但存在如下几个问题：

1、 

本地路由冲突问题，即：

在BLUE和YELLOW两个VPN中可能会使用相同的IP地址段，比如10.1.1.0/24，那么在PE上如何区分这个地址段的路由是属于哪个VPN的。

2、 

路由在网络中的传播问题，上述问题会在整个网络中存在。

3、 

PE向CE的报文转发问题，当PE接收到一个目的地址在10.1.1.0/24网段内的IP报文时，他如何判断该发给哪个VPN？

针对上述3个问题，分别有以下解决方案：

为了解决本地路由冲突问题，我们引入了VRF的概念：

把每台PE路由器在逻辑上划分为多台虚拟路由器，即多个VPN路由转发实例VRF，每个VRF对应一个VPN，有自己独立的路由表、转发表和相应的接口。

这就相当于将一台各VPN共享的PE模拟成多台专用PE。

这样PE与CE交互的路由信息只是该VPN的路由，从而实现了VPN路由的隔离。

由于不同VPN的路由存放在不同的VRF中，所以VPN路由重叠的问题也解决了。

VPN重叠路由在网络中的传播问题，可以在路由传递的过程中为这条路由再添加一个标识，用以区别不同的VPN。

正常的BGP4协议只能传递IPv4的路由，由于不同VPN用户具有地址空间重叠的问题，必须修改BGP协议。

BGP最大的优点是扩展性好，可以在原来的基础上再定义新的属性，通过对BGP修改，把BGP4扩展成MP-BGP。

在MP-IBGP邻居间传递VPN用户路由时打上RD标记等VPN信息，这样CE传来的VPN用户的IPv4路由被PE转换为VPN-IPv4路由，这样就能保证对端PE能够区分开属于不同VPN用户的地址重叠的路由。

PE向CE的报文转发问题，由于IP报文的格式不可更改，没有什么文章可以做，但可以在IP头之外加上一些信息（标签），由始发的VPN打上标记，这样PE在接收报文时可以根据这个标记进行转发。

每一个VRF可以看作一台虚拟的路由器，好像是一台专用的PE设备。

该虚拟路由器包括如下元素：

一张独立的路由表/转发表，当然也包括了独立的地址空间。

一组归属于这个VRF的接口集合。

一组只用于本VRF的路由协议。

对于每个PE，可以维护一个或多个VRF，同时维护一个公网的路由表（也叫全局路由表），多个VRF实例相互分离独立。

实现VRF并不困难，关键在于如何在PE上使用特定的策略规则来协调各VRF和全局路由表之间的关系。

在VRF中定义的和VPN业务有关的两个重要参数是RT和RD，RT和RD长度都是64bit。

RT是RouteTarget的缩写，RT的本质是每个VRF表达自己的路由取舍及喜好的方式，主要用于控制VPN路由的发布和安装策略。

分为import和export两种属性，前者表示了我对那些路由感兴趣，而后者表示了我发出的路由的属性。

当PE发布路由时，将使用路由所属VRF的RTexport规则，直接发送给其他的PE设备。

对端PE接收路由时，首先接收所有的路由，并根据每个VRF配置的RT的import规则进行检查，如果与路由中的RT属性match，则将该路由加入到相应的VRF中。

以下图为例：

SITE-1：

我发的路由是蓝色的，我也只接收蓝色的路由。

SITE-2：

我发的路由是黄色的，我也只接收黄色的路由。

SITE-3：

SITE-4：

这样，SITE-1与SITE-3中就只有自己和对方的路由，两者实现了互访。

同理SITE-2与SITE-4也一样。

这时我们就可以把SITE-1与SITE-3称为VPNBLUE，而把SITE-2与SITE-4称为VPNYELLOW。

图2

RD是RouteDistinguisher的缩写，是说明路由属于哪个VPN的标志。

理论上可以为每个VRF配置一个RD，通常建议为每个VPN的VRF都配置相同的RD，并且要保证这个RD全球唯一。

如果两个VRF中存在相同的地址，但是由于RD不同，这两个路由在PE间发布过程中也不会混淆，因为MPBGP把RD和路由一起发送，对端PE可以根据RD确定路由所属的VPN，从而把路由安装到正确的VRF中。

RD并不会影响不同VRF之间的路由选择以及VPN的形成，这些事情由RT搞定。

PE从CE接收的标准的路由是IPv4路由，如果需要发布给其他的PE路由器，此时需要为这条路由附加一个RD。

在IPv4地址加上RD之后，就变成VPN-IPv4地址族了。

VPN-IPv4地址仅用于服务供应商网络内部。

在PE发布路由时添加，在PE接收路由后放在本地路由表中，用来与后来接收到的路由进行比较。

CE不知道使用的是VPN-IPv4地址。

2 

组网应用

2.1 

VRF与MPLS组合应用

下面以图3为例说明MPLSVPN与VRF的典型应用：

组网中两个用户站点SITE1和SITE2属于同一个VPN，在两个PE上分别配置VRF参数，其中VRFSITE1的RD=100:

1，importRT=100:

3，exportRT=100:

2，VRFSITE2的RD=100:

2，exportRT=100:

3。

通过VRF的配置可见：

两个VRF的RD同为100:

1，说明他们属于同一个VPN；

VRFSITE1导入和导出的RT分别等于VRFSITE2导出和导入的RT，说明两个VRF分别可以接收对方的VPN站点内的路由；

PE连接CE的接口与VRF绑定，说明该接口是属于对于VRF的资源，其他VRF和公网是看不到的。

PE和CE之间可以运行OSPF、RIP2、EBGP和静态路由。

运营商网络要求为MPLS网络，在PE1和PE2之间建立LSP，同时PE1与PE2间通过MP-IBGP来传播VPN路由。

BGP和路由协议的相关配置请参考VRP操作手册和命令手册。

图3

VPNSITE1内的一条路由10.10/16被通告到VPNSITE2的过程如下：

PE1从接口S0/0上学习到由CE1通告的10.10.0.0/16的路由，由于S0/0是绑定到VRF的接口，所以PE1把该路由安装到对应VRF的路由表中，并且分配该路由的本地标签，注意该标签是本地唯一的。

然后通过路由重新发布把VRF路由表中的路由重新发布到BGP中，此时通过附加VRF表的RD、RT参数，把正常的IPv4路由变成VPN-IPv4路由，如10.10.0.0/16变成100:

1:

10.10.0.0/16，同时把exportRT值和该路由的本地标签值等信息一起通过MP-IBGP会话通告给PE2。

PE2收到这条VPN-IPv4路由后，先根据RD确定该路由所属的VRF，然后去掉VPN-IPv4路由所带的RD值，使之恢复IPv4路由原貌，并且根据所属VRF配置的导入策略（本地ImportRT与收到的exportRT是否一致）决定是否在本地VRF中安装此路由。

本例中导入策略允许，所以PE2把10.10.0.0/16路由添加到VRF路由表中，同时记录对应的标签。

PE2再通过CE和PE之间的路由协议，把10.10.0.0/16路由通过与VRF绑定的接口S0/1通告出去，CE2学习到这条路由后把该路由添加到路由表中。

同样的道理SITE2内的路由10.11.0.0/16也可以被CE1学到。

下面说明从CE2Ping10.10.0.0/16时数据报文的转发过程（假设PE1为该路由分配的标签为10，从PE2到PE1的LSP标签分别为L1、L2）：

图4

首先Ping包从CE2发出，为IPv4报文，在图中用绿色方块标识。

当IP报文到达PE2时，PE2根据目的地址查找VRF的转发表，发现该路由出标签为10，同时该路由下一跳为PE1，而PE1对应的LSP标签为L1，于是PE2给报文分别打上10、L1作为内外层标签，进行MPLS转发。

MPLS报文到达P时，P根据MPLS转发表项把外层标签替换为L2继续转发。

MPLS报文到达PE1时，因为PE1是LSP的终点，所以外层标签被剥掉。

PE1根据露出的内层标签10判断出该报文是发往SITE1所属VPN的报文。

于是PE1剥掉内层标签向CE1转发IP报文。

CE1收到的是还原后的IP报文，后续处理与正常IP处理流程一样，这里不再赘述。

2.2 

VRFlite特性