deploying mpls vpns-2up

© 2007, Cisco Systems, Inc. All rights reserved. Presentation_ID.scr

1

© 2007 Cisco Systems, Inc. All rights reserved. Cisco Confidential BRKRST-2102 13902_06_2007_x1 1

Deploying MPLS VPN Networks

BRKRST-2102


Other MPLS Related Sessions

  BRKRST-1101 Introduction to MPLS

  BRKRST-2102 Deploying MPLS VPNs

  BRKRST-2103 Migration Considerations When Buying MPLS VPN Services from Service Providers

  BRKRST-2104 Deploying MPLS Traffic Engineering

  BRKRST-2105 Inter-AS MPLS Solutions

  BRKRST-3101 Advanced Topics and Future Directions in MPLS

  TECAGG-2003 Layer 2 Virtual Private Networks

  LABRST-2105 Implementing MPLS in Service Provider Networks

  LABRST-2106 Enabling MPLS in Enterprise Networks


2


Agenda

 MPLS VPN Explained

 MPLS VPN Services

 Best Practices

 Conclusion


Prerequisites

 Must be willing to bet… … on MPLS VPN Networks

 Must understand basic IP routing, especially BGP

 Must understand MPLS basics (push, pop, swap, label stacking)

 Must be able to keep the speaker awake… … by asking Bad questions


3


Terminology

  LSR: Label switch router   LSP: Label switched path

The chain of labels that are swapped at each hop to get from one LSR to another

  VRF: VPN routing and forwarding Mechanism in Cisco IOS® used to build per-interface RIB and FIB

  MP-BGP: Multiprotocol BGP   PE: Provider edge router interfaces with CE routers   P: Provider (core) router, without knowledge of VPN   VPNv4: Address family used in BGP to carry MPLS-VPN routes   RD: Route distinguisher

Distinguish same network/mask prefix in different VRFs

  RT: Route target Extended community attribute used to control import and export policies of VPN routes

  LFIB: Label forwarding information base   FIB: Forwarding information base


Agenda

 MPLS VPN Explained Technology

Configuration

 MPLS-VPN Services

 Best Practices

 Conclusion


4


MPLS-VPN Technology

 Control plane—VPN route propagation

 Data plane—VPN packet forwarding


PE Routers   Edge routers

  Use MPLS with P routers

  Uses IP with CE routers

  Connects to both CE and P routers Distribute VPN information through MP-BGP to other PE router with VPN-IPv4 addresses, extended community, label

P Routers   P routers are in the core of the

MPLS cloud

  P routers do not need to run BGP and doesn’t need to have any VPN knowledge

  Forward packets by looking at labels

  P and PE routers share a common IGP

PE  VPN Backbone IGP

MP-iBGP Session

PE P P

P P

MPLS-VPN Technology MPLS VPN Connection Model


5


MPLS-VPN Technology Separate Routing Tables at PE

The Global Routing Table   Populated by the IGP

within MPLS backbone

CE

PE

CE VPN 1

VPN 2

 MPLS Backbone IGP (OSPF, ISIS)

VRF Routing Table   Routing (RIB) and forwarding table

(CEF) associated with one or more directly connected sites (CEs)

  The routes the PE receives from CE routers are installed in the appropriate VRF routing table(s)

blue VRF routing table or

green VRF routing table


MPLS-VPN Technology Virtual Routing and Forwarding Instance (1)

  What’s a VRF ?

  Associates to one or more interfaces on PE Privatize an interface i.e., coloring of the interface

  Has its own routing table and forwarding table (CEF)

  VRF has its own instance for the routing protocol (static, RIP, BGP, EIGRP, OSPF)

  CE router runs standard routing software

VRF Blue

VRF Green

 EBGP, OSPF, RIPv2, Static

CE

PE

CE VPN 1

VPN 2

 MPLS Backbone IGP (OSPF, ISIS)


6


MPLS-VPN Technology Virtual Routing and Forwarding Instance (2)

 PE installs the routes, learned from CE routers, in the appropriate VRF routing table(s)

 PE installs the IGP (backbone) routes in the global routing table

 VPN customers can use overlapping IP addresses

PE  MPLS Backbone IGP (OSPF, ISIS)

CE

CE VPN 1

VPN 2

 EBGP, OSPF, RIPv2, Static


MPLS-VPN Technology Control Plane

Let’s Discuss:   Route Distinguisher (RD); VPNv4 route

  Route Target (RT)

  Label

8 Bytes

Route-Target

3 Bytes

Label

MP_REACH_NLRI attribute within MP-BGP UPDATE message

1:1

8 Bytes 4 Bytes

RD IPv4 VPNv4

10.1.1.0


7


MPLS VPN Control Plane MP-BGP Update Components: VPNv4 Address

 To convert an IPv4 address into a VPNv4 address, RD is appended to the IPv4 address i.e. 1:1:10.1.1.0

Makes the customer’s IPv4 route globally unique

 Each VRF must be configured with an RD at the PE RD is what that defines the VRF

8 Bytes

Route-Target

3 Bytes

Label

MP-IBGP update with RD, RT, and label

1:1

8 Bytes 4 Bytes

RD IPv4 VPNv4

10.1.1.0

! ip vrf v1 rd 1:1 !


MPLS VPN Control Plane MP-BGP Update Components: Route-Target

 Route-target (RT): Identifies the VRF for the received VPNv4 prefix. It is an 8-byte extended community (a BGP attribute)

 Each VRF is configured with RT(s) at the PE RT helps to color the prefix !

ip vrf v1 route-target import 1:1 route-target export 1:2 !

8 Bytes

Route-Target

3 Bytes

Label

MP-IBGP update with RD, RT, and Label

1:1

8 Bytes 4 Bytes

RD IPv4 VPNv4

10.1.1.0 2:2


8


MPLS VPN Control Plane MP-BGP Update Components: Label

  The Label (for the VPNv4 prefix) is assigned only by the PE whose address is the next-hop attribute

PE routers rewrite the next-hop with their own address (loopback)

“Next-hop-self” towards MP-iBGP neighbors by default

  PE addresses used as BGP next-hop must be uniquely known in the backbone IGP

Do Not Summarize the PE Loopback Addresses in the Core

3 Bytes

Label

MP-IBGP update with RD, RT, and label

1:1

8 Bytes 4 Bytes

RD IPv4 VPNv4

10.1.1.0 2:2 50

8 Bytes

Route-Target


MPLS VPN Control Plane Putting It All Together

1.  PE1 receives an IPv4 update (eBGP/OSPF/ISIS/RIP/EIGRP)

2.  PE1 translates it into VPNv4 address Assigns an RT per VRF configuration

Rewrites next-hop attribute to itself

Assigns a label based on VRF and/or interface

5.  PE1 sends MP-iBGP update to other PE routers

10.1.1.0/24 Next-Hop=CE-1

MP-iBGP Update: RD:10.1.1.0 Next-Hop=PE-1 RT=Green, Label=100

1

3

10.1.1.0/24

PE1 PE2 P

P P

P

CE2 CE1

MPLS Backbone

Site 1 Site 2


9


MPLS VPN Control Plane Putting It All Together

4.  PE2 receives and checks whether the RT=green (40:103, say) is locally configured within any VRF, if yes, then

5.  PE2 translates VPNv4 prefix back into IPv4 prefix, Installs the prefix into the VRF routing table

Updates the VRF CEF table with label=100 for 10.1.1.0/24

Advertise this IPv4 prefix to CE2 (using EBGP/RIP/OSPF/ISIS/EIGRP)

5

10.1.1.0/24 Next-Hop=CE-1

MP-iBGP Update: RD:10.1.1.0 Next-Hop=PE-1 RT=Green, Label=100

10.1.1.0/24

MPLS Backbone

Site 1 Site 2 10.1.1.0/24 Next-Hop=PE-2

1

3

PE1 PE2 P

P P

P

CE2 CE1


MPLS-VPN Technology Forwarding Plane

The Global Forwarding Table (show ip cef)   PE routers store IGP routes

  Associated labels

  Label distributed through LDP/TDP

VRF Forwarding Table (show ip cef vrf <vrf>)   PE routers store VPN routes

  Associated labels

  Labels distributed through MP-BGP

Global Routing/Forwarding Table Dest->Next-Hop PE2 P1, Label: 50

Global Routing/Forwarding Table Dest->Next-Hop PE1 P2, Label: 25

10.1.1.0/24 Next-Hop=CE-1

10.1.1.0/24

Site 1 Site 2

VRF Green Forwarding Table Dest->NextHop 10.1.1.0/24-PE1, label: 100

PE1 PE2 P2

P P

P1

CE2 CE1


10


10.1.1.0/24

PE1 PE2

CE2 CE1 Site 1 Site 2

10.1.1.1

P

P P

P

10.1.1.1 100 50

MPLS-VPN Technology Forwarding Plane

  PE2 imposes TWO labels for each packet going to the VPN destination 10.1.1.1

  The top label is LDP learned and derived from an IGP route Represents LSP to PE address (exit point of a VPN route)

  The second label is learned via MP-BGP Corresponds to the VPN address

10.1.1.1

10.1.1.1 100

10.1.1.1 100 25


Agenda

 MPLS VPN Explained Technology

Configuration


 Best Practices

 Conclusion


11


MPLS VPN Sample Configuration (Cisco IOS)

10.1.1.0/24

ip vrf VPN-A rd 1:1 route-target export 100:1 route-target import 100:1

interface Serial0 ip address 192.168.10.1 255.255.255.0 ip vrf forwarding VPN-A

VRF Definition

PE1

CE1 Site 1

192.168.10.1 Se0

PE1

PE-P Configuration

Se0 P

PE1 s1

Interface Serial1 ip address 130.130.1.1 255.255.255.252 mpls ip

router ospf 1 network 130.130.1.0 0.0.0.3 area 0

PE1



PE: MP-IBGP

RR: MP-IBGP

router bgp 1 neighbor 1.2.3.4 remote-as 1 neighbor 1.2.3.4 update-source loopback0 ! address-family vpnv4 neighbor 1.2.3.4 activate neighbor 1.2.3.4 send-community both !

PE1

router bgp 1 no bgp default route-target filter neighbor 1.2.3.6 remote-as 1 neighbor 1.2.3.6 update-source loopback0 ! address-family vpnv4 neighbor 1.2.3.6 route-reflector- client neighbor 1.2.3.6 activate !

RR

PE1 PE2

RR

PE1 PE2

RR


12



router bgp 1 ! address-family ipv4 vrf VPN-A neighbor 192.168.10.2 remote-as 2 neighbor 192.168.10.2 activate exit-address-family !

PE-CE BGP

PE-CE OSPF router ospf 1 ! router ospf 2 vrf VPN-A network 192.168.10.0 0.0.0.255 area 0 redistribute bgp 1 subnets !

PE1

PE1

10.1.1.0/24

PE1

CE1 Site 1

192.168.10.1

192.168.10.2

10.1.1.0/24

PE1

CE1 Site 1

192.168.10.1

192.168.10.2



router rip ! address-family ipv4 vrf VPN-A version 2 no auto-summary network 192.168.10.0 redistribute bgp 1 metric transparent !

PE-CE RIP

PE-CE EIGRP router eigrp 1 ! address-family ipv4 vrf VPN-A no auto-summary network 192.168.10.0 0.0.0.255 autonomous-system 1 redistribute bgp 1 metric 100000 100 255 1 1500 !

10.1.1.0/24

PE1

CE1 Site 1

192.168.10.1

192.168.10.2

10.1.1.0/24

PE1

CE1 Site 1

192.168.10.1

192.168.10.2


13



ip route vrf VPN-A 10.1.1.0 255.255.255.0 192.168.10.2

PE-CE Static

PE-CE MB-iBGP Routes to VPN router rip address-family ipv4 vrf VPN-A version 2 redistribute bgp 1 metric transparent no auto-summary network 192.168.10.0 exit-address-family

If PE-CE protocol is non-BGP, then redistribution of other sites VPN routes from MP-IBGP is required (shown below for RIP) -

10.1.1.0/24

PE1

CE1 Site 1

192.168.10.1

192.168.10.2

PE1

RR

CE1

Site 1



 For config hands-on, please attend “Configuring MPLS VPNs” (LABCRT-2208) session

 Having familiarized with Cisco IOS based config, let’s glance through the IOX based config for VPNs

router bgp 1 neighbor 1.2.3.4 remote-as 1 neighbor 1.2.3.4 update-source loopback 0

address-family ipv4 vrf VPN-A redistribute {rip|connected|static|eigrp|ospf}

PE-RR (VPN Routes to VPNv4)

If PE-CE protocol is non-BGP, then redistribution of local VPN routes into MP-IBGP is required (shown below) -

PE1

RR

CE1

Site 1


14


MPLS VPN Sample Configuration (IOX)

10.1.1.0/24

vrf VPN-A router-id 192.168.10.1 address-family ipv4 unicast

import route-target 100:1 export route-target 100:1 export route-policy raj-exp

interface Serial0 vrf VPN-A ipv4 address 192.168.10.1/24

VRF Definition

PE1

CE1 Site 1

192.168.10.1 Se0

PE1

router bgp 1 vrf VPN-A rd 1:1 address-family ipv4 unicast redistribute connected ! neighbor 192.168.10.2 remote-as 2 address-family ipv4 unicast route-policy raj-temp in ! ! ! !

PE-CE BGP

PE1 10.1.1.0/24

PE1

CE1 Site 1

192.168.10.1

192.168.10.2


Agenda

  MPLS VPN Explained

  MPLS-VPN Services 1.  Providing Load-Shared Traffic to the Multihomed VPN Sites

2.  Providing Hub and Spoke Service to the VPN Customers

3.  Providing MPLS VPN Extranet Service

4.  Providing Internet Access Service to VPN Customers

5.  Providing VRF-Selection Based Services

6.  Providing Remote Access MPLS VPN

7.  Providing VRF-Aware NAT Services

8.  Providing QoS Service to VPNs

9.  Providing Multicast Service to VPNs

10.  Providing MPLS/VPN over IP transport

11.  Providing Multi-VRF CE Service

  Best Practices

  Conclusion


15


PE11

PE2

MPLS Backbone

PE12

CE1

Site A

171.68.2.0/24

Site B

CE2

RR

MPLS VPN Services: 1. Loadsharing for the VPN Traffic

 VPN sites (such as Site A) could be multihomed

 VPN customer may demand the traffic (to the multihomed site) be loadshared

Route Advertisement


MPLS VPN Services: 1. Loadsharing for the VPN Traffic: Cases

Site A

171.68.2.0/24

2 CEs 2 PEs

PE11

PE2

MPLS Backbone

PE12 Site B

CE2

RR

Traffic Flow

CE2

CE1

PE11

PE2

MPLS Backbone

PE12

171.68.2.0/24

Site B

CE2

RR

Traffic Flow

1 CE 2 PEs

Site A

CE1


16


MPLS VPN Services: 1. Loadsharing for the VPN Traffic: Deployment

  How to deploy the loadsharing?   Configure unique RD per VRF per PE for multihomed

site/interfaces   Enable BGP multipath within the relevant BGP VRF

address-family at remote/receiving PE2 (why PE2?)

PE11

PE2

MPLS Backbone PE12

CE1

Site A

171.68.2.0/24

Site B

CE2

RR

ip vrf green rd 300:11 route-target both 1:1

1


1

router bgp 1 address-family ipv4 vrf green maximum-paths eibgp 2

2


1


MPLS VPN Services: 1. Loadsharing for the VPN Traffic

  If RR exists in the network, then RR must advertise all the BGP paths learned via PE11 and PE12 to the remote PE routers that are to select BGP multipaths

Please note that without ‘unique RD per VRF per PE’, RR would advertise only one of the received paths for 171.68.2.0/24 to other PEs

  Watch out for the increased memory consumption (within BGP) due to multipaths at the PEs

  “eiBGP multipath” implicitly provides both eBGP and iBGP multipath for VPN paths

PE11

PE2

MPLS Backbone PE12

CE1

Site A

171.68.2.0/24

Site B

CE2

RR Route Advertisement


17


MPLS VPN Services: 1. VPN Fast Convergence – PE-CE Link Failure

  In a classic case, PE11, upon detecting the PE-CE link failure, sends BGP message to withdraw all the related VPN routes from the MPLS/VPN network

This results in the remote PE routers selecting the alternate bestpath (if any), but until then, they keep sending the MPLS/VPN traffic to PE11, which keeps dropping the traffic

  Cisco IOS and IOX now have incorporated a “Fast Local Repair” feature to minimize the loss due to the PE-CE link failure from sec to msec

PE11

PE2

MPLS Backbone PE12

CE1

Site A

171.68.2.0/24

Site B

CE2

RR VPN Traffic Redirected VPN traffic

Traffic is dropped by PE11


MPLS VPN Services: 1. VPN Fast Convergence – PE-CE Link Failure

  This feature helps PE11 to minimize the traffic loss from sec to msec, by redirecting the CE1 bound traffic to PE12 (with the right label), which forwards the traffic to CE1

PE11 reprograms the forwarding entry after selecting the alternate BGP best path (which is via PE12)

  In parallel, PE11 sends the ‘BGP withdraw message’ to RR/PE2, which will run the bestpath algorithm and removes the path learned via PE11, and then adjust their forwarding entries via PE12

  This feature is independent of whether multipath is enabled on PE2 or not, however, dependent on VPN site multihoming

PE11

PE2

MPLS Backbone PE12

CE1

Site A

171.68.2.0/24

Site B

CE2

RR VPN Traffic Redirected VPN traffic

Traffic is redirected by PE11


18


Agenda













  Best Practices

  Conclusion


MPLS-VPN Services: 2. Hub and Spoke Service to the VPN Customers

 Traditionally, VPN deployments are Hub and Spoke Spoke to spoke communication is via Hub site only

 Despite MPLS VPN’s implicit any-to-any, i.e, full-mesh connectivity, Hub and Spoke service can easily be offered

Done with import and export of route-target (RT) values

 PE routers can run any routing protocol with VPN customer’s Hub and spoke sites independently


19


MPLS-VPN Services: 2. Hub and Spoke Service: Configuration

PE-SA

PE-Hub

MPLS VPN Backbone PE-SB

CE-SA

CE-SB Spoke B

Spoke A 171.68.1.0/24

171.68.2.0/24

Eth0/0.2 Eth0/0.1

ip vrf green-spoke1 description VRF for SPOKE A rd 300:111 route-target export 1:1 route-target import 2:2

ip vrf green-spoke2 description VRF for SPOKE B rd 300:112 route-target export 1:1 route-target import 2:2

ip vrf HUB-IN description VRF for traffic to HUB rd 300:12 route-target export 2:2

ip vrf HUB-OUT description VRF for traffic from HUB rd 300:11 route-target import 1:1

Note - Only VRF configuration is shown here.



  If BGP is used between every PE and CE, then as-override and allowas-in knobs must be used at the PE_Hub*

Otherwise AS_PATH looping will occur

  If the spoke sites only need the default route from the hub site, then it is possible to use a single interface between PE-hub and CE-hub (instead of two interfaces as shown on the previous slide)

Let CE-hub router advertise the default or aggregate

Avoid generating a BGP aggregate at the PE

* Configuration for this is shown on the next slide


20


router bgp <ASN> address-family ipv4 vrf HUB-IN neighbor <CE> allowas-in 2


PE-SA

PE-Hub

MPLS VPN Backbone PE-SB

CE-SA

CE-SB Spoke B

Spoke A 171.68.1.0/24

171.68.2.0/24

Eth0/0.2 Eth0/0.1

ip vrf green-spoke1 description VRF for SPOKE A rd 300:111 route-target export 1:1 route-target import 2:2

ip vrf green-spoke2 description VRF for SPOKE B rd 300:112 route-target export 1:1 route-target import 2:2


router bgp <ASN> address-family ipv4 vrf HUB-OUT neighbor <CE> as-override

ip vrf HUB-OUT description VRF for traffic from HUB rd 300:11 route-target import 1:1


MPLS-VPN Services: 2. Hub and Spoke Service: Control Plane

  Two VRFs at the PE-hub: VRF HUB_OUT would have knowledge of every spoke routes

VRF HUB_IN only have a 171.68.0.0/16 route and advertise that to spoke PEs

  Import and export route-target within a VRF must be different

PE-SA

MPLS Backbone

PE-SB

CE-SA

CE-SB Spoke B

Spoke A

VRF HUB-IN

VRF HUB-OUT

VRF HUB-OUT RT and LFIB Destination NextHop Label 171.68.1.0/24 PE-SA 40 171.68.2.0/24 PE-SB 50

171.68.1.0/24

PE-Hub

MP-iBGP 171.68.2.0/24 Label 50 Route-Target 1:1


VRF RT and LFIB at PE-SA 171.68.0.0/16 PE-Hub 35 171.68.1.0/24 CE-SA

VRF RT and LFIB at PE-SB 171.68.0.0/16 PE-Hub 35 171.68.2.0/24 CE-SB

171.68.2.0/24

VRF HUB-IN Routing Table Destination NextHop 171.68.0.0/16 CE-H1



21


PE-SA

PE-Hub

MPLS Backbone

MPLS-VPN Services: 2. Hub and Spoke Service: Forwarding Plane

PE-SB

CE-SA

CE-SB Spoke B

Spoke A

VRF HUB-IN

VRF HUB-OUT

171.68.1.0/24

171.68.2.0/24

171.68.1.1

L1 35 171.68.1.1

L2 40 171.68.1.1

171.68.1.1

L1 is the label to get to PE-Hub

L2 is the label to get to PE-SA

This is how the spoke-to-spoke traffic flows -


MPLS-VPN Services: 2. Hub and Spoke Service: Half-Duplex VRF

 Why do we need Half-duplex VRF?

  If more than one spoke router (CE) connects to the same PE router within the single VRF, then such spokes can reach other without needing the Hub

This defeats the purpose of doing Hub and Spoke

 Half-duplex VRF is the answer Half-duplex VRF is specific to virtual-template* i.e. dial-user

  It requires two VRFs on the PE (Spoke) router Upstream VRF for Spoke->Hub communication

Downstream VRF for Spoke<-Hub communication

* Being extended to other interfaces as well


22


PE-SA

PE-Hub

MPLS Backbone

MPLS-VPN Services: 2. Hub and Spoke Service: Half-Duplex VRF

CE-SA

CE-SB Spoke B

Spoke A 171.68.1.0/24

171.68.2.0/24

PE-SA installs the spoke routes only in downstream VRF i.e. blue-VRF PE-SA forwards the incoming IP traffic (from Spokes) using the upstream VRF i.e. red-vrf routing table


Int virtual-template1 …. ip vrf forward red-vrf downstream blue-vrf …

Upstream VRF Downstream VRF

ip vrf red-vrf description VRF – upstream flow rd 300:111 route-target import 2:2

ip vrf blue-vrf description VRF – downstream flow rd 300:112 route-target export 1:1 ip vrf HUB-OUT

description VRF for traffic from HUB rd 300:11 route-target import 1:1


Agenda













  Best Practices

  Conclusion


23


MPLS-VPN Services 3. Extranet VPN

 MPLS VPN, by default, isolates one VPN customer from another

Separate virtual routing table for each VPN customer

 Communication between VPNs may be required i.e., extranet

External intercompany communication (dealers with manufacturer, retailer with wholesale provider, etc.)

Management VPN, shared-service VPN, etc.

 Needs right import and export route-target (RT) values configuration within the VRFs

Export-map or import-map should be used


 VPN_B Site#1 180.1.0.0/16

3. MPLS-VPN Services: Extranet VPN Goal: Only VPN_A site#1 to Be Reachable to VPN_B

171.68.0.0/16 PE1 PE2

MPLS Backbone  VPN_A Site#2

SO P

 VPN_A Site#1

ip vrf VPN_A rd 3000:111 export map VPN_A_Export import map VPN_A_Import route-target import 3000:111 route-target export 3000:111 route-target import 3000:1 ! route-map VPN_A_Export permit 10 match ip address 1 set extcommunity rt 3000:2 ! route-map VPN_A_Import permit 10 match ip address 2 ! access-list 1 permit 171.68.0.0 0.0.0.0 access-list 2 permit 180.1.0.0 0.0.0.0

ip vrf VPN_B rd 3000:222 export map VPN_B_Export import map VPN_B_Import route-target import 3000:222 route-target export 3000:222 route-target import 3000:2 ! route-map VPN_B_Export permit 10 match ip address 2 set extcommunity rt 3000:1 ! route-map VPN_B_Import permit 10 match ip address 1 ! access-list 1 permit 171.68.0.0 0.0.0.0 access-list 2 permit 180.1.0.0 0.0.0.0

192.6.0.0/16

Only Site#1 of both VPN_A and VPN_B would Communicate with Each Other, Site#2 Won’t be part of it.


24


Agenda













  Best Practices

  Conclusion


MPLS-VPN Services 4. Internet Access Service to VPN Customers

  Internet access service could be provided as another value-added service to VPN customers

 Security mechanism must be in place at both provider network and customer network

To protect from the Internet vulnerabilities

 VPN customers benefit from the single point of contact for both Intranet and Internet connectivity


25


MPLS-VPN Services 4. Internet Access: Different Methods of Service

Four ways to provide the Internet service 1.  VRF specific default route with “global” keyword

2.  Separate PE-CE sub-interface (non-VRF)

3.  Extranet with Internet-VRF

4.  VRF-aware NAT


MPLS-VPN Services 4. Internet Access: Different Methods of Service

1.  VRF specific default route 1.1 Static default route to move traffic from VRF to Internet

(global routing table)

1.2 Static routes for VPN customers to move traffic from Internet (global routing table) to VRF

3.  Separate PE-CE sub-interface (non-VRF) May run BGP to propagate Internet routes between PE and CE

5.  Extranet with Internet-VRF VPN packets never leave VRF context; issue with overlapping VPN address

7.  Extranet with Internet-VRF along with VRF-aware NAT VPN packets never leave VRF context; works well with overlapping VPN address


26


192.168.1.2

MPLS-VPN Services: 4.1 Internet Access: VRF Specific Default Route

  A default route, pointing to the ASBR, is installed into the site VRF at each PE

  The static route, pointing to the VRF interface, is installed in the global routing table and redistributed into BGP

PE1 ASBR

CE1 MPLS Backbone

192.168.1.1 Internet GW

SO

P PE1# ip vrf VPN-A rd 100:1 route-target both 100:1

Interface Serial0 ip address 192.168.10.1 255.255.255.0 ip vrf forwarding VPN-A

Router bgp 100 no bgp default ipv4-unicast redistribute static neighbor 192.168.1.1 remote 100 neighbor 192.168.1.1 activate neighbor 192.168.1.1 next-hop-self neighbor 192.168.1.1 update-source loopback0

ip route vrf VPN-A 0.0.0.0 0.0.0.0 192.168.1.1 global ip route 171.68.0.0 255.255.0.0 Serial0

Site1  Internet 171.68.0.0/16


Cons

Using default route for Internet routing does NOT allow any other default route for intra-VPN routing Increasing size of global routing table by leaking VPN routes

Static configuration (possibility of traffic blackholing)

MPLS-VPN Services: 4.1 Internet Access: VRF Specific Default Route (Forwarding)

171.68.0.0/16

PE1 PE2

192.168.1.1

Se0 P

VRF Routing/FIB Table Destination Label/Interface 0.0.0.0/0 192.168.1.1 (global) Site-1 Serial 0

Global Routing/FIB Table Destination Label/Interface 192.168.1.1/32 Label=30 171.68.0.0/16 Serial 0

IP Packet D=Cisco.com

Label = 30 IP Packet D=Cisco.com

Label = 35 IP Packet D=171.68.1.1

 Internet

Global Table and LFIB Destination Label/Interface 192.168.1.2/32 Label=35 171.68.0.0/16 192.168.1.2 Internet Serial 0

192.168.1.2

IP Packet D=171.68.1.1

Pros

Different Internet gateways can be used for different VRFs PE routers need not to hold the Internet table Simple configuration

Site1

SO

MPLS Backbone IP Packet D=Cisco.com

IP Packet D=171.68.1.1


27


MPLS-VPN Services 4.2 Internet Access

1.  VRF specific default route 1.1 Static default route to move traffic from VRF to Internet

(global routing table)

1.2 Static routes for VPN customers to move traffic from Internet (global routing table) to VRF

3.  Separate PE-CE sub-interface (non-VRF) May run BGP to propagate Internet routes between PE and CE

5.  Extranet with Internet-VRF VPN packets never leave VRF context; overlapping VPN addresses could be a problem

7.  Extranet with Internet-VRF along with VRF-aware NAT VPN packets never leave VRF context; works well with overlapping VPN addresses


  One sub-interface for VPN routing associated to a VRF

  Another sub-interface for Internet routing associated to the global routing table

  Could advertise full Internet routes or a default route to CE

  The PE will need to advertise VPN routes to the Internet (via global routing table)

4.2 Internet Access Service to VPN Customers Using Separate Sub-Interface (Config)

ip vrf VPN-A rd 100:1 route-target both 100:1

Interface Serial0.1 ip vrf forwarding VPN-A ip address 192.168.20.1 255.255.255.0 frame-relay interface-dlci 100 ! Interface Serial0.2 ip address 171.68.10.1 255.255.255.0 frame-relay interface-dlci 200 !

Router bgp 100 no bgp default ipv4-unicast neighbor 171.68.10.2 remote-as 502

171.68.0.0/16

PE1 ASBR

CE1

MPLS Backbone

Internet GW

192.168.1.1 Se0.2

P

BGP-4

Site1

192.168.1.2 Se0.1

 Internet  Internet


28


171.68.0.0/16

PE1 PE2

MPLS Backbone

PE-Internet GW

192.168.1.1 S0.2

P

Site1

192.168.1.2 S0.1

 Internet  Internet IP Packet D=Cisco.com

CE Routing Table VPN Routes Serial0.1 Internet Routes Serial0.2

PE Global Table and FIB Internet Routes 192.168.1.1 192.168.1.1 Label=30

Label = 30 IP Packet D=Cisco.com IP Packet

D=Cisco.com

Pros

CE could dual home and perform optimal routing

Traffic separation done by CE

Cons

PE to hold full Internet routes

BGP complexities introduced in CE; CE1 may need to aggregate to avoid AS_PATH looping

Internet Access Service to VPN Customer 4.2 Using Separate Sub-Interface (Forwarding)


Internet Access Service 4.3 Extranet with Internet-VRF

 The Internet routes could be placed within the VRF at the Internet-GW i.e. ASBR

 VRFs for customers could ‘extranet’ with the Internet VRF and receive either default, partial or full Internet routes

 Be careful if multiple customer VRFs, at the same PE, are importing full Internet routes

 Works well only if the VPN customers don’t have overlapping addresses


29


Internet Access Service 4.4 Internet Access Using VRF-Aware NAT

  If the VPN customers need Internet access without Internet routes, then VRF-aware NAT can be used at the Internet-GW i.e. ASBR

 The Internet GW doesn’t need to have Internet routes either

 Overlapping VPN addresses is no longer a problem

 More in the “VRF-aware NAT” slides…


Agenda













  Best Practices

  Conclusion


30


MPLS VPN Service 5. VRF-Selection

 The common notion is that a single VRF must be associated to an interface

  “VRF-selection” breaks this association and enables to associate multiple VRFs to an interface

 Each packet on the PE-CE interface could be handled (based on certain criteria) via different VRF routing tables

Criteria such as source/dest IP address, ToS, TCP port, etc. specified via a route-map

 Voice and data can be separated out into different VRFs at the PE; Service enabler


MPLS VPN Service 5. VRF-Selection: Based on Source IP Address

PE1 PE2 MPLS Backbone

(Cable Company) CE1

RR

44.3.12.1

66.3.0.0/16 VPN Green

66.3.1.25

33.3.14.1

44.3.0.0/16 VPN Blue

Global Interface

Se0/0 Cable Setup

VRF Interfaces

Traffic Flows

ip vrf brown rd 3000:111 route-target export 3000:1 route-target import 3000:1 ! ip vrf blue rd 3000:222 route-target export 3000:2 route-target import 3000:2 ! ip vrf green rd 3000:333 route-target export 3000:3 route-target import 3000:3

route-map PBR-VRF-Selection permit 10 match ip address 40 set vrf brown

route-map PBR-VRF-Selection permit 20 match ip address 50 set vrf blue

route-map PBR-VRF-Selection permit 30 match ip address 60 set vrf green

interface Serial0/0 ip address 215.2.0.6 255.255.255.252 ip policy route-map PBR-VRF-Selection ip receive brown ip receive blue ip receive green

access-list 40 permit 33.3.0.0 0.0.255.255 access-list 50 permit 44.3.0.0 0.0.255.255 access-list 60 permit 66.3.0.0 0.0.255.255

33.3.0.0/16 VPN Brown


31


Agenda













  Best Practices

  Conclusion


MPLS VPN Service 6. Remote Access Service

 Remote access users i.e. dial users, IPSec users could directly be terminated in VRF

PPP users can be terminated into VRFs

IPSec tunnels can be terminated into VRFs

 Remote access services integration with MPLS VPN opens up new opportunities for providers and VPN customers

BRKSEC-2010 Deploying Remote-Access IPSec/SSL VPNs

  “Remote Access” is not to be confused by “GET VPN” that provides any-to-any (CE-based) security service

BRKSEC-4012 Advanced IPSec with GET VPN


32


 Internet

MPLS VPN Service 6. Remote Access Service: IPSec to MPLS VPN

Corporate Intranet Branch Office Access

Remote Users/ Telecommuters

MPLS VPN IPSec Session IP IP

Cable/DSL/ ISDN ISP

IP/MPLS/Layer 2 Based Network

VPN A

VPN B

SP Shared Network

Customer B

Customer A head office

Customer C

PE

PE

VPN C

SOHO

Local or Direct

Dial ISP

Cisco IOS VPN Routers or Cisco Client 3.x or higher

Customer A Branch Office

PE

SP AAA Customer AAA PE+IPSec

Aggregator

VPN A

IKE_ID is used to map

the IPSec tunnel to the VRF

(within the ISAKMP profile)


Agenda













  Best Practices

  Conclusion


33


MPLS-VPN Services 7. VRF-Aware NAT Services

 VPN customers could be using ‘overlapping’ IP address i.e. 10.0.0.0/8

 Such VPN customers must NAT their traffic before using either “Extranet” or “Internet” or any shared* services

 PE is capable of NATting the VPN packets (eliminating the need for an extra NAT device)

* VoIP, Hosted Content, Management, etc.


MPLS-VPN Services 7. VRF-Aware NAT Services

 Typically, inside interface(s) connect to private address space and outside interface(s) connect to global address space

NAT occurs after routing for traffic from inside-to-outside interfaces

NAT occurs before routing for traffic from outside-to-inside interfaces

 Each NAT entry is associated with the VRF

 Works on VPN packets in the following switch paths: IP->IP, IP->MPLS and MPLS->IP


34


 Internet 217.34.42.2 .1

MPLS-VPN Services 7. VRF-Aware NAT Services: Internet Access

PE11

PE-ASBR

MPLS Backbone

PE12

CE1

Blue VPN Site 10.1.1.0/24

P

CE2

10.1.1.0/24

Green VPN Site

IP NAT Inside

IP NAT Outside

VRF-Aware NAT Specific Config VRF Specific Config

ip nat pool pool-green 24.1.1.0 24.1.1.254 prefix-length 24

ip nat pool pool-blue 25.1.1.0 25.1.1.254 prefix-length 24

ip nat inside source list vpn-to-nat pool pool-green vrf green ip nat inside source list vpn-to-nat pool pool-blue vrf blue

ip access-list standard vpn-to-nat permit 10.1.1.0 0.0.0.255

ip route vrf green 0.0.0.0 0.0.0.0 217.34.42.2 global ip route vrf blue 0.0.0.0 0.0.0.0 217.34.42.2 global

ip vrf green rd 3000:111 route-target both 3000:1 ip vrf blue rd 3000:222 route-target both 3000:2

router bgp 3000 address-family ipv4 vrf green network 0.0.0.0 address-family ipv4 vrf blue network 0.0.0.0


MPLS-VPN Services 7. VRF-Aware NAT Services: Internet Access

  This is also one of the ways to provide Internet access to VPN customers with or without overlapping addresses

PE11 PE-ASBR

MPLS Backbone

PE12

Blue VPN Site 10.1.1.0/24

P

Traffic Flows

10.1.1.0/24

 Internet Green VPN Site

Src=10.1.1.1 Dest=Internet




Label=30 Src=10.1.1.1 Dest=Internet

Label=40 Src=10.1.1.1 Dest=Internet

IP Packet

MPLS Packet

IP Packet

NAT Table VRF IP Source Global IP VRF-Table-Id 10.1.1.1 24.1.1.1 green 10.1.1.1 25.1.1.1 blue

  PE-ASBR removes the label from the received MPLS packets per LFIB

  Performs NAT on the resulting IP packets

  Forwards the packet to the internet

  Returning packets are NATed and put back in the VRF context and then routed

CE1

CE2


35


Agenda













  Best Practices

  Conclusion


MPLS-VPN Services: 8. Providing QoS to VPN Customers

  VPN customers may want SLA so as to treat real-time, mission-critical and best-effort traffic appropriately

  QoS can be applied to VRF interfaces Just like any global interface

Same old QoS mechanisms are applicable

  Remember – IP Precedence bits are copied to MPLS EXP bits (default behavior)

  MPLS Traffic-Eng could be used to provide the bandwidth-on-demand or Fast Rerouting to VPN customers

BRKRST-2104 Deploying MPLS Traffic Engineering

BRKRST-1101 Introduction to MPLS


36


Agenda











10.  Providing MPLS/VPN over IP Transport


  Best Practices

  Conclusion


MPLS-VPN Services: 9. Providing Multicast Service to VPNs

 Multicast VPN service is also available for deployment Current deployment model utilizes GRE encapsulation (not MPLS) within SP network

 Multicast VPN also utilizes the existing 2547 infrastructure

 MPLS multicast i.e., mLDP and P2MP TE, is not far away either

 Please see the following session for details on mVPN: BRKRST-2105 Inter-AS MPLS Solutions

BRKRST-3261 Advances IP Multicast


37


Agenda

  MPLS VPN Explained   MPLS-VPN Services

1.  Providing Load-Shared Traffic to the Multihomed VPN Sites 2.  Providing Hub and Spoke Service to the VPN Customers 3.  Providing MPLS VPN Extranet Service 4.  Providing Internet Access Service to VPN Customers 5.  Providing VRF-Selection Based Services 6.  Providing Remote Access MPLS VPN 7.  Providing VRF-Aware NAT Services 8.  Providing QoS Service to VPNs 9.  Providing Multicast Service to VPNs 10. Providing MPLS/VPN over IP transport 11.  Providing Multi-VRF CE Service

  Best Practices   Conclusion


MPLS-VPN Services: 10. Providing MPLS/VPN over IP Transport

 MPLS/VPN (rfc2547) can also be deployed using IP transport

NO LDP or MPLS anywhere

Useful when the core (P) routers are not capable of MPLS

  In this mode, Instead of using the MPLS Tunnel to reach the next-hop, an IP tunnel is used

IP tunnel could be L2TPv3, GRE etc.

 Basically, the MPLS/VPN packet is encapsulated inside another IP header

MPLS labels are still allocated for the VPN prefix by the PE routers and used only by the PE routers


38



  Ingress PE encapsulates the incoming IP packet (on VRF interface) into an MPLS packet and then encapsulates that MPLS packet inside the IP tunnel such as L2TPv3 tunnel

  Egress PE decapsulates the incoming L2TP packet and recirculates the resulting MPLS packet for usual MPLS packet forwarding

  Core routers forward the packet based on IP header

2547 over L2TPv3

2547 over GRE



 The IP tunnel could be a p2p or multipoint tunnel

IP/MPLS Network

IP Network

IP/MPLS Network

CE

CE

CE

PE

PE

MPLS/MPLS

MPLS/IP


39


Agenda











10.  Providing MPLS/VPN over IP Transport


  Best Practices

  Conclusion


MPLS-VPN Services: 11. Providing Multi-VRF CE Service

  Is it possible for an IP router to keep multiple customer connections separated?

Yes, “multi-VRF CE” aka vrf-lite can be used

  “Multi-VRF CE” provides multiple virtual routing tables (and forwarding tables) per customer at the CE router

Not a feature but an application based on VRF implementation

Any routing protocol that is supported by normal VRF can be used in a Multi-VRF CE implementation

  Note that there is no MPLS functionality needed on the CE, no label exchange between the CE and any router (including PE)

  One of the deployment models is to extend the VRFs to the CE, another is to extend it further inside the Campus => Virtualization

Campus Virtualization blends really well


40


MPLS-VPN Services: 11. Providing Multi-VRF CE Service

Campus

PE Router

MPLS Network

Multi-VRF CE Router

SubInterface Link *

*SubInterface Link – Any Interface type that supports Sub Interfaces, FE-Vlan, Frame Relay, ATM VC’s

PE Router

Campus

One Deployment Model—Extending MPLS/VPN to CE

Vrf green

Vrf red

Vrf red

Vrf green

ip vrf green rd 3000:111 route-target both 3000:1 ip vrf blue rd 3000:222 route-target both 3000:2 ip vrf red rd 3000:333 route-target both 3000:3

ip vrf green rd 3000:111 ip vrf blue rd 3000:222 Ip vrf red rd 3000:333

Vrf green

Vrf red


Agenda



 Best Practices

 Conclusion


41


Best Practices

1.  Use RR to scale BGP; deploy RRs in pair for the redundancy Keep RRs out of the forwarding paths and disable CEF (saves memory)

2.  RT and RD should have ASN in them i.e. ASN: X Reserve first few 100s of X for the internal purposes such as filtering

3.  Consider unique RD per VRF per PE, if load sharing of VPN traffic is required

4.  Don't use customer names as the VRF names; nightmare for the NOC. Use simple combination of numbers and characters in the VRF name

For example: v101, v102, v201, v202, etc. Use description.

5.  PE-CE IP address should come out of SP’s public address space to avoid overlapping

Use /31 subnetting on PE-CE interfaces

6.  Define an upper limit at the PE on the number of prefixes received from the CE for each VRF or neighbor

Max-prefix within the VRF configuration; Do suppress the inactive routes. Max-prefix per neighbor within the BGP VRF af (if BGP on the PE-CE)


Agenda



 Best Practices

 Conclusion


42


Conclusion

 MPLS VPN is a cheaper alternative to traditional l2vpn Secured VPN

 MPLS-VPN paves the way for new revenue streams VPN customers could outsource their layer3 to the provider

 Straightforward to configure any-to-any VPN topology Partial-mesh, Hub and Spoke topologies can also be easily deployed

 CsC and Inter-AS could be used to expand into new markets

 VRF-aware services could be deployed to maximize the investment


Q and A


43


Recommended Reading

  Continue your Networkers at Cisco Live learning experience with further reading from Cisco Press®

  Check the Recommended Reading flyer for suggested books

Available Onsite at the Cisco Company Store


Complete Your Online Session Evaluation

 Win fabulous prizes; give us your feedback

 Receive ten Passport Points for each session evaluation you complete

 Go to the Internet stations located throughout the Convention Center to complete your session evaluation

 Winners will be announced daily at the Internet stations


44



Additional Slides

Advanced MPLS VPN Topics

Inter-AS and CsC


45


Agenda

Advanced MPLS VPN Topics   Inter-AS MPLS-VPN

  CsC Carrier Supporting Carrier


What Is Inter-AS?

VPN-A VPN-A

PE-1

PE2

CE2 CE-1

AS #1 AS #2

149.27.2.0/24

MP-iBGP Update:

BGP, OSPF, RIPv2 149.27.2.0/24, NH=CE-1

Problem:

How do Provider X and Provider Y exchange VPN

routes?

??? ASBR1 ASBR2

RR2 RR1

Provider X Provider Y


46


4. Non-VPN Transit Provider

1. Back-to-Back VRFs

(option A)

2. MP-eBGP for VPNv4

(option B)

3. Multihop MP-eBGP Between RRs

(Option C)

Inter-AS Deployment Scenarios

PE1

PE2

CE2

Following Options/Scenarios for Deploying Inter-AS:

AS #1 AS #2

ASBR1 ASBR2

CE1

Each Option Is Covered in Additional Slides

VPN-A VPN-A


Scenario 1: Back-to-Back VRF Control Plane

PE-1 PE-2

VPN-B

CE-2 CE-3

VPN-B

VRF to VRF Connectivity between ASBRs

ASBR-1 ASBR-2

10.1.1.0/24

BGP, OSPF, RIPv2 10.1.1.0/24,NH=CE-2

VPN-v4 update:RD:1:27:10.1.1.0/24 NH=PE-1 RT=1:1, Label=(29)

VPN-B VRFImport routes with

route-target 1:1

BGP, OSPF, RIPv2 10.1.1.0/24 NH=ASBR-2

VPN-v4 update:RD:1:27:10.1.1.0/24, NH=ASBR-2 RT=1:1, Label=(92)

VPN-B VRFImport routes with

route-target 1:1

BGP, OSPF, RIPv2 10.1.1.0/24,NH=PE-2


47


  Not scalable. # of interface on both ASBRs is directly proportional to #VRF

  No end-to-end MPLS   Unnecessary memory consumed in RIB/(L)FIB   Dual-homing of ASBR makes

provisioning worse

Scenario 1: Back-to-Back VRF Forwarding Plane

PE-1 PE-2

VPN-B

CE-2 CE-3

VPN-B

ASBR-1 ASBR-2

10.1.1.0/24

10.1.1.1

10.1.1.1

10.1.1.1

10.1.1.1 29 30

10.1.1.1 92 20

P2

P1

10.1.1.1 92

IP Packets between ASBRs

  Per-customer QoS is possible   It is simple and elegant since no need to load

the Inter-AS code (but still not widely deployed)

Pros Cons


Cisco IOS Configuration Scenario 1: Back-to-Back VRF Between ASBRs

AS #1 AS #2 VRF routes exchange via

any routing protocol

Note: ASBR must already have MP-iBGP session with iBGP neighbors such as RRs or PEs.

1.1.1.0/30

ip vrf green rd 1:1 route-target both 1:1 ! Router bgp x Address-family ipv4 vrf green neighbor 1.1.1.x activate

ASBR VRF and BGP config

VPN-A

PE1

CE-1

VPN-A

CE-2

PE2

ASBR1 ASBR2


48


Scenario 2: MP-eBGP Between ASBRs to Exchange VPNv4 Routes

 New CLI “no bgp default route-target filter” is needed on the ASBRs

 ASBRs exchange VPN routes using eBGP (VPNv4 af)

 ASBRs store all VPN routes – But only in BGP table and LFIB table

Not in routing nor in CEF table

 ASBRs don’t need - VRFs to be configured on them

LDP between them


Scenario 2: MP-eBGP Between ASBRs for VPN Control Plane

PE-1 PE-2

VPN-B

CE-2 CE-3

VPN-B

ASBR-1 ASBR-2

10.1.1.0/24

BGP, OSPF, RIPv2 10.1.1.0/24, NH=CE-2

MP-iBGP update:RD:1:27:10.1.1.0/24, NH=PE-1 RT=1:1, Label=(40)

MP-iBGP update:RD:1:27:10.1.1.0/24, NH=ASBR-2 RT=1:1, Label=(30)

BGP, OSPF, RIPv2 10.1.1.0/24, NH=PE-2

MP-eBGP update:RD:1:27:10.1.1.0/24, NH=ASBR-1 RT=1:1, Label=(20)


49


Scenario 2: MP-eBGP Between ASBRs for VPN Forwarding Plane

PE-1 PE-2

VPN-B CE-2 CE-3

VPN-B

ASBR-1 ASBR-2

10.1.1.0/24

10.1.1.1

10.1.1.1 30

20 10.1.1.1 10.1.1.1 40

10.1.1.1

10.1.1.1 30 20

10.1.1.1 40 30

P1

P2

MPLS Packets between ASBRs

More scalable   Only one interface between ASBRs routers   No VRF configuration on ASBR   Less memory consumption (no RIB/FIB memory)

MPLS label switching between providers   Still simple, more scalable and works today

Pros Cons Automatic Route Filtering must be disabled   But we can apply BGP filtering

ASBRs are still required to hold VPN routes


Cisco IOS Configuration Scenario 2: External MP-BGP Between ASBRs for VPN

VPN-A

PE1

VPN-A

PE2

CE-2 CE-1

ASBR1 ASBR2

AS #1 AS #2

MP-eBGP for VPNv4

Label exchange between ASBRs using

MP-eBGP

1.1.1.0/30

Note: ASBR must already have MP-iBGP session with iBGP neighbors such as RRs or PEs.

Router bgp x no bgp default route-target filter neighbor 1.1.1.x remote-as x ! address-family vpnv4 neighbor 1.1.1.x activate neighbor 1.1.1.x send-com extended

ASBR MB-EBGP Configuration


50


Scenario 3: Multihop MP-eBGP Between RRs to Exchange VPNv4 Routes

 Exchange VPNv4 prefixes via the Route Reflectors Requires Multihop MP-eBGP (with next-hop-unchanged)

 Exchange IPv4 routes with labels between directly connected ASBRs using eBGP

Only PE loopback addresses need to be exchanged (they are BGP next-hop addresses of the VPN routes)

499-0753


Scenario 3: Multihop MP-eBGP Between RRs for VPN Routes: Control Plane

PE-1 PE-2

VPN-B

CE-2

CE-3 VPN-B

ASBR-1

RR-2

AS#2 ASBR-2

RR-1

IP-v4 update: Network=PE-1 NH=ASBR-1 Label=(20)

BGP, OSPF, RIPv2 10.1.1.0/24,NH=CE-2

10.1.1.0/24

VPN-v4 update:RD:1:27:10.1.1.0/24, NH=PE-1 RT=1:1, Label=(90)



BGP, OSPF, RIPv2 10.1.1.0/24,NH=PE-2

AS#1

IGP+LDP: Network=PE-1 NH=ASBR-2 Label=(30)

IGP+LDP: Network=PE-1 NH=PE-1 Label=(40)

Note - Instead of IGP+Label, iBGP+Label can be used to exchange PE routes/label. Please see Scenario#5 on slide#49 and 50.


51


Scenario 3: Multihop MP-eBGP Between RRs for VPN Routes: Forwarding Plane

PE-1

PE-2

VPN-B

CE-2 CE-3

VPN-B

RR-2

ASBR-2

RR-1

10.1.1.0/24

10.1.1.1

90 10.1.1.1 30

20 90 10.1.1.1

10.1.1.1 90

10.1.1.1

50 90 10.1.1.1

40 90 10.1.1.1

ASBR-1

P1 P2

Note - Instead of IGP+Label, iBGP+Label can be used to exchange PE routes/label.


Scenario 3: Pros/Cons

Pros Cons More scalable than Scenario 1 and 2   Separation of control and forwarding planes

Route Reflector exchange VPNv4 routes+labels   RR hold the VPNv4 information anyway

ASBRs now exchange only IPv4 routes+labels   ASBR Forwards MPLS packets

Advertising PE addresses to another AS may not be acceptable to few providers


52


Cisco IOS Configuration Scenario 3: Multihop MP-eBGP Between RRs for VPN

VPN-A

PE1

VPN-A

PE2

CE-2 CE-1

ASBR-1

RR-2

AS #1 AS #2

Multihop MP-eBGP for VPNv4 with

next-hop-unchange

ASBR-2

RR-1

eBGP IPv4 + Labels

iBGPipv4+label could also be used in within each AS (instead of “network <x.x.x.x>”) to propagate the label information for PEs.

router ospf x redistribute bgp 1 subnets ! router bgp x neighbor < ASBR-x > remote-as x ! address-family ipv4 Network <PEx> mask 255.255.255.255 Network <RRx> mask 255.255.255.255 neighbor < ASBR-x > activate neighbor < ASBR-x > send-label

router bgp x neighbor <RR-x> remote-as x neighbor <RR-x> ebgp-multihop neighbor <RR-x> update loopback 0 ! address-family vpnv4 neighbor <RR-x> activate neighbor <RR-x> send-com extended neighbor <RR-x> next-hop-unchanged

RR Configuration ASBR Configuration


Scenario 4: Non-VPN Transit Provider

 Two MPLS VPN providers may exchange routes via one or more transit providers

Which may be non-VPN transit backbones just running MPLS

 Multihop MP-eBGP deployed between edge providers With the exchange of BGP next-hops via the transit provider


53


Scenario 4: Non-VPN Transit Provider

PE1

PE2 VPN-B

CE-2

CE-3

VPN-B

ASBR-1

RR-2

Non-VPN MPLS Transit Backbone

Multihop MP-eBGP OR MP-iBGP for VPNv4

ASBR-2

RR-1

ASBR-3

ASBR-4 next-hop-unchanged

eBGP IPv4 + Labels

eBGP IPv4 + Labels

MPLS VPN Provider #1

MPLS VPN Provider #2

iBGP IPv4 + Labels

iBGP IPv4 + Labels


Route-Target Rewrite at ASBR

 ASBR can add/delete route-target associated with a VPNv4 prefix

 Secures the VPN environment

ASBR(conf)#router bgp 1000 ASBR(conf-router)#neighbor 1.1.1.1 route-map route-target-deletion out ASBR(conf-router)#exit ASBR(conf)#route-map route-target-delete ASBR(conf-route-map)#match extcommunity 101 ASBR(conf-route-map)#set extcomm-list 101 delete ASBR(conf-route-map)#set extcommunity rt 123:123 additive ASBR(conf)# ip extcommunity-list 101 permit rt 100:100


54


Inter-AS Deployment Guidelines

1. Use ASN in the Route-target i.e. ASN:xxxx

2. Max-prefix limit (both BGP and VRF) on PEs

3. Security (BGP MD5, BGP filtering, BGP max-prefix etc.) on ASBRs

4. End-to-end QoS agreement on ASBRs

5. Route-Target rewrite on ASBR

6.  Internet connectivity on the same ASBR??


Agenda

Advanced MPLS VPN Topics   Inter-AS MPLS-VPN

  Carrier Supporting Carrier (CsC)


55


MPLS/VPN Networks Without CsC

 Number of VPN routes is one of the biggest limiting factors in scaling the PE router

Few SPs are running into this scaling limitation

  If number of VPN routes can be reduced somehow (without loosing the functionality), then the existing investment can be protected

The same PE can still be used to connect more VPN customers

 Carrier Supporting Carrier (CsC) provides the mechanism to reduce the number of routes from each VRF by enabling MPLS on the PE-CE link


CsC Deployment Model

PE1 PE2

ISP PoP Site-1

CE-1 CE-2

IPv4 Routes with Label Distribution

ISP PoP Site-2

MP-iBGP for VPNv4

Carrier’s MPLS Core

P1

ASBR-2

R1 R2

ISP Customers = External Routes

Full-Mesh iBGP for External Routes

IPv4 Routes with Label Distribution

ASBR-1

Internal Routes = IGP Routes

Internal Routes = IGP Routes

IGP+LDP IGP+LDP

INTERNET

C1

MPLS Enabled VRF Int


56


Benefits of CsC

 Provide transport for ISPs ($) No need to manage external routes from ISPs

 Build MPLS Internet Exchange (MPLS-IX) ($$) Media Independence; POS/FDDI/PPP possible

Higher speed such OC192 or more

Operational benefits

 Sell VPN service to subsidiary companies that provide VPN service ($)


What Do I Need to Enable CsC?

1. Build an MPLS-VPN enabled carrier’s network

2. Connect ISP/SPs sites (or PoPs) to the Carrier’s PEs

3. Exchange internal routes + labels between Carrier’s PE and ISP/SP’s CE

4. Exchange external routes directly between ISP/SP’s sites


57


CsC Deployment Models

PE1 PE2

ISP PoP Site-1

CE-1 CE-2

IPv4 routes with label distribution

ISP PoP Site-2

MP-iBGP for VPNv4

Carrier’s MPLS Core

P1

ASBR-2

R1 R2

ISP customers = external routes

Full-mesh iBGP for external routes

IPv4 routes with label distribution

ASBR-1

internal routes = IGP routes

Internal routes = IGP routes

IGP+LDP IGP+LDP

INTERNET

C1

MPLS enabled VRF int


CsC Deployment Models

1. Customer-ISP not running MPLS

2. Customer-ISP running MPLS

3. Customer-ISP running MPLS-VPN

• Model 1 and 2 are less common deployments. • Model 3 will be discussed in detail.


58


PE1 PE2

ISP PoP Site-1

CE-1 CE-2

30.1.61.25/32, NH=CE-1, Label = 50 30.1.61.25/32,

NH=PE-2, Label = 52

ISP PoP Site-2

MP-iBGP update:1:1:30.1.61.25/32, RT=1:1NH =PE-1, Label=51

Carrier’s Core

P1

ASBR_PE-1 30.1.61.25/32

ASBR_PE-2

R1 R2 Network =

10.1.1.0/24

MP-iBGP update:1:1:10.1.1.0/24, RT=1:1 NH =30.1.61.25/32, Label = 90

IGP+LDP, Net=PE-1, Label = pop

IGP+LDP, Net=PE-1, Label = 16

VPN Site-2

10.1.1.0/24, NH=R1 10.1.1.0/24, NH

=ASBR_PE-2

IGP+LDP 30.1.61.25/32,Label = pop

IGP+LDP, 30.1.61.25/32

NH=CE-2, Label=60

IGP+LDP, 30.1.61.25/32 NH=C1,

Label=70

VPN Site-1

C1

CsC: ISP Sites Are Running MPLS-VPN Hierarchical MPLS-VPN Control Plane


PE1 PE2

ISP PoP Site-1

CE-1 CE-2

ISP PoP Site-2

Carrier’s Core

P1

ASBR-1 ASBR-2

R1 R2 Network = 10.1.1.0/24

10.1.1.1 10.1.1.1 10.1.1.1 90 70

10.1.1.1 90 50

10.1.1.1 90 51 16

10.1.1.1 90 52

10.1.1.1 90 60

10.1.1.1 90 51

10.1.1.1 90

VPN Site-1 VPN Site-2

C1

CsC: ISP Sites Are Running MPLS-VPN Hierarchical MPLS-VPN Forwarding Plane

deploying mpls vpns-2up

Documents

mpls brkrst

cisco systems

mpls vpn networks brkrst

cisco confidential brkrst

agenda mpls vpn

mpls solutions brkrst

mpls vpns brkrst

mpls tecagg