Definition

As shown in Figure 15-41, a basic BGP/MPLS VPN applies to the scenario in which there is only one carrier or the backbone networks of multiple carriers belong to the same AS. A basic BGP/MPLS IP VPN has the following characteristics:

• Transmits packets using extended BGP.

• Encapsulates and transmits VPN packets over MPLS LSPs serving as public network tunnels.

• Allows a device that can play PE, P, and CE roles to play only one role at a time.

Figure 15-41 Basic BGP/MPLS IP VPN networking

Related Concepts

• Site

  The concept of "site" is frequently mentioned in the VPN technology. The following describes a site from different aspects:

  • A site is a group of IP systems that can communicate without using carrier networks.

    As shown in Figure 15-42, on the networks of the left side, the headquarters network of company X in City A is a site; the branch network of company X in City B is another site. IP devices within each site can communicate without using the SP network.

    Figure 15-42 Schematic diagram for sites
    

  • Sites are classified based on topological relationships between devices rather than the geographical locations of devices, even though devices in a site are geographically adjacent to each other in general. If two geographically separated IP systems are connected over a leased line instead of a carrier network, the two systems compose a site.

    As shown in Figure 15-42, if the branch network in City B connects to the headquarters network in City A over a leased line instead of a carrier network, the branch network and the headquarters network compose a site.

  • Devices at a site can belong to multiple VPNs. In other words, a site can belong to more than one VPN.

    As shown in Figure 15-43, the decision-making department of company X in City A (Site A) is allowed to communicate with the R&D department in City B (Site B) and the financial department in City C (Site C). Site B and Site C are not allowed to communicate with each other. In this case, VPN1 and VPN2 can be established, with Site A and Site B belonging to VPN1 and Site A and Site C belonging to VPN2. In this manner, Site A is configured to belong to multiple VPNs.

    Figure 15-43 One site belonging to multiple VPNs
    

  • A site connects to a carrier network through the CE and may contain more than one CE, but a CE belongs only to one site.

    It is recommended that you determine the devices to be used as CEs based on the following principles:

    If the site is a host, use the host as the CE.

    If the site is a subnet, use switches as CEs.

    If the site comprises multiple subnets, use routers as CEs.

    Sites connecting to the same carrier's network can be categorized into different sets based on configured policies. Only sites that belong to the same set can access each other, and this set is a VPN.

• Address space overlapping

  As a private network, a VPN independently manages an address space. Address spaces of different VPNs may overlap. For example, if both VPN1 and VPN2 use addresses on network segment 10.110.10.0/24, address space overlapping occurs.

  VPNs can use overlapped address spaces in the following situations:

  • Two VPNs do not cover the same site.

  • Two VPNs cover the same site, but devices at the site and devices using addresses in overlapped address spaces in the VPNs do not access each other.

• VPN instance

  CEs are user-side devices and need to send only local VPN routes to PEs, irrespective of whether the PEs connect to the public network or other VPNs. PEs are network-side devices, and a PE generally connects to multiple CEs from different VPNs. A PE may receive routes from different VPNs. Because address spaces used by different VPNs may overlap, routes sent from different VPNs may carry the same destination address. If a PE maintains only one routing and forwarding table, this table will accept only one of the routes from different VPNs but with the same destination address. To prevent this problem, the VPN technology uses VPN instances.

  A VPN instance is also called a VPN routing and forwarding (VRF) table. A PE maintains multiple routing and forwarding tables, including a public routing and forwarding table and one or more VRF tables. In other words, a PE has multiple instances, including a public network instance and one or more VPN instances, as shown in Figure 15-44. Each VPN instance maintains routes from the corresponding VPN. The public network instance maintains public network routes. This enables a PE to keep all routes from VPNs, irrespective of whether their address spaces overlap.

  Figure 15-44 Schematic diagram for VPN instances
  
  

  The differences between a public routing and forwarding table and a VRF table are as follows:

  • A public routing table contains the IPv4 routes of all PEs and Ps. These IPv4 routes are static routes configured on the backbone network or are generated by routing protocols configured on the backbone network.

  • A VPN routing table contains the routes of all sites that belong to the corresponding VPN instance. The routes are obtained through exchange of VPN routes between PEs or between CEs and PEs.

  • Based on route management policies, a public forwarding table contains the minimum forwarding information extracted from the corresponding routing table, whereas a VPN forwarding table contains the minimum forwarding information extracted from the corresponding VPN routing table.

    The VPN instances on a PE are independent of each other. They are also independent of the public routing and forwarding table.

    Each VPN instance can be considered as a virtual router, which maintains an independent address space and has one or more interfaces connected to the router.

    In relevant standards (BGP/MPLS IP VPNs), a VPN instance is called a per-site forwarding table. As the name suggests, one VPN instance corresponds to one site. To be specific, every connection between a CE and a PE corresponds to a VPN instance, but this is not a one-to-one mapping. The VPN instance is manually bound to the PE interface that directly connects to the CE.

    A VPN instance uses an RD to identify an independent address space and uses VPN targets to manage VPN memberships and routing principles of directly connected sites and remote sites.

• Relationships between VPNs, sites, and VPN instances

  The relationships between VPNs, sites, and VPN instances are as follows:

  • A VPN consists of multiple sites. A site may belong to multiple VPNs.

  • A site is associated with a VPN instance on a PE. A VPN instance integrates the VPN member relationships and routing rules of its associated sites. Multiple sites form a VPN based on VPN instance rules.

• RD and VPN-IPv4 address

  Traditional BGP cannot process the routes of VPNs with overlapped address spaces. Assume that VPN1 and VPN2 use addresses on the network segment 10.110.10.0/24, and each of them advertises a route destined for this network segment. The local PE identifies the two VPN routes based on VPN instances and sends them to the remote PE. Because routes from different VPNs cannot work in load-balancing mode, the remote PE adds only one of the two routes to its VRF table based on BGP route selection rules.

  This is because BGP cannot distinguish VPN routes with the same IP address prefix. To solve this problem, BGP/MPLS IP VPN uses the VPN-IPv4 address family.

  A VPN-IPv4 address consists of 12 bytes. The first eight bytes represent the RD and the last four bytes represent the IPv4 address prefix, as shown in Figure 15-45.

  Figure 15-45 VPN-IPv4 address structure
  
  

  RDs are used to distinguish IPv4 prefixes using the same address space. The format of RDs enables carriers to allocate RDs independently. An RD, however, must be unique on the entire network to ensure correct routing if CEs are dual-homed to PEs. IPv4 addresses with RDs are called VPN-IPv4 addresses. After receiving IPv4 routes from a CE, a PE converts the routes to globally unique VPN-IPv4 routes and advertises the routes on the public network.

• VPN target

  The VPN target, also called the route target (RT), is a 64-bit BGP extended community attribute. BGP/MPLS IP VPN uses VPN targets to control the advertisement of VPN routing information.

  A VPN instance is associated with one or more VPN target attributes, which are of the following types:

  • Export VPN target: After learning an IPv4 route from a directly connected site, a PE converts the route to a VPN-IPv4 route and sets the export VPN target for the route. As an extended community attribute, the export VPN target is advertised with the route.

  • Import VPN target: After receiving a VPN-IPv4 route advertised by another PE, the local PE checks the export VPN target of the route. If the export VPN target is identical with the import VPN target of a VPN instance on the PE, the PE adds the route to the VPN instance.

  After receiving a route from a directly connected CE, a PE sets the export VPN targets of the route. The PE then uses BGP to advertise the route with export VPN targets to related PEs. After receiving the route, the related PEs compare the export VPN targets with the import VPN targets of all their VPN instances. If an export VPN target is identical with an import VPN target, the route is added to the corresponding VPN instance.

  The reasons for using VPN targets instead of RDs as the BGP extended community attributes are as follows:

  • A VPN-IPv4 route has only one RD, but can be associated with multiple VPN targets. With multiple extended community attributes, BGP can greatly improve network flexibility and expansibility.

  • VPN targets are used to control route advertisement between different VPNs on a PE. After being configured with matching VPN targets, different VPN instances on a PE can import routes from each other.

  On a PE, different VPNs have different RDs, but the extended community attributes allowed by BGP are limited. Using RDs for route importing limits network expansibility.

  On a BGP/MPLS IP VPN, VPN targets can be used to control exchange of VPN routes between sites. Export VPN targets and import VPN targets are independent of each other and can be configured with multiple values, ensuring flexible VPN access control and diversified VPN networking modes.

• Multiprotocol Border Gateway Protocol (MP-BGP)

  Traditional BGP-4 standards can manage only IPv4 routing information, and cannot process VPN routes with overlapping address spaces.

  To correctly process VPN routes, VPNs use MP-BGP defined in relevant standards (Multiprotocol Extensions for BGP-4). MP-BGP supports multiple network layer protocols. Network layer protocol information is contained in the Network Layer Reachability Information (NLRI) field and the Next Hop field of an MP-BGP Update message.

  MP-BGP uses the address family to differentiate network layer protocols. An address family can be a traditional IPv4 address family or any other address family, such as a VPN-IPv4 address family or an IPv6 address family. For the values of address families, see relevant standards (Assigned Numbers).

Route Advertisement on a Basic BGP/MPLS IP VPN

After a PE receives routes of different VPNs from a local CE, if the next hops of these routes are reachable or these routes can perform recursion, the PE matches the export VPN targets of these routes with the import VPN targets of its local VPN instances. This process is called local route leaking. During local route leaking, the PE filters these routes based on a VRF import policy and modifies the attributes of eligible routes.

Packet Forwarding on a BGP/MPLS IP VPN

On a BGP/MPLS IP VPN backbone network, a P does not know VPN routing information. VPN packets are forwarded between PEs over tunnels. Figure 15-46 shows an example of packet forwarding on a BGP/MPLS IP VPN. A packet is transmitted from CE1 to CE2. I-L indicates an inner label, and O-L indicates an outer label. The outer label directs the packet to the BGP next hop, and the inner label identifies the outbound interface for the packet or the VPN to which the packet belongs.

Figure 15-46 Forwarding of a VPN packet from CE1 to CE2

In this manner, the packet is sent from CE1 to CE2. CE2 forwards the packet to the destination in the way it sends other IP packets.

Benefits

Networking Description

Hub & Spoke networking schemes include:

• External Border Gateway Protocol (EBGP) running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs

• IGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs

• EBGP running between the Hub-CE and Hub-PE, and IGP running between Spoke-PEs and Spoke-CEs

The following describes these networking schemes in detail:

• EBGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs

  Figure 15-49 EBGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs
  
  

  As shown in Figure 15-49, the routing information advertised by a Spoke-CE is forwarded to the Hub-CE before being transmitted to other Spoke-PEs. If EBGP runs between the Hub-PE and Hub-CE, the Hub-PE performs the AS-Loop check on the route. If the Hub-PE detects its own AS number in the route, it discards the route. In this case, to implement the Hub & Spoke networking, the Hub-PE must be configured to permit the existence of repeated local AS numbers.

• IGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs

  Figure 15-50 IGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs
  
  

  Because all PEs and CEs exchange routing information through IGP and IGP routes do not contain the AS_Path attribute, the AS_Path field of BGP VPNv4 routes is null.

• EBGP running between the Hub-CE and Hub-PE, and IGP running between Spoke-PEs and Spoke-CEs

  Figure 15-51 EBGP running between the Hub-CE and Hub-PE, and IGP running between Spoke-PEs and Spoke-CEs
  
  

  The networking topology is similar to that shown in Figure 15-49. The AS_Path attribute of the route forwarded by the Hub-CE to the Hub-PE contains the AS number of the Hub-PE. Therefore, the Hub-PE must be configured to permit the existence of repeated local AS numbers.

Background

The multi-VPN-instance customer edge (MCE) technology provides logically independent VPN instances and address spaces on a CE, allowing multiple VPN users to share the same CE. The MCE technology provides an economical and easy-to-use solution to solve problems concerned with VPN service isolation and security.

VPN services are becoming increasingly refined, and the demand for VPN service security is growing. Carriers must isolate different types of VPN services on networks to meet this demand. As shown in Figure 15-52, the traditional BGP/MPLS IP VPN technology isolates VPN services by deploying one CE for each VPN, bringing in high costs and complicated network deployment. If multiple VPNs use the same CE to access upper-layer devices, these VPNs will share the same routing and forwarding table, and data security for these VPNs cannot be ensured. The MCE technology addresses conflicts between network costs and data security problems caused by multiple VPNs sharing the same CE.

Figure 15-52 Networking diagram for VPN service isolation using BGP/MPLS IP VPN

Implementation

The MCE technology creates a VPN instance for each VPN service to be isolated. Each VPN uses an independent routing protocol to communicate with the MCE to which these VPNs are connected. A VPN instance is bound to each link between the MCE and the PE to which the MCE is bound. As a result, an independent channel is established for each VPN service, and different VPN services are isolated.

As shown in Figure 15-53, three VPN instances are configured on the MCE: VPN1, VPN2, and VPN3. To be specific, three independent VPN routing and forwarding tables are created on the MCE. VPN1 is bound to the link between the MCE and Site1 and a link between the MCE and PE, VPN2 is bound to the link between the MCE and Site2 and a link between the MCE and PE, and VPN3 is bound to the link between the MCE and Site3 and a link between the MCE and PE. These configurations allow VPN services to be isolated using only one MCE.

Figure 15-53 MCE networking

Benefits

The MCE technology enables CEs to provide PE functions. MCEs avoid the practice of deploying one CE for each VPN although; whereas isolating VPN services, significantly reducing maintenance costs and expenditure on devices.

Inter-AS VPN Option A

• Inter-AS VPN Option A overview

As a basic BGP/MPLS IP VPN application in the inter-AS scenario, Option A does not need special configurations and MPLS does not need to run between ASBRs. In this mode, ASBRs of two ASs directly connect to each other and function as PEs in the ASs. Each ASBR views the peer ASBR as its CE, creates a VPN instance for each VPN, and advertises IPv4 routes to the peer ASBR through EBGP.

On the network shown in Figure 15-54, for ASBR1 in AS 100, ASBR2 in AS 200 is a CE. Similarly, for ASBR2, ASBR1 is a CE. Here, a VPN LSP indicates a private network tunnel, and an LSP indicates a public network tunnel.

Figure 15-54 Inter-AS VPN Option A

• Route advertisement in an inter-AS VPN Option A scenario

  MP-IBGP runs between PEs and ASBRs to exchange VPN-IPv4 route information. A common PE-CE routing protocol (BGP or IGP multi-instance) or static route can be used between ASBRs for the exchange of VPN information. Because this involves interaction between different ASs, using EBGP is recommended.

  For example, CE1 advertises route 10.1.1.1/24 to CE2. Figure 15-55 shows the process. D indicates the destination address, NH the next hop, and L1 and L2 the VPN labels. This figure does not show the distribution of public network IGP routes and labels.

  Figure 15-55 Route advertisement in an inter-AS VPN Option A scenario
  

  The specific process is as follows:

  1. CE1 uses BGP, OSPF, or RIP to advertise the route to PE1 in AS 100.
  2. PE1 in AS100 uses MP-IBGP to advertise the labeled VPNv4 route to ASBR1 in AS100.
  3. After ASBR1 receives the VPNv4 route, if the ERT of the route matches the IRT configured for the local VPN instance, ASBR1 adds the route to the VPN routing table, saves the VPN label carried in the route, and advertises the unicast route to ASBR2 through the VPN instance peer relationship.
  4. ASBR2 converts the received unicast route to a VPNv4 route and uses MP-IBGP to advertise the VPNv4 route to PE2 in AS 200.
  5. PE2 in AS 200 uses BGP, OSPF, or RIP to advertise the route to CE2.
• Packet forwarding in an inter-AS VPN Option A scenario
  Figure 15-56 shows the process of forwarding packets through an LSP on the public network. L1 and L2 indicate VPN labels, and Lx and Ly public network labels.

  Figure 15-56 Packet forwarding in an inter-AS VPN Option A scenario
  

Inter-AS VPN Option B

• Inter-AS VPN Option B overview

  On the inter-AS VPN Option B network shown in Figure 15-57, two ASBRs use MP-EBGP to exchange labeled VPN-IPv4 routes received from local PEs in their respective ASs. A VPN LSP indicates a private network tunnel, and an LSP a public network tunnel.

  Figure 15-57 Inter-AS VPN Option B
  

  In inter-AS VPN Option B, ASBRs receive all inter-AS VPN-IPv4 routes from the local and external ASs and then advertise these routes. In basic MPLS VPN implementation, a PE stores only the VPN routes that match the VPN targets of its local VPN instances. The ASBRs are configured to store all the received VPN routes, regardless of whether these routes match the VPN targets of its local VPN instances.

  The advantage of this solution is that all traffic is forwarded by ASBRs. In this way, traffic is controllable, but the loads on the ASBRs are heavy. BGP routing policies, such as VPN target-based filtering policies, can be configured on ASBRs, so that ASBRs only save some of VPN-IPv4 routes.

• Route advertisement in an inter-AS VPN Option B scenario
  Figure 15-58 shows a route advertisement example. In this example, CE1 advertises route 10.1.1.1/24 to CE2. NH indicates the next hop, and L1, L2, and L3 the VPN labels. This figure does not show the distribution of public network IGP routes and labels.

  Figure 15-58 Route advertisement in an inter-AS VPN Option B scenario
  

  The specific process is as follows:

  1. CE1 uses BGP, OSPF, or RIP to advertise the route to PE1 in AS 100.
  2. PE1 in AS 100 uses MP-IBGP to advertise the labeled VPNv4 route to ASBR1 in AS 100. If a route reflector (RR) is deployed on the network, PE1 advertises the VPNv4 route to the RR, and the RR then reflects the route to ASBR1.
  3. ASBR1 uses MP-EBGP to advertise the labeled VPNv4 route to ASBR2. Because MP-EBGP changes the next hop of a route when advertising the route, ASBR1 allocates a new label to the VPNv4 route.
  4. ASBR2 uses MP-IBGP to advertise the labeled VPNv4 route to PE2 in AS 200. If an RR is deployed on the network, ASBR2 advertises the VPNv4 route to the RR, and the RR then reflects the route to PE2. When ASBR2 advertises routes to an MP-IBGP peer in the local AS, it changes the next hop of the routes to itself.
  5. PE2 in AS 200 uses BGP, OSPF, or RIP to advertise the route to CE2.

  ASBR1 and ASBR2 both swap the inner labels of VPNv4 routes and use BGP to transmit inter-AS label information. Therefore, LDP does not need to run between ASBRs.
• Packet forwarding in an inter-AS VPN Option B scenario

  In an inter-AS VPN Option B scenario, the two ASBRs need to swap VPN LSPs once during packet forwarding. Figure 15-59 shows the process of forwarding packets through an LSP on the public network. Here, L1, L2, and L3 indicate VPN labels, and Lx and Ly indicate public network labels (outer tunnel labels).

  Figure 15-59 Packet forwarding in an inter-AS VPN Option B scenario
  

Inter-AS VPN Option C

• Inter-AS VPN Option C overview

  In the preceding two inter-AS VPN modes, ASBRs need to maintain and distribute VPN-IPv4 routes. When each AS needs to exchange a large number of VPN routes, ASBRs may hinder network expansion.

  One solution to the problem is that PEs directly exchange VPN-IPv4 routes with each other and ASBRs do not maintain or advertise such routes.

  • ASBRs use MP-IBGP to advertise labeled IPv4 routes to PEs in their respective ASs, and advertise labeled IPv4 routes received by PEs in their respective ASs to the peer ASBRs in other ASs. ASBRs in the intermediate AS also advertise labeled IPv4 routes. Therefore, a VPN LSP needs to be established between the ingress and egress PEs.

  • The PEs in different ASs establish multi-hop EBGP connections with each other to exchange VPN-IPv4 routes.

  • The ASBRs neither store VPN-IPv4 routes nor advertise VPN-IPv4 routes to each other.

  Figure 15-60 shows the networking of inter-AS VPN Option C. In the figure, VPN LSPs are private network tunnels, and LSPs are public network tunnels. A BGP LSP enables two PEs to exchange loopback route information. A BGP LSP consists of two unidirectional BGP LSP. For example, BGP LSP1 is established from PE1 to PE2, and BGP LSP2 is established from PE2 to PE1.

  Figure 15-60 Inter-AS VPN Option C
  

  To improve scalability, you can specify an RR in each AS. The RR stores all VPN-IPv4 routes and exchanges VPN-IPv4 routes with PEs in the same AS. The RRs in two ASs establish MP-EBGP connections with each other to advertise VPN-IPv4 routes.

  Figure 15-61 Inter-AS VPN Option C with RRs deployed
  
• Route advertisement in an inter-AS VPN Option C scenario

  The key to implementing inter-AS VPN Option C is to establish inter-AS public network tunnels. For example, Figure 15-62 shows how CE1 advertises route 10.1.1.1/24. D indicates the destination address, NH the next hop, L3 the VPN label, and L9 and L10 the BGP LSP labels. This figure does not show the distribution of public network IGP routes and labels.

  Figure 15-62 Route advertisement in an inter-AS VPN Option C scenario
  
• Packet forwarding in an inter-AS VPN Option C scenario

  Figure 15-63 shows the process of forwarding packets through an LSP on the public network. L3 indicates the VPN label, L10 and L9 BGP LSP labels, and Lx and Ly public network labels (outer tunnel labels).

  Figure 15-63 Packet forwarding in an inter-AS VPN Option C scenario
  

  When PE2 forwards a packet to PE1, PE2 needs to add three labels to the packet: a VPN label, a BGP LSP label, and a public network label. When the packet reaches ASBR2, only the VPN label and BGP LSP label remain. After the packet reaches ASBR1, ASBR1 removes the BGP LSP label and forwards the packet as a common MPLS VPN packet.

Comparison of the Three Inter-AS VPN Modes

Background

A customer of an SP providing BGP/MPLS IP VPN services may also be an SP. In this case, the SP providing the BGP/MPLS VPN service is called the provider carrier or Level 1 carrier and the customer is called the customer carrier or Level 2 carrier, as shown in Figure 15-64. This networking model is called carrier's carrier. In this model, the Level 2 carrier is a VPN user of the Level 1 carrier.

Figure 15-64 Networking of carrier's carrier

Related Concepts

To ensure good expansibility, the Level 2 carrier uses an operation mode similar to that of a stub VPN. In other words, the Level 1 carrier CE advertises only Level 2 carrier's internal routes, instead of the Level 2 carrier routes, to the Level 1 carrier PE. In this section, the internal and external routes of the Level 2 carrier are called internal and external routes for short, respectively.

The differences between internal and external routes are as follows:

• Routes to Level 2 carrier SP sites are called internal routes. The routes to VPNs of the Level 2 carrier are called external routes.

• Level 1 carrier PEs exchange internal routes using BGP. The external routes are exchanged using BGP between Level 2 carrier PEs, but are not advertised to Level 1 carrier PEs.

• The VPN-IPv4 routes of the Level 2 carrier are considered as external routes. The Level 2 carrier PEs import only internal routes and not external routes to their VRFs, reducing the number of routes that need to be maintained on the Level 1 carrier network. The Level 2 carrier network has to maintain both internal and external routes.

The Level 1 carrier's CEs refer to the devices used by the Level 2 carrier to access the Level 1 carrier network. These devices function as CEs for the Level 1 carrier and as PEs for the Level 2 carrier. The devices used by users to access the Level 2 carrier network are called user CEs.

Scenario Categories

A customer carrier can be a common SP or a BGP/MPLS IP VPN SP.

If a Level 2 carrier is a common SP, MPLS does not need to be configured on Level 2 carrier PEs. Level 2 carrier PEs communicate with Level 1 carrier PEs using an IGP. Level 2 carrier PEs exchange external routes with each other over BGP sessions, as shown in Figure 15-65.

In this scenario, BGP needs to run between CE1 and CE2 to transmit the internal routes of the Level 2 carrier. If CE1 and CE2 are in the same AS, establish an IBGP peer relationship between CE1 and CE2 and configure CE1 and CE2 as RRs. If CE1 and CE2 are in different ASs, establish an EBGP peer relationship between CE1 and CE2.

Figure 15-65 Level 2 carrier serving as a common SP

If a Level 2 carrier is a BGP/MPLS IP VPN SP, Level 2 carrier PEs must be configured with MPLS. Level 2 carrier PEs communicate with Level 1 carrier CEs using an IGP and LDP. Level 2 carrier PEs exchange external routes between each other using MP-BGP, as shown in Figure 15-66.

Because PE3 and PE4 need to provide VPN services, an LSP needs to be established between PE3 and PE4. Generally, LDP runs between the Level 1 carrier and Level 2 carrier. Two solutions are available for connecting the Level 1 carrier CE to the Level 1 carrier PE: using the LDP multi-instance to establish an LDP LSP, or using BGP labeled routes to establish a BGP LSP.

Figure 15-66 Level 2 carrier serving as a BGP/MPLS IP VPN SP

Classification of Implementation Solutions

When the Level 2 carrier is a common SP, the IP network and the BGP/MPLS IP VPN are co-constructed. The key point is that a BGP peer relationship is re-established after Level 1 carrier CEs can communicate with each other.

When the Level 2 carrier is a BGP/MPLS IP VPN SP, the LDP multi-instance solution is called carrier's carrier solution 1 and the BGP label routing solution is called carrier's carrier solution 2 according to the method that the Level 2 carrier CE uses to access the Level 2 carrier PE.

The scenario where the Level 2 carrier is a BGP/MPLS IP VPN SP is more commonly used. The scenario where the Level 2 carrier is a common SP is seldom used and the configuration scheme is simple. Therefore, the following description focuses on the scenario where the Level 2 carrier is a BGP/MPLS IP VPN SP.

Carrier's Carrier Solution 1 (LDP Multi-Instance)

When the Level 1 carrier CE uses the LDP multi-instance to set up an LDP LSP to access the Level 1 carrier PE, the routing information exchange process is shown in Figure 15-67. D represents the destination address of a route, N the next hop, and L the label.

Figure 15-67 Route information exchange process in carrier's carrier solution 1

The following uses the advertisement of a VPN route destined for 10.1.1.1/32 advertised by PE4 to PE3 as an example to describe VPN route exchange inside the Level 2 carrier network.

1. PE4 advertises a route destined for itself to CE2 using an IGP running on the Level 2 carrier network. Meanwhile, PE4 assigns label L''1 to the IGP next hop and establishes a public network LSP to CE2.

2. CE2 advertises the route destined for PE4 to PE2 using an IGP running between CE2 and PE2. In addition, LDP is used to allocate label L1 to the route. (LDP multi-instance needs to be configured on PE2's interface connected to CE2.)

3. PE2 assigns label L2 to the route destined for PE4 and advertises the route to PE1 using MP-IBGP. Previously, PE2 has advertised its routes to PE1 using an IGP running on the Level 1 carrier backbone network and assigned label L' to the routes destined for itself. A public network LSP has been established between PE2 and PE1.

4. PE1 assigns label L3 to the route destined for PE4 based on the LDP multi-instance peer relationship with CE1, and advertises the route carrying label L3 to CE1.

5. CE1 uses an IGP to advertise the route to PE4 to PE3.

   Previously, CE1 has advertised its routes to PE3 using an IGP running on the Level 2 carrier backbone network and assigned label L''2 to the routes destined for itself. A Level 2 public network LSP has been established between CE1 and PE3.

6. After the route destined for PE3 is advertised to PE4, an MP-IBGP connection is established between PE3 and PE4.

7. PE4 assigns VPN label I-L to the VPN route destined for 10.1.1.1/32 and advertises the route to PE3 using MP-IBGP.

   The advertisement of a VPN route from PE3 to PE4 is similar to that from PE4 to PE3 and therefore is not described here.

Figure 15-68 shows the transmission of VPN packets on the carrier network. I-L indicates a VPN label assigned by MP-BGP. L' indicates the public network label used on the Level 1 carrier network. L''1 and L''2 stand for public network labels used on the Level 2 carrier network. L1, L2, and L3 represent labels assigned to packets destined for PE4.

Figure 15-68 Packet forwarding process in carrier's carrier solution 1

The following uses forwarding of the VPN packet destined for 10.1.1.1/32 from PE3 to CE4 as an example to describe VPN packet forwarding over carrier networks.

1. After receiving a VPN packet destined for 10.1.1.1/32, PE3 adds the VPN label I-L to this packet and transparently transmits the packet to CE1 over the public network LSP on the Level 2 carrier network.

   Before the packet arrives at CE1, the penultimate LSR removes the outer public network label of the packet.

2. CE1 adds label L3 to the packet and forwards this packet to PE1.

3. PE1 replaces label L3 with label L2 and adds label L' to the packet. PE1 then forwards the packet to PE2 over the public network LSP. Before the packet arrives at PE2, the penultimate LSR removes label L'.

4. PE2 replaces label L2 with label L1 and forwards the packet to CE2.

5. CE2 removes label L1, adds label L''1, and transparently forwards the packet to PE4 over the public network LSP on the Level 2 carrier network.

   Before the packet arrives at PE4, the penultimate LSR removes label L''1.

6. PE4 removes label I-L and forwards the packet to CE4 based on label I-L.

Carrier's Carrier Solution 2 (BGP Labeled Route)

Figure 15-69 shows the route exchange process when the Level 1 carrier CE uses the BGP labeled route solution to establish a BGP LSP and accesses the Level 1 carrier PE. D represents the destination address of a route, N the next hop, and L the label.

Figure 15-69 Route information exchange process in carrier's carrier solution 2

The following uses the advertisement of a VPN route destined for 10.1.1.1/32 from PE4 to PE3 as an example to describe VPN route exchange inside the Level 2 carrier network.

1. PE4 advertises a route destined for itself to CE2 using an IGP running on the Level 2 carrier network. Meanwhile, PE4 assigns label L''1 to the IGP next hop and establishes a public network LSP to CE2.

2. CE2 assigns label L1 to the route to PE4 based on the MP-BGP peer relationship with PE2, and advertises the labeled route to PE2.

3. PE2 assigns label L2 to the route and advertises the route destined for PE4 to PE1 using MP-IBGP.

   Previously, PE2 has advertised its routes to PE1 using an IGP running on the Level 2 carrier's backbone network and assigned label L' to the routes destined for itself. A public network LSP has been established between PE2 and PE1.

4. PE1 assigns label L3 to the route destined for PE4 based on the MP-BGP peer relationship with CE1, and advertises the route carrying label L3 to CE1.

5. CE1 assigns label L4 to the route destined for PE4, and advertises the route carrying label L4 to PE3 through the MP-IBGP peer relationship between CE1 and PE3.

   Previously, CE1 has advertised its route to PE3 using an IGP running on the Level 2 carrier backbone network and assigned label L''2 to the route destined for itself. A Level 2 public network LSP has been established between CE1 and PE3.

6. The route destined for PE4 and label assigned to the route are advertised to PE3. A BGP LSP is established between CE2 and PE3.

   After the route destined for PE3 is advertised to PE4, an MP-EBGP connection is successfully established between PE3 and PE4.

7. PE4 assigns VPN label I-L to the VPN route destined for 10.1.1.1/32 and advertises the route to PE3 using MP-EBGP.

The advertisement of the VPN route from PE3 to PE4 is similar to that from PE4 to PE3 and therefore is not described here.

Figure 15-70 shows the transmission of VPN packets on the carrier network. I-L represents the VPN label assigned using MP-BGP. L' indicates the public network label used on the Level 1 carrier network. L''1 and L''2 stand for public network labels used on the Level 2 carrier network. L1, L2, L3, and L4 represent labels assigned to packets destined for PE4.

Figure 15-70 Packet forwarding process in carrier's carrier solution 2

The following uses forwarding of the VPN packet destined for 10.1.1.1/32 from PE3 to CE4 as an example to describe VPN packet forwarding over carrier networks.

1. After receiving the VPN packet destined for 10.1.1.1/32, PE3 adds the VPN label I-L and BGP LSP label L4 to this packet and transparently forwards the packet to CE1 over the public network LSP on the Level 2 carrier network.

   Before the packet arrives at CE1, the penultimate LSR removes the outer public network label of the packet.

2. CE1 replaces L4 with L3 and forwards the packet to PE1.

3. PE1 replaces label L3 with label L2, adds label L', and forwards the packet to PE2 over the public network LSP. Before the packet arrives at PE2, the penultimate LSR removes label L'.

4. PE2 replaces label L2 with label L1 and forwards the packet to CE2.

5. CE2 removes label L1, adds label L''1, and transparently forwards the packet to PE4 over the public network LSP on the Level 2 carrier network.

   Before the packet arrives at PE4, the penultimate LSR removes label L''1.

6. PE4 removes label I-L and forwards the packet to CE4 based on label I-L.

Benefits

The carrier's carrier model has the following advantages:

• Part of the configuration, management, and maintenance work used to be carried out by the Level 2 carrier can be undertaken by the Level 1 carrier.

• The Level 2 carrier can flexibly plan addresses, as its addresses are independent of those of the customers and the Level 1 carrier.

• The Level 1 carrier can provide VPN services for multiple Level 2 carriers over a backbone network, and can provide Internet services at the same time. This increases the profits of the Level 2 carrier.

• The Level 1 carrier manages and maintains VPN services of each Level 2 carrier in the same manner instead of maintaining individual backbone networks for Level 2 carriers. This simplifies the operation of the Level 1 carrier.

The carrier's carrier model has the following disadvantages: As a strict symmetrical networking mode, Only VPN users at the same network level can communicate with each other.

VPN users at the same network level need to directly exchange VPN routing information between each other. Therefore, these user devices must be routable. The user devices at the same network level must maintain all routing information of this network level. The PEs at the same network level need to directly exchange VPNv4 routes between each other.

Background

Figure 15-71 Basic architecture of a BGP/MPLS IP VPN

To deploy VPN functions in a hierarchical architecture, a BGP/MPLS IP VPN must use a hierarchical model instead of a plane model. As a result, the concept of HVPN is introduced.

Related Concepts

A UPE and an SPE are connected by only one link and exchange packets based on labels. An SPE does not need to provide a large number of interfaces for access users. UPEs and SPEs can be connected by physical interfaces with physical links, by sub-interfaces with VLANs or PVCs, or by tunnel interfaces with LSPs. If an IP or MPLS network resides between a UPE and an SPE, the UPE and SPE can be connected by tunnel interfaces to exchange labeled packets over a tunnel.

The capabilities of SPEs and UPEs differ according to the roles they play on a network. SPEs require large-capacity routing tables and high forwarding performance, but few interface resources. UPEs, on the other hand, require only low-capacity routing tables and low forwarding performance, but high access capabilities.

The roles of UPEs and SPEs are relative. On an HVPN, a superstratum PE is the SPE of an understratum PE, and an understratum PE is the UPE of a superstratum PE.

An HoPE is compatible with common PEs on an MPLS network.

If a UPE and an SPE belong to the same AS, they use MP-IBGP. If they belong to different ASs, they use MP-EBGP.

If MP-IBGP is used, an SPE can function as the RR for multiple UPEs to advertise routes between IBGP peers. To reduce the number of routes on UPEs, ensure that an SPE that is already acting as the RR for UPEs is not used as the RR for other PEs.

Figure 15-72 HVPN architecture

HVPN can be classified into HoVPN and H-VPN.

The following describes the route exchanging and packet forwarding processes on an HoVPN and an H-VPN. In the following figures, N indicates a next hop, and L indicates a label.

Route Advertisement from CE1 to Device1 on an HoVPN or H-VPN

Figure 15-73 Route advertisement from CE1 to Device1 on an HoVPN or H-VPN

Route Advertisement from Device1 to CE1 on an HoVPN

Figure 15-74 Route advertisement from Device1 to CE1 on an HoVPN

Route Advertisement from Device1 to CE1 on an H-VPN

Figure 15-75 Route advertisement from Device1 to CE1 on an H-VPN

Packet Forwarding from Device1 to CE1 on an HoVPN or H-VPN

Figure 15-76 Packet forwarding from Device1 to CE1 on an HoVPN or H-VPN

Packet Forwarding from CE1 to Device1 on an HoVPN

Figure 15-77 Packet forwarding from CE1 to Device1 on an HoVPN

Packet Forwarding from CE1 to Device1 on an H-VPN

Figure 15-78 Packet forwarding from CE1 to Device1 on an H-VPN

Related Functions

H-VPN supports HoPE embedding:

• You can connect a new SPE to an existing SPE and configure the existing SPE to be the UPE of the new SPE.

• You can connect a new UPE to an existing UPE and configure the existing UPE to be the SPE of the new UPE.

• HoPEs can be embedded repeatedly in the preceding two methods.

HoPE embedding can infinitely expand a VPN in theory.

Figure 15-79 shows a three-layer H-VPN, and the PEs in the middle are referred to as middle-level PEs (MPEs). MP-BGP runs between the SPE and MPEs, and between the MPEs and UPEs.

The MPE concept is introduced solely for descriptive purposes and does not actually exist in an H-VPN model.

MP-BGP advertises all the VPN routes of UPEs to the SPE, but advertises only the default routes of the VPN instances of the SPE to UPEs.

An SPE maintains the routes of all VPN sites connected to its understratum PEs, whereas a UPE maintains only the routes of its directly connected VPN sites. The numbers of routes maintained by an SPE, an MPE, and a UPE are in descending order.

Figure 15-79 HoPE embedding

Benefits

HVPN networking offers the following benefits:

• Flexible expansibility

  If the performance of a UPE is insufficient, you can add an SPE for the UPE to access. If the access capabilities of an SPE are insufficient, add more UPEs to the SPE.

• Reduced interface resource requirements

  Since a UPE and an SPE exchange packets based on labels, they only need to be connected over a single link.

• Reduced burdens on UPEs A UPE needs to maintain only local VPN routes. The remote VPN routes are represented by a default or aggregated route, lightening the burdens on UPEs.

• Simpler configuration

  SPEs and UPEs use MP-BGP, a dynamic routing protocol, to exchange routes and advertise labels. Each UPE only needs to establish a single MP-BGP peer relationship with an SPE.

Background

In BGP/MPLS IP VPN networking, a device assigns a VPN label (MPLS label) to each VPN instance by default. On a network with a large number of VPN routes, the one-label-per-instance mode helps conserve label resources and reduce PE capacity requirements. Table 15-4 describes three label allocation modes that are supported.

Implementation

One-label-per-instance

After one-label-per-instance label distribution is configured in a VPN instance IPv4 or IPv6 address family, all VPN routes from such an address family share the same VPN label. As shown in Figure 15-80, PE1 is configured with two VPN instances. If PE1 receives 10,000 routes from the sites of each VPN instance, only two labels on the PE are used by default.

Figure 15-80 Networking diagram for the one-label-per-instance mode

One-label-per-route

After the one-label-per-route function is configured in the VPN instance IPv4 or IPv6 address family view, each VPN route is assigned a label. During the forwarding of private network packets, the packets are forwarded directly to the next hop whose information is carried in a label, and the forwarding speed is fast.

One-label-per-nexthop

After one-label-per-next-hop label distribution is configured on an ASBR or PE, the ASBR or PE re-advertises an MP-BGP Update packet to its peers. The MP-BGP Update packet carries VPNv4 routes and their labels that are re-assigned based on next hops. After a peer receives the MP-BGP Update message, the peer updates its local label forwarding table and re-establishes an LSP. After the label forwarding tables of the ASBR or PE and its peers are updated, service traffic is forwarded according to the new label forwarding table.

Figure 15-81 Networking diagram for the one-label-per-next-hop mode

One-label-per-next-hop label allocation is applicable to VPN routes learned by PE1 and peer routes learned by ASBRs:

• Method 1: On the network shown in Figure 15-81, two VPN instances named VPN1 and VPN2 are configured on PE1 in the inter-AS VPN Option B scenario, and the label distribution mode is one-label-per-route. If 10,000 VPN routes are imported to CE1 and CE2 belonging to VPN1 and VPN2, respectively, 20,000 labels are consumed when ASBR1 advertises 20,000 routes learned from PE1 to ASBR2. After one-label-per-next-hop label allocation is enabled on ASBR1, ASBR1 allocates only one label to the VPN routes with the same next hop and outgoing label. In this case, ASBR1 only needs to allocate two labels to the 20,000 routes.

• Method 2: On the network shown in Figure 15-81, two VPN instances named VPN1 and VPN2 are configured on PE1 in the inter-AS VPN Option B scenario. Each of CE1 and CE2 belonging to VPN1 and VPN2, respectively, sends 10,000 VPN routes to PE1. If the label allocation mode is one-label-per-route, 20,000 labels are consumed when PE1 advertises 20,000 routes to ASBR1. After one-label-per-next-hop label allocation is enabled on PE1, PE1 allocates only one label to the VPN routes with the same next hop and outgoing label. In this case, PE1 only needs to allocate two labels to the 20,000 routes.

The one-label-per-route mode and one-label-per-next-hop mode can be flexibly switched to each other. During label allocation mode switching, service packets are lost for a short period due to the update of label forwarding tables.

In the inter-AS VPN Option B scenario, one-label-per-instance label allocation must be configured on PEs if one-label-per-next-hop label allocation is configured on ASBRs.

Benefits

Using an appropriate label distribute mode conserves label resources.

Background

In BGP/MPLS IP VPN networking, the users of a VPN can communicate with the users of another VPN provided that the two VPNs have matching VPN targets, but cannot communicate with public network users. To enable VPN users and public network users to communicate, configure route import between VPN and public network.

Implementation

After route import between VPN and public network is configured, the VPN and public network will be able to import protocol-specific routes from each other. The imported routes retain their route attributes and recursion information. After routes are imported, these routes need to be compared with the routes with the same prefix of the corresponding protocol in the destination routing table. Only the optimal route can be delivered to the IP routing table to guide traffic forwarding.

The VPN and public network can import the following types of routes from each other:

• Static routes
• Direct routes
• OSPF routes
• IS-IS routes
• BGP routes (including active BGP routes preferentially selected in the IP routing table and valid BGP routes with reachable next hops)
• Vlink direct routes

Traffic forwarding relies on direct routes (Vlink direct routes) generated based on user entries. When QinQ or Dot1q VLAN tag termination sub-interfaces are used for route import between VPN and public network, Vlink direct routes cannot be imported. As a result, traffic forwarding is interrupted. To solve this problem, route import between VPN and public network newly supports import of Vlink direct routes.

Usage Scenario

Route import between VPN and public network applies to scenarios where VPN users need to communicate with public network users in BGP/MPLS IP VPN networking. On the network shown in Figure 15-83, CE1 resides on a VPN and DeviceA resides on the public network. To enable VPN users to communicate with public network users, specifically, to enable CE1 to communicate with DeviceA, configure route import between VPN and public network on PE1.

After PE1 receives a BGP route from DeviceA, PE1 imports the route to its VPN instance. After PE1 determines based on a preconfigured routing policy that the newly imported route is an optimal route, PE1 adds the route to its VPN IP forwarding table and advertises the route to CE1, its VPN BGP peer. After PE1 receives a route from CE1, PE1 imports the route to its public network instance. After PE1 determines based on a preconfigured routing policy that the newly imported route is an optimal route, PE1 adds the route to its public IP forwarding table and advertises the route to DeviceA. CE1 and Device A can then communicate.

Figure 15-83 Route import between the VPN and public network instances

Benefits

Route import between VPN and public network allows VPN users to communicate with public network users.

Background

As networks develop rapidly, the time used for end-to-end service convergence if a fault occurs on a carrier's network has been used as an indicator to measure bearer network performance. MPLS TE FRR is one of the commonly used fast switching technologies. The solution is to create an end-to-end TE tunnel between two PEs and a backup label switched path (LSP) that protects a primary LSP. When either of the PEs detects that the primary LSP is unavailable because of a node or link failure, the PE switches the traffic to the backup LSP.

MPLS TE FRR protects services in case a link or node fails between two PEs at both ends of a TE tunnel. MPLS TE FRR, however, cannot protect services against endpoint PE faults. If a PE fault occurs, services can only be restored through end-to-end route convergence and LSP convergence. The service convergence time is closely related to the number of routes inside an MPLS VPN and the number of hops on the bearer network. The more VPN routes, the longer the service convergence time.

VPN FRR sets in advance on a remote PE forwarding entries pointing to the active and standby PEs, respectively. In collaboration with fast PE fault detection, VPN FRR can reduce end-to-end service convergence time if a fault occurs on an MPLS VPN where a CE is dual-homed to two PEs. In VPN FRR, service convergence time depends on only the time required to detect remote PE faults and change tunnel status. VPN FRR enables the service convergence time to be irrelevant to the number of VPN routes on the bearer network.

Implementation

As shown in Figure 15-84, normally, CE1 accesses CE2 over Link A. If PE2 is Down, CE1 accesses CE2 over Link B.

Based on the traditional BGP/MPLS IP VPN technology, both PE2 and PE3 advertise routes destined for CE2 to PE1, and assign VPN labels to these routes. PE1 then selects a preferred VPNv4 route based on the routing policy. In this example, the preferred route is the one advertised by PE2, and only the routing information, including the forwarding prefix, inner label, selected LSP, advertised by PE2 is filled in the forwarding entry of the forwarding engine to guide packet forwarding.

If PE2 fails, PE1 detects the fault on PE2 (the BGP peer goes Down or the MPLS LSP is unavailable), re-selects the route advertised by PE3, and updates the forwarding entry to complete E2E service convergence. Before PE1 re-delivers the forwarding entry for the route advertised by PE3, CE1 cannot access CE2 for a certain period. This is because PE2 is the end point of the MPLS LSP to which the forwarding entry refers and fails. As a result, E2E services are interrupted.

VPN FRR is an improvement on the traditional reliability technology. VPN FRR enables PE1 to add the optimal route advertised by PE2 and the second optimal route advertised by PE3 to a forwarding entry. The optimal route is used for traffic forwarding, and the second optimal route is used as a backup route.

If a fault occurs on PE2, the MPLS LSP between PE1 and PE2 becomes unavailable. After detecting the fault by means of techniques such as BFD, PE1 marks the corresponding entry in the LSP status table as unavailable, and delivers the setting to the forwarding table. After selecting a forwarding entry, the forwarding engine examines the status of the LSP corresponding to the forwarding entry. If the LSP is unavailable, the forwarding engine uses the second optimal route carried in the forwarding entry to forward packets. After being tagged with the inner labels assigned by PE3, packets are transmitted to PE3 over the LSP between PE1 and PE3 and then forwarded to CE2. In this manner, fast end-to-end service convergence is implemented and traffic from CE1 to CE2 is restored.

If both EVPN L3VPN over SRv6 and L3VPN over SRv6 are deployed on the network, PE2 and PE3 advertise four routes destined for CE2 to PE1. To prevent routes from the same device (PE2 or PE3) from being selected as the optimal route and sub-optimal route, configure an export routing policy to change the local preference of routes. This policy ensures that the route with the highest preference is preferred, and the selected optimal route and sub-optimal route correspond to link A and link B, respectively.

Figure 15-84 VPN FRR networking

Other Functions

VPN FRR is a fast switching technique based on inner labels. The outer tunnels can be LDP LSPs, RSVP-TE tunnels. When the forwarding engine detects that the outer tunnel is unavailable during packet forwarding, fast switching based on inner labels can be implemented.

VPNv6 FRR implements fast switching of IPv6 VPN routes on an IPv6 VPN where a CE is dual-homed to two PEs. The working principle of VPNv6 FRR is similar to that of VPN FRR.

Usage Scenario

On a VPN, after a PE fails, VPN FRR ensures that VPN services can be rapidly switched to the standby PE for transmission.

Benefits

On a VPN where a CE is dual-homed to two PEs, VPN FRR speeds up service convergence and enhances network availability in the case of PE failures.

Prerequisite for GR Implementation

On a traditional device, a processor implements both control and forwarding. The processor finds routes based on routing protocols, and maintains the routing table and forwarding table of the device. Mid-range and high-end devices generally adopt the multi-RP structure to improve forwarding performance and reliability. The processor in charge of routing protocols is located on the main control board, whereas the processor responsible for data forwarding is located on the interface board. The design helps to ensure the continuity of packet forwarding on the interface board during the restart of the main processor. The technology that separates control from forwarding satisfies the prerequisite for GR implementation.

At present, a GR-capable device must have two main control boards. In addition, the interface board must have an independent processor and memory.

Related Concepts

GR involves the following concepts:

• GR restarter: A GR-capable ME device that performs a master/slave main control board switchover upon the occurrence of a failure or under the instructions of an administrator.

• GR helper: Neighbor of a GR restarter. A GR helper must support GR.

• GR session: indicates a session, through which a GR restarter and a GR helper negotiate GR capabilities.

• GR time: indicates the time when the GR helper finds that the GR restarter is Down but keeps the topology information or routes obtained from the GR restarter. This time is called GR time.

Currently, the HUAWEI ME60 can only function as a GR helper.

VPN GR Overview

VPN GR is the application of the GR technology on a VPN. VPN GR ensures that VPN traffic is not interrupted when a master/slave main control board switchover is performed on a ME device that transmits VPN services. VPN GR offers the following benefits:

• Reduces the impact of VPNv4 route or BGP label route flapping on an entire network during the route processor switchover.

• Decreases the packet loss ratio to almost 0%.

• Reduces the impact on important VPN services.

• Reduces PE or CE single-point failures to improve the reliability of an entire VPN.

To support VPN GR, a BGP/MPLS IP VPN must support IGP GR and BGP GR. When using an MPLS LDP LSP as a tunnel, the BGP/MPLS IP VPN must support MPLS LDP GR. If traffic engineering is used, the BGP/MPLS IP VPN must also support RSVP GR. After the master/slave main control board switchover is performed on a PE or CE, the ME device and its connected PE can keep the forwarding information of all VPN routes for a certain period to ensure that VPN traffic is not interrupted. In addition, the CE that connects to the PE on which the master/slave main control board switchover is performed also needs to keep the forwarding information of all VPN routes for a certain period.

On a common L3VPN, the master/slave main control board switchover can be performed on the ME device that functions as a PE, CE, or P.

Master/Slave Main Control Board Switchover of a PE

The master/slave main control board switchover of a PE consists of three phases:

1. Before the switchover

   The PE negotiates the IGP GR and MPLS LDP GR capabilities with a P, and negotiates the IGP GR or BGP GR capabilities with the connected CE. The PE also negotiates BGP GR capabilities with the peer PE and sends the Open message containing the GR capability field of <AFI=Unicast, SAFI=VPNv4>.

2. During the switchover

   The PE keeps the status of forwarding VPNv4 routes and the following procedures are involved:

   • MPLS LDP GR

     If a neighbor detects that the corresponding TCP session enters the Down state, the neighbor backs up all LSPs on the slave board and marks these LSPs as invalid.

   • BGP GR

     BGP session messages are lost during the switchover. Then, the PE does not keep any routing information but the forwarding information. GR-aware BGP peers mark all the routes related to the GR ME devices as Stale. The BGP peers, however, still forward packets based on these routes within the GR time.

3. After the switchover

   The PE instructs all the IGP neighbors, BGP IPv4 peers, and private network IGP neighbors between the PE and CE to reestablish connections. The following procedures are involved:

   • IGP convergence

     To resynchronize the link state database (LSDB) of OSPF or IS-IS with the neighboring P, the PE sends a signal to each neighboring P and reestablishes the neighbor relationship list after receiving a response. If IS-IS or OSPF multi-instances are run between the PE and CE, the PE also needs to resynchronize the LSDB with the CE. The PE obtains the topology or routing information by establishing sessions with all the neighbors. The PE obtains topology or routing information by establishing sessions with all neighbors. After obtaining the topology and routing information, the PE recalculates the routing table and deletes the routes in the Stale state to complete IGP convergence.

   • BGP convergence

     The PE also exchanges routing information with BGP peers, including public network BGP peers, MP-BGP peers, and private network BGP peers. The PE then updates the routing table and the forwarding table according to the new routing information and replaces the invalid routing information to complete BGP convergence.

     After receiving the End-of-Rib message from a BGP peer on a public or private network, the PE notifies the routing management (RM) module. The End-of-Rib message is used to notify the peer that the first routing information update after a BGP session is established has been completed.

     Before all routing protocols complete the GR, only FIB information on the main control board is updated, and the FIB information on the interface board is not updated.

   After all routing protocols complete the GR, the RM module sends a message to notify each protocol that the GR is complete, and then updates the FIB information on the interface board. BGP sends BGP public network IPv4 routes, private network IPv4 routes, and VPNv4 routes to each peer. After sending the routes, BGP sends End-of-Rib messages.

The processing on ME devices connected to the PE is as follows:

• After detecting the restart of the PE, the CE connected to this PE uses the same processing flow as that of the GR helper in the common IGP GR or BGP GR and keeps information about all IPv4 routes for a certain period.

• After the P connected to this PE detects the restart of the PE, either of the following situations occurs:

  • If BGP is not configured, the P uses the same processing flow as that of the GR helper in the common IGP GR or MPLS LDP GR.

  • If BGP is configured, the BGP processing flow is the same as that of the GR helper in the common BGP GR except that the BGP processing flow includes additional IGP GR processing and MPLS LDP GR processing, and the P then keeps information about all the public IPv4 routes for a certain period.

• After detecting the restart of the PE, the RRs reflecting VPNv4 routes and the other PEs (including ASBRs) connected to this PE use the same processing flow as that of the GR helper in the BGP GR. They then keep information about all the public IPv4 routes and VPNv4 routes for a certain period.

Master/Slave Main Control Board Switchover of a P

The processing flow of a P is the same as that of the GR restarter in common IGP GR, MPLS LDP GR, or BGP GR.

After detecting the restart of a P, other Ps and PEs that connect to the P use the same processing flow as that of the GR helper in common IGP GR or BGP GR. That means that they keep information about all the public network IPv4 routes for a certain period.

Master/Slave Main Control Board Switchover of a CE

The processing flow of a CE is the same as that of the GR restarter in common IGP GR or BGP GR.

After detecting the restart of a CE, the PEs that connect to the CE use the same processing flow as that of the GR helper in common IGP GR or BGP GR. That means that they keep information about all the private network IPv4 routes for a certain period.

Background

Carriers have increasing demands for IP network reliability. Conventional non-stop forwarding (NSF) and GR techniques cannot prevent traffic interruptions if a neighboring node does not support GR or multiple nodes fail simultaneously during a GR process. Interruptions occur because a GR-enabled node cannot obtain routing information from or establish control plane connections to neighboring nodes during the GR process. As a result, traffic is interrupted temporarily before the GR process is complete. To tackle this problem, NSR is introduced. NSR is an innovation, compared with NSF. NSR can be used to ensure uninterrupted traffic transmission and retain control plane connections if a software or hardware fault occurs on the control plane. The control planes of neighboring nodes are unaware of the fault during the NSR process.

Related Concepts

• High availability (HA): supports data backup between the AMB and SMB.
• Non-stop forwarding (NSF): enables a node to use the GR mechanism to ensure uninterrupted transmission during an AMB/SMB switchover.
• NSR: allows a standby control plane to take over traffic from an active control plane if the active control plane fails, preventing the control planes of neighbors from detecting the fault.
• AMB and SMB: run control plane processes.

Implementation

Active and standby control planes must be able to run on different boards of an NSR-capable device.

For details about NSR, see chapter "Uninterruptible Service Technology" in HUAWEI ME60Multiservice Control GatewayFeature Description - Reliability.

Related Functions

An NSR-enabled device can function as a GR helper. The GR helper communicates with NSR-disabled devices and responds to neighboring nodes' GR requests during an AMB/SMB switchover.

Usage Scenario

If a single node is connected to multiple links, FRR is used on the link side to protect services. If the master main control on the node fails, services are interrupted. Therefore, NSR needs to be configured on the node to enhance reliability. Figure 15-85 shows a typical NSR application using PE3.

Figure 15-85 Typical VPN NSR application

NSR minimizes the impact of control plane faults and prevents route flapping on heavily loaded networks.

Benefits

• NSR ensures the uninterrupted operation of the forwarding plane and allows a standby control plane to retain connections between a local node and its neighboring nodes if the VPN control plane of the local node fails.

• A VPN node can use NSR to work independently without the assistance of neighboring nodes. NSR can help multiple VPN nodes implement AMB/SMB switchovers if control planes of these nodes over an MPLS network fail.

Typical Application Scenario of VPN MPLS/VPN SRv6 Dual-Stack Tunnels

When an MPLS backbone network that carries VPN routes spans multiple ASs, inter-AS VPN technology is used to deploy L3VPN over MPLS services. As IPv4 addresses gradually run out, IPv6 networks will be increasingly deployed to solve this issue. However, such an evolution cannot take place overnight, causing IPv4 and IPv6 services to coexist.

To prevent existing services from being compromised during the upgrade and evolution of existing networks, VPN MPLS/VPN SRv6 dual-stack tunnels can be used. Such tunnels not only prevent traffic interruption when IPv4 and IPv6 services coexist, but also make it much more feasible to transition from IPv4 to IPv6.

On the network shown in Figure 15-88, an end-to-end VPNv4 IPv4 peer relationship, a VPNv4 IPv6 peer relationship, and an SRv6 BE tunnel are established between PE1 and PE2.

Figure 15-88 Typical application scenario of VPN MPLS/VPN SRv6 dual-stack tunnels

Services are deployed in the following process:

1. An end-to-end VPNv4 IPv4 BGP peer relationship is established between PE1 and PE2. The route to CE1 is advertised to PE2 through the VPNv4 IPv4 BGP peer relationship. After receiving the route, PE2 adds the route to its VPN instance, which then sends the route to CE2.
2. PE1 and PE2 are configured to preferentially select routes with IPv4 next hops based on their high priority using the peer ipv4–address high-priority command.
3. SRv6 BE services are deployed between PE1 and PE2.
4. A VPNv4 IPv6 peer relationship is established between PE1 and PE2, and the devices are enabled to exchange IPv4 prefix SID information with each other using the peer ipv6–address prefix-sid command.
5. Run the segment-routing ipv6 locator locator-name or segment-routing ipv6 locator locator-name end-dt46 command in the VPN instance corresponding to CE1 on PE1 to enable VPN routes to carry the SID attribute.
6. After PE1 receives a VPN route from its VPN instance, PE1 advertises a copy of this route to the VPNv4 IPv4 peer and applies for an MPLS label. PE1 then advertises another copy to the VPNv4 IPv6 peer, with the route carrying a SID. A route without a SID cannot be advertised to the VPNv4 IPv6 peer.
7. PE2 receives two VPN routes with the same prefix, but one with an IPv4 next hop and the other with an IPv6 next hop. PE2 then adds the two routes to its VPN instance that connects to CE2.
8. After CE2 receives the two routes, the route with the IPv4 next hop recurses to the MPLS tunnel, and the route with the IPv6 next hop recurses to the SRv6 tunnel.
9. After the route with the IPv6 next hop becomes stable, the peer ipv6–address high-priority and undo peer ipv4–address high-priority commands are run on PE2 to trigger a change in route preference. In this way, the preferred route switches from that with the IPv4 next hop to that with the IPv6 next hop, and user traffic switches from the traditional MPLS tunnel to the SRv6 tunnel accordingly.

Application Scenario of VPN MPLS/VPN SRv6 Dual-Stack Tunnels (with RRs)

On the network shown in Figure 15-89, an end-to-end VPNv4 IPv4 peer relationship, a VPNv4 IPv6 peer relationship, and an SRv6 BE tunnel are established between PE1 and PE2.

Figure 15-89 Application scenario of VPN MPLS/VPN SRv6 dual-stack tunnels (with RRs)

Services are deployed in the following process:

1. In AS1, VPNv4 IPv4 BGP peer relationships are established between PE1 and RR1 and between RR1 and ASBR1. The next hop of a VPNv4 route is not changed when the route is being reflected by RR1.

2. In AS2, VPNv4 IPv4 BGP peer relationships are established between PE2 and RR2 and between RR2 and ASBR2. The next hop of a VPNv4 route is not changed when the route is being reflected by RR2.

3. PE1, ASBR1, ASBR2, and PE2 are configured to preferentially select routes with IPv4 next hops based on their high priority using the peer ipv4–address high-priority command.

4. SRv6 BE services are deployed between PE1 and PE2.

5. VPNv4 IPv6 peer relationships are established between PE1 and RR1, between RR1 and ASBR1, between ASBR2 and RR2, and between RR2 and PE2. The devices are enabled to exchange IPv4 prefix SID information with specified IPv6 peers using the peer ipv6–address prefix-sid command.

6. CE1 advertises VPN route A to PE1, and PE1 sends the route to the VPNv4 address family. After finding that route A is a locally leaked VPN route, the VPNv4 address family advertises route A to RR1 through the VPNv4 IPv4 and IPv6 peer relationships separately.

7. RR1 receives two routes with the same prefix but different next hops from its IPv4 and IPv6 peers. According to the BGP route advertisement policy, the RR advertises only the optimal route to ASBR1. This may lead to just one link being available to the same destination address during data transmission. To address this issue, you can deploy the BGP Add-Path feature on RR1 so that the router can advertise multiple routes with the same prefix to its BGP peers. Specifically, RR1 reflects the VPNv4 route with the IPv4 next hop to the IPv4 BGP peer, and reflects the VPNv4 route with the IPv6 next hop to the IPv6 BGP peer. In this way, multiple links to the same destination address are formed.

8. ASBR1 receives two VPN routes with the same prefix, but one with an IPv4 next hop and the other with an IPv6 next hop. ASBR1 adds both routes to its VPN instance. After the VPN instance receives the two remotely leaked routes, the route with the IPv4 next hop recurses to the MPLS tunnel, and the route with the IPv6 next hop recurses to the SRv6 tunnel.

9. CE2 switches traffic to the SRv6 BE tunnel, through which traffic is forwarded to ASBR1. Then ASBR1 also switches traffic to the SRv6 BE tunnel.

Route Regeneration Scenario with VPN MPLS/VPN SRv6 Dual-Stack Tunnels

On the network shown in Figure 15-90, a VPNv4 IPv6 BGP peer relationship and an SRv6 tunnel are established between PE1 and PE2. A VPNv4 IPv4 BGP peer relationship and an MPLS tunnel are established between PE2 and PE3.

Figure 15-90 Route regeneration scenario with VPN MPLS/VPN SRv6 dual-stack tunnels

Services are deployed in the following process:

1. PE3 advertises a route to PE2 through the VPNv4 IPv4 BGP peer relationship, and then PE2 advertises the route to PE1 through the VPNv4 IPv6 BGP peer relationship. Route advertisement from PE1 to PE3 follows the same process but in reverse.

2. PE2 advertises the route (received from PE3) with the IPv4 next hop to PE1, and advertises the route (received from PE1) with the IPv6 next hop to PE3.

3. Route regeneration is enabled on PE2. Specifically, after the VPNv4 routes received from PE3 and PE1 are added to PE2's VPN instance, the VPN instance is configured to advertise regenerated routes to the VPNv4 address family using the advertise route-reoriginate command.

4. PE2 is enabled to advertise the routes regenerated in the VPNv4 address family to the VPNv4 IPv4 and IPv6 BGP peers using the peer ipv4-address advertise route-reoriginated vpnv4 and peer ipv6-address advertise route-reoriginated vpnv4 commands, respectively.