Mpls
Upcoming SlideShare
Loading in...5
×
 

Mpls

on

  • 1,543 views

this presentation cover about the virtual private network

this presentation cover about the virtual private network

Statistics

Views

Total Views
1,543
Views on SlideShare
1,543
Embed Views
0

Actions

Likes
4
Downloads
214
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Mpls Mpls Presentation Transcript

  • MPLS VPN Configurations Fahad Ahmed Khan
  • 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
        • 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 Provider Edge (PE) device VPN Site VPN Site VPN Terminology CPE (CE) Device CPE (CE) Device Provider core (P) device
  • 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
  • Service Provider Network Provider Edge (PE) device Provider Edge (PE) device VPN Site VPN Site Virtual Circuit VPN Overlay Model 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
  • Service Provider Network Provider Edge (PE) Router Provider Edge (PE) Router VPN Site VPN Site CPE (CE) Router CPE (CE) Router Layer-3 Routing Adjacency VPN Peer-to-Peer Model Layer-3 Routing Adjacency
  • 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 CE VPN-A VPN-B CE VPN-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 Table VPN-A routes VPN-B routes VPN-C routes
  • 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 VPN-A PE CE VPN-A VPN-B CE Dedicated router approach expensive to deploy Paris London P Routing Table VPN-A routes (community 111:1) VPN-B routes (community 111:2) VPN-B PE P Router CE VPN-A Brussels VPN-A routes ONLY VPN-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
  • 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)
  • Benefits of MPLS VPNs PE CE VPN-A VPN-A CE VPN-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
  • 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
    • 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)
  • VPN Routing & Forwarding Instance (VRF) PE CE VPN-A VPN-A CE VPN-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 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
  • 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
    • 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
    PE CE CE Site-2 Site-1
  • Local VRF Route Population PE CE VPN-A VPN-A CE VPN-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 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 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
  • Concept of RD 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 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 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-1 SOO=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-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 - In Label FEC Out Label 41 197.26.15.1/32 POP In Label FEC Out Label - 197.26.15.1/32 41 MPLS/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.1 SOO=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-2 197.26.15.1
  • 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
  • Penultimate Hop Popping London Brussels Paris 197.26.15.1 In Label FEC Out Label - 197.26.15.1/32 In Label FEC Out Label 41 197.26.15.1/32 POP In Label FEC Out Label - 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
  • In Label FEC Out Label - 197.26.15.1/32 41 MPLS/VPN Packet Forwarding Paris 149.27.2.27 PE-1 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>
    149.27.2.27 28 41 VPN-A VRF 149.27.2.0/24, NH= 197.26.15.1 Label=( 28 )
  • In Label FEC Out Label 41 197.26.15.1/32 POP MPLS/VPN Packet Forwarding Paris 149.27.2.27 PE-1 London 149.27.2.0/24 149.27.2.27 28 41 VPN-A VRF 149.27.2.0/24, NH= 197.26.15.1 Label=( 28 ) 149.27.2.27 28 In Label FEC Out Label 28(V) 149.27.2.0/24 - VPN-A VRF 149.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 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
  • 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 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 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 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 131.108.1.1 remote-as 110
      • neighbor 131.108.1.1 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 131.108.1.1 activate
      • neighbor 131.108.1.1 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 131.108.1.1 (IPv4, VPNv4)
      • Neighbor 131.108.1.2 (IPv4 only)
      • Neighbor 131.108.1.3 (VPNv4 only)
  • 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 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 10.1.1.1 remote-as 115
      • neighbor 10.1.1.1 activate
  • 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
    • 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 CE VPN-A CE VPN-B MPLS BGP backbone London Area 0 Area 1 VPN-A CE VPN-B Area 2 Area 0 VPN-A CE Paris
  • 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
    VPN-A VPN-B MPLS BGP backbone VPN-A CE Paris Area 0 VPN-A VPN-B Area 0 OSPF route Redistributed into BGP PE1 PE2 PE3
  • 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 10.1.0.0 0.0.255.255 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 49.0001.1201.0003.0001.00 redistribute bgp 65000 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 10.1.0.0 255.255.0.0 10.1.1.5 serial 2/0