MPLS L3 VPN

Advantages of MPLS Layer-3 VPN

● Scalability
● Security
● Easy to Create
● Flexible Addressing
● Integrated Quality of Service (QoS) Support
● Straightforward Migration
MPLS/VPN Technology Overview

• More than one routing and forwarding tables

• Control plane—VPN route propagation
• Data or forwarding plane—VPN packet forwarding

3
IGP (ISIS/OSPF
MPLS on Service Backbone
VRF towards the Customer
MP-BGP on PE1 and PE2
Customer R6, R7
 IP/VPN Technology
MPLS IP/VPN Topology | Connection Model
CE P P
CE
PE PE
MPLS Network
P P
CE
CE

MP-iBGP Session

PE Routers P Routers
▪ Sit at the Edge | customers connect her ▪ Sit inside the network | Core routers
▪ Use MPLS with P routers ▪ Forward packets by looking at labels
▪ Uses IP with CE routers ▪ P and PE routers share a common IGP
▪ Distributes VPN information through (OSPF, ISIS)
MP-BGP to other PE routers

11
 IP/VPN Technology Overview
Separate Routing Tables at PE
CE2
VPN 2
P
CE1 E MPLS Network IGP (OSPF, ISIS)
VPN 1

Customer Specific Routing Table

Global Routing Table
• Routing (RIB) and forwarding table (CEF)
dedicated to VPN customer • Created when IP routing is enabled on PE.
• VPN1 routing table • Populated by OSPF, ISIS, etc. running
• VPN2 routing table inside the MPLS network
• Referred to as VRF table for <named VPN>
IOS: “show ip route”
IOS: “show ip route vrf <name>” IOS-XR:“sh route ipv4 unicast”
IOS-XR:“sh route vrf <name> ipv4 NX-OS: “sh ip route”
NX-OS: “sh ip route vrf <name>”

12
IP/VPN Technology Overview
Virtual Routing and Forwarding Instance

CE2
VPN 2 VRF Green
PE
CE1 MPLS Network IGP (OSPF, ISIS)
VPN 1 Ser0/0
VRF Blue

• What’s a Virtual Routing and Forwarding (VRF) ?

• Representation of VPN customer inside the 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
IOS_PE(conf)#ip vrf blue
• No changes needed at CE IOS_PE(conf)#interface Ser0/0
IOS_PE(conf)#ip vrf forwarding blue
 IP/VPN Technology Overview
Virtual Routing and Forwarding Instance
EIGRP, eBGP, OSPF, RIPv2, Static

CE2
VPN 2 VRF Green
PE
CE1 MPLS Network IGP (OSPF, ISIS)
VPN 1 Ser0/0
VRF Blue

• PE installs the internal routes (IGP) in global routing table

• PE installs the VPN customer routes in VRF routing table(s)
• VPN routes are learned from CE routers or remote PE routers
• VRF-aware routing protocol (static, RIP, BGP, EIGRP, OSPF) on each PE
• VPN customers can use overlapping IP addresses
• BGP plays a key role. Let’s understand few BGP specific details..…
14
IP/VPN Technology Overview
Control Plane = Multi-Protocol BGP (MP-BGP)
8 Bytes 4 Bytes 8 Bytes 3 Bytes
MP-BGP UPDATE Message Showing
VPNv4 Address, RT, Label only
1:1 [Link]
RD IPv4 Route-Target Label
VPNv4

MP-BGP Customizes the VPN Customer Routing Information as

per the Locally Configured VRF Information at the PE using:
• Route Distinguisher (RD)
• Route Target (RT)
• Label
15
IP/VPN Technology Overview: Control Plane Reference

MP-BGP UPDATE Message Capture Reference

• Visualize how the

BGP UPDATE
message
advertising
VPNv4 routes
looks like.
• Notice the Path
Attributes. Route Target = 3:3

VPNv4 Prefix [Link][Link]/30

; Label = 23

16
IP/VPN Technology Overview: Control Plane
Route-Distinguisher (rd)
8 Bytes 4 Bytes 8 Bytes 3 Bytes MP-BGP UPDATE Message Showing
VPNv4 Address, RT, Label only

1:1 [Link]
RD IPv4 Route-Target Label
VPNv4

• VPN customer IPv4 prefix is converted into a VPNv4 prefix by

appending the RD (1:1, say) to the IPv4 address ([Link], say) =>
[Link][Link]
• Makes the customer’s IPv4 address unique inside the SP MPLS
network. IOS_PE#
!
• Route Distinguisher (rd) is configured in the VRF at PE ip vrf green
rd 1:1
• RD is not a BGP attribute, just a field. !

17
IP/VPN Technology Overview: Control Plane
Route-Target (rt)

8 Bytes 4 Bytes 8 Bytes 3 Bytes

1:1 [Link] 1:2

RD IPv4 Route-Target Label
VPNv4

• Route-target (rt) identifies which VRF(s) keep which VPN prefixes

IOS_PE#
• rt is an 8-byte extended community attribute. !
ip vrf green
• Each VRF is configured with a set of route-targets at PE route-target import 3:3
route-target export 3:3
• Export and Import route-targets must be the same for route-target export 10:3
any-to-any IP/VPN !

• Export route-target values are attached to VPN routes in PE->PE

MP-iBGP advertisements
IP/VPN Technology Overview: Control Plane
Label
8 Bytes 4 Bytes 8 Bytes 3 Bytes

1:1 [Link] 2:2 50

RD IPv4 Route-Target Label
VPNv4

• PE assigns a label for the VPNv4 prefix;

• Next-hop-self towards MP-iBGP neighbors by default i.e. PE sets
the NEXT-HOP attribute to its own address (loopback)
• Label is not an attribute.
• PE addresses used as BGP next-hop must be uniquely
known in IGP
• Do not summarize the PE loopback addresses in the core
19
IP/VPN Technology Overview: Control Plane
MP-iBGP Update:
RD:[Link]
Site 1 3 Next-Hop=PE-1 Site 2
CE1 RT=1:2, Label=100
[Link]/24
2 P P
[Link]/24 CE2
Next-Hop=CE-1
P P
1 PE1
PE2

MPLS Backbone

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

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

• PE1 sends MP-iBGP update to other PE routers

20
IP/VPN Technology Overview: Control Plane
MP-iBGP Update:
[Link]/24
3
RD:[Link]
Next-Hop=PE-2
Site 2
Site 1 Next-Hop=PE-1
RT=1:2, Label=100
CE1 5
[Link]/24
2 4
P P CE2
[Link]/24
Next-Hop=CE-1
P P
1 PE1 PE2

MPLS Backbone
• 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 to IPv4 prefix
• Updates the VRF CEF Table for [Link]/24 with label=100

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

Control Plane is now ready

21
IP/VPN Technology Overview
Forwarding Plane
Site 1 Site 2
[Link]/24 CE1
P P
CE2

P P
PE1 PE2
MPLS Backbone

Customer Specific Forwarding Table Global Forwarding Table

• Stores VPN routes with associated • Stores next-hop i.e. PE routes with
labels associated labels
• VPN routes learned via BGP • Next-hop i.e. PE routes learned through IGP
• Labels learned via BGP • Label learned through LDP or RSVP

IOS:show ip cef vrf <name> IOS:show ip cef

NX-OS: show forwarding ipv4
NX-OS: show forwarding vrf <name> IOS-XR: show cef ipv4
IOS-XR: show cef vrf <name> ipv4
22
IP/VPN Technology Overview: Forwarding Plane
Packet Forwarding
Site 1 Site 2
CE1 CE2
[Link]/24
P3 P4
PE1 PE2
[Link] [Link] IP Packet
100 [Link] P1 P2
IP Packet

50 100 [Link] 25 100 [Link] MPLS Packet

• PE2 imposes two labels (MPLS headers) for each IP packet going to site2
• Outer label is learned via LDP; Corresponds to PE1 address (e.g. IGP route)
• Inner label is learned via BGP; corresponds to the VPN address (BGP route)
• P1 does the Penultimate Hop Popping (PHP)
• PE1 retrieves IP packet (from received MPLS packet) and forwards it to CE1.

23
IP/VPN Technology: Forwarding Plane Reference

Reference

MPLS IP/VPN Packet Capture

• This capture
might be helpful
if you never
captured an
MPLS packet
Ethernet Header
Outer Label

before.
Inner Label

IP Packet

24
Agenda

• IP/VPN Overview
• Technology Overview
• Configuration Overview (IOS, IOS-XR and NX-OS)
• IP/VPN Services
• Best Practices
• Conclusion
 MPLS based IP/VPN Sample Configuration (IOS) - 1
Reference

Reference

VRF Definition
ip vrf VPN-A vrf definition VPN-A
rd 1:1 rd 1:1
Site 1 route-target export 100:1 address-family ipv4
CE1 route-target import 100:1 route-target export 100:1
[Link]/24 route-target import 100:1
PE1
PE1 interface Serial0 interface Serial0
Se0
ip address [Link]/24 ip address [Link]/24
[Link] vrf forwarding VPN-A
ip vrf forwarding VPN-A

PE-P Configuration
Interface Serial1
ip address [Link] [Link]
P mpls ip
PE1 s1 PE1
Se0
router ospf 1
network [Link] [Link] area 0

26
 MPLS based IP/VPN Sample Configuration (IOS) - 2
Reference

PE: MP-IBGP Config

router bgp 1
neighbor [Link] remote-as 1
RR neighbor [Link] update-source loopback0
!
PE1 PE2 PE1 address-family vpnv4
neighbor [Link] activate
neighbor [Link] send-community both
!

RR: MP-IBGP Config

router bgp 1
no bgp default route-target filter
neighbor [Link] remote-as 1
RR
neighbor [Link] update-source loopback0
RR !
PE1 PE2 address-family vpnv4
neighbor [Link] route-reflector- client
neighbor [Link] activate
!

27
 MPLS based IP/VPN Sample Configuration (IOS) - 3
Reference

PE-CE Routing: BGP

router bgp 1
Site 1
CE1 !
address-family ipv4 vrf VPN-A
[Link]/24 PE1 neighbor [Link] remote-as 2
neighbor [Link] activate
[Link] PE1 exit-address-family
!
[Link]

PE-CE Routing: OSPF

router ospf 1
Site 1
CE1 !
router ospf 2 vrf VPN-A
[Link]/24 PE1 network [Link] [Link] area 0
redistribute bgp 1 subnets
[Link] PE1 !
[Link]

28
 MPLS based IP/VPN Sample Configuration (IOS)
Reference

PE-CE Routing: RIP

router rip
!
Site 1
CE1 address-family ipv4 vrf VPN-A
version 2
[Link]/24 PE1 no auto-summary
network [Link]
[Link] PE1 redistribute bgp 1 metric transparent
!
[Link]

PE-CE Routing: EIGRP

router eigrp 1
!
Site 1 address-family ipv4 vrf VPN-A
CE1 no auto-summary
[Link]/24 PE1 network [Link] [Link]
autonomous-system 10
redistribute bgp 1 metric 100000 100
[Link] PE1
255 1 1500
[Link] !

29
 MPLS based IP/VPN Sample Configuration (IOS)
Reference

PE-CE Routing: Static

Site 1
CE1
ip route vrf VPN-A [Link] [Link]
[Link]/24 PE1 [Link]
[Link] PE1

[Link]

30
 MPLS based IP/VPN Sample Configuration (IOS)
Reference

If PE-CE Protocol Is Non-BGP, then Redistribution of Local

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

PE-RR (VPN Routes to VPNv4)

Site 1 router bgp 1
neighbor [Link] remote-as 1
RR
neighbor [Link] update-source loopback 0
PE1
PE1 address-family ipv4 vrf VPN-A
CE1 redistribute
{rip|connected|static|eigrp|ospf}

• Having familiarized with IOS based config, let’s peek through IOS-XR and
NX-OS config for VPNs

31
Agenda
• IP/VPN Overview
• IP/VPN Services
1. Hub and Spoke Service
2. Extranet Service
3. Internet Access Service
4. IP/VPN over IP Transport

•
IP/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 based IP/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
33
IP/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

34
 Import and Export RT Supported in IO
Values Must Be Different NXOS and IOS-X
IP/VPN Services:
2. Hub and Spoke Service: IOS Configuration – Option#1
ip vrf green-spoke1
description VRF for SPOKE A
rd 300:111 ip vrf HUB
route-target export 1:1 description VRF for HUB
route-target import 2:2 rd 300:11
Spoke A route-target import 1:1
CE-SA PE-SA
route-target export 2:2
[Link]/24

PE-Hub
Eth0/0
Spoke B CE-SB
PE-SB
CE-Hub
MPLS VPN Backbone
[Link]/24

ip vrf green-spoke2 • PE-Hub MUST advertise only default or aggregate route(s)

description VRF for SPOKE B to PE-SA/SB
rd 300:112 • PE-Hub MUST NOT use bgp aggregation
route-target export 1:1
route-target import 2:2

Note: Only VRF Configuration Is Shown Here

 Import and Export RT Values Supported in
Must Be Different NXOS and IO
IP/VPN Services:
2. Hub and Spoke Service: IOS Configuration – Option#2
ip vrf green-spoke1
description VRF for SPOKE A
rd 300:111
route-target export 1:1 ip vrf HUB-IN
route-target import 2:2 description VRF for traffic from HUB
Spoke A PE-SA rd 300:11
CE-SA
route-target import 1:1
[Link]/24

Eth0/0.1
PE-Hub Eth0/0.2
PE-SB
Spoke B CE-SB MPLS VPN Backbone CE-Hub
[Link]/24
ip vrf HUB-OUT
description VRF for traffic to HUB
ip vrf green-spoke2 rd 300:12
description VRF for SPOKE B route-target export 2:2
rd 300:112
• PE-Hub can advertise Spoke specific route(s) to PE-SA/SB.
route-target export 1:1 • PE-Hub MAY use bgp aggregation.
route-target import 2:2

Note: Only VRF Configuration Is Shown Here

 Supported in IOS,
NXOS and IOS-XR
IP/VPN Services:
2. Hub and Spoke Service: Configuration – Option#2
• 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
37
 Supported in IOS,
NXOS and IOS-XR

IP/VPN Services:
2. Hub and Spoke Service: Configuration – Option#2
router bgp <ASN>
ip vrf green-spoke1
address-family ipv4 vrf HUB-IN
description VRF for SPOKE A neighbor <CE> as-override
rd 300:111
route-target export 1:1
ip vrf HUB-IN
route-target import 2:2
description VRF for traffic from HUB
Spoke A PE-SA rd 300:11
CE-SA route-target import 1:1
[Link]/24

Eth0/0.1
PE-Hub Eth0/0.2
Spoke B PE-SB
CE-SB CE-Hub
MPLS VPN Backbone
[Link]/24

ip vrf green-spoke2 ip vrf HUB-OUT

description VRF for SPOKE B description VRF for traffic to HUB
rd 300:112 rd 300:12
route-target export 1:1 route-target export 2:2
route-target import 2:2
router bgp <ASN>
address-family ipv4 vrf HUB-OUT
neighbor <CE> allowas-in 2

38
 Supported in IOS,
NXOS and IOS-XR

IP/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 [Link]/16 routes to remote PEs

VRF FIB and LFIB

Destination NextHop Label MPLS Backbone FIB—IP Forwarding Table
[Link]/16 PE-Hub 35
LFIB—MPLS Forwarding
[Link]/24 CE-SA
Table
Spoke A MP-iBGP Update
[Link]/24 VRF HUB-IN FIB and LFIB
[Link]/24 CE-SA PE-SA Label 40 Destination NextHop Label
Route-Target 1:1 [Link]/24 PE-SA 40
[Link]/24 PE-SB 50

MP-iBGP Update
VRF FIB and LFIB
[Link]/16
VRF HUB-IN
[Link]/16 PE-Hub 35
Label 35 PE-Hub
[Link]/24 CE-SB VRF HUB-OUT
PE-SB Route-Target 2:2

Spoke B VRF HUB-OUT FIB CE-Hub

MP-iBGP Update Destination NextHop
[Link]/24 [Link]/24 [Link]/16 CE-H1
CE-SB Label 50
Route-Target 1:1

39
 Supported in IOS,
NXOS and IOS-XR

IP/VPN Services:
2. Hub and Spoke Service: Forwarding Plane (Option#2)
This Is How the Spoke-to-Spoke Traffic Flows

Spoke A [Link] MPLS Backbone

PE-SA
CE-SA L2 40 [Link]
[Link]/24 [Link]

VRF HUB-IN
CE-Hub
Spoke B PE-Hub
VRF HUB-OUT
PE-SB L1 35 [Link]
CE-SB
[Link]
[Link]/24

[Link]

L1 Is the Label to Get to PE-Hub

L2 Is the Label to Get to PE-SA
40
IP/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 ☹ CE-SA1
PE-Hub

CE-SA2 PE-SA

CE-SA3

• Half-duplex VRF is the answer

• Uses two VRFs on the PE (spoke) router :
• A VRF for spoke->hub communication (e.g. upstream)
• A VRF for spoke<-hub communication (e.g. downstream)
Note: 12.2(33) SRE Supports Any Interface Type (Eth, Ser, POS, Virtual-Access, etc.)
41
 Supported in IOS

IP/VPN Services:
2. Hub and Spoke Service: Half-Duplex VRF
ip vrf green-up ip vrf green-down
description VRF - upstream description VRF - downstream traffic
traffic rd 300:112
rd 300:111 route-target export 1:1
route-target import 2:2 ip vrf HUB-IN
description VRF for traffic from
HUB
Spoke A rd 300:11
route-target import 1:1
CE-SA
[Link]/24 S
Hub Site
w GE0/0 MPLS Backbone
PE-SA

PE-Hub
Spoke B CE-Hub
Interface GigEthernet 0/0
ip vrf HUB-OUT
ip address [Link] [Link]
[Link]/24 description VRF for traffic to
ip vrf forward green-up downstream
green-down
HUB
CE-SB rd 300:12
..
route-target export 2:2

Upstream VRF Downstream VRF

1. PE-SA installs the Spoke routes only in downstream VRF i.e. green-down
2. PE-SA installs the Hub routes only in upstream VRF i.e. green-up
3. PE-SA forwards the incoming IP traffic (from Spokes) using upstream VRF i.e. green-up routing table.
4. PE-SA forwards the incoming MPLS traffic (from Hub) using downstream VRF i.e. green-down routing table 42
43

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
MPLS-VPN Services
3. Extranet VPN

• MPLS based IP/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.

44
 Supported in IOS,

MPLS-VPN Services NXOS and IOS-XR

3. Extranet VPN – Simple Extranet (IOS Config sample)

MPLS Backbone
[Link]/16
VPN_A Site#2
P P
VPN_A Site#1
[Link]/16 PE1 PE2
[Link]/16

VPN_B Site#1

ip vrf VPN_A ip vrf VPN_B

rd 3000:111 rd 3000:222
route-target import 3000:111 route-target import 3000:222
route-target export 3000:111 route-target export 3000:222
route-target import 3000:222 route-target import 3000:111

All Sites of Both VPN_A and VPN_B Can Communicate

with Each Other
45
 Supported in IOS,
NXOS and IOS-XR

MPLS-VPN Services
3. Extranet VPN – Advanced Extranet (IOS Config sample)
[Link]/16
MPLS Backbone
VPN_A Site#2
VPN_A Site#1
[Link]/16 PE1 PE2
P [Link]/16
VPN_B Site#1

ip vrf VPN_A ip vrf VPN_B

rd 3000:111 rd 3000:222
route-target import 3000:111 route-target import 3000:222
route-target export 3000:111 route-target export 3000:222
route-target import 3000:1 route-target import 3000:2
import map VPN_A_Import import map VPN_B_Import
export map VPN_A_Export export map VPN_B_Export
! !
route-map VPN_A_Export permit 10 route-map VPN_B_Export permit 10
match ip address 1 match ip address 2
set extcommunity rt 3000:2 additive set extcommunity rt 3000:1 additive Lack of ‘Additive’
! ! Would Result in
route-map VPN_A_Import permit 10 route-map VPN_B_Import permit 10 3000:222 Being
match ip address 2 match ip address 1 Replaced with
! ! 3000:1. We Don’t
access-list 1 permit [Link] [Link] access-list 1 permit [Link] [Link] Want That.
access-list 2 permit [Link] [Link] access-list 2 permit [Link] [Link]

Only Site #1 of Both VPN_A and VPN_B Would Communicate

with Each Other
46
47

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
MPLS-VPN Services
4. Internet Access Service to VPN Customers

• Internet access service could be provided as another value-added service

to VPN customers
• Security mechanism must be in place at both provider network and
customer network
• To protect from the Internet vulnerabilities
• VPN customers benefit from the single point of contact for both Intranet
and Internet connectivity

48
MPLS-VPN Services
4. 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

49
MPLS-VPN Services
4. 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

50
 Supported in IOS

IP/VPN Services: Internet Access

4.1 Option#1: VRF Specific Default Route
Site1 MPLS Backbone
CE1
[Link]/16 Internet
SO [Link] ASBR

P
PE1 [Link]
PE1#
ip vrf VPN-A
Internet GW
rd 100:1
route-target both 100:1
Interface Serial0
ip address [Link] [Link] ▪ A default route, pointing to the
ip vrf forwarding VPN-A ASBR, is installed into the site VRF at
Router bgp 100 each PE
no bgp default ipv4-unicast
redistribute static
neighbor [Link] remote 100 ▪ The static route, pointing to the VRF
neighbor [Link] activate interface, is installed in the global
neighbor [Link] next-hop-self
neighbor [Link] update-source loopback0 routing table and redistributed into
BGP
ip route vrf VPN-A [Link] [Link] [Link] global
ip route [Link] [Link] Serial0
51
 Supported in IOS,

IP/VPN Services: Internet Access

4.1 Option#1: VRF Specific Default Route (Forwarding)
Site1 MPLS Backbone
IP Packet
IP Packet Internet
[Link]/16 [Link] MPLS Packet
30 [Link] [Link] ([Link]/16)
S0 PE1 PE2
[Link] P [Link] IP Packet
[Link] S0
[Link]
PE1: Global Routing/FIB Table [Link] 35 [Link] PE2: Global Table and LFIB
Destination Label/Interface IP Packet Destination Label/Interface
[Link]/32 Label=30
MPLS Packet
[Link]/32 Label=35
[Link]/16 Serial 0 [Link]/16 [Link]
[Link]/16 Serial 0

PE1: VRF Routing/FIB Table Pros Cons

Destination Label/Interface
▪ Using default route
[Link]/0 [Link] (Global) for Internet
Site-1 Serial 0 ▪ Different Internet gateways
▪ Routing does not allow any other
▪ Can be used for default route for intra-VPN routing
different VRFs Increasing size
▪ PE routers need not to of global routing table by leaking
hold the Internet table VPN routes
▪ Simple configuration ▪ Static configuration (possibility of
traffic blackholing)

52
 Supported in IOS,
NXOS and IOS-XR

IP/VPN Services: Internet Access

4.2 Option#2: Separate PE-CE Subinterfaces
Site1
[Link]/16 MPLS Backbone
iBGP Internet
Internet
CE1
Se0.2
PE1 PE2
Se0.1 [Link] P
[Link]
ip vrf VPN-A
rd 100:1 Internet GW
route-target both 100:1

Interface Serial0.1
▪ PE1-CE1 has one sub-interface associated
ip vrf forwarding VPN-A to a VRF for VPN routing
▪
ip address [Link] [Link]
frame-relay interface-dlci 100 PE1-CE has another subinterface (global)
! for Internet routing
Interface Serial0.2
ip address [Link] [Link] ▪ PE1 may have eBGP peering with CE1 over
frame-relay interface-dlci 200 the global interface and advertise full
! Internet routes or a default route to CE1
▪ PE2 must advertise VPN/site1 routes to
Router bgp 100 the Internet.
no bgp default ipv4-unicast
neighbor [Link] remote-as 502

53
 Supported in IOS,
NXOS and IOS-XR

IP/VPN Services: Internet Access

4.2 Option#2: Separate PE-CE Subinterfaces (Forwarding)
Site1
MPLS Backbone
[Link]/16 IP Packet
[Link]
IP Packet Internet
Internet
CE1
MPLS Packet [Link]
S0.2
PE1 30 [Link]
PE2
S0.1 [Link] P
[Link]

CE Routing Table PE-Internet GW

VPN Routes Serial0.1
Internet Routes Serial0.2

Pros Cons
PE1 Global Table and FIB
Internet Routes [Link] 1. CE is dual-homed and can perform 1. PE to Hold Full Internet Routes or
[Link] Label=30 Optimal Routing default route via the Internet GW

2. Traffic Separation Done . BGP Complexities Introduced at CE;

by CE CE1 May Need to Aggregate to Avoid
AS_PATH Looping

54
 Supported in IOS,
NXOS and IOS-XR

IP/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
• Default route is recommended
• 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

55
 Supported in IOS,

IP/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…

56
57

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
 Supported in IOS,
NXOS and IOS-XR

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

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

[Link]
58
 Supported in IOS,
NXOS and IOS-XR

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

PE1 PE2
CE1 CE2
GRE/IP Tunnel

IP
VRF VRF

IP Header
• GRE/IP header and VPN label imposed on VPN traffic by PE1
GRE Header
VPN Label
• VPN traffic is forwarded towards egress PE using IP forwarding
• Egress PE2 decapsulates, and uses VPN label to forward packet to CE2
Src Add Src Add Src Add
IP Packet Dst Add Dst Add Dst Add

Data Data Data

Source -- [Link] 59
60

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
 Supported in IOS,
NXOS and IOS-XR

IP/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
• Core can stay on IPv4
• PE-CE interface can be single-stack IPv6 or dual-stack
• IPv4 and IPv6 VPNs can be offered on the same PE-CE interface
• Config and operation of IPv6 VPN are similar to IPv4 VPN

v4 and v6 PE PE v4 and v6
VPN A VPN A
CE
P P CE
MPLS/VPN
v4 and v6 Network
VPN A
CE P P v6 Only VPN B
PE PE
VPN B v6 Only CE
iBGP Sessions in VPNv4 and
CE VPNv6 Address-Families 61
 Supported in IOS,

IP/VPN Services: NXOS and IOS-XR

11. IPv6 VPN Service IOS-XR_PE#

! NXOS_PE#
IOS_PE#
vrf v2 !
!
! vrf context v2
vrf definition v2
address-family ipv6 unicast rd 2:2
rd 2:2
route-target export 2:2 !
!
route-target import 2:2 address-family ipv6 unicast
address-family ipv6
! route-target export 2:2
route-target export 2:2
router bgp 1 route-target import 2:2
route-target import 2:2
address-family vpnv6 unicast !
!
! router bgp 1
router bgp 1
neighbor [Link] neighbor [Link]
!
remote-as 30000 remote-as 1
address-family vpnv6
address-family vpnv6 unicast update-source loopback0
neighbor [Link] activate
! address-family vpnv6 unicast
neighbor [Link] send-community
vrf v2 send-community extended
both
rd 2:2 !
!
address-family ipv6 unicast vrf vpn1
address-family ipv6 vrf v2
! neighbor 200::2
neighbor 200::2 remote-as 30000
neighbor 200::2 remote-as 30000
neighbor 200::2 activate
remote-as 30000 address-family ipv6 unicast
!
address-family ipv6 unicast !
!

v4 and v6 PE PE v4 and v6
VPN A VPN A
CE
P P CE
MPLS/VPN
v4 and v6 Network
VPN A
CE P P v6 Only VPN B
PE PE
VPN B v6 Only CE
iBGP Sessions in VPNv4 and
CE VPNv6 Address-Families 62
63

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
 Supported in IOS,
NXOS and IOS-XR
IP/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

64
 Supported in IOS,
NXOS and IOS-XR

IP/VPN Services:
12. Providing Multi-VRF CE Service
One Deployment Model—Extending MPLS/VPN to CE

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

Campus ip vrf blue

rd 3000:222
route-target both 3000:2
ip vrf red
rd 3000:333
route-target both 3000:3
Vrf Campus
Green SubInterface
Link * MPLS
Vrf Green
Network Vrf Green
Vrf
Red Vrf Red PE
Multi-VRF PE Router
CE Router
Vrf Red
ip vrf green
rd 3000:111
ip vrf blue
rd 3000:222
Ip vrf red
rd 3000:333

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

Frame Relay, ATM VCs
65
66

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
 Supported in IOS

MPLS-VPN Services
5. VRF-Aware NAT Services

• VPN customers could be using ‘overlapping’ IP address i.e.,[Link]/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.

67
 Supported in IOS

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

68
 Supported in IOS

IP/VPN Services:
5. VRF-Aware NAT Services: Internet Access
CE1
[Link]/24 MPLS Backbone
Green VPN Site PE-ASBR Internet
PE11 .1 [Link]
P
PE12
CE2
[Link]/24 IP NAT Inside
Blue VPN Site
IP NAT Outside

ip vrf green ip nat pool pool-green [Link] [Link] prefix-length 24

rd 3000:111
route-target both 3000:1 ip nat pool pool-blue [Link] [Link] prefix-length 24
ip vrf blue
rd 3000:222 ip nat inside source list vpn-to-nat pool pool-green vrf green
route-target both 3000:2 ip nat inside source list vpn-to-nat pool pool-blue vrf blue

router bgp 3000 ip access-list standard vpn-to-nat

address-family ipv4 vrf green permit [Link] [Link]
network [Link]
address-family ipv4 vrf blue ip route vrf green [Link] [Link] [Link] global
network [Link] ip route vrf blue [Link] [Link] [Link] global
VRF Specific Config VRF-Aware NAT Specific Config
69
 Supported in IOS

IP/VPN Services:
5. VRF-Aware NAT Services: Internet Access
Src=[Link]
Dest=Internet Label Stack 30 MPLS Backbone
CE1 Src=[Link]
[Link]/24 Dest=Internet Src=[Link]
Green VPN Site PE-ASBR Dest=Internet
PE11 Internet
IP Packet P Src=[Link]
PE12
CE2 Dest=Internet
Label Stack 40
[Link]/24 IP Packet
Src=[Link]
Blue VPN Site Dest=Internet Traffic Flows
Src=[Link]
Dest=Internet MPLS Packet
NAT Table
▪ PE-ASBR removes the label from the VRF IP Source Global IP VRF-Table-ID
received MPLS packets per LFIB [Link] [Link] Green
▪ Performs NAT on the resulting [Link] [Link] Blue
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
70
 Supported in IOS

IP/VPN Services:
5. VRF-Aware NAT Services: Internet Access Reference

• 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

[Link]
71
72

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
 Supported in IOS

MPLS based IP/VPN Service

6. VRF-Selection Reference

• 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

73
 Supported in IOS

MPLS based IP/VPN Service

6. VRF-Selection: Based on Source IP Address
VPN Brown
Global Interface RR VRF Interfaces [Link]/16

Ca PE1 MPLS Backbone PE2

[Link] ble (Cable Company) VPN Yellow
Set CE1 Se0/0 [Link]/16
up
[Link]
VPN Green
[Link] Traffic Flows [Link]/16
ip vrf red
interface Serial0/0 route-map PBR-VRF-Selection permit 10
rd 3000:111
ip address [Link] [Link] match ip address 40
route-target export 3000:1
ip policy route-map PBR-VRF-Selection set vrf red
route-target import 3000:1
ip vrf receive red !
!
ip vrf receive yellow route-map PBR-VRF-Selection permit 20
ip vrf yellow
ip vrf receive green match ip address 50
rd 3000:222
! set vrf yellow
route-target export 3000:2
access-list 40 permit [Link] [Link] !
route-target import 3000:2
access-list 50 permit [Link] [Link] route-map PBR-VRF-Selection permit 30
!
access-list 100 permit udp [Link] [Link] any match ip address 100
ip vrf green
dscp ef range 30000 31000 set vrf green
rd 3000:333
!
route-target export 3000:3
ip route vrf red [Link] [Link] Se0/0
route-target import 3000:3
ip route vrf yellow [Link] [Link] Se2/0
ip route vrf green [Link] [Link] Se2/0
74
75

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
 Supported in IOS

MPLS based IP/VPN Service

7. 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 based IP/VPN opens up new opportunities for providers
and VPN customers

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

76
 Supported in IOS

MPLS based IP/VPN Service

7. Remote Access Service: IPSec to MPLS VPN
Branch Access SP Shared Network Corporate Intranet
Office
SP AAA Customer
PE+IPSec AAA
SOHO
Aggregator
VPN A
Customer A
Internet
PE PE Head Office IKE_ID Is
IP/MPLS/Layer 2
Local or
Based Network
Used to Map
Direct the IPSec
Dial ISP Tunnel to
VPN B the VRF
PE (Within the
Cable/DSL/ Customer B ISAKMP
ISDN ISP
Profile)
VPN C
VPN A
Remote Users/
Telecommuters Cisco IOS VPN Routers or
Customer A Customer C
Cisco Client 3.x or Higher
Branch Office

IP IPSec Session MPLS VPN IP

77
78

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
 Supported in IOS,
NXOS, and IOS-XR

IP/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 TC/EXP bits (default behavior)
• MPLS Traffic-Eng could be used to provide the bandwidth-on-demand or Fast Rerouting (FRR) to VPN
customers

79
80

Agenda
• IP/VPN Overview
• IP/VPN Services
1. Load-Sharing for Multihomed VPN Sites
2. Hub and Spoke Service
3. Extranet Service
4. Internet Access Service
5. IP/VPN over IP Transport
6. IPv6 VPN Service
7. Multi-VRF CE Service
8. VRF-Aware NAT Services
9. VRF-Selection Based Services
10. Remote VPN Access Service
11. QoS Service
12. Multicast VPN Service
• Best Practices
• Conclusion
 Supported in IOS,
NXOS, and IOS-XR

IP/VPN Services:
9. Providing Multicast Service to VPNs

• Multicast VPN (mVPN) service is available for deployment

• MPLS Multicast (e.g. Label Switched Multicast) is now available
• GRE encapsulation for mVPN is also available
• Multicast VPN (mVPN) utilizes the existing 2547 infrastructure

81
82

Agenda
• IP/VPN Overview
• IP/VPN Services
• Best Practices
• Conclusion
Best Practices (1)
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.
Helpful to avoid add-path, shadow RR 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 VRF 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

83
Best Practices (2)
6. Limit number of prefixes per-VRF and/or per-neighbor on PE
Max-prefix within VRF configuration; Suppress the inactive routes
Max-prefix per neighbor (PE-CE) within OSPF/RIP/BGP VRF af
7. Leverage BGP Prefix Independent Convergence (PIC) for fast convergence <100ms (IPv4 and IPv6):
• PIC Core
• PIC Edge
• Best-external advertisement
• Next-hop tracking (ON by default)
8. Consider RT-constraint for Route-reflector scalability
9. Consider ‘BGP slow peer’ for PE or RR – faster BGP convergence

84
Agenda
• IP/VPN Overview
▪ IP/VPN Services
▪ Best Practices
▪ Conclusion
Conclusion
• MPLS based IP/VPN is the most optimal L3VPN technology
• Any-to-any IPv4 or IPv6 VPN topology
• Partial-mesh, Hub and Spoke topologies also possible

• Various IP/VPN services for additional value/revenue

• IP/VPN paves the way for virtualization & Cloud Services

• Benefits whether SP or Enterprise.

86