1 MPLS Bootcamp © 2000, Cisco Systems, Inc. Cisco Confidential MPLS Bootcamp MPLS VPN Khalid Raza,...

MPLS BootcampMPLS VPN

Khalid Raza, Kyle Bearden, &

Munther Antoun

March, 2001

Version 0.1

Khalid Raza, Kyle Bearden, &

Munther Antoun

March, 2001

Version 0.1

MPLS VPNAgenda

• VPN Concepts

• MPLS VPN Functional Components

• MPLS VPN Architectural Components

• VPN Routing & Forwarding

• MPLS VPN Route Distribution

• MPLS VPN Data Plane

• MPLS VPN Topologies

• Convergence & Scaling Considerations

• QoS

• Deployment Strategies

• MPLS VPN Labs

Virtual Private Networks

ConceptsConcepts

Virtual Private NetworksVirtual Private Networks

• An IP Network Infrastructure Delivering Private Network Services over a Public Infrastructure

Certainly not a new concept

Leased Lines --> Statistical Multiplexing

Delivered at Layer-2 (SP backbone) or Layer-3 (IP backbone)

Private connectivity amongst multiple sites

Controlled access into the VPN

Global or non-unique private IP addressing space amongst the different VPNs

Virtua l Networks

V irtua l Private Networks V irtua l D ia lup Networks V irtua l LANs

O verlay VPN Peer-to-Peer VPN

Layer-2 VPN Layer-3 VPN

X.25 F /R ATM G RE IPSec

Access lists(Shared router)

Split routing(Dedicated router)

M PLS/VPN

Virtual Private NetworksVirtual Private Networks

VPN - Overlay ModelVPN - Overlay Model

Service Provider Network

Provider Edge (PE) device

VPN Site VPN Site

Virtual Circuit

CPE (CE) Device

Layer-3 Routing Adjacency

Private Trunks Across a Telco/SP Shared Infrastructure

Leased/Dialup LinesFR/ATM Virtual CircuitsIP(GRE) Tunnelling

Point-to-point Solution between Customer SitesHow to Size Inter-site Circuit Capacities?Full Mesh Requirement for Optimal RoutingCPE Routing Adjacencies between Sites

Provider Edge Router

VPN Site 1 VPN Site 2

CPE Router CPE Router

Layer-3 Routing Adjacencies

VPN - Peer-to-Peer ModelVPN - Peer-to-Peer Model

Provider Edge Device Exchanges Routing Information with CPEAll customer routes carried within SP IGPSimple routing scheme for VPN customerRouting between sites is optimalCircuit sizing no longer an issue

Private Addressing is NOT an OptionAddition of New Sites is Simpler

No overlay mesh to contend with

Provider Edge (PE) Router

VPN Site 1 VPN Site 2

Customer Edge (CE)

Router

Customer Edge (CE) Router

Static, RIP, OSPF, or eBGP Routing

VPN - MPLS VPN ModelVPN - MPLS VPN Model

Combines Benefits of Overlay and Peer-to-peer Paradigms Overlay (security and isolation amongst customers)Peer-to-peer (simplified customer routing)

PE Routers only Hold Routes for Attached VPNsReduces size of PE routing informationProportional to number of VPNs attached

MPLS Used to Forward Packets (not Traditional IP Routing)Full routing within backbone no longer required

MP-iBGP Session

MPLS VPN Functional Components

MPLS VPN Connection ModelThe Whole Picture

VPN_B10.3.0.0

10.1.0.0

11.5.0.0

10.1.0.0

10.2.0.0

11.6.0.0

10.2.0.0

iBGP sessions

• P Routers (LSRs) are in the core of the MPLS cloud

• PE Routers (Edge LSRs or LERs) use MPLS with the core and plain IP with CE routers

• P and PE routers share a common IGP

• PE routers are MP-iBGP fully-meshed

or use Route-Reflectors (RRs)

Confederations supported in IOS 12.1(5)T & higher [maybe also 12.0(14)ST?]

P-Network

PE Router PE Router

C-Network

CE Router CE Router

VPN Site

P Router

VPN Site

MPLS VPN ModelMPLS VPN Model

MPLS VPN Connectivity ModelMPLS VPN Connectivity Model

• A VPN is a collection of sites sharing common routing information

Same set of routes within the routing table

• A site may belong to more than one VPN

through sharing of routing information

• A VPN can be thought of as a closed user group (CUG) or community of interest

MPLS VPN Architectural Components

MPLS VPNArchitectural Components

• Control Planes

LDP/TDP, MP-BGP, CE-PE Peering, IGP

Forwarding Table

• Data Plane

• PEs Maintain Separate Routing Tables

Global Routing Table

Contains all PE and P routes (perhaps non-VPN BGP)

Populated by the VPN backbone IGP

VRF (VPN Routing & Forwarding)

Routing & forwarding table associated with one or more directly connected sites (CE Routers)

VRF is associated with any type of interface, whether logical or physical (e.g. Sub/Virtual/Tunnel)

Interfaces may share the same VRF if the connected sites share the same routing information

VPN Routing & Forwarding Instance (VRF)

VPN Routing & Forwarding Instances (VRF)

CEVPN-B

Global Routing Table

VRF for VPN-A

VRF for VPN-B

VPN Routing Table

Multiple routing & forwarding instances (VRFs) provide

separation amongst different customers

IGP & non-VPN BGP

London

Munich

MPLS VPN Connectivity ModelMPLS VPN Connectivity Model

• Private addressing in multiple VPNs no longer an issue

Provided that members of a VPN do not use the same address range

VPN B VPN C

London

Paris Munich

Brussels Vienna

Address space for VPN A and B must be

unique

10.2.1.0/24 10.22.12.0/24

10.2.1.0/24 10.3.3.0/24 10.2.12.0/24

10.4.12.0/24

VRF Route PopulationVRF Route Population

• VRF populated locally through PE and CE routing protocol

RIP, OSPF, BGP-4 & Static routing

• Separate routing context for each VRF

Routing Protocol Context (BGP-4 & RIP V2)

Separate Process (OSPF)

Site-2

Site-1

EBGP,OSPF, RIPv2,Static

VRF Route DistributionVRF Route Distribution

• PE routers distribute local VPN information across the MPLS VPN backbone

through MP-iBGP & redistribution from VRF

Receiving PE imports routes into attached VRFs

PE PE CE Router CE Router

P Router

Site Site MP-iBGP

Multi-Protocol BGP (MP-BGP) VPN Components

• Route Distinguisher (RD)

• Route Target (RT)

• Site of Origin (SOO)

MP-BGPVPN Components

VPN Routing & ForwardingInstances

• The global (non-VRF) routing table is populated through IGP protocols

May also contain BGP-4 (IPv4) routes

No VPN routes

• VRF routing tables contain VPN-specific routes

MP-iBGP routes imported into VRFs

CE routes populate VRFs based on routing protocol context

MPLS VPN Table PopulationMPLS VPN Table Population

VRF Population of MP-iBGPVRF Population of MP-iBGP

CEVPN-B

VRF VPN-A VRF VPN-B

MP-iBGP

BGP Table

Routes from VPN-A Routes from VPN-B

Re-distribution from VRFs into MP-iBGP for VPN information exchange

London

Munich

VRF Population through MP-iBGPVRF Population through MP-iBGP

• Receiving PE router needs to understand:

where the route originated from

into which VRF(s) the route should be placed

how to distinguish between duplicate addresses

• Uniqueness of IPv4 prefix achieved through the use of a Route Distinguisher

RD (64-bit) identifier

VPNv4 Route: 96-bit NLRI (RD + 32-bit IPv4 NLRI)

Extended Community AttributeExtended Community Attribute

• Permits placement in the proper VRF and site origin

• BGP transitive optional attributes containing a set of extended communities

Route Target

Identifies set of sites to which a particular route should be exported

SOO (Site of Origin)

(Optionally) refers to the site that originated a particular route

MP-iBGP

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

VPN-v4 update:RD:1:27:149.27.2.0/24, Next-hop=PE-1SOO=Paris, RT=VPN-A, Label=(28)

• PE Routers Translate (32-bit) IPv4 Prefix into (96-bit) VPN-v4 Route

Assign a RD, RT and (Optional) SOO based on configurationRe-write next-hop attribute (to PE loopback)Assign a label based on VRF and/or interface

Send MP-iBGP update to all PE neighbors

Paris London

• VPN-V4 Address

Route Distinguisher (64 bits)

Makes the IPv4 route globally unique

RD is configured in the PE for each VRF

RD may or may not be related to a site or a VPN

IPv4 address (32bits)

• Route Target (RT) & Optional Site of Origin (SOO)

MP-iBGP UpdateMP-iBGP Update

• Any other standard BGP attribute

Local PreferenceMEDNext-hopAS_PATHStandard community

• A Label identifying: The outgoing interface or VRF where a lookup has

to be performed (Aggregate/Connected)

MP-iBGP utilizes a second label in the label stack

MP-iBGP

ip vrf VPN-B

route-target import VPN-AVPN-v4 update:RD:1:27:149.27.2.0/24, Next-hop=PE-1SOO=Paris, RT=VPN-A, Label=(28)

• Receiving PE routers translate to IPv4

Insert the route into the VRF identified by the RT

attribute (based on PE configuration)

• The label associated to the VPN-V4 address will be set on packets forwarded towards the destination

VPN-v4 update is translated into IPv4 address and put into VRF VPN-A as RT=VPN-A and optionally advertised to CE-2

Paris London

P RouterP Router

MPLS VPN BackboneMPLS VPN BackboneVPN A VPN A

SITE-2SITE-2

Site-1 routes Site-1 routes Site-2 routes Site-2 routes Site-3 routes Site-3 routes Site-4 routesSite-4 routes

MP-iBGP

Basic Intranet ModelBasic Intranet Model

Site-3 & Site-4 routes Site-3 & Site-4 routes RT=VPN-A RT=VPN-A

Site-1 & Site-2 routes Site-1 & Site-2 routes RT=VPN-ART=VPN-A

Site-1 routes Site-1 routes Site-2 routes Site-2 routes Site-3 routes Site-3 routes Site-4 routesSite-4 routes

SITE-1SITE-1 SITE-3SITE-3

SITE-4SITE-4

MP-BGPRoute Target (RT)

andSite of Origin (SOO)

MP-BGPRoute Target (RT)

andSite of Origin (SOO)

RT & SOO

• Two EXTENDED (64-bit) BGP Attributes Used to DefineRoute-target

Set of routers the route has to be exported to

SOO (Site of Origin Identifier)

Routers where the route has been originated

• This enables the closed user group functionality

• Set by PE routers in order to define import/export policies on a per-site/VRF basis

BGP-4 EnhancementsBGP-4 Enhancements

Extended Community

• Extended community attribute type code: TBD

Type Field: 2 bytesValue Field: 6 bytes

• Types 0 through 0x7FFF inclusive are assigned by IANA

• Types 0x8000 through 0xFFFF inclusive are vendor-specific

Extended Community

• High order bit of the type field 0x00 Administrator sub-field: 2 bytes (AS#)

Assigned number sub-field: 4 bytes

Example: 9177:123

• High order bit of the type field 0x01Administrator sub-field: 4 bytes (IP address)

Assigned number sub-field: 2 bytes

Example: 141.253.1.1:123

Extended Community

• Router origin community

• Identifies one or more routers that inject a set of routes (that carry this community) into BGPThe Type field for the Route Origin community is

0x0001 or 0x0101

• Similar to the Site of Origin (SOO)Site of Origin use code 0x0003 and 0x0103

Extended Community

• Route target community

Identifies one or more routers that may receive a set of routes (that carry this community) carried by BGP

The type field for the route target community is 0x0002 or 0x0102

Extended Community

• Site of Origin (SOO)

• Identifies customer site

• Used to prevent loops when AS_PATH cannot be used

• The type field for SOO is 0x0003 or 0x0103

Site-1

Site of OriginSite of Origin

ip vrf odd rd 100:1 route-target export 100:3 route-target import 100:3!interface Serial1 ip vrf forwarding odd ip address 192.168.65.6 255.255.255.0

!router bgp 100 no synchronization no bgp default ipv4-unicast neighbor 192.168.0.7 remote-as 100 neighbor 192.168.0.7 update-source Loop0 neighbor 192.168.0.7 activate neighbor 192.168.0.7 next-hop-self no auto-summary ! address-family ipv4 vrf odd neighbor 192.168.65.5 remote-as 250 neighbor 192.168.65.5 activate neighbor 192.168.65.5 route-map setsoo in no auto-summary no synchronization exit-address-family ! address-family vpnv4 neighbor 192.168.0.7 activate neighbor 192.168.0.7 send-community extended no auto-summary exit-address-family!route-map setsoo permit 10 set extcommunity soo 100:65

7200-1#sh ip route vrf oddC 192.168.65.0/24 is directly connected, Serial2B 192.168.0.5 [20/0] via 192.168.65.5, 00:08:44, Serial27200-1#7200-1#sh ip bgp vpn all Network Next Hop Metric LocPrf Weight PathRoute Distinguisher: 100:1 (default for vrf odd)*> 192.168.0.5/32 192.168.65.5 0 0 250 i7200-1#sh ip bgp vpn all 192.168.0.5BGP routing table entry for 100:1:192.168.0.5/32, version 17Paths: (1 available, best #1) Advertised to non peer-group peers: 192.168.0.7 250 192.168.65.5 from 192.168.65.5 (192.168.0.5) Origin IGP, metric 0, localpref 100, valid, external, best Extended community: SoO:100:65 RT:100:37200-1#

192.168.0.5/32

Site of Origin

CE-1 Site-1SOO=100:65

192.168.0.5/32

eBGP4 update: 192.168.0.5/32

intCE1

VPN-IPv4 update:RD:192.168.0.5/32, Next-hop=PE-1SOO=100:65, RT=100:3, Label=(intCE1)

eBGP4 update: 192.168.0.5/32

PE-2 will not propagate the route since the update SOO is equal to the one configured for the site

Multi-Protocol BGP

• Extension to the BGP protocol in order to carry routing information about other protocolsMulticastMPLSIPv6…

• Exchange of Multi-Protocol NLRI must be negotiated at session set up

BGP Capabilities negotiation

Multi-Protocol BGP - RFC2858

• Obsoletes RFC2283

• New non-transitive and optional BGP attributesMP_REACH_NLRI

“Carry the set of reachable destinations together with the next-hop information to be used for forwarding to these destinations”

MP_UNREACH_NLRICarry the set of unreachable destinations

• Attribute contains one or more triplesAddress Family Information (AFI)Next-Hop InformationNLRI

Labelled VPN-IPV4 Addresses in BGP-4

• Labelled VPN-IPV4 address appears in BGP NLRI

AFI = 1 - Sub-AFI = 128

• NLRI is encoded as one or more triples

Length: total length of Label + prefix (RD included)

Label: 24 bits

Prefix: RD (64 bits) + IPv4 prefix (32 bits)

Labelled VPN-IPV4 Addresses in BGP-4

• The label is assigned by the router originating the NLRI

i.e., the router identified by the next-hop value

• The label is changed by the router that modifies the next-hop value

Typically the EBGP speaker

Or iBGP forwarder configured with next-hop-self

Labelled VPN-IPV4 addresses in BGP-4

• Next-hop address must be of the same family of the NLRI

The next-hop will be a VPN-IPv4 address with RD set to 0

• BGP will consider two VPN-IPV4 comparable even with different labels

A withdrawn of a VPN-IPv4 address will be considered for all NLRI corresponding to the VPN-IPV4 address, whatever are the different assigned labels

BGP Capabilities Negotiation

• BGP routers establish BGP sessions through the OPEN message

• OPEN message contains optional parameters

• BGP session is terminated if OPEN parameters are not recognised

• A new optional parameter: CAPABILITIES

• A BGP router sends an OPEN message with CAPABILITIES parameter containing its capabilities:

Multiprotocol extension

Route Refresh

Co-operative Route Filtering

• BGP routers determine capabilities of their neighbors by looking at the capabilities parameters in the open message

• Unknown or unsupported capabilities may trigger the transmission of a NOTIFICATION message

“The decision to send the NOTIFICATION message and terminate peering is local to the speaker. Such peering should not be re-established automatically”draft-ietf-idr-bgp4-cap-neg

• BGP routers use BGP-4 Multiprotocol Extension to carry label (label) mapping informationMultiprotocol Extension capability

Used to negotiate the Address Family Identifier

AFI = 1

Sub-AFI = 128 for MPLS-VPN

BGP Route Refresh

• New BGP Capability: Route Refresh

• Allows a router to request to any neighbor the re-transmission of BGP updates

Useful when inbound policy has been modified

Similar to Cisco “soft-reconfiguration”

without need to store any route

• BGP speakers may send “Route-Refresh” message only to neighbors from which the capability has been exchanged

BGP Route Refresh

• When the inbound policy has been modified, the BGP speaker sends a Route-Refresh message to its neighborsWith AFI, Sub-AFI attributes

• Neighbors will re-transmit all routes for that particular AFI and Sub-AFI

BGP Co-operative Route Filtering

• In order to reduce amount of BGP traffic and CPU used to process updates, routers exchange filter configurations

• BGP speakers advertise to downstream neighbors the outbound filter(s) they have to use

• Filters are described in ORF entriesOutbound Route Filter

• ORF entries are part of the Route-Refresh message

BGP Co-operative Route Filtering

• ORF capability must be negotiated during session set-upCapability negotiation

• ORF capable BGP speaker will install ORFs per neighbor

• Each ORF will be defined by the upstream neighbor through route-refresh messages

BGP Co-operative Route FilteringORF Entry

• ORF EntryAFI/Sub-AFI

Filter will apply only to selected address families

ORF-Type

Determine the content of ORF-Value

NLRI is one ORF-Type

NLRI is used to match IP addresses (subnets)

• ORF EntryAction

ADD: Add an ORF entry to the current ORF

DELETE: Delete a previously received ORF entry

DELETE ALL: Delete all existing ORF entries

PERMIT: Pass routes that match the ORF entry

DENY: Do not pass routes that match the ORF entry

• ORF Entry ORF-Value (for ORF-Type=NLRI) is <Scope,NLRI>

EXACT: Remote peer should consider routes equal to the NLRI specified in the ORF

REFINE: Remote peer should consider routes that are part of a subset of the NLRI specified in the ORF

NLRI: <length, prefix>

Multiple ORF entries will follow longest match

ORF Entries and Route-Refresh

• ORF entries are carried in BGP Route-Refresh messages

• AFI/Sub-AFI are encoded into the AFI/Sub-AFI field of the route refresh message

WHEN-TO-REFRESH field

IMMEDIATE: apply the filter immediately

DEFER: wait for subsequent route-refresh message

ORF-Type to be extended for Extended Communities

Packet ForwardingMPLS VPN Data Plane

T1 L7L2 L8L3 L9L4 L7L5 LBL6 LBL7 L8

MPLS VPN Forwarding

10.3.0.0

10.1.0.0

11.5.0.0

P4P2PE4

<RD_B,10.1> , iBGP next hop PE1<RD_B,10.2> , iBGP next hop PE2<RD_B,10.3> , iBGP next hop PE3<RD_A,11.6> , iBGP next hop PE1<RD_A,10.1> , iBGP next hop PE4<RD_A,10.4> , iBGP next hop PE4<RD_A,10.2> , iBGP next hop PE2

<RD_B,10.2> , iBGP NH= PE2 , L2 L8• Ingress PE Receives Normal IP

Packets from CE Router

• PE Router Does “IP Longest Match” in VRFVRF , Finds iBGP Next Hop PE2PE2 and Imposes a Stack of Labels: Second Level Label L2L2 + Top Label L8L8

DataL8L2

10.1.0.0

10.2.0.0

11.6.0.0

10.2.0.0

MPLS VPN Forwarding

10.3.0.0

10.1.0.0

11.5.0.0

P4P2PE4

T7T8L9LaLb

LuLwLxLyLz

L8, POP

L2 Data

outin /

• All subsequent P routers switch packet solely on top label

• Egress PE router’s upstream LDP neighbor (Penultimate Hop or PH) removes top label (PHP)

• Egress PE uses bottom (VPN) label to select which VPN/CEto forward the Packet to

• Bottom label is removed and packet forwarded to CE router

10.1.0.0

10.2.0.0

11.6.0.0

10.2.0.0 CE

L2 DataData

P routerP router

In Label FEC Out Label

- 197.26.15.1/32 -

41 197.26.15.1/32 POP

- 197.26.15.1/32 41

MPLS VPN Packet ForwardingMPLS VPN Packet Forwarding

Use label implicit-null for destination 197.26.15.1/32

Use label 41 for destination 197.26.15.0/24

VPN-v4 update:RD:1:27:149.27.2.0/24, NH=197.26.15.1SOO=Paris, RT=VPN-A, Label=(28)

London

• PE and P routers have BGP next-hop reachability through the backbone IGP

• Labels are distributed through LDP corresponding to BGP next-hops

or RSVP with Traffic Engineering

149.27.2.0/24

• Label Stack is used for packet forwarding

Top label indicates BGP next-hop (exterior label)

Second level label indicates outgoing interface or VRF(interior VPN label)

• MPLS nodes forward packets based on top labelany subsequent labels are ignored

- 197.26.15.1/32 41

149.27.2.27

London149.27.2.0/24

• Ingress PE receives normal IP packets

• PE router performs IP Longest Match from VPN FIB, finds iBGP next-hop and imposes a stack of labels <IGP, VPN>

149.27.2.272841

VPN-A VRF149.27.2.0/24,

NH=197.26.15.1Label=(28)

68 197.26.15.1/32 POP

149.27.2.27

London149.27.2.0/24

VPN-A VRF149.27.2.0/24,

NH=197.26.15.1Label=(28)

28(V) 149.27.2.0/24 -

VPN-A VRF149.27.2.0/24,

NH=Paris

149.27.2.27

• Penultimate PE router removes the IGP label

Penultimate Hop Popping procedures (implicit-null label)

• Egress PE router uses the VPN label to select which VPN/CE to forward the packet to

• VPN label is removed and the packet is routed toward the VPN site

2868 149.27.2.27149.27.2.2728149.27.2.272841

41 197.26.15.1/32 68

MPLS VPN TopologiesMPLS VPN Topologies

MPLS VPN Extranet SupportMPLS VPN Extranet Support

• Extranet support is simply the import of routes from one VRF into another VRF which services a different VPN

• Controlled through the use of Route Target

if we import the route, we have access

• Various topologies are viable using this technique

MPLS VPN Extranet SupportMPLS VPN Extranet Support

VRF for VPN-A

VRF for VPN-B

VPN-A Paris Routes VPN-B Munich RoutesCE

Sharing of VPN information between VRFs provides Extranet support

Extranet VPN Routing

Munich

Central Services ModelCentral Services Model

• Common topology is central services VPN

client sites may access central services but may not communicate directly with other client sites

• Once again controlled through the use of route target

client sites belong to unique VRF, servers share common VRF

client exports routes using client-rt and imports server-rt

server exports routes using server-rt and imports server-rt & client-rt

Central Services Model

Central Server Site

195.12.2.0/24

146.12.7.0/24

146.12.9.0/24

VPN A VRFVPN A VRF 195.12.2.0/24 195.12.2.0/24 146.12.9.0/24146.12.9.0/24

VPN B VRFVPN B VRF 146.12.7.0/24 146.12.7.0/24 146.12.9.0/24146.12.9.0/24

VPN A VRF (Export RT=client-rt) (Import RT=server-rt)

VPN B VRF (Export RT=client-rt)

(Import RT=server-rt)

Server VRF (Export RT=server-rt) (Import RT=server-rt) (Import RT=client-rt)

MP-iBGP Update RD:195.12.2.0/24,

RT=client-rt

RT=server-rt

RT=client-rt

MPLS VPN Internet ConnectivityStatic Default Route

• VPN sites may require Internet access

either directly or via a central site - no full routing

• Default route provided through static or dynamic route within the VRF

extension to ‘ip route’ command - Global keyword

Internet gateway points to an exit point whose address is within the global routing table

• PE router generates VPN customer routes into BGP through global static routes

MPLS VPN Internet ConnectivityStatic Default Route

Global Internet Access

VPN A VRFVPN A VRF 0.0.0.0 NH=Internet-PE0.0.0.0 NH=Internet-PE

VPN B VRFVPN B VRF 0.0.0.0 NH=Internet PE0.0.0.0 NH=Internet PE

Internet Routing Internet Routing TableTable

MPLS VPN BackboneMPLS VPN Backbone

ip route vrf VPN_A 0.0.0.0 0.0.0.0 Internet-PE global ip route 195.12.2.0 255.255.255.0 serial 1/0

ip route vrf VPN_B 0.0.0.0 0.0.0.0 Internet-PE global ip route 146.12.9.0 255.255.255.0 serial 1/1

195.12.2.0/24

146.12.9.0/24

MPLS VPN BackboneMPLS VPN BackboneVPN AVPN A

VPN A VPN A Central SiteCentral Site

VPN B VPN B Central SiteCentral Site

VPN-IPv4 Update VPN-IPv4 Update Net=0.0.0.0/0 Net=0.0.0.0/0

RT=RT=17:2217:22

RT=RT=17:2817:28

RT=RT=17:2217:22

Export VPN A default with Export VPN A default with RT=RT=17:22 17:22 and VPN B default and VPN B default

with RT=with RT=17:2817:28

VPN BVPN B

MPLS VPN Internet ConnectivityDynamic Default Route

VPN A VRF (Import RT=17:22)

VPN B VRF (Import RT=17:28)

MPLS VPN Internet ConnectivitySeparate BGP Session PE/CE Link

• Many clients wish to send/receive routes directly with the Internet

default route is not sufficient in this environment

• Routes reside on the PE router

but within the global not VRF tables

• Mechanism needed to distribute this routing information to VPN customer sites

and also receive routes and place them into the global, and not VRF table

• Achieved by using a second interface to the client site

either physical or logical, such as sub-interface or tunnel

MPLS VPN Internet ConnectivitySeparate BGP Session PE/CE Link

PEVPN Site

Global Internet

Internet Routes

(sub)interface associated with global routing table

(sub)interface associated with VRF

MPLS VPN Internet ConnectivityGlobal Internet Table Association

• If multiple exit points, then possibility to associate full Internet routes with a VRF

if only one exit point, then default pointing to Internet exit point interface will normally suffice

• With multiple interfaces, sub-optimal routing a possibility with default route generation

as multiple defaults would allow load balancing but no best path selection

• Association of Internet routes with VRF provide ability to generate aggregate default

ISP BISP BISP AISP A

Export default route with Export default route with Internet_access route targetInternet_access route target

Full Internet Routes

Full Internet Routes Full Intern

et Routes

Full Intern

et Routes

Static default pointing to loopback interface so lookup

in VRF will occur on incoming packets

• Optimal routing between providers now possible

• Need to filter everything other than default

cpu and administrative overhead

• Label assignment will occur for every route within the VRF

memory overhead even though labels are never used

• If full routes distributed, could result in multiple copies of Internet routing table

MPLS VPN ConvergenceMPLS VPN Convergence

Routing ConvergenceRouting Convergence

• Convergence needs to be assessed in two main areas

convergence within the MPLS VPN backbone

convergence between VPN client sites

• Both areas are completely independent ...

but work together to provide end-to-end convergence as perceived by the VPN client

therefore must be assessed in conjunction

VPN Client VPN Client AA

New VPN route New VPN route advertisedadvertised

Advertisement of new Advertisement of new VPN route to relevant VPN route to relevant

VPN sitesVPN sites

New VPN route imported New VPN route imported into relevant VRFsinto relevant VRFs

End-to-End Routing ConvergenceEnd-to-End Routing Convergence

Client-to-client and MPLS VPN backbone IGP convergence are independent

New VPN route propagated across MP-

iBGP session

If link fails, MPLS VPN backbone IGP converges on new path to BGP next-hop

Convergence Across BackboneConvergence Across Backbone

• Convergence of MPLS VPN backbone IGP will not affect client-to-client route convergence

unless BGP next-hop becomes unavailable;

but will affect client-to-client traffic while backbone converges

• Backbone may be router-only based or based on ATM switches

convergence will be different for the MPLS forwarding plane - cell-mode versus frame-mode implementation

Convergence - Router Based Backbone

• Unsolicited Downstream

Bindings advertised as soon as route is in the routing table

• Liberal Label Retention

If multiple neighbors, next-hop change causes new label to be used for forwarding

• Immediate Notification of Routing Table Change

A route change (addition/deletion) immediately propagated to MPLS process

Convergence - Router Based Backbone

MPLS & IGP backbone convergence are closely entwined

If P-1 to PE-2 link fails, PE-1 next-hop to destinations reachable via 197.26.15.1/32 (PE-2 Loopback) will change to P-3. As label exists (41), convergence is as quick as the IGP

Use label 41 for destination 197.26.15.1/32 Use label POP for destination

197.26.15.1/32

Use label 23 for destination 197.26.15.1/32

Use label 25 for destination 197.26.15.1/32 P-2

Use label POP for destination 197.26.15.1/32

Convergence - ATM BackboneConvergence - ATM Backbone

• Downstream-on-demand

Affects convergence as LSR must signal for downstream label binding

• Conservative Label Retention

Convergence is affected as LSR must signal for downstream label binding if one does not exist

Next-hop change will cause label request

• Two-stage Convergence:

IGP: converge around topology changesMPLS: re-establish label mappings

Convergence - ATM Based Backbone

MPLS LSR must re-converge on IGP change AND re-signal for label mapping to downstream next-hop

If P-1 to PE-2 link fails, PE-1 next-hop to destinations reachable via 197.26.15.1/32 (PE-2 Loopback) will change to P-3. As label does not exist, PE-1 must signal the next-hop downstream ATM-LSR

Label request for destination 197.26.15.1/32

Use label 1/239 for destination 197.26.15.1/32

Use label 1/321 for destination 197.26.15.1/32

Label request for destination 197.26.15.1/32

Client-to-Client ConvergenceClient-to-Client Convergence

• Four Main Convergence Areas

–Advertisement of routes from CE to PE and placement into VRF

–Propagation of routes across the MPLS VPN backbone

–Import process of these routes into relevant VRFs

–Advertisement of VRF routes to attached VPN sites

Backbone Route PropagationBackbone Route Propagation

• Changes are not propagated to other BGP speakers immediately

Batched together and sent at “advertisement-interval”Default = 5 seconds for iBGP, 30 for eBGP

• Can be tweaked using the “neighbor advertisement-interval” command

Needs to be changed for both backbone and CE routers if BGP between PE & CE

Import ProcessImport Process

• Import Process Uses a Separate Invocation of the Scanner Process

Default = 15 seconds

Can be tuned using the “bgp scan-time import” command

• Can take up to 15 Seconds for a Route to be Placed into a Receiving VRF

and then potentially another 30 Seconds to be advertised to CE if eBGP is in operation!

Scanner ProcessScanner Process

• Scanner process will also have an effect on convergence

Used to check next-hop reachability and to process any “network” commands within the BGP process

Invoked every 60 seconds by default

Can be tuned with the “bgp scan-time” command

Large BGP table and small scan-time can be VERY CPU intensive - beware !

BGP Route AdvertisementBGP Route Advertisement

• In addition to the scanning and importing of routes, each PE router needs to advertise the best routes within each VRF to all its VRF neighbors

This occurs at both ingress and egress of the MPLS VPN network

With eBGP CE neighbors, advertisement of these routes occurs every 30 seconds

With (iBGP) PE neighbors, routes advertisement occurs every 5 seconds

Can be tuned with the “neighbor a.b.c.d advertisement-interval” command

MPLS VPN ScalingMPLS VPN Scaling

ScalingScaling

• Existing BGP techniques can be used to scale the route distribution: route reflectors (RRs) & BGP confederations (Inter-AS VPN)

• Each edge router needs only the information for the directly-connected VPNs it supports

• RRs are used to distribute VPN routing information

MPLS-VPNScaling BGP

Route Reflectors

• Route reflectors may be partitioned

Each RR stores routes for a set of VPNs

• Thus, no BGP router needs to store information on ALL VPNs

• PEs will peer to RRs according to the VPNs they support

MPLS-VPN ScalingBGP Updates Filtering

• iBGP full mesh amongst PEs results in flooding of all VPN routes to all PEs

• Scaling problems when large amount of routes.

• PEs need routes for only attached VRFs

• Each PE will discard any VPN-IPv4 route that hasn’t a route-target configured to be imported in any of the attached VRFs

• This reduces significantly the amount of information each PE has to store

• Volume of BGP table is equivalent of volume of attached VRFs (nothing more)

• Each VRF has an import and export policy configured

• Policies use route-target attribute (extended community)

• PE receives MP-iBGP updates for VPN-IPv4 routes

• If route-target is equal to any of the import values configured in the PE, the update is accepted

• Otherwise it is silently discarded

MP-iBGP sessions

VRFs for VPNsyellowgreen

VPN-IPv4 update:RD:Net1, Next-hop=PE-XSOO=Site1, RT=Green, Label=XYZ

VPN-IPv4 update:RD:Net1, Next-hop=PE-XSOO=Site1, RT=Red, Label=XYZ

Import RT=yellow

Import RT=green

MPLS-VPN ScalingRoute Refresh

• Policy may change in the PE if VRF modifications are done

New VRFs, removal of VRFs

• However, the PE may not have stored routing information which become useful after a change

• PE request a re-transmission of updates to neighbors

Route-Refresh

Import RT=green

Import RT=red1. PE doesn’t have red routes (previously filtered out)

2. PE issue a Route-Refresh to all neighbors in order to ask for re-transmission

3. Neighbors re-send updates and “red” route-target is now accepted

MPLS-VPN ScalingOutbound Route Filters - ORF

• PE router will discard update with unused route-target

• Optimisation requires these updates NOT to be sent

• Outbound Route Filter (ORF) allows a router to tell its neighbors which filter to use prior to propagate BGP updates

Import RT=yellow

Import RT=green

1. PE doesn’t need red routes

2. PE issue a Route-Refresh message with a ORF entry to neighbors in order not to receive red routes:

Permit RT = Green, Yellow

3. Neighbors dynamically configure the outbound filter and send updates accordingly

Connecting MPLS-VPN Backbones

• Providers exchange routes between PE-ASBR routers

• MP-eBGP for (Labelled) VPNv4 addresses between ASBRsNext-hop and labels are re-written by the PE-ASBRs

• Requires PE-ASBRs to store VPN routes that need to be exchanged

• Routes are in the MP-BGP table but not in any routing tablePE-ASBRs do not have any VRFs

MP-eBGP labels are used in LFIB

Connecting MPLS-VPN backbones

PE-ASBR1

PE-ASBR2

Core of P LSRs

RR-2 Core of P LSRs

MP-eBGP VPNv4 routeswith label distribution

PE-ASBRs exchange VPNv4 addresses with labels

RR-1 reflects VPNv4 internal routesPE-ASBR1 advertises VPNv4 external routes

RR-2 reflects VPNv4 internal routesPE-ASBR2 advertises VPNv4 external routes

Connecting MPLS-VPN backbones

PE-ASBR1

PE-ASBR2

Core of P LSRs

RR-2 Core of P LSRs

Network=RD1:NNext-hop=PE1Label=L1

Network=RD1:NNext-hop=PE-ASBR1Label=L2

Network=RD1:NNext-hop=PE1Label=L1 Network=RD1:N

Next-hop=PE-ASBR2Label=L3

Network=RD1:NNext-hop=PE-ASBR2Label=L3

Network=NNext-hop=CE2

Network=NNext-hop=PE3

Multi-AS MPLS-VPN backbonesVPNV4 routes exchanged between

PE-ASBRs

PE-ASBR1

PE-ASBR2

Core of P LSRs

RR-2 Core of P LSRs

Dest=N

LDP-PE-ASBR2-labelL3Dest=N

L3Dest=N

L2Dest=N

LDP-PE1-labelL1Dest=N

L1Dest=N

Dest=N

MPLS VPN ConfigurationMPLS VPN Configuration

• VPN knowledge is on PE routers

• Several basic steps are necessary to provision a PE router for VPN service

configuration of VRFs

configuration of Route Distinguishers

configuration of import/export policies

configuration of PE to CE links

association of VRFs to interfaces

configuration of MP-BGP

VRF & RD ConfigurationVRF & RD Configuration

• RD is configured on PE routers

separate RD per VRF

good practise is to use the same RD for the same VPN in all PE routers

although this is not mandatory

• VRF configuration commands

ip vrf <vrf-symbolic-name> rd <route-distinguisher-value> route-target import <Import route-target community> route-target export <Import route-target community>

VRF ConfigurationVRF Configuration

CEVPN-B

VRF VPN-A VRF VPN-B

London

Munich

ip vrf VPN-A rd 1:129 route-target export 100:1 route-target import 100:1ip vrf VPN-B rd 1:131 route-target export 100:2 route-target import 100:2

VRFfor VPN-A(RT100:1)

Paris routesLondon routes

VRFfor VPN-B(RT100:2)

Munich routes

PE/CE Routing ProtocolPE/CE Routing Protocol

• PE/CE can use BGP, RIPv2, OSPF or Static

• Routing context used for all except OSPF which uses a separate process

• Routing contexts are defined within the routing protocol instance

router rip version 2! address-family ipv4 vrf <vrf symbolic-name> version 2 network 195.27.15.0! address-family ipv4 vrf <vrf symbolic-name> ..

router ospf 100 vrf <vrf-symbolic-name>!router ospf 200 vrf <vrf symbolic-name>

• OSPF uses a different process

• BGP uses address-family command

router bgp <AS #>! address-family ipv4 vrf <vrf symbolic-name>! address-family vpnv4

• Static routes are configured per-VRF

ip route vrf <vrf symbolic-name>

CEVPN-B

London

Munich

interface Serial3/5 ip vrf forwarding VPN-A ip address 192.168.61.6 255.255.255.252 encapsulation ppp!interface Serial3/6 ip vrf forwarding VPN-A ip address 192.168.61.9 255.255.255.252 encapsulation ppp!interface Serial3/7 ip vrf forwarding VPN-B ip address 192.168.62.6 255.255.255.252 encapsulation ppp

router bgp 109 no bgp default ipv4-unicast neighbor 195.27.2.1 remote-as 100 neighbor 195.27.2.1 update-source Loopback0! address-family ipv4 vrf VPN-B neighbor 192.168.62.5 remote-as 65503 neighbor 192.168.62.5 activate exit-address-family ! address-family ipv4 vrf VPN-A neighbor 192.168.61.5 remote-as 65501 neighbor 192.168.61.5 activate neighbor 192.168.61.10 remote-as 65502 neighbor 192.168.61.10 activate exit-address-family! address-family vpnv4 neighbor 195.27.2.1 activate neighbor 195.27.2.1 send-community extended exit-address-family

• All show commands are VRF based

show ip route vrf <vrf-symbolic-name>show ip protocol vrf <vrf-symbolic-name>show ip cef vrf <vrf-symbolic-name>

• Ping and Telnet commands are VRF based

ping x.x.x.x vrf <vrf-symbolic-name>telnet x.x.x.x /vrf <vrf-symbolic-name>

VRF Based CommandsVRF Based Commands

MPLS VPN Internet Routing VRF Specific Default Route

Internet

Site-1

Site-2

Network 171.68.0.0/16

Serial0

192.168.1.1

192.168.1.2

ip vrf VPN-A

rd 100:1

route-target both 100:1

Interface Serial0

ip address 192.168.10.1 255.255.255.0

ip vrf forwarding VPN-A

Router bgp 100

no bgp default ipv4-unicast

network 171.68.0.0 mask 255.255.0.0

neighbor 192.168.1.1 remote 100

neighbor 192.168.1.1 activate

neighbor 192.168.1.1 next-hop-self

neighbor 192.168.1.1 update-source loopback0!address-family ipv4 vrf VPN-A neighbor 192.168.10.2 remote-as 65502 neighbor 192.168.10.2 activate exit-address-family

address-family vpnv4 neighbor 192.168.1.2 activateexit-address-family

ip route 171.68.0.0 255.255.0.0 Serial0

ip route vrf VPN-A 0.0.0.0 0.0.0.0 192.168.1.1 global

MP-BGP

MPLS VPN Internet Routing VRF Specific Default Route

Internet

Site-1

Site-2

Network 171.68.0.0/16

Serial0

192.168.1.1

192.168.1.2

Site-2 VRF

0.0.0.0/0 192.168.1.1 (global)

Site-1 routesSite-2 routes

Global Table and LFIB

192.168.1.1/32 Label=3

192.168.1.2/32 Label=5

IP packetD=cisco.com

Label = 3 IP packetD=cisco.com

MPLS VPN Internet RoutingSeparated (sub)Interfaces

Internet

Site-1

Site-2

Network 171.68.0.0/16

Serial0.1

192.168.1.1

192.168.1.2

ip vrf VPN-A

rd 100:1

route-target both 100:1

Interface Serial0

no ip address

Interface Serial0.1

ip address 192.168.20.1 255.255.255.0

ip vrf forwarding VPN-A

Interface Serial0.2

ip address 171.68.10.1 255.255.255.0

Router bgp 100

no bgp default ipv4-unicast

neighbor 192.168.1.1 remote 100

neighbor 192.168.1.1 activate

neighbor 192.168.1.1 next-hop-self

neighbor 192.168.1.1 update-source loopback0

network 171.68.0.0 mask 255.255.0.0

neighbor 171.68.10.2 remote 502!address-family ipv4 vrf VPN-A neighbor 192.168.20.2 remote-as 502 neighbor 192.168.20.2 activate exit-address-family

address-family vpnv4 neighbor 192.168.1.2 activateexit-address-family

MP-BGP

Serial0.2

MPLS VPN Internet RoutingSeparate (sub)Interfaces

Internet

Site-1

Site-2

Network 171.68.0.0/16

Serial0.1

192.168.1.1

192.168.1.2

Serial0.2

Serial0.1Serial0.2

CE routing table

Site-1 routes ----> Serial0.1

Internet routes ---> Serial0.2

PE Global Table

Internet routes ---> 192.168.1.1

192.168.1.1, Label=3

Label = 3 IP packetD=cisco.com

MPLS-VPN ScalingRoute Refresh

VPN-IPv4 update:RD:Net1, Next-hop=PE-XSOI=Site1, RT=Green, Label=XYZ

VPN-IPv4 update:RD:Net1, Next-hop=PE-XSOI=Site1, RT=Red, Label=XYZ

Import RT=yellow

Import RT=green

Import RT=red1. PE doesn’t have red routes (previously filtered out)

2. PE issue a Route-Refresh to all neighbors in order to ask for re-transmission

3. Neighbors re-send updates and “red” route-target is now accepted• New BGP capability: route refresh

• Allows a router to request to any neighbor the re-transmission of BGP updates

Useful when inbound policy has been modified

Similar to Cisco “soft-reconfiguration”

without need to store any route

• BGP speakers may send “Route-Refresh” message only to neighbors from which the capability has been exchanged

• draft-chen-bgp-route-refresh-02.txt

MPLS-VPN ScalingOutbound Route Filters - ORF

PE router will discard update with unused route-target

Optimisation requires these updates NOT to be sent

Outbound Route Filter (ORF) allows a router to tell its neighbors which filter to use prior to propagate BGP updates

draft-chen-bgp-route-filter-00.txt

VPN-IPv4 update:RD:Net1, Next-hop=PE-XSOI=Site1, RT=Green, Label=XYZ

VPN-IPv4 update:RD:Net1, Next-hop=PE-XSOI=Site1, RT=Red, Label=XYZ

Import RT=yellow

Import RT=green

1. PE doesn’t need red routes

2. PE issue a ORF message to all neighbors in order not to receive red routes

3. Neighbors dynamically configure the outbound filter and send updates accordingly

MPLS VPN - Configuration

Site-1 Site-2 Site-3 Site-4

Multihop MP-iBGP

Site-1

Site-3

Site-4

Site-2

VPN-AVPN-C

VRFfor site-4(100:3)

Site-1 routesSite-2 routesSite-3 routes

ip vrf site3 rd 100:2 route-target export 100:2 route-target import 100:2 route-target import 100:3 route-target export 100:3ip vrf site-4 rd 100:3 route-target export 100:3 route-target import 100:3!interface Serial4/6 ip vrf forwarding site3 ip address 192.168.73.7 255.255.255.0 encapsulation ppp!interface Serial4/7 ip vrf forwarding site4 ip address 192.168.74.7 255.255.255.0 encapsulation ppp

ip vrf site1 rd 100:1 route-target export 100:1 route-target import 100:1ip vrf site2 rd 100:2 route-target export 100:2 route-target import 100:2 route-target import 100:1 route-target export 100:1!interface Serial3/6 ip vrf forwarding site1 ip address 192.168.61.6 255.255.255.0 encapsulation ppp!interface Serial3/7 ip vrf forwarding site2 ip address 192.168.62.6 255.255.255.0 encapsulation ppp

MPLS VPN - ConfigurationPE/CE routing protocols

Site-1 Site-2 Site-3 Site-4

PE1 PE2

MP-iBGP

Site-1

Site-3

Site-4

Site-2

VPN-AVPN-C

router bgp 100no bgp default ipv4-unicast neighbor 6.6.6.6 remote-as 100 neighbor 6.6.6.6 update-source Loop0! address-family ipv4 vrf site4

neighbor 192.168.74.4 remote-as 65504

neighbor 192.168.74.4 activate exit-address-family ! address-family ipv4 vrf site3

neighbor 192.168.73.3 activate exit-address-family ! address-family vpnv4 neighbor 6.6.6.6 activate neighbor 6.6.6.6 next-hop-selfexit-address-family

IOS Support forMPLS

MPLS-VPN IOS Releases - LDP Status

• Initial limited deployment release in 12.0(10)ST and up

• 12.0(11)ST available on CCO

• General deployment also planned for 12.2(1)T

• Will be based on the current IETF draft (draft-ietf-mpls-ldp-11.txt?)

ReferencesReferences

• RFCs and Internet Draftsdraft-rosen-rfc2547bis-02.txt (was RFC2547)

RFC2858 (Obsoletes RFC2283)

draft-ietf-mpls-bgp4-mpls-02.txt

draft-ramachandra-bgp-extcommunities04.txt

• Textbook“MPLS and VPN Architectures,” by Ivan Pepelnjak, Jim Guichard (ISBN# 1-58705-002-1)

MPLS: Technology and Applications, by Bruce Davie, Yakov Rekhter (ISBN#1-55860-656-4)

• Useful URLshttp://wwwin-mpls.cisco.com/

http://wwwin-ch.cisco.com/SQA/devtest/tag-switching/

http://wwwin-people.cisco.com/sprevidi/

Reference PointersReference Pointers

• Mailing Lists

tag-vpn@cisco.com<-- (mpls-vpn questions)

cs-tagswitching@cisco.com <-- (general mpls questions)

CS-rrr@cisco.com <--(mpls-te questions)

mpls-deployment@cisco.com

1 MPLS Bootcamp © 2000, Cisco Systems, Inc. Cisco Confidential MPLS Bootcamp MPLS VPN Khalid Raza,...

Documents

Configuring MPLS over DMVPN - Cisco · ConfiguringMPLSoverDMVPN TheMPLSoverDMVPNfeatureimplementsMultiprotocolLabelSwitching(MPLS)overadynamically …

Slide 1 MPLS and DiffServ Sources: MPLS Forum, Cisco V. Alwayn, Advanced MPLS Design and Implementation, Cisco Press E. W. Gray, MPLS Implementing the

Cisco Mpls -Te for Vpns

MPLS Forwarding Commands on Cisco IOS XR Software · MPLS Forwarding Commands on Cisco IOS XR Software clear mpls forwarding counters MPR-89 Cisco IOS XR MPLS Command Reference OL-15786-02

Www.netaP.net Implementing Cisco MPLS (MPLS) v2.1 Volume 1

Configuring MPLS over FlexVPN - Cisco

MPLS Cisco (1)

MPLS Basic MPLS Configuration Guide, Cisco IOS XE … · MPLS Basic MPLS Configuration Guide, Cisco IOS XE Release 3S First Published: July24,2013 Last Modified: July24,2013 Americas

Cisco - MPLS Overview

Cisco Mpls Te

Cisco Mpls Concept

KnowledgeNet Implementing Cisco MPLS (MPLS) 2.0 …docstore.mik.ua/cisco/pdf/other/KnowledgeNet Implementing Cisco...KnowledgeNet Implementing Cisco MPLS (MPLS) 2.0 Student Guide

Managing MPLS Networks - Cisco

Mpls Cisco

Cisco MPLS Management

Cisco IOS-XR MPLS Command · PDF fileiii Cisco IOS-XR MPLS Command Reference CONTENTS MPLS Label Distribution Protocol Commands on Cisco IOS-XR Software MPR-1 MPLS Traffic Engineering

Mpls Cisco (RUS)

Configuring MPLS QoS - Cisco

© 2006 Cisco Systems, Inc. All rights reserved. MPLS v2.2—3-1 Frame-Mode MPLS Implementation on Cisco IOS Platforms Configuring Frame-Mode MPLS on Cisco

Introduction to Cisco MPLS VPN Technology · 1-2 Cisco VPN Solutions Center: MPLS Solution Provisioning and Operations Guide DOC-7812189= Chapter 1 Introduction to Cisco MPLS VPN