DeployingIPMPLSVPN

8/2/2019 DeployingIPMPLSVPN

1/103

2008 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKRST-210214416_04_2008_c1 1

Deploying MPLS

VPN Networks

Ade Yudha GRahman Isnaini

Rommy Kuntoro


2/103

2008 Cisco Systems, Inc. All rights reserved. Cisco Public 2BRKRST-210214416_04_2008_c1

Abstract

Multi Protocol Label Switching (MPLS) has been widelyadopted by the Network Operators to provide scalableL2, L3 VPN, traffic engineering services etc.Enterprises are fast adopting this technology to address

network segmentation and traffic separation needs.This session covers MPLS Layer3 VPN, which isthe most adopted MPLS application. The sessionwill cover:

MPLS VPN Technology Overview (RFC2547/RFC4364)

MPLS/VPN Configuration Overview

MPLS/VPN-based services (multihoming, Hub&Spoke,extranet, Internet, NAT, VRF-lite, etc.)

Best Practices


3/103


Agenda

MPLS VPN Overview

MPLS VPN Services

Best Practices

Conclusion


4/103


Prerequisites

Must understand basic IP routing, especially BGP

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

Should understand MPLS VPN basics Must keep the speaker engaged

by asking bad questions


5/103


Terminology

LSR: label switch router

LSP: label switched pathThe chain of labels that are swapped at each hop to get from one LSR to another

VRF: VPN routing and forwardingMechanism in Cisco IOSused to build per-customer 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 policiesof VPN routes

LFIB: label forwarding information base

FIB: forwarding information base


6/103


Agenda

MPLS VPN Overview

Technology (how it works)

Configuration

MPLS-VPN Services Best Practices

Conclusion


7/103 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 7

BRKRST-210214416_04_2008_c1

MPLS-VPN Technology

More than one routing and forwarding tables

Control planeVPN route propagation

Data or forwarding planeVPN packet forwarding



BRKRST-210214416_04_2008_c1

MPLS-VPN TechnologyMPLS VPN Connection Model

PE

MPLS Backbone

MP-iBGP Session

PE

P P

P P

CE CE

CECE

P Routers

Sit inside the network

Forward packets by looking

at labelsP and PE routers share acommon IGP

PE Routers

Sit at the Edge

Use MPLS with P routers

Uses IP with CE routers

Distributes VPN informationthrough MP-BGP to other PErouters



BRKRST-210214416_04_2008_c1

CE2

MPLS-VPN TechnologySeparate Routing Tables at PE

PE

CE1

VPN 1

VPN 2

MPLS Backbone IGP (OSPF, ISIS)

Customer Specific Routing Table

Routing (RIB) and forwarding table(CEF) dedicated to VPN customer

VPN1 routing table

VPN2 routing table

Referred to as VRF table for the.

show ip route vrf

Global Routing Table

Created when IP routing isenabled on PE.

Populated by OSPF, ISIS, etc.

inside the MPLS backbone

show ip route



BRKRST-210214416_04_2008_c1

MPLS-VPN TechnologyVirtual Routing and Forwarding Instance (1)

Whats a Virtual Routing and Forwarding (VRF) ?

VRF represents the VPN customer inside the SP MPLS network

Each VPN is associated with at least one VRF

VRF must be defined (locally significant) on each PE and associated withone or more PE-CE interfaces;

Privatize an interface, i.e., coloring of the interface

Each VRF has a dedicated routing table and forwarding table,and a dedicated instance of the routing protocol (static, RIP,BGP, EIGRP, ISIS, OSPF)

PE is capable of VRF-aware routing protocol

No changes needed at the CECE router runs whatever software

PE(conf)#interface Ser0/0

PE(conf)#ip vrf forwarding blue

PE(conf)#ip vrf green

CE2

PE

CE1

VPN 1

VPN 2

MPLS Backbone IGP (OSPF, ISIS)

VRF Blue

VRF Green

Ser0/0


11/103 2008 Cisco Systems, Inc. All rights reserved. Cisco Public 11BRKRST-210214416_04_2008_c1

MPLS-VPN TechnologyVirtual Routing and Forwarding Instance (2)

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

More on this in the Control Plane slides later on. PE installs the IGP (backbone) routes in the global routing table

VPN customers can use overlapping IP addresses

BGP plays a key role. Lets understand few BGP specific details..

CE2

PE

CE1

VPN 1

VPN 2

EBGP, OSPF, RIPv2, StaticMPLS Backbone IGP (OSPF, ISIS)



MPLS-VPN Technology: Control Plane

MP-BGP Customizes the VPN customer Routing Information as perthe locally configured VRF information at the PE -

Route Distinguisher (RD)

Route Target (RT)

Label

8 Bytes

Route-Target

3 Bytes

Label

MP-BGP UPDATE message showingonly VPNv4 address, RT, Label

1:1

8 Bytes 4 Bytes

RD IPv4

VPNv4

10.1.1.0

The Control Plane for MPLS VPN Is Multi-Protocol BGP



MPLS-VPN Technology: Control PlaneMP-BGP UPDATE Message Capture

This capture mighthelp to visualize howthe BGP UPDATEmessage advertising

VPNv4 routes looklike.

Notice the PathAttributes.

MP_REACH_NLRI1:1:200.1.62.4/30

Route Target 3:3



MPLS VPN Control PlaneMP-BGP Update Components: RD & VPNv4 Address

VPN customer IPv4 address is converted into a VPNv4address by appending RD to the IPv4 address i.e. 1:1:10.1.1.0

Makes the customers IPv4 route unique inside the SP MPLS network.

Each VRF should* be configured with an RD at the PE

RD is what that defines the VRF

8 Bytes

Route-Target

3 Bytes

Label

MP-BGP update showing RD, RT, and label

1:1

8 Bytes 4 Bytes

RD IPv4

VPNv4

10.1.1.0

!

ip vrf green

rd 1:1

!

* After 12.4(3)T, 12.4(3) 12.2(32)S, 12.0(32)S etc., RD Configuration withinVRF Has Become Optional. Prior to that, It Was Mandatory.



MPLS VPN Control PlaneMP-BGP Update Components: Route-Target

Route-target (RT): identifies the VRF for the received

VPNv4 prefix. It is an 8-byte extended community attribute. Each VRF is configured with a set of RT(s) at the PE

RT helps to identify which VRF(s) get the VPN route !ip vrf green

route-target import 1:1

route-target export 1:2

!

8 Bytes

Route-Target

3 Bytes

Label

MP-BGP update showing RD, RT, and Label

1:1

8 Bytes 4 Bytes

RD IPv4

VPNv4

10.1.1.0 2:2



MPLS VPN Control PlaneMP-BGP Update Components: Label

PE assigns a label for the VPNv4 prefix; Label is not an attribute.

Next-hop-self towards MP-iBGP neighbors by default i.e. PE sets the NEXT-

HOP attribute to its own address (loopback)

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

Do not summarize the PE loopback addresses in the core

3 Bytes

Label

MP-BGP update showing 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 and constructs the MP-iBGP UPDATE message

Associates the RT values (import RT value=1:2) per VRF configuration

Rewrites next-hop attribute to itself

Assigns a label (100, say); Installs it in the MPLS forwarding table.

3. 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.0Next-Hop=PE-1RT=1:2, Label=100

1

3

10.1.1.0/24

PE1 PE2

P

P P

PCE2

MPLS Backbone

Site 1 Site 2

CE1

2



MPLS VPN Control Plane:Putting It All Together

4. PE2 receives and checks whether the RT=1:2 is locally configured asimport RT within any VRF, if yes, then

PE2 translates VPNv4 prefix back in IPv4 prefixUpdates the VRF CEF Table for 10.1.1.0/24 with label=100

5. PE2 advertises this IPv4 prefix to CE2 (using whatever routing protocol)

5

10.1.1.0/24

Next-Hop=CE-1

MP-iBGP Update:

RD:10.1.1.0Next-Hop=PE-1RT=1:2, Label=100

10.1.1.0/24

Site 1 Site 210.1.1.0/24

Next-Hop=PE-2

1

3

PE2

PP

P P

MPLS Backbone

CE1

2 4CE2

PE1



MPLS-VPN Forwarding PlaneReview

Global Forwarding Table

(show ip cef) Stores Next-hop routes with associatedlabels

Next-hop routes learned through IGP

Label learned through LDP/TDP

VRF Forwarding Table(show ip cef vrf ) Stores VPN routes with associated labels

VPN routes learned through BGP

Labels learned through MP-BGP

10.1.1.0/24

Site 1 Site 2

VRF Green Forwarding TableDest NextHop10.1.1.0/24-PE1, label: 100

PE1 PE2P4

P1 P2

P3

CE2CE1

Global Routing/Forwarding TableDest Next-HopPE2 P3, Label: 50

Global Routing/Forwarding TableDest Next-HopPE1 P2, Label: 25



BRKRST-210214416_04_2008_c1

10.1.1.0/24

PE1 PE2

CE2CE1

Site 1 Site 2

10.1.1.1

10.1.1.110050

MPLS-VPN Forwarding PlanePacket Forwarding

PE2 imposes two labels (MPLS headers) for each packet going to

the VPN destination 10.1.1.1.Outer label is LDP learned; Corresponds derived from an IGP route

Inner label is learned via MP-BGP; corresponds to the VPN address

PE1 recovers the IP packet (from the received MPLS packet) andforwards it to CE1.

10.1.1.1

10.1.1.1100

10.1.1.1 10025

IP Packet

MPLS Packet

IP Packet

P4

P1 P2

P3



BRKRST-210214416_04_2008_c1

MPLS-VPN Technology: Control PlaneMPLS Packet Capture

This capturemight be helpfulif you nevercaptured an

MPLS packetbefore.

Inner Label

Outer Label

IP packet

Ethernet Header



BRKRST-210214416_04_2008_c1

Agenda

MPLS VPN Explained

Technology

Configuration

MPLS-VPN Services Best Practices

Conclusion



BRKRST-210214416_04_2008_c1

MPLS VPN Sample Configuration (IOS)

PE-P Configuration

ip vrf VPN-Ard 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

PE110.1.1.0/24

PE1

CE1Site 1

192.168.10.1

Se0

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

PE1Se0

P

PE1s1



BRKRST-210214416_04_2008_c1


PE: MP-IBGP Config

RR: MP-IBGP Config

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



!address-family vpnv4

neighbor 1.2.3.6 route-reflector- client


!

RR

PE1 PE2

RR

PE1 PE2

RR


25/103


26/103



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 Routing: RIP

PE-CE Routing: EIGRP router eigrp 1!


no auto-summary

network 192.168.10.0 0.0.0.255autonomous-system 1

redistribute bgp 1 metric 100000 100

255 1 1500

!

10.1.1.0/24

PE1

CE1Site 1

192.168.10.1

192.168.10.2

10.1.1.0/24

PE1

Site 1

192.168.10.1

192.168.10.2

CE1


27/103



ip route vrf VPN-A 10.1.1.0 255.255.255.0

192.168.10.2

PE-CE Routing: Static

PE-CE MB-iBGP Routes to VPNrouter rip


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 SitesVPN Routes from MP-IBGP Is Required (Shown Below for RIP)

10.1.1.0/24

PE1

CE1Site 1

192.168.10.1

192.168.10.2

PE1

RR

CE1

Site 1


28/103



For config hands-on, please attend Configuring MPLSVPNs (LABCRT-2208) session

Having familiarized with IOS based config, lets glancethrough the IOX-based config for VPNs

router bgp 1


neighbor 1.2.3.4 update-source loopback 0


redistribute {rip|connected|static|eigrp|ospf}

PE-RR (VPN Routes to VPNv4)

If PE-CE Protocol Is non-BGP, then Redistribution of LocalVPN Routes into MP-IBGP Is Required (Shown Below)

PE1

RR

CE1

Site 1


29/103


MPLS VPN Sample Configuration (IOX)

vrf VPN-Arouter-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

router bgp 1

vrf VPN-A

rd 1:1


redistribute connected

!neighbor 192.168.10.2remote-as 2


route-policy raj-temp in

!

!

!

!

PE-CE Routing: BGP

PE1

10.1.1.0/24

PE1

CE1Site 1

192.168.10.1Se0

10.1.1.0/24

PE1

Site 1

192.168.10.1

192.168.10.2

CE1


30/103


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


31/103


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


32/103


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

PE2

MPLS Backbone

CE2

Traffic Flow

1 CE

2 PEs

CE1

Site A

171.68.2.0/24

PE11

RR

PE12

Site B

Site A

171.68.2.0/24

2 CEs 2 PEsPE11

PE2

MPLS Backbone

PE12

Site B

CE2

RR

Traffic Flow

CE2

CE1


33/103


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

Assuming RR exists

Enable BGP multipath within the relevant BGP VRF address-familyat remote/receiving PE2 (why PE2?)

PE11

PE2

MPLS Backbone

PE12

CE1

Site A

171.68.2.0/24

Site B

CE2

RR

ip vrf greenrd 300:11route-target both 1:1

1


1

router bgp 1address-family ipv4 vrf greenmaximum-paths eibgp 2

2


1


34/103


MPLS VPN Services:1. VPN Fast ConvergencePE-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 fromthe 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

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

PE11

PE2

MPLS Backbone

PE12

171.68.2.0/24

RR VPN Traffic

Redirected VPN Traffic

Traffic IsDropped

by PE11

CE1 CE2

Site A Site B


35/103


MPLS VPN Services:1. VPN Fast ConvergencePE-CE Link Failure

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

PE11 immediately 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 learnedvia 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

PE2

MPLS Backbone

PE12

171.68.2.0/24

Traffic IsRedirected

by PE11

VPN Traffic

Redirected VPN Traffic

Site A Site B

CE2CE1

PE11

RR


36/103


Agenda












Best Practices

Conclusion


37/103


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

Traditionally, VPN deployments were hub and spoke,and need to continue for valid reasons

Spoke to spoke communication is via Hub site only

Despite MPLS VPNs implicit any-to-any, i.e.,full-mesh connectivity, hub and spoke servicecan easily be offered

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

Requires unique RD per VRF per PE

PE routers can run any routing protocol with VPNcustomer hub and spoke sites independently


38/103


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

PE-SA

PE-Hub

MPLS VPN Backbone

PE-SB

CE-SA

CE-SBSpoke 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 Ard 300:111route-target export 1:1route-target import 2:2

ip vrf green-spoke2description VRF for SPOKEBrd 300:112route-target export 1:1route-target import 2:2

ip vrf HUB-INdescription VRF for traffic to HUBrd 300:12route-target export 2:2

ip vrf HUB-OUTdescription VRF for traffic from HUBrd 300:11route-target import 1:1

Note: Only VRF Configuration Is Shown Here


39/103



If BGP is used between every PE and CE, thenas-override and allowas-in knobs must be used atthe PE_Hub*

Otherwise AS_PATH looping will occur

If the spoke sites only need the default route from thehub site, then it is possible to use asingle interfacebetween PE-hub and CE-hub (instead of two interfacesas 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


40/103


router bgp address-family ipv4 vrf HUB-INneighbor allowas-in 2


PE-SA

PE-Hub

MPLS VPN BackbonePE-SB

CE-SA

CE-SBSpoke 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 Ard 300:111route-target export 1:1route-target import 2:2

ip vrf green-spoke2description VRF for SPOKEBrd 300:112route-target export 1:1route-target import 2:2

ip vrf HUB-INdescription VRF for traffic to HUBrd 300:12route-target export 2:2

router bgp

address-family ipv4 vrf HUB-OUTneighbor as-override

ip vrf HUB-OUTdescription VRF for traffic from HUBrd 300:11route-target import 1:1


41/103


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

Two VRFs at the PE-hub:VRF HUB_OUT to learn every spoke routes from remote PEs

VRF HUB_IN to advertise either summary 171.68.0.0/16 or specific routes toremote 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 FIB and LFIBDestination NextHop Label171.68.1.0/24 PE-SA 40171.68.2.0/24 PE-SB 50

171.68.1.0/24

VRF FIB and LFIB at PE-SA171.68.0.0/16 PE-Hub 35171.68.1.0/24 CE-SA

VRF FIB and LFIB at PE-SB171.68.0.0/16 PE-Hub 35171.68.2.0/24 CE-SB

171.68.2.0/24

VRF HUB-IN FIBDestination NextHop171.68.0.0/16 CE-H1

MP-iBGP update171.68.0.0/16Label 35Route-Target 2:2

FIBIP Forwarding Table

LFIBMPLS Forwarding Table

MP-iBGP update171.68.2.0/24Label 50Route-Target 1:1

MP-iBGP update171.68.1.0/24

Label 40Route-Target 1:1

PE-Hub


42/103


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

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

171.68.1.1


43/103


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 thesame PE router within the single VRF, then suchspokes 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) routerUpstream VRF for spoke->hub communication

Downstream VRF for spoke


44/103


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 theupstream VRF i.e. red-vrf routing table

ip vrf HUB-INdescription VRF for traffic to HUB

rd 300:12route-target export 2:2

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

Upstream VRF Downstream VRF

ip vrf red-vrfdescription VRF upstream flowrd 300:111route-target import 2:2

ip vrf blue-vrfdescription VRF downstream flowrd 300:112route-target export 1:1 ip vrf HUB-OUT

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


45/103


Agenda












Best Practices

Conclusion


46/103


MPLS-VPN Services3. Extranet VPN

MPLS VPN, by default, isolates one VPN customerfrom another

Separate virtual routing table for each VPN customer

Communication between VPNs may be requiredi.e., extranet

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

Management VPN, shared-service VPN, etc.

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

Export-map or import-map should be used

S S


47/103


VPN_B Site#1

180.1.0.0/16

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

171.68.0.0/16 PE1 PE2

MPLS Backbone VPN_A Site#2

SOP

VPN_A Site#1

ip vrf VPN_Ard 3000:111export map VPN_A_Exportimport map VPN_A_Importroute-target import 3000:111route-target export 3000:111route-target import 3000:1!route-map VPN_A_Export permit 10match ip address 1

set extcommunity rt 3000:2 additive!route-map VPN_A_Import permit 10match ip address 2

!access-list 1 permit 171.68.0.0 0.0.0.0access-list 2 permit 180.1.0.0 0.0.0.0

ip vrf VPN_Brd 3000:222export map VPN_B_Exportimport map VPN_B_Importroute-target import 3000:222route-target export 3000:222route-target import 3000:2!route-map VPN_B_Export permit 10match ip address 2

set extcommunity rt 3000:1 additive!route-map VPN_B_Import permit 10match ip address 1!access-list 1 permit 171.68.0.0 0.0.0.0access-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 Wont Be Part of It


48/103


Agenda












Best Practices

Conclusion

MPLS VPN S i


49/103


MPLS-VPN Services4. Internet Access Service to VPN Customers

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

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

To protect from the Internet vulnerabilities

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

MPLS VPN S i


50/103


MPLS-VPN Services4. 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 S i


51/103


MPLS-VPN Services4. Internet Access: Different Methods of Service

1. VRF specific default route1.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 (globalrouting table) to VRF

2. Separate PE-CE subinterface (non-VRF)May run BGP to propagate Internet routes between PE and CE


VPN packets never leave VRF context; issue with overlapping VPN address

4. Extranet with Internet-VRF along with VRF-aware NATVPN packets never leave VRF context; works well with overlappingVPN address

MPLS VPN Services:


52/103


192.168.1.2

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

A default route, pointing to theASBR, is installed into the siteVRF at each PE

The static route, pointing to theVRF interface, is installed in theglobal routing table andredistributed into BGP

PE1

ASBR

CE1 MPLS Backbone

192.168.1.1

Internet GW

SO

PPE1#

ip vrf VPN-A

rd 100:1route-target both 100:1

Interface Serial0

ip address 192.168.10.1 255.255.255.0


Router bgp 100

no bgp default ipv4-unicast

redistribute staticneighbor 192.168.1.1 remote 100


neighbor 192.168.1.1 next-hop-self


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

Site1Internet171.68.0.0/16

MPLS VPN S i I t t A


53/103


Disadvantages Using default route

for Internet

Routing does not allow anyother default route for intra-VPN routing Increasing sizeof global routing table byleaking VPN routes

Static configuration(possibility of trafficblackholing)

MPLS-VPN Services: Internet Access4.1 VRF Specific Default Route (Forwarding)

171.68.0.0/16

PE1 PE2Se0

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 PacketD=Cisco.com

Label = 30


Label = 35

IP Packet

D=171.68.1.1

Internet

Global Table and LFIB

Destination Label/Interface192.168.1.2/32 Label=35

171.68.0.0/16 192.168.1.2

Internet Serial 0

192.168.1.2

IP PacketD=171.68.1.1

Advantages

Different Internet gateways Can be used for

different VRFs

PE routers need not tohold the Internet table

Simple configuration

Site1

SO

MPLS Backbone


IP PacketD=171.68.1.1192.168.1.1

MPLS VPN S i


54/103


MPLS-VPN Services4.2 Internet Access

1. VRF specific default route1.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 (globalrouting table) to VRF

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


VPN packets never leave VRF context; overlapping VPN addresses could bea problem

4. Extranet with Internet-VRF along with VRF-aware NAT

VPN packets never leave VRF context; works well with overlappingVPN addresses

4 2 Internet Access Service to VPN


55/103


One sub-interface for VPN routingassociated to a VRF

Another subinterface for Internetrouting associated to the globalrouting table

Could advertise full Internet routes ora default route to CE

The PE will need to advertise VPNroutes to the Internet (via global

routing table)

4.2 Internet Access Service to VPNCustomers Using Separate Subinterface (Config)

ip vrf VPN-A

rd 100:1route-target both 100:1

Interface Serial0.1


ip address 192.168.20.1 255.255.255.0

frame-relay interface-dlci 100

!

Interface Serial0.2ip address 171.68.10.1 255.255.255.0

frame-relay interface-dlci 200

!

Router bgp 100

no bgp default ipv4-unicast


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

InternetInternet

I t t A S i t VPN C t


56/103


CE Routing TableVPN Routes Serial0.1Internet Routes Serial0.2

PE Global Table and FIBInternet Routes 192.168.1.1192.168.1.1 Label=30

Pros

CE Could Dual Home and

Perform Optimal Routing

Traffic Separation Doneby CE

Cons

PE to Hold Full Internet

Routes

BGP Complexities Introducedin CE; CE1 May Need toAggregate to Avoid AS_PATHLooping

171.68.0.0/16

PE1

PE2

MPLS Backbone

PE-Internet GW

192.168.1.1

S0.2

P

Site1

S0.1

InternetInternetIP PacketD=Cisco.com

192.168.1.2


Internet Access Service to VPN Customer4.2 Using Separate Subinterface (Forwarding)

Label = 30


Internet Access Service


57/103


Internet Access Service4.3 Extranet with Internet-VRF

The Internet routes could be placed within the VRFat the Internet-GW i.e., ASBR

VRFs for customers could extranet with the InternetVRF 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 onlyif the VPN customers dont haveoverlapping addresses

Internet Access Service


58/103


Internet Access Service4.4 Internet Access Using VRF-Aware NAT

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

The Internet GW doesnt need to have Internet

routes either

Overlapping VPN addresses is no longer a problem

More in the VRF-aware NAT slides


59/103


Agenda












Best Practices

Conclusion

MPLS VPN Services


60/103


MPLS-VPN Services7. VRF-Aware NAT Services

VPN customers could be using overlapping IP addressi.e.,10.0.0.0/8

Such VPN customers must NAT their traffic beforeusing either Extranet or Internet or any shared*

services

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

* VoIP, Hosted Content, Management, etc.

MPLS VPN Services


61/103


MPLS-VPN Services7. VRF-Aware NAT Services

Typically, inside interface(s) connect to private addressspace and outside interface(s) connect to globaladdress space

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

interfacesNAT occurs before routing for traffic from outside-to-insideinterfaces

Each NAT entry is associated with the VRF

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

MPLS VPN Services:


62/103


Internet217.34.42.2.1

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

PE-ASBRMPLS Backbone

CE1

Blue VPN Site

10.1.1.0/24

CE2

10.1.1.0/24

Green VPN Site

IP NAT Inside

IP NAT Outside

VRF-Aware NAT Specific ConfigVRF 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-natpool pool-greenvrf greenip nat inside source list vpn-to-natpool pool-bluevrf blue

ip access-list standard vpn-to-natpermit 10.1.1.0 0.0.0.255

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

ip vrf greenrd 3000:111route-target both 3000:1ip vrf bluerd 3000:222route-target both 3000:2

router bgp 3000address-family ipv4 vrf greennetwork 0.0.0.0address-family ipv4 vrf bluenetwork 0.0.0.0

PPE11

PE12

MPLS VPN Services:


63/103


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

MPLS Backbone

P

Traffic Flows

Internet

Src=10.1.1.1Dest=Internet



Label=30


IP Packet

MPLS Packet

NAT TableVRF IP Source Global IP VRF-Table-Id10.1.1.1 24.1.1.1 green10.1.1.1 25.1.1.1 blue

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

Performs NAT on the resultingIP packets

Forwards the packet to the internet Returning packets are NATed and

put back in the VRF context andthen routed

This is also one of the ways to provideInternet access to VPN customers

with or without overlapping addresses

PE11

PE12

PE-ASBR

CE1

Green VPN Site

10.1.1.0/24

CE2

Blue VPN Site

10.1.1.0/24


IP PacketLabel=40Src=10.1.1.1Dest=Internet


64/103


Agenda












Best Practices

Conclusion

MPLS VPN Services:


65/103


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

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

Yes, multi-VRF CE a.k.a. 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 ina 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

MPLS-VPN Services:


66/103


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

Campus

PERouter

MPLSNetwork

Multi-VRFCE Router

SubInterfaceLink *

PERouter

Campus

One Deployment ModelExtending MPLS/VPN to CE

Vrf Green

Vrf Red

Vrf

Green

ip vrf greenrd 3000:111

route-target both 3000:1

ip vrf blue

rd 3000:222


ip vrf red

rd 3000:333


Vrf Green

Vrf Red

*SubInterface LinkAny Interface Type that Supports Sub Interfaces, FE-Vlan,

Frame Relay, ATM VCs

VrfRed

ip vrf green

rd 3000:111

ip vrf blue

rd 3000:222

Ip vrf red

rd 3000:333


67/103


Agenda

MPLS VPN Explained

MPLS-VPN Services

Best Practices

Conclusion


68/103


Best Practices

1. Use RR to scale BGP; deploy RRs in pair for the redundancyKeep 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 trafficis required

4. Dont 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 SPs public address space toavoid overlapping

Use /31 subnetting on PE-CE interfaces

6. Define an upper limit at the PE on the number of prefixes received fromthe 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)


69/103


Agenda

MPLS VPN Explained

MPLS-VPN Services

Best Practices

Conclusion


70/103


Conclusion

MPLS VPN is becoming acheaper and fasteralternativeto 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 beeasily deployed

CsC and Inter-AS could be used to expand intonew markets

VRF-aware services could be deployed to maximizethe investment


71/103


Q and A


72/103


Recommended Reading

Continue your Cisco Livelearning experience with furtherreading from Cisco Press

Check the Recommended

Reading flyer for suggestedbooks

Available Onsite at the Cisco Company Store

Complete Your Online


73/103


pSession Evaluation

Give us your feedback and you could winfabulous prizes. Winners announced daily.

Receive 20 Passport points for each sessionevaluation you complete.

Complete your session evaluation online now(open a browser through our wireless networkto access our portal) or visit one of the Internetstations throughout the Convention Center.

Dont forget to activateyour Cisco Live virtualaccount for access toall session materialon-demand and returnfor our live virtual eventin October 2008.

Go to the CollaborationZone in World ofSolutions or visitwww.cisco-live.com.

2008 Cisco Systems, Inc. All rights reserved. Cisco PublicBRKRST-210214416_04_2008_c1 88


74/103



75/103


Additional Slides

Advanced MPLS VPN Topics

Inter-AS and CsC


76/103


Agenda

Advanced MPLS VPN TopicsInter-AS MPLS-VPN

CsC Carrier Supporting Carrier


77/103


What Is Inter-AS?

VPN-A VPN-A

PE-1

PE2

CE2CE-1

AS #1 AS #2

149.27.2.0/24

MP-iBGP Update:

BGP, OSPF, RIPv2149.27.2.0/24, NH=CE-1

Problem:

How Do ProviderX and Provider Y

Exchange VPNRoutes?

???ASBR1 ASBR2

RR2RR1

Provider X Provider Y


78/103


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


79/103


Scenario 1: Back to Back VRFControl Plane

PE-1PE-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, RIPv210.1.1.0/24,NH=CE-2

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

VPN-B VRFImport routes withRoute-Target1:1

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

BGP, OSPF, RIPv210.1.1.0/24,NH=PE-2

VPN-B VRFImport Routes with

Route-Target1:1

BGP, OSPF, RIPv210.1.1.0/24

NH=ASBR-2

Scenario 1: Back-to-Back VRF


80/103


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

No end-to-end MPLS

Unnecessary memory consumed inRIB/(L)FIB

Dual-homing of ASBR makesprovisioning worse

Scenario 1: Back to Back VRFForwarding 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.12930

10.1.1.19220

P2

P1

10.1.1.192

IP Packets

Between ASBRs

Per-customer QoS is possible

It is simple and elegant since no needto load the Inter-AS code (but still notwidely deployed)

Pros Cons

Cisco IOS Configuration


81/103


Cisco IOS ConfigurationScenario 1: Back-to-Back VRF Between ASBRs

AS #1 AS #2VRF Routes Exchange via

any Routing Protocol

1.1.1.0/30

ip vrf greenrd 1:1route-target both 1:1!Router bgp xAddress-family ipv4 vrf greenneighbor 1.1.1.x activate

ASBR VRF and BGP config

VPN-A

PE1

CE-1

VPN-A

CE-2

PE2

ASBR1 ASBR2

Note: ASBR Must Already Have MP-iBGP Session with iBGP Neighbors such as RRs or PEs

Scenario 2: MP-eBGP Between ASBRs


82/103


to Exchange VPNv4 Routes

New CLI no bgp default route-target filter is neededon 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 dont need

VRFs to be configured on them

LDP between them

Scenario 2: MP-eBGP bet ASBRs


83/103


PE-1 PE-2

VPN-B

CE-2 CE-3

VPN-B

ASBR-1 ASBR-2

10.1.1.0/24

BGP, OSPF, RIPv210.1.1.0/24, NH=CE-2

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

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

RD:1:27:10.1.1.0/24,NH=ASBR-1

RT=1:1, Label=(20)

BGP, OSPF, RIPv210.1.1.0/24, NH=PE-2

for VPN Control Plane

Scenario 2: MP-eBGP bet ASBRs


84/103


for VPN Forwarding Plane

PE-1

VPN-B

CE-2 CE-3

VPN-B

ASBR-1 ASBR-2

10.1.1.0/24

10.1.1.1

10.1.1.13020

10.1.1.130P2

20 10.1.1.1

MPLS PacketsBetween ASBRs

10.1.1.14030

10.1.1.140

10.1.1.1

Pros Cons

More scalableOnly one interface betweenASBRs routers

No VRF configuration on ASBR.

Less memory consumption (no RIB/FIB memory)

MPLS label switching between providersStill simple, more scalable & works today

Automatic route filtering mustbe disabled

But we can apply BGP filtering

ASBRs are still required to holdVPN routes



85/103


gScenario 2: External MP-BGP between ASBRs for VPN

AS #1 AS #2

1.1.1.0/30

VPN-A

PE1

CE-1

VPN-A

CE-2

PE2

ASBR1 ASBR2MP-eBGP for

VPNv4

Label ExchangeBetween ASBRsUsing MP-eBGP

Router bgp xno bgp default route-target filter

neighbor 1.1.1.x remote-as x!

address-family vpnv4

neighbor 1.1.1.x activateneighbor 1.1.1.x send-com extended

ASBR MB-EBGP Configuration

Note: ASBR Must Already Have MP-iBGP Session with iBGP Neighbors such as RRs or PEs

Scenario 3: Multihop MP-eBGP BetweenRR E h VPN 4 R


86/103


RRs to Exchange VPNv4 Routes

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

Exchange IPv4 routes with labels between directlyconnected ASBRs using eBGP

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

Scenario 3: Multihop MP-eBGP BetweenRR f VPN R C l Pl


87/103


RRs for VPN Routes: Control Plane

PE-1 PE-2

VPN-B

CE-2

CE-3

VPN-B

ASBR-1

RR-2

AS#2ASBR-2

RR-1

IP-v4 Update:Network=PE-1NH=ASBR-1Label=(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-1RT=1:1, Label=(90)



BGP, OSPF, RIPv210.1.1.0/24,NH=PE-2

AS#1

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

Note: Instead of IGP+Label, iBGP+Label Can Be Used to Exchange PE Routes/Label.Please see Scenario#5 on slide#49 and 50.

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

Scenario 3: Multihop MP-eBGP BetweenRR f VPN R t F di Pl


88/103


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

20 90 10.1.1.1

10.1.1.190

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.

90 10.1.1.130

S i 3 P /C


89/103


Scenario 3: Pros/Cons

More scalable than Scenario 1and 2Separation of control andforwarding planes

Route Reflector exchangeVPNv4 routes+labels

RR hold the VPNv4information anyway

ASBRs now exchange onlyIPv4 routes+labels

ASBR forwards MPLS packets

Advertising PE addressesto another AS may not beacceptable to few providers

Pros Cons



90/103


gScenario 3:Multihop MP-eBGP between RRs for VPN

VPN-A

PE1

VPN-A

PE2

CE-2CE-1

ASBR-1

RR-2

AS #1 AS #2

Multihop MP-eBGPfor VPNv4 with

next-hop-unchange

ASBR-2

RR-1

eBGP IPv4 + Labels

iBGPipv4+label Could Also Be Used in Within Each AS (Instead ofnetwork ) to Propagate the Label Information for PEs

router ospf xredistribute bgp 1 subnets!router bgp xneighbor < ASBR-x > remote-as x!address-family ipv4

Network mask 255.255.255.255Network mask 255.255.255.255neighbor < ASBR-x > activateneighbor < ASBR-x > send-label

router bgp xneighbor remote-as xneighbor ebgp-multihopneighbor update loopback 0!address-family vpnv4

neighbor activateneighbor send-com extendedneighbor next-hop-unchanged

RR Configuration ASBR Configuration

S i 4 N VPN T it P id


91/103


Scenario 4: Non-VPN Transit Provider

Two MPLS VPN providers may exchange routes viaone 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

S i 4 N VPN T it P id


92/103


Scenario 4: Non-VPN Transit Provider

PE1

PE2VPN-B

CE-2

VPN-B

ASBR-1

RR-2

Non-VPN MPLSTransit Backbone

Multihop MP-eBGP OR

MP-iBGP for VPNv4

ASBR-2

RR-1

ASBR-3

ASBR-4next-hop-unchanged

eBGP IPv4 + Labels

eBGP IPv4 + Labels

MPLS VPNProvider #1

MPLS VPNProvider #2

iBGP IPv4 + Labels

CE-3

iBGP IPv4 + Labels

R t T t R it t ASBR


93/103


Route-Target Rewrite at ASBR

ASBR can add/delete route-target associated with aVPNv4 prefix

Secures the VPN environment

ASBR(conf)#router bgp 1000

ASBR(conf-router)#neighbor 1.1.1.1 route-map route-target-deletionout

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

Inter AS Deployment Guidelines


94/103


Inter-AS Deployment Guidelines

1. Use ASN in the Route-target i.e., ASN:xxxx2. 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


95/103


Agenda

Advanced MPLS VPN TopicsInter-AS MPLS-VPN

Carrier Supporting Carrier (CsC)

MPLS/VPN Networks Without CsC


96/103


MPLS/VPN Networks Without CsC

Number of VPN routes is one of the biggest limitingfactors 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 existinginvestment 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 eachVRF by enabling MPLS on the PE-CE link

CsC Deployment Model


97/103


CsC Deployment Model

PE1PE2

ISP PoPSite-1

CE-1 CE-2

ISP PoPSite-2

MP-iBGP for VPNv4

Carriers MPLS Core

P1

ASBR-2

R1 R2

ISP Customers =External Routes

Full-Mesh iBGPfor External Routes

ASBR-1

Internal Routes =IGP Routes


IGP+LDPIGP+LDP

Internet

C1

MPLS-Enabled VRF Int

IPv4 Routes withLabel Distribution


Benefits of CsC


98/103


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 ?


99/103


What Do I Need to Enable CsC ?

1. Build an MPLS-VPN enabled carriers network2. Connect ISP/SPs sites (or PoPs) to the Carriers PEs

3. Exchange internal routes + labels between CarriersPE and ISP/SPs CE

4. Exchange external routes directly betweenISP/SPs sites

CsC Deployment Models


100/103


Internet


PE1PE2

ISP PoPSite-1

CE-1CE-2

ISP PoPSite-2

MP-iBGP for VPNv4

Carriers MPLS Core

P1

ASBR-2

R1

R2

ISP Customers =External Routes

Full-Mesh iBGPfor External Routes


ASBR-1

internal Routes= IGP Routes

IGP+LDPIGP+LDP

MPLS-Enabled VRF int

C1





101/103



1. Customer-ISP not running MPLS2. 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.

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


102/103


PE1 PE2

ISP PoPSite-1

CE-1CE-2

ISP PoPSite-2

MP-iBGP Update:1:1:30.1.61.25/32, RT=1:1

NH =PE-1, Label=51

Carriers Core

P1

ASBR_PE-130.1.61.25/32

ASBR_PE-2

R1R2

Network =10.1.1.0/24

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

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/32NH=C1, Label=70

VPN Site-1

C1

Hierarchical MPLS-VPN Control Plane

IGP+LDP30.1.61.25/32,Label = pop

30.1.61.25/32,NH=PE-2, Label = 52

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

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

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

IGP+LDP,30.1.61.25/32

NH=CE-2, Label=60

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


103/103

PE1

PE2

ISP PoPSite-1

CE-1CE-2

ISP PoPSite-2

Carriers Core

P1

ASBR-1 ASBR-2

10.1.1.1905116

C1

Hierarchical MPLS-VPN Forwarding Plane

10.1.1.110.1.1.1 10.1.1.19070

10.1.1.190

10.1.1.19060

10.1.1.19052

10.1.1.19051

10.1.1.19050

Date post:	06-Apr-2018
Category:	Documents
Upload:	minhtuanqni
View:	217 times
Download:	0 times

DeployingIPMPLSVPN

Documents