DD2491 p2 2009 BGP-MPLS VPNs Olof Hagsand KTH/CSC
Literature Practical BGP: Chapter 10 JunOS Cookbook: Chapter 14 and 15
MPLS Advantages Originally, the motivation was speed and cost. But routers does IP lookup in hardware at very high speeds. Current advantages: Label switching can be used for traffic engineering Aggregating a class of traffic and treating it in a specific way Control of traffic in a network Labels can be used to forward using other fields than destination address Label switching can be used to support VPNs virtual private networks The generalized form of MPLS: GMPLS can be used for optical networking such as management of wavelengths: lambdas
Where is MPLS used? MPLS is used as a tunneling technique within an operator's internal IP network tunneling characteristics - traffic is isolated VPNs traffic engineering - control bandwidths and links MPLS is not used in traditional enterprise networks between operators (inter-as) L2 networks
Why MPLS? MPLS gives a simple tunneling mechanism integrated with IP BGP is not needed for transit traffic in interior routers: A BGP-free core Another IP-based tunneling protocol could give the same service IP in IP But MPLS has a nice toolbox and is easy to configure Alternatives Pure IP networking: manage tunnels yourself Provider backbone bridging (IEEE 802.1ah)
Typical use: MPLS for transit BGP BGP IGP + MPLS AS BGP Use an IGP to compute internal routes Setup LSPs between border routers using the IGP Eg border routers may set up a full-mesh of LSPs Send transit traffic via LSPs (src and dst outside the AS) But still send internal traffic via IP (src or dst inside the AS) External routes need not be distributed to non-border routers, so we do not need IBGP there A BGP-free core Only the border routers need to speak BGP This is considered an advantage
Protection switching in MPLS Assume a primary LSP is signalled from A-D via B and C If a link or node goes down, how is reliability ensured? There are several issues and techniques: Detection of failure IGP re-route Path protection Local protection A To think about Switchover latency Over-reservation B C E F D
MPLS in JunOS See http://www.juniper.net/techpubs/software/junos/junos94/ swconfig-mpls-apps Example: Enable mpls on all forwarding interfaces Enable icmp in mpls for debugging (traceroute) Setup LSPs (using explicit path setup: no cspf) interface so-0/0/0 { unit 0 { family mpls; # Enable mpls address family } } protocols mpls { icmp-tunneling; # Enable icmp for debugging interface so-0/0/0.0; # Include interface in mpls forwarding label-switched-path btoc { # Define an LSP to 193.10.255.6; # LSP end-point no-cspf; # Enable explicit-path computation } rsvp { interface so-0/0/0.0; # Enable rsvp on interface } cspf - Constrained Path LSP Computation Computes path using bandwidth, load, etc.
Motivation to VPNs Companies and organizations wish to connect their local offices, personel working from their home or while travelling. Leased lines are expensive, it makes sense to use IP / the Internet.
VPN Architecture 1 Connect hosts to central server/lan. Main LAN Internet Point-to-point tunnels
VPN Architecture 2 Connect several LAN islands. LAN LAN Internet LAN
Addressing and security The Internet is public and has only one address domain. You need to separate your private traffic from the global traffic You need to secure your traffic Provider-based VPNs (peer) You trust your provider Guarantee resources Provider adds service more costly One provider / set of providers only Customer-based VPNs (overlay) Do it yourself using IPSEC tunneling Cheap solution Best effort Internet
Provider-based VPNs using MPLS/RSVP/ BGP Several related variants including L3VPN RFC 4364 L2VPN pseudowires VPLS ( dynamic L2VPN ) These solutions all use multiprotocol BGP, relays data with MPLS and have a BGP-free core.
Provider-based VPNs CE - Customer Edge PE - Provider Edge (BGP) P - Provider (no BGP) More than one customer: red and blue More than two sites per customer CE is either router or L2 device CE CE PE PE CE P P CE CE PE PE
L3VPN L3VPN is a peer-type and dynamic VPN using BGP and MPLS Each customer may use the same adress space, eg 1918 addresses Each customer site is modelled as a separate AS customer interior routing runs independently at each site An address conversion scheme makes each customer VPN route unique within the provider's network Multiple routing and forwarding tables are supported on each PE separating different customer routing information BGP is used as a signalling protocol to setup VPN connections between customer sites. RSVP (or LDP) is used to setup the MPLS paths MPLS multistacking is used to keep provider's network free of customer routing information Encryption by other means, security by trusting the provider
L3VPN 192.16.100.0/24 CE CE 192.16.100.0/24 PE AS 65100 PE CE 10.2.1.0/24 P P CE 10.1.1.0/24 CE PE PE 10.1.1.0/24
View from one customer Provider network acts as a distributed router 192.16.100.0/24 AS 65100 10.2.1.0/24 10.1.1.0/24
CE to PE routing The local PE learns routes from the local customer CE Static routing, ebgp, RIP, or some other IGP Customer should be able to decide Often the customer wants a separate routing protocol for the CE-PE peering (eg. so OSPF link-state is not propagated to the provider) The PE router takes the routes and propagates them over the provider network to the remote PE:s The remote PE:s announce the client routes to matching remote CE sites The remote CE sites can then access the local CE
CE to PE routing I 192.16.100.0/24 H 192.16.100.0/24 OSPF B static routing AS 65100 D C F G 10.1.1.0/24 ebgp RIP A E J 10.1.1.0/24
Overlapping addresses: Route Distinguisher How does the provider keep the different client prefixes unique? A new address class is used, where a unique prefix is prepended to the IPv4 route Eg: Red and blue VPN both have 10.1.1.0/24 This unique prefix is called a route distinguisher (RD) The new route is written: <route distinguisher>::<ipv4addr>/<prefixlen> 8 bytes Route Distinguisher 4 bytes IPv4 address
Route Distinguisher I T Type[Subtype] 1 byte 1 byte Data 6-7 bytes The route distinguisher has the same format as the BGP extended community (see earlier lecture) which is 8 bytes. Two variants Type 0 and Type 1 Type 0 used in the book Can be better to identify VPNs, or if many AS Type 1 used primarily in the lab Easier to see the origin of the routes 8 bytes 4 bytes Route Distinguisher 2 bytes Type 0: Type/Subtype 2 bytes Type 1: Type/Subtype 2 bytes IPv4 address 4 bytes AS# Number 4 bytes IP# IPv4 address 2 bytes Number IPv4 address
Route distinguisher type 0 Example: 65100:3::192.16.100.0/24 announced by B 65100:4::192.16.100.0/24 announced by D I 192.16.100.0/24 H 192.16.100.0/24 B RD: 65100:3 AS 65100 RD: 65100:4 D C F RD: 65100:2 G 10.1.1.0/24 RD: 65100:1 A E J 10.1.1.0/24
Route distinguisher type 1 Example: 192.30.200.3:1::192.16.100.0/24 announced by B You can see where the routes come from And you can see which VPN they belong to (1=blue, 2=red) I 192.16.100.0/24 H 192.16.100.0/24 B RD: 192.30.200.3:1 AS 65100 RD: 192.30.200.4:2 D C F RD: 192.30.200.2:2 G 10.1.1.0/24 RD: 192.30.200.1:1 A E J 10.1.1.0/24
Routing table example Example: Routing table in a PE router (prefix + nexthop) VPN-IPv4 address family (bgp.l3vpn in JunOS) 192.30.200.3:1::192.168.100.0/24 B 192.30.200.2:2::10.1.1.0/24 A 192.30.200.1:1::10.1.1.0/24 E 192.30.200.4:2::192.168.100.0/24 IPv4 address family: 192.30.200.3 192.30.200.2 192.30.200.1 192.30.200.4 D
Operation A CE announces a prefix to a PE The PE prepends the route distinguisher and announces it to the other PE:s Eg 192.30.200.3:1::192.168.100.0/24 The PEs receive it, strips the route distinguisher and announces it to the local matching CE Eg 192.168.100.0/24 to B by H Eg 192.168.100.0/24 to J by E The CE network can reach 192.168.100.0/24
Operation: announcing prefixes 19 2. 16.1 192.16.100.0/24 H 00.0 /2 4 I 192.16.100.0/24 B RD: 192.30.200.3:1 65100 1AS 92 19. 2. 30 16.2.1 00 C 00.3.0 :1 /2 :: 4F RD: 192.30.200.2:2 G 10.1.1.0/24 RD: 192.30.200.4:2 D RD: 192.30.200.1:1 A 19 J 2 E.16.1 00.0 /2 4 10.1.1.0/24
Virtual Routing and Forwarding - VRF A virtual router is a subset of a physical router. A virtual router has its own routing processes, routing tables, forwarding tables and its own interfaces, Typically interfaces of virtual routers are virtual (eg VLANs) The virtual routers are partitioned into several disjoint virtual routers. Similar in concept to VLANs and VLAN bridges, but in L3. Virtual Physical...
VRF in a PE Example: A router with two customers instances: VRF1 and VRF2. VRF table VRF1 VRF1 VRF_ main VRF2 VRF_ main Local BGP table VRF table VRF2
VRF Importing and exporting Local BGP Table: import 192.30.200.1:1::10.1.1.0/24 192.168.100.0/24 10.1.1.0/24 192.168.100.0/24 H export 192.30.200.3:1::192.168.100.0/24 B RD: 192.30.200.3:1 C F E RD: 192.30.200.1:1 J 10.1.1.0/24 VRF:
Routing instances in JunOS Routing Instance: main RIBs Routing Instance: other RIBs inet.0 Routing protocol 3 RI B inet.0 IPv4 unicast routes inet6.0 IPv6 unicast routes inet.1 IPv4 multicast forwarding cache inet.2 IPv4 multicast RPF table IPv4 routes learnt from MPLS-TE path exploration VPN-IPv4 routes inet.3 bgp.l3vp n mpls.0 MPLS label-switch table Example: main.inet.0 juniper_private1.inet.0 Logical routers, VPNs, virtual routers, etc, use routing instances.
BGP signaling How does BGP carry the extended VPN-IPv4 extended adress family? By using the multiprotocol extension (see earlier lecture) MP_REACH and MP_UNREACH VPN-IPv4 is AFI= 1, SAFI = 128 The NLRI is The 12 byte route: distinguisher::ipv4 adress An MPLS forwarding label The next-hop is the CE nexthop
Using MPLS and RSVP Establish LSP:s between border routers Use double stacking: outer tag: LSP PE<-->PE inner tag: VPN label Internal nodes (P-nodes) are only aware of outer tags (PE to PE) With RSVP you set up the outer tag and can also traffic engineer the LSP:s outer: LSP label inner: VPN label VRF1 VRF1 2 23 VRF_ main VRF_ main 23 VRF2 1 VRF2
LSP label 20 Double push Swap F LSP label 10Pop IP: dst10.1.1.23 Route C MPLS: 10 IP: dst10.1.1.23 B MPLS: 9 MPLS: 10 IP: dst10.1.1.23 H MPLS: 8 MPLS: 10 IP: dst10.1.1.23 IP: dst10.1.1.23 Local routing table VRF Local BGP table MPLS table MPLS table Local BGP table VRF Local routing table MPLS Forwarding E J Pop+route
Route target We still have not described how the VPNs are constructed how PE:s know which CE:s are a part of which VPNs. The purpose of the route target (RT) extended community is to tag the VPN-IPv4 routes with this information The route target has the same format as the routedistinguisher AS#:number (type 0) IP#:number (type 1) The route target is used to color the routes In our example red and blue
Route target example Example: RT 65100:100 <-> blue VPN RT 65100:3 <-> red VPN Tag the routes when exporting to BGP I 192.16.100.0/24 H 192.16.100.0/24 B RD: 192.30.200.3:1 RT: 65100:100 AS 65100 D RD: 192.30.200.4:2 RT: 65100:3 C F RD: 192.30.200.2:2 RT: 65100:3 G 10.1.1.0/24 RD: 192.30.200.1:1 RT: 65100:100 A E J 10.1.1.0/24
Importing and exporting routes Routes are exported from the VRF to BGP And imported from BGP to the VRF Rules are defined using route targets How to export routes How to import routes Typically, every VRF has a set of import and export rules Every export rule corresponds to tagging the announced VPN-IPv4 route with a route target attribute Every import rule corresponds to matching targets with incoming route target attributes
Import and export Same as previous example using export and import rules This is the default policy (full mesh) and can be accomplished in JunOS without export/import using: set vrf-target target:<route target> I 192.16.100.0/24 H 192.16.100.0/24 B RD: 192.30.200.3:1 import: 65100:100 export: 65100:100 AS 65100 D C RD: 192.30.200.4:2 import: 65100:3 export: 65100:3 F RD: 192.30.200.2:2 import: 65100:3 export: 65100:3 10.1.1.0/24 G A E RD: 192.30.200.1:1 import: 65100:100 export: 65100:100 J 10.1.1.0/24
More elaborate examples More elaborate examples (apart from full mesh) can be made by using import and export rules in various ways The book has several examples Extranets Hub-and-spoke
Extranet The Extranet is defined between the upper two customer sites Note that the prefixes have been changed to be unique And the route targets are unique per PE I 192.16.101.0/24 H 192.16.102.0/24 B RD: 192.30.200.3:1 import: 65100:12 65100:21 export: 65100:22 AS 65100 D C RD: 192.30.200.4:2 import: 65100:11 65100:22 export: 65100:12 F RD: 192.30.200.2:2 import: 65100:12 export: 65100:11 10.1.1.0/24 G A E RD: 192.30.200.1:1 import: 65100:22 export: 65100:21 J 10.1.1.0/24
Hub-and-spoke VPN All traffic passes via a HUB Filtering / security purposes Note the two peerings at A I 10.1.3.0/24 H 10.1.4.0/24 B RD: 192.30.200.3:1 import: 65100:200 export: 65100:100 AS 65100 C RD: 192.30.200.2:2 export: 65100:200 F A K import: 65100:100 Filtering ibgp D RD: 192.30.200.4:2 import: 65100:200 export: 65100:100 G E RD: 192.30.200.1:1 import: 65100:200 export: 65100:100 J 10.1.1.0/24
Summary of protocols in L3VPN IP basic information carrier MPLS tunnels (LSPs) through the provider network RSVP or LDP label distribution to setup MPLS LSPs (outer labels) OSPF or ISIS Find shortest paths through provider network for RSVP and BGP BGP Distribition of reachability information (prefixes), VRF information and inner VPN labels CE-PE routing protocol. RIP?
L3VPN JunOS example protocols { bgp { local-address 192.30.200.3; group internal { type internal; family inet-vpn unicast; neighbor 192.30.200.1; } } } routing-instances { VRF1_BLUE { instance-type vrf; interface fe-0/0/0.0; route-distinguisher 192.30.200.3:1; vrf-target target:65100:100; vrf-table-label; protocols { bgp { group siteb { type external; peer-as 1; neighbor 192.16.100.1; # H } } } }
L3VPN Summary L3VPN is a peer-type and dynamic VPN using BGP and MPLS This way of creating VPNs have quickly become popular. Easy to configure (but hard to understand) Drawback: Customer routing tables are imported into the provider's network (PE:s) Suppose each customer has its own full BGP routing table (~200K routes) The providers routing tables will explode Typical encapsulation in provider's network: MPLS MPLS IP
L2VPN pseudo-wire Static, multipoint overlay solution Setup point-to-point L2 connections between every site in the VPN Pseudo-wires Using MPLS/RSVP/BGP in a similar way as L3VPN L2 frames are encapsulated using IP and MPLS Can transform between different link-layers Typical encapsulation in provider's network: MPLS MPLS ETH IP
Customer view: Switches as CE:s Provider network acts as a set of wires. Learning and spanning tree can be made by attaching learning bridges as CE:s to create a large LAN I
Customer view: Routers as CE:s Routers can communicate backto-back over an L2VPN I
Provider view: L2VPN Access circuits between CE/PE MPLS LSPs between PEs using RSVP BGP signals L2 circuits between sites CE Site 1 PE I CE Site 2 P P PE PE Site 3 CE
CE-PE issues Since CE-PE communication needs to distinguish between different circuits, it is common to use virtual connections, as CE-PE circuits, such as VLANs. You assign one VLAN per wire. There are many link-layers. You need to configure which encapsulation you use. We use 'ethernet-vlan', but it is possible to use other encapsulation types and translate between them using 'translational cross-connects'
Configuring L2VPN Setup the backbone: ISIS, MPLS, RSVP, ibgp as before but enable 'l2vpn signaling' as bgp protocol family Setup CE-PE circuits (VLANs) Use ethernet interface with units > 0 Set RFC1918 addresses on the VLANs Setup an l2vpn routing instance: Set route distinguisher Setup Sites and setup LSPs by connecting remote sites <PE loopback>:<vpnid> Bind vlans to remote sites using vlanids Setup encapsulation 'ethernet-vlan' Set no-control-word (used for other link-layers) Setup vpn import/export rules use vrf-target
Configuring VLAN example CE side: fe-1/0/0 { vlan-tagging; unit 15 { vlan-id 15; family inet { address 10.10.11.1/30; } } } PE side: no IP address, configure encapsulation vlan-ccc
L2VPN JunOS example routing-instances { l2vpn { description "experimental L2VPN"; instance-type l2vpn; interface fe-0/0/0.512; route-distinguisher 192.168.4.2:10; vrf-target target:1000:10; protocols { l2vpn { encapsulation-type ethernet-vlan; no-control-word; site red1 { site-identifier 1; interface fe-0/0/0.512 { remote-site-id 2; } } } } } }
Virtual Private LAN Services (VPLS) Dynamic, multipoint peer solution VPN services for L2 (eg switched networks) Backbone over IP Interconnects a switched L2 network In VPLS an IP network works as a distributed switch MPLS is used together with BGP to create pseudo-wires between the LAN islands. VPLS: Dynamic establishment of pseudo-wires Bridging (learning) enabled STP MP-BGP is used for distributing mac adress learning Disadvantage (similar to L3VPN) Provider imports MAC learning tables into network
View from one customer Customer B Provider network acts as a distributed switch Provider network performs learning (and STP) Customer B Customer B
Lab: L3VPN and L2VPN First build a backbone Core routers are pre-configured Then configure L3VPN Finally configure L2VPN
LAB backbone Backbone RTC1 RTB3 RTB4 RTC2 RTB1 RTB2 RTC3 RTC4
L3VPN lab setup: customer view (Yellow) Provider Edge (PE).1 10.1.2.0/30.2 RTD3.1 10.1.1.0/30.2 RTA3.1 10.1.3.0/30.2 Customer Edge (CE) RTE3
L2VPN lab setup: customer view (RED) 10.1.3.0/30 VLANID: 514 10.1.1.0/30 10.1.2.0/30 VLANID: 512 VLANID: 513.1.2.1.1.2.2 Customer Edge (CE) RTD2 RTA2 RTE2
LAB Netmap Backbone RTB3 RTB4 RTC1 RTC2 RTC2 RTA2 RTA3 RTC2 RTA4 RTE1 RTE2 RTE3 RTE4 L3VPN #4 L3VPN #3 L2VPN #2 L1VPN #1 L3VPN #4 L3VPN #3 RTA1 RTB2 L2VPN #2 L3VPN #3 L2VPN #2 L2VPN #1 RTD4 L2VPN #1 RTD2 RTD3 L3VPN #4 RTD1 RTB1