TECIPM3012

MPLS en Profundidad
La tecnología para redes de Nueva Generación

de Proveedores de Servicio y Corporativos
TECIPM-3012
Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Public 1
Goals of this Session
§ Multi Protocol Label Switching (MPLS) has been widely
adopted by the Network Operators to provide scalable
L2, L3 VPN, and Traffic Engineering services etc.
§ Enterprises are fast adopting this technology to
address network segmentation, traffic separation
needs and Data Center consolidation.
§ This session covers major MPLS technology
components, and most adopted MPLS application like
Traffic Engineering, Layer 2 and Layer3 VPN, which
are the most adopted MPLS application.
BRKRST-1101 © 2009 Cisco Systems, Inc. All rights reserved. Cisco Public 2
Speakers
§ Hernán Contreras G.
Consulting Systems Engineer
10-Year CCIE R &S, CCIP
Cisco Systems Chile
§ Marcelo Fernandez Y.
Network Consulting Engineer
CCIE SP and R&S, CCIP
Cisco Systems Chile
§ Bernard Wall R.
Network Consulting Engineer
CCIE SP and R&S, CCIP
Cisco Systems Chile
Agenda
§ Introduction
§ MPLS Network Components
§ MPLS QoS
§ MPLS Traffic Engineering
§ MPLS Layer 3 VPNs
§ MPLS Layer 2 VPN
§ High Availability
§ MPLS OAM
§ Summary
Introduction
The business drivers for MPLS
What Is MPLS Technology?
§ It’s all about labels …
§ Use the best of both worlds
Layer-2 (ATM/FR): efficient forwarding and traffic engineering
Layer-3 (IP): flexible and scalable
§ MPLS forwarding plane
Use of labels for forwarding Layer-2/3 data traffic
Labeled packets are being switched instead of routed
Leverage layer-2 forwarding efficiency
§ MPLS control/signaling plane
Use of existing IP control protocols extensions + new protocols
to exchange label information
Leverage layer-3 control protocol flexibility and scalability
Reference Slide: MPLS Transport and
Services
MPLS L3 VPN Service
Customer A Customer A
Site 1 Site 2
MPLS Core
CE CE
PE-PE LSPs
PWES PWES
PE PE
Pseudo Wires
Customer B Customer B
PSN Tunnel Site 2
Site 1
Emulated Service
MPLS Domain scope
IPv4 VPN
Mcast
CsC RSVP, QoS VPN
DS-TE
OAM Protect
IGP
+ FRR
LDP TE
IPv6 VPN
Inter-AS EoMPLS
VPLS
H-VPLS
Internet transport
MPLS - The Big Picture
End-to-end MPLSServices
End-to-end VPN Services
Layer-3 VPNs MPLS in Core Network Layer-2 VPNs

End-to-end MPLS-enabled
Services
Edge MPLS Network
MPLS NetworkServices
Core Core
Services Edge
Edge Edge
MPLS QoS MPLS TE MPLS OAM/MIBs

Layer-3 VPNs Layer-2 VPNs
MPLS Signaling and Forwarding
Edge Edge
Core MPLS
MPLS QoS MPLS TE MPLS OAM/MIBs
Edge Core Core Edge
Network
NetworkInfrastructure
Infrastructure
MPLS Technology Framework
§ End-to-end data connectivity services across MPLS
networks (from PE to PE)
End-to-end Services
IPv4 Multicast IPv6 E-LINE E-LAN ATM/FR
QoS TE/FRR HA OAM
Network Infrastructure
What Is a Virtual Private Network?
§ VPN is a set of sites or groups which are allowed to communicate
with each other in a secure way
Typically over a shared public or private network infrastructure
§ VPN is defined by a set of administrative policies
Policies established by VPN customers themselves (DIY)
Policies implemented by VPN service provider (managed/unmanaged)
§ Different inter-site connectivity schemes possible
Ranging from complete to partial mesh, hub-and-spoke
§ Sites may be either within the same or in different organizations
VPN can be either intranet or extranet
§ Site may be in more than one VPN
VPNs may overlap
§ Not all sites have to be connected to the same service provider
VPN can span multiple providers
MPLS VPN Options
MPLS VPN Models

• CPE connected to PE via IP-based connection
(over any layer-2 type)
Point-to-Point Multi-Point – Static routing
Layer-2 VPNs Layer-2 VPNs – PE-CE routing protocol; eBGP, OSPF, IS-IS
• CEs peer with PE router
• CPE connected to • CPE connected to
PE via p2p Layer-2 PE via Ethernet • PE routers maintain customer-specific routing
connection (FR, connection (VLAN) tables and exchange customer=specific routing
ATM) information
• CEs peer with each
• CEs peer with each other via • Layer-3 VPN provider’s PE routers are part of
other (IP routing) fully/partial mesh customer routing
via p2p layer-2 VPN Layer-2 VPN
connection connection
• CE-CE routing; no • CE-CE routing; no
SP involvement SP involvement
MPLS VPN Example
PE-CE PE-CE
Link Link
P P
CE PE PE CE
VPN
CE CE
PE P P PE
Label switched traffic
§ PE-CE link
Connect customer network to SP network; layer-2 or layer-3
§ VPN
Dedicated secure connectivity over shared infrastructure
Layer 3 and Layer 2 VPN Characteristics
LAYER 3 VPNs LAYER 2 VPNs
1. Packet based forwarding, e.g. IP 1. Frame Based forwarding e.g.
2. SP is involved DLCI,VLAN, VPI/VCI
3. IP specific 2. No SP involvement
4. Example: RFC 2547bis VPNs 3. Multiprotocol support
(L3 MPLS-VPN) 4. Example: FR—ATM—Ethernet
MPLS support both L3 and L2 VPN
Why Multi Protocol Label Switching?
§ SP/Carrier perspective
Reduce Costs (CAPEX & OPEX)
Consolidated network for multiple customers and Layer-2/3 services
Migrate legacy networks onto single converged network
Network optimization (QoS and TE)
Support increasingly stringent SLAs

Handle increasing scale/complexity of IP-based services
§ Enterprise/end-user perspective
Enables site/campus network segmentation
Allows for dedicated connectivity for users, applications, etc
Virtualization and consolidation of network Resources and Applications
Enables easier setup of Network connectivity

Easier and more flexible configuration of L2 and L3 site-to-site connectivity for
Campus and WAN
MPLS Customer Distribution
Cisco MPLS customer distribution
MPLS Customer Segments Geographic Customer Distribution

Japan
AsiaPac 2%
9%
Government
12%
Emerging European
Markets Markets
Service Provider 20% 42%
45%
Enterprise
43%
US and Canada
27%
Source: MPLS Tracker and various other internal Cisco databases, based on 2008 data.
Enterprise MPLS Customers
§ Two types of enterprise customers for MPLS
technology
§ MPLS indirectly used as subscribed WAN service
Enterprise subscribes to WAN connectivity data service offered
by external Service Provider
Data connectivity service implemented by Service Provider via
MPLS VPN technology (e.g., layer-2 and layer-3 VPNs)
VPN Service can be managed or unmanaged
§ MPLS used as part of self managed network

Enterprise deploys MPLS in it’s own network
Enterprise manages it’s own MPLS-based network
MPLS Enterprise Customer Segments
30
25 Financials, Transportation, and System

Integrators are currently biggest
% of Total MPLS Enterprise Customer Base
enterprise customer segments for MPLS

20
15
25
10 20
13 13
5 10
9
7
3 3 3
2 2
1 1 1 1 1
0
M
l
tai
y
IT
se
e
CR
are
erg
l
cia
te
t
g
Re
en
nc
l
tion
tica
r
fen
or
l
rin
era
rch
ide
na
t
an
En
hc
en
rnm
ura
rat
ctu
De
eu
rta
er
ov
ea
Fin
lom
alt
nm
eg
Ins
po
ac
Int
ve
ufa
Pr
He
es
Int
ng
tai
Go
ns
arm
/R
nt
an
ter
Co
m
Tra
nte
on
Ph
En
ste
ati
Co
ia/
Sy
uc
ed
Ed
M
Enterprise Customer Segments
Source: MPLS Tracker and various other internal Cisco databases, based on 2008 data.
Enterprise Network Virtualization
Multi-networks integration
• Virtualization: 1 to Many
• One network supports many virtual networks
Outsourced Merged New Segregated Department
IT Department Company (Regulatory Compliance)
Virtual Virtual Virtual
Actual Campus LAN
Data Center Virtualization
The Full-Service Network:
Integrated MPLS Technologies
Layer 3 Routing IP Services like NAT, Traffic Engineering for
Protocols Available on DHCP Can Be Bandwidth Protection
PE-CE—Static, RIP, Configured on per-VPN and Restoration
OSPF, EIGRP, eBGP Basis on the PE Router
CE Internet
Gateway Internet
IP/MPLS
PE Backbone
CE
CE PE
Legend
Layer 2 Circuits CE
QoS Mechanisms like Available—Ethernet,
Queuing and Policing
Layer 3 VPN
ATM, Frame Relay,
Are Configured at Layer 2 VPN
PPP, HDLC
CE and PE Routers Traffic Engineering
Layer 3 VPNs and Layer 2 VPNs, Traffic Engineering +

QoS + IP Services Can Coexist on a Single Infrastructure
MPLS Technology Components
Basic building blocks of MPLS
End-to-end Services
MPLS Network Services
MPLS QoS MPLS TE HA OAM
Core MPLS
MPLS Forwarding and Signaling
§ MPLS label forwarding and signaling mechanisms
Core MPLS
Basic Building Blocks
§ The big picture
MPLS-enabled network devices
Label Switched Paths (LSPs)
§ The internals
MPLS labels
Processing of MPLS labels
Exchange of label mapping information
Forwarding of labeled packets
§ Other related protocols and protocols to exchange

label information
Between MPLS-enabled devices
MPLS Network Overview
MPLS Domain
P P
CE PE PE CE
CE CE
PE P P PE
§ P (Provider) router = label switching router = core router (LSR)

Switches MPLS-labeled packets
§ PE (Provider Edge) router = edge router (LSR)
Imposes and removes MPLS labels
§ CE (Customer Edge) router
Connects customer network to MPLS network
MPLS Network Protocols
MP-iBGP
OSPF, IS-IS,
P EIGRP, EIGRP P
CE PE PE CE
LDP, RSVP
CE CE
PE P P PE
§ IGP: OSPF, EIGRP, IS-IS on core facing and core links

§ RSVP and/or LDP on core and/or core facing links
§ MP-iBGP on PE devices (for MPLS services)
MPLS Core Architecture Summary
1a. Existing Routing Protocols (e.g. OSPF, IS-IS)
Establish Reachability to Destination Networks
1b. LDP Establishes Label to Destination 4. Edge LSR at
Network Mappings Egress Removes
Label and Delivers
Packet
2. Ingress Edge LSR Receives Packet,

Performs Layer 2/3 Value-Added
Services, and “Labels” Packets 3. LSR Switches Packets
Using Label Swapping
MPLS Control and Forwarding Plane
§ MPLS control plane
Used for distributing labels Routing
and building label-switched RIB Routing Updates/
paths (LSPs) Process Adjacencies
Typically supported by LDP;

also supported via RSVP and
BGP Label Binding
LIB MPLS
Updates/
Labels define destination Process Adjacencies
and service
§ MPLS forwarding plane
Used for label imposition,
swapping, and disposition
Independent of type of control MFI FIB
plane
Labels separate forwarding MPLS Traffic IP Traffic
Forwarding Forwarding
from IP address-based routing
Label Distribution Protocol
§ MPLS nodes need to exchange label information with each other
Ingress PE node (Push operation)
Needs to know what label to use for a given FEC to send packet to neighbor
Core P node (Swap operation)
Needs to know what label to use for swap operation for incoming labeled packets
Egress PE node (Pop operation)
Needs to tell upstream neighbor what label to use for specific FEC type LDP used for
exchange of label (mapping) information
§ Label Distribution Protocol (LDP)

Defined in RFC 3035 and RFC3036; updated by RFC5036
LDP is a superset of the Cisco-specific Tag Distribution Protocol
§ Note that, in addition LDP, also other protocols are being used for
label information exchange
Will be discussed later
Some More LDP Details
§ Assigns, distributes, and installs (in forwarding) labels for prefixes
advertised by unicast routing protocols
OSPF, IS-IS, EIGRP, etc.
§ Also used for Pseudowire/PW (VC) signaling
Used for L2VPN control plane signaling
§ Uses UDP (port 646) for session discovery and TCP (port 646) for
exchange of LDP messages
§ LDP operations
LDP Peer Discovery
LDP Session Establishment
MPLS Label Allocation, Distribution, and Updating MPLS forwarding
§ Information repositories used by LDP
LIB: Label Information Database (read/write)
RIB: Routing Information Database/routing table (read-only)
LDP Operations
§ LDP startup
Local labels MPLS Node A MPLS Node B
LDP Control Plane
assigned to RIB
prefixes and stored Session Setup
RIB RIB
in LIB
LIB LIB
Peer discovery and Label Binding
Exchange
session setup
Exchange of MPLS
LDP Interactions
label bindings with
MPLS Forwarding
§ Programming of
MPLS forwarding MPLS MPLS
Forwarding Forwarding
CEF/MFI CEF/MFI
Based on LIB info
CEF/MFI updates
Frame-mode Label Distribution
Label bindings placed into the LIB
# sh mpls ldp bind 10.98.76.2 32

lib entry: 10.98.76.2/32, rev 92
local binding: label: 29
remote binding: lsr: 10.98.76.2:0, label: imp-null
remote binding: lsr: 10.98.76.3:0, label: 35
Only label from next-hop used for forwarding in the LFIB
# show mpls forwarding-table

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
29 Pop Label 10.98.76.2/32 0 Gi3/1/0 192.169.12.2
Forwarding Equivalence Class
§ Mechanism to map ingress layer-2/3 packets onto a Label
Switched Path (LSP) by ingress PE router
Part of label imposition (Push) operation
§ Variety of FEC mappings possible
IP prefix/host address
Groups of addresses/sites (VPN x)
Used for L3VPNs
Layer 2 circuit ID (ATM, FR, PPP, HDLC, Ethernet)
Used for Pseudowires (L2VPNs)
A bridge/switch instance (VSI)
Used for VPLS (L2VPNs)
Tunnel interface
Used for MPLS traffic engineering (TE)
MPLS Label Operations
Label Imposition (Push) Label Swap Label Swap Label Disposition (PoP)
L1 L1 L2 L2 L3 L3
L2/L3 Packet
P P
CE PE PE CE
CE CE
PE P P PE
§ Label imposition (Push)

By ingress PE router; classify and label packets
§ Label swapping or switching
By P router; forward packets using labels; indicates service class & destination
§ Label disposition (PoP)
By egress PE router; remove label and forward original packet to destination CE
MPLS Label and Label Encapsulation
MPLS Label
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Label # – 20bits EXP S TTL-8bits
COS/EXP = Class of Service: 3 Bits; S = Bottom of Stack; TTL = Time to Live
MPLS Label Encapsulation

PPP Header
PPP Header Label Layer 2/L3 Packet
(Packet over SONET/SDH)
One or More Labels Appended to the Packet
(Between L2/L3 packet header and link layer header)
LAN MAC Label Header MAC Header Label Layer 2/L3 Packet
The Label Stack
MPLS is recursive
In In Address Out Out

I/F Lab Prefix I/F Lab
0 Next-Hop
5171.68.10 1 7
... ... ... ... ...
171.68.10/24
Label = 5 Label = 7
Rtr-A
Label = 21 Label = 21
IP packet IP packet
D=171.68.10.12 D=171.68.10.12
§ Rtr-A forwards using the top-most label of the stack

§ Last label in the stack is marked with EOS bit
§ Allows building services such as
MPLS VPNs
Traffic Engineering and Fast Re-route
VPNs over Traffic Engineered core
Any Transport over MPLS
Label Stacking
§ More than one label can be used for MPLS packet encapsulation
Creation of a label stack
§ Recap: labels correspond to Forwarding Equivalence Class (FEC)
Each label in stack used for different purposes
§ Outer label always used for switching MPLS packets in network
§ Remaining inner labels used to specific services/FECs, etc.
§ Last label in stack marked with EOS bit
Outer Label
§ Allows building services such as
TE Label
MPLS VPNs; LDP + VPN label
LDP Label
Traffic engineering (FRR): LDP + TE label
VPN Label
VPNs over TE core: LDP + TE + VPN label Layer 2/3
Inner Label
Any transport over MPLS: LDP + PW label Packet Header
Summary Steps For MPLS Forwarding
§ Each node maintains IP routing information via IGP
IP routing table (RIB) and IP forwarding table (FIB)
§ LDP leverages IGP routing information

§ LDP label mapping exchange (between MPLS nodes)
takes place after IGP has converged
LDP depends on IGP convergence
Label binding information stored in LIB
§ Once LDP has received remote label binding

information MPLS forwarding is updated
Label bindings are received from remote LDP peers
MPLS forwarding via MFI
IP Packet Forwarding Example
FIB
FIB FIB Address
I/F
Prefix
Address Address
I/F I/F
Prefix Prefix 128.89 0
128.89 1 128.89 0 171.69 1
171.69 1 171.69 1 …
… …
128.89
0
0 128.89.25.4 Data
1 128.89.25.4 Data
1
128.89.25.4 Data 128.89.25.4 Data
171.69
Packets Forwarded
Based on IP Address
(via RIB lookup)
Step 1: IP Routing (IGP) Convergence
MFI/FIB MFI/FIB MFI/FIB
In Address Out Out In Address Out Out In Address Out Out
Label Prefix I’face Label Label Prefix I’face Label Label Prefix I’face Label
128.89 1 128.89 0 128.89 0
171.69 1 171.69 1
… … … … … …
0 128.89
0
1
You Can Reach 128.89 Thru Me

You Can Reach 128.89 and 1
171.69 Thru Me
Routing Updates
You Can Reach 171.69 Thru Me 171.69
(OSPF, EIGRP, …)
Step 2a: LDP Assigns Local Labels
- 128.89 1 4 128.89 0 9 128.89 0 -
- 171.69 1 5 171.69 1
… … … … … … … … … … … …
0 128.89
0
1
171.69
Step 2b: LDP Assigns Remote Labels
- 128.89 1 4 4 128.89 0 9 9 128.89 0 -
- 171.69 1 5 5 171.69 1 7
… … … … … … … … … … … …
0 128.89
0
1
Use Label 9 for 128.89

Use Label 4 for 128.89 and 1
Use Label 5 for 171.69
Label Distribution
Use Label 7 for 171.69 171.69
Protocol (LDP)
(Downstream Allocation)
Step 3: Forwarding MPLS Packets
- 128.89 1 4 4 128.89 0 9 9 128.89 0 -
- 171.69 1 5 5 171.69 1 7
… … … … … … … … … … … …
0 128.89
0
128.89.25.4 Data
1
9 128.89.25.4 Data
128.89.25.4 Data 4 128.89.25.4 Data 1
Label Switch Forwards

171.69
Based on Label
Penultimate Hop Popping
In Label FEC Out Label In Label FEC Out Label In Label FEC Out Label
- 197.26.15.1/32 28 28 197.26.15.1/32 POP - 197.26.15.1/32 -
197.26.15.1/32
London Brussels Paris

Use label 28 for destination Use label implicit-null for
197.26.15.1/32 destination 197.26.15.1/32
Paris# show mpls ldp binding 197.26.15.1

lib entry: 197.26.15.1/32, rev 10
local binding: label: imp-null(1)
Brussels# show mpls ldp binding 197.26.15.1

lib entry: 197.26.15.1/32, rev 10
local binding: label: 28
remote binding: lsr: 172.16.3.2:0, label: imp-null(1)
Brussels# show mpls forwarding

Local Outgoing Prefix Bytes Label Outgoing Next Hop
Label Label or VC or Tunnel Id Switched interface
28 Pop label 197.26.15.1/32 0 Gi0/0/2 point2point
May be disabled using explicit-null option

(Useful to maintain end-to-end label for QoS classification)
Understand MPLS phases
& Basic debugging
1. IP connectivity must be established èping ip

2. Broadcast Discovery neighbors protocol èsh mpls ldp disc
3. LDP session establish (TCP session 646) èsh mpls ldp neigh
4. Binding of full labels with all neighbors èsh mpls ldp bind
5. Select next-hop using routing table èsh ip cef
6. Selected Label for destination èsh mpls forwarding
7. CEF is the switching path èsh ip cef IP@ detail
8. Verify LSP èPing / traceroute mpls
9. End-to-End LSP (path & labels) èdebug mpls packet
10. LSR (P router) switching èping/traceroute mpls
Summary
§ MPLS uses labels to forward traffic
§ More than one label can be used for traffic
encapsulation; multiple labels make up a label stack
§ Traffic is encapsulated with label(s) at ingress and at
egress labels are removed in MPLS network
§ MPLS network consists of PE router at ingress/egress
and P routers in the core
§ MPLS control plane used for signaling label mapping
information to set up end-to-end Label Switched Paths
§ MPLS forwarding plane used for label imposition
(PUSH), swapping, and disposition (POP) operation
MPLS QoS
Technology Overview and Applications
§ MPLS QoS support for traffic marking and classification
to enable differentiated services
P MPLS Signaling and Forwarding
Why MPLS QoS?
§ Typically different traffic types (packets) sent over
MPLS networks
E.g., Web HTTP, VoIP, FTP, etc.
§ Not all application traffic types/flows are the same …

Some require low latency to work correctly; e.g., VoIP
§ MPLS QoS used for traffic prioritization to guarantee

minimal traffic loss and delay for high priority traffic
Involves packet classification and queuing
§ MPLS leverages mostly existing IP QoS architecture

Based on Differentiated Services (DiffServ) model; defines per-
hop behavior based on IP Type of Service (ToS) field
MPLS QoS Operations
§ MPLS EXP bits used for packet classification and
prioritization instead of IP Type of Service (ToS) field
DSCP values mapped into EXP bits at ingress PE router
§ Most providers provide 3–5 service classes
§ Different DSCP <-> EXP mapping schemes
Uniform mode, pipe mode, and short pipe mode
MPLS DiffServ Marking IP DiffServ Marking

in Experimental Bits
EXP DSCP
Layer-2 Header MPLS Header Layer 3 Header
QoS Enabled MPLS
Ingress Interior Egress

Node Node Node
TC PHB TC
PHB PHB
Enhanced QoS capabilities for packets in

Per-VPN QoS policies at the edge
MPLS core
Traffic Classification and Conditioning Per-Hop Behavior
Point-to-network guarantees
Enterprise-to-Service Provider Mapping
Five-Class Provider-Edge Model Remarking Diagram
Enterprise PE Classes
DSCP
Application
Routing CS6
Voice EF EF SP-Real Time
35%
Interactive Video AF41 è CS5 CS5
Streaming Video CS4 è AF21

CS6
Mission-Critical Data AF31 AF31 SP-Critical
20%
Call Signaling CS3 è CS5 CS3
Transactional Data AF21 è CS3 AF21 SP-Video

CS2 15%
Network Management CS2
AF11/CS1 SP-Bulk 5%
Bulk Data AF11
Scavenger CS1 è 0 SP-Best Effort
25%
Best Effort 0
MPLS DiffServ Tunneling Modes
RFC 3270
Uniform
Pipe
Short
Pipe
IP IP/MPLS IP
CE1 PE1 PE2 CE2
MPLS Uniform Mode DiffServ Tunneling
Uniform Mode Operation
Shaded Area Represents Customer/Provider DiffServ Domain

Assume a Policer Remarks Out-of-Contract
Traffic’s Top-Most Label to MPLS EXP 0 Here
CE Router PE Router MPLS VPN PE Router CE Router
P Routers
IPP3/DSCP AF31 MPLS EXP 3 MPLS EXP 0 MPLS EXP 0 IPP0/DSCP 0

Packet Initially MPLS EXP 3 MPLS EXP 3 IPP3/DSCP AF31 MPLS EXP Value
Marked to IPP3/ Is Copied to
DSCP AF31 IPP3/DSCP AF31 IPP3/DSCP AF31 Top-Most Label Is
IP ToS Byte
By Default IPP Top-Most Label Is Popped, and EXP
Values Will Be Marked down by Value Is Copied
Copied to MPLS a Policer to Underlying
EXP Labels Label
Direction of Packet Flow
MPLS Pipe Mode DiffServ Tunneling
Pipe Mode Operation
Shaded Area Represents Provider DiffServ Domain
Assume a Policer Remarks Unshaded Areas
Out-of-Contract Traffic’s Top- Represent Customer
Most Label to MPLS EXP 0 Here DiffServ Domain
PE Edge (to CE)

MPLS VPN Policies Are Based on
CE Router PE Router Provider Markings
P Routers
PE Router CE Router
MPLS EXP 0
IPP3/DSCP AF31 MPLS EXP 4 MPLS EXP 0 MPLS EXP 4 IPP3/DSCP AF31
Packet Initially MPLS EXP 4 MPLS EXP 4 IPP3/DSCP AF31 Original Customer-
Marked to IPP3/ Marked IP ToS
IPP3/DSCP AF31 IPP3/DSCP AF31 No Penultimate
DSCP AF31 Values Are
MPLS EXP Values Top-Most Label Is Hop Popping Preserved
Are Set Independently Marked down by (PHP)
from IPP/DSCP Values a Policer
Direction of Packet Flow

MPLS Short Pipe Mode
§ End-to-end behavior: original IP DSCP is preserved
At ingress PE, EXP value set based on ingress classification
EXP changed in the MPLS core
At egress PE, original IP DSCP value used for QoS processing
CE CE
PE P P PE
MPLS MPLS
EXP 3 EXP 2
MPLS MPLS MPLS
EXP 3 EXP 3 EXP 2
IP IP IP IP IP
DSCP DSCP DSCP DSCP DSCP
3 3 3 3 3
MPLS QoS Summary
§ MPLS QoS used for MPLS packet-specific marking
and classification
Based on EXP bits
§ Different schemes for mapping between IP

(ToS/DSCP) and MPLS packet (EXP) classification
At ingress and egress PE router
MPLS pipe mode mostly used; preserves end-to-end IP QoS
§ Enables traffic prioritization to guarantee minimal traffic

loss and delay for high priority traffic
Useful when packet loss and delay guarantees must be
provided for high priority traffic across MPLS network
MPLS Traffic Engineering
§ Traffic engineering capabilities for bandwidth
management and network failure protection
P MPLS QoS MPLS TE HA OAM
Traffic Engineering with MPLS
Utilizes the inherent capability of MPLS to base forwarding decisions on
criteria other than least-cost path determination
§ Path differs from normally Path Chosen by Path Specified by

routed path (IGP) IP Routing Protocol Traffic Engineering
(IGP Shortest) (constrained or explicit)
§ Traffic follows prespecified path
§ Why traffic engineer?
Optimize link utilization
Avoid congested links
Specific paths by
customer or class
Balance traffic load
Route around failed links/nodes
Capacity planning
The Problem with Shortest-Path
IP (Mostly) Uses Destination-Based Least-
Cost Routing Alternate Path Under Utilized
Node Next-Hop Cost § Some links are DS3, some are OC-3
B B 10
§ Router A has 40M of traffic for
C C 10
router F, 40M of traffic for router G
D C 20
E B 20 § Massive (44%) packet loss at router
F B 30 B? router E!
G B 30
Changing to A->C->D->E won’t help
Router B Router F
OC-3 OC-3
Router A Router E
DS3
Router G
OC-3
OC-3 DS3
Router C
DS3 Router D
How MPLS TE Solves the Problem
§ Router A sees all links
Node Next-Hop Cost § Router A computes paths on
B B 10 properties other than just
C C 10 shortest cost; creation of 2
D C 20 tunnels
E B 20
§ No link oversubscribed!
F Tunnel 0 30
G Tunnel 1 30
Router B Router F
OC-3 OC-3
Router A Router E
DS3
Router G
OC-3
OC-3 DS3
Router C
DS3 Router D
MPLS TE Overview
§ Introduces explicit routing

§ Supports constraint-
based routing IP/MPLS
§ Supports admission control
§ Provides protection capabilities
§ Uses RSVP-TE to
establish LSPs
§ Uses ISIS / OSPF extensions to
advertise
link attributes
TE LSP
How MPLS TE Works
§ Link information Distribution*
Head end ISIS-TE
OSPF-TE
IP/MPLS
§ Path Calculation (CSPF)*
§ Path Setup (RSVP-TE)
§ Forwarding Traffic
down Tunnel
Auto-route
Static
PBR
Mid-point Tail end CBTS / PBTS
TE LSP Forwarding Adjacency
Tunnel select
* Optional
For your
Link Information Distribution reference
only
§ Additional link characteristics

Interface address
IP/MPLS
Neighbor address
Physical bandwidth
Maximum reservable bandwidth
Unreserved bandwidth
(at eight priorities)
TE metric
Administrative group (attribute flags)
§ IS-IS or OSPF flood link

information
§ TE nodes build a topology TE
database Topology
database
§ Not required if using off-line path
computation
BRKRST-1101 http://www.cisco.com/go/mpls
© 2009 Cisco Systems, Inc. All rights reserved. Cisco Public 66
Path Calculation
Find shortest
path to R8
§ TE nodes can perform
with 8Mbps constraint-based routing
IP/MPLS
R1 § Constraints and topology
15 3
database as input to path
5
10
R8 computation
10
10 8 § Shortest-path-first algorithm
10
ignores links not meeting
constraints
§ Tunnel can be signaled once a
TE path is found
Topology
database § Not required if using offline
path computation
n Link with insufficient bandwidth

n Link with sufficient bandwidth
For your
TE LSP Signaling reference
only
§ Tunnel signaled with TE

extensions to RSVP
§ Soft state maintained with
downstream PATH messages Head end IP/MPLS
§ Soft state maintained with
upstream RESV messages
§ New RSVP objects
L=16
LABEL_REQUEST (PATH) RESV Tail end
LABEL (RESV)
PATH
EXPLICIT_ROUTE
RECORD_ROUTE (PATH/RESV)
Input Out Label,
SESSION_ATTRIBUTE (PATH) Label Interface
17 16, 0
§ LFIB populated using TE LSP
RSVP labels allocated by RESV
messages
Traffic Selection
§ Multiple traffic selection options

Head end
Auto-route
IP/MPLS Static routes
Policy Based Routing
Forward Adjacency
Pseudowire Tunnel Selection
Class / Policy Based Tunnel Selection
§ Tunnel path computation
independent of routing decision
injecting traffic into tunnel
TE LSP
§ Traffic enters tunnel
at head end
Autoroute
Node Next-Hop Cost
B B 10
C C 10
D C 20
Everything “behind” the
E B 20
tunnel is routed via the
F B 30
tunnel
G B 30
Tunnel1
H B 40
Tunnel1
I B 40 B
Tunnel1 F
A E H
Tunnel1 G
I
C D
Physical topology
BRKRST-1101
èSPF topology
© 2009 Cisco Systems, Inc. All rights reserved.
èAutoroute
Cisco Public 70
Forwarding Adjacency
interface tunnel xx
mpls traffic-eng forwarding-adjacency
isis metric <x> level-<y>
R9
R3
R4
R2
TE tunnels
with FA, R5
Load-balancing metric 10
between R2 and R6
R1
R1 sees two-equal R6 R7
cost paths to R9
R67 all links : metric 10
Configuring Tunnel at Head End
(Cisco IOS)
interface Tunnel1 Destination (tunnel
description FROM-ROUTER-TO-DST1
tail end)
ip unnumbered Loopback0 TE tunnel (as
tunnel destination 172.16.255.3 opposed to GRE or
tunnel mode mpls traffic-eng others)
tunnel mpls traffic-eng priority 5 5
tunnel mpls traffic-eng bandwidth 10000 Setup/hold
tunnel mpls traffic-eng affinity 0x0 mask 0xF priorities
tunnel mpls traffic-eng path-option 5 explicit name PATH1 Signaled
tunnel mpls traffic-eng path-option 10 dynamic bandwidth
!
ip explicit-path name PATH1 enable Consider links with
next-address 172.16.0.1 0x0/0xF as
next-address 172.16.8.0 attribute flags
! Tunnel path
options (PATH1,
otherwise dynamic)
Explicit PATH1
definition
Configuring Tunnel at Head End
(Cisco IOS XR)
explicit-path name PATH1 Explicit PATH1
index 1 next-address ipv4 unicast 172.16.0.4
definition
index 2 next-address ipv4 unicast 172.16.0.7 MPLS TE P2P
index 3 next-address ipv4 unicast 172.16.4.2 tunnel
!
interface tunnel-te1 Setup/hold
priorities
description FROM-ROUTER-TO-DST1
ipv4 unnumbered Loopback0 Signaled
priority 5 5 bandwidth
signalled-bandwidth 100000
destination 172.16.255.2 Destination (tunnel
path-option 10 explicit name PATH1 tail end)
path-option 20 dynamic
Tunnel path
affinity f mask f
options (PATH1,
! otherwise dynamic)
Consider links with

0xF/0xF as
attribute flags
Configuring MPLS TE and Link Information
Distribution Using IS-IS (Cisco IOS)
mpls traffic-eng tunnels Enable MPLS TE on this
! node
interface POS0/1/0
ip address 172.16.0.0 255.255.255.254 Enable MPLS TE on this
ip router isis interface
mpls traffic-eng tunnels
Attribute flags
mpls traffic-eng attribute-flags 0xF
mpls traffic-eng administrative-weight 20 TE metric
ip rsvp bandwidth 100000
! Maximum reservable
router isis bandwidth
net 49.0001.1720.1625.5001.00
is-type level-2-only
Enable wide metric format
metric-style wide and TE extensions (TE Id,
mpls traffic-eng router-id Loopback0 router level)
mpls traffic-eng level-2
passive-interface Loopback0
!
Configuring MPLS TE and Link Information
Distribution Using OSPF (Cisco IOS XR)
router ospf DEFAULT Enable TE extensions on
this area
area 0
mpls traffic-eng
TE router Id
interface Loopback0
passive
!
Configuration mode for
RSVP global and interface
interface POS0/3/0/0 commands
!
mpls traffic-eng router-id Loopback0
Maximum reservable
!
bandwidth
rsvp
interface POS0/3/0/0
bandwidth 100000
Configuration mode for
MPLS TE global and
!
interface commands
!
mpls traffic-eng
TE metric
admin-weight 5
attribute-flags 0x8 Attribute flags
!
!
MPLS TE Integration with Network Services
A TE LSP provides transport for network services
PE PE CE
CE ATM ATM
CE CE
IP/MPLS
PE PE
Frame
CE Ethernet
Relay CE
CE
PE
CE CE
PE PE
CE Ethernet Ethernet CE
TE LSP with IP (VPN)

Low-Latency, BW L2VPN
Reserved BW Service
Protected TE LSP (Pseudowire)
Per VPN Traffic-Engineering
VPNV4:
If RT=Green then Force NH=Green
VPN Site
VPN Site
Ip route NH=Green
to TE_Green
VPN Site
VPN Site
It is just a question of BGP !
Per VPN TE
Or even inside VPN TE
And in addition:
One one side:
ip vrf green
address-family vpnv4
rd 10:2
neighbor 1.1.12.1 activate
export map Set_RT70
neighbor 1.1.12.1 send-community extended
route-target both 10:2
neighbor 1.1.12.1 route-map set-pref-nh out
!
access-list 1 permit 100.10.2.12
ip extcommunity-list 70 permit rt:10:70
!
route-map set-pref-nh permit 10
route-map Set_RT70 permit 10
match extcommunity 70
match ip address 1
set ip next-hop 10.52.52.52
set extcommunity rt:10:70 additive
« Or even per Subnet into the VRF »

On the other side: Could also use PBR
ip route 10.52.52.52 255.255.255.255 Tunnel70 VPN selection !
MPLS TE Deployment Models
Bandwidth Optimization Tactical
Strategic
R1 IP/MPLS R1 IP/MPLS
R8 R8
R2 R2
Protection Point-to-Point SLA

R8 R8
R2 R2
Strategic Bandwidth Optimization
Physical Topology Tunnel mesh to satisfy

Traffic Matrix traffic matrix
R1 R6 R1 R6
R1 R2 R3 R4 R5 R6
R1 4 7 1 5 4 5
R2 2 2 4 7 2 3 R2 R5 R2 R5
R3 1 2 9 5 5 5
R4 9 1 4 1 3 1
R5 3 7 9 2 7 7
R6 6 3 5 4 9 12
R3 R4 R3 R4
§ Tries to optimize underlying physical topology based on traffic matrix

§ Key goal is to avoid link over/under utilization
§ On-line (CSPF) or off-line path computation
§ May result in a significant number of tunnels
§ Should not increase your routing adjacencies
Traffic Matrix Measurement
Measuring Internal and External Traffic Matrix
§ Unconstrained tunnels
§ Interface MIB AS65001 AS65002 AS65003
§ MPLS LSR MIB

§ NetFlow
NetFlow BGP Next Hop PE PE
P P
MPLS-Aware NetFlow
PE PE
Egress/Output NetFlow
§ BGP policy accounting PE P P PE
Communities
POP POP
AS path
IP prefix Server Server
Farm Farm
Auto Bandwidth
Total Bandwidth
bandwidth available to
for all TE other tunnels
tunnels Max
on a path
Min
Tunnel
resized to
measured rate
Time
§ Dynamically adjust bandwidth reservation based on measured

traffic
§ Optional minimum and maximum limits
§ Sampling and resizing timers
§ Tunnel resized to largest sample since last adjustment
AutoTunnel Mesh
New mesh
§ Mesh group: LSRs to mesh group
automatically member
§ Membership identified by
Matching TE Router ID
against ACL
New mesh
IGP mesh-group group
advertisement member
§ Each member automatically
creates tunnel upon
detection of a member
§ Tunnels instantiated from
template
§ Individual tunnels not
displayed in router
configuration
Configuring AutoTunnel Mesh
(Cisco IOS)
mpls traffic-eng tunnels Enable Auto-tunnel Mesh
mpls traffic-eng auto-tunnel mesh
!
Tunnel template
interface Auto-Template1
ip unnumbered Loopback0 Template cloned for each
tunnel destination mesh-group 10 member of mesh group 10
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
Dynamic (CSPF) path to
tunnel mpls traffic-eng path-option 10 dynamic
each mesh group member
tunnel mpls traffic-eng auto-bw frequency 3600
!
router ospf 16 Tunnels will adjust
log-adjacency-changes bandwidth reservation
mpls traffic-eng router-id Loopback0 automatically
mpls traffic-eng area 0
mpls traffic-eng mesh-group 10 Loopback0 area 0 Advertise mesh group 10
passive-interface Loopback0 membership in area 0
network 172.16.0.0 0.0.255.255 area 0
!
Tactical Bandwidth Optimization
Strategic
R8 R8
R2 R2
§ Selective deployment of tunnels when highly-utilized

links are identified
§ Generally, deployed until next upgrade cycle alleviates
affected links
Tactical TE Deployment
Requirement: Need to Handle Scattered Congestion Points in the Network

Solution: Deploy MPLS TE on Only Those Nodes that Face Congestion
MPLS Traffic Engineering Bulk of Traffic Flow

Tunnel Relieves Congestion Points e.g. Internet Download
Internet
Service Provider
Backbone
Oversubscribed
Shortest Links
Strategic
R8 R8
R2 R2

R8 R8
R2 R2
Traffic Protection Using MPLS TE Fast
Re-Route (FRR)
§ Subsecond recovery against

node/link failures
IP/MPLS
R1 § Scalable 1:N protection
R8
§ Greater protection granularity
R2
§ Cost-effective alternative to
1:1 protection
§ Bandwidth protection
Primary TE LSP
Backup TE LSP
FRR Link Protection Operation
§ Requires next-hop (NHOP)

backup tunnel IP/MPLS
§ Point of Local Repair (PLR) R3
25
swaps label and pushes 22 22
backup label
R1 R2 R6 R7
§ Backup terminates
on Merge Point (MP) where
traffic rejoins primary 16 22
§ Restoration time expected

under
R5
~50 ms
Primary TE LSP
Backup TE LSP
FRR Node Protection Operation
§ Requires next-next-hop
(NNHOP) backup tunnel IP/MPLS
§ Point of Local Repair (PLR) R3
25
swaps next-hop label and 36 36
pushes
backup label R1 R2 R4 R6 R7
§ Backup terminates on
Merge Point (MP) where 16 22 36
traffic rejoins primary
§ Restoration time depends
R5
on failure detection time
Primary TE LSP
Backup TE LSP
Link Protection Example
Primary Path Pop

R8 R9
R2 14 R3 Tail End for
Primary Path
37
Protected Link
Fast Reroute Path Pop
R1 17 R5
Headend For R6 R7
Primary Path 22
Primary Path: R1 è R2 è R3 è R9
Fast Reroute Path: R2 è R6 è R7 è R3
Normal TE Operation
Pop 14
R8 Swap 37 with 14
R9
R
R2 R3
3
Push 37
R1 R5
R6 R7
IP 14
37
Fast Reroute Link Failure
Pop 14
R8 Swap 37 with 14
R9
R2 R3
Push 37
R1 R5
Push 17 Pop 22
R6 R7
Swap 17 with 22
IP 14 17
37 22
Configuring FRR (Cisco IOS)
Primary Tunnel
interface Tunnel1
description FROM-ROUTER-TO-DST1-FRR
ip unnumbered Loopback0
tunnel destination 172.16.255.2
tunnel mpls traffic-eng bandwidth 20000
tunnel mpls traffic-eng path-option 10 dynamic Indicate the desire for
tunnel mpls traffic-eng fast-reroute
! local protection during
signaling
Backup Tunnel
interface Tunnel1 Explicitly routed backup
description NNHOP-BACKUP
to 172.16.255.2 with
tunnel destination 172.16.255.2 zero bandwidth
tunnel mpls traffic-eng path-option 10 explicit name PATH1
!
interface POS1/0/0
ip address 172.16.192.5 255.255.255.254 Use Tunnel1 as backup
mpls traffic-eng tunnels for protected LSPs
mpls traffic-eng backup-path Tunnel1 through POS1/0/0
ip rsvp bandwidth
!
Define a Backup TE Tunnel
hostname [P1]
!
interface Tunnel1 Destination ( P2)
description P1-P3-P2-BACKUP
no ip directed-broadcast Use Path EXPL-
tunnel destination 172.16.255.130 P1-TO-P2 to
tunnel mpls traffic-eng path-option 10 explicit name EXPL-P1-TO-P2
Reach NHOP
!
interface Serial2/0 Tunnel1 as
mpls traffic-eng backup-path Tunnel1
!
Backup for
ip explicit-path name EXPL-P1-TO-P2 enable Failures on
next-address 172.16.0.2 Serial2/0
next-address 172.16.0.6
!
Path with
Explicit Hops
3-4
Configuring FRR (Cisco IOS XR)
Primary Tunnel
interface tunnel-te1
description FROM-ROUTER-TO-DST1-FRR
ipv4 unnumbered Loopback0
destination 172.16.255.2
fast-reroute
path-option 10 dynamic Indicate the desire for local
! protection during signaling
Backup Tunnel
interface tunnel-te1 Explicitly routed backup to
description NHOP-BACKUP 172.16.255.130 with zero
bandwidth
path-option 10 explicit name PATH1
!
mpls traffic-eng
backup-path tunnel-te 1 Use tunnel-te1 as backup
! for protected LSPs through
! POS0/3/0/0
Bidirectional Forwarding Detection Trigger for
FRR
§ FRR relies on quick

IP/MPLS
PLR failure detection R1
§ Some failures may not R8

produce loss of signal
R2
or alarms on a link
§ BFD provides light-
weight neighbor
connectivity failure
detection BFD session
Primary TE LSP
Backup TE LSP
BFD-Triggered TE Fast Re-Route (FRR)
§ Use of BFD for failure detection of protected links,
triggering switchover to MPLS TE backup path
1. P1-P2 link failure 4. Tunnel Head End (HE) computes and

signals new LSP path
2. Point of Local Repair (PLR) gets notified by
BFD and will start to forward packets into 5. Head-End starts forwarding traffic
Backup Tunnel and signals PathErr onto newly signaled path and tears
message to TE Headend down original path (make-before-break)
3. Merge Point merges traffic from backup
TE tunnel onto tailend of primary tunnel
P3 New Primary Tunnel
HE
PLR MP
PathErr
PE1 P1 P2 PE2
Primary Tunnel
BFD session Primary TE Tunnel: PE1 -> P1 -> P2 -> PE2 Protected Link: P1 – P2
Bandwidth Protection
§ Backup tunnel with
associated bandwidth
capacity IP/MPLS
§ Backup tunnel may or may R3
not actually signal
bandwidth
R1 R2 R4 R6 R7
§ PLR will decide best
backup to protect primary
(nhop/nnhop, backup-bw,
class-type, node-protection
flag)
R5
Primary TE LSP
Backup TE LSP
AutoTunnel: Primary Tunnels
What’s the Problem?
§ FRR can protect
TE Traffic IP/MPLS
R1
§ No protection mechanism
for IP or LDP traffic R8
R2
§ How to leverage FRR
for all traffic?
§ What if protection
desired without traffic
engineering?
Primary TE LSP
Backup TE LSP
Why One-Hop Tunnels?
§ CSPF and SPF yield same
results (absence
of tunnel constraints) IP/MPLS
R1
§ Auto-route forwards
all traffic through R8
one-hop tunnel
R2
§ Traffic logically mapped to
tunnel but no label imposed
(imp-null)
§ traffic is forwarded
as if no tunnel was
in place
Primary TE LSP
What’s the Solution?
Forward all traffic through a one-
hop protected primary TE tunnel
§ Create protected one-hop tunnels
IP/MPLS on all TE links
R1
Priority 7/7
Bandwidth 0
R8
Affinity 0x0/0xFFFF
R2 Auto-BW OFF
Auto-Route ON
Fast-Reroute ON
Forwarding-Adj OFF
Load-Sharing OFF
§ Tunnel interfaces not shown on
router configuration
Primary TE LSP
§ Configure desired backup tunnels
(manually or automatically)
Configuring AutoTunnel Primary
Tunnels (Cisco IOS)
mpls traffic-eng tunnels Enable auto-tunnel

mpls traffic-eng auto-tunnel primary onehop primary
mpls traffic-eng auto-tunnel primary tunnel-num min 900 max 999
!
Range for tunnel
interfaces
AutoTunnel: Backup Tunnels
What’s the Problem?
§ MPLS FRR requires
backup tunnels to be
preconfigured IP/MPLS
R1
§ Automation of backup R8
tunnels is desirable
R2
Primary TE LSP
Backup TE LSP
AutoTunnel: Backup Tunnels
What’s the Solution?
Create backup tunnels
automatically as needed
IP/MPLS § Detect if a primary tunnel requires
R1
protection and is not protected
R8 § Verify that a backup tunnel
doesn’t already exist
R2
§ Compute a backup path to NHOP
and NNHOP excluding the
protected facility
§ Optionally, consider shared risk
link groups during backup path
computation
Primary TE LSP
Backup TE LSP
§ Signal the backup tunnels
Configuring AutoTunnel Backup Tunnels
(Cisco IOS)
mpls traffic-eng tunnels Enable auto-tunnel

mpls traffic-eng auto-tunnel backup nhop-only backup (NHOP
mpls traffic-eng auto-tunnel backup tunnel-num min 1900 max 1999 tunnels only)
mpls traffic-eng auto-tunnel backup timers removal unused 7200
mpls traffic-eng auto-tunnel backup srlg exclude preferred
! Range for tunnel
interfaces
Tear down unused

backup tunnels
Consider SRLGs
preferably
What About Path Protection?
§ Primary and backup
share head and tail,
but diversely routed IP/MPLS
R1
§ Expected to result in R8
higher restoration
R2
times compared to
local protection
§ Doubles number of
TE LSPs (1:1
protection)
Primary TE LSP
§ May be an acceptable
Backup TE LSP
solution for restricted
topologies (e.g. rings)
Configuring Enhanced Path Protection
(Cisco IOS)
mpls traffic-eng path-option list name PATH-LST List of backup
path-option 10 explicit name PE1-P3-P4-PE2 paths
path-option 20 explicit name PE1-P5-P6-PE2
path-option 30 explicit name PE1-P7-P8-PE2
!
interface Tunnel1
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng path-option 10 explicit name PE1-P1-P2-PE2
tunnel mpls traffic-eng path-option protect 10 list name PATH-LST
! Use path list to
protect primary
path
Shared Risk Link Group (SRLG)
Layer-3 Plus
Layer-3 Topology
Physical Topology
SRLG 10
IP/MPLS R2-R4
IP/MPLS
R2-R3
R2 R4 R2 R4
R1 R5 R1 R5 SRLG 20
R4-R2
R4-R3
R3 R3
SRLG 30
R3-R2
R3-R4
§ Some links may share same physical resource (e.g. fiber, conduit)
§ AutoTunnel Backup can force or prefer exclusion of SRLG
to guarantee diversely routed backup tunnels
§ IS-IS and OSPF flood SRLG membership as an additional
link attribute
Configuring SRLG (Cisco IOS)
mpls traffic-eng tunnels Force SRLG

mpls traffic-eng auto-tunnel backup nhop-only exclusion during
mpls traffic-eng auto-tunnel backup srlg exclude force backup path
! computation
interface POS0/1/0
ip address 172.16.0.0 255.255.255.254
mpls traffic-eng srlg 15
mpls traffic-eng srlg 25 Interface member
ip rsvp bandwidth of SRLG 15 and
! 25
interface POS1/0/0
ip address 172.16.0.2 255.255.255.254
mpls traffic-eng srlg 25
ip rsvp bandwidth Interface member
! of SRLG 25
QoS and TE
Strategic
R8 R8
R2 R2

R8 R8
R2 R2
Motivations
§ Point-to-point SLAs
§ Admission control
PE1 IP/MPLS
§ Integration with DiffServ
PE3 § Increased routing control
PE2 to improve network
performance
Network with MPLS TE
Service
Differentiation § A solution when:
No differentiation required
Optimization required
§ Full mesh or selective
deployment to avoid
over-subscription
TE § Increased network utilization
Resource
§ Adjust link load to actual
Optimization link capacity
§ No notion of traffic classes
Load Capacity
Network with MPLS DiffServ
and MPLS TE
Service
Differentiation required
DiffServ Optimization required
+
TE
§ Adjust class capacity
to expected class load
§ Adjust class load to actual
class capacity for one class
Resource § Alternatively, adjust
Optimization
link load to actual
Class2
link capacity
Load Capacity
Class1
Load Capacity
Load Capacity
Class3
Network with MPLS DiffServ
and MPLS DS-TE
Service
DiffServ
+ Strong differentiation required
DS-TE
Fine optimization required
§ Control both load and
capacity per class
§ Adjust class capacity to
expected class load
Resource § Adjust class load to actual
Optimization
class capacity
Class2
Load Capacity
Class1
Load Capacity
Load Capacity
Class3
DiffServ-Aware Traffic Engineering
§ Enables per-class traffic

engineering
PE1 IP/MPLS
§ IS-IS or OSPF flood link information
(as usual)
PE3 § Per-class unreserved bandwidth on
each link
PE2
§ New RSVP object (CLASSTYPE)
§ Nodes manages link bandwidth
using a bandwidth constraint model
§ Two models defined
Maximum Allocation Model (MAM)
Russian Doll Model (RDM)
§ Unique class definition and
constraint model throughout
network
Bandwidth Constraints § Two classes (class-types) in current
Class-type 1 (voice) 20% implementations
Class-type 2 (video) 40%
What Is New in IETF DS-TE
Implementation?
§ Supports both RDM and MAM (Maximum Allocation
Model) for bandwidth constraints
§ New CLASSTYPE object in RSVP-TE to signal desired
class-type (unused by “class-type 0” for backward
compatibility with non-DS-TE)
§ Minor Changes to OSPF-TE and ISIS-TE bandwidth
advertisements
Same “unreserved bandwidth” sub-TLV (8 entries)
as non-DS-TE interpreted according to local definition
of TE-Class (class-type/preemption priority)
New BC sub-TLV
§ Operates in migration or IETF mode in Cisco IOS
§ Developed simultaneously for IOS and IOS XR
DiffServ Trafic-Engineering (DS-TE)
IETF allocation models
§ BW pool applies to
BC0
one class Class0
§ Sum of BW pools may exceed MRB BC1 Class1 All

Maximum
Reservable
Classes Bandwidth
§ Sum of total reserved BW may not (MRB)
exceed MRB BC2

Class2
§ Current implementation supports

BC0 and BC1 Maximum Allocation Model (MAM)
§ BW pool applies to one or more

classes BC0
All
Classes
§ Global BW pool (BC0) equals MRB (Class0

+
Maximum
Reservable
Class1 Bandwidth
BC1 +
§ BC0..BCn used for computing Class1
+
Class2) (MRB)
unreserved BW for class n BC2 Class2

Class2
§ Current implementation supports

BC0 and BC1 Russian Dolls Model (RDM)
MAM vs. RDM
MAM RDM
One BC per CT One or more CTs per BC
Sum of all BCs may exceed maximum BC0 always equals to maximum
reservable bandwidth reservable bandwidth
Preemption not required to provide Preemption required to provide bandwidth
bandwidth guarantees per CT guarantees per CT
Bandwidth efficiency and protection Provides bandwidth efficiency and

against QoS degradation are mutually protection against QoS degradation
exclusive simultaneously
Configuring DS-TE Classes and
Bandwidth Constraints (Cisco IOS)
RDM
mpls traffic-eng tunnels Enable IETF DS-
mpls traffic-eng ds-te mode ietf TE
mpls traffic-eng ds-te te-classes
te-class 0 class-type 1 priority 0
te-class 2 class-type 1 priority 2 Explicit TE-Class
te-class 3 class-type 1 priority 3 definition
te-class 6 class-type 0 priority 6 RDM bandwidth
te-class 7 class-type 0 priority 7 constraints
!
interface POS0/1/0
ip address 172.16.0.0 255.255.255.254
mpls traffic-eng tunnels Enable IETF DS-
ip rsvp bandwidth rdm bc0 155000 bc1 55000
! TE and use default
TE-Class definition
MAM
mpls traffic-eng ds-te mode ietf Enable MAM
mpl traffic-eng ds-te bc-model mam
!
interface POS0/1/0 MAM bandwidth
ip address 172.16.0.0 255.255.255.254 constraints
ip rsvp bandwidth mam max-reservable-bw 155000 bc0 100000 bc1 55000
!
Configuring DS-TE Classes and
Bandwidth Constraints (Cisco IOS XR)
RDM
rsvp
bandwidth rdm bc0 155000 bc1 55000 RDM bandwidth
! constraints
mpls traffic-eng
!
ds-te mode ietf
ds-te te-classes Enable IETF DS-
te-class 0 class-type 1 priority 0 TE
te-class 3 class-type 1 priority 3 Explicit TE-Class
te-class 4 class-type 0 priority 4 definition
te-class 7 class-type 0 priority 7 MAM bandwidth
!
constraints
MAM
rsvp
bandwidth mam max-reservable-bw 155000 bc0 100000 bc1 55000 Enable IETF DS-
! TE and use default
!
mpls traffic-eng
TE-Class definition
!
ds-te mode ietf
ds-te bc-model mam
Enable MAM
!
TE-Class Definition Examples
TE-Class definition MUST be consistent throughout the network
Default TE-Class definition
Priority 0 Priority 1 Priority 2 Priority 3 Priority 4 Priority 5 Priority 6 Priority 7
CT0 (Global) TE-Class4 TE-Class0
CT1 (Sub) TE-Class5 TE-Class1
TE-Class definition compatible with non-DS-TE

CT0 (Global) TE-Class0 TE-Class1 TE-Class2 TE-Class3 TE-Class4 TE-Class5 TE-Class5 TE-Class7
CT1 (Sub)
User-defined TE-Classes with no preemption between class-types

CT0 (Global) TE-Class4 TE-Class5 TE-Class6 TE-Class7
CT1 (Sub) TE-Class0 TE-Class1 TE-Class2 TE-Class3
User-defined TE-Classes with preemption between/within class-types

CT0 (Global) TE-Class1 TE-Class3 TE-Class5 TE-Class7
CT1 (Sub) TE-Class0 TE-Class2 TE-Class4 TE-Class6
Configuring DS-TE Tunnel (Cisco IOS)
interface Tunnel1 Signal Tunnel1

description FROM-ROUTER-TO-DST1-CT0 with CT0 (priority
ip unnumbered Loopback0 and CT must
no ip directed-broadcast
tunnel destination 172.16.255.3 match valid TE-
tunnel mode mpls traffic-eng Class)
tunnel mpls traffic-eng bandwidth 100000 class-type 0
!
interface Tunnel2
description FROM-ROUTER-TO-DST1-CT1
no ip directed-broadcast
tunnel destination 172.16.255.3 Signal Tunnel2
tunnel mode mpls traffic-eng with CT1 (priority
tunnel mpls traffic-eng bandwidth 50000 class-type 1 and CT must
tunnel mpls traffic-eng path-option 10 dynamic match valid TE-
! Class)
Configuring DS-TE Tunnels
(Cisco IOS XR)
interface tunnel-te1 Signal tunnel-te1
with CT0 (priority
priority 5 5 and CT must
signalled-bandwidth 100000 class-type 0 match valid TE-
destination 172.16.255.2 Class)
!
interface tunnel-te2
priority 0 0 Signal tunnel-te2
signalled-bandwidth 50000 class-type 1 with CT1 (priority
destination 172.16.255.2 and CT must
! match valid TE-
Class)
Class-Based Tunnel Selection: CBTS
Tunnel1 § EXP-based selection between

Tunnel10 Prefix1
Tunnel2 multiple tunnels to same destination
Tunnel3 § Local mechanism at
Tunnel4 Tunnel20 Prefix2 head-end (no IGP extensions)
Tunnel5
§ Tunnel master bundles tunnel
Tunnel6 members
Tunnel30 Prefix3
Tunnel7
§ Tunnel selection configured on
tunnel master (auto-route, etc.)
FIB
Prefix1 Tunnel10
Tunnel Bundle § Bundle members configured with
Prefix2 Tunnel20
EXP values to carry
Prefix3 Tunnel30 § Bundle members may be
configured as default
Master (Tunnel10) § Supports VRF traffic,
IP-to-MPLS and MPLS-to-MPLS
Member (Tunnel1) switching paths
Member (Tunnel2)
Configuring CBTS (Cisco IOS)
interface Tunnel1 Tunnel1 will carry
ip unnumbered Loopback0 packets with MPLS
tunnel destination 172.16.255.2 EXP 5
tunnel mpls traffic-eng exp 5 Tunnel2 will carry
! packets with MPLS
interface Tunnel2
ip unnumbered Loopback0 EXP other than 5
tunnel mpls traffic-eng exp default Tunnel10 defined as
! bundle master with
interface Tunnel10 Tunnel2 and Tunnel1
tunnel destination 172.16.255.2 as members
tunnel mpls traffic-eng exp-bundle master
tunnel mpls traffic-eng exp-bundle member Tunnel1
tunnel mpls traffic-eng exp-bundle member Tunnel2
!
ip route 192.168.0.0 255.255.255.0 Tunnel10 CBTS performed on
! prefix 192.168.0.0/24
using Tunnel10
Policy-based Tunnel Selection: PBTS
Tunnel1 § EXP-based selection between

Tunnel2
Prefix1
multiple tunnels to same destination
Tunnel3 § Local mechanism at
Tunnel4 Prefix2 head-end
Tunnel5
§ Tunnels configured via policy-
Tunnel6 class with one EXP value to carry
Tunnel7 Prefix3
§ Tunnel without policy-class
acts as default
FIB
Prefix1, exp 5 tunnel-te1 § No IGP extensions
Prefix1, * tunnel-te2
§ Supports VRF traffic,
Prefix2, exp 5 tunnel-te3
IP-to-MPLS and MPLS-to-MPLS
Prefix2, exp 2 tunnel-te4 switching
Prefix3, exp 5 tunnel-te6
Configuring PBTS (Cisco IOS XR)
interface tunnel-te1 tunnel-te1 will carry
ipv4 unnumbered Loopback0 packets with MPLS
autoroute announce EXP 5
policy-class 5
path-option 10 explicit name PATH1 tunnel-te2 will carry
path-option 20 dynamic packets with MPLS
! EXP other than 5
interface tunnel-te2 (default tunnel)
autoroute announce
path-option 10 explicit name PATH2
!
Tunnel-based Admission Control
IP/MPLS
IP IP
RSVPoDiffServ RSVPoDiffServ
Tunnel
RSVP flows (IPv4)
Aggregation / Aggregation /
De-aggregation De-aggregation
§ Tunnel aggregates RSVP (IPv4) flows

§ No per-flow state in forwarding plane (only DiffServ)
§ No per-flow state in control plane within MPLS TE network
§ RSVP enhancements enable end-to-end admission control solution
(Receiver Proxy, Sender Notification, Fast Local Repair)
Configuring Tunnel-based Admission Control
(Cisco IOS)
interface Tunnel1 Signaled bandwidth
tunnel destination 172.16.255.2 RSVP local policy (200
tunnel mode mpls traffic-eng flows max, 1Mbps per flow
tunnel mpls traffic-eng autoroute announce max)
tunnel mpls traffic-eng bandwidth 100000 Maximum reservable
tunnel mpls traffic-eng path-option 10 dynamic bandwidth
ip rsvp policy local default
maximum senders 200 Interface QoS policy
maximum bandwidth single 1000 (DiffServ)
forward all
ip rsvp bandwidth 100000 Maximum reservable
! bandwidth
interface GigabitEthernet3/3/0
ip address 192.168.0.1 255.255.255.254 Act as RSVP receiver
service-policy output OUT-POLICY proxy on this interface
ip rsvp bandwidth percent 10
ip rsvp listener outbound reply No RSVP flow
ip rsvp data-packet classification none classification
ip rsvp resource-provider none
! No RSVP flow queuing
ip rsvp qos
! Enable per-flow RSVP
MPLS TE Summary
§ MPLS TE can be used to implement traffic engineering to enable
enhanced network availability, utilization, and performance
§ Enhanced network availability can be implemented via MPLS TE
Fast Re-Route (FRR)
Link, node, and path protection
Automatically route around failed links/nodes; like SONET APS
§ Better network bandwidth utilization can be implemented via
creation of MPLS TE tunnels using explicit routes
Route on the non-shortest path
§ MPLS TE can be used for capacity planning by creation of
bandwidth-specific tunnels with explicit paths through the network
Bandwidth management across links and end-to-end paths
MPLS Layer-3 VPNs
Presentation_ID © 2009 Cisco Systems, Inc. All rights reserved. Cisco Public 132
MPLS VPN Technology Overview
(RFC2547 / RFC4364)
site 3 site 4
MPLS provides an efficient
mechanism for supporting L3 VPNs
This capability is implemented through Virtual
PE PE Routing/Forwarding (VRF) tables for each
customer existing at Provider Edge Routers
(PE), which labels the packets and routes them
through its MPLS core to the edge router that is
P closest to the destination.
§ Traffic Separation at Layer 3 Each VPN Has
Unique Routing Table (VRF)
§ Per VRF Routing/Label distribution via MP-BGP
and VPNv4 address family
PE PE
§ Forwarding of VPN trraffic via MPLS Label
Stacking, with privacy and isolation equivalent to
CE
frame-Relay model
site 1 site 2
MPLS VPN Connection Model (PE-CE)
VPN Site VPN Site
P Router
CE Router CE Router
EBGP, OSPF, RIPv2, Static
PE IP/MPLS Backbone PE
C-Network P-Network C-Network
§ Customer router (CE) has a IP peering connection with PE router in

MPLS network
IP routing/forwarding across PE-CE link
§ PEs maintain multiple and separate Instance of per VPN Routing and
Forwarding Tables (VRF, one per each VPN) to Isolate customer
VPNs (Privacy)
Permit Address overlap (customer to use the same address space)
Capable of VRF-aware routing protocol (static, RIP, BGP, EIGRP, OSPF).
VPN Routing & Forwarding Instance (VRF)
Separate Routing Tables at PE
Per VPN
VPN-A Virtual Routing Table
CE Virtual Forwarding Table
Paris PE
MPLS Backbone
VPN-A VRF for VPN-A
CE
IGP & BGP
London
VRF for VPN-B
VPN-B CE
Munich ip vrf green Global Routing Table
§ One VRF created for each customer VPN on PE router (provides routing
isolation for different VPNs)
§ VRF associated with one or more customer interfaces
§ VRF has its own instance of routing table (RIB) and forwarding table
(FIB, handled by CEF).
§ VRF has its own instance for PE-CE configured routing protocols
VPN Routing & Forwarding Instance (VRF)
PE-CE Routing Protocol Per VPN
Virtual Routing Table
VPN-A eBGP Virtual Forwarding Table
CE
RiPv2
Paris Static PE
OSPF
VPN-A VRF for VPN-A
CE EIGRP
IGP &/or
London BGP
VRF for VPN-B
VPN-B CE
Router …
Munich address-family ipv4 vrf blue Global Routing Table
• VRF is populated locally through PE and CE routing protocol exchange

RIP Version 2, OSPF, EIGRP, BGP-4 & Static routing
• Separate routing context for each VRF ( “show ip route vrf <name>”)
routing protocol context (BGP-4 & EIGRP & RIP V2)
distinct process (OSPF) or distinct address-family instances depending on version
MPLS VPN Connection Model (PE-P)
P P
CE CE
PE PE
MPLS Backbone
P P
CE
CE
MP-iBGP Session
• MPLS Backbone (PE and P Routers) share a single IP/MPLS domain

• Global Routing Table (show ip route”) populated by a (single) IGP protocol
(OSPF, IS-IS)
• MPLS enabled at backbone for IP Label switching (LDP, RSVP)
§ PE Routers Distributes VPN Routing information to other PE routers through
MP-BGP
§ P Routers Forward VPN packets by looking at MPLS labels used for internal
networks (PE loopbacks) distributed by LDP
MPLS VPN: Constrained distribution of VPN
routing information
§ PE routers distribute local VPN information across the MPLS/VPN
backbone using extended addressing schema (VPNv4, 96 bits)
supporting address overlap and isolation
through the use of MP-iBGP* & redistribution from VRF
receiving PE imports routes into attached VRFs
P Router
CE Router PE PE CE Router
Site MP-iBGP Site
Router bgp .
address-family vpnv4
* Multiprotocol BGP, RFC2858 (obsoleted by RFC4760)
VPN Route Distribution
PE routers exchange VPN-IPv4 updates through MP-iBGP sessions
VPN Route Exchange
Customer Customer
Route BGP RR Route
Exchange Exchange
P P
CE PE PE CE
VRF
VPN 1 VRF
CE CE
VRF
VPN 2 VRF
PE P P PE
Label switched traffic MP-iBGP Session
• MP-BGP updates contain VPN-IPv4 addresses and labels

PE originating the route is the next-hop of the route
PE addresses are known as host routes into the core IGP
VPNv4 and MP-BGP Update
VPNv4 address= RD+VPN IP prefix Route
Route Distinguisher (RD) makes the address unique across VPNs
8 Bytes 4 Bytes 8 Bytes 3 Bytes
1:1 10.1.1.0
RD IPv4 Route-Target Label
VPNv4
MP-BGP update showing RD, RT, and label

§ VPN customer 32-bit IPv4 address (10.1.1.0, say) is converted into a 96-bit
VPNv4 address by appending the 64-bit RD to the IPv4 address
=>1:1:10.1.1.0
Makes the customer’s IPv4 address globally unique inside the SP MPLS network.
§ 64-bit Route Distinguisher (RD) is configured inside the VRF at PE
RD is not a BGP attribute, just a field ip vrf green
rd 1:1
RD may or may not be related to a site or a VPN. !
(Unique RD per VRF per Router allows load balancing and faster convergence)
§ Recommended identification:
AS Number : (Router in AS / VRF in Router)
VPN Control Plane Processing
BGP advertisement:
VPN-IPv4 Addr = RD:16.1/16
BGP Next-Hop = PE1
Route Target = 100:1
eBGP: Label=42 eBGP:
16.1/16 16.1/16
No VPN Routes
IP Subnet P in core (P) nodes P IP Subnet
CE1 PE1 PE2 CE2
VRF
VPN 1 VRF
ip vrf Green
RD 1:100
route-target export 1:100
route-target import 1:100
Make customer routes unique: Processing Steps:

§ Route Distinguisher (RD): 8-byte field, VRF 1. CE1 redistribute IPv4 route to PE1 via eBGP.
parameters; unique value assigned by a 2. PE1 allocates VPN label for prefix learnt from
provider to each VPN to make different VPN CE1 to create unique VPNv4 route
routes unique
3. PE1 redistributes VPNv4 route into MP-iBGP,
§ VPNv4 address: RD+VPN IP prefix it sets itself as a next hop and relays VPN site
Selective distribute customer routes: routes to PE2
§ Route Target (RT): 8-byte field, VRF 4. PE2 receives VPNv4 route and, via processing
parameter, unique value to define the in local VRF (green), it redistributes original
import/export rules for VPNv4 routes IPv4 route to CE2.
§ MP-iBGP: advertises VPNv4* prefixes + labels
VPNv4 and MP-BGP Update
Route Target
Extended Community Route-Target is used import/export routes from/to
VRFs
1:1 10.1.1.0 2:2

VPNv4
MP-BGP update showing RD, RT, and Label
§ Route-target (RT): 8-byte (64-bit) field, VRF parameter, unique

value to define the import/export rules for VPNv4 routes
§ Sent as a extended community attribute, identifies the VRF for the
received VPNv4 prefix, acting as a filter
§ Each VRF is configured with a set of RT(s) at the PE
ip vrf green
RT helps to identify which VRF(s) get the VPN route route-target import 1:1
RT export: Label routes export criteria !
RT import: Select the routes to import
VRF Route Distribution control
Create VPN accross the network
MP-iBGP
(RFC2858)
RD1@Net1; RT: 1 ,2
RD2@Net3; RT: 3
RD4@Net4; RT: 4
RT Import: 1
RT Export: 1&2 RT Import : 2

PE1 PE2
RT Export: 3 RT Import : 2 & 3
RT Export: 4
Route-Target (RT) are acting as Import/Export filters

Route-map are also available + Any BGP attribute
No limitation on number of RT per VRF è a VRF may belong to multiple VPN
MPLS VPN Control Plane
MP-BGP Update Components: Label
1:1 10.1.1.0 2:2 50

VPNv4
MP-BGP update showing RD, RT, and 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
§ Any other standard BGP attributes used and sent as usual (AS-
path, Local-Pref, Med, SOO …)
MPLS VPN Control Plane:
Putting It All Together
MP-iBGP Update:
RD:10.1.1.0
3 Next-Hop=PE-1
Site 1 RT=Green, Label=100
CE1 CE2 Site 2
10.1.1.0/24
P P
PE1 PE2
10.1.1.0/24
Next-Hop=CE-1 VRF VPN 1 VRF
P P
1 ip vrf Green
RD 1:100
MPLS
route-target Backbone
import 1:100
1. PE1 receives an IPv4 update (eBGP/OSPF/ISIS/RIP/EIGRP)

2. PE1 translates it into VPNv4 address
Assigns an RT (export value) per VRF configuration
Rewrites next-hop attribute to itself
Assigns a label based on VRF and/or interface and install in the per-
VRF MPLS Forwarding table
3. PE1 sends MP-iBGP update to other PE routers
MPLS VPN Control Plane:
Putting It All Together
MP-iBGP Update: 10.1.1.0/24
3
RD:10.1.1.0
5 Next-Hop=PE-2
Next-Hop=PE-1
Site 1 RT=Green, Label=100
CE1 CE2 Site 2
10.1.1.0/24
P P
PE1 PE2
10.1.1.0/24
Next-Hop=CE-1
VRF
VPN 1 VRF
P P
1 ip vrf Green
RD 1:100
route-targetMPLS Backbone
import 1:100
4. PE2 receives and checks whether the RT=green (40:103, say) is locally
configured within any VRF (RT import), if yes, then
PE2 translates VPNv4 prefix back into IPv4 prefix and installs the prefix into the
VRF routing table
Updates the VRF CEF table with label=100 for 10.1.1.0/24
§ PE2 Advertise this IPv4 prefix to CE2 (using BGP/RIP/OSPF/EIGRP)
MP-BGP peering design
Scalability using Route-Reflectors and clustering
Optional Clustering with RT filtering, only for Extranet
RR RR
CE
CE
P P PE CE
CE PE2
CE P P
PE CE
PE1
CE
§ Full mesh of BGP sessions among all PE routers

Multi-Protocol BGP extensions (MP-iBGP)
Typically BGP Route Reflector (RR) used for improved scalability
MPLS VPN Data Plane
Global MPLS Forwarding Table
The label associated to the VPN-V4 address In Label FEC Out Label
will be set on packets forwarded towards - 197.26.15.1/32 25
the destination VPN-A VRF
10.1.1.0/24,
NH=197.26.15.1
PE-1 Label=(100)
MPLS Packet 25 100 10.1.1.1 10.1.1.27
MP-iBGP Update:
RD:10.1.1.0
Paris Next-Hop= 197.26.15.1
RT=Green, Label=100 London
10.1.1.0/24
• Ingress PE receives normal IP packets

• PE router performs IP Longest Match from VPN FIB, finds iBGP next-hop
(and VPN prefix label) and imposes a stack of labels:
•Top (outer) label is used for forwarding from ingress PE to egress PE
Outer label is LDP (or RSVP) learned; Derived from an IGP route to next-hop of
the BGP route (Loopback of target PE at Global table)
•Bottom (inner) label is used for forwarding at egress PE
Label distributed via MP-BGP (together with the VPN route)
VPN Forwarding Plane Processing (Cont)
IGP VPNv4 IGP VPNv4 IGP VPNv4

IPv4 Label C Label IPv4 Label B Label IPv4 Label A Label IPv4 IPv4
IPv4 P1 P2 IPv4
Packet PE1 PE2 Packet
CE1 CE2
VRF
VPN 1 VRF
§ PE2 imposes stack of labels and forwards MPLS packet to

next-hop P-router P2.
§ P-routers P1 and P2 switch the packet based on outer label
(IGP/LDP derived) and forward label packet to PE1.
§ Router PE1 strips VPN label and forwards IPv4 packet to
CE1.
MPLS-VPN Forwarding Plane
Packet Forwarding Summary
Site 1 Site 2
CE1
10.1.1.0/24 CE2
P3 P4
PE1 PE2
10.1.1.1 10.1.1.1 IP Packet
100 10.1.1.1 P1 P2
VRF Green Forwarding Table
IP Packet
Dest à NextHop
10.1.1.0/24-à PE1, label: 100
50 100 10.1.1.1 25 100 10.1.1.1 MPLS Packet
Global MPLS Forwarding Table Global Routing/Forwarding Table

In Label à Out Label Dest à Next-Hop
25 à 50, Interface 1 PE1 à P2, Label: 25
§ VPN packets are forwarded by P Routes using outer MPLS label (Global
MPLS Forwarding Table, or LFIB)
–Not per-VPN Routing information required at P Routers !
§ Since PHP (P1 remove the top label), single VPN Label is exposed in
target PE
–Single lookup at MPLS packet
–Inspection at PE1’s LFIB goes to next-hop associated to VRF (CE1’s outgoing
interface)
Traffic Separation in MPLS VPNs
Data Packet Two Labels
The second-level label

identifies the destination
VPN and customer address
The ingress MPLS Edge

Switch or Router puts two
labels on each packet
• Packets in MPLS VPN are forwarded based on Labels

• LSRs switch packets based on label at the top of the stack
• Each packet has a label identifying the destination VPN and customer site
• This provides the same level of privacy as Frame Relay
C1
MPLS VPN Sample Configuration (IOS)

Reference
VRF Definition ip vrf VPN-A

rd 1:1
Site 1 route-target export 100:1
CE1 route-target import 100:1
10.1.1.0/24
PE1
PE1 interface Serial0
Se0 ip address 192.168.10.1 255.255.255.0
192.168.10.1 ip vrf forwarding VPN-A
PE-P Configuration Interface Serial1

ip address 130.130.1.1 255.255.255.252
P mpls ip
PE1 PE1
Se0 s1
router ospf 1
network 130.130.1.0 0.0.0.3 area 0
Slide 152
C1 Animation
Cisco, 5/21/2004
C2

Reference
PE: MP-IBGP Config router bgp 1

neighbor 1.2.3.4 remote-as 1
RR neighbor 1.2.3.4 update-source loopback0
!
PE1 PE2 PE1 address-family vpnv4
neighbor 1.2.3.4 send-community both
!
RR: MP-IBGP Config router bgp 1

no bgp default route-target filter
RR neighbor 1.2.3.6 update-source loopback0
RR !
PE1 PE2 address-family vpnv4
neighbor 1.2.3.6 route-reflector- client
!
Slide 153
C2 Animation
Cisco, 5/21/2004
C3

Reference
PE-CE Routing: BGP

router bgp 1
Site 1 !
CE1
address-family ipv4 vrf VPN-A
10.1.1.0/24 PE1 neighbor 192.168.10.2 remote-as 2
192.168.10.2 PE1 exit-address-family
!
192.168.10.1
PE-CE Routing: OSPF

router ospf 1
Site 1 !
CE1
router ospf 2 vrf VPN-A
10.1.1.0/24 PE1 network 192.168.10.0 0.0.0.255 area 0
redistribute bgp 1 subnets
192.168.10.2 PE1 !
192.168.10.1
Slide 154
C3 Animation
Cisco, 5/21/2004
C4

Reference
PE-CE Routing: RIP router rip

!
Site 1 address-family ipv4 vrf VPN-A
CE1
version 2
10.1.1.0/24 PE1 no auto-summary
network 192.168.10.0
192.168.10.2 PE1 redistribute bgp 1 metric transparent
!
192.168.10.1
PE-CE Routing: EIGRP router eigrp 1

!
Site 1
CE1 no auto-summary
PE1 network 192.168.10.0 0.0.0.255
10.1.1.0/24
autonomous-system 1
redistribute bgp 1 metric 100000 100
192.168.10.2 PE1
255 1 1500
192.168.10.1 !
Slide 155
C4 Animation
Cisco, 5/21/2004
C5

Reference
PE-CE Routing: Static

Site 1
CE1
ip route vrf VPN-A 10.1.1.0 255.255.255.0
10.1.1.0/24 PE1 192.168.10.2
192.168.10.2 PE1
192.168.10.1
If PE-CE Protocol Is non-BGP (such as RIP), then Redistribution of

VPN Routes from MP-IBGP Is Required (Shown Below for RIP) -
PE-CE: MB-iBGP Routes to VPN

Site 1 router rip
RR
version 2
redistribute bgp 1 metric transparent
PE1 PE1 no auto-summary
CE1 network 192.168.10.0
exit-address-family
Slide 156
C5 Animation
Cisco, 5/21/2004
C6

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
RR neighbor 1.2.3.4 remote-as 1
neighbor 1.2.3.4 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 glance

through the IOS-XR based config for VPNs
Slide 157
C6 Animation
Cisco, 5/21/2004
MPLS VPN Sample Configuration (IOX)
Reference
VRF Definition vrf VPN-A

router-id 192.168.10.1
Site 1 address-family ipv4 unicast
CE1 import route-target 100:1
10.1.1.0/24 export route-target 100:1
PE1 export route-policy raj-exp
PE1 interface Serial0
Se0
vrf VPN-A
192.168.10.1 ipv4 address 192.168.10.1/24
router bgp 1
PE-CE Routing: BGP vrf VPN-A
rd 1:1
address-family ipv4 unicast
redistribute connected
Site 1
CE1 !
neighbor 192.168.10.2
10.1.1.0/24 PE1 remote-as 2
address-family ipv4 unicast
192.168.10.2 PE1
route-policy raj-temp in
192.168.10.1 !
!
!
!
C30
MPLS-VPN Services: Import and export RT
values must be equals
Intranet Model (Any-to-Any connectivity)
ip vrf green MPLS VPN’s implicit any-to-any model, i.e.,

description Green-Site A full-mesh connectivity
rd 300:111 ip vrf Green
route-target export 1:1 description Green-Central
route-target import 1:1 rd 300:111
Site A PE-A route-target export 1:1
CE-SA
171.68.1.0/24
MPLS VPN Backbone
PE-Central
Site B PE-B
CE-SB CE-Central
171.68.2.0/24
ip vrf green
description Green-Site B
rd 300:111 If BGP is used between every PE and CE, and Sites use
route-target export 1:1 the same BGP ASN then as-override* knobs must be used
at PE
Note: Only VRF Configuration Is Shown Here

Slide 159
C30 Animation
Cisco, 5/21/2004
AS-Override
AS= 1 / 65001 / 65001 / …
AS= 1 / 1 / 1 / …
AS 65001 AS 1 AS 65001
Neighbor .. As-override
Allows all sites of the same customer

to be into the same split Autonomous System
C8
MPLS-VPN Services: Import and export RT
values must be different
Hub and Spoke Service: Configuration
ip vrf green-spoke1 Spoke to spoke communication is via Hub site only

description VRF for SPOKE A
rd 300:111 Requires unique RD per VRF per PE
ip vrf HUB-IN
description VRF for traffic from HUB
Spoke A PE-SA rd 300:11
CE-SA
171.68.1.0/24
Eth0/0.1
PE-Hub Eth0/0.2
Spoke B PE-SB
CE-SB CE-Hub
MPLS VPN Backbone
171.68.2.0/24
ip vrf HUB-OUT
ip vrf green-spoke2 description VRF for traffic to HUB
description VRF for SPOKE B rd 300:12
rd 300:112 route-target export 2:2
route-target import 2:2 If BGP is used between every PE and CE, and Sites use
the same BGP ASN then allowas-in and as-override* knobs
must be used at PE
Note: Only VRF Configuration Is Shown Here
Slide 161
C8 Animation
Cisco, 5/21/2004
Allow-AS-In AS 65001
AS= 65001/1 / 1 / 1 / …
AS 1
Neighbor .. Allow-AS-in 4
AS 65001 AS 65001
Allows Central inter-site of inter-VPN routing
C10
MPLS-VPN Services:
Hub and Spoke Service: Control Plane
VRF FIB and LFIB MPLS Backbone
Destination NextHop Label FIB—IP Forwarding Table
171.68.0.0/16 PE-Hub 35 LFIB—MPLS Forwarding Table
171.68.1.0/24 CE -SA
Spoke A MP-iBGP update

VRF HUB-IN FIB and LFIB
171.68.1.0/24
171.68.1.0/24 CE-SA PE-SA Label 40 Destination NextHop Label
171.68.1.0/24 PE-SA 40
Route-Target 1:1
171.68.2.0/24 PE-SB 50
MP-iBGP update
VRF FIB and LFIB
171.68.0.0/16
VRF HUB-IN
171.68.0.0/16 PE-Hub 35
Label 35 PE-Hub VRF HUB-OUT
171.68.2.0/24 CE -SB
PE-SB Route-Target 2:2
Spoke B VRF HUB-OUT FIB CE-Hub

MP-iBGP update Destination NextHop
171.68.2.0/24 CE-SB 171.68.2.0/24 171.68.0.0/16 CE-H1
Label 50
Route-Target 1:1
§ 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
Slide 163
C10 Animation
Cisco, 5/21/2004
C11
MPLS-VPN Services:
Hub and Spoke Service: Forwarding Plane
This Is How The Spoke-to-Spoke Traffic Flows
171.68.1.1 MPLS Backbone

Spoke A
PE-SA
CE-SA L2 40 171.68.1.1
171.68.1.0/24 171.68.1.1
VRF HUB-IN
CE-Hub
Spoke B PE-Hub
VRF HUB-OUT
CE-SB PE-SB L1 35 171.68.1.1
171.68.1.1
171.68.2.0/24
171.68.1.1
L1 Is the Label to Get to PE-Hub

L2 Is the Label to Get to PE-SA
Slide 164
C11 Animation
Cisco, 5/21/2004
MPLS-VPN Services
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.
Extranet Model
All Sites of Both VPN Green and Orange can Communicate
with Each Other.
ip vrf Orange ip vrf Green
rd 500:24 rd 48:22
route-target export 500:2 route-target export 500:1
Green- route-target import 500:1
route-target import 500:1 Site A
route-target import 500:2 route-target import 500:2
Orange-
ip vrf Orange
Site B
rd 12:43
P Router
ip vrf Green
rd 48:22 Orange –
Green – route-target export 500:1 Site A
Site B route-target import 500:1
C14
MPLS-VPN Services
Extranet VPN – Advanced Extranet
192.6.0.0/16
MPLS Backbone
VPN_A Site#2
VPN_A Site#1
71.8.0.0/16 PE1 PE2
P 180.1.0.0/16
VPN_B Site#1
ip vrf VPN_A ip vrf VPN_B

rd 3000:111 rd 3000:222
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 71.8.0.0 0.0.0.0 access-list 1 permit 71.8.0.0 0.0.0.0 want that.
access-list 2 permit 180.1.0.0 0.0.0.0 access-list 2 permit 180.1.0.0 0.0.0.0
Only Site #1 of Both VPN_A and VPN_B Would Communicate

with Each Other.
Slide 167
C14 Animation
Cisco, 5/21/2004
Use Case 3: Shared Access to Services
Requirement: To resell information (based on raw data) to other companies

Solution: Enterprise needs to become an “Information Provider”. Solution set similar
to Service Providers – MPLS VPNs
Company “B” and Company “A”

Company “A”
VRF instances Site 1 Site 2 maybe in the same physical
created for each location for reduced access costs
“subscriber”
“Information Provider XYZ”
company
Company “B”
VPN_A
VPN_A
VPN_B
MPLS Backbone VPN_B
Company “A”
VPN_A
Site 2
Company “A” and Company “B” access

“Information Provider XYZ” for analysis, reports, trends, etc.
Central services Model (Uncontrolled Access)
Sharing between VPNs with Route-target
VRF Export 3:3

Export 3:3 VRF Import 1:1
Import 1:1
Export 2:2 VRF VRF Export 2:2
Import 1:1 Import 1:1
VRF Import 3:3

Import 2:2
Export 1:1
Shared
Services
Bi-Directional Communication
Between All VRFs and Central
§ No routes exchanged between
Services VRF blue/red
§ Central services routes imported into both
VRF red and blue (1:1) § No transitivity: imported routes are
§ Central VRF imports routes for blue and red not “re-exported”
subnets (3:3, 2:2) à Blue and red remain isolated
Control route advertisement
between VRF
RT import 20:50 MP-iBGP
ip vrf green
rd 20:1 Works also
export map Server1 with import
route-target export 20:1 map
!
access-list 1 permit 100.21.150.0
!
route-map Server1 permit 10
match ip address 1
set extcommunity rt 20:50 additive
MPLS-VPN Services
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
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
C15
MPLS-VPN Services: Internet Access

Option#1: VRF Specific Default Route
Site1 MPLS Backbone

CE1
71.8.0.0/16 Internet
SO 192.168.1.2 ASBR
P
PE1 192.168.1.1
PE1#
ip vrf VPN-A
Internet GW
rd 100:1
Interface Serial0
ip address 192.168.10.1 255.255.255.0 • Static default route to move traffic
ip vrf forwarding VPN-A
from VRF to Internet (global
Router bgp 100 routing table)
no bgp default ipv4-unicast
redistribute static • Static routes for VPN customers
neighbor 192.168.1.1 remote 100
to move traffic from Internet (global
neighbor 192.168.1.1 next-hop-self routing table) to VRF
neighbor 192.168.1.1 update-source loopback0
ip route vrf VPN-A 0.0.0.0 0.0.0.0 192.168.1.1 global

ip route 71.8.0.0 255.255.0.0 Serial0
Slide 172
C15 Animation
Cisco, 5/21/2004
C16

Option#1: VRF Specific Default Route (Forwarding)
Site1 MPLS Backbone

IP Packet
IP Packet Internet
71.8.0.0/16 5.1.1.1 MPLS Packet
30 5.1.1.1 5.1.1.1 (5.1.0.0/16)
S0 PE1 PE2
71.8.1.1 P 71.8.1.1 IP Packet
192.168.1.2 S0
192.168.1.1
PE1: Global Routing/FIB Table

71.8.1.1 35 71.8.1.1 PE2: Global Table and LFIB
Destination Label/Interface IP Packet
MPLS Packet Destination Label/Interface
192.168.1.1/32 Label=30 192.168.1.2/32 Label=35
71.8.0.0/16 Serial 0 71.8.0.0/16 192.168.1.2
5.1.0.0/16 Serial 0
PE1: VRF Routing/FIB Table Pros Cons

Destination Label/Interface
0.0.0.0/0 192.168.1.1 (global)
§ Using default route
for Internet
Site-1 Serial 0 § Different Internet gateways
§ Routing does not allow any
§ Can be used for other default route for intra-
different VRFs VPN routing Increasing size
§ PE routers need not to of global routing table by
hold the Internet table leaking VPN routes
§ Simple configuration § Static configuration
(possibility of traffic
blackholing)
Slide 173
C16 Animation
Cisco, 5/3/2004
Option#2: Separate PE-CE Subinterfaces
Site1 May run BGP to propagate Internet routes between PE and CE
71.8.0.0/16 MPLS Backbone
iBGP Internet
Internet
CE1
Se0.2
PE1 PE2
Se0.1 192.168.1.2 P
192.168.1.1
ip vrf VPN-A
rd 100:1 Internet GW
Interface Serial0.1 § PE1-CE1 has one sub-interface

ip vrf forwarding VPN-A associated to a VRF for VPN routing
ip address 192.168.20.1 255.255.255.0
frame-relay interface-dlci 100 § PE1-CE has another subinterface
! (global) for Internet routing
Interface Serial0.2
ip address 71.8.10.1 255.255.0.0 § PE1 may have eBGP peering with
frame-relay interface-dlci 200 CE1 over the global interface and
!
advertise full Internet routes or a
default route to CE1
Router bgp 100
no bgp default ipv4-unicast § PE2 must advertise VPN/site1 routes
neighbor 71.8.10.2 remote-as 502 to the Internet
Option#2: Separate PE-CE Subinterfaces (Forwarding)
Site1 Firewall
MPLS Backbone
71.8.0.0/16 IP Packet
5.1.1.1
IP Packet Internet
Internet
CE1
MPLS Packet 5.1.1.1
S0.2
PE1 30 5.1.1.1
PE2
S0.1 192.168.1.2 P
192.168.1.1
CE Routing Table PE-Internet GW

VPN Routes Serial0.1
Internet Routes Serial0.2
Pros Cons
PE1 Global Table and FIB
Internet Routes 192.168.1.1 § PE to Hold Full Internet
192.168.1.1 Label=30 § CE is dual-homed and can
perform Optimal Routing Routes or default route via
the Internet GW
§ Traffic Separation Done
by CE: Network Address § . BGP Complexities
Translation (NAT) and Introduced at CE; CE1 May
Firewall, if required Need to Aggregate to
Security Avoid AS_PATH Looping
Extranet with Internet-VRF along with VRF-aware NAT
•Have concept of outside/inside interfaces in NAT
•NAT inspects all traffic routed VRF-to-VRF or VRF-to-Global
•All native NAT applications are supported
Internet Services VRF INSIDE OUTSIDE

A 10.88.1.1 172.0.0.1
B 10.88.1.1 172.0.1.1
B 10.88.3.1 172.0.1.2
10.88.2.0
OUTSIDE
OUTSIDE CE-B2
I-GW NAT PE
Internet VRF-B
INSIDE
INTERFACE
VRF-B
VRF-A
VRF-B
VRF-B
VRF-A
CE-A1 CE-B3
CE-B1 CE-A2 10.88.3.0
10.88.1.0 10.88.1.0 10.88.2.0
MPLS VPN Services:
Loadsharing for the VPN Traffic
RR
PE11
CE1 PE2 CE2

171.68.2.0/24
PE12
Site A Site B
MPLS Backbone
Route Advertisement
§ VPN sites (such as Site A) could be multihomed

§ VPN customer may demand the traffic (to the
multihomed site) be loadshared
C36
MPLS VPN Services:
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-family
at remote PE routers such as PE2 (why PE2?).
ip vrf green
1 2 router bgp 1
rd 300:11
RR address-family ipv4 vrf green
PE11 maximum-paths eibgp 2
CE1 CE2
PE2
171.68.2.0/24
PE12
Site A MPLS Backbone Site B
1 ip vrf green
rd 300:12 ip vrf green
route-target both 1:1 1 rd 300:13
Slide 178
C36 Animation
Cisco, 5/21/2004
MPLS VPN Services:
Loadsharing for the VPN Traffic
RR
Route Advertisement
PE11
CE1 PE2 CE2

171.68.2.0/24
PE12
§ If RR exists in the network, then RR must advertise all the BGP paths
learned via PE11 and PE12 to the remote PE routers that are to select
BGP multipaths
Please note that without ‘unique RD per VRF per PE’, RR would advertise only
one of the received paths for 171.68.2.0/24 to other PEs L
§ Watch out for the increased memory consumption (within BGP) due to
multipaths at the PEs
§ “eiBGP multipath” implicitly provides both eBGP and iBGP multipath for
VPN paths
MPLS VPN Services:
Loadsharing for the VPN Traffic: Cases
RR
1 CE à2 PEs
PE11
CE1 PE2 CE2

171.68.2.0/24
PE12
Site A Site B
MPLS Backbone
Traffic Flow
2 CEs à 2 PEs
RR
PE11
CE1
PE2 CE2
171.68.2.0/24 CE2
PE12
Site B
Site A MPLS Backbone
Traffic Flow
Multi-VRF CE (i.e. VRF-Lite)
Ability to create VRF without MPLS switching
Allows to push ‘PE-like’ function to CE
ip vrf green
rd 3000:111 NO Labels Required
ip vrf blue
rd 3000:222 •Single Physical Link
Ip vrf red •Logical Link per VRF for separation
rd 3000:333
•802.1q, FR/ATM VC’s, GREs IP VPN Service
Vrf MPLS Domain
Green
Vrf
Red CE Routing Updates
EBGP, OSPF, RIPv2, Static
PE iBGP Domain
Multi-VRF
Single router supporting
CE Router
Multiple VRF Instances
§ Each individual VRF on the PE is extended to the CE

§ Separation is maintained via layer-2 or “logical” separation
(e.g. 802.1Q, FR/ATM VC’s)
§ CE is not required to support MPLS labels (no LDP, no MP-BGP)

§ Routing protocol options from CE-PE remain the same
(e.g. BGP, RIPv2, OSPF, EIGRP, static)
MPLS-VPN Services:
Providing Multi-VRF CE Service (a.k.a. VRF-Lite)
§ “Multi-VRF CE” provides multiple virtual routing tables
(and forwarding tables) per customer at the CE router
Not a feature but an application based on VRF implementation
Any routing protocol that is supported by normal VRF can be used in
a multi-VRF CE implementation
§ Note that there is no MPLS functionality needed on the CE, no label
exchange between the CE and any router (including PE) J
§ One of the deployment models is to extend the VRFs to
the CE, another is to extend it further inside the Campus => Virtualization
§ Most of CE functions are supported for VRF (VRF Aware Services)
802.1q
VRF
VRF
VRF
VRF-aware IP-services
§ VRF Aware Ping, Traceroute, § VRF Aware AAA

§ VRF Aware Telnet, SNMP § VRF Aware Syslog
§ VRF Specific Static ARP § VRF Aware Tacacs+
§ VRF Aware HSRP § VRF Aware IPSec
§ VRF Aware DHCP § VRF Aware PKI
§ VRF Aware ODAP § VRF Aware Firewall
§ VRF Aware NAT § VRF Aware GLBP
§ VRF Aware IP SLA § VRF Aware VRRP
§ VRF-lite PBR § VRF Aware Multicast
For your
Example: VRF-lite + 802.1Q reference
only
§ Layer-2 access
§ No BGP or MPLS
L2
§ VRF-lite configured on core and
distribution nodes v v
§ MPLS labels substituted by

802.1q tags end-to-end
Layer 3
§ Every link is a 802.1Q trunk v v
§ Many-to-Many model
§ Restricted scalability
v v
§ Typical for department
inter-connectivity v Multi-VRF
VPN1 v v
L2
VPN2
802.1Q
VRF-Lite over GRE
Control Plane
GRE Tunnel per VRF GRE Tunnel per VRF
MPLS
Branch Site Campus/MAN
Multi-
VRF CE
IPv4 c-PE
Service
Routing to SP BGP/static BGP/static
IGP per VRF

Enterprise Routing IGP per VRF
MP-iBGP for
IGP per VRF VPNv4 to
campus/MAN
§ Routing process required per VRF

§ Works over L2 or L3 VPN service
§ Supports both hub-to-spoke and spoke-to-spoke
connection models
VRF-Lite over GRE
Forwarding Plane mGRE Tunnel
per VRF MPLS
Campus/MAN
Branch Site
Multi- Per-VRF
VRF CE NHRP
IPv4 Server
Service
c-PE
IP outer IP outer IP outer LDP

GRE GRE GRE VPN
IP IP IP IP IP

GRE GRE GRE VPN
IP IP IP IP IP

GRE GRE GRE VPN
IP IP IP IP IP
MPLS over Point-to-Point GRE
Control Plane
MPLS
GRE Tunnel Campus/MAN
Core/Branch Site
IPv4 VPN c-PE
Service
Routing to SP BGP/static BGP/static
IGP, LDP, MP-iBGP IGP, LDP

Enterprise Routing over GRE
§ IGP, BGP, and LDP are enabled over GRE tunnel

§ GRE keepalive is available as an event trigger mechanism
§ IGP can also be used as event detection mechanism for tunnel
availability
§ MPLS over point-to-point GRE is most robust MPLS service option
available
Supports all MPLS services: L2/L3 VPN, IPv6 VPN, VPLS, multicast
MPLS over Point to Point GRE
Forwarding Plane
MPLS
GRE Tunnel Campus/MAN
Core/Branch Site
Per-VRF
c-PE IPv4 VPN c-PE NHRP
Server RR
Service
SP LDP
SP VPN
IP outer IP outer IP outer
GRE GRE GRE
VPN VPN VPN
IP IP IP IP IP
MPLS VPN Inter-AS
How to provide VPN connectivity between different Providers ?
Provider X Provider Y
RR1 RR2
ASBR1 ASBR2
MP-iBGP Update: ???
PE-1 AS #1 AS #2
Problem: PE2
BGP, OSPF, RIPv2
149.27.2.0/24, NH=CE-1 How Do Provider X and
Provider Y Exchange VPN
CE-1 CE2
Routes ?
VPN-A How Forward Traffic VPN-A
149.27.2.0/24
between PEs belongin to
different ASs ?
Inter-AS Deployment Scenarios
Following Options/Scenarios
for Deploying Inter-AS:
ASBR1 ASBR2
1. Back-to-Back VRFs
(Option A)
2. MP-eBGP for VPNv4
AS #1 (Option B) AS #2
PE1 3. Multihop MP-eBGP Between RRs PE2
(Option C)
CE1 CE2
4. Non-VPN Transit Provider
VPN-A VPN-A
Each Option Is Covered in Additional Slides
C31
Option A: Back-to-Back VRF

Control Plane
ASBR-1 VPN-B VRF ASBR-2

Import routes with
VPN-v4 Update: Route-Target 1:1
RD:1:27:10.1.1.0/24 VPN-v4 Update:
NH=PE-1 RD:1:27:10.1.1.0/24,
RT=1:1, Label=(29) NH=ASBR-2
RT=1:1, Label=(92)
BGP, OSPF, RIPv2 VPN-B VRF

10.1.1.0/24 Import Routes with
PE-1 NH=ASBR-2 Route-Target 1:1 PE-2
CE-2 CE-3 BGP, OSPF, RIPv2

BGP, OSPF, RIPv2 10.1.1.0/24,NH=PE-2
10.1.1.0/24,NH=CE-2
VPN-B VPN-B
10.1.1.0/24
VRF-to-VRF Connectivity Between ASBRs
Slide 191
C31 Animation
Cisco, 5/21/2004
C32
Option A: Back-to-Back VRF
Forwarding Plane
ASBR-1 ASBR-2 92 10.1.1.1 P2
30 29 10.1.1.1
P1
10.1.1.1 20 92 10.1.1.1
PE-1 PE-2
IP Packets
Between ASBRs
CE-2 CE-3 10.1.1.1
10.1.1.1
VPN-B
10.1.1.0/24 VPN-B
Pros Cons
§ Per-customer QoS is possible § Not scalable. # of interface on both
§ It is simple and elegant since no need ASBRs is directly proportional to #VRF.
to load the Inter-AS code (but still not § No end-to-end MPLS
widely deployed) § Unnecessary memory consumed in
RIB/(L)FIB
§ Dual-homing of ASBR makes
provisioning worse
Slide 192
C32 Animation
Cisco, 5/21/2004
Option B: MP-eBGP bet ASBRs
for VPN Control Plane
ASBRs exchange VPN routes using eBGP (VPNv4 af)
MP-eBGP for
ASBR-1 ASBR-2
VPNv4 MP-iBGP Update:
MP-iBGP Update:
RD:1:27:10.1.1.0/24, RD:1:27:10.1.1.0/24,
NH=PE-1 NH=ASBR-2
RT=1:1, Label=(40) RT=1:1, Label=(30)
MP-eBGP Update:
RD:1:27:10.1.1.0/24,
PE-1 NH=ASBR-1 PE-2
RT=1:1, Label=(20)
BGP, OSPF, RIPv2
BGP, OSPF, RIPv2 CE-2 CE-3 10.1.1.0/24, NH=PE-2
10.1.1.0/24, NH=CE-2
VPN-B
10.1.1.0/24 VPN-B
§ 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
Option B: MP-eBGP bet ASBRs
for VPN Forwarding Plane
30 40 10.1.1.1 30 10.1.1.1
P2
ASBR-1 ASBR-2
40 10.1.1.1 20 10.1.1.1 20 30 10.1.1.1
PE-1 MPLS Packets

Between ASBRs
10.1.1.1 CE-2 CE-3 10.1.1.1
VPN-B
10.1.1.0/24 VPN-B
Pros Cons
§ More scalable § Automatic route filtering must
Only one interface between be disabled
ASBRs routers But we can apply BGP filtering
No VRF configuration on ASBR.
Less memory consumption (no RIB/FIB memory) § ASBRs are still required to hold
§ MPLS label switching between providers VPN routes
Still simple, more scalable & works today
C33
Option C: Multihop MP-eBGP Between
RRs for VPN Routes: Control Plane
Exchange VPNv4 prefixes with labels via the Route Reflectors
Multihop MP-eBGP for VPNv4 (next-hop unhanged)
VPN-v4 Update:
RR-1 RD:1:27:10.1.1.0/24, RR-2
VPN-v4 Update: NH=PE-1 VPN-v4 Update:
RD:1:27:10.1.1.0/24, RT=1:1, Label=(90) RD:1:27:10.1.1.0/24,
NH=PE-1 NH=PE-1
ASBR-1 ASBR-2 RT=1:1, Label=(90)
RT=1:1, Label=(90)
AS#1 AS#2
PE-1 IGP+LDP:
Network=PE-1 eBGP IPv4 + Labels IGP+LDP: PE-2
NH=PE-1 Network=PE-1
Label=(40) IP-v4 Update: NH=ASBR-2 BGP, OSPF, RIPv2
BGP, OSPF, RIPv2 Network=PE-1 Label=(30) 10.1.1.0/24,NH=PE-2
CE-2 NH=ASBR-1
10.1.1.0/24,NH=CE-2
Label=(20)
VPN-B CE-3
10.1.1.0/24 VPN-B
Only PE loopback addresses need to be exchanged between ASBRs

(they are BGP next-hop addresses + labels of the VPN routes)
Note: Instead of IGP+Label, iBGP+Label Can Be Used to Exchange PE Routes/Label.

Slide 195
C33 Animation
Cisco, 5/21/2004
C34
Option C: Multihop MP-eBGP Between

RRs for VPN Routes: Forwarding Plane
RR-1
RR-2
P1 P2
40 90 10.1.1.1
ASBR-2
ASBR-1 30 90 10.1.1.1
90 10.1.1.1 50 90 10.1.1.1
PE-1
20 90 10.1.1.1
PE-2
10.1.1.1
CE-2 CE-3 10.1.1.1
VPN-B
10.1.1.0/24
Pros VPN-B
§ More scalable than Option A and B
Cons
Separation of control and forwarding
planes
Route Reflector exchange VPNv4 § Advertising PE addresses
routes+labels (RR hold the VPNv4 to another AS may not be acceptable
information anyway) to few providers
§ ASBRs now exchange only IPv4
routes+labels
ASBR forwards MPLS packets
Slide 196
C34 Animation
Cisco, 5/21/2004
MPLS VPN Inter-AS Option AB
MP-eBGP between ASBRs
on a control plane interface
in global table
ASBR1 ASBR2
vpn-B
vpn-G
PE-1
AS 1 Data forwarding on
per VRF interface AS 2 PE-2
as in Option A
CE-2 CE-3 CE-4

CE-1
VPN-B1 VPN-G1 VPN-G2 VPN-B2
§ Combines the benefits of Option A & Option B.

§ Single MP-eBGP peer session between ASBRs leads to better scaling and
reduced configurations.
§ Separate per VRF interfaces between ASBRs forward data as in Option A.
This provides security and QoS benefits of IP forwarding on the I-AS link.
Inter-AS VPNv4 Distribution Options
Back-to-Back VRFs
ASBR1 Option A ASBR2
Data forwarding on
per VRF interface
Option B
MP-eBGP for All
AS #1 AS #2
Option C
PE1 VPNv4 updates
RR1 Multihop MP-eBGP RR2 PE2
between RRs
AND
eBGP IPv4 + Labels
OR IGP + LDP
between ASBRs
§ Option A offers better security but not scalable for high #s of VPNs as it
requires per VRF routing session
§ Option B removes per VRF routing sessions but VPN traffic forwarded over
the same interface(s)
Control & Forwarding Plane
VPN-v4 update:
RD2:P, NH=ASBR1
RT=100:1, Label=(L2)
ASBR1 ASBR2
VPN-v4 update: VPN-v4 update:
RD1:P, NH=PE1 RD3:P, NH=ASBR2
vpn-B RT=100:1, Label=(L3)
RT=100:1, Label=(L1)
PE-1 IP
AS 1 AS 2 PE-2
AS1
L1 IP eBGP, OSPF, RIPv2
AS2
L3 IP P=152.12.4.0/24,
eBGP, OSPF, RIPv2
NH=PE2
P=152.12.4.0/24, IP IP
NH=CE1
CE-1 CE-4
VPN-B1 VPN-B2
§ASBR installs VPN-IPv4 routes into VRFs as described in RFC4364.

§VPN-IPv4 routes are converted back to IPv4 routes and imported into VRFs via
Route Target (RT) based filtering policies.
§ASBRs can be configured to set itself as a Next Hop.
§After IPv4 routes are installed in a VRF, they are converted to VPNv4 routes by the
Route Distinguisher (RD) values, along with VRF’s associated RT(s) as set on the
ASBR.
eBGP for control plane
ASBR-1 VPN-B ASBR-2
VPN-G
AS 1
Data forwarding on per
PE-1 VRF interface as in
Option A PE-2
CE-1 CE-2
CE-3 CE-4
VPN-B VPN-G
Site1 Site1 VPN-G VPN-B
Site2 Site2
§ MPLS VPN Inter-AS option AB

Preserves per VRF based IP forwarding in data plane with IP QoS benefit
Improves scaling in control plane by reducing required number of BGP
session to one
Multicast VPN Overview
• Allows MPLS VPN customers to access Multicast content
• Uses draft-rosen-vpn-mcast encapsulation and signaling to build MVPNs
• Highly Efficient – Multicast tree built dynamically in the core
Blue
RP
CE1
Red PIM-SM
PIM-SM
CE2 PIM-SM
PE4 Blue
PIM-SSM PE3 CE2
Red RP
PIM-SM
CE1 PIM-BIDIR RP
PE1 PIM-SM
PE2
PIM-SM
CE3 CE3
RP
Red
Blue
Multicast VPN Solution
Concept - Multicast Domains
VRF
CE
mVRF
Global Multicast PE
CE Global
PE P
PE
CE
A multicast domain is a set of multicast enabled VRF’s (mVRF’s) that can

send multicast traffic to each other
§ Multicast enabled VPN have a VPN Multicast routing table (mVRF)
§ PEs maintain PIM adjacencies with CE devices
No PIM adjacency between non-directly connected CEs devices
Normal PIM configuration in customer network (RPs etc)
§ A separate multicast group is used inside of Provider Network for each
customer VPN.
–Customer MCast traffic mapped to Multicast enabled P-network
–P-Network does not hold (S, G) for individual customers
Multicast VPN - Default MDTs
PE 2 CE
Provider Network
CE Per VRF
MDT
PE 1
CE
PE 3
§ PE routers build a default MDT in the global table for each of its
mVRF’s using standard PIM procedures
All PE’s participating in the same mVPN join the same Default-MDT
PE are always a root (source) of the MDT
PE is also a leaf (receiver) to the MDT rooted on remote PEs
Control and data packets are transported per VRF over Default MDT
• PE Stablish a per-VRF PIM relationship for Multicast VPN
• Low-speed Multicast traffic from VPN is encapsulated in Default MDT
Default-MDT group address
configuration
ip vrf green ip vrf green
rd 1:80 rd 1:80
mdt default 239.1.1.1 mdt default 239.1.1.1 ip vrf green
rd 1:80
ip vrf red mdt default 239.1.1.1
rd 1:99
mdt default 239.1.1.2 PE2
PE3
PE4
PE1 ip vrf red
P rd 1:99
ip vrf red route-target import 1:99
rd 1:99 mdt default 239.1.1.2
mdt default 239.1.1.2
MDT Tree for Green VPN (239.1.1.1)
MDT Tree for Red VPN (239.1.1.2)
Default Multicast Distribution Tree
mVPN B
Customer
Default B
MDT
Root Default MDT
(*,239.192.10.2)
Leaf 239.192.10.2
PE PE
PE
Multicast Tunnel
Interfaces
CE B1 CE B3
CE B2
• Default MDT is used as a permanent channel both PIM control
messages and low bandwidth streams
• Access to the Default MDT from the mVRF is via a Multicast
Tunnel Interface (MTI)
Appears as a “TunnelX” interface in the mVRF
RPF is executed against MTI
• A PE is always a root (source) of the MDT
• A PE is also a leaf (receiver) to the MDT rooted on remote PEs
Multicast VPN – Control Plane
Multicast Domains
PE-CE PIM neighborship CE

PE-P PIM neighborship
PE-PE PIM neighborship (over MT)
PE
PE CE
PE
CE Provider Network
CE router forms PIM neighborship with VRF instance on PE router

PE routers form PIM neighborship with P routers. This is a global neighborship
PE routers form PIM neighborship with other PE routers over tunnel. This is a VRF
specific neighborship
Multicast Domains – Forwarding Plane
Forwarding is achieved by encapsulating C -packet into P -packet using GRE
C-data-packet
S=192.1.1.1
C-data-packet P-packet D=239.1.1.1
S=192.1.1.1
D=239.1.1.1
S=10.1.1.1
PE Receiver
D=239.2.2.2
Payload=C-packet
Sender 10.2.2.2 192.2.2.2
192.1.1.1 10.1.1.1 PE CE
PE C-control-packet
CE C-control-packet
P-packet S=192.2.2.2
S=192.2.2.2
S=10.2.2.2 D=224.0.0.13 (PIMRTR)
D=224.0.0.13
D=239.2.2.2
Payload=C-packet
• Both customer control and data traffic are sent over the multicast tunnel
• P routers only see MDT group packets, so they won’t build state for traffic and
groups inside the customer VPN
• Customer´s multicast packets will go to each PE router that is in the multicast
domain (default-MDT)
mVPN: mGRE Encapsulation (Rosen model)
C-Packet P-Packet C-Packet
Src = 195.12.2.6 Src = 194.22.15.2 Src = 195.12.2.6
Grp = 239.255.020 Grp = 239.192.10.1 Grp = 239.255.0.20
C-Packet S G C-Packet S G S G C-Packet S G
C-Join (*, 239.255.0.20)
GRE header
and trailer
Source CE B2 CE B1 Receiver
195.12.2.6 Lo0 = 194.22.15.2
MTI
MDT-Group = 239.192.10.1
PE P PE
• Forwarding on the MDT uses GRE, C-packet becomes a P -Packet

• P-Packet S address := PE’s BGP peering address
G address := MDT-Group address (Default or Data)
• C-Packet IP TOS will be copied to P -Packet
• MPLS labels are NOT used in core, only native multicast
Data Multicast Distribution Tree
CE B1
Customer B
Data MDT
239.192.10.32
Customer B
Default MDT High Bandwidth
239.192.10.2 Source
PE PE
ip vrf green
û
rd 1:80 PE
mdt default 239.1.1.1 CE B3
CE B2
mdt data 239.1.2.0 0.0.0.3 threshold 4
• Optionally a Data MDT can created from sending PE when a high

bandwidth source appears in the customer network
• Data MDTs will be created for customer (S, G) states only
• Trees are optimised for the source and active receivers - more state in
the core network tradeoff
Data-MDT Join message
P-Join for Data-MDT New Data MDT
Default MDT
CE PE PE CE
Receiver High
Data- Bandwidth
PE MDT Join
Data--MDT entry cached
Data Source
• Source PE routers will issue Data-MDT join message over Default-MDT

• All PEs on the Default-MDT will receive message. Interested PEs can
join new Data-MDT, others will just cache the message
• Message is sent to ALL-PIM-ROUTERS in UDP using port 3232 every 60
seconds
0 15 16 32
Type Length
Customer VPN Source
Customer VPN Group
Data-MDT Group
Multicast VPN (MVPN)
Summary
Receiver 4 Join high • Customer CE devices
CE
bandwidth source
A joins the MPLS Core
CE Receiver 1 through provider’s PE
CE CE devices
B2
B1 PE
A E
• The MPLS Core forms a
PE
Default MDT for a given
PE B MPLS VPN
Core
E Customer
Default CE
MDT • A High-bandwidth
F source for that
For low
Bandwidth &
control Data customer starts
traffic only. MDT sending traffic
PE For High
• Interested receivers 1 &
Bandwidth
D traffic only.
2 join that High
CE C
PE Bandwidth source
D
C CE • Data-MDT is formed for

Receiver 3
this High-Bandwidth
High bandwidth Join high source
bandwidth source Receiver 2
multicast source
6PE: IPv6 over MPLS
IPv6 global connectivity over and IPv4-MPLS core
iBGP (MBGP) Sessions

2001:DB8:: v6 v6 2003:1::
145.95.0.0 v4 v6 2001:CAFE::
6PE P P 6PE
Dual Stack IPv4-IPv6 Routers Dual Stack IPv4-IPv6 Routers
2001:F00D:: v6
P P
CE
6PE IPv4 6PE
MPLS v4
192.76.10.0 v4 192.254.10.0
CE CE
§ PEs are updated to support dual stack/6PE
§ IPv4 or MPLS core infrastructure is IPv6-unaware
§ IPv6 reachability exchanged among 6PEs via iBGP (MBGP)
IPv6 AF + Label SAFI used to exchange prefixes between PEs
§ IPv6 packets transported from 6PE to 6PE inside MPLS (label switching)
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/iosip_an.htm
6PE Routing/Label Distribution
Connectivity Model is very similar to VPN-MPLS for IPv4
6PE-2 Sends MP-iBGP Advertisement to 6PE-1 Which Says:
IGP or MP-BGP 2001:F00D:: Is Reachable
Advertising Via BGP Next Hop = 200.10.10.1 (6PE-2)
2001:F00D:: Bind BGP Label to 2001:F00D:: (*)
IPv6 Next Hop Is an IPv4 Mapped IPv6 Address Built from 200.10.10.1
2001:DB8::
6PE-1 IGPv4 Advertises Reachability 2001:F00D::

of 200.10.10.1
200.11.11.1
LDPv4 Binds Label 6PE-2

to 200.10.10.1 P1 P2 200.10.10.1
LDPv4 Binds
LDPv4 Binds Label Implicit-Null (i.e.
to 200.10.10.1 Pop) to 200.10.10.1
IGPv6 or MP-BGP
Advertising
2001:F00D::
6PE Forwarding (6PE-1)
IPv6 Forwarding and Label Imposition:

§ 6PE-1 receives an IPv6 packet
§ Lookup is done on IPv6 prefix
§ Result is:
2001:DB8:: Label binded by MP-BGP to 2001:F00D::
Label1 binded by LDP/IGPv4 to the IPv4
6PE-1 address of BGP next hop (6PE-2) 2001:F00D::
IPv6 Packet
to 2001:F00D::1
LDP/v4 MP-BGP IPv6

6PE-2
Label1 to
Label Packet
6PE-2
P1 P2
6PE Forwarding (P1)
IPv6-UNaware MPLS Label Switching:

§ P1 receives an MPLS packet
2001:DB8:: § Lookup is done on Label1
§ Result is Label2
6PE-1 2001:F00D::
6PE-2
P1 P2
LDP/v4
MP-BGP
Label2 to IPv6 Packet
6PE-2 Label
6PE Forwarding (P2)

§ P2 receives an MPLS packet
2001:DB8:: § Lookup is done on Label2
§ Result includes Pop label (PHP), if used
6PE-1 2001:F00D::
6PE-2
P1 P2 MP-BGP
IPv6 Packet
Label
6PE Forwarding (6PE-2)
§ MPLS label forwarding:
§ 6PE-2 receives an MPLS packet
§ Lookup is done on label
§ Result is:
2001:DB8:: Pop label and do IPv6 lookup
on v6 destination
6PE-1 2001:F00D::
6PE-2
P1 P2
6PE Benefits/Drawbacks
§ IPv6 global table connectivity for different sites
§ Core network (Ps) untouched (no HW/SW upgrade,
no configuration change)
§ IPv6 traffic inherits MPLS benefits (wire-rate, fast re-
route, TE, etc.)
§ Incremental deployment possible (i.e., only upgrade
the PE routers which have to provide IPv6 connectivity)
§ Each site can be v4-only, v4VPN-only, v4+v6,
v4VPN+v6
§ P routers won’t be able to send ICMP messages
(TTL expired, traceroute)
§ No VRF configuration
6PE-1 Configuration
2001:DB8::
ipv6 cef iBGP Session
!
mpls label protocol ldp
!
6PE-2
router bgp 100
6PE-1
no synchronization
no bgp default ipv4 unicast
neighbor 2001:DB8:1::1 remote-as 65014 2001:DB8:1::1 Is the Local CE
neighbor 200.10.10.1 remote-as 100 200.10.10.1 Is the Remote 6PE
neighbor 200.10.10.1 update-source Loopback0
!
address-family ipv6
neighbor 200.10.10.1 send-label Send Labels Along with
neighbor 2001:DB8:1::1 activate IPv6 Prefixes by Means of
MP-BGP Note: Will Cause
redistribute connected Session to Flap
no synchronization
exit-address-family
6PE Configuration-IOS-XR
PE1-PE2
PE1 PE2
CE1-BLUE CE2-BLUE
PE1# MP-iBGP Tunnel
PE2#
interface GigabitEthernet0/0/1/5 interface GigabitEthernet0/0/1/5
cdp cdp
ipv6 address 2001:db84:beef:1::1/64 ipv6 address 2001:db82:cafe:1::1/64
! !
router bgp 3 router bgp 3
! address-family ipv4 unicast
address-family vpnv4 unicast !
! address-family ipv6 unicast
address-family ipv6 unicast network 2001:db82:cafe:1::/64
network 2001:db84:beef:1::/64 allocate-label all
allocate-label all !
! address-family vpnv6 unicast
address-family vpnv6 unicast !
neighbor 192.168.253.4
remote-as 3 update-source Loopback0
update-source Loopback0 address-family ipv4 unicast
! !
address-family ipv4 unicast address-family vpnv4 unicast
! !
address-family ipv6 labeled-unicast address-family ipv6 labeled-unicast
6VPE: BGP-MPLS VPN extension for IPv6 (RFC 4659)
Layer-3 VPNs for IPv6 customers
v4 and v6 VPN iBGP (MBGP) Sessions v4 and v6 VPN
VPN BLUE
VPN BLUE
VPN YELLOW v6 Only

P P
v4 and v6 VPN
VPN BLUE
P P v6 Only
VPN YELLOW v6 Only

VPN YELLOW
MPLS VPNs
Apply all RFC4364bis mechanisms to IPv6 VPNs:
• IPv6-VPN reachability exchanged among PEs via MP-BGP
• New BGP address family: AFI=2 (IPv6”), SAFI=128 (VPN)
• NLRI in the form of <length, VPN-IPv6-prefix, label>
• 192bits Address including the 64 bits route distinguisher and the 128 bits IPv6
address <RD:IPv6>
•Nexthop is carried as RD:v4-mapped-v6-address
• VRFs, RT, SOO, RRs,…operate exactly as with IPv4-VPN IPv6 packets
transported from PEx to PEy inside IPv4 LSPs
• IPv4/MPLS core remains IPv6-unaware
New Multi-AF VRF Configuration
IPv6 IPv6 VPN LDP IPv6
Packet Packet Label Label Packet
IPv6/IPv4 Network MPLS IPv4 Backbone IPv6/IPv4 Network
10.1.1.0/24 10.1.2.0/24
2001:db8:beef:1::/64 P P 2001:db8:beef:2::/64
200.10.10.1 200.11.11.1
IPv4 VRF
IPv4 VRF
IPv4
IPv6 MPLS IPv6
CE1 6VPE1 6VPE2 CE2
172.16.1.0/30 172.16.3.0/30
P P
2001:db8:cafe:1::/64 2001:db8:cafe:3::/64
vrf definition GREEN § New VRF AF definition

rd 200:1
! Common RT policies go here Allows address-families
address-family ipv4
route-target export 200:1 Each with unique or common policies
§ vrf upgrade-cli multi-af-mode {common-
exit-address-family
policies | non-common-policies} [vrf
!
<name>]
address-family ipv6
route-target export 200:1 This command can update existing
exit-address-family
VRF definitions
6VPE1 General Configuration
10.1.1.0/24 10.1.2.0/24
2001:db8:beef:1::/64 P P 2001:db8:beef:2::/64
200.10.10.1 200.11.11.1
IPv4 VRF
IPv4 VRF
IPv4
IPv6 MPLS IPv6
CE1 6VPE1 6VPE2 CE2
172.16.1.0/30 172.16.3.0/30
P P
2001:db8:cafe:1::/64 2001:db8:cafe:3::/64
ipv6 unicast-routing !
ipv6 cef interface Ethernet2/0
! description Link to Core Network
interface Loopback0 ip address 192.168.1.1 255.255.255.252
ip address 200.10.10.1 255.255.255.255 mpls ip
! !
interface Ethernet0/0 router ospf 1
Description Link to CE1 log-adjacency-changes
vrf forwarding GREEN redistribute connected subnets
ip address 172.16.1.2 255.255.255.0 passive-interface Loopback0
ipv6 address 2001:db8:cafe:1::2/64 network 192.168.1.0 0.0.0.255 area 0
6VPE1 BGP Configuration
10.1.1.0/24 10.1.2.0/24
2001:db8:beef:1::/64 P P 2001:db8:beef:2::/64
200.10.10.1 200.11.11.1
IPv4 VRF
IPv4 VRF
IPv4
IPv6 MPLS IPv6
CE1 6VPE1 6VPE2 CE2
172.16.1.0/30 172.16.3.0.0/30
P P
2001:db8:cafe:1::/64 2001:db8:cafe:3::/64
router bgp 100 address-family vpnv6 ß To 6VPE2

neighbor 200.11.11.1 remote-as 100 neighbor 200.11.11.1 activate
neighbor 200.11.11.1 update-source lo0 neighbor 200.11.11.1 send-community ext
! exit-address-family
address-family ipv4 ß Internet Routes !
neighbor 200.11.11.1 activate address-family ipv4 vrf GREEN ß To CE1
no auto-summary redistribute connected
no synchronization neighbor 172.16.1.1 remote-as 500
exit-address-family neighbor 172.16.1.1 activate
! exit-address-family
address-family vpnv4 ß To 6VPE2 !
neighbor 200.11.11.1 activate address-family ipv6 vrf GREEN ß To CE1
neighbor 200.11.11.1 send-community ext neighbor 2001:db8:cafe:1::1 remote-as 500
exit-address-family neighbor 2001:db8:cafe:1::1 activate
exit-address-family
6VPE VRF Routing/Label Distribution (MP-BGP)
e-BGP
advertising 6VPE-2 sends MP-iBGP advertisement to 6VPE-1 which
2001:0421:: says:
2001:0420:: 2001:0421:: is reachable
via BGP Next Hop = ::FFFF:192.254.10.17 (6VPE-2)
Site-1
bind BGP 16010 to 2001:0421::
6VPE-1
2001:0421::
192.72.170.13
Site-1
6VPE-2
P1 P2 192.254.10.17
e-BGP
advertising
2001:0421::
•IPv6 vrf routing on Edge (eBGP, Static ,EIGRP)

•MP-BGP VPNv6 routing PE-to-PE
6VPE Label Stack Forwarding:
Populating 6PE-1 FIB yellow Table (inner and outer labels)
6VPE-2 sends MP-iBGP advertisement to 6VPE-1 which
says:
2001:0420:: 2001:0421:: is reachable , L=16010
via BGP Next Hop = 192.254.10.17 (6VPE-2)
Site-1 bind BGP label L10 to 2001:0421::
6VPE-1
2001:0421::
192.72.170.13
Prefix Labels Site-1

LDPv4 binds label1
to 192.254.10.17 2001:0421:: label1/16010
6VPE-2
P1 P2 192.254.10.17
Recursion of BGP Next Hop: populate entry with LDP label
6VPE Forwarding (6VPE-1)
2001:0420::
2001:0421::
IPv6 packet vrf yellow

to 2001:0421::
Site-1
6VPE-1
IPv6 packet
to 2001:0421::
192.72.170.13 IGPv4/LDP MP-BGP 16010 IPv6 packet

label1 to 6VPE-2 to 2001:0420:: to 2001:0421::
Site-1
MP-BGP 16010 IPv6 packet
to 2001:0420:: to 2001:0421::
IPv6 Forwarding and Label 6VPE-2

Imposition: 192.254.10.17
P1 P2
•6VPE-1 receives an IPv6 packet
•Lookup is done on IPv6 prefix, in
vrf yellow IGPv4/LDP MP-BGP 16010 IPv6 packet
•Result is “push two labels”: label2 to 6PE-2 to 2001:0420:: to 2001:0421::
Label 16010 binded by MP-BGP to
2001:0421::
Label1 binded by LDP/IGPv4 to the
IPv4 address of BGP Next Hop
(6VPE-2)
6VPE Forwarding (P1)
2001:0420::
IPv6-UNaware MPLS Label Switching: 2001:0421::
•P1 receives an MPLS packet
•Lookup is done on Label1
IPv6 packet
to 2001:0421::
•Result is Label2
Site-1
6VPE-1
IPv6 packet
to 2001:0421::

label1 to 6PE-2 to 2001:0420:: to 2001:0421::
Site-1
to 2001:0420:: to 2001:0421::
6VPE-2
P1 P2 192.254.10.17
IGPv4/LDP MP-BGP 16010 IPv6 packet

label2 to 6PE-2 to 2001:0420:: to 2001:0421::
6VPE Forwarding (P2)
2001:0420::
2001:0421::
IPv6 packet
to 2001:0421::
Site-1
6VPE-1
IPv6 packet
to 2001:0421::

label1 to 6PE-2 to 2001:0420:: to 2001:0421::
Site-1
to 2001:0420:: to 2001:0421::
6VPE-2
P1 P2 192.254.10.17

label2 to 6PE-2 to 2001:0420:: to 2001:0421::

•P2 receives an MPLS packet
•Lookup is done on Label2
•Result is Pop label (Penultimate Hop Popping)
6VPE Forwarding (6VPE-2)
MPLS Label Pop and IPv6 Forwarding :
2001:0420::
•6VPE-2 receives an MPLS packet
•Lookup is done on 16010 2001:0421::
•If per-vrf label allocation mode is configured,
lookup is done on inner IPv6 destination address in
IPv6 packet the VRF yellow.
to 2001:0421::
Site-1
6VPE-1
IPv6 packet
to 2001:0421::

label1 to 6PE-2 to 2001:0420:: to 2001:0421::
Site-1
to 2001:0420:: to 2001:0421::
6VPE-2
P1 P2 192.254.10.17

label2 to 6PE-2 to 2001:0420:: to 2001:0421::
6VPE Summary
§ RFC4659: BGP-MPLS IP Virtual Private Network
(VPN) Extension for IPv6 VPN
§ 6VPE simply adds IPv6 support to current IPv4 MPLS
VPN offering
§ For end-users: v6-VPN is same as v4-VPN services
(QoS, hub and spoke, internet access, etc.)
§ For operators:
Same configuration operation for v4 and v6 VPN
No upgrade of IPv4/MPLS core (IPv6 unaware)
MPLS Layer-3 VPN Summary
§ Provide layer-3 connectivity among CE sites via IP peering
(across PE-CE link)
§ Implemented via VRFs on edge/PE nodes providing customer
route and forwarding segmentation
§ Support for IPv4, IPv6 and Multicast
§ BGP used for control plane to exchange customer VPN (VPNv4)
routes between PE routers
§ MPLS VPNs enable full-mesh, hub-and-spoke, and hybrid IP
connectivity among connected CE sites
§ MPLS VPN support for Single o Multiple Operator enviroment
(Inter-AS)
§ Proven and Scalable solution for both Service Provider and
Enterprise networks
§ L3 VPNs for enterprise network segmentation can also be
implemented via VRFs + GRE tunnels or VLANs
MPLS Layer-2 VPNs
Why Is L2VPN Needed?
§ It allows SP and Enterprise to have a single
infrastructure for both IP and legacy services
For SP Move legacy ATM/FR traffic to MPLS/IP core without
interrupting current services
Enterprise allow them to build better DataCenter and spam
across L2 AC across WAN/MPLS and provide better HA
§ Help SP provide new P2P Layer 2 tunnelling services

Customer can have its own routing, QoS policy, etc.
§ A migration step towards IP/MPLS VPN
Motivation for L2VPNs
I’ve Really Got to Consolidate These Networks
MPLS or IP
IP IP
ATM
FR/ATM
FR/ATM
Metro
Ethernet
Ethernet
Access Access
Multiple Access Services Require Multiple Core Technologies = $$$ High Costs/Complex
Management
Layer-2 VPN Overview
§ Enables transport of any Layer-2
traffic over MPLS network SP
Interconnection
Includes label encapsulation PE Router
and translation
SP
Network
PE Router
Pseudo Wire
Many Subscriber
FR Encapsulations
ATM
Supportable
PPP HDLC
Ethernet
L2VPN Options
L2VPN Models
VPWS VPLS
Virtual Private Wire Service Virtual Private LAN Service
Point to Point Point to Multipoint
MPLS Core
L2TPv3 AToM Ethernet
IP Core MPLS Core
Ethernet Ethernet MPLS Layer-2 VPNs

Frame Relay Frame Relay
ATM (AAL5 and Cell) ATM (AAL5 and Cell)
PPP and HDLC PPP and HDLC Any Transport over MPLS: AToM
Point-to-Point vs. Multipoint
§ Point-to-Point (VPWS, E-LINE, EWS/ERS, and so on)
One virtual circuit connect two UNIs
UNI can be on the same box or two boxes
No MAC learning or MAC-based forwarding are involved
Virtual Circuit is tied to port/VLAN, it doesn’t need systemwide
VLAN resource, potential large scale number of circuit are supported
§ Multipoint (VPLS, L2 local bridging, EMS/EMRS, and so on)

More than two UNIs, one or multiple Virtual Circuits
MAC learning and MAC-based forwarding
Bridge-domain is tied to system wide resource like global VLAN,
thus less scale
Typically it has maximum peers per bridge-domain limit
L2 VPN Services
ATM Frame Relay Ethernet
VPWS VPLS
AAL5 over FR over Ethernet Relay Ethernet Multipoint
Pseudo Wire Pseudo Wire Service (ERS) Service (EMS)
Muxed UNI Muxed UNI Muxed UNI

Unmuxed
UNI
Cell Relay w/
Packing over Ethernet Relay
Pseudo Wire PPP/HDLC over Ethernet Wire Multipoint Service
Pseudo Wire Service (EWS) (ERMS)
Muxed UNI
Muxed
Unmuxed UNI Unmuxed UNI UNI
Other Variants…
PPP/HDLC
Technology for L2VPNs: Pseudowires
§ L2VPNs are built with “Pseudowire” (PW) technology
§ PW is an emulated circuit
§ PWs provide an common intermediate format to transport multiple
types of network services over a Packet Switched Network (PSN)
§ Any Transport over MPLS (AToM) is PW based L2VPNs for
various encapsulations
§ PW technology provides Like-to-Like (L2L) transport and also
Interworking (IW)
Ethernet Ethernet Ethernet

ATM
ATM ATM Frame
Frame Ethernet Relay
Frame
Relay Like-to-Like Relay Interworking
TM1
What Is a Pseudowire?
§ A pseudowire (PW) is an emulation of a telecommunications
service over a Packet Switched Network (PSN)
§ PWs emulate the essential attributes of the native service
§ The PSN may be IP or IP/MPLS
§ Packets are transported over IP/MPLS networks using a PSN
Tunnel (LSP) setup between PEs.
Payload Type PW Service

Packet Ethernet (all types), HDLC framing,
PPP, Frame Relay, ATM AAL5 PDU
Cell ATM
Bit stream Unstructured E1/T1, E3/T3
Structured bit stream SONET/SDH
Slide 241
TM1 PPP under PW Service for Packet?

Tim McSweeney, 5/16/2007
Any Transport over MPLS Architecture
§ Based on IETF’s Pseudo-Wire (PW) Reference Model
§ PW is a connection (tunnel) between 2 PE Devices, which
connects 2 PW End-Services
PW connects 2 Attachment Circuits (ACs)
Bi-directional (for p2p connections)
Use of PW/VC label for encapsulation
Customer2 Customer2
Site1 PWES PSN Tunnel PWES Site2
Pseudo-Wires
Customer1 PE PE Customer1
Site1 Site2
PWES PWES
Emulated Layer-2 Service
AToM Technology Components
§ PE-CE link
Referred to as Attachment Circuit (AC)
Can be any type of layer-2 connection (e.g., FR, Ethernet)
§ AToM Control Plane
Targeted LDP (Label Distribution Protocol) Session
Virtual Connection (VC)-label negotiation, withdrawal, error notification
§ AToM Forwarding Plane
2 labels used for encapsulation + control word
Outer tunnel (LDP) label
To get from ingress to egress PE using MPLS LSP
Inner de-multiplexer (VC) label
To identify L2 circuit (packet) encapsulated within tunnel label
Control word
Replaces layer-2 header at ingress; used to rebuild layer-2 header at
egress
AToM Control Plane Processing
4 Label Mapping Messages
5 5
2 3 LDP session
2
P P
CE1 PE1 PE2 CE2
Layer-2 Layer-2
Connection Connection
Processing Steps (for both P1 and P2):

1. CE1 and CE2 are connected to PE routers via layer-2 connections
2. Via CLI, a new virtual circuit cross-connect is configured, connecting
customer interface to manually provided VC ID with target remote PE
3. New targeted LDP session between PE routers established, in case one
does not already exist
4. PE binds VC label with customer layer-2 interface and sends label-
mapping message to remote PE over LDP session
5. Remote PE receives LDP label binding message and matches VC ID with
local configured cross-connect
Based on xconnect command, both PE’s will create directed LDP session if
doesn’t exist already
BRKRST-1101 244
© 2009 Cisco Systems, Inc. All rights reserved. Cisco Public
PWE3: PWid FEC signaling
VC1 PE1
Directed LDP
xconnect <PE2> <VCID>
PE2
VC2
PWE3: VC Label distributed through directed
LDP session
2. PE1 binds
Label Mapping Msg
VCID to VC VC FEC TLV 4. PE2
Label repeats same
VC Label TLV steps
Directed LDP
PE1 PE2
P1 P3
CE1
CE2
Site1
VC1 VC2 Site2
P2 P4
3. PE2
1. Provision VC C VC VC Info matches its
TLV Type Length VCID to one
AC & PW
Group ID received
VC ID
Interface Parameters
PWid FEC TLV
LDP: PWid FEC TLV
VC C VC VC Info PW Type Description

TLV Type Length 0x0001 Frame Relay DLCI
Group ID 0x0002 ATM AAL5 SDU VCC transport
VC ID 0x0003 ATM transparent cell transport

0x0004 Ethernet Tagged Mode (VLAN)
Interface Parameters
0x0005 Ethernet
0x0006 HDLC
Virtual Circuit FEC Element
0x0007 PPP
0x0008 SONET/SDH Circuit Emulation Service Over MPLS
§ C—control word present

§ VC Type—ATM, FR, Ethernet, HDLC, PPP, etc.
§ VC Info Length—length of VCID
§ Group ID—group of VCs referenced by index
§ VC ID—used to identify
§ Interface Parameters—MTU, etc.
AToM Forwarding Plane Processing
Tunnel VC Tunnel VC Tunnel VC
L2 Label C Label L2 Label B Label L2 Label A Label L2 L2
Layer-2 P1 P2 Layer-2
CE1 Packet PE1 Directed LDP PE2 Packet
CE2
Label Exchange for VC Label
Neighbor LDP– Neighbor LDP– Neighbor LDP–

Label C Label B Label A
Processing Steps:
1. CE2 forwards layer-2 packet to PE2.
2. PE2 imposes VC (inner) label to layer-2 packet received from
CE2 and optionally a control word as well (not shown).
3. PE2 imposes Tunnel outer label and forwards packet to P2.
4. P2 and P1 router forwards packet using outer (tunnel) label.
5. Router PE2 strips Tunnel label and, based on VC label, layer-2
packet is forwarded to customer interface to CE1, after VC label
is removed
In case control word is used, new layer-2 header is generated first.
Pseudowire Traffic Encapsulation
0 1 2 3
0 1 2 3 4 5 67 8 9 01 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Tunnel Label Tunnel Label (LDP/RSVP) EXP 0 TTL
VC Label VC Label (VC) EXP 1 TTL (Set to 2)
Control Word 0000 Flags FRG Length Sequence Number
Layer 2 PDU
§ Three-level encapsulation
Tunnel Label – Determines path through network Control Word
VC Label – Identifies VC at endpoint Encap. Required
Control Word – Contains attributes of L2 payload
CR No
§ Packets switched between PEs using top
(tunnel) label AAL5 Yes
Eth No
§ VC label identifies PW
FR Yes
§ VC label negotiated between PE with directed LDP
HDLC No
§ Optional control word carries Layer 2 control bits and enables
sequencing PPP No
VPWS EoMPLS— RFC 4448
Original Ethernet or VLAN Frame
Preamble DA SA 802.1q L Payload FCS
DA’ SA’ 0x8847

Tunnel VC Ethernet Ethernet
FCS’
Label Label Header Payload
§ VC type-0x0004 is used for VLAN over MPLS

application
§ VC type-0x0005 is used for Ethernet port tunneling
application (port transparency)
A Typical Configuration: EoMPLS VLAN
R201 R202 R203
10.0.0.201 10.0.0.202 10.0.0.203
e0/0.10 e1/0 e1/0 e2/0 e2/0 e0/0.10

e0/0.10 10.1.1.0/24 10.1.2.0/24 e0/0.10
R200 R204
PE P PE
dot1Q 10 LDP LDP dot1Q 10
CE CE
10.10.10.200/24 10.10.10.204/24
Targeted LDP
hostname R203
hostname R201 !
! ip cef
ip cef mpls ip
mpls ip mpls label protocol ldp
mpls label protocol ldp mpls ldp router-id Loopback0 force
mpls ldp router-id Loopback0 force !
! interface Loopback0
interface Loopback0 ip address 10.0.0.203 255.255.255.255
ip address 10.0.0.201 255.255.255.255 !
! pseudowire-class eompls
interface Ethernet0/0.10 encapsulation mpls
description *** To R200 *** !
encapsulation dot1Q 10 interface Ethernet0/0.10
xconnect 10.0.0.203 10 encapsulation mpls description *** To R204
encapsulation dot1Q 10
xconnect 10.0.0.201 10 pw-class eompls
Calculating MTU Requirements
for the Core
§ Core MTU = Edge MTU + Transport Header + AToM
Header + (MPLS Label Stack * MPLS Header Size)
§ Edge MTU is the MTU configured in the CE-facing
PE’s interface
§ Examples (all in bytes):
MPLS MPLS
Edge Transport AToM Total
Stack Header
1526
EoMPLS Port Mode 1500 14 4 [0] 2 4
[1522]
1530
EoMPLS VLAN Mode 1500 18 4 [0] 2 4
[1526]
1530
EoMPLS Port w/ TE FRR 1500 14 4 [0] 3 4
[1526]
Example of large MTU requirement
4 Bytes
Back--up FRR Label (VC)
Back EXP S TTL
4 Bytes
TE or primary FRR Label (VC) EXP S TTL
4 Bytes
Core LDP Label (VC) EXP S TTL
4 Bytes
VPN label (L2 or L3) EXP S TTL
4 Bytes
Optional Control-
Control-word
4 Bytes
Dot1Q Header (only in Port Mode Xconnect)
PDU
MPLS MTU = 1536 Bytes

Layer 2 Extension
Ethernet over MPLS over GRE
Per VLAN
VC/GRE
Per VLAN
alternate path
Backup EoMPLS Pseudo-wire

into Core
L3 L3
DCI DCI DCI
DCI Si Si Si Si
L2 L2
L2 Etherchannel L2 Etherchannel
as VSS Is Viewed as VSS Is Viewed
as One Device as One Device
Aggregation Aggregation
Si Si Si Si
VSL VSL
MEC
Access Access Si Si
VSL
Configuration Example
Frame-Relay to Ethernet
Frame Link
frame-relay switching Ethernet/VLAN Link
! !
pseudowire-class atom_fr_vlan pseudowire-class atom_vlan_fr
encapsulation mpls encapsulation mpls
interworking ip interworking ip
! !
interface serial3/0 interface GigabitEthernet4/0.310
encapsulation frame-relay encapsulation dot1Q 310
clock source internal xconnect 192.168.200.1 210 pw-class atom_vlan_fr
frame-relay lmi-type ansi
frame-relay intf-type dce
!
connect fr-vlan serial3/0 210 l2transport
xconnect 192.168.200.2 210 pw-class atom_fr_vlan
MPLS/IP
VLAN 310
DLCI 210
interface serial5/0.210 point-to-point interface GigabitEthernet6/0.310

ip address 172.16.1.1 255.255.255.0 encapsulation dot1Q 310
frame-relay interface -dlci 210 ip address 172.16.1.2 255.255.255.0
ATM / IMA Over Pseudowires
§ IMA terminated on Cell-site
router. L2 MPLS MPLS Control ATM
§ ATM psuedowire between cell-

site and aggregation router. ATM / IMA
MWR2941
§ Aggregation router can map Node-B
VCs from psuedowire to ATM

OC3 Clear Channel towards MPLS / IP
RNC. ATM / OC3c
RNC
Cisco 7600
aggregation
§ ATM VC mode allows VPI and
MWR2941
VCI rewrite.
ATM / IMA
§ ATM VP mode allows VPI
rewrite. Node-B
256
Circuit Emulation over Packet (CEoP)
TDM/ATM Circuits Standards based CEoP TDM/ATM Circuits
(ChSTM1/OC3, (ChSTM1/OC3,
T1/E1 etc.) Packet T1/E1 etc.)
Switche
d
Network
§ Circuit Emulation over Packet (CEoP) allows customers to provide TDM circuit
service over a Packet Switched Network (PSN)
Circuit Emulation = imitation of a physical communication link
§ CEoP imitates a physical communication link across Packet network
Available for AToM (MPLS) now; L2TPv3 (IP) in future
§ Allows the transport of any type of communication over Packet
§ Ideal for TDM or Leased Line replacement and legacy network consolidation
§ CEoP emulates T1/E1, T3/E3 and OC3/STM-1, unstructured and structured, down
to nxDS0 circuits
§ SATOP
Unstructured E1 frame
§ CESoPSN
Structured Unchannelized E1 frame (timeslots 1-31)
Structured Channelized E1 frame (timeslot x-y)
Signal PW Type (CEM)
VC TLV C VC Type VC info length
Group ID
VC ID
Interface Parameter
VC TLV = 128 or 0x80

VC Type: 0x0011 E1 (SaToP)
0x0012 T1 (SaToP)
0x0013 E3 (SaToP)
0x0014 T3 (SaToP)
0x0015 CESoPSN basic mode
0x0017 CESoPSN TDM with CAS
C: 1 control word present
Group ID: If for a group of VC, useful to withdraws many labels at once
VC ID : ID for the transported L2 vc
Int. Param: classical + IETF-PWE3-TDM-CP-Extension
CEoP Configuration Example
Attachment Circuit Attachment Circuit
Pseudo-Wire
CEM Circuit 7600 7600 CEM Circuit
MPLS
BTS BSC
T1 Data T1 Data
card type t1 1 3
card type t1 3 3 controller T1 1/3/0
controller T1 3/3/0 framing esf
framing esf cem-group 0 timeslots 1-24
cem-group 0 timeslots 1-24 !
! controller T1 1/3/1
controller T1 3/3/1 framing esf
framing esf cem-group 1 timeslots 1-5
cem-group 1 timeslots 1-5 cem-group 5 timeslots 10-15
! !
controller T1 3/3/2 controller T1 1/3/2
framing unframed framing unframed
cem-group 2 unframed cem-group 2 unframed
interface CEM3/3/0 [CESoP] interface CEM1/3/0 [CESoP]
cem 0 cem 0
xconnect 192.168.37.3 330 encapsulation mpls xconnect 192.168.37.2 330 encapsulation mpls
! !
interface CEM3/3/1 [CESoP] interface CEM1/3/1 [CESoP]
cem 1 cem 1
xconnect 192.168.37.3 331 encapsulation mpls xconnect 192.168.37.2 331 encapsulation mpls
! cem 5
interface CEM3/3/2 [SAToP] xconnect ....
cem 2 !
xconnect 192.168.37.3 332 encapsulation mpls interface CEM1/3/2 [SAToP]
cem 2
BRKRST-1101 xconnect 192.168.37.2 Cisco
332Public
encapsulation mpls 259
Coupling Layer-2 Services with MPLS
TE—AToM Tunnel Selection
§ Static mapping between
pseudo-wire and TE CE
Tunnel on PE PE1
IP/MPLS
§ Implies PE-to-PE TE PE2

deployment
ATM
PE3
§ TE tunnel defined as
preferred path for
pseudo-wire ATM
TE LSP
CE
§ Traffic will fall back

Layer 2 Circuit
Layer 2 Circuit
to peer LSP if tunnel

goes down pseudowire-class my-path- pref
encapsulation mpls
preferred-path interface tunnel 1 disable-fallback
!
interface fastEthernet <slot/port>.<subif-id>
encapsulation dot1Q 150
xconnect 172.18.255.3 1000 pw-class my-path-pref
ATOM: Preferred Path TE Tunnels
§ Three TE tunnels (Tunnel 0, Tunnel 1 and Tunnel2) between PE1 and PE2
§ “Preferred path” can be used to map each vc (or multiple vcs) traffic into different
TE tunnels
Site 1 TE Tunnel 0
TE Tunnel 2 Site 2
192.168.0.5/32 CE2
CE1
10.1.1.0/24 P3 P4
30
CE2 Site 2
Site 1 CE1
35
10.1.1.0/24
PE1
PE2
CE1
P2 P1
34
CE2 Site 2
Site 1
10.1.1.0/24
TE Tunnel 1
interface Ethernet2/0.1
pseudowire -class test description green vc
encapsulation mpls xconnect 192.168.0.5 1 encapsulation mpls pw-class test
preferred-path interface Tunnel0 !
! interface Ethernet2/0.2
pseudowire -class test1 description red vc
encapsulation mpls xconnect 192.168.0.5 20 encapsulation mpls pw-class test1
preferred-path interface Tunnel1 !
! interface Ethernet2/0.3
pseudowire -class test2 description dark green vc
encapsulation mpls xconnect 192.168.0.5 30 encapsulation mpls pw-class test2
preferred-path interface Tunnel2
Inter-AS PW using Tunnel Stitching
– Reference Model
PE-22 VC 101
PE11 eBGP IPv4
VC 201 +
Labels
VC 201/404 VC 404/101
ASBR-11 ASBR-21
AS 1 AS 2
VC 202 VC 202/303 PE-22
VC 303/102 VC102
Attachment-
Attachment- AS1 PW–AS1
Pseudowire Tunnel Stitch PW Pseudowire-AS2
AS2 PW circuit
circuit
• ASBR uses VFI to perform stitching

• Per-AS Pseudowire control and encapsulation independence
• Reduces pseudo wire control plane burden on PE as well as the number of
required Inter-AS pseudowire control channels
• Re-coloring of EXP value inside or at AS boundaries
• ASBR nodes must store ALL L2VPN end-point NLRIs as well as maintain
attachment circuit state for each pseudowire domain that it connects.
Inter-AS PW using Tunnel Stitching
– Packet Flow
Tunnel Label 37 22
VC Label 24 24 38 34 34
L2 Frame Frame Frame Frame Frame Frame Frame
PE1
ASBR1 ASBR2 PE2
AS 1 AS 2
P11 P21
• Tunnel/IGP • VC Label •VC Label • Tunnel Label •VC Label
Label Entry Entry
- Label 36 (24) - Label 56 (38) - Label 52 (34)
-Label 55 ( 37) - Label 34 (22)
- Exp = 0 - Exp = 0 - Exp = 0
-Exp = 0 - Exp = 0
- S=1 - S=1 - S=1
-S = 0 -S=0
- TTL = 254 - TTL = 255 - TTL = 254
-TTL = 254 - TTL = 254
• VC Label • VC Label
- Label 36 (24) - Label 52 (34)
- Exp = 0 - Exp = 0
- S=1 - S=1
- TTL = 255 - TTL = 255
Attachment
Attachment- AS1 PW–AS1
Pseudowire TunnelStitch
Tunnel StitchPW
PW Pseudowire-AS2
AS2 PW circuit
circuit
Inter-AS VPLS ASBR-ASBR Switching Options
Option A: § Clear demarcation between ASs
facilitates management and
Layer-2 troubleshooting Pseudowire
Peering § Granular QoS control
PE1 IP/MPLS IP/MPLS PE3
between § No reachability information shared ASBR1 ASBR2
ASBRs between ASs ..
PE2 PE4
§ LDP and L2TPv3 signaling can be
combined
§ May require a large number of ACs
between ASBRs
Option C: § Simple provisioning on ASBRs

Pseudowire
Single-Hop § No clear demarcation between ASs
§ Significant sharing of reachability IP/MPLS ASBR1 ASBR2 IP/MPLS
PW PE1 PE3
information (unless Inter-AS TE used)
§ Limited QoS control between ASBRs PE4
PE2
(unless Inter-AS TE used)
§ LDP or L2TPv3 signaling cannot be
combined
Option B: § Clear demarcation between ASs

facilitates management and Pseudowire
Multi-Hop troubleshooting
PW PE1 IP/MPLS IP/MPLS PE3
§ Minimal reachability info shared (single
ASBR1 ASBR2
peering address)
§ Granual QoS control possible with per- PE2 PE4
PW QoS
§ LDP and L2TPv3 signaling can be
combined
§ Additional provisioning (on ASBRs)
Virtual Private LAN Service (VPLS)
Site1 PE1 PE2 Site2
CE CE
MPLS
WAN
Site3 All CEs Appear Connected on a

CE Common Virtual Switch
§ Provides Ethernet Multipoint Services over MPLS network

§ VPLS operation emulates an IEEE Ethernet bridge
§ Two VPLS drafts in existence
RFC4762 • Virtual Private LAN Service (VPLS) Using Label Distribution
Protocol (LDP) Signaling M. Lasserre, V. Kompella.
RFC4761 • Virtual Private LAN Service (VPLS) Using BGP for Auto-
Discovery and Signaling. K. Kompella, Y. Rekther.
Virtual Private LAN Service (VPLS)
§ VPLS defines an architecture allows MPLS networks offer
Layer 2 multipoint Ethernet Services
§ SP emulates an IEEE Ethernet bridge network (virtual)
§ Virtual Bridges linked with MPLS Pseudo Wires
Data Plane used is same as EoMPLS (point-to-point)
§ Forwarding of Frames based on Learned MAC addresses

VPLS is an Architecture
PE PE
CE CE
CE
VPLS Technology Components
§ PE-CE link
Referred to as Attachment Circuit (AC)
Ethernet VCs are either port mode or VLAN ID
§ VPLS Control Plane
Full mesh of targeted LDP sessions
Virtual Connection (VC)-label negotiation, withdrawal, error
notification
§ VPLS Forwarding Plane
Virtual Switching Instance: VSI or VFI (Virtual Forwarding Instance),
Uses a Virtual Forwarding Instances (VFI, like VLAN) for
customer separation
VPN ID: Unique value for each VPLS instance
PWs for interconnection of related VSI instances
VPLS Components
Attachment Circuit
Full Mesh of Targeted-LDP Sessions
Exchange VC Labels
n-PE n-PE
CE CE
PW
Tunnel LSP PW
CE CE
PW
CE CE
Red VSI Red VSI
Blue VSI Directed LDP Blue VSI
Green VSI Session Between Green VSI
CE
Participating PEs Full Mesh of PWs
Between VSIs
§ AC (Attachment Circuit)
Connect to CE device, it could be Ethernet physical or logical port, ATM bridging (RFC-1483), FR
bridging (RFC-1490), even AToM pseudo wire; one or multiple ACs can belong to same VFI
§ VC (Virtual Circuit)
EoMPLS data encapsulation, tunnel label is used to reach remote PE, VC label is used to identify VFI;
one or multiple VCs can belong to same VFI
§ VFI (Virtual Forwarding Instance)
Also called VSI (Virtual Switching Instance); VFI create L2 multipoint bridging among all ACs and VCs;
it’s L2 broadcast domain like VLAN
Multiple VFI can exist on the same PE box to separate user traffic like VLAN
VPLS Components
Pseudo Wires within LSP

Virtual Switch Interface (VSI)
terminates PW and provides
Attachment circuits Ethernet bridge function
Port or VLAN mode
Mesh of LSP between N-PEs
N-PE N-PE
CE router CE router
CE router CE router
CE switch MPLS CE switch

Core
Targeted LDP between PEs

to exchange VC CE router
labels for Pseudo Wires Attachment CE
can be a switch or router
CE switch
N-PE
VPLS Data Plane and Control Plane
BGP-Based VPLS Auto Discovery
Data Plane
§ Although VPLS simulate multipoint virtual LAN service, the
individual VC is still point-to-point EoMPLS; it uses the same data
encapsulation as point-to-point EoMPLS
Unidirectional LSP carries Ethernet frames between pair of N-PE Per
§ VFI will participate in learning and forwarding process
Control Plane
§ Signaling
Same as EoMPLS, using targeted LDP session to exchange VC information
§ Auto-discovery of VPN membership

Reduces VPN configuration and errors associated with configuration
7600 support BGP based auto discovery from 12.2(33)SRB release, based on
draft-ietf-l2vpn-signaling-xx.txt
VPLS – Forwarding Plane
VPLS Simulates a Virtual LAN Service, It Must Operate Like a
Traditional L2 LAN Switch as Well
§ Flooding/Forwarding
Forwarding based on (per VFI) MAC Destination Address
MAC table instances per customer (per VFI) for each PE
Unknown Ucast/Mcast/Broadcast—flood to all ports and pseudowires
(IGMP snooping can be used to constrict multicast flooding)
§ Address Learning/Aging/Withdrawal
Dynamic learning based on Source MAC and per VFI
LDP enhanced with additional MAC List TLV (label withdrawal)
MAC timers refreshed with incoming frames
§ Loop Prevention
Create full-mesh of Pseudo Wire VCs (EoMPLS)
A VPLS instance use “split horizon” concepts to prevent loops
Spanning Tree disable at VPLS Domain
Loop Prevention: Split-Horizon
N-PE3 MPLS N-PE4
VFI VFI
VFI
N-PE1
§ How to avoid loop in VPLS (multipoint bridging) network?

§ Spanning tree is possible but not desirable
§ VPLS use split-horizon to avoid loop
Packet received on VPLS VC can only be forwarded to ACs, not the other VPLS
VCs (H-VPLS is exception)
Require full mesh VCs among all PEs
Case Study: MPLS (VPLS) Solution for DCI
MPLS
WAN VPLS/EoMPLS WAN
MPLS MPLS
Core
Core
PWs
L2/L3 L2/L3
Aggr Aggr
DC-1 DC-2
A B C D A B C D
WAN and Core requirements: •Map VLAN to VPLS PW with Scale

•Connectivity options(Nx10GE, 1GE, POS) •Sub-rate QoS
•WAN/NPE Redundancy •Roadmap to 40/100GE
•L2 extension cross DCs, POD to POD •POD to POD communication
communication
VPLS for Data Center Interconecction
l2 vfi vlan3700 manual l2 vfi vlan3700 manual
vpn id 3700 Layer 3 Core vpn id 3700
neighbor 192.168.255.251 encapsulation mpls Intranet neighbor 192.168.255.250 encapsulation mpls
neighbor 192.168.255.252 encapsulation mpls neighbor 192.168.255.251 encapsulation mpls
METRO CORE
DC Core DC Core
Agg Agg
PW – Pseudo Wires
Metro Core Metro Core
l2 vfi vlan3700 manual l2 vfi vlan3700 manual

vpn id
Access 3700 vpn id 3700 Access
L2 Links (GE or 10GE)
L3 Links (GE or 10GE) 192.168.255.252 encapsulation mpls
neighbor
neighbor 192.168.255.253 encapsulation mpls
Server Farm Server Farm
VPLS for Data Center Interconecction
interface Vlan3700
Layer 3 Core interface Vlan3700
no ip address
load-interval 30 Intranet no ip address
load-interval 30
xconnect vfi vlan3700
METRO CORE
DC Core DC Core
VLAN
Agg
3700 Agg
PW – Pseudo Wires
Metro Core Metro Core
interface Vlan3700 interface Vlan3700

Access no ip address no ip address Access
load-interval 30 load-interval 30
xconnect vfi vlan3700 L2 Links (GE or 10GE)
L3 Links (GE or 10GE)
Server Farm Server Farm
Layer 2 Extension
VPLS over GRE
Per VLAN
VFI/GRE
Per VLAN
alternate path
L3 L3 L3
DCI DCI DCI DCI DCI
DCI Si Si Si Si Si Si
L2 L2 L2
L2 Etherchannel L2 Etherchannel L2 Etherchannel
as VSS Is Viewed as VSS Is Viewed as VSS Is Viewed
as One Device as One Device as One Device
Aggregation Aggregation Aggregation

Si Si Si Si Si Si
Si
VSL VSL VSL
MEC
Access Access Access

Si Si
Si
VSL
EoMPLS / VPLS over GRE for DCI
EoMPLS VPLS
§ EoMPLS connectivity over IP-only network § VPLS connectivity over IP-only
§ EoMPLS VCs are established over network.
MPLSoGRE Tunnels § VPLS VCs are established over
MPLSoGRE Tunnels (Requires SIP-
400 on the 6500 with SUP720)
EoMPLS
vpls
instance EoMPLS
instance vpls
instance
instance
CE
MPLSoGRE Tunnels CE CE
MPLSoGRE CE
Tunnels
§ As with L3 VPN requirements, GRE Tunnels provide CE

vpls
MPLS connectivity over IP-only network for L2 transport instance
§ MPLS LDP session is established through the GRE

tunnel
§ L2 frames traverse the IP tunnel (with/without
encryption)
Case Study: VPLS for Metro Ethernet
Requirement: Need to create full-mesh connectivity between separate metro
networks.
Solution: Use VPLS to create transparent bridge layer-2 Ethernet connectivity
between ethernet networks.
Customer A1 Customer A1
CE11 PE1 PE2

L2 Metro L2 Metro CE12
Ethernet Ethernet
CE21 Carrier A Metro Carrier A CE22
Backbone
Provider QinQ
VPLS VPN Name: VPLS-

CarrierA
VPN ID: 1100
PE3 CE13
VCID: 1234 Metro Customer A1
Ethernet
Each PE points to other peer
Carrier A CE23
PE’s loopback address
A Simple VPLS Configuration Example
VLAN Tag Tunnel LabelVC Label
11 3 7 11
N-PE3 MPLS N-PE4
VFI
VFI
N-PE3 N-PE4
interface Loopback0 interface Loopback0
ip address 10.0.0.3 255.255.255.255 VFI ip address 10.0.0.4 255.255.255.255
! Define VPLS VFI l2 vfi vpls11 manual

l2 vfi vpls11 manual vpn id 11
vpn id 11 ß global significant
N-PE1 neighbor 10.0.0.1 encapsulation mpls
neighbor 10.0.0.4 encapsulation mpls
interface Vlan11
! Attach VFI to VLAN interface xconnect vfi vpls11
! VLAN ID is local PE significant
N-PE1 ! Attachment circuit
interface Vlan11
xconnect vfi vpls11 <snip> interface GigabitEthernet5/1
switchport
! Attachment circuit config switchport trunk encapsulation dot1q
interface GigabitEthernet5/1 switchport mode trunk
switchport
switchport trunk encapsulation dot1q
switchport mode trunk
H-VPLS : 2 approaches
To increase scalability and provide better options, solution 2 Hierarchical
models has been suggested in VPLS
“L2” VPLS • H-VPLS with bridge-
(QinQ) (IP/MPLS Core) group domain at access
N-PE 1
U-PE A
CE
STP
• Access domain defined
(QinQ)
PW
by IEEE 802.1ad
CE
U-PE B
N-PE 2
MPLS VPLS § H-VPLS with MPLS the

(H&S PW) (IP/MPLS Core)
edge, using PW EoMPLS
N-PE 1
CE
U-PE A circuit to backhall traffics
MPLS from U-PE to N-PE
PW
CE
U-PE B
N-PE 2
Why H-VPLS?
VPLS H-VPLS
PE
CE
CE CE
PE-rs MTU-s
PE PE
CE
CE PE PE CE PE-rs
PE-rs
CE
CE
PE PE
PE-rs PE-r
PE-rs PE-rs
CE CE
CE
PE
CE
§ Potential signaling overhead § Minimizes signaling overhead

§ Full PW mesh from the Edge § Full PW mesh among Core devices
§ Packet replication done at the Edge § Packet replication done the Core
§ Node Discovery and Provisioning § Partitions Node Discovery process
extends end to end
H-VPLS With MPLS Access
Split-Horizon Rule
MPLS MPLS MPLS

VFI VFI
N-PE3 VFI N-PE4 U-PE4

N-PE1
U-PE3
Split-Horizon Rule
§ Between no-split-horizon VCs à forwarding
§ Between no-split-horizon VCs and split-horizon VCs à forwarding
§ Between split-horizon VCs à blocking
§ Between ACs and VCs à forwarding
§ Between ACs à forwarding
H-VPLS With MPLS Access Example
C-tag 3 7 C-tag 4 8 C-tag 5 3 C-tag C-tag
MPLS MPLS MPLS

VFI VFI
U-PE3 N-PE3 VFI N-PE4 U-PE4

N-PE1
N-PE3 Configuration
! Define VPLS VFI

U-PE3 Configuration l2 vfi vpls11 manual
vpn id 11
! Regular EoMPLS configuration on U-PE neighbor 10.0.0.1 encapsulation mpls
! Use port-mode in this example neighbor 10.0.0.4 encapsulation mpls
neighbor 10.0.0.7 encapsulation mpls no-split-horizon
interface GigabitEthernet2/13
xconnect 10.0.0.3 11 encap mpls ! Attach VFI to VLAN interface
interface Vlan11
xconnect vfi vpls11
! Uplink is MPLS/IP to support EoMPLS
! Attachment circuit is spoke PW for H-VPLS MPLS access
interface GigabitEthernet2/47 ! Downlink is MPLS/IP configuration to support H-VPLS
ip address 10.0.57.2 255.255.255.252 interface GigabitEthernet4/0/1
mpls ip ip address 10.0.57.1 255.255.255.252
mpls ip
VPLS Configuration Example
Autodiscovery
Neighbor statements are no longer used to identify PE VPLS peers
1.1.1.1 / 32 PE-1 PE-2 2.2.2.2 / 32
MPLS Network
l2 vfi Customer-A discovery l2 vfi Customer-A discovery
vpn id 100 vpn id 100
! !
Interface loopback 0 Interface loopback 0

PE-3 3.3.3.3 / 32 ip address 2.2.2.2 255.255.255.255
ip address 1.1.1.1 255.255.255.255
l2 vfi Customer-A discovery

vpn id 100
!
Interface loopback 0
ip address 3.3.3.3 255.255.255.255
Do not apply to H -VPLS provisonning

VPLS: Configuration Example
(BGP Autodiscovery)
1.1.1.1 / 32 PE-1 PE-2 2.2.2.2 / 32
MPLS Network
router bgp 1 PE-3 3.3.3.3 / 32

no bgp default ipv4-unicast
neighbor 2.2.2.2 update-source loopback0
…
address-family l2vpn
neighbor 2.2.2.2 activate “vpn-id” is used as both RD and RT
neighbor 2.2.2.2 send-community extended (VPN-id=RD=RT) (default)
…
exit-address-family
Layer-2 VPN Summary
§ Enables transport of any Layer-2 traffic over MPLS
network
§ Two types of L2 VPNs; AToM for point-to-point and
VPLS point-to-multipoint layer-2 connectivity
§ Layer-2 VPN forwarding based on Pseudo Wires (PW),
which use VC label for L2 packet encapsulation
LDP used for PW signaling
§ AToM PWs suited for implementing transparent point-

to-point connectivity between Layer-2 circuits
§ VPLS suited for implementing transparent point-to-
multipoint connectivity between Ethernet links/sites
High Availability
Carrier Class MPLS Networks
High Availability in MPLS Networks
§ MPLS has incorporated a lot of resilience mechanism
to provide high availability services
P Layer-3 VPNs P Layer-2 VPNs
P MPLS QoS P MPLS TE HA OAM
Core MPLS
Availability Definitions
• The probability that an item (or network, etc.) is operational, and
functional as needed, at any point in time
• Or, the expected or measured fraction of time the defined service,

device or area is operational; annual uptime is the amount (in
days, hrs., min., etc.) the item is operational in a year
• Availability – Equates to the probability of an element, path,

or system being available at a given moment in time.
MTBF – Mean Time Between Failure
MTTR – Mean Time To Repair
Network Provider
Shared Network
User Server
Network Network
What Is High Availability?
Availability DPM Downtime Per Year (24x365)

99.000% 10000 3 Days 15 Hours 36 Minutes
99.500% 5000 1 Day 19 Hours 48 Minutes
99.900% 1000 8 Hours 46 Minutes
99.950% 500 4 Hours 23 Minutes
99.990% 100 53 Minutes
99.999% 10 5 Minutes “High

1 Availability”
99.9999% 30 Seconds
Minimize downtime during failures !
Components of High Availability
Network Operations
Network Center Business
Architecture Alignment
§ Highly resilient architecture § People, Process, & Tools § Partnership between the
and design Business & IT
§ Metrics
§ Standardized designs and § Knowledge of business
§ Industry standard
configurations critical functions and
methodologies (ITIL
applications
§ Network Scalability Framework)
§ Network Delivery Scorecard
§ 7x24x365
§ Service Level Agreements
Carrier Class MPLS
System & Network Level Resiliency
§ MPLS core resiliency
Focus on MPLS path between adjacent or end-to-en nodes nodes
- MPLS control plane resiliency (Fast-IGP, BFD, LDP/IGP Sync, LDP
Session Protection, Graceful Restart Capabilities for LDP and RSVP)
- MPLS data-plane support for Fast Re-Route (MPLS TE-FRR Link and
Node protection )
§ MPLS edge resiliency

Focus on edge device, with PIC (Prefix Independent Convergence)
- PW/VPLS PW tunnel selection
- Pseudowire redundancy
- PIC (Prefix Independence Convergence)
- BGP Next-Hop-Tracking, BGP Fast Peer Deactivation
§ MPLS node resiliency

Focus on MPLS edge (PE) nodes with dual RPs
- Non Stop Routing (NSR)
- Non Stop Forwarding (NSF)
- Stateful Switch-Over (SSO)
Core Failures
§ Detect a core link or node failure as soon as possible

“Interrupt driven” link down detection (aka LOS) on GE ports
BFD or RSVP Hellos
§ Avoid to touch BGP prefixes
Re-routing to another PE should not be required (depends on your PE-P link design
though)
Converge IGP fast to BGP Next-hop
§ Two high-level approaches
IGP/LDP convergence only (Fast IGP and BGP tuning!)
TE/FRR for <50msec restoration goal (creating mesh of TE tunnels)
§ Protocols in use: ISIS/OSPF, BGP, BFD, LDP, TE/FRR
IP/MPLS High Availability
Fast Convergence
• Network convergence is the time needed for traffic to be rerouted
to the alternative or more optimal path after the network event.
Network convergence requires all affected routers to process the
event and update the appropriate data structures used for
forwarding
• Fast Convergence is the tools to achieve Network Convergence
as fast as possible:
Fast Detection of event has occurred (link/node failure)
Fast Propagation of the event (flooding)
Fast Processing of the event (computation)
Fast Update of related forwarding structures (RIB/FIB)
§ Two approaches
Fast IGP (alternate path selection by Rebuilding the topology quickly)
Fast Reroute (protection by pre-computed path)
Fast convergence
Fast detection is key
• Detection of Link failure
– Direct detection of Link down: LoS (loss of Signal)*
– Indirect detection: BFD, CFM (802.1ag)
– Consider using IP Event Dampening to quell link flaps
§ Detection of Node Failure
– BFD
– Fast IGP Hellos for OSPF, IS-IS, PIM and RSVP
– Next-Hop Tracking for BGP
– Triggered RPF Check for PIM (Multicast)
MPLS - SP A
C-A-R2
C-A-R1 C-A-R4
C-A-R3
HQ-W 1
BR-W 1
Link or Device Failure

*Carrier Delay
Separate Carrier Delay up/down
§ Facilitates the existing carrier-delay interface command
Router(config-if)#carrier-delay ?
<0-60> Carrier Transitions delay seconds
down Carrier Down Transitions
msec delay specified in milliseconds
up Carrier Up Transitions
§ Down Convergence (normally set to 0)

Router(config-if)#carrier-delay down msec ?
<0-1000> Carrier Down Transitions delay milliseconds
§ Up convergence (depending on Layer 2 switch)
Router(config-if)#carrier-delay up msec ?
<0-1000> Carrier Down Transitions delay milliseconds
Router(config-if)#carrier-delay down ?
<0-60> Carrier Up/Down Transitions delay seconds
IP Event Dampening – Algorithm
Illustration
Actual
interface
state
Maximum penalty
Accumulated Suppress threshold

penalty
Reuse threshold
Interface
state seen
by routing
protocols
High Availability
Link Failure Detection
§ POS
AIS alarm is used to trigger FRR protection, detected within a few ms
SDH/SONET has end to end signalling
§ GE
LOS based GE triggers FRR when GE interface goes down
Can be as fast as POS but should only be deployed over dark fibre or optical
network with end to end signalling
Yes: LoS or signaling
Yes: with e2e signaling SDH SDH
No: BFD will help but

might not be as fast
BFD Protocol Overview
§ Lightweight hello protocol
§ Configurable transmit and receive time intervals
§ Neighbors negotiate rate at which to send BFD control packets
§ Neighbors exchange hello packets at negotiated regular intervals
§ If a BFD control packet is not received in the negotiated detect time, the
peer is indicated as down
§ BFD sessions are established by the clients e.g. OSPF, IS-IS, EIGRP,
BGP
BFD Control Packets

EIGRP EIGRP
IS-IS BFD BFD IS-IS
BGP BGP
OSPF OSPF
Fast IGP (OSPF, IS-IS)
Fast ISIS/OSPF introduced msec timers and throttling for Update
(LSA/LSP) generation and SPF computation
• Fast LSA/LSP Generation after Initial Event
Exponential Backoff (Repeated events increase regeneration delay)
• Inmediate SPF/PRC Calculation
Exponential Backoff algorithm protect the router as the cost of
convergence time
Partial SPF/PRC
• Fast Flooding of LSA/LSPs
Pacing timer is 33ms by default (jittered by 10%)
• Prefix Prioritization
/32 IPv4 and /128 IPv6 prefixes are classified by default in Medium Priority
Fast IGP is a key component for MPLS Networks !
MPLS Convergence = Fast IGP + LDP + FRR
Fast IGP Exponential Backoff
timers throttle lsa all <lsa-start> <lsa-hold> <lsa-max>
timers throttle spf <spf-start> <spf-hold> <spf-max>
All values are in ms
NOTE: MinLSArrival must be <= lsa-hold
Events Causing LSA Generation timers throttle lsa all 10 500 5000
1000
t1 t2 time [ms]
LSA Generation
500 5000 5000
time [ms]
LSA Generation – Back-off Alg.
500 1000 2000 4000 5000
t1+10 t2+10 time [ms]

previous LSA generation at t0 (t1 – t0) > 5000 ms
Convergence in MPLS Networks
LDP IGP Sync
• Problem:
– Traffic hit on link up when IGP converges before MPLS (LDP)
– Traffic loss when no LDP session on outbound interfaces
– Traffic hit/loss for any VPN traffic or multi-label traffic
• Solution:
– Makes sure that no traffic is routed towards links on which MPLS
(LDP) is not yet converged
– Synchronize IGP with LDP so that LDP controls IGP metric for given
link, depending on LDP state on given link
– A link is advertised by IGP with max metric if LDP session is not yet
up or not yet converged (label bindings exchange)
LDP IGP Sync (cont’d)
• IGP sync feature enabled only under IGP
router(config-isis-if-af)#
mpls ldp sync [ level <1-2> ]
router(config-ospf)#, (config-ospf-ar)#, (config-ospf-ar-if)#

mpls ldp sync
• To delay declaring sync up, a delay time can be configured under LDP:
router(config-ldp)#
igp sync delay seconds
LDP Session Protection
• Problem:
– Link up: IP converges much faster/earlier than MPLS (LDP).
– Link up, MPLS traffic loss until MPLS converges .
– Link flap: LDP session also flaps.
• Solution:
– Protect an LDP (link) session by means of “parallel” source of
targeted discovery/hello.
– Given IP connectivity, LDP session is kept alive and neighbor label
bindings are maintained while link is down.
– Minimizes traffic loss as well as enables faster MPLS convergence
on link coming up.
router(config-ldp)#
session protection [for peer-acl] [duration seconds]
LDP Local Label Allocation Filtering
§ Per default LDP generates label bindings for all IGP or statically
derived prefixes
§ To optimize MPLS L3VPN end2end VPN convergence, people
want to limit label bindings to PE loopbacks in order to make IGP
converge faster
§ This feature allows use of prefix-lists to control label bindings
being generated
tuonno(config)#mpls ldp la tuonno(config)#ip prefix-list test seq 4 permit ?

tuonno(config-ldp-lbl)#allocate ? A.B.C.D IP prefix <network>/<length>,
global Specify global Routing/Forwarding instance e.g., 35.0.0.0/8
tuonno(config-ldp-lbl)#allocate global ? tuonno#sh ip prefix-list

host-routes allocate local label for host routes only ip prefix-list test: 2 entries
prefix-list Specify a prefix list for local label filtering seq 5 permit 1.1.0.0/23
<cr> seq 34 deny 32.0.0.0/3
tuonno(config-ldp-lbl)#allocate global prefix-list ?
WORD IP prefix-list for destination prefixes;
name or number (1-99)
Traffic Engineering / Fast Re-Route
Protected Node
Protected Link Primary TE Tunnel
X
X
CEoP
CEoP
Link Protected FRR Tunnel Node Protected FRR Tunnel
Deployment scenarios
P
§ Scenario 1 : One-Hop TE LSPs on P-P links
P P
PE
PE LDP LSP logically nested into one-hop TE LSP
Logical nesting, as there is no label on one-hop LSP (if PHP
active)
P P P
P P P
§ Scenario 2 : Full mesh of P nodes
PE PE TE capabilities in P network
LDP/TDP LSP nested into TE LSP
P P P
P P P § Scenario 3 : Full mesh of PE nodes

PE
PE TE capabilities between PEs
PE-PE traffic is traffic engineered by means of TE
LSP
P P P
100 PE / 20 P
Scenario 1 Scenario 2 Scenario 3
15 FRR links
BRKRST-1101 # of TE LSP 30 (2x15) < 380 (20x19)
9900 (100x99)
Cisco Public 307
1-Hop Tunnel Deployment
Requirement: Need Protection Only — Minimize Packet Loss of
Bandwidth in the Core
Solution: Deploy MPLS Fast Reroute for Less than 50ms Failover Time
with 1-Hop Primary TE Tunnels and Backup Tunnel for Each
Service Provider
Backbone
VPN Site A Primary 1-Hop TE Tunnel

VPN Site B
Backup Tunnel
Physical Links
Edge Failures
§ This is the harder part

§ Think about different Scenarios and their implications
L2 VPN versus L3 VPN
CEs single or dual homed
§ Protocols in use: ISIS/OSPF/RIP/EIGRP/Static, BGP,

LDP, BFD,
MPLS Edge resiliency for L3 VPN
• Avoid that ingress PE need to converge to other egress PE
• If BGP convergence needed on ingress PE, try to make it fast
RR1 RR2
PE3
CE3
P1 P2
PE1
CE1 PE2 CE2
P3
MPLS Core
Technologies to consider for convergence

• Core options:
options:
– P Links/Node protection è FRR
– PE/P IGP restoration è Fast IGP + LDP
• Edge
Edge::
– PE
PE--PE iMP-
iMP-BGP è Fast BGP via RR
– CE
CE--PE edge routing è IGP or BGP / OAM
BGP Convergence
§ BGP Convergence is key for MPLS L3 VPN Services

BGP Used for Distributing VPNv4 prefixes among PEs
• BGP and IGP Convergence tuning have a different focus
IGP Convergence - Rebuild the topology quickly following an event
BGP Convergence - Transfer large amounts of prefix information very
quickly
• The magnitude of time involved is different
IGP - Sub-Second
BGP - Seconds to Minutes
• Fast IGP Convergence plays a role in maintaining availability for
BGP prefixes
Often topological changes can result in no BGP changes, the IGP
updates the next-hop information for BGP prefixes
Site-to-Site Convergence in MPLS
VPN Environment
Receipt of Local M P-BGP
Routes into BGP Table Table Receipt of Advertised
on the PE Router RR Routes into BGP Table
M P-BGP on the PE Router
Vrf Table
Table
Vrf
Table RIB FIB
RIB FIB T4 T4 T5
LC-HW LC T3 Advertisement LC-HW
FIB
LC
FIB
FIB FIB
Local_PE of Routes to Remote_PE
MP-BGP
Peers = 5 sec T6
T2
Import of Local
Routing T7 Import of Newly
Information into the T1 Received Routes
Corresponding into Local
Advertisement of
Ingress VRF Routes to CE VRF’s Routing
Routing Table PE Router Table = 15 sec
Receives a Routers = 30 sec
Routing Update
from a CE Router T8
Local_CE = 30 sec Remote_CE
Processing of Incoming
Updates by the CE Router
§ Convergence depends on the service provider network

§ Site-to-site convergence heavily dependant on MP-BGP convergence in the provider network
§ End-to-end convergence sum of highlighted convergence points T1 thru T8
Convergence in MPLS VPN
Summary (Theoretical Convergence)
§ Two sets of timers; first set consists
of T1, T4, T6, and T7; second set
comprises of T2, T3, T5, and T8 T4=5s T4=5s
§ First set mainly responsible Local_PE T3 T5 T6=15s

for the slower convergence RR Remote_PE
T2 T7=30s
unless aggressively
T1=30s
tweaked down T8
§ Theoretically sums up Local_CE Remote_CE
to ~ 85 seconds [30 (T1)+5*2
(T4)+15(T6)+30 (T7)]
Max Conv. Time
§ Once different timers are tuned, PE-CE Protocol
Max Conv. Time
(Default Settings)
(Timers Tweaked
convergence mainly depends Scan=5, Adv=0)
on T6; min T6=5 secs BGP ~85+x Seconds ~5+x Seconds

OSPF ~25+x Seconds ~5+x Seconds
§ Assuming ~“x” secs for T2, EIGRP ~25+x Seconds ~5+x Seconds
T3, T5, and T8 collectively RIP ~85+x Seconds ~5+x Seconds
Convergence Basics – BGP Scanner
How quickly can BGP propagate the change throughout the network?
• BGP Scanner plays a key role in convergence

• Full BGP scan runs every 60 secs and performs multiple
housekeeping tasks
Validate nexthop reachability
Validate bestpath selection
Route redistribution and network statements
Conditional advertisement
Route dampening
BGP Database cleanup
§ BGP Scanner period configurable (min = 15 seconds), but lowering this value
not recommended due to high CPU load :
bgp scan-time X
• Import scanner runs once every 15 seconds
Imports VPNv4 routes into vrfs
bgp scan-time import X
Next-Hop Verification – BGP Scanner
§ BGP Scanner runs every 60 seconds (configurable) and performs

various house-keeping tasks:
Validate nexthop reachability
Validate bestpath selection
Route redistribution and network statements
Conditional advertisement
Route dampening
BGP Database cleanup
§ Invalidates paths whose NH is unreachable
§ Performs best-path when metric to NH was changed
§ Periodic nature of BGP scanner delays reaction to NH failures (for
example PE node failures) for up to 60 seconds
§ BGP Scanner period configurable (min = 15 seconds), but not
recommended due to high CPU load
è We need something else to react to NH changes quicker
BGP NHT – Next Hop Tracking
Event driven model allows BGP to react quickly to IGP changes
• Every 60 seconds the BGP scanner recalculates bestpath for all prefixes
Check each BGP nexthop’s IGP cost every 60 seconds (Polling model)
Invalidates paths whose NH is unreachable
Performs best-path when metric to NH was changes
• Changes to the IGP cost of a BGP nexthop will go unnoticed until
scanner’s next run
IGP may converge in less than a second (fast convergence)
BGP may not react for as long as 60 seconds L
Periodic nature of BGP scanner delays reaction to NH failures (for example PE
node failures) for up to 60 seconds
• Need to change from a polling model to an event driven model to improve
convergence
BGP Next Hop Tracking: BGP is informed when the IGP cost to a BGP nexthop
changes (Event driven model)
BGP NHT will trigger a lightweight “BGP Scanner” run
Enabled by default ([no] bgp nexthop trigger enable)
PE node failure
PE2 CE2
CE1 PE1 P2 VPN1
P1
HQ
VPN1 PE3 CE3
site
§ UNREACHABILITY is detected by IGP

§ BGP Next-Hop-Tracking trigger BGP scanner (VRF scoped)
§ BGP NHT will trigger a lightweight “BGP Scanner” run
Bestpaths will be calculated
Waits 5 seconds before triggering NHT scan (bgp nexthop trigger delay <0-100>)
None of the other “Full Scan” work will happen
Dampening is used to reduce frequency of triggered scans
§ Dependencies: router isis
spf-interval 50 150 20
è Fast Convergence for IGP Prefixes
fast-flooding 15
è Prefix Prioritization (Next-Hops) router bgp 1
è unique RD per VPN bgp nexthop trigger delay 1
How quickly can the entire BGP network converge?

BGP Prefix Independent Convergence (PIC)
§ Data plane convergence until the control plane

converges and updates the FIB
§ BGP PIC allows sub-second convergence time for BGP
routes on specific failure scenarios no matter the
amount of prefixes to be updated:
PIC CORE: failure in the core resulting in a new path to reach the
BGP NH
PIC EDGE: PE or eBGP link failure
§ Based on new FIB implementation

Hierarchical FIB structure
§ Convergence time does not depend of the number of

BGP prefixes anymore !!
BGP PIC Core Details
Flattened FIB Hierarchical FIB
Faster Convergence Post-Failure:
Prefix-Independent-Convergence Effect
iox-crs1-P-ISIS-BGPipv4-dpi2i-021307_154358-l-nlb
Agilent measurements
400
350
0%
300 50%
traffic loss (msec) 250 90%

100%
200 0%
150 50%
90%
100 100%
50
0
0 1000 2000 3000 4000 5000 6000 7000
BGP PIC
prefix nr
effect
§ Testbed: Tier1 ISP topology, CRS1, IOX3.5, 5000 ISIS prefixes, 350k IPv4 BGP
dependents to impacted BGP nhop
§ When ISIS converges, all the BGP dependents immediately leverage the ISIS
convergence
Core MPLS
RR Failure
RRB1 RRA1 PE2 CE2

CE1 PE1 VPN1
RRB2 RRA2 HQ
VPN1 PE3 CE3
site
• PE1 receives routes via both RR1 and RR2, select RR1 for bestpath
• RR1 becomes unreachable or blows up
• Traffic flows until RR1-PE1 BGP session is detected down
• PE1 will delete the bestpath
•The other path via RR2 is not available for immediate import L
• It is imported during the next import scanner run !
the solution is to load-balance RR advertisement

è provision a unique RD per PE per customer.
è maximum-paths 2 import 2
Convergence in MPLS VPN :
MPLS VPN PE-CE Link Protection
Traffic Is Dropped
by PE11 until PE2 RR
converges PE11
CE1 PE2 CE2

171.68.2.0/24
PE12
§ 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.
§ MPLS VPN PE-CE Link Protection
Upon a PE-CE link failure, the egress PE (Point of Local Repair) switches VPN
traffic to an alternative egress PE before the control plane has converged
The feature improves VPN end-to-end convergence under certain scenarios
Convergence in MPLS VPN :
VPN Fast Convergence—PE-CE Link Failure
!
Traffic Is PE-1: Point of
Local repair
RR ip vrf green
rd 300:11
Redirected protection local-prefixes
by PE11 PE11 !
CE1 PE2 CE2

171.68.2.0/24
MPLS Backbone
Site A Site B
PE12 VPN Traffic
Redirected VPN Traffic
§ ‘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
Configuring MPLS VPN –
BGP Local Convergence
§ Can be enabled/disabled on a per VRF basis
§ Cleanup Timer of 5 minutes is not configurable
tuonno(config-vrf)#protection ?
local-prefixes Enable protection for local prefixes
tuonno#sh ip vrf detail vrf1

VRF vrf1 (VRF Id = 1); default RD 4711:1; default VPNID <not set>
No interfaces
VRF Table ID = 1
Export VPN route-target communities
RT:4711:1
Import VPN route-target communities
RT:4711:1
No import route-map
No export route-map
VRF label distribution protocol: not configured
VRF label allocation mode: per-prefix
vrf-conn-aggr for connected and BGP aggregates (No Label)
Local prefix protection enabled
BRKRST-1101 © 2009 Cisco Systems, Inc. All rights reserved. Reference:

Cisco Public EDCS-500998 324
MPLS VPN – BGP Local Convergence
Test Results
PE-CE Link Protection Convergence
14000
12000
Convergence Time (ms)
10000
Min - ON
Ave - ON
8000
Max - ON
Min - OFF
6000
Ave - OFF
Max - OFF
4000
2000
0
100 200 500 1000
Protected Routes
Source: Ted Qian (NSSTG PM), EDCS-574768
Fast Convergence Key Takeaways
§ Fast detection is key
LoS, BFD & IGP Fast-hellos
NHT
§ Fast Convergence based on core and edge optimization
Core optimization: FRR + Fast IGP + LDP
Edge optimization: Fast MP-iBGP, Fast BGP
§ Unique RD is a key element
§ Convergence affected with Label rewrite (ie impact of full routing) -
> requires PIC
Site-to-Site Convergence Tuning
RR
Designated VPNv4 RRs
BGP Multipath, NHT, PIC,

Local Convergence, Unique RD,
Local_PE MAI=0, Tune Import Scanner
Remote_PE
BGP Multipath, BFD

IGP/BGP Timers 1/3 IGP Tuning/MPLS TE
LDP/IGP Sync
Local_CE Remote_CE
Performance
Routing (OER)
L2VPN Convergence Elements
End-2-End Failure Scenarios
Fail #5 Fail #4 Fail #3 Fail #2 Fail #1

PE3 PE1 U-PE1
Agt Port Agt Port

XXX XXX
EoMPLS or
Ethernet (QinQ)
VPLS Access
Core
PE4 PE2 U-PE2
Protection Schema:
Fail 1: Attachment Circuit Redundancy
Fail 2: PW re-routing or TE/FRR or PW-RED
Fail 3: PW-RED with VPLS MAC Withdrawal TLV
Fail 4: VPLS PW re-routing or TE/FRR
Fail 5: Attachment Circuit Redundancy or Dual-Homed CE
50 msec TE/FRR Protection for H-VPLS
Fail #2 Fail #1
PE3 PE1 U-PE1

Primary-TE
Primary - PW
Agt Port Agt Port
XXX XXX
EoMPLS
VPLS
Access
Core
Backup-TE
PE4 PE2 U-PE2
Protection Schema:
Fail 1: TE/FRR or PW re-routing or PW-RED
Fail 2: VPLS PW re-routing or TE/FRR
PW High Availability
PE1 PE3
P1 P3
Site1 P2 P4
Site2
PE2 PE4
CE2
CE1
§ Failure in the Provider core mitigated with link redundancy and FRR
§ PE router failure – PE Diversity
§ Attachment Circuit failure – Need Pair of Attachment Ckts end-to-end
§ CE Router failure – Redundant CEs
L2VPN Networks—Dual Homed PW
Sites Without Redundancy Feature
interface e 1/0.1
encapsulation dot1q 10
xconnect <PE3 router ID> <VCID> encapsulation mpls
x
PE1 PE3
P1 P3
Site1 P2 P4 Site2
PE2
PE4
CE1 CE2
CE3
Interface e1/0.1
encapsulation dot1q 10
xconnect <PE4 router ID> <VCID> encapsulation mpls
Data Center Option Utilizing Layer 2 VPN to Provide High Availability
Between Two Data Centers and Two Service Providers
6500-DCN-SWITCH PE1-COREB
! !
interface gigabitethernet 1/0/1 COREA interface gigabitethernet 1/0/0
channel-group 1 mode on no switchport
switchport xconnect X.X.X.PE2 70 encapsulation mpls PE2-COREA
switchport trunk encapsulation dot1q __________________________________________________
switchport mode trunk PE2-COREB
! !
interface gigabitethernet 1/0/2 COREB interface gigabitethernet 1/0/0
channel-group 1 mode on no switchport
switchport xconnect X.X.X.PE1 70 encapsulation mpls PE1-COREA
Data Center Option Utilizing Layer 2 VPN to Provide Physical High
Availability Dual Switches Between Two Data Centers STP Free
Topology
6500-A
6500-A 6500-B PE1-COREA

! ! interface gigabitethernet 3/0 <-6500 A
interface gigabitethernet 1/0/1 interface gigabitethernet 1/0/1 xconnect 10.1.1.2 20 encapsulation mpls
channel-group 1 mode on channel-group 1 mode on !
switchport trunk encapsulation switchport trunk encapsulation interface gigabitethernet 4/0 <-6500 B
dot1q dot1q xconnect 10.1.1.2 40 encapsulation mpls
switchport mode trunk switchport mode trunk
! !
interface gigabitethernet 1/0/2 interface gigabitethernet 1/0/2
channel-group 1 mode on channel-group 1 mode on
switchport trunk encapsulation switchport trunk encapsulation
dot1q dot1q
switchport mode trunk switchport mode trunk
! !
interface Port-channel1 interface Port-channel1 PE1-COREB
interface gigabitethernet 3/0 <-6500 A
switchport trunk switchport trunk
xconnect 10.1.1.2 20 encapsulation mpls
! ! !
interface gigabitethernet 1/0/4 interface gigabitethernet 1/0/4
interface gigabitethernet 4/0 <-6500 B
switchport mode access switchport mode access xconnect 10.1.1.2 40 encapsulation mpls
Switchport access vlan 10 Switchport access vlan 10
Data Center Option Utilizing Layer 2 VPN
and Virtual Switching New Features
PE1-COREA
interface gigabitethernet 3/0 < -6500 B PE1-COREB
interface gigabitethernet 3/0 < -6500 A
! xconnect 10.1.1.1 20 encapsulation mpls
!
interface gigabitethernet 4/0 < -6500 B
xconnect 10.1.1.2 40 encapsulation mpls interface gigabitethernet 4/0 < -6500 B
High Availability in L2VPN Networks
PE3
PE1
P1 P3
Primary
Site1 Primary
Standby
P2 P4 Site2
Primary
PE4
§ If PE3 fail or PE3 attachment circuit fail, PW will go down. TE/FRR won’t
help this scenario.
§ Solution – create backup PW between PE1 and PE4. When primary PW
goes down, backup PE will come up. Traffic will continue between CEs.
§ Primary and backup PW can be between same pair of PEs, with different
Attachment Circuit, or between different pair of PE like this example
Dual Homed PW Sites—
with Redundancy Feature
x
PE1 PE3
P1 P3
CE2
Site1 P2 P4 Site2
PE2
PE4
CE3
CE1
pe1(config)#int gig 0/0.1

pe1(config-subif)#encapsulation dot1q 10
pe1(config-subif)# xconnect <PE3 router ID> <VCID> encapsulation mpls
pe1(config-subif-xconn)#backup peer <PE4 router ID> <VCID>
Pseudowire Redundancy
ACR: Attachment Circuit Redundancy
MR-APSAPS 1+1
Node B Primary PW
Working
Backup PW Protection
“PWE3 Redundancy: A Redundant L2 Connection both to the Active and

Backup APS Interfaces on RNC and BSC”
Can be used for redundancy of adaptive clocking.
Example setup:
§ RNC and BSC are using MR-APS (traditional)
§ “Primary PWE3” from NodeB (ATM) and BTS (TDM)
§ “Backup PWE3” from NodeB (ATM) and BTS (TDM)
§ Force APS failover on RNC and BSC, MR-APS on Aggregation router
Data Center Option utilizing Layer 2 VPN to Provide Physical High
Availability Dual Switches Between Three Data Centers and One Transit
Data Center
X
PE1 PE2
interface gigabitethernet 3/0 interface gigabitethernet 3/0
xconnect 10.1.1.3 20 encapsulation mpls backup peer xconnect 10.1.1.3 30 encapsulation mpls backup peer
10.1.1.2 200 10.1.1.1 200
Data Center 3 6500 Switch

! PE3
interface gigabitethernet 3/0 interface gigabitethernet 3/0
switchport trunk encapsulation dot1q Q-in-Q xconnect 10.1.1.1 20 encapsulation mpls
!
interface gigabitethernet 4/0
switchport mode trunk Q-in-Q PE3
interface gigabitethernet 4/0
H-VPLS MPLS Access Redundancy
Overview
PW redundancy
N-PE11
N-PE21
U-PE11
P P VFI
VFI
P P
VFI VFI
P
N-PE12
UPE12 N-PE22
Link blocked by SPT,

REP or FlexLink Active Pseudowire
§ VPLS PW full mesh in the core

§ U-PE uses PW redundancy to create active/backup PW to two N-PEs
§ If primary N-PE fail or all of the primary N-PE’s downside MPLS links fail,
it will cause active PW fail. U-PE will switch over to the backup PW
§ Link/node failure within MPLS cloud will trigger MPLS TE/FRR, PW will
cut-over to different TE tunnel. In this case, U-PE will keep original active
PW instead of switchover to backup PW.
H-VPLS MPLS Access Redundancy
MAC Withdrawal
N-PE11
N-PE21
U-PE11
P P xVFI
VFI
P P
VFI VFI
P MAC withdrawal
N-PE12
UPE12 N-PE22
§ MAC withdrawal solves traffic blackhole due to outdated MAC tables after PW
switchover; i.e. as long as VFI and VC’s are up MAC entries are active until
aged out.
§ U-PE11 switchover to backup PW if primary PW goes down
§ When backup PW come active, U-PE generates MAC withdrawal message via D-
LDP to N-PE12. N-PE12 will flush it’s MAC table and forward this message to its
peers
§ After receive the MAC withdrawal message, remote PEs will flush MAC address
tables.
§ Packet from N-PE21 will flood to all N-PEs. Flooding will stop if PE receive
packet from the reverse direction.
Hot Standby Pseudowire Concept
Minimize service downtime due to an unavailability of the backup PW
Pri PW
PE1 PE2
Backup PW PE3
§ Hot Standby pseudowire redundancy reduces the convergence time by

removing the time necessary to establish the backup PW and rebuild the FW
table
Local label is allocated/mapped and ready to be sent
§ PE1 has 2 PW, active and standby. Standby PW is established but not
forwarding.
§ PW status is signaled in LDP PW status code (Status Bit). When the primary
PW goes down, the active status is signaled to the secondary neighbor.
§ The next step to reduce the PW switchover time is to shorten the failure
discovery time of the primary PW. Features like BFD VCCV are envisaged to
provide short failure detection times.
§ Additional extensions introduced to support “Standby” mode:
draft-muley-dutta-pwe3-redundancy-bit
Draft-nmcgill-l2tpext-circuit-status-extensions
MPLS Pseudowire Status
Signaling Procedure
§ PW label mapping message is signaled as soon as the PW is provisioned,
irrespective of the PW status.
AC PE1 PE2 AC
LDP Notification Message
PW Status TLV
PW Status Code
§ PW Status Signaling method selected if supported by both peers.

§ PEs exchange label mapping messages upon PW configuration.
§ Simple Label Withdraw status method will be used if one of the peers
doesn’t support PW Status Signaling.
§ PW label won’t be withdrawn unless AC is administratively down or the
PW configuration is deleted.
§ PW state set to “down” if the Label mapping is not available.
§ Capability is on by default.
PW Preferential Forwarding Status Bit
Failure Log: AC in Standby
Pri PW
PE1 PE2
Standby PW PE3
PE1-22#sh xconnect all
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State

UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+---------------------
UP pri ac Fa3/1(Ethernet) UP mpls 193.193.193.9:90 UP
IA sec ac Fa3/1(Ethernet) UP mpls 193.193.193.3:30 SB
mLACP With Two Sided
VPWS/VPLS Redundancy
MPLS
PW 2 L3
L2 Standby Active
Standby PE1 PE2 Active
PW 1
Standby Active
PW 3
L1 Standby
L4
DHD1 Active DHD2
Active PE4 Standby
PE3 E Active PW 4
Standby
§ VPWS
Two PEs form one virtual group on each site, one PE is primary the other is backup
PE’s send primary/backup information during PW signaling
PW with both sides status <active> are established, others are hot standby
MPLS uplinks, attachment circuits and PW status tracking
Message exchange within virtual group (for mLACP it is ICC) with redundancy status
§ VPLS
PW will be active between PE’s with active access circuits only
Single active path through VPLS domain between PE virtual group
L2 VPN PE Redundancy Summary
§ 50 msec TE/FRR for P node and link protection
§ PW redundancy for PE node protection
PW switchover can be as fast as second (or sub-second)
Hot Standby PW (active-active model, VC independent)
§ End-to-End EoMPLS/VPLS Redundancy Solution
P-to-P EoMPLS PW for single or dual homed CEs
H-VPLS with both MPLS access and Ethernet access
Pw Redundancy with VPLS MAC address withdrawal
Full integration with Access technologies (MST, REP)
§ Two-way PW redundancy via mLACP
End-to-End L2VPN Redundancy Overview
H-VPLS MPLS Aggregation (H-)VPLS Ethernet Aggregation
MPLS P VPLS Core L2 switch
MPLS PE
n-PE3 2
u-PE1 n-PE1
1 5
3 1
4
5
U-PE2 n-PE2 n-PE4
(H-)VPLS Pseudo wires Failure 2 – L2 network link or node failure

Rapid STP, REP
Failure 1 – MPLS network link or P node failure
TE/FRR with fast LoS Detection
Failure 4 – Ethernet aggregation n-PE node failure
Failure 3 – MPLS aggregation n-PE node failure MST over special PW with VPLS MAC withdrawal
REP with VPLS MAC withdrawal
PW redundancy with VPLS MAC withdrawal
Failure 5 – u-PE to access network failures

Access Redundancy
MPLS High Availability
§ MPLS network resiliency
Focus on MPLS path between adjacent MPLS nodes or end-
to-end path in MPLS network
– Failure detection enhancements for MPLS control plane
protocols
– Resilience and Restoration under Link and Node Failures
§ MPLS node resiliency
Focus on MPLS edge (PE) nodes with dual RPs
Cisco Non Stop Forwarding (NSF)
• Continuous MPLS packet forwarding during RP switch-over while MPLS
peering relationships are reestablished via Graceful Restart (GR)
procedures
Cisco Stateful Switch-Over (SSO)
• Active RP synchronizes (checkpoints) MPLS protocol state information with
standby RP
• MPLS control plane state preserved after RP switchover
Cisco NSF/SSO
Nonstop Forwarding with Stateful Switchover
Non Stop Forwarding (NSF) with Stateful Switch Over (SSO) allows the standy Supervisor to
take control and continue forwarding data in the event of the active Supervisor failing.
• Cisco NSF with SSO

New active
exchanges info with
neighbors, rebuilds
Increases availability at key edge points routing information,
validates forwarding
Employs dual processors information
STANDBY
STANDBY
ACTIV
• Cisco SSO
E
Allows the standby RP to take immediate
control and maintain connectivity Cisco
Express
Cisco
Express
protocols Forwarding Forwarding
Cisco
Maintains connectivity for L2 protocols Express
Line Card
Line Card
Line Card
Line Card
Forwarding
• NSF
Continues to forward using current FIB
while routing information (RIB) is
validated
Stateful Switchover (SSO)—Zero
Layer 3 (BGP, OSPF, IS-IS) recovers Interruption in Layer 2 Connectivity
routing information from neighbors, Nonstop Forwarding (NSF)—
updates Continuous Packet Forwarding
BRKRST-1101 with
© 2009 Cisco Systems, Inc. All rights Minimal Packet Loss
reserved. Cisco Public 348
348
NSF-Aware Neighbors
Graceful Restart procedures for OSPF, IS-IS and BGP
NSF-capable router
Standby
Active
SSO
NSF-aware
neighbor
Failover time:
0-3s
NSF-aware
neighbor
Line Cards
Predictable traffic path
No route Flap
•NSF-aware neighbors do not reconverge •NSF-capable router rebuild their L3
•NSF-aware neighbors help the NSF-capable routing protocol database from
router restart neighbor
•NSF-aware neighbors continue forwarding •Data is forwarded in hardware based
traffic to the restarting router on pre-switchover CEF information
while routing protocols reconverge
MPLS High Availability (HA)
NSF/SSO for MPLS
Proven Cisco NSF/SSO Technology for MPLS LDP and VPNs
§ Extended MPLS NSF/SSO capabilities (Packet forwarding with
no disruption during RP-switchover) for MPLS LDP, RSVP and
MPLS VPNs (including Inter-AS and CsC)
§ MPLS HA—LDP NSF/SSO
1. Checkpointing local label bindings to backup RP
On devices with route processor redundancy
2. LDP graceful restart capability

On participating PEs, RRs,and P routers
MPLS HA
3. Checkpointing refreshed/new local label bindings
LDP
§ MPLS HA—BGP VPNv4 NSF/SSO MP-BGP
1. MPLS VPN checkpointing capability RSVP
2. BGP graceful restart capability
§ Eliminates service disruptions at IP/MPLS edge IP HA

BGP
§ Preserves sessions and mitigates outage impact
OSPF
(Network downtime, SLA penalties) EIGRP
§ Increases operational efficiency through ISSU IS-IS
High Availability NSF/SSO
LDP Graceful Restart Operation
LDP GR: 20.0.0.0/8:: updating Rb(config)#mpls ldp LDP GR: 10.0.0.0/8:: updating
binding from 1.1.1.1:0, inst 1:: graceful-restart binding from 1.1.1.1:0, inst 1::
marking stale; LDP Adj LDP Adj marking stale;
UP UP
Primary
A Standby C
LDP B LDP
Session Session
Reset Reset
LDP GR: 20.0.0.0//8:: LDP GR: 10.0.0.0//8::
refreshing stale binding from LDP refreshing stale binding from
1.1.1.1:0, inst 1 -> inst 2 Restart 1.1.1.1:0, inst 1 -> inst 2
§ LDP paths established, LDP GR negotiated

§ When RP fails on LSRb, communication between peers is lost; LSRb encounters a LDP
restart, while LSRa and LSRc encounter an LDP session reset
§ LSRa and LSRc mark all the label bindings from LSRb as stale, but continue to use the same
bindings for MPLS forwarding
§ LSRa and LSRc attempt to reestablish an LDP session with Rb
§ LSRb restarts and marks all of its forwarding entries as stale; at this point, LDP state is in
restarting mode
§ LSRa and LSRc reestablish LDP sessions with Rb, but keep their stale label bindings; at this
point, the LDP state is in recovery mode
§ All routers re-advertise their label binding info; stale flags are removed if a label has been
relearned; new LFIB table is ready
MPLS VPN: BGP Graceful Restart Procedure
RFC 4781 (January 07)
eBGP, IGP MP-iBGP eBGP, IGP
LSP
CE1 PE1 LDP P LDP PE2 CE2

Traffic Flow
IGP (ie: OSPF)
Traffic is forwarded continuously

§ PE1-PE2 exchange graceful restart cap (restart time, AFI/SAFI, etc.) and routing
information via BGP
§ PE2 RP fails and continues forward traffic ; PE1 retains its last Adj-RIB-In and
forwarding state learned from PE2; entries learned from PE2 as stale; PE1
continues to forward traffic to PE2
§ PE2 RP re-establishes TCP session with PE1; PE1 sends BGP updates from Adj-
RIBs-Out to PE2 along with the label mapping; PE2 updates its Loc-RIB, FIB,
Adj_RIBs-Out and advertise its routes to PE1; on completion sends End-of-RIB
marker
§ PE2 updates its Adj-RIBs-In, deletes stale entries, runs its decision process,
updates its Loc-RIB, FIB, and Adj-RIBs-Out
NSR – Non Stop Routing
§ NSR in a nutshell
Provides forwarding and
preserves routing during Active
RP failover to Standby RP
BGP protocol changes ARE
NOT required to recover from
failover
BGP peers’ TCP sessions are
maintained
CEs do not need to be
upgraded!
NSR – Non Stop Routing
§ Simplified deployment for
service providers
Only PEs need to be upgraded
to support NSR (incremental
deployment)
CEs are not touched! (i.e., no
software upgrade required)
§ Scaling optimizations
PE uses NSR with CEs that are
not NSF-aware
PE uses NSF (Graceful Re-
Start) with NSF-aware CEs
iBGP sessions to RRs use NSF
(Graceful Re-Start)
Focus: Carrier Class MPLS
End-to-End Resilience
• Both link and node availability along MPLS path need to be
considered (Core and Edge Resilience)
• MPLS HA (NSF/SSO) focused on MPLS failure protection,
detection, and (auto) correction mechanisms
HA HA
TE
HA
Customer’s
Network Provider’s
PE
Provider’s ASBR ASBR
CE Network Network
PE-CE
link
Prot.
• MPLS NSF/SSO support
• MPLS FRR (node + link protection)
• Embedded MPLS OAM and diagnostics
MPLS HA Components - Summary
MPLS node and network protection capabilities
Embedded management capabilities to detect MPLS failures
Scope Feature Capabilities
• MPLS control plane • MPLS NSF/SSO

capabilities, which • MPLS Fast Re-
Re-Route
MPLS Failure automatically detect
and bypass/re-
bypass/re-route • MPLS control plane
Protection resiliency
around node/link
failures
• NM capabilities to • MPLS MIBs

detect and isolate • MPLS OAM
MPLS Failure
MPLS failures not • MPLS Netflow
Detection, Isolation, covered by
and Diagnosis • MPLS diagnostics
embedded MPLS
tools
protection features
• Embedded feature • MPLS Control and

capabilities to Forwarding plane
Auto--Correction
Auto automatically detect consistency
of MPLS Failures and correct certain validation and
MPLS failure correction
conditions
§Enhanced MPLS network availability achieved by reducing number of network failures

and improved network reliability
MPLS Management
§ MPLS management using SNMP MPLS MIB and
MPLS OAM capabilities
P Layer-3 VPNs P Layer-2 VPNs
P MPLS QoS P MPLS TE P HA OAM
MPLS Operations Lifecycle
§ Build and plan the network
Capacity planning and resource
monitoring
One-time Strategic Operations
§ Monitor the network
External-Focused Operations
Internal-Focused Operations
Node/link failure detection Network Service
Configuration Configuration
May impact multiple services and Planning and Planning
§ Provision new services and

maintain existing services
Network Service
Edge/service node Monitoring Monitoring
configuration
§ Monitor service
Ongoing Tactical Operations
End-to-end monitoring
Linked to customer SLAs
What’s Needed for MPLS management?
§ What’s needed beyond the basic MPLS CLI?
CLI used for basic configuration and trouble shooting (show commands)
VRF-Aware commands for traditional troubleshooting tools
Traditional management tools:
§ MIBs to provide management information for SNMP management
applications
MIB counters and Trap notifications form MPLS
New management tools:
§ MPLS OAM -> for reactive trouble shooting
Ping and trace capabilities of MPLS label switched paths
§ Monitoring and Performance Management via MPLS Aware Netflow
and IP SLA for MPLS L3 VPN
§ Automated MPLS OAM -> for proactive trouble shooting
Automated LSP ping/trace via Auto IP SLA
Embedded Management for MPLS
OAM Tools
LSP Ping and Trace for LDP, RSVP distribution mechanisms and VCCV
Deployment Standard
OAM Feature Cisco Value Add
Scope Compliance
LSP ping/trace for LDP-

MPLS LSP Ping/Trace for LDP IPv4 FECs RFC4379 signaled LSPs
LDP MPLS OAM automation via IP SLA
Core Discovery of available LDP
LSP Multipath (ECMP) Tree Trace RFC4379 ECMP LSPs between PEs
Automation via IP SLA
Traffic LSP ping/trace for RSVP -
Engineered MPLS LSP Ping/Trace for RSVP IPv4 FECs RFC4379 signaled LSPs
MPLS Core OAM automation via IP SLA
VCCV – LSP Ping (single and multi-segment RFC 5085 Use of LSP Ping for liveliness
PW) IETF Draft detection
PW3E
Use of BFD over VCCV control
VCCV – BFD (incl. Fault, AC Notification) IETF Draft
channel for failure detection
MPLS LSP Ping/Traceroute
§ Detect MPLS traffic black holes or misrouting

§ Isolate MPLS faults
Requirement
§ Verify data plane against the control plane
§ Detect MTU of MPLS LSP paths
• MPLS LSP ping (ICMP) for connectivity checks

Solution • MPLS LSP traceroute for hop-by-hop fault localization
• MPLS LSP traceroute for path tracing
§ IPv4 LDP prefix, VPNv4 prefix: tunnel monitoring

Applications § TE tunnel
§ L2 VPNs
RFC Standards • RFC 4377, RFC 4378, RFC4379
MPLS OAM
Embedded management capabilities used for node-specific and end-to-
end MPLS failure detection
§ A broken LSP will affect end to end connectivity and services, it is
difficult to troubleshoot an MPLS failure:
Requires the operator to do manual/hop-by-hop work MPLS
§ Various reasons for an LSP to break: 50
49
Broken LDP adjacency

R2
MPLS not enabled (globally or per interface) R1
R3
Mismatched labels LSP Broken
Software/hardware corruption—
§ MPLS OAM facilitates and speeds Up troubleshooting of MPLS failures
§ Principle…similar to traditional (ICMP based) tools:
LSP Ping: based on echo request and echo reply
LSP Trace: packets with incremental TTL
Virtual Circuit Connection Verification (VCCV): end-to-end fault detection and
diagnostics for an emulated PW service
MPLS OAM Packets Format
§ Principle—similar to traditional (ICMP-based) tools
LSP Ping: Based on echo request and echo reply
LSP Trace: Packets with incremental TTL
§ LSP Ping/Trace do not use ICMP packets

New packet format specifically designed for MPLS OAM
IPv4 (IPv6) UDP packets with port 3503
UDP packets : MPLS echo-req. or MPLS echo-reply
Packets contain Control Information and Diagnostic Information

from LSR at Failure Point for Fault Localization and Many
Options to provide for Efficient Troubleshooting information
MPLS OAM Theory of Operation (1 of 2)
MPLS Echo-Req
50 SA DA=127/8 Echo SA DA=127/8 Echo
SA=Source Addr 49
DA=Destination Addr 50
R1
R3 R4 R2
LSP Broken MPLS Echo-Reply
§ Label stack is same as used by the LSP and this makes the echo to be
switched in-band of LSP
? Same label stack ? takes the same path as MPLS data
§ Where the LSP is broken, the Packet Is “consumed” by the router trying to
forward the packet using the IP header
IP-DA = Loopback
§ In this case R2 would not forward the echo-req to R1, but rather
consumes the packet and reply to it accordingly
MPLS OAM Theory of Operation (2 of 2)
MPLS Echo-Req 49 SA DA=127/8 Echo

SA DA=127/8 Echo
50 SA DA=127/8 Echo
49
50
R1
R3 R2
R4
SA=Source Addr MPLS Echo-Reply
DA=Destination Addr
§ LSP reply will be generated as an IP packet which may use an LSP path
back if available
§ Reply contains Return Code information
§ An Echo reply, which may or not be labeled, Information is displayed on
R3 which initiated the MPLS OAM test (probe)
Diagnostic Capability at Failure Point for Fault Localization and

More Options to provide for Efficient Troubleshooting information
Validation of PE-PE MPLS Connectivity
§ Connectivity of LSP path(s) between PE routers can be
validated using LSP ping (ping mpls command via CLI)
pe1>ping mpls ipv4 10.1.2.249/32
Sending 5, 100-byte MPLS Echos to 10.1.2.249/32,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
PE1
'M' - malformed request, 'm' - unsupported tlvs, 'N' PE2
- no label
entry, P1 P2
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
'X' - unknown return code, 'x' - return code 0
Type escape sequence to abort.

!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max =
284/294/300 ms
Cisco IOS IP SLAs LSP Health Monitor
§ LSP Health Monitor
Automatic connectivity testing of label switch paths (LSP) between
PE devices
Combined end-to-end latency and connectivity testing utilizing LSP Ping and
LSP Trace
Ease of use with automatic configuration of IP SLAs operations based on
BGP neighbors
Equal cost multi-path discovery and measurement (future release)
§ MPLS Core Health Monitoring

Real-time automatic health monitoring for the L3 MPLS VPN network
Reducing Operational expense and problem isolation times
Locating and isolating MPLS core forwarding and path issues
Measurement of all equal paths between PE edges measuring all customer
traffic paths (future release)
Automated MPLS OAM
§ Automatic MPLS OAM probes between PE routers
Automatic discovery of PE targets via BGP next-hop discovery
Automatic discovery of all available LSP paths for PE targets via LSP
multi-path trace
Scheduled LSP pings to verify LSP path connectivity
3 consecutive LSP ping failures result in SNMP Trap notification
PE1 - MPLS OAM Probe PE3

PE2 - MPLS OAM Probe
PE3 - MPLS OAM Probe
P1 P2
PE1 PE2
Automated LSP Verification
IPSLA VPN
IP SLAs
CE
MPLS
IP SLAs LSP Health Monitor
§ Proactive end-to-end LSP verification
Standards-based LSP-Ping
Automatic Neighbor PE discovery (per VRF) 100s of PEs
Ingress + Egress
LSP Path Discovery for each Egress PE (including multiple
paths)
IP SLAs
§ Scalability
Fast retry on failure CE
IP SLA VPN
Ease of configuration- automated test setup
Intelligent group-based notifications
Group scheduling
IP SLAs LSP Health Monitor
Functionality - in Detailed Steps
0. User configures 3. IP SLA+ LSP-Ping
Auto-Command per • Send LSP ping to Neighbor at a time and rate
VRF or for the PE controlled by IP SLA (random Start)
• Fast retry on failure; send trap on
IPSLA VPN timeout/connection loss
IP SLAs
PE2
CE PE1
PE3
MPLS
2. IP SLA Agent
• Group-Schedule of
1. Automated LSP Discovery IP SLA probes: Probes
• Find BGP Next hops generated from source to
all destination PEs using PEx
• For all VPNs, or for selected VPN(s) /32 MP-IBGP VPNv4 loopbacks
• Use a single probe template
PE50
4. VPN Discovery interval updates
• LSP Scan Rate (SR); add probes if new IP SLAs
BGP neighbor
• LSP Scan Rate Factor “N” (SRxN) ?
Delete probes (ex: VRF removed or no
route in the VRF)
IP SLA VPN
Virtual Circuit Connection Verification
(VCCV)
• Ability to provide end-to-end fault detection and
diagnostics for an emulated pseudowire service
Requirement One tunnel can serve many pseudowires
MPLS LSP ping is sufficient to monitor the PSN tunnel
(PE-PE connectivity), but not VCs inside of tunnel
§ VCCV allows sending control packets in band of

PseudoWires (PW)
§ Two components
Signaling component: communicate VCCV capabilities as
Solution part of VC label
Switching component: cause the PW payload to be treated
as a control packet
Type 1: uses Protocol ID of PW Control word
Type 2: use MPLS router alert label
Type 3: manipulate TTL exhaust
Applications
§ Layer 2 transport over MPLS
FRoMPLS, ATMoMPLS, EoMPLS
IETF Standards • RFC 5085

MPLS OAM: Virtual Circuit Connection Verification
§ VCCV checks connectivity between egress and ingress PEs
§ VCCV capability is negotiated when the AToM tunnel is brought up
(depends on the LDP peer and the VC type)
QinQ
Customer VLAN
7600
MPLS 7600
QinQ
Customer VLAN
• Verify/Trace Path of LSP Tunnels between PEs.
• Verify/Trace Emulated services (e.g. Ethernet) mapped to Customer VLANS
(Attachment VCs)
• Trace/Verify packets take same path as data packets
Connectivity Trace Using VCCV EoMPLS
§ VCCV marks the payload as control packet for switching purpose;
packet follows the PW data path
§ Control packets sent over the AToM tunnels are intercepted by the
egress PE
PE1#ping mpls pseudowire 172.16.255.4 333
Attachment
Circuit
PE1
VCCV Packet
•TTL in VC label is set appropriately at the is Lost
initiator to reach the node of interest to
verify the connectivity to
•VCCV packets use the same path as the Attachment
data packets (may use different path than Circuit
signaling traffic)
PE2
Connectivity of single-segment PW is implemented using VCCV CC type1 (RFC 5085)
VCCV Switching Types
Three different Switching Modes
Type 1 Type 1 involves defining the upper nibble of the CW
(control word) as a Protocol ID (PID) field to signal in-
(in-band vccv)
band VCCV [RFC4385]
Type 2 Type 2 involves shimming a MPLS router alert label

between the IGP label stack and VC label
(out-of-band VCCV)
Type 3 (TTL expiry) Manipulate and Signal TTL exhaust (TTL == 1) for
multiple switching point PEs
• Cisco Routers always use Type 1, if available, for LSP Ping over an AToM
VC Control Channel.
• Type 2 Switching accommodates those VC types and implementations that
do not support or interpret the AToM Control word.
•A new CC Type 3 – new switching point TLV - is introduced to support VCCV
in MS-PWs (RFC 5085)
VCCV Switching Types (Type–2)
Signal out-of-band VCCV using MPLS router alert label.
Shim an MPLS Router Alert Label Between the IGP Label
Stack and VC Label.
PE1#sh mpls l2transport binding 10

Destination Address: 10.200.0.1, VC ID: 10 PE1 PE2
Local Label: 16
Cbit: 0, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a IGP Label TTL=255 Rtr Alert Label 0x0001
Rtr Alert Label 0x0001 vc Label+CW
VCCV Capabilities: Type 2 vc Label+CW L2 Payload
L2 Payload
Remote Label: 69 VCCV Packet VCCV Packet
Sent to PE2 Received from PE1
Cbit: 0, VC Type: Ethernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV Capabilities: Type 2
VCCV for Multi-Segmented Pseudowires
Ping Operation using VCCV Type III
Ping from T-PE2 to S-PE1
CE1 S-PE1 S-PE2

AC VCID: 100
VCID: 101 AC CE2
VCID: 102
ACCESS MPLS MPLS Core ACCESS MPLS
T-PE1 T-PE2
3. 1.
2.
TTL 0 Label PWID 101
Punt to Switch Sender IP: S -PE2
OAM Packet Remote IP: S -PE1
TTL 1 TTL 2
PSN Tunnel
Pseudowire 4. SRC IP: T-PE2
Code 8 Dest IP: 127.0.0.1
TTL 2
Src IP:
127.0.0.1
Dest IP:
BRKRST-1101 T-PE2 © 2009 Cisco Systems, Inc. All rights reserved. Cisco Public 377
MPLS Aware NetFlow
§ Provides flow statistics per MPLS and IP packets
MPLS packets:
Labels information
And NetFlow v5 fields for underlying IP packet
IP packets:
Regular IP NetFlow records
§ Leverages the new NetFlow version 9 export format
§ Configure on ingress interface
§ Supported on sampled/non-sampled NetFlow
VRF aware Netflow Export support

Router(config)# ip flow-export destination 10.10.10.10 9999 vrf terps <sctp|udp>
Example: MPLS VPN Aware Netflow
vrf = red
172.16.99.1
98.98.98.98 201 204 99.99.99.99

IP/MPLS
PE PE
VRF = red 10.100.1.201 10.100.1.204 VRF = red
VPN Traffic
flow Netflow Interface
201#sh ip bgp vpnv4 vrf red labels
Network Next Hop In label/Out label

Route Distinguisher: 1:1 (red)
24.24.24.24/32 10.100.1.204 nolabel/21
98.98.98.98/32 172.16.98.2 19/nolabel
99.99.99.99/32 10.100.1.204 nolabel/20
172.16.98.0/24 0.0.0.0 21/nolabel(red)
172.16.99.0/24 10.100.1.204 nolabel/18
201.201.201.201/32
0.0.0.0 18/nolabel(red))
Example: MPLS VPN Aware Netflow
172.16.99.1
98.98.98.98 201 204 99.99.99.99

IP/MPLS
PE PE
VRF = red 10.100.1.201 10.100.1.204 VRF = red
VPN Traffic
flow Netflow Interface
ip flow-cache mpls label-positions 1

!
201#sh ip cache verbose flow
SrcIf SrcIPaddress DstIf DstIPaddress Pr TOS Flgs Pkts

Port Msk AS Port Msk AS NextHop B/Pk Active
Et1/0 172.16.98.2 Tu0* 172.16.99.1 00 05 10 276K

0000 /0 0 0000 /0 0 0.0.0.0 60 1550.9
Pos:Lbl-Exp-S 1:18-0-1
Label = 18
EXP = 0
BRKRST-1101 Stack = 1
Embedded Management for MPLS:
SNMP MIBs and Traps
Deployment Standard
MIB Module/OAM Feature Cisco Value Add
Scope Compliance
MPLS-LSR-MIB RFC3813 VRF-aware MIB capabilities
MPLS-LDP-MIB RFC3815 VRF-aware MIB capabilities
LDP MPLS
MPLS-FTN-MIB RFC3814 VRF-aware MIB capabilities
Core
LDP session status Trap
MPLS-LDP-STD-MIB
notifications
VRF max-route Trap
MPLS-L3VPN-STD-MIB
notifications
MPLS-TE-MIB RFC3812 -
Traffic
Engineered MPLS-FRR-MIB IETF Draft -
MPLS Core
TE Tunnel status Trap
MPLS-TE-STD-MIB
notifications
LDP Event Monitoring Using LDP Traps
Interface Shutdown (E1/0 on PE1) LDP Session Down (PE1 – P01)
Time = t: Received SNMPv2c Trap from pe1: Time = t: Received SNMPv2c Trap from pe1:
sysUpTimeInstance = 8159606 sysUpTimeInstance = 8159606
snmpTrapOID.0 = mplsLdpSessionDown snmpTrapOID.0 = mplsLdpSessionDown
mplsLdpSessionState.<index> = nonexistent(1)
mplsLdpSessionDiscontinuityTime.<index> = 8159605
mplsLdpSessionStatsUnknownMesTypeErrors.<index> = 0
mplsLdpSessionStatsUnknownTlvErrors.<index> = 0
ifIndex.5 = 5
ifIndex.5 = 5
Interface goes down LDP session goes down
Time = t+1: Received SNMPv2c Trap from pe1:
sysUpTimeInstance = 8159906 Time = t+1: Received SNMPv2c Trap from p01:
snmpTrapOID.0 = linkDown sysUpTimeInstance = 8160579
ifIndex.5 = 5 snmpTrapOID.0 = mplsLdpSessionDown
ifDescr.5 = Ethernet1/0 mplsLdpSessionState.<index> = nonexistent(1)
PE1
ifType.5 = ethernetCsmacd(6)
locIfReason.5 = administratively down
PE1
P1 P1
Time = t+2:LDP
Received
session SNMPv2c Trap from p01: ifIndex.5 = 5 LDP session
sysUpTimeInstance = 8160579
snmpTrapOID.0 = mplsLdpSessionDown
ifIndex.5 = 5
MPLS Management Summary
§ MPLS management operations include MPLS node
and service configuration, and monitoring
§ In addition to CLI, SNMP MIBs and OAM capabilities
are available for MPLS management
§ MPLS MIBs provide LDP, VPN, and TE management
information, which can be collected by SNMP tools
MIB counters, Trap notifications
§ Advanced MPLS management capabilities can be

implemented via MPLS OAM
LSP path discovery and connectivity validation
Proactive monitoring via automated MPLS OAM
Cisco MPLS Management Architecture
Operations Support
GUI System Software Partners
• CORBA
• SNMP
• TL1
• XML
Element
Fault Configuration Performance
and Accounting
Management
System
Infrastructure
Enhancements
• Alarm Notification • Config Upload • Data Collection
• Alarm • Incremental • Data Export
Synchronisation Configuration • SNMP Get and
• Threshold Alerts • Change Notification GetBulk Performance
• Diagnostic Monitoring • Programmatic • Bulk file transfer IP SLA
• SNMP Get, getBulk, Interface • NetFlow MIBs
Traps • CLI
• Syslogs • TFTP
• RMON
MPLS
CNS Bus FCAPS
SNMP HTTP Telnet
NetFlow SSH Accounting
LSP Ping
XML MPLS Traceroute
NetFlow
CLI VCCV
SNMP Embedded Protocol
Enhancements
Cisco IOS Management AutoTunnel
Programmatic
AutoMEsh
Interface Security
Cisco IOS Software
Summary
Final Notes and Wrap Up
MPLS Technology
Summary and Key Takeaways
§ It’s all about labels …
Label-based forwarding and IP protocol extensions for label exchange
Best of both worlds … L2-type forwarding and L3 control plane
§ Key application of MPLS is to implement VPN services
Secure and scalable layer 2 and 3 VPN connectivity
§ MPLS supports advanced traffic engineering capabilities
QoS, bandwidth control, and failure protection
§ MPLS is a mature technology with widespread deployments
Both SP and enterprise networks
§ Two types of MPLS users
Indirect (Subscriber): MPLS used as transport for subscribed service
Direct (DIY): MPLS implemented in (own) SP or enterprise network
MPLS, The Foundation for the NGN
A quick recap of the Benefits
§ MPLS is a Services Creation & Convergence platform

Layer3 MPLS based IP-VPN Services
Layer2 VPN Services (VPWS & VPLS)
Legacy Frame-relay and ATM Services
New Ethernet based Wire and LAN Services
Wide range of Value Added Services (Voice, Video…)
• Quality of Service and Traffic Engineering
• Network Reliability via Link and Node Protection and Restoration
• IP & ATM Integration (Routers and Switches)
• IP & Optical Integration (G-MPLS)
• Large End-user acceptance as enabler of Business IP
Services
Consider MPLS When …
§ There’s a need for network segmentation
Segmented connectivity for specific locations, users,
applications, etc.
Full-mesh and hub-and-spoke connectivity
§ There’s a need for network realignment/migration

Consolidation of (multiple) legacy networks
Staged network consolidation after company merger/acquisition
§ There’s a need for optimized network availability and

performance
Node/link protection, pro-active connectivity validation
Bandwidth traffic engineering and QoS traffic prioritization
MPLS Applications
Service Enterprise Data Data center EWAN
Providers Center interconnects Edge
L2/L3VPN’s
Key Features
VPN’s VPN’s / VRF’s VPN’s / VRF’s

TE/FRR
TE/FRR VRF-Aware Security VRF Aware Security
QoS
High Availability High Availability High Availability
High Availability
Hosted Data centers

Departmental
Applications
Data center segmentation Disaster Recovery

interconnect Service multiplexing Vmotion support Internet Access
Segmentation for IT Security Branch Connectivity
Mergers, Acquisitions, Branch Interconnects
Mergers, spinoffs
Acquisitions, spinoffs
• Network Consolidation – Merging Multiple parallel network into a shared infrastructure

• Network segmentation – By user groups or business function
• • Service and policy centralization – Security policies and appliances at a central location
•
• New applications readiness – Converged multi-service network
•
• Increased network security – User groups segmentation with VPNs
•
•
MPLS: Key Network Virtualization Enabler
Allows Vast Network “Service” Capabilities over an IP Backbone
§ Layer 3 Segmentation
VPN (RFC 2547bis)
Provides Any-to-Any connectivity
§ Maximize Link Utilization with Selective Routing/Path Manipulation

Traffic Engineering Key Virtualization
Mechanisms over
Optimization of bandwidth and protection using Fast-ReRoute (FRR) An IP Infrastructure
§ Layer 2 VPN/Transport
AToM (Any Transport over MPLS) i.e. “pseudo-wire”
Layer-2 transport: Ethernet, ATM/FR, HDLC/PPP, interworking
Layer-2 VPN: VPLS for bridged L2 domains over MPLS
§ QoS Capabilities
Diffserv, Diffserv aware Traffic Engineering (DS-TE)
§ Bandwidth Protection Services

Combination of TE, Diffserv, DS-TE, and FRR
§ IP Multicast (per VPN/VRF)

§ Transport of IPv6 over an IPv4 (Global Routing Table) Infrastructure
§ Unified Control Plane (Generalized MPLS)
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.
Q and A
Recommended Reading
Source: Cisco Press

Recommended Reading
Source: Cisco Press

Recommended Reading
Source: Cisco Press

Terminology Reference
Terminology Description
AC Attachment Circuit. An AC Is a Point-to-Point, Layer 2 Circuit Between a CE and a PE.
AS Autonomous System (a Domain)
CoS Class of Service
ECMP Equal Cost Multipath
IGP Interior Gateway Protocol
LAN Local Area Network
LDP Label Distribution Protocol, RFC 3036.
LER Label Edge Router. An Edge LSR Interconnects MPLS and non-MPLS Domains.
LFIB Labeled Forwarding Information Base
LSP Label Switched Path
LSR Label Switching Router
NLRI Network Layer Reachability Information
P Router An Interior LSR in the Service Provider's Autonomous System
An LER in the Service Provider Administrative Domain that Interconnects the Customer
PE Router
Network and the Backbone Network.
PSN Tunnel Packet Switching Tunnel
Terminology Reference
Terminology Description
A Pseudo-Wire Is a Bidirectional “Tunnel" Between Two Features on a
Pseudo-Wire
Switching Path.
PWE3 Pseudo-Wire End-to-End Emulation
QoS Quality of Service
RD Route Distinguisher
RIB Routing Information Base
RR Route Reflector
RT Route Target
RSVP-TE Resource Reservation Protocol based Traffic Engineering
VPN Virtual Private Network
VFI Virtual Forwarding Instance
VLAN Virtual Local Area Network
VPLS Virtual Private LAN Service
VPWS Virtual Private WAN Service
VRF Virtual Route Forwarding Instance
VSI Virtual Switching Instance

TECIPM3012

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

TECIPM3012

Hochgeladen von

Copyright:

Verfügbare Formate

MPLS en Profundidad

La tecnología para redes de Nueva Generación

Layer-3 VPNs MPLS in Core Network Layer-2 VPNs

MPLS QoS MPLS TE MPLS OAM/MIBs

IPv4 Multicast IPv6 E-LINE E-LAN ATM/FR

Layer-3 VPNs Layer-2 VPNs

QoS TE/FRR HA OAM

MPLS Signaling and Forwarding

MPLS VPN Models

Layer-2 VPNs Layer-3 VPNs

Label switched traffic

MPLS support both L3 and L2 VPN

Support increasingly stringent SLAs

Enables easier setup of Network connectivity

MPLS Customer Segments Geographic Customer Distribution

§ MPLS used as part of self managed network

25 Financials, Transportation, and System

enterprise customer segments for MPLS

Virtual Virtual Virtual

Actual Campus LAN

Layer 3 VPNs and Layer 2 VPNs, Traffic Engineering +

Layer-3 VPNs Layer-2 VPNs

MPLS Network Services

MPLS QoS MPLS TE HA OAM

MPLS Signaling and Forwarding

Layer-3 VPNs Layer-2 VPNs

MPLS QoS MPLS TE HA OAM

MPLS Signaling and Forwarding

§ Other related protocols and protocols to exchange

Label switched traffic

§ P (Provider) router = label switching router = core router (LSR)

Label switched traffic

§ IGP: OSPF, EIGRP, IS-IS on core facing and core links

2. Ingress Edge LSR Receives Packet,

Typically supported by LDP;

§ Label Distribution Protocol (LDP)

# sh mpls ldp bind 10.98.76.2 32

Only label from next-hop used for forwarding in the LFIB

# show mpls forwarding-table

§ Label imposition (Push)

Label # – 20bits EXP S TTL-8bits

COS/EXP = Class of Service: 3 Bits; S = Bottom of Stack; TTL = Time to Live

MPLS Label Encapsulation

In In Address Out Out

§ Rtr-A forwards using the top-most label of the stack

§ LDP leverages IGP routing information

§ Once LDP has received remote label binding

You Can Reach 128.89 Thru Me

Use Label 9 for 128.89

Label Switch Forwards

London Brussels Paris

Paris# show mpls ldp binding 197.26.15.1

Brussels# show mpls ldp binding 197.26.15.1

Brussels# show mpls forwarding

28 Pop label 197.26.15.1/32 0 Gi0/0/2 point2point

May be disabled using explicit-null option

1. IP connectivity must be established èping ip

Layer-3 VPNs Layer-2 VPNs

MPLS QoS MPLS TE HA OAM

P MPLS Signaling and Forwarding

§ Not all application traffic types/flows are the same …

§ MPLS QoS used for traffic prioritization to guarantee

§ MPLS leverages mostly existing IP QoS architecture

MPLS DiffServ Marking IP DiffServ Marking