一、基本概念
Site 在介绍 VPN 时经常会提到“Site”， Site（站点）的含义可以从下述几个方面理解： Site 是指相互之间具备 IP 连通性的一组 IP 系统，并且，这组 IP 系统的 IP 连通性不需通过运营商网络实现。
如图所示，左半边的网络中， A 市 X 公司总部网络是一个 Site， B 市 X 公司分支机构网络是另一个 Site。这两个网络各自内部的任何 IP 设备之间不需要通过运营商网络就可以互通。
Site 示意图
Site 的划分是根据设备的拓扑关系，而不是地理位置，尽管在大多数情况下一个 Site 中的设备地理位置相邻。地理位置隔离的两组 IP 系统，如果它们使用专线互联，不需要通过运营商网络就可以互通，这两组 IP 系统也组成一个 Site。
如图所示，右半边网络， B 市的分支机构网络不通过运营商网络，而是通过专线直接与 A市的总部相连，则 A 市的总部网络与 B 市的分支机构网络构成了一个 Site。
一个 Site 中的设备可以属于多个 VPN，换言之，一个 Site 可以属于多个 VPN。
如图所示， X 公司位于 A 市的决策部网络（Site A）允许与位于 B 市的研发部网络（Site B）和位于 C 市的财务部网络（Site C）互通。但是不允许 Site B 与 Site C 互通。这种情况下，可以构建两个 VPN（VPN1 和 VPN2）， Site A 和 Site B 属于 VPN1， Site A 和 Site C 属于 VPN2。这样， Site A 就属于多个 VPN。
图一个 Site 属于多个 VPN
Site 通过 CE 连接到运营商网络，一个 Site 可以包含多个 CE，但一个 CE 只属于一个 Site。
根据 Site 的情况，建议 CE 设备选择方案如下： 如果 Site 只是一台主机，则这台主机就作为 CE 设备； 如果 Site 是单个子网，则使用交换机作为 CE 设备； 如果 Site 是多个子网，则使用路由器作为 CE 设备。
对于多个连接到同一运营商网络的 Site，通过制定策略，可以将它们划分为不同的集合（set），只有属于相同集合的 Site 之间才能通过运营商网络互访，这种集合就是 VPN。
地址空间重叠 VPN 是一种私有网络，不同的 VPN 独立管理自己的地址范围，也称为地址空间（address space）。
不同 VPN 的地址空间可能会在一定范围内重合，例如， VPN1 和 VPN2 都使用 10.110.10.0/24 网段地址，这就发生了地址空间的重叠（address spaces overlapping）。
以下两种情况允许 VPN 使用重叠的地址空间： 1、两个 VPN 没有共同的 Site 2、两个 VPN 有共同的 Site，但此 Site 中的设备不与两个 VPN 中使用重叠地址空间的设备互访
VPN 实例 在 BGP/MPLS IP VPN 中，不同 VPN 之间的路由隔离通过 VPN 实例（VPN-instance）实现。
PE 为每个直接相连的 Site 建立并维护专门的 VPN 实例， VPN 实例中包含对应 Site 的 VPN 成员关系和路由规则。具体来说， VPN 实例中的信息包括：IP 路由表、标签转发表、与 VPN 实例绑定的接口以及 VPN 实例的管理信息。VPN 实例的管理信息包括 RD（Route Distinguisher，路由标识符）、路由过滤策略、成员接口列表等。
VPN、 Site、 VPN 实例之间的关系如下： 1、VPN 是多个 Site 的组合。一个 Site 可以属于多个 VPN。 2、每一个 Site 在 PE 上都关联一个 VPN 实例。VPN 实例综合了它所关联的 Site 的 VPN 成员关 系和路由规则。多个 Site 根据 VPN 实例的规则组合成一个 VPN。 3、VPN 实例与 VPN 不是一一对应的关系， VPN 实例与 Site 之间存在一一对应的关系。
VPN 实例也称为 VPN 路由转发表 VRF（VPN Routing and Forwarding table）。PE 上存在多个路由转发表，包括一个公网路由转发表，以及一个或多个 VPN 路由转发表。如图所示。
VPN 实例示意图
公网路由转发表与 VPN 实例存在以下不同： 公网路由表包括所有 PE 和 P 设备的 IPv4 路由，由骨干网的路由协议或静态路由产生。 VPN 路由表包括属于该 VPN 实例的所有 Site 的路由，通过 CE 与 PE 之间或者两个 PE 之间的 VPN 路由信息交互获得。 公网转发表是根据路由管理策略从公网路由表提取出来的最小转发信息；而 VPN 转发表是根据路由管理策略从对应的 VPN 路由表提取出来的最小转发信息。
可以看出， PE 上的各 VPN 实例之间相互独立，并与公网路由转发表相互独立。 可以将每个 VPN 实例看作一台虚拟的设备，维护独立的地址空间并有连接到该设备的接口。
RD 和 VPN-IPv4 地址 传统 BGP 无法正确处理地址空间重叠的 VPN 的路由。假设 VPN1 和 VPN2 都使用了 10.110.10.0/24网段的地址，并各自发布了一条去往此网段的路由。虽然本端 PE 通过不同的 VPN 实例可以区分地址空间重叠的 VPN 的路由，但是这些路由发往对端 PE 后，由于不同 VPN 的路由之间不进行负载分担，因此对端 PE 将根据 BGP 选路规则只选择其中一条 VPN 路由，从而导致去往另一个 VPN的路由丢失。
PE 之间使用 MP-BGP（Multiprotocol Extensions for BGP-4， BGP-4 的多协议扩展）来发布 VPN 路由，并使用 VPN-IPv4 地址族来解决上述问题。
VPN-IPv4 地址共有 12 个字节，包括 8 字节的路由标识符 RD（Route Distinguisher）和 4 字节的 IPv4地址前缀，如图所示。
VPN-IPv4 地址结构
RD 用于区分使用相同地址空间的 IPv4 前缀，增加了 RD 的 IPv4 地址称为 VPN-IPv4 地址（即 VPNv4地址）。PE 从 CE 接收到 IPv4 路由后，转换为全局唯一的 VPN-IPv4 路由，并在公网上发布。
RD 的结构使得每个服务供应商可以独立地分配 RD，但为了在 CE 双归属的情况下保证路由正常，必须保证 PE 上的 RD 全局唯一。如图 5 所示， CE 以双归属方式接入到 PE1 和 PE2。PE1 同时作为路由反射器 RR（Route Reflector）。
CE 双归属组网示意图
该组网中， PE1 作为骨干网边界设备发布一条 IPv4 前缀为 10.1.1.1/8 的 VPN-IPv4 路由给 PE3。同 时又作为 RR 反射 PE2 发布的 IPv4 前缀为 10.1.1.1/8 的 VPN-IPv4 路由给 PE3。
如果该 VPN 在 PE1 和 PE2 上的 RD 一样，由于目的地址相同， PE3 只保留一条到 10.1.1.1/8的 VPN-IPv4 路由，其路径为：PE3—>PE1－>CE。
当 PE1 与 CE 之间的直连链路出现故障时， PE3 删除到 10.1.1.1/8 的 VPN-IPv4 路由，无法正确转发到该目的地址的 VPN 数据。而实际上 PE3 应该有一条到 10.1.1.1/8 的路由，其路径为：PE3—>PE2－>CE。
如果该 VPN 在 PE1 和 PE2 上的 RD 不同，则 PE3 从 PE1 接收的到 10.1.1.1/8 两条 VPN-IPv4路由的目的地址不同，因此 PE3 上保留两条到 10.1.1.1/8 的 VPN-IPv4 路由。当 PE1 与 CE 之间的任何一条链路出现故障时， PE3 将删除其中对应的一条，仍保留另一条，使得到 10.1.1.1/8的数据能正确转发。
VPN Target BGP/MPLS IP VPN 使用 32 位的 BGP 扩展团体属性－VPN Target（也称为 Route Target）来控制VPN 路由信息的发布。
每个 VPN 实例关联一个或多个 VPN Target 属性。有两类 VPN Target 属性： 1、Export Target：本地 PE 从直接相连 Site 学到 IPv4 路由后， 转换为 VPN-IPv4 路由，并为这些路由设置 Export Target 属性。Export Target 属性作为 BGP 的扩展团体属性随路由发布。
2、Import Target：PE 收到其它 PE 发布的 VPN-IPv4 路由时，检查其 Export Target 属性。当此属性与 PE 上某个 VPN 实例的 Import Target 匹配时， PE 就把路由加入到该 VPN 实例中。
在 BGP/MPLS IP VPN 网络中，通过 VPN Target 属性来控制 VPN 路由信息在各 Site 之间的发布和接收。VPN Export Target 和 Import Target 的设置相互独立，并且都可以设置多个值，能够实现灵活的 VPN 访问控制，从而实现多种 VPN 组网方案。
例如：某 VPN 实例的 Import Target 包含 100:1， 200:1 和 300:1，当收到的路由信息的 Export Target为 100:1、 200:1、 300:1 中的任意值时，都可以被注入到该 VPN 实例中。
二、基本原理 从如下几部分介绍 BGP/MPLS IP VPN 的基本原理： 私网标签分配 私网路由交叉 公网隧道迭代 私网路由的选择规则 BGP/MPLS IP VPN 的路由发布
BGP/MPLS IP VPN 的报文转发
私网标签分配 在 BGP/MPLS IP VPN 中， PE 通过 MP-BGP 发布私网路由给骨干网的其他相关的 PE 前，需要为私网路由分配 MPLS 标签（私网标签）。当用户数据包在骨干网传输时，携带私网标签。
PE 上分配私网标签的方法有如下两种： 基于路由的MPLS标签分配：默认情况下，设备为VPN路由表的每一条路由分配一个标签（one label per route）。这种方式的缺点是：当路由数量比较多时，设备入标签映射表 ILM（Incoming Label Map）需要维护的表项也会增多，从而提高了对设备容量的要求。
基于 VPN 实例的 MPLS 标签分配：为整个 VPN 实例分配一个标签，该 VPN 实例里的所有路由都共享一个标签。使用这种分配方法的好处是节约了标签。
说明： MP-BGP 为私网路由分配标签的前提是 PE 上使能 MPLS 功能。
私网路由交叉
两台 PE 之间通过 MP-BGP 传播的路由是 VPNv4 路由。当接收到 VPNv4 路由， PE 先进行如下处理： 检查其下一跳是否可达。如果下一跳不可达，该路由被丢弃。 对于 RR 发送过来的 VPNv4 路由，如果收到的路由中 cluster_list 包含自己的 cluster_id，则丢弃这条路由。 进行 BGP 的路由策略过滤，如果不通过，则丢弃该路由。
之后， PE 把没有丢弃的路由与本地的各个 VPN 实例的 Import Target 属性匹配。VPNv4 路由与本地 VPN 实例的 Import VPN-Target 进行匹配的过程称为私网路由交叉。
PE 上有种特殊的路由，即来自本地 CE 的属于不同 VPN 的路由。对于这种路由，如果其下一跳直接可达或可迭代成功， PE 也将其与本地的其他 VPN 实例的 Import Target 属性匹配，该过程称为本地交叉。
例如：CE1 所在的 Site 属于 VPN1， CE2 所在的 Site 属于 VPN2，且 CE1 和 CE2 同时接入 PE1。当 PE1 收到来自 CE1 的 VPN1 的路由时，也会与 VPN2 对应的 VPN 实例的 Import Target属性匹配。
说明： 为了能够将报文正确转发出去， BGP 设备必须先找到一个直接可达的地址，通过这个地址到达路由表中指示的下一跳。在上述过程中，去往直接可达地址的路由被称为依赖路由， BGP 路由依赖于这些路由指导报文转发。根据下一跳地址找到依赖路由的过程就是路由迭代。
公网隧道迭代 为了将私网流量通过公网传递到另一端，需要有一条公网隧道承载这个私网流量。因此私网路由交叉完成后，需要根据目的 IPv4 前缀进行路由迭代，查找合适的隧道（本地交叉的路由除外）；
只有隧道迭代成功，该路由才被放入对应的 VPN 实例路由表。将路由迭代到相应的隧道的过程叫做隧道迭代。 隧道迭代成功后，保留该隧道的标识符（Tunnel ID），供后续转发报文时使用。Tunnel ID 用于唯一标识一条隧道。VPN 报文转发时根据 Tunnel ID 查找对应的隧道，然后从隧道上发送出去。
私网路由的选择规则 经过路由交叉和隧道迭代的路由并不是全部被放入 VPN 实例路由表。从本地 CE 收到的路由和本地交叉路由也不是全部被放入 VPN 实例路由表。
对于到同一目的地址的多条路由，如果不进行路由的负载分担，按如下规则选择其中的一条： 同时存在直接从CE收到的路由和交叉成功后的同一目的地址路由，则优选从 CE收到的路由。 同时存在本地交叉路由和从其他 PE 接收并交叉成功后的同一目的地址路由，则优选本地交叉路由。
对于到同一目的地址的多条路由，如果进行路由的负载分担，则： 优先选择从本地CE收到的路由。只有一条从本地CE收到的路由而有多条交叉路由的情况下，也只选择从本地 CE 收到的路由。 只在从本地 CE 收到的路由之间分担或只在交叉路由之间分担，不会在本地 CE 收到的路由和交叉路由之间分担。 负载分担的 AS_PATH 属性必须完全相同。
BGP/MPLS IP VPN 的路由发布 基本 BGP/MPLS IP VPN 组网中， VPN 路由信息的发布涉及 CE 和 PE， P 设备只维护骨干网的路由，不需要了解任何 VPN 路由信息。PE 设备一般维护所有 VPN 路由。
VPN 路由信息的发布过程包括三部分：本地 CE 到入口 PE、入口 PE 到出口 PE、出口 PE 到远端CE。完成这三部分后，本地 CE 与远端 CE 之间建立可达路由， VPN 路由信息能够在骨干网上发布。
下面分别对这三部分进行介绍。
1、本地 CE 到入口 PE 的路由信息交换 CE 与直接相连的 PE 建立邻居或对等体关系后，把本站点的 IPv4 路由发布给 PE。CE 与 PE之间可以使用静态路由、 RIP、 OSPF、 IS-IS 或 BGP。无论使用哪种路由协议， CE 发布给 PE的都是标准的 IPv4 路由。
2、入口 PE 到出口 PE 的路由信息交换 PE 从 CE 学到 VPN 路由信息后，存放到 VPN 实例中。同时，为这些标准 IPv4 路由增加 RD，形成 VPN-IPv4 路由。
入口 PE 通过 MP-BGP 的 Update 报文把 VPN-IPv4 路由发布给出口 PE。Update 报文中携带 Export VPN Target 属性及 MPLS 标签。
出口 PE 收到 VPN-IPv4 路由后，在下一跳可达的情况下进行路由交叉、隧道迭代和路由优选，决定是否将该路由加入到 VPN 实例的路由表。被加入到 VPN 路由表的路由，本地 PE 为其保留如下信息以供后续转发报文时使用：MP-BGP Update 消息中携带的 MPLS 标签值 和 Tunnel ID
3、出口 PE 到远端 CE 的路由信息交换 远端 CE 有多种方式可以从出口 PE 学习 VPN 路由，包括静态路由、 RIP、 OSPF、 IS-IS 和BGP，与本地 CE 到入口 PE 的路由信息交换相同。此处不再赘述。值得注意的是，出口 PE发布给远端 CE 的路由是普通 IPv4 路由。
下面以图 （PE-CE 之间使用 BGP，公网隧道为 LSP）为例，说明将 CE2 的一条路由发送到 CE1的过程。
1. 在 CE2 的 BGP IPv4 单播地址族下引入 IGP 路由。
2. CE2 将该路由随 EBGP 的 Update 消息一起发布给 Egress PE。Egress PE 从连接 CE2 的接口收到 Update 消息，把该路由转化为 VPN IPv4 路由，加入对应的 VPN 实例路由表。
3. Egress PE 为该路由分配 MPLS 标签，并将标签和 VPN IPv4 路由信息加入 MP-IBGP 的 Update消息中的 NLRI 字段中， Export-RT 属性加入 MP-BGP Update 消息的扩展团体属性字段中，将 Update 消息发送给 Ingress PE。
4. Ingress PE 对该路由进行路由交叉。交叉成功则根据路由目的 IPv4 地址进行隧道迭代，查找合适的隧道。如果迭代成功，则保留该隧道的 Tunnel ID 和标签，并将路由加入该 VPN 实例路由表。
5. Ingress PE 把该路由通过 BGP Update 消息发布给 CE1。此时路由是普通 IPv4 路由。
6. CE1 收到该路由后，把该路由加入 BGP 路由表。通过在 IGP 中引入 BGP 路由的方法可使CE1 把该路由加入 IGP 路由表。
上面过程只是将 CE2 的路由发布给 CE1。要实现 CE1 与 CE2 的互通，还需要将 CE1 的路由发布给 CE2，其过程与上面的步骤类似，此处不再赘述。
BGP/MPLS IP VPN 的报文转发 在基本 BGP/MPLS IP VPN 应用中（不包括跨域的情况）， VPN 报文转发采用两层标签方式：
第一层（公网）标签在骨干网内部进行交换，指示从 PE 到对端 PE 的一条 LSP。VPN 报文利用这层标签，可以沿 LSP 到达对端 PE；
第二层（私网）标签在从对端 PE 到达 CE 时使用，指示报文应被送到哪个 Site，或者更具体一些，到达哪一个 CE。这样，对端 PE 根据内层标签可以找到转发报文的接口。
特殊情况下，属于同一个 VPN 的两个 Site 连接到同一个 PE，这种情况下只需要知道如何到达对端CE。
以图为例说明 BGP/MPLS IP VPN 报文的转发过程。图 2 是 CE1 发送报文给 CE2 的过程。其中，I-L 表示内层标签， O-L 表示外层标签。
图VPN 报文转发过程
1. CE1 发送一个 VPN 报文。
2. Ingress PE 从绑定了 VPN 实例的接口上接收 VPN 数据包后进行如下操作： 先根据绑定的 VPN 实例的 RD 查找对应 VPN 的转发表。 匹配目的 IPv4 前缀，查找对应的 Tunnel ID。 将报文打上对应的标签（I-L），根据 Tunnel-ID 找到隧道。 将报文从隧道发送出去。此例的隧道是 LSP，则打上公网（外层）MPLS 标签头（O-L1）。 接着，该报文携带两层 MPLS 标签穿越骨干网。骨干网的每台 P 设备都对该报文进行外层标签交换。
3. Egress PE 收到该携带两层标签的报文，交给 MPLS 协议处理。MPLS 协议将去掉外层标签（此例最后的外层标签是 O-L2，但如果应用了倒数第二跳弹出，则此标签会在到达 Egress PE之前的一跳弹出， Egress PE 只能收到带有内层标签的报文）。
4. 此时 Egress PE 就可以看见内层标签，发现该标签处于栈底，将内层标签剥离。
5. Egress PE 将报文从对应出接口发送给 CE2。此时报文是个纯 IP 报文。 这样，报文就成功地从 CE1 传到 CE2 了。CE2 按照普通的 IP 转发过程将报文传送到目的地。
三、基本组网
Intranet VPN 最简单的情况下，一个 VPN 中的所有用户形成闭合用户群，相互之间能够进行流量转发， VPN 中的用户不能与任何本 VPN 以外的用户通信。这种组网方式的 VPN 叫做 Intranet VPN，其站点通常是属于同一个组织。
对于这种组网，需要为每个 VPN 分配一个 VPN Target，作为该 VPN 的 Export Target 和 Import Target，并且，此 VPN Target 不能被其他 VPN 使用。
在图 中， PE 上为 VPN1 分配的 VPN Target 值为 100:1，为 VPN2 分配的 VPN Target 值为 200:1。VPN1 的两个 Site 之间可以互访， VPN2 的两个 Site 之间也可以互访，但 VPN1 和 VPN2 的 Site 之间不能互访。
Extranet VPN 如果一个 VPN 用户希望访问其他 VPN 中的某些站点，可以使用 Extranet 组网方案。 对于这种组网，如果某个 VPN 需要访问共享站点，则该 VPN 的 Export Target 必须包含在共享站点的VPN实例的Import Target中，而其Import Target必须包含在共享站点VPN实例的Export Target中。
在图中， VPN1 的 Site3 能够被 VPN1 和 VPN2 访问： PE3 能够接收 PE1 和 PE2 发布的 VPN-IPv4 路由； PE3 发布的 VPN-IPv4 路由能够被 PE1 和 PE2 接收；
基于以上两点， VPN1 的 Site1 和 Site3 之间能够互访， VPN2 的 Site2 和 VPN1 的 Site3 之间能够互访；
PE3不把从 PE1接收的 VPN-IPv4路由发布给 PE2，也不把从PE2接收的 VPN-IPv4路由发布给PE1，因此， VPN1 的 Site1 和 VPN2 的 Site2 之间不能互访。
Hub and Spoke 如果希望在 VPN 中设置中心访问控制设备，其它用户的互访都通过中心访问控制设备进行，可以使用 Hub and Spoke 组网方案。其中，中心访问控制设备所在站点称为 Hub 站点，其他用户站点称为 Spoke 站点。Hub 站点侧接入 VPN 骨干网的设备叫 Hub-CE；Spoke 站点侧接入 VPN 骨干网的设备叫 Spoke-CE。VPN 骨干网侧接入 Hub 站点的设备叫 Hub-PE，接入 Spoke 站点的设备叫Spoke-PE。
Spoke 站点需要把路由发布给 Hub 站点，再通过 Hub 站点发布给其他 Spoke 站点。Spoke 站点之间不直接发布路由。Hub 站点对 Spoke 站点之间的通讯进行集中控制。 对于这种组网情况，需要设置两个 VPN Target，一个表示“Hub”，另一个表示“Spoke”。如图所示。
各 Site 在 PE 上的 VPN 实例的 VPN Target 设置规则为： Spoke-PE：Export Target 为“Spoke”， Import Target 为“Hub”。任意 Spoke-PE 的 Import Route Target 属性不与其它 Spoke-PE 的 Export Route Target 属性相同； Hub-PE：Hub-PE 上需要使用两个接口或子接口。 一个用于接收 Spoke-PE 发来的路由，其 VPN 实例的 Import Target 为“Spoke”； 另一个用于向 Spoke-PE 发布路由，其 VPN 实例的 Export Target 为“Hub”。
在图中， Spoke 站点之间的通信通过 Hub 站点进行（图中箭头所示为 Site2 的路由向 Site1 的发布过程）： Hub-PE 能够接收所有 Spoke-PE 发布的 VPN-IPv4 路由； Hub-PE 发布的 VPN-IPv4 路由能够为所有 Spoke-PE 接收； Hub-PE 将从 Spoke-PE 学到的路由发布给 Hub-CE，并将从 Hub-CE 学到的路由发布给所有Spoke-PE。因此， Spoke 站点之间可以通过 Hub 站点互访； 任意 Spoke-PE 的 Import Target 属性不与其它 Spoke-PE 的 Export Target 属性相同。因此，任意两个 Spoke-PE 之间不直接发布 VPN-IPv4 路由， Spoke 站点之间不能直接互访。
四、VPN FRR
产生背景 在网络高速发展的今天，运营商网络发生故障时的端到端业务收敛时间已经成为承载网的重要指标。
MPLS TE FRR（Fast Reroute）是最常用的快速倒换技术之一，它的基本思路是在两个 PE 设备之间建立端到端的 TE 隧道，并且为需要保护的主用 LSP（标签交换路径）事先建立好备用 LSP，当设备检测到主用 LSP 不可用时（节点故障或者链路故障），将流量倒换到备用 LSP 上，从而实现业务的快速倒换。
从 MPLS TE FRR 技术的原理看，对于作为 TE 隧道起始点和终结点的两个 PE 设备之间的链路故障和节点故障， MPLS TE FRR 能够实现快速的业务倒换。但是这种技术不能解决作为隧道起始点和终结点的 PE 设备的故障，一旦 PE 节点发生故障，只能通过端到端的路由收敛、 LSP 收敛来恢复业务，其业务收敛时间与 MPLS VPN 内部路由的数量、承载网的跳数密切相关， VPN 私网路由数量越大，收敛时间越长，导致大量的流量丢失。
VPN FRR 利用基于 VPN 的私网路由快速切换技术，通过预先在远端 PE 中设置指向主用 PE 和备用 PE 的主备用转发项，并结合 PE 故障快速探测，旨在解决 CE 双归 PE 的 MPLS VPN 网络中，PE 节点故障导致的端到端业务收敛时间长的问题。同时对于 VPN FRR 技术，其收敛时间只取决于远端 PE 故障的检测并修改对应隧道状态的时间，由此解决了私网路由数目越多， PE 节点故障恢复时间越长的问题。
实现原理
图 VPN FRR 典型组网图
如图，假设正常情况下 CE1 访问 CE2 的路径为 Link A，当 PE2 发生故障后， CE1 访问 CE2 的路径收敛为 Link B。
按照传统的 BGP/MPLS VPN 技术， PE2 和 PE3 都会向 PE1 发布指向 CE2 的路由，并分配私网标签， PE1 优选一个 MBGP 邻居发送的 VPNv4 路由，在这个例子中，优选的是 PE2 发布的路由，并且只把 PE2 发布的路由信息（包括转发前缀、内层标签、选中的 LSP 隧道）填写在转发引擎使用的转发项中，指导转发。
当 PE2 节点故障时， PE1 感知到 PE2 的故障（BGP 邻居 Down 或者外层 LSP 隧道不可用），重新优选 PE3 发布的路由，并重新下发转发项，完成业务的端到端收敛。在 PE1 重新优选PE3 发布的路由，下发到转发项之前，由于转发项指向的外层 LSP 隧道的终点是 PE2，而 PE2节点故障，因此，在一段时间内， CE1 是无法访问 CE2 的，端到端业务中断。
VPN FRR 技术对传统技术进行了改进：支持 PE1 设备将最优的 PE2 发布的路由信息和次优的 PE3 发布的路由信息都填写在转发项中，其中最优的路由用于指导业务流量转发，而次优路由用于作为备份路由。
当 PE2 节点故障时， PE1 感知到 PE1 与 PE2 之间的外层隧道不可用，便将 LSP 隧道状态表中的对应标志设置为不可用并下发到转发引擎中，转发引擎命中一个转发项之后，检查该转发项对应的 LSP 隧道状态，如果为不可用，则使用本转发项中携带的次优路由的转发信息进行转发。这样，报文就会被打上 PE3 分配的内层标签，沿着 PE1 与 PE3 之间的外层 LSP 隧道交换到 PE3，再转发给 CE2，从而恢复 CE1 到 CE2 的业务，实现 PE2 节点故障情况下的端到端业务的快速收敛。
VPN FRR 技术面向内层标签的快速倒换，在外层隧道的选择方面，可以是 LDP LSP 或 RSVP TE，转发引擎在报文转发的时候感知到外层隧道的状态为不可用就可以进行快速的基于内层标签的倒换。
五、VPN GR
概述
VPN GR（Graceful Restart）是 GR 技术在 VPN 场景中的应用。VPN GR 实现在承载 VPN 业务的设备发生主备倒换时 VPN 流量不中断。
实现 VPN GR 的目的： 减少主备倒换时路由震荡对全网的影响； 减少丢包，基本可以达到 VPN 流量丢包率为 0%； 减少对重要 VPN 业务的影响； 减少 PE 或 CE 单点故障，提高 VPN 环境整网的可靠性。
实现前提 倒换设备及与之相连的设备都必须具备 GR 能力，在一段时间内保存所有 VPN 路由的转发信息，保持 VPN 流量不中断。即： 支持 IGP GR、 BGP GR 支持 LDP GR，如果骨干网使用 TE 隧道，则需要支持 RSVP GR
实现过程 在一般的 BGP/MPLS VPN 环境中，发生主备倒换的设备可能是 PE， CE 或 P。
1、PE 发生主备倒换
PE 处理流程同普通 IGP GR、 LDP GR、 BGP GR 处理过程中 GR Restarter 的处理流程一样与此 PE 相连的 CE 在感知到 PE 重启后，进行与普通 IGP GR 或 BGP GR 中的 GR Helper 相同的流程处理，在一段时间内保存所有 IPv4 路由信息。
与此 PE 相连的 P 在感知到 PE 重启后，进行与普通 IGP GR、LDP GR 或 BGP GR 中 GR Helper相同的流程处理，在一段时间内保存所有公网 IPv4 路由信息。 与此 PE 相连的其它 PE（包括作为 ASBR 的 PE）和反射 VPNv4 路由的 RR（Route Reflector）在感知到此 PE 重启后，处理流程与 BGP GR 处理过程中的 GR Helper 的处理流程一致，在一段时间内保存所有公网 IPv4 路由信息和 VPNv4 路由信息。
2、P 发生主备倒换 P 处理流程同普通 IGP GR、 LDP GR 或 BGP GR 处理过程中 GR Restarter 的处理流程一样。
与此 P 相连的 P 或 PE 在感知到该 P 设备重启后，处理流程同普通 IGP GR、 LDP GR 或 BGPGR 处理过程中 GR Helper 的处理流程一致，在一段时间内保存所有公网 IPv4 路由信息。
3、CE 设备发生主备倒换 CE 设备处理流程同普通 IGP GR 或 BGP GR 处理过程中 GR Restarter 的处理流程一样。
与此 CE 设备相连的 PE 设备在感知到 CE 设备重启后，处理流程同普通 IGP GR 或 BGP GR处理过程中 GR Helper 的处理流程一致，在一段时间内保存所有私网 IPv4 路由信息。
六、VPN NSR
在网络高速发展的今天，三网合一的需求日益迫切，运营商对 IP 网络的可靠性要求不断提高， VPN NSR（Non-Stop Routing，不间断路由）作为高可靠性的解决方案应运而生。
NSR 是系统控制平面发生故障，且存在备用控制平面的场景下，邻居控制平面不感知的一种技术，不仅局限于路由信令的邻居关系不中断，也包括 MPLS 信令协议，以及其他为满足业务需求而提供支撑的协议。
VPN NSR 作为可靠性的解决方案，其根本目的都是为了保证用户业务在设备故障的时候不受影响或者影响最小。
VPN NSR 在本端主备倒换后不仅实现转发平面业务不中断，而且 VPN 路由发布不中断，做到断点续传。在这个过程中，邻居关系不会受到影响，对端完全不会感知本端设备发生倒换，为 VPN 业务不中断提供了高可靠性的解决方案。
