BGP MPLS IP VPN Features PDF

VRP V500R011C01
BGP/MPLS IP VPN Feature Description

Issue Date 01 2012-09-10
HUAWEI TECHNOLOGIES CO., LTD.
Copyright Huawei Technologies Co., Ltd. 2012. All rights reserved. No part of this document may be reproduced or transmitted in any form or by any means without prior written consent of Huawei Technologies Co., Ltd.
Trademarks and Permissions

and other Huawei trademarks are trademarks of Huawei Technologies Co., Ltd. All other trademarks and trade names mentioned in this document are the property of their respective holders.
Notice
The purchased products, services and features are stipulated by the contract made between Huawei and the customer. All or part of the products, services and features described in this document may not be within the purchase scope or the usage scope. Unless otherwise specified in the contract, all statements, information, and recommendations in this document are provided "AS IS" without warranties, guarantees or representations of any kind, either express or implied. The information in this document is subject to change without notice. Every effort has been made in the preparation of this document to ensure accuracy of the contents, but all statements, information, and recommendations in this document do not constitute a warranty of any kind, express or implied.
Huawei Technologies Co., Ltd.

Address: Huawei Industrial Base Bantian, Longgang Shenzhen 518129 People's Republic of China http://www.huawei.com support@huawei.com
Website: Email:
Issue 01 (2012-09-10)
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.
VRP BGP/MPLS IP VPN Feature Description
Contents
Contents
1 Introduction to BGP/MPLS IP VPN...........................................................................................1 2 References.......................................................................................................................................3 3 Principles.........................................................................................................................................4
3.1 Basic BGP/MPLS IP VPN.................................................................................................................................5 3.2 Inter-AS VPN...................................................................................................................................................13 3.3 Carrier's Carrier................................................................................................................................................17 3.4 Multi-role Host.................................................................................................................................................27 3.5 HoVPN.............................................................................................................................................................29 3.6 Interconnection Between VPNs and the Internet..............................................................................................32 3.7 VPN FRR..........................................................................................................................................................36 3.8 IP+VPN FRR....................................................................................................................................................38 3.9 VPN GR............................................................................................................................................................39 3.10 VPN NSR.......................................................................................................................................................42 3.11 QPPB..............................................................................................................................................................42 3.12 BGP SoO........................................................................................................................................................43 3.13 Next-Hop-based Label Distribution for VPN Routes by ASBRs...................................................................44 3.14 Query on the Bearing Relationship Between VPN and Tunnel.....................................................................46 3.15 BGP/MPLS IPv6 VPN Extension..................................................................................................................47 3.16 VPN Dual-Stack Access.................................................................................................................................48
4 Applications..................................................................................................................................49
4.1 BGP/MPLS IP VPN Application.....................................................................................................................50 4.2 Typical Application of IP+VPN FRR..............................................................................................................51 4.3 Hub&Spoke Networking Application..............................................................................................................52 4.4 HoVPN Networking Application.....................................................................................................................54
5 Terms and Abbreviations..........................................................................................................57
Issue 01 (2012-09-10)
ii
1 Introduction to BGP/MPLS IP VPN
1
Definition
Introduction to BGP/MPLS IP VPN
A BGP/MPLS IP VPN is a Layer 3 Virtual Private Network (L3VPN). A BGP/MPLS IP VPN uses the Border Gateway Protocol (BGP) to advertise VPN routes and the Multiprotocol Label Switching (MPLS) to forward VPN packets on backbone networks. IP means that IP packets are carried by the VPN. Figure 1-1 shows the basic model of a BGP/MPLS IP VPN. Figure 1-1 Model of a BGP/MPLS IP VPN VPN 2 Site
VPN 1 Site
CE
Service provider's P backbone P
CE
PE PE PE VPN 2 Site P P VPN 1 Site
CE
CE
The BGP/MPLS IP VPN model consists of the following parts: l Customer Edge (CE): It is an edge device on a customer network, providing interfaces that are directly connected to the Service Provider (SP) network. A CE can be a router, a switch, or a host. Usually, a CE neither senses the VPN nor supports MPLS. Provider Edge (PE): It is an edge device on an SP network. A PE is directly connected to the CE. On an MPLS network, PEs process all VPN services. Thus, the requirements on the performance of PEs are rather high.
Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 1
Issue 01 (2012-09-10)
1 Introduction to BGP/MPLS IP VPN
Provider (P): It is a backbone device on an SP network. A P is not directly connected to CEs. Ps only need to possess basic MPLS forwarding capabilities and do not maintain information about a VPN.
PEs and Ps are managed by SPs. CEs are managed by users except that the users trust SPs with the management right. A PE can access multiple CEs. A CE can be connected to multiple PEs of the same SP or of different SPs.
Purpose
MPLS seamlessly integrates the flexibility of IP routing and simplicity of Asynchronous Transfer Mode (ATM) label switching. A connection-oriented control plane is introduced into an MPLS IP network, which enriches the means of managing and operating the network. On IP networks, MPLS traffic engineering (TE) has become an important tool in managing network traffic, reducing network congestion, and ensuring Quality of Service (QoS). Therefore, the VPNs or MPLS VPNs using MPLS IP networks as the backbone networks are highly evaluated by carriers, and become an important means of providing value-added services. Unlike the Interior Gateway Protocol (IGP), BGP focuses on controlling route transmission and choosing the optimal routes instead of discovering and calculating routes. VPNs use public networks to transmit VPN data, and the public networks use IGP to discover and calculate their routes. The key to constructing a VPN is controlling the transmission of VPN routes and choosing the optimal routes between two PEs. BGP uses the Transport Control Protocol (TCP) with the port number being 179 as the transport layer protocol. The reliability of BGP is thus enhanced. Therefore, VPN routes can be directly exchanged between two PEs with devices locating between them. BGP can carry any information appended to a route. As the optional BGP attributes, the information is transparently forwarded by BGP devices that cannot identify those attributes. VPN routes, thus, can be conveniently transmitted between PEs. When routes are updated, BGP sends only updated routes rather than all routes. This saves the bandwidth consumed by route transmission. The transmission of a great number of routes over a public network thus becomes possible. As an Exterior Gateway Protocol (EGP), BGP is suitable for VPNs that span more than one carrier network.
Issue 01 (2012-09-10)
2 References
2
The following table lists the references of this document. Docume nt RFC2858 RFC4364 RFC2764 RFC3392 RFC2917 RFC3107 RFC4026 RFC4364 RFC4577 Description Multiprotocol Extensions for BGP-4 BGP/MPLS IP Virtual Private Networks (VPNs) A Framework for IP Based Virtual Private Networks Capabilities Advertisement with BGP-4 A Core MPLS IP VPN Architecture Carrying Label Information in BGP-4 Provider Provisioned Virtual Private Network (VPN) Terminology BGP/MPLS IP Virtual Private Networks (VPNs)
References
Remarks
OSPF as the Provider/Customer Edge Protocol for BGP/ MPLS IP Virtual Private Networks (VPNs)
Issue 01 (2012-09-10)
3 Principles
3
About This Chapter
3.1 Basic BGP/MPLS IP VPN 3.2 Inter-AS VPN 3.3 Carrier's Carrier 3.4 Multi-role Host 3.5 HoVPN 3.6 Interconnection Between VPNs and the Internet 3.7 VPN FRR 3.8 IP+VPN FRR 3.9 VPN GR 3.10 VPN NSR 3.11 QPPB 3.12 BGP SoO 3.13 Next-Hop-based Label Distribution for VPN Routes by ASBRs 3.14 Query on the Bearing Relationship Between VPN and Tunnel 3.15 BGP/MPLS IPv6 VPN Extension 3.16 VPN Dual-Stack Access
Principles
Issue 01 (2012-09-10)
3 Principles
3.1 Basic BGP/MPLS IP VPN

Definition
As shown in Figure 3-1, a basic BGP/MPLS IP 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: l l l 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 3-1 Network diagram for a basic BGP/MPLS IP VPN

VPN1 VPN2 MP-BGP MPLS Backbone CE Site3
CE Site1
VPN2
PE
PE
VPN1
CE Site2
CE Site4
Related Concepts
l 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 with IP connectivity that can be achieved independent of service provider (SP) networks. As shown in Figure 3-2, on the networks on the left, the headquarters of company X in city A is a site, the branch of company X in city B is another site. IP devices can communicate within each site without using the SP network.
Issue 01 (2012-09-10)
3 Principles
Figure 3-2 Schematic diagram of sites

Two sites Site A CE Carrier's network CE Headquarters of X company in City A Carrier's network Headquarters of X company in City A CE CE Branch of X company in City B Branch of X company in City B One site Site X
Site B
Sites are classified based on the topological relationships between devices rather than the geographical locations of devices, although devices in a site are geographically adjacent to each other in general. If two geographically separated IP systems are connected over a leased line, the two systems form a site if they can communicate without the help of SP networks. As shown in Figure 3-2, if the branch network in city B is connected to the headquarters network in city A over a leased line instead of an SP network, the branch network and the headquarters network form a site. The devices at a site may belong to multiple VPNs. In other words, a site may belong to more than one VPN. As shown in Figure 3-3, in company X, the decision-making department in city A (Site A) is allowed to communicate with the research and development (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, two VPNs (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.
Issue 01 (2012-09-10)
3 Principles
Figure 3-3 One site belonging to multiple VPNs

City A Site A X Company Decision-making department CE VPN 2 City C X Company Financial department Site C Carrier's network CE VPN 1 Site B City B CE X Company R&D department
A site is connected to an SP network using a CE. A site may contain more than one CE, but a CE belongs to only 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 connected to the same SP network can be classified 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. l 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 the network segment 10.110.10.0/24, address space overlapping occurs.
NOTE
VPNs can use overlapped address spaces in the following situations: l Two VPNs do not cover the same site. l Two VPNs cover the same site, but devices at the site and devices using addresses in overlapped address spaces in the VPNs cannot 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 are connected to the public network or other VPNs. PEs are network-side devices, and a PE is generally connected 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
Issue 01 (2012-09-10)
3 Principles
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 VRFs. A PE has multiple instances, including a public network instance and one or more VPN instances, as shown in Figure 3-4. 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 their address spaces overlap. Figure 3-4 Schematic diagram of VPN instances
VPN1
Site1 CE VPN1 VPN-instance VPN2 VPN-instance VPN2 PE
Backbone
Public forwarding table
Site2 CE
The differences between a public routing and forwarding table and a VRF 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. According to 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. VPN instances on a PE are independent of each other and of the public routing and forwarding table. Each VPN instance can be regarded as a virtual router, which maintains an independent address space and has one or more interfaces connected to the router. In RFC 4364 (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 more accurate, 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.
Issue 01 (2012-09-10)
3 Principles
A VPN instance uses a route distinguisher (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. l 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 principles of its associated sites. Multiple sites form a VPN based on VPN instance rules. l RD and VPN-IPv4 address Traditional BGP cannot process the routes that have overlapping 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 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 the IPv4 address prefix, as shown in Figure 3-5. Figure 3-5 VPN-IPv4 address structure
Route Distinguisher ( 8-Byte ) Type Field ( 2-Byte ) Assigned Administrator Number Subfield Subfield IPv4 Address Prefix ( 4-Byte )
RDs are used to distinguish address spaces with the same IPv4 address prefix. The format of RDs enables SPs 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. l VPN target The VPN target, also called the route target (RT), is a 32-bit extended community attribute. BGP/MPLS IP VPN uses the VPN target to control the advertising of VPN routing information. A VPN instance is associated with one or more VPN targets. VPN targets are classified into the following types: Export target: After learning an IPv4 route from a directly connected site, a PE converts the route to a VPN-IPv4 route and sets export targets for the route. As an extended community attribute, export targets are advertised with the route. Import target: After receiving a VPN-IPv4 route from one PE, a second PE checks the export targets of the route. If one of the export targets is identical with an import target of a VPN instance on the PE, the PE adds the route to the corresponding VRF.
Issue 01 (2012-09-10) Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd. 9
3 Principles
A VPN target defines which sites can receive a VPN route and which VPN routes of which sites can be received by a PE. After receiving a route from a directly connected CE, a PE sets export targets for the route. The PE then uses BGP to advertise the route with the export targets to related PEs. After receiving the route, the related PEs compare the export targets with the import targets of all their VPN instances. If an export target is identical with an import target, the route is added to the corresponding VRF. The reasons for using the VPN target instead of the RD as the extended community attribute is 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 the flexibility and expansibility of a network. VPN targets can be used to control route advertisement between different VPNs on a PE. With properly configured 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 targets and import targets are independent of each other and can be configured with multiple values, ensuring flexible VPN access control and diversified VPN networking modes. l MP-BGP Traditional BGP-4 defined in RFC 1771 can manage IPv4 routes but not the routes of VPNs with overlapped address spaces. To correctly process VPN routes, VPNs use MP-BGP defined in RFC 2858 (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 VPNIPv4 address family or an IPv6 address family. For the values of address families, see RFC 1700 (Assigned Numbers).
Route Advertisement on a Basic BGP/MPLS IP VPN

On a basic BGP/MPLS IP VPN, CEs and PEs are responsible for advertising VPN routes, whereas Ps only need to maintain the backbone network routes. Ps do not need to maintain VPN routes, whereas PEs generally maintain all VPN routes on the network. Advertisement of VPN routes consists of three phases: from local CEs to the ingress PE, from the ingress PE to the egress PE, and from the egress PE to remote CEs. After this process, reachable routes can be established between local and remote CEs and VPN routes can be advertised on the backbone network. The following describes the three phases in detail. 1. Advertisement from local CEs to the ingress PE After neighbor or peer relationships are established between CEs and their directly connected PE, the CEs advertise local VPN routes to the PE. CEs can communicate with the PE over static routes or routes established using Routing Information Protocol (RIP), Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System (IS-IS), or BGP. Regardless of which routing protocol is used, routes advertised by CEs to the PE are standard IPv4 routes.
3 Principles
VPN instances on a PE are isolated from each other and independent of the public routing and forwarding table, so as to prevent problems caused by address space overlapping. After learning routes from CEs, a PE decides to which routing and forwarding table the routes need to be added based on configurations. 2. Advertisement from the ingress PE to the egress PE Advertisement from the ingress PE to the egress PE consists of the following parts: l After learning VPN routes from a CE, a PE stores these routes in corresponding VRFs and adds RDs to these standard IPv4 routes, generating VPN-IPv4 routes. l The ingress PE advertises VPN-IPv4 routes to the egress PE by sending MP-BGP Update messages. The MP-BGP Update messages also contain VPN targets and MPLS labels. Before being sent to the next-hop PE, these VPN-IPv4 routes are filtered by BGP routing policies, including the VRF export policy and peer export policy. After these routes arrive at the egress PE, if they pass the peer import policy and their next hops are reachable or they can be iterated, the egress PE performs local route crossing and filters these routes based on a VRF import policy. The egress PE then decides which routes are to be added to its VRFs. Routes received from other PEs are added to the VPN routing table based on VPN targets. The egress PE stores the following information for subsequent packet forwarding: l Values of MPLS labels contained in MP-BGP Update messages l Tunnel IDs generated after tunnel iteration 3. Advertisement from the egress PE to remote CEs A remote CE can learn VPN routes from an egress PE over static routes or routes established using RIP, OSPF, IS-IS, and BGP. Route advertisement from the egress PE to a remote CE is similar to that from a local CE to the ingress PE. The details are not described here. Note that routes advertised by the egress PE to a remote CE are standard IPv4 routes. 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 be iterated, the PE matches the export targets of these routes with its VRF import targets. This process is called local route crossing. During local route crossing, 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, Ps cannot recognize VPN routing information, so VPN packets are forwarded between PEs over tunnels. Figure 3-6 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.
Issue 01 (2012-09-10)
11
3 Principles
Figure 3-6 Forwarding of a VPN packet from CE1 to CE2

CE1 Ingress PE P Egress PE CE2
data
data data I-L O-L1 Push
data data I-L I-L O-L1 O-L2 Out-Label Switch
data data I-L O-L2 Pop
data
The forwarding process is as follows: 1. 2. CE1 sends a VPN packet to the ingress PE. After receiving the packet from an interface bound to a VPN instance, the ingress PE performs the following steps: l Searches the corresponding VPN forwarding table based on the RD of the bound VPN instance. l Matches the destination IPv4 address with forwarding entries and searches for the corresponding tunnel ID. l Adds an I-L to the packet and finds the tunnel to be used based on the tunnel ID. l Adds an outer label to the packet and sends the packet over the tunnel. In this example, the tunnel is an LSP, and the outer label is an MPLS label. l Transmits the double-tagged packet over the backbone network. Each P on the forwarding path swaps the outer label of the packet. 3. After receiving the packet, the egress PE removes the outer label of the packet.
NOTE
In this example, the final outer label of the packet is O-L2. If penultimate hop popping (PHP) is configured, O-L2 is removed on the penultimate hop, and the egress PE receives a packet with the inner label only.
4. 5.
The egress PE removes the inner label residing at the bottom of the label stack. The egress PE sends the packet from the corresponding outbound interface to CE2. After its labels are removed, the packet becomes a pure IP packet.
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
BGP/MPLS IP VPN brings the following benefits: l l Enables users to communicate with each other over networks of geographically different regions. Ensures the security of VPN user data during transmission on the public network.
Issue 01 (2012-09-10)
12
3 Principles
3.2 Inter-AS VPN

With the wide application of MPLS VPN solutions, different MANs of a carrier or backbone networks of collaborative carriers frequently span multiple ASs. Generally, an MPLS VPN architecture runs within an AS in which the VPN routing information is flooded on demand. The VPN routing information within the AS cannot be flooded to the AS of other SPs. To realize the exchange of VPN route information between different ASs, the interAS MPLS VPN model is introduced. The inter-AS MPLS VPN model is an extension of the existing protocol and MPLS VPN framework. Through this model, the route prefix and label information can be advertised over the links between different carrier networks. RFC 4364 presents the following Inter-AS VPN solutions: l Inter-Provider Backbones Option A: ASBRs manage VPN routes, through dedicated interfaces for the VPNs that traverse different ASs. This solution is also called VRF-toVRF. Inter-Provider Backbones Option B: ASBRs advertise labeled VPN-IPv4 routes to each other through MP-EBGP. This solution is also called EBGP redistribution of labeled VPNIPv4 routes. Inter-Provider Backbones Option C: PEs advertise labeled VPN-IPv4 routes to each other through Multi-hop MP-EBGP. This solution is also called Multi-hop EBGP redistribution of labeled VPN-IPv4 routes.
Inter-Provider Backbones Option A

As a basic BGP/MPLS IP VPN application in the inter-AS scenario, Option A does not need special configurations and MPLS need not run between ASBRs. In this mode, ASBRs of the two ASs are directly connected, and they act as the PEs in the ASs. Either of the ASBR PEs takes the peer ASBR as its CE and advertises IPv4 routes to the peer ASBR through EBGP. Figure 3-7 Networking diagram for ASBRs to manage VPN routes in inter-AS VPN Option A mode
VPN1 CE1 BGP/MPLS backbone AS: 100 ASBR1 MP-IBGP EBGP PE2 VPN LSP1 CE2 VPN2 LSP1 IP forwarding BGP/MPLS backbone AS: 200
VPN1 CE3
PE1
PE3 CE MP-IBGP ASBR2 PE4 CE4 VPN2
Issue 01 (2012-09-10)
13
3 Principles
In Figure 3-7, for ASBR1 in AS 100, ASBR2 is a CE. Similarly, for ASBR2, ASBR1 is a CE.
Inter-Provider Backbones Option B

In Option B, through MP-EBGP, two ASBRs receive the labeled VPN-IPv4 routes from the PEs in the ASs respectively and then exchange the routes. Figure 3-8 Networking diagram for ASBRs to manage VPN routes in inter-AS VPN Option B mode
VPN1 CE1 BGP/MPLS backbone AS: 100 BGP/MPLS backbone AS: 200 MP-EBGP ASBR1 PE2 VPN LSP1 LSP1 VPN LSP2 VPN LSP3 LSP2 ASBR2 PE4
VPN1 CE3 PE3
PE1
MP-IBGP
MP-IBGP
CE2 VPN2
CE4 VPN2
In inter-AS VPN Option B, ASBRs receive all inter-AS VPNv4 routes within the local AS and from the outside ASs and then advertise these VPN-IPv4 routes. In the basic MPLS VPN implementation, a PE stores only the VPN routes that match the VPN target of the local VPN instance. Thus, the VPN instance whose routes need to be advertised by the ASBR can be configured on the ASBR, but no interface is bound to VPN instances. If the ASBR is not configured with the related VPN instances, the following methods can be adopted: l The ASBR processes the labeled VPN-IPv4 routes specially and stores all the received VPN routes regardless of whether the local VPN instance that matches the routes exists. When using this method, note the following: ASBRs do not filter the VPN-IPv4 routes received from each other based on VPN targets. Therefore, the SPs in different ASs that exchange VPN-IPv4 routes must reach a trust agreement on route exchange. The VPN-IPv4 routes are exchanged only between VPN peers of private networks. A VPN cannot exchange VPN-IPv4 routes with public networks or MP-EBGP peers with whom there is no trust agreement. All the traffic is forwarded by the ASBR; thus, the traffic is easy to control, but the load on the ASBR increases.
3 Principles
Use BGP routing policies such as the policy filtering routes based on RTs to control the transmission of VPN-IPv4 routes.
Inter-Provider Backbones Option C

The preceding two modes can satisfy networking requirements of inter-AS VPN. ASBRs, however, need to maintain and distribute VPN-IPv4 routes. When each AS needs to exchange a large number of VPN routes, ASBRs may hinder network extension. The solution to the problem is that PEs directly exchange VPN-IPv4 routes with each other and ASBRs do not maintain or advertise VPN-IPv4 routes. l ASBRs advertise labeled IPv4 routes to PEs in their respective ASs through MP-IBGP, and advertise labeled IPv4 routes received on PEs in the local AS to the ASBR peers in other ASs. ASBRs in the transit AS also advertise labeled IPv4 routes. Therefore, a BGP LSP can be established between the ingress PE and egress PE. The PEs in different ASs establish multi-hop EBGP connections with each other and exchange VPN-IPv4 routes. The ASBRs do not store VPN-IPv4 routes or advertise VPN-IPv4 routes to each other.
l l
Figure 3-9 Networking diagram for PEs to manage VPN routes in inter-AS VPN Option C mode
VPN1 CE1
BGP/MPLS backbone AS: 100
BGP/MPLS backbone AS: 200
Multi-hop MP-EBGP PE1 MP-IBGP ASBR1 PE2 Multi-hop MP-EBGP VPN LSP CE2 VPN2 EBGP ASBR2 PE4 PE3 MP-IBGP
VPN1 CE3
CE4 VPN2
To improve the expansibility, you can specify a Route Reflector (RR) in each AS. The RR stores all VPN-IPv4 routes and exchanges VPN-IPv4 routes with the PEs in the AS. The RRs in two ASs establish MP-EBGP connections with each other and advertise VPN-IPv4 routes.
Issue 01 (2012-09-10)
15
3 Principles
Figure 3-10 Networking diagram of inter-provider backbones Option C with RRs VPN1 CE1 BGP/MPLS backbone AS: 100 PE1 MP-IBGP EBGP ASBR1 ASBR2 MP-IBGP BGP/MPLS backbone AS: 200 PE3
VPN1 CE3
PE2
RR-1
RR-2 PE4 CE4 VPN2
Multi-hop MP-EBGP VPN LSP CE2 VPN2 LSP
Comparison Between Three Options

Table 3-1 Comparison between three options Inter-AS VPN Option A Characteristic This solution is easy to implement because MPLS is not required between ASBRs and no special configuration is required. The expansibility, however, is poor because ASBRs need to manage all VPN routes and create VPN instances for each VPN. This may result in too many VPN-IPv4 routes on PEs. In addition, as common IP forwarding is performed between the ASBRs, each inter-AS VPN requires different interfaces, which can be sub-interfaces, physical interfaces, and bound logical interfaces. Therefore, this option poses high requirements for PEs. If a VPN spans multiple ASs, the intermediate ASs must support VPN services. This requires complex configurations and greatly affects the operation of the intermediate ASs. If the number of inter-AS VPNs is small, Option A can be considered. Option B Unlike Option A, Option B is not limited by the number of the links between ASBRs. VPN routing information is stored on and forwarded by ASBRs. When a great number of VPN routes exist, the overburdened ASBRs are likely to become bottlenecks. Therefore, in the MP-EBGP solution, the ASBRs that maintain VPN routing information do not perform IP forwarding on the public network.
Issue 01 (2012-09-10)
16
3 Principles
Inter-AS VPN Option C
Characteristic VPN routes are directly exchanged between the ingress PE and the egress PE. The routes need not be stored and forwarded by intermediate devices. The exchange of VPN routing information involves only PEs. Ps and ASBRs are responsible for packet forwarding only. The intermediate devices need to support only MPLS forwarding rather than the MPLS VPN services. In such a case, ASBRs are unlikely to become bottlenecks. Option C, therefore, is suitable for the VPN that spans multiple ASs. MPLS VPN load balancing is easy to carry out in Option C. The disadvantage lies in the high-cost management of an end-to-end connection between PEs.
3.3 Carrier's Carrier

Background
A customer of an SP providing the BGP/MPLS IP VPN service may also be an SP. In this case, the SP providing the BGP/MPLS IP VPN service is called the provider carrier or the first carrier and the customer is called the customer carrier or the second carrier, as shown in Figure 3-11. This networking model is called carrier's carrier. In this model, the customer carrier is a VPN user of the provider carrier. Figure 3-11 Networking of carrier's carrier
Provider Carrier Customer Carrier Customer Carrier
Customer
Customer
Customer
Customer
Related Concepts
l Internal routes and external routes To ensure good expansibility, the customer carrier uses an operation mode similar to that of a stub VPN. That is, the provider carrier CE advertises only internal routes, instead of
3 Principles
the internal and external routes of the customer carrier to the provider carrier PE. In this section, the internal and external routes of the customer carrier are called internal and external routes for short. The differences between internal and external routes are as follows: The routes to the backbone network of the customer carrier are called internal routes. The routes to VPNs of the customer carrier are called external routes. Provider carrier PEs exchange internal routes using BGP. The external routes are exchanged using BGP between customer carrier PEs. The external routes are not advertised to provider carrier PEs. The VPN-IPv4 routes of the customer carrier are regarded as external routes. The provider 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 provider carrier network. The customer carrier network has to maintain both internal and external routes.
NOTE
A provider carrier CE is a device through which the customer carrier network accesses the provider carrier network. A user CE is a device through which a user accesses the customer carrier network.
Classification of carrier scenarios Compared with a basic BGP/MPLS IP VPN, the access of provider carrier CEs to provider carrier PEs is the key to the carrier's carrier model. A customer carrier can be a common SP or a BGP/MPLS IP VPN SP. If a customer carrier is a common SP, MPLS does not need to be configured on customer carrier PEs. Customer carrier PEs communicate with provider carrier PEs using an IGP. Customer carrier PEs exchange external routes with each other over BGP sessions, as shown in Figure 3-12. Figure 3-12 Customer carrier serving as a common SP
Second Carrier ASBR1 IGP or BGP CE1 PE1 MP-IBGP BGP First Carrier PE2 CE2 IGP or BGP Second Carrier ASBR2
IGP & LDP or labeled BGP
IGP & LDP or labeled BGP
Issue 01 (2012-09-10)
18
3 Principles
Table 3-2 Comparison between networking modes for customer carriers serving as common SPs and those serving as BGP/MPLS IP VPN SPs Location of Provider Carrier's Backbone Network and Customer Carrier Network In the same AS Characteristics
Provider carrier PEs and CEs exchange routes using the IGP and LDP. Provider carrier CEs exchange external routes between each other using BGP. Provider carrier PEs and CEs exchange labeled VPNIPv4 routes using EBGP. Provider carrier CEs exchange external routes between each other using BGP.
In different ASs
If a customer carrier is a BGP/MPLS IP VPN SP, customer carrier PEs must be configured with MPLS. Customer carrier PEs communicate with provider carrier CEs using the IGP and LDP. Customer carrier PEs exchange external routes between each other using MP-BGP, as shown in Figure 3-13. Figure 3-13 Customer carrier serving as a BGP/MPLS IP VPN SP
Second Carrier PE3 IGP & LDP CE1 PE1 First Carrier PE2 CE2 Second Carrier PE4
IGP & LDP MP-IBGP or labeled BGP MP-BGP
IGP & LDP IGP & LDP or labeled BGP
Table 3-3 Comparison between networking modes for customer carriers serving as BGP/MPLS IP VPN SPs Location of Provider Carrier's Backbone Network and Customer Carrier Network In the same AS Characteristics
Provider carrier PEs and CEs exchange routes and labels using the IGP and LDP. When entering the customer carrier network, VPN packets must be double-tagged. Provider carrier PEs and CEs exchange routes and labels using MP-EBGP. When entering the customer carrier network, VPN packets must be triple-tagged.
19
In different ASs
Issue 01 (2012-09-10)
3 Principles
The following describes route exchanging and packet forwarding based on customer carrier roles and location of the provider carrier's backbone network and customer carrier network. l l l l l l l Route Exchanging in the Scenario in Which the Customer Carrier Is a Common SP (Same AS) Route Exchanging in the Scenario in Which the Customer Carrier Is a Common SP (Different ASs) Packet Forwarding in the Scenario in Which the Customer Carrier Is a Common SP Route Exchanging in the Scenario in Which the Customer Carrier Is a BGP/MPLS IP VPN SP (Same AS) Packet Forwarding in the Scenario in Which the Customer Carrier Is a BGP/MPLS IP VPN SP (Same AS) Route Exchanging in the Scenario in Which the Customer Carrier Is a BGP/MPLS IP VPN SP (Different ASs) Packet Forwarding in the Scenario in Which the Customer Carrier Is a BGP/MPLS IP VPN SP (Different ASs)
Route Exchanging in the Scenario in Which the Customer Carrier Is a Common SP (Same AS)
Figure 3-14 shows route exchanging in the scenario in which a customer carrier is a common SP and the provider carrier's backbone network and the customer carrier network are in the same AS. D represents the destination address, N the next hop, and L the label. Figure 3-14 Route exchanging in the scenario in which the customer carrier is a common SP (same AS)
IGP & LDP IGP D: CE2 PE1 D: PE2 L: L' IGP D: ASBR2 PE2 IF0 IF1 IGP & LDP D:CE2 N:IF0 L: L0
ASBR1
Second Carrier AS:100
CE1
First Carrier AS:100 MP-IBGP D:CE2 N:PE2 L: L1
CE2
Second Carrier AS:100 IGP
ASBR2
IBGP D:10.1.1.1/32 N:CE2
IGP & LDP D:CE2 N:PE1 L: L2
D:10.1.1.1/32 N:CE4 CE4 10.1.1.1/32
IBGP D: 10.1.1.1/32 N:CE2
The following uses the advertisement of an Internet route destined for 10.1.1.1/32 from CE4 to ASBR1 as an example to show Internet route exchange inside the customer carrier network.
3 Principles
1. 2.
CE2 advertises an internal route (use the route destined for CE2 as an example) to PE2 using the IGP and also assigns label L0 to the route using LDP. PE2 assigns label L1 to the route using MP-IBGP and advertises the route to PE1. Previously, PE2 has advertised its routes to PE1 using the IGP running on the provider carrier's backbone network and has assigned label L' to the routes destined for itself. In this manner, a public network LSP is established between PE2 and PE1. PE1 assigns label L2 to the route using LDP and advertises the label and route to CE1 using the IGP running between PE1 and CE1. CE1 advertises the route to ASBR1 using the IGP running on the customer carrier network. After the routes of the VPN where CE1 and ASBR1 reside are advertised to CE2, an IBGP connection is set up between CE1 and CE2. ASBR2 advertises the external route destined for 10.1.1.1/32 and learned from CE4 to CE2 using the IGP running in the AS. Previously, ASBR2 has set the next hop of this route as CE4. CE2 imports this external route to BGP and advertises this route to CE1 using IBGP. Upon receipt, CE1 sets the next hop of this route as CE2, and advertises the route to ASBR1 using the IGP running on the customer carrier network. Here, the customer carrier networks are in the same AS, and CE1 needs to be configured as an RP between CE2 and ASBR1.
3. 4. 5. 6.
7. 8.
The process of advertising the routes of the VPN where ASBR1 and CE1 reside to CE2 and ASBR2 is similar to this process and therefore is not described.
Route Exchanging in the Scenario in Which the Customer Carrier Is a Common SP (Different ASs)
Figure 3-15 shows route exchanging in the scenario in which the customer carrier is a common SP and the customer carrier network and the provider carrier's backbone network are in different ASs. D represents the destination address of a route, N the next hop, and L the label. Figure 3-15 Route exchanging in the scenario in which the customer carrier is a common SP (different ASs)
IGP & LDP IGP D: CE1 PE1 D: PE2 L: L' IGP D: ASBR2 PE2 CE2
ASBR1
CE1
First Carrier AS:100 MP-IBGP D:CE2 N:PE2 L: L1
IF0
ASBR2
IF1 MP-EBGP D:CE2 N:IF0 L: L0
IGP D:10.1.1.1/32 N:CE1
MP-EBGP D:CE2 N:PE1 L: L2
IGP D:10.1.1.1/32 N:CE4 CE4 10.1.1.1/32
EBGP D: 10.1.1.1/32 N:CE2
Issue 01 (2012-09-10)
21
3 Principles
The following uses the advertisement of an Internet route destined for 10.1.1.1/32 from CE4 to ASBR1 as an example to show Internet route exchange inside the customer carrier network. 1. 2. CE2 advertises a route destined for itself to PE2 using EBGP running between CE2 and PE2. Meanwhile, CE2 assigns label L0 to this route. PE2 assigns label L1 to the route using MP-IBGP and advertises the route to PE1. Previously, PE2 has advertised its routes to PE1 using the IGP run on the provider carrier's backbone network and has assigned label L' to the routes destined for itself. A public network LSP has been established between PE2 and PE1. 3. 4. 5. 6. 7. 8. PE1 assigns label L2 to the route using MP-IBGP and advertises the route to CE1. CE1 advertises the route to ASBR1 using the IGP running on the customer carrier network. After the routes of CE1 are advertised to CE2, an EBGP connection is established between CE1 and CE2. ASBR2 advertises the external route destined for 10.1.1.1/32 to CE4 using the IGP running on the customer carrier network. CE2 imports the route to BGP and advertises this route to CE1 using EBGP. Upon receipt, CE1 sets the next hop of this route as CE2, and advertises the route to ASBR1 using the IGP running on the customer carrier network.
The process of advertising the routes of the AS where ASBR1 and CE1 reside to CE2 and ASBR2 is similar and therefore is not described.
Packet Forwarding in the Scenario in Which the Customer Carrier Is a Common SP

If the customer is a common SP, packet forwarding is the same no matter whether the provider carrier's backbone network and customer carrier network is in the same AS or different ASs. Figure 3-16 shows user packet transmission over carrier networks if the customer carrier is a common SP. L represents the label assigned by the provider carrier network using MP-BGP, and L' represents the public network label used on the provider carrier network. Figure 3-16 Packet forwarding in the scenario in which the customer carrier is a common SP
ASBR1 Second CE1 Carrier PE1 First Carrier PE2 CE2 Second Carrier ASBR2
IP packet
IP packet L2
IP packet L1 L'
IP packet IP packet L0
ASBR3
10.1.1.1/32
The following uses forwarding of a packet destined for 10.1.1.1/32 from ASBR1 to CE4 as an example to describe packet transmission over carrier networks: 1.
Issue 01 (2012-09-10)
ASBR1 transparently transmits the packet to CE1 based on IP forwarding.

3 Principles
2. 3. 4. 5. 6.
CE1 adds label L2 to the packet and forwards this packet to PE1. PE1 replaces label L2 with label L1 and adds label L' to the packet. PE1 then forwards the packet to PE2 over the public network LSP. PE2 replaces L1 with L0 and forwards the packet to CE2. CE2 removes label L' and forwards the packet to ASBR2 based on IP forwarding. ASBR2 advertises the packet to CE4.
Route Exchanging in the Scenario in Which the Customer Carrier Is a BGP/MPLS IP VPN SP (Same AS)
Figure 3-17 shows route exchanging in the scenario in which the customer carrier is a BGP/ MPLS IP VPN SP and the provider carrier's backbone network are in the same AS as the customer carrier network. D represents the destination address of a route, N the next hop, and L the label. Figure 3-17 Route exchanging in the scenario in which the customer carrier is a BGP/MPLS IP VPN SP (same AS)
IGP & LDP D: CE1 L: L''2 PE1 IGP & LDP D: PE2 L: L' IGP & LDP D: PE4 L: L''1
PE3
CE1
First Carrier AS:100 MP-IBGP D: PE4 N: PE2 L: L2
PE2
CE2
PE4
IGP D: PE4
IGP & LDP D: PE4 N: PE1 L: L3
IGP & LDP D: PE4 N: CE2 L: L1 CE4
MP-IBGP D: 10.1.1.1/32 L: I-L
10.1.1.1/32
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 customer carrier network. 1. PE4 advertises a route destined for itself to CE2 using the IGP running on the customer carrier network. Meanwhile, PE4 assigns label L''1 to the IGP next hop and establishes a public network LSP with CE2. CE2 advertises the route to PE2 using the IGP running between CE2 and PE2. Meanwhile, CE2 assigns label L1 to the route using LDP. PE2 assigns label L2 to the route and advertises the route to PE1 using MP-IBGP. Previously, PE2 has advertised its routes to PE1 using the IGP running on the provider 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.
2. 3.
Issue 01 (2012-09-10)
3 Principles
4. 5.
PE1 assigns label L3 to the route using LDP running between PE1 and CE1 and advertises the route to CE1. CE1 advertises the route to PE3 using the IGP running on the customer carrier network. Previously, CE1 has advertised its routes to PE1 using the IGP running on the provider carrier's backbone network and assigned label L''2 to the routes destined for itself. A public network LSP has been established between CE1 and PE3.
6. 7.
After the routes destined for PE3 are advertised to PE4, an MP-IBGP connection is established between PE3 and PE4. 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.
Packet Forwarding in the Scenario in Which the Customer Carrier Is a BGP/MPLS IP VPN SP (Same AS)
Figure 3-18 shows packet forwarding in the scenario in which the customer carrier is a BGP/ MPLS IP VPN SP and the provider carrier's backbone network are in the same AS as the customer carrier network. I-L represents the VPN label assigned using MP-BGP. L' indicates the public network label used on the provider carrier network. L''1 and L''2 stand for public network labels used on the customer carrier network. L1, L2, and L3 represent labels assigned to packets destined for PE4. Figure 3-18 Packet forwarding in the scenario in which the customer carrier is a BGP/MPLS IP VPN SP (same AS)
PE3 Second Carrier
CE1
PE1
First Carrier
PE2
CE2
Second Carrier
PE4
CE4 IP packet I-L L'' 2 IP packet I-L L3 IP packet I-L L2 L' IP packet IP packet I-L I-L IP packet L1 L'' 1 10.1.1.1/32
The following uses forwarding of a VPN packet destined for 10.1.1.1/32 from PE3 to CE4 as an example to describe packet transmission 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 customer carrier network. Before the packet arrives at CE1, the penultimate LSR removes the outer public network label of the packet. 2.
Issue 01 (2012-09-10)
CE1 adds label L3 to the packet and forwards this packet to PE1.
3 Principles
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. Label L' is removed on the penultimate LSR of PE2. PE2 replaces label L2 with label L1 and forwards the packet to CE2. CE2 removes label L1, adds label L''1, and transparently forwards the packet to PE4 over the public network LSP on the customer carrier network. Before the packet arrives at PE4, the penultimate LSR removes label L''1. PE4 removes label I-L and forwards the packet to CE4 based on label I-L.
4. 5.
6.
Route Exchanging in the Scenario in Which the Customer Carrier Is a BGP/MPLS IP VPN SP (Different ASs)
Figure 3-19 shows route exchanging in the scenario in which the customer carrier is a BGP/ MPLS IP VPN SP and the customer carrier network and the provider carrier's backbone network are in different ASs. D represents the destination address of a route, N the next hop, and L the label. Figure 3-19 Route exchanging in the scenario in which the customer carrier is a BGP/MPLS IP VPN SP (different ASs)
IGP & LDP D: CE1 L: L''2 IGP & LDP D: PE2 L: L' IGP & LDP D: PE4 L: L''1
PE3
Second Carrier AS:100 MP-IBGP D : PE4 N : CE1 L : L4
CE1
PE1
First Carrier AS:200 MP-IBGP D : PE4 N :PE2 L : L2
PE2
CE2
PE4
MP-EBGP D : PE4 N : PE1 L : L3
MP-EBGP D : PE4 N : CE2 L : L1
CE4 10.1.1.1/32
MP-EBGP D: 10.1.1.1/32 L : I-L
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 customer carrier network. 1. PE4 advertises a route destined for itself to CE2 using the IGP running on the customer carrier network. Meanwhile, PE4 assigns label L''1 to the IGP next hop and establishes a public network LSP with CE2. CE2 assigns label L1 to the route and advertises the route to PE2 using MP-EBGP. PE2 assigns label L2 to the route and advertises the route to PE1 using MP-IBGP.
2. 3.
Issue 01 (2012-09-10)
3 Principles
Previously, PE2 has advertised its routes to PE1 using the IGP running on the provider 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. 5. PE1 assigns label L3 to the route and advertises the route to CE1 using MP-EBGP. CE1 assigns label L4 to the route and advertises the route to PE3 using MP-IBGP. Previously, CE1 has advertised its routes to PE1 using the IGP running on the customer carrier's backbone network and assigned label L' to the routes destined for itself. A public network LSP has been established between CE1 and PE3. 6. A BGP LSP is established between CE2 and PE3. After the routes of PE3 are advertised to PE4, an MP-EBGP 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-EBGP.
The advertisement of a VPN route from PE3 to PE4 is similar to that from PE4 to PE3 and therefore is not described here.
Packet Forwarding in the Scenario in Which the Customer Carrier Is a BGP/MPLS IP VPN SP (Different ASs)
Figure 3-20 shows packet forwarding in the scenario in which the customer carrier is a BGP/ MPLS IP VPN SP and the customer carrier network and the provider carrier's backbone network are in different ASs. I-L represents the VPN label assigned using MP-BGP. L' indicates the public network label used on the provider carrier network. L''1 and L''2 stand for public network labels used on the customer carrier network. L1, L2, L3, and L4 represent labels assigned to packets destined for PE4. Figure 3-20 Packet forwarding in the scenario in which the customer carrier is a BGP/MPLS IP VPN SP (different ASs)
PE3
Second Carrier
CE1
PE1
First Carrier
PE2
CE2
Second Carrier
PE4 CE4
IP packet I-L L4 L'' 2
IP packet I-L L3
IP packet I-L L2 L'
IP packet IP packet I-L I-L IP packet L1 L'' 1 10.1.1.1/32
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 customer carrier network.
Issue 01 (2012-09-10)
3 Principles
Before the packet arrives at CE1, the penultimate LSR removes the outer public network label of the packet. 2. 3. CE1 replaces L4 with L3 and forwards the packet to PE1. 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'. PE2 replaces label L2 with label L1 and forwards the packet to CE2. CE2 removes label L1, adds label L''1, and transparently forwards the packet to PE4 over the public network LSP on the customer 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.
4. 5.
Benefits
The carrier's carrier model has the following advantages: l l l Part of the configuration, management, and maintenance work used to be carried out by the customer carrier can be undertaken by the provider carrier. The customer carrier can flexibly plan addresses, as its addresses are independent of those of the customers and the provider carrier. The provider carrier can provide VPN services for multiple customer carriers over a backbone network, and can provide Internet services at the same time. This increases the profits of the provider carrier. The provider carrier manages and maintains VPN services of each customer carrier in the same manner instead of maintaining individual backbone networks for customer carriers. This simplifies the operation of the provider 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.
3.4 Multi-role Host

Background
On a BGP/MPLS IP VPN, the VPN attributes of the packets received by PEs from CEs are determined by the VPN instances bound to the inbound interfaces on the PEs. Packets forwarded by the same PE inbound interface belong to the same VPN. In real-world situations, a server or a terminal, however, is generally required to access multiple VPNs. This server or a terminal is called a multi-role host. For example, a server for a financial department in VPN1 and a server for an accounting department in VPN2 need to communicate. With L2TP, a PE can serve as a multi-role host to dynamically provide services for users to access different VPNs based on user names and passwords. This method, however, has the following disadvantages:
3 Principles
In addition to the L2TP header, a PPP frame must also be encapsulated with UDP and IP headers for transmission over an L2TP tunnel. High costs lead to low transmission efficiency. LCP and NCP negotiation is time-sensitive, and PPP session timeout may occur. L2TP does not apply to the scenario in which the physical positions and roles of multi-role hosts are fixed.
l l
As shown in Figure 3-21, the VPN to which the multi-role host (PC) belongs is VPN1. If VPN1 and VPN2 on PE1 do not import routes from each other, the PC can access only VPN1. The data stream from the PC to VPN2 can be transmitted only based on the VPN1 routing table of PE1. If the destination address of a packet does not exist in the VPN1 routing table, PE1 drops the packet. Figure 3-21 Implementation of a multi-role host
VPN1 PC Static-Route Backbone CE1 PE1 PE3 PE2 CE2
VPN1
Policy-Based Routing CE3
VPN2
Policy-based routing (PBR) can be configured on PEs to allow packets from a CE to reach multiple VPNs. In a multi-role host model, only the multi-role host can access multiple VPNs; the non-multi-role hosts can access only the VPN to which the hosts belong.
Related Concepts
l Policy-based routing PBR supports routing based on source IP addresses and packet length. After a packet arrives, the system forwards it according to PBR first. If PBR is not configured or if PBR is configured but no matching entry exists, the system forwards the packet based on the Forward Information Base (FIB) table.
Implementation
A multi-role host implements the following functions: l Ensures that the data stream of the multi-role host reaches the destination VPN network. As shown in Figure 3-21, to ensure that the data stream of the PC can reach VPN2, configure PBR on the PE1 interface that connects to CE1. After the configuration is complete, if PE1 cannot find the destination address of a packet from CE1 in the routing table of VPN1, it searches the routing table of VPN2 for the route and then forwards the packet. PBR directs data streams to different VPNs generally based on IP addresses.
3 Principles
Ensures that the data stream from the destination VPN network reaches the multi-role host. As shown in Figure 3-21, to ensure that the data stream returned from the destination VPN network reaches the PC, PE1 must be able to search for the routes in the VPN1 routing table for the data stream from VPN2. This is implemented by adding a static route bound for the PC to the VPN2 routing table on PE1. The outbound interface of the static route is the PE1 interface that connects to CE1.
In brief, the functions of a multi-role host are implemented mainly on the PE accessed by the CE that the multi-role host accesses: l l PBR configured on a PE enables data streams from the same VPN to be transmitted based on the routing tables of different VPNs at the same time. Static routes added to the routing table of the destination VPN on the PE use interfaces connected to the multi-role host as their outbound interfaces.
NOTE
Note that each IP address of the VPNs that the multi-role host can access is unique.
Benefits
The multi-role host solution enables a specified server or terminal to access multiple VPNs, increasing networking flexibility.
3.5 HoVPN
Hierarchical Model and Plane Model
On a BGP/MPLS IP VPN, as the key devices, PEs perform the following functions: l l Ensure the access for users, and thus require a great number of interfaces. Manage and advertise VPN routes, and process user packets. Thus, the PEs require largecapacity memory and high forwarding capabilities.
Currently, the hierarchical architecture is adopted by most networking schemes. For example, the typical architecture of a MAN consists of three layers: the core layer, convergence layer, and access layer. From the core layer to the access layer, the performance requirements for devices decline, but the network scale enlarges. A BGP/MPLS IP VPN uses a plane model, which has the same performance requirement for all the PEs. If certain PEs have problems in performance or scalability, the whole network is affected. The BGP/MPLS IP VPN plane model is not the same as the typical hierarchical model. In the plane model, deployment of PEs is hindered by poor scalability on each layer. Therefore, the plane model is unfavorable for VPN deployment on a large scale.
HoVPN
To improve scalability, a BGP/MPLS IP VPN must use the hierarchical model instead of the plane model. In a Hierarchy of VPN (HoVPN), the functions of a PE are distributed among multiple PEs. Playing different roles, these PEs form a hierarchical architecture and fulfill the functions of a centralized PE. For this reason, the solution is also called a Hierarchy of PE (HoPE).
3 Principles
On an HoVPN, the routing and forwarding capabilities of the devices of higher levels must be stronger than those of lower levels.
Advantages of HoVPN
The HoVPN model has the following advantages: l A BGP/MPLS IP VPN can be divided into different hierarchies. If the performance of an underlayer PE (UPE) does not satisfy the requirements, a superstratum PE (SPE) can be added, and the UPE accesses the new SPE. When the service access capabilities of the SPE is insufficient, UPEs can be added to the SPE. Label forwarding is performed between UPEs and SPEs. Thus, a UPE and an SPE need be connected through only a pair of interfaces or sub-interfaces. Thus, interface resources are saved. If UPEs and SPEs are separated by an IP or MPLS network, GRE or LSP tunnels are set up to connect the UPEs and SPEs. A layered MPLS VPN features excellent scalability. The UPEs need maintain only the local VPN routes. All the remote routes are represented by a default or aggregated route. This lightens the burden on the UPEs. SPEs and UPEs exchange routes and advertise labels through the Multi-protocol Extensions for Border Gateway Protocol (MP-BGP). Each UPE sets up only one MP-BGP peer. Thus, the protocol cost is low and the configuration load is little.
l l l
Architecture of an HoVPN
Figure 3-22 Architecture of an HoVPN
VPN1 site1
CE
VPN2 site3 PE
VPN2 site1
CE CE CE UPE SPE HoPE UPE VPN backbone PE CE
VPN1 site2
VPN1 site3
VPN2 site2
CE
As shown in Figure 3-22, the devices that are directly connected to user devices are called underlayer PEs or UPEs; on the internal network, the device that is connected to UPEs is called a superstratum PE or an SPE.
3 Principles
The relationships between the UPEs and the SPE are as follows: l The UPEs provide the access service for users. The UPEs maintain the routes of the directly connected VPN sites. The UPEs do not maintain the routes of the remote VPN sites, or only maintain their aggregation routes. The UPEs assign inner labels to the routes of the directly connected sites, and advertise the labels with the VPN routes to the SPE through MP-BGP. The SPE mainly manages and advertises VPN routes. The SPE maintains all the routes of the VPN sites connected through the UPEs, including the routes of the local and the remote sites. Instead of advertising routes of the remote sites to the UPEs, the SPE advertises the default routes of VPN instances that carry labels to the UPEs. Label forwarding is adopted between the UPEs and the SPE. Thus, only one interface of the SPE is required to connect to a UPE. The SPE does not need to provide many interfaces for access users. The interface that connects the UPEs and the SPE can be a physical interface, a sub-interface such as VLAN and Permanent Virtual Circuit (PVC), or a tunnel interface such as GRE and LSP. If a tunnel interface is used, and an IP network or an MPLS network resides between the SPE and the UPEs, the SPE and the UPEs can communicate. Labeled packets are transmitted through the tunnel. If the tunnel is a GRE tunnel, it must support the MPLS encapsulation.
Different roles of an SPE and a UPE result in different requirements, which are as follows: l l The SPE requires a large-capacity routing table, high forwarding performance, and less interface resources. The UPE requires a small-capacity routing table, low forwarding performance, and high access capabilities.
Note that the SPE and UPE are relative concepts. In an HoVPN, the superstratum PE is the SPE of the underlayer, and the underlayer PE is the UPE of the superstratum. An HoPE can coexist with common PEs in an MPLS network.
SPE-UPE
If an SPE and a UPE belong to the same AS, MP-BGP running between the SPE and the UPE is MP-IBGP. If they belong to different ASs, MP-BGP running between them is MP-EBGP. When MP-IBGP is used, to advertise routes between the IBGP peers, the SPE can function as the RR of multiple UPEs. To reduce the number of routes on the UPEs, do not use the SPE to function as a RR for other PEs.
Embedding and Extension of an HoVPN

An HoVPN supports the embedding of HoPEs. l l l An HoPE can function as a UPE, and compose a new HoPE with an SPE. An HoPE can function as an SPE, and compose a new HoPE with multiple UPEs. An HoPE can be embedded recursively in the preceding two modes.
The embedding of an HoPE can infinitely extend a VPN in theory.
Issue 01 (2012-09-10)
31
3 Principles
Figure 3-23 Embedding of an HoVPN
SPE
MPE
UPE
UPE
UPE
CE
CE
CE
CE
Figure 3-23 shows a three-layer HoPE, and the PE in the middle is called the middle-level PE (MPE). MP-BGP runs between the SPE and the MPE, and between the MPE and the UPEs.
NOTE
The MPE does not actually exist in an HoVPN model. The concept is introduced just for the convenience of description.
MP-BGP advertises all the VPN routes of the UPEs to the SPE, but advertises only the default routes of the VPN instances of the SPE to the UPEs. The SPE maintains the routes of all VPN sites that the PEs access, whereas the UPE maintains only the VPN routes of the directly connected VPN sites. The numbers of routes maintained by the SPE, MPE, and UPE are in descending order.
3.6 Interconnection Between VPNs and the Internet

Generally, users within a VPN can communicate only with each other instead of with Internet users. In addition, the VPN users cannot access the Internet. Sites within the VPN, however, may have the requirements to access the Internet. To implement the interconnection between the VPN and the Internet, the following conditions must be satisfied: l l l The devices that need to access the Internet have the route to the Internet. The Internet has the route to the devices. Similar to the interconnection between non-VPN users and the Internet, security mechanisms such as firewalls must be used.
The interconnection between the VPN and the Internet can be implemented in the following manners:
3 Principles
The PEs of the backbone network differentiate the data streams of the VPN from those of the Internet, and then forward the data to the Internet and to the VPN respectively. At the same time, the PEs provide the firewall function between the VPN and the Internet. The interconnection is carried out on the Internet gateways, which are carrier devices accessing the Internet. The Internet gateways must support the VPN route management. For example, the Internet gateways can be PEs that do not provide the access service to VPN users. The interconnection is realized on a CE. The CEs of the private network differentiate the data streams of the VPN from those of the Internet, and then guide the data streams into two areas: One area accesses the VPN through a PE; the other area accesses the Internet through an ISP router that does not belong to the VPN. At the same time, the CEs provide the firewall function.
Interconnection Implemented on a PE
In the VPN backbone network: l l l The Internet routes exist in the public routing table of the PE. The routing information about users exists in the VPN routing table of the PE, and does not exist in the public routing table. The routes passing through the PE interfaces and CE interfaces do not exist in the public routing table.
All the preceding conditions set the obstacle for the interconnection between VPNs and the Internet. These conditions, however, are also the keys for the breakthrough. Figure 3-24 Interconnection implemented on a PE
Internet Internet Gateway VPN backbone VPN site CE PE
To implement the interconnection between a VPN and the Internet on a PE, generally, default static routes are used. l l l The PE sends a default route destined for the Internet to the CE. A default route destined for the Internet gateway is added to the VPN routing table. To ensure that the Internet has a route to the VPN, a static route with the destination address as the CE and the next hop as the PE interface that connects the CE needs to be added to
Issue 01 (2012-09-10)
3 Principles
the public routing table. Then the route is advertised to the Internet. This is implemented by the addition of a static route to the public routing table of the PE. The destination address of the route is the address of the VPN user. The outgoing interface of the route is the PE interface that connects the CE. The route is advertised to the Internet through an IGP.
Interconnection Implemented on an Internet Gateway

To implement the interconnection between VPNs and the Internet, you need to configure each VPN with an instance on the Internet gateway. Each VPN uses one interface to access the Internet, and the interface is bound to the VPN instance. Figure 3-25 Interconnection implemented on an Internet gateway
Internet VPN-instance Internet Gateway VPN backbone VPN site CE PE
Interconnection Implemented on a CE
The interconnection between a VPN and the Internet can be implemented on a CE in the following manners: l One is that the CE directly accesses the Internet, as shown in Figure 3-26. Direct access of the CE to the Internet is divided into the following modes: The central CE of the VPN user accesses the Internet. After a default route to the Internet is configured on the central CE, the route is advertised to other nodes through the VPN backbone network. The firewalls are deployed only on the central CE. In this mode, all the traffic to the Internet passes through the VPN backbone network except the traffic of the central CE. All the CEs access the Internet. That is, each CE is configured with the default route to the Internet. Each CE is configured with the firewall functions. All the traffic to the Internet does not need to pass through the VPN backbone network.
Issue 01 (2012-09-10)
34
3 Principles
Figure 3-26 Direct access of the CE to the Internet
Internet
VPN backbone VPN site
CE
PE
The other is that a single CE interface or sub-interface accesses the PE. The PE injects the routes of the CE into the public routing table and advertises the routes to the Internet. Then the PE advertises the default route or the Internet routes to the CE. The interface that accesses the PE does not belong to any VPN, and is not associated with any VPN instance. That is, the user can act as a VPN user and a non-VPN user to accesses the PE, as shown in Figure 3-27. It is recommended to set up a tunnel between the VPN backbone device that accesses the Internet and the PE that the CE accesses. Thus, the Internet routes are transmitted through the tunnel, and Ps do not accept the Internet routes. Figure 3-27 A single interface accessing the PE
Internet
CE VPN site
VPN-instance PE
VPN backbone
Comparison Between the Three Schemes

The interconnection implemented on a CE is simple to deploy. Public routes and private routes are separated; thus, this scheme features high security and reliability. The disadvantage is that the scheme consumes the resources of interfaces and each VPN needs to use a public network address.
3 Principles
The interconnection implemented on a PE can save resources of interfaces and different VPNs can share one public IP address. The disadvantages are that the configurations on the PE are complex and the security cannot be guaranteed. l l If a CE is connected to the PE to access the Internet through logical links, a great amount of attack traffic occupies the links; thus, the legal VPN packets cannot be transmitted. The PE is likely to be attacked by the Denial of Service (DoS) of the Internet regardless of whether the CE accesses the PE through logical links or physical links.
The interconnection implemented on an Internet gateway features higher security than that on a PE. An Internet gateway, however, must be configured with multiple VPN instances, which may overburden the gateway. In addition, an Internet gateway has multiple interfaces connected to the Internet with each interface having a public network IP address. Each VPN uses an interface on the gateway and one public network IP address. Table 3-4 Comparison between three schemes of interconnection between VPNs and the Internet Scheme On a CE Security High Used Interface The CE must reserve an interface for each VPN to access the Internet. This consumes the interface resources of the CE. The PE reserves only one interface for both the VPN access and the Internet access. This scheme saves the interface resources. The Internet gateway must reserve an interface for each VPN to access the Internet. This consumes the interface resources of the gateway. Used Public IP Address Each VPN uses a public IP address. Easiness of Deployment Easy
On a PE
Low
Multiple VPNs on the PE share a public IP address.
Difficult
On an Internet gateway
High
Each VPN uses a public IP address.
Difficult
3.7 VPN FRR

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.
3 Principles
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 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, however, cannot implement fast switching if faults occur on the ingress or egress. If a fault occurs on the ingress or egress, services can only be restored through end-toend 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 LSP hops on the bearer network. The more VPN routes, the longer the service convergence time, and the more traffic is lost. 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-toend 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
Figure 3-28 VPN FRR networking
PE2 Backbone VPN Site CE1 PE1 Link A Link B VPN Site CE2
PE3
As shown in Figure 3-28, 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. When a fault occurs on PE2, PE1 detects the fault of 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 end-to-end convergence. Before PE1 re-delivers the forwarding entry for the route advertised by PE3, CE1 cannot reach CE2 for a certain period, because PE2, an end point of the LSP, is Down. As a result, end-to-end services are interrupted. VPN FRR is an improvement of the traditional reliability technology. With VPN FRR, PE1 can select the appropriate VPNv4 routes based on the matching rules. For these routes, in addition to information about the preferred routes advertised by PE2, information about the second-best route advertised by PE3 is also filled in the forwarding entry.
3 Principles
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 bidirectional forwarding detection (BFD) and MPLS OAM, 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-best 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.
Other Functions
VPN FRR is a fast switching technique based on inner labels. The outer tunnels can be LDP LSPs, RSVP-TE tunnels, or traditional tunnels used by L3VPN (such as GRE 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 where a CE is dual-homed to two PEs, after a PE fails, VPN FRR ensures that the VPN services from the CE to the PE 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.
3.8 IP+VPN FRR

IP+VPN FRR ensures high reliability of traffic transmission between the CE and PEs. If a link between the CE and a PE fails, the PE can use IP+VPN FRR to switch traffic bound for the CE to the other PE for transmission. In a scenario where a CE is dual-homed to two PEs, if a link that can be divided into sub-links, for example, a GE link, is deployed between the two PEs, sub-interfaces can be configured on the GE interface on each PE and bound to different VPN instances. After IP FRR is enabled on the two PEs, the member links of the GE link will provide protection for the traffic between the CE and PEs. Configuration and management in this IP FRR protection solution, however, are not easy tasks. In addition, this solution is inapplicable to a scenario where a link that cannot be divided into sub-links, for example, a POS link, is deployed between the two PEs. IP+VPN FRR can be deployed on PEs to address these problems. After IP+VPN FRR is deployed, a PE stores a CE-bound VPNv4 cross route sent from its peer as a backup route for its local VPNv4 route, and generates an FRR entry. If the local VPNv4 route to the CE becomes unreachable, the PE will immediately select the backup route to transmit traffic to the CE. This ensures high reliability of traffic transmission between the PE and CE, bringing benefits of fast link switching, link multiplexing, and a reduction in configuration and management workload. IP+VPN FRR includes IPv4+VPN FRR and IPv6+VPN FRR. The working principle and deployment method of IPv6+VPN FRR are similar to that of IPv4+VPN FRR.
3 Principles
3.9 VPN GR
Graceful restart (GR) is one of the high availability (HA) technologies, which comprise a series of comprehensive technologies such as fault-tolerant redundancy, link protection, faulty node recovery, and traffic engineering. As a fault-tolerant redundancy technology, GR ensures normal forwarding of data during the restart of routing protocols to prevent interruption of key services. Currently, GR has been widely applied to the master/slave switchover and system upgrade. GR is usually used when the active route processor (RP) fails because of a software or hardware error, or used by an administrator to perform the master/slave switchover.
Prerequisite for GR Implementation

On a traditional routing 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 of GR
The concepts related to GR are as follows: l l l l GR restarter: indicates a device that performs master/slave switchover triggered by the administrator or a failure. A GR restarter must support GR. GR helper: indicates the 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 can 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.
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 the master/slave switchover is performed on the device transmitting VPN services. The purposes of implementing VPN GR are as follows: l l l l
Issue 01 (2012-09-10)
Reducing the impact of VPNv4 route or BGP label route flapping on an entire network during the RP switchover Reducing lost packets so that the packet loss ratio of VPN traffic can be decreased to almost 0% Reducing the impact on important VPN services Reducing PE or CE failures to improve the reliability of an entire VPN
3 Principles
To support VPN GR, a BGP/MPLS VPN must support IGP GR and BGP GR. When using an MPLS LDP LSP as a tunnel, the BGP/MPLS VPN must support MPLS LDP GR. After the master/slave switchover is performed on a PE or a CE, the PE or CE 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 connecting the PE on which the master/slave switchover is performed also needs to keep the forwarding information of all VPN routes over a certain period. If traffic engineering is used, the BGP/MPLS VPN also needs to support RSVP GR. On a common L3VPN, the master/slave switchover may be performed on any PE, CE, or P device.
Master/Slave Switchover of PEs

The master/slave switchover of PEs consists of three phases. 1. Before the master/slave switchover A PE negotiates the IGP GR and MPLS LDP GR capabilities with a P, and the IGP GR or BGP GR capabilities with the connected CE. It 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 master/slave switchover The PE keeps the status of VPNv4 route forwarding and the following procedures are involved: l MPLS LDP GR If a neighbor detects that the corresponding TCP session is in the Down state, the neighbor backs up all LSPs on the slave board and marks these LSPs as invalid. l BGP GR BGP session messages are lost during the master/slave 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 devices as Stale; the BGP peers, however, still forward packets based on these routes within the GR time. 3. After the master/slave switchover The PE notifies all the IGP neighbors, BGP IPv4 neighbors, and private network IGP neighbors between the PE and CE to reestablish connections, and the following procedures are involved: l IGP convergence To resynchronize the 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 P 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. l 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. l Label Switching Path Management (LSPM)
3 Principles
BGP may receive or send routes with labels to create BGP LSPs and apply for labels. Thus, all information about BGP LSPs is sent to LSPM. LSPM checks whether the corresponding LSP exists. If the matching LSP exists, the LSPM module deletes the invalid flag of this LSP. When receiving the End-of-RIB message, which is used to inform the peer that the update of routing information after the establishment of a BGP session is completed, from a BGP peer on a public or private network, the PE informs the routing management (RM) module of this. Before all routing protocols complete the GR, only FIB information on the main control board is updated; 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 and LSPM module that the GR is complete, and then updates the FIB information on the interface board. a. b. 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 LSPM module deletes all the LSPs in the Stale state. Then, VPN GR is complete.
The devices connected to the PE can be processed in the following manners: l After sensing the restart of the PE, the CE connected to this PE adopts the same processing flow as that of the GR helper in the common IGP GR or BGP GR. That is , they keeps information about all IPv4 routes over a certain period. After sensing the restart of the PE, the following situations occur on P connected to the PE: If BGP is not configured, the P adopts the same processing flow as that of the GR helper in the common IGP GR and 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 over a certain period. l After sensing the restart of the PE, the RRs reflecting VPNv4 routes and the other PEs (including ASBRs) connected to this PE adopt 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 over a certain period.
Master/Slave Switchover of Ps
The processing flow of Ps is the same as that of the GR restarter in the common IGP GR, MPLS LDP GR, or BGP GR. After sensing the restart of a P, other Ps and PEs, which are connected to the P, adopt the same processing flow as that of the GR helper in the common IGP GR or BGP GR. That is, they keep information about all the public network IPv4 routes over a certain period.
Master/Slave Switchover of CEs

The processing flow of CEs is the same as that of the GR restarter in the common IGP GR or BGP GR. After sensing the restart of a CE, the PEs connected to the CE adopt the same processing flow as that of the GR helper in the common IGP GR or BGP GR. That is, they keep information about all the private network IPv4 routes over a certain period.
3 Principles
3.10 VPN NSR

As networks develop fast, the demand for the triple play services of the Public Switched Telephone Network (PSTN), TV network, and Internet becomes more and more stringent. Operators pose high requirements for reliability on IP networks. Non-Stop Routing (NSR), as an High Availability (HA) solution, is thus introduced. NSR ensures that the control plane of a neighbor does not sense the fault on the control plane of the local device which provides a slave control plane. In this process, the neighbor relationships set up through specific routing protocols, MPLS, and other protocols that carry services are not interrupted. As an HA solution, NSR ensures that user services are not affected or least affected in the case of device failures. During the master/slave switchover, VPN NSR ensures the continuous forwarding and continuous advertisement of VPN routes. In this process, the neighbor relationships are not affected, with neighbors not knowing the switchover on the local device. This ensures uninterrupted transmission of VPN services.
3.11 QPPB
Figure 3-29 Networking diagram of the QPPB application
RouterA
RouterB
QoS Policy Propagation Through the Border Gateway Protocol (QPPB) is a technology used to propagate the QoS policy through BGP. In QPPB, the BGP route sender sets attributes of BGP routes based on routing policies. The BGP route receiver can set the IP precedence, QoS local ID, and traffic behavior name for BGP routes based on the community attribute list, cost, BGP AS-path list, ACL, and IP prefix list. The IP precedence, QoS local ID, and traffic behavior name are delivered with routing information to the FIB. According to the locally configured policy, different QoS policies can be applied during packet forwarding based on the IP precedence, QoS local ID, and traffic behavior name. The biggest advantage of QPPB is that the BGP route sender can set attributes of the BGP routes to pre-classify routes, and the BGP route receiver can apply different local QoS policies to the BGP routes based on the attributes set by the BGP route sender. In a complicated network where dynamic modification of route classification policies is frequent, QPPB can simplify the modification of policies on the route receiver. With QPPB, it is only needed to modify the routing policies on the BGP route sender to meet the requirement. As shown in Figure 3-29, Router B advertises the BGP route with attributes to Router A. Receiving the route from Router B, Router A sets the IP precedence, QoS local ID, and traffic behavior name for the route based on the matched community attribute list, ACL, and BGP ASpath list. After the interfaces connecting Router A and Router B are enabled with QPPB policies, the corresponding QoS policy is applied to the packets sent from Router A to Router B.
3 Principles
VPN QoS
Figure 3-30 Networking diagram of the VPN QoS application
CE1
CE3
PE1 CE2
PE2 CE4
VPN QoS provides the policies of sending routes in private networks through BGP. It is an extension of QPPB applied to an L3VPN. VPN QoS can be applied to VPN instances and VPNv4. When deploying VPN QoS to the route of a specified VPN instance, apply inbound and outbound routing policies to this VPN instance; when deploying VPN QoS to the routes of all VPN instances, apply inbound and outbound routing policies to VPNv4 neighbors of BGP. As shown in Figure 3-30, PE1 is connected to CE1 and CE2, and PE2 is connected to CE3 and CE4. CE1 and CE3 belong to VPN Yellow, and CE2 and CE4 belong to VPN Green. l Outbound routing policy applied in the VPN instance When receiving the private network route from CE3, PE2 uses the outbound routing policy of VPN Yellow to set the community attribute for the private route of CE3 and then forwards the community attribute to PE1 with a VPNv4 route. l Inbound routing policy applied in the VPN instance When receiving the VPNv4 route from PE2 and performing the VPN route matching, PE1 matches the route with the inbound routing policy of VPN Yellow, including the community attribute, ACL, IP prefix, or AS-path, to set the IP precedence, QoS local ID, and traffic behavior name for the private route of CE3. l Outbound routing policy applied in the VPNv4 When sending the VPNv4 route to PE1, PE2 uses the outbound routing policy on its VPNv4 neighbor to set the community attribute. l Inbound routing policy applied in the VPNv4 When receiving the VPNv4 route from PE2, PE1 uses the inbound routing policy on its VPNv4 neighbor to match the community attribute, ACL, prefix, and AS path, and to set the IP preference, QoS Local ID, and traffic behavior name for VPNv4 routes.
3.12 BGP SoO

When multiple CEs in a VPN site access different PEs, VPN routes sent from CEs to PEs may return to this VPN site after traveling through the backbone network. This may cause routing loops in the VPN site.
3 Principles
After the BGP Site-of-Origin (SoO) attribute is configured on a PE, the PE adds the SoO attribute to the route sent from a CE and then advertises the route to other PE peers. Before advertising the VPN route to the connected CE, the PE peers check the SoO attribute carried in the VPN route. If the PE peers find that this SoO attribute is the same as the locally configured SoO attribute, the PE peers do not advertise this VPN route to the connected CE. As shown in Figure 3-31, CE1 and CE2 are in the same VPN site and can advertise routes to each other. CE1 advertises the route to 10.1.1.1/8 in the VPN site to PE1 and PE1 advertises the route to PE2 by using MP-IBGP. PE2 then advertises the route to CE2 by using BGP. As a result, the route returns to the original VPN site from which the route is advertised, which may cause a routing loop in the VPN site. Figure 3-31 Networking diagram for the BGP SoO application
CE1
PE1
VPN Site 10.1.1.1/8 VPN Backbone CE2 PE2 PE3
To avoid routing loops in a VPN site, you can configure an SoO attribute on PE1 for CE1, the SoO attribute identifies the site where the CE1 resides. The routes advertised by CE1 to PE1 then carry this SoO attribute and PE1 advertises the routes with the SoO attribute to other PEs across the backbone network. Before advertising the received routes to its peer CE2, PE2 checks whether the routes carry the SoO attribute specified for the site where CE2 resides. If a route carries this SoO attribute, it indicates that this route is advertised from the site where CE2 resides. PE2 then refuses to advertise such a route to CE2, thus avoiding routing loops in the site.
3.13 Next-Hop-based Label Distribution for VPN Routes by ASBRs

Background
Unlike the inter-AS VPN Option A mode, the inter-AS VPN Option B mode is not limited by the number of links between ASBRs, and all traffic is forwarded by ASBRs. In inter-AS VPN Option B mode, traffic is easy to control, but the load on ASBRs is heavy because all VPN routing information is stored on and exchanged by ASBRs. By default, an ASBR uses prefixbased label distribution, assigning one label to one VPN route. If many VPN routes exist, assigning one label to each VPN route may lead to insufficient label resources on ASBRs. To solve this problem, next-hop-based label distribution is used to allow ASBRs to assign labels based on next hops. This function saves label resources. In next-hop-based label distribution, an ASBR assigns the same label to multiple VPN routes with the same forwarding behavior (same forwarding path and outgoing label). Compared with prefix-based label distribution, next-hopbased label distribution enables labels to be more flexibly distributed. Next-hop-based label
3 Principles
distribution used in combination with VPN-instance-based label distribution can effectively save label resources on ASBRs.
Implementation
By default, an ASBR uses prefix-based label distribution. You can configure an ASBR to distribute labels based on next hops. After next-hop-based label distribution is enabled on an ASBR, the ASBR re-advertises an MP-BGP Update packet to its peers. The MP-BGP Update packet carries VPNv4 routes and their labels re-assigned based on next hops. After a peer receives the MP-BGP Update packet, the peer updates its local label forwarding table and reestablishes LSPs. After the ASBR and its peers update their label forwarding tables, packets are forwarded based on updated label forwarding tables.
NOTE
Prefix-based label distribution and next-hop-based label distribution can be flexibly switched to each other. During label distribution mode switching, service packets are lost for a short period due to update of label forwarding tables.
Figure 3-32 Schematic diagram of next-hop-based label distribution for VPN routes by ASBRs
VPN1 CE1 BGP/MPLS backbone AS: 100 BGP/MPLS backbone AS: 200
VPN1 CE3 PE3
MP-EBGP PE1 MP-IBGP ASBR1 ASBR2
MP-IBGP PE4 CE4 VPN2
CE2 VPN2
As shown in Figure 3-32, two VPN instances named VPN1 and VPN2 are configured on PE1 in inter-AS VPN Option B mode. PE1 uses the VPN-instance-based label distribution mode. If next-hop-based label distribution is disabled on ASBR1, ASBR1 assigns 20,000 labels to the 20,000 VPN routes imported from CE1 and CE2 over PE1 before advertising these routes to ASRB2. If next-hop-based label distribution is enabled on ASBR1, ASBR1 only needs to assign one label to VPN routes with the same next hop and outgoing label. Therefore, ASBR1 assigns only two labels to the 20,000 routes imported from CE1 and CE2 over PE1 before advertising these routes to ASRB2.
Usage Scenario
Next-hop-based label distribution mainly applies to ASBRs in inter-AS VPN Option B mode.
3 Principles
Benefits
Next-hop-based label distribution saves label resources on ASBRs and increases label resource usage.
3.14 Query on the Bearing Relationship Between VPN and Tunnel

Query on the Bearing Relationship Between VPN and LSP
By specifying the VRF name, next hop of the public network, and tunnel ID, you can query detailed information about the tunnel that carries specified VRF services, and then the queried information about the tunnel can be returned to the NMS client. Figure 3-33 Typical networking of basic BGP/MPLS IP VPN
CE1
PE1
PE2
CE2
As shown in Figure 3-33, a public network tunnel is set up between PE1 and PE2, and both PEs function as the BGP VPNv4 peers of each other. Through the MP-IBGP relationship, PE1 advertises its VPNv4 routes to PE2. After receiving these VPNv4 routes and performing the VPN route matching, and based on a specified tunnel policy, PE2 iterates the public network tunnel according to the next hop of these routes. Note that if tunnel load balancing is configured, multiple public network tunnels are iterated. In this manner, the bearing relationship between public network tunnel(s) designated by PE2 and a specific VRF is established. The MIB querying the bearing relationship between VPN and LSP is to return queried detailed information about the tunnel to the NMS client by sending SNMP packets based on the specified VRF name, next hop of the public network, and the tunnel ID. The detailed tunnel information includes the destination address of the tunnel, source address of the tunnel, tunnel type, outbound interface of the tunnel, load balancing status of the tunnel, LSP index, outbound interface of the LSP, outgoing label of the LSP, next hop of the LSP, LSP FEC, mask length of the LSP FEC, and LSP status (primary or backup). Note that tunnels can be of different types, such as LocalIfNet, TE, GRE, and LSP. Only tunnels of the LSP and TE types can be filled with the LSP information, including LSP index, outbound interface of the LSP, outgoing label of the LSP, next hop of the LSP, LSP FEC, mask length of the LSP FEC, and LSP status (primary or backup). Other types of tunnels are not filled with the LSP information.
Query on the tunnel bearing VPN

The querying MIB of the tunnel bearing VPN: By specifying the tunnel ID and tunnel interface name, you can query which VPN services are carried on the tunnel, and then return the queried VPN information to the NMS client through SNMP packets. The queried VPN information includes information about L3VPN, VPLS, and PWE3/VLL. The returned L3VPN information is the VPN name, the returned VPLS information is VSI name, VSI ID, IP address of the peer,
3 Principles
and VC ID, and the returned PWE3/VLL information is IFname, IP address of the peer, and VC ID. Querying VPN services carried on a specified tunnel is vital for the network operation and maintenance, service monitor, and fault location.
3.15 BGP/MPLS IPv6 VPN Extension

On a BGP/MPLS IP VPN network, IPv4 routing protocols (such as BGP, OSPF, and IS-IS) run between PEs, and between PEs and CEs. After a VPN customer network transits from IPv4 to IPv6, the preceding routing protocols are not applicable between PEs and CEs, and IPv6 VPN packets are transmitted on the backbone network. With BGP/MPLS IPv6 VPN extension, the backbone network can provide IPv6 VPN services for customers without having to be upgraded to an IPv6 network. Figure 3-34 is the BGP/MPLS IPv6 VPN extension model. After BGP/MPLS IPv6 VPN extension is configured, IPv6 routing protocols run between PEs and CEs, and the following IPv6 routing protocols can be used to provide IPv6 VPN services: l l l l BGP4+ OSPFv3 IS-IS IPv6 Static IPv6 routes
Figure 3-34 BGP/MPLS IPv6 VPN extension model
CE(IPv6) VPN 1 Site CE(IPv6) PE PE CE(IPv6) VPN 2 Site P CE(IPv6) P PE Service provider's IPv4 or IPv6 backbone P P
VPN 2 Site
VPN 1 Site
IPv4 protocols can still run on the carriers' backbone networks that provide IPv6 VPN services between PEs. In this manner, the carriers' networks can smoothly transit from IPv4 to IPv6. The backbone network is an IPv4 network, IPv4 addresses are used to establish VPNv6 peers between PEs to inform IPv6 VPN routes. For IPv6 VPN routes, IPv4 tunnels on the backbone network can be selected to transmit IPv6 VPN services. BGP/MPLS IPv6 VPN has the same principle and functions as BGP/MPLS IPv4 VPN except that the routing protocols running between PEs and CEs are different.
Issue 01 (2012-09-10)
47
3 Principles
3.16 VPN Dual-Stack Access

IPv4 address exhaustion is the decreasing supply of unallocated IPv4 addresses available on the network. This forces carriers to put IPv6 network planning issues high on their agendas. For the BGP/MPLS IPv4 VPN services that have been widely deployed, supporting VPN dual-stack access is a practical and readily available solution to the transition from IPv4 to IPv6. Originally, interfaces in a VPN support only a single type of protocol stack. After VPN dualstack access is configured, both IPv4 and IPv6 address families can be configured in a VPN so that the interfaces bound to this VPN can support not only IPv4 VPN access but also IPv6 VPN access. This greatly improves the feasibility of the transition from IPv4 to IPv6. As shown in Figure 3-35, IPv4/IPv6 VPN dual-stack access allows VPN sites to support both IPv4 and IPv6 networks and to be connected to a PE through the same interface. Figure 3-35 Networking diagram of VPN dual-stack access
CE1
PE1
MPLS Backbone P
PE2
CE2
IPv4/IPv6 Network
IPv4/IPv6 Network
Issue 01 (2012-09-10)
48
4 Applications
4
About This Chapter
4.1 BGP/MPLS IP VPN Application 4.2 Typical Application of IP+VPN FRR 4.3 Hub&Spoke Networking Application 4.4 HoVPN Networking Application
Applications
Issue 01 (2012-09-10)
49
4 Applications
4.1 BGP/MPLS IP VPN Application

Service Overview
Figure 4-1 shows a typical networking diagram for a carrier. Site1 and Site2 represent two networks in different cities. The two networks may be networks for two branches of a company, or networks for municipal governments of the two cities. During communication between Site1 and Site2, data security must be ensured. The two networks must be separated from other networks and packets exchanged between the two networks must be transparently transmitted over the carrier's backbone network. The BGP/MPLS IP VPN technology can meet such service requirements. VPN labels assigned using MP-BGP enable packets to enter the correct VPN site and MPLS enables packets to be transparently transmitted over tunnels on the carrier's backbone network. Figure 4-1 BGP/MPLS IP VPN application
MPLS Backbone VPN1 CE1 Site1 PE1 RR1 P1 PE3 RR2 VPN1 Site2 CE2 PE2 P2 PE4
Networking Description
PEs and Ps on the carrier's backbone network must be used to transmit routes and packets between Site1 and Site2 from the two networks to communicate. CEs can be dual-homed to PEs to ensure high network availability. Generally, a carrier deploys route reflectors (RRs) on the backbone network to reflect VPNv4 and VPNv6 routes.
Feature Deployment
In BGP/MPLS IP VPN networking, the following configurations must be performed: l l Configure static routes between CEs and PEs or configure RIP, OSPF, IS-IS, or BGP on CEs and PEs for them to exchange routing information. Configure MP-BGP peer relationships between all PEs and RR1 and between all PEs and RR2. Configure all PEs as the clients of RR1 and RR2 and configure RR1 and RR2 to back up each other. These configurations ensure network reliability.
Issue 01 (2012-09-10)
4 Applications
l l
Configure an IGP and MPLS on PEs and Ps and establish MPLS tunnels for traffic forwarding. Adjust IGP costs of links to: Ensure that the two links between CE1 and CE2 work in primary/secondary mode. If one link fails, traffic is switched to the other link for transmission. Adjust the costs of links between RRs and the backbone network. Ensure that RRs are used only for route reflection, not for traffic forwarding.
Configure VPN FRR for services that have high requirements on real-time transmission to enhance network reliability.
4.2 Typical Application of IP+VPN FRR

On the network shown in Figure 4-2, CE2 is dual-homed to PE2 and PE3. A BGP VPNv4 peer relationship is set up between PE2 and PE3. Each of the PEs sends its route that is bound for CE2 to the other PE. PE2 selects the local route, not the route sent from PE3, to transmit traffic to CE2. In normal situations, the traffic sent from PE2 to CE2 travels along link A. If link A fails, route reselection is triggered on PE2. PE2 activates the VPNv4 cross route sent from PE3, switching the traffic bound for CE2 to link B. Route convergence is an important factor in this switchover mode, and the convergence time is determined by the number of VPN routes. The larger the number of VPN routes, the longer the route convergence time. Therefore, the link switchover time in this mode is varying and may fail to meet requirements if routers are heavily loaded. Figure 4-2 Networking diagram for IP+VPN FRR
PE2 VPN Backbone LinkA LinkB CE1 PE1 PE3 CE2
VPN Site
VPN Site
After IP+VPN FRR is deployed, PE2 stores the CE2-bound VPNv4 route that is sent from PE3 as a backup route for its local route bound for CE2, and generates an FRR entry. If link A fails, PE2 can quickly switch the traffic bound for CE2 to link B. The link switchover speed in IP +VPN FRR mode is very fast (within subseconds) because it depends on the fault detection speed on the PE, not on route convergence speed (this means that the number of VPN routes does not matter). Long-term service interruption is therefore prevented. If the fault on link A is cleared, routes on PE2 converge again, PE2 will preferentially select local routes but not the cross routes, and the traffic to CE2 is switched back to link A.
Issue 01 (2012-09-10)
51
4 Applications
4.3 Hub&Spoke Networking Application

Service Overview
Financial enterprises such as banks can use the Hub&Spoke networking mode to ensure financial data security. Hub&Spoke networking allows branches to exchange data only through the headquarters. In this manner, data transmission between branches is under effective supervison. In Hub&Spoke networking, the site where the access control device of the headquarters is located is called a Hub site; other sites where branches are located are called Spoke sites. At the Hub site, a device that accesses the VPN backbone network is called a Hub-CE. At a Spoke site, a device that accesses the VPN backbone network is called a Spoke-CE. On the VPN backbone network, a device that accesses the Hub site is called a Hub-PE, and a device that accesses a Spoke site is called a Spoke-PE. A Spoke site advertises routes to the Hub site. The Hub site then advertises the routes to other Spoke sites. No direct route exists between the Spoke sites. The Hub site controls communication between the Spoke sites. In the Hub&Spoke networking model, two VPN targets are configured to stand for Hub and Spoke, respectively. The configuration of a VPN target on a PE must comply with the following rules: l l The export and import targets of a Spoke-PE are Spoke and Hub, respectively. The import target of a Spoke-PE is different from the export targets of other Spoke-PEs. A Hub-PE requires two interfaces or sub-interfaces. One interface or sub-interface receives routes from Spoke-PEs, and the import target of the VPN instance on the interface or subinterface is Spoke. The other interface or sub-interface advertises the routes to Spoke-PEs, and the export target of the VPN instance on the interface or sub-interface is Hub.
Networking Description
Hub&Spoke networking includes the following schemes: l l l 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 an IGP running between Spoke-PEs and Spoke-CEs
The following describes these networking schemes in detail: l EBGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs As shown in Figure 4-3, a route advertised by a Spoke-CE is forwarded to the Hub-CE and Hub-PE before being transmitted to other Spoke-PEs. If EBGP runs between the HubPE and the Hub-CE, the Hub-PE performs an AS-Loop check on the route. When the HubPE 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 duplicate local AS numbers.
Issue 01 (2012-09-10)
52
4 Applications
Figure 4-3 EBGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs
AS65401
Spoke-PE1 EBGP IBGP VPN backbone AS100 IBGP EBGP EBGP VPN_in Hub-PE EBGP VPN_out Hub-CE
Spoke-CE1
Spoke-CE2
AS65403
AS65402
Spoke-PE2
IGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs As shown in Figure 4-4, because all PEs and CEs exchange routes using the IGP, and IGP routes do not contain the AS_Path attribute, the AS_Path field of BGP VPNv4 routes is empty. Figure 4-4 IGP running between the Hub-CE and Hub-PE, and between Spoke-PEs and Spoke-CEs
AS65401
Spoke-PE1 OSPF100 vpn1
Spoke-CE1
IBGP VPN backbone AS100 IBGP
OSPF 100 Hub-CE vpn_in OSPF 200 Hub-PE vpn_out AS65403
Spoke-CE2 OSPF100 vpn1 AS65402
Spoke-PE2
EBGP running between the Hub-CE and Hub-PE, and an IGP running between Spoke-PEs and Spoke-CEs As shown in Figure 4-5, the networking topology is similar to that shown in Figure 4-3. 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 duplicate local AS numbers.
Issue 01 (2012-09-10)
53
4 Applications
Figure 4-5 EBGP running between the Hub-CE and Hub-PE, and an IGP running between Spoke-PEs and Spoke-CEs
AS65401 Spoke-PE1 OSPF100 vpn1
Spoke-CE1
IBGP VPN backbone AS100 IBGP
EBGP vpn_in Hub-PE EBGP vpn_out
Hub-CE
Spoke-CE2 OSPF100 vpn1 AS65402
AS65403
Spoke-PE2
4.4 HoVPN Networking Application

Application of HoVPN on a Hierarchical Network
If an MPLS VPN spans a country, the VPN is generally of a flat structure, meaning MPLS VPN services are directly provided by the backbone network. In the flat structure, the PEs of the backbone network are generally deployed in central cities. The CEs converge packets to PEs, as shown in Figure 4-6. Figure 4-6 Networking diagram of a non-hierarchical network
P
Core layer
PE
Central city
CE1
CE2
CE3
Site A
Site B
Site C
Issue 01 (2012-09-10)
54
4 Applications
In non-hierarchical networking, a lot of WAN link resources are consumed when remote CEs access the central cities. Limited scale of the backbone network leads to poor expansibility and limited coverage of the VPN. As shown in Figure 4-7, if the HoVPN model is used, UPEs can be deployed in cities or counties, and VPN user packets be transmitted to adjacent UPEs before being converged to SPEs in central cities. The coverage of the VPN can be extended. The services can be smoothly upgraded, and the network can be extended as required. SPEs and UPEs can reside within an AS or serve as joints between ASs. Figure 4-7 Networking diagram of an HoVPN
Core layer
SPE UPE1
Central city UPE2
CE1
CE2 Site B Site C
CE3
Site A
Deployment of HoVPN on an Inter-AS VPN

As shown in Figure 4-8, the backbone network and MANs belong to different ASs. SPEs are deployed on the backbone network, and UPEs are deployed on the MANs. The UPEs advertise all MAN routes to the SPEs, but the SPEs advertise only the default routes of VPN instances to the UPEs. Therefore, the MANs need to maintain only the routes of the VPN sites instead of the routes of sites outside the MANs. The backbone network must maintain the routes of all VPN sites. In inter-AS VPN mode, MP-EBGP or multi-hop EBGP can be configured between SPEs and UPEs for flexible device deployment. On an inter-AS HoVPN, the backbone network processes global services; the MAN processes only local services. Developing global VPN services does not challenge the capacity and expansibility of MANs.
Issue 01 (2012-09-10)
55
4 Applications
Figure 4-8 Inter-AS HoVPN

Backbone network AS100 Default route Default route
SPE1 Routes within the area UPE1 MAN A AS65410
SPE2 Routes within the area UPE2 MAN B AS65420
Issue 01 (2012-09-10)
56
5 Terms and Abbreviations
5
Terms
Term CE Address space GRE Description
Terms and Abbreviations
Customer edge equipment that is directly connected to the service provider. In a MPLS-based VPN, a CE can be a router, switch, or even a host. An address realm managed by a VPN. An encapsulation mode in which packets of certain network protocols such as IP and IPX are encapsulated and thus can be transmitted in networks supporting other protocols such as IP. A Layer 2 tunneling protocol that is drafted by IETF and involves the participation of companies such as Microsoft. The L2TP combines the advantages of both PPTP and L2F. A multi-protocol extension of BGP-4. MP-BGP supports multiple network layer protocols and identifies the protocols based on address families. MP-BGP transmits VPN composition information and VPN-IPv4 routes between PEs. A backbone device that is located in the service provider network. A P is not directly connected to CEs. Ps only need to possess basic MPLS forwarding capabilities and do not maintain information about a VPN. A device that is located in the backbone network of the MPLS VPN structure. A PE is responsible for VPN user management, establishment of LSPs between PEs, and exchange of routing information between sites of the same VPN. During the process, a PE performs the mapping and forwarding of packets between the private network and the public channel. A PE can be a UPE, an SPE, or an NPE. A route distinguisher, which is a 8-byte field in a VPN IPv4 address. An RD and a 4-byte IPv4 address prefix construct a VPN IPv4 address, which is used to differentiate the IPv4 prefixes using the same address space. A group of IP systems with IP connectivity, which can be achieved independent of SP networks.
L2TP
MP-BGP
PE
RD
site
Issue 01 (2012-09-10)
57
Term Tunnel
Description A channel on the packet switching network that transmits service traffic between PEs. In VPN, a tunnel is an information transmission channel between two entities. The tunnel ensures secure and transparent transmission of VPN information. In most cases, a tunnel is an MPLS tunnel. A process in which a route is iterated to a tunnel. A group of information, including the token, slot number of an outgoing interface, tunnel type, and location method. A recently-developed technology that implements the private network over a public network. It is a network that only logically exists. An entity that is set up and maintained by PEs for directly-connected sites. Each site has its VPN instance on a PE. A VPN instance is also called the VPN Routing and Forwarding (VRF) table. A PE has multiple forwarding tables, including a public-network routing table and one or multiple VRFs. A BGP extended community attribute that is also called Route Target. In BGP/ MPLS IP VPN, VPN-Target is used to control VPN routing information. The VPN-Target attribute defines which sites can receive a VPN IPv4 route and the routes from which sites can be received by a PE.
Tunnel iteration Tunnel ID VPN VPN instance
VPNTarget
Abbreviations
Abbreviation AS ASBR BGP CE GRE HoPE HoVPN IGP IS-IS ISP L2TP LCP LDP Full Spelling Autonomous Systems Autonomous System Boundary Router Border Gateway Protocol Customer Edge Generic Routing Encapsulation Hierarchy of PE Hierarchy of VPN Interior Gateway Protocol Intermediate System to Intermediate System Internet Service Provider Layer 2 Tunneling Protocol Link Control Protocol Label Distribution Protocol
Issue 01 (2012-09-10)
58
Abbreviation LSP LSR MP-BGP MPLS NAT NCP OSPF P PE PHP PVC QoS QPPB RD RR RSVP VPN VPN QoS VRF
Full Spelling Label Switched Path Label Switching Router Multiprotocol extensions for BGP-4 MultiProtocol Label Switch Net Address Translation Net Control Protocol; Network Control Point; Network Control Protocol Open Shortest Path First Provider Provider Edge Penultimate Hop Popping Permanent Virtual Channel Quality of Service Qos Policy Propagation Through the Border Gatewat Protocol Route Distinguisher Route-Reflector Resource Reservation Protocol Virtual Private Network Virtual Private Network Quality Of Service VPN Routing and Forwarding table
Issue 01 (2012-09-10)
59

BGP MPLS IP VPN Features PDF

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BGP MPLS IP VPN Features PDF

Uploaded by

Copyright:

Available Formats

VRP V500R011C01

BGP/MPLS IP VPN Feature Description

HUAWEI TECHNOLOGIES CO., LTD.

Trademarks and Permissions

Huawei Technologies Co., Ltd.

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

5 Terms and Abbreviations..........................................................................................................57

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

1 Introduction to BGP/MPLS IP VPN

Introduction to BGP/MPLS IP VPN

Service provider's P backbone P

PE PE PE VPN 2 Site P P VPN 1 Site

VRP BGP/MPLS IP VPN Feature Description

1 Introduction to BGP/MPLS IP VPN

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

3.1 Basic BGP/MPLS IP VPN

Figure 3-1 Network diagram for a basic BGP/MPLS IP VPN

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

Figure 3-2 Schematic diagram of sites

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

Figure 3-3 One site belonging to multiple VPNs

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

Site1 CE VPN1 VPN-instance VPN2 VPN-instance VPN2 PE

Public forwarding table

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

VRP BGP/MPLS IP VPN Feature Description

Route Advertisement on a Basic BGP/MPLS IP VPN

VRP BGP/MPLS IP VPN Feature Description

Packet Forwarding on a BGP/MPLS IP VPN

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

Figure 3-6 Forwarding of a VPN packet from CE1 to CE2

data data I-L O-L1 Push

data data I-L I-L O-L1 O-L2 Out-Label Switch

data data I-L O-L2 Pop

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

3.2 Inter-AS VPN

Inter-Provider Backbones Option A

PE3 CE MP-IBGP ASBR2 PE4 CE4 VPN2

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

Inter-Provider Backbones Option B

VPN1 CE3 PE3

VRP BGP/MPLS IP VPN Feature Description

Inter-Provider Backbones Option C

BGP/MPLS backbone AS: 100

BGP/MPLS backbone AS: 200

Huawei Proprietary and Confidential Copyright Huawei Technologies Co., Ltd.

VRP BGP/MPLS IP VPN Feature Description

RR-2 PE4 CE4 VPN2