BGP MPLS IP VPN Features.pdf

7/28/2019 BGP MPLS IP VPN Features.pdf

1/62


2/62

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

Website: http://www.huawei.com

Email: [email protected]

Issue 01 (2012-09-10) Huawei Proprietary and Confidential

Copyright Huawei Technologies Co., Ltd.

i
http://www.huawei.com/


3/62

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.......................................................................................................................................................423.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

VRP

BGP/MPLS IP VPN Feature Description Contents



ii


4/62

1 Introduction to BGP/MPLS IP VPNDefinition

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

CE

CE

CE Service provider's

backbone

CEVPN 1

Site

Site

Site

Site

VPN 1

VPN 2

PE

PE

PE

P

P P

PVPN 2

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.

l 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.

VRP

BGP/MPLS IP VPN Feature Description 1 Introduction to BGP/MPLS IP VPN



1


5/62

l 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.

VRP

BGP/MPLS IP VPN Feature Description 1 Introduction to BGP/MPLS IP VPN



2


6/62


7/62

3 PrinciplesAbout 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

VRP

BGP/MPLS IP VPN Feature Description 3 Principles



4


8/62

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 Transmits packets using extended BGP.

l Encapsulates and transmits VPN packets over MPLS LSPs serving as public network

tunnels.

l 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 abasic BGP/MPLS IP VPN

VPN1

Site3

Site4CE

VPN2

CE

PEVPN2

Site2CE

VPN1

Site1

CE

PE P

MPLS

Backbone

MP-BGP

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.

VRP




5


9/62

Figure 3-2 Schematic diagram of sites

CE

Carrier's

network

CE

Two sites One site

Site A

Carrier's

networkHeadquarters of

X company in

City A

Site X

Branch of X

company in

City B

Headquarters

of X company

in City A

Branch of X

company in

City B

CE

Site B

CE

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.

VRP




6


10/62

Figure 3-3 One site belonging to multiple VPNs

Carrier's

networkCE

CE

Site B

Site C

X Company

Decision-making

department

CE

Site A

City A City B

City C

VPN 2

VPN 1X Company

R&D

department

X Company

Financial

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.

l 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 PEmaintains only one routing and forwarding table, this table will accept only one of the routes

VRP




7


11/62

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 andone 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

VPN2

Site2 CE

VPN1

Site1 CE

PEVPN1

VPN-instanceVPN2

VPN-instance

Public

forwarding table

Backbone

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 informationextracted 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.

VRP




8


12/62

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 thetwo 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

Type Field( 2-Byte )

IPv4 Address Prefix( 4-Byte )

AdministratorSubfield

AssignedNumber Subfield

Route Distinguisher ( 8-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 targetof a VPN instance on the PE, the PE adds the route to the corresponding VRF.

VRP




9


13/62

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 ofall 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 layerprotocol information is contained in the Network Layer Reachability Information (NLRI)

field and the Next Hop field of an MP-BGP Update message.

MP-BGP uses the address family to differentiate network layer protocols. An address

family can be a traditional IPv4 address family or any other address family, such as a VPN-

IPv4 address family or an IPv6 address family. For the values of address families, see 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 VPNroutes, 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 arestandard IPv4 routes.

VRP




10


14/62

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 PEAdvertisement 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 andfilters 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 indicatesan 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.

VRP




11


15/62

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

Ingress PECE1 Egress PE CE2

data

P

I-L

data

O-L1

I-L

data

O-L1

I-L

data

O-L2

Out-Label Switch

I-L

data

O-L2

datadata data

Push Pop

The forwarding process is as follows:

1. CE1 sends a VPN packet to the ingress PE.

2. After receiving the packet from an interface bound to a VPN instance, the ingress PEperforms 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. The egress PE removes the inner label residing at the bottom of the label stack.

5. 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 Enables users to communicate with each other over networks of geographically different

regions.

l Ensures the security of VPN user data during transmission on the public network.

VRP




12


16/62

3.2 Inter-AS VPNWith 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 inter-

AS 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-to-

VRF.

l 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 VPN-

IPv4 routes.

l 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 thetwo 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

BGP/MPLS backbone

AS: 100

VPN1CE1

PE2

ASBR1

PE1

CE2

VPN2

ASBR2

BGP/MPLS backbone

AS: 200

MP-IBGP

EBGP

LSP1

VPN LSP1 IP forwarding

CE

PE3

PE4

VPN1

CE3

CE4

VPN2

MP-IBGP

VRP




13


17/62

In Figure 3-7, for ASBR1 in AS 100, ASBR2 is a CE. Similarly, for ASBR2, ASBR1 is a CE.

Inter-Provider Backbones Option BIn 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

BGP/MPLS backbone

AS: 100

VPN1

CE1

PE2

ASBR1

PE1

CE2

VPN2

ASBR2

BGP/MPLS backbone

AS: 200

MP-IBGPMP-EBGP

LSP1VPN LSP1

PE3

PE4

VPN1

CE3

CE4

VPN2

MP-IBGP

VPN LSP3VPN LSP2

LSP2

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.

VRP




14


18/62

l 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.

l The PEs in different ASs establish multi-hop EBGP connections with each other and

exchange VPN-IPv4 routes.

l The ASBRs do not store VPN-IPv4 routes or advertise VPN-IPv4 routes to each other.

Figure 3-9 Networking diagram for PEs to manage VPN routes in inter-AS VPN Option C mode

BGP/MPLS backbone

AS: 100

VPN1

CE1

PE2

ASBR1

PE1

CE2

VPN2

ASBR2

BGP/MPLS backbone

AS: 200

MP-IBGPEBGP

PE3

PE4

VPN1

CE3

CE4

VPN2

MP-IBGP

VPN LSP

Multi-hop MP-EBGP

Multi-hop MP-EBGP

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.

VRP




15


19/62

Figure 3-10 Networking diagram of inter-provider backbones Option C with RRs

BGP/MPLS backboneAS: 100

VPN1

CE1

PE2ASBR1

PE1

CE2VPN2

ASBR2

BGP/MPLS backboneAS: 200

MP-IBGPEBGP

PE3

PE4

VPN1

CE3

CE4

VPN2

MP-IBGP

VPN LSP

Multi-hop MP-EBGP

RR-1 RR-2

LSP

Comparison Between Three Options

Table 3-1 Comparison between three options

Inter-AS

VPN

Characteristic

Option A 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.

VRP




16


20/62

Inter-ASVPN

Characteristic

Option C 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 thatof a stub VPN. That is, the provider carrier CE advertises only internal routes, instead of

VRP




17


21/62

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 providercarrier network. A user CE is a device through which a user accesses the customer carrier network.

l 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

First

Carrier

Second

CarrierSecond

Carrier

ASBR1 PE1 PE2CE1 CE2 ASBR2

MP-IBGPIGP

or

BGP

IGP

or

BGPBGP

IGP & LDP IGP & LDPor

labeled BGP

or

labeled BGP

VRP




18


22/62

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 ProviderCarrier's Backbone

Network and CustomerCarrier Network

Characteristics

In the same AS Provider carrier PEs and CEs exchange routes using the

IGP and LDP. Provider carrier CEs exchange external

routes between each other using BGP.

In different ASs Provider carrier PEs and CEs exchange labeled VPN-

IPv4 routes using EBGP. Provider carrier CEs

exchange external routes between each other using

BGP.

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

First

Carrier

Second

Carrier

Second

Carrier

PE3 PE1 PE2CE1 CE2 PE4

MP-IBGP

MP-BGP

IGP & LDP IGP & LDP

or

labeled BGP

or

labeled BGP

IGP & LDP IGP & LDP

Table 3-3 Comparison between networking modes for customer carriers serving as

BGP/MPLS IP VPN SPs

Location of ProviderCarrier's BackboneNetwork and CustomerCarrier Network

Characteristics

In the same AS 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.

In different ASs Provider carrier PEs and CEs exchange routes and

labels using MP-EBGP. When entering the customer

carrier network, VPN packets must be triple-tagged.

VRP




19


23/62

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 Route Exchanging in the Scenario in Which the Customer Carrier Is a Common SP

(Same AS)

l Route Exchanging in the Scenario in Which the Customer Carrier Is a Common SP

(Different ASs)

l Packet Forwarding in the Scenario in Which the Customer Carrier Is a Common SP

l Route Exchanging in the Scenario in Which the Customer Carrier Is a BGP/MPLS

IP VPN SP (Same AS)

l Packet Forwarding in the Scenario in Which the Customer Carrier Is a BGP/MPLS

IP VPN SP (Same AS)

l Route Exchanging in the Scenario in Which the Customer Carrier Is a BGP/MPLS

IP VPN SP (Different ASs)

l 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)

FirstCarrier

SecondCarrier

SecondCarrier


IBGP10.1.1.1/32

CE4

D: PE2

L: L'

D: 10.1.1.1/32

N:CE2

MP-IBGPIGP & LDP

D: ASBR2

IGPIGP

IGP & LDP

D: CE2

AS:100 AS:100 AS:100

IGP & LDP IGP

D:10.1.1.1/32

N:CE2

IF0

IF1

IBGP

D:10.1.1.1/32

N:CE4

D:CE2

N:IF0

L: L0

D:CE2

N:PE2L: L1

D:CE2

N:PE1

L: L2

The following uses the advertisement of an Internet route destined for 10.1.1.1/32 from CE4 toASBR1 as an example to show Internet route exchange inside the customer carrier network.

VRP




20


24/62

1. 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.

2. 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 thismanner, a public network LSP is established between PE2 and PE1.

3. 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.

4. CE1 advertises the route to ASBR1 using the IGP running on the customer carrier network.

5. 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.

6. 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.

7. CE2 imports this external route to BGP and advertises this route to CE1 using IBGP.

8. 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.

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)

First

Carrier

Second

Carrier

Second

Carrier


EBGP10.1.1.1/32

CE4

D: PE2

L: L'

D: 10.1.1.1/32

N:CE2

MP-IBGPMP-EBGP

D: ASBR2

IGPIGP

IGP & LDP

D: CE1

AS:200 AS:100 AS:300

MP-EBGPIGP

D:10.1.1.1/32

N:CE1

IF0

IF1

IGP D:10.1.1.1/32N:CE4

D:CE2

N:IF0L: L0

D:CE2

N:PE2

L: L1

D:CE2

N:PE1

L: L2

VRP




21


25/62

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. CE2 advertises a route destined for itself to PE2 using EBGP running between CE2 and

PE2. Meanwhile, CE2 assigns label L0 to this route.

2. 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. PE1 assigns label L2 to the route using MP-IBGP and advertises the route to CE1.

4. CE1 advertises the route to ASBR1 using the IGP running on the customer carrier network.

5. After the routes of CE1 are advertised to CE2, an EBGP connection is established between

CE1 and CE2.

6. ASBR2 advertises the external route destined for 10.1.1.1/32 to CE4 using the IGP running

on the customer carrier network.7. CE2 imports the route to BGP and advertises this route to CE1 using EBGP.

8. 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

First

Carrier

Second

Carrier

Second

Carrier


10.1.1.1/32

ASBR3IP packet IP packet

L2

IP packetIP packet

L1

L'

IP packet

L0

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. ASBR1 transparently transmits the packet to CE1 based on IP forwarding.

VRP




22


26/62

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

3. 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.

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

5. CE2 removes label L' and forwards the packet to ASBR2 based on IP forwarding.

6. ASBR2 advertises the packet to CE4.

Route Exchanging in the Scenario in Which the Customer Carrier Is a BGP/MPLSIP 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 IPVPN SP (same AS)

FirstCarrier

SecondCarrier

SecondCarrier


MP-IBGP10.1.1.1/32

CE4

D: PE2

L: L'

D: PE4

N: PE1

L: L3

D: PE4

N: PE2

L: L2

MP-IBGPIGP & LDP

IGP & LDP

AS:100 AS:100 AS:100

D: CE1

L: L''2

IGP & LDP

D: PE4N: CE2

L: L1

D: PE4L: L''1

IGP & LDP IGP & LDP

D: PE4

IGP

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.

2. CE2 advertises the route to PE2 using the IGP running between CE2 and PE2. Meanwhile,

CE2 assigns label L1 to the route using LDP.

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


carrier's backbone network and assigned label L' to the routes destined for itself. A publicnetwork LSP has been established between PE2 and PE1.

VRP




23


27/62

4. PE1 assigns label L3 to the route using LDP running between PE1 and CE1 and advertises

the route to CE1.

5. 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 publicnetwork LSP has been established between CE1 and PE3.

6. After the routes destined for PE3 are advertised to PE4, an MP-IBGP connection is

established between PE3 and PE4.

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

route to PE3 using MP-IBGP.

The advertisement of a VPN route from PE3 to PE4 is similar to that from PE4 to PE3 and

therefore is not described here.

Packet Forwarding in the Scenario in Which the Customer Carrier Is a BGP/MPLSIP 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)

First

Carrier

Second

Carrier

Second

Carrier


10.1.1.1/32

CE4

IP packet

I-L

L3

IP packet

I-L

L1IP packet

IP packet

I-L

L'' 1

IP packet

I-L

L'' 2

IP packet

I-L

L2

L'

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. CE1 adds label L3 to the packet and forwards this packet to PE1.

VRP




24


28/62

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.

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

5. CE2 removes label L1, adds label L''1, and transparently forwards the packet to PE4 overthe 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.

Route Exchanging in the Scenario in Which the Customer Carrier Is a BGP/MPLSIP 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 thelabel.

Figure 3-19 Route exchanging in the scenario in which the customer carrier is a BGP/MPLS IP

VPN SP (different ASs)

L : I-L

First

Carrier

Second

Carrier

Second

Carrier


MP-EBGP10.1.1.1/32

CE4

D: PE2

L: L'

D : PE4N : PE1

L : L3 L : L2

MP-IBGP

IGP & LDP

AS:100 AS:200 AS:300

D: CE1L: L''2

MP-EBGP

D: PE4L: L''1

IGP & LDP IGP & LDP

D : PE4

N : CE1

L : L4

MP-IBGP

D: 10.1.1.1/32

D : PE4N : CE2

L : L1

MP-EBGP

D : PE4

N :PE2

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.

2. CE2 assigns label L1 to the route and advertises the route to PE2 using MP-EBGP.

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

VRP




25


29/62


carrier's backbone network and assigned label L' to the routes destined for itself. A public

network LSP has been established between PE2 and PE1.

4. PE1 assigns label L3 to the route and advertises the route to CE1 using MP-EBGP.

5. 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 andtherefore is not described here.

Packet Forwarding in the Scenario in Which the Customer Carrier Is a BGP/MPLSIP 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)

First

CarrierSecond

Carrier

Second

Carrier


10.1.1.1/32

CE4

IP packet

I-L

L3

IP packet

I-L

L1IP packet

IP packetI-L

L'' 1

IP packet

I-L

L'' 2

IP packet

I-L

L2

L'

L4

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 thepublic network LSP on the customer carrier network.

VRP




26


30/62

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

label of the packet.

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

3. PE1 replaces label L3 with label L2, adds label L', and forwards the packet to PE2 over the

public network LSP. Before the packet arrives at PE2, the penultimate LSR removes labelL'.

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

5. CE2 removes label L1, adds label L''1, and transparently forwards the packet to PE4 over

the public network LSP on the 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.

Benefits

The carrier's carrier model has the following advantages:

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.

l The customer carrier can flexibly plan addresses, as its addresses are independent of those

of the customers and the provider carrier.

l 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.

l 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 thefollowing disadvantages:

VRP




27


31/62

l 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.

l LCP and NCP negotiation is time-sensitive, and PPP session timeout may occur.

l L2TP does not apply to the scenario in which the physical positions and roles of multi-rolehosts are fixed.

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

VPN2

PC

CE1

CE2

CE3

PE1

PE2

PE3VPN1

Backbone

Policy-Based Routing

Static-Route

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 theForward 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 thepacket. PBR directs data streams to different VPNs generally based on IP addresses.

VRP




28


32/62

l 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 isthe 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 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.

l 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 Ensure the access for users, and thus require a great number of interfaces.

l Manage and advertise VPN routes, and process user packets. Thus, the PEs require large-

capacity 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 acentralized PE. For this reason, the solution is also called a Hierarchy of PE (HoPE).

VRP




29


33/62

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.

l 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.

l 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.

l 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.

l 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.

Architecture of an HoVPN

Figure 3-22 Architecture of an HoVPN

PESPE

UPE

UPE

PE

VPN1site2

VPN2

site3

VPN2

site2

VPN1site3

HoPE

VPN1

site1

VPN2

site1

CE

CE

CE

CE

CE

CE

VPN

backbone

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 calleda superstratum PE or an SPE.

VRP




30


34/62

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 throughMP-BGP.

l 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.

l 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 The SPE requires a large-capacity routing table, high forwarding performance, and less

interface resources.

l 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 An HoPE can function as a UPE, and compose a new HoPE with an SPE.

l An HoPE can function as an SPE, and compose a new HoPE with multiple UPEs.

l An HoPE can be embedded recursively in the preceding two modes.

The embedding of an HoPE can infinitely extend a VPN in theory.

VRP




31


35/62

Figure 3-23 Embedding of an HoVPN

CE CE CECE

UPE UPE

UPEMPE

SPE

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 InternetGenerally, 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 The devices that need to access the Internet have the route to the Internet.

l The Internet has the route to the devices.

l 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 followingmanners:

VRP




32


36/62

l 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.

l 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.

l 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 The Internet routes exist in the public routing table of the PE.

l The routing information about users exists in the VPN routing table of the PE, and does

not exist in the public routing table.

l 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

VPN siteCE PE

Internet

VPN

backbone

InternetGateway

To implement the interconnection between a VPN and the Internet on a PE, generally, default

static routes are used.

l The PE sends a default route destined for the Internet to the CE.

l A default route destined for the Internet gateway is added to the VPN routing table.

l

To ensure that the Internet has a route to the VPN, a static route with the destination addressas the CE and the next hop as the PE interface that connects the CE needs to be added to

VRP




33


37/62

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

VPN site

CE PE

Internet

VPN

backbone

VPN-instance

Internet

Gateway

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, allthe 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.

VRP




34


38/62

Figure 3-26 Direct access of the CE to the Internet

VPN siteCE PE

Internet

VPN

backbone

l 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

VPN site

CE

PE

Internet

VPN

backboneVPN-instance

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 networkaddress.

VRP




35


39/62

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

Documents

BGP MPLS IP VPN Features.pdf