MPLS VPN
SecuCam Technologies & Electronic Securities
114 / 10 Dr. Gogte Chawl, Behind Hotel City Park, Murarji Peth, Solapur 1 Mobile: +91 9860095499 / + 91 9850809876 E-mail:
[email protected] MPLS/BGP VPNs
Goals MPLS/BGP VPN Features Implementation Conclusions
What is a site to site VPN ?
VPN is a set of sites which are allowed to communicate with each other VPN is defined by a set of administrative policies policies determine both connectivity and QoS among sites policies established by VPN customers policies could be implemented completely by VPN Service Providers using BGP/MPLS VPN mechanisms
BGP/MPLS VPN - example
VPN A/Site 2 VPN B/Site 1 10.1/16
CE2B1 CE B1 P1
1
10.2/16
CEA2 PE2 P2 CEB2
10.2/16 VPN B/Site 2
PE1
CEA1 P3
PE3
CEA3
10.3/16
CEB3
10.1/16 VPN A/Site 1 10.4/16 VPN B/Site 3
VPN A/Site 3
BGP/MPLS VPN key components:
(1) Constrained distribution of routing information + multiple forwarding tables (2) Address extension (3) MPLS
Constrained Distribution of Routing Information
Provides control over connectivity among sites
flow of data traffic (connectivity) is determined by flow (distribution) of routing information
Routing Information Distribution
Step 1: from site (CE) to service provider (PE)
e.g., via RIP, or static routing, or BGP, or OSPF
Step 2: export to providers BGP at ingress PE Step 3: within/across service provider(s) (among PEs): Step 4: import from providers BGP at egress PE Step 5: from service provider (PE) to site (CE)
e.g., via RIP, or static routing, or BGP, or OSPF
Constrained Distribution of Routing Information
Occurs during Steps 2, 3, 4 Performed by Service Provider using route filtering based on BGP Extended Community attribute BGP Community is attached by ingress PE at Step 2 route filtering based on BGP Community is performed by egress PE at Step 4
Routing Information Distribution example
VPN C/Site 2 VPN B/Site 1 12.1/16
CE B1 RIP RIP PE1 Step 2 CEA1 Static CEB3 PE3
1
CEA2 Static RIP PE2 CEB2
11.2/16 VPN B/Site 2
11.1/16
CE2B1 Step 1
BGP
Step 3
Step 4 Step 5 RIP BGP CEA3
16.2/16
VPN A/Site 3
16.1/16 VPN A/Site 1 12.2/16 VPN C/Site 1
MPLS and Traditional BGP
MPLS significantly simplifies packet forwarding to BGP destinations
Traditionally BGP had to be run on every router in the core of an ISP network to enable proper packet forwarding MPLS allows to forward packets to BGP destinations by simply label-switching traffic to a BGP next-hop address BGP next-hop addresses must be reachable via IGP, which allows them to be associated with MPLS labels This allows ISP core routers to run only an IGP (IS-IS). ISP PE routers are the only ones that need to run BGP
MPLS and Traditional BGP (contd)
Pre-MPLS
Peering ISP or Customer
CORE
Peering ISP or Customer
IBGP IGP EBGP
MPLS
Peering ISP or Customer
LDP LDP LDP
Peering ISP or Customer
PE
MPLS CORE
PE
Multiple Forwarding Tables
How to constrain distribution of routing information at PE that has sites from multiple (disjoint) VPNs attached to it ?
single Forwarding Table on PE doesnt allow per VPN segregation of routing information
Multiple Forwarding Tables (cont.)
PE maintains multiple Forwarding Tables one per set of directly attached sites with common VPN membership
e.g., one for all the directly attached sites that are in just one particular VPN
Enables (in conjunction with route filtering) per VPN segregation of routing information on PE
Multiple Forwarding Tables (cont.)
Each Forwarding Table is populated from: (a) routes received from directly connected CE(s) of the site(s) associated with the Forwarding Table (b) routes receives from other PEs (via BGP)
restricted to only the routes of the VPN(s) the site(s) is in
via route filtering based on BGP Extended Community Attribute
Multiple Forwarding Tables (cont.)
Each customer port on PE is associated with a particular Forwarding Table via configuration management (at provisioning time) Provides PE with per site (per VPN) forwarding information for packets received from CEs Ports on PE could be logical e.g., VLAN, FR, ATM, L2F, etc...
Address Extension
How to support VPNs without imposing constraints on address allocation/management within VPNs (e.g., allowing private address space [RFC1918]) ? constrained distribution of routing information uses BGP BGP is designed with the assumption that addresses are unique
VPN-IP Addresses
New address family: VPN-IP addresses VPN-IP address = Route Distinguisher (RD) + IP address RD = Type + Providers Autonomous System Number + Assigned Number
No two VPNs have the same RD
convert non-unique IP addresses into unique VPN-IP addresses Reachability information for VPN-IP addresses is carried via multiprotocol extensions to BGP-4
Converting between IP and VPN-IP addresses
Performed by PE in control plane only ingress PE - exporting route into providers BGP:
PE is configured with RD(s) for each directly attached VPN (directly attached sites) convert from IP to VPN-IP (by prepending RD) before exporting into providers BGP
egress PE - importing route from providers BGP:
convert from VPN-IP to IP (by stripping RD) before inserting into sites forwarding table
Route Distinguisher vs BGP Communities
Route Distinguisher: used to disambiguate IP addresses via VPN-IP addresses not used to constrain distribution of routing information (route filtering)
BGP Communities: not used to disambiguate IP addresses used to constrain distribution of routing information
via route filtering based on BGP Communities
MPLS
Given that BGP operates in term of VPN- IP addresses, how to forward IP packets within Service Provider(s) along the routes computed by BGP ?
IP header has no place to carry Route Distinguisher
MPLS (cont.)
Use MPLS for forwarding MPLS decouples information used for forwarding (label) from the information carried in the IP header Label Switched Paths (labels) are bound to VPN-IP routes Label Switched Paths are confined to VPN Service Provider(s)
Packet Forwarding - example
Logically separate forwarding table (FIB) for each (directly attached) VPN
IP PKT
PE LSR
Label 1. Identify VPN FIB Table
IP PKT
expressed in terms of IP address prefixes
conversion from VPN-IP to IP addresses happen when FIB is populated from the routing table (RIB)
3. Attach label info and send out
Incoming interface determines the FIB
Next Hop Label Info 2. Select FIB for this VPN
Two-level label stack
VPN routing information is carried only among PE routers (using BGP)
BGP Next Hop provides coupling between external routes (VPN routes) and service provider internal route (IGP routes)
route to Next Hop is an internal route
Top (first) level label is used for forwarding from ingress PE to egress PE inside the ISP cloud Bottom (second) level is used for forwarding at egress PE
distributed via BGP (together with the VPN route)
P routers maintain only internal routes (routes to PE routers and other P routers), but no VPN routes
Two-level label stack - example
CE1 PE1
IP packet
BGP (Dest = RD:10.1.1, Next-Hop = PE2, Label = X)
CE2
Service providers IGP Cloud (usually IS-IS)
IGP Label for PE2 via LDP/RSVP IGP Label for PE2 via LDP/RSVP
Dest = 10.1.1/24
PE2
IP packet
IGP Label for PE2 via LDP/RSVP
IGP Label(PE2)
VPN label = X
IP packet
P1
P2
VPN label = X IP packet
IGP Label(PE2)
VPN label = X IP packet
Scalability - divide and conquer
(1) Two levels of labels to keep P routers free of all the VPN routing information (2) PE router has to maintain routes only for VPNs whose sites are directly connected to the PE router (3) Partition BGP Route Reflectors within the VPN Service Provider among VPNs served by the Provider No single component within the system is required to maintain all routes for all the VPNs Capacity of the system isnt bounded by the capacity of an individual component
BGP/MPLS VPN - Summary
Supports large scale VPN services Increases value add by the VPN Service Provider Decreases Service Providers cost of providing VPN services Simplifies operations for VPN customers Mechanisms are general enough to enable VPN Service Provider to support a wide range of VPN customers
