Mpls

1CQFE rev17 Russ Davis © 1999, Cisco Systems, Inc.

MPLS VPN Configurations

Fahad Ahmed Khan

MPLS VPN Configurations

Fahad Ahmed Khan

2CQFE rev14 Russ Davis © 1999, Cisco Systems, Inc. www.Cisco.com

AgendaAgenda

• Introduction to VPNs concepts

• VPN definitions

• Types of VPNs (Overlay/Peer)

• Comparison between Overlay and Peer model

• Benefits for MPLS VPNs


AgendaAgenda

• Idea behind VRF, RD, RT

• Route propagation in MP-BGP

• Routing between PE-CE

• MPLS Packet Forwarding


AgendaAgenda

• MPLS configuration

VRF

MP-BGP

PE-CE configuration

Advance configuration


AgendaAgenda

• MPLS topologies

• VPN connectivity

• Design considerations

• Deployment strategies


VPN/MPLS ConceptsVPN/MPLS Concepts

• VPNConcept is to use the service providers shared resources connecting multiple customer sites

Technologies such as X.25, Frame-relay which use virtual circuits to establish end-to-end connection using shared service of the provider infrastructure

This statistical sharing of resources enables the service provider to offer low cost services to the end user


VPN Terminology

• Provider Network (P-Network)

The backbone under control of a Service Provider

• Customer Network (C-Network)

Network under customer control

• CE router

Customer Edge router. Part of the C-network and interfaces to a PE router


VPN Terminology

• Site

Set of (sub)networks part of the C-network and co-located

A site is connected to the VPN backbone through one or more PE/CE links

• PE router

Provider Edge router. Part of the P-Network and interfaces to CE routers

• P router

Provider (core) router, without knowledge of VPN


Service Provider Network

Provider Edge (PE) device


VPN Site

VPN Site

VPN TerminologyVPN Terminology

CPE (CE) Device

CPE (CE) Device

Provider core (P) device


Types of VPNsTypes of VPNs

• VPN services are offered in two major ways

Overlay Model where the service provider provides the virtual connections between sites

Peer model where the service provider participates in the layer routing of the customer


VPN Overlay ModelVPN Overlay Model

• Service provider network is a connection of point-to-point links

• Routing within the customer network is transparent to the service provider network

• Service provider is responsible purely for data transport between customer sites



• Layer 1 implementation (IP, HDLC, PPP (customer) - provider gives bit pipes only

• Layer 2 implementation - service provider responsible for L2 VC via ATM, Frame-relay





VPN Site VPN Site

Virtual Circuit


CPE (CE) Device

CPE (CE) Device

Layer-3 Routing Adjacency


VPN Peer Model

• Both provider and customer network use same network protocol

• CE and PE routers have a routing adjacency at each site

• All provider routers hold the full routing information about all customer networks

• Private addresses are not allowed

• May use the virtual router capability

Multiple routing and forwarding tables based on Customer Networks



Provider Edge (PE) Router

Provider Edge (PE) Router

VPN Site VPN Site

CPE (CE) Router

CPE (CE) Router


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



VPN Peer ModelVPN Peer Model

• Peer model used two types of approach

Shared router

Dedicated router



• Shared router

Where a common router was used, extensive packet filtering is used on the PE router to isolate customer

Service provider allocated addresses out of its space to the customer and managed the packet filter to ensure same customer reachability, and isolation between customers.

High maintenance cost associated with packet filters

Performance impact due to packet filtering


Peer-to-Peer Model Shared Router Approach

Peer-to-Peer Model Shared Router Approach

PE

CE

VPN-A

VPN-B

CEVPN-C

CE

Shared router approach with complex filters

Paris

London

Munich

interface Serial0/1 description ** interface to VPN-A customer ip address 192.168.61.6 255.255.255.252 ip access-group VPN-A in ip access-group VPN-A out!interface Serial0/2 description ** interface to VPN-B customer ip address 192.168.61.9 255.255.255.252 ip access-group VPN-B in ip access-group VPN-B out!interface Serial0/3 description ** interface to VPN-C customer ip address 192.168.62.6 255.255.255.252 ip access-group VPN-C in ip access-group VPN-C out

PE Routing TableVPN-A routesVPN-B routesVPN-C routes



• Dedicated router

Customer isolation is achieved via dedicated routers connected to customer

POP edge router filter routing updates between different provider edge routers

Route filtering is achieved via BGP Communities

Not cost effective


Peer-to-Peer Model Dedicated Router ApproachPeer-to-Peer Model Dedicated Router Approach

VPN-A PE

CE

VPN-A

VPN-B

CE

Dedicated router approach expensive to deploy

Paris

London

P Routing TableVPN-A routes (community 111:1)VPN-B routes (community 111:2)

VPN-B PE

P Router CE VPN-A

Brussels

VPN-A routes ONLYVPN-B

router bgp 111

neighbor 10.13.1.2 remote-as 111

neighbor 10.13.1.2 route-reflector-client

neighbor 10.13.1.2 route-map VPN-A out

!

route-map VPN-A permit 10

match community-list 75

!ip community-list 75 permit 111:1


Comparison Between the Two Models


• Overlay Model

Easy to implement

No knowledge of customer routing

Isolation between the two network

• Peer Model

Optimal routing

Easy to provision additional VPNs through site provisioning - no need for link provisioning




• Overlay ModelOptimal routing between sites requires full mesh

Bandwidth provisioning

Virtual circuits have to be manually configured

• Peer Model

Customer convergence is depended on SP routing convergence

Lot of routes with the provider networks causes scalability problems


Benefits of MPLS VPNsBenefits of MPLS VPNs

• Best of both worlds

• PE participates in routing so you can achieve optimal routing between sites

• PE isolates customer routing information like dedicated router solution

• Overlapping addresses are permitted between customers



• PE router is subdivided into virtual routers

• Similar to the dedicated router approach

• Each customer is assigned independent routing tables

• IOS does this isolation through the concept of VRF (Virtual Routing and Forwarding)



PE

CE

VPN-A

VPN-A

CEVPN-B

Global Routing Table

VRF for VPN-A

VRF for VPN-B

VPN Routing Table

CE

Multiple routing & forwarding instances (VRFs) provide the separation

Paris

London

Munich

IGP &/or BGP


ProblemProblem

• How to propagate routing across the network between the PE devices?

• We need a routing protocol that will transport the customer routes across the provider network

• Need to maintain the independency of customers routing and address space


Easy and Lazy AnswerEasy and Lazy Answer

• Run multiple routing protocols, one each for customer

• But PE routers will have to run large number of routing instances

• Poor P router will have to carry all the VPN routes

• P routers still will run into overlapping address problem unless you configure all the vrfs on the PE router

• Does not scale


Better SolutionBetter Solution

• Run a routing protocol that can exchange the routing updates only between PE routers

• P router is protected from customer routes


But how to do it ?But how to do it ?

• Use BGP to pass the routing information between PE devices

• Use MPLS labels to exchange packets between next-hops (PE routers)

• Extend BGP to be able to handle overlapping addresses


• PE routers maintain separate routing tables

Global routing table

contains all PE and P routes (perhaps 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)





PE

CE

VPN-A

VPN-A

CEVPN-B

Global Routing Table

VRF for VPN-A

VRF for VPN-B

VPN Routing Table

CE

Multiple routing & forwarding instances (VRFs) provide the separation

Paris

London

Munich

IGP &/or BGP


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 A

VPN B VPN C

London

Milan

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 can be thought of as a virtual router with the following structures:

forwarding table based on CEF

a set of interfaces that use the derived forwarding table

rules to control import/export of routes from/into the VPN routing table

set of routing protocols/peers which inject information into the VPN routing table (including static routing)

router variables associated with the routing protocol used to populate the VPN routing table


VRF Route PopulationVRF Route Population

• VRF is populated locally through PE and CE routing protocol exchange

RIP Version 2, OSPF, BGP-4 & Static routing

• Separate routing context for each VRF

routing protocol context (BGP-4 & RIP V2)

separate process (OSPF)

PE

CE

CE

Site-2

Site-1

EBGP,OSPF, RIPv2,Static


Local VRF Route PopulationLocal VRF Route Population

PE

CE

VPN-A

VPN-A

CEVPN-B

VRF for VPN-A

VRF for VPN-B

CE

Local VRF population driven by routing protocol context or process (OSPF)

Paris

London

Munich

Which routing protocol context or

process ?

Global


VRF Route DistributionVRF Route Distribution

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

through the use of MP-BGP & redistribution from VRF

receiving PE imports routes into attached VRFs

PE PE CE Router CE Router

P Router

VPN Site VPN Site MP-BGP

MPLS/VPN Backbone


Concept of RDConcept of RD

• If customers have overlapping address, BGP will treat them is single prefix

• Extend the prefix with a 64-bit prefix (route-distinguisher)

• Now, with 32 bit IP address and 64 bit RD, the two overlapping IP address are unique



• 32 bit IP prefix is the IPv4 address

• With 64 bit RD, it is now extended to 96 bit and is now VPNv4 address

• This address is exchanged only between the PE routers via BGP

• This is carried in Multi-Protocol BGP



PE1

CE

VPN-A

VPN-B

VPN-B

CE

MP-BGP

PE2

BGP Table

Routes from VPN-A Routes from VPN-B

Munich

MPLS/VPN Backbone

CE router sends 32 bit IPv4 prefix

PE router converts it into a 96 bit VPNv4 prefix


Processing of RDProcessing of RD

• RD is propagated between the PE routers

• RD is removed by the receiving PE routers

• CE router receives just the IPv4 prefixes


Usage of RDUsage of RD

• RD is only used to extend the IP prefix such that overlapping address are unique

• Simple VPN topologies require single RD per customer

• In some cases multiple RDs may be required


Can RD be the VPN Identifier?Can RD be the VPN Identifier?

• Yes - it could be a VPN identifier

• Complex topologies require another component for VPN topologies other than RD, just like communities are more flexible.


Concept of RTConcept of RT

• Sites that have to participate in more than one VPN- RD is not sufficient

• You need another way of deciding the membership

• RT was introduced to support complex topologies such that separation and grouping is easier



• RT is extended BGP communities, attached to VPNv4 address

• Give more flexibility to the VPN membership

• Any number of RT can be attached to a route

• Extended communities are 64 bit values



• RTs are either exported or imported

• Export route target are attached to the route the moment it is converted from IPv4 to VPNv4

• Import RT is used to decide the routes that would be imported into the VPN


Routing Within MPLS VPNRouting Within MPLS VPN

• Pass IPv4 to the customer routers

• No VPN routes within the MPLS core (P routers)

• P routers run IGP and global BGP (if needed)

• Provider Edge router carries connected VPN routes and Internet routes


Routing P-router PerspectiveRouting P-router Perspective

• Runs IGP with all the P and PE routers in the network

• No MPLS VPN routing information

• Very simple view of the network


Routing PE-router PerspectiveRouting PE-router Perspective

• Exchanges IPv4 routes with CE router

• Exchange VPNv4 routes with other PE routers

• Run common IGP with P router and also internet BGP with P routers (if needed)


Routing Table on PE RouterRouting Table on PE Router

• PE router has to maintain number of routing tables

• Global routing table (IGP, Internet routes)

• VRF routing information for VPNs connected

• VRF routing is populated via CE and other PE routes


PE to PE Route Information FlowPE to PE Route Information Flow

• PE router creates VPNv4 update

• Adds extended community attribute (RT, SOO)

• All other BGP attributes

• Received route is imported into appropriate VRF according to RT values

• Routes installed into VRF are propagated to CE routers


MP-BGP UpdateMP-BGP 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)

The BGP label will be the second label in the label stack of packets travelling in the core


VRF Population of MP-BGPVRF Population of MP-BGP

PE-1

CE-1

ip vrf VPN-A

route-target import VPN-A

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

CE-2

• 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 toward 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

PE-2


Routing Between PE-CERouting Between PE-CE

• CE does not need any understanding of MPLS

• CE needs standard IP software

• Currently EBGP, OSPF, RIP, and static routing is supported

• PE router looks like a standard corporate backbone to the CE 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

Paris

Use label implicit-null for destination 197.26.15.1/32

Use label 41 for destination 197.26.15.1/32

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

PE-1

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

PE-2197.26.15.1



• Label Stack is used for packet forwarding

Top label indicates BGP Next-Hop (interior label)

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

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

• Penultimate Hop Popping procedures used one hop prior to egress PE router


Penultimate Hop PoppingPenultimate Hop Popping

London London Brussels Brussels Paris Paris

197.26.15.1


- 197.26.15.1/32


41 197.26.15.1/32 POP


- 197.26.15.1/32 41

Use label 41 for destination 197.26.15.1/32

Use label implicit-null for destination 197.26.15.1/32

London# show tag-switching tdp binding 197.26.15.1 tib entry: 197.26.15.1/32, rev 10

local binding: tag: imp-null(1)remote binding: tsr: 172.16.3.1:0, tag: 41

Brussels# show tag-switching tdp binding 197.26.15.1 tib entry: 197.26.15.1/32, rev 10

local binding: tag: 41 remote binding: tsr: 172.16.3.2:0, tag: imp-null(1)

Brussels# show tag-switching forwarding Local Outgoing Prefix Bytes tag Outgoing Next Hop tag tag or VC or Tunnel Id switched interface 41 Pop tag 197.26.15.1/32 0 Se0/0/2 point2point



- 197.26.15.1/32 41


Paris

149.27.2.27

PE-1

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)



41 197.26.15.1/32 POP


Paris

149.27.2.27

PE-1

London149.27.2.0/24

149.27.2.272841

VPN-A VRF149.27.2.0/24,

NH=197.26.15.1Label=(28)

149.27.2.2728


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


MPLS/VPN Configuration and Implementation

MPLS/VPN Configuration and Implementation


MPLS ConfigurationMPLS Configuration

• VRF: Sites requiring same routing policies share same VRF

IP routing table

CEF forwarding

Route distinguisher

Route Target (export, import)



• VRF configuration

Step 1. Create VRF

Step 2. Assign an RD

Step 3. RT export

Step 4. RT import

Step 5. Define an interface to a VRF




Step 1.

Creating a VRF

ip vrf name

Example ip vrf bootcamp

Where bootcamp is just a name like route-map name



• VRF configurations

Step 2.

Every VRF needs an associated RD

rd route-distinguisher

Could be AS:X or IP address :X

Example: rd 109:12345




Step 3.

Defining a route target that will be exported with every route that is send from the VRF

Multiple route-target can be attached to a vrf

route-target export RT

Example: route-target export 109:1234




Step 4.

Define a route-target that will be accepted by the router to be imported into the VRF

route-target import

Example: route-target import 109:1345




Step 5.

Associate an interface to the VRF; this will remove the interface from the global routing process

Existing IP address is removed once the interface is defined to a VRF; you will have to re-configure the IP address



• VRF configurationIp vrf GREEN

rd 109:145

route-target export 109:145

route-target import 109:145

interface serial 1/0/1

ip forwarding vrf GREEN

ip address 10.1.1.5 255.255.255.252



• MP-BGP configuration

BGP process is extended to perform three functions

Tasks are configured in same BGP process through address families

1. Maintain and exchange global routing information (IPv4 routing)

2. VPNv4 routing

3. VRF routing exchange with CE



• MP-BGP configurations

Global neighbor are configured under the global BGP process (All P and PE neighbors)

These neighbors need to be activated under the appropriate address family according to requirements

VRF specific neighbors are defined under the corresponding VRFs




Step 1. Configure neighbors and their parameters under the global process

Step 2. Configure address family VPNv4

Step 3. Activate neighbors to carry VPNv4 routes

Step 4. Activate the VPNv4 specific parameters under the address family (filter, etc.)




Step 1. Configure BGP processrouter bgp 110


neighbor 131.108.1.1 update-source loopback 0



• MP-BGP Configurations

Step 2. Configure the address family, activate the neighbor under the address family for VNPv4 routes. Neighbor that was defined earlier under main BGP process

address-family vpnv4

neighbor 131.108.1.1 activate

neighbor 131.108.1.1 next-hop-self



• Let’s talk a little about the IPv4 address family

Address-family IPv4 is same is your regular BGP process

Configurations done under this family will be added to the global BGP configurations



no bgp default ipv4 unicast

• Disables the default behavior of IPv4 route propagation

• Activate the neighbors that need to get IPv4 routes

• Isolation of VPNv4 and IPv4 routes such that few neighbors get both and few receive VPnv4 only



• Example: 3 neighbors: two of them need IPv4 routes, one does not

• Requirements

Neighbor 131.108.1.1 (IPv4, VPNv4)

Neighbor 131.108.1.2 (IPv4 only)

Neighbor 131.108.1.3 (VPNv4 only)



Router bgp 110

No bgp default ipv4 unicast

Neighbor 131.108.1.1 remote-as 110



Neighbor 131.108.1.1 activate


Address-family vpnv4





• Configuring PE-CE Routing

BGP between PE-CE

RIP between PE-CE

OSPF between PE-CE

Static routes



• BGP/RIP require single routing process

• Distance/path vector no database separation needed; done through address-families

• OSPF requires a separate routing process for each VRF to maintain a separate database



• All non-BGP VRF routes have to be redistributed

• No sync is default

• No auto summary is default



• BGP

Define the neighbor under the address-family vrf and not under the global BGProuter bgp 110

!

address-family ipv4 vrf Green


neighbor 10.1.1.1 activate



• RIP

Single routing process

RIP parameters in each VRFrouter rip

version 2

address-family ipv4 vrf BLUE

network 10.0.0.0

redistribute bgp 110 metric transparent


MPLS OSPF MPLS OSPF

• IGP-BGP redistribution is done by MPLS

• Not a very good thing for OSPF

• Routes redistributed in OSPF are external

• Single LSA for every external route


MPLS OSPF MPLS OSPF

• If all the routes are carried as external

• Route summarization would be a problem

• Stub areas would be hard to implement


MPLS OSPFMPLS OSPF

• MPLS VPNs needed to be extended to carry OSPF information

• Per se create a concept of super backbone

• Super backbone is created with MP-BGP between the PE-routers

• This super backbone is between the PE routers; it is transparent to OSPF


MPLS OSPFMPLS OSPF

CEVPN-A CEVPN-B

MPLS BGP backbone

VPN-A

CE

ParisLondon

Area 0

Area 1

VPN-A CEVPN-B

Area 2

Area 0


MPLS OSPFMPLS OSPF

• OSPF between sites does not use normal OSPF-BGP redistribution

• Internal OSPF routes are kept internal to OSPF

• External routes are kept external

• OSPF metrics are preserved

• MPLS OSPF backbone is transparent to CE OSPF that runs standard software


MPLS OSPFMPLS OSPF

• PE routers act as ABRs

• In the case of no stub area, PE routers also act as ASBRs

• For CE routers’ perspective, send an inter-area route into the connected area


MPLS OSPF MPLS OSPF

• Intra-area OSPF routes are redistributed into BGP by the PE router

• Route Summarization can be done at the redistribution point by the PE router


MPLS OSPFMPLS OSPF

• Super backbone acts just like area 0 in regular OSPF

• Redistributed routes at the PE routers appear as inter-area routes

• Routes from one area 0 site into another area 0 sites appear as inter-area routes

• Redistributed intra- and inter-area routes appear as inter-area routes; external still appear as external


MPLS OSPFMPLS OSPF

• For MP-BGP, extended community of 0x8000 is used

• OSPF cost is copied as MED for BGP

• LSA type and metric are carried across


MPLS OSPFMPLS OSPF

• OSPF-BGP loop avoidance

VPN-AVPN-B

MPLS BGP backbone

VPN-A

CE

Paris Area 0

VPN-AVPN-BArea 0

OSPF route Redistributed into BGP

PE1 PE2PE3


MPLS OSPFMPLS OSPF

• PE1 learns the route via OSPF intra-area

• PE1 advertises the route to PE2 and PE3 via MP-BGP

• One of the PE router redistributes it first (sort of race condition)

• PE2 sends the route to PE3 via OSPF summary LSA


MPLS OSPFMPLS OSPF

• PE3 removes the iBGP route for the destination and installs the OSPF summary route, due to lower admin distance

• You can solve the problem by lowering the administrative distance of iBGP to be less… not a clean solution


MPLS OSPFMPLS OSPF

• To solve this problem a (Down bit) has been added to option field of the header like ISIS TLV 135

• PE router sets the down bit when redistributing routes from MP-BGP to OSPF

• PE router will never redistribute OSPF route back into BGP with down bit set


MPLS OSPFMPLS OSPF

• Double redistribution loop is still possible

• When the CE does redistribution between domains and the down bit is lost

• For this purpose, tag field is used as done by standard BGP-OSPF redistribution

• PE routers never redistributes OSPF routes with Tag field equal to their own AS number into MP-BGP



• OSPF

Configuration is still simple

router ospf 110 vrf RED

network 10.1.0.0 0.0.255.255 area 0

redistribute bgp 110


MPLS IS-ISMPLS IS-IS

• VPN backbone is treated as a level above L2

• All L1/L2 routes will be redistributed into BGP at the PE router

• New extended community in BGP 0x0006



• Same as route leaking concept: don’t send out IS-IS back into BGP if UP/Down bit is set

• Don’t send route if the route in the table is not learned via IS-IS



• At the receiving site redistribute the route into IS-IS with UP/Down bit set

• Same concept as separation of LSDB: one DB can belong to one VPN



• Configuration is similar to OSPFrouter isis tag1 vrf vpn-bluenet 49.0001.1201.0003.0001.00

redistribute bgp 65000 metric transparent level-1-2



• Static

Used to configure VRF specific routes

Always need to specify the interface even though you have the next-hop

ip route vrf YELLOW 10.1.0.0 255.255.0.0 10.1.1.5 serial 2/0

Mpls

Technology

Transcript of Mpls