MPLS VPN Configurations Khalid Raza

MPLS VPN Configurations Khalid Raza

Agenda Introduction to VPNs concepts VPN definitions
Types of VPNs (Overlay/Peer) Comparison between Overlay and Peer model Benefits for MPLS VPNs

Agenda Idea behind VRF, RD, RT Route propagation in MP-BGP
Routing between PE-CE MPLS Packet Forwarding

Agenda MPLS configuration VRF MP-BGP PE-CE configuration
Advance configuration

Agenda MPLS topologies VPN connectivity Design considerations
Deployment strategies

VPN/MPLS Concepts VPN Concept 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 PE router P router
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

VPN Terminology Provider core (P) device Provider Edge (PE) device
VPN Site CPE (CE) Device CPE (CE) Device Provider Edge (PE) device Provider Edge (PE) device VPN Site Service Provider Network

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

VPN Overlay Model 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 Overlay Model Virtual Circuit Layer-3 Routing Adjacency
CPE (CE) Device CPE (CE) Device Provider Edge (PE) device Provider Edge (PE) device VPN Site VPN Site Service Provider Network

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

VPN Peer-to-Peer Model
Layer-3 Routing Adjacency Layer-3 Routing Adjacency CPE (CE) Router CPE (CE) Router Provider Edge (PE) Router Provider Edge (PE) Router VPN Site VPN Site Service Provider Network

VPN Peer Model Peer model used two types of approach Shared router
Dedicated router

VPN Peer Model 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
PE Routing Table VPN-A routes VPN-B routes VPN-C routes VPN-A CE interface Serial0/1 description ** interface to VPN-A customer ip address ip access-group VPN-A in ip access-group VPN-A out ! interface Serial0/2 description ** interface to VPN-B customer ip address ip access-group VPN-B in ip access-group VPN-B out interface Serial0/3 description ** interface to VPN-C customer ip address ip access-group VPN-C in ip access-group VPN-C out Paris PE VPN-B CE London VPN-C CE Munich Shared router approach with complex filters

VPN Peer Model 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 Approach
router bgp 111 neighbor remote-as 111 neighbor route-reflector-client neighbor route-map VPN-A out ! route-map VPN-A permit 10 match community-list 75 ip community-list 75 permit 111:1 VPN-A CE Paris VPN-B P Router VPN-A CE VPN-A PE Brussels VPN-A routes ONLY VPN-B CE P Routing Table VPN-A routes (community 111:1) VPN-B routes (community 111:2) VPN-B PE London Dedicated router approach expensive to deploy

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

Comparison Between the Two Models
Overlay Model Optimal 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 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

Benefits of MPLS VPNs 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)

Multiple routing & forwarding instances (VRFs) provide the separation
Benefits of MPLS VPNs VPN Routing Table VPN-A CE Paris PE VRF for VPN-A VPN-A CE IGP &/or BGP London VRF for VPN-B VPN-B CE Munich Global Routing Table Multiple routing & forwarding instances (VRFs) provide the separation

Problem 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 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 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 ? 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

VPN Routing & Forwarding Instance (VRF)
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 Table VPN-A CE Paris PE VRF for VPN-A VPN-A CE IGP &/or BGP London VRF for VPN-B VPN-B CE Munich Global Routing Table Multiple routing & forwarding instances (VRFs) provide the separation

MPLS/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 London Paris Munich /24 /24 /24 /24 Address space for VPN A and B must be unique Milan Brussels Vienna VPN B /24 /24 VPN C

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 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 Site-2 Site-1 EBGP,OSPF, RIPv2,Static

Local VRF Route Population Which routing protocol context or process ?
VPN-A CE Paris VRF for VPN-A PE VPN-A Which routing protocol context or process ? Global CE London VRF for VPN-B VPN-B CE Munich Local VRF population driven by routing protocol context or process (OSPF)

VRF 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 P Router CE Router PE PE CE Router MP-BGP VPN Site VPN Site MPLS/VPN Backbone

Concept 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

Concept of RD 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

Routes from VPN-A Routes from VPN-B
Concept of RD VPN-A PE router converts it into a 96 bit VPNv4 prefix CE PE1 PE2 MPLS/VPN Backbone VPN-B MP-BGP CE VPN-B BGP Table Routes from VPN-A Routes from VPN-B Munich CE router sends 32 bit IPv4 prefix

Processing 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 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?
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 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

Concept of RT 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

Concept of RT 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 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 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 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 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 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 Update Any other standard BGP attribute
Local Preference MED Next-hop AS_PATH Standard 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-BGP
ip vrf VPN-A route-target import VPN-A VPN-v4 update is translated into IPv4 address and put into VRF VPN-A as RT=VPN-A and optionally advertised to CE-2 PE-1 PE-2 VPN-v4 update: RD:1:27: /24, Next-hop=PE-1 SOO=Paris, RT=VPN-A, Label=(28) CE-1 CE-2 Paris London 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

Routing 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

MPLS/VPN Packet Forwarding
In Label FEC Out Label / In Label FEC Out Label / POP In Label FEC Out Label / PE-1 PE-2 Use label implicit-null for destination /32 Use label 41 for destination /32 VPN-v4 update: RD:1:27: /24, NH= SOO=Paris, RT=VPN-A, Label=(28) Paris London /24 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

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 label any subsequent labels are ignored Penultimate Hop Popping procedures used one hop prior to egress PE router

Penultimate Hop Popping
In Label FEC Out Label /32 In Label FEC Out Label / POP In Label FEC Out Label / London Brussels Paris Use label implicit-null for destination /32 Use label 41 for destination /32 London# show tag-switching tdp binding tib entry: /32, rev 10 local binding: tag: imp-null(1) remote binding: tsr: :0, tag: 41 Brussels# show tag-switching tdp binding tib entry: /32, rev 10 local binding: tag: 41 remote binding: tsr: :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 Pop tag / Se0/0/2 point2point

In Label FEC Out Label / VPN-A VRF /24, NH= Label=(28) PE-1 41 28 Paris London /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>

In Label FEC Out Label 28(V) / In Label FEC Out Label / POP VPN-A VRF /24, NH= Label=(28) VPN-A VRF /24, NH=Paris PE-1 28 41 28 Paris London /24 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 Configuration VRF: Sites requiring same routing policies share same VRF IP routing table CEF forwarding Route distinguisher Route Target (export, import)

MPLS Configuration 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

MPLS Configuration VRF configuration Step 1. Creating a VRF
ip vrf name Example ip vrf bootcamp Where bootcamp is just a name like route-map name

MPLS Configuration 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

MPLS Configuration VRF configuration 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

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

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

MPLS Configuration VRF configuration Ip 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

MPLS Configuration 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

MPLS Configuration 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

MPLS Configuration MP-BGP configurations
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.)

MPLS Configuration MP-BGP configurations Step 1. Configure BGP process
router bgp 110 neighbor remote-as 110 neighbor update-source loopback 0

MPLS Configuration 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 activate neighbor next-hop-self

MPLS Configuration 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

MPLS Configuration 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

MPLS Configuration Example: 3 neighbors: two of them need IPv4 routes, one does not Requirements Neighbor (IPv4, VPNv4) Neighbor (IPv4 only) Neighbor (VPNv4 only)

MPLS Configuration Router bgp 110 No bgp default ipv4 unicast
Neighbor remote-as 110 Neighbor remote-as 110 Neighbor remote-as 110 Neighbor activate Neighbor activate Address-family vpnv4 Neighbor activate

MPLS Configuration Configuring PE-CE Routing BGP between PE-CE
RIP between PE-CE OSPF between PE-CE Static routes

MPLS Configuration 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

MPLS Configuration All non-BGP VRF routes have to be redistributed
No sync is default No auto summary is default

MPLS Configuration BGP
Define the neighbor under the address-family vrf and not under the global BGP router bgp 110 ! address-family ipv4 vrf Green neighbor remote-as 115 neighbor activate

MPLS Configuration RIP Single routing process
RIP parameters in each VRF router rip version 2 address-family ipv4 vrf BLUE network redistribute bgp 110 metric transparent

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 If all the routes are carried as external
Route summarization would be a problem Stub areas would be hard to implement

MPLS 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 OSPF MPLS BGP backbone Area 0 Area 1 Area 2 Area 0 VPN-A CE VPN-A
Paris Area 0 VPN-A VPN-B CE VPN-A VPN-B CE CE Area 1 Area 2 London Area 0

MPLS 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 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 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 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 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 OSPF OSPF-BGP loop avoidance PE2 PE1 PE3 MPLS BGP backbone
OSPF route Redistributed into BGP PE1 PE3 VPN-A Area 0 VPN-A VPN-B VPN-A VPN-B CE Paris Area 0

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

MPLS Configuration OSPF Configuration is still simple
router ospf 110 vrf RED network area 0 redistribute bgp 110

MPLS 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

MPLS IS-IS 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

MPLS 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

MPLS IS-IS Configuration is similar to OSPF
router isis tag1 vrf vpn-blue net redistribute bgp metric transparent level-1-2

MPLS Configuration Static Used to configure VRF specific routes
Always need to specify the interface even though you have the next-hop ip route vrf YELLOW serial 2/0

MPLS VPN Configurations Khalid Raza

Similar presentations

Presentation on theme: "MPLS VPN Configurations Khalid Raza"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

MPLS VPN Configurations Khalid Raza

Similar presentations

Presentation on theme: "MPLS VPN Configurations Khalid Raza"— Presentation transcript:

Similar presentations

About project

Feedback