designing mpls l3vpn networksd2zmdbbm9feqrf.cloudfront.net/2011/eur/pdf/brkipm-2017.pdf ·...

BRKIPM-2017

Rajiv Asati, Distinguished Engineer

Designing MPLS Layer3 VPN Networks

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco PublicBRKIPM-2017 2

Abstract

Multi Protocol Label Switching (MPLS) has been widely adopted by the Network Operators to provide scalable L2, 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 is the most adopted MPLS application. The session will 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


Other MPLS-Related Sessions

Session-ID Session Name

BRKRST-1101 Introduction to MPLS

BRKRST-2103 Migration Considerations when

Buying MPLS VPN Service

BRKRST-2105 Inter-AS MPLS Solutions

BRKRST-3101 Advanced Topics and Future

Directions in MPLS


MPLS VPN Overview

MPLS VPN Services

Best Practices

Conclusion

Agenda


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

Reference


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 IOS® used 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 distinguisherDistinguish same network/mask prefix in different VRFs

RT: route targetExtended community attribute used to control import and export policies of VPN routes

LFIB: label forwarding information base

FIB: forwarding information base

Reference


Agenda

MPLS VPN Overview

Technology (how it works)

Configuration

MPLS-VPN Services

Best Practices

Conclusion


MPLS-VPN Technology

More than one routing and forwarding tables

Control plane—VPN route propagation

Data or forwarding plane—VPN packet forwarding


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 labels

P and PE routers share a common IGP

PE Routers

Sit at the Edge

Use MPLS with P routers

Uses IP with CE routers

Distributes VPN information through MP-BGP to other PE routers


CE2

MPLS-VPN TechnologySeparate Routing Tables at PE

Global Routing Table

Created when IP routing is enabled on PE.

Populated by OSPF, ISIS, etc. inside the MPLS backbone

“show ip route”

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 <named VPN>.

“show ip route vrf <name>”


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

What‘s a Virtual Routing and Forwarding (VRF) ?

Representation of VPN customer inside the SP MPLS network

Each VPN is associated with at least one VRF

VRF configured on each PE and associated with PE-CE interface(s)

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

VRF-aware routing protocol (static, RIP, BGP, EIGRP, ISIS, OSPF)

No changes needed at CE PE(conf)#interface Ser0/0

PE(conf)#ip vrf forwarding blue

PE(conf)#ip vrf blue

CE2

PE

CE1

VPN 1

VPN 2

MPLS Backbone IGP (OSPF, ISIS)

VRF Blue

VRF Green

Ser0/0


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

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

PE installs the VPN routes in VRF routing table(s).

VPN routes are learned from CE routers or remote PE routers

VPN customers can use overlapping IP addresses

BGP plays a key role. Let‘s 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 per the 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 showing

only 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

Visualize how the BGP UPDATE message advertising VPNv4 routes looks like.

Notice the Path Attributes.

VPNv4 prefix with label is encoded in this attribute.

Route Target 3:3

Reference


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

VPN customer IPv4 address (10.1.1.0, say) is converted into a VPNv4 address by appending the RD to the IPv4 address

=>1:1:10.1.1.0

Makes the customer‘s IPv4 address unique inside the SP MPLS network.

Route Distinguisher (RD) is configured inside the VRF at PERD is not a BGP attribute, just a field.

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 within VRF Has Become Optional. Prior to that, It Was Mandatory.


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

Each VRF is configured with a set of RT(s) at the PE

RT identifies which VRF(s) keep which VPN route

Export RT(s) attached to VPN routes in PE->PE advertisements

!

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 1:2


MPLS VPN Control Plane MP-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 in the 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 (export RT =1:2, say) 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.0

Next-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 as ‗import RT‘ within any VRF, if yes, then

PE2 translates VPNv4 prefix back in IPv4 prefix

Updates 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.0

Next-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


Global Forwarding Table(show ip cef)

Stores Next-hop routes with associated labels

Next-hop routes learned through IGP

Label learned through LDP/TDP

VRF Forwarding Table(show ip cef vrf <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 Table

Dest NextHop

10.1.1.0/24-PE1, label: 100

PE1 PE2P4

P1 P2

P3

CE2CE1

Global Routing/Forwarding Table

Dest Next-Hop

PE2 P3, Label: 50

Global Routing/Forwarding Table

Dest Next-Hop

PE1 P2, Label: 25

MPLS-VPN Forwarding PlaneReview


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) and forwards 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


MPLS-VPN Technology: Forwarding PlaneMPLS Packet Capture

This capture might be helpful if you never captured an MPLS packet before.

Inner Label

Outer Label

IP packet

Ethernet Header

Reference


Agenda

MPLS VPN Explained

Technology

Configuration

MPLS-VPN Services

Best Practices

Conclusion


MPLS VPN Sample Configuration (IOS)

PE-P Configuration

ip vrf VPN-A

rd 1: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.1Se0

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

Reference



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



!


neighbor 1.2.3.6 route-reflector- client


!

RR

PE1 PE2

RR

PE1 PE2

RR

Reference



router bgp 1

!

address-family ipv4 vrf VPN-A



exit-address-family

!

PE-CE Routing: BGP

PE-CE Routing: 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

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

Reference



router rip

!


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

autonomous-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

Reference

PE1

PE1



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 (such as RIP), then Redistribution of

VPN 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

Reference

PE1

PE1



For config hands-on, please attend ―Configuring MPLS VPNs‖ Lab session.

Having familiarized with IOS based config, let‘s glance through the IOS-XR 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 Local

VPN Routes into MP-IBGP Is Required (Shown Below)

PE1

RR

CE1

Site 1

Reference

PE1


MPLS VPN Sample Configuration (IOX)

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

router bgp 1

vrf VPN-A

rd 1:1


redistribute connected

!

neighbor 192.168.10.2

remote-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

Reference


Agenda

MPLS VPN Explained

MPLS-VPN Services

1. Load-Sharing for Multihomed VPN Sites

2. Hub and Spoke Service

3. MPLS VPN Extranet Service

4. Internet Access Service

5. VRF-Aware NAT Services

6. VRF-Selection Based Services

7. Remote VPN Access Service

8. QoS Service

9. Multicast VPN Service

10. MPLS/VPN over IP Transport

11. IPv6 VPN Service

12. Multi-VRF CE Service

Best Practices

Conclusion


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

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 PEs

PE11

PE2

MPLS Backbone

PE12

Site B

CE2

RR

Traffic Flow

CE2

CE1


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

Configure unique RD per VRF per PE for multihomed site/interfaces

Assuming RR exists

Enable BGP multipath within the relevant BGP VRF address-family at remote PE routers such as 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

ip vrf green

rd 300:12


1

router bgp 1

address-family ipv4 vrf green

maximum-paths eibgp 2

2

ip vrf green

rd 300:13



!

ip vrf green

rd 300:11

protection local-prefixes

!

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

In a classic multi-homing case, PE11, upon detecting the PE-CE link failure, sends BGP message to withdraw the VPN routes towards other PE routers.

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.

Use fast local repair feature (referred to as BGP local convergence) to 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 Is Dropped by PE11

CE1 CE2

Site A Site B


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

‗BGP Local Convergence‘ feature helps PE11 to minimize the traffic loss from sec to msec, during local PE-CE link failure

PE11 immediately reprograms the forwarding entry with the alternate BGP best path (which is via PE12)

PE11 redirects the CE1 bound traffic to PE12 (with the right label)

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

PE2

MPLS Backbone

PE12

171.68.2.0/24

Traffic Is Redirected by PE11

VPN Traffic

Redirected VPN Traffic

Site A Site B

CE2CE1

PE11

RR


Agenda

MPLS VPN Explained

MPLS-VPN Services








8. QoS Service





Best Practices

Conclusion


MPLS-VPN Services: 2. Hub and Spoke Service

Many VPN deployments need to be hub and spoke

Spoke to spoke communication 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

Requires unique RD per VRF per PE

PE routers can run any routing protocol with VPN customer‘ hub and spoke sites independently


MPLS-VPN Services: 2. Hub and Spoke Service

Two configuration Options :

1. 1 PE-CE interface to Hub & 1 VRF;

2. 2 PE-CE interfaces to Hub & 2 VRFs;

Use option#1 if Hub site advertises default or summary routes towards the Spoke sites, otherwise use Option#2

HDVRF feature* allows the option#2 to use just one PE-CE interface

* HDVRF feature is discussed later


MPLS-VPN Services: 2. Hub and Spoke Service: Configuration – Option#1

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

ip vrf green-spoke1

description VRF for SPOKE A

rd 300:111



ip vrf green-spoke2

description VRF for SPOKE B

rd 300:112



ip vrf HUB

description VRF for HUB

rd 300:11



Note: Only VRF Configuration Is Shown Here

CE-Hub

Import and export RT values must be different



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


rd 300:111



ip vrf green-spoke2


rd 300:112



ip vrf HUB-OUT

description VRF for traffic to HUB

rd 300:12


ip vrf HUB-IN

description VRF for traffic from HUB

rd 300:11


CE-Hub

Import and export RT values must be different

Note: Only VRF Configuration Is Shown Here



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

Otherwise AS_PATH looping will occur

* Only if Hub and Spoke sites use the same BGP ASN

** Configuration for this Is Shown on the Next Slide


router bgp <ASN>

address-family ipv4 vrf HUB-OUT

neighbor <CE> allowas-in 2


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


rd 300:111



ip vrf green-spoke2


rd 300:112



ip vrf HUB-OUT


rd 300:12


router bgp <ASN>

address-family ipv4 vrf HUB-IN

neighbor <CE> as-override

ip vrf HUB-IN


rd 300:11


CE-Hub


MPLS-VPN Services: 2. Hub and Spoke Service: Control Plane (Option#2)

Two VRFs at the PE-Hub:

VRF HUB-IN to learn every spoke routes from remote PEs

VRF HUB-OUT to advertise spoke routes or summary 171.68.0.0/16 routes to remote PEs

PE-SA

MPLS Backbone

PE-SB

CE-SA

CE-SB

Spoke B

Spoke A

VRF HUB-OUT

VRF HUB-IN

VRF HUB-IN FIB 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

171.68.2.0/24

VRF HUB-OUT FIB

Destination NextHop

171.68.0.0/16 CE-H1

MP-iBGP update

171.68.0.0/16

Label 35

Route-Target 2:2

FIB—IP Forwarding TableLFIB—MPLS Forwarding Table

MP-iBGP update

171.68.2.0/24

Label 50

Route-Target 1:1

MP-iBGP update

171.68.1.0/24

Label 40

Route-Target 1:1

PE-Hub

CE-Hub

VRF FIB and LFIB

Destination NextHop Label

171.68.0.0/16 PE-Hub 35

171.68.1.0/24 CE-SA

VRF FIB and LFIB

171.68.0.0/16 PE-Hub 35

171.68.2.0/24 CE-SB


PE-SA

PE-Hub

MPLS Backbone

MPLS-VPN Services: 2. Hub and Spoke Service: Forwarding Plane (option#2)

PE-SB

CE-SA

CE-SB

Spoke B

Spoke A

VRF HUB-OUT

VRF HUB-IN

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

171.68.1.1

171.68.1.1

CE-Hub


MPLS-VPN Services: 2. What if many spoke sites connect to the same PE router?

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

Defeats the purpose of hub and spoke

Half-duplex VRF is the answer

Uses two VRFs on the PE (spoke) router :

A VRF for spoke->hub communication (upstream)

A VRF for spoke<-hub communication (downstream)

Note- 12.2(33)SRE supports any interface type (Eth, Ser etc.)

PE-SA

CE-SA1

CE-SA2

CE-SA3

PE-Hub


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. green-down

PE-SA forwards the incoming IP traffic (from Spokes) using the upstream VRF i.e. green-up routing table.

ip vrf HUB-OUT


rd 300:12


Int virtual-template1

….

ip vrf forward green-up downstream green-down

…

Upstream VRF Downstream VRF

ip vrf green-updescription VRF – upstream flowrd 300:111route-target import 2:2

ip vrf green-downdescription VRF – downstream flowrd 300:112route-target export 1:1 ip vrf HUB-IN


rd 300:11


CE-Hub


Agenda

MPLS VPN Explained

MPLS-VPN Services








8. QoS Service





Best Practices

Conclusion


MPLS-VPN Services3. 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 to share the import and export route-target (RT) values within the VRFs of extranets.

Export-map or import-map may be used for advanced extranet.


VPN_B Site#1

180.1.0.0/16

MPLS-VPN Services3. Extranet VPN – Simple Extranet

71.8.0.0/16 PE1 PE2

MPLS BackboneVPN_A Site#2

P

VPN_A Site#1

ip vrf VPN_A

rd 3000:111




ip vrf VPN_B

rd 3000:222




192.6.0.0/16

All Sites of Both VPN_A and VPN_B can Communicate

with Each Other.


VPN_B Site#1

180.1.0.0/16

MPLS-VPN Services3. Extranet VPN – Advanced Extranet

71.8.0.0/16 PE1 PE2

MPLS BackboneVPN_A Site#2

P

VPN_A Site#1

ip vrf VPN_A

rd 3000:111




import map VPN_A_Import

export map VPN_A_Export

!

route-map VPN_A_Export permit 10

match ip address 1

set extcommunity rt 3000:2 additive

!

route-map VPN_A_Import permit 10

match ip address 2

!

access-list 1 permit 71.8.0.0 0.0.0.0


ip vrf VPN_B

rd 3000:222




import map VPN_B_Import

export map VPN_B_Export

!

route-map VPN_B_Export permit 10

match ip address 2

set extcommunity rt 3000:1 additive

!

route-map VPN_B_Import permit 10

match ip address 1

!



192.6.0.0/16

Only Site #1 of Both VPN_A and VPN_B Would Communicate

with Each Other.

Lack of ‘additive’

would result in

3000:222 being

replaced with

3000:1. We don’t

want that.


Agenda

MPLS VPN Explained

MPLS-VPN Services








8. QoS Service to VPNs





Best Practices

Conclusion


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


MPLS-VPN Services4. Internet Access: Design Options

Four options 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 Services4. Internet Access: Design Options

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

2. Separate PE-CE subinterface (non-VRF)

May run BGP to propagate Internet routes between PE and CE

3. Extranet with Internet-VRF

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

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

VPN packets never leave VRF context; works well with overlapping VPN address


192.168.1.2

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

CE1MPLS Backbone

192.168.1.1

Internet GW

SO

P

PE1#

ip vrf VPN-A

rd 100:1


Interface Serial0

ip address 192.168.10.1 255.255.255.0


Router bgp 100

no bgp default ipv4-unicast

redistribute static

neighbor 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 71.8.0.0 255.255.0.0 Serial0

Site1

Internet71.8.0.0/16

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


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: Internet Access4.1 Option#1: VRF Specific Default Route (Forwarding)

71.8.0.0/16

PE1 PE2S0

P

PE1: VRF Routing/FIB Table

Destination Label/Interface

0.0.0.0/0 192.168.1.1 (global)

Site-1 Serial 0

PE1: Global Routing/FIB Table


192.168.1.1/32 Label=30

71.8.0.0/16 Serial 0

Internet

(5.1.0.0/16)

PE2: Global Table and LFIB


192.168.1.2/32 Label=35

71.8.0.0/16 192.168.1.2

5.1.0.0/16 Serial 0

192.168.1.2

Pros

Different Internet gateways

Can be used for different VRFs

PE routers need not to hold the Internet table

Simple configuration

Site1

S0

MPLS Backbone

192.168.1.1

5.1.1.130

MPLS Packet

5.1.1.1

IP Packet

71.8.1.135

5.1.1.1

IP Packet

71.8.1.1 IP Packet71.8.1.1

MPLS Packet

71.8.1.1

IP Packet


PE1-CE1 has one sub-interface associated to a VRF for VPN routing

PE1-CE has another subinterface (global) for Internet routing

PE1 may have eBGP peering with CE1 over the global interface and advertise full Internet routes or a default route to CE1

PE2 must advertise VPN/site1 routes to the Internet.

ip vrf VPN-A

rd 100:1


Interface Serial0.1


ip address 192.168.20.1 255.255.255.0

frame-relay interface-dlci 100

!

Interface Serial0.2

ip address 71.8.10.1 255.255.0.0

frame-relay interface-dlci 200

!

Router bgp 100

no bgp default ipv4-unicast


71.8.0.0/16

CE1

MPLS Backbone

Internet GW

Se0.2

P

iBGP

Site1

Se0.1

InternetInternet

MPLS-VPN Services: Internet Access 4.2 Option#2: Separate PE-CE Subinterfaces

192.168.1.2192.168.1.1

PE1 PE2


CE Routing Table

VPN Routes Serial0.1

Internet Routes Serial0.2

PE1 Global Table and FIB

Internet Routes 192.168.1.1

192.168.1.1 Label=30

Pros

1. CE is dual-homed and can

perform Optimal Routing

2. Traffic Separation Done

by CE

Cons

1. PE to Hold Full Internet Routes

or default route via the Internet

GW

. BGP Complexities Introduced at

CE; CE1 May Need to Aggregate

to Avoid AS_PATH Looping

71.8.0.0/16

MPLS Backbone

PE-Internet GW

S0.2

P

Site1

S0.1

InternetInternet

MPLS-VPN Services: Internet Access 4.2 Option#2: Separate PE-CE Subinterfaces (Forwarding)

192.168.1.2192.168.1.1

PE1 PE2

5.1.1.1

IP Packet

5.1.1.130

MPLS Packet 5.1.1.1

IP PacketCE1


MPLS-VPN Services: Internet Access 4.3 Option#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


MPLS-VPN Services: Internet Access 4.4 Option#4: 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

MPLS VPN Explained

MPLS-VPN Services








8. QoS Service





Best Practices

Conclusion


MPLS-VPN Services5. 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 Services5. 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


Internet217.34.42.2.1

MPLS-VPN Services:5. 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-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


ip vrf blue

rd 3000:222


router bgp 3000

address-family ipv4 vrf green

network 0.0.0.0

address-family ipv4 vrf blue

network 0.0.0.0

PPE11

PE12



MPLS Backbone

P

Traffic Flows

Internet

Src=10.1.1.1

Dest=Internet

Src=24.1.1.1

Dest=Internet

Src=10.1.1.1

Dest=Internet

Label Stack 30

Src=10.1.1.1

Dest=Internet

IP Packet

MPLS 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

This is also one of the ways to provide Internet 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

Src=25.1.1.1

Dest=Internet

IP Packet Label Stack 40

Src=10.1.1.1

Dest=Internet



The previous example uses one of many variations of NAT configuration

Other variations (few below) work fine as well

Extended vs. standard ACL for traffic classification

PAT (e.g. overload config)

Route-map instead of ACL for traffic classification

Single NAT pool instead of two pools

Reference


Agenda

MPLS VPN Explained

MPLS-VPN Services








8. QoS Service





Best Practices

Conclusion


MPLS VPN Service6. VRF-Selection

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

―VRF-selection‖ breaks this association and enables multiple VRFs associated to an interface

Each packet on PE-CE interface is classified in real-time and mapped to one of many VRFs

Classification criteria could be source/dest IP address, ToS, TCP port, etc. specified in the ACL

Voice and data traffic on a single PE-CE interface can be separated out into different VRFs at the PE;

service enabler

Reference


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

PE1 PE2MPLS Backbone

(Cable Company)

CE1

RR

44.3.12.1 66.3.0.0/16

VPN Green

33.3.14.1

44.3.0.0/16

VPN Yellow

Global Interface

Se0/0

Cable

Setup

VRF Interfaces

Traffic Flows

ip vrf red

rd 3000:111



!

ip vrf yellow

rd 3000:222



!

ip vrf green

rd 3000:333



route-map PBR-VRF-Selection permit 10

match ip address 40

set vrf red

!


match ip address 50

set vrf yellow

!


match ip address 100

set vrf green

interface Serial0/0

ip address 215.2.0.6 255.255.255.252

ip policy route-map PBR-VRF-Selection

ip vrf receive red

ip vrf receive yellow

ip vrf receive green

!



access-list 100 permit udp 33.3.1.0 0.0.0.255 any

dscp ef range 30000 31000

!

ip route vrf red 33.3.14.0 0.0.0.255 Se0/0

ip route vrf yellow 44.3.1.0 0.0.0.255 Se2/0

ip route vrf green 33.3.1.0 0.0.0.255 Se2/0

33.3.0.0/16

VPN Brown

Reference

33.3.1.25


Agenda

MPLS VPN Explained

MPLS-VPN Services








8. QoS Service





Best Practices

Conclusion


MPLS VPN Service7. 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-3005 Deploying Remote-Access IPSec/SSL VPNs

BRKSEC-3006 Deploying Site-to-site VPN with DMVPN

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

BRKSEC-2007 Site to Site VPN with GET VPN

Reference


Internet

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

Corporate IntranetBranchOffice

Access

Remote Users/

Telecommuters

MPLS VPNIPSec SessionIP 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 higherCustomer A

Branch Office

PE

SP AAA Customer

AAAPE+IPSec

Aggregator

VPN A

IKE_ID is used to map

the IPSectunnel to the VRF(within the ISAKMP profile)

Reference


Agenda

MPLS VPN Explained

MPLS-VPN Services






6. Remote VPN Access


8. QoS Service





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

BRKIPM-2104 Deploying MPLS Traffic Engineering

BRKIPM-3071 Advanced MPLS Designs

BRKIPM-2018 QoS Decomposed

Reference


Agenda

MPLS VPN Explained

MPLS-VPN Services






6. Remote VPN Access


8. QoS Service





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:

BRKIPM-2261 Deploying IP Multicast

BRKIPM-3261 Advances in IP Multicast

Reference


Agenda

MPLS VPN Explained

MPLS-VPN Services




4. Internet Access Service to VPN Customers


6. Remote Access MPLS VPN



9. Multicast Service to VPNs




Best Practices

Conclusion


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

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

No MPLS needed in the core

PE-to-PE IP tunnel is used, instead of MPLS tunnel, for sending MPLS/VPN packets

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

MPLS/VPN packet is encapsulated inside an IP header

IP tunnel could be GRE, mGRE etc.

Reference

http://www.cisco.com/en/US/docs/ios/interface/configuration/guide/ir_mplsvpnomgre.html


IP Header

GRE Header

VPN Label

src adddst add

data

src adddst add

data

src adddst add

data

IP

CE1 CE2PE1 PE2

VRF

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

GRE/IP header and VPN label imposed on VPN traffic by PE1

VPN traffic is forwarded towards egress PE using IP forwarding

Egress PE2 decapsulates, and uses VPN label to forward packet to CE2

GRE/IP Tunnel

Reference

VRF

http://www.cisco.com/en/US/docs/ios/interface/configuration/guide/ir_mplsvpnomgre.html

IP Packet


Agenda

MPLS VPN Explained

MPLS-VPN Services













Best Practices

Conclusion


MPLS-VPN Services:11. IPv6 VPN Service

Similar to IPv4 VPN, IPv6 VPN can also be offered.

Referred to as ―IPv6 VPN Provider Edge (6VPE)‖.

No modification on the MPLS core.

IPv4 and IPv6 VPNs can be offered on the same interface

Config and operation of IPv6 VPN are similar to IPv4 VPN

P

P

P

P

iBGP Sessions in VPNv4 and

VPNv6 address-families

VPN B

VPN A

v4 and v6

VPN A

v6 Only

v4 and v6

VPN B

VPN A

v6 Only

v4 and v6

MPLS/VPN

Network

PE PE

PE PE

CE

CE

CE

CE

CE


MPLS-VPN Services:11. IPv6 VPN Service

P

P

P

P

iBGP Sessions in VPNv4 and

VPNv6 address-families

VPN B

VPN A

v4 and v6

VPN A

v6 Only

v4 and v6

VPN B

VPN A

v6 Only

v4 and v6

MPLS/VPN

Network

PE PE

PE PE

CE

CE

CE

CE

CE

PE#

!

vrf definition v2

rd 2:2

!

address-family ipv4



exit-address-family

!

address-family ipv6



exit-address-family

!

!

router bgp 1

!




exit-address-family

!




exit-address-family

!

address-family ipv4 vrf v2

exit-address-family

!

address-family ipv6 vrf v2

neighbor 200::2 remote-as 30000

neighbor 200::2 activate

exit-address-family

!


Agenda

MPLS VPN Explained

MPLS-VPN Services













Best Practices

Conclusion


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

Is it possible for an IP router to keep multiple customer connections 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 in a multi-VRF CE implementation

No MPLS functionality needed on CE, no label exchange between CE and any router (including PE)

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


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

Campus

PE

MPLS

Network

Multi-VRF

CE Router

SubInterface

Link *

PE

Router

Campus

One Deployment Model—Extending MPLS/VPN to CE

Vrf Green

Vrf Red

Vrf

Green

ip vrf green

rd 3000:111


ip vrf blue

rd 3000:222


ip vrf red

rd 3000:333


Vrf Green

Vrf Red

*SubInterface Link—Any Interface Type that Supports Sub Interfaces, FE-Vlan,

Frame Relay, ATM VCs

Vrf

Red

ip vrf green

rd 3000:111

ip vrf blue

rd 3000:222

Ip vrf red

rd 3000:333


Agenda

MPLS VPN Explained

MPLS-VPN Services

Best Practices

Conclusion


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. Choose AS format for RT and RD 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,

Helpful for many scenarios such as multi-homing, hub&spoke etc.

4. Don‘t use customer names (V458:GodFatherNYC32ndSt) as the VRF names; nightmare for the NOC.

Consider v101, v102, v201, v202, etc. and Use description for naming

5. Utilize SP‘s public address space for PE-CE IP addressing

Helps to avoid overlapping; Use /31 subnetting on PE-CE interfaces

6. Limit the number of prefixes per-VRF and/or per-neighbor on PE

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)


Best Practices

7. Leverage BGP Prefix Independent Convergence (PIC) for fast convergence

• PIC Core and PIC Edge

• Best-external advertisement

• Next-hop tracking (ON by default)

8. Consider RT-constraint for Route-reflector scalability


Agenda

MPLS VPN Explained

MPLS-VPN Services

Best Practices

Conclusion


Conclusion

MPLS VPN is becoming a cheaper and faster alternative to traditional l2vpn

Secured VPN

Straightforward to configure any-to-any VPN topology

Partial-mesh, Hub and Spoke topologies can also be easily deployed

VRF-aware services could be deployed to maximize the investment

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

MPLS-VPN paves the way for virtualization.

Benefits whether SP or Enterprise.


Complete Your Online Session Evaluation

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

Receive 20 Passport points for each session evaluation you complete.

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

Don‘t forget to activate your Cisco Live Virtual account for access to all session material, communities, and

on-demand and live activities throughout the year. Activate your account at the

Cisco booth in the World of Solutions or visit www.ciscolive.com.

http://www.ciscolive.com/


Meet The Expert

To make the most of your time at Cisco Networkers 2010, schedule a Face-to-Face Meeting with a top Cisco Expert.

Designed to provide a "big picture" perspective as well as "in-depth" technology discussions, these face-to-face meetings will provide fascinating dialogue and a wealth of valuable insights and ideas.

Visit the Meeting Centre reception desk located in the Meeting Centre in World of Solutions


Recommended Reading

Continue your 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


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

RR2RR1

Provider X Provider Y


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/24NH=PE-1RT=1:1, Label=(29)

VPN-B VRFImport routes with Route-Target 1:1

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

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

VPN-B VRFImport Routes with

Route-Target 1:1

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


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.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 need to load the Inter-AS code (but still notwidely deployed)

Pros Cons


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 green

rd 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

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


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


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-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-1RT=1:1, Label=(20)

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

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


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

More scalable Only one interface between

ASBRs routers

No VRF configuration on ASBR.

Less memory consumption (no RIB/FIB memory)

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

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 Packets

Between ASBRs

10.1.1.14030

10.1.1.140

10.1.1.1

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

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 Exchange Between ASBRs Using MP-eBGP

Router bgp x

no bgp default route-target filter

neighbor 1.1.1.x remote-as x

!


neighbor 1.1.1.x activate

neighbor 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 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)


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#2ASBR-2

RR-1

IP-v4 Update: Network=PE-1 NH=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, RIPv2 10.1.1.0/24,NH=PE-2

AS#1

IGP+LDP: Network=PE-1 NH=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-1 NH=PE-1Label=(40)


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

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


Scenario 3: 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

Pros Cons


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

!


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


Scenario 4: Non-VPN Transit Provider

PE1

PE2VPN-B

CE-2

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-4next-hop-unchanged

eBGP IPv4 + Labels

eBGP IPv4 + Labels

MPLS VPN

Provider #1

MPLS VPN

Provider #2

iBGP IPv4 + Labels

CE-3

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


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)


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

PE1PE2

ISP PoP

Site-1

CE-1 CE-2

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

ASBR-1

Internal Routes = IGP Routes


IGP+LDPIGP+LDP

Internet

C1

MPLS-Enabled VRF Int

IPv4 Routes with Label Distribution



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


Internet

CsC Deployment Models

PE1PE2

ISP PoP

Site-1

CE-1CE-2

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


ASBR-1

internal Routes = IGP Routes

IGP+LDPIGP+LDP

MPLS-Enabled VRF int

C1




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.


PE1 PE2

ISP PoP

Site-1

CE-1CE-2

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

R1R2

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

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

VPN Site-1

C1

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

IGP+LDP 30.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


PE1

PE2

ISP PoP

Site-1

CE-1CE-2

ISP PoP

Site-2

Carrier’s Core

P1

ASBR-1 ASBR-2

R1 R2Network =

10.1.1.0/24

10.1.1.1905116

VPN Site-1VPN Site-2

C1

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

10.1.1.110.1.1.1 10.1.1.19070

10.1.1.19010.1.1.19060

10.1.1.19052

10.1.1.19051

10.1.1.19050

designing mpls l3vpn networksd2zmdbbm9feqrf.cloudfront.net/2011/eur/pdf/brkipm-2017.pdf ·...

Documents