mpls vpn configurations khalid raza l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
MPLS VPN Configurations Khalid Raza PowerPoint Presentation
Download Presentation
MPLS VPN Configurations Khalid Raza

Loading in 2 Seconds...

play fullscreen
1 / 101

MPLS VPN Configurations Khalid Raza - PowerPoint PPT Presentation


  • 352 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'MPLS VPN Configurations Khalid Raza' - tal


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
agenda
Agenda
  • Introduction to VPNs concepts
  • VPN definitions
  • Types of VPNs (Overlay/Peer)
  • Comparison between Overlay and Peer model
  • Benefits for MPLS VPNs
agenda3
Agenda
  • Idea behind VRF, RD, RT
  • Route propagation in MP-BGP
  • Routing between PE-CE
  • MPLS Packet Forwarding
agenda4
Agenda
  • MPLS configuration
    • VRF
    • MP-BGP
    • PE-CE configuration
    • Advance configuration
agenda5
Agenda
  • MPLS topologies
  • VPN connectivity
  • Design considerations
  • Deployment strategies
vpn mpls concepts
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
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 terminology8
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
slide9

VPN Terminology

Provider core (P) 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
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
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 model12
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
slide13

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

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 model16
VPN Peer Model
  • Peer model used two types of approach
    • Shared router
    • Dedicated router
vpn peer model17
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
slide18

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

Paris

PE

VPN-B

CE

London

VPN-C

CE

Munich

Shared router approach with complex filters

vpn peer model19
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
slide20

Peer-to-Peer Model Dedicated Router Approach

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

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
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 models22
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
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 vpns24
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)
slide25

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

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
slide31

VPN Routing & Forwarding Instance (VRF)

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

10.2.1.0/24

10.3.3.0/24

10.2.12.0/24

10.4.12.0/24

Address space for VPN A and B must be unique

Milan

Brussels

Vienna

VPN B

10.2.1.0/24

10.22.12.0/24

VPN C

vpn routing forwarding instance vrf
VPN Routing & Forwarding Instance (VRF)
  • 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

CE

PE

CE

Site-2

Site-1

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)
  • EBGP,OSPF, RIPv2,Static
slide35

Local VRF Route Population

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
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
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 rd38
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
slide39

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
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
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
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
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 rt44
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 rt45
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
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
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
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
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 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
slide51

MP-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 labelin the label stack of packets travelling in thecore
slide52

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:149.27.2.0/24, Next-hop=PE-1SOO=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
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
slide54

MPLS/VPN Packet Forwarding

In Label FEC Out Label

- 197.26.15.1/32 -

In Label FEC Out Label

41197.26.15.1/32POP

In Label FEC Out Label

-197.26.15.1/32 41

197.26.15.1

PE-1

PE-2

Use label implicit-null for destination 197.26.15.1/32

Use label41for 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)

Paris

London

149.27.2.0/24

  • PE and P routers have BGP next-hop reachability through the backbone IGP
  • Labels are distributed through LDP corresponding to BGP Next-Hopsor RSVP with Traffic Engineering
mpls vpn packet forwarding
MPLS/VPN Packet Forwarding
  • 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
slide56

Penultimate Hop Popping

In Label FEC Out Label

- 197.26.15.1/32

In Label FEC Out Label

41 197.26.15.1/32POP

In Label FEC Out Label

- 197.26.15.1/32 41

197.26.15.1

London

Brussels

Paris

Use labelimplicit-nullfor destination 197.26.15.1/32

Use label41 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

41Pop tag197.26.15.1/32 0 Se0/0/2 point2point

slide57

MPLS/VPN Packet Forwarding

In Label FEC Out Label

-197.26.15.1/32 41

VPN-A VRF149.27.2.0/24, NH=197.26.15.1Label=(28)

PE-1

149.27.2.27

41

28

149.27.2.27

Paris

London

149.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>
slide58

MPLS/VPN Packet Forwarding

In Label FEC Out Label

28(V)149.27.2.0/24-

In Label FEC Out Label

41197.26.15.1/32 POP

VPN-A VRF149.27.2.0/24, NH=197.26.15.1Label=(28)

VPN-A VRF149.27.2.0/24, NH=Paris

PE-1

149.27.2.27

28

149.27.2.27

41

28

149.27.2.27

149.27.2.27

Paris

London

149.27.2.0/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 configuration
MPLS Configuration
  • VRF: Sites requiring same routing policies share same VRF
    • IP routing table
    • CEF forwarding
    • Route distinguisher
    • Route Target (export, import)
mpls configuration61
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 configuration62
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 configuration63
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 configuration64
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
mpls configuration65
MPLS Configuration
  • VRF configuration
    • 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
mpls configuration66
MPLS Configuration
  • VRF configuration
    • 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
mpls configuration67
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 10.1.1.5 255.255.255.252
mpls configuration68
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 configuration69
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 configuration70
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 configuration71
MPLS Configuration
  • MP-BGP configurations
    • Step 1. Configure BGP process
    • router bgp 110
    • neighbor 131.108.1.1 remote-as 110
    • neighbor 131.108.1.1 update-source loopback 0
mpls configuration72
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 131.108.1.1 activate
    • neighbor 131.108.1.1 next-hop-self
mpls configuration73
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 configuration74
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 configuration75
MPLS Configuration
  • 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)
mpls configuration76
MPLS Configuration

Router bgp 110

No bgp default ipv4 unicast

Neighbor 131.108.1.1 remote-as 110

Neighbor 131.108.1.2 remote-as 110

Neighbor 131.108.1.3 remote-as 110

Neighbor 131.108.1.1 activate

Neighbor 131.108.1.2 activate

Address-family vpnv4

Neighbor 131.108.1.1 activate

Neighbor 131.108.1.3 activate

mpls configuration77
MPLS Configuration
  • Configuring PE-CE Routing
    • BGP between PE-CE
    • RIP between PE-CE
    • OSPF between PE-CE
    • Static routes
mpls configuration78
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 configuration79
MPLS Configuration
  • All non-BGP VRF routes have to be redistributed
  • No sync is default
  • No auto summary is default
mpls configuration80
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 10.1.1.1 remote-as 115
    • neighbor 10.1.1.1 activate
mpls configuration81
MPLS Configuration
  • RIP
    • Single routing process
    • RIP parameters in each VRF
    • router 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 ospf83
MPLS OSPF
  • If all the routes are carried as external
  • Route summarization would be a problem
  • Stub areas would be hard to implement
mpls ospf84
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 ospf85

VPN-A

CE

Paris

MPLS OSPF

MPLS BGP backbone

Area 0

VPN-A

VPN-B

CE

VPN-A

VPN-B

CE

CE

Area 1

Area 2

London

Area 0

mpls ospf86
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 ospf87
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 ospf88
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 ospf89
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 ospf90
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 ospf91
MPLS OSPF
  • OSPF-BGP loop avoidance

MPLS BGP backbone

PE2

OSPF route

Redistributed into BGP

PE1

PE3

VPN-A

Area 0

VPN-A

VPN-B

VPN-A

VPN-B

CE

Paris

Area 0

mpls ospf92
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 ospf93
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 ospf94
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 ospf95
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 configuration96
MPLS Configuration
  • 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 is
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 is98
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 is99
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 is100
MPLS IS-IS
  • Configuration is similar to OSPF
    • router isis tag1 vrf vpn-blue net 49.0001.1201.0003.0001.00 redistribute bgp 65000 metric transparent level-1-2
mpls configuration101
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 10.1.0.0 255.255.0.0 10.1.1.5 serial 2/0