rst-253 5444 05 2002 c1 - net130.com · © 2002, cisco systems, inc. all rights reserved. 3 rst-253...


Deploying MPLS VPNsSession RST-253

James WuTechnical Consultant

Cisco Systems – Asia PacCCIE #5514


Agenda

• Assumptions• MPLS VPN State of the Union• Quick MPLS VPN Overview• MPLS VPNs from the Customer

Perspective• New Stuff


Assumptions

• You should already understand…Basic MPLS forwarding (push/pop/swap)BGP/IGP/IP routing and forwardingSome MPLS-VPN basics (RD/RT, stacking)


Agenda




Cisco’s MPLS Is Proven140+ Deployments Today

Americas EMEA APT/Japan


1996 1997 1998 1999 2000 2001Time

MPLS TEDeployed

MPLS VPNDeployed

Large Scale Deployment

Cisco ShipsMPLS TE

Cisco ShipsMPLS (TagSwitching)

Cisco StandardizesTag Switching

at IETF

Evolution and Adoption of MPLS

Focus Area

AToM, OtherNew Stuff


BGP MPLS VPNs

• Most popular MPLS application• Deployed by majority of Cisco MPLS customers• Offer QoS-based services• Most common—Single private network

Many have also deployed it in a multi-AS environmentAlso overlaid are Internet and VPN on the same network200–400 PEs200–500 VPNs average with as many as 1000+ VPNs 4K sites per VPN

• Few deploying advanced features such as CsC


Agenda




MPLS VPN Terminology

• Provider network (P-network)The backbone under control of a service provider

• Customer network (C-network)Network under customer control

• CE routerCustomer Edge router; part of the C-network and interfaces to a PE router



• PE routerProvider edge router; part of the P-network and interfaces to CE routers

• P routerProvider (core) router, without knowledge of VPN



• Route-Target64 bits identifying routers that should receive the route

• Route DistinguisherAttributes of each route used to uniquely identify prefixes among VPNs (64 bits)VRF-based (not VPN-based)

• VPNv4 addressesAddress including the 64 bits Route Distinguisher and the 32 bits IP address



• MP-BGPMulti-protocol extensions to BGP

• VRFVPN routing and forwarding instanceRouting table and FIB tablePopulated by routing protocol contexts

• VPN-aware networkA provider backbone where MPLS-VPN is deployed

• VPN-aware applicationApps aware of VRF context: vrf-ping, vrf-trace…


VPNv4 Addresses

• New address family: VPNv4 addressesVPNv4 address = Route Distinguisher (RD) + IP addressMultiple RT associated with each routeRDs are assigned by a service providerRDs are globally unique (by virtue of assignment) Convert non-unique IP addresses into unique VPNv4 addresses

• Reachability information for VPNv4 addresses is carried via multiprotocol extensions to BGP-4


VPN A/Site 1

VPN C/Site 2

VPN A/Site 2

VPN B/Site 2

VPN B/Site 1

VPN C/Site 1

CEA1

CEB3

CEA3

CEA2

CE1B1

CE2B1

PE1

PE2

PE3

P1

P2

P3

16.1/16

12.1/1612.1/16

16.2/16

16.1/16 16.2/16RIPv2

Static

OSPF

RIPv2

BGP

OSPF

RIPv2BGP

12.2/1612.2/16

CEB2

MPLS VPN Routes Distribution

Step 2Step 2Step 4Step 4Step 1Step 1 Step 3Step 3

Step 5Step 5


MPLS VPN Example: 1—Simple Intranet

• One BGP extended community • At PE with directly attached site:

Exports all site’s routes into provider’s BGP with same route target (ext. community)Imports into the forwarding table associated with the VPN (sites) only routes with same route target

Multiple Sites with Full Mesh Connectivity


MPLS VPN Example: 2—Hub/Spoke VPN

• PE at a spoke sites:Export spoke site’s routes with a community spokeImport community hub into the forwarding table associated with the VPN (site) routes

• PE at the hub site:Import community spoke into the forwarding table associated with the VPN (site) routesExports hub site’s routes with community hubAdditional setup (2 VRFs/RDs) needed for centralized services at CE site

All Spoke Sites Communicate through Hub


Multiple Forwarding Tables

• PE maintains multiple forwarding tablesOne per set of directly attached sites with common VPN membershipe.g. One for all the directly attached sites that are in just one particular VPN

• Enables (in conjunction with route filtering) per VPN segregation of routing information on PE



• Each forwarding table is populated from:Routes received from directly connected CE(s) of the site(s) associated with the forwarding tableRoutes received from other PEs (via BGP) restricted to only the routes of the VPN(s) the site(s) is in via route filtering based on BGP extended community attribute



• Each customer port on PE is associated with a particular forwarding table

Via configuration (at provisioning time)Provides PE with per site forwarding information for packets received from CEsPorts on PE could be “logical”

e.g. VLAN, FR, ATM, L2TP, etc.


Packet Forwarding

• Forwarding based on extended (VPNv4) addresses

• MPLS binds VPNv4 routes to label switched paths

• Logically separate forwarding information base (FIB) for each VPN

FIB Table

1. Identify VPN

VPNv4 Route Label Info

2. Select FIBfor This VPN

3. Apply Labelto VPN

IP PKTIP PKTLabelLabel

Provider Edge LSR

4. Apply Labelto Next PEand Select Egress I/F

IP PKTIP PKTLabelLabel LabelLabel

IP PKTIP PKT


Agenda




Customer Perspective

• Customers are asking service providers specifically for MPLS-VPNs, rather than other {FR, ATM, IPSec, etc.} VPNs; why?

Unmanaged CE (customer doesn’t have to maintain more than one routing neighbor in the cloud)Remote access integration is a lot easierBecause it may come with a lower price tagBecause all the cool kids are doing it!


Agenda




New Services

• EIGRP PE-CE• Remote access• CSC• Inter-AS• L2 vs. L3 VPNs


EIGRP PE-CE

EIGRP Does

Run across Your Backbone!No Chasing SIAs!


EIGRP Route Propagation Behavior

MPLS VPN Backbone

AS-1 AS-110.1.x.x10.1.x.x10.3.x.x10.3.x.x

AS-210.2.x.x10.2.x.x


MPLS VPN Backbone

AS-1 AS-110.1.x.x10.1.x.x10.3.x.x10.3.x.x

AS-210.2.x.x10.2.x.x


EIGRP Routes Are Advertised into BGP Backbone Preserving the EIGRP Route Type and Metric Information in

the BGP Extended Community Attribute

EIGRP InternalEIGRP Internal EIGRP

InternalEIGRP Internal

EIGRP InternalEIGRP Internal


MPLS VPN Backbone

AS-1 AS-110.1.x.x10.1.x.x10.3.x.x10.3.x.x

AS-210.2.x.x10.2.x.x


BGP Redistributes Routes into EIGRP Using Route Type and Metric Information Extracted from BGP

Extended Community Information

EIGRP AS1: Internal

EIGRP AS2: External

EIGRP AS1: Internal

EIGRP AS2: External

EIGRP AS1: ExternalEIGRP AS1: External

EIGRP AS1: Internal

EIGRP AS2: External

EIGRP AS1: Internal

EIGRP AS2: External


OperationGeneral

• CE runs EIGRP as before• PE runs an EIGRP-VRF process per vrf/AS but

not limited to 28 like OSPF; it is like RIPv2/BGP that use address families

• EIGRP routes are distributed to sites customer via MP-iBGP on the MPLS-VPN backbone

• Each EIGRP-VRF process needs to be redistributed into MP-iBGP and vice versa

• MP-iBGP will carry extended community information across the MPLS-VPN backbone to other customer sites


MPLS VPN Backbone

AS-1 AS-110.1.x.x10.1.x.x10.3.x.x10.3.x.x


Network Topology Like This…

EIGRP AS1: InternalEIGRP AS1: InternalEIGRP AS1: InternalEIGRP AS1: Internal



…Customer Routing Topology Like This

AS-1 AS-110.1.x.x10.1.x.x10.3.x.x10.3.x.x

EIGRP AS1: InternalEIGRP AS1: InternalEIGRP AS1: InternalEIGRP AS1: Internal

MPLS VPN Backbone


OperationGeneral

• BGP Basic Configurationaddress-family ipv4 vrf <vrf-name>

redistribute connectedredistribute EIGRP <AS>no auto-summaryno synchronization

exit-address-family


New Extended Communities

• MPLS/VPN backbone is BGP• There is no EIGRP, no EIGRP adjacencies

and no EIGRP updates in MPLS/VPN backbone

• EIGRP information is carried across MPLS/VPN backbone by BGP in new extended communities (set and used by PE’s)

• Backbone adds zero cost to a route


New Extended Communities

• EIGRP uses extended communities 0x8800-0x8805 to carry various routing information in BGP

• Need to allow these extended communities across your backbone for routes to arrive properly at the importing side


OperationPE: Non-EIGRP Routes

• If a route is received via BGP, and the route has no extended community information for EIGRP:

The route is advertised to the CE as an external EIGRP route using the default metric; if not default metric is configured, the route will not be advertised to the CE


OperationPE: Internal Routes

• If a route is received via BGP, and the route has extended community information for EIGRP:

If the route type is“internal” and the source AS matched

The route is advertised to the CE as an internal EIGRP route using the extended community information


OperationPE: External Routes

• If a route is received via BGP, and the route hasextended community information for EIGRP:

If the route type is“internal” and the source AS does not matchorroute type is “external”

The route is advertised to the CE as an external EIGRP route; the route will not use the extended community information as it did not originate from the same AS


Configuration Single Instance

router EIGRP 1network 10.0.0.0address-family ipv4 vrf vrf-red

network 42.0.0.0autonomous-system 42redistribute BGP 100 metricno auto-summaryno eigrp log-neighbor-changes

exit-address-familyaddress-family ipv4 vrf vrf-green

network 49.0.0.0anonymous-system 99redistribute BGP 101 metricno auto-summaryno eigrp log-neighbor-changes

exit-address-familyno eigrp log-neighbor-changes

Commands for Default Routing Table

Commands for vrf-red

Commands for vrf-green

More Commands for Default Routing Table


New Services



Dial in SessionEncapsulation PPP


Dial In Architectures Overview

CE RouterLNS/PE

LAC

PE RouterAAA Server

MPLS Cloud

SP AAA Server

Platform List LNS/PE:• 36x0• 6400 NRP1 and NRP2 • 7200 with NPE board—Not NSE-1( toaster chip has to be turned off

to make this board work—Chip turned off automatically in IOS with CSCds59844 integrated)

• 7500 RSP4 and RSP8

POP IP Cloud

P RouterP Router

PPP Session (Virtual-access)Inserted in Customer

VPN Network


VPN Network

PPP SessionForwarded via L2TP

PPP SessionForwarded via L2TP

VPN Dial Clientfor VPN Customer 1

VPN Dial Clientfor VPN Customer 1

Customer 1Customer 1

Scenario 1: L2TP Dial in ScenarioScenario 1: L2TP Dial in Scenario



Closer Look at LAC:• Access VPN service = L2TP—Only requirement on LAC

therefore: IOS image on LAC should support VPDN services; purpose is to bring the dial in session over to an MPLS edge device; the VPDN service are not at all made VRF aware on the LAC—the L2TP endpoint is located in the global IP routing table!

• LAC will forward sessions to LNS/PE based on:Domain DNIS

• L2TP information to construct L2TP tunnel to LNS/PE:Configured locally on LACFrom SP radius serverFrom a RPMS server

Scenario 1: L2TP Dial in ScenarioScenario 1: L2TP Dial in Scenario


Dial In Architectures OverviewLNS/PE Requirements, Restrictions, and Capabilities:• Access VPN service = session forwarded from LAC to LNS/PE

via L2TP; LNS/PE is endpoint for L2TP tunnel—L2TP tunnel uses global IP routing table; it are the PPP sessions in the L2TP that are inserted in the MPLS VPN network, not the L2TP tunnel!!

• Authentication & Authorization for incoming PPP sessions:Locally on LNS/PEAAA via radiusProxy AAAPer VPN AAA

• Support for non-MLPPP dial in clients as for MLPPP dial in clients• IP address assignment to dial in PPP sessions:

LNS/PE can use a fixed IP address for the dial in clientLNS/PE can handout IP addresses from a local (overlapping) pool Address assignment can be done by the SP AAA radius serverAddress assignment via ODAP (On Demand Address Pools)



Platform List NAS/PE:• 36x0• 7200 with NPE board—Not NSE-1( toaster chip has to be turned off to

make this board work—Chip turned off automatically in IOS withCSCds59844 integrated)

!!Only ISDN calls supported: No modem, V.110 or V.120 calls!!

CE RouterNAS/PE PE Router

AAA Server

MPLS CloudMPLS Cloud

SP AAA Server

P RouterP Router


VPN Network


VPN Network

Customer 1Customer 1

Scenario 2: Direct Dial in ScenarioScenario 2: Direct Dial in Scenario


Dial in SessionEncapsulation PPPVPN Dial Client

for VPN Customer 1VPN Dial Client

for VPN Customer 1


Dial In Architectures OverviewNAS/PE Requirements, Restrictions, and Capabilities:• Authentication & Authorization for incoming PPP

sessions:AAA via radiusProxy AAAPer VPN AAA on NAS/PE restricted (only in L2TP sessions)Local A&A on NAS/PE restricted (only in L2TP sessions)

• IP address assignment to dial in PPP sessions:LNS/PE can use a fixed IP address for the dial in clientLNS/PE can handout IP addresses from a local (overlapping) pool Address assignment can be done by the SP AAA radius serverAddress assignment via ODAP (On Demand Address Pools)


DSL Aggregation Solutions Overview

• RFC1483 MPLS VPN• PPPoX MPLS VPN• RBE MPLS VPN• L2TP MPLS VPN


RFC1483Model

• RFC1483 interfaces are statically assigned to VRF• Can run RIP, BGP across upstream interfaces• ADSL provider cannot offer service selection

ADSL

6400-PE6400-PE

6400-PE6400-PE

MPLSMPLS

IP over RFC1483IP over RFC1483

ISP1ISP1

ISP2ISP2

CECE

CECE

CentralSite

CECE

CentralSite

CentralSite

CECE

ADSL


PPPoX MPLS VPNPPP to Dynamic VPN

• Single card solution • PPP session dynamically selects VRF

through Radius• PE-NRP terminates PPP sessions (Radius and Proxy only)

ADSL

ADSL

PPPPPP

CentralSite

CECE

CentralSite

CentralSite

CECEPE-NRPPE-NRP

RADIUS

PP

MPLS BackboneMPLS Backbone

PEPE

PEPE


RBE and MPLS-VPN

• Appropriate for wholesale DSL provider who wants to migrate L2 core (current PTA solution) to L3 core

• Subscribers are assigned to NSP VPN as part of the provisioning process

• Address assignment done via DHCP to SP server (can use VPN-ID)

BridgedBridged

ADSL

ADSL

CentralSite

CECE

CentralSite

CentralSite

CECEPEPE

PEPE

NRPNRPPP



L2TP MPLS VPN Model

• L2TP tunnel between LAC and LNS • LNS/NAP terminates L2TP/PPP sessions and routes into

MPLS VPN• AAA, Local A&A, Proxy AAA, Per-VRF AAA

LACLAC

ADSL

ADSL

CentralSite

CECE

CentralSite

CentralSite

CECEPEPE

PEPE

PP


6400LNS/PE

6400LNS/PE

RADIUS


New Services



Carrier’s Carrier Architecture

• Labels exchanged between PE and CE• Labels are for some or all of CE’s IGP

At a minimum, labels for all CEs within the CSC VPN

• Motivation here is to put an Internet provider in a VPN

Can’t hold very many full Internet tables on a single PECSC much more scalable—O(CE-IGP) or O(CEs), not O(Internet)


Carrier’s Carrier Architecture

• iBGP used by ISP to distribute external routing information between all sites

• BGP next-hop addresses exchanged between ISP and Carrier PE routers

And are placed into VRFs and distributed using MP-BGP

• MPLS with LDP label distribution used on PE-CE links

To provide end-to-end LSP between ISP sites• Only need to run MPLS on the PE-CE link (and

PE core), not necessary in CE network


ISP Customers

ISP Customers

ISP London Site

ISP Paris Site

MPLS VPN Carrier Backbone

Exchange of BGP RoutesExchange of BGP Routes

ASBR-1

ISP Internal Routes IPv4 + LDP


MP-BGP Session for VPNv4 Prefix Exchange

MP-BGP Session for VPNv4 Prefix Exchange



PE1 PE2

Carrier’s Carrier Architecture No MPLS Needed within ISP Sites

ASBR-2


Network Y

BGP-4 Net=Y NH=ASBR-1IGP

Net=ASBR-1

BGP-4 Net=Y NH=ASBR-1

Net=ASBR-1 NH=CE-1

Label=POP

VPNv4 Net=ASBR-1

NH=PE-1 Label=75

IGP + LDP Net=PE-1

Label=POP

IGP + LDP Net=PE-1 Label=17

IGP + LDP Net=ASBR-1

Label=55

IGP Net=ASBR-1

CE-2

BGP-4 Net=Y NH=ASBR-1

Carrier’s Carrier Architecture No MPLS within ISP Sites

PE1 PE2

ASBR-1 ASBR-2

ISP Customers

CE-1


Network Y

Dest=Y

Dest=Y

Dest=Y55

75 Dest=Y17Dest=Y75

Dest=Y

Dest=Y

Dest=Y

CE-2

ASBR-1

PE1 PE2

ASBR-2

CE-1

Carrier’s Carrier Architecture No MPLS within ISP Sites

ISP Customers


New Services



VPN Client Connectivity

• VPN sites may be geographically dispersed Requiring connectivity to separate MPLS VPN service providers

• Transit between VPN sites may pass through multiple providers MPLS backbones

This implies exchange of VPN routing information between providersProvider backbones may or may not provide VPN service directly

• Referred to as multi-provider VPN or inter-provider VPN or inter-AS VPN


VPN Client Connectivity

VPN-A-1VPN-A-2

PE-1PE-1

PE2PE2

CE2 CE2

Edge Router1Edge Router1 Edge Router2Edge Router2

CE-1 CE-1

VPN Sites Attached to Different MPLS VPN Service Providers

VPN Sites Attached to Different MPLS VPN Service Providers

AS #1 AS #2

149.27.2.0/24149.27.2.0/24

VPN-v4 update:RD:1:27:149.27.2.0/24,

NH=PE-1RT=1:231, Label=(28)

BGP, OSPF, RIPv2 149.27.2.0/24,NH=CE-1

VPN-A VRFImport Routes withroute-target 1:231

How to Distribute Routes between

SPs?

How to Distribute Routes between

SPs?


VPNv4 Distribution Options

PE-1PE-1

PE-2PE-2

CE-2 CE-2

Back-to-back VRFs

MP-eBGP for VPNv4

Multihop MP-eBGPbetween RRs

Non-VPN Transit Provider

Several Options Available for Distribution of VPNv4 Prefix Information

Several Options Available for Distribution of VPNv4 Prefix Information

AS #1 AS #2

PE-ASBR-1PE-ASBR-1 PE-ASBR-2PE-ASBR-2

CE-1 CE-1

Multihop MP-eBGP

VPN-A-1 VPN-A-2


Option 1: Back-to-back VRF Connectivity

• MPLS VPN providers exchange routes across VRF interfaces

VRF represents a particular VPN client• Each PE-ASBR router treats the other as a CE

Although both provider interfaces associated with a VRF

• Provider edge routers are gateways used for VPNv4 route exchange

• PE-ASBR to PE-ASBR link may use any supported PE-CE routing protocol

Currently OSPF, BGP-4, RIPv2, and static


PE-1PE-1PE-2PE-2

AS #1 AS #2

CE-1 CE-1

VPN-A-1 VPN-A-2

Back-to-back VRF Connectivity

VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2

VRF to VRF Connectivity between PE-ASBRs VRF to VRF Connectivity between PE-ASBRs

One Logical Interface and VRF

per VPN Client

CE-4 CE-4



PE-1PE-1PE-2PE-2


VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2


152.12.4.0/24152.12.4.0/24


VPN-v4 update:RD:1:27:152.12.4.0/24,

NH=PE-1RT=1:222, Label=(29)

VPN-B VRFImport routes withroute-target 1:222

BGP, OSPF, RIPv2 152.12.4.0/24

NH=PE-ASBR1

VPN-v4 update:RD:1:27:152.12.4.0/24,

NH=PE-ASBR-2RT=1:222, Label=(92)

VPN-B VRFImport routes withroute-target 1:222

BGP, OSPF, RIPv2 152.12.4.0/24,NH=PE-2



PE-1PE-1PE-2PE-2


VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2152.12.4.0/24152.12.4.0/24


152.12.4.1

LDP PE-ASBR-2 Label92

152.12.4.1152.12.4.1

LDP PE-1 Label29

152.12.4.1

152.12.4.1



Option 2: External MP-BGP for VPNv4 Prefix Exchange

• Gateway PE-ASBRs exchange routes directly using BGP

External MP-BGP for VPNv4 prefix exchange; no LDP or IGP

• MP-BGP session with next-hop set to advertising PE-ASBR

Next-hop and labels are rewritten when advertised across the inter-provider MP-BGP session

• PE-ASBR stores all VPN routes that need to be exchanged

But only within the BGP tableNo VRFs; labels are populated into the LFIB of the PE-ASBR


External MP-BGP for VPNv4

• Receiving gateway PE-ASBRs may allocate new label if desired

Controlled by configuration of next-hop-self (default is off)

• Receiving PE-ASBR will automatically create a /32 host route for its PE-ASBR neighbor

Which must be advertised into receiving IGP if next-hop-self is not in operation to maintain the LSP

• PE-ASBRs need to hold all inter-AS VPN routes


PE-1PE-1PE-2PE-2

AS #1 AS #2

CE-1 CE-1

VPN-A-1 VPN-A-2VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2

CE-4 CE-4



MP-BGP VPNv4 Prefix Exchange between Gateway PE-ASBRs

MP-BGP VPNv4 Prefix Exchange between Gateway PE-ASBRs

MP-eBGP for VPNv4

MP-eBGP for VPNv4

Label Exchangebetween GatewayPE-ASBR RoutersUsing MP-eBGP


AS #1 AS #2


PE-1PE-1PE-2PE-2

VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2


152.12.4.0/24152.12.4.0/24


VPN-v4 update:RD:1:27:152.12.4.0/24,

NH=PE-1RT=1:222, Label=(L1)

VPN-v4 update:RD:1:27:152.12.4.0/24,

NH=PE-ASBR-2RT=1:222, Label=(L3)


VPN-v4 update:RD:1:27:152.12.4.0/24,





152.12.4.1

LDP PE-ASBR-2 Label L3

152.12.4.1

152.12.4.1L3

L2 152.12.4.1

LDP PE-1 LabelL1

152.12.4.1

152.12.4.1 L1

152.12.4.1

PE-1PE-1

VPN-B-1VPN-B-1

CE-2CE-2

152.12.4.0/24152.12.4.0/24

PE-2PE-2

CE-3 CE-3

VPN-B-2VPN-B-2


Option 3: Multi-Hop External MP-BGP for VPNv4

• External MP-BGP between PE-ASBR routers just as in option 2

• PE-ASBR routers exchange routes across a multi-hop BGP session

External MP-BGP for VPNv4 prefix exchange

• IGP and LDP required between PE-ASBR routersTo maintain the end-to-end internal LSPStatic routing to interface addresses may also be used

• No /32 host route created for adjacent PE-ASBR routers


PE-1PE-1PE-2PE-2

AS #1 AS #2

CE-1 CE-1

VPN-A-1 VPN-A-2

CE-4 CE-4


Multi-Hop Session between Gateway PE-ASBRs Multi-Hop Session between Gateway PE-ASBRs

Multi-Hop MP-eBGPfor VPNv4

Multi-Hop MP-eBGPfor VPNv4

IGP and LDPIGP and LDP

Multi-hop External MP-BGP for VPNv4


PE-1PE-1PE-2PE-2

VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2


152.12.4.0/24152.12.4.0/24


VPN-v4 update:RD:1:27:152.12.4.0/24,


VPN-v4 update:RD:1:27:152.12.4.0/24,



IGP & LDP exchange of PE-ASBR-1


VPN-v4 update:RD:1:27:152.12.4.0/24,




PE-1PE-1

VPN-B-1VPN-B-1

CE-2CE-2

152.12.4.0/24152.12.4.0/24

PE-2PE-2

CE-3 CE-3

VPN-B-2VPN-B-2

152.12.4.1

LDP PE-ASBR-2 LabelL3

152.12.4.1

152.12.4.1L3

LDP PE-1 LabelL1

152.12.4.1

152.12.4.1L1

152.12.4.1


152.12.4.1



Option 4: Multihop MP-eBGP for VPNv4 between RRs

• MPLS VPN providers exchange VPNv4 prefixes via their route reflectors

Requires Multihop MP-eBGP (VPNv4 routes)

• Next-hop-self must be disabled on route reflectorPreserves next-hop and label as allocated by the originating PE router

• Providers exchange IPv4 routes with labels between directly connected ASBRs using eBGP

Only PE loopback addresses exchanged as these are BGP next-hop addresses


PE-1PE-1PE-2PE-2

AS #1 AS #2

CE-1 CE-1

VPN-A-1 VPN-A-2VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2

CE-4 CE-4

Multihop MP-eBGP for VPNv4 between RRs

Multihop MP-eBGP VPNv4 prefix Exchange between Route Reflectors

Multihop MP-eBGP VPNv4 prefix Exchange between Route Reflectors

ASBR-1ASBR-1

RR-2RR-2Multihop MP-eBGPfor VPNv4 with no

next-hop-self

Multihop MP-eBGPfor VPNv4 with no

next-hop-self

ASBRs Exchange BGPnext-hop Addresses

with Labels

ASBR-2ASBR-2

RR-1RR-1

eBGP IPv4 + LabelseBGP IPv4 + Labels


VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2

ASBR-1ASBR-1

RR-2RR-2

ASBR-2ASBR-2

RR-1RR-1


Network=PE-1 NH=ASBR-1Label=(L2)


152.12.4.0/24152.12.4.0/24

VPN-v4 update:RD:1:27:152.12.4.0/24,


VPN-v4 update:RD:1:27:152.12.4.0/24,


VPN-v4 update:RD:1:27:152.12.4.0/24,



Network=PE-1 NH=ASBR-2Label=(L3)PE-1PE-1

PE-2PE-2


VPN-B-1VPN-B-1

CE-2CE-2 CE-3 CE-3

VPN-B-2VPN-B-2

ASBR-1ASBR-1

RR-2RR-2

ASBR-2ASBR-2

RR-1RR-1

152.12.4.0/24152.12.4.0/24

PE-1PE-1PE-2PE-2


152.12.4.1

L1 LDP PE-ASBR-2 LabelL3 L1

152.12.4.1

152.12.4.1L3

L2 L1 152.12.4.1

LDP PE-1 LabelL1

152.12.4.1152.12.4.1L1

152.12.4.1


Option 5: Non-VPN Transit Provider

• Two MPLS VPN providers may exchange routes via one or more third parties

Which are non-VPN transit backbones running MPLS

• Multihop MP-eBGP deployed between edge providers

With the exchange of BGP next-hops via the transit provider

• Providers may use the same AS# within each region or different AS#

Transit network is not part of the AS path



• Requirement to propagate BGP next-hops and also build end-to-end LSPs

• Several options for end-to-end LSP creationOption 1: Merge IGPs of all AS’s including the

transit networkOption 2: Redistribute PE host routes

between AS’sOption 3: Use static routes across boundaries and

redistribution into IGPOption 4: Use IPv4 + labels


CE-2CE-2

VPN-B-1VPN-B-1


PE-2PE-2

CE-3 CE-3

VPN-B-2VPN-B-2

ASBR-1ASBR-1

RR-2RR-2

Multihop MP-eBGP orMP-iBGP for VPNv4

ASBR-2ASBR-2

RR-1RR-1ASBR-3ASBR-3

ASBR-4ASBR-4NO next-hop-selfNO next-hop-self

eBGP IPv4 + Labels

eBGP IPv4 + Labels

MPLS VPN Provider #1


eBGP IPv4 + Labels

eBGP IPv4 + Labels eBGP IPv4 + Labels

PE-1PE-1

Non-VPN MPLSTransit Backbone


PE1PE1

CE-2CE-2

VPN-B-1VPN-B-1 PE-2PE-2

CE-3 CE-3

VPN-B-2VPN-B-2

ASBR-1ASBR-1

RR-2RR-2


ASBR-2ASBR-2

ASBR-3ASBR-3

ASBR-4ASBR-4



152.12.4.0/24152.12.4.0/24


152.12.4.0/24,NH=PE-1

RT=1:222, Label=(L1)


152.12.4.0/24, NH=PE-1RT=1:222, Label=(L1)

152.12.4.0/24,NH=PE-1

RT=1:222, Label=(L1)




RR-1RR-1

End-to-End LSP(Forwarding Path)End-to-End LSP

(Forwarding Path)

Inner Label Exchange

Inner Label Exchange


CE-2CE-2

VPN-B-1VPN-B-1PE-2PE-2

CE-3 CE-3

VPN-B-2VPN-B-2

ASBR-1ASBR-1

RR-2RR-2


ASBR-2ASBR-2

ASBR-3ASBR-3

ASBR-4ASBR-4

152.12.4.0/24152.12.4.0/24

RR-1RR-1


CE-3 CE-3


152.12.4.1


L1152.12.4.1

152.12.4.1L1L4


L1152.12.4.1

L1L2 152.12.4.1LDP PE-1 Label

L1 152.12.4.1

L1 152.12.4.1

PE1PE1


New Services



L2 vs. L3 VPNs

L3VPNL3VPN

L3VPN Is Better Suited for PurePrivate IP Networks L3VPN Is Better Suited for PurePrivate IP Networks

L2VPNL2VPN

L3VPNs Can Offer IP-based DSCPQoS with QoS TransparencyL3VPNs Can Offer IP-based DSCPQoS with QoS Transparency

CsC Can Be Used for Scalingwhen the SP’s Customers Are ISPswith Full Internet Routing Tables

CsC Can Be Used for Scalingwhen the SP’s Customers Are ISPswith Full Internet Routing Tables

L3VPNs Is Less Work—They Don’tHave to Manage WAN Routing FullMesh vs. Hub-and-spoke

L3VPNs Is Less Work—They Don’tHave to Manage WAN Routing FullMesh vs. Hub-and-spoke

L2VPN Is the Good Choice forNon-IP Traffic L2VPN Is the Good Choice forNon-IP Traffic

L2VPNs Can Offer QoS by Copying QoS Bits (e.g. 802.1P) into the EXP Bits

L2VPNs Can Offer QoS by Copying QoS Bits (e.g. 802.1P) into the EXP Bits

L2VPN May Be Preferable WhereISPs May Not Trust Other (I)SPs toTransport Their Routes Across

L2VPN May Be Preferable WhereISPs May Not Trust Other (I)SPs toTransport Their Routes Across

L2VPNs Offer Customers Choice of Doing Their Own RoutingL2VPNs Offer Customers Choice of Doing Their Own Routing


Recommended Reading

MPLS and VPN Architectures, CCIP Edition ISBN: 1-58705-081-1

Available On-site at the Cisco Company StoreAvailable On-site at the Cisco Company Store


Thank You!


Deploying MPLS VPNsSession RST-253


Please Complete Your Evaluation Form

Session RST-253

rst-253 5444 05 2002 c1 - net130.com · © 2002, cisco systems, inc. all rights reserved. 3 rst-253...

Documents