XMPLST4-IG v4.0.1

XMPLST4
Cisco IOS XR MPLS and

Tunnel Technologies for
IPv4
Version 4.0.1
Instructor Guide
Text Part Number: xx-xxxx-xx
Copyright ! 2011, Cisco Systems, Inc. All rights reserved.

Cisco Systems has more than 200 offices in the following countries and regions. Addresses, phone numbers, and fax
numbers are listed on the Cisco Web site at www.cisco.com/go/offices.
Argentina Australia Austria Belgium Brazil Bulgaria Canada Chile China PRC Colombia Costa Rica Croatia
Czech Republic Denmark Dubai, UAE Finland France Germany Greece Hong Kong SAR Hungary
India Indonesia Ireland Israel Italy Japan Korea Luxembourg Malaysia Mexico The Netherlands
New Zealand Norway Peru Philippines Poland Portugal Puerto Rico Romania Russia Saudi Arabia
Scotland Singapore Slovakia Slovenia South Africa Spain Sweden Switzerland Taiwan Thailand Turkey Ukraine
United Kingdom United States Venezuela Vietnam Zimbabwe
Copyright " 2006, Cisco Systems, Inc. All rights reserved. CCIP, the Cisco Powered Network mark, the
Cisco Systems Verified logo, Cisco Unity, Follow Me Browsing, FormShare, Internet Quotient, iQ
Breakthrough, iQ Expertise, iQ FastTrack, the iQ logo, iQ Net Readiness Scorecard, Networking Academy,
ScriptShare, SMARTnet, TransPath, and Voice LAN are trademarks of Cisco Systems, Inc.; Changing the Way We
Work, Live, Play, and Learn, Discover All Thats Possible, The Fastest Way to Increase Your Internet Quotient, and
iQuick Study are service marks of Cisco Systems, Inc.; and Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE,
CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, the Cisco IOS logo, Cisco Press,
Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Empowering the Internet Generation,
Enterprise/Solver, EtherChannel, EtherSwitch, Fast Step, GigaStack, IOS, IP/TV, LightStream, MGX, MICA, the
Networkers logo, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, RateMUX, Registrar, SlideCast,
StrataView Plus, Stratm, SwitchProbe, TeleRouter, and VCO are registered trademarks of Cisco Systems, Inc. and/or
its affiliates in the U.S. and certain other countries.
All other trademarks mentioned in this document or Web site are the property of their respective owners. The use of
the word partner does not imply a partnership relationship between Cisco and any other company. (0203R)
Printed in the USA
Course Overview
Intended Audience
This course is for technical professionals who design, implement, and
operate MPLS and other tunnel technologies in a service provider
network employing routers using Cisco IOS XR Software. The primary
audience for this course is:
Network and senior engineers
Network operations center (NOC) engineers
Support engineers
Course Level
This course provides an advanced level of information pertaining to
the platforms currently supporting Cisco IOS XR Software.
Prerequisites
For a student to successfully complete this course, they must meet
these minimum recommended prerequisites:
Have knowledge of the Cisco IOS XR Software configuration

syntax to the extent covered in the Cisco CRS-1 Essentials, Cisco
IOS XR Fundamentals for Network Operations, or Cisco ASR 9000
Essentials course.
Be able to establish, without assistance, a configuration for Open

Shortest Path First Version 2 (OSPFv2), Intermediate System-toIntermediate System (IS-IS), and Border Gateway Protocol (BGP)
with Routing Policy Language (RPL) policies as accomplished in
the Cisco IOS XR IPv4 Routing course labs.
Have a basic understanding of MPLS configuration and operation

as covered in the Cisco CRS-1 Essentials, Cisco IOS XR
Fundamentals for Network Operations, or Cisco ASR 9000
Essentials course.
2011 Cisco Systems, Inc.
Version 4.0.1
Additional Information
Cisco Systems Technical Publications
You can print technical manuals and release notes directly from the
Internet. Go to
http://www.cisco.com/en/US/products/ps5845/tsd_products_suppor
t_series_home.html.
Find the Cisco Systems product for which you need documentation.
Then locate the specific category and model or version for your
hardware or software product. Using Adobe Acrobat Reader, you can
open the manuals and release notes, search for the sections you need,
and print them on most standard printers. You can download Acrobat
Reader free from the Adobe Systems Web site, www.adobe.com.
Documentation sets and CDs are available through your local Cisco
Systems sales office or account representative.
Cisco Systems Service
Comprehensive network support is available from Cisco Systems

Service & Support solutions. For a listing of services, go to
http://www.cisco.com/en/US/support/index.html.
vi
Version 4.0.1

Tunnel Technologies for IPv4
Course Agenda
Day 1
Course and Student Introduction
Module 1 MPLS Technology Introduction
Lab 1 Lab Familiarization and Initial Configuration
Module 2 MPLS Operations, Administration, and Management (OAM)
Module 3 MPLS Label Distribution Protocol (LDP) (Part 1)
Lab 2 MPLS LDP Implementation with OSPF
Day 2
Module 3 MPLS Label Distribution Protocol (LDP) (Part 2)
Lab 2 MPLS LDP Implementation with IS-IS
Module 4 Layer 3 Virtual Private Networks (L3VPN)
Lab 3 L3VPN (Intranet)
Module 4 Layer 3 Virtual Private Networks (L3VPN) (Cont.)
Lab 3 L3VPN (Extranet)
Day 3
Module 5 Inter-AS L3VPNs
Lab 4 Inter-AS L3VPNs
Module 6 MPLS Traffic Engineering (MPLS-TE) (Part 1)
Lab 5 MPLS-TE (Parts 1 and 2)
Day 4
Module 6 MPLS Traffic Engineering (MPLS-TE) (Part 2)
Lab 5 MPLS-TE (Parts 3)
Module 7 L2VPNs and AToM (Part 1)
Lab 6 L2VPNs and AToM (Part 1)
Version 4.0.1
vii
Day 5
Course Summary
viii
Version 4.0.1

Course Introduction and Objectives
Overview
Description
This course is designed to teach service provider customers (and
internal Cisco staff) how to configure and to verify their operation of:
Cisco IOS XR Multiprotocol Label Switching (MPLS)
MPLS Label Distribution Protocol (LDP)
MPLS Traffic Engineering (MPLS-TE)

!
Resource Reservation Protocol (RSVP)
Layer 3 Virtual Private Networks (L3VPN)
Layer 2 VPNs (L2VPN)
Any Transport over MPLS (AToM)
The course will include both lecture and intensive hands-on lab
exercises.
The lab network will consist of multiple cores of P and PE routers
running Cisco IOS XR Software Release 3.9.0 and preconfigured CE
routers running Cisco IOS software.
This course does not cover routing fundamentals, MPLS
fundamentals, or Multicast fundamentals, IPv6, QoS, or Layer 3
VPNs.
Version 4.0.1
ix
Objectives
After completing this course, you will be able to do the following:
Describe MPLS, MPLS LDP, MP-BGP, RSVP, MPLS-TE, L2VPN,

L3VPN, MPLS OAM
Configure MPLS, MPLS LDP, MP-BGP, RSVP, MPLS-TE, L2VPN,

L3VPN, MPLS OAM
Verify MPLS, MPLS LDP, MP-BGP, RSVP, MPLS-TE, L2VPN,

L3VPN, MPLS OAM implementations
Examine MPLS, MPLS LDP, MP-BGP, RSVP, MPLS-TE, L2VPN,

L3VPN, MPLS OAM to verify operation
Version 4.0.1

Contents
Course Overview ................................................................................................................... v!
Course Agenda ..................................................................................................................... vii!
Course Introduction and Objectives ................................................................ ix!

Overview ............................................................................................................................... ix!
Module 1........................................................................................................... 11!
Overview ............................................................................................................................ 11!
MPLS Conceptual Overview ............................................................................................. 12!
MPLS Operational Overview ............................................................................................ 18!
MPLS LDP Overview ...................................................................................................... 116!
MPLS L3VPN Overview ................................................................................................. 120!
MPLS L2VPN Overview ................................................................................................. 126!
MPLS Traffic Engineering Overview ............................................................................. 130!
Resource Reservation Protocol Overview ....................................................................... 136!
Summary ......................................................................................................................... 142!
Module 2............................................................................................................... 1!
Overview ................................................................................................................................ 1!
Review .................................................................................................................................... 2!
The Need for MPLS OAM ..................................................................................................... 4!
Using MPLS OAM ............................................................................................................... 14!
MPLS OAM Operation ........................................................................................................ 20!
Using MPLS LSP Ping and Traceroute ............................................................................. 34!
Finding a Maximum Transmission Unit (MTU) Mismatch .............................................. 46!
MPLS OAM Multipath Trace ............................................................................................. 48!
MPLS OAM with Traffic Engineering ............................................................................... 60!
MPLS OAM with Virtual Circuit Connection Verification (VCCV) ................................. 64!
Configuration and Management of MPLS OAM ............................................................... 66!
Summary ............................................................................................................................. 72!
Module 3........................................................................................................... 31!
Overview ............................................................................................................................ 31!
Components of LFIB ......................................................................................................... 32!
MPLS LDP Fundamental Points .................................................................................... 310!
Version 4.0.1
xi
LDP Protocol Overview ................................................................................................... 314!

Cisco IOS XR LDP Implementation ............................................................................... 340!
Cisco IOS XR MPLS Forwarding Infrastructure (MFI) ................................................ 352!
Configuring LDP Operation............................................................................................ 356!
Session Authentication ................................................................................................... 364!
Label Filtering ................................................................................................................. 366!
Session Protection ........................................................................................................... 372!
LDP IGP Synchronization .............................................................................................. 378!
Graceful Restart .............................................................................................................. 388!
LDP Non-Stop Routing (NSR) and Forwarding Overview ............................................ 398!
LDP Pseudowire (PW) Signaling .................................................................................. 3108!
Commands to Troubleshoot LDP Operation ................................................................ 3114!
Displaying LDP Operational States ............................................................................. 3118!
Summary ....................................................................................................................... 3120!
Module 4........................................................................................................... 41!

Overview ............................................................................................................................ 41!
Layer 3 Virtual Private Network Overview ..................................................................... 42!
Layer 3 VPN General Operation .................................................................................... 410!
Multiprotocol BGP Overview .......................................................................................... 420!
MPLS L3VPN Operation ................................................................................................ 428!
L3VPN Intranet Configuration ...................................................................................... 436!
L3VPN Intranet Verification .......................................................................................... 460!
L3VPN Extranet Operation ............................................................................................ 484!
L3VPN Extranet Verification ......................................................................................... 494!
Summary ....................................................................................................................... 4108!
Module 5........................................................................................................... 51!
Overview ............................................................................................................................ 51!
MPLS Inter-AS L3VPN Overview .................................................................................... 52!
Inter-AS Option A Operation............................................................................................ 58!
Inter-AS Option A Configuration ................................................................................... 514!
Inter-AS Option A Verification ....................................................................................... 520!
Inter-AS Option B Operation.......................................................................................... 526!
Inter-AS Option B Configuration ................................................................................... 532!
Inter-AS Option B Verification ....................................................................................... 536!
Inter-AS Option C Operation.......................................................................................... 542!
Inter-AS Option C Configuration ................................................................................... 550!
Inter-AS Option C Verification ....................................................................................... 560!
Summary ......................................................................................................................... 582!
xii
Version 4.0.1

Module 6........................................................................................................... 61!

Overview ............................................................................................................................ 61!
MPLS Traffic Engineering Overview ............................................................................... 62!
Cisco MPLS TE Tunnel Operation Overview ................................................................ 618!
Traffic Engineering and Interior Gateway Protocols .................................................... 628!
RSVP Operation Overview ............................................................................................. 644!
MPLS Traffic Engineering Configuration...................................................................... 674!
Creating Traffic Engineering Tunnels ........................................................................... 684!
Reviewing TE Tunnel Configuration and Operation .................................................. 6136!
Cisco MPLS TE Explicit Tunnels ................................................................................. 6144!
Cisco MPLS TE and Fast Reroute ................................................................................ 6152!
Traffic Engineering Timers .......................................................................................... 6178!
Reoptimization .............................................................................................................. 6180!
Other Traffic Engineering Information ....................................................................... 6190!
Summary ....................................................................................................................... 6202!
Module 7........................................................................................................... 71!
Overview ............................................................................................................................ 71!
Introduction to Layer 2 VPNs .......................................................................................... 72!
Any Transport over MPLS (AToM) ................................................................................ 720!
Implementing Virtual Private Wire Service (VPWS) .................................................... 736!
Ethernet over MPLS (EoMPLS) ..................................................................................... 742!
AToM Redundancy Features .......................................................................................... 750!
Virtual Private LAN Service .......................................................................................... 754!
Hierarchical Virtual Private LAN Service (H-VPLS) ................................................... 784!
Displaying L2VPN Information.................................................................................... 7100!
H-VPLS Redundancy .................................................................................................... 7106!
MAC Address Withdrawal ............................................................................................ 7110!
VPLS Auto-Discovery .................................................................................................... 7116!
Summary ....................................................................................................................... 7132!
Version 4.0.1
xiii
This page is intentionally blank.
xiv
Version 4.0.1

Module 1
MPLS Technology Introduction
Overview
Description
This module provides a brief background of the concepts and architecture
of MPLS and MPLS tunnels and supporting technologies. The module
describes the similarities and differences among Layer 2 VPNs,
Layer 3 VPNs, and Traffic Engineering (TE), and describes Resource
Reservation Protocol.
Objectives
After completing this module, you will be able to:
Describe MPLS and Label Distribution Protocol (LDP)
Describe MPLS Layer 2 and Layer 3 tunnel concepts
Describe MPLS Traffic Engineering (TE) concepts and operation
Describe MPLS control and forwarding planes
Version 4.0.1
11
Module 1
MPLS Conceptual Overview

In this section you cover information about the MPLS technology, its
services, and its security from a high level.
What is MPLS?
Multiprotocol Label Switching (MPLS) is a technology for enhanced
delivery of services that resolves many issues with packet forwarding
across the Internet. MPLS integrates forwarding using label swapping
with network layer (OSI Layer 3) routing. This integration enables packet
forwarding through label-switch paths (LSPs). The LSPs can be created in
several ways and by using several protocols. A short general list is on the
opposite page.
MPLS provides mechanisms to transport Layer 2 technologies as outlined
in these IETF RFCs:
12
RFC 4446: IANA Allocations for Pseudowire Edge-to-Edge Emulation

(PWE3)
RFC 4447: Pseudowire Setup and Maintenance Using the Label

Distribution Protocol (LDP)
RFC 4448: Encapsulation Methods for Transport of Ethernet over

MPLS Networks
Version 4.0.1

Module 1
What is MPLS?
Multiprotocol Label Switching is a technology for delivery

of network services
MPLS technology uses labels, rather than IP addresses,

to transport the data
Layer 2 technologies can traverse an MPLS network
!ATM
!Frame Relay
!PPP and HDLC
!POS
!Ethernet
!Sonet/SDH circuit emulation over packet (CEP)
2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/4
13
Module 1
MPLS and Value-Added Services

MPLS is the basis for value-added services.
MPLS separates the routing mechanism from the packet transport. At the
same time, MPLS provides a single secure infrastructure that supports a
variety of service applications. MPLS provides better network utilization
and bandwidth efficiency, as well as a way to load balance traffic.
All of these improve network flexibility and scalability for service delivery
so service providers can improve their network performance while
delivering more services at lower costs.
_____________________________ Note _________________________
This course does not cover IP+Optical GMPLS. This course does cover
Any Transport over MPLS (AToM) and Layer 2 VPNs together.
__________________________________________________________________
14
Version 4.0.1

Module 1
MPLS and Value-Added Services
Layer 3
VPNs
Traffic
Engineering
Layer 2
VPNS
Any
Transport
over MPLS
IP+Optical
GMPLS
MPLS
Network Infrastructure
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/5
15
Module 1
MPLS Security
MPLS security translates to protection and privacy of traffic across the
network. Protection of data in the customer private network over the
public service provider network represents a small slice of the service
providers overall security.
16
Version 4.0.1

Module 1
MPLS Security
Operation
Implementation
Architecture and
Algorithm
MPLS
Privacy
Privacy in MPLS relies on three principles
! Break one and privacy is gone
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/6
17
Module 1
MPLS Operational Overview

This section covers a high level introduction to the parts of MPLS, its
operation, important security considerations, and how it is implemented in
Cisco IOS XR software.
MPLS Elements
MPLS consists of two planes and some core services such as label
management and packet forwarding.
The control plane enables and disables MPLS on interfaces, allocates and
manages label tables, sets up label rewrites, and interacts with the IGP to
set up label binding and forwarding path creation.
The forwarding plane imposes (pushes) labels onto packets, swaps labels
along the forwarding path, and disposes of (pops) labels.
MPLS uses the idea of binding a label to a forwarding equivalence class
(FEC). A FEC describes packets forwarded behind a certain label. A FEC
can represent IP prefixes, layer 2 frames transported over a pseudowire, or
even SONET frames in Circuit Emulation over Packet Switched networks
(CEoPS). In following modules we discuss the case of IP prefixes.
The control plane creates label bindings and stores them in a label
information base (LIB). Label Distribution Protocol (LDP) is used to
distribute this label prefix binding amongst the Label Switch Routers
(LSRs).
Each LSR constructs a label forwarding information base (LFIB) by
participating in the routing protocol using the information received from
the other router participants. The participation associates a destination
prefix to a locally significant label creating the local binding. MPLS LDP
labels are locally significant because they are replaced at each hop in the
label-switched path (LSP).
An LFIB contains an incoming label, outgoing label, outgoing interface,
and outgoing MAC address. The incoming label indexes the destination
prefix.
18
Version 4.0.1

Module 1
MPLS Elements
Control plane
Exchange of
routing information
IP routing protocols
IP routing table
Exchange of
label bindings
Label information base
MPLS IP routing control

Control plane
Forwarding plane
Incoming unlabeled
packets
Incoming labeled
packets
Forwarding information base
Outgoing labeled or
unlabeled packets
Label forwarding
information base
Outgoing labeled or
unlabeled packets
Forwarding plane
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/8
19
Module 1
MPLS Operation Review

The forwarding of data traffic to its destination is based on establishing
paths through the network. With MPLS, the path to a destination is
established through the interaction of the interior gateway protocol (IGP)
and MPLS. MPLS assigns labels using Label Distribution Protocol to each
step in the path, from the source to the destination. These paths are called
label-switched paths or LSPs. The result is destinations in the network are
reachable by only one path. (It is possible to set up paths based on cost, but
we do not cover that aspect here.)
The grouping of destinations is an example of a forwarding equivalence
class or FEC. FECs may also be based on traffic type or other
classifications.
MPLS prepares for, and then carries traffic in this manner:
1. An IGP routing protocol, such as OSPF or IS-IS, determines the Layer
3 topology. All routers in the core network build the Layer 3 topology.
2. The LDP establishes label values for each router according to the
routing topology, to build a table of destination networks. LDP
automatically assigns the labels creating the LSP.
3. An ingress packet enters the edge label switch router (LSR). The LSR
labels it, does all the Layer 3 value-added services, including QoS,
bandwidth management, and others. It applies a label to it based on
information in the forwarding tables.
4. The core LSRs read the labels on each packet on the ingress interface,
and based on the label, forward the packet out to the appropriate
egress interface with a new label.
5. The egress Edge LSR removes the label and sends the packet to its
destination.
110
Version 4.0.1

Module 1
MPLS Operation Review
1. Existing IGP routing protocols (OSPF, ISIS) establish routes

2. Label Distribution Protocol (LDP)
establishes label switched path
(LSP) (label to routes mapping)
5. Edge LSR at egress

removes label and
delivers packet
3. Ingress edge LSR receives packet,
performs Layer 3 value-added services,
and labels packets
Version 3.9.0a
4. LSRs forward labeled packets

using label swapping
XMPLST4Module 1/10
Instructor's Note
Slide animation: Slides starts with network diagram; click 1 Existing protocols(#1),
double arrows between cloud routers, pointer; click 2 LDP(#2), dashed arrows, pointer; click 3
Ingress LSR(#3), packets, pointers; click 4 LSRs forward(#4), packets, pointer; click
5 Edge LSR, packets, pointer
Version 4.0.1
111
Module 1
Cisco IOS XR MPLS Architecture

Architecturally, Cisco IOS XR software is a modular operating system. It
separates the control plane and data plane. MPLS consists of some basic
elements that it implements. The terminology used in Cisco IOS XR
software implementation varies slightly from conventional terminology as
shown on the illustration on the opposite page.
The basic MPLS elements are divided between the physical route processor
(RP) and the line card. The CRS-1 Router has an RP, and a modular
services card (MSC) and Physical Layer Interface Module (PLIM)
combination. The Cisco XR12000 Series Router has a Performance Route
Processor (PRP) and a line card.
The MPLS elements are:
Control plane shared between RP and line card including:

!
Label switch database (LSD) or label information base (LIB)
Label forwarding database (LFD)
Data plane on the line card

!
LFD, in conjunction with the forwarding information base (FIB),

creates the label forwarding information base (LFIB)
MPLS encapsulation and decapsulation
MPLS LSPs are enabled in the network dynamically using signaling

protocols, such as LDP, Resource Reservation Protocol (RSVP), or BGP.
A static or explicit method of creating LSPs is typically used in traffic
engineering (TE) scenarios.
The dynamic protocols each handle the creation of the label switch paths
(LSPs) slightly differently:
LDP uses a hop-by-hop setup method
RSVP sets up end-to-end signaling that includes constraints such as

bandwidth limitations
BGP creates labels to identify specific traffic such as Layer 3 VPNs
Each of these is covered in additional contextual detail later in this course.

Rewrites (in the illustration) refer to preparing a label to be applied to an
outbound packet. Label information contains class of service (CoS) and
Time-to-Live (TTL) indicators, as well as the label needed to reach the next
hop. This information is retained in tables and used to rewrite the label
when forwarding the packet.
112
Version 4.0.1

Module 1
Cisco IOS XR MPLS Architecture
Basic elements
!
!
!
Label Switching Database (LSD)

Label Forwarding Database (LFD)
MPLS encapsulation and
decapsulation routines
RP
BGP
RSVP
IGP
LDP
Label Switch Database (LSD)
!
!
!
Allocates and deallocates labels

Maintains a rewrite database by
interacting with the LFD
Implements an API for MPLS
applications to create, modify, and
delete rewrites
(LFD)
!
!
!
LC*
Encap
or
decap
Label Forwarding Database

Accepts rewrites from the LSD
Links rewrite to the correct
forwarding tables
Sets up label tables for MPLS
encapsulation and decapsulation
RIB
LSD
FIB
LFD
LFIB
*LC means line card and may be the
CRS-1 MSC and PLIM combination
or XR 12000 Series router line cards
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/11
113
Module 1
Securing MPLS Core

MPLS VPNs (both Layer 2 and Layer 3) are important to customers
because they provide the ability to securely connect distant locations
together in order to assure their customers of that security, service
providers need to secure each individual router in their network.
Several other steps that protect the network are also critical:
Preventing packets from entering the core and disrupting the network
function, however the routing protocol may still be an open issue
Using security for the routing protocol, using authentication, maximum

routes available parameters, table sizes restrictions, aggressive timing
for routing updates, and for L2VPNs, using maximum MAC address
limits
Designing network resources to handle transit traffic and aggressively

limiting access to routers, while managing oversubscription, using
quality of service (QoS) to meet service level agreements (SLAs), and
securing edge and edge resources by limiting access to them, too
Operating securely by using authentication, authorization, and

accounting
The entry point, or edge, of the provider network is clearly the most
vulnerable point. A key factor to keep in mind is the choice of the routing
protocol selected to connect customer CE to provider PE.
114
Static routing is the most secure method because no dynamic updating

occurs
eBGP is next as it has many security features and includes redundancy

and dynamic updating that can be managed and protected
Other IGPs, such as RIPv2, EIGRP, or OSPF, may be the choice of the
customer. These have limited security features and should only be
employed by specific customer request
Version 4.0.1

Module 1
Securing MPLS Core
Secure each router individually

Prevent packets entering the core
Network still
open: routing
protocol
Secure the routing protocol using:
Leaves attack
vectors:
transit traffic,
Denial of Service
(DoS)
- Neighbor authentication, maximum routes,

other techniques
Design resources for transit traffic
! Use QoS to meet Service Level

Agreements (SLAs)
! Protect against oversubscription

! Secure edge and edge resources by
Now only insider

attacks possible
limiting access
Avoid insider
attacks
Operate securely
Version 3.9.0a
XMPLST4Module 1/13
Instructor's Note
Slide animation: Slide starts with first bullet; click 1 second bullet followed after 1 second by
yellow arrow and text box; click 2 third bullet followed after 1 second by yellow arrow and text
box; click 3 fourth bullet followed after 1 second by yellow arrow and text box; click 4 fifth
bullet followed after 1 second by yellow arrow and text box;
Version 4.0.1
115
Module 1
MPLS LDP Overview

This section covers a brief overview of the MPLS Label Distribution
Protocol (LDP).
MPLS Label Distribution Protocol

MPLS Label Distribution Protocol (LDP) is a method used to create label
paths to networks. It is deployed in core networks, and assigns labels to
underlying IGP prefixes. LDP is a control plane mechanism that binds
labels to prefixes, installs them in label databases, and distributes them to
neighboring LDP routers.
LDP dynamically sets up the paths, hop-by-hop, between neighboring label
switch routers (LSRs). The paths using labels through the core are called
Label Switch Paths (LSPs).
The LDP control plane is used to establish peering relationships with
adjacent neighbors by using a hello discovery. It may also be used to
establish peering relationships with distant routers by using a targeted
hello discovery.
LDP is deployed in core networks to provide services such as L2VPNs and
L3VPNs, and inter-autonomous system (Inter-AS) connectivity for VPNs.
It may also be used in core networks that employ BGP on only the edge
routers; known as a BGP-free core.
116
Version 4.0.1

Module 1
MPLS LDP Overview
MPLS Label Distribution Protocol
Labels represent the next hop toward a particular

destination
MPLS Label Distribution Protocol (LDP)
!Deployed in network core

!Labels set up dynamically hop by hop
!Labels assigned to underlying IGP routes
Label Switch Paths (LSP)
!Created dynamically by LDP
LDP control plane used for
!Peer discovery
!Peer session establishment
" Using hello discovery

" Targeted hello for non-adjacent neighbors
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/15
117
Module 1
Label Distribution
Each LSR creates a local binding or label for each IGP prefix in the local
routing information base (RIB) and stores the labels in the LIB as local.
The router distributes these local labels to each of its LDP neighbors. The
neighbors store these labels in their LIB as remote. Each LSR follows this
procedure for prefixes in its RIB.
An LSR may receive more than one remote label for a single prefix. The
LSR chooses the remote label based on the next hop for the prefix in its
RIB. It creates the LFIB labels using the best path routes.
In this simplistic illustration, the network, 10.1.1.0 with a mask of 24 bits
is attached to the router, R4. R4 assigns a label, 16043, to the prefix and
distributes the label upstream to R3. In turn, R3 enters the label in its
LIB. R3 assigns its own label to the prefix, 16032, and distributes it to R2.
R2 assigns the label, 16021, to the prefix and distributes it to R1.
When a device on a network attached to R1 wants to reach 10.1.1.0/24, R1
adds the label, 16021 to the outgoing packet. When the packet reaches R2,
it reads the label 16021 and swaps it for label 16032 and forwards the
packet to R3. This process continues until the packet reaches its
destination.
118
Version 4.0.1

Module 1
MPLS LDP Overview
Label Distribution
Local label binding

for 10.1.1.0/24 is
16021
R1
Local label binding

for 10.1.1.0/24 is
16032
R2
Local label binding

for 10.1.1.0/24 is
16043
10.1.1.0/24
R4
R3
Label 16021
Label 16032
Label 16043
10.1.1.0/24
10.1.1.0/24
10.1.1.0/24
Local labels bound to prefixes by router

Local labels sent to neighbors by LDP
Label is entered in LIB as remote label for prefix
Local label bound to prefix and sent to neighbors
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/16
119
Module 1
MPLS L3VPN Overview

In this section you review the basic concepts of Layer 3 Virtual Private
Networks (L3VPN) and their implementation.
MPLS Layer 3 Virtual Private Networks

MPLS Layer 3 Virtual Private Networks (L3VPN) provides service
providers a way to offer customers a secure connection between their
offices, to vendors, or for their own customers. The public IP network is
used to support these private networks.
The service provider uses BGP, static route, or an IGP to exchange routing
information between its edge router and the customer edge router.
Customers may use overlapping addresses; the use of L3VPNs isolates and
protects their network.
120
Version 4.0.1

Module 1
MPLS L3VPN Overview
Use public IP networks to

support private networks
Multicast
Customers connect to a
Hosting
service provider
Intranet
VoIP
Provider uses MPLS to
Extranet
forward data from ingress to

egress
!Any-to-any connectivity for

single VPN
Customers may use to
connect to vendors or other

customers
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/18
121
Module 1
L3VPN Services and Topologies

There are typically two types of topology implementations and services
that fit those implementations.
Single L3VPN or Intranet
This is the basic type of L3VPN in which multiple sites are connected
together, and each site has full connectivity to the other. The VPN is
isolated from other VPNs that the service provider supports. Customers
might use the same IP addressing within their networks and their own
VPNs as other service provider customers, but the separation prevents any
issue.
Central Services L3VPN
These types of VPNs are also called extranets. An example is multiple auto
parts stores that have access to a central site parts warehouse. However,
while the multiple sites have access to the central site, they do not have
access to each others networks. In this type of VPN some unique IP
addressing is required for customers to access both the extranet and their
own intranets.
122
Version 4.0.1

Module 1
MPLS L3VPN Overview
L3VPN Services and Topologies
Seattle
San Diego
Boston
IP
and
MPLS
Atlanta
Single L3VPN
Single VPN or Intranet
SP provides any-to-any connectivity and service between

the sites
VPN is separate from any other VPN in SP network
Customer A
Customer B
Customer C
IP
and
MPLS
Customer C
Central site
service
Central Services VPN
Selected sites have access

SP provides same any-to-any connectivity
Non-overlapping addresses required
Version 4.0.1
123
Module 1
L3VPN Overlapping Addressing and Separation

MPLS Layer 3 Virtual Private Network (L3VPN) service is a method of
providing individual customers with access to their network locations,
without requiring separate physical connections between each location, as
was required in the past.
L3VPNs let customers maintain their network addressing by prepending a
unique value on the IPv4 prefixes, to create a VPNv4 address. This keeps
each customer network separate from other customers.
The individual interfaces connecting the service provider equipment (PE)
with the customer equipment (CE) are part of the VPN. This separates the
addresses assigned to this interface from other customer networks.
The core uses IPv4 addressing managed by an interior gateway protocol
(usually OSPF or IS-IS). By using these unique identifiers, the core
network is separated from customer networks as well.
124
Version 4.0.1

Module 1
MPLS L3VPN Overview
L3VPN Overlapping Addressing and Separation
CE
L3VPN service
CE
L3VPN service
CE
0.0.0.0255.255.255.255
CE
mbehring
0.0.0.0255.255.255.255
PE-CE interfaces
belong to VPN
Data planes:
VPNv4 address
PE
Control plane:
IPv4 address
PE
Core address space

0.0.0.0255.255.255.255
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/22
125
Module 1
MPLS L2VPN Overview

In this section you cover basic information about Layer 2 Virtual Private
Networks (L2VPNs).
Traditional Approach to Layer 2 VPNs

The traditional approach to Layer 2 VPNs (L2VPN) is a service model that
connects the customer sites using Layer 2 type virtual circuits or transport
method. In this model, the core routers maintain individual information
about all the virtual circuits (VCs) that pass through them.
These L2VPNs are meant to replace the old leased lines that the customers
needed between sites, or ATM permanent virtual circuits (PVCs) and
Frame Relay data link connection identifiers (DLCIs) that they received
from service providers. These old methods were expensive.
126
Version 4.0.1

Module 1
MPLS L2VPN Overview
Service model used to interconnect customer sites using

Layer 2 virtual circuits (VC) or transport
Replaces traditional leased lines and virtual circuits such as

ATM PVCs or Frame Relay DLCIs
Core routers
have individual
VC information
VPN pink
VPN blue
VPN green
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/24
127
Module 1
Current Approach to L2VPNs

MPLS Layer 2 VPNs typically come in two varieties, point-to-point and
point-to-multipoint. In terms of implementation, a VPN must use the same
encapsulation method at both ends, such as Ethernet (most popular),
HDLC, ATM, or others.
The key L2VPN advantage is the absence of signaling between the
customer and the service provider.
Ethernet over MPLS (EoMPLS) is implemented in two ways:
Point-to-pointAll Ethernet traffic travels between sites over a single

virtual circuit (VC) or LSP
Virtual Private LAN Service (VPLS)Multiple sites are connected over

a full-mesh VC network
Ultimately, with L2VPNs, the transport is separate from the service;

therefore, the transport carries all the traffic as shown by the illustration
on the opposite page.
128
Version 4.0.1

Module 1
MPLS L2VPN Overview
Current Approach to L2VPNs
Use L2 transport mechanisms such as AToM or L2TPv3

VPN packets are forwarded based on L2 information
IP network provides both L2 and L3 services
Virtual circuits (VC)

carry all traffic
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/25
129
Module 1
MPLS Traffic Engineering Overview

In this section you briefly cover MPLS Traffic Engineering (MPLS-TE) at a
high level.
Traffic Engineering
What is traffic engineering? Most service providers research the traffic in
their network to understand how their resources are being used. Typically,
they use certain statistical techniques to analyze the data they collect. This
analysis helps them understand how they might be able to manage some
traffic to take advantage of their resources.
After they have analyzed the data, they can
Allocate resources to more high-profile traffic by using faster links
Move low-profile traffic to slower links
Use QoS to manage traffic queues
Using MPLS and RSVP, you can establish and maintain LSPs by using
particular resource requirements and available resources (usually
bandwidth) passed on by the IGPs.
Differentiated Services Traffic Engineering

Differentiated Services Traffic Engineering (DS-TE) is an IETF-defined
method of defining traffic into classes, and allocating resources based on
those definitions. There are eight defined traffic classes, of which four are
used with two priorities (high and low).
IETF DS-TE also employs two bandwidth allocation modes that meet many
of the service providers requirements for traffic engineering. The two
allocation methods are Maximum Allocation Bandwidth Constraints Model
(MAM) defined by IETF RFC 4125, and Russian Dolls Bandwidth
Constraints Model (RDM) defined by IETF RFC 4127.
130
Version 4.0.1

Module 1
Traffic Engineering
PRINT ONLY!!
What is it?
Statistical resource allocation techniques to control

network traffic
How does it work for MPLS?
Uses Resource Reservation Protocol (RSVP)
!Allocate and maintain LSPs

!Determine LSP path using
" Resource requirements

" Available resources (bandwidth)
Has resource information passed on by link-state IGP
!Specific extensions to protocols to carry resource

information
Differentiated Services Traffic Engineering

Version 3.9.0a
XMPLST4Module 1/28
IETF DS-TE
Traffic classes
!Eight defined; four used with two priorities
Bandwidth allocation modes
!Service provider requirements for DiffServ-aware support

!
!
for MPLS traffic engineering

Enforce different bandwidth constraints for different traffic
types
Models
" Maximum Allocation Bandwidth Constraints Model
(RFC 4125)
" "Russian Dolls" Bandwidth Constraints Model (RFC 4127)
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/29
131
Module 1
MPLS-TE Terminology
There are some terms that are important to the understanding of traffic
engineering:
132
HeadendThe router on which a particular tunnel is configured. This

router sends out the request for the resources to the intended
destination of the tunnel
TailendThe router that is the intended to be the destination of the

configured tunnel
MidpointAny router through which a tunnel passes
Version 4.0.1

Module 1
MPLS Terminology
TE Tunnel
R1
R2
R3
Network X
Headend
Midpoint
Tailend
Headend is a router on which a TE tunnel is configured (R1)

Tailend is a router on which TE tunnel terminates (R3)
Midpoint is a router through which TE tunnel passes (R2)
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/30
133
Module 1
MPLS-TE Operational Basics

The goal of traffic engineering is to use resources that are under-utilized.
Interior gateway protocols do not understand the resource availability of
links in the network.
Using TE, you need to take a request of 40 Mbps and find the best path,
while utilizing the available bandwidth resource. Note that the shortest
path does not accommodate the request.
If you let the IGP decide, it will send the data down a path that becomes
over-utilized and that, in turn, affects existing traffic and new traffic.
Customers whose traffic follows this path become dissatisfied.
Using TE, you can send the traffic over the other path and give the
customer what they need while not impacting other customers or traffic.
134
Version 4.0.1

Module 1
MPLS-TE Operational Basics
Available
bandwidth
for TE
80 Mbps
bp
s
0
10
50
10
30 Mbps
80 Mbps
100 Mbps
100 Mbps
Headend
s
bp
s
bp
M
s
bp
60
80
s
bp
60
Total link
bandwidth
bp
s
100 Mbps
Tailend
Use of network resources uneven

IGPs do not understand available bandwidth
!Attempt to send 40 Mbps of data would be slowed
Use TE to get around overused link

Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/31
135
Module 1
Resource Reservation Protocol Overview

In this section we cover the use of Resource Reservation Protocol as it
relates to MPLS-TE.
Resource Reservation Protocol

Resource Reservation Protocol (RSVP) is a transport protocol defined to
reserve resources within the network. It is defined originally in IETF
RFC 2205, and then refined in RFC 3209.
RSVP uses a resource request that is sent by the router initiating the
tunnel (headend). The resources are setup by the receiver router at the
tunnel end (tailend), by returning the request to the headend, and
reserving the resources at each midpoint along the path.
136
Version 4.0.1

Module 1
Resource Reservation Protocol
Transport layer protocol used to reserve

resources across a network
!Defined in RFC 2205

!Refined in RFC 3209
Uses receiver initiated setup for resource
requests of data flows
!Maintains the reservations for the flows

Used to create a label-switched paths (LSP) for
Traffic Engineering (TE) tunnels
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/33
137
Module 1
RSVP Path Setup

While the IGP does not understand the resources of the network, it can
carry the information using extensions to the protocol definitions. This
means the routers in the network have knowledge of the amount of
resources available at certain periods of time.
Based on the current knowledge of the network, the headend router
calculates the path it wants to use for a particular resource request. This is
done based on the traffic engineering topology learned through, and
calculated by, the IGP. The router sends an RSVP PATH message toward
the tailend router. At each router between the headend and tailend, the
PATH message is read and the resource request is noted.
When the PATH message reaches the destination, the tunnel tailend
returns a RESV message that reserves the resources and obtains MPLS
labels along the path.
After this path is calculated, the LSP is created and is used to forward the
data.
138
Version 4.0.1

Module 1
RSVP Path Setup
Path is calculated at headend
!Based on router network knowledge

!Known available resources, such as bandwidth
RSVP PATH message sent to tailend
!Resources requested along the path
RSVP RESV message returned by tailend
!When PATH message reaches it

!Reserves resources on return and obtains labels
After path is calculated, LSP built across the

path
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/34
139
Module 1
RSVP Path Setup for MPLS-TE Tunnel

In this example, router A wants a tunnel to router G. It sends the PATH
message, asking for a particular bandwidth along the path, from router A
to router C, to router D, to router E, and finally, to router G, the tailend.
Router G returns the RESV message that follows, in the reverse direction,
the same path as the PATH message. The RESV message reserves the
bandwidth needed at routers E, D, and ultimately A. In each router, a label
is allocated and transmitted to the upstream router, too.
140
Version 4.0.1

Module 1
RSVP Path Setup for MPLS-TE Tunnel
PATH message: Can I have bandwidth along this path?

RESV message: Yes, and here s the label to use.
= PATH messages
= RESV messages
Router B
Router F
Router A
Router E
Router G
Router C
Router D
Version 3.9.0a
Version 4.0.1
XMPLST4Module 1/35
141
Module 1
Summary
In this module, you learned:
142
Describe MPLS and Label Distribution Protocol (LDP)
Describe MPLS Layer 2 and Layer 3 tunnel concepts
Describe MPLS Traffic Engineering (TE) concepts and operation
Describe MPLS control and forwarding planes
Version 4.0.1

Module 2
MPLS OAM
Overview
Description
MPLS operations, administration, and maintenance (MPLS OAM) is a set
of tools that helps to diagnose and troubleshoot MPLS network
connectivity. This module takes a look at the need for MPLS OAM, what it
is, and how it is used in the Cisco IOS XR operating system. Relevant
MPLS OAM tasks are distributed throughout various lab exercises in this
course.
Objectives
Define the need for MPLS OAM
Describe the troubleshooting use of MPLS OAM
Identify the capabilities of MPLS OAM in Cisco IOS XR operating

system
Configure and manage MPLS OAM in an Cisco IOS XR operating

system network
Use MPLS ping and traceroute commands to verify MPLS

connectivity
Version 4.0.1
MPLS OAM
Module 2
Review
This is a review of some basic definitions relevant to the concepts that are
covered in this module.
Definition Review
These are some basic definitions used in the concepts of MPLS OAM:
LSRLabel switch router, provides label swapping and stacking

operations. If used as a LER, it may also perform label imposition and
disposition.
LERLabel edge router performs label imposition and disposition, if

used as a LSR, it may also perform label swapping or stacking
operations.
PHPPenultimate hop popping router is adjacent to the disposition

LER. Its function is to pop the outer most label in a stack so that the
LER focuses on the bottom label in a stack.
FECForwarding equivalence class

!
FEC is a group of packets that are forwarded in the same manner,

over the same path, and with the same forwarding treatment.
FEC may correspond to a destination IP subnet, a TE tunnel, a

pseudowire, or any traffic class that the edge-LSR considers
significant
Version 4.0.1

Module 2
Review
Definition Review
LSR: label switched router

LER: label edge router
PHP: penultimate hop popping
Traffic
LSR, LER
PHP
LSR
LSR
LSR, LER
FEC: forwarding equivalence class

An FEC is a group of packets which are forwarded in the same
manner, over the same path, and with the same forwarding treatment
An FEC may correspond to a destination IP network, a TE tunnel, a

pseudowire, or any traffic class that the edge-LSR considers
significant
Version 3.9.0a
XMPLST4Module #/3
Instructors Note
Just establish a baseline to be sure everyone has the same points of reference and resolve any
student questions.
Version 4.0.1
MPLS OAM
Module 2
The Need for MPLS OAM

This section explores why MPLS OAM is required; The section begins with
a reference diagram of the MPLS transport and services.
MPLS ReferenceTransport and Services

The reference diagram shows an overview of the MPLS core, where MPLS,
in conjunction with an IGP, provides the transport mechanism for various
customer services. The PE-to-PE services take advantage of the MPLS core
LSPs. These include L3VPNs, L2VPNs and TE tunnels that are built on
the RSVP protocol. In addition, service providers use Pseudowire
Emulation Service (PWES) to provide customer services using their IP
infrastructure.
MPLS coreLDP, in conjunction with the IGP, creates a label switched

core
PE to PE LSPs
Provide a basis for L3VPNs using MP-BGP
L2VPN pseudowires use targeted LDP sessions
TE tunnels are built using the RSVP protocol
PWESprovides customers a point-to-point L2 service using their

existing IP infrastructure. In this environment, providers have no
involvement with the customers routing.
Version 4.0.1

Module 2
MPLS ReferenceTransport and Services
MPLS L3VPN service

Customer A
Site 1
Customer A
Site 2
MPLS CORE
CE
CE
PE-PE LSPs
PWES
PE
PE
PWES
Pseudowires
Customer B
Site 1
TE tunnels
Customer B
Site 2
MPLS L2VPN service

Version 3.9.0a
Version 4.0.1
XMPLST4Module #/5
MPLS OAM
Module 2
Ping and Traceroute Review

Ping
Ping makes use of the Internet Control Message Protocol (ICMP) protocol.
There are two ping message types:
Type=8: ICMP echo request messages
Type=0: ICMP echo reply message
These messages contain an optional data field that is used to store the time
the ICMP echo request message was sent. This allows a system to
determine the message round trip time (RTT).
In the first example on the adjacent page the ping from R1 reaches R4,
which responds with an echo reply. The ping is successful. In the second
example the ping packet is lost due to a failure in the core of the network;
there is no response to the originating router resulting in a timeout error.
Traceroute
Traceroute makes use of the Internet Control Message Protocol (ICMP)

protocol and time-to-live (TTL) field on the IP header. Traceroute is sent
in a UDP packet encapsulated on an IP packet. The TTL-field of an IP
datagram is processed during handling by each router in its path.
If a router holds an IP-datagram for more than one second, it

decrements the TTL-field of that IP datagram by the number of seconds
it is held
If a packet is not held the router decrements the TTL-field by one
In the example on the adjacent page, a traceroute is being initiated from

R1 to R4. First an ICMP packet with a TTL of 1 is sent out. When R2
receives the ICMP packet, it decrements the TTL counter, to zero. Since R2
is not the destination router, it responds to R1 with a TTL-expired
message. R1 continues to increment the TTL counter, sending out ICMP
packets and receiving hop-by-hop responses, until the destination router is
reached, or there is a timeout. As a result of this operation, R1 has all the
ICMP error messages with the corresponding source addresses, enabling it
to display the complete route to the destination.
Version 4.0.1

Module 2
Ping and Traceroute Review
R1
R2
R3
R4
a. Ping reaches R4
R4 sends ICMP
echo response
ICMP echo req

to R4
ICMPbased
ping
Packet dropped between R1 and R4

time out occurs on R1
IP Dest=R4
TTL=1
IP Dest=R4
TTL=2
R2 drops packet
R2 sends TTL expired
ICMP message back to R1
R2 decreases TTL by 1
and forwards it to R3
R3 drops packet
sends TTL expired
ICMP back to R1
UDP/ICMPbased
traceroute
IP Dest=R4
TTL=3
R1 now has all the ICMP error messages with the corresponding source
addresses and can display the complete route to the destination
Version 3.9.0a
XMPLST4Module #/6
Instructor's Note
Instructors may wish to discuss failure scenarios for the traceroute command.
Version 4.0.1
MPLS OAM
Module 2
Ping or Traceroute with MPLS Encapsulation

Ping and traceroute use a LSP, if one is available. The criteria for this to
take place are:
Local router has MPLS enabled
Outbound interface is MPLS enabled
Next hop has a distributed label for the FEC
It is critical to remember that ICMP pings and traceroute can be successful

with a broken or even with no LSP. The reason is that in a single label
environment, if the next hop is unable to determine the FEC, the
underlying IP header is used, and the ping or traceroute is successful.
When two or more labels are present, such as, with L3VPNs, L2VPNs, and
TE tunnels, this operation is not successful.
Version 4.0.1

Module 2
Ping or Traceroute with MPLS Encapsulation
Ping or traceroute uses a LSP, if one exists for the

destination
!Requirements for LSP use are:
" Local router MPLS enabled

" Outbound interface MPLS enabled
" Next hop has a distributed label for the FEC
Be cautious, ICMP pings may be successful with either
!Broken path OR
!No MPLS path
!In a single label environment, if the next-hop cannot
determine the FEC, the underlying IP header is used

" The ICMP ping or traceroute is successful
" The above does not apply with two or more labels as with TE tunnels
or MPLS VPNs
Version 3.9.0a
XMPLST4Module #/7
Instructors Note
One confusing issue is that an ICMP ping might also use an LSP to forward packets. Traditional
ICMP would likely be encapsulated as an MPLS packet if MPLS is enabled on the source router.
This leads to nice discussion on the different failures that can be detected with ICMP and LSP
ping (that is, if packet is untagged it may still make it across network and so on)
Version 4.0.1
MPLS OAM
Module 2
MPLS Troubleshooting Without OAM

A typical assumption is that MPLS failures always cause devices to send
traps. In reality, customers are often aware of a fault before service
providers are.
Without MPLS OAM, troubleshooting path failures is a manual, tedious,
and time-consuming task that requires hop-by-hop tracing (inbound and
outbound labels for a FEC). The use of IP ping and traceroute are not
fully effective tools for this task.
10
Version 4.0.1

Module 2
MPLS Troubleshooting Without OAM
Assumption
MPLS failures always cause devices to send traps
Reality
Customer is often aware of the fault before the service
provider
MPLS troubleshooting prior to MPLS OAM

Manual
Hop-by-hop tracing (inbound and outbound labels for a FEC)

IP ping and traceroute not fully effective
Time consuming
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/8
11
MPLS OAM
Module 2
ReviewWhy MPLS OAM?

A LSP fault affects endtoend connectivity and customer services. Some
causes for LSP failure may be:
Broken LDP adjacency
MPLS not enabled (globally or per interface)
Mismatched labels
Software or hardware corruption
Detecting MPLS failures can be difficult without MPLS OAM for these
reasons:
12
Traditional ICMP-based pings might be successful and not detect the

failure
Unsuccessful pings provide no diagnostic information; they just timeout
Troubleshooting requires manual hop-by-hop inspection tracing

inbound and outbound labels for the FEC; a laborious time consuming
effort
Version 4.0.1

Module 2
ReviewWhy MPLS OAM
MPLS
A LSP fault affects endtoend

connectivity and services
49
50
Some causes for LSP failure
R4

MPLS not enabled (globally or per interface)
R2
R1
R3
LSP Broken
Mismatched labels
Software or hardware corruption
Detecting MPLS failures can be difficult
ICMP based pings might be successful

Unsuccessful pings provide no diagnostic information they just
timeout
Troubleshooting requires manual hop-by-hop inspection

Version 3.9.0a
Version 4.0.1
XMPLST4Module #/9
13
MPLS OAM
Module 2
Using MPLS OAM

This section discusses various uses of MPLS OAM and the commands it
provides.
MPLS LSP Ping and Traceroute

MPLS OAM enables the use of the ping and traceroute LSP tools for LSP
failure detection and diagnosis. These tools enable operators to quickly
detect routing errors or black holes, and isolate faults resulting from LSP
failures.
The requirements satisfied by these tools are:
The detection of MPLS black holes and misrouting
The ability to isolate MPLS faults
Verification of the MPLS control and data plane operation
The ability to determine the MTU of a LSP
The solutions available to meet these requirements are:
MPLS LSP ping provides connectivity checks
MPLS LSP traceroute provides hop-by-hop fault localization, MTU,

path, and multipath tracing
These tools are available for these network applications:
IPv4 LDP prefixes
VPNv4 prefixes
TE tunnels
L2VPNs (pseudowires)
The IETF has these RFCs for OAM:
14
RFC 4377 Operations and Management (OAM) Requirements for

Multi-Protocol Label Switched (MPLS) Networks
RFC 4378 A Framework for Multiprotocol Label Switching for

Operations and Management
RFC 4379 Detecting Multiprotocol Label Switched Data Plane

Failures (updated by RFC 5462)
Version 4.0.1

Module 2
Using MPLS OAM
Requirements:
Detect of MPLS black holes and misrouting

Isolate MPLS faults
Verify MPLS control and data plane
Determine the MTU of a LSP
Solutions:
MPLS LSP ping for connectivity checks

MPLS LSP traceroute for hop-by-hop fault localization, and path
tracing
Applications:
IPv4 LDP prefix, VPNv4 prefixes, TE tunnels, and L2VPNs

RFC standards:
RFC 4377, RFC 4378, RFC 4379

Version 3.9.0a
XMPLST4Module #/11
Instructor's Note
RFC 4379 is updated by RFC 5462.
Version 4.0.1
15
MPLS OAM
Module 2
MPLS OAM Tools

For LSP ping, traceroute and pseudowire (PW) virtual circuit connection
verification, use MPLS echo request and reply packets to test the LSPs.
16
MPLS LSP ping tests LSP connectivity for IPv4 LDP prefixes, TE
FECs, and any transport over MPLS (AToM) FECs
MPLS LSP traceroute traces the LSPs for IPv4 LDP prefixes, TE
FECs, and any transport over MPLS (AToM) FECs
Virtual Circuit Connection Verification (VCCV) tests the PW section of

an AToM VC
Version 4.0.1

Module 2
Using MPLS OAM
MPLS OAM Tools
LSP ping: End-to-end LSP connectivity check

LSP traceroute: Hop-by-hop fault localization
VCCV: Inband Virtual Circuit Connection Verification for AToM VC s
MPLS Echo-request
50 SA
DA
SA
Echo
SA=Source Addr
DA=Destination Addr
DA
Echo
49
50
R1
R3
R2
LSP Broken
Critical concepts:
Test packet follows the MPLS data path
Traditional IP ping or trace does not detect many MPLS failures
LSRs provide diagnostic information at the point of failure
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/12
17
MPLS OAM
Module 2
MPLS OAM Applicability

MPLS OAM supports testing LSPs created by LDP and RSVP-TE with the
ping and traceroute commands as follows:
18
MPLS LSPUse the ping MPLS IPv4 or traceroute MPLS IPv4

command
MPLS VPNUse the ping VRF or traceroute MPLS VRF command
MPLS TEUse the ping MPLS traffic-eng or traceroute MPLS trafficeng command
PseudowiresUse the ping MPLS pseudowire or traceroute pseudowire

multisegment command
Version 4.0.1

Module 2
Using MPLS OAM
MPLS OAM Applicability
MPLS OAM
CE
Ingress
PE
LSPs created by LDP and RSVP-TE
Egress
PE
CE
PWE3, TE
or
VPN Label
MPLS OAM supports
MPLS LSP
MPLS VPN
MPLS TE
Pseudowires (L2VPN)
Version 3.9.0a
XMPLST4Module #/13
Instructors Note
The traceroute pseudowire multisegment command supports testing a PW with a single
segment by specifying a destination address only with PE-ID
Version 4.0.1
19
MPLS OAM
Module 2
MPLS OAM Operation

This section describes MPLS OAM operation in more detail.
Operation of MPLS OAM

MPLS OAM is similar to traditional ICMP-based tools, in that the LSP
ping command is based on the echo request and reply, while the LSP trace
command uses an incremental TTL counter, just as the traditional trace
command.
This is where the similarity between these commands ends. LSP ping and
traceroute use a new packet format; UDP port 3503, for the UDP echo
request and echo reply. Additionally, to provide additional troubleshooting
information, the packets contain control and diagnostic information from
LSRs at the point of failure.
20
Version 4.0.1

Module 2
MPLS OAM Operation
MPLS OAM Operation
In principle MPLS OAM is similar to traditional (ICMP-based)

tools:
LSP Ping: Is based on echo request and echo reply

LSP Traceroute: Uses packets with an incrementing TTL
LSP ping and trace do not use ICMP packets:
New packet format specifically designed for MPLS OAM

IPv4 UDP packets with port 3503
UDP packets: MPLS echo-request or MPLS echo-reply
Packets contain control and diagnostic information from the
LSR at the point of failure

Return packets assist in fault localization with options to provide
additional troubleshooting information
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/15
21
MPLS OAM
Module 2

The MPLS LSP ping echo request and reply is useful for testing a LSP,
which is identified by the FEC stack. The echo request uses the same label
stack as the LSP; therefore, it is switched inband.
Assume that a network LSP is set up using LDP. The egress router has the
IP address, 10.4.4.4. The ingress routers FEC stack contains a single
element, an LDP IPv4 prefix with value 10.4.4.4/32. If the LSP being
tested is an RSVP LSP, at the other side of the LSP the FEC stack consists
of a single element; this element captures the RSVP session that uniquely
identifies the LSP.
The destination IP address within the echo request packet is 127/8. This is
not the IP address used for selecting the LSP, as described earlier, but this
address (127/8) is useful as a troubleshooting tool. Any router with a
broken LSP would use the 127/8 address for forwarding. As a result, the
router detecting the failed path would punt the packet for local processing,
as the egress router would. The RP generated echo reply uses the echo
requests source address and port as the destination address and port. The
routers outgoing interface IP address is used as the source address of the
reply. The echo reply interface may, or may not, be MPLS-enabled; so, the
echo reply can take an MPLS or IP path.
_____________________________ Note _________________________
MPLS LSP ping and traceroute verify LSP paths in only one direction.
__________________________________________________________________
22
Version 4.0.1

Module 2
MPLS OAM Operation
MPLS echo-request
MPLS echo-reply
MPLS LSP ping is based on echo request and echo reply operation
Echo request uses data path LSP for the specified FEC
Echo reply copies the echo request source address and port
!Uses the outgoing interface IP address as the source
Echo reply interface may, or may not, be MPLS enabled
!Echo reply may take an MPLS or an IP path
Note: MPLS LSP ping and traceroute verify LSP paths in only one
direction
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/16
23
MPLS OAM
Module 2
MPLS LSP Ping and Traceroute Failures

Some of the reasons an LSP may be down include:
MPLS not enabled
Mismatched labels
Software hardware corruption
The MPLS LSP ping and traceroute are valuable tools for diagnosing a
LSP failure. In this example, the failure between R3A and R2 results in
the LSP being down. As a result of the MPLS path failure, R3A processes
the packet using the IP header. R3A does not forward the echo request, but
responds with an echo reply, thus helping isolate the location of the LSP
path failure.
24
Version 4.0.1

Module 2
MPLS OAM Operation
MPLS LSP Ping and Traceroute Failures
MPLS Echo-request
R3A
MPLS Echo-reply
LSP Down
Some of the reasons an LSP can be down include:
! Broken LDP adjacency

! MPLS not enabled
! Mismatched labels
! Software or hardware corruption
IP header destination address (127/8) results in:
! Packet being processed by any router forwards the packet using

the IP header
In this example R3A does not forward the echo-request toward

R1:
! Drops the packet and replies to it accordingly
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/17
25
MPLS OAM
Module 2
Echo Request, Echo Reply Packet Format

LSP echo mode is used to test MPLS end-to-end connectivity by verifying
the FEC between the ingress and egress nodes. An MPLS echo request is
sent on the same path as data packets belonging to the same FEC. At the
FEC egress LSR, an echo reply packet is generated that contains the
appropriate return code.
The structure of the echo request and reply packets, with the IP header
and basic information they contain, is displayed on the adjacent page.
Field definitions:
Version number currently set to a value of 1
Message type determines whether packet is echo request or reply
26
Echo request value is 1
Echo reply value is 2
Reply mode controls how target router responds to echo request

!
Value of 1 do not reply
Value of 2 reply using an IPv4 UDP packet
Value of 3 reply using an IPv4 UDP packet with router alert (RA)
Return code discussed later in this module
Sender handle relevant to, and set by the sender; used to match all
echo replies and requests of a single ping
Sequence number set by sender, changed for every request sent
Timestamp fields in Network Time Protocol (NTP) format; time sent

by sender; time received by receiver
Version 4.0.1

Module 2
MPLS OAM Operation
Echo Request, Echo Reply Packet Format
Echo requestMPLS with IP (UDP)

Label TTL=255
IP (UDP) packet
IP or MPLS header
Version number
Must be zero
Message type Reply mode Return code Rtn subcode

Sender's handle
Sequence number
Source address: routable address

sender (core IGP)
Destination address: random
from 127.0.0.0/8
Destination port: 3503; TTL=1
Timestamp sent (NTP seconds)

Timestamp sent (NTP fraction of usecs)
Timestamp received (NTP seconds)
Timestamp received (NTP fraction of usecs)
TLVs
Echo replySame format as echo request
Response to an MPLS echo request

IP (UDP) packet
! Source address: routable address of

destination router responding interface
! Destination address: copied from echo
request
! Source port: well-known UDP (MPLS ping)
! Destination port: copied from echo request
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/18
27
MPLS OAM
Module 2
MPLS Echo Request Operation

When the ping mpls command is initiated, a MPLS echo request packet is
generated. The echo request payload can include LDP, L2VPN, or RSVP
circuit sub-TLV information, depending on the type of LSP being used. A
pad TLV is also included in the echo request for MTU testing. The type of
LSP that is being tested is chosen using the CLI as shown on the adjacent
page.
When issuing a MPLS pseudowire ping the target VC is specified as an
IPv4 address with PW-ID.
The return code field definitions are:
28
Return code there are seven (7) return codes from target router
!
Value of 0 error code contained in attached TLV section
Value of 1 malformed echo request was received
Value of 2 one or more TLVs are not understood
Value 0f 3 replying router is an egress for the FEC
Value of 4 replying router has no mapping for FEC
Value of 5 replying router not a downstream router
Value of 6 replying router is a downstream router; its FEC

mapping is the given label
Version 4.0.1

Module 2
MPLS OAM Operation
MPLS Echo Request Operation
MPLS LSP ping generates an MPLS

echo request
The packet payload contains:
IP or MPLS header
Version number
Must be zero
Message type Reply mode Return code Rtn subcode
MPLS echo header

Target FEC stack TLV
Pad TLV to pad the echo request to a
given size (for MTU testing)
Sender's handle
Sequence number
Timestamp sent (NTP seconds)
Timestamp sent (NTP fraction of usecs)
Timestamp received (NTP seconds)
Timestamp received (NTP fraction of usecs)
TLVs
The initiating router sets return code to 0

The replying router sets return code according
to the type of response
:router# ping mpls ?

ipv4
Target specified as an IPv4 address
pseudowire Ping over MPLS pseudowire
traffic-eng Target specified as TE tunnel interface
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/19
29
MPLS OAM
Module 2
Using Ping MPLS

When a LSP is created using LDP, the IPv4 FEC is a simple way to check
the health of the LSP. In this instance, a MPLS IPv4 ping originates on
PE66, with a destination address of 10.4.4.44. The LSP ping is successful.
The LSP ping has these available options:
30
address/mask: Address prefix of the target and network mask
destination (start address, end address, address increment): The

127/8 address used as the destination address in the echo request
packet
dsmap: Indicates that a downstream mapping (DSMAP) type length

and value should be included in the LSP echo request
exp: MPLS experimental field value in the MPLS header for echo
replies
force-explicit-null: Adds explicit null label to the MPLS label stack

and allows LSP ping to be used to detect LSP breakages at the
penultimate hop
interval: Send interval, in milliseconds, between requests
output interface: The output interface where echo request packets

are sent
repeat: Specifies the number of times a packet must be resent
reply dscp: The differentiated service codepoint value for an MPLS

echo reply
mode [ ipv4 | router-alert | no-reply]: Reply mode for the echo

request
reply pad-tlv: Indicates that a pad TLV should be included
revision: Specifies the Cisco extension TLV versioning field
size: Specifies the number of bytes in a echo request
source: Source address used in the echo request packet
sweep: Specifies a range of sizes for the echo packets sent
timeout: Specifies the timeout interval, in seconds
ttl: TTL value used in the MPLS labels
verbose: Verbose output information, includes MPLS echo reply,

sender address of the packet, and return codes
Version 4.0.1

Module 2
MPLS OAM Operation
Using Ping MPLS
ping mpls ipv4 address/mask [destination start-address end-address increment]

[dsmap] [exp exp-bits][force-explicit-null] [interval min-send-delay]
[output interface output interface] [repeat count] [reply {dscp dscp-value |
mode{ipv4 | no-reply | router-alert}| pad-tlv}] [revision version] [size packet-size]
[source source-address] [sweep min value max value increment] [timeout timeout]
[ttl value] [verbose]
:router# ping mpls ipv4 10.4.4.44/32

Sending 5, 100-byte MPLS Echos to 10.4.4.44/32,
Codes: '!' - success,'Q' - request not sent,'.' - timeout,'L' - labeled output intf,
'B' - unlabeled output interface,'D' - DS Map mismatch,'F' - no FEC mapping,
'f' - FEC mismatch,'M' - malformed request,'m' - unsupported tlvs, 'N' - no rx label,
'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
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/6/9 ms
Using Ping MPLS (Cont.)

Version 3.9.0a
XMPLST4Module #/21
:router# ping mpls ipv4 10.4.4.44/32 ?

destination
Destination address or address range
dsmap
Request dsmap from replying router
exp
EXP bits in mpls header
force-explicit-null Force an explicit null label to be added
interval
Send interval between requests in msec
output
Output options
pad
Pad TLV pattern
repeat
Repeat count
reply
Reply mode
revision
Echo packet TLV versioning
size
Packet size
source
Source specified as an IP address
sweep
sweep ping
timeout
Timeout in seconds
ttl
Time to live
verbose
Verbose output mode
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/22
31
MPLS OAM
Module 2
MPLS OAM VCCV Support

Virtual Circuit Connection Verification (VCCV) is an inband feature that is
used for verifying pseudowire connections. A single PE-to-PE tunnel is able
to service many pseudowires. MPLS ping can monitor the tunnel or the
PE-to-PE connectivity, but not the VCs inside the tunnel.
32
Version 4.0.1

Module 2
MPLS OAM Operation
MPLS OAM VCCV Support
PE2
PE1
CE
CE
Tunnel
CE
CE
Virtual Circuit Connection Verification (VCCV) is used

for pseudowire connections
VCCV uses ping and LSP ping technology
One tunnel can serve many pseudowires
MPLS LSP ping can monitor the PSN tunnel (PE-PE
connectivity), but not VCs inside of tunnel
Version 3.9.0a
XMPLST4Module #/24
LSP Ping is multiplexed onto the pseudowire
PE
PE
ping mpls pseudowire

Tunnel label
Tunnel label
VC label
VC label
VC label
LSP ping
LSP ping
LSP ping
Note: Traceroute is not applicable to VCCV
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/25
33
MPLS OAM
Module 2
Using MPLS LSP Ping and Traceroute

This section discusses the LSP ping and traceroute commands in more
detail.
MPLS Ping Output

The ping mpls command may or may be successful when used. Whether
successful or not, the command always provides a return code,
In the example, the ping mpls command is successful. The display shows
all of the possible return codes no matter the outcome of the command.
MPLS Ping Return codes

The output results always show one of the available codes.
The chart matches the return codes with the TLV field. For example, the
! output in the display denotes a successful MPLS ping. If the return
code is a Q, it indicates the echo request packet could not be sent; that,
for some reason, a LSP that matches the FEC data entered in the
command could not be found. In that case, you check the RIB, FIB, and
LIB for the FEC information to determine where the information is being
lost.
34
Version 4.0.1

Module 2
MPLS Ping Output and Return codes
router# ping mpls ipv4 10.3.3.33/32

Codes: '!' - success, 'Q' - request not sent,
'.' - timeout, 'L' - labeled output intf,
'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping,
'f' - FEC mismatch, 'M' - malformed request,
'm' - unsupported tlvs, 'N' - no rx label,
'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
Q return code means packet could not be

sent
Usually means an LSP matching the
entered FEC information on the
command line could not be found
!!!!!
Success rate is 100 percent (5/5),
round-trip min/avg/max = 4/6/9 ms
The ping command permits forcing LSP ping packets to follow

a specific path though a MPLS network
Codes
TLV
Meaning
Version 3.9.0a
No return code
Malformed echo request
Unsupported TLVs
Success
No FEC mapping.
Down Stream Map mismatch
Unknown Upstream Interface index
Reserved
Labeled output interface
Unlabeled output interface
10
FEC mismatch
11
No label entry
12
No receive interface label protocol
13
Premature termination of the LSP
unknown
Undefined return code
Transit router
Timeout
Request not sent
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/28
XMPLST4Module #/29
35
MPLS OAM
Module 2
Testing Successful MPLS Connectivity

First, to establish a point of reference, MPLS ping and traceroute
commands were initiated between PE66 and PE33 in a training lab. A
single MPLS path was used from PE66! P22! P11! PE33. These
commands show the results with MPLS operational on the interfaces in the
specified path.
36
Version 4.0.1

Module 2
Testing Successful MPLS Connectivity
RP/0/5/CPU0:PE66# ping mpls ipv4 10.3.3.33/32 verbose

timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,
<output omitted>
Type escape sequence to abort.
!
size 100, reply addr 192.168.113.3, return code 3
RP/0/5/CPU0:PE66# traceroute mpls ipv4 10.3.3.33/32
Tracing MPLS Label Switched Path to 10.3.3.33/32, timeout is 2 seconds
<output omitted>
0 192.168.126.6 MRU 1500 [Labels: 16001 Exp: 0]
L 1 192.168.126.2 MRU 1500 [Labels: 16001 Exp: 0] 31 ms
L 2 192.168.112.1 MRU 1500 [Labels: implicit-null Exp: 0] 95 ms
! 3 192.168.113.3 10 ms
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/30
37
MPLS OAM
Module 2
MPLS Failure on the Egress Link

In the first example on the adjacent page, MPLS is disabled on the input
link to PE33. MPLS traceroute and ping commands are issued from
PE66 to PE33.
As a follow-up, MPLS is enabled on PE33s input link and disabled on the
output link of P11. Again, MPLS ping and traceroute commands are
used. In both cases, the MPLS traceroute command detected that the link
between P11 and PE33 is unlabeled. The traceroute command detected
the point of failure.
The MPLS ping command is successful in both cases, however. It does not
detect the failure because the packet is forwarded out of the correct
interface based on inbound label information.
MPLS Failure Between P Routers

In the second example on the adjacent page, two different failures are
introduced, one where MPLS is disabled inbound to P11, and then
outbound from P22. In both cases, MPLS traceroute and ping commands
detect the failure. Traceroute reported the unlabeled output interface on
P22, while ping reports a FEC mismatch on P11s inbound interface.
Refer to the return code table earlier in this module for the code meanings.
38
Version 4.0.1

Module 2
MPLS Connectivity Failure
LSP
broken
49
P22
P11
PE66
PE33
Note: - MPLS disabled on interface; input to PE33 or

outbound from P11
- Traceroute MPLS detects unlabeled interface
from P11 to PE33
- Ping MPLS does not detect the failure on the
link to the egress router, based on ingress
label ping forwarded to PE33
:PE66# traceroute mpls ipv4 10.3.3.33/32 verbose

Thu Sep 23 13:35:39.059 UTC
0 192.168.126.6 10.2.2.22 MRU 1500 [Labels: 16001 Exp: 0]
L 1 192.168.126.2 192.168.112.1 MRU 1500 [Labels: 16001 Exp: 0] 22 ms, ret code 8
B 2 192.168.112.1 192.168.113.3 MRU 1500 [No Label] 14 ms, ret code 9
:PE66# ping mpls ipv4 10.3.3.33/32
Thu Sep 23 13:38:13.026 UTC
!
Version 3.9.0a
49
P22
PE66
P11
PE33
Additional output omitted
XMPLST4Module #/32
Note: - MPLS disabled on interface; input to P11 or

outbound from P22
- Traceroute MPLS detects an unlabeled interface
from P11 to P22
- Ping MPLS reports a FEC mismatch for
inbound interface on P11

'L' - labeled output interface, 'B' - unlabeled output interface,
0 192.168.126.6 10.2.2.22 MRU 1500 [Labels: 16001 Exp: 0]
B 1 192.168.126.2 192.168.112.1 MRU 1500 [No Label] 18 ms, ret code 9
:PE66# ping mpls ipv4 10.3.3.33/32 ver
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
f
Success rate is 0 percent (0/5)
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/33
39
MPLS OAM
Module 2
FIB and LFIB Inconsistency

In the example on the adjacent page, there is a customer complaint that
the service provider is dropping traffic. If a standard ping is issued from
PE1-to-PE2, the ping is lost as the result of LFIB error on P2; that is, the
traffic is directed to P3, based on the LFIB. PE2s echo reply contains a
label of 70. The LFIB on P2 directs this traffic to P3 with a label of 60. P3
has no label binding for 60, and drops the packet.
In the second example, the MPLS ping is issued with the router-alert
option. When PE2 generates a reply, it places the router-alert label (label
value of 1) on top of the stack, prior to label 70. P2 receives the reply, sees
the router-alert label (value of 1), and punts the packet for local processing.
P2 uses the FIB containing an outgoing label of 80, for an inbound label of
70, and the echo reply is successful. This type of problem indicates a FIB
inconsistency within the network and additional troubleshooting is
necessary.
40
Version 4.0.1

Module 2
FIB and LFIB Inconsistency
PE2 receives echo request and generates an echo reply to PE1

Echo reply comes to P2 with top label 70
! With corrupted LFIB echo reply is switched to P3 with label 60
P3 does not have a label binding for label 60 and drops the packet
LSP ping fails
Version 3.9.0a
XMPLST4Module #/35
* Top label 1 is a router alert label
:PE1# ping mpls ip 10.200.0.1/32 reply mode router-alert

Codes: '!' - success, 'Q' - request not transmitted,
!!!!!
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/33
41
MPLS OAM
Module 2
MPLS Traceroute
There are two fundamental types of traceroute. The first kind is a path
trace that provides information about only one path out of all the possible
Equal Cost Multipaths (ECMPs). The second is the multipath trace that
provides information on all possible paths between source and destination.
Both of these options are further explored in this section.
42
Version 4.0.1

Module 2
MPLS Traceroute
Two traceroute types

Path
Multipath
Path A
Path B
Path traceGives information about only one path out of all possible
equal cost multipaths (ECMPs)
Path trace from PE1 to PE2 gives information about path A OR path B
Multipath traceReturns all possible paths between source and
destination
Multipath trace from PE1 to PE2 gives information about path A AND path B
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/34
43
MPLS OAM
Module 2
Using MPLS Traceroute

The MPLS traceroute command incrementally increases the value
(starting at 1) of the TTL field as it sends out successive echo requests
looking for the destination router. The expiration of the TTL filed at each
node along the path results in these nodes returning MPLS echo replies
that contain information about them. Here are some results of the path
trace:
0 192.168.126.6 MRU 1500 [Labels: 16001 Exp: 0]This is the path

trace originating interface on PE66, displayed as hop 0
L 1 192.168.126.2 MRU 1500 [Labels: 16001 Exp: 0] 31 msThis is

the inbound labeled interface on P22, displayed at hop 1

This is the inbound labeled interface on P11, displayed at hop 2
! 3 192.168.113.3 10 msThis is the inbound interface to the

destination router PE33, hop 3, the ! denotes a successful path trace
MPLS traceroute has a rich set of options just as MPLS ping. Once the
traceroute mpls command is issued there are three parameter choices:
44
IPv4Target is specified as an IPv4 address
MultipathLSP multipath traceroute
Traffic-engTarget specified is a tunnel interface
Version 4.0.1

Module 2
Using MPLS Traceroute
PE66
P22
P11
PE33
:PE66# traceroute mpls ipv4 10.3.3.33/32

Thu Sep 23 13:29:53.848 UTC
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
0 192.168.126.6 MRU 1500 [Labels: 16001 Exp: 0]
L 1 192.168.126.2 MRU 1500 [Labels: 16001 Exp: 0] 31 ms
! 3 192.168.113.3 10 ms
Version 3.9.0a
XMPLST4Module #/39
:P66# traceroute mpls ?

ipv4
multipath
LSP multipath traceroute
traffic-eng Target specified as TE tunnel interface
:P66# traceroute mpls multipath ?
ipv4
:P66# traceroute mpls ipv4 10.3.3.33/32 ?
destination
exp
flags
Flag options
hashkey
Downstream map multipath settings
interval
Send interval between requests
output
Output options
reply
Reply mode
retry-count
Echo request retry count
revision
Echo Packet TLV versioning
source
timeout
Timeout in seconds
ttl
Maximum time to live
verbose
Verbose output mode
<cr>
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/37
45
MPLS OAM
Module 2
Finding a Maximum Transmission Unit (MTU) Mismatch

This section discusses determining mismatches of transmission units.
Finding a MTU Mismatch with Traceroute

In this example, the MTU size of the interface from P22 to P11 was
changed to 1000 bytes.
As seen from the MPLS traceroute verbose command output, the
maximum receive unit (MRU) outbound from P22 is 986 bytes; that is, the
payload less the Ethernet header, but including the 4-byte label.
The output shows the valuable path troubleshooting information the MPLS
traceroute command provides.
46
Version 4.0.1

Module 2
Finding a Maximum Transmission Unit (MTU) Mismatch
Finding a MTU Mismatch with Traceroute
PE66
P22
MTU set to 1000
P11
PE33

Thu Sep 23 19:19:57.469 UTC
0 192.168.126.6 10.2.2.22 MRU 1500[Labels:16001 Exp:0]
L 1 192.168.126.2 192.168.112.1 MRU 986[Labels:16001 Exp:0]26 ms,ret code 8
L 2 192.168.112.1 192.168.113.3 MRU 1500[Labels:implicit-null Exp:0]26 ms,ret code 8
! 3 192.168.113.3 6 ms, ret code 3
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/41
47
MPLS OAM
Module 2
MPLS OAM Multipath Trace

The multipath feature of traceroute is a tool used to discover all possible
paths of an LSP between the ingress and egress routers.
Multipath Trace
The syntax for the traceroute MPLS multipath IPv4 command is shown
A multipath trace:
Allows the auto discovery of multiple MPLS paths in a cloud

!
Identifies all possible paths between two end points
Verifies load balanced paths
May be used separately, or in combination with, an IP SLA LSP health

monitor
May be used to check the health of the multiple paths
Path failures may affect SLAs and services for some traffic flows, but not
others. The flows affected are linked to the failing paths
48
Version 4.0.1

Module 2
Multipath Trace
:router#
traceroute mpls multipath ipv4 address/mask [destination start-address end-address
address-increment] [exp exp-bits] [flags fec] [force-explicit-null] [hashkey ipv4
bitmap bit-size] [interval min-send-delay] [output interface type interface-path-id
[nexthop nexthop-address] ] [reply {dscp dscp-value | mode{ipv4 | router-alert}]
[retry-count count] [revision version] [source source-address] [timeout timeout]
[ttl value] [verbose]
Allows the auto discovery of multiple MPLS paths in a cloud

Identifies all possible paths between two end points
Verifies load balanced paths
May be used in combination with an IP SLA LSP health monitor

May be used to check the health of the multiple paths
Enables better understanding of the MPLS network, allowing for easier
troubleshooting
Enables more efficient monitoring of the transport LSPs

A path failure
!May affect SLAs and services for some flows

Version 3.9.0a
Version 4.0.1
XMPLST4Module #/43
49
MPLS OAM
Module 2
LSP Multipath Trace Example

The traceroute multipath ipv4 command can automatically insert an IP
destination address of 127/8 in the traceroute. In addition, the multipath
trace tool can vary the 127/8 address automatically when sending packets.
Varying the value of the IP address (127/8), allows the tool to explore different
MPLS paths for an FEC.
The alternative to this automatic feature is to manually specify a destination
address, increase it monotonically with successive traceroute transmissions,
and note the path taken each time.
50
Version 4.0.1

Module 2
LSP Multipath Trace Example
R3
Path 127.0.0.1
R1
R4
R2
R6
Path 127.0.0.2
Path 127.0.0.3
Path 127.0.0.4
R7
R8
R9
R1 has a comprehensive map of equal cost paths and can test

all path permutations with a minimum number of pings
Alternative is to monotonically increase 127/8 address
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/41
51
MPLS OAM
Module 2
Multipath Trace CLI Command

This traceroute mpls multipath command provides a convenient means
to identify multiple paths that exist between two devices. The command
provides a list of LSP selectors to simulate the discovered paths:
The syntax for the traceroute mpls multipath ipv4 command to
automatically discover more than 32 paths includes prefix address and
mask. It may also include options such as a hashkey and bitmap to
increase the path size beyond 32 possible selectors.
The sample CLI command, using two (2) bits in the map, sends
traceroute commands to destination IP addresses 127.0.0.1 and 127.0.0.2,
only.
Special consideration needs to be taken when selecting a prefix block size.
If the block is too large, there are too many IP addresses to test and
resources are wasted, if it is too small, a group of paths may not be
discovered.
52
Version 4.0.1

Module 2
Multipath Trace CLI Command
:router# traceroute mpls multipath ipv4 10.3.3.33/32 hashkey ipv4 bitmap 2
bitmap 2 ! specify the number of bits as 2; for example 127.0.0.1, 127.0.0.2
Choosing a LSP
Varying the value of the IP address 127/8
! Allows exploration of the different MPLS paths for an FEC
Each network has an optimal size for the trace

If the block too large; there are too many IP addresses to test
If the block too small; whole set of paths in a network are not
discovered
Bitmap identifies the number of paths between two devices
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/45
53
MPLS OAM
Module 2
Equal Cost Multipath

Using our lab architecture, we explore equal cost multipath. On PE66 we
look at the routing table, built using ISIS, for the destination network on
PE33 (10.3.3.33). The routing table contains two (2) equal cost paths, one
through P22 (192.168.126.2) and the other through P11 (192.168.116.1).
In the second example, the traceroute mpls multipath ipv4
10.3.3.33/32 command is used to initiate the testing, and determine the
number of available paths from PE66 to PE33. From the truncated display,
you can see that two paths were discovered. The first path displayed goes
through P22, and the second path uses P11. In addition, summary
information is provided to show how many paths were found, and whether
any paths are broken or unexplored. Also displayed is the echo request and
reply data with elapsed transit time.
54
Version 4.0.1

Module 2
Equal Cost Multipath
MPLS trace identifies number of paths

between PE pairs
Provides accurate MPLS topology
Tests every ECMP to destination and
10.3.3.33
PE33
10.1.1.11
PE55
P1
identifies failures
Tells you how to test failed paths
Example shows two paths between

PE66 and PE33
10.5.5.55
P2
PE44
10.2.2.22
10.4.4.44
PE66
10.6.6.66
:PE66# show route 10.3.3.33

Fri Sep 24 14:07:20.176 UTC
Routing entry for 10.3.3.33/32
Known via "isis L2-12", distance 116, metric 20, type level-2
Installed Sep 24 13:38:45.831 for 00:28:34
Routing Descriptor Blocks
192.168.126.2, from 10.3.3.33, via GigabitEthernet0/4/0/0
Route metric is 20
192.168.116.1, from 10.3.3.33, via GigabitEthernet0/4/0/3
Route metric is 20
No advertising protos.
Version 3.9.0a
XMPLST4Module #/47
:PE66# traceroute mpls multipath ipv4 10.3.3.33/32

Starting LSP Path Discovery for 10.3.3.33/32
L!
Path 0 found,
output interface GigabitEthernet0/4/0/0 nexthop 192.168.126.2
source 192.168.126.6 destination 127.0.0.0
L!
Path 1 found,
Paths (found/broken/unexplored) (2/0/0)
Echo Request (sent/fail) (4/0)
Echo Reply (received/timeout) (4/0)
Total Time Elapsed 101 ms
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/48
55
MPLS OAM
Module 2
Traceroute MPLS Multipath Verbose

The traceroute mpls multipath ipv4 10.3.3.33/32 verbose command
provides additional information in the command output. Hop-by-hop data,
that includes the MRU and label information for each hop, is shown. This
information assists greatly in troubleshooting, because it pinpoints the
area of the network where a failure has occurred, and provides an error
code to define what has caused the error.
This table shows return codes, TLV value, and the meaning of the code.
Codes
56
TLV
Meaning
No return code
Malformed echo request
Unsupported TLVs
Success
No FEC mapping.
Down Stream Map mismatch
Unknown Upstream Interface index
Reserved
Labeled output interface
Unlabeled output interface
10
FEC mismatch
11
No label entry
12
No receive interface label protocol
13
Premature termination of the LSP
unknown
Undefined return code
Transit router
Timeout
Request not sent
Version 4.0.1

Module 2
Traceroute MPLS Multipath Verbose
:PE66# traceroute mpls multipath ipv4 10.3.3.33/32 verbose

L!
Path 0 found,
0 192.168.126.6 192.168.126.2 MRU 1500 [Labels: 16001 Exp: 0] multipaths 0
L 1 192.168.126.2 192.168.123.3 MRU 1500 [Labels: impl-null Exp: 0]ret code 8 multipaths 1
! 2 192.168.123.3, ret code 3 multipaths 0
L!
Path 1 found,
0 192.168.116.6 192.168.116.1 MRU 1500 [Labels: 16001 Exp: 0] multipaths 0
L 1 192.168.116.1 192.168.113.3 MRU 1500 [Labels: impl-null Exp: 0] ret code 8 multipaths 1
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/49
57
MPLS OAM
Module 2
MPLS Disabled on P to PE Link

In this example, one leg of the MPLS multipath was disabled. MPLS was
disabled on the inbound interface of P22 as shown in the diagram. Path 0
is sited as being broken between PE66 and P22, the result of no label being
sent from P22 to PE66. Note that the MRU information on the link is
presented, even though MPLS is down.
The summary information shows one successful path and one broken path.
58
Version 4.0.1

Module 2
MPLS Disabled on P to PE Link
10.3.3.33
PE33
10.1.1.11
PE55
10.5.5.55
MPLS is disabled on
P22 s PE facing interface
P11
P22
10.4.4.44
PE44
10.2.2.22
PE66
10.6.6.66
:PE66# traceroute mpls multipath ipv4 10.3.3.33/32 verbose

Path 0 Broken,
0 192.168.126.6 192.168.126.2 MRU 1500 [No Label] multipaths 0
L!
Path 1 found,
0 192.168.116.6 192.168.116.1 MRU 1500 [Labels: 16001 Exp: 0]
L 1 192.168.116.1 192.168.113.3 MRU 1500 [Labels: implicit-null Exp: 0]
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/50
59
MPLS OAM
Module 2
MPLS OAM with Traffic Engineering

MPLS OAM enables testing MPLS TE tunnels built using RSVP. Both the
ping and traceroute commands are fully supported.
Verify RSVP Path with MPLS Ping

The example on the adjacent page shows that MPLS OAM provides a full
range of ping MPLS options.
60
Version 4.0.1

Module 2
Verify RSVP Path with MPLS Ping
:PE66# ping mpls traffic-eng tunnel 1 ?

destination
dsmap
Request dsmap from replying router
exp
interval
Send interval between requests in msec
pad
Pad TLV pattern
repeat
Repeat count
reply
Reply mode
revision
Echo packet TLV versioning
size
Packet size
source
sweep
sweep ping
timeout
Timeout in seconds
ttl
Time to live
verbose
Verbose output mode
<cr>
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/52
61
MPLS OAM
Module 2
MPLS Ping and Traceroute for TE Tunnels

The ping mpls traffic-eng tunnel 14 command displays a successful
ping through tunnel 14, from PE66 through P11, to PE33.
The traceroute mpls traffic-eng tunnel 14 command displays a
successful trace of the route through tunnel 14, from PE66 through P11, to
PE33. The overall output and operation is the same as in any MPLS
network, except here, the path tracked is a RSVP tunnel.
62
Version 4.0.1

Module 2
MPLS Ping and Traceroute for TE Tunnels
:PE66# ping mpls traffic-eng tunnel 14

!!!!!
:PE66# traceroute mpls traffic-eng tunnel 14
Tracing MPLS TE Label Switched Path on tunnel-te14, timeout is 2 seconds
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'P' - no rx intf label prot, 'p' - premature termination of LSP,
'R' - transit router, 'I' - unknown upstream index,
0 192.168.116.6 MRU 1500 [Labels: 16041 Exp: 0]
! 2 192.168.113.3 7 ms
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/53
63
MPLS OAM
Module 2
MPLS OAM with Virtual Circuit Connection Verification (VCCV)

MPLS OAM supports ping and traceroute options for testing
pseudowires using VCCV.
L2VPN Pseudowire Connection Verification

In the example on the adjacent page, a pseudowire is successfully tested
between PE33 and PE66.
64
Version 4.0.1

Module 2
MPLS OAM with Virtual Circuit Connection Verification (VCCV)
L2VPN Pseudowire Connection Verification
10.5.5.55
10.3.3.33
Attachment VC
PE33
10.1.1.11
PE55
P11
VCCV Packet
Attachment VC
P22
PE44
10.2.2.22
Two Labels 10.4.4.44
PE66
10.6.6.66
RP/0/5/CPU0:PE33# ping mpls pseudowire 10.6.6.66 3001

Sending 5, 100-byte MPLS Echos to 10.6.6.66 VC: 3001,
!!!!!
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/55
65
MPLS OAM
Module 2
Configuration and Management of MPLS OAM

MPLS OAM is disabled by default in the Cisco IOS XR operating system. It
is enabled using the mpls oam configuration command.
MPLS OAM Configuration

MPLS OAM is enabled using the mpls oam command. When OAM is
enabled, the echo command option lets you to disable vendor support, take
the default option, or select a vendor-specific echo revision. Specific vendor
TLVs are sent by default with the echo command. For interoperability
purposes, vendor support is typically disabled.
When MPLS OAM is enabled, the default option is automatically selected.
66
Version 4.0.1

Module 2
MPLS OAM Configuration
MPLS OAM disabled in Cisco IOS XR operating system

One single global configuration line
:router(config)# mpls oam
Optionally, with echo command
! Disable vendor support

! Select version support
:router(config-oam)# echo ?
disable-vendor-extension Disable sending vendor extension TLV with
echo request
revision
Echo packet default revision
:router(config-oam)# echo revision ?
1 draft-ietf-mpls-lsp-ping-03 (initial)
2 draft-ietf-mpls-lsp-ping-03 (rev 1)
3 draft-ietf-mpls-lsp-ping-03 (rev 2)
4 draft-ietf-mpls-lsp-ping-09 (initial)
Version 3.9.0a
XMPLST4Module #/57
Instructor's Note
In IOS OAM is enabled by default
Version 4.0.1
67
MPLS OAM
Module 2
Managing MPLS OAM

There are a variety of MPLS OAM show commands. Our focus here is on
only two of the command options, interfaces and clients.
The clear commands offer the options to clear global, interface, and packet
counters.
68
Version 4.0.1

Module 2
Managing MPLS OAM
Show commands
:router# show mpls oam ?
client
clients registered with LSPV server
counters
LSP verification counters
database
information about active LSP verification databases
interface Specify an interface
trace
Trace data
Clear commands
:router# clear mpls oam ?
counters Counters information
:router# clear mpls oam counters ?
global
Clear global counters
interface Specify an interface
packet
Clear global packet counter
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/58
69
MPLS OAM
Module 2
MPLS OAM Interfaces

The show mpls oam interface command provides a display of OAMenabled interfaces on a particular router, their state, MTU, IP address,
and mask. In addition, the command output may be filtered by interface
type.
MPLS OAM Clients

The show mpls oam client command provides a display of client
processes that utilize MPLS OAM. As seen in the output, L2VPNs, TE
control, and MPLS LDP are all MPLS OAM client processes. In this case,
these processes are operational on the SDR in slot 5. Additionally, the
process IDs are listed for each process.
70
Version 4.0.1

Module 2
MPLS OAM Interfaces and Clients
:router# show mpls

GigabitEthernet
Loopback
MgmtEth
Multilink
Null
POS
Serial
VASILeft
VASIRight
all
tunnel-te
oam interface ?
GigabitEthernet/IEEE 802.3 interface(s)
Loopback interface(s)
Ethernet/IEEE 802.3 interface(s)
Multilink network interface(s)
Null interface
Packet over SONET/SDH network interface(s)
Serial network interface(s)
VASI Left interface(s)
VASI Right interface(s)
Display all interfaces
MPLS Traffic Engineering Tunnel interface(s)
:router# show mpls oam interface all

Interface
State
MTU
-------------------------- ---------- ----Loopback0
up
0
MgmtEth0/5/CPU0/0
up
1500
GigabitEthernet0/4/0/0
up
1500
up
1500
up
1500
IP
---------------10.6.6.66/32
172.21.116.64/24
192.168.126.6/24
192.168.156.6/24
192.168.116.6/24
Version 3.9.0a
Index
---------0x00000007
0x00000005
0x00000002
0x00000003
0x00000004
XMPLST4Module #/60
:router# show mpls oam client

Client Process: l2vpn_mgr Node: 0/5/CPU0 Pid: 196816
Client Process: te_control Node: 0/5/CPU0 Pid: 213212
Client Process: mpls_ldp Node: 0/5/CPU0 Pid: 213213
Instructor's Note
Index is for internal use and relates to the unique interface descriptor block for engineering
troubleshooting.
Pid is the process ID.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/61
71
MPLS OAM
Module 2
Summary
MPLS OAM
In this module, you learned to:
72
Define the need for MPLS OAM
Describe the troubleshooting use of MPLS OAM
Identify the capabilities of MPLS OAM in Cisco IOS XR operating

system
Configure and manage MPLS OAM in a Cisco IOS XR operating system

network
Use MPLS ping and traceroute commands to verify MPLS

connectivity
Version 4.0.1

Module 3
MPLS LDP
Overview
Description
This module describes the MPLS Label Distribution Protocol (LDP). It
discusses the basic protocol operation of LDP, such as message exchanges
that occur between neighboring label switching routers (LSRs). The
module provides a description of the major data structures used to hold
label information. It also explains how LSRs discover each other and
maintain state information. The module also contains a series of CLI
examples used to configure LDP, and to examine status and statistical
information.
Objectives
Define the fundamental concepts of LDP
Describe the operation of LDP
Describe the operation of LDP on Cisco IOS XR operating system
Describe the Cisco IOS XR MPLS Forwarding Infrastructure
Configure basic LDP plus LDP with feature enhancements
Describe LDP pseudowire signaling
Describe and use LDP troubleshooting commands
Version 4.0.1
31
MPLS LDP
Module 3
Components of LFIB
The Label FIB (LFIB) consists of three main components: Next Hop Label
Forwarding Entry (NHLFE), FEC-to-NHLFE (FTN) and Incoming Label
Map (ILM). Each is discussed separately. First we define forwarding
equivalence class (FEC), which is critical to the understanding of the three
components of the LFIB
Forwarding Equivalence Class (FEC)

FEC refers to a group of IP packets that are forwarded in the same
manner, over the same path, and with the same forwarding treatment.
An FEC may correspond to a destination IP network
An FEC may correspond to any traffic class that the Edge-LSR

considers significant. For example, all traffic with a certain value of IP
precedence might constitute a FEC
At the ingress of an MPLS network, packets entering the MPLS domain

are assigned to an FEC. These packets belonging to this FEC are
associated with a NHLFE (an MPLS label) using the FEC-to-NHLFE
mapping (For more detail, see RFC 3031 Multiprotocol Label Switching
Architecture). This relationship defines how ingress LSRs imposes MPLS
labels onto incoming packets. It also defines how egress LSRs
de-encapsulate the MPLS header from outgoing MPLS packets.
32
Version 4.0.1
Cisco IOS XR MPLS and Tunnel

Technologies for IPv4
Module 3
Components of LFIB
Forwarding Equivalence Class (FEC)
Forwarding equivalence class (FEC)
!Term used in MPLS to describe a set of packets

with similar or identical characteristics that
" May be forwarded the same way
" May be bound to the same MPLS label
Typical characteristic determining the FEC of a

packet is a destination IP network
FEC corresponds to a label switched path (LSP)

LSP can be used for multiple FECs
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/4
33
MPLS LDP
Module 3
Next Hop Label Forwarding Entry (NHLFE)

The NHLFE entry is used when forwarding a labeled packet. It contains
the following information:
Packets next hop
Operation to perform on the packets label stack, which could be:

!
Replace the label at the top of the label stack with a specified new
label
Pop the label stack
Replace the label at the top of the label stack with a specified new
label, and then push one or more specified new labels onto the label
stack
The NHLFE may also contain:

!
Data link encapsulation to use when transmitting the packet
Way to encode the label stack when transmitting the packet
Any other information needed to properly dispose of the packet
If the packets next hop is the current LSR (egress LSR or label edge router
(LER)), then the label stack operation MUST pop the stack.
In the sample output from PE66 showing NHLFE information, note that:
MAC/Encaps for the unlabeled path is 14/14; the first number is the
size of the MAC header and the second number is the MAC header plus
the label
MAC/Encaps for the labeled path is 14/18; MAC header and MAC
header with one label (4 bytes)
Both of these are for L3VPN payloads.
Instructor's Note
Observe that there are 2 paths to the 192.168.134.0 network from PE66: unlabeled using P22 and labeled using P11.
Traffic arriving with a label of 16072 can be forwarded out G0/4/0/0 unlabeled with 14 bytes of MAC address and
14 bytes of encapsulation. Or out G0/4/0/3 with a label of 16005 with 14 bytes of MAC address and 18 bytes of
encapsulation that include the MPLS label.
34
Version 4.0.1

Module 3
Components of LFIB
Next Hop Label Forwarding Entry (NHFLE)
Used when forwarding a labeled packet

Contains information about the packet:
!Packet s next hop

!Operation to perform on the packet
s label stack
" Replace the label on top with a new specified label

" Pop the label stack
" Replace the label on top with a new specified label, and push
one or more specified new labels onto the label stack
!May also contain
" data link encapsulation

" encoding methods for packet transmission
" other information needed to properly dispose of the packet
If next hop = current LSR (egress LSR or LER), then label

stack operation MUST be to pop the stack
Version 3.9.0a
XMPLSTModule 2/6
:router# show mpls ldp forwarding 192.168.134.0/24

Prefix
Label
In
---------------- ------192.168.134.0/24 16072
Label
Out
---------Unlabelled
16005
Outgoing
Interface
-----------Gi0/4/0/0
Gi0/4/0/3
Next Hop
--------------192.168.126.2
192.168.116.1
:router# show mpls forwarding detail

16072 Unlabelled 192.168.134.0/24 Gi0/4/0/0 192.168.126.2 250
Updated Sep 24 08:59:17.087
MAC/Encaps: 14/14, MTU: 1500
Label Stack (Top -> Bottom): { Unlabelled }
Packets Switched: 4
16005
192.168.134.0/24 Gi0/4/0/3 192.168.116.1 156
Updated Sep 24 08:59:17.087
Label Stack (Top -> Bottom): { 16005 }
Packets Switched: 3
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/7
35
MPLS LDP
Module 3
FEC-to-NHLFE (FTN)
The FEC-to-NHLFE (FTN) maps each FEC to a set of NHLFEs. It is used
when forwarding packets that arrive unlabeled, but that need to be labeled
before being forwarded.
If the FTN maps a particular label to a set of NHLFEs that contains more
than one element, exactly one element of the set must be chosen before the
packet is forwarded. Having the FTN map a label to a set containing more
than one NHLFE may be useful when, for example, you want to load
balance over equal-cost paths.
The show mpls forwarding command provides output showing inbound
and outbound labels and IP addresses. On the PE routers, observe the
ingress traffic from the CE router is labeled as it passes through an
LDP-enabled core. This is an example of FEC-to-NHLFE.
36
Version 4.0.1

Module 3
Components of LFIB
FEC-to-NHLFE (FTN)
Maps each FEC to a set of NHLFEs

Used when forwarding packets arrive as
unlabeled, but must be labeled before being

forwarded
FTN could map a label to a set of NHLFEs
!Might be useful for load balancing over equalcost paths
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/8
37
MPLS LDP
Module 3
Incoming Label Map (ILM)

The Incoming Label Map (ILM) maps each incoming label to a set of
NHLFEs. It is used when forwarding packets that arrive as labeled
packets.
If the ILM maps a particular label to a set of NHLFEs that contains more
than one element, exactly one element of the set must be chosen before the
packet is forwarded. The label at the top of the stack is used as an index
into the ILM. Having the ILM map a label to a set containing more than
one NHLFE may be useful if, for example, you want to load balance the
traffic across multiple links.
38
Version 4.0.1

Module 3
Components of LFIB
Incoming Label Map (ILM)
Maps each incoming label to a set of NHLFEs

Used when forwarding packets arrive as labeled
packets
Label at the top of the stack is used as an index

into the ILM
ILM could map a label to a set of NHLFEs
!Might be useful if you wish to load balance traffic

across multiple links
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/9
39
MPLS LDP
Module 3
MPLS LDP Fundamental Points

MPLS has control and forwarding plane components. The function of the
control plane component is to assign a locally-significant label to a
forwarding equivalence class (FEC), and advertise this label binding to its
neighbors. The goal of this label exchange is to set up a Label Switched
Path (LSP) for forwarding traffic.
The forwarding plane applies, swaps, and removes labels while forwarding
the packet along the LSP.
Label Protocols for MPLS

MPLS LSPs can be setup either statically (similar to IP static routing), or
using these signaling protocols:
Label Distribution Protocol (LDP)
Uses hop-by-hop path setup (not end-to-end). The details of this

protocol are described in this module
Sets up L2VPN pseudowires using targeted neighbors
Resource Reservation Protocol, Traffic Engineering extensions (RSVP-TE)
End-to-end LSP signaling based on traffic engineering constraints
Label Exchange Protocol with Respective FEC Type
The table lists the label exchange protocols that assign and advertise label
bindings for various FEC types. The label exchange protocols are LDP,
RSVP and MP-BGP.
Instructor's Note
Constraint Based Routing LDP (CR-LDP), an older and deprecated protocol, used LDP
extensions for traffic engineering
310
Version 4.0.1

Module 3
Labeling Protocols for MPLS
MPLS label distribution protocols can be configured either
Statically (like IP static routing) or

Using signaling protocols
Label Distribution Protocol (LDP)
Used for hop-by-hop path setup (not end-to-end)

L2VPN pseudowires using targeted neighbors
Resource Reservation Protocol - TE Extensions (RSVP-TE)
End-to-end LSP signaling with traffic engineering constraints
Label Exchange Protocol

LDP
FEC Class Type

Version 3.9.0a
IPv4 prefixes
XMPLSTModule 2/12
IPv6 prefixes
L2VPN pseudowires
RSVP
Traffic engineering tunnels
MP-BGP
IPv4 and IPv6 prefixes

VPNv4 and VPNv6 prefixes
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/13
311
MPLS LDP
Module 3
LDP Support for MPLS Deployments

Two key deployment scenarios, which are a major part of our focus, are
Layer 3 Virtual Private Networks (L3VPNs) and Layer 2 VPNs (L2VPNs).
MPLS Core Including L3VPNs
In L3VPNs, LDP is used to exchange label bindings to establish LSPs in

the core, so the L3VPN packets are transported across it. This requires
LDP sessions between PE and P routers, as well as between P routers. In
addition to LDP, BGP is used to exchange VPNv4 label bindings between
PE devices. From a data forwarding perspective, VPN packets have a core
LSP label (corresponding to the IGP route for the remote PE) on the top,
and below that, a VPNv4 label (IP address plus route distinguisher used by
MP-BGP to distinguish between L3VPNs). The core LSP (top) label carries
the packet between the PE devices, and the VPNv4 (bottom or internal)
label is used to deliver the packet to the right VPN on the destination PE
device.
L2VPNs (Layer 2 MPLS Services)
L2VPNs use a slightly different mechanism to exchange virtual circuit

(VC) labels (this is the counterpart of VPNv4 labels used in L3VPNs). The
mechanism is known as a LDP targeted session that is setup between the
PE devices to signal VC labels. From a data forwarding perspective,
L2VPN packets have a core LSP label (corresponding to the IGP route for
the remote PE) on the top, and below that, a VC label. The core LSP label
carries the packet between the PE devices, and the VC label is used to
deliver the packet to the right interface.
MPLS Inter-AS Services
In this environment, ASBRs use BGP to exchange label bindings to

support interconnectivity.
312
Version 4.0.1

Module 3
LDP Support for MPLS Deployments
Network Deployment
Scenario
Use of LDP
LDP Deployment Details
MPLS-enabled Core
(incl. L3VPNs)
Exchange of label
bindings for IGP prefixes
between P and PE routers
LDP sessions between

directly connected PE and
P routers
MPLS Layer-2 VPN services
Exchange of control, VC,

and label info between PE
routers
Targeted LDP sessions

between PE routers
(ingress and egress)
MPLS Inter-AS Option C
Exchange of label
bindings for IGP prefixes
supporting ASBR interconnectivity
Label binding exchanged

between ASBRs use BGP,
within the AS they use
LDP
Version 3.9.0a
XMPLSTModule 2/14
Instructor's Note
Remember that with L2VPNs, a pseudowire is comprised of 2 VCs.
Version 4.0.1
313
MPLS LDP
Module 3
LDP Protocol Overview

LDP is an MPLS control plane protocol that is used to setup Label
Switched Paths (LSPs) alongside IP forwarding paths. LDP assigns,
distributes, and installs labels for prefixes advertised by unicast routing
protocols, such as OSPF, IS-IS, and static routes. LDP was originally
specified in RFC 3036, LDP Specification, which is superseded by
RFC 5036, LDP Specification, in which, LDP is extended as a signaling
protocol for use with L2VPN pseudowires.
Typical LDP Deployment Scenarios
314
MPLS enabled coreProvides label switching services for L2 and

L3VPN provider services.
BGP free core with MPLSBGP was needed on all network routers to
prevent black-holes in transit networks, by ensuring that all
destinations are known by all routers in the transit network. This need
was circumvented by the introduction of MPLS. MPLS core routers no
longer need destination prefixes because they do not perform normal IP
lookups; they perform label switching. Therefore, core routers in the
service provider network no longer need to run BGP; only the edge
routers need to do that
MPLS L2VPN signaling servicesL2VPNs use a targeted LDP session

that is setup between the PE devices. The PE uses the VC signaling to
negotiate parameters such as PW type, PW ID, and interface. The core
LSP label carries the packet between the PE devices and the VC label
is used to deliver the packet to the right interface or subinterface
MPLS L3VPN Inter-AS Option CIn this environment, LDP is used to

exchange labels within an AS. BGP is used to exchange label bindings
between autonomous system boundary routers (ASBRs) for customer
IGP prefixes, using a labeled unicast address family. BGP Route
Reflectors (RRs) in each AS exchange VPNv4 routes
Version 4.0.1

Module 3
LDP Protocol Overview and Deployment Scenarios
LDP is MPLS control plane protocol used to setup Label

Switched Paths (LSPs) along IP forwarding paths
LDP assigns, distributes, and installs (forwarding) labels for
prefixes advertised by unicast routing protocols, such as OSPF,

IS-IS, Static routes, and so on
Extended as a signalling protocol for L2VPN pseudowire (PW)

Specified in RFC 3036 originally
Newer version 2 is RFC 5036
Typical LDP deployment scenarios
MPLS-enabled core (typically for L2VPN and L3VPN transport)

BGP-free core with MPLS
MPLS L2VPN signalling services
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/16
315
MPLS LDP
Module 3
LDP Protocol Operations

LDP operations can be divided into segments:
LDP neighbor discovery
LDP peer session establishment
Binding exchange
Forwarding setup
LDP protocol messages
Basic neighbor discovery is used between directly connected LSRs. LDP

link hello packets are sent to UDP port number 646. The LDP discovery
message carries a LDP identifier, which is typically built using the LDP
router-ID. When an LSR receives an LDP hello packet on an interface, it
first creates a Hello adjacency on this interface, and then attempts to
establish an LDP session using the LDP identifier of the peer. The LDP
sessions use TCP port 646 for the exchange of messages.
Each of the segments listed above are discussed.
316
Version 4.0.1

Module 3
LDP Protocol Operations
LDP protocol operations can be divided into segments:

LDP neighbor discovery
LDP peer session establishment
Binding exchange
Forwarding setup
LDP protocol messages
Operations overview
Uses UDP port 646 for neighbor discovery (hellos)

Uses TCP port 646 for exchange of LDP messages
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/17
317
MPLS LDP
Module 3
Neighbor Discovery
LDP hellos, which use UDP port 646, are automatically sent on all links
(with LDP enabled) to discover neighbors and identify their originator.
LDP Identifier
LDP Hello packets carry an identifier known as the LDP Identifier used to
uniquely identify each peer. The LDP Identifier consists of a LSR-ID
(typically a router-ID address) and Label Space ID. There are two types of
LDP Identifiers:
Platform-wide where zero (0) is used as the Label Space ID

!
The zero Label Space ID represents a pool of labels that are shared
across all the devices interfaces
It is typically used with LAN and synchronous interfaces
Per-interface label spaces use a non-zero Label Space ID

!
The non-zero Label Space ID represents labels that are linked to an

interface, and therefore, may be reused by multiple interfaces
It is typically used for ATM interfaces that use VPI/VCI for labels
Discovery Hellos
When an LSR receives an LDP hello packet, it first creates a Hello

adjacency with its neighbor; then, it attempts to establish an LDP session
using the LDP identifier of the peer.
There are two types of discovery hellos:
Basic hellos are sent on directly connected links to a link local

multicast group
Extended or targeted hellos are sent towards a unicast IP destination

address and may traverse multiple hops
Basic Discovery
LDP link hello packets are sent to directly-connected links (link-local

mcast) with a destination IP address of 224.0.0.2, which is a reserved
address for all routers on the subnet with UDP port number 646. When an
LSR receives an LDP hello packet on an interface, it creates a Hello
adjacency on this interface.
Extended Discovery
LDP extended discovery is used between non-directly connected LSRs.

When using extended discovery, an LSR sends targeted LDP hellos to a
specific IP unicast address (using UDP port 646). LDP extended discovery
is used by L2VPNs and other applications.
318
Version 4.0.1

Module 3
Neighbor Discovery
LDP hellos sent to discover neighbors use:
UDP port 646

LDP identifier
LDP identifier <LSR-id : label-space-id>
LSR-IDGlobally unique value, typically a router-ID address (4 octets)

Label-space-IDZero for platform-wide label space, non-zero for
interface specific label spaces (2 octets)
Platform-wide: One pool of labels is shared across all interfaces

Per-interface: Label values can be reused on each interface
LDP identifier examples:
172.12.0.55:0 (platform-wide)
172.12.0.55:5 (per-interface)
Version 3.9.0a
XMPLSTModule 2/19
Two types of hellos:
Basic/Link:
Hellos sent to directly-connected link (link-local mcast destination

224.0.0.2)
Extended also called targeted:
Hellos sent to an IP unicast target address to connected or indirectly

connected neighbors.
Successful neighbor discovery results in an hello adjacency

Hello adjacencies are maintained using periodic Hellos
Instructor's Note
Platform-wide label spaces are used with LAN and synchronous type interfaces, while interface
specific label spaces are used with ATM interfaces. This is known as label-controlled ATM, and is
an MPLS interface in which labels are carried in the VPI or VCI fields of the ATM cells, and in
which VC connections are established under the control of MPLS software.
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/20
319
MPLS LDP
Module 3
LSR Neighbor Discovery
In the given example:

1. R1 has three network connections: P-to-P, ATM, and Ethernet
2. Hellos sent on the P-to-P and Ethernet links contain the router-ID
followed by zero, specifying that the labels share a common database.
The hello on the ATM link has the router-ID followed by one indicating
the labels are specific to this interface
3. R1 is receiving neighbor responses. On the Ethernet, R3 and R4
respond both with global label spaces on the interface. R2 responds
with an interface specific label space on the ATM interface
4. R1 builds a picture of the attached routers with IDs and label spaces
from the discovery hellos
320
Version 4.0.1

Module 3
Neighbor Discovery (Cont.)
LSRs discover neighbors by sending and receiving hellos
Point-to-point
Ethernet
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/21
321
MPLS LDP
Module 3
Peer Session Establishment

Successful neighbor discovery triggers session establishment. Sessions are
established using TCP port 646, with an active and passive side, which are
automatically established by the LDP protocol. The active side initiates the
TCP session. LDP adjacencies are maintained using periodic Hello packets,
while sessions are maintained using periodic session keep-alive packets.
A LDP session is a TCP connection between two routers. These two routers
can have multiple physical connections; that is, more than one physical
(Hello) adjacency. Regardless of the number of physical connections that
may exist between the two routers, only one LDP session per label space is
established. Session establishment terminology includes:
Neighbor a router that has been discovered using LDP Hellos
Session a TCP connection established to a discovered neighbor. This

doesnt necessarily imply that there has been a successful label
exchange
Peer relationship a connection established when session parameters

for label exchange are successfully negotiated. Once peering is
successfully completed label exchange occurs between LSRs
Session establishment
In the figure, R1 receives a Hello message from R2. If an LDP session for
the label space is not currently established, R1 attempts to open a TCP
connection to R2. When opening a TCP connection, an LSR will have one of
two roles: active or passive as described in the table. The LSR compares
the LDP identifiers (IP addresses) of both ends of the TCP connection.
R1s LDP identifier (IP address), is greater
in value than R2s
R1 plays an active role
R1 attempts to open a
connection to R2
R1s LDP identifier (IP address), is NOT

greater in value than R2s
R1 plays a passive role
R1 waits for a connection

attempt from R2
A TCP connection is opened; LSRs exchange LDP messages to negotiate:
Type of label distribution method:

!
Downstream unsolicited
Downstream on-demand
Hold time for the LDP session
When negotiation succeeds, the LDP connection is up, and the LSRs begin
to use the connection for label distribution.
322
Version 4.0.1

Module 3
Peer Session Establishment
Successful neighbor discovery triggers session establishment

A session is associated with 1 or more hello adjacencies
Sessions are established using TCP port 646
Session connections have an active and passive side
Active side is typically highest LDP router-ID used in the discovery
process
Sessions are maintained using LDP keep-alives and protocol

messages
Terminology
Neighbor router that has been discovered using LDP hellos
Session LDP sessions are TCP connections established to
discovered neighbors
Peer router that has successfully negotiated session parameters
for label exchange
Version 3.9.0a
XMPLSTModule 2/23
R1 receives Hello R2:0 on link

R1 attempts to open LDP TCP connection to R2
R1 and R2 negotiate session parameters using an exchange of
initialization messages
! For example, advertisement mode and label range
Instructor's Note
Discovery hellos for a link are maintained using UDP port 646 packets every 5 seconds, while
sessions are maintained using TCP port 646 keep-alive packets every 60 seconds.
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/24
323
MPLS LDP
Module 3
TCP Sessions and Discovery Adjacencies

An LDP session consists of a transport adjacency that is a TCP connection
established between two LSRs. There can also be one or more discovery
(link or targeted) adjacencies between the LSRs.
The figure illustrates two cases of link adjacencies:
Single adjacency
Multiple adjacencies
Note that in both cases there is only one TCP connection between the pair
of LSRs. In other words, where multiple links between an LSR pair involve
the exchange of the same label spaces over all of the links, the relationship
would be many links to one TCP connection.
The example on the adjacent page uses platform-wide label spaces.
324
Version 4.0.1

Module 3
TCP Sessions and Discovery Adjacencies
LDP session = 1 TCP connection

+ 1 or more discovery adjacencies for
the same label space
LDP session between R1 and R2

1 TCP connection
1 discovery adjacency
LDP session between R1 and R2

1 TCP connection
3 discovery adjacencies
Platform-wide example
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/25
325
MPLS LDP
Module 3
Maintaining LDP Sessions

Discovery Adjacency
Periodic transmission of LDP Hello messages indicates the peers

capability of label switching over the link (or towards the target)
Expiration of LDP Hello timer without receipt of an LDP Hello message

from the other peer LSR causes the LSR to terminate the discovery
adjacency
When the last discovery adjacency for an LDP session is terminated,

the LSR terminates the LDP session
Transport Adjacencies
326
Periodic transmission of LDP Keep-alive messages is used to monitor

the integrity of a TCP transport connection
Expiration of transport connection timer without receipt of an LDP

keep-alive message from the peer LSR causes the LSR to terminate the
transport adjacency. As a result, the LDP session is also terminated. In
other words, the transport adjacency (TCP connection) is a prerequisite
for the LDP session
Version 4.0.1

Module 3
Maintaining LDP Sessions
LSRs maintain their sessions by:

Discovery Adjacency
Continued periodic transmission of discovery hello
packets to indicate willingness to label switch over
the link
Sent toward the target in 5 second intervals
Transport Adjacency
Periodic transmission of LDP keep-alive messages
on TCP connection to monitor integrity of TCP
connection
Sent in 60 second intervals

Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/26
327
MPLS LDP
Module 3
Binding Exchange
When the session peering is established, the LDP protocol enters the
binding exchange phase. LDP peers freely exchange two types of bindings:
IP address information about locally configured (interface) addresses
FEC to label mapping that includes:

!
Association between IPv4 or IPv6 prefix FEC and label
Association between VC (L2) FEC and labels
The label information base (LIB) is a database in LDP that maintains, for
each FEC or prefix:
328
Local label binding
Remote bindings learned from peers
Version 4.0.1

Module 3
Binding Exchange
Established LDP peers freely exchange 2 types of

bindings:
Address - IP address information about local interface

addresses
Label - FEC to label mapping

! Association between IPv4 and IPv6 prefix FEC and label
! Association between VC (L2) FEC and label
For each prefix, Label Information Base (LIB)

maintains:
Local label binding

Remote label bindings learned from peers
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/27
329
MPLS LDP
Module 3
Label Values
Label values 0 through 15 are reserved for MPLS-specific control functions,
and not for general forwarding use. Based on the RFCs, the LSR assigns a
specific function to each label. The reserved labels and their functions are:
0: IPv4 explicit null is a label assigned to a FEC by the egress LSR

(LER) and sent to the penultimate hop router. As a result, the
penultimate router zeros the top label of a stack, for packets destined
for the FEC, on the LER that sent the explicit null and leaves the EXP
field intact. The LER can perform QoS actions using information in the
EXP field of the top label, prior to removing it. With the label removed,
the LER performs another lookup to obtain forwarding information.
That lookup can be MPLS label- or IP-packet based
1: Router alert, local processing operation. This label value is legal

anywhere in the label stack, except at the bottom. When a received
packet contains this label value at the top of the label stack, it is
delivered to a local software module for processing. The actual
forwarding of the packet is determined by the local label beneath it in
the stack
2: IPv6 explicit null
3: Implicit null is a label assigned to a FEC by the egress LSR, and sent
to the penultimate hop router. This triggers the penultimate hop router
to pop the top label of a stack for packets destined for the FEC with the
implicit null
4 to 15: reserved
General use: label range 16 to 1,048,575
A specific label value range can be assigned to each router. The key benefit
is clarity when examining MPLS forwarding statistics.
330
Version 4.0.1

Module 3
Label Values
Special use and reserved range
! 0 ! IPv4 explicit null, top label value zeroed

! 1 ! Router alert, local processing operation
! 2 ! IPv6 explicit null, top label value zeroed
! 3 ! Implicit null, triggers label stack pop, overrides label swap
! 4 to 15 ! reserved
General use range
! 16 to 1,048,575
Specific label value range may be assigned to each router
! Benefit is clarity when examining MPLS forwarding statistics
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/28
331
MPLS LDP
Module 3
Forwarding Setup
LDP uses routing information to assign labels and forward traffic, it does
not perform any routing. It uses the routing next-hop information and
determines the remote label from the corresponding LDP peer, setup LSPs
that would forward traffic.
LSP Forwarding Setup
R3 is an egress PE router. It sends its local label L3 with associated

FEC 10.0.0.0/8 to R2
R2 assigns a local label L2 to FEC 10.0.0.0/8. From the routing and

binding exchange with R3, R2 learns to use remote label L3 through R3
to get to network 10.0.0.0/8. An alternate path (using R4), though
available, is not chosen because its cost is higher than the path using
R3
R1 assigns a local label L1 to FEC 10.0.0.0/8. From the routing and

binding exchange with R2, it learns to use remote label L2 through R2
to get to network 10.0.0.0/8
LSP Path
332
An IP packet destined for network 10.0.0.0 enters R1
A FIB lookup sends it out with label L2 on an interface bound for R2
The labeled packet arrives at R2. An index lookup of L2 shows that a

label swap to L3 needs to take place, and the packet is forwarded on a
interface bound for R3
The packet arrives at R3. An index lookup of L3 shows that the label is
to be removed, and the IP packet is to be forwarded out the
corresponding interface
Version 4.0.1

Module 3
Forwarding Setup
FEC
10.0.0.0/8
FEC
Local
Label
Out
Label
Nexthop
L1
L2
R2
Local
Label
10.0.0.0/8
L1
IP
LFIB
LFIB
LFIB
L2
Out
Label
Nexthop
L1
R1
L3
R3
L4
R4
R1
R2
IP L3
Local
Label
Out
Label
Nexthop
L2
R2
L3
UL*
Rx
10.0.0.0/8
L3
L2
L2
IP L2
FEC
10.0.0.0
cost =5
R3
IP
L2
L4
cos
t =1
R4 LFIB
FEC
*UL: Unlabeled
10.0.0.0/8
Version 3.9.0a
Local
Label
Out
Label
Nexthop
L2
R2
L4
UL*
Ry
XMPLSTModule 2/29
Instructors Note
In this example, the point is to explain how labels are assigned to a FEC. Also, walk through how
an IP packet with MPLS label gets from R1 through to R3. Remember you are looking at label
switching and not a L3VPN.
Version 4.0.1
333
MPLS LDP
Module 3
LDP Protocol Message Summary

There are four main categories of LDP messages:
1. Discovery messages
Announce and maintain the presence of an LSR in a network
HELLOSent periodically on all adjacencies to announce and

maintain their presence in the network
2. Session messages
Establish, maintain, and terminate sessions between LDP peers
INITIALIZATION, KEEP-ALIVEThese messages establish and,

using periodic keep-alive messages, maintain the TCP connection
between LDP peers
3. Advertisement messages
Add, remove, change, and request LDP bindings (labels and addresses)
ADDRESS, ADDRESS-WITHDRAW, LABEL-MAPPING, LABELWITHDRAW, LABEL-RELEASE, LABEL-REQUEST, LABEL-ABORTREQUEST
4. Notification messages
Provide advisory and signal error information (these use a status code)
NOTIFICATIONProvide status and error information. LDP uses

notification messages to report errors and events of interest. If an
error notification is received (such as a bad PDU), the router
terminates the LDP session, and discards all label mappings learned.
Informational notifications provide information about the current
session, or the status of some previous message received from the peer
Relationship LDP Message Types to Routers
The second diagram provides a pictorial representation of the relationship

that exists between the LDP message types and routers in a network.
334
Version 4.0.1

Module 3
LDP Protocol Message Summary
Four categories of LDP messages:

Discovery messages:
Announce and maintain the presence of an LSR in a network

HELLO (5 sec interval)
Session messages:
Establish, maintain, and terminate sessions between LDP peers

INITIALIZATION, KEEPALIVE (60 sec interval)
Advertisement messages:
Add, remove, change, and request LDP bindings (label and addresses)
ADDRESS, ADDRESS-WITHDRAW, LABEL-MAPPING, LABEL-WITHDRAW,
LABEL-RELEASE, LABEL-REQUEST, LABEL-ABORT-REQUEST
Notification messages:
Provide advisory and signal error information (these use a status code)
NOTIFICATION
HELLO
Version 3.9.0a
XMPLSTModule 2/31
INITIALIZATION
ADDRESS (MAPPING, WITHDRAW)
LABEL (MAPPING, WITHDRAW, RELEASE, REQUEST, ABORT-REQUEST)
NOTIFICATION
KEEPALIVE
R1
Hello
R5
R3
R4
R6
Targeted session
Targeted hello
R2
Note: The LDP session between R3 and R4 is

not required
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/32
335
MPLS LDP
Module 3
LDP Protocol Message Details

The LDP protocol uses a set of messages to communicate label and other
state information between peer LSRs.
Communications features of the general LDP packet format include:
TCP as the transport for most messages where information is conveyed.

UDP is used for messages requiring multicast delivery, such as the
Hello message and which are out-of-band of an LDP session
TCP and UDP use well-known port number 646. Messages use wellknown port number 646 for the source port, as well as the destination
port
The LDP data portion of the packet is encoded as one or more TypeLength-Value (TLV) fields. TLV fields consist of a fixed-size (2-octet)
parameter type identifier, a fixed-size (2-octet) length field, and a
variable-length data value
One or more messages can be sent towards a peer within a LDP PDU
The LDP header consists of these fields:
Version number (2 octets)Currently set to 1
Protocol Data Unit (PDU) length (2 octets)Excludes the version

number and PDU length fields
LDP identifier (6 octets)Consists of the router ID (one of the LSRs IP

addresses) and a label space ID
The LDP message portion consists of these fields:
336
Message Type (2 octets)Identifies the specific LDP message, such as a

hello. Refer to the following page for more details
Message Length (2 octets)Excludes the message type message length

fields
Message ID (4 octets)Sequence number for correlating related

messages
Parameters (variable)Depending on the message type, various

mandatory and optional parameter values are included
Version 4.0.1

Module 3
LDP Protocol Message Details
20
General
format
IP
18
10
TCP
LDP header
octets
LDP message
Well-known port 646

Some message types use UDP for multicast
2
LDP
header
Version PDU length
LDP
message
Currently
1
Excludes length
and version
Type
Address
Address withdraw
Hello
Initialization
KeepAlive
Label mapping
octets
LDP identifier
Router ID (IP address)
and Label Space ID
6
Length
Excludes type
and length
ID
octets
Parameters
Sequence
number
Mandatory
and optional
Label request
Label abort request
Label withdraw
Label release
Notification
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/33
337
MPLS LDP
Module 3
The LDP protocol involves the use of eleven (11) messages. These
messages can be categorized as:
Node discovery and identificationHello, address, and address

withdraw messages
LDP session and TCP connection managementInitialization and
keep-alive messages
Label distributionLabel mapping, label request, label abort request,
label withdraw, and label release messages
Error conditionNotification message
The eleven LDP messages are:
338
NotificationNotify a peer about an error condition, such as a

malformed message, expiration of a keep-alive timer without a keepalive message being received, shutdown of a node, failure of session
initialization
HelloEnables peers to discover each other. Sent at the expiration of a
negotiated hold (LDP session keep-alive) timer. Sent using UDP
multicast
InitializationRequests the establishment of an LDP session.
Parameters negotiated include the hold timer, type of advertisement
mode
Keep-AliveMonitor the integrity of the TCP connection for the session
AddressAdvertises an LSRs interface address. Interface addresses
are stored for purposes of mapping peer LDP identifiers and next hop
addresses
Address withdrawRemoves the address
Label mappingAdvertises FEC-label bindings
Label requestRequests a label binding for a given FEC. Sent when an
LSR recognizes a route change involving the next hop LDP peer, for
which a label binding is needed
Label abort request Aborts an outstanding label request message.
Can occur, for example, when route state information is learned that
invalidates the request for label information that is currently
outstanding
Label withdrawRemoves a label mapping advertisement, in part or
whole. Requests that an FEC-label binding be deleted by the receiver
that was previously advertised by the sender
Label releaseInforms the receiver that it is no longer using the
indicated label. This may be sent unsolicited or may also be sent in
response to a label withdraw message
Version 4.0.1

Module 3
LDP Protocol Message Details (Cont.)
Description
Message Type
Notification
Reports an error condition
Hello
LDP keep-alive, sent periodically based on hold timer
Initialization
Sets up an LDP session and negotiate parameters
KeepAlive
Monitors integrity of TCP connection supporting a session
Address
Advertises a list of interface addresses
Address withdraw
Removes the address
Label mapping
Advertises FEC or label bindings to neighbors
Label request
Requests a label binding for a given FEC
Label abort request
Aborts an outstanding label request message
Label withdraw
Deletes FEC or label binding when its no longer supported
Label release
Deletes FEC or label binding due to route change
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/34
339
MPLS LDP
Module 3
Cisco IOS XR LDP Implementation

This section covers the implementation of LDP in the Cisco IOS XR
operating system.
Cisco IOS XR LDP Operating Modes

Label distribution is the process of exchanging locally-assigned and other
learned labels with peer LSRs. An LSR can distribute bindings in an
unsolicited manner called downstream unsolicited (DU), or in a manner
called downstream on-demand. Downstream refers to the direction of
traffic flow towards a destination.
There are two methods of LDP label advertisement:
Downstream Unsolicited (downstream controlled) is simpler and used
in the Cisco IOS XR environment
Downstream on Demand (upstream controlled) is more complex and is
used for ATM
The behavior of the downstream unsolicited and downstream on-demand
label distribution methods are qualified by a control mode.
There are two control modes that an LSR may be configured:
Independent control mode transmits labels to a neighbor as soon as

they are assigned locally. This is used in downstream unsolicited mode,
and is the default mode in the Cisco IOS XR operating system
environment
Ordered mode, in which the label setup is strictly sequenced. The
ordered mode is used for ATM interfaces with downstream on-demand
label distribution
To understand label assignments, think in terms of label spaces. There are
two kinds of label spaces that a vendor may implement:
Platform-wideUsed for interfaces that can share a pool of labels such
as LAN and synchronous interfaces used in Cisco IOS XR operating
system software
Per interfaceUsed for interfaces that use interface resources such as
ATM (ATM uses the VPI/VCI for labels)
Modes and Features Not Supported:
The following are unsupported modes and features of Cisco IOS XR

operating system software:
340
CR-LDP
LC-ATM
Loop Detection
Version 4.0.1

Module 3
Cisco IOS XR LDP Operating Modes
Label distribution mode - Downstream Unsolicited (DU)

LSR is responsible for advertising a label mapping when it wants
an upstream LSR to use the label
Control mode - Independent
Transmits labels as soon as they are assigned locally, and label

advertisement mode is set to DU
Label retention - Liberal
Labels from a peer LSR are retained regardless of whether the

LSR is the next hop for the advertised mapping
Label space - Per platform
Platform-wide incoming labels are used for interfaces that can

share the same labels
Modes and features not supported:

CR-LDP, LC-ATM, loop detection
Version 3.9.0a
XMPLSTModule 2/36
Instructors Note
CR-LDPConstraint-based LDP contains extensions for LDP to extend its capabilities; allows
path setup beyond what is available for the routing protocol in traffic engineering. (deprecated; no
longer used)
LC-ATMLabel-controlled ATM is an MPLS interface in which labels are carried in the VPI or
VCI fields of the ATM cells; VC connections are established under the control of MPLS
Loop DetectionLDP relies on IGP loop prevention in the MPLS domain, not the TTL field in
the MPLS label.
Cisco IOS XR supports frame-mode MPLS (not LC-ATM*); routers running MPLS exchange
pure IP packets (PHP) and labeled IP packets with each other in an MPLS domain. Data link
layer connectivity in frame-mode MPLS can use HDLC/PPP, Ethernet, or ATM. In ATM Layer
2 cells are used to transport IP packets that also contain MPLS headers. With ATM links in MPLS
it is possible to have IP point-to-point links (routed PVCs). This is considered frame-mode MPLS
while the Layer 2 protocol is ATM.
Version 4.0.1
341
MPLS LDP
Module 3
Label Distribution Modes

When there is a change to routing, the LSR installs a new label into its
LFIB and advertises it. As mentioned earlier, there are two methods of
LDP Label Advertisement:
Downstream Unsolicited is the simpler model

!
In the example, the downstream router Rd sends one or more labels

to the upstream neighbor periodically. This enables Ru to learn the
label to use when sending traffic with a particular FEC through Rd.
This method is used for packet-based interfaces such as Point-toPoint Protocol (PPP), Packet over SONET (POS), and Ethernet
Downstream on Demand (upstream controlled), is more complex and is

typically used for ATM networks. We do not cover this in this course
!
An LSR explicitly requests label-binding information from a peer

LSR. This mode is used with ATM links to conserve label virtual
circuits (label VCs, or LVCs)
Downstream Unsolicited
In the example topology in the lower figure, the LSRs are configured to use
the downstream unsolicited method of label advertisement.
LSRs B and C advertise their label information for destination P/n to
LSR A as soon as they are ready to do so. This is a result of the IGP route
distribution protocol detecting a route to the destination.
The notation P/n is shorthand for the IP address prefix representing a
network, subnet, supernet, or possibly even a host-specific destination. An
IP address prefix consists of an IP address and bit mask.
In this example, the LSD on LSR A would be populated with a label from
both peer LSRs.
342
Version 4.0.1

Module 3
Downstream Unsolicited
Upstream
LSR
Downstream
LSR
Ru
Rd
Label LX for
destination DY
Downstream Unsolicited:
B and C advertise P/n when ready to
label switch packets for P/n
Label Mapping (P/n, Lb)
Version 3.9.0a
XMPLSTModule 2/38
Label Mapping (P/n, Lc)

LIB at
Node A
Prefix Peer
P/n
B
C
Label
Lb
Lc
Version 3.9.0a
Instructor's Note:
XMPLSTModule 2/39
Downstream On-Demand
Upstream
LSR
Downstream
LSR
Ru
Request
Rd
Label LX for
destination DY
Downstream on Demand (upstream controlled), is more complex and is typically used for ATM
networks. In the example, the downstream router Rd sends label-binding information only in
response to a request from its upstream neighbor Ru.
Version 4.0.1
343
MPLS LDP
Module 3
Label Distribution Control

The behavior of the downstream unsolicited and downstream on-demand
label distribution methods is further qualified by what is called the control
mode. There are two control modes, for which an LSR may be configured:
independent mode or ordered mode.
In the figure, the action of R2 during label distribution depends on the
configuration of the label distribution control.
In independent mode (the default in the Cisco IOS XR operating system)
IGP convergence results in R2 taking immediate action as soon as the
prefix appears in the routing table. R2 LDP allocates a local label for those
prefixes received from R4. R2 may not yet have any labels from R4, but it
advertises the existence of R4 prefixes to R1. R1 may begin forwarding
traffic to R4, but since R2 has no label yet assigned from R4, it discards the
traffic. Ordered mode is typically used for downstream on-demand label
distribution with ATM interfaces.
In ordered mode, label setup is strictly sequenced.
344
Version 4.0.1

Module 3
Label Distribution Control
k1
Lin
R1
1
Lin
k3
R3
R4
Lin
k2
k4
Lin
R2
Independent label distribution (R1-R4, fastest mode)
May drop packets in the core until setup is complete

Assigns labels for prefix with no downstream label
Used with Layer 3 only
Version 3.9.0a
XMPLSTModule 2/40
Instructor's Note
R2 responds to request for R4 even if R4 has not yet responded to R2.
In ordered mode, the label setup is strictly sequenced. R2 now requests and receives a label from
R4 prior to returning a label response message to R1. Ordered mode is typically used for
downstream on-demand label distribution with ATM interfaces
Ordered Label Distribution (R1-R4)
k1
Lin
Only assign label after one is
R1
received from next hop LSR
May request a label from next hop
Lin
k
LSR then assign it
R3
Lin
k
3
R4
R2
k4
Lin
2
Version 4.0.1
345
MPLS LDP
Module 3
Label Retention Mode Summary

Liberal Label Retention
Liberal label retention on an LSR maintains the bindings between labels

and FECs that are received from LSRs, that are not the next hop for that
FEC. Liberal label retention mode allows for quick adaptation to routing
changes. Therefore:
Each LSR stores all received labels in its LIB; including labels not
received from a next-hop LSR
This mode of operation improves convergence speed
Conservative Label Retention
Conservative label retention on an LSR discards bindings from peers that

are not the next hop for an FEC. Conservative label retention results in
LSRs maintaining fewer labels. Therefore:
346
LSR stores only the labels received from next-hop LSRs
All other labels are ignored
Downstream on demand is typically required for the convergence phase
Version 4.0.1

Module 3
Label Retention Mode Summary
Liberal label retention mode
!Each LSR stores all received labels in its LIB

" Even labels not received from next-hop LSR
!This mode of operation improves convergence

speed
Conservative label retention mode
!LSR stores received from next-hop LSRs only

!All other labels ignored
!Downstream on demand is typically required
Version 3.9.0a
XMPLSTModule 2/41
Instructor's Note
Briefly review the difference between the LIB and LFIB.
Version 4.0.1
347
MPLS LDP
Module 3
Topology, Sessions, and Label Spaces

Here are some additional details about MPLS network topologies, and the
relationship to LDP sessions and label spaces.
In the figure, each LSR is connected by a packet-based link such as PPP,
POS, or Ethernet. This results in:
348
One link to each router
One session to each router
Platform-wide label spaces for each router
Version 4.0.1

Module 3
Topology, Sessions, and Label Spaces
LDP Sessions
Topology
k1
Lin
R3
Session
over Link1
Lin
k3
R1
R4
Lin
k2
R2
R3
R1
k4
Lin
Session
over Link2
Session
over Link3
R4
R2
Session
over Link4
Label Spaces
Version 3.9.0a
Version 4.0.1
XMPLSTModule 2/42
349
MPLS LDP
Module 3
Label Spaces with Multiple Links

In the adjacent figure, two LSRs are connected by multiple links, three in
this specific example. Note that all links are packet-based:
Link1 is POS
Link2 is PPP
Link3 is Ethernet
Observe that only one LDP session is established with a neighboring LSR,
because all interfaces are packet-based, and they will use the same
platform-wide label space.
_____________________________ Note _________________________
The label space format used is the type <LSR_id : label_space_id>
where label_space_id is 0 for platform wide label spaces, and a number
greater than zero for interface-specific label spaces.
__________________________________________________________________
350
Version 4.0.1

Module 3
Label Spaces with Multiple Links
Topology
Multiple links
Sessions
Link1
R1
R1
R2
Link2
R2
One session for

Link1, Link2, and Link3
Link3
Label spaces
R1:0
Platform-wide
R2:0
Platform-wide
Instructor's Note
In the Mixed Topology figure below, the following relationships occur: Link 1 and 3 share a
platform-wide database; there is a unique session for each ATM link on each LSR; label space is
one per interface on each LSR for ATM interfaces.
Version 3.9.0a
XMPLST4Module 2/43
Mixed Topology
Topology
Link1
R1
ATM Link2
LDP sessions
Session over Link2
R2
R1
R2
Session over
Link1 and Link3
Link3
Label spaces
Interface-specific
(Link 2)
R1:1
R2:1
Interface-specific
(Link 2)
Platform-wide
R1:0
R2:0
Platform-wide

Version 4.0.1
Version 3.9.0a
351
XMPLST4Module 2/44
MPLS LDP
Module 3
Cisco IOS XR MPLS Forwarding Infrastructure (MFI)

This section is a discussion of the infrastructure of MPLS within the Cisco
IOS XR operating system.
MPLS Forwarding Infrastructure

The MFI provides a core set of services for LSRs. They are label
management services that are handled by the control plane, and
forwarding services that are handled by the data plane.
The control plane creates the label switch (LSD) database from its
interaction with the label distribution protocols, to setup forwarding paths
and label bindings for MPLS enabled interfaces. It also sets up the rewrite
information that will be used by the data plane.
The data plane provides the MPLS label operations such as push, pop, and
swap in addition to encapsulation and de-encapsulation operations for
packet forwarding.
352
Version 4.0.1

Module 3
MPLS Forwarding Infrastructure (MFI)
Core set of services, on LSRs
!Label management
!Forwarding
Control plane
!Enable and disable MPLS on interfaces

!Label table allocation and management
" Create a label switch path (LSP)
!Rewrite setup
!Interaction with the label distribution protocols
" Set up label binding
" Forwarding path creation
Data plane
!Label imposition (push), disposition (pop), swapping
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/46
353
MPLS LDP
Module 3
Cisco IOS XR LDP Architecture

The Label Switch Database (LSD) on the RP and DRP is a central
repository of label switching information. LDP, RSVP for TE, and MP-BGP
are MPLS forwarding applications, and act as LSD clients. These clients or
applications bind labels to a FEC, and download the label forwarding data
to the LSD.
LDP is used primarily for creating and exchanging label bindings for IGP
prefixes. Its application has since been expanded to include the label
binding exchange for L2VPN and multicast (S,G). RSVP is used to create
bindings for MPLS Traffic Engineering tunnels, and downloads the labelforwarding data of these tunnels to the LSD.
The command show mpls lsd application displays a list of the applications
that are registered with LSD, and used to set up label switch paths.
_____________________________ Note _________________________
The label-binding exchange for L2VPN pseudowires is handled by LDP.
__________________________________________________________________
The LSD maintains the label database; it receives label-forwarding
updates from clients, and downloads the LSD rewrite table to the FIB
process on the line cards. (See the illustration on the adjacent page.) LSD
rewrite information is downloaded from the RP (or DRP) to the line card
CPUs using BCDL (bulk content downloader which uses group services
protocol (GSP not shown) to distribute the data using multicast like
transmission).
354
Version 4.0.1

Module 3
Cisco IOS XR LDP Architecture
RP or DRP
OSPF
LC-CPU
RIP
ISIS
AIB
RIB
BCDL
BGP
LDP
LSD
Switch fabric
EIGRP
Static
routes
LC-HW
Ifmgr
Queries
BCDL
FIB
process
RSVP
Used by
NetIO
Version 3.9.0a
Version 4.0.1
Hardware
FIB
Software
FIB table
XMPLST4Module 2/47
355
MPLS LDP
Module 3
Configuring LDP Operation

This section covers the configuration steps and commands to implement
Cisco IOS XR MPLS LDP operation
LDP Configuration Basics

Use these steps to configure MPLS LDP
Enable MPLS LDP
Configure the LDP router-IOD for identification in management and

troubleshooting
Enable discovery hellos by enabling LDP on an interface
Enable targeted hellos, if necessary. There are four ways in which LDP
targeted discovery is enabled:
356
LDP over TE tunnel configuration
LDP targeted neighbor configuration
LDP session protection configuration
L2VPN and AToM neighbor configuration
Configure a variety of other parameters, such as:

!
Session parameters, such as MD5 password for security, and

various timers
Label management, such as specific label allocation and inbound

policies
Version 4.0.1

Module 3
LDP Configuration Basics
Enable MPLS LDP

Configure a LDP router-ID
Configure discovery
! Enable LDP on an interface
Enable targeted discovery, if needed
! LDP over TE tunnel configuration

! LDP Targeted neighbor configuration
! LDP Session Protection configuration
! L2VPN and AToM neighbor configuration
Configure variety of other parameters. such as:
! Session parameters
" Security
" Timers
! Label management
" Allocation
" Inbound policies
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/49
357
MPLS LDP
Module 3
MPLS LDP Manual Configuration

Configure MPLS LDP by using the mpls ldp command at the global
configuration mode.
Once in LDP configuration mode, additional parameters may be configured
as needed. The parameters indicated on the illustration are covered later
in this module.
358
Version 4.0.1

Module 3
MPLS LDP Manual Configuration
router(config)#
mpls ldp
:router(config)# mpls ldp
:router(config-ldp)# ?
backoff
Configure session backoff parameters
default-route
Enable MPLS forwarding for default route
describe
Describe a command without taking real actions
discovery
Configure discovery parameters
downstream-on-demand Downstream on demand label advertisement mode
explicit-null
Configure explicit-null advertisement
graceful-restart
Configure graceful restart feature
holdtime
Configure session holdtime
igp
Configure IGP related parameters
interface
Enable LDP on an interface and enter interface submode
label
Configure label allocation, advertisement, and acceptance
log
Configure logging of LDP events
neighbor
Configure neighbor parameters
nsr
Configure Non-Stop Routing
pwd
Commands used to reach current submode
redistribute
Redistribute information from routing protocols
router-id
Configure router Id
session
Configure session parameters
show
Show contents of configuration
signalling
Configure signalling parameters
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/50
359
MPLS LDP
Module 3
MPLS LDP Parameter Configuration

In this illustration, you see some of the basic configuration parameters:
LDP router ID is configured in MPLS LDP submode using an IP

address
Discovery hello timers determine the time interval for sending hello
messages and waiting to hear from a neighbor. The range is 1 to 65535
seconds, and 65535 means an infinite wait.
360
Hello interval is the time interval between the discovery hello

messages sent to a neighbor; the default interval is 5 seconds
Holdtime interval is the time interval the router waits for a hello
from a discovered LDP neighbor; default is 15 seconds
Discovery targeted-hello timers determine the time interval for sending

hello messages and waiting to hear from a neighbor. Targeted discovery
includes additional parameters to limit the scope of the received hello
messages. The range is 1 to 65535 seconds, and 65535 means an
infinite wait
!
Hello interval is the time interval between the discovery hello

messages sent to a targeted neighbor; the default interval is 5
seconds
Holdtime interval is the time interval the router waits for a hello
from a discovered targeted LDP neighbor; default is 15 seconds
Accept decides whether or not a router accepts incoming hellos from

any other router; default is no acceptance
From is an optional parameter that may be used to limit the sources

of targeted hellos by using an access control list (ACL)
Holdtime is the base for maintaining sessions with other LDP peers
when no messages are received. The default time is 180 seconds and
the range is 15 to 65535 seconds.
Version 4.0.1

Module 3
MPLS LDP Parameter Configuration
:router(config-ldp)# router-id 1.1.1.1

:router(config-ldp)# discovery hello holdtime 15
:router(config-ldp)# discovery hello interval 5
:router(config-ldp)# discovery targeted-hello holdtime 90
:router(config-ldp)# discovery targeted-hello interval 10
:router(config-ldp)# discovery targeted-hello accept from TARGETED-PEERS-ACL
:router(config-ldp)# holdtime 180
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/51
361
MPLS LDP
Module 3
MPLS LDP IGP Auto-Configuration

The LDP IGP auto-configuration feature simplifies the process of enabling
LDP on interfaces used by an IGP instance, without specifically
configuring them under LDP.
MPLS LDP Auto-Configuration Options

Only OSPF and IS-IS have support for MPLS LDP auto-configuration.
For OSPF, you may use the mpls ldp auto-config command at the router
configuration mode for OSPF or the OSPF area submode.
For IS-IS, the configuration is created under the IPv4 address family at the
router configuration mode.
LDP may be disabled on specific interfaces by using the igp auto-config
disable command on any interface within the LDP interface configuration
mode.
362
Version 4.0.1

Module 3
LDP IGP Auto-Configuration and Options
Auto-configuration feature simplifies process of enabling

LDP on interfaces of an IGP
Configure auto-config under the specific IGP: OSPF or

IS-IS
!No interface configuration in MPLS LDP

:router(config)# router ospf test
:router(config-ospf)# area 0
:router(config-ospf-ar)# mpls ldp auto-config
:router(config-ospf-ar)# interface POS0/2/0/2
Configuration options for OSPF
Version 3.9.0a
XMPLST4Module 2/51
! At OSPF process level

! At OSPF area level
:router(config)# router ospf lab

:router(config-ospf)# mpls ldp auto-config
:router(config-ospf-ar)# mpls ldp auto-config
Configuration options for IS-IS

:router(config)# router isis lab
:router(config-isis)# address-family ipv4 unicast
:router(config-isis-af)# mpls ldp auto-config
Disable options per LDP interface

:router(config-ldp-if)# igp auto-config disable
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/52
363
MPLS LDP
Module 3
Session Authentication
Each session between a router and its peers may be secured. Maintaining
session security is accomplished by establishing passwords between
neighbors. Authentication of peer sessions is discussed in this section.
LDP Neighbor Session Authentication

LDP supports Message Digest 5 (MD-5) based TCP session authentication.
To configure password authentication using the MD-5 option for a
neighbor, use the neighbor password command in the MPLS LDP
configuration mode.
This security feature is enabled for each neighbor, so that a session
establishment attempt is allowed only when a password match has been
made. This option must be configured on both sides of the connection.
The clear option means the command is entered with an unencrypted
password string. The encrypted option means the string following is
encrypted. When viewing the neighbor command in the configuration file,
or with a show command, the password is displayed only as an encrypted
value.
364
Version 4.0.1

Module 3
Session Authentication
LDP Neighbor Session Authentication
Authentication is MD-5 based password for the TCP-based

LDP session
Configuration options are
! Global password for all neighbors

! Enable password by neighbor
! Disable password by neighbor
:router(config-ldp)#
neighbor password {clear | encrypted} password

neighbor ipv4-address password {clear | encrypted} password
neighbor ipv4-address password disable
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/56
365
MPLS LDP
Module 3
Label Filtering
This section discusses the allocation and filtering of LDP labels. Labels are
allocated locally and advertised to peers. The labels allocated and
advertised may be managed using filters. Likewise, labels received from
peers may also be managed using filters.
Local Label Allocation

By default, LDP allocates local labels for all IGP prefixes it learns.
For L3VPNs it is neither efficient nor necessary, to allocate and advertise
local labels for, potentially, thousands of IGP prefixes. It is more efficient
to setup LDP to allocate and advertise local labels for the loopback
addresses of PE routers, or use LDP local label allocation control to limit
the allocation of local labels to a set of prefixes.
Limiting local label allocation provides several benefits:
Reduced memory usage
Fewer local forwarding updates
Fewer network and peer updates
Faster convergence
The local label allocation policy controls allocation of local labels and
supersedes outbound label filtering rules. If no label is allocated none is
advertised.
The label allocate for <access-list | host-routes> command permits
control of allocated label prefixes based upon an ACL or host routes only.
366
Version 4.0.1

Module 3
Label Filtering
Local Label Allocation
Local label allocation policy
! Control allocation of local label

! Limit allocation to a set of routing prefixes
Saves
! Control and forwarding plane activity

! Memory resource usage
! Network updates
Faster LDP convergence

Useful with L2VPN and L3VPN setup
! Allocate and advertise labels for PE loopback address only
label allocate for { access-list | host-routes }
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/58
367
MPLS LDP
Module 3
Outbound Label Advertisement

By default, LDP advertises labels for all the prefixes to all its neighbors.
For enhanced scalability and security, LDP can be configured to perform
outbound filtering for local label advertisement for one or more prefixes to
one or more peers. This feature is known as LDP outbound label filtering,
or outbound label advertisement control.
Outbound label advertisement controls the advertisement of local

labels
!
Label advertisement is limited to a set of prefixes sent to set of

peers
Outbound label filtering is not required unless a per-peer

advertisement policy is needed, even if a label allocation policy is in
place
This feature allows multiple configuration rules and may be

complex in nature
!
Care is advised to avoid conflicts with rule ordering
Outbound label advertisement commands
Here are the commands to control outbound label advertisements:
368
The label advertisement command allows advertising the interfaces

/32 addresses
Label advertisement can be limited to prefixes defined in a source

prefix ACL, by using the label advertise for command with ACLs
To disable label advertisement to all peers for all prefixes (if there are
no other conflicting rules) use the label advertise disable command
Version 4.0.1

Module 3
Label Filtering
Outbound Label Advertisement
Defines a local label advertisement policy
! Controls advertisement of local labels

! Advertisement is limited to set of prefixes sent to set of peers
With a label allocation policy in place
! Outbound policy is not required unless a per-peer advertisement

policy is needed
Feature configuration:
! Multiple configuration rules

! May be complex in nature
! Care is required to avoid conflicts with rule ordering
label advertise [ disable | for access-list [ to peer-acl ] | interface type interface-id ]
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/59
369
MPLS LDP
Module 3
Inbound Label Acceptance

By default, LDP accepts labels (as remote bindings) for all prefixes, from
all peers. LDP operates in liberal label retention mode, which instructs
LDP to keep remote bindings from all peers, for a given prefix.
For security reasons, or to conserve memory, you may override this
behavior, by configuring label binding acceptance for a set of prefixes from
a given peer. The ability to filter remote bindings for a defined set of
prefixes is also referred to as LDP inbound label acceptance.
_____________________________ Note _________________________
Inbound label acceptance can also be implemented using an equivalent
outbound filtering policy at the peer LSR. However, you may not be
able to implement this method if an LDP peer resides under a different
administrative domain. When both inbound and outbound filtering
options are available, we recommend that you use outbound label
filtering.
__________________________________________________________________
Unlike outbound filtering configuration, that may use a peer ACL, inbound
configuration is done per-neighbor by IP address.
The label accept for prefix-acl from peer-ip-addr command configures
inbound label acceptance for prefixes specified by a prefix-acl from a
specified neighbor defined by its IP address.
_____________________________ Note _________________________
If the inbound label filtering policy changes, such that it allows
previously-denied prefixes from a peer, you must reset the LDP session
with the peer using the clear mpls ldp neighbor command.
__________________________________________________________________
370
Version 4.0.1

Module 3
Label Filtering
Inbound Label Acceptance
Defines a remote label acceptance policy
Controls receipt of incoming labels (remote

bindings) for set of prefixes from peers
Used at LERs to control receipt of labels from peers

under different administrative domain
Outbound policy application on peer side is more

efficient than inbound policy on local side
Inbound configuration is done per-neighbor

label accept for prefix-acl from ip-address
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/60
371
MPLS LDP
Module 3
Session Protection
LDP session protection is a feature to protect existing LDP (link-based)
sessions by means of a parallel source of targeted hellos towards the peer.
Overview
When a link flaps and comes back up, IP may converge before LDP. This
may result in an MPLS traffic loss until LDP converges. If a link flaps, the
LDP session also flaps due to loss of link hellos.
With session protection, an LDP session is kept alive and neighbor label
bindings are maintained when links are down. Upon reestablishment of
primary link adjacencies, LDP convergence is expedited, because it need
not relearn the neighbor label bindings.
The LDP session protection feature results in:
Minimal traffic loss
Fast convergence
LDP session protection lets you configure LDP to automatically protect

sessions with all, or a given set of peers (as specified by a peer-acl). When
configured, LDP initiates backup targeted hellos automatically for
neighbors for which primary link adjacencies already exist. These backup
targeted hellos maintain LDP sessions when primary link adjacencies fail.
The figure on the adjacent page illustrates LDP session protection between
neighbors R1 and R3. The primary link adjacency between R1 and R3 is a
directly connected link, and the backup is a targeted adjacency between R1
and R3. If the direct link fails, the LDP link adjacency fails, but the session
is maintained by a targeted hello adjacency (through R2). When the direct
link is restored, there is no change in the LDP session state so LDP
converges rapidly and forwards MPLS traffic over the original link.
372
Version 4.0.1

Module 3
Session Protection
Session Protection Overview
Problem:
Link up: IP converges before LDP
! MPLS traffic is lost until LDP converges
Link flap: LDP session also flaps

Solution:
Protect the LDP session by means of a parallel source with a

targeted hello discovery
Using IP connectivity the LDP session is kept alive and
neighbor label bindings are maintained while a link is down
When the link comes up there is:
! Minimal traffic loss

! Faster LDP convergence
Targeted
hello
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/62
373
MPLS LDP
Module 3
Session Protection Configuration

Configure LDP session protection for peers specified by a peer-acl using a
maximum duration, set in seconds with this command:
session protection [duration seconds | infinite] [for peer-acl]
The session protection command, by itself, implements protection for all
peer sessions and continues for 24 hours after the loss of session.
Session protection is not configured by default, so there is no default value
for the duration. Duration, when configured, has a range of 30 to 2147483
seconds. When the keyword, infinite, is used the session lasts forever
after the loss of the link is discovered.
Session protection logging may be enabled allowing you to monitor and
troubleshoot the process.
log session-protection
In addition to session protection logging, debugging may be used as a
troubleshooting analysis tool.
debug mpls ldp session protection peer-acl ACL
374
Version 4.0.1

Module 3
Session Protection
Session Protection Configuration
Creates LDP session protection for all peers or a set of peers
!Set hold duration
session protection [ duration seconds | infinite ] [ for peer-acl ]

log session protection
:router(config-ldp)# session protection duration 120 for SESSION-PROTECTED-PEERS

:router(config-ldp)# log session-protection
mpls_ldp[315]:%LDP-5-SESS_PROTECT:Session hold up initiated for peer 3.3.3.3:0
mpls_ldp[315]:%LDP-5-SESS_PROTECT:Session recovery succeeded for peer 3.3.3.3:0
:router# debug mpls ldp session protection peer-acl acl
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/63
375
MPLS LDP
Module 3
Session Protection Status

To view LDP neighbor session protection status, use this command:
show mpls ldp neighbor ipv4-address detail
The result of the command provides a display of the status of the targeted
hello session and configured information, in addition to other LDP session
parameters.
376
Version 4.0.1

Module 3
Session Protection
Session Protection Status
Displays LDP Session Protection status for given neighbor

:router#
show mpls ldp neighbor ipv4-address detail

:router# show mpls ldp neighbor 3.3.3.3 detail
Peer LDP Identifier: 3.3.3.3:0
Up time: 00:04:23
LDP Discovery Sources:
Targeted Hello (1.1.1.1 -> 3.3.3.3, active)
Addresses bound to this peer:
Clients: Dir Adj Client

Session Protection:
Enabled, state: Protecting
ACL: 'peer-acl3', Duration: 45 seconds
Holdup timer remaining: 21 seconds
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/64
377
MPLS LDP
Module 3
LDP IGP Synchronization

LDP IGP synchronization delays use of a link under IGP until MPLS LDP
converges on the link. This feature is extremely effective in an
environment where a router goes down, and later comes back up.
Overview of LDP Synchronization

Lack of synchronization between LDP and IGP can cause MPLS traffic
loss. Upon link up, for example, IGP can advertise and use a link before
LDP convergence has occurred; similarly a link may continue to be used in
IGP, after an LDP session goes down.
LDP considers a link converged, when
An LDP session is running on a link
All label bindings are sent to a peer
At least one label is received from a peer
LDP communicates this information to the IGP upon link up, or session
down events and IGP acts accordingly, depending on the synchronized
state.
With local LDP restart, (using IGP-sync and graceful restart) a recovered
LDP graceful restart session is used and treated as converged, and is given
an opportunity to connect and re-synchronize.
LDP IGP Synchronization for TE Tunnels

IGP synchronization with MPLS traffic engineering auto-route announced
tunnels (an IGP shortcut) is available for OSPF only. The behavior is
similar to the physical interfaces, however there is a difference in the
metric computation for a TE tunnel. It is configured at the router mode, or
area and interface (tunnel) submodes.
378
Version 4.0.1

Module 3
LDP IGP Synchronization Overview
Problem:
Link up: traffic delay, because IGP converges before LDP

LDP session down: Traffic loss on peer next hop interfaces
Traffic delay or loss for L2VPN, L3VPN, or multi-label traffic
Solution:
Best use when a router goes down and returns to operation

No traffic is routed towards links on which LDP has not yet converged
Synchronize IGP with LDP so that LDP controls the IGP metric for a
link
A link is advertised by IGP with a max-metric if the LDP session has
not yet converged (label binding exchange)
Version 3.9.0a
XMPLST4Module 2/67
Use the shortcut synchronization command
!Makes synchronization available to IGP shortcuts

" Traffic engineering tunnels
Configure in
!Router mode
!Area submode
!Interface submode
" Auto-route announced TE tunnels
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/68
379
MPLS LDP
Module 3
LDP OSPF Synchronization Configuration

Synchronization for LDP with OSPF is configured at the router or process
mode for all interfaces under OSPF. It may be configured at the area
submode or the interface submode, as well.
The disable keyword is available to turn off synchronization at any one of
the levels. For instance, turning on synchronization at area level may
include interfaces for which synchronization is unneeded, and therefore it
can be disabled for those interfaces.
LDP OSPF TE Synchronization Configuration

MPLS shortcuts, auto-route announced tunnels, are configured for IGP
(OSPF) synchronization using the mpls ldp sync-igp-shortcuts
command.
380
Version 4.0.1

Module 3
LDP IGP Synchronization Configuration
Enabled under OSPF
! Process mode
! Area submode
! Interface submode
:router(config-ospf)#
mpls ldp sync [ disable ]

mpls ldp sync-igp-shortcuts [ disable ]
:router(config-ospf)# mpls ldp sync
:router(config-ospf-ar)# mpls ldp sync
:router(config-ospf-ar-if)# mpls ldp sync
:router(config-ospf)# mpls ldp sync-igp-shortcuts
:router(config-ospf-ar)# mpls ldp sync-igp-shortcuts
Version 3.9.0a
XMPLST4Module 2/70
Enabled under router OSPF mode

Enabled under OSPF area submode
Enabled under interface submode for TE tunnels only
!Not available under regular interfaces
:router(config-ospf-ar)#
:router(config-ospf-ar-if)#
mpls ldp sync-igp-shortcuts [ disable ]
:router(config-ospf)# mpls ldp sync-igp-shortcuts

:router(config-ospf-ar)# mpls ldp sync-igp-shortcuts
:router(config-ospf-ar)# interface tunnel-te3
:router(config-ospf-ar-if)# mpls ldp sync-igp-shortcuts
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/71
381
MPLS LDP
Module 3
LDP IS-IS Synchronization Configuration

With the IS-IS protocol, MPLS VPN traffic using LDP labels may be
dropped due to:
Introduction of a new link in the network and IS-IS converging before

LDP has assigned a label and advertised it
An existing LDP session fails while IS-IS remains up over a particular

link
In these situations, outbound labels are not available to forward MPLS

traffic. Synchronization for LDP with IS-IS addresses this scenario. IS-IS
advertises the maximum link metric until LDP converges on the link. The
maximum metric varies depending on the metric style, wide or narrow.
The narrow metric is not affected, but the wide metric maximum of
16777214 is advertised to exclude the link from the shortest path first
(SPF) calculation. Once a peering and label exchange occurs, IS-IS
advertises the normal metric.
Synchronization is configured at the address family submode under the
interface submode.
382
Version 4.0.1

Module 3
LDP IS-IS Synchronization Configuration
Enabled under IS-IS interface address family

:router#
mpls ldp sync [ level {1 | 2 } ]
:router(config-isis-if-af)# mpls ldp sync level 2
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/72
383
MPLS LDP
Module 3
Viewing LDP IGP Synchronization Status

Each of these commands provides information on LDP IGP
synchronization link status, either in general, or by protocol and interface:
The show mpls ldp igp sync command displays any interface on the
router that is configured for MPLS LDP IGP synchronization. It shows the
status of synchronization and the peer at the far end of the link. Notice in
the display that GR (graceful restart) is available on the POS0/2/0/1 link
with the peer, 3.3.3.3.
The information about individual links is available within the larger
interface display for the protocol. In the illustration, the information is
singled out by using a pipe (|) and include parameter, and specifying
LDP.
384
Version 4.0.1

Module 3
LDP IGP Synchronization Status
Display LDP IGP sync status for links

:router#
show mpls ldp igp sync [ interface type interface-id ] [ location node-id | standby ]
:router# show mpls ldp igp sync
POS0/2/0/1:
Sync status: Ready
Peers:
3.3.3.3:0 (GR)
POS0/2/0/2:
Sync status: Not ready
(Deferred; 23 sec remaining)
:router# show ospf lab interface POS 0/2/0/1 | inc LDP
LDP Sync Enabled, Sync Status: Achieved
:router# show isis lab interface POS 0/2/0/1 | inc LDP
LDP Sync Enabled, Sync Status: Achieved
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/73
385
MPLS LDP
Module 3
LDP IGP Synchronization Delay

Under certain circumstances, it may be required to delay the declaration of
re-synchronization for a configurable interval. LDP provides a
configuration option to delay declaring synchronization for up to 60
seconds. LDP communicates this information to the IGP upon link up, or
session down events.
The configuration for LDP IGP synchronization resides in the respective
IGPs, OSPF and IS-IS. There is no LDP-specific configuration for enabling
this feature. However, there is a specific LDP configuration for delaying
the declaration of sync-up to IGPs, after a session comes up on a link.
IGP Sync Delay On Process Restart

In a large-scale network comprised of hundreds of LDP and IGP
adjacencies, including multiple IGP areas and routes, a process restart is
very resource intensive. If that restarting LDP process has IGP-sync, but
no graceful-restart (GR), the convergence, with the SPF calculation and
routing changes, is very process-intensive, too. Delaying the convergence
computation and notification to the IGP, after the LDP process restart, has
benefits. It helps LDP achieve a steady state with the peer protocol by
reducing IGP stress while using one bulk notification for all links to the
IGP, after the global delay timer expires.
LDP IGP Synchronization Delay Configuration

By default, LDP does not delay declaring synchronization up as soon as
convergence conditions are met. Use the igp sync delay to configure the
LDP IGP synchronization delay interval, if the network needs the extra
time to synchronize.
To delay sync-up globally for LDP process restarts, configure LDP IGP
synchronization upon process restart, under MPLS LDP.
386
Version 4.0.1

Module 3
LDP IGP Synchronization Delay and Configuration
Want to hold synchronization for some time period

! Network design may dictate holding synchronization
Delay synchronization if LDP fails or restarts
! Help LDP achieve steady state with peers

! Help LDP achieve to coordinate information with IGP
" Prior to sending missed LDP keep-alive messages
! Help IGP by reducing stress
" One bulk notification to IGP after timer expires
igp sync delay seconds

igp sync delay on-proc-restart seconds
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/74
387
MPLS LDP
Module 3
Graceful Restart
LDP graceful restart provides a control plane mechanism to ensure high
availability; it allows detection and recovery from failure conditions, while
preserving nonstop forwarding (NSF) services.
Overview
Graceful restart is a way to recover from signaling and control plane
failures, without impacting forwarding. Without LDP graceful restart,
when an established session fails, the corresponding forwarding states are
cleaned immediately from the restarting and peer nodes. In that case, LDP
forwarding has to restart from the beginning, causing a potential loss of
data and connectivity.
The LDP graceful restart capability is negotiated between two peers during
session initialization time, using the fault tolerant session TLV (FT
SESSION TLV). In this TLV, an LSR advertises this information to its
peers:
Reconnect time: maximum time the peer should wait for this LSR to
reconnect after control channel failure before purging its state
Recovery time: maximum time that the peer has on its side to reinstate
or refresh its states with this LSR. This time is used only during
session reestablishment after earlier session failure
FT flag: flag indicates whether a restart could restore the preserved

(local) node state
Once the graceful restart session parameters are conveyed, and the session
is up and running, graceful restart procedures are activated.
Graceful Restart Operational Modes

These are the graceful restart operational modes:
Capable: supports both local restart and peer restart
Aware: supports only peer restart; local restart is not supported,

usually due to an inability to preserve forwarding state during LDP
restart
Cisco IOS XR operating system LDP is fully GR capable and supports both
local and peer restarts.
388
Version 4.0.1

Module 3
Graceful Restart
Graceful Restart Overview
LDP GR IETF specification, RFC 3478
!Peers advertise GR capability during session

!
establishment phase
GR operational support modes
" Capable: support both local restart and peer restart

" Aware: supports only peer restart; local restart is not
supported usually due to inability to preserve forwarding

state during LDP restart
Cisco IOS XR operating system Graceful Restart (GR)
!Mechanism to enable NSF

!Way to recover from control plane failures with minimal
!
forwarding impact
Supports both capable and aware modes for local and peer
Version 3.9.0a
XMPLST4Module 2/76
Instructor's Note
Following a processor switchover, graceful restart and non-stop routing both allow for the
forwarding of data packets to continue along known routes, while the routing protocol
information is being restored (in the case of graceful restart) or refreshed (in the case of non-stop
routing). When GR is used, peer networking devices are informed, using protocol extensions
prior to the event, of the SSO capable routers ability to perform graceful restart. The peer device
must have the ability to understand this messaging. When a switchover occurs, the peer will
continue to forward to the router switching over, as instructed by the GR process for each
particular protocol, even though in most cases, the peering relationship needs to be rebuilt.
Essentially, the peer router gives the switching over router a grace period to re-establish the
neighbor relationship, while continuing to forward to the routes from that peer.
Version 4.0.1
389
MPLS LDP
Module 3
Graceful Restart Phases

The graceful restart mechanism can be divided into different phases:
Control communication failure detection
Forwarding state maintenance during failure
Control state recovery
Control Communication Failure Detection

Control communication failure for a session is detected when the system
detects:
Missed LDP hello discovery messages
Missed LDP keep-alive protocol messages
Detection of Transmission Control Protocol (TCP) disconnection with a

peer
Forwarding State Maintenance During Failure

While the control plane is in the process of recovering, the forwarding
plane keeps the forwarding states, but marks them as stale. Similarly, the
peer control plane also keeps (and marks as stale) the installed forwarding
rewrites associated with the restarting node. The combination of local and
remote node forwarding plane states ensures non-stop forwarding (NSF),
and that there is no disruption in the bi-directional traffic.
Control State Recovery
Recovery occurs when the session is re-established and label bindings are
exchanged again. This process allows the peer nodes to synchronize and to
refresh stale forwarding states.
390
Version 4.0.1

Module 3
Graceful Restart
Graceful Restart Phases
Graceful Restart can be divided into three phases:
Control Communication Failure
! Missed LDP hello messages

! Missed LDP keepalive messages
! TCP disconnects from a peer
Forwarding State Maintenance During Failure
! Forwarding continues using existing states, but marks them as

stale
! Peer also marks forwarding rewrites for restarting node as stale
! Forwarding plane states ensure NSF continues no disruption to
bi-directional traffic
Control State Recovery
! Session is reestablished and label bindings are exchanged again

! Peer nodes synchronize and refresh stale forwarding states
Version 4.0.1
391
MPLS LDP
Module 3
Graceful Restart Recovery

Restarting LSR Control Plane
When the LDP control plane recovers, the restarting LSR starts its
forwarding state hold timer, and restores its forwarding state entries. This
action reinstates the forwarding state entries, and marks them as ^not
stale. The restarting LSR reconnects to its peer, indicating in the fault
tolerant session type length value (FT Session TLV), that it either, was or
was not, able to restore its state successfully. If it was able to restore the
state, the bindings are resynchronized.
Peer LSR
The peer LSR stops its neighbor reconnect timer (started at the time of
communication channel failure), when the restarting peer connects. It also
starts a neighbor recovery timer. The peer LSR checks the FT Session
TLV. If the restarting peer was able to restore its state successfully it
reinstates the corresponding forwarding state entries and receives
bindings from the restarting peer. When the recovery timer expires, any
forwarding state that is still marked as stale is deleted.
_____________________________ Note _________________________
If the restarting LSR fails to recover (restart), the restarting LSR
forwarding state and entries will eventually timeout and be deleted.
Neighbor-related forwarding states, or entries, are removed by the peer
LSR upon expiration of the reconnect or recovery timer.
__________________________________________________________________
392
Version 4.0.1

Module 3
Graceful Restart
Graceful Restart Recovery
Control Plane Recovery for restarting LSR
!Starts forwarding state hold timer

!Reinstate forwarding state entries mark them not stale
!Reconnect to peer
" States successfully restored re-synchronized bindings
Peer LSR
!Stops reconnect timer
" Started at the time of communication channel failure

" Neighbor recovery timer started when reconnect timer
stopped
" When recovery timer expires any stale forwarding states
deleted
Version 3.9.0a
XMPLST4Module 2/78
Instructor's Note
Graceful restart also handles failures such as process restart.
Version 4.0.1
393
MPLS LDP
Module 3
Graceful Restart Timers

Reconnect-Timeout
This parameter is used to start a timer on the peer LSR (upon a neighbor
restart). This timer is typically referred to as the neighbor liveliness timer,
because it determines the length of time a neighbor waits to reconnect,
before declaring a graceful restart session as down.
Forwarding State Hold time
This timer specifies the length of time that stale LDP forwarding states
and rewrites are maintained in forwarding. When the forwarding state
hold time expires, any previously installed LDP forwarding state or rewrite
that has not been refreshed, is deleted from the forwarding table. The
forwarding state hold time encompasses local control plane restart and
recovery time.
Recovery Timeout
The recovery time sent to the peer LSR after restart. It is the current
remaining value of the forwarding state hold timer.
394
Version 4.0.1

Module 3
Graceful Restart
Graceful Restart Timers
Reconnect-timeout
! Time restarting router wants neighbor to wait after LDP session
initially fails
Forwarding-state-holdtime
! Time it takes for the restarting router to complete its restart
process
Recovery timeout
!Time advertised by a restarting LSR

!Indicates time MPLS forwarding state is retained after
being preserved across the restart
!Current remaining value of the forwarding state hold timer
" Zero indicates MPLS forwarding state was not, or could not be,
preserved across the restart

" Recovery time should be long enough to allow the neighboring LSRs
to re-synchronize all LSPs in a graceful manner
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/79
395
MPLS LDP
Module 3
Graceful Restart Configuration

Graceful restart is an MPLS LDP configuration option that is enabled, or
disabled, for all MPLS LDP interfaces globally. The graceful restart event
logging feature presents information by the session.
Graceful restart requires the LDP neighbor to have peer (aware)
capability. If the LDP session is already active and graceful restart is
configured, the session flaps because this capability is negotiated during
LDP startup.
The default reconnect time of 120 seconds (2 minutes) may not be long
enough for heavily loaded systems. For those heavily loaded systems
needing periods of 5 to 10 minutes may be required (with some customers
needing up to 15 minutes).
Logging can be used to show how long a neighbor is down and the time it
takes to reconnect. Note that the display on the opposite page has been
cleaned up for presentation purposes.
396
Version 4.0.1

Module 3
Graceful Restart
Graceful Restart Configuration
GR is enabled and disabled globally

GR event logging related to sessions
graceful-restart
graceful-restart reconnect-timeout seconds
graceful-restart forwarding-state-holdtime seconds
log graceful-restart
:router# show log | incl mpls_ldp
mpls_ldp[282]:%ROUTING-LDP-5-GR:GR session 3.3.3.3:0 (instance 1) disconnected
mpls_ldp[282]:%ROUTING-LDP-5-GR:GR session 3.3.3.3:0 (instance 2) reconnected
mpls_ldp[282]:%ROUTING-LDP-5-GR:GR session 3.3.3.3:0 (instance 2) timed out
mpls_ldp[282]:%ROUTING-LDP-5-GR_RESTART_COMPLETE:GR forwarding state hold
timer expired
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/80
397
MPLS LDP
Module 3
LDP Non-Stop Routing (NSR) and Forwarding Overview

This section discusses non-stop routing and forwarding and how it is
implemented in the Cisco IOS XR operating system.
Overview
LDP nonstop routing (NSR) functionality makes failures, such as route
processor (RP) or distributed route processor (DRP) failover, invisible to
routing peers with minimal or no disruption of convergence performance.
By default, NSR is globally enabled on all LDP sessions except AToM.
A disruption in service may include any of these events: Route processor
(RP) or distributed route processor (DRP) failover, LDP process restart, inservice system upgrade (ISSU), or minimum disruption restart (MDR).
_____________________________ Note _________________________
Unlike graceful restart functionality, LDP NSR does not require
protocol extensions, does not force software upgrades on other routers
in the network, and does not require peer routers to support NSR.
__________________________________________________________________
Graceful restart (GR) has some limitations or drawbacks:
Routing protocol extensions are needed, and interoperability issues can
exist between different equipment vendors
Timers may need to be adjusted to obtain optimal performance
Stale forwarding (headless forwarding) states, where forwarding
continues based on the last set of routing updates, which are not
updated until timers have expired and LDP updates have been
completed
_____________________________ Note _________________________
GR is also known as non-stop forwarding (NSF)

__________________________________________________________________
NSR maintains the routing topology across HA events, such as RP
switchover. NSR does not require protocol extensions, reducing the
possibility of vendor compatibility issues. There is no dependence on the
forwarding-planes NSF capability and near transparent NSR-enabled
recovery:
!
!
398
Neighbors and protocol peers are unaware of OSPF and LDP

process restart or RP failover
Minimal information re-flooded during NSR recovery
Version 4.0.1

Module 3
Non-Stop Routing and NSF Overview
GR or NSF limitations and drawbacks
!Protocol extensions and interoperability issues

!Timer tuning
!Stale forwarding (headless forwarding)
NSR solution
!Routing topology maintained across HA events

" RP switchover
!No protocol extensions required

!No forwarding-plane NSF capability dependence
!Near transparent NSR-enabled recovery
" Neighbors and protocol peers unaware of BGP, OSPF, IS-IS and LDP
process state changes
" Minimal information re-flooded during NSR recovery
LDP NSR and GR features can co-exist

Version 3.9.0a
XMPLST4Module 2/82
Instructor's Note
Graceful restart and non-stop routing suppress routing changes on peers to SSO-enabled devices
during processor switchover events, reducing network instability and downtime. SSO is necessary
to handle other non-routing protocol-related items needed for the router to operate, following a
switchover. These items include synchronizing the complete router configuration, CEF entries
and other information needed by the standby processor. Following a processor switchover,
graceful restart and non-stop routing both allow for the forwarding of data packets to continue
along known routes while the routing protocol information is being restored (in the case of
graceful restart) or refreshed (in the case of non-stop routing). When non-stop routing is used,
peer-networking devices have no knowledge of any event occurring on the router experiencing
switchover. All information needed to continue the routing protocol peering state is transferred to
the standby processor so it can pick up immediately upon a switchover. Unlike graceful restart,
non-stop routing uses more system resources due to the information transfer taking place to the
standby processor. Standards are not necessary in the case of non-stop routing, as the solution
does not require any additional communication with protocol peers.
Version 4.0.1
399
MPLS LDP
Module 3
SSO Functionality
Stateful Switchover (SSO) is required for both GR (NSF) and NSR across
RP and DRP failover.
Graceful restart and non-stop routing suppress routing changes to SSOenabled peer devices during processor switchover events. This results in
reduced network instability and downtime. With SSO, active and standby
RPs maintain non-routing protocol-related items needed for the router to
operate following a switchover. These items include:
Synchronizing the complete router configuration
Layer 2 data-link connectivity information (required to maintain

Layer 2 connections)
CEF entries and other information needed by the standby processor
Maintaining the connection is imperative to minimize CPU utilization,

reduce the amount of data loss during a switchover, and quickly establish
the standby processor to an active state.
3100
Version 4.0.1

Module 3
SSO Functionality
SSO required for NSF and NSR on RP and DRP

failover
With SSO active and standby RPs
!Minimize CPU utilization and data loss

!Maintain non-routing protocol related items for router
operation following a switchover
Includes, but not limited to
" Synchronizing complete router configuration

" Layer 2 data-link connectivity information (required to
maintain Layer 2 connections)
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/83
3101
MPLS LDP
Module 3
NSR and SSO Functionality

SSO supports NSR across both RP and DRP failover. Using SSO without
NSR capability has these shortcomings:
LDP sessions terminate during an RP failover
LDP on standby RP re-establishes the sessions after the standby goes

active
Using SSO with NSR has these advantages:
LDP sessions do not terminate during an RP failover
New active RP continues and peers are unaware of the failover
NSR is achieved because the LDP stack runs on both the active and
standby RP. The RPs collaborate with each other and with their respective
TCP stacks. LDP NSR functionality is based on three stages:
Initial synchronization: session and peer binding state is synchronized

between the active and standby RP and DRP. LDP and TCP transport
stacks start providing NSR capability for that session.
Steady-state: active LDP (A-LDP) and standby LDP (S-LDP) operate

independent of each other, running their state machines, and building
their database, separately. There is some minimal steady state
synchronization, where the A-LDP stack mirrors some states to its
counterpart, the S-LDP stack. S-LDP takes over in event of a failover;
that is, it starts from the point where the A-LDP stack left off. The
active TCP stack also collaborates with the standby TCP stack in
sending and receiving peer data.
Switch-over stage (after failover occurs):

!
The TCP stack on the new A-RP retransmits information requested

by the peer, and resumes the normal TCP stack operation in both
directions
The new A-LDP stack carries out these functions:

!
Re-sends its protocol updates (local label and addresses) to the

peers
Sends any pending updates and responses to its peer
Processes incoming messages and continues from where the

previously active LDP session left off
Once the new S-LDP becomes available again, the stacks go through the
synchronization and steady-state stages again to provide NSR capability.
3102
Version 4.0.1

Module 3
NSR and SSO Functionality
NSR uses SSO on RP and DRP failover
! Maintain Layer 2 connectivity on active and standby RP

! Maintains Layer 2 connectivity during switchover
Without NSR
! LDP sessions terminate during an RP failover

! LDP on S-RP re-establishes the sessions after S-RP goes active
With NSR
! LDP sessions do not terminate during an RP failover

! New active RP continues; peers are unaware of failover
To provide NSR
! LDP stack runs on both active and standby RP

! A-LDP and S-LDP collaborate with each other and with TCP stacks on
respective RP nodes
LDP NSR based on three stages
Version 3.9.0a
XMPLST4Module 2/85
1. Initial synchronization: session state is synchronized between the

active and standby RP and DRP. LDP and TCP stacks start providing
NSR capability for that session
2. Steady-state: A-LDP stack mirrors peer binding states to its
counterpart S-LDP. S-LDP takes over in event of FO, starting from the
point where the A-LDP left off
! A-TCP collaborates with S-TCP in sending and receiving peer data
3. Switch-over stage (after FO occurs)

! TCP stack on new A-RP retransmits information requested by peer, and
resumes the normal TCP stack operation in both directions

! The new A-LDP stack:
" Re-sends its protocol updates (local label and addresses) to the peers
" Sends any pending updates and responses to peer
" Processes incoming messages and continues from where the previously A-LDP
has left off
Once the new S-LDP becomes available again, stacks go through
the synchronization and steady-state stages again to provide NSR

capability
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/86
3103
MPLS LDP
Module 3
LDP NSR Component Interactions

With LDP NSR, the active and standby RP (DRP) interact:
Standby-LDP standby capability:

!
Operationally HOT (NSR configured)
Operationally WARM (NSR not configured)
Standby-LDP connects to S-TCP to replicate NSR sessions and to

perform protocol message input and output
S-LDP interacts with other collaborators to build its local state
! Routes: Routing Information Base (RIB)

! Labels: Label Switch Database (LSD)
! Local addresses: Address Resolution Manager (ARM)
! Local Interfaces: Interface Manager (Ifmgr)
Active and S-LDP use asynchronous communication to synchronize
their LDP global and protocol states
State synchronization is done during initial-sync phase, and during

steady state operation
The LDP states related to synchronization functionality include:

!
!
!
!
3104
Hello adjacencies
Peer sessions
Peer label bindings
Peer address bindings
Version 4.0.1

Module 3
LDP NSR Component Interactions
Active RP
Ifmg
ARM
RIB
r
Address
Route
Interface resolution
mgr
UDP
Discovery
hellos
table
LDP
Standby RP
LSD
Label forward
database
LDP sync
LDP
UDP
Peer connections and

protocol msg I/O
TCP
TCP sync
TCP
S-LDP standby capability: HOT (NSR configured), WARM (NSR not configured)
S-LDP connects to S-TCP to replicate NSR sessions and to perform I/O
S-LDP interacts with other collaborators (RIB, LSD, ARM, and IfMgr) to build its local state
A-LDP and S-LDP use asynchronous communication to synchronize LDP global and protocol
states
State synchronization is done at initial synchronization, and in steady state
LDP state includes:
Hello adjacencies, peer sessions, peer label bindings, peer address bindings
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/87
3105
MPLS LDP
Module 3
NSR Configuration
LDP NSR is enabled globally under LDP. Enabling LDP NSR does not
cause the LDP session to flap; it causes the standby RP (DRP) to
synchronize to the active RP (DRP) by replicating the session to the
standby-LDP process.
The LDP configuration command log nsr supports the logging of LDP NSR
synchronization events.
3106
Version 4.0.1

Module 3
NSR Configuration
LDP NSR is enabled globally under LDP

Supports enabling logging of NSR sync events
nsr
log nsr
:router# show log | incl ldp
mpls_ldp[281]:%ROUTING-LDP-5-NSR_SYNC_START:Initial synch started for
1 peer
mpls_ldp[281]:%ROUTING-LDP-5-NSR_SYNC_PEER:Peer 2.2.2.2:0 initial
synch done
mpls_ldp[281]:%ROUTING-LDP-5-NSR_SYNC_DONE:Initial synch success done
1 peer
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/88
3107
MPLS LDP
Module 3
LDP Pseudowire (PW) Signaling

Pseudowire Emulation Edge to Edge (PWE3) specifies the
encapsulation, transport, control, management, interworking
and security of services emulated over IETF-specified packet switched
networks (PSNs).
Overview
The pseudowire emulates a point-to-point or point-to-multipoint
link. It provides a single service that is perceived as an unshared link or
circuit. The emulation need only be sufficient for the satisfactory
operation of the service. PWE3 operates "edge to edge" and will not exert
control on the underlying PSN, other than to use any existing QoS or
path control mechanism to provide the required connectivity
between the endpoints of the PW.
LDP is also used to carry L2VPN signaling for Layer2 (PW) FEC. LDP plus
L2VPN and AToM implement the PW signaling protocol described in the
IETF PWE3 control protocol. PW setup and maintenance using LDP is
described in these RFCs:
Virtual Private Wire Service (VPWS), RFC 4447
Virtual Private LAN Service (VPLS), RFC 4762
As a signaling protocol between L2VPN PE nodes, LDP is responsible for:
3108
Establishing and maintaining PW sessions
Parsing and relaying messages to AToM
Constructing and transmitting messages for AToM
Version 4.0.1

Module 3
LDP Pseudowire Signaling Overview
LDP and L2VPN or AToM implement the PW signaling protocol

described in IETF PWE3 control protocol
!VPWS: RFC 4447

!VPLS: RFC 4762
A signaling protocol between L2VPN PE nodes, LDP is responsible for:
-Establishing and maintaining PW sessions

-Parsing and relaying messages to AToM
-Constructing and transmitting messages for AToM
Emulated service
Attachment
circuit
Attachment
circuit
Pseudowire
PSN tunnel
MPLS/IP
network
P routers
CE1
PE1
PE2
CE2
LDP PW session
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/90
3109
MPLS LDP
Module 3
LDP PW Signaling Components

LDP protocol extensions for L2VPN and VPWS include:
PW labelPW label bindings are distributed by LDP (between PW

endpoints) using downstream unsolicited distribution with liberal label
retention mode
PWid FEC elementThe operator manually provisions the PEs with

matching PWid values. Each of the two pseudowire endpoints, using
the assigned PWid independently, initiates the setup of a unidirectional
LSP
PW interface parameterSpecific parameters used to validate whether

the PEs at the ingress and egress ports have the necessary capabilities
to interoperate with each other, such as the same MTU
PW error status codeThe PE devices use an LDP TLV to indicate

their status to their remote peers in a four octet bit field that is capable
of carrying multiple errors simultaneously. The status TLV is
transmitted to the remote peer in a notification message
PW status negotiationWhen a PW is first set up, the PEs negotiate

the usage of the PW status TLV. The PW status TLV is used for the
lifetime of the pseudowire
AToM to LDP events include:
3110
Session request: Open and CloseLDP messages are used to set up,
maintain, and tear down sessions with remote PEs for AToM
pseudowires. LDP messages also handle PW label and notification
messages
PW label message transmit: mapping, withdraw, request, release
Notification transmit: PW status
Version 4.0.1

Module 3
LDP protocol extensions for L2VPN and VPWS include:
PW label
PWid FEC element
PW interface parameter
PW error status code
PW status negotiation
AToM to LDP events:
Session request: open or close

PW Label message Transmit: mapping, withdraw, request,
release
Notification Transmit: PW status
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/91
3111
MPLS LDP
Module 3
LDP to AToM events include:
Session: up, down notification
GR per-session: up, down or ended notification
GR global: GR forwarding state hold timer has expired
PW label message received: mapping, withdraw, request, release
Notification received: PW status
Hybrid LDP sessions between directly connected PEs (IPv4 and PW)
events include:
3112
PW: LDP for PW signaling
IPv4: LDP as core labeled transport (enabled on IPv4 interface

connecting the PEs)
Version 4.0.1

Module 3
LDP to AToM events:
Session: up or down notification

GR session: up, down or ended notification
GR global: GR forward state hold timer expired
PW Label message received: mapping, withdraw, request, release
Notification received: PW status
Hybrid LDP session directly connected PEs (IPv4 + PW):
PW: LDP for PW signaling

IPv4: LDP as core labeled transport
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/92
3113
MPLS LDP
Module 3
Commands to Troubleshoot LDP Operation

This section provides some basic LDP troubleshooting steps and
commands.
Basic LDP Troubleshooting

The illustration on the adjacent page provides a basic sequence of steps
used to collect information to assist in resolving problems with LDP.
3114
Version 4.0.1

Module 3
Basic LDP Troubleshooting
Is LDP configured for the interface? show running-config

Is LDP enabled on my interface? show mpls interfaces
Is the LDP process running? show processes mpls_ldp
mpls ldp
The process should be in RUN state. No thread should be in mutex for long time.
View the threads with show process thread jid
For targeted sessions over TE tunnels verify
Tunnel head is in show mpls interfaces
Tunnel tail mpls ldp discovery targeted-hello accept is configured
Does LDP have a reachable LDP id?
Displayed in show mpls ldp discovery and show mpls ldp parameter
If the router ID shows as 0.0.0.0 check the configuration
Is the peer session up? show mpls ldp neighbor brief
Needs both udp and tcp connectivity
Check the up time to gauge stability
Configure mpls ldp log neighbor to monitor flaps
Verify IP connectivity in routing table, with ping
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/94
3115
MPLS LDP
Module 3
Additional Considerations
RP or DRP Failover
Even if graceful restart is configured, the LDP session may flap. MPLS
LDP sessions are dependent on the underlying TCP socket between the
peers. When an RP fails over, TCP restart and LDP restart occurs, the
TCP socket is lost resulting in a session flap. With the mpls ldp gracefulrestart command configured, the forwarding state is preserved for a
period of time, while the session is being re-established.
MPLS GR also requires IGP graceful restart to prevent traffic loss. That is,
traffic forwarding will continue while routes are marked stale, and then
restored, as long as communication with the neighboring router is
reestablished within timer limits.
Explicit Router-ID Configuration
The explicit router ID is a known LDP router address. The use of an

interface designation with the configuration of the router ID has been
deprecated. The mpls ldp router-id <loopback> command variant is no
longer valid. Instead use the mpls ldp router-id <ip-addr> command.
Changes to Inbound Label Filtering
Inbound label filtering is used when you have no control over the neighbor
router because it is in a different management domain. Modifying inbound
filters to accept bindings (associated with prefixes) from a neighbor
requires that you reset the MPLS LDP neighbor, because LDP does not
request a resend of bindings previously discarded by an ACL. However,
when altering a filter to reject previously-accepted bindings, it is not
necessary to clear the neighbor connection.
3116
Version 4.0.1

Module 3
Additional Considerations
On RP (DRP) failover
With GR configured, the LDP session may flap

! That is normal behavior
MPLS needs IGP GR to prevent traffic loss
Set the LDP router ID using explicit address configuration

Changes to inbound label filtering ACLs require command
clear mpls ldp neighbor ipv4-address
LDP does not request a resend of binding
s previously
discarded by an ACL
This action not required to transition from accepting to
rejecting a binding
! Just starts discarding
Version 3.9.0a
Version 4.0.1
XMPLST4Module 2/95
3117
MPLS LDP
Module 3
Displaying LDP Operational States

Here are some additional commands to display the operations of LDP.
show mpls ldp backoff Displays session backoff parameters and table Areas: Session
show mpls ldp binding Displays label bindings (local and remote) Areas: Binding,
Forwarding
show mpls ldp
discovery
Displays discovery, hello info for both link & targeted: tx, rx,
params, timers, stats Areas: Discovery, Session
show mpls ldp

discovery
Displays LDP forwarding setup view Areas: Binding,

Forwarding
show mpls ldp

graceful-restart
Displays LDP GR global and per-session info Areas: Session,

GR, Forwarding
show mpls ldp igp

sync
Displays LDP IGP Sync (global + per-intf) info Areas: IGP-Sync,

Routing
show mpls ldp

interface
Displays IPv4 interface info (all known ipv4, def-vrf interfaces)
show mpls ldp

neighbor
Displays LDP peer information: TCP conn, discovery, addresses,

stats, timers, features (GR, NSR, SP) and so on Areas:
Discovery, Session, GR, NSR, Session Protection, Forwarding
(nexthop addr)
show mpls ldp nsr
Displays LDP NSR global and per-session info: sync, stats, status
Areas: NSR, Session/Discovery
Areas: Interface, LDP configuration, IGP Auto-config
show mpls ldp param Displays LDP global params: confg, in-use
System
Areas: Process,
show mpls ldp

summary
Displays LDP summary
show mpls ldp trace
Displays LDP event logging and traces Areas: Debugging
3118
Version 4.0.1
Areas: Scale

Module 3
show mpls ldp backoff
Displays session backoff param + table Areas: Session
show mpls ldp binding
Displays label bindings (local and remote) Areas: Binding, Forwarding
show mpls ldp discovery
Displays discovery, hello info for both link & targeted: tx, rx, params, timers, stats
Areas: Discovery, Session
show mpls ldp discovery
Displays LDP forwarding setup view Areas: Binding, Forwarding
show mpls ldp gr
Displays LDP GR global and per-session info Areas: Session, GR, Forwarding
show mpls ldp igp sync
Displays LDP IGP Sync (global + per-intf) info Areas: IGP-Sync, Routing
show mpls ldp interface
Displays IPv4 interface info (all known ipv4, def-vrf interfaces)

Areas: Interface, LDP configuration, IGP Auto-config
show mpls ldp neighbor
Displays LDP peer information: TCP conn, discovery, addresses, stats, timers,
features (GR, NSR, SP) and so on
Areas: Discovery, Session, GR, NSR, Session Protection, Forwarding (nexthop addr)
show mpls ldp nsr
Displays LDP NSR global and per-session info: sync, stats, status
Areas: NSR, Session and Discovery
show mpls ldp param
Displays LDP global params: confg, in-use
show mpls ldp summary
Displays LDP summary Areas: Scale
show mpls ldp trace
Displays LDP event logging and traces Areas: Debugging
Version 3.9.0a
Version 4.0.1
Areas: Process, System
XMPLST4Module 2/96
3119
MPLS LDP
Module 3
Summary
MPLS LDP
3120
Define the fundamental concepts of LDP
Describe the overall operation of LDP
Describe the operation of LDP on Cisco IOS XR
Describe the Cisco IOS XR MPLS Forwarding Infrastructure
Configure basic LDP plus LDP with feature enhancements on Cisco

IOS XR
Describe the use of LDP in pseudowire signaling
Describe and use LDP troubleshooting command
Version 4.0.1

Module 4
Overview
Description
This module provides information about the operation, configuration,
management, and troubleshooting of Layer 3 Virtual Private Networks for
intranets and extranets.
Objectives
Describe Layer 3 Virtual Private Networks (L3VPNs)
Describe Multiprotocol Border Gateway Protocol (MP-BGP)
Implement, analyze, and examine an MP-BGP configuration
Implement, analyze, and examine a L3VPN intranet configuration
Implement, analyze, and examine a L3VPN extranet configuration
Version 4.0.1
41
Module 4
Layer 3 Virtual Private Network Overview

In this section you cover information about the MPLS Layer 3 Virtual
Private Network (L3VPN) and how it is implemented within Cisco IOS XR
Software.
MPLS L3VPNs
Because privacy is essential for delivering IP services, you need a very
efficient, scalable, and flexible delivery scheme.
The problem with traditional overlay schemes is that they require you to
create tunnels between endpoints. Not only does this limit connectivity, QoS
options, and bandwidth efficiency, it also requires a new network design for
each customer. Adding new services is also a challenge, since you are selling
connections, not networks.
In contrast, leveraging MPLS allows you to build a VPN-based on networks,
not connections. This makes it easy to add valuable services such as content
hosting, or implement IP multicast for multimedia services. MPLS enables
connectionless IP VPNs with multiple service classes and the same privacy
as Frame Relay.
Not only do VPN-aware networks scale to large VPNs and large numbers of
VPNs, it allows you to provision all customer VPNs over a single network,
eliminating per-customer network design.
42
Version 4.0.1

Module 4
Use public IP networks to support private
VoIP
networks
Support secure communications
!
!
!
Hosting
Control route distribution

Prevent spoofing VPN identity
Support IPSec and application level
encryption
Intranet
Multicast
Extranet
Support provisioning scalability for service

providers
!
!
!
Group users and services easily

Support overlapping addressing in
customer networks as defined by
RFC 1918
Per VPN QoS possible
Single point of connectivity for customers
!
!
!
Simpler routing configuration for

customers
Transport independent
Support additional connectivity
" Intranet
" Extranet
Version 4.0.1
43
Module 4
VPN Models
The figures show two different service provider backbones with many
customer sites around the edge.
In the overlay model, VPNs connect customers to each other. Each customer
communicates only with a cloud with a similar alphabetic label (for example,
A to A). The exception is D, which connects to both A and B customer sites.
The connections are similar to emulated leased lines. The customer routers
exchange topology information over emulated lines.
In the peer-to-peer model, the customer router (CE) shares its routing
information with the provider router (PE). The provider network is used
more efficiently to route VPN traffic, based on its own network knowledge.
44
Version 4.0.1

Module 4
VPN Models
Provider
backbone
C
Peer-to-peer model
Provider
backbone
Overlay model
Version 4.0.1
45
Module 4
VPN Topologies
There are several types of VPN topologies that have been developed over
time. Here is a brief description of the three most typical types.
Overlay types
The most common of topology is hub and spoke with a central site connected
to remote sites. Typically, the central site communicates with the remote
sites, and some remote sites may communicate with other remote sites. This
topology is generally used in enterprises with a hierarchical structure, such
as banks, governments, retail outlets, and so on.
Full or partial mesh topologies are used by enterprises with less strict
structures. These topologies are generally determined by traffic flow.
The hybrid topology is typically a blend of hub and spoke with partial mesh.
Peer-to-peer types
These types of topologies may take the form of extranets, where different
companies connect their networks for the purpose of exchanging data, but
with security being of utmost importance.
The central services type is one in which enterprise networks may be
connected for the purpose of sharing some service. Supply chain
management is an example of this type of topology.
Special purpose types
The virtual private dial-up network (VPDN) is usually implemented using

tunneling with PPP through the use of dial-IP lines.
The managed network is one in which a service provider manages a
customers network through the use of its own equipment. The actual
topology may take several forms, but is likely to be of the hub and spoke
variety to connect the networks with a central network management center.
46
Version 4.0.1

Module 4
VPN Topologies
Overlay types:
! Hub and spoke

! Partial or full-mesh
! Hybrid
Peer-to-peer types:
! Extranet; either any-to-any or central services
Special purpose:
! VPDN
! Managed network
Version 4.0.1
47
Module 4
MPLS L3VPN Architecture

The designers of MPLS VPN technology were faced with some routing
requirements:
MPLS/VPN architecture requires peering between routers with VPN

information. Border Gateway Protocol and Multiprotocol BGP are
required
The customer routers (CE) should run standard IP routing software and
not be MPLS VPN-aware
The provider core routers (P) must not carry VPN routes to make the
MPLS VPN solution scalable
The provider edge routers (PE) must support MPLS VPN services and
traditional Internet services
The internal topology of the BGP backbone must be transparent to the

customer
P Router
P routers run only a backbone IGP with other P routers and with PE routers,
exchanging core subnet information. BGP deployment on P routers is not
required for MPLS VPN operation.
PE Router
PE routers peer with CE routers using BGP. The PE routers peer with each
other to facilitate exchange of VPN information.
CE Router
The MPLS VPN backbone should look like a standard corporate backbone to
the CE routers. The CE routers run standard IP routing software and
exchange routing updates with the PE routers that appear as normal routers
in the customer network.
Virtual routing and forwarding instance (VRF)
Overlapping IP addressing is the main obstacle to deploying some VPNs. To

overcome the obstacle, the concept of virtual routing is used. Each physical
VPN router has internal virtual routing and forwarding tables (VRF). The
VRF is made up of a VPN IP routing table and VPN IP forwarding table, so
only customer sites with access to a particular VPN have access to the
information relevant to their VPN.
48
Version 4.0.1

Module 4
MPLS L3VPN Architecture
Routing Requirements
Customer routers (CE routers) run standard IP routing
protocol
Provider edge routers (PE routers) support MPLS L3VPN

and Internet routing
Provider core routers (P routers) have no VPN routes

Peering between CE and PE routers required
! BGP, Static, EIGRP, OSPF, or RIP may be used
Virtual routing and forwarding instance
! Internal to physical routers

! Combination of:
" VPN IP routing table
" VPN IP forwarding table
Version 4.0.1
49
Module 4
Layer 3 VPN General Operation

This section discusses general Layer 3 VPN operation in Cisco IOS XR
Software.
MPLS L3VPN Technology

The MPLS L3VPN router technology generally includes provider (P) and
provider edge (PE) routers. The P and PE routers use the same interior
gateway protocol (IGP).
The PE routers are at the edge of the network. The P routers are typically
the core of the MPLS cloud. The PE routers connect to both the customer
equipment (CE) and P routers. Connectivity to the CE routers is through the
use of a routing protocol, while connectivity to the P routers uses MPLS. The
PE also uses iBGP, but that is not a requirement for the P router, and in
fact, the P router need not know anything about the VPNs in the network.
The P routers may only use the labels to forward traffic in the network.
In some special circumstances, a network may have no P routers at all. The
PE routers may be directly connected and L3VPNs deployed. It is typically
for scalability, as well as other reasons, that P routers are deployed.
410
Version 4.0.1

Module 4
MPLS L3VPN Technology
PE
PE
VPN Backbone IGP
P
P
MP-iBGP Session
PE Routers
Edge routers
Connect to both CE and P routers
!
!
P Routers
In the core of the MPLS cloud
Do not need to run BGP and do not
Use MPLS with P routers

Uses IP with CE routers
need any VPN knowledge
Forward packets by looking

at labels
Distribute VPN information
through MP-BGP to other PE

router using VPN-IPv4 addresses,
extended community, label
P and PE routers share a common IGP
Instructor's Note
Slide animation: starts with picture, PE and P routers headings and P and PE share ; click 1
PE routers bullet 1; click 2 PE routers bullet 2 and sub-bullets; click 3 PE routers last bullet;
click 4 P router bullets 1; click 5 P routers bullet 2; click 6 P routers bullet 3
Version 4.0.1
411
Module 4
Separate Routing Tables at PE

A key piece of VPNs is their security. Security for L3VPNs is about
controlling prefix distribution and keeping routing tables separate. This
means keeping the prefixes that one customer uses separate from any other
customer, and keeping all customer prefixes out of the SPs own routing
information base (RIB).
To accomplish this, the prefixes from each VPN are kept in separate virtual
routing and forwarding (VRF) tables. And the routes used by the SP network
are kept in a separate RIB called the default VRF.
Any routes received from a CE are installed in a VRF. In the illustration,
prefixes received from the CE accessing VPN blue are installed in the VRF
routing table blue. Likewise, the prefixes received from the CE accessing
VPN green are installed in the VRF routing table green. The prefixes may be
received as connected routes, or by using routing protocols, such as eBGP,
Static, RIPv2, EIGRP, or OSPF.
The default VRF contains the routes that are received from IGP
advertisements between P and PE routers.
412
Version 4.0.1

Module 4
Separate Routing Tables at PE
CE
VPN blue
PE
MPLS Backbone IGP (OSPF, ISIS)
VPN green
CE
VRF Routing Table
Default VRF
Routing (RIB) and forwarding
table (FIB) associated with one

or more directly connected sites
(CEs)
Routes the PE receives from CE

routers are installed in the
appropriate VRF routing tables
!
!
VRF routing table blue or

VRF routing table green
Version 4.0.1
Populated by the IGP
within MPLS backbone
PE-to-CE Routing Protocols
eBGP
Static
OSPF
EIGRP
RIPv2
413
Module 4
Virtual Routing and Forwarding Instance

A virtual routing and forwarding instance is the process that associates
interfaces connecting CEs to a VRF. In essence, the interface is made private
because it is part of the VPN and separated from the default RIB. Each VRF
has its own routing protocol contexts and connected prefixes are included.
The CE at the opposite end of the link uses a standard routing protocol to
pass the prefixes it wants advertised in the VPN. When the PE receives the
prefixes, it installs them into the VRF.
The PE advertises the prefixes to all other PEs. It also receives prefixes from
the other PEs, and installs appropriate routes into the VRF. Because the
prefixes are kept separate, customers may use overlapping IP addresses in
their networks without interference.
The PE also installs the SP IGP routes into a default VRF, as discussed
previously.
414
Version 4.0.1

Module 4
Virtual Routing and Forwarding Instance
CE
VPN blue
PE
VPN green
CE
What is a virtual routing and forwarding instance?
!
!
!
!
Associates to one or more interfaces on PE

Privatize an interface
Maintains its own virtual routing and forwarding table (VRF)
VRF has its own context for the routing protocol
" Static, RIP, BGP, EIGRP, OSPF
CE router runs standard routing protocol

PE installs prefixes learned from CE routers into the appropriate VRF
routing tables
Including MP-BGP prefixes learned from VPN partners
VPN customers may use overlapping IP addresses

PE installs the IGP routes in the default VRF
Version 4.0.1
415
Module 4
L3VPN Control Plane

A PE, with configured VPNs, receives routing updates from local CEs and
from remote PEs as part of the control plane process.
The PE installs the prefixes received from the locally connected CE into the
appropriate VRF table. The PE sends routing updates using MP-BGP that
contain the prefixes that were received from the CE to other PEs.
The prefixes received from other PEs through MP-BGP are installed in the
appropriate VRF table, based on an identifier (discussed later in this
module).
The MP-BGP labels received are installed into the MPLS label forwarding
information base (LFIB).
416
Version 4.0.1

Module 4
L3VPN Control Plane
PE
PE
PE installs prefixes into the appropriate VRF routing tables
!
!
Learned from VPN partner CE routers

Learned from VPN partner PE routers through MP-BGP
PE route propagation
!
!
Sending PEs identify each VPN separately

Receiving PEs import only relevant prefixes
PE installs labels into MPLS label forwarding information base (LFIB)
Version 4.0.1
417
Module 4
L3VPN Data Plane

When data flows from the CE to a destination at a remote location, the PE
performs a Forwarding Information Base (FIB) lookup in the VRF associated
with the interface on which the packet was received.
The PE prepends an inner label, often called the VPN label, learned from a
Multiprotocol BGP (MP-BGP) update. The PE adds an outer label
representing the BGP next hop of the next router in the path toward the
destination (generally the source of the MP-BGP update).
Each router in the path swaps the outer label as the packet moves toward
the ultimate destination. As with all MPLS label forwarding, the PE router
immediately preceding the final PE (called the penultimate router) removes
the outer label and forwards the packet to the last PE.
The last PE identifies the label as belonging to a particular VPN route and
interface and forwards the packet to the appropriate CE router.
418
Version 4.0.1

Module 4
L3VPN Data Plane
CE
VPN blue
CE
PE
VPN blue
PE
VPN green
VPN green
CE
CE
Data flow
! For each VPN
Forward data between PE routers
! Deliver to correct interface

! Based on labels in MPLS LFIB
Version 4.0.1
419
Module 4
Multiprotocol BGP Overview

In this section, we discuss some of the details of Multiprotocol BGP
(MP-BGP).
MP-BGP Technology: Control Plane

The BGP multiprotocol reachability attribute is an MP-BGP multiprotocol
extension, currently defined by RFC 2858. The attribute enables BGP to
associate a network layer protocol with the next hop information, and the
network layer protocol with network layer reachability information (NLRI).
The relevant fields in the MP_REACH_NLRI attribute are the label pointing
to the next hop in the core IGP, the VPNv4 route, and the route targets
assigned to the prefixes.
420
Version 4.0.1

Module 4
MP-BGP Technology: Control Plane
3 bytes
8 bytes
Label
RD
4 bytes
8 bytes (each)
10.1.1.0
IPv4
prefix
Route targets
MP_REACH_NLRI attributes
Relevant fields in MP-iBGP update message
Label
VPNv4 route
! Route distinguisher (RD)

! IPv4 address
Route targets (RT)
Instructor's Note
The label in this diagram is only 3 bytes long. The label is usually 4 bytes long. The usual label
consists of 20 bits of label, 3 bits for class of service, 1 stack bit, and 8 bits of time-to-live (TTL).
The picture above does not consider the TTL bits.
Version 4.0.1
421
Module 4
MP-BGP Control Plane: VPNv4 Address

The VPNv4 address is a combination of the IPv4 prefix being advertised and
a unique route distinguisher (RD). The RD is prepended onto the prefix to
make the IPv4 route globally unique, thus allowing customers to use
overlapping addresses as defined by RFC 1918.
Each VRF configured on the PE is associated with an RD for the L3VPN. It
is a Cisco leading practice to use the official service provider (SP)
autonomous system number or an SP-specific official IP address as the RD.
This avoids any conflicts when VPNs are established between multiple
service providers.
422
Version 4.0.1

Module 4
MP-BGP Control Plane: VPNv4 Address
3 bytes
Label
8 bytes
4 bytes
65001:1
10.1.1.0
RD
IPv4
prefix
8 bytes
Route targets
VPNv4
Converts an IPv4 address into a VPNv4 address
! RD is prepended to IPv4 address

! Example: 65001:1:10.1.1.0
Makes IPv4 route globally unique

Each VRF must be associated with an RD at the PE
Version 4.0.1
423
Module 4
MP-BGP Control Plane: Route-Target

The BGP extended community, route target (RT), identifies the VPN to
which the VPNv4 prefix belongs. The route target acts as a VPN identifier.
Every prefix within a VPN has one or more route target identifiers. The
route target is a 64-bit identifier that has the format of <ASN:nn>, where
the ASN is the autonomous system (AS) number and nn is an number
assigned by the administrative authority of the AS. The RT is configured on
the PE.
When the PE receives a routing advertisement from a CE, the PE adds the
assigned RT (one or more) to the MP-BGP advertisement prior to exporting
it to partner PEs.
When a PE receives this MP-BGP update, it determines whether it should
accept and import the VPNv4 prefix by examining the RTs attached to the
prefixes. A VPNv4 prefix may be installed into one or several VRFs on a PE.
During the process of installing the prefix into a VRF, the RD is removed
first.
Again, as in the case of the RD, it is a Cisco leading practice to use the
official service provider (SP) autonomous system number in the RT.
424
Version 4.0.1

Module 4
MP-BGP Control Plane: Route-Target
3 bytes
8 bytes
65001:1
Label
RD
4 bytes
8 bytes
10.1.1.0
65001:2
IPv4
prefix
Route targets
VPNv4
Route-target
! Identifies the VRF for the received VPNv4 prefix

! 8-byte BGP extended community attribute
Each VRF is configured with RTs at the PE
! RT is used to accept or reject prefixes
Version 4.0.1
425
Module 4
MP-BGP Control Plane: Label

When the PE sends the routing update to a partner PE, it looks up the next
hop of that partner in the LFIB and places the applicable label in the
MP-BGP update. The router then assigns an outer MPLS label for the next
router in the path toward the PE target.
PE loopback addresses should not be summarized in core as it may lead to
connectivity breaks.
426
Version 4.0.1

Module 4
MP-BGP Control Plane: Label
3 bytes
8 bytes
50
65001:1
Label
RD
4 bytes
8 bytes
10.1.1.0
65001:2
IPv4
prefix
Route targets
Label for the VPNv4 prefix
! Assigned by PE whose address is the next-hop attribute
PE routers rewrite the next-hop with their own loopback

address
Next-hop-self towards MP-iBGP neighbors by default
! PE addresses used as BGP next-hop must be uniquely known in

the backbone IGP
Version 4.0.1
427
Module 4
MPLS L3VPN Operation

In this section we discuss, with an example, the control and data plane
operation of MPLS Layer 3 VPN.
MPLS L3VPN Control Plane: Step 1

One point of a VPN is, of course, to connect multiple sites for a particular
customer together using the SP network and avoiding the use of multiple
individual links between sites. The customer sites typically share
information about their networks by advertising site prefixes to the other
sites. Thus, the CE advertises its prefixes to the SP PE to which it is
connected. The advertisement triggers a control plane operation for the
routers involved in the VPN connection for this customer.
The first step of that PE control plane operation when it receives the update
from the CE is to assign the RD to the prefixes, creating the VPNv4 address.
Next, it assigns the relevant route targets based on the VRF configuration,
or any applicable route policies.
For the target PE router to know what its destination PE address for these
prefixes is, the sending PE changes the next hop for the prefixes to its own
address, usually the loopback address.
Finally, the PE assigns a MP-BGP label for the relevant VRF or interface to
the customer site.
The MP-BGP update is then assigned an MPLS label for the next hop in the
core and sent on toward that router. The MPLS labels are obtained using the
standard MPLS LDP process and are not shown here.
428
Version 4.0.1

Module 4
MPLS Layer 3 VPN Control Plane: Step 1
MP-iBGP update:
RD:65001:1
Next-hop=PE1
RT=Green, Label=16100
Site 1
10.1.1.0/24
Site 2
CE1
10.1.1.0/24
Next-hop=CE1
CE2
PE1
PE2
MPLS backbone
PE1 receives an IPv4 update from a CE
!Assigns an RD to create a VPNv4 address

!Assigns an RT based on the VRF configuration
!Rewrites next-hop attribute to itself
!Assigns a label based on VRF or interface
PE1 sends MP-iBGP update to other PE routers

Version 3.9.0a
XMPLST4Module 4/22
Instructor's Note
Slide animation: Starts with network drawing; Click 1 1st major bullet appears, followed by text
box under site 1, followed by arrow from CE1 to PE1; click 2 1st minor bullet; click 3 2nd
minor bullet; click 4 3rd minor bullet; click 5 4th minor bullet; click 6 2nd major bullet,
followed by text box containing MP-iBGP update, followed by arrow from PE1 to PE2
Version 4.0.1
429
Module 4

In this continuing illustration, PE2 receives the update and verifies the
route target and the VRF to which it belongs; in this case, green. Once PE2
has determined the VRF, it translates the VPNv4 prefix back into an IPv4
prefix. It installs the prefix into the VRF for this VPN and customer. The PE
updates the VRF table with a label (16100) for the prefix that points to the
egress PE1. Finally, it advertises the prefix to CE2 using the connecting
protocol (eBGP, static, RIP, EIGRP, or OSPF).
430
Version 4.0.1

Module 4
MP-iBGP update:
RD:65001:1
Next-hop=PE1
RT=Green, Label=16100
Site 1
10.1.1.0/24
10.1.1.0/24
Next-hop=PE2
CE1
10.1.1.0/24
Next-hop=CE1
Site 2
CE2
PE1
PE2
MPLS backbone
PE2 receives and determines if RT=green is locally configured VRF
! Translates VPNv4 prefix back into IPv4 prefix

! Installs the IPv4 prefix into the VRF routing table
! Updates the VRF FIB table with label=16100 for 10.1.1.0/24
! Advertises the prefix to CE2
Version 3.9.0a
XMPLST4Module 4/24
Instructor's Note
Slide animation: Starts with network drawing with text box under Site 1 and MP-iBGP update;
Click 1 1st major bullet; click 2 1st minor bullet; click 3 2nd minor bullet; click 4 3rd minor
bullet; click 5 4th minor bullet, followed by text box next to Site 2, followed by arrow from PE2
to CE2
Version 4.0.1
431
Module 4
MPLS L3VPN Technology: Forwarding

Once the control plane is set up, data may flow between sites. For data to
flow both the VRF forwarding table and the default VRF are involved.
In this illustration, an IP packet sent by any device at site 2 attempting to
reach a device on the 10.1.1.0 network at site 1 would be assigned an inner
MP-BGP label by PE2 that tells PE1 to which VRF that packet is destined.
PE2 looks up the BGP next hop (in the illustration, the PE1 loopback IP
address) in the default VRF and determines an MPLS outer label assigned to
the BGP next hop by a P router. In the illustration this is P2 in the core as
the next hop to reach PE1. The labels at P2 and P1 are not shown in the
illustration.
432
Version 4.0.1

Module 4
MPLS L3VPN Technology: Forwarding
Site 2
Site 1
CE1
10.1.1.0/24
10.1.1.0/24
Next-hop=CE1
CE2
P2
P1
PE1
Default VRF
Dest.
Next-hop
PE2
P1
PE2
Default VRF
Dest.
Next-hop
PE1
P2
Label
16075
VRF green forwarding

table
Dest.
Next-hop
10.1.1.0/24 PE1
label: 16100
Label
16025
VRF forwarding table
Default VRF
PE routers store IGP routes
PE routers store VPN routes
Associated labels
Associated labels
Label distributed through LDP
Labels distributed through MP-iBGP
Version 3.9.0a
Version 4.0.1
XMPLST4Module 4/25
433
Module 4
Adding detail to the forwarding example, PE2 imposes two labels on the
packets received from CE2 that have the 10.1.1.0/24 network as the
destination. The packet sent from CE2 for a device with the address of
10.1.1.1 arrives at PE2. PE2 assigns the inner MP-BGP label of 16100 for
the VPN destination as learned from the MP-BGP update for 10.1.1.0/24 and
allocated by PE1.
PE2 then assigns an LDP label of 16025 that represents the LSP path to the
BGP next hop. The BGP next hop is learned from the IGP that is employed
between the P and PE routers. In this example, router P2, which is the next
hop to reach PE1, assigns label 16025 and the packet is sent to P2. At P2,
the label of 16075 is swapped for the label 16025, and the packet sent on to
P1. P1 is the last router prior to the destination PE1 in this LSP or the
penultimate router. P1 removes the top label; an action called penultimate
hop popping (PHP), and sends the remaining packet with the VPN label to
PE1.
When PE1 receives the packet it performs a label, in this case for label
16100. The inner VPN label tells PE1 the packet is destined for 10.1.1.0 in
VRF green. PE1 places the packet on the interface to CE1.
434
Version 4.0.1

Module 4
MPLS L3VPN Technology: Forwarding (Cont.)
Site 2
Site 1
CE1
10.1.1.0/24
16075
16100
10.1.1.1
16025
P1
16100
16100
10.1.1.1
CE2
P2
PE1
10.1.1.1
10.1.1.1
PE2
10.1.1.1
PE2 imposes TWO labels for each packet going to VPN destination
10.1.1.1
Inner label is learned using MP-iBGP
! Corresponds to the VPN address
Outer label is LDP learned and derived from an IGP route
! Represents LSP to BGP next hop address; exit point of VPN route
Outer label is popped at P1 and packet with inner label is delivered to PE1
PE1 examines inner label for VPN assignment
! Verifies corresponding RT; removes inner label; forwards to CE1
Version 3.9.0a
XMPLST4Module 4/27
Instructor's Note
Slide animation: Click 1: textbox 10.1.1.1 from CE2-to-PE2 appears followed by arrow; click 2:
first bullet followed by textbox 10.1.1.1 above PE2; click 3: second bullet followed by 16100 label;
click 4: third bullet followed by 16025 label; click 5: fourth bullet appears; click 6: fifth bullet and
sub-bullet appear
Version 4.0.1
435
Module 4
L3VPN Intranet Configuration

In this section we discuss the configuration steps and commands needed to
create a L3VPN in Cisco IOS XR software.
Configuration Steps
Configuration of VPNs for customers in Cisco IOS XR includes both provider
edge and the core provider routers.
In the core, you define:
Routing protocols: IGP, BGP, MPLS LDP

!
A BGP-free core (P routers) is possible
Forwarding method: MPLS
These are configured on the P routers and the PE routers for the interfaces
into the core.
On the PE routers, you configure:
A VPN definition (VRF)
A routing protocol to the customer premises (CE); the customer

connection protocols may be static, eBGP, RIPv2, EIGRP, or OSPF
A BGP connection from provider edge to provider edge (PE-to-PE) for the
VPN partnership
The relationship between the VPN, BGP, and MPLS
The routing protocols used in the core, typically either OSPF or IS-IS
The customer premises equipment must have a configuration for the routing
protocol to the PE.
Keep in mind that within Cisco IOS XR the key to connecting all the parts of
a VPN on a single PE router is the VRF name. While it is locally significant,
it must always be the same name in the same router. It is also case sensitive.
436
Version 4.0.1

Module 4
Configuration Steps
On the provider edge router (PE):
! Define the VPN by creating a VRF

! Assign the VRF to the interface attached to
customer premises equipment (CE)
" Remove IP address prior
! Create routing protocol relationship to the CE

" Add the VRF under appropriate route protocol
definition
" Define the address family
" Define the routes with the destination IPv4 address
! Create the BGP relationships
" Define the VRF, RD, and address family

" Turn on BGP-to-MPLS connection
" Add appropriate address family to neighbor
On the CE:
! Define the routing relationship to the PE
The VRF names are locally significant
! They must all be the same for a single VPN

definition in the same router
" At all levels of the configuration of the VPN
! Case sensitive
Version 4.0.1
437
Module 4
L3VPN Configuration: VRF

The initial step in the VPN configuration is to define the virtual routing and
forwarding instance (VRF). This is a global configuration; you log in to
configuration mode and add the VRF using the CLI command vrf vrf name.
Address families define the type of protocol that will be handled in the VPN.
In this case, you are configuring for IPv4 unicast traffic. When in VRF
address family configuration mode, add the import and export route target
statements.
The typical next step is to configure the interface leading to the customer
equipment. A note of caution in performing this part of the configuration
any existing IPv4 address assigned to the interface must be removed first.
Cisco IOS XR does not remove the address automatically and the commit
fails with a warning. The warning happens if you attempt to add or remove
an interface with an IP address in a VRF.
After removing any IPv4 address, you again use the vrf vrf name command
in interface configuration mode to assign that interface to a VRF. Remember,
the name must be the same as the VRF previously defined. Once that is
complete, you may add the IPv4 address to the interface.
438
Version 4.0.1

Module 4
L3VPN Configuration: VRF
vrf vrf name
10.1.1.0/24
:router(config)# vrf CE3

:router(config-vrf)# address-family ipv4 unicast
:router(config-vrf-af)# import route-target 65001:6
:router(config-vrf-af)# export route-target 65001:3
CE3
PE3
172.16.130.3
:router(config)# interface gige0/4/0/4

:router(config-if)# vrf CE3
:router(config-if)# ipv4 address 172.16.130.3/24
Configure VRF globally
! Define the address family
" Create the route targets for import and export
Configure VRF on interface to CE
! Must remove any interface IP address before
Version 3.9.0a
XMPLST4Module 4/33
Instructor's Note
Animation: click 1 - Bullet 1; click 2 1st sub-bullet, then its sub-bullet; click 3 top CLI display
and arrow; click 4 2nd major bullet and sub-bullet; click 5 lower CLI display and arrow
Version 4.0.1
439
Module 4
L3VPN Configuration: MP-BGP

The core side of the VPN connection is configured to support the carrying of
the type of traffic that the VPN carries. Support for address families are
configured at the BGP instance level first, to create the required data
structures, such as the VPNv4 BGP table.
Each VPN customer has a VRF definition created that uses the same name
as the VRF defined in global configuration. Within the BGP VRF definition
is a route distinguisher definition and an address family configuration for
the type of traffic that will be in the VPN.
In some instances, such as verifying connectivity to remote CEs, it is
desirable to announce the PE-to-CE interface prefix in MP-BGP. You use the
redistribute connected command to achieve this piece of the
configuration. Alternatively, a network CLI command may be included for
adding local networks, such as a loopback address, which may also be used
for testing purposes.
If the routing protocol between the PE and CE is eBGP, nothing further is
required. However, if any of the other available PE-to-CE routing protocols
are used, then a redistribute command is needed under the address family
configuration in the VRF.
440
Version 4.0.1

Module 4
L3VPN Configuration: MP-BGP
10.1.1.0/24
:router(config)# router bgp 65001

:router(config-bgp)# address-family vpnv4 unicast
CE3
172.16.130.33
PE3
172.16.130.3
:router(config-bgp)# vrf CE3

:router(config-bgp-vrf)# rd 65001:3
:router(config-bgp-vrf)# address-family ipv4 unicast
:router(config-bgp-vrf-af)# redistribute connected
Core network
Define the VPNv4 address family to support IPv4 unicast VPNs

Define the VRF for the customer
!
!
Define a route distinguisher

Define the address family
" Redistribute the PE-to-CE interface for testing

" Define network statements for local networks to be included; loopbacks
Redistribution
!
!
!
Needed for testing connectivity from PE to remote CE

Required for other protocols
Configured in the VRF for the customer
Version 4.0.1
441
Module 4
MP-BGP Extended Community: Site of Origin

If a customer has multiple entry points into the providers network for
redundancy, it may result in a routing loop. This may happen as a result of
redistribution to, and from BGP, in multiple locations. Routing loops are not
good for the network.
In the illustration, a customer connects from the same site to the SP MPLS
network at two points CE1-to-PE1 and CE2-to-PE2. Both CE1 and CE2
send routing updates for the same prefixes to the SP. The SP PE routers
exchange the update. The PEs then forward the update on to their respective
connected CE.
At this point, both CE1 and CE2 have two sets of routes for their own
network a set of local routes and a set learned from the SP. This result
may cause a permanent routing loop, a transitory loop, or suboptimal
routing. The actual effect depends on the CE-to-PE routing protocol, but is
particularly problematic when that protocol is eBGP. EBGP routes are
preferred over IGP, or even iBGP, routes because of their administrative
distance (eBGP = 20, iBGP = 200).
To resolve this issue, you use the BGP extended community attribute of site
of origin (SoO). The attribute is attached to prefixes received from the
customer. In turn, prefixes advertised to the site are filtered out.
Site of Origin (Route Origin Community) is defined in RFC 4360.
Site-of-originBGP extended community attribute that is attached to peer
prefixes when advertised to prevent routing loops; the parameters may be
included in one of two ways:
as-number:nn Autonomous system number defined as
!
2-byte range from 1 to 65535
4-byte range in asplain format from 1 to 4294967295
4-byte range is asdot+ format from 1.0 to 65535.6553
nn 32-bit number
or
ip-address:nn IPv4 address in 32-bit form and a 16-bit number
Asplain format represents all the possible 4-byte AS numbers by decimal
integer notation. Asdot+ format represents the AS numbers using two
integer values joined with a period (.). Asdot format represents a mix of
asplain and asdot+. Cisco does not support asdot format (although the
documentation indicates it does). Asplain, asdot+, and asdot are defined in
IETF RFC 5396.
442
Version 4.0.1

Module 4
MP-BGP Extended Community: Site of Origin
Customer network
Routing update
10.1.1.0/24
CE1
CE2
Routing update
10.1.1.0/24
PE2
PE1
MP-iBGP update
net=10.1.1.0/24
SOO=2:2 RT=2:2
MPLS backbone IGP (OSPF, ISIS)
Prevent routing loops
site-of-origin [ as-number:nn | ip-address:nn ]
Multihomed sites with same SP
Updates not advertised

Configured in the address family submode of the BGP VRF definition
Instructor's Note
Slide animation: 1st bullet, network drawing, routing updates without SoO all show initially; click
1 2nd bullet appears followed by red X emphasizing the advertisements being blocked on the
outbound side when SoO is employed; click 2 3rd bullet appears followed by CLI command.
Version 4.0.1
443
Module 4
L3VPN Configuration: Customer with eBGP

When configuring a BGP protocol connection between the PE and CE, you
configure a customer site eBGP connection in a BGP VRF definition. This
illustration is a continuation of the previous page. Configure a VRF for using
the same name as used in the initial VRF configuration.
eBGP Neighbor Configuration
The neighbor definition has the same format as the definitions for all other
BGP neighbors. For an eBGP definition, you include the remote autonomous
system number. Configure the address family using the address-family
ipv4 command. The address family support is configured to include inbound
and outbound route policies that are a requirement of eBGP neighbor
relationships. Without inbound and outbound route policies for an eBGP
neighbor, BGP updates are neither sent nor received.
The CUSTOMER3 inbound route policy looks like this:
route-policy CUSTOMER3
if destination in(10.1.1.0/24 le 32) then
pass
endif
end-policy
The PASS-ALL outbound route policy looks like this:

route-policy PASS-ALL
pass
end-policy
444
Version 4.0.1

Module 4
L3VPN Configuration: Customer with eBGP
10.1.1.0/24
CE3
172.16.130.33
PE3
172.16.130.3
:router(config-bgp)# vrf CE3

:router(config-bgp-vrf)# neighbor 172.16.130.33
:router(config-bgp-vrf)# remote-as 65003
:router(config-bgp-vrf)# address-family ipv4 unicast
:router(config-bgp-vrf-af)# site-of-origin 65001:3
:router(config-bgp-vrf-af)# route-policy CUSTOMER3 in
:router(config-bgp-vrf-af)# route-policy PASS-ALL out
Configure eBGP routing protocol for CE connection
Define the neighbor in the VRF
! Set the remote autonomous system

! Define the address family
" Define the site of origin to avoid routing loops

" eBGP connections must have route policies defined
Version 4.0.1
445
Module 4
L3VPN Configuration: Customer with Static

When configuring a static route connection between the PE and CE, you use
the router static command.
Configuring the VRF for Static Routes
Configure a VRF for static routing using the same name as used in the
initial VRF configuration and configure the address family using the
address-family ipv4 command. Include the static IP addresses for the
networks that may be reached using the link to the CE in the address
family.
Redistribution into BGP
For MP-BGP to carry prefixes to other sites, add redistribution for the static
routes from the CE to the BGP configuration, as shown in this example:
router bgp 65001
vrf CE3
address-family ipv4 unicast
redistribute connected
redistribute static
446
Version 4.0.1

Module 4
L3VPN Configuration: Customer with Static
10.1.1.0/24
:router(config)# router static

:router(config-static)# vrf CE3
:router(config-static-vrf)# address-family ipv4 unicast
:router(config-static-vrf-af)# 10.33.0.0/16 172.16.130.33
CE3
172.16.130.33
PE3
172.16.130.3
Configure static routing protocol for CE connection
Define the VRF

Define the address family
! Define the prefixes; use
" Next-hop IP address OR

" Physical address (gige0/4/0/4)
Version 4.0.1
447
Module 4
L3VPN Configuration: Customer with RIPv2

When configuring a RIPv2 protocol connection between the PE and CE, use
the router rip command.
Configuring the VRF for RIPv2
Configure a VRF for RIP using the same name as used in the initial VRF
configuration and configure the address family using the address-family
ipv4 command. In RIPv2 configuration, add the interface type going to the
CE. Lastly, redistribute the BGP routes that are received from the other
VPN sites into RIP VRF so they may be advertised to the CE.
Add redistribution for RIP prefixes advertised from the CE to the BGP
configuration, as shown here:
router bgp 65001
vrf CE3
redistribute rip
448
Version 4.0.1

Module 4
L3VPN Configuration: Customer with RIPv2
10.1.1.0/24
CE3
:router(config)# router rip

:router(config-rip)# vrf CE3
:router(config-rip-vrf)# interface pos0/3/0/3
:router(config-rip-vrf-if)# exit
172.16.130.33
PE3
:router(config-rip-vrf)# redistribute bgp 650001
172.16.130.3
Configure RIPv2 routing protocol for CE connection
Define the VRF
! Define the interface connecting the CE

! Redistribute the BGP prefixes
Add the redistribution commands to BGP configuration
Version 4.0.1
449
Module 4
EIGRP Customer Protocol Configurations

In EIGRP, only connected prefixes are redistributed without any default
values for metrics. You are creating a scenario in which IPv4 traffic from a
customer is going to transit the SP core network using a VPN. For prefixes to
be advertised from one end of the VPN to the other, you need to use
redistribution. Thus, you need to set values for the EIGRP metrics.
EIGRP Metrics
The metrics are:
450
BandwidthThis metric is the minimum amount of bandwidth, in

kilobits, to be used. Range is from 1 to 4294967295
DelayThis metric is the amount of delay in transmission, measured in

microseconds that will be tolerated. The valid value range for this metric
is 1 to 4294967295. Delay is configured in 10 microsecond units
ReliabilityThis metric is the likelihood of a successful packet

transmission. Values range from zero (indicating no reliability) to 255
(indicating 100 percent reliability)
LoadingThis metric is the effective bandwidth of this route. Values

range from 1 to 255, with 255 a 100 percent loading, or full use
MTUThe maximum transmission unit is the smallest allowable value

for the route. Range is from 1 to 65535
Version 4.0.1

Module 4
EIGRP Protocol Customer Configurations
10.1.1.0/24
CE3
172.16.130.33
PE3
default-metric bandwidth delay reliability loading mtu
172.16.130.3
EIGRP default metric
- BandwidthMinimum in kilobits; range is 1 to 4,294,967,295

- DelayRoute delay in microseconds; value is 1 to 4,294,967,295
- ReliabilityLikelihood of successful packet transmission; 255 equals 100
percent, 0 equals no reliability
- LoadingEffective bandwidth of the route; value 1 to 255, with 255 equal
to 100 percent
- MTUSmallest allowable value for MTU; range from 1 to 65,535
Needed for any redistribution
- Connected routes can redistributed without default; metric values set to

zero
Version 3.9.0a
Version 4.0.1
XMPLST4Module 4/40
451
Module 4
L3VPN Configuration: Customer with EIGRP

When configuring the EIGRP protocol connection between the PE and CE,
use the router eigrp command followed by an autonomous system number.
Configure a VRF for EIGRP using the same name as used in the initial VRF
configuration and configure the address family using the address-family
ipv4 command.
Assigning Autonomous System Number
An important additional parameter that must be configured on a PE for

support of EIGRP as the PE-to-CE protocol is the identification of the
autonomous system number (ASN). For this VPN to work properly, the ASN
must be the same as the actual ASN of the customers CE device. As
different customers may use different autonomous system numbers, use the
autonomous-system command to set the value in the EIGRP VRF
definition.
Other EIGRP VPN Configuration
To identify the source of routing updates within EIGRP, use the router-id
command. To maintain consistency and linkage for the configuration, the
interface that is used between the PE and the customer router must also be
included in the EIGRP VRF configuration. Use the redistribute bgp
command to include the prefixes received from the other partners in the
VPN.
Add redistribution for EIGRP advertised prefixes received from the CE to

the BGP configuration:
router bgp 65001
vrf CE3
redistribute eigrp 65036
452
Version 4.0.1

Module 4
L3VPN Configuration: Customer with EIGRP
10.1.1.0/24
:router(config)# router eigrp 65003

:router(config-eigrp)# vrf CE3
:router(config-eigrp-vrf)# address-family ipv4
:router(config-eigrp-vrf-af)# autonomous-system 65036
:router(config-eigrp-vrf-af)# router-id 10.3.3.3
:router(config-eigrp-vrf-af)# default-metric 10000 100 255 1 1500
:router(config-eigrp-vrf-af)# interface gig0/4/0/4
:router(config-eigrp-vrf-af)# redistribute bgp 65001
CE3
172.16.130.33
PE3
172.16.130.3
10.3.3.3
Configure EIGRP routing protocol for CE connection
Define the VRF
!
!
!
!
!
!
Define the address family; EIGRP supports only IPv4 and IPv6
Define an autonomous system number for the EIGRP process running
within the VRF
Define the router ID
Define the metric
Define the interface used to reach the CE
Redistribute the relevant BGP prefixes
Version 4.0.1
453
Module 4
L3VPN Configuration: Customer with OSPF

When configuring an OSPF protocol connection between the PE and CE, use
the router ospf command followed by an autonomous system number.
Configuring the VRF for OSPF
Configure a VRF for OSPF using the same name as used in the initial VRF
configuration. OSPF requires the router ID be configured within the VRF.
Use the router-id CLI command. For the prefixes from the partners in the
VPN to reach this customer router, redistribute the BGP prefixes into the
OSPF VRF with the redistribute bgp autonomous-system-number
command (the autonomous-system-number is that of the BGP instance
running on this router).
Configure the Area
Within the VRF, you define the area that will be used for the interface to the
CE, and then configure the interface in the area.
Add redistribution for EIGRP advertised prefixes received from the CE to

the BGP configuration:
router bgp 65001
vrf CE3
redistribute ospf 65001
454
Version 4.0.1

Module 4
L3VPN Configuration: Customer with OSPF
10.1.1.0/24
CE3
172.16.130.33
PE3
:router(config)# router ospf 65001

:router(config-ospf)# vrf CE3
:router(config-ospf-vrf)# router-id 10.3.3.3
:router(config-ospf-vrf)# redistribute bgp 65001
:router(config-ospf-vrf)# area 30
:router(config-ospf-vrf-ar)# interface pos0/3/0/3
172.16.130.3 10.3.3.3
Configure OSPF routing protocol for CE connection

Define the VRF
! Define the router ID

! Redistribute the BGP prefixes into the VRF
! Decide the area for the interface between PE and CE
! Define the interface connecting the CE
Version 4.0.1
455
Module 4
L3VPN Configuration: Core Side

This illustration shows basic sample IGP and MPLS configurations that you
need to define within the PE for the core side.
MPLS Configuration
You turn on MPLS with the MPLS LDP command discussed in an earlier
module in this course. You configure router ID, hello timers, interfaces,
neighbor security, and any other requirements as defined by your operation.
OSPF Configuration
For your OSPF configuration for the core you include such parameters as
router ID, areas, interfaces to be included, and other parameters as may be
required by your operation.
IS-IS Configuration
For your IS-IS configuration for the core you include such parameters as
level type, NSAP ID, interfaces, address families, and other parameters as
may be required by your operation.
456
Version 4.0.1

Module 4
L3VPN Configuration: Core Side
P
10.1.1.0/24
10.1.1.1
CE3
POS0/3/0/1
10.3.3.3
PE3
GigE0/4/0/1
P
10.2.2.2

:router(config-ldp)# discovery hello holdtime 30
:router(config-ldp)# discovery hello interval 25
:router(config-ldp)# interface pos0/3/0/1
:router(config-ldp)# neighbor 10.1.1.1 password secret
:router(config)# router ospf 65001
:router(config-ospf)# router-id 10.3.3.3
:router(config-ospf-ar)# interface pos0/3/0/1
:router(config-ospf-ar)# interface loopback0
:router(config-ospf-ar-if)# passive enable
:router(config)# router isis CORE2
:router(config-isis)# is-type level-2-only
:router(config-isis)# net 49.0002.0000.0000.0033.00
:router(config-isis)# interface gige0/4/0/1
:router(config-isis-if)# address-family ipv4 unicast
:router(config-isis)# interface loopback0
:router(config-isis-if)# passive
:router(config-isis-if)# address-family ipv4 unicast
Examples of configuration of MPLS LDP and IGP for PE core side operations
Version 4.0.1
457
Module 4
L3VPN Configuration: Route Reflector

Route reflectors are a way of scaling the operation of the iBGP protocol such
that the rules of route propagation updates are relaxed. Within the
designated route reflector, iBGP peers are defined as either a client or not.
iBGP Clients
Based on the route reflector update method, the address family VPNv4 is
defined in the neighbor definition. The only neighbors that are defined in
iBGP clients, such as the PEs, are the route reflectors.
Route Reflector
On the route reflector, all neighbors are identified as clients by using the
parameter route-reflector-client command. This command is included in
all the address families that are defined for the particular client. So if you
are creating VPNs, and want the advertisements going to other clients from
the route reflector, you must include the command in the VPNv4 address
family definition as shown in the illustration.
458
Version 4.0.1

Module 4
L3VPN Configuration: Route Reflector
PE: MP-iBGP
PE3
10.3.3.3
RR
:router(config-bgp)# neighbor 10.1.1.1

:router(config-bgp-nbr)# remote-as 65001
:router(config-bgp-nbr)# update-source loopback0
:router(config-bgp-nbr)# address-family vpnv4 unicast
10.1.1.1
PE6
Configure route reflector as neighbor
Define the address family as vpnv4 to indicate support

for VPN addressing
RR: MP-iBGP
PE3
10.3.3.3
RR

:router(config-bgp-nbr-af)# route-reflector-client
10.1.1.1
PE6
Configure neighbor as route reflector client
Define the address family as vpnv4 to indicate support

for VPN addressing
Version 4.0.1
459
Module 4
L3VPN Intranet Verification

In this section we review a variety of commands that will help review,
analyze and resolve issues with the L3VPN intranet configuration
Displaying General VRF Information

Once a VPN is configured, there are several show commands you may use to
see information about a specific VRF or all VRFs. The two commands in the
illustration provide the route distinguisher and route target information.
You also see which address families are included in the VRF, the interface to
the customer location and any policies that may be in place.
These commands provide a good starting place for troubleshooting, as you
can verify between PEs that the RD, RT, and AFI, SAFI information
matches correctly.
Each of the commands offers additional information as indicated by the

following:
:router# show vrf vrf name ?
afi-all
Information for all address families
detail
Detailed information
ipv4
IPv4 information
ipv6
IPv6 information
unresolved
Unresolved VRFs
:router# show vrf vrf name ipv4 ?
460
detail
multicast
Multicast information
safi-all
Information for all sub-address families
unicast
Unicast information
unresolved
Unresolved VRFs
Version 4.0.1

Module 4
:PE3#show vrf CE3

Wed Jul 7 19:33:08.767 UTC
VRF
RD
CE3
65001:3
RT
import
export
65001:6
65001:3
AFI
SAFI
IPV4
IPV4
Unicast
Unicast
:PE3#show vrf CE3 detail

Wed Jul 7 19:33:29.299 UTC
VRF CE3; RD 65001:3; VPN ID not set
Description not set
Interfaces:
POS0/3/0/0
Address family IPV4 Unicast
Import VPN route-target communities:
RT:65001:6
Export VPN route-target communities:
RT:65001:3
No import route policy
No export route policy
No import VPN route-target communities
No export VPN route-target communities
Version 4.0.1
461
Module 4
Displaying VRF Routes

Once the VRF has been configured and is up and active you may review the
prefixes in the specific VRF routing table. The illustration shows the prefixes
in the VRF CE3 on the PE3 router. These prefixes should not appear in the
default VRF.
A set of additional, more specific information is available as shown here:

:router# show route vrf vrf name ?
462
A.B.C.D/length
Network to display information about
afi-all
IPv4 and IPv6 commands
backup
Backup paths
best-local
Best Local
bgp
Border Gateway Protocol (BGP)
connected
Connected
eigrp
Enhanced IGRP
ipv4
IPv4 commands
ipv6
IPv6 commands
isis
ISO IS-IS
local
Local
next-hop
Route next-hop
ospf
Open Shortest Path First (OSPF)
quarantined
looping routes
resolving-next-hop
Next Hop
rip
Routing Information Protocol (RIP)
standby
Display standby information
static
Static routes
summary
Summary of all routes
Version 4.0.1

Module 4
:PE3#show route vrf CE3

Wed Jul 7 19:34:44.829 UTC
Codes: C - connected, S - static, R - RIP, B - BGP
D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area
N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - ISIS, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, su - IS-IS summary null, * - candidate default
U - per-user static route, o - ODR, L - local, G - DAGR
A - access/subscriber
Gateway of last resort is not set
S
B
S
S
B
C
L
B
10.33.0.0/16 [1/0] via 172.16.30.33, 05:19:23

10.66.0.0/16 [200/0] via 10.6.6.6 (nexthop in vrf default), 00:51:58
10.250.0.0/16 [1/0] via 172.16.30.33, 05:19:23
30.0.0.0/16 [1/0] via 172.16.30.33, 05:19:23
172.16.30.0/24 is directly connected, 2d09h, POS0/3/0/0
These routes do not appear in the main routing table (default

VRF)
Version 4.0.1
463
Module 4
Displaying CEF VRF Detail

The Cisco CEF process is embedded in the Cisco IOS XR Software. Some
show commands are available to display the information that CEF
maintains for VPNs. The illustrated command, show cef vrf name detail
displays the prefixes along with next-hop, interface used, and label
information.
Note the imposition of the labels, where one is added by MP-BGP (VPNv4)
and MPLS (LDP) adds one. You can resolve issues with the VPN traffic by
following the labels that determine the path of the packets.
A set of additional, more specific information is available as shown here:

:router# show cef vrf vrf name ?
A.B.C.D/length or X:X::X/length
464
Prefix Mask
Interfaces
Interface information by installed type

and location
adjacency
CEF adjacency status and configuration
bgp-attribute
Display downloaded BGP attributes
detail
Display full information
drops
CEF drop summary
exact-route
Display exact path for source/dest addr

pair
exceptions
CEF exception summary
external
Show CEF information related to CEF

external clients
flags
Interpret any flags in the output
interface
CEF interface status and configuration
ipv4
CEF show commands for IPV4 protocol
ipv6
CEF show commands for IPV6 protocol
non-recursive
Display non-recursive routes only
recursive-nexthop
Display recursive nexthop database
summary
CEF table summary
trace
Show CEF trace data
Version 4.0.1

Module 4

:PE3#show cef vrf CE3 detail
Wed Jul 7 19:34:44.829 UTC
10.66.0.0/16, version 3, internal 0x40040001 (ptr 0x9ccf6a68) [1], 0x0 (0x0), 0x4100 (0x9d4d23e8)
Updated Jul 7 18:42:46.908
Prefix Len 16, traffic index 0, precedence routine (0)
via 10.6.6.6, 3 dependencies, recursive [flags 0x10]
Next-hop, interface,
LDP VPNv4
next hop VRF - 'default', table - 0xe0000000
and label information
next hop 10.6.6.6 via 16006/0/21
next hop 192.168.23.2
PO0/3/0/3
labels imposed {16006 16013}
60.0.0.0/16, version 3, internal 0x40040001 (ptr 0x9ccf6ad8) [1], 0x0 (0x0), 0x4100 (0x9d4d2410)
Updated Jul 7 18:42:46.908
next hop 10.6.6.6 via 16006/0/21
next hop 192.168.23.2
PO0/3/0/3
172.16.30.0/24, version 1, attached, connected, internal 0xc0000c01 (ptr 0x9ccf5e28)
[2], 0x0 (0x9ccc37a0), 0x0 (0x0)
Updated Jul 5 10:29:30.463
local adjacency point2point
Directly connected
via POS0/3/0/0, 4 dependencies, weight 0, class 0 [flags 0x8]
local adjacency
172.16.60.0/24, version 3, internal 0x40040001 (ptr 0x9ccf6c28) [1], 0x0 (0x0), 0x4100 (0x9d4d2438)
Updated Jul 7 18:42:46.908
next hop 10.6.6.6 via 16006/0/21
next hop 192.168.23.2
PO0/3/0/3
Version 4.0.1
465
Module 4
Displaying MPLS Label Detail

The MPLS label table (LIB) displays locally assigned labels. The fields in the
table have the following meanings:
TableIdentity of the MPLS table
LabelLabel number assigned
OwnerApplication that allocated the label
StateOne of the following four label states:
InUseLabel allocated and used by an application
AllocLabel allocated but not yet used by an application
PendLabel was in use by an application that unexpectedly

terminated and label has not been reclaimed
Pend-SLabel was in use by an application, but MPLS LSD

restarted and application has not reclaimed the label
RewriteIndicates whether label rewrite has been initiated
A set of additional more specific information is available as shown here:

:router# show mpls ?
forwarding
Forwarding information
label
Label information
lsd
Label Switching Database
:router# show mpls label ?

range
Show label range
table
Local labels
:router# show mpls label table ?
466
application
Owner application
detail
label
Show a specific label
private
Private information
summary
Summary
Version 4.0.1

Module 4
Displaying MPLS Label Detail
:PE3#show mpls label table detail

Thu Jul 8 12:07:15.236 UTC
Table Label
Owner
----- ------- ---------------------------0
16000
LDP:Active
(IPv4, 'default':4U, 10.1.1.1/32)
0
16001
LDP:Active
(IPv4, 'default':4U, 10.2.2.2/32)
0
16002
LDP:Active
(IPv4, 'default':4U, 192.168.12.0/24)
0
16006
LDP:Active
(IPv4, 'default':4U, 10.6.6.6/32)
0
16013
LDP:Active
(IPv4, 'default':4U, 10.5.5.5/32)
0
16014
BGP-VPNv4:bgp-0
(IPv4, 'CE3':4U, 10.33.0.0/16)
0
16015
BGP-VPNv4:bgp-0
(IPv4, 'CE3':4U, 10.250.0.0/16)
0
16016
BGP-VPNv4:bgp-0
(IPv4, 'CE3':4U, 30.0.0.0/16)
State Rewrite
------ ------InUse Yes
InUse
Yes
InUse
Yes
InUse
Yes
InUse
Yes
InUse
No
InUse
No
InUse
No
Version 4.0.1
467
Module 4
Displaying BGP VRF Information

You use the show bgp vrf vrf name command to display the BGP prefixes
that are stored in BGP for a particular VRF. In the display on the opposite
page you see the prefixes from both CE3 and CE6, which are the VPN
partners.
468
Version 4.0.1

Module 4
:PE3#show bgp vrf CE3

Thu Aug 19 18:56:39.344 UTC
VRF: CE3
========
BGP VRF CE3, state: Active
BGP Route Distinguisher: 65001:3
VRF ID: 0x60000002
BGP router identifier 10.3.3.3, local AS number 65001
Non-stop routing is enabled
BGP table state: Active
Table ID: 0xe0000002
BGP main routing table version 28
BGP NSR Initial initsync version 1 (Reached)
Status codes: s suppressed, d damped, h history, * valid, > best
i - internal, S stale
Origin codes: i - IGP, e - EGP, ? - incomplete
Network
Next Hop
Metric LocPrf Weight Path
Route Distinguisher: 65001:3 (default for vrf CE3)
*>i10.66.0.0/16
10.6.6.6
0
100
0 ?
*> 30.0.0.0/8
172.16.30.33
0
0 65003 i
*> 30.0.0.0/9
172.16.30.33
0
0 65003 i
*> 30.128.0.0/9
172.16.30.33
0
0 65003 i
*>i60.0.0.0/9
10.6.6.6
0
100
0 ?
*>i60.128.0.0/9
10.6.6.6
0
100
0 ?
*>i172.16.60.0/24
10.6.6.6
0
100
0 ?
BGP
prefix
table
Processed 7 prefixes, 7 paths
Version 4.0.1
469
Module 4
Displaying BGP VRF Summary Information

The show bgp summary command typically lists the neighbor
relationships that are established along with numbers of messages and
prefixes received, and up and down status.
The show bgp summary command, by default, shows only the IPv4 BGP
neighbors in the default VRF. To see neighbors in other VRFs, or for other
address families, additional keywords are entered as shown in the example
This display is the same but is limited to the eBGP VRF relationship with
the customer CE router.
470
Version 4.0.1

Module 4
Displaying BGP VRF Summary Information
:PE3#show bgp vrf CE3 summary

Wed Jul 21 17:18:11.144 UTC
VRF ID: 0x60000003
Table ID: 0xe0000003
BGP is operating in STANDALONE mode.
Process
Speaker
Neighbor
172.16.30.33
RcvTblVer
4
bRIB/RIB
4
LabelVer
4
Spk
AS MsgRcvd MsgSent
0 65003
107
104
ImportVer
4
TblVer
4
Version 4.0.1
SendTblVer
4
InQ OutQ Up/Down

0
0 01:41:36
StandbyVer
0
St/PfxRcd
3
471
Module 4
Displaying BGP Address Family Summary Information

The show bgpvpnv4 unicast summary command lists the neighbor
relationships that are established along with message, up and down status,
and numbers of prefixes received for the specific VPN address family.
From this display, you see that all the PEs are defined as neighbors.
However, P1 and P2 are not available because in this configuration they are
not configured as VPNv4 neighbors. PE4 and PE5 are not supplying prefixes,
but five prefixes have been received from PE6, which is expected as that is
the partner in this VPN.
A set of additional, specific information is available here:

:router# show bgp vpnv4 unicast ?
472
advertised
Show advertised routes
attribute-key
Display networks with associated

attribute key indexes
community
Display routes matching the communities
convergence
Test an address family for convergence
dampened-paths
Display paths suppressed due to

dampening
inconsistent-as
Display networks with inconsistent

origin AS
labels
Display routes and their in/out labels
neighbors
Information on TCP and BGP neighbor

connections
nexthops
Show nexthop related information.
nsr
BGP nsr
rd
Display routes with specific route

distinguisher
route-policy
Display networks that match route policy
summary
Summary of BGP neighbor status
vrf
Display routes for a specified VRF
Version 4.0.1

Module 4
Displaying BGP Address Family Summary Information
:PE3#show bgp vpnv4 unicast summary

Fri Aug 20 14:26:56.243 UTC
BGP generic scan interval 60 secs
Table ID: 0x0
BGP scan interval 60 secs
BGP is operating in STANDALONE mode.
Process
Speaker
Neighbor
10.1.1.1
10.2.2.2
10.4.4.4
10.5.5.5
10.6.6.6
RcvTblVer
50
Spk
0
0
0
0
0
bRIB/RIB
50
LabelVer
50
AS MsgRcvd MsgSent
65001
19873
19881
65001
19891
19894
65001
19891
19898
65001
19895
19894
65001
19898
19900
ImportVer
50
TblVer
0
0
50
50
50
Version 4.0.1
SendTblVer
50
StandbyVer
0
InQ OutQ Up/Down St/PfxRcd

0
0
2d22h (NoNeg)
0
0
1d23h (NoNeg)
0
0
1d23h
0
0
0
1w6d
0
0
0 19:14:38
5
473
Module 4
Displaying BGP Address Family Information

The display of the BGP VRF route table based on IPv4 VPN unicast
configuration is displayed using the show bgp vpnv4 unicast command.
In this display, you see the routes that are part of the local VRF, in this case
VRF CE3, and those that are received from the partner in the VPN. Further,
the displays shows the information by route distinguisher, so you can see
what prefixes are received, what the source of those prefixes is, and which
prefixes were chosen as the best path.
Notice the RD 65001:6, which represents the VPN definition on PE6.
474
Version 4.0.1

Module 4

:PE3#show bgp vpnv4 unicast
Wed Jul 7 19:58:46.368 UTC
Network
Next Hop
*> 10.33.0.0/16
172.16.30.33
0
32768 ?
*>i10.66.0.0/16
10.6.6.6
0
100
0 ?
*> 10.250.0.0/16
172.16.30.33
0
32768 ?
*> 30.0.0.0/16
172.16.30.33
0
32768 ?
*>i60.0.0.0/16
10.6.6.6
0
100
0 ?
*> 172.16.30.0/24
0.0.0.0
0
32768 ?
*>i172.16.60.0/24
10.6.6.6
0
100
0 ?
Route Distinguisher: 65001:6
*>i10.66.0.0/16
10.6.6.6
0
100
0 ?
* i
10.6.6.6
0
100
0 ?
*>i60.0.0.0/16
10.6.6.6
0
100
0 ?
* i
10.6.6.6
0
100
0 ?
*>i172.16.60.0/24
10.6.6.6
0
100
0 ?
* i
10.6.6.6
0
100
0 ?
Version 4.0.1
475
Module 4
Displaying BGP Address Family Labels

Using the show bgp vpnv4 unicast labels command you can see what MPBGP labels are assigned to the prefixes. The local prefixes are assigned
labels that are advertised to partners of the VPN. The remote prefixes
advertised by the PE peer router for this VPN have labels assigned by the
remote PE.
476
Version 4.0.1

Module 4

:PE3#show bgp vpnv4 unicast labels
Wed Jul 7 19:59:57.937 UTC
Network
Next Hop
Rcvd Label
Local Label
*> 10.33.0.0/16
172.16.30.33
nolabel
16014
*>i10.66.0.0/16
10.6.6.6
16013
nolabel
*> 10.250.0.0/16
172.16.30.33
nolabel
16015
*> 30.0.0.0/16
172.16.30.33
nolabel
16016
*>i60.0.0.0/16
10.6.6.6
16014
nolabel
*> 172.16.30.0/24
0.0.0.0
nolabel
16003
*>i172.16.60.0/24
10.6.6.6
16015
nolabel
*>i10.66.0.0/16
10.6.6.6
16013
nolabel
* i
10.6.6.6
16013
nolabel
*>i60.0.0.0/16
10.6.6.6
16014
nolabel
* i
10.6.6.6
16014
nolabel
*>i172.16.60.0/24
10.6.6.6
16015
nolabel
* i
10.6.6.6
16015
nolabel
Version 4.0.1
477
Module 4
Displaying BGP Address Family Neighbors

This illustration shows the unicast neighbor with which PE3 has its VPN
relationship. The command was entered for the VPNv4 unicast address
family. You see the numbers of accepted prefixes, the bestpaths, and the
number of denied prefixes.
A complete set of additional, more specific information is available as shown

here:
:router# show bgp vpnv4 unicast neighbors ?
478
A.B.C.D or X:X::X
Neighbor to display information about
detail
missing-eor
Show neighbors that didn't receive EoR

in read-only mode
nsr
Show postit information across

neighbors
performance-statistics
Show performance statistics
standby
Display Standby BGP information
Version 4.0.1

Module 4
Displaying BGP Address Family Neighbors
:PE3#show bgp vpnv4 unicast neighbors

BGP neighbor is 10.6.6.6
Remote AS 65001, local AS 65001, internal link
Description: PE6
Remote router ID 10.6.6.6
BGP state = Established, up for 22:33:04
For Address Family: VPNv4 Unicast

BGP neighbor version 46
Update group: 0.1 (Update Generation Throttled)
Route refresh request: received 2, sent 2
4 accepted prefixes, 4 are bestpaths
Cumulative no. of prefixes denied: 0.
Prefix advertised 5, suppressed 0, withdrawn 0, maximum limit 524288
Threshold for warning message 75%
An EoR was received during read-only mode
Last ack version 46, Last synced ack version 0
Outstanding version objects: current 3, max 5
Connections established 15; dropped 14
Local host: 10.3.3.3, Local port: 55933
Foreign host: 10.6.6.6, Foreign port: 179
Version 4.0.1
479
Module 4
Displaying MPLS Forwarding

As with following the control path information, to see the VPN-specific
information while troubleshooting, use show commands that address the
specific VRF, such as show mpls forwarding vrf vrf name.
In the two illustrations on the opposite page, you see both summary and
detail information about forwarding, labels, interfaces, next-hops, and how
much data has been sent.
A complete set of additional, more specific information is available as shown

here:
:router# show mpls forwarding ?
debug
Include debug information
detail
exact-route
Display exact path for source/dest addr pair
interface
Match outgoing interface
labels
Match label values
prefix
Match destination prefix and mask
private
Include private information
summary
Summarized information
tunnels
Tunnel(s) at head
vrf
Show entries for a VPN Routing/Forwarding instance
:router# show mpls forwarding vrf vrf name ?
480
debug
Include debug information
detail
hardware
Read from hardware
location
Specify a location
no-counters
Skip displaying counters
prefix
Match destination prefix and mask
private
Include private information
Version 4.0.1

Module 4
Displaying MPLS Forwarding
:PE3#show mpls forwarding vrf CE3

Thu Jul 8 13:39:47.522 UTC
Local Outgoing
Prefix
Outgoing
Label Label
or ID
Interface
------ ----------- ------------------ -----------16003 Aggregate
CE3: Per-VRF Aggr[V]
\
CE3
16014 Unlabelled 10.33.0.0/16[V]
PO0/3/0/0
16015 Unlabelled 10.250.0.0/16[V]
PO0/3/0/0
16016 Unlabelled 30.0.0.0/16[V]
PO0/3/0/0
Next Hop
Bytes
Switched
--------------- ------------
172.16.30.33
172.16.30.33
172.16.30.33
:PE3#show mpls forwarding vrf CE3 detail

Thu Jul 8 13:40:02.073 UTC
Local Outgoing
Prefix
Outgoing
Next Hop
Label Label
or ID
Interface
------ ----------- ------------------ ------------ --------------16003 Aggregate
CE3: Per-VRF Aggr[V]
\
CE3
Updated Jul 7 14:11:50.860
16014 Unlabelled 10.33.0.0/16[V]
PO0/3/0/0
172.16.30.33
Updated Jul 7 14:15:21.951
Packets Switched: 0
0
0
0
0
Bytes
Switched
-----------0
0
16015
Unlabelled 10.250.0.0/16[V]
PO0/3/0/0
Updated Jul 7 14:15:21.951
Packets Switched: 0
172.16.30.33
16016
Unlabelled 30.0.0.0/16[V]
PO0/3/0/0
Updated Jul 7 14:15:21.951
Packets Switched: 0
172.16.30.33
Version 4.0.1
481
Module 4
Testing VPN Connectivity

Using access to the PE router, you can test the connectivity of the VPN by
using a ping vrf vrf name command.
Using the traceroute command provides further information about the path
and the labels that the packet takes.
Both of these commands are valuable to resolving issues with any VPN.
You may use an extended ping command for additional help.
482
Version 4.0.1

Module 4
:PE3#ping vrf CE3 10.66.16.66

Thu Jul 8 15:06:39.844 UTC
Sending 5, 100-byte ICMP Echos to 10.66.16.66, timeout is 2 seconds:
!!!!!
:PE3#traceroute vrf CE3 10.66.16.66

Thu Jul 8 15:08:41.329 UTC
Tracing the route to 10.66.16.66
1
2
3
4
192.168.23.2
192.168.12.1
192.168.16.6
172.16.60.66
[MPLS: Labels 16006/16013 Exp 0] 56 msec 6 msec 3 msec

[MPLS: Labels 16003/16013 Exp 0] 3 msec 4 msec 2 msec
[MPLS: Label 16013 Exp 0] 40 msec 6 msec 5 msec
2 msec * 2 msec
Version 4.0.1
483
Module 4
L3VPN Extranet Operation

In this section we examine the creation of a VPN extranet. A VPN extranet
lets you create VPNs for customers and their suppliers, or clients that they
may do business with, outside of their normal network.
Creating Intranet L3VPN

As you have seen in the previous sections, creating an intranet relationship
with other sites of your own operation requires defining:
Virtual routing and forwarding instance (VRF) to separate and secure

the VPN routes from other prefixes
Route distinguisher to provide a unique identity for the VPN prefixes and
to allow for potential overlapping private addresses
Route targets, import and export, which provide an extended MP-BGP

community that may be used to set the identity for and select prefixes
from iBGP advertisements for a particular VPN
The illustration shows the intranets that you created during the last lab and
which we can use as a base for showing how to create extranet VPNs.
_____________________________ Note _________________________
While the illustration on the adjacent page is in black and white, the
configurations (on the presentation slide) are color-coded with PE3 green,
PE4 blue, PE5 red, and PE6 orange to identify the VPNs they use for the
CEs with which they are directly connected.
__________________________________________________________________
Now we want to extend our VPN capability to partners, or other customers
with whom we may do business. Neither the customer nor we want to reveal
all of our networks to each other, but we do want to establish a private
network that benefits us and enhances each others business. It is worth
noting, that in extranet VPNs, the participants must have unique IP
addresses for successful communication. The separation inside the MPLS
L3VPN with the RD, does not remove this end-to-end requirement.
L3VPN Intranet Definitions

Using the bottom illustration, on the next page, to review the intranet
definitions, you see how the export and import statements work to establish
the VPN connectivity between the PE routers.
484
Version 4.0.1

Module 4
Creating Intranet L3VPNs and the Definitions
When creating intranet, we need
VRF definition
Route distinguisher
Export route target
Import route target
VPN definition:
RD: 65001:3
RT: Export 65001:3
Import 65001:6
CE3
CE4
VPN definition:
RD: 65001:5
RT: Export 65001:5
Import 65001:4
PE3
P1
PE5
CE5
PE4
P2
PE6
CE6
VPN definition:
RD: 65001:4
RT: Export 65001:4
Import 65001:5
VPN definition:
RD: 65001:6
RT: Export 65001:6
Import 65001:3
Version 4.0.1
485
Module 4
L3VPN Extranet Definitions

Here is an illustration showing one way to establish extranet VPNs.
However, this option only works if there is no IP address overlap between
the participants. The illustration shows each PE importing all of the routes
from an extranet VPN partner. PE3 is importing all of PE4s CE prefixes and
PE4 is importing all of PE3s CE prefixes. Likewise, PE5 and PE6 do the
same for each other.
Most, if not all, customers do not want to share all of their prefixes with
their extranet partners. The reasons for this may include security or partial
IP address overlap that might create connectivity issues for at least one of
the participants in the extranet VPN.
There are two possible solutions. One is to have separate VRFs with
separate interfaces, or sub-interfaces, for each VPN. However this does not
scale very well. Alternatively, one may set up route policies to control prefix
advertisements.
We examine the use of routing policy to manage the prefix advertisements,
which is the most commonly deployed solution for extranet VPNs.
486
Version 4.0.1

Module 4
L3VPN Extranet Definitions
VPN definition:
RD: 65001:3
RT: export 65001:3
import 65001:6
import 65001:4
CE3
CE4
VPN definition:
RD: 65001:5
RT: export 65001:5
import 65001:4
import 65001:6
PE3
P1
PE5
CE5
PE4
P2
PE6
CE6
VPN definition:
RD: 65001:4
RT: export 65001:4
import 65001:5
import 65001:3
VPN definition:
RD: 65001:6
RT: export 65001:6
import 65001:3
import 65001:5
When creating extranet, import route target of extranet VPN
Version 4.0.1
487
Module 4
L3VPN Extranet Using Route Policy

One recommendation for customers is to create a network that may be used
to share data with the extranet partner.
With the route policy option, you may specifically isolate that particular
customer network and make it available to the extranet partner by adding a
different route target identity to the prefix. The partner does the same, and
then the customer and the partner each imports the prefixes that contain the
new route target designation.
In the illustration, we are showing that a policy would be written on PE3
that assigns a route target of 65001:34 to the particular network on CE3 (not
shown in the picture), and that is designated for use in the extranet
relationship with PE and CE4. A similar policy would be added to PE4, such
that it sets CE4s designated network with a route target of 65001:43.
Then, using import route target statements in the configuration, each side of
the extranet would have access to the designated networks, but not all of the
rest of the networks.
488
Version 4.0.1

Module 4
L3VPN Extranet Using Route Policy
VPN definition:
RD: 65001:3
RT: export 65001:3
import 65001:6
import 65001:43
CE3
PE3
P1
PE5
CE5
PE4
P2
PE6
CE6
Route policy:
Add extcommunity
RT of 65001:34
CE4
VPN definition:
RD: 65001:4
RT: export 65001:4
import 65001:5
import 65001:34
Use route policy to set additional route target for extranet VPN
Apply the policy to the VRF definition for the CE as an export route policy
Version 4.0.1
489
Module 4
L3VPN Extranet Route Policy Configuration

Creating a route policy lets you add an identifier to the prefix, to be used for
the extranet. The extranet partner uses this route target identifier when
they import the prefixes that you want them to use for the business
relationship represented. The partners would use a similar setting so that
you can import the designated prefix from them.
To set the route target, use the set extcommunity rt command. This
command provides the extended community route target parameter with an
identifier for the prefixes to be used by the extranet partner.
The optional parameter, additive, adds the extended community route
target to any already existing route targets that identify this network. If the
everyday operation of your network involves other locations in your intranet
also having access to the network that is used in the extranet, those
locations use the originally assigned RT.
Once the installation is complete, you want to test the connectivity. In this
case, for a successful test to take place from the PE to the remote CE, the
interface between the local CE and the PE must be included in the policy.
Otherwise, the return packet does not have a valid return address to use.
490
Version 4.0.1

Module 4
L3VPN Extranet Route Policy Configuration
set extcommunity rt { rt-extcommunity-set-name | rt-inline-extcommunity-set | parameter }

additive
10.1.103.0/24
:router(config)# route-policy EXTRANET_CE4

:router(config-rpl)# if destination in (10.1.103.0/24) then
:router(config-rpl)# set extcommunity rt(65001:34) additive
:router(config-rpl)# endif
:router(config-rpl)# end-policy
:router(config)#
CE3
PE3
172.16.130.3
Create the route policy to specify a unique route

target for the extranet relationship
! Keyword additive places another RT on prefix
Version 4.0.1
491
Module 4
L3VPN Extranet VRF Configuration

Returning to the VRF you created for the intranet, you add two additional
statements. One of the statements, import route-target 65001:43, imports
the extranet VRF prefixes. The other statement, export route-policy
EXTRANET_CE4, sets the route policy in place.
492
Version 4.0.1

Module 4
L3VPN Extranet VRF Configuration
10.1.103.0/24
:router(config)# vrf CE3

:router(config-vrf-af)#
:router(config-vrf-af)# export route-policy EXTRANET_CE4
:router(config-vrf-af)#
CE3
PE3
172.16.130.3
Add an import statement for the RT of the extranet

partner
Add an export route policy to designate a specific RT

to be imported by extranet partner
Version 4.0.1
493
Module 4
L3VPN Extranet Verification

In this section, you review some of the show commands that may be used to
resolve issues with a L3VPN extranet. Many of the commands are those you
saw earlier in this module, but now show additional information that may be
helpful to problem resolution.

Using the show vrf vrf name command, as you did in the earlier intranet
section, you see the addition of the import route target and the export route
policy.
494
Version 4.0.1

Module 4
:PE3#show vrf CE3

Thu Jul 22 07:47:22.457 UTC
VRF
RD
CE3
65001:3
RT
import
import
export
65001:6
65001:43
65001:3
AFI
SAFI
IPV4
IPV4
IPV4
Unicast
Unicast
Unicast
:PE3#show vrf CE3 detail

Thu Jul 22 07:48:36.438 UTC
VRF CE3; RD 65001:3; VPN ID not set
Description not set
Interfaces:
POS0/3/0/0
Import VPN route-target communities:
RT:65001:6
Import the extranet prefixes
RT:65001:43
Export VPN route-target communities:
RT:65001:3
Use an export route policy to set RT
Export route policy: EXTRANET_CE4
No import VPN route-target communities
No export VPN route-target communities
Version 4.0.1
495
Module 4

In the VRF routing table, you see the addition of the extranet network and
its next hop information.
496
Version 4.0.1

Module 4
:PE3#show route vrf CE3

Wed Jul 7 19:34:44.829 UTC
B
B
B
B
B
B
B
B
B
C
L
B
10.31.13.0/24 [20/0] via 172.16.30.33, 00:28:09

10.31.103.0/24 [20/0] via 172.16.30.33, 00:28:09
10.250.0.0/16 [20/0] via 172.16.30.33, 00:28:09
30.0.0.0/9 [20/0] via 172.16.30.33, 00:28:09
Note the route for the extranet partner now in the VRF CE3
routing table
Version 4.0.1
497
Module 4

In this illustration of the show cef vrf vrf name detail command, you see
prefixes from both the intranet and the extranet displayed. The display has
the same information, such as next hop VRF, next hop address, and next hop
interface address. A key to note is the lack of a label for the LDP assigned to
the extranet prefix. PE4 is the next router in the path and thus PE3 is the
penultimate router in this instance.
498
Version 4.0.1

Module 4

:PE3#show cef vrf CE3 detail
Thu Aug 26 19:34:44.829 UTC
10.31.103.0/24, version 8, internal 0x40040001 (ptr 0x9ccf6fa8) [1], 0x0 (0x0), 0x4000 (0x9d4d2398)
Updated Aug 26 12:23:59.293
local adjacency point2point
next hop 172.16.30.33 via 172.16.30.0/24
local label 16016
next hop 172.16.30.3
PO0/3/0/0
labels imposed {None}
10.41.104.0/24, version 1, internal 0x40040001 (ptr 0x9ccf7408) [1], 0x0 (0x0), 0x4100 (0x9d4d2668)
Updated Aug 26 11:58:46.927
unresolved
labels imposed {16017}
10.66.0.0/16, version 5, internal 0x40040001 (ptr 0x9ccf7018) [1], 0x0 (0x0), 0x4100 (0x9d4d2488)
Updated Aug 25 19:40:36.977
next hop 10.6.6.6 via 16003/0/21
next hop 192.168.13.1
PO0/3/0/1
next hop 192.168.23.2
PO0/3/0/3
Version 4.0.1
499
Module 4

Now when you look at the BGP routes for the VRF, you should see the
extranet partner prefix for the network that is available. Here the prefix
10.41.104.0 is in the BGP route table, and no other prefixes from the CE4
partner are seen. You have isolated the connection to that one network.
In the BGP route table on PE4, you see the prefix from CE3 that is available
for the extranet connection. You do not see any other prefixes from CE3, so
you have isolated access to the single network.
Instructor's Note
If there is time during the lab, you may want to explore creating access from the intranet partner
(CE6) to the extranet partner (CE4).
4100
Version 4.0.1

Module 4


Network
Next Hop
*> 10.31.13.0/24
172.16.30.33
0
0 65003
*> 10.31.103.0/24
172.16.30.33
0
0 65003
*>i10.41.104.0/24
10.4.4.4
0
100
0 65004
*>i10.66.0.0/16
10.6.6.6
0
100
0 ?
*> 10.250.0.0/16
172.16.30.33
0
0 65003
*> 30.0.0.0/9
172.16.30.33
0
0 65003
*>i60.0.0.0/8
10.6.6.6
0
100
0 65006
*>i60.0.0.0/9
10.6.6.6
0
100
0 ?
*>i60.128.0.0/9
10.6.6.6
0
100
0 ?
*>i172.16.60.0/24
10.6.6.6
0
100
0 ?
i
i
i
i
i
i
Extranet partner now visible
! Other prefixes from extranet partner not visible


Network
Next Hop
*>i10.31.103.0/24
10.3.3.3
0
100
0 65003
*> 10.41.14.0/24
172.16.40.44
0
0 65004
*> 10.41.104.0/24
172.16.40.44
0
0 65004
*>i10.55.0.0/16
10.5.5.5
0
100
0 65005
*>i10.250.0.0/16
10.5.5.5
0
100
0 65005
*> 40.0.0.0/9
172.16.40.44
0
0 65004
*>i50.0.0.0/8
10.5.5.5
0
100
0 65005
*>i50.0.0.0/9
10.5.5.5
0
100
0 65005
*>i50.128.0.0/9
10.5.5.5
0
100
0 65005
*> 172.16.40.0/24
0.0.0.0
0
32768 i
i
i
i
i
i
i
i
i
i
Extranet partner visible
! None of other prefixes visible
Version 4.0.1
4101
Module 4

You use the show bgp vpnv4 unicast command to display the prefixes that
are in the BGP route table that are included in the VPNs. As the illustration
shows, the extranet route distinguisher and the prefix available for the
extranet VPN show up, as they should.
You can also see the original prefix (10.41.104.0/24) received from PE4 and
the same prefix installed in the VRF CE3. This proves that the import of the
prefix, defined by the route policy, is working properly.
You may also use the show bgp vpnv4 unicast vrf vrf name to display
information related to individual VPNs. However, the specific route
distinguishers are left out of this output.
4102
Version 4.0.1

Module 4
:PE3#show bgp vpnv4 unicast

Thu Aug 26 13:18:20.907 UTC
*> 10.31.13.0/24
172.16.30.33
0
*> 10.31.103.0/24
172.16.30.33
0
*>i10.41.104.0/24
10.4.4.4
0
100
*>i10.66.0.0/16
10.6.6.6
0
100
*> 10.250.0.0/16
172.16.30.33
0
*> 30.0.0.0/9
172.16.30.33
0
*>i60.0.0.0/8
10.6.6.6
0
100
*>i60.0.0.0/9
10.6.6.6
0
100
*>i60.128.0.0/9
10.6.6.6
0
100
*>i172.16.60.0/24
10.6.6.6
0
100
*>i10.41.104.0/24
10.4.4.4
0
100
*>i10.66.0.0/16
10.6.6.6
0
100
*>i60.0.0.0/8
10.6.6.6
0
100
*>i60.0.0.0/9
10.6.6.6
0
100
*>i60.128.0.0/9
10.6.6.6
0
100
*>i172.16.60.0/24
10.6.6.6
0
100

Connected CE
0
0
0
0
0
0
0
0
0
0
65003
65003
65004
?
65003
65003
65006
?
?
?
i
i
i
i
i
i
Copy created after

import to VRF CE3
Original update
Extranet CE
0 65004 i
0
0
0
0
0
?
65006 i
?
?
?
Intranet CE
Version 4.0.1
4103
Module 4

Use the show bgp vpnv4 unicast labels command to review the labels
assigned by route distinguisher to the prefixes in the BGP label table.
You may also use the show bgp vpnv4 unicast vrf vrf name labels to
display more information related to individual VPNs.
4104
Version 4.0.1

Module 4
:PE3#show bgp vpnv4 unicast labels

Network
Next Hop
Rcvd Label
*> 10.31.13.0/24
172.16.30.33
nolabel
*> 10.31.103.0/24
172.16.30.33
nolabel
*>i10.41.104.0/24
10.4.4.4
16017
*>i10.66.0.0/16
10.6.6.6
16013
*> 10.250.0.0/16
172.16.30.33
nolabel
*> 30.0.0.0/9
172.16.30.33
nolabel
*>i60.0.0.0/8
10.6.6.6
16017
*>i60.0.0.0/9
10.6.6.6
16014
*>i60.128.0.0/9
10.6.6.6
16015
*>i172.16.60.0/24
10.6.6.6
16016
*>i10.41.104.0/24
10.4.4.4
16017
*>i10.66.0.0/16
10.6.6.6
16013
*>i60.0.0.0/8
10.6.6.6
16017
*>i60.0.0.0/9
10.6.6.6
16014
*>i60.128.0.0/9
10.6.6.6
16015
*>i172.16.60.0/24
10.6.6.6
16016

Local Label
16015
16016
nolabel
nolabel
16017
16000
nolabel
nolabel
nolabel
nolabel
The label is not changed

when imported into the VRF
nolabel
nolabel
nolabel
nolabel
nolabel
nolabel
Display labels for VPN prefixes by RD
Version 4.0.1
4105
Module 4

Using access to the PE router, you can test the connectivity of the VPN by
using a ping vrf vrf name command.
Using the traceroute command provides further information about the path
and the labels that the packet takes.
Both commands are valuable to resolving issues with any VPN.
You may use an extended ping command for additional help.
4106
Version 4.0.1

Module 4
:PE3#ping vrf CE3 10.41.104.44

Thu Aug 26 15:06:39.844 UTC
Sending 5, 100-byte ICMP Echos to 10.41.104.44, timeout is 2 seconds:
!!!!!
:PE3#traceroute vrf CE3 10.41.104.44

Thu Aug 26 15:08:41.329 UTC
Tracing the route to 10.41.104.44
1
2
192.168.34.4 [MPLS: Label 16017 Exp 0] 7 msec

172.16.40.44 7 msec * 5 msec
Version 4.0.1
5 msec
3 msec
4107
Module 4
Summary
4108
Describe Layer 3 Virtual Private Networks (L3VPNs)
Describe Multiprotocol Border Gateway Protocol (MP-BGP)
Implement, analyze, and examine an MP-BGP configuration
Implement, analyze, and examine a L3VPN intranet configuration
Implement, analyze, and examine a L3VPN extranet configuration
Version 4.0.1

Module 5
MPLS Inter-AS L3VPN
Overview
Description
This module provides information about the operation, configuration,
management, and troubleshooting of Layer 3 Virtual Private Networks
across different autonomous systems (AS).
Objectives
Describe Inter-AS L3VPNs
Implement an Inter-AS L3VPN configuration
Analyze the Inter-AS L3VPN configuration
Examine the Inter-AS L3VPN operation
Version 4.0.1
51
MPLS Inter-AS L3VPN
Module 5
MPLS Inter-AS L3VPN Overview

In this section you learn about what Inter-AS means, what scenarios are
available for L3VPN connectivity between AS, and some deployment
guidelines.
What is Inter-Autonomous System?

A service provider customer may have sites geographically dispersed, such
as in the US, Asia, Europe, or other parts of the world. Some of the sites
may be connected to the same service provider and other sites may be
connected to different service providers.
The service providers exchange routing information for access to the
networks they maintain for their customers. They may also maintain that
same information for VPN customers to provide seamless VPN connectivity
Inter-AS VPNs may also be referred to as multi-provider VPNs or interprovider VPNs.
Some of the benefits of Inter-AS include:
Quicker geographic service coverage for expansion
Quicker VPN service expansion with new M&A
SP Objectives for Inter-AS VPNs
What is the SP objective (what are we trying to accomplish?) with Inter-AS

VPNs?
An SP wants:
100% or full reachability for all Inter-AS VPNs, including control plane
and data plane
No reachability for VPNs that do not share control and data plane
On the other hand, service providers do not want:
Any separation between Inter-AS VPNs with either control or data

plane
No firewalls, limitations, or sanity checks within an Inter-AS VPN
If an SP has VPN sites in an Inter-AS set up, then the SP has full access to
all the VPN sites, including those in other AS.
52
Version 4.0.1

Module 5
What is Inter-Autonomous System?
Provider 1
RR1
P1
AS 65001
Provider 2
RR2
ASBR1
ASBR2
???
P2
AS 65002
VPN-v4 update::
PE1
PE2
BGP, OSPF, RIPv2

149.27.2.0/24,NH=CE1
CE1
CE2
Customer A
VPN-12
Customer A
VPN-12
149.27.2.0/24
How do provider 1 and provider 2 exchange VPN routes?
Version 4.0.1
53
MPLS Inter-AS L3VPN
Module 5
Inter-AS Deployment Scenarios

Generally there are three (3) options that SPs may use between them to
accomplish the Inter-AS implementation of L3VPNs as outlined in IETF
RFC 4364.
Option ABack-to-back virtual routing and forwarding (VRF) tables.

This implementation creates a VPN between the two AS boundary
routers (ASBR). Refers to section 10A of the RFC
Option BMultiprotocol external BGP (MP-eBGP) connection passing

VPNv4 traffic between the ASBRs. Refers to section 10B of the RFC
Option CMultihop MP-eBGP connection using route reflectors to

maintain routes between VPN endpoints. Refers to section 10C of the
RFC
In the rest of this module you learn about the operation of each of these
options and how to configure them in Cisco IOS XR software.
54
Version 4.0.1

Module 5
Inter-AS Deployment Scenarios
Some options for deploying Inter-AS L3VPN

ASBR2 (PE)
ASBR1 (PE)
Option A - Back-to-back VRFs
P2
P1
AS #1
Option B - MP-eBGP for VPNv4
AS #2
PE1
PE2
Option C - Multihop MP-eBGP between RRs
CE1
CE2
VPN-A
VPN-A
Version 4.0.1
55
MPLS Inter-AS L3VPN
Module 5
Inter-AS Deployment Guidelines

There are several important things to consider when deploying Inter-AS
VPNs.
56
When creating route targets and route distinguishers you should use
your local AS number
When creating end-to-end VPNs, consider using limits on the PEs for
prefixes that may be installed in routing tables. These limits should
include both the BGP routing table and the individual VRFs
When creating Inter-AS connections for VPNs, consider the security

aspects on the ASBRs. Using BGP MD5, BGP filtering, maximum
prefixes accepted and other security measures
When creating Inter-AS VPNs, consider end-to-end quality of service

(QoS) and service level agreements (SLAs) on the ASBRs to manage the
expectations of the customers for response times and data delivery
times
Version 4.0.1

Module 5
Inter-AS Deployment Guidelines
Use AS number in the route target and route

distinguisher
Consider max-prefix limits on PEs
! For both BGP and VRF
Consider security on ASBRs
! BGP MD5, BGP filtering, BGP max-prefix, and

others
Consider an end-to-end QoS or SLA agreement

on ASBRs
Version 4.0.1
57
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option A Operation

In this section you learn details about the operation of each of the MPLS
L3VPN Inter-AS options.
Option A: Back-to-Back VRF

In Inter-AS Option A, the ASBRs appear to be PE or CE to each other. In
the illustration, ASBR P1 is a PE to ASBR P11 and ASBR P11 is a CE to
ASBR P1. From ASBR P11 the opposite is true.
Option A is not very scalable, as each VPN requires its own physical or
logical interface. Thus 1000 VRFs (for Inter-AS) would need 1000
interfaces (physical or logical) on both ASBRs.
In this option, there is no end-to-end MPLS. QoS may be applied to each of
the VPNs.
There are some added problems when dual-homing of an ASBR makes
provisioning worse.
While this is simple implementation, it is not widely deployed.
58
Version 4.0.1

Module 5
Option A: Back-to-Back VRF
P1
P11
P22
P2
AS 65002
AS 65001
PE3
PE55
CE3
CE5
VPN-B
VPN-B
10.52.0.0/16
Customer prefix updates
VPNv4 prefix updates
IGP (IPv4) and LDP updates
eBGP updates in VRF
Version 4.0.1
59
MPLS Inter-AS L3VPN
Module 5
Option A: Establish Back-to-Back VRF

Advertisements generated from the network behind CE3 are sent using the
VPN-B connection with PE3.
PE3 adds the identity information, including the route distinguisher,
65001:11 and the route target, 65001:1. MP-BGP carries the advertisement
as a VPNv4 address family update from the originating PE (PE3) to the
ASBR (P1).
On P1, a VRF is set up and another VRF is set up on P11 in AS 65002. An
interface or sub-interface is then used between the two. The VPN VRF on
each ASBR imports prefixes with route targets that are assigned to VPN-B
within its own AS; in this case P1 imports prefixes with a route target of
65001:15 from its own AS. P11 may be importing prefixes with a route
target of 65002:51.
The ASBRs send the VPNv4 advertisements back into their AS with a
route target they assign, for example 65002:15 as shown. Thus, the
destination PE router, PE55, receives the advertisement, and because it
imports prefixes with the 65002:15 route target, places the prefixes into
the VRF for CE5 and passes those prefixes to CE5. CE5 advertises its
prefixes in the reverse direction to CE3 in the same way.
The route distinguishers are different also, as they reflect the AS number.
Note that because both autonomous systems use MPLS, labels are used to
move the MP-BGP VPNv4 updates between the routers in the path
between originating PE and ASBR. No label is used in the VPN between
the ASBRs at the edge of the AS.
The flow of advertisements from CE5 in AS 65002 to CE3 in AS 65001
means creating similar configuration statements in the respective PE and
ASBR routers.
510
Version 4.0.1

Module 5
Option A: Establish Back-to-Back VRF
VPNv4 update:
RD:65001:15:10.31.13.0/24
NH=PE3
RT=65001:15, Label=(29)!
P1
VPN-B VRF
imports routes
with RT 65001:15!
VPN-B VRF
exports routes
with RT 65002:15!
P11
VPNv4 update:
RD=65002:15:10.31.13.0/24
NH=P11,RT=65002:15
Label=(92)!
P22
P2
AS 65001
PE3
AS 65002
BGP, OSPF, RIPv2
10.31.13.0/24 NH=P1!
CE3
PE55
CE5
BGP, OSPF, RIPv2

10.31.13.0/24,NH=PE55!
BGP, OSPF, RIPv2

10.31.13.0/24,NH=CE3!
VPN-B
VPN-B
10.31.13.0/24!
Control plane operation

VRF to VRF connectivity between ASBRs
! Interface is in a VRF at both ends
Version 3.9.0a
XMPLST4Module 5/10
Instructor's Note
Animation sequence: Click 1 box and arrow, CE3-to-PE3; click 2 box and arrow, PE3 P1;
click 3 box and arrow, P1; click 4 box and arrow P1 P11; click 5 box and arrow, P11;
click 6 box and arrow, P11 PE55; click 7 box and arrow, PE55 to CE5
Version 4.0.1
511
MPLS Inter-AS L3VPN
Module 5
Option A: Back-to-Back VRF Data Flow

In this illustration, you see a workstation attempt to reach a destination,
10.31.13.1, in the network behind CE3.
The CE5 router passes the packet to its SP connection, PE55. PE55 applies
an MP-BGP VPN label, 92 to indicate the packet is destined for the ASBR,
P11. PE55 then adds the LDP label 20 so the packet reaches the next hop
in the path toward the ASBR, P11.
When the packet reaches P11 it is sent over the interface or sub-interface
that connects the VRFs back-to-back. When P1 receives the packet, it
knows the packet is destined for PE3, so it applies the MP-BGP VPN label
29 to the packet and then the label of 30 to reach the next destination in
the path to PE3.
Once the packet reaches PE3 it is sent on to CE3 for delivery to the
destination, 10.31.13.1.
512
Version 4.0.1

Module 5
Option A: Back-to-Back VRF Data Flow
30!
29!
P1
10.31.13.1!
P11
92!
10.31.13.1!
P22
P2
29!
10.31.13.1!
10.31.13.1!
AS 65001
AS 65002
PE3
10.31.13.1!
20!
92!
10.31.13.1!
PE55
CE5
CE3
VPN-B
P1 uses label=30 to
reach PE3
(learned using LDP)!
10.31.13.1!
VPN-B
PE55 uses label=20
to reach P11
(learned using LDP)!
10.31.13.0/24!
Forwarding plane operation

Between ASBRs packets are IP
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/11
513
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option A Configuration

In this section you learn about the steps to configure Inter-AS Option A.
Option A: Back-to-Back VRF Configuration

The configuration for this option has two parts:
514
Configuring the relationship between the ASBRs of each AS

!
Configure the VRF with an address family
Configure the import and export route targets
Configure an interface or sub-interface to include in the VPN
Configure BGP neighbor relationship with the other ASBR and the
route policies that apply
Configuring the VPNv4 in your AS

!
Configure the VRF on the PE connecting to the customer
Configure the import and export route targets
Configure the interface to include the VPN
Version 4.0.1

Module 5
Option A: Back-to-Back VRF Configuration
P1
P11
P22
P2
AS 65001
PE3
2. Configure
and verify
VPNv4
AS 65002
1. Configure and verify

ASBR eBGP
connection with VRF
CE3
PE55
CE5
VPN-B
VPN-B
10.31.13.0/24
eBGP updates in VRF
Version 4.0.1
515
MPLS Inter-AS L3VPN
Module 5
Option A: VPNv4 Configuration

The VRF configuration is locally significant.
In this illustration, a VRF called VPN1-11 is configured on P1. The address
family is defined for IPv4 unicast traffic. The import route target is defined
to accept prefixes with the 65001:12 route target. The export route target
sets the prefixes sent into the AS 65001to have a route target of 65001:21.
On PE3 the VRF would be configured to accept prefixes with a route target
of 65001:21 and send prefixes from this VPN with a route target of
65001:12.
As stated earlier in this module, it is a Cisco Systems, Inc. best practice to
use the local AS number in the route target.
516
Version 4.0.1

Module 5
Option A: VPNv4 Configuration
P1
P11
.1
P2
192.168.1.0
.11
P22
POS0/3/1/2
PE3
Configure import
and export route
targets
AS 65002
AS 65001
CE3
PE55
:router(config)# vrf VPN1-11
CE5
VPN-B
VPN-B
10.31.13.0/24
Configure VRF with route targets
! Configuration on SP 2 P11 similar
Configure route targets on PE to match ASBR
Version 4.0.1
517
MPLS Inter-AS L3VPN
Module 5
Option A: eBGP VRF Configuration

For the eBGP connection to happen between the two ASBRs both the
interface (or sub-interface), and a BGP VRF and neighbor configuration,
must be completed.
In Cisco IOS XR software the IP address of an interface connecting a
PE-CE relationship is configured inside the VRF definition. Remove the IP
address from the POS interface and add the VPN. Then reconfigure the
IPv4 address. Here is an example of configuring the interface:
interface pos0/3/1/2
vrf VPN1-11
ipv4 address 192.168.1.1/24
For the BGP configuration create the VRF (VPN1-11 in the illustration).
Then define the eBGP neighbor as a part of the VPN. Remember that with
Cisco IOS XR software both an inbound and outbound route-policy is
required for any eBGP neighbor relationship defined.
The route policy defined in this illustration is very simple example:
route-policy PASS-ALL
pass
route-policy end
This route policy allows all prefixes to be advertised to and received from
the defined neighbor.
The number of prefixes received from a neighbor may be limited, if needed,
by using the following command:
maximum-prefix maximum [threshold] [warning-only]

!
maximum [threshold] the maximum number of prefixes that area

allowed from a neighbor. The range is from 1 to 4294967295. The
default varies depending on the address family being used; IPv4
unicast has a default of 524,288 prefixes. A warning message is
generated at 75 percent of whatever has been set as the limit.
This command is implemented under the respective address family.
518
Version 4.0.1

Module 5
Option A: eBGP VRF Configuration
P1
P11
.1 192.168.1.0 .11
P2
P22
POS0/3/1/2
AS 65002
AS 65001
PE3
PE55

:router(config-bgp)# vrf VPN1-11
:router(config-bgp-vrf)# rd 65001:111
:router(config-bgp-vrf)# address-family
ip4 unicast
CE3
CE5
:router(config-bgp-vrf)# neighbor 192.168.1.11
:router(config-bgp-vrf-nbr)# remote-as 65002
:router(config-bgp-vrf-nbr)# description ASBR2 in AS 65002
VPN-B :router(config-bgp-vrf-nbr)#
VPN-B
:router(config-bgp-vrf-nbr-af)# route-policy PASS-ALL in
10.31.13.0/24
:router(config-bgp-vrf-nbr-af)# route-policy PASS-ALL out
Configuration on SP 2 P11 similar

Separate VRF configuration between ASBR neighbors
For each VPN
Route policies required on eBGP connections
Policies reflect only VPN1-11 traffic in VRF
Version 4.0.1
519
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option A Verification

In this section you see some of the commands that are helpful in verifying
and analyzing the configuration and its operation.
Option A: Display VPNv4 Prefixes on SP1 ASBR

The show bgp vpnv4 unicast command isolates the prefixes in the BGP
VPNv4 unicast routing information base (RIB). The command presents the
prefix information separated by route distinguisher (RD) for easy
understanding.
In the illustration, you see in P1 prefixes that have been advertised from
both CE3 (10.31.x.x and 30.x.x.x) and CE5 (10.52.x.x and 50.x.x.x). From
this display you can determine that the correct prefixes have reached this
ASBR.
520
Version 4.0.1

Module 5
Option A: Display VPNv4 Prefixes on SP 1 ASBR
P1
P2
PE3
P11
192.168.1.0 .11
.1
P22
AS 65002
AS 65001
:P1# show bgp vpnv4 unicast

PE55
Network
Next Hop
* i10.31.13.0/24
10.3.3.3
0
100
0 65003
CE1
*>i
10.3.3.3
100
0 65003
CE5 0
* i10.31.103.0/24
10.3.3.3
0
100
0 65003
*>i
10.3.3.3
0
100
0 65003
* i30.0.0.0/9
10.3.3.3
0
100
0 65003
*>i VPN-B
10.3.3.3
100
0 65003
VPN-B 0
Route Distinguisher: 65001:111 (default for vrf VPN1-11)
152.12.4.0/24
*>i10.31.13.0/24
10.3.3.3
0
100
0 65003
*>i10.31.103.0/24
10.3.3.3
0
100
0 65003
*> 10.52.0.0/16
192.168.1.11
0 65002
*>i30.0.0.0/9
10.3.3.3
0
100
0 65003
*> 50.0.0.0/9
192.168.1.11
0 65002
*> 50.128.0.0/9
192.168.1.11
0 65002
i
i
i
i
i
i
i
i
?
i
?
?
Version 4.0.1
521
MPLS Inter-AS L3VPN
Module 5
Option A: Display VPNv4 Prefixes on SP 2 ASBR

In this display of Option A VRF table prefixes on P11, once again you see
the expected prefixes advertised. This shows that these prefixes are
correctly being delivered across the VPN created between the two ASBRs.
522
Version 4.0.1

Module 5
Display VPNv4 Prefixes on SP2 ASBR
P1
P2
PE3
P11
192.168.1.0 .11
.1
P22
AS 65002
AS 65001

Network
Next Hop
Metric LocPrf Weight
* i10.52.0.0/16
10.5.5.55
0
100
CE1
*>i
10.5.5.55
0 CE5 100
* i50.0.0.0/9
10.5.5.55
0
100
*>i
10.5.5.55
0
100
* i50.128.0.0/9
10.5.5.55
0
100
VPN-B
*>i
10.5.5.55
0
100
VPN-B
Route Distinguisher: 65002:111 (default for vrf VPN11-1)
152.12.4.0/24
*> 10.31.13.0/24
192.168.1.1
*> 10.31.103.0/24
192.168.1.1
*>i10.52.0.0/16
10.5.5.55
0
100
*> 30.0.0.0/9
192.168.1.1
*>i50.0.0.0/9
10.5.5.55
0
100
*>i50.128.0.0/9
10.5.5.55
0
100
PE55
Path
0
0
0
0
0
0
?
?
?
?
?
?
0
0
0
0
0
0
65001 65003 i
65001 65003 i
?
65001 65003 i
?
?
Version 4.0.1
523
MPLS Inter-AS L3VPN
Module 5
Option A: Display VPNv4 Prefixes on PE

Here the illustration shows you the information in the BGP VPNv4 table
at the PE. Again, the prefixes you want are appearing in the table.
524
Version 4.0.1

Module 5
Option A: Display VPNv4 Prefixes on PE
P1
P11
.1 192.168.1.0 .11
P2
AS 65002
AS 65001
PE3
P22
PE55
:pe55# show bgp vpnv4 unicast
CE5 Weight Path
Network CE3
Next Hop
Metric LocPrf
*>i10.31.13.0/24
10.1.1.11
100
0 65001
*>i10.31.103.0/24
10.1.1.11
100
0 65001
*>i30.0.0.0/9VPN-B
10.1.1.11
100
0 65001
VPN-B
*> 10.52.0.0/16
0
32768 ?
152.12.4.0/24 0.0.0.0
*> 50.0.0.0/9
0.0.0.0
0
32768 ?
*> 50.128.0.0/9
0.0.0.0
0
32768 ?
*>i10.31.13.0/24
10.1.1.11
100
0 65001
* i
10.1.1.11
100
0 65001
*>i10.31.103.0/24
10.1.1.11
100
0 65001
* i
10.1.1.11
100
0 65001
*>i30.0.0.0/9
10.1.1.11
100
0 65001
* i
10.1.1.11
100
0 65001
65003 i
65003 i
65003 I
65003
65003
65003
65003
65003
65003
i
i
i
i
i
i
Version 4.0.1
525
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option B Operation

This section explains the Inter-AS Option B operation.
Option B: MP-eBGP for VPNv4

Option B offers a more scalable solution than Option A. Some of the
reasons for that are:
Only one interface between ASBR routers is required
No VRF configuration on ASBR
Less RIB and FIB memory consumption
Also, no MPLS LDP needs to be running between the ASBRs.

Each of the AS configure their normal VPN operation to carry the intra-AS
VPN traffic.
The ASBRs configure an MP-eBGP neighbor relationship that includes the
VPNv4 address family. Thus the VPN advertisements and traffic move
across the MP-eBGP connection the same as regular unicast traffic.
526
Version 4.0.1

Module 5
Option B: MP-eBGP for VPNv4
P2
P22
P1
P11
AS 65001
LDP
PE4
AS 65002
LDP
PE66
CE6
CE4
VPN-B
VPN-B
10.41.14.0/24!

MP-eBGP updates
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/21
527
MPLS Inter-AS L3VPN
Module 5
Option B: Establish End-to-End VPNv4

The CE4 router advertises the active and available networks that it wants
CE6 in AS 65002 to know. PE4 receives the advertisements and prepends
the RD, 65001:11, sets itself as the next hop, adds the RT and label for the
VPN. Then it passes the advertisement to the other routers in AS 65001.
When the VPNv4 advertisement reaches the ASBR, P2, it is sent over the
eBGP connection to ASBR P22. The MP-BGP label is changed each time
the BGP next hop is changed. BGP rewrites both the next hop and the
VPN label. P22 passes the advertisement to all its neighbors and it
eventually reaches PE66. PE66 has the VPN defined to CE6, so it removes
the RD and other information and passes the advertisement on.
The ASBRs store the prefixes in their BGP and LFIB tables, but the
prefixes do not appear in the RIB. It is possible to apply BGP filtering at
the ASBRs.
BGP is advertising only VPNv4 prefixes and labels. BGP needs an IGP to
resolve the next hop address for the other ASBR. The best practice is to
define a static route between the ASBRs so BGP can recursively resolve
the next hop address.
528
Version 4.0.1

Module 5
Option B: Establish End-to-End VPNv4
VPNv4 update:
RD=65001:11:10.41.14.0/24
NH=PE4
RT=65001:11 Label=(40)!
P2
VPNv4 update:
RD=65001:11:10.41.14.0/24
NH=P22
RT=65001:11 Label=(30)!
P22
P11
P1
AS 65001
LDP
PE4
BGP, OSPF, RIPv2

10.41.14.0/24, NH=CE4!
VPNv4 update:
RD:65001:11:10.41.14.0/24,
NH=P2
RT=65001:11, Label=(20)!
AS 65002
LDP
CE6
CE4
VPN-B
PE66
BGP, OSPF, RIPv2
10.41.14.0/24,
NH=PE66!
VPN-B
10.41.14.0/24!
Control Plane operation

eBGP between ASBRs
Label is MP-BGP label, not LDP
LDP labels in AS networks

Version 3.9.0a
XMPLST4Module 5/23
Instructor's Note
Animation: click 1 box and arrow, CE4-PE4; click 2 box and arrow, PE4-P2; click 3 box
and arrow, P2-P22; click 4 box and arrow, P22-PE66; click 5 box and arrow, PE66-CE6
Version 4.0.1
529
MPLS Inter-AS L3VPN
Module 5
Option B: MP-eBGP with VPNv4 Data Flow

As can be seen in the illustration, a packet is sent from a station in the
network behind CE6. The packet is forwarded to PE66, where the VPNv4
label and LDP label are added. The packet is forwarded across the network
to the ASBR P22.
The ASBR P22 swaps the MP-BGP label used in AS 65002 for a new
MP-BGP label and the packet is forwarded across the eBGP link to the
ASBR P2. At P2 the MP-BGP label is swapped for a label that indicates the
VPN to which the packet is to be delivered. P2 then adds an LDP label for
PE4 and forwards the packet.
Once the packet reaches PE4, the MP-BGP label is removed and the packet
is placed on the link connecting to CE4.
530
Version 4.0.1

Module 5
Option B: MP-eBGP with VPNv4 Data Flow
30!
40!
30!
10.41.14.1!
P2
10.41.14.1!
P22
P11
P1
40!
10.41.14.1!
AS 65001
PE4
LDP
10.41.14.1!
P2 uses MP-BGP
label=40 for VRF and
LDP label=30 to reach
PE4!
AS 65002
20!
10.41.14.1!
20!
30!
10.41.14.1!
LDP
PE66
CE4
CE6
VPN-B
VPN-B
10.41.14.0/24!
10.41.14.1!
PE66 uses MP-BGP

label=30 for VRF and
LDP label=20 to
reach P22!

Between ASBRs packets are MPLS
Version 3.9.0a
XMPLST4Module 5/25
Instructor's Note
Animation: click 1 address & arrow, CE6-PE66; click 2 labels, address, blue text & arrow,
PE66-P11; click 3 label, address, & arrow, P11-P22; click 4 label, address, & arrow, P22-P2;
click 5 blue text, labels, address, & arrow, P2-P1; click 6 label, address, & arrow, P1-PE4;
click 7 address & arrow, PE4-CE4
Version 4.0.1
531
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option B Configuration

In this section you see how to configure Inter-AS Option B in Cisco IOS XR
software.
Option B: MP-eBGP with VPNv4 Configuration

As with Option A, the standard configuration for VPNv4 traffic is
completed in AS 65001.
In each of the ASBRs you configure an eBGP neighbor relationship that
includes VPNv4 traffic. This configuration adds the MP-BGP label to
indicate how the advertised prefix can be reached. No MPLS LDP is
required between the ASBRs.
532
Version 4.0.1

Module 5
Option B: MP-eBGP with VPNv4 Configuration
P22
P2
P1
P11
AS 65001 1. Configure and verify

LDP
ASBR eBGP
PE4
neighbor connection
2. Configure
and verify
VPNv4
AS 65002
LDP
PE66
CE6
CE4
VPN-B
VPN-B
10.41.14.0/24!

MP-eBGP updates
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/27
533
MPLS Inter-AS L3VPN
Module 5
Option B: MP-eBGP with VPNv4 Neighbor Configuration

The configuration for Inter-AS Option B is relatively straightforward.
In BGP you define support for VPNv4 traffic by adding the address family
at the top level of the BGP configuration. In the address family you set the
router to retain the route targets. You do this because route targets are a
BGP extended community that is not carried across an eBGP connection.
You want to keep the route targets for use in the other AS, so use the
command:
retain route-target { all | route-policy route-policy-name }
The options for the command let you pass all prefixes with their route
targets or manage the ones you want using a route policy.
On the ASBR P2 in the illustration, you configure the ASBR of the other
autonomous system as a neighbor supporting VPNv4 traffic. Remember to
configure route policies for both inbound and outbound prefix
advertisements, as this is an eBGP connection.
The route policy applied in this configuration is the same as applied in the
Option A configuration earlier.
534
Version 4.0.1

Module 5
Option B: MP-eBGP with VPNv4 Neighbor Configuration
P2
P22
.2
P1
192.168.2.0 .22
P11
POS0/3/1/2
PE4
Configure
route targets
AS 65001
LDP
AS 65002
LDP
PE66
:router(config-bgp)# address-family vpnv4 unicast
:router(config-bgp-af)# retain route-target all
CE6
CE4

:router(config-bgp-nbr)# description ASBR P22 in AS 65002
vpnv4 unicast
VPN-B:router(config-bgp-nbr)# address-family
VPN-B
:router(config-bgp-nbr-af)# route-policy
PASS-ALL in
152.12.4.0/24
!
:router(config-bgp-nbr-af)#
route-policy PASS-ALL out
BGP forwards only VPNv4 prefixes

Route target
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/28
535
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option B Verification

In this section you examine the BGP tables to verify the configuration and
operation of Inter-AS Option B.
Option B: Display MP-eBGP with VPNv4 Prefixes on SP 1 ASBR

The illustration displays the output from the show bgp vpnv4 unicast
command.
In the ASBR P2 you see the route distinguishers used on each of the PEs,
PE4 in AS 65001 and PE66 in AS 65002. The prefixes are the ones passed
between the two PEs, and ultimately to the CEs.
536
Version 4.0.1

Module 5
P22
P2
.2 192.168.1.0 .22
P1
P11
AS 65002
AS 65001
PE4
PE66
CE6
CE4
VPN-B

152.12.4.0/24
!
Route
Distinguisher:
65001:4
*>i10.41.14.0/24
10.4.4.4
*>i10.41.104.0/24
10.4.4.4
*>i40.0.0.0/9
10.4.4.4
*>i172.16.40.0/24
10.4.4.4
*> 10.62.0.0/16
192.168.2.22
*> 60.0.0.0/9
192.168.2.22
*> 60.128.0.0/9
192.168.2.22
VPN-B
0
100
0
100
0
100
0
100
RD from AS 65002
0
0
0
0
65004 i
65004 i
65004 i
I
0 65002 ?
0 65002 ?
0 65002 ?

Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/30
537
MPLS Inter-AS L3VPN
Module 5

Here is the output from the show bgp vpnv4 unicast command for the
ASBR P22 in AS 65002.
Here you see the same prefixes that were in P2 and the ones you expect to
be passed between PE4 and PE66.
This verifies the correct advertising of prefixes across the eBGP connection.
538
Version 4.0.1

Module 5
P2
P22
.2
P1
192.168.2.0 .22
P11
AS 65002
AS 65001
PE4
PE66
CE6
CE4
:P22# show bgp vpnv4

unicast
VPN-B
Network
Next Hop
10.41.14.0/24
!
*> 10.41.14.0/24
192.168.2.2
*> 10.41.104.0/24
192.168.2.2
*> 40.0.0.0/9
192.168.2.2
*> 172.16.40.0/24
192.168.2.2
*>i10.62.0.0/16
10.6.6.66
*>i60.0.0.0/9
10.6.6.66
*>i60.128.0.0/9
10.6.6.66
VPN-B

RD from AS 65001
0 65001
0 65001
0 65001
0 65001
0
0
0
Version 3.9.0a
Version 4.0.1
100
100
100
65004 i
65004 i
65004 i
I
0 ?
0 ?
0 ?
XMPLST4Module 5/31
539
MPLS Inter-AS L3VPN
Module 5
Option B: Display MP-eBGP with VPNv4 Prefixes on PE

At the PE you see the same prefixes in the VRF table indicating the
prefixes have correctly been advertised from one end of the VPN
relationship to the other across the Inter-AS Option B connection.
Note that other prefixes appear in the VRF for CE6. These prefixes may be
received through another configuration.
540
Version 4.0.1

Module 5
Option B: Display MP-eBGP with VPNv4 Prefixes on PE
P22
P2
.2 192.168.2.0 .22
P1
P11
AS 65002
AS 65001
PE4
PE66
AS Path
CE6
CE4
:pe66# show bgp vpnv4 unicast

Network
Next Hop
* i10.41.14.0/24 VPN-B
192.168.2.2
100
VPN-B 0 65001
* i10.41.104.0/24
192.168.2.2
100
0 65001
152.12.4.0/24
!
* i40.0.0.0/9
192.168.2.2
100
0 65001
* i172.16.40.0/24
192.168.2.2
100
0 65001
*>i10.32.0.0/16
10.3.3.33
0
100
0 ?
*> 10.62.0.0/16
0.0.0.0
0
32768 ?
*>i30.0.0.0/9
10.3.3.33
0
100
0 ?
*>i30.128.0.0/9
10.3.3.33
0
100
0 ?
*> 60.0.0.0/9
0.0.0.0
0
32768 ?
*> 60.128.0.0/9
0.0.0.0
0
32768 ?
65004 i
65004 i
65004 i
i

Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/32
541
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option C Operation

This section provides an explanation of Inter-AS Option C, multihop eBGP
with labeled VPNv4 prefixes between autonomous systems.
Inter-AS Option C was introduced in RFC 2547bis with the purpose of
removing the requirement to hold VPN-specific information on an ASBR.
While Option C provides for the VPN ingress and egress PE routers to
directly connect, that is not scalable.
So Option C was expanded to allow BGP route reflectors (RR) to be used to
improve scalability. This method removes the need for the ASBRs to have
an LFIB because the ASBR does not keep VPNv4 prefix and label
information. PE routers peer with their own RR in their AS and the RRs
peer with each other using multihop MP-eBGP.
Option C: eBGP Multihop with Route Reflectors

In this version of Option C, providers exchange VPNv4 prefixes using route
reflectors and the ASBRs exchange reachability information to establish
the LSP between the PEs in each AS.
The route reflectors in each provider network are peers. The route
reflectors exchange the VPNv4 routes and labels and hold the VPNv4
information. To accomplish this, use eBGP multihop between the RRs. As a
rule BGP changes the label whenever the next-hop changes, so using the
next-hop-unchanged parameter prevents the label changing when the
address is advertised across the AS boundary.
The exchange of PE addresses between the ASBRs occurs in one of two
possible ways:
IGP plus LDP label is redistributed into BGP
IPv4 unicast eBGP plus label
ASBRs do the job of forwarding the VPN packets between each other, and
forwarding MPLS packets within their own AS.
542
Version 4.0.1

Module 5
Option C: eBGP Multihop with Route Reflectors
Reflect
VPNv4
prefixes
RR1
P1
ASBR1
RR2
P2
ASBR2
AS #1
AS #2
PE1
PE2
CE1
CE2
VPN-B
VPN-B
152.12.4.0/24!

eBGP multihop for VPNv4 prefix updates
IPv4 unicast eBGP plus label OR IGP plus label updates
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/35
543
MPLS Inter-AS L3VPN
Module 5
Option C: Next Hop Route Resolution

Service providers exchange IPv4 addresses with labels between directly
connected ASBRs using eBGP. These addresses are typically PE loopback
addresses.
PE loopback addresses exchanged between AS

!
As a general best practice, SPs use their global address space

prefixes for loopback addresses to avoid potential overlap or conflict
with addresses
Route policies control the advertisements over the eBGP neighbor

connection
PE loopbacks are the BGP next-hop addresses of the VPN routes
These PE addresses exchanged are either the IGP plus LDP label or the
iBGP IPv4 address plus LDP label. If the IGP and LDP label is used, you
redistribute the IGP routes and labels into BGP and the BGP prefixes into
the IGP.
You attach a route policy to the redistribute command to manage the
addresses being advertised into the other AS. The addresses may be listed
in the route policy. Another option is to create a prefix-list that contains
only the loopback addresses of the PEs with VPN relationships in the other
providers network. Then you write a route policy to limit outbound
advertisements to the PEs and drop others.
Advertising PE addresses to another AS may not be acceptable to some
providers.
With Cisco IOS XR software, an eBGP peering requires a route policy.
Typically you use the same route policy as used when redistributing the
prefixes.
544
Version 4.0.1

Module 5
Option C: Next Hop Route Resolution
RR2
RR1
P1
AS #1
PE1
IGP+LDP:
NH=PE1
Label=(40)"
ASBR1
ASBR2
eBGP IPv4 update:

NH=ASBR1
Label=(20)"
P2
AS #2
PE2
IGP+LDP:
NH=ASBR2
Label=(30)"
CE1
CE2
VPN-B
VPN-B
152.12.4.0/24"

Addresses of next hops advertised in SP network
!
!
IGP plus LDP label OR

iBGP IPv4 plus LDP label
Addresses of next hops advertised by MP-BGP with labels

Version 3.9.0a
XMPLST4Module 5/37
Instructor's Note
Animation: click 1 first text box, blue arrow, red arrow; click 2 second text box, blue arrow,
red arrow; click 3 third text box, blue arrow, red arrow.
Version 4.0.1
545
MPLS Inter-AS L3VPN
Module 5
Option C: VPNv4 Update Process

With Inter-AS Option C, updates from CE1 are sent directly to the route
reflector from PE1 where the route distinguisher for VPN-B is added. The
route reflector shares the VPNv4 prefixes directly with the route reflector
in AS 65002. The RR in AS 65002 updates PE2, which passes the update
on to CE2.
546
Version 4.0.1

Module 5
Option C: VPNv4 Update Process
VPNv4 update: RD:

65001:11:152.12.4.0/24
NH=PE1
RT=65001:11, Label=(90)!
RR1
VPNv4 update: RD:

65001:11:152.12.4.0/24
NH=PE1
RT=65001:11, Label=(90)!
ASBR1
P1
ASBR2
AS 65001
RR2
VPNv4 update: RD:

65001:11:152.12.4.0/24
NH=PE1
RT=65001:11, Label=(90)!
P2
AS 65002
PE2
PE1
BGP, OSPF, RIPv2
152.12.4.0/24, NH=CE1!
BGP, OSPF, RIPv2

152.12.4.0/24, NH=PE2!
CE1
CE2
VPN-B
VPN-B
152.12.4.0/24!

VPNv4 addresses for VPN-B updates
Version 3.9.0a
XMPLST4Module 5/39
Instructor's Note
Animation: click 1 arrow from CE1 to PE1, text box; click 2 arrow from PE1 to RR1, text
box; click 3 arrow from RR1 to RR2, text box; click 4 arrow from RR2 to PE2, text box;
click 5 arrow from PE2 to CE2, text box
Version 4.0.1
547
MPLS Inter-AS L3VPN
Module 5
Option C: MP-eBGP Multihop Data Flow

The data forwarding in Option C is different than the other options.
In this data flow an IPv4 BGP plus label is included on the packet going
across the ASBR connection. Note in the illustration that the MP-BGP
label is 90, which was added by PE2 in AS 65002 and it remains the same
until reaching PE1 in AS 65001.
In each AS, for the other steps in the path between PE2 and PE1 an LDP
label swap (based on the local MPLS LDP implementation in each AS)
occurs until the penultimate hop, when the LDP label is removed.
548
Version 4.0.1

Module 5
Option C: MP-eBGP Multihop Data Flow
RR1
RR2
P2
P1
40!
90!
90!
152.12.4.1!
ASBR1
152.12.4.1!
ASBR2
30!
AS 65001
PE1
152.12.4.1!
90!
152.12.4.1!
20!
90!
152.12.4.1!
VPN-B
152.12.4.1!
PE2
CE2
CE1
90!
50!
AS 65002
152.12.4.1!
VPN-B
152.12.4.0/24!

MP-BGP label stays the same from PE2-to-PE1
MPLS LDP labels change at each hop until penultimate hop
Version 3.9.0a
XMPLST4Module 5/41
Instructor's Note
Animation: click 1 text box with 152.12.4.1 address, arrow from CE2 to PE2; click 2 text box
with address and MP-BGP (90) and LDP (50) labels, arrow from PE2 to P2; click 3 - text box
with address, MP-BGP and swapped LDP label, arrow from P2 to ASBR2; click 4 - text box with
address and labels, arrow from ASBR2 to ASBR1; click 5 - text box with address and labels, arrow
from ASBR1 to P1, click 6 text box with address and MP-BGP label only, arrow from P1 to
PE1; click 7 text box with address, arrow from PE1 to CE1
Version 4.0.1
549
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option C Configuration

In this section you learn the steps and commands to configure Inter-AS
Option C using route reflectors in Cisco IOS XR software.
Option C: eBGP Multihop Configuration

There are three parts to this configuration of Option C with RRs that must
be implemented:
Exchange of VPNv4 routes

!
Between routers in an AS using a normal route reflector (RR)

configuration
Between different AS RRs
Exchange of labeled IPv4 prefixes on ASBRs to establish an end-to-end

label switch path (LSP)
!
BGP next hops or neighbor AS PE loopbacks
Exchange of BGP next hop prefixes or neighbor AS PE loopback

addresses to other local PEs
!
Using iBGP plus label updates
Using IGP plus labels and redistribution of BGP into the IGP on the
ASBR; this is the least preferred option
The order of configuration for this option includes the following:
550
Configure and verify the eBGP connection between ASBRs. Create RPL
policy to limit advertisements to relevant loopback addresses
Configure and verify the route reflectors connection
Create and verify the PE-to-PE connection
Create and verify the VPN connection
Version 4.0.1

Module 5
Option C: eBGP Multihop Configuration
RR1
2. Configure VPNv4
P1
4. Configure and verify RR

MP-BGP multihop
connection
ASBR1
P2
ASBR2
AS #1
PE1
RR2
AS #2
3. Configure and verify

ASBR eBGP
connection
CE1
VPN-B
PE2
CE2
1. Configure a VRF for
CE and peer with RR
152.12.4.0/24!
VPN-B

IPv4 unicast eBGP plus label OR IGP plus label updates
Version 3.9.0a
XMPLST4Module 5/44
Instructor's Note
Animation: click 1 first text box and arrows; click 2 second text box; click 3 third text box;
click 4 fourth text box
Version 4.0.1
551
MPLS Inter-AS L3VPN
Module 5
Option C: PE Configuration
On the PE a VRF is created for the VPN traffic. The VRF contains the
prefixes advertised by the local CE. When the configuration is completed
the VRF contains the prefixes advertised by the CE from the other AS.
The PE BGP configuration includes the address family VPNv4 unicast for
the VPN traffic. With option C, you configure a neighbor peering with the
route reflector. The configuration includes the IPv4 and VPNv4 unicast
prefixes. In this configuration a neighbor group is used to consolidate the
features.
neighbor-group iBGP
remote-as 65001
update-source loopback0
next-hop self
!
address-family vpnv4 unicast
552
Version 4.0.1

Module 5
Option C: PE Configuration
RR2
RR1
10.1.1.12
10.2.2.12
10.1.1.1
P1
AS 65001
10.1.1.11
ASBR1
10.1.1.2
.1
192.168.1.0
ASBR2
.11
10.2.2.2
10.2.2.1
AS 65002
10.2.2.11
PE1
CE1
VPN-B
152.12.4.0/24!
P2
PE2
CE2

:router(config-bgp)# address-family ipv4 unicast
:router(config-bgp-af)# network 10.1.1.11/32
VPN-B
:router(config-bgp)# address-family vpnv4
unicast
:router(config-bgp-af)#
:router(config-bgp-nbr)# use neighbor-group iBGP
:router(config-bgp-nbr)# description route reflector
BGP IPv4 unicast address family

BGP VPNv4 unicast address family
Route reflector is neighbor to forward VPN prefixes
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/45
553
MPLS Inter-AS L3VPN
Module 5
Option C: Inter-AS Route Reflector Configuration

The configuration of the route reflectors includes the route reflector in the
other autonomous system as a neighbor. Within that neighbor
configuration, the ebgp-multihop command is used to allow the
advertisements to reach beyond the ASBR to the route reflector. The
default value for TTL is 255, indicating the RR could be up to 255 hops
away.
ebgp-multihop [ttl-value]
In this illustration, the update source has been set to Loopback0. In the
route reflector multiple loopback addresses may be defined, one for
internal AS use and the other for external AS use. The external loopback
address is typically an address from the SPs private address space. This
prevents the possibility of duplicate addresses. You use a network
statement in the IPv4 address family definition to define the host address
of the being used as the external address.
Exchanging VPNv4 prefixes between route reflectors in SP networks can
be problematic when a particular RR contains millions of prefixes. One
way to limit the potential for too many prefixes flooding the BGP RIB is to
use an RPL to limit them. In the illustration all prefixes are being passed.
The RR peering between the two AS is an eBGP peering. For that reason,
we add the next-hop-unchanged command to the address family
definition of the RR neighbor. Normally, route reflectors would not change
the next hop attribute by definition. However, because of the eBGP
relationship they would. This command prevents that.
next-hop-unchanged [inheritance-disable]
The inheritance-disable is an optional parameter used whenever you

want to override a next hop that has been set in a neighbor or address
family group.
554
Version 4.0.1

Module 5
Option C: Inter-AS Route Reflector Configuration
RR2
RR1
10..1.12
10.1.1.12
10.2.2.12
10.1.1.1
P1
AS 65001
10.1.1.11
ASBR1
10.1.1.2
.1
192.168.1.0
ASBR2
.11
10.2.2.2
10.2.2.1
AS 65002
10.2.2.11
PE1
P2
PE2
CE1
VPN-B
152.12.4.0/24!

CE2
:router(config-bgp-nbr)# description RR2 in AS 65002
:router(config-bgp-nbr)# ebgp-multihop 255
VPN-B
:router(config-bgp-nbr)# update-source
loopback0
:router(config-bgp-nbr-af)# route-policy PASS-ALL in
:router(config-bgp-nbr-af)# route-policy PASS-ALL out
:router(config-bgp-nbr-af)# next-hop-unchanged
Configuration on RR2 similar

Route policies required on eBGP multihop connections
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/46
555
MPLS Inter-AS L3VPN
Module 5
Option C: RR Local ASBR Client Configuration

You also configure the ASBR as a route reflector client. In this illustration
the definition carries the same elements as the PE-to-RR definition used,
IPv4 and VPNv4 unicast address families.
556
Version 4.0.1

Module 5
Option C: RR Local ASBR Client Configuration
RR2
RR1
10.1.1.12
10.2.2.12
10.1.1.1
P1
AS 65001
10.1.1.11
ASBR1
10.1.11
10.1.1.2
.1
192.168.1.0
ASBR2
.11
10.2.2.2
10.2.2.1
AS 65002
10.2.2.11
PE1
CE1
VPN-B
152.12.4.0/24!
P2
PE2

CE2
:router(config-bgp-nbr)# address-family ipv4 unicast
VPN-B

Configuration on RR2 similar

Neighbor configuration for ASBR
! Address families are IPv4 and VPNv4 unicast

! Same configuration for other neighbors in AS
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/47
557
MPLS Inter-AS L3VPN
Module 5
Option C: Inter-AS eBGP ASBR Configuration

In the configuration of ASBR1 in this illustration, a standard eBGP
neighbor definition is created with ASBR2.
As with all eBGP connections in Cisco IOS XR software, route policies are
required for any prefix advertisements to be passed.
In this example, an outbound route policy that limits the prefixes being
advertised to the PEs that have Inter-AS VPNs is used. The inbound policy
presumes trust of the prefixes being advertised from AS 65002.
Here is a sample of an outbound route policy:
route-policy OPT-C-RTRS-OUT
if destination in VPN-RTRS-OUT then
pass
endif
end-policy
prefix-set VPN-RTRS-OUT
10.1.1.11/32,
10.1.1.12/32
end-set
In our illustration we are distributing the prefixes into the IGP from BGP
and from BGP into the IGP.
The BGP configuration occurs in the address family definition at the router
BGP configuration level:
redistribute ospf lab metric 3333 route-policy OPT-C-RTRS-OUT
allocate-label route-policy OPT-C-RTRS-OUT
Note the use of the route policy to limit the actual prefix advertisements to
those received from certain routers.
The IGP redistribution for OSPF is illustrated here:
router ospf lab
redistribute bgp 65001 route-policy OPT-C-RTRS-IN
The redistribution into the IGP uses a route policy to limit the prefix
advertisements, too. The prefixes in this policy are those received from the
other AS.
558
Version 4.0.1

Module 5
Option C: Inter-AS eBGP Configuration
RR2
RR1
10.1.1.12
10.2.2.12
10.1.1.1
P1
AS 65001
10.1.1.11
ASBR1
10.1.1.2
.1
192.168.1.0
ASBR2
.11
10.2.2.2
10.2.2.1
AS 65002
10.2.2.11
PE1
CE1
VPN-B
152.12.4.0/24!
P2
PE2
CE2
:ASBR1(config)# router bgp 65001
:ASBR1(config-bgp)# neighbor 192.168.1.11
:ASBR1(config-bgp-nbr)# remote-as 65002
VPN-B
:ASBR1(config-bgp-nbr)# description ASBR2 in AS 65002
:ASBR1(config-bgp-nbr)# address-family ipv4 unicast
:ASBR1(config-bgp-nbr)# address-family ipv4 labeled-unicast
:ASBR1(config-bgp-nbr-af)# route-policy PASS-ALL in
:ASBR1(config-bgp-nbr-af)# route-policy OPT-C-RTRS-OUT out
Configuration on SP 2 ASBR similar

Route policies required on eBGP connections
!
!
Inbound policy trusts prefixes sent from ASBR2

Outbound policy limits addresses to RR and PE loopbacks going to AS 65002
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/48
559
MPLS Inter-AS L3VPN
Module 5
Inter-AS Option C Verification

In this section you examine the BGP information on the P, PE, and RR
routers to verify the configuration and operation of Inter-AS Option C.3
Option C: Display ASBR Neighbor

In this display from the ASBR you see the neighbors that support the IPv4
labeled unicast class of prefixes. As the ASBRs are the only routers to
carry these prefix category, you see only the ASBR of AS 65002.
560
Version 4.0.1

Module 5
Option C: Display ASBR Neighbor
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:P1# show bgp ipv4 labeled-unicast summary

Process
Speaker
Neighbor
192.168.1.11
RcvTblVer
5
bRIB/RIB
5
LabelVer
5
Spk
AS MsgRcvd MsgSent
0 65002
100
101
ImportVer
5
TblVer
5
SendTblVer
5
StandbyVer
5
InQ OutQ Up/Down

0
0 01:36:04
St/PfxRcd
2

Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/50
561
MPLS Inter-AS L3VPN
Module 5
Option C: Display ASBR Labeled Unicast Prefixes

Continuing with the IPv4 unicast labeled packets, you see in this
illustration the prefixes that are using labels. The prefixes are all loopback
addresses of routers. They represent the two route reflectors and the two
PEs that are connected for their VPN.
562
Version 4.0.1

Module 5
Option C: Display ASBR Labeled Unicast Prefixes
P22
P2
PE
AS 65001
P1
192.168.1.0
.1
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:P1# show bgp ipv4 labeled-unicast

i - internal, r RIB-failure, S stale
Network
Next Hop
*> 10.2.2.2/32
192.168.12.2
3333
32768 ?
*> 10.2.2.22/32
192.168.1.11
3333
0 65002 ?
*> 10.3.3.3/32
192.168.12.2
3333
32768 ?
*> 10.5.5.55/32
192.168.1.11
3333
0 65002 ?
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/51
563
MPLS Inter-AS L3VPN
Module 5
Option C: Display ASBR Label Information

Following the path of the VPN flow, you use the show cef <prefix/mask>
command to determine the label used to reach one of the prefixes in the
VPN. In this illustration, you see the label 16014 assigned to the next hop
address. The next hop address is the interface address of the connected
ASBR for AS 65002.
564
Version 4.0.1

Module 5
Option C: Display ASBR Label Information
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:P1# show cef 10.5.5.55/32

10.5.5.55/32, version 2, internal 0x40040001 (ptr 0x9d7a0e0c) [1], 0x0 (0x9d12adac),
0x4100 (0x9d97b118)
via 192.168.1.11, 3 dependencies, recursive, bgp-ext [flags 0x20]
path-idx 0
next hop 192.168.1.11 via 16014/0/21
local label 16015
next hop 192.168.1.11/32 PO0/3/1/2
labels imposed {ImplNull 16002}
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/52
565
MPLS Inter-AS L3VPN
Module 5
Option C: Display ASBR Label Forwarding

Following up with a look at the MPLS forwarding label, you see
corroborating information that the 16014 label points the interface address
of the ASBR for AS 65002 as the next hop when trying to reach the host
address (loopback) of PE55.
566
Version 4.0.1

Module 5
Option C: Display ASBR Label Forwarding
P22
P2
PE
AS 65001
P1
192.168.1.0
.1
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:P1# show mpls forwarding label 16014

Local Outgoing
Prefix
Label Label
or ID
------ ----------- -----------------16014 Pop
192.168.1.11/32
Outgoing
Next Hop
Interface
------------ --------------PO0/3/1/2
192.168.1.11
Bytes
Switched
-----------10534
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/53
567
MPLS Inter-AS L3VPN
Module 5
Option C: Display RR VPNv4 Neighbor Information

The route reflectors, in each of the AS, peer so they may pass information
about prefixes used in the connection of the VPN from AS 65001 to
AS 65002.
In this illustration you see the RR in AS 65002 as a peer of the RR in
AS 65001 for VPNv4 prefixes. Note that two prefixes have been received
from the RR in AS 65002.
568
Version 4.0.1

Module 5
Option C: Display RR VPNv4 Neighbor Information
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
:P2# show bgp vpnv4 unicast summary
Process
RcvTblVer
bRIB/RIB
Speaker
6
6
Neighbor
10.1.1.1
10.2.2.22
10.3.3.3
10.4.4.4
10.5.5.5
10.6.6.6
Spk
0
0
0
0
0
0
CE5
LabelVer
6
AS MsgRcvd MsgSent
65001
98
94
65002
95
95
65001
95
96
65001
95
94
65001
0
0
65001
95
95
ImportVer
6
TblVer
0
6
6
0
0
0
SendTblVer
6
StandbyVer
6
InQ OutQ Up/Down St/PfxRcd

0
0 01:32:49 (NoNeg)
0
0 01:31:29
2
0
0 01:31:32
3
0
0 01:32:53 (NoNeg)
0
0 00:00:00 Idle
0
0 01:32:55 (NoNeg)
RR in AS
65002

Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/54
569
MPLS Inter-AS L3VPN
Module 5
Option C: Display RR VPNv4 Unicast Prefixes

Here is an illustration of the prefixes received by the RR in AS 65001 from
the RR in AS 65002. Note the route distinguisher is 65002:55.
570
Version 4.0.1

Module 5
Option C: Display RR VPNv4 Unicast Prefixes
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
Network
Next Hop
*>i10.31.13.0/24
10.3.3.3
0
100
0 65003 i
*>i10.31.103.0/24
10.3.3.3
0
100
0 65003 i
*>i30.0.0.0/9
10.3.3.3
0
100
0 65003 i
*> 10.52.15.0/24
10.5.5.55
0 65002 ?
*> 50.128.0.0/9
10.5.5.55
0 65002 ?
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/55
571
MPLS Inter-AS L3VPN
Module 5
Option C: Display RR VPNv4 Unicast Labels

This illustration shows the labels that are carried with the individual
prefixes being advertised from AS 65002. These labels are the MP-BGP
labels.
572
Version 4.0.1

Module 5
Option C: Display RR VPNv4 Unicast Labels
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:P2# show bgp vpnv4 unicast labels

Network
Next Hop
Rcvd Label
Local Label
*>i10.31.13.0/24
10.3.3.3
16015
nolabel
*>i10.31.103.0/24
10.3.3.3
16019
nolabel
*>i30.0.0.0/9
10.3.3.3
16020
nolabel
*> 10.52.15.0/24
10.5.5.55
16016
nolabel
*> 50.128.0.0/9
10.5.5.55
16016
nolabel
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/56
573
MPLS Inter-AS L3VPN
Module 5
Option C: Display PE VRF

For the prefixes advertised by the PE in AS 65002 to be entered into the
VPN routing table (VRF), they must carry a route target. When the
advertisement arrives at the PE in AS 65001, the intended VRF imports
prefixes with specific route targets.
In this example PE3 is looking for prefixes with the route target 65002:55,
indicating they are from the PE representing our partner CE in the other
AS.
574
Version 4.0.1

Module 5
Option C: Display PE VRF
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
:PE3# show vrf CE3

VRF
CE3
CE5
RD
65001:3
RT
import
import
import
export
AFI
65001:6
65001:43
65002:55
65001:3
IPV4
IPV4
IPV4
IPV4
SAFI
Unicast
Unicast
Unicast
Unicast
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/57
575
MPLS Inter-AS L3VPN
Module 5
Option C: Display PE VRF Prefixes

This illustration shows the prefixes received from the PE in the other AS.
As we saw on the RR there are two prefixes received from the other AS and
you see them in this VRF routing table.
576
Version 4.0.1

Module 5
Option C: Display PE VRF Prefixes
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:PE3# show route vrf CE3

B
B
B
B
B
C
L
10.31.13.0/24 [20/0] via 172.16.30.33, 00:00:44

10.31.103.0/24 [20/0] via 172.16.30.33, 00:00:44
30.0.0.0/9 [20/0] via 172.16.30.33, 00:00:44
172.16.30.0/24 is directly connected, 00:01:33, POS0/3/0/0
172.16.30.3/32 is directly connected, 00:01:33, POS0/3/0/0
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/58
577
MPLS Inter-AS L3VPN
Module 5
Option C: Display PE Label Information

Looking at the PE you may find the label information for a particular
prefix using the show cef vrf vrf name prefix/mask command.
The illustration shows that the prefix entered has a next hop of the
loopback address of the PE in AS 65002 and uses the label 16014.
578
Version 4.0.1

Module 5
Option C: Display PE Label Information
P22
P2
PE
AS 65001
P1
.1
192.168.1.0
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:PE3# show cef vrf CE3 10.52.15.0/24

10.52.15.0/24, version 1, internal 0x40040001 (ptr 0x9cf152f8) [1], 0x0 (0x0),
0x4100 (0x9d6c83e8)
Updated Apr 13 18:18:49.290
path-idx 0
next hop 10.5.5.55 via 16014/0/21
next hop 192.168.34.4/32 PO0/3/0/2
Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/59
579
MPLS Inter-AS L3VPN
Module 5
Option C: Display PE Label Forwarding

Using the show mpls forwarding labels label command provides the
outgoing interface and next hop information for the prefix.
580
Version 4.0.1

Module 5
Option C: Display PE Label Forwarding
P22
P2
PE
AS 65001
P1
192.168.1.0
.1
.11
P11
PE
AS 65002
PE55
PE3
CE3
CE5
:PE3# show mpls forwarding labels 16014

Local
Label
-----16014
Outgoing
Label
----------16014
Prefix
or ID
-----------------10.5.5.55/32
Outgoing
Next Hop
Interface
------------ --------------PO0/3/0/2
192.168.34.4
Bytes
Switched
-----------0

Version 3.9.0a
Version 4.0.1
XMPLST4Module 5/60
581
MPLS Inter-AS L3VPN
Module 5
Summary
MPLS Inter-AS L3VPN
582
Describe Inter-AS L3VPNs
Implement an Inter-AS L3VPN configuration
Analyze the Inter-AS L3VPN configuration
Examine the Inter-AS L3VPN operation
Version 4.0.1

Module 6
MPLS Traffic Engineering
Overview
Description
This module provides information about the operation, configuration, and
management of Multiprotocol Label Switching (MPLS) traffic engineering
(TE) and Fast Reroute (FRR).
Objectives
Describe Cisco MPLS TE and its operation
Discuss MPLS dynamic traffic engineering
Implement, analyze, and examine an MPLS dynamic Cisco MPLS TE

configuration
Implement, analyze, and examine an MPLS explicit Cisco MPLS TE

configuration
Describe Cisco MPLS TE Fast Reroute (FRR) operation
Implement, analyze, and examine an Cisco MPLS TE FRR

configuration
Version 4.0.1
61
Module 6

In this section, you learn what Cisco MPLS TE is, how it resolves problems
and enhances the resources of the network, some of the steps in the
decision to use Cisco MPLS TE, and how it is implemented within Cisco
IOS XR Software.
What is Traffic Engineering?

Cisco MPLS TE enables you to make the best use of your network
resources by directing traffic to available resources such as bandwidth,
thus letting you make use of under utilized links in the network. It enables
you to route traffic more efficiently so that you may offer users better
throughput service and minimize delay and congestion.
Cisco MPLS TE provides you with a methodology for improving fast
convergence, particularly when a path is lost either through link or node
loss. Cisco MPLS TE has a fast reroute capability that typically reroutes
traffic over a backup path in 50 milliseconds (ms) or less.
62
Version 4.0.1

Module 6
What is Traffic Engineering?
Enables the best use of network resources
!Directing traffic to the available resources

!Making use of underutilized links
Enhancing the ability to control traffic
!Avoiding congestion in parts of network
Enabling fast convergence
!Using Fast Reroute (FRR) to achieve sub-second

convergence
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/4
63
Module 6
The Shortest Path Problem

In the case of native IP, traffic follows the shortest path to the destination
based on calculations make by your chosen Interior Gateway Protocol
(IGP) (typically Open Shortest Path First (OSPF) or Intermediate Systemto-Intermediate System (IS-IS)). In your network, the shortest path is
probably not the only path. By following the shortest path, some of the
other paths may be under utilized, even when they may have faster links.
Changing the metric of links diverts all the traffic to the alternate path.
If you can move some of the traffic away from the shortest path calculated
by the IGP to a less congested path, you could control traffic, and use all
the available resources. Cisco MPLS TE provides you a variety of ways,
including explicit routing and setup of explicitly computed label-switched
paths (LSPs).
64
Version 4.0.1

Module 6
The Shortest Path Problem
R3
R8
R4
R5
R2
R1
R6
R7
IP uses shortest path destination-based routing

Shortest path may not be the only path
!May be over utilized
Alternate paths may be under utilized

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/5
65
Module 6
Shortest Path and Congestion

The illustration shows how congestion can occur when the IGP path is
used. In the illustration, traffic from R1, downstream from R2, sends two
traffic flows at the rate of 40 Mbps each. A second traffic source, R8, also
downstream of R2, sends 100 Mbps of traffic. The destination for both
flows is R5. The aggregate of the three flows at R2 is 180 Mbps.
The shortest path from R2 to R5, based on IGP hops (and standard weights
for the links) is to use R3 and R4. However, notice that the links from R2 to
R5 are all OC3 (155 Mbps). Thus, congestion occurs between R2 and R3
and 25 Mbps of traffic must be dropped across that link. The alternate
path, which has sufficient bandwidth, is not being used at all.
66
Version 4.0.1

Module 6
Shortest Path and Congestion
R3
R8
100 Mbps
traffic to R5
180 Mbps
aggregate
R4
OC3
OC3
OC3
R1
R2
OC3
(155 Mbps)
R5
OC3
OC3
OC3
2-40 Mbps
traffic to R5
R6
OC3
R7
Three traffic flows
!R1 to R5 needs two of 40 Mbps

!R8 to R5 needs one of 100 Mbps
Shortest path becomes over utilized

Alternate path is under utilized
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/6
67
Module 6
Why Use Traffic Engineering?

More efficient use of bandwidth resources helps reduce the overall cost of
operations. This, in turn, helps a service provider gain advantage over
competitors. This advantage gains importance as the service provider
market gets more competitive.
More efficient use of bandwidth resources means that a provider may avoid
a situation where some parts of the network are congested, while other
parts are underutilized.
You can use Cisco MPLS TE to load share as part of resource utilization,
by overriding the shortest path selected by your IGP and moving traffic
along a path other than the shortest path chosen by the IGP. Using Cisco
MPLS TE, you can route the critical traffic onto preferred paths, and you
can include or exclude some links from being available to some types of
traffic.
You can use Cisco MPLS TE to help handle network failures by routing
around them. And when those links are available again, you can have
Cisco MPLS TE restore the traffic to the links non-disruptively. And when
new links become available, you can re-optimize the traffic on these more
optimal paths.
TE supports quality of service (QoS) and you may configure it to ensure the
best path for certain traffic types through the use of policies.
68
Version 4.0.1

Module 6
Why Use Traffic Engineering?
Load share
! Override the shortest path selected by the IGP
" Move traffic along path other than IGP shortest path
" Allow critical traffic paths to have preferred paths
" Include or exclude particular links for certain traffic
Handle failures
! Route around network failures

! Re-optimize on restored (or new) links non-disruptively
Support quality of service
! Ensure the desirable path for certain traffic types based on

certain policies
Reduce high cost of network assets
! Promote efficiency
! Reduce costs
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/7
69
Module 6
Traffic Engineering Decision

To make a clear decision how Cisco MPLS TE may help your network,
there are several points you must consider:
610
Collecting information understand what the traffic patterns in your

network are. You can do this by collecting metrics, such as link
utilization
Defining traffic categories define the type of traffic in your network,

such as voice, video, file transfer, email, and others. Then create
categories for each of the important types of traffic
Modeling traffic model the traffic in your network to determine the

patterns. Determine the most prevalent category of traffic and when it
appears in the network. Then, determine the same information for the
other categories of traffic you have defined
Placing traffic where you want it build your Cisco MPLS TE tunnels
to utilize the paths and bandwidth in your network in the way that best
works
Utilizing FRR configure links to be protected using alternate paths

when a link in the tunnel path is lost
Version 4.0.1

Module 6
Traffic Engineering Decision
What is the basis of a TE decision?
Collecting metrics
!Measuring utilization
Defining traffic categories

Modeling traffic to understand traffic patterns
Placing traffic where you want it
Utilizing FRR
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/8
611
Module 6
A Traffic Engineering Solution

Using MPLS labels, you can set explicit paths for the traffic. Using the
same requirements as in the last illustration, you might engineer a path
that would take the 2 40 Mbps traffic over the path R1-R2-R3-R4-R5, the
normal path. You might create a second path, R8-R2-R6-R7-R4-R5, to carry
the 100 Mbps traffic.
You are now taking advantage of Cisco MPLS TE to use the resources
available and accommodate customer traffic needs. However, note that the
link from R4 to R5 is still congested. This can only be resolved by
increasing the bandwidth.
612
Version 4.0.1

Module 6
A Traffic Engineering Solution
R3
R8
100 Mbps traffic

to R8 from R5
100 Mbps
traffic to R5
R4
OC3
R2
OC3
R1
OC3
2-40 Mbps
traffic to R5
OC3
R5
OC3
OC3
80 Mbps traffic
to R1 from R5
R6
OC3
R7
MPLS labels can be used to engineer explicit paths

Tunnels are unidirectional
Normal path: R8 ! R2 ! R3 ! R4
Tunnel path: R1 ! R2 ! R6 ! R7 ! R4
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/9
613
Module 6
How Does Traffic Engineering Work?

Traffic engineering works by determining what bandwidth is available on
what links and flooding that information using a link-state routing
protocol, such as OSPF or IS-IS. Cisco MPLS TE attempts to match
bandwidth requests by tunnels to the available bandwidth along a path
from a source to a destination.
Using an algorithm such as Constrained Shortest Path First (CSPF), Cisco
MPLS TE selects a path dynamically after it has verified that the path and
bandwidth are available. However, you may choose to send traffic along a
specific path to a destination by using a static or explicit path.
Traffic is placed on these paths using a variety of methods such as by
policy or access control list (ACL) based forwarding, by static route, auto
routing, TE metric, interface delay, or by using the IGP.
614
Version 4.0.1

Module 6
How Does Traffic Engineering Work?
Bandwidth
!Link bandwidth available

!Tunnel bandwidth requirement
Path selection
!Dynamically created
" IGP CSPF calculation including available bandwidth
!Explicitly defined
" Manually defined path
Tunnel traffic assignment
!Automatic using IGP

!Static
!Policy
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/10
615
Module 6
Cisco MPLS TE in Cisco IOS XR Software

In Cisco IOS XR Software, MPLS TE acts as an umbrella for several other
sub-functions:
616
Path calculation processing that determines the best path based on

the tunnel requirements and path availability
Resource Reservation Protocol-Traffic Engineering (RSVP-TE)

signaling protocol that seeks out the required path and requests the
bandwidth reservation from each of the nodes (routers) in the path.
RSVP-TE then signals back to the beginning of the path to indicate the
availability of the path and the bandwidth
Tunnel admission control processing that executes on each node in

the path to reserve and then admit a tunnel
Version 4.0.1

Module 6
Cisco MPLS TE in Cisco IOS XR Software
MPLS TE is an umbrella
!Path calculation
!RSVP-TE
!Tunnel admission control
MPLS-TE
RSVP-TE
PCALC
Admission
Control
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/11
617
Module 6
Cisco MPLS TE Tunnel Operation Overview

In this section, you learn about the operational aspects of MPLS TE.
Cisco MPLS TE Terminology

Some of the terminology that you use in describing a Cisco MPLS TE
operation:
618
Ingress or HeadendRouter on which the Cisco MPLS TE tunnel is

configured; you use headend. In the illustration, the headend router is
R1
Egress or TailendRouter on which the Cisco MPLS TE tunnel

terminates; you use tailend. In the illustration, the tailend router is R3
MidpointRouter, or routers, through which a Cisco MPLS TE tunnel

passes. In the illustration, the midpoint router is R2
LSPLabel-switched path taken by the Cisco MPLS TE tunnel. In the

illustration it is R1-R2-R3. Routers are called label switch routers
(LSR) in the path
Downstream routerRouter closer to the tunnel tailend. In the

illustration, R2 is downstream from R1
Upstream routerRouter farther away in relation to the tunnel

tailend. In the illustration, R2 is upstream to R3
Version 4.0.1

Module 6
Cisco MPLS TE Terminology
TE Tunnel
R1
R2
R3
Network X
Headend
Midpoint
Tailend
Ingress or HeadendRouter on which a TE tunnel is configured (R1)

Egress or TailendRouter on which TE tunnel terminates (R3)
MidpointRouter through which a TE tunnel passes (R2)
LSPLabel-switched path taken by the TE tunnel (R1-R2-R3)
! Label switch routers (LSR) in the path
Downstream router is closer to the tunnel tail
! R2 is downstream from R1
Upstream router is farther from the tunnel tail
! R2 is upstream to R3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/13
619
Module 6
Cisco MPLS TE Mechanisms

The mechanisms of Cisco MPLS TE are divided into a control plane and a
data plane.
The control plane uses existing link-state database interior gateway
protocols, OSPF and IS-IS, with Cisco MPLS TE extensions to provide the
topology information, including link cost, resources such as bandwidth, and
other constraints. To provide the relevant information to the routers in the
Cisco MPLS TE network, OSPF uses an opaque link-state advertisement
(LSA), and IS-IS uses type, length, value (TLV) link-state packets (LSPs).
Ultimately, the path used by a Cisco MPLS TE tunnel is determined by
OSPF or IS-IS based on the available resources and constraints in the
path.
The second protocol used in the formation of Cisco MPLS TE tunnels is
Resource Reservation Protocol (RSVP). RSVP is used to set up tunnels and
exchange labels by signaling the routers in the path from headend to
tailend, thus setting up a LSP or tunnel.
Finally, the Cisco MPLS TE tunnel, when activated, is available for the
data plane to forward data from the headend to the tailend based on the
MPLS label forwarding information base (LFIB). Data forwarding into a
tunnel may also be based on policies.
620
Version 4.0.1

Module 6
Cisco MPLS TE Mechanisms
MPLS Domain
Headend
IGP
IGP
IGP
RSVP
RSVP
RSVP
Midpoint
Midpoint
Tailend
Control plane
!OSPF or IS-IS with MPLS TE extensions distribute topology
information with costs, resources, and constraints

" OSPF with opaque LSAs
" IS-IS with TLVs
!RSVP-TE sets up an MPLS TE tunnel and exchanges tunnel labels
" Setting up the LSP or tunnel
Data plane
!Forwards packets into the MPLS TE tunnel based on LFIB
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/14
621
Module 6
Link Attributes
All links in the network have attributes, such as bandwidth, type (POS,
Gigabit Ethernet, and so on), and the physical path (satellite links,
undersea cable, land-based fiber optic, and copper are some examples).
Resource class affinity (policy) supports the ability to include, or exclude,
certain links for certain traffic trunks, based on a user-defined policy that
includes:
32 bits
Bandwidth by QoS precedence matched to tunnel priority
Bandwidth by priority Differentiated Services-Traffic Engineering

(DS-TE)
IP Precedence (IPP)
Affinity string and affinity policy may be used to steer traffic over, or keep
traffic off, specific links.
Affinity refers to the attractiveness of a particular link to carrying tunnel
traffic. Affinity in Cisco MPLS TE permits specifying bits, or strings of bits,
to dictate the type of traffic that can traverse the link. Typically, a bit
signifies something, link type, color, or some other value with meaning.
622
Version 4.0.1

Module 6
Link Attributes
Resource attributes configured on relevant links

in the network
!Available bandwidth
!Affinity policy
Resource attributes distributed by a link-state
IGP within the network
!Available bandwidth
" Per link
" Per priority (DS-TE)
!Affinity string
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/15
623
Module 6
Tunnel Attributes
Tunnels have various purposes, some more important than others. Traffic
such as voice cannot afford delay and needs to get resources when
required. Email and other data traffic do not have the same need. You
configure the tunnel attributes at the headend router. Each tunnel has
attribute flags set for it, which are used during the reservation process.
The attribute with the highest impact is bandwidth. The amount of
bandwidth a particular tunnel wants dictates the path the tunnel takes
through your network.
Cisco MPLS TE enables you to set the priority for the traffic based on the
requirements and allows tunnels to take precedence over others for set up,
and determines if the tunnel holds its bandwidth when another tunnel
wants to come up.
There are path options available for your tunnels too. The most popular is
explicit or static tunnels, in which you choose the path the tunnel takes.
This type of tunnel takes full knowledge and understanding of your
networks resources and the traffic that uses it. You may also use tunnels
that are dynamically computed paths based on combination of bandwidth
and policies.
You may also set up your tunnels for reoptimization, which is an attempt
to keep your tunnels on the best possible path. Occasionally, the network
resources are rechecked and if they have changed, your tunnels may be
rerouted, or optimized, to the new resources.
624
Version 4.0.1

Module 6
Tunnel Attributes
Configured at tunnel headend
Bandwidth requirement
Affinity bits
Priority
!Setup priority
!Hold priority
Path options
!Static or explicit
!Dynamic
Reoptimization
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/16
625
Module 6
Path Selection Considerations

The path a tunnel takes once it is configured depends on several
considerations:
Network topology and its possible physical paths as well as the choice
of pathexplicit or dynamic
Bandwidth required by the tunnel, the bandwidth available from the

headend router and the tailend, and the cost of the links
Attribute flags set and used during the set up. Links in the network
also have attributes. For a tunnel to use a particular link, it must
match an affinity for the link. Affinity includes constraints on
bandwidth and path restrictions. Using default settings for links and
tunnels simply allows the use of all possible links by the tunnel
Path priority defines whether or not a path is set up or holds its

bandwidth when another tunnel needs access and there is insufficient
bandwidth.
Each headend router runs an algorithm, known as shortest path first

(SPF), using the information that is collected in a link-state routing
protocol database. The SPF computes the shortest paths for the traffic
engineering database based on the constraints learned and stored in the
database. There is an additional calculation the headend makes, called the
CSPF, which takes into account an IGP database with links pruned based
on constraints such as bandwidth and the link affinities.
After the path is calculated, the tunnel must be signaled using RSVP:
626
Reserving bandwidth along the requested path
Setting up the LSP
Obtaining the labels along the path
Version 4.0.1

Module 6
Path Selection Considerations
Network topology learned from IGP

Link resource attributes learned from IGP
! Links with insufficient bandwidth are pruned
SPF algorithm computes shortest path based on constraints
! CSPF
" Different from regular SPF LSDB calculation

" IGP LSDB with pruned links removed
! Constraints
"
"
"
"
Available bandwidth
Affinity
Administrative weight
Explicit path, if defined
After the path calculation, tunnel must be signaled using RSVP
! Reserve bandwidth along the path

! Set up the tunnel or LSP
! Obtain labels
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/17
627
Module 6
Traffic Engineering and Interior Gateway Protocols

Traffic engineering uses two link-state protocols to obtain and flood
information about the network, such as bandwidth and constraints. The
two protocols are Open Shortest Path First (OSPF) and Intermediate
System to Intermediate System (IS-IS).
OSPF and IS-IS for Cisco MPLS TE

Cisco MPLS TE tunnels are set up from the headend. The headend
requires detailed information about the network, such as the topology and
the individual link cost.
Further, the headend needs and uses the constraint information supplied
by the IGPs:
Bandwidth:
!
Maximum bandwidth available
Maximum bandwidth available to reserve, by priority
Unreserved bandwidth
Traffic engineering metrics
Administrative groupings or affinities
OSPF and IS-IS, with their Cisco MPLS TE extensions. perform these:
628
Propagate link resources and constraints
Calculate a tunnel path based on cost, resources, and the constraints
Version 4.0.1

Module 6
MPLS TE tunnels are set up from the headend

Headend requires detailed information about
! Topology
! Link cost
! Bandwidth
" Maximum available for tunnels

" Maximum reservable by priority (DS-TE)
" Unreserved
! TE metric
! Administrative grouping or affinity
Link-state routing protocol with MPLS TE extensions

required
! Propagate link resources and constraints

! Calculate tunnel path based on costs, resources and constraints
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/19
629
Module 6
IGP Flooding
To create tunnels, routers need valid information to make strategic
decisions about the path the tunnel takes. Routers learn the information
that helps make the decisions, from the IGPs when they flood.
To make path decisions, routers need to know these:
Available bandwidth per link by priority
Attribute flags set per link
Administrative weight per link
The information is distributed and the flow is controlled by:
Flooding the significant information immediately after flooding occurs

!
Including when a change in configuration causes an error
Flooding less significant events less often than significant ones but
more often than regular periodic flooding
Flooding on regular periodic intervals that best suit your network
IS-IS and OSPF flood the LSP and LSA, respectively, when the link state
changes, up and down, or when the configuration of the interface changes.
Each of the IGPs also floods periodically, every 30 minutes for OSPF and
every 15 minutes for IS-IS. These refresh rates can be changed through
specific IGP configuration.
630
Version 4.0.1

Module 6
IGP Flooding
Main considerations
!Distribute what information
" Available bandwidth per link by priority

" Link attribute flags
" Administrative weight per link
!Distribute information when; how is flooding

controlled
" Flood significant events, including changes that cause
errors, immediately
" Flood insignificant events less often, but more often
than regular periodic updates
" Periodic information updates using refresh intervals
!What is required for IGP to distribute information

" OSPF defines opaque TE-extension LSAs
" IS-IS defines TE-extension TLVs
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/20
631
Module 6
OSPF Extensions for Opaque LSA

OSPF was extended to include capabilities to advertise the information
needed by Cisco MPLS TE. RFC 2370, The OSPF Opaque LSA Option,
updated by RFC 5250 introduced the three LSAs called opaque LSAs. The
extensions let OSPF carry information for other applications, such as TE^.
OSPF floods the information so that Cisco MPLS TE does not have to do so.
The three LSAs are:
632
Type 9, a link-local advertisement, that is, the advertisement is only

sent on a link
Type 10, an area-wide advertisement that does not go beyond area

border routers
Type 11, an autonomous system-wide advertisement that is used in the

entire OSPF domain
Version 4.0.1

Module 6
OSPF Extensions for Opaque LSA
IETF RFC 5250!The OSPF Opaque LSA Option
!Makes RFC 2370 obsolete

!Three LSAs
Type 9 LSA
!Flooding scope is link-local

!Sent only on a link and never forwarded
Type 10 LSA
!Flooding scope is area-wide

!Stopped at area border routers
Type 11 LSA
!Flooding scope is AS-wide

!Flooded throughout OSPF domain
" Transit areas, not stub areas
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/21
633
Module 6
OSPF Traffic Engineering Opaque LSA Detail

While there are three types of opaque LSAs, type 10 has been defined as
the traffic engineering opaque LSA by RFC 3630, Traffic Engineering
Extensions to OSPF Version 2. The table contains the OSPF link TLV subTLVs.
Sub-TLV
#
Name
Length
in octets
Meaning
Link type
Point-to-point or multi-access
Link ID
Router ID of neighbor or DR
interface address
Local interface IP address
Remote interface IP address
Traffic engineering metric
Maximum bandwidth
Total bandwidth in bytes per

second
Maximum reservable
bandwidth
Reservable bandwidth in bytes

per second
32
8 priorities, 4 octets each; not

yet reserved bandwidth in
bytes per second
Administrative group
Administrative settings for

affinity bits for link
RFC 2370 defines a new option bit, O-bit, to define the ability of the
routers to send or receive opaque LSAs. The option field is present in OSPF
hello and database description packets, and all LSAs.
The LSA option field values are:
O bitIndicates capability of sending and receiving opaque LSAs
DC bitDescribes handling of demand circuits
EA bitDescribes willingness to receive and forward External=AttributeLSAs
N/P bitDescribes handling of type-7 LSAs
MC bitDescribes whether Multicast packets are forwarded
E bitDescribes external routing capability and the way AS-externalLSAs are flooded
634
Version 4.0.1

Module 6
OSPF Traffic Engineering Opaque LSA Detail
31
LS age
Options
Opaque type
LSA type 9, 10, 11
Opaque ID
Advertising router
LS sequence router
LS checksum
Length
Opaque information
TE opaque LSA is type 10
! Includes one or more type, length, values (TLVs)

*
DC
EA
N/P
MC
LSA options field
!O-bit added to indicate opaque LSA capability
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/22
635
Module 6
IS-IS Extensions for Traffic Engineering

To take advantage of traffic engineering when IS-IS is the IGP, the IETF
introduced RFC 3784, IS-IS Extensions for Traffic Engineering, which has
been made obsolete by the introduction of RFC 5305 (same name). The
RFCs introduced two new TLVs to replace existing TLVs, and new ways to
carry routing information, sub-TLVs. The sub-TLVs are included in some
regular TLVs and provide extra information to supplement those
particular TLVs. In particular, each sub-TLV will have three fields, oneoctet fields for Type and Length, and a Value field of zero or more octets.
The first new TLVs is type 22, the extended IS reachability TLV
containing new data:
!
System ID and pseudonode number7 octets
Default metric3 octets; a 24-bit unsigned integer
Sub-TLV length1 octet
Sub-TLVs0 to 244 octets

!
Sub-type1 octet
Length1 octet
Value0 to 242 octets
The second new TLV is the Extended IP Reachability TLV is type 135.
This TLV succeeds the IP Reachability TLV types 128 and 130. The
original TLVs had four metrics of which only the default was really
used. And the ability to redistribute routes was limited to up level in
the IS-IS hierarchy. The new TLV 135 extends the metric to 32 bits and
adds a bit to indicate redistribution down in the hierarchy.
The third new TLV IS the TE router ID TLV (type 134), which contains
the 4-octet router ID of the LSP-originating router. This ensures a
single stable address reference for the path.
The three new TLVs are implemented only in the LSP.
636
Version 4.0.1

Module 6
IETF RFC 5305
!IS-IS Extensions for Traffic Engineering

!Makes RFC 3784 obsolete
Three new TLVs
!Extended IS Reachability TLV, type 22

!Traffic Engineering Router ID TLV, type 134
!Extended IP Reachability TLV, type 135
Introduces sub-TLVs
!Add information to TLV

!Contains Type field, Length field, and Value
octets
Version 3.9.0a
XMPLST4Module 6/23
Instructor's Note
Additional information is contained after the Summary page, as it was too much to include here.
Version 4.0.1
637
Module 6
OSPF and IS-IS Path Determination

In this example, the first illustration shows a network with five routers
and links with varying speeds connecting the routers together. The cost of
each link, no matter what the speed, is ten (10).
The headend router, R1, is aware of the topology, the link costs, and the
available bandwidth.
Using the default SPF calculation including the entire topology, the
shortest path is R1-R3-R5. Cost is the only calculation factor used to
determine the path. Thus, an MPLS tunnel follows that path unless other
otherwise directed.
638
Version 4.0.1

Module 6
OSPF and IS-IS Path Determination
10
R4
Mb
ps
30
30
Cost=10
Cost=10
Cost=10
Cost=10
Cost=10
Cost=10
s
bp
R2
R3
R4
R4
R5
R5
10
R1
R1
R2
R3
R3
R4
50 Mbps
R3
Headend
10
R1
50
10
bp
s
50 Mbps
10
R2
10
R5
Tailend
10 Mbps
B/W=30 Mbps
B/W=50 Mbps
B/W=50 Mbps
B/W=30 Mbps
B/W=10 Mbps
B/W=50 Mbps
Headend is aware of:
!Topology
!Link costs
!Available link bandwidths
Version 3.9.0a
10
R4
Mb
ps
30
30
50 Mbps
10
s
bp
M
MPLS traffic
R3
10
Headend
10
50
10
bp
s
50 Mbps
10
R2
R1
XMPLST4Module 6/25
R5
Tailend
10 Mbps
Shortest path
Default SPF is performed over the entire

topology
Cost is the only factor in this path calculation

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/26
639
Module 6

Cisco MPLS TE alters the equation. Cisco MPLS TE considers link cost,
available bandwidth, and other resource constraints to make a choice
about the path. With these attributes under consideration, links with
insufficient resources are excluded from the path calculation. This means
that the path selection criterion is lowest cost first, and the highest
minimum bandwidth is the tiebreaker when the costs are equal.
In this illustration, a Cisco MPLS TE tunnel with a 20 Mbps bandwidth
requirement takes the path R1-R3-R4-R5. The tunnel takes this path
because the available bandwidth between R3 and R5 is insufficient.
640
Version 4.0.1

Module 6
10
R2
R4
Mb
ps
10
30
30
50 Mbps
10
s
bp
MPLS tunnel
B/W req. 20 Mbps
R3
10
10
R1
Headend
50
10
M
bp
s
50 Mbps
R5
Tailend
10 Mbps
MPLS TE considers
! Cost
! Available bandwidth
" Per priority (eight priorities)
! Constraints
" Resource affinity
Links with insufficient resources are excluded from path calculation

Path selection criteria
! Lowest cost
! Highest minimum bandwidth is tie breaker
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/27
641
Module 6
Configuring the IGP Relationship

OSPF and IS-IS are the two link-state protocols used for TE in
Cisco IOS XR Software.
You define Cisco MPLS TE in OSPF router mode. You configure the Cisco
MPLS TE router ID in OSPF mode and also in area mode. This defines an
OSPF opaque LSA 10. Cisco MPLS TE may be defined in multiple areas.
This is further discussed later in this module.
On the other hand, you configure IS-IS TE in the IS-IS context in the
address family mode, currently available only in IPv4. You define a router
ID and TE by level. Note that Cisco MPLS TE does not work with the
default interface metric setting of narrow. You must configure the metric
style to wide on an IS-IS interface to use Cisco MPLS TE.
642
Version 4.0.1

Module 6
Configuring the IGP Relationship
IGP routing protocolsOSPF
Define a router ID for the protocol

Define TE^^ by area
mpls traffic-eng router-id {ipv4-address | interface-type interface-instance}

mpls traffic-eng
:router(config-ospf)# mpls traffic-eng router-id loopback0
:router(config-ospf-ar)# mpls traffic-eng
IGP routing protocolsIS-IS
Version 3.9.0a
XMPLST4Module 6/29
All TE definitions are in address family IPv4

Requires wide metric configuration (also in address family IPv4)
Define a router ID for the protocol
Define TE by level
:router(config-isis-af)#
metric-style wide [ transition ] { 1 | 2 }

mpls traffic-eng router-id { ipv4-address | interface-type interface-instance }
mpls traffic-eng { level-1 | level-1-2 | level-2-only }
:router(config-isis-af)# metric-style wide
:router(config-isis-af)# mpls traffic-eng router-id loopback0
:router(config-isis-af)# mpls traffic-eng level-2-only
:router(config-isis-af)#
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/30
643
Module 6
RSVP Operation Overview

In this section you get an overview of RSVP and its operation in support of
MPLS TE.
RSVP works by requesting that every device between two endpoints
reserve the required bandwidth and latency for traffic. RSVP is both a
unicast and a multicast signaling protocol, designed to install and
maintain reservation state information at each router along the path of a
stream of data.
A host seeking to request specific qualities of service from the network for
particular application data streams, or flows, uses the RSVP protocol.
RSVP requests generally result in resources being reserved in each node
along the path.
Signaling Tunnel Setup

Cisco MPLS TE tunnels are signaled in several circumstances that may be
broken into two general categories, the tunnel is down or the tunnel is up.
When the tunnel is down, the possible reasons for signaling by the headend
are:
First time configuration of the tunnel
Existing tunnel has gone down
New tunnel is set up after a tunnel preemption has occurred
Unprotected tunnel has a path verification failure
When a tunnel is already up, possible reasons for signaling by the headend
include:
644
Periodic reoptimization timer expires
Reoptimization of a fast reroute (FRR) tunnel occurs
Path verification fails for a protected tunnel
Auto bandwidth calculation triggers a change in path or bandwidth
Version 4.0.1

Module 6
Signaling Tunnel Setup
When does it occur?
Tunnel is down
!Configuration of a new tunnel

!Existing tunnel is down and new resources become
!
!
available
After preemption
Path verification failure for unprotected tunnels
Tunnel is up
!Periodic reoptimization
!Reoptimization on FRR
!Path verification failure for protected tunnels
!Auto bandwidth-triggered change
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/33
645
Module 6
Tunnel Request
RSVP uses a series of messages to manage the tunnels, such as Path, Resv,
PathTear, ResvTear, ResvErr, and PathErr. These messages contain
objects, or information, that is used by RSVP routers to make decisions
about the tunnels they manage. In this module, you learn about the
messages and their use in this module.
A headend router sends the RSVP reservation request, in the form of a
Path message. The RSVP reservation is identified using:
Sender Address
LSP IDEach time tunnels change bandwidth or path, LSP ID

increments by one (1)
Endpoint Address
Tunnel ID16 bits
Extended Tunnel ID32 bits (source address)
The reservation request contains a Label_Request object that signals the

tailend to start the LSP creation process.
In the illustration, router R1 needs a tunnel to router R9. The service
provider network administrator chose a specific path based on his, or her,
knowledge of the network. R1 sends a Path message, with destination of
R9 and with a Router Alert (RA) bit set. The objects in this Path message
contain an explicit route object (ERO). When the Path message reaches
router R2, the router will open it because the RA bit is set. R2 will look at
the endpoint address and the ERO. R2 will remove itself from the ERO and
send a new Path message, with the RA bit set, on to router R6.
This will continue until a Path message reaches router R9. R9 will open
the packet and find that it is the destination. R9 will prepare a response to
the Path request.
646
Version 4.0.1

Module 6
Tunnel Request
R9
R8
R3
R4
Path
message
20Mbps
30
R2
R1
80
60
R5
70
50
60
40
R6
R7
100
80
80
RSVP path: R1 ! R2 ! R6 ! R7 ! R4 ! R9
Available bandwidth
Version 3.9.0a
XMPLST4Module 6/35
Instructor's Note
Slide animation: Click 1 Path message 20 Mbps appears and blue arrows trace from R1 to
R9
Version 4.0.1
647
Module 6
Tunnel Admission Control

Tunnel admission control occurs as part of the response to the request for a
Cisco MPLS TE path (Path message). RSVP sends a reservation (Resv)
message to allocate and distribute the labels for the LSP using a Label
object (response to Label_Request).
The tailend router of the requested tunnel sends the Resv message. Each
router in the path determines and reserves the requested resources, and
admits the tunnel into the network and supplies that information in the
Resv message on its way to the headend router. Local resource accounting
is performed to update availability for potential future tunnel requests.
The granting of resources during tunnel admission may result in some
existing tunnels being torn down.
A set of thresholds that cover both increasing and decreasing bandwidth
availability are tested during the reservation process. Crossing a threshold
as a consequence of the reservation process often results in resource
updates being flooded.
648
Version 4.0.1

Module 6
Tunnel Admission Control
Response to RSVP-TE request (Path)
!RSVP Resv message
Performed by routers along LSP
!Labels allocated and distributed
Determine if resources are available

May tear down existing tunnels with lower
priorities
Perform local accounting

Trigger IGP information distribution when
resource thresholds are crossed
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/36
649
Module 6
Tunnel Reservation
The response to the Path message is an RSVP Resv message sent by the
tailend router to the headend router.
R9 formulates the Resv message with a destination of R1. The objects in
the Resv message include the address of the link between R9 and R4, and
the R1 router ID. There is no RA^% bit set in the Resv message.
This illustration shows a successful tunnel reservation and admission.
Failure scenarios are addressed later in this module.
650
Version 4.0.1

Module 6
Tunnel Reservation
R9
R8
R3
R4
30
10
R2
R1
80
60
27
32
70
50
60
40
49
RESV
message
Pop
R6
R5
R7
100
80
22
RSVP Resv-Returns labels and reserves
bandwidth on each link for 20 Mbps request
49
80
Returned label using Resv message

Available bandwidth after tunnel admitted
Version 3.9.0a
XMPLST4Module 6/38
Instructor's Note
Slide animation: Slide starts with available bandwidth shown in red; Click 1 Yellow Resv
message and green POP label appear from right. Yellow arrows appear R9-R4-R7-R6-R2-R1
along with accompanying green labels. Note the available bandwidth numbers are in red. Click 2
The available bandwidth numbers are reduced to account for new reserved bandwidth and color
changes to tan.
Version 4.0.1
651
Module 6
Path Maintenance
RSVP has a process that it uses to maintain the paths that tunnels take for
as long as the tunnel needs that path.
RSVP is a soft-state protocol. A soft-state mechanism is one that times out
without regular refreshing.
The headend of a path sends periodic Path messages to refresh the path
information. Occasionally midpoint routers may originate new Path
messages.
Path and Resv messages are sent asynchronously by the headend and
tailend, respectively. Each is sent independent of the other. They are sent
within a standard interval of 45 seconds that is varied to account for
possible jitter in the network. The jitter calculation is one half of the
interval, or 22.5 seconds. Thus, a refresh is sent between 22.5 and
67.5 seconds.
652
Version 4.0.1

Module 6
Path Maintenance
RSVP is soft-state protocol
!Need to refresh the state periodically
Headend sends periodic Path messages to

refresh the path
Midpoint routers occasionally originate new Path

messages
Same procedure for Resv messages as

previously outlined
Path and Resv messages are sent
asynchronously and independently

Version 3.9.0a
XMPLST4Module 6/40
Path and Resv messages are sent asynchronously
!Every 45 seconds using a plus or minus half the interval to

account for jitter
!Sent to the neighbor between 22.5 and 67.5 seconds
Neighbor hold time is calculated as
!(K + 0.5) x 1.5 x R

!K is number of refreshes
!R is refresh interval
!K and R can be configured
RFC 2205 says
!K-1 refreshes can be missed
Cisco IOS XR defaults
" K = 4
" R = 45 seconds
" Default soft-state timeout is approximately 303 seconds
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/41
653
Module 6
Path Maintenance Example

Path and Resv message refreshes act asynchronously and independently.
Here is an illustration of what happens during path maintenance. In the
refresh mechanism for the Path messages, R2 is expecting a Path message
refresh from R1. R1 sends a Path message to R2 and expects nothing in
return.
If, however, the R2 RSVP hold time expires, R2 does this:
Deletes the RSVP state
Sends PathTear downstream to R6
Sends ResvTear upstream to R1
The PathTear message proceeds hop-by-hop until it reaches the end of the
path. In other words, R3 sees the PathTear message, sends a ResvTear
message, and so on.
The refresh mechanism for a Resv message is the same. R1 is expecting to
see Resv messages from R2 after the initial Resv. In turn, each pair of
adjacent routers does the same thing. And if a timer expires before
receiving the Resv message, the same thing happens as in the case of the
Path message.
If the interface between R6 and R7 goes down, several steps take place
depending on the type of tunnel that was created. If the tunnel was created
as an unprotected tunnel, or as a protected tunnel, but with no backup
path, as in this case, these happen:
R6 deletes the RSVP state for the affected tunnel
R6 sends a PathErr message with the Path State Remove (PSR) bit set
toward R1
R6 sends a ResvTear message upstream to R1
R7 sends a PathTear message downstream to R9
If the tunnel is protected and a backup is available, these happen:
R6 does not remove the state and no ResvTear message is sent

upstream
R6 sends a PathErr message upstream, but the PSR bit is not set.
Tunnel protection and backup paths are discussed later in this module.
654
Version 4.0.1

Module 6
Path Maintenance Example

R9
R4
R2
R1
R6
R7
Path and Resv refreshes act asynchronously and independently

Refresh mechanism for Path message
R2 is expecting Path message (refresh) from R1
Refresh mechanism for Resv is same

Each pair of adjacent routers does the same thing
R2 hold time expires
!
!
Send PathTear towards R6

Send ResvTear towards R1
Version 3.9.0a
XMPLST4Module 6/43
R9
R4
R2
R1
R6
R7
Interface from R6 to R7 goes down

Unprotected tunnel or protected tunnel with no backup path
! R6 deletes state
" Sends PathErr message upstream with Path State Remove (PSR) bit
set
" Sends ResvTear message upstream
! R7 sends PathTear message downstream

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/44
655
Module 6
Insufficient Bandwidth for Tunnel

During tunnel setup, a router may not have sufficient bandwidth to satisfy
a request. When that occurs, steps are taken to notify the other routers in
the path.
Midpoint Behavior
When a request for bandwidth reaches a midpoint router in the path from
headend to tailend, the amount of available bandwidth already in use by
other tunnels may be more than what the new tunnel can be granted.
However, the midpoint router does not reject the request immediately. The
midpoint router examines the hold priorities of the existing tunnels and
compares them with the setup priority of the new tunnel request. The
midpoint will preempt any lower priority tunnels it needs to satisfy the
bandwidth request of the new tunnel.
If the midpoint is unable to preempt any existing tunnels, admission
failure occurs. This may be caused by a stale view of the Cisco MPLS TE
database at the headend that requested the tunnel. In this instance, the
midpoint sends a PathErr message to headend.
This also causes OSPF to flood a type-10 LSA or IS-IS to flood a type-135
LSP to update the Cisco MPLS TE databases.
Headend Behavior
When the tunnel setup has failed and the midpoint has sent a PathErr
message, the headend follows a procedure to attempt to deal with the
failure. First, the headend uses an exponential backoff algorithm to holddown the path option. The headend does not hold-down the link in the
Cisco MPLS TE database, so that other existing tunnels are not affected.
If an additional path option for the tunnel is configured, the headend
attempts to signal this new path option. This continues until it is
successful or all path options are exhausted. Retries are attempted based
on the backoff timer.
In the event this is a reoptimization attempt to re-signal a tunnel, the
attempt is abandoned until the next expiration of the reoptimization timer.
The headend receives the OSPF or IS-IS link-state updates and makes the
adjustments to the Cisco MPLS TE topology in parallel with the path
retries.
656
Version 4.0.1

Module 6
Insufficient Bandwidth of Tunnel
Midpoint behavior
Midpoint will preempt lower priority tunnels
!If they exist and reserve the requested bandwidth
If preemption is not possible
!Admission failure occurs

!Likely caused by stale view of TE database at headend
Midpoint sends PathErr to the headend

Triggers flooding
!OSPF type-10 LSA

!IS-IS type-135 LSP
Version 3.9.0a
Headend behavior
Headend receives admission failure PathErr message
XMPLST4Module 6/46
Headend holds down the path option
! Exponential back-off
! While waiting for CSPF
Link is not held down in topology due to admission failure PathErr
! So other tunnels are not affected
Headend moves to the next path option and tries to signal

If all path options are exhausted
! Headend waits for the holddown (backoff) duration before retrying

! If attempting to reoptimize the tunnel
" Attempt is abandoned
" Wait for the next expiration of the periodic reoptimization timer
TE topology updated in parallel
! By receipt of OSPF type-10 LSA or IS-IS type-135 LSP
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/47
657
Module 6
Path Teardown
A tunnel may be shut down if it is dynamic and the application no longer
needs the tunnel, or an administrator may shut it down, or it may be shut
down in favor of another tunnel, which has a higher priority.
The headend will send a PathTear message toward the tunnel destination
with the RA option bit set. Every router in the path will need to act on this
PathTear message. They do so by sending a ResvTear message back
toward the headend and their own PathTear message toward the tailend.
When the tailend router receives the PathTear message, it will send its
own ResvTear message back toward the headend.
Path teardown also occurs when an RSVP state times out.
658
Version 4.0.1

Module 6
Path Teardown
Tunnel is shut down at headend
Headend sends PathTear message
!PathTear is sent to the destination with RA option

!Every router in the path needs to act on it
" Send ResvTear to upstream neighbor and send its own
PathTear downstream
Tailend sends ResvTear on the path
!No RA on the packet
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/48
659
Module 6
RSVP Error Signaling

RSVP will signal an error when certain events occur:
A link breaks in the network
An error appears in a Path or Resv message
PCALC inserts a bad hop in the ERO
A reservation asks for more bandwidth than what exists on a link in

the path
A PathErr message is sent to the headend router. It is sent to the next

upstream hop without the RA bit set.
660
Version 4.0.1

Module 6
RSVP Error Signaling
Errors occur when
A link breaks in the middle of the network

There is an error in the Path or Resv message
PCALC inserts a bad hop in the ERO
A reservation is asking for more bandwidth than what
exists on a particular link in the path
In these cases, router will send a PathErr message

towards the headend
Sent to the previous hopNo RA set in the message
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/49
661
Module 6
RSVP Common Header and Message Type Summary

RSVP messages use a common header that contains some specific
necessary information:
VersionProtocol version number, which is currently 1
Message TypeThere are currently nine message types in use; the

types are listed on the opposite page
The other parts of the header are useful for managing the packets in the
network and insuring their integrity, or represent items that have not yet
been defined by the IETF.
The most common message types are listed in the lower illustration, along
with their purpose, what triggers them, which router sends the message,
and to whom the message is sent.
662
Version 4.0.1

Module 6
RSVP Common Header
0
Version
(4 bits)
4
Flags
8
Message type
(4 bits)
16
RSVP checksum
(8 bits)
(16 bits)
Send TTL
Reserved
RSVP length
(8 bits)
(8 bits)
(16 bits)
31
VersionProtocol version number; currently version 1.

FlagsReserved; no flag bits are defined currently
Message type
! 1 = Path
! 2 = Resv
! 3 = PathErr
! 4 = ResvErr
! 5 = PathTear
! 6 = ResvTear
! 7 = ResvConf
! 10 = ResvTearConf
! 20 = Hello
Version 3.9.0a
RSVP Message
Purpose
Path (RA)
Signal resource
request
Resv
Response to Path,
carry labels
Receipt of Path at tailend

and maintenance
Tail and midpoint,

upstream
Next hop
PathErr
Error in Path
message
Link in the middle goes

down or not enough
bandwidth
Midpoint and tailend,

upstream
Next Hop
ResvErr
Error in Path
Message
Same as PathErr above
Headend and midpoint,

downstream
Next Hop
PathTear (RA)
Sent to tail to tear

down an existing
reservation
Tunnel shut down
ResvTear
Sent to head to tear

down an existing
reservation
Tunnel shut down
Tail and midpoint,

upstream
Next Hop
Hello
Keepalive
Every 5 seconds
All neighbors
Router ID of
neighbor
Trigger
XMPLST4Module 6/51
Who Sends It
Tunnel establishment and Headend and midpoint,

maintenance
downstream
Version 3.9.0a
Version 4.0.1
Headend and midpoint,

downstream
To Whom
Tailend
Tail
XMPLST4Module 6/52
663
Module 6
RSVP CLI Configuration Structure

Cisco IOS XR Software command-line interface (CLI) is typically a
hierarchical structure where some parameters set at a higher level are
inherited at lower levels, or may be overridden at a lower level.
With the RSVP CLI, bandwidth and authentication may be inherited from
a higher level of the command structure. Here you see that there are two
configuration modes, authentication and interface, under the general
RSVP mode.
You should be aware of some inconsistencies in the structure of the RSVP
CLI. While many CLI commands may be invoked in RSVP mode, some
bandwidth commands must be invoked in CLI global configuration mode.
There are some other commands that also work this way.
664
Version 4.0.1

Module 6
RSVP CLI Configuration Structure
Hierarchical RSVP configuration
Some inheritance
!Bandwidth on interfaces
!Authentication on neighbors
rsvp
(config-rsvp)
authentication
interface
(config-rsvp-auth)
(config-rsvp-if)
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/53
665
Module 6
Configuring RSVP for Traffic Engineering

You set up signaling on each interface that will be implementing RSVP.
Enter the RSVP context and select the interface, or interfaces, on which
you want to implement signaling.
Configuring RSVP Path Signaling Timers

RSVP relies on a soft-state mechanism to maintain state consistency in the
face of network losses. The soft-state mechanism is based on continuous
refresh messages to keep a state current. Each RSVP router is responsible
for sending periodic refresh messages to its neighbors.
The router attempts to randomize network traffic and reduce burstiness by
jittering the actual interval between refreshes by as much as 50 percent.
As a result, refreshes may not be sent at exactly the interval specified.
However, the average rate of refreshes is within the specified refresh
interval.
Lengthening the interval reduces the refresh load of RSVP on the network
but causes downstream nodes to hold state longer. This reduces the
responsiveness of the network to failure scenarios. Shortening the interval
improves network responsiveness but expands the messaging load on the
network.
666
Version 4.0.1

Module 6
Configuring RSVP for Traffic Engineering
Setting up signaling
Enter the RSVP context
Choose the interface
:router(config)#
rsvp
:router(config-rsvp)#
interface type interface-path-id

:router(config)# rsvp
:router(config-rsvp)# interface POS 0/3/0/7
:router(config-rsvp-if)#
Version 3.9.0a
XMPLST4Module 6/55
Setting router average RSVP status update frequency
! Updates are randomized to reduce network load

! May vary as much as 50% from setting
! Set in seconds; default is 45 seconds
signalling refresh interval seconds
:router(config)# rsvp
:router(config-rsvp)# interface POS 0/3/0/7
:router(config-rsvp-if)# signalling refresh interval 60
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/56
667
Module 6
RSVP Bandwidth for Traffic Engineering

When you configure the bandwidth for an interface, the amount you chose
is relative to the intrinsic bandwidth of the link. A default configuration, in
other words not using the bandwidth parameter on the interface, results
in 75 percent of the intrinsic bandwidth being available for TE. The
bandwidth parameter is set in either bits per second or percentage. The
percentage value is used in IETF DDS-TE, which is beyond the scope of
this module.
Configuring RSVP Bandwidth

Bandwidth may be configured in RSVP configuration mode. This will be
discussed later in this module.
You may also configure bandwidth in interface mode. The amount of
bandwidth you can set aside for an interface defaults to 75 percent of the
intrinsic bandwidth. You configure a lesser amount by specifying the
bandwidth value in kilobits per second (kbps), megabits per second (Mbps),
or gigabits per second (Gbps). You may configure the bandwidth in pools.
The bc0 or global-pool is a general-purpose pool normally associated with
best-effort traffic, while bc1 or sub-pool is typically bandwidth set aside for
high-priority traffic.
You may also use the Russian Doll Model (RDM) or the Maximum
Allocation Model (MAM) methods of reserving bandwidth.
The Cisco IOS XR interface bandwidth configuration defaults to RDM.
668
Version 4.0.1

Module 6
RSVP Bandwidth and Configuring for Traffic Engineering
Measured against intrinsic bandwidth of link

Default is 75% of link bandwidth
! When no amount is specified
Choice of bits per second or percentage
! Percentage used with DS-TE
Physical
link
RSVP
bandwidth
Setting the total bandwidth available per interface for reservation

In Kbps, Mbps, or Gbps
Version 3.9.0a
XMPLST4Module 6/58
! Range is 04,294,967,295
! Default is Kbps
Bandwidth pools
! bc0 and global-pool are synonymous

! MAM and RDM are DS-TE related
! RDM is the default
bandwidth {total-reservable-bandwidth | bc0 | global-pool | mam | rdm}
:router(config-rsvp-if)# bandwidth 6 Gbps
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/59
669
Module 6
Maximum Allocation and Russian Doll Bandwidth Examples

This is a brief description of the MAM and RDM. Cisco IOS XR Software
routers default to using the RDM method of bandwidth allocation for nonDS-TE implementations.
MAM Bandwidth Example

In the MAM model of bandwidth allocation, each class type (CT) has a
maximum bandwidth. This is a constraint for the class. MAM adds the
bandwidth maximum of each class type to obtain the total maximum
reservable bandwidth.
RDM Bandwidth Example

In the RDM model of bandwidth allocation, the bandwidth for each class
type is the sum of the bandwidth of the class plus the bandwidth of any
lower classes. The sum of all the bandwidth of all the classes is the
maximum reservable bandwidth.
670
Version 4.0.1

Module 6
MAM and RDM Bandwidth Examples
MAM
Each class type (CT) has a
CT2
maximum bandwidth
constraint
BC2
Sum of the bandwidths
CT1
reserved for all the CT must

be less than or equal to
MaxRBW
BC1
CT0
BC0
Max Reservable Bandwidth (MaxRBW)
RDM
Version 3.9.0a
CT2
XMPLST4Module 6/61
CT2 + CT1+ CT0
CT2 + CT1
BC2
BC1
BC0=MaxRBW
Each CT has bandwidth equal to the sum of two components
- Sum of the bandwidth of lower classes

- Its own component bandwidth
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/62
671
Module 6
Displaying RSVP Interfaces

You may wish to review all the interfaces that you have configured for
RSVP. The show rsvp interface command displays each interface with
its maximums and allocations of bandwidth. The MaxBW column shows
what has been configured for the interface, while the Allocated column
shows the how much is being used by tunnels.
If you wish to see the detail about each interface, use the
show rsvp interface <name> detail command. In the illustration, you
see the additional detailed information about the interface. You can use
this information to analyze the interface for tunnel configuration and
problem resolution.
Maxflow is the maximum bandwidth allowed for a single traffic
engineering flow on the RSVP link.
672
Version 4.0.1

Module 6
Displaying RSVP Interfaces
:router# show rsvp interface

Wed Mar 17 01:05:16.141 UTC
Interface
MaxBW (bps) MaxFlow (bps) Allocated (bps)
MaxSub (bps)
----------- ----------- ------------- -------------------- -----------PO0/3/0/1
80M
80M
0 ( 0%)
0
Gi0/4/0/2
4G
4G
0 ( 0%)
0
Display all interfaces and the bandwidth

:router# show rsvp interface pos 0/3/0/1 detail
Wed Mar 17 00:44:53.049 UTC
INTERFACE: POS0/3/0/1 (ifh=0x4000700).
VRF ID: 0x60000000 (Default).
BW (bits/sec): Max=80M. MaxFlow=80M.
Allocation shows up when
Allocated=0 (0%). MaxSub=0.
tunnels are activated
Signalling: No DSCP marking. No rate limiting.
States in: 0. Max missed msgs: 4.
Expiry timer: Not running. Refresh interval: 45s.
Normal Refresh timer: Not running. Summary refresh timer: Not running.
Refresh reduction local: Enabled. Summary Refresh: Enabled (4068 bytes max).
Reliable summary refresh: Disabled. Bundling: Enabled. (4096 bytes max).
Ack hold: 400 ms, Ack max size: 4096 bytes. Retransmit: 900ms.
Display all interfaces and the bandwidth

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/63
673
Module 6
MPLS Traffic Engineering Configuration

In this section, you learn about various aspects of Cisco MPLS TE and its
configuration in the Cisco IOS XR operating system.
Enabling Traffic Engineering

In Cisco IOS XR software MPLS TE is configured separately so that
various parameters and timers may be set globally.
You will cover the highlighted items in this module.
674
Version 4.0.1

Module 6
Enabling Traffic Engineering
:router(config)#
mpls traffic-eng
:router(config)# mpls traffic-eng ?
affinity-map
auto-bw
bfd
ds-te
fast-reroute
interface
link-management
lmp
load-share
logging
path-selection
pce
reoptimize
router-id
signalling
timers
topology
<cr>
Affinity Map Configuration

Auto-bandwidth configuration
Configure BFD parameters
Diff-Serv Traffic-Engineering Parameters
Fast-reroute config parameters
Enable MPLS-TE on an interface
MPLS Link Manager subcommands
LMP configuration commands
Load-share configuration
MPLS Traffic-Eng. logging configuration
Path Selection Configuration
MPLS Traffic Engineering PCE functionality
MPLS TE Reoptimize config
Router ID
Signalling options
Traffic Engineering timers
Topology Database Configuration
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/65
675
Module 6
Enabling Cisco MPLS TE on Interfaces

For every interface on which you plan to run Cisco MPLS TE, you must
configure that interface under the MPLS Traffic Engineering configuration
mode. This is shown in the illustration.
After you have configured an interface, additional configurable options for
the interface are available:
admin-weightSet the administrative weight for the interface
attribute-flagsSet user-defined interface attribute flags
attribute-namesSpecify one or more attribute names
backup-pathConfigure an Cisco MPLS TE backup for this interface
bfdConfigure Bidirectional Forwarding Detection (BFD) parameters

on Ethernet links
floodingSet flooding parameters
When you configure an interface for Cisco MPLS TE, RSVP is turned on for
the interface, even if you have not previously configured it. However, zero
bandwidth is allocated and the Cisco MPLS TE tunnels will not activate
until RSVP bandwidth is configured.
Also, if the IGP in the network is IS-IS Cisco MPLS TE does not work until
the metric style of the interface is changed to wide. The metric-style is
configured in the IS-IS interface configuration.
676
Version 4.0.1

Module 6
Enabling Cisco MPLS TE on Interfaces
:router(config-mpls-te)#
interface
:router(config)# mpls traffic-eng
:router(config-mpls-te)# interface POS 0/3/0/1
:router(config-mpls-te-if)#
Traffic engineering must be configured for each interface

participating in TE
Enter MPLS traffic engineering mode

Enable MPLS TE interfaces
!Set the options for the interfaces
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/66
677
Module 6
Other Cisco MPLS TE Interface Commands

You can use the admin-weight command to override the IGP weight for
the link or tunnel and use this cost in its place. The default weight is 1 for
OSPF and 10 for IS-IS. This parameter is configured in the MPLS TE
interface configuration mode.
Sometimes a router may receive an RSVP error indicating that a path
cannot be set up because a link is unavailable before an IGP advertisement
indicating the link status. To prevent the link from being used as part of
the CSPF calculation after the signaling error, the link is ignored for a
hold-down period of time (default is 10 seconds). You can change the
hold-down timer used to ignore this link in the Cisco MPLS TE topology
database by using the topology holddown sigerr command.
678
Version 4.0.1

Module 6
Other Cisco MPLS TE Interface Commands
admin-weight weight
:router(config-mpls-te-if)# admin-weight 5
Override IGP cost for this tunnel link

Path selection metric must be configured
topology holddown sigerr seconds

:router(config-mpls-te-if)# topology holddown sigerr 5
Time router should ignore link in topology database for CSPF calculations
! After a RSVP signaling error
Headend router may receive RSVP error message before IGP

advertisement
! Avoids creating paths including link until IGP confirms or hold-down timer
expires
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/67
679
Module 6
Displaying General Cisco MPLS TE Interface Information

Use the show mpls traffic-eng link-management summary command
to obtain some general information about the interfaces that you have
configured and the relationship with the IGP running in the network.
In the illustration, you see one network with OSPF and one with IS-IS as
the network IGP. The Links Count value is the number of interfaces
configured to run Cisco MPLS TE. The IGP Areas Count represents the
actual number of areas configured to run Cisco MPLS TE. In both IGPs, it
is possible to run multiple areas with Cisco MPLS TE.
In the IGP Areas display, you see the actual protocol, the status of the
flooding of information for tunnel use and how often that information is
flooded, the IGP and Cisco MPLS TE router IDs (for OSPF they could be
the same, but in this display they are different), and the number of
neighbors in the IGP area.
680
Version 4.0.1

Module 6
Displaying General Cisco MPLS TE Interface Information
:router# show mpls traffic-eng link-management summary

System Information::
Links Count
: 5 (Maximum Links Supported 250)
Flooding System
: enabled
IGP Areas Count
: 1
IGP Areas
---------IGP Area[1]:: OSPF lab area 0
Flooding Protocol
: OSPF
Flooding Status
: flooded
Periodic Flooding
: enabled (every 180 seconds)
Flooded Links
: 5
IGP System ID
: 0.0.0.1
MPLS TE Router ID
: 10.1.1.1
IGP Neighbors
: 5
OSPF information
Displays the TE interface count

Displays the IGP type and related information
Version 3.9.0a
XMPLST4Module 6/69
:router# show mpls traffic-eng link-management summary

Links Count
Flooding System

: enabled
IGP Areas Count
: 1
IGP Areas
---------IGP Area[1]:: IS-IS L2-12 level 2
Flooding Protocol
: IS-IS
Flooding Status
Periodic Flooding
: flooded
: enabled (every 180 seconds)
Flooded Links
: 3
IGP System ID
MPLS TE Router ID
: 0000.0000.0033
: 10.3.3.33
IGP Neighbors
: 3
Version 3.9.0a
Version 4.0.1
IS-IS information
XMPLST4Module 6/70
681
Module 6
Displaying Specific Cisco MPLS TE Interface Information

Here you see more specific information about an interface that has been
configured for Cisco MPLS TE. Because this is a Gigabit Ethernet
interface, the intrinsic bandwidth is labeled physical bandwidth. Also the
Link Label Type indicates PSC, which stands for packet-switch capable.
This is the default for Cisco MPLS TE links.
In the second part of the display, there is a lot of information showing
default bandwidth reservations and the pools from which those
reservations have been made. Notice that the link has been configured to
use both the RDM (default) and MAM bandwidth allocation models.
Also, you see the state of Cisco MPLS TE and RSVP, as well as the
administrative status of the link.
In this display, the link has a Flooding Status, which tells you what the
IGP is, what areas are involved, what the status of flooding traffic
engineering information is, and the IP address. Also notice that the IGP
has set its administrative weight, but that no special Cisco MPLS TE
administrative weight has been configured.
682
Version 4.0.1

Module 6
Displaying Specific Cisco MPLS TE Interface Information
:router# show mpls traffic-eng link-management interface gig0/4/0/1

Links Count
Link ID:: GigabitEthernet0/4/0/1 (192.168.123.3)

Local Intf ID: 10
Link Status:
Link Label Type
: PSC
Physical BW
: 1000000 kbits/sec
Intrinsic bandwidth
--More--
Display TE interface Gigabit Ethernet 0/4/0/1
Default bandwidth constraint model
BCID
: RDM
Max Reservable BW
: 200000 kbits/sec (reserved: 0% in, 0% out)
Version 3.9.0a
BC0 (Res. Global BW): 200000 kbits/sec (reserved: 0% in, 0% out)

BC1 (Res. Sub BW)
: 0 kbits/sec (reserved: 100% in, 100% out)
MPLS TE Link State
: MPLS TE on, RSVP on, admin-up
Inbound Admission
: reject-huge
Outbound Admission
: allow-if-room
IGP Neighbor Count
: 1
Max Res BW (RDM)
: 200000 kbits/sec
BC0 (RDM)
: 200000 kbits/sec
BC1 (RDM)
: 0 kbits/sec
Max Res BW (MAM)
: 500000 kbits/sec
BC0 (MAM)
: 500000 kbits/sec
BC1 (MAM)
: 500000 kbits/sec
Attributes
: 0x0
Attribute Names
XMPLST4Module 6/72
Bandwidth reserved
TE and RSVP up
RDM default bandwidth reserved
MAM default bandwidth reserved
Flooding Status: (1 area)

IGP Area[1]: IS-IS L2-12 level 2, flooded
Nbr: ID 0000.0000.0022.05, IP 192.168.123.2 (Up)
IGP information
Admin weight: not set (TE), 10 (IGP)
Display TE interface Gigabit Ethernet 0/4/0/1 contd

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/73
683
Module 6
Creating Traffic Engineering Tunnels

In this section, you see what is needed to configure and review Cisco
MPLS TE tunnels.
Traffic Engineering Tunnels

For tunnels to actually be used and carry traffic to their destination, you
define them as interfaces. The bandwidth required for the tunnel is
measured against the available bandwidth in the Cisco MPLS TE database
for the path designated. Links in the network may have attribute bit
settings that have been configured and tunnels may have affinity bits set
to either let them set up over the link or not be allowed to set up over the
link.
684
Version 4.0.1

Module 6
Traffic Engineering Tunnels
Tunnels carry traffic to destination

Based on bandwidth required compared to
bandwidth available
Based on affinity settings
!Some links can host some tunnels

!Some links reject some tunnels
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/75
685
Module 6
Creating Cisco MPLS TE Tunnels

A TE tunnel is an interface from the standpoint of configuration in
Cisco IOS XR Software.
Use the interface tunnel-te command in global configuration, followed by
a numeric value. The tunnel numbers range from 0 to 65,535. A description
is also allowed for documentation.
TE Tunnel Options
As you can see from the illustration, there are several parameters that
may be set for a tunnel interface:
autorouteParameters for IGP routing over tunnel
destinationTunnel destination
ipv4IPv4 interface subcommands
path-optionPrimary or fallback path setup option
priorityTunnel priority
signalled-bandwidthTunnel bandwidth requirement to be

signalled
Some of the other parameters are discussed later in this module.
686
Version 4.0.1

Module 6
Creating Cisco MPLS TE Tunnels and the Options
:router(config)#
interface tunnel-te tunnel-id
:router(config)# interface tunnel-te 45

:router(config-if)# description tunnel-to-PE5
:router(config-if)#
Create an interface
Assign a locally unique tunnel-id value
!Range is 0-65,535
Provide a description
:router(config-if)# ?
address-family
affinity
auto-bw
autoroute
backup-bw
description
destination
fast-reroute
forwarding-adjacency
ipv4
load-interval
load-share
logging
mpls
path-option
path-protection
path-selection
policy-class
priority
record-route
service-policy
shutdown
signalled-bandwidth
signalled-name
Version 3.9.0a
XMPLST4Module 6/77
AFI/SAFI configuration
Link attributes for links traversed by tunnel
Enable tunnel auto-bandwidth and enter its submode
Parameters for IGP routing over tunnel
Fast-reroute backup bandwidth requirement
Set description for this interface
Specify tunnel destination
Specify MPLS tunnel can be fast-rerouted
Use the tunnel as forwarding adjacency
IPv4 interface subcommands
Specify interval for load calculation for an interface
Specify tunnel load-sharing metric
Per-interface logging configuration
MPLS interface subcommands
Primary or fallback path setup option
Enable the path protection feature on this tunnel
Path Selection Configuration
Specify classs for policy-based tunnel selection
Tunnel priority
Record the route used by the tunnel
Configure a service policy
shutdown the given interface
Tunnel bandwidth requirement to be signalled
The signaling name to assign to tunnel
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/78
687
Module 6
Assigning Tunnel IP Address

The two options for assigning an IP address to a Cisco MPLS TE tunnel
are specifying a particular address as you would any interface, or
associating the tunnel with a more accessible address, such as a loopback
address. For the tunnel to come active and be usable, you must configure
at least one of the parameters:
addressSet a specific IPv4 address and mask of the interface
unnumberedEnable IPv4 processing without an explicit address.

Effectively, this means use whatever address is assigned to the entity
value entered. For example, it is common to use a loopback address
here because it typically means that address is locatable. However,
physical (POS and Gigabit Ethernet are examples) as well as other
tunnels, bundles, or ATM interfaces may be used.
There are other optional parameters available within the IPv4

configuration that are not covered in this course:
688
directed-broadcastEnable forwarding of directed broadcasts
helper-addressSpecify a destination address for UDP broadcasts
mask-replyEnable sending ICMP mask reply messages
mtuSet IPv4 Maximum Transmission Unit (MTU)
redirectsEnable sending ICMP Redirect messages
unreachableEnable sending ICMP Unreachable messages
Version 4.0.1

Module 6
Assigning Tunnel IP Address
:router(config-if)#
ipv4 unnumbered interface-id

:router(config-if)# ipv4 unnumbered loopback0
IP address must be assigned for tunnel to activate
!Most common is unnumbered interface, loopback, for

reliability
!May use an actual IPv4 address
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/78
689
Module 6
Displaying Tunnel IP Address Information

Use the show ipv4 interface brief command to display all the IP
interfaces configured. You can see in this illustration that the configured
Cisco MPLS TE tunnels stand out, because they show up near the top of
the list. You can also see here that the Loopback0 address was assigned to
the tunnel interface te45. The tunnel is down now. You will see ways to
determine why the tunnel is down.
Displaying Tunnel Information

The show ipv4 interface tunnel-te45 command displays the same
information you see when displaying any interface, including more specific
address information and the MTU size.
690
Version 4.0.1

Module 6
Displaying IP Address and Tunnel Information
[output omitted]
:router# show ip interface brief
Addresses the same
Interface
Loopback0
tunnel-te45
IP-Address
10.4.4.4
10.4.4.4
Status
Up
Down
Protocol
Up
Down
POS0/3/0/0
POS0/3/0/1
POS0/3/0/2
unassigned
192.168.24.4
192.168.34.4
Up
Up
Up
Up
Up
Up
POS0/3/0/3
POS0/3/0/4
POS0/3/0/5
POS0/3/0/6
192.168.14.4
unassigned
unassigned
unassigned
Up
Shutdown
Shutdown
Shutdown
Up
Down
Down
Down
POS0/3/0/7
unassigned
unassigned
unassigned
192.168.146.4
Down
Shutdown
Shutdown
Up
Down
Down
Down
Up
unassigned
unassigned
unassigned
unassigned
Shutdown
Up
Up
Shutdown
Down
Up
Up
Down
unassigned
Shutdown
Down
Version 3.9.0a
XMPLST4Module 6/80
:router# show ip interface tunnel-te45

Thu Mar 18 01:47:20.340 UTC
tunnel-te45 is Down, ipv4 protocol is Down
Vrf is default (vrfid 0x60000000)
Interface is unnumbered. Using address of Loopback0 (10.4.4.4/32)
MTU is 1500 (1500 is available to IP)
Helper address is not set
Directed broadcast forwarding is disabled
Outgoing access list is not set
Inbound access list is not set
Proxy ARP is disabled
ICMP redirects are never sent
ICMP unreachables are always sent
ICMP mask replies are never sent
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/81
691
Module 6
Assigning Tunnel Destination Address

Each tunnel needs a destination or endpoint. The destination must be a
unique Cisco MPLS TE router ID. You should not use a Cisco MPLS TE
link address.
692
Version 4.0.1

Module 6
Assigning Tunnel Destination Address
:router(config-if)#
destination ip-address
:router(config-if)# destination 10.5.5.5
Each tunnel needs an endpoint or destination

Destination address must be MPLS-TE router ID of
destination router
:router# show mpls traffic-eng tunnels

Name: tunnel-te45 Destination: 10.5.5.5
Status:
Admin:
up Oper:
up
Path: valid
Signalling: connected
path
option
20,reserved.
type dynamic (Basis for Setup,
path weight 2)
Version 3.9.0a
2011, Cisco
Systems,
Inc. All rights
G-PID: 0x0800 (derived from egress interface properties)
Bandwidth Requested: 10000 kbps CT0
Config Parameters:
Bandwidth:
10000 kbps (CT0) Priority: 5 3 Affinity: 0x0/0xffff
Metric Type: TE (default)
AutoRoute: enabled LockDown: disabled
Policy class: not set
Forwarding-Adjacency: disabled
Loadshare:
0 equal loadshares
Auto-bw: disabled
Fast Reroute: Disabled, Protection Desired: None
Path Protection: Not Enabled
History:
Tunnel has been up for: 1w1d
Current LSP:
Uptime: 1w1d
Reopt. LSP:
Last Failure:
LSP not signalled, identical to the [CURRENT] LSP
Date/Time: Wed Oct 13 16:29:33 UTC 2010 [1w1d ago]
Path info (OSPF lab area 0):
Hop0: 192.168.24.2
Hop1: 192.168.25.5
Hop2:
10.5.5.5
Version 3.9.0a
2011, Cisco
Systems,
Inc. All rights reserved.
Version 4.0.1
[output omitted]
XMPLST4Module 6/83
XMPLST4Module 6/84
693
Module 6
Setting Tunnel Bandwidth

Each tunnel needs bandwidth. However, it is possible to create zerobandwidth tunnels and they will use whatever bandwidth is available at
the time that the traffic flows. The bandwidth for a tunnel is configured in
kilobits. The bandwidth will be used from the global pool reserved by the
RSVP settings. The range is from 0 to 4,294,967,295 kilobits.
Using a class type, you may set the DS-TE pools to take advantage of
prioritizing traffic. The class type parameter lets you use bandwidth from
the global-pool by using class-type 0, and from the sub-pool by using classtype 1. Class-type 1, or sub-pool traffic, cannot use a bandwidth setting of
zero, so its range is from 1 to 4,294,967,295.
Traffic Engineering Bandwidth

Earlier in this module, you saw how to allocate bandwidth on links using
RSVP. From that reserved bandwidth, you create Cisco MPLS TE tunnels
with specific bandwidth from the available pool. The illustration shows
tunnels are carved from RSVP bandwidth reserved from the intrinsic
bandwidth of the link. Depending on your network configuration, some of
the reserved RSVP bandwidth may be used for DS-TE tunnels.
Other traffic uses whatever non-reserved bandwidth is available.
Instructor's Note
The instructor should discuss an explanation of the pools, how they work and how they
complement each other.
Slide Animation: Click 1 TE tunnels text appears; followed by dark blue tunnels within RSVP
bandwidth and arrow; followed by Unused bandwidth and arrow
694
Version 4.0.1

Module 6
Tunnel Bandwidth
:router(config-if)#
signalled-bandwidth {bandwidth [ class-type ct ] | sub-pool bandwidth}

:router(config-if)# signalled-bandwidth 4000
Tunnel bandwidth defaults to 0 kbps
! Unless configured
Bandwidth is in kilobits
! Range is 0-4294967295
! Reserved in global-pool
Class type refers to pool to be used for DS-TE
! Values are 0 or 1
" Type 0 is global-pool

" Type 1 is sub-pool
! Sub-pool bandwidth range is 1-4294967295

Version 3.9.0a
XMPLST4Module 6/86
TE tunnels bandwidth taken from RSVP bandwidth

Unused portion of RSVP bandwidth may be used by other
signaled traffic
- DSCP
Other bandwidth designations remain the same

RSVP reservations for MPLS-TE have no affect on QoS policies
TE
tunnels
Physical
link
RSVP
bandwidth
Version 3.9.0a
Version 4.0.1
Unused b/w
for other
RSVP signaled
traffic: DSCP
XMPLST4Module 6/88
695
Module 6
Tunnel Priorities
You may set tunnel set up priorities with a value in the range of 0 to 7. The
lower the priority of the tunnel the higher (better or more important) the
value of the tunnel. Likewise, a higher priority tunnel presents a less
important tunnel. The tunnel priority configuration uses two parameters,
defined here:
Setup - priority for taking a resource
Hold - priority for holding a resource
Tunnel Preemption
Headend and midpoint routers may preempt tunnels of a lower hold

priority (less important and not numerically lower) when a tunnel of a
higher setup priority needs to be established and does not have sufficient
bandwidth. Preemption applies to the RDM of bandwidth allocation, not
MAM. The concept of make-before-break, discussed later, is not used.
The preempted tunnel is shut down until the headend router re-signals a
new LSP for the tunnel and reinstalls it, based on the tunnel parameters.
696
Version 4.0.1

Module 6
Tunnel Priorities
Priorities assigned to tunnels range from 0 (highest) - 7 (least)

Two types of priorities
! Setup
" Possible to preempt existing tunnels
! Hold
" Possible to keep tunnel despite another request
Setup priority
! Primarily used for bandwidth reservation

! High-priority tunnels can preempt low-priority ones in RDM
How important is it to set up tunnel A at the expense of tunnel

B which is already established and holding reservation on a
link?
! If bandwidth is unavailable and tunnel A has a better setup

priority than the hold priority of tunnel B, the latter will be
preempted
Default priority is Setup = 7, Hold = 7
! Setup < hold priority is invalid
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/89
697
Module 6
Preemption Steps
Here you see what happens when a tunnel is preempted by another tunnel,
and how the tunnel headend learns about the tunnel preemption.
Headend Behavior
The RSVP PathErr message travels upstream to the headend, reporting
errors in processing the Path message. The message passes through each
node without changing the state of the path until it reaches the originating
router. The headend matches the PathErr information against the latest
Cisco MPLS TE topology from the IGP database, determining available
bandwidth and the destination accessibility. The headend should attempt
to bring up the tunnel using some other path; typically using a different
outgoing interface.
Midpoint Behavior
A midpoint is any router that is not the headend or tailend of the tunnel.
There may be many midpoint routers in the path.
A PathErr message is an advisory message, but uses reliable messaging
(Prec-6) so that it is not lost, and reaches the sender. In the preemption
scenario, the midpoint notifies the headend of the preempted tunnel and
the link that is the source.
The midpoint sends a ResvTear message to the sender. The intent is for
upstream routers to clean up the associated reservations for this tunnel.
The midpoint sends a PathTear message downstream to the receiver to tell
routers along that path to clean up the resources. Because neither the
ResvTear nor the PathTear messages is reliable, the resources may not be
restored until the tunnel reservation is timed out when it is not refreshed.
Instructor's Note
If bandwidth is not available and a configuration such as EoMPLS with preferred TE tunnel is
configured, there is a question whether or not this traffic would flow at all using IP routing.
698
Version 4.0.1

Module 6
Preemption StepsHeadend and Midpoint Behavior
Headend behavior
Headend receives preemption PathErr message and

brings down the tunnel
TE topology updated with the receipt of OSPF LSA or IS-IS

TLV
!Indicates available bandwidth

!Destination still accessible
Headend attempts to bring tunnel up using best available
path option
!New path available
" Tunnel is brought up when LSP is signaled and set up
!No new path available
" Traffic may flow using regular IP path based on route
information
Version 3.9.0a
XMPLST4Module 6/91
Midpoint behavior
Midpoint sends PathErr, ResvTear, and PathTear
messages and cleans up LSP
PathErr tells the headend about preemption and link

that caused it
ResvTear tells upstream routers to clean up the

reservation states
PathTear tells downstream routers to do the same

Note: PathErr sent with reliable RSVP messaging and
will not be lost; PathTear and ResvTear are best effort
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/92
699
Module 6
Tunnel Priority and Preemption

Here is an example of what happens when one tunnel preempts another
during set up.
Initially, a tunnel is set up from R1 to R4 going through R2; the tunnel is a
high-priority tunnel, perhaps voice traffic. The tunnel request is for
150 kbps of bandwidth. The original bandwidth on each of the links
between R1 and R4 is 200 kbps. After the tunnel is up and operating only
50 kbps of bandwidth remains.
Now a low-priority tunnel requests 100 kbps of bandwidth from R3 to R5
using R2 as its midpoint. On the links of this path there is 200 kbps, so the
tunnel leaves 100 kbps available after it is up and operating.
Suppose that the link between R2 and R4 fails, resulting in the loss of the
high-priority tunnel between R2 and R4. Because the tunnel is high
priority, R1 will immediately attempt to set the tunnel up again. R1
signals for a new tunnel from R1 to R2 to R5 to R4, requesting 150 kbps of
bandwidth.
However, the link between R2 and R5 does not have sufficient bandwidth
to support the request because of the presence of the green tunnel. But the
blue tunnel has a higher priority and preempts the green tunnel. R2 tears
down the green tunnel, notifying R3 that it has done so. R2 proceeds to set
up the blue tunnel with 150 kbps of bandwidth to R5 and R5 sets up a
150 kbps tunnel to R4 and the traffic resumes from R1 to R4.
Meanwhile, R3 attempts to set up the green tunnel on a different path, R3
to R4 to R5, which is successful.
Remember that the tunnels are symmetrical, so bandwidth is needed in
both directions. In the example, the common link for the tunnels is
between R5 and R4 and there is sufficient bandwidth to support both the
tunnels.
6100
Version 4.0.1

Module 6
Tunnel Priority and Preemption
R1
R2
100 Kbps
200 Kbps
R3
50 Kbps
200 Kbps
50 Kbps
100 Kbps
200 Kbps
100 Kbps
200 Kbps
50 Kbps
200 Kbps
High priority!150 Kbps request

Low priority!100 Kbps request
R5
300 Kbps
150Kbps
R4
Tunnels are symmetrical
!But is the bandwidth deduction?
Version 3.9.0a
XMPLST4Module 6/94
Instructor's Note
Slide animation: Click 1 Solid blue arrow R1-R2-R4 appears; Click 2 Bandwidth on each
link changes from 200 to 50; Click 3 Green arrow R3-R2-R5 appears; Click 4 Bandwidth goes
from 200 to 100; Click 5 Red X appears on link R2-R4; 50kbps R2-R4 disappears; solid blue
arrow disappears; B/W R1-R2 returns to 200kbps; Click 6 Dashed blue arrow R1-R2-R5-R4
appears; Click 7 Green arrow disappears; blue arrow becomes solid; Click 8 B/W R1-R2 goes
200 to 50, R2-R5 goes 100 to 50, R5-R4 goes 300 to 150; Click 9 B/W R2-R3 goes 100 to 200;
Click 10 Dashed green arrow, R3-R4-R5; Click 11 Green arrow becomes solid, B/W R3-R4
goes 200 to 100, R4-R5 stays at 150
Version 4.0.1
6101
Module 6
Setting Tunnel Priority

When a tunnel is signaled, it may encounter a link that does not have the
required bandwidth. However, the link may already be supporting other
tunnels. If the setup priority of the new tunnel is higher than the hold
priority of an existing tunnel, the existing tunnel will be torn down in favor
of the new tunnel. In fact, more than one tunnel may be affected, until
there is enough bandwidth to support the higher priority tunnel. After the
new tunnel is up, it will stay in place until a tunnel with higher priority
attempts to come up.
Often, you may use a higher priority for setup and a lower priority for hold.
This allows you to set up the tunnel by preempting other tunnels when
required, but let the tunnel be taken down if a more important tunnel is
needed.
Typically, tunnels are set up with the same value for both their setup and
hold priority. Setup priority cannot be smaller than hold priority.
To configure the tunnel priority, use the priority command in the tunnel
interface context.
6102
Version 4.0.1

Module 6
Setting Tunnel Priority
:router(config-if)#
priority setup-priority hold-priority
:router(config-if)# priority 1 1
:router(config-if)#
Tunnel priority
!Range is 07
" Lower the number; higher the priority
!SetupThis tunnel may preempt another
!HoldThis tunnel may be preempted by another
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/95
6103
Module 6
Path Calculation
The path calculation or PCALC is a modified version of the Dijkstra
algorithm used with IS-IS and OSPF. It uses a graphical method of
determining the lowest cost path from a source to a destination. The
shortest path calculation for resolving Cisco MPLS TE paths (LSPs) is the
CSPF calculation.
When the calculation occurs, there is a possibility that more than one path
may meet the minimum requirements. PCALC finds all the paths in the
database with the lowest IGP cost. It looks at the minimum bandwidth
available on each link and selects the highest. PCALC then chooses the
lowest number of hops for the path; actual physical hops, not an IGP cost.
Finally, if there are still multiple available paths, it randomly chooses one.
The PCALC process is illustrated on the next few pages.
6104
Version 4.0.1

Module 6
Path Calculation
Modified Dijkstra algorithm runs at tunnel headend

Often referred to as CSPF
Constrained SPF
PCALC (path calculation)
What if there is more than one path that meets the minimum
requirements, such as bandwidth?
PCALC algorithm:
1. Find all paths with the lowest IGP cost

2. Pick the path with the highest minimum bandwidth along the
path
3. Pick the path with the lowest hop count (not IGP cost, just
hop count)
4. Pick one path at random
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/96
6105
Module 6
Path CalculationPart 1
In the example on this and the subsequent pages, you see how the PCALC
algorithm works with the help of an example.
You determine the best path from R1 to R2 given the network illustrated.
In each path, the link outbound from R1 has a cost of 10 and 100 Mbps of
bandwidth. On the other side of the network, the inbound links to R2 all
have a cost of 5 and 50 Mbps of bandwidth.
The path you want to create requests 20 Mbps of bandwidth.
Because all of the R1 outbound costs are equal, and all of the R2 inbound
costs are equal, the calculation centers on the middle of the network. As
you can see, the topmost link has a cost of 10, which is not the lowest cost
for a path. Previously, you learned that the first step of PCALC is to find
all the paths with the lowest cost. In this illustration, the four lower paths
each have a cost of 8, which is equal, and the lowest of the five available
paths.
6106
Version 4.0.1

Module 6
What is the best path from R1 to R2

with bandwidth of 20 Mbps (M)?
Path cost of 10
is not the
lowest cost
{10,100M}
}
,5
,10
0M
M}
}
{5, 50M
}
0M
5
,
{5
,10
0
0M
{10
{4,90M}
R2
50M
{8,90M}
,5
{10
{4,90M}
{5,
{10,100M}
0M
{8,80M}
00M
{10,1
R1
{5
0M
{5
{1
0
0,1
{8,90M}
{cost, available b/w}

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/97
6107
Module 6
Now the most costly path has been removed from the illustration. PCALC
now looks for the path with the highest minimum bandwidth. In this
example, the topmost path has 80 Mbps, whereas the lower three each
have 90 Mbps bandwidth.
So the top path will be eliminated.
6108
Version 4.0.1

Module 6

Path b/w less

than the other
paths
{8,80M}
00M
{10,1
,10
0M
,10
0
M}
}
{5, 50M
}
0M
5
,
{5
{10
{4,90M}
0M
{10
{4,90M}
R2
50M
{8,90M}
,5
{10,100M}
{5,
{5
R1
{8,90M}

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/98
6109
Module 6
The next part of the calculation is to pick a path that is the actual lowest
hop count, meaning nodes, not IGP cost. The key reason for this choice is
lower overhead, and it minimizes the links and nodes that might fail and
disrupt the traffic in the tunnel.
So once again the topmost path is eliminated because it has three nodes in
the path, while the other paths have two nodes each.
6110
Version 4.0.1

Module 6

Hop count for this path is 4;
more than the other paths
R1
R2
,10
0M
M}
,10
0
}
{5, 50M
}
0M
5
,
{5
0M
{10
{4,90M}
{8,90M}
,5
{10
{4,90M}
{5
{10,100M}
{8,90M}

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/99
6111
Module 6
Finally, you are left with two possible paths. Each of these paths is equal
in every way. The PCALC algorithm now chooses a path by random.
6112
Version 4.0.1

Module 6

Choose a path at
random
R1
R2
{5
{8,90M}
M}
0M
0M
0
,5
,5
,10
,10
0
{5
{10
{10
{8,90M}

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/100
6113
Module 6
Path CalculationResult
In the example, continue the previous pattern, and eliminate the topmost
path, leaving the bottom path as the one on which you set up your LSP.
6114
Version 4.0.1

Module 6
Path CalculationResult

R1
0M
0M
,5
,10
{5
{10
R2
{8,90M}

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/101
6115
Module 6
Setting the Path Option

The path option provides you with multiple paths for a single tunnel. You
may configure multiple explicit paths and a dynamic option. The priority
number refers to path preference and is based on the rule, lower the
number, higher the priority. If a lower path option fails, the tunnel is
automatically set up using the next option. The exception is the lockdown
feature that does not allow for reoptimization of the tunnel.
Here are some parameters for the path-option command:
6116
preference-priorityPath preference option number from 1 to 1000
protectingSpecific option number to protect a path; range is

1 to 1000
dynamicOption to use the best dynamically calculated path
pcePath Computation Element (PCE)
address ipv4Configures an IPv4 PCE address
explicitSpecific path for the tunnel; the actual path is configured

separately
nameName of an explicit path
identifierSpecific path number for an explicit path
isisLimits the CSPF algorithm to a single IS-IS instance
levelConfigures the IS-IS level, either 1 or 2
lockdownSpecifies the path cannot be reoptimized
ospfLimits the CSPF algorithm to a single OSPF instance
areaConfigures the area for the OSPF instance
verbatimBypasses the topology or CSPF check when configuring an

explicit path
Version 4.0.1

Module 6
Setting the Path Option
:router(config-if)#
path-option preference-priority [protecting number] {dynamic [pce [address

ipv4 address]] | explicit {name path-name | identifier path-number }} [isis
instance level level ] [lockdown] [ospf instance area {value | address}] [verbatim]
:router(config-if)# path-option 100 dynamic
Provide multiple paths for a tunnel
!Dynamic uses the best path calculation

!Explicit is a static path
!Lower path number is preferred
!Cisco leading practiceUse higher number for preferencepriority not 1
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/102
6117
Module 6
Getting Traffic into a Tunnel

Typically, there are four ways of traffic getting into a tunnel:
6118
AutorouteMethod makes the tunnel part of the available paths to

the destination address without using the IGP. Because tunnels are
unidirectional, there is no valid way in which to use the tunnel as part
of the regular routing protocol. Autoroute makes the destination
available to traffic on the router bound for the destination address or
any other address behind that destination
Static routePrefix is entered into the routing table and traffic for
that destination takes this route
Forwarding adjacencyCisco MPLS TE tunnels are configured

across a core of routers and usually in a single area (multiple areas are
discussed later). But for other routers to take advantage of the tunnels
that are available, there needs to be a way for the routers to know
about the tunnel and use it in a route calculation. Forwarding
adjacency handles this
Policy-based tunnel selection (PBTS)Specific criteria to decide to

which tunnel to send certain traffic. Typically used when voice and
data traffic are in the same network. This module does not cover PBTS
Version 4.0.1

Module 6
Getting Traffic into a Tunnel
How do you get traffic to use a tunnel?
Autoroute
Static routes
Forwarding adjacency
EoMPLS tunnel selection
Other methods (not covered in this course)
!Policy-based tunnel selection (PBTS)

!QoS-based tunnel selection
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/103
6119
Module 6
Forwarding Packets into TE Tunnel

The illustration shows a packet arriving at R1 with a destination network
of 128.89.0.0/16. The destination network lies beyond R3 and R4. Looking
at the Cisco MPLS TE forwarding database (LFIB) you see two paths to
the destination network. One uses label 4 and interface 1 to send the
packet to R3. The other path uses a tunnel that has label 5 and the same
interface (1) and sends the packet to R4. In this example, the packet uses
the tunnel.
Thus, the packet arrives at R2 with a label of 5. Looking at the LFIB in R2,
you see that a packet with a label of 5, arriving at R2, has its label
swapped for a label of 7, and is sent out onto interface 1. R4 receives the
packet and swaps the label to send it to the destination network.
The decision, of which way to send the traffic, is based on the tunnel
configuration and its availability to traffic.
6120
Version 4.0.1

Module 6
Forwarding Packets into TE Tunnel
In
lbl
Address
prefix
Out
If
Out
lbl
In
lbl
Address
prefix
Out
If
Out
lbl
128.89
128.89
Tunnel path 1
...
...
...
...
...
...
...
...
Entry populated by TE
tunnel setup
R3
R1
R2
1
128.89.25.4
Data
128.89.25.4
128.89.25.4
To
128.89
Data
Data
LSR forwards based

on TE label
Version 3.9.0a
Version 4.0.1
R4
XMPLST4Module 6/104
6121
Module 6
Forwarding Adjacency
One of the ways to steer traffic along the paths you want is by using
forwarding adjacency.
TE tunnels are not advertised as part of the IGP, so changing metrics on
tunnels does not have the desired affect of load-balancing traffic or even
sending traffic along a particular path.
Further, having tunnels go from each router in the network to every other
router where you want them, is not a scalable option. So a better solution
is to create the tunnels at some higher level of the network where they may
be better utilized.
Forwarding adjacency lets you use the IGP to advertise tunnels
downstream, so networks outboard of these downstream routers can reach
networks outboard of the tunnel tailend.
In the illustration on the lower part of the opposite page, you see two
points of presence (POP 1 and POP 2) with a core network between them.
All the routers in the illustration are at IS-IS Level-2 and form
adjacencies. All the links in the illustration have the same administrative
weight of 10.
Without any Cisco MPLS TE involved, the traffic from R100 to R200 flows
over the path, R100-R1-R3-R200, because it is the shortest, least cost path.
To attempt to balance the traffic flow across both paths, you might create
two tunnels on the core routers that follow the R1-R3 and R2-R4 paths and
make their administrative weight equal. But R100 still has no way to know
about the tunnels (they are not advertised), so the traffic continues to flow
over the original path.
6122
Version 4.0.1

Module 6
Forwarding Adjacency
Headend and tailend must be at the same IS-IS

level or OSPF area
TE tunnels are not advertised by IGP
!Changing a tunnel metric does not help routers

choose different paths
Tunnels typically at higher level of network
!Area 0 or Level-2
!Scales better
Tunnels advertised in IGP by headend router to

downstream routers
!They can use them to reach networks at tailend

Version 3.9.0a
XMPLST4Module 6/106
Physical view
R100
R1
R200
R3
Create tunnels here

R2
R4
All links have administrative weight of 10

POP 2
POP 1
Logical view
R3
R1
R2
R4
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/107
6123
Module 6
What is needed is a way for R2 to learn about the tunnel paths so that it
may treat them equally and split the traffic over each as needed.
To accomplish that, you configure forwarding adjacency on the tunnels
created at the R1 headend. This permits the IGP to advertise the
availability of the tunnels to both R2 and R3; the tunnel is installed in the
topology database.
The forwarding-adjacency command has a holdtime parameter that is
associated with the forwarding-adjacency LSP. The parameter is optional
and its default value is zero milliseconds and has a range from 0 to
20,000 milliseconds.
There are caveats about the holdtime parameter and the possible delay of
the forwarding-adjacency notification to the IGP:
6124
No delay in notifying the IGP is incurred if forwarding-adjacency is

configured on a tunnel that is already up
No delay in notifying the IGP is incurred if forwarding-adjacency is

unconfigured (using the no form of the command) on a tunnel that is
already up
No notification to the IGP occurs when forwarding-adjacency is

configured on a tunnel that is down
Notification to the IGP is delayed for the period of the holdtime

(presuming nonzero hold time) when a tunnel that has
forwarding-adjacency configured comes up. When the holdtime
expires, the IGP is notified
Version 4.0.1

Module 6
Forwarding Adjacency (Cont.)
Physical view
R1
R3
Create tunnels here

R2
R4
POP 2
POP 1
Logical view
R3
R1
R2
R4
Version 3.9.0a
XMPLST4Module 6/109
:router(config-if)#
forwarding-adjacency [holdtime time]

:router(config-if)# forwarding-adjacency holdtime 60
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/110
6125
Module 6
Autoroute Announce
Autoroute announce is the automatic assignment of traffic based on the
IGP used in the network. It uses a modified SPF calculation. The tunnel
configured at the headend router appears the same as any interface.
During the SPF calculation, at the tailend, the next hop is set for the
interface associated with the end of the tunnel. Therefore, any
destinations, whose shortest paths use the tunnel, also use that interface
associated with the tunnel end at the tailend, as the next hop. Note that
the use of the tunnel does not alter the path metric in the routing table.
Autoroute Physical Topology

The illustration shows a physical network topology over which you create a
tunnel from Router A to Router G, so you reach either Router H or
Router I. After configuring the tunnel, it appears as a single link directly
connected from Router A to Router G.
No IGP adjacency is permitted over the tunnel. The autoroute concept is
limited to a single OSPF area or IS-IS level.
Autoroute Logical Topology

After the tunnel is created, the logical topology looks like the lower
illustration. The green tunnel (dotted arrow), Tunnel 1, is configured from
Router A to Router G over whatever LSP is used. The interim routers on
the path the tunnel takes, do not see the tunnel.
6126
Version 4.0.1

Module 6
Autoroute Physical and Logical Topology
Router B
Router F
Router H
Router E
Router A
Router G
Router C
Router I
Router D
Tunnel is treated as a directly connected link to the tailend
! For destinations behind the tunnel endpoint
IGP adjacency is not run over the tunnel
! Unlike an ATM or FR virtual circuit
Autoroute is limited
! OSPF single area

! IS-IS level only
Version 3.9.0a
XMPLST4Module 6/112
Router B
Router F
Router H
Router E
Router A
Router G
Router C
Router D
Router I
Router A view
!Tunnel to Router G
Other routers do not see the tunnel
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/113
6127
Module 6
Autoroute RIB Entries

Looking at the routing table from Router A, which has been built using the
autoroute process, you see Routers G, H, and I all using Tunnel 1. Notice,
also, that Routers H and I have a cost higher than Router G because they
are behind Router G.
Autoroute and Multiple Paths

Suppose that a link is added between Router F and Router H. Nothing
changes with respect to the routing table. Two paths, over which load
balancing might take place, are available.
The table in the illustrations shows that two paths may reach Router H,
each with a cost of 40. One path is now Router A to Router G using the
Tunnel 1, and then Router G to Router H. The other path is Router A to B
to E to F to H.
If the tunnel administrative cost is altered, the picture changes again.
6128
Version 4.0.1

Module 6
Autoroute RIB Entries and Multiple Paths
Node
B
C
D
E
F
G
H
I
Next-hop
B
C
C
B
B
Tunnel 1
Tunnel 1
Tunnel 1
Cost
10
10
20
20
30
30
40
40
Router A routing table
!Built using autoroute
Everything behind
the tunnel end is routed

using the tunnel
Router B
Router F
Router H
Router E
Router A
Router G
Tunnel 1
Router C
Router I
Router D
Version 3.9.0a
Node
B
C
D
E
F
G
H
H
Next-hop
B
C
C
B
B
Tunnel 1
Tunnel 1
B
Cost
10
10
20
20
30
30
40
40
Tunnel 1
40
XMPLST4Module 6/115
Presume a link from F to H
!Router A would have two paths to H

" A->G->H
" A->B->E->F->H
!Nothing else changes

Link added
Router B
Router F
Router H
Router E
Router A
Router G
Tunnel 1
Router C
Router D
Version 3.9.0a
Version 4.0.1
Router I
XMPLST4Module 6/116
6129
Module 6
Configuring Autoroute Announce Option

You still need to let the IGP know about the available tunnel so that the
traffic can use it. Or to put it another way, treat the tunnel as a direct link
between the headend router and the tailend router. Because the tunnel is
unidirectional, you cannot run the IGP on this tunnel like any other
interface.
The autoroute announce command does just that; it specifies that the
IGP should use the tunnel in its CSPF calculation.
6130
Version 4.0.1

Module 6
Configuring Autoroute Announce Option
:router(config-if)#
autoroute announce
:router(config-if)# autoroute announce

:router(config-if)#
IGP uses the tunnel in path calculation
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/117
6131
Module 6
Display Cisco MPLS TE Autoroute Information

You can use the show mpls traffic-eng autoroute command to display
the autoroute tunnels the IGP uses in the CSPF calculation. The tunnels
are organized by their destination.
The fields shown in the illustration are:
6132
DestinationCisco MPLS TE tailend router ID
Traffic shareFactor, based on bandwidth, of the amount each

tunnel uses relative to other tunnels. Two tunnels going to the same
destination, one with a one share and the second with a two share,
means the second is carries two-thirds of the traffic. In the illustration,
each tunnel carries 50 percent.
Version 4.0.1

Module 6
Display Cisco MPLS TE Autoroute Information
:PE4# show mpls traffic-eng autoroute

Wed Apr 21 23:05:02.525 UTC
Destination 10.5.5.5 has 2 tunnels in OSPF lab area 0
tunnel-te45 (traffic share 1, nexthop 10.5.5.5)
tunnel-te452 (traffic share 1, nexthop 10.5.5.5)
Destination is MPLS TE tailend router ID

Traffic share is bandwidth usage relative to other
tunnels
Next hop is next hop router ID of the tunnel

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/118
6133
Module 6
Static Routing
Another way to get traffic into a Cisco MPLS TE tunnel is by using static
routing. You create a static route using the tunnel exactly as you would
any other interface.
In this illustration, the administrative cost of each link between routers is
10. Using the IGP, both R8 and R9 are each reached at a cost of 40, no
matter which path is used.
To route the traffic for R8 and R9 over a specific path you want, you create
a tunnel between R1 and R7, using the desired path for the traffic. The cost
remains the same. R7, however, is not reached using the tunnel, but by
using the IGP, even though R7 is the tunnel endpoint.
You see the result in the routing table display for R1.
The configuration takes place in router static mode when you enter the
router ID representing the networks you want to reach, and point the
destination ID at the tunnel, in this case, Tunnel1. Note that you must
configure this in the address family you want to support. In this example,
you configure for IPv4 unicast traffic.
6134
Version 4.0.1

Module 6
Static Routing
Node
2
3
4
5
6
7
8
9
Next-hop
2
3
3
2
2
2
Tunnel1
Tunnel1
Cost
10
10
20
20
30
30
40
40
R8 and R9 are reached

using the tunnel
R7 is not reached using

the tunnel
R2
-Uses IP routing
-Yet still tunnel tail
R6
R1
R8
R5
Tunnel1
R7
R9
R3
R4
Version 3.9.0a
XMPLST4Module 6/120
:router(config-static-af)#
Ipv4-address/mask [vrf vrf-name] {ipv4-address | interface-id} [distance]

[description text] [tag tag] [permanent]
:router(config-static)# address-family ipv4 unicast

:router(config-static-af)# 10.8.8.8/32 Tunnel1
:router(config-static-af)# 10.9.9.9/32 Tunnel1
Enter static routing mode

Enter the address family mode
Configure the static route to use the tunnel
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/121
6135
Module 6
Reviewing TE Tunnel Configuration and Operation

In this section, you see the results of the configuration of Cisco MPLS TE
tunnels using show commands.
Displaying Cisco MPLS TE TunnelsNot Valid

The show mpls traffic-eng tunnels command is a key command in
establishing the status of the tunnels you create and use. The output
shows the status, bandwidth requested, configuration parameters, and any
path calculation issues. You see that the tunnel is a dynamic.
In the illustration of the command, you see that while the path is
administratively up, it is operationally down, as is the signaling. The
display indicates that the path is invalid. The reason is the PCALC error
finds no path to the destination because of bandwidth.
The available bandwidth is a function of RSVP, you need to check that
next.
Displaying RSVP InterfacesNo Bandwidth

Using the show rsvp interfaces command, you see three interfaces
configured, but none have any bandwidth reserved. The information fields
displayed by the command are these:
6136
InterfacePhysical interfaces configured for RSVP
MaxBWMaximum reservable bandwidth for the interface
MaxFlowMaximum bandwidth allowed to a single flow
AllocatedAmount of bandwidth currently in use by the tunnels
MaxSubMaximum bandwidth of the subpool
Version 4.0.1

Module 6
Displaying Invalid TE Tunnels and RSVP Interfaces Without Bandwidth
[output omitted]
:PE3# show mpls traffic-eng tunnels

Name: tunnel-te36
Destination: 10.6.6.6
Status:
Admin:
up Oper: down
path option 10,
Path: not valid
Signalling: Down
type dynamic
Last PCALC Error: Wed Apr 21 22:53:15 2010
PE3
P1
PE5
PE4
P2
PE6
Info: No path to destination, 10.6.6.6 (bw)

Bandwidth Requested: 50000 kbps
CT0
Config Parameters:
Bandwidth:
50000 kbps (CT0) Priority:
5 Affinity: 0x0/0xffff

AutoRoute:
enabled
LockDown: disabled
Loadshare:
0 equal loadshares
Auto-bw: disabled
Fast Reroute: Disabled, Protection Desired: None
Displayed 1 (of 1) heads, 0 (of 0) midpoints, 0 (of 0) tails
Displayed 0 up, 1 down, 0 recovering, 0 recovered heads
Version 3.9.0a
XMPLST4Module 6/124
:PE3# show rsvp interfaces

Wed Apr 21 23:05:02.525 UTC
Interface
MaxSub (bps)
----------- ----------- ------------- -------------------- -----------PO0/3/0/1
0 (
0%)
PO0/3/0/2
0 (
0%)
PO0/3/0/3
0 (
0%)
PE3
P1
PE5
PE4
P2
PE6
RSVP interfaces created when MPLS TE

interfaces are configured
No RSVP bandwidth configured
- Must configure bandwidth
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/125
6137
Module 6
Displaying RSVP InterfacesBandwidth

In this illustration, you see that bandwidth has been configured for all the
interfaces and allocated for tunnel traffic on one of the interfaces,
POS0/3/0/3. The bandwidth allocated is 10 percent of the available
bandwidth.
Displaying Cisco MPLS TE TunnelsValid

Now you see a tunnel that is administratively and operationally up, with a
valid path and signaling that it has connected. You also see that the
bandwidth requested is the same as in the RSVP interface display for
allocated bandwidth.
After the path is made valid by the addition of the bandwidth in RSVP and
the tunnel goes active, you see the path the tunnel takes.
Notice also the tunnel history and current uptime.
6138
Version 4.0.1

Module 6
Displaying RSVP Interfaces with Bandwidth and Valid Tunnels
:PE3# show rsvp interfaces

Wed Apr 21 23:18:30.398 UTC
Interface
MaxSub (bps)
----------- ----------- ------------- -------------------- -----------PO0/3/0/1
50M
50M
PO0/3/0/2
50M
50M
PO0/3/0/3
50M
50M
0 (
0%)
0 (
0%)
5M ( 10%)
PE3
P1
PE5
PE4
P2
PE6
RSVP interfaces with bandwidth

configured
Tunnel bandwidth allocated
[output omitted]
:PE3# show mpls traffic-eng tunnels

Name: tunnel-te36
Status:
Admin:
up Oper:
path option 10,
up
Path:
type dynamic
valid
(Basis for Setup, path weight 2)

Bandwidth Requested: 5000 kbps
CT0
Config Parameters:
Bandwidth:
5000 kbps (CT0) Priority:
5 Affinity: 0x0/0xffff

[output omitted]
History:
Tunnel has been up for: 00:02:07
PE3
P1
PE5
PE4
P2
PE6
Current LSP:
Uptime: 00:02:07
Path info (OSPF lab area 0):
Hop0: 192.168.23.2
Hop1: 192.168.26.6
Hop2: 10.6.6.6
Version 4.0.1
6139
Module 6
Displaying RSVP Sessions

You can use the show rsvp session command to review the general
information about the tunnels that RSVP supports. The command output
shows you information:
TypeType of data flow, LSP, IPv4, or Optical User Network Interface

(O-UNI)
Destination addressDestination of the traffic and tail of the tunnel
DPortDestination port or tunnel ID for Cisco MPLS TE and O-UNI)
Proto/ExtTunIdSource address of tunnels or IPv4 traffic
PSBsPath state blocks for the session
RSBsReservation state blocks for local reservations for the session
ReqsNumber of requests representing reservations sent upstream
The two illustrations represent the headend, tailend, and midpoints of the
tunnel.
6140
Version 4.0.1

Module 6
Displaying RSVP Sessions
:PE3# show rsvp session dest 10.6.6.6

Type Destination Add DPort
Proto/ExtTunID
PSBs
RSBs
Reqs
---- --------------- ----- --------------- ----- ----- ----LSP4
10.6.6.6
Headend
36
10.3.3.3
PE5
P1
PE3
Dynamic tunnel
from PE3 to PE6
P2
PE4
PE6
Tailend
:PE6# show rsvp session dest 10.6.6.6

Proto/ExtTunID
PSBs
RSBs
Reqs
---- --------------- ----- --------------- ----- ----- ----LSP4
10.6.6.6
36
10.3.3.3
Version 3.9.0a
PE3
P1
PE5
PE4
P2
PE6
XMPLST4Module 6/130
Midpoint
:P2# show rsvp session dest 10.6.6.6
Proto/ExtTunID
PSBs
RSBs
Reqs
---- --------------- ----- --------------- ----- ----- ----LSP4
10.6.6.6
36
10.3.3.3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/131
6141
Module 6
Displaying RSVP Neighbors

This illustration displays the RSVP neighbors from each of the points
along the LSP for the tunnel. You use the show rsvp neighbor command
to see this information.
The display includes the neighbor ID, the interface IP address of the
neighbor, and the physical interface used to reach the neighbor.
Use the detail keyword to see additional information.
6142
Version 4.0.1

Module 6
Displaying RSVP Neighbors
PE3
:PE3# show rsvp neighbor
PE5
P1
Global Neighbor: 10.2.2.2

Interface Neighbor
Interface
-------------------- -----------192.168.23.2
PE4
P2
POS0/3/0/3
PE6
:P2# show rsvp neighbor
:PE6# show rsvp neighbor
Interface Neighbor
Interface Neighbor
Interface
Interface
-------------------- ------------
-------------------- ------------
192.168.23.3
192.168.26.2
POS0/3/0/3
POS0/3/0/7

Interface Neighbor
Interface
-------------------- -----------192.168.26.6
POS0/3/1/1
Neighbor established when Path or

Resv message sent or received
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/132
6143
Module 6
Cisco MPLS TE Explicit Tunnels

In this section, you learn about explicit paths and how they are used in
both a single area and between areas.
Cisco MPLS TE explicit path lets you choose the path for the tunnel by
configuring it specifically. It uses the ERO in the RSVP Path and Resv
messages. How does ERO come into play?
If the explicit path option is used, the Cisco MPLS TE topology

database is used to verify the Explicit Path
If the dynamic path option is used, the Cisco MPLS TE topology

database is used to compute the Explicit Path
An explicit path may mean different things depending on how you

implement it:
Implementing an explicit path tunnel with all exclude addresses is the

same as a dynamic tunnel
Implementing an explicit path tunnel with router IDs and a choice of

multiple links between a pair of routers is the same as a dynamic
tunnel
Implementing an explicit path tunnel with loose addressing is the same

as a dynamic tunnel
Implementing multiple path-option commands is the same as a

dynamic tunnel
When you use explicit tunnels, you must decide if the traffic using the
tunnel is important enough to have a backup path. Backup tunnels will be
discussed later in this module.
Cisco MPLS TE Intra-Area Explicit Tunnels

In this example, you choose to send traffic across the POS link from R3 to
R1; then across the Gigabit Ethernet link from R1 to R2 and finally across
the POS link from R2 to R6. Although there is a direct link between R3
and R2, you want to take advantage of the bandwidth that the Gigabit
Ethernet link offers.
Explicit paths use a concept of strict or loose hops to define each of the
hops in the path. By default, all hops are strict. Strict hops are for intraarea tunnels, where the head router can see the topology and find the best
path to each strict hop specified, and then the specified destination.
6144
Version 4.0.1

Module 6
Cisco MPLS TE Intra-Area Explicit Tunnels
Intra-area tunnel
! Path within the same area
Strict hop
192.168.13.1
R3
R1
POS
OSPF Area 0
GigE
POS
192.168.112.2
POS
192.168.23.2
R2
Version 3.9.0a
Version 4.0.1
192.168.26.6
R6
XMPLST4Module 6/135
6145
Module 6
Creating Explicit Paths

An explicit path configuration is a separate list of hops that the path takes
to go from the headend to the tailend router. The configuration of the
explicit path uses either a name or an identifier for later recognition. The
identifier is a numeric value with a range from 1 to 65,535.
In explicit path configuration mode, an index value between 1 and 65,535
is used to order the addresses to be used.
Following the index value is either a next-address or an
exclude-address parameter. Explicit paths may include addresses that
lay out the path or it may exclude addresses so that a particular node is
bypassed. You may also combine include and exclude parameters to force
traffic over certain paths. In either case, an IPv4 address is used.
Currently, IPv6 addresses are not used.
Strict Hop
Remember to use strict hop in a single area where the headend sees the
entire topology.
Loose Hop
Inter-area Cisco MPLS TE allows you to configure inter-area Cisco MPLS

TE LSPs by specifying a loose source route of Area Border Routers (ABRs)
along the path. It is the responsibility of the ABR (having a complete view
of both areas) to find a path that obeys the Cisco MPLS TE LSP
constraints within the next area to reach the next hop ABR (as specified on
the headend). The same operation is performed by the last ABR connected
to the tailend area to reach the tailend LSR.
Be aware of these considerations when using loose hop optimization:
6146
The router ID of the ABR node (as opposed to a link address on the
ABR) must be specified
Cisco MPLS TE must be enabled in the subarea for Cisco MPLS TE to

find a path when loose hop is specified with multi-area deployed in a
network that contains multiple subareas
A reachable explicit path for the inter-area tunnel must be specified
Version 4.0.1

Module 6
Creating Explicit Paths
:router(config)#
explicit-path {identifier number | name pathname}

:router(config-expl-path)#
index index-id next-address [[loose | strict] ipv4 unicast] ipv4-address

index index-id exclude-address {ipv4 unicast ipv4-address}
:router(config)# explicit-path name path3126
:router(config-expl-path)# index 5 next-address 192.168.13.1
Create a TE path list
!
!
Use a numeric identifier

Use a name
index-id is the hop number
!
!
Range is 165,535
Account for path change or expansion
next-address ipv4-address is next hop

Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/136
6147
Module 6
Creating Explicit Cisco MPLS TE Tunnels

You use the interface tunnel-te command to create the actual tunnel just
as you did for dynamic tunnels earlier. The key difference is in specifying
path-option, which is set to explicit followed by the explicit path name
created earlier.
Setting the Explicit Tunnel Path Option

Because an explicit path is like a static route, if a link in the path goes
down, the tunnel is no longer available to carry traffic. It is typical to
create multiple path options, as in the illustration, to provide alternatives,
should the original path become unavailable.
The path option for the explicit path named path3426 looks like this:
explicit-path name path3426
index 5 next-address 192.168.34.4
6148
Version 4.0.1

Module 6
Creating Explicit Cisco MPLS TE Tunnel and Setting the Path Option
:router(config)# interface tunnel-te326

:router(config-if)# description explicit-tunnel-to-PE6
:router(config-if)# ipv4 unnumbered Loopback0
:router(config-if)# priority 4 3
:router(config-if)# autoroute announce
:router(config-if)# signalled-bandwidth 5000
:router(config-if)# destination 10.6.6.6
:router(config-if)# path-option 10 explicit name path3126
Same steps as in dynamic tunnels
!IP address
!Priority
!Announce path to IGP
!Bandwidth
!Destination
Version 3.9.0a
XMPLST4Module 6/138
:router(config-if)#

ipv4 address]] | explicit {name path-name | identifier path-number }}
[isis instance-name level level ] [lockdown] [ospf instance-name area {value |
address}] [verbatim]
Use explicit for a manually constructed path

More scalable with other options
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/139
6149
Module 6
Cisco MPLS TE Inter-Area Explicit Path

Loose hops are for inter-area tunnels, where the headend router does not
have the complete topology and cannot find the path; ABRs perform loosehop expansion.
In this example, you have an autonomous system (AS) with three OSPF
areasarea 1 (with router-IDs 10.1.1.x), backbone area 0 (with router-IDs
10.0.0.x), and area 3 (with router-IDs 10.3.3.x). ABRs have area 0 routerIDs. You want your tunnel to take advantage of the Gigabit Ethernet link
in area 0.
For traffic on R1 in area 1 to reach R7 in area 3, you use strict addressing
to reach R2 and strict addressing to reach R4, the ABR. From R4 to R6 to
R7, you use loose addressing because of the lack of visibility in the R1
OSPF routing table.
6150
Version 4.0.1

Module 6
Cisco MPLS TE Inter-Area Explicit Path
Inter-area path
!Path through more than one area
Loose hop
OSPF Area 1
10.1.1.1
10.1.1.2
R1
10.0.0.3
R2
R4
R3
10.0.0.4
OSPF Area 0
GigE
POS
10.0.0.6
10.0.0.5
R5
R6
10.3.3.7
R7
OSPF Area 3
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/140
6151
Module 6
Cisco MPLS TE and Fast Reroute

In this section, you learn about the concepts of recovery, protection, and
FRR.
Recovery Cycle and Time

Any recovery has several key parts:
6152
Fault detection time
Hold-off time
Fault notification time
Recovery of operation time
Recovery of traffic time
Version 4.0.1

Module 6
Recovery Cycle and Time
Total recovery time

Failure
Detected
Time
Traffic recovery time

Recovery operation time
Fault notify time
Hold-off time
Fault detection time
Key pieces
Recovery methods
! Link, node, and path protection

! MPLS TE FRR
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/141
6153
Module 6
Protection
Recovery methods are employed with Cisco MPLS TE:
Link protectionProtection for individual interfaces; backup tunnel

is created to all possible endpoints for tunnels that cross this link
Node protectionProtection for the next node (router) in the tunnel

path; each node in the path creates a backup tunnel to all possible
endpoints for all tunnels crossing that node
Path protectionComplete protection of the tunnel path; requires

headend to have a designated backup path on which to reroute the
traffic; least scalable; least used; this is sometimes referred to as
global protection or end-to-end protection
FRR is the Cisco MPLS TE configuration that indicates to routers in the

LSP of the tunnel, that the tunnel wants to be rerouted in the event of a
link or node failure. FRR builds a path to be used in the event of a failure
in the network.
Two important definitions to understand for TE are point of local repair
(PLR), which is the node immediately upstream from the failure, and
merge point (MP), the node at which the backup tunnel terminates.
_____________________________ Note _________________________
FRR protects only the traffic in the Cisco MPLS TE tunnels. It does not
protect regular traffic flowing over the failed link.
__________________________________________________________________
6154
Version 4.0.1

Module 6
Protection
Tunnel protection
! Local protection
" Link protection

" Node protection
! Path protection
Terms
! Point of local repair (PLR)Node immediately upstream from the failure

! Merge point (MPNode at which the backup tunnel terminates
! NHOPnext hop protecting interface failure
! NNHOP next next hop protecting node failure
FRR in tunnel configuration makes tunnel eligible to be

rerouted
I want protection if one of the following occurs:

" Link in the LSP from headend to tailend fails
" Node in the LSP from headend to tailend fails
Reminders
! All tunnels use LSPs

! Non-tunnel traffic is not protected
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/142
6155
Module 6
In the illustration, when either the R2-R6 link or R6 fail, R1 receives a

PathError message and a ResvTear message from R2. R1 also receives a
new LSA or LSP indicating that the R2-R6 link is down, and concludes
that the LSP has failed. Which one of the two events occurs first? It
depends on the failure type and IGP tuning.
Receiving the PathError message allows removal of the failed link from the
Cisco MPLS TE database to prevent any retry of the same failed link. If
the backup path is a dynamic tunnel, R1 calculates a new path for the
tunnel and signals the new tunnel. If no path is available, R1 tries
continuously to find a new path.
6156
Version 4.0.1

Module 6
Protection (Cont.)
R3
NNHOP
back-up
tunnel
R2
R1
Protected
tunnel
R6
PLR
NHOP
backup
tunnel
R5
R4
R9
Version 3.9.0a
R7
Merge
point
R8
Merge
point
XMPLST4Module 6/144
Instructor's Note
Slide animation: Starts with network drawing; Click 1 Red arrow and protected tunnel text;
Click 2 Red X on link R2-to-R6; Click 3 Protected tunnel text and red arrow disappear;
PLR appears with green arrow, NHOP backup tunnel, and Merge point appear; Click 4
Green arrow, PLR, NHOP backup LSP, Merge point disappear; Protected tunnel and
red arrow reappear; Click 5 R6 turns red; Click 6 Protected tunnel text and red arrow
disappear, PLR, beige arrow, NNHOP backup LSP, and Merge point appear
Version 4.0.1
6157
Module 6
FRRLink Protection Forwarding

In this illustration, you see an IP packet with a destination of network
172.198.81.0 behind R8, arriving at R1.
In the original LSP that follows the path R2-R6-R7, the packet has a label
of 21 from R1 to R2; at R2, label 21 is swapped for label 62; at R6, label 62
is swapped for label 72; at R7, PHP removes the label and forwards the
packet to R8.
When the link between R2 and R6 drops, several things occur:
6158
R2 begins sending the traffic on the backup path. It keeps the original
label for R6, label 62, and pushes a label to reach R9, label 92 onto the
packet
At R9, label 92 is swapped for label 79; labels 92 and 79 represent the
path to the loopback address of R6
At R7, the label is popped because that router is the last hop before R6
R6 receives the packet, it sees the inner label of 62 and swaps it for
label 72 and forwards the packet to R7
R7 removes the label and forwards the packet to R8
Version 4.0.1

Module 6
FRRLink Protection Forwarding
IP packet
Original packet and labels
21
62
21
172.198.11.0
R1
72
62
R2
72
R7
R6
R8
172.198.81.0
79
79
92
92
62
R9
62
62
21 Label
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/145
6159
Module 6
FRRNode Protection Forwarding

It is fairly straightforward as to how a link failure is recognized and how
the subsequent link protection mechanism works. What about node
protection?
The main difference between link and node protection is the concept of
next hop (NHop), which works for link protection. For node protection, you
need next-next hop (NNHop), which presents the label-stacking issue. In
link protection, the PLR knows about the label that is needed to reach the
next hop, but with node failure, that is not possible, because the PLR does
not know the label of the hop beyond the node that fails.
You still configure for node protection at the same PLR as you did with the
link protection in the previous discussion. However, this time you build
your protection tunnel to the NNHop, rather than the NHop.
As shown in the illustration, you build your node protection tunnel on R2,
as you did the link protection tunnel. Because you have configured both
link and node protection, R2 presumes node protection failure and uses
that protection mechanism for the backup tunnel.
What backup LSP type would be employed at R2 if both NHOP and
NNHOP were configured? Because R2 cannot know which failure has
occurred, NNHOP is the recovery method.
6160
Version 4.0.1

Module 6
FRRNode Protection Forwarding
43
72
43
32
R3
72
R5
R4
32
72
74
R2
R1
172.198.11.0
21
21
IP packet
R7
R6
62
62
72
R8
172.198.81.0
72
Original packet and labels

21 Label
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/146
6161
Module 6
Path Protection
Path protection is protection for a tunnel generally used in a few specific
situations, usually a ring type network where it is not practical or too
costly. An example is Japan, which has a mountain range roughly in the
middle that prohibits laying fiber. So the Japanese have laid their cable
around the range in what you could loosely describe as a clock.
Further, because of the amount of configuration required, path protection
is not scalable.
In this illustration, R1 has a tunnel to R5. If the link between R2 and R3
were to stop working, node or link protection would need to set up a
backup tunnel that would go from R1-R8-R7-R6-R5-R4-R3-R4-R5. Similar
backup tunnels would need to be setup to account for all possible link or
node losses. This is not very practical.
However, in the illustration, path protection lets you create a backup
tunnel going from R1-R8-R7-R6-R5 to protect the original tunnel.
6162
Version 4.0.1

Module 6
Path Protection
Backup
tunnel
Protected
tunnel
R1
R8
PLR
R2
R3
R7
R6
R4
R5
Version 3.9.0a
XMPLST4Module 6/148
Instructor's Note
Slide animation: Starts with network drawing; Click 1 Green pipe and Protected LSP text;
Click 2 Red X on link R2-to-R3 and PLR text; Protected LSP text and green pipe
disappear; Click 3 Orange pipe and Backup LSP text appear
Version 4.0.1
6163
Module 6
Record Route
Route recording is typically turned on in a protected tunnel configuration
for node protection. The RSVP Path message has the Record Route Object
(RRO) and the Resv message records the addresses on the return.
The record-route command is used to keep track of the IP addresses of
each hop in the path. In Cisco IOS XR Software, the record-route
command must be enabled for tunnels protected by multiple backup paths
that merge at the same node.
6164
Version 4.0.1

Module 6
Record Route
:router(config-if)#
record-route
RSVP Path message has RRO
!Purpose is to record address and labels for

tunnel path
!Necessary for FRR
!Configured as part of tunnel
RSVP Resv message populates RRO
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/149
6165
Module 6
FRRLink Protection Configuration

This is an illustration of a configuration for link protection.
In the top illustration, on R3, you see a configuration for an explicit tunnel
from R3 to R6 using the link between R1 and R2. R1 is the PLR and R6 is
both the MP and the endpoint.
In this configuration, the tunnel is protected by fast reroute and route
recording is turned on.
In the bottom illustration, you see that the link between R1 and R2,
POS0/3/0/2 is protected with a backup path, tunnel-te156 on R1. Note that
the interface protection is turned on in mpls traffic-eng mode.
You also see that the backup tunnel, tunnel-te156, is created on R1 with its
path going to R5, and then R6.
6166
Version 4.0.1

Module 6
FRR Link Protection Configuration
:R3# show run

[output omitted]
explicit-path identifier 3126
index 5 next-address strict ipv4 unicast 192.168.13.1
interface tunnel-te 3126
description explicit-tunnel-to-PE6
ipv4 unnumbered Loopback0
priority 4 3
autoroute announce
signalled-bandwidth 5000
destination 10.6.6.6
fast-reroute
record-route
path-option 10 explicit identifier 3126
PLR
R1
R5
R3
POS 0/3/0/2
Protected
LSP
Version 3.9.0a
XMPLST4Module 6/151
:R1# show run

description backup-int-pos0302
priority 4 3
autoroute announce
Merge
point
R6
R2
R4
backup-path tunnel-te tunnel-number
:R1# show run

mpls traffic-eng
backup-path tunnel-te 156
PLR
Backup
tunnel
R1
R5
R3
POS 0/3/0/2
Protected
LSP
R2
R4
Version 3.9.0a
Version 4.0.1
R6
Merge
point
XMPLST4Module 6/152
6167
Module 6
Displaying Link Protection

You may use the show mpls traffic-eng tunnels command to display all
kinds of information about the tunnels you create.
In the top illustration, you see the explicit path created on R3 from the
perspective of the origination router and the destination router, R6. Note
that the illustration indicates that this is an explicit type tunnel and that
FRR is enabled. Also, the configured path is shown with more detail.
In the bottom illustration of R6, you see the recorded path information.
Note that the reservation information for the record route is empty
indicating that the tunnel is not being used.
6168
Version 4.0.1

Module 6
Displaying Link Protection
[output omitted]
:R3# show mpls traffic-eng tunnels

Status:
Admin:
up Oper:
up
Path: valid
path option 10, type explicit 3126 (Basis for Setup, path weight 30)
Config Parameters:
Bandwidth:
Loadshare:
0 equal loadshares
Auto-bw: disabled
Fast Reroute: Enabled, Protection Desired: Any
Path info (IS-IS L2-12 level-2):
R3
Hop0: 192.168.113.1
Hop1: 192.168.112.2
Hop2: 192.168.126.2
Hop3: 192.168.126.6
Hop4: 10.6.6.66
R4
R1
R2
Version 3.9.0a
R5
R6
XMPLST4Module 6/154
[output omitted]

LSP Tunnel 10.3.3.33 3126 [2] is signalled, connection is up
Tunnel Name: R3_t3126 Tunnel Role: Tail
InLabel: GigabitEthernet0/4/0/0, implicit-null
Signalling Info:
Src 10.3.3.33 Dst 10.6.6.66, Tun ID 3126, Tun Inst 2, Ext ID 10.3.3.33
Router-IDs: upstream
10.2.2.22
local
10.6.6.66
R1
Path Info:
R3
Incoming:
Explicit Route:
Strict, 192.168.126.6
Strict, 10.6.6.66
Record Route:
IPv4 192.168.126.2, flags 0x0
R4
R2
IPv4 192.168.112.1, flags 0x0
IPv4 192.168.113.3, flags 0x0
Tspec: avg rate=5000 kbits, burst=1000 bytes, peak rate=5000 kbits
Session Attributes: Local Prot: Set, Node Prot: Not Set, BW Prot: Not Set
Resv Info: None
Record Route: Empty
Fspec: avg rate=5000 kbits, burst=1000 bytes, peak rate=5000 kbits
Version 3.9.0a
Version 4.0.1
R5
R6
XMPLST4Module 6/155
6169
Module 6
In this illustration, you see the explicit path from a midpoint perspective,
and you see the entire route and record route information.
6170
Version 4.0.1

Module 6
Displaying Link Protection (Cont.)
[output omitted]
LSP Tunnel 10.3.3.33 3126 [2] is signalled, connection is up
Tunnel Name: R3_t3126 Tunnel Role: Mid
InLabel: GigabitEthernet0/2/0/0, 16013
OutLabel: GigabitEthernet0/2/0/4, 16017
Bandwidth Requested:
5000 kbps CT0
Signalling Info:
Src 10.3.3.33 Dst 10.6.6.66, Tun ID 3126, Tun Inst 2, Ext ID 10.3.3.33
Router-IDs: upstream
10.3.3.33
local
10.1.1.11
downstream 10.2.2.22
Path Info:
Incoming:
Explicit Route:
Strict, 192.168.113.1
R3
Strict, 192.168.112.2
Strict, 192.168.126.2
Strict, 192.168.126.6
Strict, 10.6.6.66
Outgoing:
Explicit Route:
R4
Strict, 192.168.112.2
Strict, 192.168.126.2
Strict, 192.168.126.6
Strict, 10.6.6.66
--More- 2011, Cisco Systems, Inc. All rights reserved.
R1
R2
Version 3.9.0a
R5
R6
XMPLST4Module 6/157
[output omitted]
Record Route:
IPv4 192.168.113.3, flags 0x0
Tspec: avg rate=5000 kbits, burst=1000 bytes, peak rate=5000 kbits
Session Attributes: Local Prot: Set, Node Prot: Not Set, BW Prot: Not Set
Resv Info:
Record Route:
IPv4 10.2.2.22, flags 0x20
Label 16017, flags 0x1
IPv4 192.168.112.2, flags 0x0
Label 16017, flags 0x1
IPv4 10.6.6.66, flags 0x20
Label 3, flags 0x1
IPv4 192.168.126.6, flags 0x0
Label 3, flags 0x1
Fspec: avg rate=5000 kbits, burst=1000 bytes, peak rate=5000 kbits
R1
R5
R3
R4
Version 3.9.0a
Version 4.0.1
R2
R6
XMPLST4Module 6/158
6171
Module 6
The show mpls traffic-eng database backup-interface command may

be used to display the information about the interface that has been
protected. This information is available only on a router that has
implemented the protection. In the illustration, you see the tunnel is
protected.
6172
Version 4.0.1

Module 6
Displaying Link Protection (Cont.)
:R1# show mpls traffic-eng fast-reroute database backup-interface

LSP midpoint FRR information:
LSP Identifier
Local
Label
----------------------------- -----10.3.3.33 3126 [2]
16013
Out Intf/
FRR Intf/
Status
Label
Label
---------------- ---------------- ------tt156:Pop
Active
R1
R5
R3
R4
Version 3.9.0a
Version 4.0.1
R2
R6
XMPLST4Module 6/159
6173
Module 6
Displaying Protection After Link Failure

Here is an illustration of the R3 router that initiated the explicit TE tunnel
when one of the links has failed. You see a message indicating a change in
resources and that a reroute is pending.
You also see that a PCALC error has occurred and that one of the explicit
addresses, in this case 192.168.112.2, is unknown. The point of local repair
is shown as the interface on R1.
You see in the History section that the prior link-state packet was removed
as the result of a path error. Note that this does not alter the actual path
information that was configured and that is what is still shown.
6174
Version 4.0.1

Module 6
Displaying Protection After Link Failure
[output omitted]

Status:
Admin:
up Oper:
up
Path: valid
path option 10, type explicit 3126 (Basis for Setup, path weight 30)
Change in required resources detected: reroute pending
Bandwidth:
Last PCALC Error [Reopt]: Tue Nov 2 15:48:37 2010
Info: Explicit path has unknown address: 192.168.112.2
Last Signalled Error: Tue Nov 2 15:48:23 2010
Info: [2] PathErr(25,3)-(notify, local repair) at 192.168.113.1
Config Parameters:
Bandwidth:
R3
Loadshare:
0 equal loadshares
Auto-bw: disabled
Fast Reroute: Enabled, Protection Desired: Any
R4
Version 3.9.0a
Version 3.9.0a
Version 4.0.1
R6
[output omitted]
R1
R5
R3
R4
R2
R5
XMPLST4Module 6/161
History:
Tunnel has been up for: 00:52:19
Current LSP:
Uptime: 00:52:19
Reopt. LSP:
Last Failure:
LSP not signalled, has no S2Ls
Date/Time: Tue Nov 02 15:48:37 UTC 2010 [00:00:09 ago]
Prior LSP:
ID: path option 10 [2]
Removal Trigger: path error
Path info (IS-IS L2-12 level-2):
Hop0: 192.168.113.1
Hop1: 192.168.112.2
Hop2: 192.168.126.2
Hop3: 192.168.126.6
Hop4: 10.6.6.66
R1
R2
R6
XMPLST4Module 6/162
6175
Module 6
FRRNode Protection Configuration

In this illustration, the network has changed. This time the merge point of
the protected tunnel is R2. The protected tunnel is tunnel-te31726 and
goes from R3-R1-R7-R2-R6.
In the lower illustration, you see the backup tunnel, tunnel-te1826,
configured on R1. This protects against R7 failing. Note that the
configuration is still done in mpls traffic-eng interface mode.
6176
Version 4.0.1

Module 6
FRRNode Protection Configuration
:R3# show run

description explicit-tunnel-to-PE6
priority 4 3
autoroute announce
fast-reroute
record-route
R7
R1
R3
R5
POS 0/3/07
PLR
Protected
LSP
R4
R6
R2
R8
Version 3.9.0a
:R1# show run

index 5 exclude-address 192.168.17.7
index 10 next-address loose 10.2.2.2
description protect-node-R7
priority 4 3
autoroute announce
Merge
point
XMPLST4Module 6/164
:R1# show run

mpls traffic-eng
backup-path tunnel-te 1826
R1
R3
POS 0/3/07
R7
R5
PLR
Protected
LSP
Merge
point
R4
R2
R8
Version 3.9.0a
Version 4.0.1
R6
XMPLST4Module 6/165
6177
Module 6
Traffic Engineering Timers

In this section you learn about TE timers and their parameter values.
TE Timers
The fast-reroute timers promotion command lets you manage how
often a router will switch a protected LSP to a new backup tunnel. This is
particularly useful if the new backup tunnel has increased its backup
bandwidth or a backup tunnel with a better path becomes available. Keep
in mind that the lower you set the value, the more impact it will have on
router performance in the event that tunnels are moved to backup paths.
We recommend that the default value be the low value used. Cisco IOS XR
Software uses internal pacing mechanisms to distribute the load when
backup promotion is in use. However, when a large number of protected
LSPs get promoted, delay may be noticeable. Further, if the timer is
configured particularly low, some protected LSPs may never get promoted.
This depends on the actual number of protected LSPs.
The timers loose-path retry-period command lets you configure the
time period between retries the headend router makes after a path error
has occurred.
The link-management timers bandwidth-hold command lets you set
the amount of time that bandwidth is held while the RSVP setup message
(Path) waits to receive a corresponding RSVP reservation (Resv) message.
The link-management timers periodic-flooding command lets you
alter the time interval of the periodic flooding of link-state information.
When some characteristics of the Cisco MPLS TE link-state information
change, they do not trigger any immediate flooding action to make the
change known. An example is a change in the bandwidth that does not
cross a threshold.
6178
Version 4.0.1

Module 6
Traffic Engineering Timers
TE Timers
:router(config-mple-te)#
fast-reroute timers promotion interval

:router(config-mpls-te)# fast-reroute timers promotion 600
Switch protected tunnels
!
!
Set in MPLS TE configuration mode

Switch to new backup if
!
!
Default interval is 300 seconds

Value range is 0604,800 seconds
" Additional bandwidth becomes available

" Better backup tunnel becomes available
timers loose-path retry-period value

:router(config-mpls-te)# timers loose-path retry-period 300
Manage headend retries after path errors
!
!
!

Default value is 120 seconds
Value range is 30600 seconds
Version 3.9.0a
XMPLST4Module 6/168
link-management timers bandwidth-hold holdtime
:router(config-mpls-te)# link-management timers bandwidth-hold 20
RSVP bandwidth setup management
!
!
!
!

Length of time bandwidth is held by PATH message until RESV message is returned
Default holdtime is 15 seconds
Value range is 1300 seconds
link-management timers periodic-flooding value
:router(config-mpls-te)# link-management timers periodic-flooding 360
Manage link-state information advertisement interval
!
!
!
!
For non-triggered changes

Default value is 180 seconds; minimum is 30 seconds
Value range is 03,600 seconds; value of 0 turns off periodic flooding
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/169
6179
Module 6
Reoptimization
In this section you learn about reoptimization of tunnels and the concept of
make-before-break.
Reoptimization in General
Reoptimization for Cisco MPLS TE means putting tunnels on the best path
to the destination.
There are four things that may influence tunnel reoptimization:
6180
Periodic timersSingle timer that can be adjusted
Manual changesIncreasing link bandwidth, adding new links to the

network, and employing the reoptimize command manually
EventsLinks that flap can result in reoptimization
Path lockdownScenario in which the tunnel is kept on a particular

path unless an underlying link in the path fails
Version 4.0.1

Module 6
Reoptimization
Reoptimization in General
What is reoptimization?
Putting tunnels on the best possible path to their destination

What influences reoptimization?
Periodic timers
! Reoptimization global timer
Manual changes
! Increasing bandwidth
! Adding new links
! Employing the reoptimize command
Events
! Link flapping
Path lockdown
! Keeping tunnel on preferred path
" Unless underlying link fails

" Returning to original path when link failure resolved
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/171
6181
Module 6
Reoptimization Commands
Here are some reoptimization commands that you may find useful.
Periodic reoptimization
Periodically, a global timer implements reoptimization of all tunnels. The

timer has a default value of 3600 seconds or one hour. The timer value can
be altered with the reoptimize command in MPLS TE configuration
mode. The range of values lets you set it for as long as a week
(604,800 seconds). The minimum value of zero means that the tunnels are
never optimized after they come up.
The periodic timer, while configured globally, is kept for each tunnel
individually. So if you have configured multiple tunnels, there is a delay
between reoptimization of each tunnel, after the tunnel comes up initially.
For example, if you have five tunnels, T1 to T5, they may come up one
minute after each other, T1 would come up at 00:00, T2 at 00:01, T3 at
00:02, T4 at 00:03, and T5 at 00:04. Fifty- ix (56) minutes later, the
reoptimization timer would go off and T1 would be reoptimized. Each
tunnel is subsequently reoptimized at its original time plus one hour
(T5 at 01:04).
Manual reoptimization
If you become aware of a change in the network, the

mpls traffic-eng reoptimize EXEC command may be used to force the
router to reoptimize all the tunnels, instead of waiting for the default
timer.
Tunnel lockdown
If you do not want a tunnel to change paths for some reason, use the
lockdown command in path option mode to keep the tunnel from being
reoptimized. If you provide any additional paths, they would only be used if
a link underlying the tunnel fails. The tunnel would switch to the newly
available path, but would return to the original path after the failed link
returns to service.
Event Driven Reoptimization
Should a tunnel be reoptimized when a new link that represents a better

path comes up? In many cases, you would want that to occur. However, in
a scenario when a link is flapping and the IGP timers do not hide the
event, reoptimizing onto that link and having to reroute when it goes down
changes the tunnel characteristics too often and would result in potentially
bad service. Thus re-optimizing as soon as a link comes up is less than
optimal. In this case, using the regular periodic timer is a good option
6182
Version 4.0.1

Module 6
Reoptimization
Reoptimization Commands
reoptimize frequency
:router(config-mpls-te)# reoptimize 7200
Regular reoptimization
! Set in MPLS TE configuration mode
:router#
" Default frequency is 3,600 seconds

" Value range is 0604,800
mpls traffic-eng reoptimize

:router# mpls traffic-eng reoptimize
Manual reoptimization
- Use in EXEC mode

- Known network changes
" Do not want to wait for regular reoptimization
Version 3.9.0a
XMPLST4Module 6/173
:router(config-if)#

ipv4 address]] | explicit {name path-name | identifier path-number }} [isis
instance level level ] [lockdown] [ospf instance-name area { value | address }]
[verbatim]
:router(config-if)# path-option 5 explicit name path1 lockdown
With lockdown option
!Tunnels that you do not want to optimize ever
" Keep same physical path always

" Change path only if an underlying link goes away
" Return to original path when link is restored
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/174
6183
Module 6
Make-Before-Break
The concept of make-before-break is nearly as simple as it sounds. The
objective of making a tunnel before breaking the original tunnel is to
change the characteristics of an existing tunnel without impacting the
traffic in the tunnel, and to avoid completely or minimize substantially,
any traffic disruption. The tunnel characteristics that change are adding
bandwidth, removing bandwidth, or discovering a more optimal path.
A second objective is to avoid double counting bandwidth on any common
links that might carry both the original tunnel and the new tunnel. Double
booking bandwidth makes it appear that not enough bandwidth exists on
the link to support the original and the new tunnels. Thus, a newer tunnel
with more bandwidth would potentially be rejected.
6184
Version 4.0.1

Module 6
Reoptimization
Make-Before-Break
Objective
Change characteristics of tunnel with minimal

impact
!Bandwidth
!Path
Avoid tearing down tunnel before new tunnel is
available
! Avoid traffic disruption

Avoid double counting bandwidth on common
links carrying the new and old tunnel
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/175
6185
Module 6
Make-Before-Break Example
For the purpose of this example, the domain administrator keeps all RSVP
bandwidth to the default 75 percent of intrinsic bandwidth. In the
illustration, you create a tunnel from R2 to R4 that requires 40 Mbps of
bandwidth. The LSP goes from R2 to R3 and to R4, the shortest physical
path. Later you decide to increase the tunnel bandwidth to 80 Mbps. The
LSP takes a new path from R2 to R1 to R5 to R4 to accommodate the
bandwidth increase request. After the tunnel is created, the original tunnel
is torn down.
OSPF cost changes could produce the same result in this particular
example.
6186
Version 4.0.1

Module 6
Reoptimization
Make-Before-Break Example
40 Mbps
R2 needs 40 Mbps tunnel to R4
! Takes path R2-R3-R4
R3
R2 wants to increase bandwidth

of tunnel to R4 to 80 Mbps
! Needs to take path R2-R1-R5-R4
R2
60 Mbps
R4
100 Mbps
100 Mbps
Orange tunnel is signalled and
100 Mbps
bandwidth reserved
! Now bandwidth is reserved over
R1
both paths
100 Mbps
R5
" Totaling 100 Mbps
Green tunnel is torn down
shortly after orange tunnel

reservation is allowed
80 Mbps
Reservable bandwidth
shown is prior reservation
Version 3.9.0a
XMPLST4Module 6/177
Instructor's Note
Slide animation: 1st major bullet appears with slide; Click 1 green arrow and 40 Mbps
appear; Takes path R2-R3-R4 text appears; Click 2 2nd major bullet appears; Click 3 text
Needs to take path R2-R1-R5-R4 appears, orange arrow and 60 Mbps appear; Click 4 3rd
major bullet, sub-bullet, and sub-sub-bullet appear; Click 5 4th major bullet appears, green
tunnel, 40 Mbps disappear
Version 4.0.1
6187
Module 6
Shared Explicit Reservation

Now using a slight variation in the design of the network, what happens
when you want to increase the bandwidth of an existing tunnel? Your
network does not have a link from R5 to R4. Instead, the link goes from R5
to R3. You use the same initial tunnel as you did in the first example.
This time you decide to increase the bandwidth of the tunnel to 75 Mbps.
The LSP is signaled from R2 to R1 to R5 to R4 because the bandwidth
requirement is more than what the link from R2 to R3 can support. This is
roughly the same path the last example followed, except that the link from
R5 to R3 is used for the new LSP. However, this time the link from R3 to
R4 does not have enough bandwidth to support the increase the tunnel
needs because the total of the two tunnels is 120 Mbps, more than the total
bandwidth of the link. (Actually more than the intrinsic bandwidth of the
physical link!)
Under normal circumstances, your request would be rejected by R3 and the
LSP would not be set up. However, using the RSVP Shared Explicit (SE)
reservation, you can set up the LSP by temporarily sharing the bandwidth
of the R3 to R4 link. SE is a style of reservation that lets an LSP share
bandwidth with itself. The headend requests this type of LSP (using the
SESSION_ATTRIBUTE object), which creates LSP identities nearly the
same for both the original LSP and the new LSP. All reservations have a
unique identity that has several parameters:
Sender addressRouter ID of the tunnel headend; included in the

SENDER_TEMPLATE object
LSP IDInstantiation counter that increments each time the

bandwidth requirement or path changes; included in the
SENDER_TEMPLATE object
Endpoint addressRouter ID of the tunnel tail; included in the

SESSION object
Tunnel IDInterface number at the headend of the tunnel; included

in the SESSION object
Extended tunnel IDTypically, all zeros or an IP address on the

headend router; inconsequential in this case; included in the SESSION
object
The result of the SE reservation process is that two Path messages with all
the above parameters the same, are considered representative of the same
reservation. For MPLS TE, if two reservations have all the above
parameters, but with a different LSP ID, the LSP requests are different,
but they share the bandwidth. This tells the reservation process to split the
bandwidth until the original LSP tunnel is torn down.
6188
Version 4.0.1

Module 6
Reoptimization
Shared Explicit Reservation
R2 needs 40 Mbps tunnel to R4
Takes path R2-R3-R4
40 Mbps
R2 wants to increase bandwidth

of tunnel to R4 to 80 Mbps
Needs to take path R2-R1-R5R3-R4
R3
100 Mbps
But can it?
No! Total bandwidth requested

from R3-R4 is 120 Mbps
R2
60 Mbps
RSVP Shared Explicit (SE)
100 Mbps
reservation is the solution
Lets existing LSP share

bandwidth with itself
" Avoids double booking
100 Mbps
80 Mbps
80 Mbps reservation request gets
R4
80 Mbps
100 Mbps
R5
80 Mbps
40 Mbps from R3-R4 link
R1
80 Mbps
40Mbps
Gets full 80 Mbps when

original reservation is torn
down
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/179
6189
Module 6
Other Traffic Engineering Information

In this section you see some additional information and commands that are
helpful in maintaining Cisco IOS XR Software MPLS TE.
Automatic Bandwidth
Cisco MPLS TE automatic bandwidth is configured at the headend for each
individual label-switched path. Cisco MPLS TE monitors the bandwidth
usage on the tunnel interfaces and adjusts the bandwidth periodically to
align with the actual traffic in the tunnel.
In each automatic bandwidth configured tunnel, the output rate is sampled
based on configurable parameters and an average is derived. The tunnel
bandwidth is adjusted based on the highest average traffic output rate
during the last interval or measurement. The bandwidth may also be
adjusted based on a maximum or minimum bandwidth value.
The automatic bandwidth application uses several variables to measure
traffic and adjust the bandwidth:
Application frequencyHow often the tunnel bandwidth is adjusted
Requested bandwidthRange limit of bandwidth requests
Collection frequencyHow often global polling takes place for

tunnel traffic rate
Highest collected bandwidthHighest amount is used by a tunnel
DeltaDifference between collected bandwidth and what is actually

used during an interval
Output traffic rates are collected at regular intervals when the application
period timer expires. The difference between the measured and current
bandwidth is the delta and the tunnel bandwidth is adjusted whenever the
delta exceeds, or is less than, the current bandwidth. When the timer
expires and the bandwidth adjustment, if any, is made, the samples are
cleared and the recording starts again for a new interval.
When the tunnel is reoptimized to take advantage of the new bandwidth, a
new LSP is signaled. If the bandwidth is not available to the LSP, the old
LSP continues without traffic interruption. Any minimum or maximum
bandwidth configurations keep the adjusted bandwidth within the
configured values. If a tunnel is shut down and restarted, all bandwidth
adjustment information is lost and the tunnel is configured with the
original bandwidth. Application intervals are restarted when the tunnel is
reactivated.
6190
Version 4.0.1

Module 6
Automatic Bandwidth
Tunnel output sampling to adjust the tunnel bandwidth

Bandwidth adjustment periodically; configurable
Average output sampling rate based on polling at
configurable interval
Tunnel application is configurable

Threshold adjustment for tunnel re-signaling configurable
Overflow detection available
Restrictions
!Tunnels in FRR backup, active, or path protect state

!Lockdown
" Exec mode command available
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/181
6191
Module 6
Automatic Bandwidth Commands

Use the auto-bw command on any tunnel on which you wish to use any
available bandwidth, while the tunnel is active. When you configure the
automatic bandwidth application for a tunnel, the various bandwidth
defaults covered later in this module apply. If output rate collection is
active and automatic bandwidth is configured, statistics collection for the
tunnel starts at the next collection interval. This command is configured in
the individual tunnel (interface) mode.
auto-bw collect frequencyCommand to set how often output

bandwidth is measured for the purpose of adjusting bandwidth on the
tunnels. The collection time is measured in minutes, with a range from
1 to 10080 minutes (7 days). The default collection interval is 5
minutes. This command is configured for all tunnels in mpls traffic-eng
mode
applicationCommand to configure how often the automatic

bandwidth application will adjust the bandwidth for the tunnel. The
interval is set in minutes, with a default time of 24 hours or 1440
minutes. The range for the frequency of adjustment is from 5 to 10080
minutes
bw-limitCommand to set minimum and maximum amounts of

bandwidth for a tunnel using the automatic bandwidth application. The
default minimum is 0, so the tunnel does not come up. The default
maximum is also 0 and the tunnel will not come up. The highest value
of bandwidth is 4,294,967,295 kbps for both minimum and maximum
You cannot configure a minimum bandwidth higher than the maximum

bandwidth.
6192
Version 4.0.1

Module 6
Automatic Bandwidth Commands
:router(config-if-tunte-autobw)#
auto-bw
:router(config-if)# auto-bw
Turn on automatic bandwidth for a tunnel
! Collection starts immediately

! Output rate collection active, collection for tunnel starts at next interval
auto-bw collect frequency minutes

:router(config-mpls-te)# auto-bw collect frequency 10
Bandwidth collection sample time

Sets the frequency time for all tunnels
Version 3.9.0a
XMPLST4Module 6/183
application minutes
:router(config-if-tunte-autobw)# application 720
Manages the automatic bandwidth application for a tunnel
!
!
Default is 1,440 minutes (24 hours); range is 510,080

Resets and restarts application for the tunnel
bw-limit min bandwidth { max bandwidth }
:router(config-if-tunte-autobw)# bw-limit min 500 max 1000
Sets the minimum and maximum automatic bandwidth for the tunnel
Default is 0 Kbps; range is 04294967295
If bandwidth limit is changed while automatic bandwidth application is active,
impact occurs at next application
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/184
6193
Module 6
The bandwidth adjustment threshold is defined as a percentage of the

current tunnel bandwidth along with an absolute minimum bandwidth.
For the automatic bandwidth application to re-signal the tunnel, both
thresholds must be crossed. The tunnel is reset only if the difference
between the largest sample output rate collected, and the current tunnel
bandwidth, is larger than the thresholds defined.
Use the adjustment-threshold command to manage the triggering of a
bandwidth adjustment by setting a change in the bandwidth percentage.
The change is triggered by the sample percentage being higher than the
current bandwidth. The default percentage is 5 percent and the range is
from 1 to 100 percent. Optionally, you may set a minimum bandwidth for a
tunnel in the range from 10 (the default) to 4,294,967,295 kbps.
To cite an example, suppose that you have a tunnel that is initially
configured for 50 Mbps with the adjustment threshold of 10 percent and
the default minimum bandwidth, or 10 kbps. To this point, the highest
output sample is 30 Mbps. When the automatic bandwidth application
timer expires, the tunnel will be signaled with 30 Mbps. This occurs
because the difference between the configured and current bandwidth is 20
Mbps and the threshold is 10 percent of 50 Mbps, or 5 Mbps, which is
smaller than the current bandwidth. Further, the current bandwidth is
higher than the minimum.
Overflow detection occurs when a sampling finds more bandwidth
(increase volume) being used than is currently signaled for the tunnel.
Increasing traffic, not decreasing, triggers any adjustment that happens as
a result of overflow detection.
Use the overflow threshold command to set a trigger based on the
percentage over the current bandwidth. Optionally, you can use a
minimum bandwidth change value for the trigger. The default for the
minimum bandwidth is 10 kbps and ranges from 10 to 4,294,967,295 kbps.
You may also set a limit to the number of consecutive collections that
surpass the threshold. The range for the limit keyword is from 1 to 10.
Any change to percentage, minimum bandwidth or the use of the limit
keyword resets the overflow counter.
Because overflow detection is off by default, there are no default values, so
values must be included.
You can apply the highest collected bandwidth to the tunnel before the
application period expiration by using the
mpls traffic-eng auto-bw apply command. This command must be
applied to either a specific tunnel or all tunnels by using one of the
appropriate keywords.
6194
Version 4.0.1

Module 6
Automatic Bandwidth Commands (Cont.)
adjustment-threshold percentage [min bandwidth]

:router(config-if-tunte-autobw)# adjustment-threshold 10
Manages the change trigger for bandwidth adjustment
! Threshold is either percentage or minimum bandwidth amount

!
!
Default is 5 percent or 10 Kbps; range is 510080 (7 days)

Resets and restarts application for the tunnel
overflow threshold percentage [min bandwidth] limit limit

:router(config-if-tunte-autobw)# overflow threshold 20 limit 5
Configures action when bandwidth overflow occurs

Overflow detection applies only to increasing bandwidth use
Version 3.9.0a
XMPLST4Module 6/186
mpls traffic-eng auto-bw apply {all | tunnel-te tunnel-number}

:router# mpls traffic-eng auto-bw apply tunnel-te 452
Apply the highest collected bandwidth
!Must specify a tunnel or all tunnels

!Does not wait for next application period to end
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/187
6195
Module 6
Displaying Automatic Bandwidth

You can review the automatic bandwidth information by using the
show mpls traffic-eng tunnels auto-bw brief command:
Tunnel NameTunnel identification
LSP IDLabel-switched path ID used by this tunnel
Last appl BW (kbps)Last requested bandwidth that was applied
Requested BW (kbps)Actual requested bandwidth for this tunnel
Signalled BW (kbps)Actual bandwidth that was signaled for this

tunnel
Highest BW (kbps)Highest measured bandwidth since the last

application interval for this tunnel
Application Time LeftAmount of time left until the application

ends for this tunnel
Clearing Automatic Bandwidth

You can use the clear mpls traffic-eng auto-bw command to reset the
high bandwidth collection information to start a new collection.
6196
Version 4.0.1

Module 6
Displaying and Clearing Automatic Bandwidth
:router#
show mpls traffic-eng tunnels auto-bw brief
:router# show mpls traffic-eng tunnels auto-bw brief

Thu Apr 15 04:22:58.833 UTC
Tunnel
LSP Last appl Requested Signalled
Highest
Application
Name
ID
BW(kbps)
BW(kbps)
BW(kbps)
BW(kbps)
Time Left
-------------- ------ ---------- ---------- ---------- ---------- -------------tunnel-te452
1
10
10
10
50
4m 59s
Version 3.9.0a
XMPLST4Module 6/189
:router#
clear mpls traffic-eng auto-bw
:router# clear mpls traffic-eng auto-bw

:router# show mpls traffic-eng tunnels auto-bw brief
Thu Apr 15 04:22:58.833 UTC
Tunnel
LSP Last appl Requested Signalled
Highest
Application
Name
ID
BW(kbps)
BW(kbps)
BW(kbps)
BW(kbps)
Time Left
-------------- ------ ---------- ---------- ---------- ---------- -------------tunnel-te452
1
10
10
10
0
3m 9s
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/190
6197
Module 6
Link Management Commands

You may on occasion need to have your IGP flood new MPLS TE tunnel
information. Rather than waiting for the normal interval to expire, you can
use the mpls traffic-eng link-management flood command to achieve
the IGP notification. In some instances, when there is no difference
between the new information and the current information in the OSPF
LSA or IS-IS LSP, the IGP may choose to dampen the advertisement.
To display the Cisco MPLS TE link advertisement information, you can use
the show mpls traffic-eng link-management advertisements
command.
6198
Version 4.0.1

Module 6
Link Management Commands
:router#
mpls traffic-eng link-management flood

:router# mpls traffic-eng link-management flood
Floods all MPLS TE links immediately

flooding thresholds {down | up} percent [percent1 [percent2 [.percent15]]]

:router(config-mpls-te-if)# flooding thresholds down 100 75 50
:router(config-mpls-te-if)# flooding thresholds up 10 25 40
Sets reserved bandwidth threshold for links

Crossed threshold causes link management advertisement
- Otherwise link management advertisements occur based on periodic

flooding setting
Version 3.9.0a
XMPLST4Module 6/192
:router#
show mpls traffic-eng link-management advertisements
:router# show mpls traffic-eng link-management advertisements
Display MPLS TE link advertisement information
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/193
6199
Module 6
When analyzing problems, you may find it helpful to clear out existing
information before starting your review of the information. One useful
command is the clear mpls traffic-eng link-management statistics
command, which will clear any existing admission control statistics.
6200
Version 4.0.1

Module 6
Link Management Commands (Cont.)
:router#
clear mpls traffic-eng link-management statistics

:router# clear mpls traffic-eng link-management statistics
Clear MPLS TE admission control information
Version 3.9.0a
Version 4.0.1
XMPLST4Module 6/194
6201
Module 6
Summary
In this module, you learned the following:
6202
Describe Cisco MPLS TE and its operation
Discuss MPLS dynamic traffic engineering
Implement, analyze, and examine an MPLS dynamic Cisco MPLS TE

configuration
Implement, analyze, and examine an MPLS explicit Cisco MPLS TE

configuration
Describe Cisco MPLS TE FRR operation
Implement, analyze, and examine an Cisco MPLS TE FRR

configuration
Version 4.0.1

Module 6
Summary
Additional Instructor Information

This section contains additional information for the instructor that could
not be fit into standard instructor notes.

The sub-TLVs for type 22, the extended IS reachability TLV, are:
Sub-TLV type
Length
Name
Administrative group, also called color
IPv4 interface address
IPv4 neighbor address
Maximum link bandwidth
10
Maximum reservable link bandwidth
11
32
18
TE default metric
250-254
Reserved for Cisco specific extensions
255
Reserved for future expansion
Bandwidth parameters are in bytes per second and the unreserved

bandwidth is the same as the previously discussed OSPF definition.
The new layout of the TLV 135, Extended IP Reachability TLV, data is:
Metric information 4 octets
Control information 1 octet

!
Up and down information 1 bit
Sub-TLV presence indicator 1 bit
Prefix length 6 bits
IPv4 prefix 0-4 octets
Optional sub-TLV 0-250 octets, consisting of

!
Sub-TLV length 1 octet
Sub-TLVs 0-250 octets of sequential sub-type (1 octet), length (1

octet), and value (0-247 octets)
Version 4.0.1
6203
Module 6
This page intentionally left blank.
6204
Version 4.0.1

Module 7
Layer 2 VPNs
Overview
Description
This module provides an overview and configuration examples for the
implementation of MPLS L2VPNs on systems using the Cisco IOS XR
operating system.
Objectives
After completing this module, you will be able to do the following:
Describe Layer 2 VPNs
Implement and verify L2VPNs
Compare Layer 2 and Layer 3 VPNs
Describe and define pseudowires and their use
Define AToM, its use, and interworking with Cisco IOS XR operating
system software
Define and configure EoMPLS
Define and implement pseudowire redundancy
Define and configure VPLS flat and hierarchical architectures
Define pseudowire switching
Version 4.0.1
71
Layer 2 VPNs
Module 7
Introduction to Layer 2 VPNs

Initially, service providers offered pointtopoint data link layer
connectivity, using ATM, Frame Relay, or leased line TDM circuits.
Customers then built their own Layer 3 networks to accommodate IP
traffic. As a result, separate networks existed for Layer 2 and Layer 3
traffic. However, maintaining separate networks for Layer 2 VPNs and
Internet traffic is difficult and costly. As a result demand is increasing for
a single IPbased network to provide both Layer 2 and Layer 3 services.

Traditionally L2VPNs were pointtopoint mechanisms for extending
Layer 1 and Layer 2 circuits across a Frame Relay, ATM, and TDM type
transport networks.
72
Version 4.0.1

Module 7
Service model used to interconnect customer sites using

Layer 2 circuits or transport
Traditionally used leased lines or virtual circuits such as ATM or

Frame Relay VCs
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/4
73
Layer 2 VPNs
Module 7
Current Approach to Layer 2 VPNs

Any Transport over MPLS (AToM) is a mechanism for transporting a
customer's L2 circuits in the form of DLCIs, PVCs, VLANs, and so on,
across an MPLS based Service Providers (SP) backbone. AToM is an L2
transport solution specifically for Service Provider's with an MPLS
backbone while L2TPv3 is geared for service providers with an IP
backbone. The preceding Layer 2 transport solutions could be broadly
categorized as L2VPNs.
74
Version 4.0.1

Module 7
Current Approach to Layer 2 VPNs
Uses Layer 2 transport mechanisms such as AToM or

L2TPv3
VPN where packets are forwarded based on Layer 2 information

Result is an IP network that provides both Layer 2 and Layer 3
services
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/5
75
Layer 2 VPNs
Module 7
Layer 2 Transport Types

The Layer 2 transport mechanisms discussed allow service providers to
have a single infrastructure that supports IP plus Layer 1 and Layer 2
legacy services. Migrating to a packet based MPLS core requires only
incremental provisioning. Implementing these Layer 2 transport models
results in network consolidation plus capital and operational savings.
Building a L2VPN system requires coordination between the ISP and the
customer. The ISP provides Layer 2 connectivity; the customer builds a
network using data link resources obtained from the ISP. In a L2VPN
service, the ISP does not require information about the customer's network
topology, policies, routing information, point-to-point links, or network
point-to-point links from other ISPs.
76
Version 4.0.1

Module 7
Layer 2 Transport Types
Point-to-point mechanism for extending Layer 1

and Layer 2 circuits across a packet based
transport network
Examples of Layer 2 transport are:
VPWS Point-to-Point
!AToM
" EoMPLS
!L2TPv3
VPLS Point-to-Multipoint
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/6
77
Layer 2 VPNs
Module 7
Layer 2 VPN Structural Hierarchies

There are three types of L2VPNs classified in two categories, virtual
private LAN service, and virtual private wire service:
Virtual Private Wire Service (VPWS)VPWS is a point-to-point circuit

that connects two Customer Edge (CE) devices. This is a logical link
established across a packet switched network. The CE in the customer
network is connected to a PE in the provider network using an
attachment circuit (AC) that is either a physical or a logical circuit.
VPWS services are achieved using either Layer 2 Tunneling Protocol
Version 3 (L2TPv3) or Any Transport over MPLS (AToM).
Virtual Private LAN Service (VPLS)VPLS is a provider service that

emulates the full functionality of a traditional Local Area Network
(LAN). VPLS makes it possible to interconnect several LAN segments
over an MPLS-based packet switched network (PSN) where the remote
LAN segments behave as one single LAN. The PSN emulates a
learning bridge where forwarding decisions are based on MAC
addresses.
_____________________________ Note _________________________

VPWS differs from VPLS in that the VPLS is point to multipoint, while
the VPWS is point to point.
__________________________________________________________________
!
Layer 2 Tunneling Protocol Version 3 (L2TPv3)L2TPv3 is a

version of L2TP that is an alternative to MPLS for the
encapsulation of multiprotocol Layer 2 communications traffic
over IP networks. Like L2TP, L2TPv3 provides a pseudowire
service, but one that is scaled to fit carrier requirements.
Any Transport over MPLS (AToM)AToM does for MPLS based

networks what L2TPv3 do for IP infrastructures. It allows for the
encapsulation and tunneling of Layer 2 packets across an MPLS
network. AToM supports traditional Frame Relay, ATM, and leased
line services, as well as transparent LAN services (TLS), linking
together remote Ethernet networks. AToM links any pair of
provider edge (PE) routers with a single label switched path (LSP)
instead of a multiple VCs by using label stacking.
!
78
ATMoMPLS supports ATM Adaptation Layer 5 (AAL5)

transport. This is a type of Layer 2 point-to-point connection
over an MPLS core. ATMoMPLS and ATM local switching are
supported only for ATM-to-ATM interface-to-interface switching
combinations.
Version 4.0.1

Module 7
Layer 2 VPN Structural Hierarchies
L2VPN Models
VPLS
VPWS
Virtual Private Wire Service
Virtual Private LAN Service
Point-to-point
Point-to-multipoint
MPLS Core
MPLS Core
IP Core
L2TPv3
AToM
Ethernet
Ethernet
Frame Relay
Frame Relay
ATM (AAL5 & Cell)
ATM (AAL5 only)
PPP & HDLC
PPP & HDLC
Ethernet
Circuit Emulation
Version 3.9.0a
XMPLST4Module #/7
Instructors Note
This course focuses on AToM functionality
L2VPN working group is responsible for defining and specifying a limited number of solutions
for supporting provider provisioned L2VPNs. These solutions include, Virtual Private LAN
Service (VPLS), Virtual Private Wire Service (VPWS), and IPonly L2VPNs.
The pseudowire edge-to-edge emulation (PWE3) working group provides the framework for
edgetoedge wire emulation over a packet based provider network so that a service provider can
offer Layer 2 services such as ATM and FR by tunneling them across the backbone. The
backbone can be either IP or MPLS or L2TP. PWE3 is focused on providing the implementation
details of edgetoedge emulation across a packet network as well as providing interworking
functionality between the different edge services.
Version 4.0.1
79
Layer 2 VPNs
Module 7
L2VPN and L3VPN Comparison

The characteristics of Layer 2 and Layer 3 virtual private networks are:
MPLS (Layer 3) VPNs use Layer 3 information to make forwarding

decisions. This requires service provider involvement in the routing
process
!
710
MPLS VPNs require a customer edge to provider edge routing

process in addition to PE-to-PE signaling using MP-BGP
Layer 2 VPNs use Layer 2 information to make forwarding decisions.

These decisions can be made on Ethernet MAC addresses, VLAN IDs,
DLCI information, or an input interface for leased line connectivity
Version 4.0.1

Module 7
L2VPN and L3VPN Comparison
Layer 2 VPNs
Layer 3 VPNs
Forwarding based on Layer 2

information
For example, Ethernet
Forwarding based on Layer 3

information
For example, IP
Advantageous for:
Advantageous for:
Customers who prefer to
outsource their WAN to service
providers
Customers who run their own

Layer 3 networks and require only
Layer 2 connectivity over the WAN
Smaller and metro-area

networks
Service provider delivers only Layer 2

connectivity
Service provider involved in customer

routing
Customers share routes with
service provider
Technologies:
VPWS (AToM, L2TPv3)
VPLS
Technologies:
BGP and MPLS VPNs
MPLS VPN over IP
GRE
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/8
711
Layer 2 VPNs
Module 7
Pseudowire
From the customer perspective a pseudowire (PW) is characterized as an
unshared link or circuit. The pseudowire edge-to-edge emulation (PWE3)
working group within the IETF defines pseudowire technology as an
emulated point-to-point connection over a packet switched network that
allows the interconnection of two nodes with any Layer 2 technology.
Pseudowires may be point-to-point, or point-to-multipoint. Point-to-point
PWs are always considered bidirectional; point-to-multipoint PWs are
always considered unidirectional.
Pseudowires support the following payloads:
PacketsPacket payloads are supported by Ethernet, HDLC and PPP

framing, frame relay and ATM AAL5 PDUs
CellsCell payloads are supported by ATM
Bit streamStream payloads are supported by unstructured1 E1/T1

and E3/T3 pseudowire services
Structured bit streamStructured2 bit stream payloads are supported

by SONET and SDH pseudowire services
_____________________________ Note _________________________

1. Unstructured TDM circuitsTDM stream is considered
unstructured when its structure (framed, unframed, or channelized)
is deemed inconsequential from the transport point of view. In such
cases all structural overhead is transparently transported by the
PW along with the payload data, and the encapsulation method
employed provides no mechanisms for its location or utilization.
2. Structured bit streamStructured bit stream payload is created by
using knowledge of the underlying structure of the bit stream to
capture, transport, and replay the bit pattern across an emulated wire.
Some parts of the original bit stream may be stripped in the ingress
direction (for example, in structured SONET the section and line
overhead may be stripped) and regenerated at egress.
__________________________________________________________________
712
Version 4.0.1

Module 7
Pseudowire
Pseudowire is the emulation of a Layer 2 point-to-point

connection-oriented service over a PSN
Pseudowire emulates the operation of a transparent wire

carrying the service
Payload Type
PW Service
Packet
Ethernet (all types), HDLC framing, PPP,

Frame Relay, ATM AAL5 PDU
Cell
Bit stream
Structured bit stream
ATM
Unstructured E1/T1, E3/T3
SONET/SDH
PSN may be
- IP
- IP and MPLS
Version 3.9.0a
XMPLST4Module #/9
Instructors Note
Unstructured - bit stream overhead is treated as part of the payload
Structured - payload created requires knowledge of the underlying bit stream; may be transmitted
in entirety or part; can be recreated at egress
Version 4.0.1
713
Layer 2 VPNs
Module 7
Pseudowire Technology
L2VPNs are built using PW technology. PWs provide a common,
intermediate format to transport multiple types of network services over a
PSN. As depicted in the diagram PW technology provides like-to-like (L2L)
and interworking (IW) transport.
The CRS-1 does not support AToM interworking. The interworking
features supported by the Cisco XR12000 Series Router are discussed later
in this module.
714
Version 4.0.1

Module 7
Pseudowire Technology
L2VPNs are built with PW technology

PWs provide a common, intermediate format to transport
multiple types of network services over a PSN
PW technology provides like-to-like (L2L) and interworking (IW)

transport
Ethernet
Ethernet
ATM
Frame
Relay
Ethernet
ATM
ATM
Like-to-like
Frame
Relay
Version 3.9.0a
Version 4.0.1
Ethernet
Frame
Relay
Interworking
XMPLST4Module #/10
715
Layer 2 VPNs
Module 7
Pseudowire Reference Model

The goal of the emulated service that uses pseudowire technology is for the
Customer Edge (CE) equipment to see the PW as an unshared link or circuit
between its CE devices. The attachment circuit (AC) is the physical or virtual
circuit attaching a CE to a provider edge device (PE). The PE device
encapsulates the protocol data units (PDUs) which are sent over the PW to the
egress PE where Layer 2 or Layer 1 headers are reconstructed and the
resultant frames are forwarded in their native format to the corresponding
CE.
716
Version 4.0.1

Module 7
Pseudowire Reference Model
Emulated service
Pseudowire
Native
service
Native
service
PSN
tunnel
PW1
CE
AC
AC
PW2
PE
AC
PE
CE
AC
CE
CE
Customer edge (CE) equipment perceives a PW as an
unshared link or circuit

An attachment circuit (AC) is the physical or virtual circuit
attaching a CE to a PE
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/11
717
Layer 2 VPNs
Module 7
Pseudowire Enables VPLS, AToM, and L2TPv3

With PW, we are able to transport a wide range of Layer 1 and Layer 2
traffic across a PSN. Depending on the network infrastructure, systems in
use, and customer requirements, this is accomplished using Virtual Private
LAN Service (VPLS), Any Transport over MPLS (AToM), or Layer 2
Transport Protocol version 3 (L2TPv3).
As seen in the diagram, service transports are over a shared packet
switched network (PSN) that supports multiple encapsulation types in
addition to service interworking.
718
Version 4.0.1

Module 7
Pseudowires Enable VPLS, AToM, and L2TPv3
Service transports over a shared
Provider
edge
packet switched network
Multiple encapsulation types

supported
Service interworking
Packet switched
network
Bridged
Ethernet
Provider
edge
Pseudowire
FR
ATM
HDLC
PPP
Ethernet
example
Ethernet
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/12
719
Layer 2 VPNs
Module 7

Any Transport over MPLS (AToM) transports Layer 2 packets over a
MPLS backbone, enabling service providers to connect customer sites with
existing Layer 2 networks by using a single, integrated, packet-based
network infrastructure. Using this feature, service providers deliver
Layer 2 connections over an MPLS backbone, instead of using separate
networks.
Multiple Services over Common Infrastructure

Service providers are going from an environment of providing many
services over many networks (not cost effective), to providing many
services over one network using the PW for the Layer 2 and Layer 1 traffic,
and MPLS or IP for the Layer 3 traffic.
AToM encapsulates Layer 2 frames at the ingress PE router and sends
them to a corresponding PE router at the other end of a pseudowire. The
egress PE removes the encapsulation and sends out the Layer 2 frame. The
successful transmission of the Layer 2 frames between PE routers is based
on the configuration of the PE routers.
720
Version 4.0.1

Module 7
Multiple Services over Common Infrastructure
ATM
Frame
Relay
IP
VPN
Frame Relay
Frame Relay
ATM
IP/MPLS
RPR
Internet
Internet
Ethernet
ATM
Ethernet
Many services,
one network,
(pseudowire)
Many services,
many networks
IP/MPLS
PPP
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/14
721
Layer 2 VPNs
Module 7
AToM Interworking
In AToM interworking (IW) a pseudowire links two attachment circuits
with different data-link layer protocols. You provision Layer 2 any-to-any
IW circuits using AToM packet-switched networks (PSNs). IW functions
perform the translation and adaptation necessary to interconnect disparate
attachment circuits. It does this by using a native service that resides in
the PE (for IW, this is called a native service processor (NSP)) between the
pseudowire termination and the attachment circuit.
IP interworking provides IP connectivity between sites, regardless of the
Layer 2 connectivity to these sites. This is different from a Layer 3 VPN,
because it is point-to-point in nature, and the service provider does not
maintain any customer routing information.
These are the supported modes of IP interworking in AToM:
722
ATM-to-EthernetConfigure both ATM and Ethernet PE routers for IP

interworking
Ethernet port-to-VLAN modeCreate an Ethernet virtual local area

network (VLAN) among geographically separated sites, using the
Ethernet port mode. Different sites can operate together over an MPLS
network as though they were on a common Ethernet network
ATM Adaptation Layer Type-5 (AAL5) Allows efficient transportation

of PVCs across the MPLS backbone. Multiple PVCs can be multiplexed
onto a single label switched path between the provider edge routers
Version 4.0.1

Module 7
AToM Interworking
Supported AToM interworking modes in

Cisco IOS XR operating system
!ATM to Ethernet
!Ethernet port to VLAN mode
!ATM AAL5 multiple PVCs multiplexed on a
single LSP
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/15
723
Layer 2 VPNs
Module 7
AToM
The primary task of Any Transport over MPLS (AToM) is establishing
pseudowires between provider edge (PE) routers and carrying Layer 2
packets over these pseudowires.
AToM is an implementation of Virtual Private Wire Service (VPWS) for
MPLS networks. It provides point-to-point transport for Layer 2 traffic,
including Ethernet, ATM, FR, PPP, HDLC and TDM across MPLS packetbased core networks. By adding QoS and MPLS traffic engineering
features to AToM service providers can offer virtual leased line types of
services. One major feature of AToM is that the service provider does not
need to participate in customer routing.
724
Version 4.0.1

Module 7
AToM
AToM
Frame Relay
ATM
Leased line,
Ethernet
Frame Relay
ATM
IP/MPLS Core
Leased line,
Ethernet
AToM is an implementation of VPWS for MPLS networks

Provides point-to-point transport for Layer 2 traffic, including
Ethernet, ATM, FR, PPP, HDLC and TDM across MPLS packetbased core networks
AToM, with QoS and MPLS traffic engineering, allows service

providers to offer virtual leased line types of services
Service provider does not participate in customer routing
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/16
725
Layer 2 VPNs
Module 7
Control Plane: PW Establishment

These steps describe the procedure for the establishment of an AToM
pseudowire:
1. An attachment circuit is configured with a peer IP address and PW
ID on PE1
2. PE1 initiates a directed LDP session to PE2 if one does not exist
3. PE1 allocates a PW Label for the new circuit and binds it to the
configured PW ID
4. PE1 encodes the local pseudowire label into the label TLV and the
pseudowire ID into the FEC TLV. PE1 sends this label binding to
PE2 in a label mapping message
5. PE2 receives VC FEC TLV and VC Label TLV that match its local
PW ID
6. PE2 repeats the preceding steps so that bi-directional label and PW
ID mappings are established
The illustration shows a L2VPN (AToM) was established between the
Ethernet ACs on PE4 and PE6 in the lab. The configuration at both ends of
the VPN defined a PW ID of 1010. MPLS automatically linked the PW ID
to a PW label of 16013.
726
Version 4.0.1

Module 7
LSP tunnel
Pseudowire
MPLS
CE
Directed LDP
session
PE1
PE2
1. Attachment circuit
configured with peer
address and PW ID!
CE
Attachment
circuit
5. PE2 receives VC FEC

TLV and VC label TLV
that match local PW ID!
2. PE1 starts directed LDP

session with PE2, if one
does not already exist!
6. PE2 repeats steps 15 so

that bi-directional label
and PW ID mappings are
established
3. PE1 allocates VC label for

new circuit and binds to
configured PW ID!
4. PE1 sends LDP label
mapping message
containing VC FEC TLV and
VC label TLV!
Version 3.9.0a
XMPLST4Module #/18
:router# show l2vpn xconnect detail

Group test1, XC pe44-pe66,state is up;Interworking none,AC: G0/4/0/4,state up
Type Ethernet MTU 1500; XC ID 0x5000001; interworking none
Statistics: packets: received 51, sent 51 bytes: received 5135, sent 5135
PW: neighbor 10.6.6.66, PW ID 1010, state is up ( established )
PW class test, XC ID 0x5000001 Encapsulation MPLS, protocol LDP
PW type Ethernet, control word disabled, interworking none
PW backup disable delay 0 sec Sequencing not set
MPLS
Local
Remote
------------ ------------------------------ -------------------------Label
16013
16013
Group ID
0x5000800
0x5000800
Interface
MTU
1500
1500
Control word disabled
disabled
PW type
Ethernet
Ethernet
VCCV CV type 0x2
0x2
(LSP ping verification)
VCCV CC type 0x6
0x6
(router alert label)
(TTL expiry)
(TTL expiry)
------------ ------------------------------ -------------------------
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/19
727
Layer 2 VPNs
Module 7
Emulated Circuit Traffic Forwarding

In the illustration on the adjacent page, the Layer 2 frame from the Site 1
AC is received by PE1. PE1 assigns the PW inner label that is established
by a directed LDP session, and is linked to the PW ID. The PW ID is
configured on the PEs at each end of the PW. PE1 encapsulates the
Layer 2 frame in an MPLS frame. The tunnel label for the LSP is
determined by LDP, and changes hop by hop.
On ingress, PE1 directs the frame from the PE AC to the proper PW and
from the PW to the proper egress PE AC, PE2 in this example.
The PW ID at each end of a PW must match when configured. The PW
labels that are linked to the PW ID do not need to match.
728
Version 4.0.1

Module 7
Emulated Circuit Traffic Forwarding
MPLS Core
18 50
18 90
PE1
18
PE2
40 20
60 20
Site1
Site2
Site2
Tunnel label
VC label
Original packet
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/20
729
Layer 2 VPNs
Module 7
Control Protocols
The control and forwarding protocols for AToM are comprised of the
targeted LDP control session, and the three layers of encapsulation that
make up the emulated circuit.
Control Connection
Targeted LDP sessions are used for VC label negotiation, label withdrawal
and error notification. They are established through LDP extended
discovery between PE routers and use periodic targeted hellos. When used
with pseudowire emulation targeted hellos distribute VC labels.
Forwarding Protocols
Forwarding protocols have three layers of encapsulation.
Tunneling Component
The tunnel label, also referred to as the LSP label, establishes the
connectivity between a pair of PEs. This is a non-targeted LDP session
established through LDP basic discovery between a PE router and its
directly connected P routers, and is used to distribute tunnel labels. The
distribution and management of tunnel labels is a function of the
deployment of the underlying MPLS network. The MPLS LSP is derived
using LDP or RSVP-TE.
De-multiplexing Component
The VC label identifies the individual attachment circuits on the receiving
PE router. VC labels are either statically defined during configuration or
negotiated using the control plane.
Layer 2 Encapsulation and Control Word
During pseudowire establishment, the PE routers exchange label-mapping
messages. Interface parameters must match between peering PE routers.
For example, if the attachment circuit interface MTU of the peered PE
routers does not match, a pseudowire is not established.
The control word is required with Frame Relay and AAL5 Layer 2 protocol
data units (PDU). For other Layer 2 protocol types the control word is
optional. Information in the headers of those Layer 2 PDUs must be
accounted for, such as, Frame Relay BECN, FECN, DE, and C/R.
730
Version 4.0.1

Module 7
Control and Forwarding Protocols
Control
connection
Targeted LDP
Used for VC-label negotiation, withdrawal, error
notification
Emulated circuits have three layers of encapsulation

Tunnel header (tunnel label)
Gets PDU from ingress to egress PE

MPLS LSP is derived using LDP or RSVP-TE
Tunneling
component
De-multiplexer field (VC label)

Demultiplexing
component
Layer 2
encapsulation
Identifies individual circuits within a tunnel

Can be an MPLS label, L2TPv3 header, GRE key
Emulated PW encapsulation (control word)
Information on enclosed Layer 2 PDU
Implemented as a 32-bit control word
Version 3.9.0a
XMPLST4Module #/21
Instructors Note
A pseudowire is comprised of two VCs, one in each direction.
Version 4.0.1
731
Layer 2 VPNs
Module 7
Control Protocol Signalling

AToM PWs consist of two unidirectional LSPs. A PW label represents each
LSP. PW emulation defines an extension to LDP known as a PW ID FEC
element that contains a PW identifier shared by the pseudowire endpoints.
The virtual circuit FEC element has these components:
732
VC TLVValue of 128 identifies this as a PW FEC element
Control word (C-bit) The control word is an optional 4-byte field that
is located between the label stack and Layer 2 packet, when present.
The C-bit set says the advertising PE expects the control word to be
present in PW packets.
VC typeA 15-bit field that defines the type of PW; some examples are:
!
0x0001 FR DLCI
0x0004 Ethernet VLAN
0x0005 Ethernet
0x0006 HDLC
0x0007 PPP
VC information lengthLength of VC ID and interface parameters

fields. A value of zero refers to all VCs in the group ID field
Group IDA value assigned to a group of VCs
VC IDSame as a PW ID. A field that distinguishes PWs from each

other. For two ACs to be attached, they are associated with the same
VC ID
Interface parametersA variable length interface parameter field that

provides AC information, such as MTU or interface description
Version 4.0.1

Module 7
Control Protocol Signalling
VC TLV
VC Type
VC info length
Group ID
VC ID
Interface parameters
Virtual circuit FEC element representation, used for VC setup

Emulated VC signaling is done using directed LDP session between PEs
- VC TLV Identifies this as a PW ID FEC element

- VC typeIdentifies type, FR, ATM, VLAN Ethernet, PPP, HDLC
- VC info lengthLength of VC ID and interface parameter field
- Group IDRepresents a group of VCs
- VC IDSame as PW ID; distinguishes PWs from each other; VC IDs must be the
same for ACs to attach
- Interface parametersVariable-length edge-facing interface parameters

! MTU (required matching parameter)
! Interface description
! AToM maximum number of concatenated cells
Version 3.9.0a
XMPLST4Module #/22
Instructors Note
The LDP specification defines Layer 3 FECs based upon the IGP only. PW emulation defines
extensions to LDP.
The VC label is part of the encoding stack that encapsulates the Layer 2 packets traveling over
PWs.; it is a forwarding plane parameter and is the same as the attachment circuit label.
Version 4.0.1
733
Layer 2 VPNs
Module 7
Encapsulation Detail
Following a native Layer 2 header (not shown in the illustration) are the
tunnel label, VC label, control word, and the Layer 2 PDU:
734
Tunnel labelDerived from LDP or RSVP, it represents the IGP path

to the peering PE router
VC labelAlso known as the PW label, it directs the Layer 2 PDU to

the corresponding attachment circuit on the peering PE router
Control word The control word preserves and transfers information

from the header of various Layer 2 PDUs that arrive on ACs (for
example, Frame Relay BECN, FECN, DE, and C/R)
!
First 4-bitsSet to zero to delineate this from the MPLS payload.

For pseudowire data packets, the first nibble in the control word is
reserved and set to 0. Virtual circuit connectivity verification
(VCCV) (discussed later) control channel type 1 traffic requires a
control word
FlagsUsed for payload signaling, such as a Frame Relay FECN,

BECN, and so on
FRGFragment; allows fragmenting a payload. Cisco IOS XR

operating system does not fragment payloads
LengthUsed by egress PE to determine the size of any padding

that may have been added by the PSN for small packets sent across
an Ethernet link. Permits removal of the padding before switching
to the AC
SequencingAllows PEs to ensure packets are received in order
Version 4.0.1

Module 7
Encapsulation Detail
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
TTL
VC label (VC)
EXP
TTL (set to 2)
VC label
Control word
0000
Flag
FRG
Length
Sequence number
Layer 2 PDU
Three-level encapsulation
!Packets are switched between PEs using top (tunnel) label

!VC label (demux) identifies PW attachment circuit
!Optional control word carries Layer 2 control bits and enables
sequencing
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/23
735
Layer 2 VPNs
Module 7
Implementing Virtual Private Wire Service (VPWS)

VPWS L2VPNs are a network of point-to-point connections that connect
remote customer sites in a VPN. The L2VPNs provide a simpler, lower cost
alternative to more complex private networks provisioned using dedicated
leased lines or using Layer 2 VCs that employ ATM or Frame Relay.
Implementing a L2VPN
On the core facing edge router, or Network Provider Edge (N-PE) router,
configure:
The interface to act as a Layer 2 transport; any configured IP address

needs to be removed
LDP using the mpls ldp command
736
Assign a router ID
Add the core interfaces that use LDP
L2VPN; enter L2VPN configuration mode to:

!
Create a PW class and define the MPLS method of encapsulation.

This encapsulation method may be applied to defined cross
connected PE routers
Define a cross-connect group and connection type (point-to-point or

point-to-multipoint)
Define the attachment circuit to be linked to the PW
Define the PE neighbors loopback address with PW ID and use the

PW class to determine the encapsulation. The PW ID must match
on both ends of the PW link
Version 4.0.1

Module 7
Implementing a L2VPN
p0/3/0/1
p0/3/0/0
CE4
MPLS
P2
N-PE4
p0/3/0/0
p0/3/0/1
CE6
N-PE6
Configure attachment circuit as a

L2 transport
:(config)# interface pos0/3/0/0 l2transport

:(config-if)# exit
Enable LDP
Define LDP router-id
Define LDP interfaces
:(config)# mpls ldp

:(config-ldp)# router-id 10.4.4.4
:(config-ldp)# interface pos0/3/0/1
p0/3/0/1
p0/3/0/0
CE4
N-PE4
L2VPN configuration mode

Create a PW class
Define encapsulation
Define cross-connect group
Define p2p xconnect and name
Define attachment circuit
Define neighbor and PW-ID that
identifies AC
Attach PW-class to PW
p0/3/0/0
p0/3/0/1
Version 3.9.0a
Instructors Notes
MPLS
P2
N-PE6
CE6XMPLST4Module #/26
:(config)# l2vpn
:(config-l2vpn)# pw-class TEST
:(config-l2vpn-pwc)# encapsulation mpls
:(config-l2vpn)# xconnect group TEST1-GRP
:(config-l2vpn-xc)# p2p PE4-PE6
:(config-l2vpn-xc-p2p)# interface pos0/3/0/0
:(config-l2vpn-xc-p2p)# neighbor 10.6.6.6
pw-id 1010
:(config-l2vpn-xc-p2p-pw)# pw-class TEST
Version 3.9.0a
XMPLST4Module #/27
When you enable sequencing using any of the available options, the sending of sequence
numbers is automatically enabled and the remote provider edge (PE) peer is requested to
send sequence numbers. Out-of-order packets received on the pseudowire are dropped
only if you use the (config-l2vpn-pwc-mpls)#sequencing receive or sequencing
both command.
Version 4.0.1
737
Layer 2 VPNs
Module 7
Display Status of the L2VPN

The show l2vpn xconnect command provides a summary of xconnect
groups, names, ACs and egress PEs and their status.
In the example on the adjacent page, there is an xconnect group called
test1-grp. This group is configured with one cross connect. The overall
status of the pe4-pe6 PW is up. The N-PE4 attachment circuit is up and
the PW ID connection to the egress PE is also up.
738
Version 4.0.1

Module 7
State of the L2VPN
p0/3/0/1
p0/3/0/0
CE4
MPLS
P2
N-PE4
p0/3/0/0
p0/3/0/1
N-PE6
CE6
:N-PE4# show l2vpn xconnect

Fri Feb 12 21:20:55.944 UTC
Legend: ST = State, UP = Up, DN = Down, AD = Admin Down, UR = Unresolved,
LU = Local Up, RU = Remote Up, CO = Connected, SB = Standby
XConnect
Segment 1
Segment 2
Group
Name
ST
------------------------
Description
ST
---------------------
Description
ST
-------------------------
PO0/3/0/0
10.6.6.6
test1-grp
pe4-pe6
UP
UP
1010
UP
PW ID
PW name
Attachment circuit
----------------------------------------------------------------------------
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/28
739
Layer 2 VPNs
Module 7
Display L2VPN Cross-Connect Details

To display L2VPN cross-connect information, use the show l2vpn
xconnect detail command.
740
The first line shows the xconnect group and the attachment circuits at
both ends of the PW as POS interfaces. The PW link is up and there is
no interworking (same interface type at both ends)
The next two lines show the attachment circuit, the interface type, the
state, the Layer 2 encapsulation type, and MTU size
The PW parameters are described next: the PE neighbor with PW ID

1010 (configured on both PEs and must be the same) and the state, the
PW class that setup the MPLS encapsulation, the LDP protocol used to
establish the directed LDP session, the PW type (HDLC), and the
status of the control word
MPLS
!
LabelThe local and remotely assigned VC labels for ACs. The VC

AC labels do not need to match. These labels are assigned by each
router individually
Group IDInternally assigned ID the represents the test1-grp on

each PE
InterfaceAttachment circuit interface on each end of the PW
MTUAttachment circuit MTU at both ends of the PW
Control wordControl word status at both ends of the link
PW typeBoth ends of the link are the same, HDLC. There is no

interworking for this xconnect session
VCCV CV typeVCCV connectivity verification (CV). CV type

defines a bit mask indicating the types of CV packets that use the
control channel defined. Type 1 is MPLS echo request, type 2 is echo
reply
VCCV CC typeVCCV control channel (CC). 0x7 defines a bit mask

indicating the types of control channels that can be used to receive
traffic to verify connectivity, in this case all three types. The control
word is type 1; router alert label is type 2, and MPLS inner label
TTL is type 3
Version 4.0.1

Module 7
Display L2VPN Cross-Connect Details
:N-PE4# show l2vpn xconnect detail

Group TEST1-GRP, XC pos-pos, state is up; Interworking none
AC: POS0/3/0/0, state is up
Type HDLC MTU 4470; XC ID 0x4000002; interworking none
Statistics: packets: rx 141, sent 51 bytes: rx 9639, sent 4095
PW class test, XC ID 0x4000002 Encapsulation MPLS, protocol LDP
PW type HDLC, control word enabled, interworking none
PW backup disable delay 0 sec
Sequencing not set
MPLS
Local
Remote
------------ ------------------------------ ------------------------Label
16007
16008
Group ID
0x4000400
0x4001400
Interface
POS0/3/0/0
POS0/3/0/0
MTU
4470
4470
Control word enabled
enabled
PW type
HDLC
HDLC
VCCV CV type 0x2
0x2
VCCV CC type 0x7
0x7
(control word)
(control word)
(TTL expiry)
(TTL expiry)
------------ ------------------------------ ------------- 2011, Cisco Systems, Inc. All rights reserved.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/29
741
Layer 2 VPNs
Module 7
Ethernet over MPLS (EoMPLS)

This section covers the AToM subset called Ethernet over MPLS
(EoMPLS).
EoMPLS
EoMPLS is one of the Any Transport over MPLS (AToM) types. AToM
transports Layer 2 packets over an MPLS backbone using a directed LDP
session between edge routers for setting up and maintaining connections.
EoMPLS encapsulates Ethernet protocol data units (PDUs) in MPLS
packets and forwards the packets across the MPLS network. Each PDU is
transported as one packet. This allows connecting two VLAN networks in
different locations that are geographically separated and have them appear
as a single entity. It permits connecting two Ethernet networks that are
geographically separated, and have the two networks appear as one logical
Ethernet or VLAN domain.
Service providers may use EoMPLS to interconnect enterprise LANs,
regardless of their physical location, in such a way that the WAN services
supporting the network are not apparent to the customer.
742
Version 4.0.1

Module 7
EoMPLS
Subset of AToM
Connects two VLAN networks in different locations that
are geographically separated and have them appear as a

single entity
Connects two Ethernet networks that are geographically

separated and have the two networks appear as a single
logical Ethernet or VLAN domain
A service provider interconnects an enterprise LAN,
regardless of its physical location, in such a way that the

WAN services supporting the network are not apparent to
the customer
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/31
743
Layer 2 VPNs
Module 7
Types of EoMPLS
Methods for configuring EoMPLS include:
744
Port modeBoth ends of a PW are connected to Ethernet ports. Allows

all traffic on a port to share a single VC across an MPLS network. The
entire Ethernet frame without the preamble or FCS is transported as a
single packet. Port mode uses VC type 5
VLAN modeTransports Ethernet traffic from a source 802.1Q VLAN

to a destination 802.1Q VLAN through a single VC over an MPLS
network. The VLAN ID should be the same on both ends of the tunnel.
VLAN mode uses VC type 4
Inter-AS ModeInter-AS is a peer-to-peer type model that allows

extension of VPNs through multiple provider or multi-domain
networks. This lets service providers peer up with one another to offer
end-to-end VPN connectivity over extended geographical locations.
Ethernet Remote Port ShutdownMechanism for the detection and

propagation of remote link failure for port mode EoMPLS on Cisco
CRS-1 systems line cards. A service provider edge router on the local
end of an Ethernet-over-MPLS (EoMPLS) pseudowire may detect a
cross-connect or remote link failure, and cause the shutdown of the
Ethernet port on the local customer edge router. Shutting down the
Ethernet port on the local customer edge router prevents, or mitigates,
a condition where that router might otherwise lose data by forwarding
traffic continuously to the remote failed link, particularly if the link is
configured as a static IP route. This functionality is configured with the
l2transport propagate command
Version 4.0.1

Module 7
Types of EoMPLS
EoMPLS encapsulates Ethernet PDUs in MPLS packets and

forwards them across the MPLS network
There are multiple ways to configure EoMPLS:
Port modeBoth ends of PW connected to Ethernet ports. Allows all
traffic on a port to share a single VC across an MPLS network. VC type 5

VLAN modeTransports Ethernet traffic from a source 802.1Q VLAN to
a destination 802.1Q VLAN through a single VC over an MPLS network.
The VLAN ID should be the same on both ends of the tunnel. VC type 4
Inter-AS modeInter-AS is a peer-to-peer type model that allows the
extension of VPNs through multiple provider networks. Service
providers can peer up to offer end-to-end VPN connectivity over
extended geographical locations
Ethernet Remote Port ShutdownMechanism for the detection, and
propagation, of remote link failures for port mode EoMPLS on Cisco
CRS-1 system line cards
Version 3.9.0a
XMPLST4Module #/32
Instructors Note
Default mode of operation is port mode VC type 5. This mode may be configured using the
L2VPN PW-class using the transport-mode <ethernet | vlan> command
Version 4.0.1
745
Layer 2 VPNs
Module 7
EoMPLS Configuration Example

This example uses EoMPLS in a point-to-point connection between PE1
and PE2.
Implementing EoMPLS
The PE router configuration includes:
746
Setting up the sub-interface as a Layer 2 transport (this means any IP

address that had been configured needs to be removed) and define the
dot1q encapsulation
Creating a PW class and defining the MPLS method of encapsulation in

L2VPN configuration mode. The encapsulation method is applied to
defined cross-connected PE routers
Defining a cross connect group and connection type (point-to-point)
Defining the attachment circuit, which is a sub-interface in this case, to

be linked to the PW
Defining the PE neighbors loopback address with PW ID and using the

PW class to determine the encapsulation. The PW ID must match on
both ends of the PW link
Version 4.0.1

Module 7
EoMPLS Configuration Example
PE1
PE2
CE1
PE1
PE2
:(config)# int gig0/2/0/38.30 l2transport

:(config-if)# encapsulation dot1q 30
:(config)# int gig0/2/0/38.30 L2transport

:(config-if)# encapsulation dot1q 30
:(config)# l2vpn
:(config)# l2vpn
:(config-l2vpn)# xconnect group AC-PW

:(config-l2vpn-xc)# p2p PE1_PE2
:(config-l2vpn-xc-p2p)# int gig0/2/0/38.30
pw-id 1
CE2
:(config-l2vpn)# xconnect group AC-PW

:(config-l2vpn-xc)# p2p PE2_PE1
:(config-l2vpn-xc-p2p)# int gig0/2/0/38.30
pw-id 1
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/33
747
Layer 2 VPNs
Module 7
AToM MTU Requirements

The MTU requirements of the MPLS network must accommodate the
largest expected frame size in the LSP plus the Ethernet frame header,
control word, and 8 additional label stack bytes. This requirement includes
the configuration of the PE and CE links.
EoMPLS MTU Requirements

The maximum frame size equals the CE MTU, plus the Layer 2 header,
plus an AToM control word, plus two (2) MPLS labels. The variables in the
calculation are:
Layer 2 Ethernet header

!
Preamble, Start Frame Delimiter (SFD), frame check sequence

(FCS) are not carried
Ethernet II encapsulation is 18 Bytes; the18-bytes include a 4-byte

customer 802.1q header. If the customer VLAN ID is not
transported, then only 14 bytes are needed
EoMPLS port mode with a 1500-byte data CE packet (Ethernet II):

!
Max Frame Size = 1500 + 14 + 8 = 1522 bytes
EoMPLS VLAN mode with a 1500-byte data CE packet (Ethernet II):

!
Max Frame Size = 1500 + 18 + 8 = 1526 bytes
Based on these calculations, the CE-side MTU or service provider core

links must be changed to accommodate the encapsulation overhead.
The AToM control word (CW) is optional. If it is not used, deduct 4 bytes
from the frame size. Ethernet frames do not use a control word.
748
Version 4.0.1

Module 7
EoMPLS MTU Requirements
MTU calculations for EoMPLS
-Maximum Frame Size = CE MTU + Layer 2 header + 2 MPLS labels
Transported L2 Ethernet header
- Preamble, SFD, FCS

- Ethernet II encapsulation - 18 Bytes
EoMPLS port mode with 1500-byte data CE packet (Ethernet II)
- Maximum Frame Size = 1500 + 14 + 8 = 1522 bytes
EoMPLS VLAN mode with a 1500-byte data CE packet (Ethernet II)
- Maximum Frame Size = 1500 + 18 + 8 = 1526 bytes
Based on these calculations, CE-side MTU, or service provider
core links must be changed to accommodate the encapsulation

overhead
Version 3.9.0a
XMPLST4Module #/34
Instructor's Note
Lab exercise break here to create AToM and EoMPLS L2VPNs
Version 4.0.1
749
Layer 2 VPNs
Module 7
AToM Redundancy Features

In this section, the redundancy features of the Atom implementation are
discussed.
Pseudowire Redundancy
Pseudowire redundancy is the ability to detect a failure in the end-to-end
network and to be able to re-route the Layer 2 service to another endpoint
in the provider network that can continue to provide that service. It
provides protection in these areas:
750
End-to-end routing failures within the packet-switched network (PSN)
PE failure resulting from a hardware or software fault
Attachment circuit failures due to link failure
CE failure resulting from hardware or software fault
Version 4.0.1

Module 7
Pseudowire Redundancy
Packet switched
network
CE1
PE2a
CE2a
PE1
Primary
pseudowire
Attachment
circuit
PE2b
Attachment
circuits
CE2b
Redundant
pseudowire
Protects from fault in four key areas:

PSN failure due to end-to-end routing failure 1
PE failure due to hardware or software fault 2
Attachment circuit failure due to link failure 3
CE failure due to hardware or software fault 4
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/37
751
Layer 2 VPNs
Module 7
Pseudowire Redundancy Configuration

To configure pseudowire redundancy for a circuit, create both a primary
and backup neighbor on the PE.
Configuring a Redundant L2VPN

Using the illustration, on PE1 configure:
The interface to act as a Layer 2 transport removing any configured IP

address first
A PW class and the supported MPLS method of encapsulation in

L2VPN configuration mode. The encapsulation method is applied to
defined cross connects
A cross connect group and connection type (point-to-point)
The attachment circuit to be linked to the PW
The primary PW PE neighbors loopback address with PW ID. Attach

the defined PW class and MPLS encapsulation required. The PW ID
must match on both ends of the PW link
The backup PW PE neighbors loopback address with PW ID and attach

the earlier defined PW class. The PW ID must match on both ends of
the PW link
On PE2, configure the primary link for PE1 using all the preceding
parameters, except the backup link.
On PE3, configure the backup link from PE1 using all the preceding
parameters, except the active link.
The primary PW remains up and the backup becomes active only in the
event of a primary failure.
752
Version 4.0.1

Module 7
Pseudo Wire Redundancy Configuration
PE1: 10.1.1.1
CE1
p 0/3/0/0
AC
PE1
Primary PW
Backup PW
PE1

:(config)# l2vpn
:(config-l2vpn)# xconnect group TEST-GROUP
:(config-l2vpn-xc)# p2p CE1-CE4
:(config-l2vpn-xc-p2p)# int pos0/3/0/0
pw-id 3001
:(config-l2vpn-xc-p2p-pw)# backup neighbor
13.1.1.1 pw-id 3002
PE2: 12.1.1.1
CE4
PE3: 13.1.1.1
PE2
:(config)# l2vpn
:(config-l2vpn-xc-p2p)# int pos0/3/0/2
pw-id 3001
PE3
:(config)# l2vpn
:(config-l2vpn-xc-p2p)# int pps0/3/1/2
pw-id 3002
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/38
753
Layer 2 VPNs
Module 7

This section describes the virtual private LAN service (VPLS).
Introduction to VPLS
Virtual private LAN service (VPLS) is a Layer 2 service that emulates a
LAN across an IP or MPLS-enabled IP network. It lets standard Ethernet
devices communicate with each other, as if they were connected to a
common LAN segment.
In a VPLS topology, the MPLS WAN acts like a virtual switch that
emulates a conventional Layer 2 bridge. The WAN supports
communication between fully meshed Layer 2 sites, without the challenges
of the spanning tree protocol.
A common VC ID is used between PEs to create part of a virtual switching
instance (VSI). PEs learn and store VPN site MAC addresses, as well as
allocate and exchange labels for them. The full mesh of targeted LDP
sessions exchange VC labels.
Both VPLS and EoMPLS have the same data plane and Layer 2 PDU
handling. However, EoMPLS is for point-to-point connectivity and VPLS
supports multipoint connectivity.
754
Version 4.0.1

Module 7
Introduction to VPLS
VPLS is a Layer 2 service emulating a LAN over an MPLS

network
PE
CE
VPLS network
PE
CE
MPLS core
Full mesh of
pseudowires
CE
VPLS technology enables geographically separate LAN segments to be

interconnected as a single bridged domain over a PSN network
VPLS lets service providers offer multipoint Layer 2 connectivity among

customer LAN islands without customer network routing
VPLS operation emulates an IEEE Ethernet bridge and extends

customers LANs over MPLS network
Version 3.9.0a
XMPLST4Module #/40
Instructors Note
RFC 4762 Virtual Private LAN Service over LDP
Version 4.0.1
755
Layer 2 VPNs
Module 7
The PE router is configured to support multiple VPLS customers. Customers

are assigned their own VPLS domain containing a virtual switch instance. The
VSI and its components are:
Virtual switch instance (VSI)Contains a functional bridge module

that acts like an Ethernet switch. The functional bridge module does
not distinguish between physical and logical ports that connect to the
VFI. These ports are treated the same for functions, such as MAC
address learning, aging, and packet flooding. In addition, the bridge
module maintains a forwarding table that maps MAC addresses to
attachment circuits, and has the ability to run the spanning-tree
protocol on the ACs. The VSI has these components:
Virtual forwarding instance (VFI)Performs bridging operations on

PWs. A VFI maintains a forwarding table that maps MAC addresses to
PWs. The forwarding table learns MAC addresses from packets
received on PWs
Bridge moduleFunctions as an Ethernet switch and does not

distinguish between physical ACs and the logical port. Its forwarding
function maps MAC addresses to physical ports
Logical portConnects a VFI to the bridges single logical port

interface
Attachment Circuit (AC)Connects to the CE device; may be either a

physical or logical port
Virtual Circuit (VC) labelIdentifies the VFI; one or more VCs can
belong to same VFI. Multiple VFIs can exist on the same PE to
separate user traffic like VLANs
Multipoint-to-multipoint configurationForwards frames based on

learned MAC addresses. Uses a virtual forwarding instance for
customer separation
The other illustration is a sample of the configuration statements and a

view of the forwarding table of the bridge domain.
Instructors Note
Review the definitions above. The configuration sample is intended to provide a link between the
definitions and the configuration to help students obtain understanding of what they are going to
do in the lab exercise.
The forwarding table capture shows how the bridge domain integrates both the ACs and PWs.
The configuration and show command captures are reviewed in more detail later in this section.
756
Version 4.0.1

Module 7
Introduction to VPLS (Cont.)
Virtual switch instance

Logical port
Bridge module
VFI
Pseudowires
Attachment circuits
Provider core
Customer network
Virtual switch instance:
Virtual forwarding instance (VFI)

Bridge module
Logical port
VFI functions as a bridge for PWs

Forwarding function maps MAC addresses to PWs
Bridge module functions as Ethernet switch
Does not distinguish between physical ACs and the logical port
Forwarding function maps MAC addresses to physical interfaces
Logical port bridge has one logical port interface that connects to a VFI
Version 3.9.0a
XMPLST4Module #/42
Sample VSI configuration

Enable bridging:(config-l2vpn)# bridge group CLASS
Define the bridge module:(config-l2vpn-bg)# bridge-domain CLASS-DOMAIN
Define the AC:(config-l2vpn-bg-bd)# interface gig0/5/1/0
Define the VFI:(config-l2vpn-bg-bd)# vfi CLASS-VFI
Define the pseudowires
:(config-l2vpn-bg-bd-vfi)# neighbor 10.6.6.6 pw-id 3001 pw-class CLASS1
:PE4# show l2vpn forwarding bridge-domain mac-address location 0/5/cpu0

Tue Mar 16 01:24:51.737 UTC
Mac Address
Type
Learned from/Filtered on
LC learned Age
-------------------------------------------------------------------------0003.323c.488c dynamic Gig0/5/1/0
0/5/CPU0
0d 0h 1m 59s
0003.e412.f48c dynamic 10.5.5.5, 3001
0/5/CPU0
0d 0h 2m 18s
0009.12fe.ec8c dynamic 10.6.6.6, 3001
0/5/CPU0
0d 0h 0m 32s
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/43
757
Layer 2 VPNs
Module 7
Expanding Use of Ethernet

In the Ethernet environment, customers have full operational control over
their routing neighbors. Additionally, there is address space privacy; they
do not have to share their address space with the carrier network. The
customer may choose any routing protocol, including non-IP based (IPX or
AppleTalk).
This method lets the customers use an Ethernet switch, instead of a router,
as the CPE, thus reducing costs. A single connection reaches all other edge
points emulating an Ethernet LAN (VPLS).
Customers using a switch as a CPE have the ability to obtain Layer 2,
Layer 3, and Internet services on a common port.
758
Version 4.0.1

Module 7
Expanding Use of Ethernet
Aggregation
Access
PSN
Aggregation
Access
Internet
VLAN 100
termination
MPLS
VLAN
200
VLAN 200
transport
VPWS
IP
Ethernet
! Layer 2, Layer 3, and Internet services on a common port
VPLS
!Extends the reach of metro-area Ethernet networks (MAN)
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/44
759
Layer 2 VPNs
Module 7
VPLS Features and Benefits

Here are some of the features offered by VPLS, and the possible benefits to
customers and providers:
MPLS core network emulates a flat LAN segment

!
Providers and customers are no longer constrained by Ethernet

distance limitations and are able to use VPLS
Customers are able to maintain routing and administrative

authority of their networks
Ethernet broadcast capability is extended across a WAN providing

point-to-multipoint connectivity
!
A customer with a single CE-PE connection has the ability to

transmit Ethernet packets to multiple CE routers
A customer requires fewer connections to get full connectivity

among multiple sites
Multipoint plug-and-play provisioning

!
760
Adding, removing, or relocating a CE router requires configuring

only the directly attached PE router
Version 4.0.1

Module 7
VPLS Features and Benefits
Feature
MPLS core network emulates a
flat LAN segment
Benefits
Overcomes distance limitations of
Extends Ethernet broadcast

capability across WAN
Point to multipoint
connectivity
Ethernet-switched networks
Enables virtual private LAN services
Customers maintain routing and
administrative autonomy
Connects each customer site to many sites

A single CE-PE link transmits Ethernet
packets to multiple remote CE routers
Fewer connections required to get full

connectivity among customer sites
Multipoint plug-and-play
provisioning
Adding, removing, or relocating a CE router

requires configuring only the directly
attached PE router
Version 3.9.0a
XMPLST4Module #/45
Instructors Note
VPLS is an IETF superset framework for two services defined by the Metro Ethernet Forum.
The services are Transparent LAN Service (TLS), called Ethernet multipoint service (Cisco
Systems, Inc.); and Ethernet Virtual Connection Service, called Ethernet relay multipoint service
(Cisco Systems, Inc.)(IETF).
Version 4.0.1
761
Layer 2 VPNs
Module 7
VPLS Functional Component Overview

Here are some component definitions and functions that are critical to
understanding the VPLS environment:
762
CECustomer edge device that is a router or switch that attaches to

an aggregation network provider edge router (N-PE), or access network
user provider edge router (U-PE), using an attachment circuit (AC).
The type of device to which the CE attaches is a function of the access
network architecture
Access network (U-PE)User-facing provider edge router is a customer

access point. Depending on the access network it may attach to, the
aggregation network (N-PE) using Q-in-Q tunneling, or an MPLS
access network
Aggregation and distribution (N-PE)Network-facing provider edge

router. Connects to the MPLS core and uses PWs to forward Layer 2
network traffic to the destination aggregation and distribution (N-PE)
routers
Version 4.0.1

Module 7
VPLS Functional Component Overview
CE
AccessPE
Aggregation and
distribution
N-PE
Aggregation and
distribution
MPLS core
N-PE
AccessPE
CE
Aggregation and distribution network (N-PE) provides VPLS

termination and Layer 3 services
Access network (U-PE) provides customer user network

interface (UNI)
CE is the customer edge device

Version 3.9.0a
Version 4.0.1
XMPLST4Module #/46
763
Layer 2 VPNs
Module 7
VPLS Architectures
The VPLS network uses two basic architectures, known as direct
attachment (flat VPLS) and hierarchical VPLS (H-VPLS).
Direct Attachment or Flat VPLS Architecture

In a VPLS domain virtual switches are interconnected by PWs. The
topology used by the PWs is an important part of insuring a loop-free
network for optimal scalability and performance.
A VPLS domain may have one of the following forms:
Full meshMost common topology deployed today. In this topology every
virtual switch has exactly one PW to every other virtual switch in the same
VPLS domain. Split horizon is used to guarantee loop-free PWs in this
topology. Split horizon eliminates the need for spanning-tree protocols run
over the backbone. One drawback to full mesh is the need for N*(N-1)/2
PWs in the core, where N is the number of virtual switches
Hub and spokePE router acts as a hub that connects other PE routers
acting as spokes. Each spoke has one PW that connects to the hub router.
Spokes are not interconnected by PWs. This topology is loop-free, so
neither the spanning tree protocol nor split horizon is needed. To maintain
Layer 2 connectivity between sites, disable split horizon on the hub PE.
The hub and spoke topology is a good choice for small VPLS deployments
Partial meshMost flexible model is partial mesh. The major concern is
to maintain loop-free forwarding in a partial mesh topology, spanning tree
protocol is needed on PWs in the core. This is typically not a good idea for
service providers
764
Version 4.0.1

Module 7
VPLS Architectures Direct Attachment
VPLS defines two architectures
!Direct
!Hierarchical
Each of these architectures has different scaling

characteristics
Direct attachment (flat)
!Full mesh - (N*N-1)/2 PWs

!Hub and spoke (loop free good for small deployments)
!Partial mesh (spanning tree needed on PWs in core)
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/47
765
Layer 2 VPNs
Module 7
VPLS Architectures - Hierarchical

H-VPLS is a hybrid model that takes advantage of the benefits of the full
mesh, and hub and spoke topologies. H-VPLS is a two-tiered network
where top tier core network facing routers are known as network provider
edge (N-PE), and provide the aggregation and distribution function. The
bottom tier customer facing routers are known as user provider edge
(U-PE), and provide the access function. H-VPLS is deployed using one of
two access models:
MPLS Edge (ME-H-VPLS, EoMPLS)Each U-PE in the bottom tier has
one PW that connects to an N-PE. This is effectively a hub and spoke
model. To assure a loop-free core network N-PE routers use Layer 2 split
horizon on all PWs connecting to other N-PE routers. Split horizon is
disabled on PWs that connect U-PE to N-PE routers. Packets originating
on a U-PE are forwarded to a N-PE and then forwarded to core PWs.
Packets from a PW that arrive at a N-PE from another N-PE can only be
forwarded to a U-PE over an access PW
Ethernet Edge (EE-H-VPLS, Q-in-Q tunnels)uses Ethernet Q-in-Q
tunnels between U-PE and N-PE routers. The N-PE forwards packets (that
arrive from the U-PE in Q-in-Q tunnels) across PWs to other N-PEs, only.
The hierarchical VPLS model reduces the number of signaling sessions and
PWs, improving network scalability and performance
766
Version 4.0.1

Module 7
VPLS Architectures - Hierarchical
Hierarchical or H-VPLS has two access methods
!MPLS edge (ME-H-VPLS) PWE3 (EoMPLS)

!Ethernet edge (EE-H-VPLS) Q-in-Q tunnels
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/48
767
Layer 2 VPNs
Module 7
Flat VPLS Architecture

In a flat architecture, customers are directly attached to a VPLS service at
the provider edge. This architecture is suitable for small customer or
service provider implementations, since provisioning is simple. However,
as the size of the VPLS network grows, the following issues need to be
considered:
Full mesh of directed LDP sessions required between participating PEs

!
Limited scalability as the number of PEs and MAC addresses increases

!
Number of connections = N*(N-1)/2; N = number of PE nodes
In VPLS, MAC addresses are used to forward Layer 2 traffic across

PWs. As the number of CE devices connected to a PE router
increases, so does the size of the MAC table
Potential signaling and packet replication overhead increases greatly

with additional PE devices
Considering end-to-end packet flow through the network:
768
The attachment circuit is either VLAN or port based. The packet

arrives at the N-PE with a source and destination MAC address (CE2).
The source MAC address is stored in the table for the virtual bridge
instance for this port
If the destination MAC address is already stored in the virtual switch,

the Layer 2 packet is sent out on the appropriate PW. Otherwise, it is
flooded out on all PWs
The packet is sent into the core with the addition of a PW label and
LSP (IGP) label
At the penultimate hop router, the LSP label is popped and the Layer 2
packet, with the PW label, is sent on to the appropriate N-PE
The PW label directs the Layer 2 packet to the appropriate AC and is

removed by the PE router
The original Layer 2 packet is forwarded to the corresponding CE

device
When the CE responds to the Layer 2 packet, the originating N-PE

stores and links the MAC address of the CE to the appropriate PW
Version 4.0.1

Module 7
Flat VPLS Architecture
CE1
Aggregation and
distribution
N-PE
Ethernet
(VLAN or port)
Data
SMAC1 DMAC2
802.1q
Customer
Data
SMAC1 DMAC2
Version 3.9.0a
Version 4.0.1
PW
CE2
Ethernet
(VLAN or port)
Full mesh PWs + LDP
Data
Aggregation and
distribution
MPLS core
N-PE
LSP
SMAC1 DMAC2
Pseudowire
service provider
core
XMPLST4Module #/49
769
Layer 2 VPNs
Module 7
Virtual Forwarding Instance

Previously we discussed the VSI as the combined functionality of the VFI
and bridge module. The VSI performs bridging operations on PWs and
attachment circuits.
The VFI maintains a forwarding table that maps MAC addresses to PWs.
The bridge module learns the MAC addresses from the ACs. The bridge
domain provides Layer 2 forwarding based on the MAC address.
The VFI provides these operations:
770
Flooding and forwarding

!
The PE routers maintain MAC table instances for each customer.

The MAC table instances may be port or VLAN-based
Each VFI on the PE actively participates in the learning and

forwarding process
Each VFI on the PE associates ports or VLANs to MAC addresses,

and floods all unknown destinations to all other ports
Address learning and aging

!
The LDP protocol has been enhanced to work more effectively with
VPLS. A MAC list TLV label withdrawal message has been added to
LDP
MAC timers are refreshed with incoming frames, address learning,

aging, NS limiting. MAC address flushing and withdrawal occur
with a topology change
Version 4.0.1

Module 7
Virtual Forwarding Interface
Flooding and forwarding
MAC table instances per customer (port or VLAN) for

each PE
VFI and bridge module participate in learning and

forwarding process
Associates ports to MAC addresses
!Flood unknown destinations to all other ports
Address learning and aging
LDP enhanced with additional MAC list TLV (label

withdrawal)
MAC timers refreshed with incoming frames

Version 3.9.0a
XMPLST4Module #/50
Instructors Note
All VLANs on a port use the same MAC address if they are on the same bridge.
Version 4.0.1
771
Layer 2 VPNs
Module 7
VPLS Flooding and Forwarding

Frame forwarding requirements:
772
MAC address to AC to PW association is needed

!
When destination MAC of unicast packet is unknown, the PE router

floods the Layer 2 frame out all PWs in the VFI
Layer 2 frame flooding takes place for broadcast and multicast

traffic
The PE dynamically learns MAC addresses on ports and PWs
Forwarding on a PW or port is based on the MAC addresses learned by

the VFI
Version 4.0.1

Module 7
VPLS Flooding and Forwarding
Pseudowire in LSP
Unknown DMAC?
Data
SMAC DMAC?
Flooding (broadcast, Multicast, unknown unicast)

Dynamic learning of MAC addresses on physical ports and PWs
Forwarding
!Physical port
!Pseudowire
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/51
773
Layer 2 VPNs
Module 7
MAC Address Learning and Forwarding

How are MAC addresses learned and used to forward traffic between VPLS
CE routers?
In the illustration, PE1 and PE2 learn the MAC address of their
corresponding CE router interface when the CEs send traffic on the PE-CE
interface. The directed LDP sessions on the PE routers use the VC label to
represent the far end MAC address. For example, PE2 advertises VC label
170 to represent MAC2 to PE1; PE1 advertises VC label 102 to represent
MAC1 to PE2.
To illustrate, a packet is sent from CE1 to CE2. The packet is sent from
CE1 with a source MAC address, MAC1, and a destination MAC address,
MAC2. The packet arrives at PE1 on interface E0/0. A MAC table lookup
assigns a VC of 170 to the destination address for MAC2. LDP assigns a
LSP label toward the destination router, PE2. The penultimate hop router
removes the PE2 LSP label, and the VC label directs the packet to the PE2
interface, E0/1. Traffic sent from CE2 to CE1 uses VC 102 and a LSP label
representing PE1.
Broadcast, Multicast, and unicast packets with unknown destination
addresses are learned from label associations. Each LSP is associated with
two PWs, receive and transmit. If either PW is down, the entire PW is
considered down.
774
Version 4.0.1

Module 7
MAC Address Learning and Forwarding
Send me frames
using label 102
MAC1
PE1
CE1
Adj
MAC 2
170
MAC 1
E0/0
Use VC
label 170
PE1
Data
102
DMAC1 SMAC2
SMAC1 DMAC2
MAC2
PE2
Use VC
label 102
E0/0
MAC address
Send me frames
using label 170
Directed LDP
170
Data
CE2
E0/1
MAC address
Adj
MAC 2
E0/1
MAC 1
102
PE2
Broadcast, Multicast, and unicast with unknown destination

are learned from received label associations
Two LSPs associated with a PW (transmit and receive)

If inbound or outbound LSP is down
! The entire pseudowire is considered down
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/52
775
Layer 2 VPNs
Module 7
Loop Prevention
VPLS uses split horizon to prevent routing loops in the core. This
functionality is automatically implemented between VPLS VCs when they
are created. Therefore neighbors do not advertise any information out a VC
that they learned on that VC.
776
Version 4.0.1

Module 7
Loop Prevention
MPLS
VFI
VFI
VFI
N-PE4
N-PE6
N-PE5
Loop Prevention
!VPLS uses split horizon to prevent loops
Split-Horizon
! Split-horizon is automatically implemented between VPLS VCs
" Result is a blocking action
! What is learned over a VC is not advertised back out that VC
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/53
777
Layer 2 VPNs
Module 7
VPLS Configuration Example

This configuration example focuses on N-PE4. N-PE5 and N-PE6 use the
same configuration steps, however with different addresses:
1. Attachment circuit
!
Configure the attachment circuit GigE 0/5/1/0 for l2transport
2. Define PW class (optional, the default is MPLS encapsulation)

!
Enter the L2VPN configuration mode
Create a PW class that defines the MPLS encapsulation
3. Define a bridge group, then a bridge domain

!
Define a bridge group in the L2VPN submode (enables bridging

functionality)
The bridge domain is defined as part of the bridge group creating a

bridging module
Assign bridge ports to the bridge domain (ACs)
4. Define the VPLS VFI linked to the bridge domain (This action
associates PWs with the VFI)
778
Define the VFI name
Associate neighbors, corresponding PW-IDs, and PW class with the

VFI
Version 4.0.1

Module 7
VPLS Configuration Example
MPLS
VFI
VFI
N-PE4
VFI
N-PE5
N-PE6
! Attachment circuit config

:(config)# interface Gig 0/5/1/0
:(config-if)# l2transport
! Define PW class
:(config)# l2vpn
:(config-l2vpn)# pw-class CLASS1
:(config-l2vpn-pw)# encapsulation mpls
! Define bridge group then bridge domain
:(config-l2vpn)# bridge group CLASS
:(config-l2vpn-bg)# bridge-domain CLASS-DOMAIN
:(config-l2vpn-bg-bd)# int gig 0/5/1/0
! Define VPLS VFI
:(config-l2vpn-bg-bd)# vfi class-vfi
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/54
779
Layer 2 VPNs
Module 7
Display the VPLS Bridge Domain

The show l2vpn bridge-domain command displays:
780
Bridge groupThe bridge group that contains bridge domains
Bridge-domainThe information on bridge ports, such as attachment

circuits and pseudowires for the specific bridge domain
MAC address parametersThe limiting, aging, action, notification, and

defined filters
Number of ACs, VFIs, and PWs, and their status
List of ACs by physical port description, state, and the static MAC
addresses defined for the port
Access PWs, if any are defined
List of VFIs by name, with neighbors, PW-IDs, state, and static MAC
address information
Version 4.0.1

Module 7
Display the VPLS Bridge Domain
MPLS
VFI
VFI
N-PE4
VFI
N-PE5
N-PE6
:N-PE4# show l2vpn bridge-domain

Bridge group: CLASS, bridge-domain: CLASS-DOMAIN,id: 0,state:up,ShgId: 0,MSTi: 0
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
Filter MAC addresses: 0
ACs: 1 (1 up), VFIs: 1, PWs: 2 (2 up)
List of ACs:
Gi0/5/1/0, state: up, Static MAC addresses: 0
List of Access PWs:
List of VFIs:
VFI test-vfi
Neighbor 10.5.5.5 pw-id 3001, state: up, Static MAC addresses: 0
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/55
781
Layer 2 VPNs
Module 7
Display the Bridge-Domain Forwarding Data

The show l2vpn forwarding bridge-domain command provides bridge
domain summary information for a line card:
782
MAC addressFirst listed is the AC Gi0/5/1/0 with the CEs MAC

address. This is followed by the MAC addresses of the CEs at the far
end of the PWs to PE5 and PE6, with their PW-ID
TypeIndicates the MAC addresses are learned dynamically rather

than statically defined
Learned from/Filtered onThe interface or address of the source of the

MAC addresses, and the PW ID, if remote
LC learnedThe line card location of the ports making the connections

in the display
AgeLength of time the connections have existed
Version 4.0.1

Module 7
View Bridge-domain Forwarding Data
MPLS
VFI
VFI
N-PE4
VFI
N-PE5
N-PE6
:N-PE4# show l2vpn forwarding bridge-domain mac-address location 0/5/cpu0

Mac Address
Type
LC learned Age
-------------------------------------------------------------------------------0003.323c.488c dynamic Gi0/5/1/0
0/5/CPU0
0d 0h 1m 59s
0003.e412.f48c dynamic 10.5.5.5, 3001
0/5/CPU0
0d 0h 2m 18s
0009.12fe.ec8c dynamic 10.6.6.6, 3001
0/5/CPU0
0d 0h 0m 32s
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/56
783
Layer 2 VPNs
Module 7
Hierarchical Virtual Private LAN Service (H-VPLS)

VPLS creates scaling issues because it requires a full mesh of control and
data planes. H-VPLS is a method of subdividing a VPLS VPN into a tiered
hierarchical network to resolve the scaling issues. This hierarchical
network uses a user provider edge (U-PE) device that aggregates multiple
customers into a single network provider edge (N-PE). Each U-PE has one
control and data plane connection into the network provide edge (N-PE).
This significantly reduces the number of MAC addresses, LDP sessions,
and LSPs required by the N-PEs, and reduces the burden on the core
network.
H-VPLS and Flat VPLS Comparison

Here is a comparison of Flat VPLS and H-VPLS.
Flat VPLS
Full PW mesh from edge-to-edge
Higher signaling overhead; each PE has one control and data

connection to every other PE
Packet replication is done at the edge
Node discovery and provisioning extend end-to-end
H-VPLS
784
Full PW mesh exists in the PE routers only, customer connections are

offloaded from the core routers and to the edge PE devices
Signaling overhead is minimized
Packet replication is done in the core not at the edge
Node discovery is portioned into smaller domains
Version 4.0.1

Module 7
H-VPLS and Flat VPLS Comparison
Flat VPLS
H-VPLS
Full PW mesh from the edge

Higher signaling overhead
Packet replication done at the edge
Node discovery and provisioning
extend end-to-end
Version 3.9.0a
Version 4.0.1
Full PW mesh only within core

Minimizes signaling overhead
Packet replication done in the core
Partitions node discovery into
smaller domains
XMPLST4Module #/58
785
Layer 2 VPNs
Module 7
Hierarchical VPLS
H-VPLS consists of two distinct levels, hub and spoke:
786
Spoke
!
Customers attach to regional Metro Ethernet networks
Layer 2 and Layer 3 tunnels connect to VPLS N-PEs

!
Q-in-Q (Layer 2)
EoMPLS (Layer 2)
MPLS (Layer 3)
L2TPv3 (Layer 3)
Hub
!
VPLS links the Metro Ethernet regions
Full mesh VPLS PWs in the MPLS core
Version 4.0.1

Module 7
Hierarchical VPLS
Two distinct levels:
Hub and Spoke
! Customers attach to regional Metro Ethernet networks

! VPLS links the Metro Ethernet regions
Hub
! Full mesh VPLS PWs in the MPLS core
Spokes Layer 2 and Layer 3 tunnels connecting to VPLS PEs
! Q-in-Q (L2)
! EoMPLS (L2)
! MPLS (L3)
! L2TPv3 (L3)
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/59
787
Layer 2 VPNs
Module 7
Q-in-Q and 802.1ad Overview

A key reason for Q-in-Q is overlapping VLANs. The IEEE standards body
created the 802.1ad standard to define the handling of multiple VLAN
headers in and Ethernet frame. The standard is essential in the
implementation of Metro Ethernet networks.
In the illustration, company A and company B have overlapping VLANs
(numbers 20-30 overlap). This may lead to mixing the different customers
traffic on the network infrastructure. Assigning a unique range of VLANs
to each customer in the service provider network solves the problem, but is
not a very scalable solution, and requires strict management.
802.1q tunneling (Q-in-Q) is a technology that enables service providers to
provide Layer 2 VPN tunnels by applying multiple VLAN tags (i.e., dot1q
tag stacking) to Ethernet frames. Service providers encapsulate traffic
from multiple VLANs from one customer with a single service provider tag.
(S-tag)
Using Q-in-Q (sometimes called dot1q tag stacking, or dot1q tunneling) lets
the customers VLAN (CE-VLAN) be encapsulated inside an SP VLAN ID.
This means two things:
788
Customers keep their own VLANs; service providers do not assign them
Service provider may overcome any VLAN ID restrictions, since the

customer VLANs can be different from service providers
The Q-in-Q technique is implemented by configuring an asymmetrical

link between the CE, and the PE and the customer LAN equipment
(CLE). With this configuration, any traffic arriving at the PE-CLE gets
tagged with the native VLAN of the port on the PE-CLE
Version 4.0.1

Module 7
Q-in-Q and 802.1ad Overview
Overlapping VLAN IDs

Customers have own VLAN IDs
Service providers mix traffic from different customers in network
-Preserve customer VLAN ID

-VLAN tags must be unique
-Maintain security by assigning customer traffic different tunnel IDs
Company
B
Company
A
VLAN# 20 - 30 overlap
VLAN# 10 30
VLAN# 20 - 40
Service provider
network
Company
A
Company
B
VLAN# 10 - 30
VLAN# 20 - 40
Version 3.9.0a
XMPLST4Module #/61
IEEE 802.1Q Tunneling Tags

Standard 802.3 Ethernet frame
DA
SA
Ether Type
(6 Bytes) (6 Bytes) (2 Bytes)
Data
FCS
(0 - 1500 Bytes) (4 Bytes)
802.1q Tagged Ethernet frame

DA
SA
Ether Type
(6 Bytes) (6 Bytes) 8100
CE 802.1q Tag
(2 Bytes)
Length/Etype Data
FCS
(2 Bytes)
(0 - 1500 Bytes) (4 Bytes)
Q tag
802.1ad Double-Tagged Ethernet frame
DA
(6 Bytes)
SA
(6 Bytes)
Ether Type
8100
SP 802.1q
(2 Bytes)
S-tag
Ether Type
8100
CE 802.1q Tag
(2 Bytes)
Length/Etype
(2 Bytes)
Data
(0 - 1500 Bytes)
FCS
(4 Bytes)
Inner tag
Inner tag added by customer

S-tag added by service provider
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/62
789
Layer 2 VPNs
Module 7
Q-in-Q (Ethernet) or MPLS access

There are two U-PE-to-N-PE connection methods:
Q-in-Q AC mapped into a VPLS instance
MPLS PW mapped into a VPLS instance
Ethernet Access with Q-in-Q

The scaling limitations of a flat VPLS architecture are addressed by
H-VPLS. H-VPLS is comprised of distributed devices that consist of edge
domains interconnected using an MPLS core.
In the Q-in-Q architecture no PWs exist between the U-PE and N-PE. This
architecture is based on two logically separated layers. Packets arrive on
the Q-in-Q tunnels that connect from the U-PE to N-PE routers. The
ingress N-PE routers then forward packets across PWs that connect to
egress N-PE routers.
Advantages of H-VPLS with Ethernet Q-in-Q access include:
Good for large scale deployments, results in reduced packet replication

and signaling overhead
Relocating an N-PE router in the network only requires reconfiguration

of N-PE routers, while relocating a U-PE router in the network, only
requires reconfiguration of attached N-PE
Expansion affects new nodes only (no reconfiguring existing PEs)
Q-in-Q Ethernet access network (S-tag is used as VPLS VFI service

delimiter; customer tag is invisible in the core)
MPLS PW Access
The N-PEs in the core are fully meshed through PWs. U-PEs in the bottom
tier have one PW that connects to the N-PE, which becomes a hub and
spoke model.
Top tiernetwork-facing PE routers (N-PE), aggregation and

distribution routers
Bottom tieruser-facing PE routers (U-PE), access routers
For a loop-free forwarding environment, N-PE routers use Layer 2 split

horizon on all PWs that connect to other N-PE routers and disable split
horizon on all PWs that connect to U-PE routers. On an N-PE router,
packets are forwarded to other PWs only if they arrive on a PW from a UPE. Packets that arrive on a PW from an N-PE can only be forwarded on
PWs that connect to a U-PE.
790
Version 4.0.1

Module 7
Q-in-Q (Ethernet) or MPLS Access
H-VPLS with Q-in-Q access
Access defined by 802.1q tag

Additional service provider tag
defined by IEEE 802.1ad (Q-in-Q)
CE
CE
CE
(MPLS Core)
U-PE A
N-PE 1
PW
U-PE B
N-PE 2
VPLS
U-PE A
(MPLS Core)
N-PE 1
MPLS
CE
(Q-in-Q)
MPLS
to backhaul traffic from

U-PE to N-PE
VPLS
STP
(Q-in-Q)
H-VPLS with MPLS access
Uses PW EoMPLS circuit
Layer 2
Version 3.9.0a
Version 4.0.1
U-PE B
PW
N-PE 2
XMPLST4Module #/63
791
Layer 2 VPNs
Module 7
Ethernet Access (EE-H-VPLS, Q-in-Q Tunnels)

Ethernet L2VPNs may be either Ethernet edge H-VPLS or Q-in-Q tunnels.
In step 1 of the illustration, the Q-in-Q architecture customer packets are
802.1q encapsulated when they arrive at the U-PE (VLAN CE).
In step 2, the customer packets are encapsulated in a service provider
(VLAN SP) VLAN tag (Q-in-Q edge) for transport to the N-PE. The service
provider tag (known as the S-tag) is used as the VPLS VFI service
delimiter making the customer tag invisible in the core.
In step 3, the VPLS VFI service delimiter and DMAC2 address table
determine the PW label, which replaces the s-tag. LDP in the core
determines the LSP label.
When the packet arrives at the destination N-PE the PW label directs the
packet to the proper VPLS VFI service delimiter where the service
provider tag is added back for transport to the U-PE, where the customer
tag is used to carry traffic to its destination.
792
Version 4.0.1

Module 7
Ethernet Access (EE-H-VPLS, Q-in-Q Tunnels)
AccessPE
CE1
Aggregation and
distribution
N-PE
Aggregation and
distribution
MPLS core
N-PE
AccessPE
Service
provider
Ethernet
transport
Service
provider
Ethernet
transport
802.1q
access
Q-in-Q
tunnel
Data
VLAN
CE
CE2
SMAC1 DMAC2
Data
802.1q
access
802.1q
customer
VLAN VLAN
CE
SP
3
Q-in-Q
tunnel
Full mesh PWs + LDP
Data
SMAC1 DMAC2
VLAN
CE
Q-in-Q
service provider edge
SMAC1 DMAC2
Version 3.9.0a
Version 4.0.1
PW
LSP
Pseudowire
service provider core
XMPLST4Module #/64
793
Layer 2 VPNs
Module 7
MPLS Access
CE to U-PE connectivity may be 802.1q or port mode Ethernet. Packets
arriving at the U-PE are directed using EoMPLS to the N-PE router. The
U-PE attachment circuit is mapped to a PW and carried to the N-PE using
the LSP label obtained from LDP in the MPLS access network.
The MPLS core is a full mesh of VPLS PWs. The EoMPLS packet arriving
at the N-PE is mapped into the N-PE bridge domain using the same PW-ID
as the core PWs in the VPLS bridge domain.
On the adjacent page the PW-ID in the core matches the PW-ID used at
the edge, and the LSP label is derived in the core using LDP.
794
Version 4.0.1

Module 7
MPLS Access
AccessPE
CE1
Aggregation and
distribution
N-PE
MPLS core
Aggregation and
distribution
N-PE
MPLS
access
802.1q
access
MPLS
pseudowire
VLAN
CE
Data
VLAN
CE
3
Full mesh PWs + LDP
SMAC1 DMAC2
MPLS
pseudowire
802.1q
access
Same VCID used in

edge and core (Labels
may differ)
802.1q
customer
3
CE2
MPLS
access
SMAC1 DMAC2
Data
AccessPE
PW
Data
LSP
VLAN
CE
Version 3.9.0a
Version 4.0.1
MPLS PW
SP Edge
SMAC1 DMAC2
PW
Pseudowire
LSP service provider
core
XMPLST4Module #/65
795
Layer 2 VPNs
Module 7
Split-Horizon Rules
By default, split horizon is enabled in a bridge domain. Any packets
arriving on either the attachment circuits or pseudowires are not returned
on the same attachment circuits or pseudowires. In addition, the packets
received on one pseudowire are not replicated on other pseudowires in the
same VFI.
Split-horizon and non-split-horizon rules may be summed up as packets
traveling between:
796
U-PE and N-PE non-split-horizon VCs are forwarded
Non-split-horizon VCs and split-horizon VCs are forwarded
Split-horizon VCs are blocked
ACs and VCs are forwarded
ACs are forwarded
Version 4.0.1

Module 7
Split-Horizon Rules
MPLS
MPLS
AC
N-PE3
AC
VFI
VFI
AC
MPLS
VFI
N-PE4
U-PE4
U-PE3
N-PE1
Packets traveling between

U-PE and N-PE non-split-horizon VCs are forwarded
Non-split-horizon VCs and split-horizon VCs are forwarded
Split-horizon VCs are blocked
ACs and VCs are forwarded
ACs are forwarded
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/66
797
Layer 2 VPNs
Module 7
MPLS Access Example

Here is a configuration example using routers U-PE3, U-PE2, and N-PE3.
U-PE3
Configure the attachment circuit interface, G0/4/0/0, as L2transport
In L2VPN configuration mode, define a PW class and encapsulation

method
Configure an EoMPLS connection from U-PE3 to N-PE3, by defining

the xconnect group with point-to-point connectivity
Link the AC interface (G0/4/0/0) to the EoMPLS neighbor (10.3.3.3)

with a PW-ID (3001), and use the PW class to define the encapsulation
U-PE2
Configure the attachment circuit interface, G0/4/0/0, as L2transport

method
Configure an EoMPLS connection from U-PE2 to N-PE3, by defining

the xconnect group with point-to-point connectivity
Link the AC interface (G0/4/0/0) to the EoMPLS neighbor (10.3.3.3)

with a PW-ID (3001), and use the PW class to define the encapsulation
N-PE3
798
Define the EoMPLS inbound interface, G0/5/1/0, as L2transport

method
Define the bridge group to enable bridging. Create a bridge domain

(Layer 2 broadcast domain), include the U-PE facing interface
(G0/5/1/0), and the U-PE neighbor addresses, with matching PW-ID
(3001) and PW class
Create the VFI and add the neighbor statements for the N-PE1 and
N-PE4 routers, with the matching PW-ID (3001) and PW class
Version 4.0.1

Module 7
MPLS Access Example
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
VFI
VFI
N-PE3
10.3.3.3
MPLS
MPLS
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
U-PE3
:(config)# interface Gig0/4/0/0 l2transport

:(config)# l2vpn
:(config-l2vpn-pwc)# encap mpls
:(config-l2vpn-xc)# p2p UPE3-NPE3
:(config-l2vpn-xc-p2p)# interface Gig0/4/0/0
:(config-l2vpn-xc-p2p)# neighbor 10.3.3.3 pw-id 3001
U-PE2
:(config)# l2vpn
:(config-l2vpn-pwc)# encap mpls
:(config-l2vpn-xc)# p2p UPE2-NPE3
:(config-l2vpn-xc-p2p)# neighbor 10.3.3.3 pw-id 3001
Version 3.9.0a
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
MPLS
MPLS
VFI
VFI
N-PE3
10.3.3.3
XMPLST4Module #/68
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
N-PE3

:(config)# l2vpn
:(config-l2vpn)# pw-class CLASS1
:(config-l2vpn-pw)# encapsulation mpls
:(config-l2vpn)# bridge group CLASS
:(config-l2vpn-bg)# bridge-domain CLASS-DOMAIN
:(config-l2vpn-bg-bd)# interface Gig0/5/1/0
:(config-l2vpn-bg-bd)# neighbor 10.33.3.3 pw-id 3001 pw-class CLASS1
:(config-l2vpn-bg-bd)# neighbor 10.22.2.2 pw-id 3001 pw-class CLASS1
:(config-l2vpn-bg-bd)# vfi class-vfi
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/69
799
Layer 2 VPNs
Module 7
Displaying L2VPN Information

The following illustrations review various L2VPN show commands.
Display the L2VPN Bridge Domain

The show l2vpn bridge-domain command provides a brief summary of
bridge domains on the router and their status. In the example on the
adjacent page N-PE3 was configured for VPLS connectivity with N-PE1
and N-PE4. Additionally, it was configured for EoMPLS connectivity with
U-PE3 and U-PE2. The command output displays:
7100
Bridge groups, bridge domains defined, and their state
MAC parameters, including aging time, MAC address limit, any action
to be taken if the limit is exceeded, the notification process if the limit
is exceeded, and MAC filter information
ACs configured (G0/5/1/0), showing this AC with one VFI that has four
PWs, and that they are all up
List of ACs within the bridge domain, their status, and any static MAC
addresses defined
List of defined access PWs and their state for an H-VPLS configuration
List of VFIs with their PW-IDs, their state, and any defined static MAC
addresses
Version 4.0.1

Module 7
Display L2VPN Bridge Domain
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
VFI
VFI
N-PE3
10.3.3.3
MPLS
MPLS
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
:N-PE3# show l2vpn bridge-domain

Bridge group: CLASS, bridge-domain: CLASS-DOMAIN,id: 0,state:up,ShgId: 0,MSTi: 0
Aging: 300 s, MAC limit: 4000, Action: none, Notification: syslog
Filter MAC addresses: 0
ACs: 1 (1 up), VFIs: 1, PWs: 4 (4 up)
List of ACs:
Gi0/5/1/0, state: up, Static MAC addresses: 0
List of Access PWs:
List of VFIs:
VFI test-vfi
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/70
7101
Layer 2 VPNs
Module 7
Display L2VPN Bridge Domain Detail

The show l2vpn bridge-domain detail command provides an in depth
view of bridge domains on the router and their status. In this example
N-PE3 was configured for VPLS connectivity with N-PE1 and N- PE4, and
EoMPLS connectivity with U-PE2 and U-PE3. Following is some of the
detailed information obtained from the command:
Defined bridge groups, bridge domains and their state
A full range of MAC parameters
Flooding status for broadcast, multicast and unicast addresses
Split-horizon groups, DHCP, IGMP snooping status, bridge MTU
One AC, one VFI with four PWs that are all operational on N-PE3
AC interfaces, with state, type, and full Layer 2 details for the bridge
group
Defined access PWs with state information
Detailed VFI information:
7102
VFI name with neighbor ID, PW-ID, state, PW class, encapsulation,

and protocol used to exchange information
PW type, whether or not a control word is used, and interworking

status
Table that comparing the local and remote ends of the PW for the
neighbor relationship
Version 4.0.1

Module 7
Display L2VPN Bridge Domain Detail
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
VFI
VFI
N-PE3
10.3.3.3
MPLS
MPLS
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
:N-PE3# show l2vpn bridge-domain detail

Bridge group: CLASS, bridge-domain: CLASS-DOMAIN, id:0, state:up, ShgId: 0,
MSTi: 0
MAC learning: enabled
MAC withdraw: enabled
Flooding: Broadcast & Multicast: enabled
Unknown unicast: enabled
MAC aging time: 300 s, Type: inactivity MAC limit: 4000, Action: none,
Notification: syslog
MAC limit reached: no MAC port down flush: enabled
Security: disabled Split Horizon Group: none
DHCPv4 snooping: disabled
IGMP Snooping profile: none
Bridge MTU: 1500
MIB cvplsConfigIndex: 1
Filter MAC addresses:
ACs: 1 (1 up), VFIs: 1, PWs: 4 (4 up)
List of ACs:
AC: GigabitEthernet0/5/1/0, state is up
Type Ethernet
MTU 1500; XC ID 0x5000003; interworking none MAC learning: enabled
AC
MPLS
Flooding: MPLS
Broadcast
enabled
Unknown unicast:
enabled
G0/5/1/0& Multicast:MPLS
MAC
aging
time: 300 s, Type: inactivity MAC limit: 4000, Action: none,
U-PE3
10.33.3.3
VFI MAC limit reached: no VFI
Notification: syslog
MAC port down flush: enabled
--More-AC
N-PE4
U-PE4
N-PE3
VFI
G0/4/0/0 U-PE2 10.22.2.2
10.3.3.3
N-PE1 10.1.1.1
10.4.4.4
3.9.0a
XMPLST4Module #/72
Security:
disabled Split Horizon Group:Version
none
DHCPv4 snooping: disabled
IGMP Snooping profile: none Storm Control: disabled Static MAC addresses:
Statistics: packets: received 84700, sent 25934 bytes: received 7140788, sent 1652893
Storm control drop counters: packets: broadcast 0, multicast 0, unknown unicast 0
List of Access PWs:
List of VFIs:
VFI CLASS-VFI PW: neighbor 10.4.4.4, PW ID 3001, state is up ( established )
PW class TEST, XC ID 0xff000007 Encapsulation MPLS, protocol LDP
PW type Ethernet, control word disabled, interworking none
PW backup disable delay 0 sec Sequencing not set
MPLS
Local
Remote
------------ ------------------------------ ------------------------Label
16005
16012
Group ID
0x0
0x0
Interface
CLASS-VFI
CLASS-VFI
MTU
1500
1500
disabled
PW type
Ethernet
Ethernet
VCCV CV type 0x2 (LSP ping verification)
0x2 (LSP ping verification)
VCCV CC type 0x6 (router alert label)
0x6 (router alert label)
(TTL expiry)
(TTL expiry)
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/73
7103
Layer 2 VPNs
Module 7
Display L2VOPN Forwarding by Location

Use the show l2vpn forwarding location command to see segments and
the relevant information
In the first segment we see the attachment circuit is defined by the
physical interface. In the second segment we see that the AC is part of the
same bridge domain as the PWs, but not part of the split horizon group. A
split horizon group was not configured for the AC. Lastly the link status is
shown.
The two PWs displayed are MPLS interfaces, showing the destination
address and PW-ID. They are part of the same bridge group as the AC. By
default the PWs are also part of the same split horizon group.
The show l2vpn forwarding bridge-domain mac-address location
command shows three MAC addresses, the AC from the physical GigE
connection, and two from the PWs representing the ACs to which they
connect.
7104
Version 4.0.1

Module 7
Display L2VPN Forwarding by Location
AC
MPLS G0/5/1/0
U-PE3 10.33.3.3
AC
G0/4/0/0 U-PE2 10.22.2.2
VFI
VFI
N-PE3
10.3.3.3
MPLS
MPLS
VFI
N-PE1 10.1.1.1
N-PE4
10.4.4.4
U-PE4
:N-PE3# show l2vpn forwarding location 0/5/cpu0

Segment 1
Segment 2
State
------------------------------------ --------------------------------- -----Gi0/5/1/0(Eth port)
Bridge id 0, SHG id 0
UP
mpls
10.1.1.1,3001
UP
mpls
10.4.4.4,3001
UP
:N-PE3#show l2vpn forwarding bridge-domain mac-address location 0/5/cpu0
Tue Mar 16 01:24:51.737 UTC
Mac Address
Type
LC learned Age
---------------------------------------------------------------------------0003.323c.488c dynamic Gi0/5/1/0
0/5/CPU0
0d 0h 1m 59s
0003.e412.f48c dynamic 10.1.1.1, 3001
0/5/CPU0
0d 0h 2m 18s
0009.12fe.ec8c dynamic 10.4.4.4, 3001
0/5/CPU0
0d 0h 0m 32s
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/74
7105
Layer 2 VPNs
Module 7
H-VPLS Redundancy
Pseudowire redundancy allows you to configure your network to detect a
failure and reroute the Layer 2 service to another endpoint that can
continue to provide service. This feature provides the ability to recover
from a failure of either the remote provider edge (PE) router or the link
between the PE and customer edge (CE) routers.
Pseudowire redundancy involves configuring the network with redundant
pseudowires and redundant network elements.
H-VPLS Access Redundancy

Redundant links, both core and access, CEs, U-PEs, N-PEs and core
routers are essential to minimizing packet drop and provide traffic
continuity. H-VPLS N-PE redundancy allows U-PEs to be dual-homed in a
loop-free topology. Old MAC addresses associated with a failed peer are
flushed on N-PEs to minimize packet loss. New MAC associations are
learned using the VPLS flooding mechanism when traffic flows again over
a backup N-PE.
If the PW between the U-PE router and N-PE fails, the L2VPN PW
redundancy feature on the U-PE activates the standby PW. In addition,
the U-PE sends a LDP MAC address withdrawal request to the new N-PE.
The new N-PE forwards the message to all PWs in the VPLS core so they
flush their MAC address table.
If a VFI on the N-PE fails, the L2VPN PW redundancy feature activates
the standby PW and the U-PE router sends a MAC withdrawal message to
the newly active N-PE.
Regardless of redundant U-PEs, and U-PE links, core devices and core
links, connectivity loss will occur if there is no redundancy at the core edge
(N-PE).
7106
Version 4.0.1

Module 7
H-VPLS Redundancy
H-VPLS Access Redundancy
U-PE
CE
N-PE21
N-PE11
VFI
VFI
VFI
VFI
N-PE12
N-PE22
VFI
N-PE31
U-PE uses PW redundancy to create active and backup

PW to N-PEs
Primary N-PE or all its U-PE facing links fail
! Active PW fails
! U-PE will switch to the backup PW
Link or node failure in the MPLS cloud triggers TE FRR
! PW will cut-over to different TE tunnel
! U-PE will keep original active PW instead of switchover to
backup PW
Version 3.9.0a
U-PE1
Primary PW
XMPLST4Module #/77
N-PE2
N-PE1 Primary
VFI
VFI
Primary PW
U-PE3
MPLS Core
U-PE2
Primary PW
VFI
VFI
N-PE4
N-PE3 Backup
Primary PW
U-PE4
PW between the U-PE and N-PE fails

Redundancy feature on the U-PE activates the standby PW
U-PE sends LDP MAC address withdrawal request to new N-PE
New N-PE, forwards the message to all PWs in the VPLS core;
flushes its MAC address table
VFI on N-PE fails, U-PE redundancy feature activates

standby PW
U-PE sends a MAC withdrawal message to new active N-PE
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/78
7107
Layer 2 VPNs
Module 7
H-VPLS Redundancy Review

To maintain redundancy between the U-PE and N-PE, one PW is
configured as a standby for loop prevention. The initial PW switches data
between a U-PE and its peered N-PEs while the backup PW is kept in
standby, eliminating any loops.
When a PW fails, the backup PW becomes active.
H-VPLS N-PE redundancy has three components:
L2VPN PW redundancy at the U-PE
Termination of the PW into a VFI interface on the N-PE
MAC address withdrawal using LDP

!
7108
Minimizes the possibility of traffic black holing by pushing all

N-PEs within the core to flush all MAC associations for the failed
peer
Version 4.0.1

Module 7
H-VPLS Redundancy
H-VPLS Redundancy Review
Two PWs are created
Traffic is always blocked on one PW for loop prevention
! Initial PW switches data between a U-PE and the peered N-PE

! Backup PW is kept in standby eliminating any loops
On PW failure, backup PW becomes active

H-VPLS N-PE redundancy requires three components:
! L2VPN PW redundancy at the U-PE

! Termination of the PW into an VFI interface on the N-PE
! MAC address withdrawal using LDP
" Minimizes traffic black holes by pushing all N-PEs within the core to
flush all MAC associations for the failed peer
Version 3.9.0a
XMPLST4Module #/79
Instructor's Note
A PW failure nay be detected by several different protocols, VCCV, LDP TCP session failure, or
IGP failure
Version 4.0.1
7109
Layer 2 VPNs
Module 7
MAC Address Withdrawal

MAC addresses may become outdated as a result of incidents that may
occur in the network.
MAC Address Withdrawal and Solution

MAC address withdrawal solves the traffic black hole problem caused by
MAC addresses becoming outdated after a PW switchover. Outdated MAC
addresses are the result of VFI and PWs remaining up, so existing MAC
entries stay active until they are aged out. To solve the traffic black hole
problem, when a backup PW becomes active the U-PE generates a MAC
address withdrawal message using a targeted LDP message.
In the illustration, router N-PE3 flushes its MAC table and forwards the
message to its peers, such as n-PE2. After receiving the MAC withdrawal
message, remote PEs flushes their MAC address tables.
A packet from N-PE2 is flooded to all N-PEs. The flooding stops when the
PE receives a packet from the opposite direction with a destination MAC
address.
7110
Version 4.0.1

Module 7
Problem: Access circuit or PW to N-PE1 fails
N-PE2 continues forwarding traffic to N-PE1

Result is a uni-directional traffic blackhole
Traffic from U-PE2 through N-PE2 to N-PE1 for U-PE1 is lost while backup
N-PE3 becomes active and updates N-PE2
Solution:
Expedite MAC address flushing on N-PE2 while backup N-PE3 activates
and then updates N-PE2. U-PE1 sends MAC withdrawal to N-PE3 which
flushes its table and forwards message to N-PE2 to flush its table
U-PE1
N-PE1
N-PE2
U-PE3
U-PE2
N-PE3
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/81
7111
Layer 2 VPNs
Module 7
MAC Address Withdrawal Message

MAC address withdrawal messages speed up the convergence process in
the event of a network failure. When a network failure occurs, PEs without
the MAC address withdrawal feature rely on their MAC address-aging
timer to purge their MAC tables before redirecting traffic.
With MAC address withdrawal the PE removes locally learned MAC
addresses and sends an LDP address withdraw message to remote VPLS
PEs, using a targeted LDP session.
The LDP MAC withdrawal TLV contains a null list of MAC addresses. This
tells the destination PE to withdraw all MAC addresses. For each MAC
address withdrawn the PE:
Relearns the association between the MAC address and the interface or
PW over which this message is received
Sends the same message to all other PEs over the corresponding
directed LDP sessions
To verify that the MAC address withdrawal is enabled, use the

show l2vpn bridge-domain command with the detail keyword.
7112
Version 4.0.1

Module 7
MAC Address Withdrawal Message
Directed LDP
MPLS
M
withdAC
rawal
MAC wal
dra
t
i
w h
MAC address withdrawal messages speed up the convergence

process
! When failures occur
Without MAC address withdrawal if a failure occurs

! PE relies on MAC address aging timer
With MAC address withdrawal
! PE removes locally learned MAC addresses

! PE sends LDP address withdraw messages to remote VPLS PEs
(using a directed LDP session)
! MAC List TLV is used to withdraw addresses
Version 3.9.0a
XMPLST4Module #/82
Instructor's Note
The IETF standard specifies a TLV withdrawal message setting a list of MAC addresses to be
withdrawn or the use of a null list. The null list standard means flush the entire MAC table.
Cisco IOS XR uses the null list in the MAC withdrawal message.
Version 4.0.1
7113
Layer 2 VPNs
Module 7
VPLS Access Redundancy Configuration

Following is an example of an access redundancy configuration for a U-PE
and corresponding N-PE.
Configure U-PE1
Enter the configuration mode for L2VPN and define:

!
PW class with an encapsulation mode of MPLS
MAC address withdraw option
Xconnect group with point-to-point connectivity
Attachment circuit and the neighbor IP address with PW ID and

attach the PW class to the neighbor statement
Backup neighbor with PW ID and attach the PW class to the

backup neighbor statement
Configure N-PE1 Primary
Enter the configuration mode for L2VPN and define:

!
PW class with an encapsulation mode of MPLS
Bridge group and bridge domain within the group
Interfaces and IP addresses plus PW ID for N-PE1s two upstream

neighbors, U-PE1 and U-PE2
The VFI for N-PE1s VPLS downstream neighbors (PE-2 and

N-PE3). Provide a neighbor statement for each downstream
neighbor that includes its PW ID and PW class
Instructor's Note
The mac-withdraw command on U-PE1 has been attached to pw-class. On the N-PE bridge
domain, MAC withdraw is the default mode of operation. This command can be disabled for the
bridge domain, using the MAC withdraw disable command. Note the syntax difference when
used in a pw-class versus a bridge domain.
7114
Version 4.0.1

Module 7
VPLS Access Redundancy Configuration
U-PE110.11.1.1
N-PE1 Primary
G0/4/0/4
PE2
10.1.1.1
G0/5/0/2 VFI
VFI
MPLS Core
CE
10.2.2.2
CE
MPLS
PW
VFI
G0/4/0/4 U-PE3 10.33.3.3
N-PE3 Backup 10.3.3.3
U-PE1
:# configure
:(config)# l2vpn
:(config-l2vpn)# pw-class REDUNDANCY
:(config-l2vpn-pwc)# encapsulation
N-PE1 Primarympls
U-PE110.11.1.1
PE2
10.1.1.1
:(config-l2vpn-pwc)#
mac-withdraw
:(config-l2vpn)# xconnect
group
A
VFI
G0/5/0/2
VFI
G0/4/0/4
CE
:(config-l2vpn-xc)#
p2p UPE1-NPE
MPLS Core
10.2.2.2
MPLS
:(config-l2vpn-xc-p2p)#
neighbor 10.1.1.1 pw-id 2
PW
:(config-l2vpn-xc-p2p-pw)# pw-class REDUNDANCY
VFI
:(config-l2vpn-xc-p2p-pw)# backup neighbor 10.3.3.3 pw-id 2
G0/4/0/4
10.3.3.3
:(config-l2vpn-xc-p2p-pw)#
pw-class
REDUNDANCY
U-PE3 10.33.3.3
N-PE3
Backup
CE
Version 3.9.0a
XMPLST4Module #/84
N-PE1
:# configure
:(config)# l2vpn
:(config-l2vpn)# pw-class
CLASS1
N-PE1
Primary
U-PE110.11.1.1 encapsulation
:(config-l2vpn-pwc)#
mpls
PE2
10.1.1.1
:(config-l2vpn)# bridge group CLASS-LAB
G0/5/0/2 VFI
VFI
G0/4/0/4
:(config-l2vpn-bg)#
bridge-domain CLASS-DOMAIN
CE
CE
MPLS
Core
10.2.2.2
MPLS
:(config-l2vpn-bg-bd-ac)# neighbor 10.11.1.1 pw-id 2
PW
:(config-l2vpn-bg-bd)#
vfi CLASS-VFI
VFI neighbor 10.2.2.2 pw-id 2 pw-class CLASS1
:(config-l2vpn-bg-bd-vfi)#
:(config-l2vpn-bg-bd-vfi)#
neighbor
10.3.3.3
pw-id 2 pw-class CLASS1
G0/4/0/4 U-PE3 10.33.3.3
10.3.3.3
N-PE3
Backup
Version 3.9.0a
XMPLST4Module #/86
N-PE1 (continued)
:(config-l2vpn-bg)# bridge-domain CLASS-DOMAIN5
:(config-l2vpn-bg-bd-ac)# neighbor 10.33.3.3 pw-id 5
:(config-l2vpn-bg-bd)# vfi CLASS-VFI
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/87
7115
Layer 2 VPNs
Module 7
VPLS Auto-Discovery
This section covers the automatic discovery of members of a VPLS domain.
VPLS without Auto-Discovery

Without auto-discovery the Cisco IOS XR software VPLS implementation
requires manual configuration of each VPLS neighbor on each PE. When a
new neighbor is added or deleted, the user must manually update the
configuration on all existing PE neighbors. When a new PE is added, the
new PE must be manually configured to connect to all existing neighbors.
VPLS with Auto-Discovery

VPLS auto-discovery is BGP-base and eliminates the need to manually
provision VPLS neighbors. After a PE is configured as a member of a
particular VPLS domain, the information required to set up connections to
remote PEs in the same VPLS domain, is distributed using BGP. When the
discovery process is complete, each PE will have the information needed to
setup VPLS PWs.
7116
Version 4.0.1

Module 7
VPLS Auto-Discovery
VPLS Auto-Discovery
VPLS without auto-discovery
Adding or removing a PE from the VPLS domain requires manual

configuration
Manual configuration adds operational costs and increases the

chance of configuration errors
No flexibility
VPLS with auto-discovery
Discovers PEs within the same VPLS domain

Automatically detects new PEs that are added or removed from
the VPLS domain
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/89
7117
Layer 2 VPNs
Module 7
VPLS Auto-Discovery and Signaling

Auto-discovery and signaling are VPLS control plane tasks used for
L2VPN establishment:
Auto-discovery automatically finds members (PE routers) of a VPLS

domain using BGP update messages
Signaling establishes the PWs. PE routers in a VPLS domain establish

point-to-point communication to send and withdraw VPN labels. These
labels are used to establish and teardown PWs between routers.
Signaling is used to transmit PW characteristics such as MTU
information and state changes.
Cisco IOS XR software supports BGP VPLS auto-discovery and signaling

within the same VFI.
The block diagram in the illustration shows VPN auto-discovery as a
function of distributed BGP. BGP is the configuration agent that discovers
VPN members without the need to explicitly list them. The configuration
steps enable the L2VPN family as part of the BGP configuration and then
create a VPLS VFI and use BGP signaling and auto-discovery.
VPLS signaling takes one of two forms:
LDP for manual configuration
BGP with auto-discovery protocol, where the peers use BGP signaling
Instructor's Note
BGP-AD with LDP signaling is currently supported only on the ASR 9000 router series and is to
be supported on all platforms in Rel 4.0.1.
Auto-discovery is a BGP extended community for PW-ID. The configuration commands:
router BGP
l2vpn
address-family
7118
Version 4.0.1

Module 7
VPLS Auto-Discovery
VPLS Auto-Discovery and Signaling
Auto-discovery and signaling are separate tasks used for

L2VPN establishment
Discovery - finds members of a L2VPN

!
Point-to-multipoint task
Signaling - establishes the pseudowires

!
Point-to-point task
Cisco IOS XR software supports BGP auto-discovery and

signaling in the same VFI
Cisco IOS XR software supports a combination of LDP
signaling and manual PW configuration in addition to
BGP auto-discovery and signaling in the same VFI
VPN
discovery
Signaling
Distributed
BGP
LDP (manual config)
BGP with auto-discovery

protocol
Auto-discovery
BGP is the configuration agent

True auto-discovery of VPN members
No need to explicitly list them
Signaling
Auto-discovery peers use BGP signaling

Auto-discovery configuration steps
Enable the L2VPN address family under the BGP configuration

Create a new VPLS VFI and use BGP signaling and auto-discovery
Instructor's Note
BGP-AD with LDP signaling is only supported on ASR 9000 at 3.9.1 and on all platforms at 4.0.1
Version 4.0.1
7119
Layer 2 VPNs
Module 7
BGP Auto-Discovery Terminology

Here are some terms used with auto-discovery. Some of these terms are
familiar and have been used in this course material.
7120
VPN-IDRepresents a bridge domain to the discovery database that

stores all AD information that pertains to the VPN (for example, route
distinguisher and route target). It is router specific and is used as an
index into the database. It is not distributed to other PEs
Route distinguisher (RD)Is a prefix added to packets originating

from a customer. It distinguishes traffic streams from different
customers. The RD must be unique within a router and is not
advertised to other PEs
Route target (RT)Identifies a VPLS bridge in a BGP AD network.

The export RT is contained in the NLRI advertised to other PEs. The
import RT is matched to the received RT in the NLRI to determine if
they belong to the same VPLS service
VPLS Edge-ID (VE-ID)Is a unique PE identifier in VPLS. VFIs in

the same VPLS service cannot share the same VE-ID. VFIs in different
bridge domains may have the same VE-ID
Network layer reachability information (NLRI)Used to

exchange VPLS membership information and parameters
Address family identifier and subsequent address family

identifier (AFI and SAFI)defines the semantics of the NLRI
messages
Version 4.0.1

Module 7
VPLS Auto-Discovery
BGP Auto-discovery Terminology
VPN-ID
! Represents a bridge domain to the discovery database storing all

AD information for the VPN (route distinguisher and route target
" Router specific
" Used as a index into the database
" Not advertised to other PEs
Route Distinguisher (RD)
! Prefix added to packets originating from a customer

! Distinguishes traffic streams from different customers
! Must be unique within router
" Not advertised to other PEs
Route Target (RT)
! Identifies a VPLS bridge in a BGP AD network

! Export RT is contained in NLRI advertised to other PEs
! Import RT is matched to the received RT in the NLRI to determine
if they belong to the same VPLS service
Version 3.9.0a
XMPLST4Module #/94
VPLS edge-ID (VE-ID)
! VE-ID is a unique PE identifier in VPLS

! VFIs in the same VPLS service cannot share the same VE-ID
! VFIs in different bridge domains can have the same VE-ID
Network layer reachability information (NLRI)
! Used to exchange VPLS membership information and parameters
Address Family Identifier and Subsequent Address Family

Identifier (AFI and SAFI)
! Defines the semantics of the NLRI messages

Instructor's Note
When a L2VPN address family is configured under BGP, the BGP process connects to the
L2VPN manager to learn about configured bridge domains and xconnects. The BGP process uses
the information to send NLRI messages for the VPLS bridge domain with the PE as the next hop
and includes the VE-ID and route target.
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/95
7121
Layer 2 VPNs
Module 7
Network Layer Reachability Information

The BGP method of PE auto-discovery is based on that used by L3VPNs to
distribute VPN prefixes between the PEs in the VPN. The MP-BGP
extensions are used to distribute VPN IDs and VPN-specific reachability
information. Since iBGP requires either a full mesh of BGP sessions, or the
use of a route reflector, enabling the VPN ID in a PEs BGP configuration
provides it with a list of all PEs. This method is for auto-discovery; LDP is
still used for signaling. This method of establishing VPLS with BGP
accomplishes both auto-discovery and signaling.
VPLS BGP network layer reachability information is used to exchange
VPLS membership information and parameters.
The components of a NLRI message are:
7122
LengthLength of the NLRI message
Route distinguisherA prefix added to packets originating from the

customer, to distinguish the traffic streams of different customers.
Must be unique for each VPLS
VPLS edge ID (VE-ID)Unique PE site identifier for a VPLS.!The

VPLS PE uses the VE- ID to index label blocks to derive transmit and
receive VPN labels for the transport of VPLS traffic. The VE-ID
identifies a PE site; it must be unique within the VPLS domain
VE block offset!Label block that provides labels to set up PWs for a

remote site
VE block sizeNumber of PWs that a peer may have in a single block
Label base!Initial label value in the advertised label block
Version 4.0.1

Module 7
VPLS Auto-Discovery
Network Layer Reachability Information
VPLS BGP NLRI used to exchange VPLS membership

information and parameters
The components of a NLRI message are:
!Length of NLRI message

!Route distinguisher prefix
" Added to packets to distinguish traffic streams from different
customers
" Unique for each VPLS
!VPLS edge ID (VE-ID)

" Unique PE site identifier for a VPLS
!VE block offset
" Identifies label block that provides labels to set up PWs
!VE block size
" Defines the number of PWs that a peer may have in a single block
!Label base
" Initial label value in the advertised label block
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/96
7123
Layer 2 VPNs
Module 7
VPLS BGP Auto-Discovery Configuration

In the example, PE4 is configured for VPLS auto-discovery:
MPLS LDP
!
7124
Router ID and LDP interfaces are defined
Router BGP
!
IPv4 and L2VPN address families are enabled for the BGP process
Each VPLS neighbor is configured with the IPv4 unicast and

L2VPN address families
L2VPN
!
Establish a bridge group enabling the bridging function in the

device
Define a bridge domain. This is a logical multiport switch that has

physical and logical ports. Define the physical ports (ACs) that are
part of the bridge domain
Define the virtual forwarding interface (VFI) to interconnect a mesh

of PWs. This configuration connects the defined VFI to the bridge
domain through a logical port
Define the VPN ID, which is an independent VFI attribute that is

locally significant, and must be unique within the router. It
represents the bridge domain to the discovery database that stores
all auto-discovery information pertaining to the VPN
Define auto-discovery BGP as the discovery protocol in the VFI. Add

the route distinguisher (RD) to BGP AD. This prefix is added to
traffic streams to distinguish one from another. The route target
identifies the NLRI for traffic streams that belong to the same
VPLS service
Enable BGP as the signaling protocol. Then add the VE-ID to

specify a local and unique identifier for each PE in the VFI
Version 4.0.1

Module 7
VPLS Auto-Discovery
VPLS BGP Auto-Discovery Configuration
10.5.5.5
G0/4/0/4
PE4
PE5
G0/4/0/4
CE5
10.4.4.4
CE4
MPLS Core
10.6.6.6 PE6
G0/4/0/4
CE6
G0/4/0/5
:PE4(config)# mpls ldp

:PE4(config-ldp)# router-id 10.4.4.4
:PE4(config-ldp)# interface GigabitEthernet0/4/0/5
:PE4(config)# router bgp 100
:PE4(config-bgp)# bgp router-id 10.4.4.4
:PE4(config-bgp)# address-family ipv4 unicast
:PE4(config-bgp)# address-family l2vpn vpls-vpws
:PE4(config-bgp)# neighbor 10.5.5.5
:PE4(config-bgp-nbr)# remote-as 100
:PE4(config-bgp-nbr)# update-source Loopback0
:PE4(config-bgp-nbr)# address-family ipv4 unicast
:PE4(config-bgp-nbr)# address-family l2vpn vpls-vpws
PE5
10.5.5.5
:PE4(config-bgp)# neighbor 10.6.6.6
G0/4/0/4
:PE4(config-bgp-nbr)#
remote-as
100
10.4.4.4
PE4
:PE4(config-bgp-nbr)#
update-source Loopback0
MPLS Core
CE4:PE4(config-bgp-nbr)# address-family ipv4 unicast
10.6.6.6 PE6
:PE4(config-bgp-nbr)# address-family l2vpn vpls-vpws
G0/4/0/5
Version 3.9.0a
G0/4/0/4
CE5
G0/4/0/4
CE6
XMPLST4Module #/98
:PE4(config)# l2vpn
:PE4(config-l2vpn)# bridge group TEST-BRIDGE
:PE4(config-l2vpn-bg)# bridge-domain TEST-DOMAIN
:PE4(config-l2vpn-bg-bd)# interface GigabitEthernet0/4/0/4
!
:PE4(config-l2vpn-bg-bd)# vfi CLASS
! Auto-discovery independent VFI attributes
:PE4(config-l2vpn-bg-bd-vfi)# vpn-id 1000
! Auto-discovery attributes
:PE4(config-l2vpn-bg-bd-vfi)# autodiscovery bgp
:PE4(config-l2vpn-bg-bd-vfi-ad)# rd auto
:PE4(config-l2vpn-bg-bd-vfi-ad)# route-target import 10:10
:PE4(config-l2vpn-bg-bd-vfi-ad)# route-target export 10:10
! Signaling attributes
:PE4(config-l2vpn-bg-bd-vfi-ad)# signaling-protocol bgp
:PE4(config-l2vpn-bg-bd-vfi-ad)# ve-id 4
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/99
7125
Layer 2 VPNs
Module 7
Display BGP L2VPN VPLS

The show bgp l2vpn vpls command provides basic BGP information in
addition to the route distinguisher data for the VPLS edge devices. The
received VPLS labels that have been assigned to the other PE routers for
this VPLS domain in addition to the local VPLS label are displayed. The
VPLS label is the internal label in the transmitted label stack. Other
details:
BGP router ID, local AS, scan interval, table state and ID, and table
version
Route distinguishers for each device in the VPLS domain
Router next hops
Received VPLS labels that have been assigned to remote PE routers
Local VPLS label representing this VPLS domain
Display L2VPN Discovery Bridge-Domain

The show l2vpn discovery bridge-domain command shows basic
service and bridge domain information. In addition, local and peer VPLS
label information is provided. Other details:
Service type is VPLS and connections are complete
Bridge group and bridge domain are displayed
Local edge is the attachment circuit, with the local label displayed
Remote edge displays the remote PE devices and the VPLS labels that
represent them
Instructor's Note
Other useful show commands:
show l2vpn bridge detail
show bgp l2vpn vpls
show mpls label table
7126
Version 4.0.1

Module 7
VPLS Auto-Discovery
Display BGP L2VPN VPLS and L2VPN Discovery Bridge-Domain
10.5.5.5
G0/4/0/4
PE4
CE4
PE5
G0/4/0/4
CE5
10.4.4.4
MPLS Core
10.6.6.6 PE6
G0/4/0/4
CE6
:PE4# show bgp l2vpn vpls

BGP generic scan interval 60 secs BGP table state: Active Table ID: 0x0
BGP main routing table version 6 BGP scan interval 60 secs
Network
Next Hop
Rcvd Label
Local Label
Route Distinguisher:10.4.4.4:32768(default for vrf test-bridge:test-domain)
*> 4:1/32
0.0.0.0
nolabel
16015
*>i5:1/32
10.5.5.5
16015
nolabel
*>i6:1/32
10.6.6.6
16015
nolabel
G0/4/0/4
PE5
10.5.5.5
Route Distinguisher: 10.5.5.5:32768
CE5
G0/4/0/4
*>i5:1/32
10.5.5.5
16015
nolabel
10.4.4.4
PE4
Route Distinguisher: 10.6.6.6:32768
MPLS Core
G0/4/0/4
CE4*>i6:1/32
10.6.6.6
16015
nolabel
10.6.6.6 PE6
CE6
Version 3.9.0a
XMPLST4Module #/100
:PE4# show l2vpn discovery bridge-domain

Service Type: VPLS, Connected
List of VPNs (1 VPNs):
Bridge group: test-bridge, bridge-domain: test-domain, id: 0
List of Local Edges (1 Edges):
Local Edge ID: 4, Label Blocks (1 Blocks)
Label base Offset
Size
Time Created
---------- --------------------------16015
1
10
03/18/2010 23:34:39
List of Remote Edges (2 Edges):
Remote Edge ID: 5, NLRIs (1 NLRIs)
Label base Offset
Size
Peer ID
Time Created
---------- ----------------------- ------------------16015
1
10
10.5.5.5
03/18/2010 23:44:34
Remote Edge ID: 6, NLRIs (1 NLRIs)
Label base Offset
Size
Peer ID
Time Created
---------- ----------------------- ------------------16015
1
10
10.6.6.6
03/18/2010 23:36:29
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/101
7127
Layer 2 VPNs
Module 7
Display L2VPN Bridge-Domain Detail

The show l2vpn bridge-domain detail command provides a detailed
display of the configured L2VPN parameters and their status. This is
followed by the status of the connection with each of PE4s VPLS neighbors.
Finally, MPLS parameters for the local and remote ends of the neighbor
relationship are displayed, including:
7128
MPLS switching label; local label representing PE4, and remote label
representing PE5
MTU on both the local and remote ends
Control word is not used with Ethernet
PW type is VPLS
VE-ID for the PE at the local and remote end
Version 4.0.1

Module 7
VPLS Auto-Discovery
Display L2VPN Bridge-Domain Detail
10.5.5.5
G0/4/0/4
PE4
CE4
PE5
G0/4/0/4
CE5
10.4.4.4
MPLS Core
10.6.6.6 PE6
G0/4/0/4
CE6
:PE4# show l2vpn bridge-domain detail

VFI class
VPN-ID: 1000 Auto Discovery:BGP, state is Advertised (Service Connected)
Route Distinguisher: (auto) 10.4.4.4:32768
Import Route Targets: 10:10
Export Route Targets: 10:10
Signaling protocol: BGP
Local VE-ID: 4 , Advertised Local VE-ID : 4
VE-Range: 10
PW class not set, XC ID 0xff000008
Encapsulation MPLS, Auto-discovered (BGP), protocol BGP
PW type VPLS, control word disabled, interworking none
PW backup disable delay 0 sec
Sequencing not set
MPLS
Local
Remote
------------ ------------------------------ --------------------Label
16019
16018
MTU
1500
1500
disabled
PW type
VPLS
VPLS
VE-ID
4
5
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/102
7129
Layer 2 VPNs
Module 7
Display L2VPN Forwarding Bridge-Domain MAC-Address by Location

The show L2VPN forwarding bridge-domain mac-address location
command provides detailed information on the bridge domains MAC
address table. In the example shown, the MAC address of the directly
attached Ethernet circuit from CE4 is displayed, along with, the PWs to
PE5 and PE6, and including the VPN-ID and the MAC addresses of their
corresponding CE routers.
7130
Version 4.0.1

Module 7
VPLS Auto-Discovery
Show L2VPN Forward Bridge-Domain MAC-Address Location
10.5.5.5
G0/4/0/4
PE4
CE4
PE5
G0/4/0/4
CE5
10.4.4.4
MPLS Core
10.6.6.6 PE6
G0/4/0/4
CE6
:PE4# show l2vpn forward bridge-domain mac-addr location 0/4/cpu0

Mac Address
Type
Learned from/Filtered on LC learned Age
-------------------------------------------------------------------------0003.323c.488c dynamic Gi0/4/0/4
0/4/CPU0
0d 0h 2m 40s
0003.e412.f48c dynamic 10.5.5.5, 1000
0/4/CPU0
0d 0h 1m 12s
0009.12fe.ec8c dynamic 10.6.6.6, 1000
0/4/CPU0
0d 0h 2m 1s
Version 3.9.0a
Version 4.0.1
XMPLST4Module #/103
7131
Layer 2 VPNs
Module 7
Summary
Layer 2 VPNs
In this module, you learned the following:
7132
Describe Layer 2 VPNs
Implement and verify L2VPNs
Compare Layer 2 and Layer 3 VPNs
Describe and define pseudowires and their use
Define AToM, its use, and interworking with Cisco IOS XR operating
system software
Define and configure EoMPLS
Define and implement pseudowire redundancy
Define and configure VPLS flat and hierarchical architectures
Define pseudowire switching
Version 4.0.1

Part Number: XMPLST4

XMPLST4-IG v4.0.1

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

XMPLST4-IG v4.0.1

Transféré par

Droits d'auteur :

Formats disponibles

XMPLST4

Cisco IOS XR MPLS and

Copyright ! 2011, Cisco Systems, Inc. All rights reserved.

Network and senior engineers

Network operations center (NOC) engineers

Have knowledge of the Cisco IOS XR Software configuration

Be able to establish, without assistance, a configuration for Open

Have a basic understanding of MPLS configuration and operation

2011 Cisco Systems, Inc.

Comprehensive network support is available from Cisco Systems

Cisco IOS XR MPLS and

2011 Cisco Systems, Inc.

Cisco IOS XR MPLS and

Course Introduction and Objectives

Cisco IOS XR Multiprotocol Label Switching (MPLS)

MPLS Label Distribution Protocol (LDP)

MPLS Traffic Engineering (MPLS-TE)

Resource Reservation Protocol (RSVP)

Layer 3 Virtual Private Networks (L3VPN)

Layer 2 VPNs (L2VPN)

Any Transport over MPLS (AToM)

2011 Cisco Systems, Inc.

Describe MPLS, MPLS LDP, MP-BGP, RSVP, MPLS-TE, L2VPN,

Configure MPLS, MPLS LDP, MP-BGP, RSVP, MPLS-TE, L2VPN,

Verify MPLS, MPLS LDP, MP-BGP, RSVP, MPLS-TE, L2VPN,

Examine MPLS, MPLS LDP, MP-BGP, RSVP, MPLS-TE, L2VPN,

Cisco IOS XR MPLS and

Course Introduction and Objectives ................................................................ ix!

LDP Protocol Overview ................................................................................................... 314!

Module 4........................................................................................................... 41!

Cisco IOS XR MPLS and

Module 6........................................................................................................... 61!

2011 Cisco Systems, Inc.

This page is intentionally blank.

Cisco IOS XR MPLS and

Describe MPLS and Label Distribution Protocol (LDP)

Describe MPLS Layer 2 and Layer 3 tunnel concepts

Describe MPLS Traffic Engineering (TE) concepts and operation

Describe MPLS control and forwarding planes

2011 Cisco Systems, Inc.

MPLS Technology Introduction

MPLS Conceptual Overview

RFC 4446: IANA Allocations for Pseudowire Edge-to-Edge Emulation

RFC 4447: Pseudowire Setup and Maintenance Using the Label

RFC 4448: Encapsulation Methods for Transport of Ethernet over

Cisco IOS XR MPLS and

MPLS Conceptual Overview

Multiprotocol Label Switching is a technology for delivery

MPLS technology uses labels, rather than IP addresses,

Layer 2 technologies can traverse an MPLS network

2011, Cisco Systems, Inc. All rights reserved.

2011 Cisco Systems, Inc.

MPLS Technology Introduction

MPLS and Value-Added Services

Cisco IOS XR MPLS and

MPLS Conceptual Overview

MPLS and Value-Added Services

2011, Cisco Systems, Inc. All rights reserved.

2011 Cisco Systems, Inc.

MPLS Technology Introduction

Cisco IOS XR MPLS and

MPLS Conceptual Overview

Privacy in MPLS relies on three principles