Cisco IOS XE Multi Protocol Label Switching Configuration Guide, Release 2

Cisco IOS XE Multiprotocol Label
Switching Configuration Guide

Release 2
Americas Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 527-0883
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT NOTICE. ALL
STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT ARE PRESENTED WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION PACKET THAT
SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO LOCATE THE SOFTWARE LICENSE
OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as part of UCB’s public
domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE PROVIDED “AS IS” WITH
ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING, WITHOUT
LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT OR ARISING FROM A COURSE OF
DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL DAMAGES, INCLUDING,
WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR INABILITY TO USE THIS MANUAL, EVEN IF CISCO
OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase, Cisco StackPower,
Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra,
Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital,
Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card, and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch,
AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo,
Cisco IOS, Cisco Lumin, Cisco Nexus, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation,
Continuum, EtherFast, EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream,
Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design),
PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc.
and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website 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. (0910R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the
document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
Cisco IOS XE Multiprotocol Label Switching Configuration Guide

© 2009 Cisco Systems, Inc. All rights reserved.
About Cisco IOS XE Software Documentation
Last Updated: December 1, 2009
This document describes the objectives, audience, conventions, and organization used in Cisco IOS XE
software documentation. Also included are resources for obtaining technical assistance, additional
documentation, and other information from Cisco. This document is organized into the following
sections:
• Documentation Objectives, page i
• Audience, page i
• Documentation Conventions, page ii
• Documentation Organization, page iii
• Additional Resources and Documentation Feedback, page x
Documentation Objectives
Cisco IOS XE documentation describe the tasks and commands available to configure and maintain
Cisco networking devices.
Audience
The Cisco IOS XE documentation set is intended for users who configure and maintain Cisco networking
devices (such as routers and switches) but who may not be familiar with the configuration and
maintenance tasks, the relationship among tasks, or the Cisco IOS commands necessary to perform
particular tasks. The Cisco IOS XE documentation set is also intended for those users experienced with
Cisco IOS XE software who need to know about new features, new configuration options, and new
software characteristics in the current Cisco IOS XE release.
i
Documentation Conventions
Documentation Conventions
In Cisco IOS XE documentation, the term router may be used to refer to various Cisco products; for
example, routers, access servers, and switches. These and other networking devices that support
Cisco IOS XE software are shown interchangeably in examples and are used only for illustrative
purposes. An example that shows one product does not necessarily mean that other products are not
supported.
This section contains the following topics:
• Typographic Conventions, page ii
• Command Syntax Conventions, page ii
• Software Conventions, page iii
• Reader Alert Conventions, page iii
Typographic Conventions
Cisco IOS XE documentation uses the following typographic conventions:
Convention Description
^ or Ctrl Both the ^ symbol and Ctrl represent the Control (Ctrl) key on a keyboard. For
example, the key combination ^D or Ctrl-D means that you hold down the
Control key while you press the D key. (Keys are indicated in capital letters but
are not case sensitive.)
string A string is a nonquoted set of characters shown in italics. For example, when
setting a Simple Network Management Protocol (SNMP) community string to
public, do not use quotation marks around the string; otherwise, the string will
include the quotation marks.
Command Syntax Conventions

Cisco IOS XE documentation uses the following command syntax conventions:
bold Bold text indicates commands and keywords that you enter as shown.
italic Italic text indicates arguments for which you supply values.
[x] Square brackets enclose an optional keyword or argument.
... An ellipsis (three consecutive nonbolded periods without spaces) after a syntax
element indicates that the element can be repeated.
| A vertical line, called a pipe, indicates a choice within a set of keywords
or arguments.
[x | y] Square brackets enclosing keywords or arguments separated by a pipe indicate an
optional choice.
{x | y} Braces enclosing keywords or arguments separated by a pipe indicate a
required choice.
[x {y | z}] Braces and a pipe within square brackets indicate a required choice within an
optional element.
ii
Documentation Organization
Software Conventions
Cisco IOS XE software uses the following conventions:
Courier font Courier font is used for information that is displayed on a PC or terminal screen.
Bold Courier font Bold Courier font indicates text that the user must enter.
< > Angle brackets enclose text that is not displayed, such as a password. Angle
brackets also are used in contexts in which the italic font style is not supported;
for example, ASCII text.
! An exclamation point at the beginning of a line indicates that the text that follows
is a comment, not a line of code. An exclamation point is also displayed by the
Cisco IOS XE software for certain processes.
[ ] Square brackets enclose default responses to system prompts.
Reader Alert Conventions

Cisco IOS XE documentation uses the following conventions for reader alerts:
Caution Means reader be careful. In this situation, you might do something that could result in equipment
damage or loss of data.
Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the
manual.
Timesaver Means the described action saves time. You can save time by performing the action described in the
paragraph.
This section describes the Cisco IOS XE documentation set, how it is organized, and how to access it on
Cisco.com. Listed are configuration guides, command references, and supplementary references and
resources that comprise the documentation set.
• Cisco IOS XE Documentation Set, page iv
• Cisco IOS XE Documentation on Cisco.com, page iv
• Configuration Guides, Command References, and Supplementary Resources, page v
iii
Cisco IOS XE Documentation Set

The Cisco IOS XE documentation set consists of the following:
• Release notes and caveats provide information about platform, technology, and feature support for
a release and describe severity 1 (catastrophic), severity 2 (severe), and severity 3 (moderate) defects
in released Cisco IOS XE software. Review release notes before other documents to learn whether
updates have been made to a feature.
• Sets of configuration guides and command references organized by technology and published for
each standard Cisco IOS XE release.
– Configuration guides—Compilations of documents that provide conceptual and task-oriented
descriptions of Cisco IOS XE features.
– Command references—Alphabetical compilations of command pages that provide detailed
information about the commands used in the Cisco IOS XE features and the processes that
comprise the related configuration guides. For each technology, there is a single command
reference that covers all Cisco IOS XE releases and that is updated at each standard release.
• Command reference book for debug commands.
• Lists of all the commands in a specific release and all commands that are new, modified, removed,
or replaced in the release.
• Reference book for system messages for all Cisco IOS XE releases.
Cisco IOS XE Documentation on Cisco.com

The following sections describe the documentation organization and how to access various document
types.
Use Cisco Feature Navigator to find information about Cisco IOS XE software image support. To access
Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
New Features List

The New Features List for each release provides a list of all features in the release with hyperlinks to the
feature guides in which they are documented.
Configuration Guides
Configuration guides are provided by technology and release and comprise a set of individual feature
guides relevant to the release and technology.
Command References
Command reference books describe Cisco IOS XE commands that are supported in many different
software releases and on many different platforms. The books are organized by technology. For
information about all Cisco IOS XE commands, use the Command Lookup Tool at
http://tools.cisco.com/Support/CLILookup or the Cisco IOS Master Command List, All Releases, at
http://www.cisco.com/en/US/docs/ios/mcl/allreleasemcl/all_book.html.
Cisco IOS XE Supplementary Documents and Resources

Supplementary documents and resources are listed in Table 2 on page x.
iv
Configuration Guides, Command References, and Supplementary Resources

Table 1 lists, in alphabetical order, Cisco IOS XE software configuration guides and
command references, including brief descriptions of the contents of the documents. The command
references contain commands for both Cisco IOS software and Cisco IOS XE software, for all releases.
The command references support many different software releases and platforms. Your Cisco IOS XE
software release or platform may not support all these technologies.
Table 2 lists documents and resources that supplement the Cisco IOS XE software configuration guides
and command references. These supplementary resources include release notes and caveats; master
command lists; new, modified, removed, and replaced command lists; system messages; and the debug
command reference.
For additional information about configuring and operating specific networking devices, and to access
Cisco IOS documentation, go to the Product/Technologies Support area of Cisco.com at the following
location:
http://www.cisco.com/go/techdocs
Table 1 Cisco IOS XE Configuration Guides and Command References
Configuration Guide and Command Reference Titles Features/Protocols/Technologies

• Cisco ASR 1000 Series Aggregation Services Routers Configuration and troubleshooting of SPA interface processors
SIP and SPA Software Configuration Guide (SIPs) and shared port adapters (SPAs) that are supported on the
Cisco ASR 1000 Series Router.
• Cisco ASR 1000 Series Aggregation Services Routers Overview of software functionality that is specific to the
Software Configuration Guide Cisco ASR 1000 Series Aggregation Services Routers.
• Cisco IOS XE Access Node Control Protocol Communication protocol between digital subscriber line access
Configuration Guide multiplexers (DSLAMs) and a broadband remote access server
• Cisco IOS Access Node Control Protocol (BRAS).
Command Reference
• Cisco IOS XE Asynchronous Transfer Mode LAN ATM, multiprotocol over ATM (MPoA), and WAN ATM.
Configuration Guide
• Cisco IOS Asynchronous Transfer Mode
Command Reference
• Cisco IOS XE Broadband Access Aggregation and DSL PPP over Ethernet (PPPoE).
Configuration Guide
• Cisco IOS Broadband Access Aggregation and DSL
Command Reference
• Cisco IOS XE Carrier Ethernet Configuration Guide IEEE 802.3ad Link Bundling; Link Aggregation Control
Protocol (LACP) support for Ethernet and Gigabit Ethernet links
• Cisco IOS Carrier Ethernet Command Reference
and EtherChannel bundles; LACP support for stateful
switchover (SSO), in service software upgrade (ISSU), Cisco
nonstop forwarding (NSF), and nonstop routing (NSR) on
Gigabit EtherChannel bundles; and IEEE 802.3ad Link
Aggregation MIB.
• Cisco IOS XE Configuration Fundamentals Autoinstall, Setup, Cisco IOS command-line interface (CLI),
Configuration Guide Cisco IOS file system (IFS), Cisco IOS web browser user
• Cisco IOS Configuration Fundamentals interface (UI), basic file transfer services, and file management.
Command Reference
v
Table 1 Cisco IOS XE Configuration Guides and Command References (continued)

• Cisco IOS XE DECnet Configuration Guide DECnet protocol.
• Cisco IOS DECnet Command Reference
• Cisco IOS XE Dial Technologies Configuration Guide Asynchronous communications, dial backup, dialer technology,
Multilink PPP (MLP), PPP, and virtual private dialup network
• Cisco IOS Dial Technologies Command Reference
(VPDN).
• Cisco IOS XE High Availability Configuration Guide A variety of high availability (HA) features and technologies
that are available for different network segments (from
• Cisco IOS High Availability Command Reference
enterprise access to service provider core) to facilitate creation
of end-to-end highly available networks. Cisco IOS HA features
and technologies can be categorized in three key areas:
system-level resiliency, network-level resiliency, and embedded
management for resiliency.
• Cisco IOS XE Intelligent Services Gateway Subscriber identification, service and policy determination,
Configuration Guide session creation, session policy enforcement, session life-cycle
• Cisco IOS Intelligent Services Gateway management, accounting for access and service usage, and
Command Reference session state monitoring.
• Cisco IOS XE Interface and Hardware Component LAN interfaces, logical interfaces, serial interfaces, virtual
Configuration Guide interfaces, and interface configuration.
• Cisco IOS Interface and Hardware Component
Command Reference
• Cisco IOS XE IP Addressing Services IP addressing, Address Resolution Protocol (ARP), Network
Configuration Guide Address Translation (NAT), Domain Name System (DNS),
Dynamic Host Configuration Protocol (DHCP), and Next Hop
• Cisco IOS IP Addressing Services
Address Resolution Protocol (NHRP).
Command Reference
• Cisco IOS XE IP Application Services Enhanced Object Tracking (EOT), Gateway Load Balancing
Configuration Guide Protocol (GLBP), Hot Standby Router Protocol (HSRP), IP
• Cisco IOS IP Application Services Services, TCP, Web Cache Communication Protocol (WCCP),
Command Reference User Datagram Protocol (UDP), and Virtual Router Redundancy
Protocol (VRRP).
• Cisco IOS XE IP Multicast Configuration Guide Protocol Independent Multicast (PIM) sparse mode (PIM-SM),
bidirectional PIM (bidir-PIM), Source Specific Multicast
• Cisco IOS IP Multicast Command Reference
(SSM), Multicast Source Discovery Protocol (MSDP), Internet
Group Management Protocol (IGMP), and Multicast VPN
(MVPN).
• Cisco IOS XE IP Routing: BFD Configuration Guide Bidirectional forwarding detection (BFD).
• Cisco IOS XE IP Routing: BGP Configuration Guide Border Gateway Protocol (BGP), multiprotocol BGP,
• Cisco IOS IP Routing: BGP Command Reference multiprotocol BGP extensions for IP multicast.
• Cisco IOS XE IP Routing: EIGRP Enhanced Interior Gateway Routing Protocol (EIGRP).
Configuration Guide
• Cisco IOS IP Routing: EIGRP Command Reference
• Cisco IOS XE IP Routing: ISIS Configuration Guide Intermediate System-to-Intermediate System (IS-IS).
• Cisco IOS IP Routing: ISIS Command Reference
vi

• Cisco IOS XE IP Routing: ODR Configuration Guide On-Demand Routing (ODR).
• Cisco IOS IP Routing: ODR Command Reference
• Cisco IOS XE IP Routing: OSPF Configuration Guide Open Shortest Path First (OSPF).
• Cisco IOS IP Routing: OSPF Command Reference
• Cisco IOS XE IP Routing: Protocol-Independent IP routing protocol-independent features and commands.
Configuration Guide Generic policy-based routing (PBR) features and commands are
• Cisco IOS IP Routing: Protocol-Independent included.
Command Reference
• Cisco IOS XE IP Routing: RIP Configuration Guide Routing Information Protocol (RIP).
• Cisco IOS IP Routing: RIP Command Reference
• Cisco IOS XE IP SLAs Configuration Guide Cisco IOS IP Service Level Agreements (IP SLAs).
• Cisco IOS IP SLAs Command Reference
• Cisco IOS XE IP Switching Configuration Guide Cisco Express Forwarding.
• Cisco IOS IP Switching Command Reference
• Cisco IOS XE IPv6 Configuration Guide For a list of IPv6 features, protocols, and technologies, go to the
IPv6 “Start Here” document at the following URL:
• Cisco IOS IPv6 Command Reference
http://www.cisco.com/en/US/docs/ios/ios_xe/ipv6/configuratio
n/guide/ip6-roadmap_xe.html
• Cisco IOS XE ISO CLNS Configuration Guide ISO Connectionless Network Service (CLNS).
• Cisco IOS ISO CLNS Command Reference
• Cisco IOS XE LAN Switching Configuration Guide VLANs and multilayer switching (MLS).
• Cisco IOS LAN Switching Command Reference
• Cisco IOS XE Multiprotocol Label Switching MPLS Label Distribution Protocol (LDP), MPLS Layer 2 VPNs,
Configuration Guide MPLS Layer 3 VPNs, MPLS Traffic Engineering (TE), and
• Cisco IOS Multiprotocol Label Switching MPLS Embedded Management (EM) and MIBs.
Command Reference
• Cisco IOS XE NetFlow Configuration Guide Network traffic data analysis, aggregation caches, and export
features.
• Cisco IOS NetFlow Command Reference
• Cisco IOS XE Network Management Basic system management, system monitoring and logging,
Configuration Guide Cisco IOS Scripting with Tool Control Language (Tcl),
Cisco networking services (CNS), Embedded Event Manager
• Cisco IOS Network Management Command Reference
(EEM), Embedded Syslog Manager (ESM), HTTP, Remote
Monitoring (RMON), and SNMP.
• Cisco IOS XE Novell IPX Configuration Guide Novell Internetwork Packet Exchange (IPX) protocol.
• Cisco IOS Novell IPX Command Reference
vii

• Cisco IOS XE Quality of Service Solutions Class-based weighted fair queueing (CBWFQ), low latency
Configuration Guide queueing (LLQ), Modular Quality of Service (QoS)
Command-Line Interface (CLI) (MQC), Network-Based
• Cisco IOS Quality of Service Solutions
Application Recognition (NBAR), priority queueing, Multilink
Command Reference
PPP (MLP) for QoS, header compression, Resource Reservation
Protocol (RSVP), weighted fair queueing (WFQ), and weighted
random early detection (WRED).
• Cisco IOS Security Command Reference Access control lists (ACLs); authentication, authorization, and
accounting (AAA); firewalls; IP security and encryption;
neighbor router authentication; network access security; public
key infrastructure (PKI); RADIUS; and TACACS+.
• Cisco IOS XE Security Configuration Guide: Secure Internet Key Exchange (IKE) for IPsec VPNs; security for VPNs
Connectivity with IPsec; VPN availability features (reverse route injection,
IPsec preferred peer, and real-time resolution for the IPsec
tunnel peer); IPsec data plane features; IPsec management plane
features; Public Key Infrastructure (PKI); Dynamic Multipoint
VPN (DMVPN); Easy VPN; and Cisco Group Encrypted
Transport VPN (GET VPN).
• Cisco IOS XE Security Configuration Guide: Securing Access Control Lists (ACLs); Firewalls: Context-Based Access
the Data Plane Control (CBAC) and Zone-Based Firewall; Cisco IOS Intrusion
Prevention System (IPS); Flexible Packet Matching; Unicast
Reverse Path Forwarding (uRPF); Threat Information
Distribution Protocol (TIDP) and TMS.
• Cisco IOS XE Security Configuration Guide: Securing AAA (includes Network Admission Control [NAC]); Security
User Services Server Protocols (RADIUS and TACACS+); Secure Shell
(SSH); Secure Access for Networking Devices (includes
Autosecure and Role-Based CLI access); Lawful Intercept.
• Cisco IOS XE Service Advertisement Framework Cisco Service Advertisement Framework.
Configuration Guide
• Cisco IOS Service Advertisement Framework
Command Reference
• Cisco IOS XE VPDN Configuration Guide Multihop by Dialed Number Identification Service (DNIS),
timer and retry enhancements for L2TP and Layer 2 Forwarding
• Cisco IOS VPDN Command Reference
(L2F), RADIUS Attribute 82 (tunnel assignment ID),
shell-based authentication of VPDN users, and tunnel
authentication via RADIUS on tunnel terminator.
• Cisco IOS XE Wide-Area Networking Frame Relay; L2VPN Pseudowire Redundancy; and
Configuration Guide Media-Independent PPP and Multilink PPP.
• Cisco IOS Wide-Area Networking
Command Reference
viii

• Cisco Unified Border Element (Enterprise) The Cisco Unified Border Element (Enterprise) on the
Configuration Guide Cisco ASR 1000 brings a scalable option for enterprise
customers. Running as a process on the Cisco ASR 1000 and
• Cisco IOS Voice Command Reference
utilizing the high-speed RTP packet processing path, the Cisco
Unified Border Element (Enterprise) is used as an IP-to-IP
gateway by enterprises and commercial customers to
interconnect SIP and H.323 voice and video networks. The
Cisco UBE (Enterprise) provides a network-to-network
demarcation interface for signaling interworking, media
interworking, address and port translations, billing, security,
quality of service (QoS), and bandwidth management.
• Cisco Unified Border Element (SP Edition) The Cisco Unified Border Element (SP Edition) is a session
Configuration Guide: Distributed Model border controller (SBC) that is VoIP-enabled and deployed at the
edge of networks. For Cisco IOS XE Release 2.3 and earlier
• Cisco Unified Border Element (SP Edition)
releases, Cisco Unified Border Element (SP Edition) is
Command Reference: Distributed Model
supported only in the distributed mode. Operating in the
distributed mode, the SBC is a toolkit of functions that can be
used to deploy and manage VoIP services, such as signaling
interworking, network hiding, security, and quality of service.
• Cisco Unified Border Element (SP Edition) The Cisco Unified Border Element (SP Edition) is a highly
Configuration Guide: Unified Model scalable, carrier-grade session border controller (SBC) that is
designed for service providers and that is generally deployed at
• Cisco Unified Border Element (SP Edition)
the border of the enterprise or SP networks to enable the easy
Command Reference: Unified Model
deployment and management of VoIP services. Cisco Unified
Border Element (SP Edition) is integrated into Cisco routing
platforms and can use a large number of router functions to
provide a very feature-rich and intelligent SBC application.
Formerly known as Integrated Session Border Controller,
Cisco Unified Border Element (SP Edition) provides a
network-to-network demarcation interface for signaling
interworking, media interworking, address and port translations,
billing, security, quality of service, call admission control, and
bandwidth management.
For Cisco IOS XE Release 2.4 and later releases, Cisco Unified
Border Element (SP Edition) can operate in two modes or
deployment models: unified and distributed. The configuration
guide documents the features in the unified mode.
Table 2 lists documents and resources that supplement the Cisco IOS XE software configuration guides
and command references.
ix
Additional Resources and Documentation Feedback
Table 2 Cisco IOS XE Software Supplementary Documents and Resources
Document Title or Resource Description

Cisco IOS Master Command List, All Releases Alphabetical list of all the commands documented in all
Cisco IOS XE software releases.
Cisco IOS Debug Command Reference Alphabetical list of debug commands including brief
descriptions of use, command syntax, and usage guidelines.
Cisco IOS XE system messages List of Cisco IOS XE system messages and descriptions. System
messages may indicate problems with your system, may be
informational only, or may help diagnose problems with
communications lines, internal hardware, or the system
software.
Release notes and caveats Information about new and changed features, system
requirements, and other useful information about specific
software releases; information about defects in specific
Cisco IOS XE software releases.
MIBs Files used for network monitoring. To locate and download
MIBs for selected platforms, Cisco IOS XE software releases,
and feature sets, use Cisco MIB Locator at the following URL:
http://www.cisco.com/go/mibs
RFCs Standards documents maintained by the Internet Engineering
Task Force (IETF) that Cisco IOS XE documentation references
where applicable. The full text of referenced RFCs may be
obtained at the following URL:
http://www.rfc-editor.org/

What’s New in Cisco Product Documentation is updated monthly and describes all new and revised
Cisco technical documentation. The What’s New in Cisco Product Documentation publication also
provides information about obtaining the following resources:
• Technical documentation
• Cisco product security overview
• Product alerts and field notices
• Technical assistance
Cisco IOS XE software technical documentation includes embedded feedback forms where you can rate
documents and provide suggestions for improvement. Your feedback helps us improve our
documentation.
x
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Nurse Connect, Cisco Pulse, Cisco SensorBase,
Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good,
Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network are trademarks;
Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store, Flip Gift Card,
and One Million Acts of Green are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA,
CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Lumin, Cisco Nexus,
Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast,
EtherSwitch, Event Center, Explorer, Follow Me Browsing, GainMaker, iLYNX, IOS, iPhone, IronPort, the IronPort logo, Laser Link, LightStream,
Linksys, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, PCNow, PIX, PowerKEY, PowerPanels, PowerTV,
PowerTV (Design), PowerVu, Prisma, ProConnect, ROSA, SenderBase, SMARTnet, Spectrum Expert, StackWise, WebEx, and the WebEx logo are
registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or website 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. (0910R)
Any Internet Protocol (IP) addresses and phone numbers used in this document are not intended to be actual addresses and phone numbers. Any
examples, command display output, network topology diagrams, and other figures included in the document are shown for illustrative purposes only.
Any use of actual IP addresses or phone numbers in illustrative content is unintentional and coincidental.
xi
xii
Using the Command-Line Interface in
Cisco IOS XE Software
This document provides basic information about the command-line interface (CLI) in Cisco IOS XE
software and how you can use some of the CLI features. This document contains the following sections:
• Initially Configuring a Device, page i
• Using the CLI, page ii
• Saving Changes to a Configuration, page xii
• Additional Information, page xii
For more information about using the CLI, see “Part 1: Using the Cisco IOS Command-Line Interface
(CLI)” of the Cisco IOS XE Configuration Fundamentals Configuration Guide.
For information about the software documentation set, see the “About Cisco IOS XE Software
Documentation” document.
Initially Configuring a Device

Initially configuring a device varies by platform. For information about performing an initial
configuration, see the hardware installation documentation that is provided with the original packaging
of the product or go to the Product Support area of Cisco.com at http://www.cisco.com/go/techdocs.
After you have performed the initial configuration and connected the device to your network, you can
configure the device by using the console port or a remote access method, such as Telnet or Secure Shell
(SSH), to access the CLI or by using the configuration method provided on the device, such as Security
Device Manager.
i
Using the Command-Line Interface in Cisco IOS XE Software
Using the CLI
Changing the Default Settings for a Console or AUX Port

There are only two settings that you can change on a console port or an AUX port:
• Change the port speed with the config-register 0x command. Changing the port speed is not
recommended. The well-known default speed is 9600.
• Change the behavior of the port; for example, by adding a password or changing the timeout value.
Note The AUX port on the Route Processor (RP) installed in a Cisco ASR 1000 series router does not serve
any useful customer purpose and should be accessed only under the advisement of a customer support
representative.
Using the CLI

This section describes the following topics:
• Understanding Command Modes, page ii
• Using the Interactive Help Feature, page v
• Understanding Command Syntax, page vi
• Understanding Enable and Enable Secret Passwords, page viii
• Using the Command History Feature, page viii
• Abbreviating Commands, page ix
• Using Aliases for CLI Commands, page ix
• Using the no and default Forms of Commands, page x
• Using the debug Command, page x
• Filtering Output Using Output Modifiers, page xi
• Understanding CLI Error Messages, page xi
Understanding Command Modes

The CLI command mode structure is hierarchical, and each mode supports a set of specific commands.
This section describes the most common of the many modes that exist.
Table 1 lists common command modes with associated CLI prompts, access and exit methods, and a
brief description of how each mode is used.
ii
Using the CLI
Table 1 CLI Command Modes
Command Access Method Prompt Exit Method Mode Usage

Mode
User EXEC Log in. Router> Issue the logout or exit • Change terminal settings.
command. • Perform basic tests.
• Display device status.
Privileged From user EXEC mode, Router# Issue the disable • Issue show and debug
EXEC issue the enable command or the exit commands.
command. command to return to • Copy images to the
user EXEC mode. device.
• Reload the device.
• Manage device
configuration files.
• Manage device file
systems.
Global From privileged EXEC Router(config)# Issue the exit command Configure the device.
configuration mode, issue the or the end command to
configure terminal return to privileged
command. EXEC mode.
Interface From global Router(config-if)# Issue the exit command Configure individual
configuration configuration mode, to return to global interfaces.
issue the interface configuration mode or
command. the end command to
return to privileged
EXEC mode.
Line From global Router(config-line)# Issue the exit command Configure individual terminal
configuration configuration mode, to return to global lines.
issue the line vty or line configuration mode or
console command. the end command to
return to privileged
EXEC mode.
iii
Using the CLI
Table 1 CLI Command Modes (continued)
Command Access Method Prompt Exit Method Mode Usage

Mode
ROM monitor From privileged EXEC rommon # > Issue the continue • Run as the default
mode, issue the reload command. operating mode when a
command. Press the The # symbol valid image cannot be
Break key during the represents the line loaded.
first 60 seconds while number and increments
at each prompt. • Access the fall-back
the system is booting.
procedure for loading an
image when the device
lacks a valid image and
cannot be booted.
• Perform password
recovery when a
CTRL-Break sequence is
issued within 60 seconds
of a power-on or reload
event.
Diagnostic The router boots or Router(diag)# If a Cisco IOS XE • Inspect various states on
enters diagnostic mode process failure is the the router, including the
in the following reason for entering Cisco IOS XE state.
scenarios. When a diagnostic mode, the • Replace or roll back the
Cisco IOS XE process failure must be resolved configuration.
or processes fail, in and the router must be
most scenarios the rebooted to exit • Provide methods of
router will reload. diagnostic mode. restarting the
Cisco IOS XE software or
• A user-configured If the router is in
other processes.
access policy was diagnostic mode
configured using because of a • Reboot hardware, such as
the transport-map transport-map the entire router, an RP, an
command, which configuration, access ESP, a SIP, a SPA, or other
directed the user the router through hardware components.
into diagnostic another port or use a • Transfer files into or off
mode. method that is of the router using remote
• The router was configured to connect to access methods such as
accessed using an the Cisco IOS XE CLI. FTP, TFTP, and SCP.
RP auxiliary port. If the RP auxiliary port
• A break signal was used to access the
(Ctrl-C, router, use another port
Ctrl-Shift-6, or the for access. Accessing
send break the router through the
command) was auxiliary port is not
entered, and the useful for customer
router was purposes.
configured to enter
diagnostic mode
when the break
signal was received.
iv
Using the CLI
EXEC commands are not saved when the software reboots. Commands that you issue in a configuration
mode can be saved to the startup configuration. If you save the running configuration to the startup
configuration, these commands will execute when the software is rebooted. Global configuration mode
is the highest level of configuration mode. From global configuration mode, you can enter a variety of
other configuration modes, including protocol-specific modes.
ROM monitor mode is a separate mode that is used when the software cannot load properly. If a valid
software image is not found when the software boots or if the configuration file is corrupted at startup,
the software might enter ROM monitor mode. Use the question symbol (?) to view the commands that
you can use while the device is in ROM monitor mode.
rommon 1 > ?
alias set and display aliases command
boot boot up an external process
confreg configuration register utility
cont continue executing a downloaded image
context display the context of a loaded image
cookie display contents of cookie PROM in hex
.
.
.
rommon 2 >
The following example shows how the command prompt changes to indicate a different command mode:
Router> enable
Router# configure terminal
Router(config)# interface ethernet 1/1
Router(config-if)# ethernet
Router(config-line)# exit
Router(config)# end
Router#
Note A keyboard alternative to the end command is Ctrl-Z.
Using the Interactive Help Feature

The CLI includes an interactive Help feature. Table 2 describes how to use the Help feature.
Table 2 CLI Interactive Help Commands
Command Purpose
help Provides a brief description of the Help feature in any command mode.
? Lists all commands available for a particular command mode.
partial command? Provides a list of commands that begin with the character string (no
space between the command and the question mark).
partial command<Tab> Completes a partial command name (no space between the command
and <Tab>).
command ? Lists the keywords, arguments, or both associated with the command
(space between the command and the question mark).
command keyword ? Lists the arguments that are associated with the keyword (space between
the keyword and the question mark).
v
Using the CLI
The following examples show how to use the help commands:
help
Router> help
Help may be requested at any point in a command by entering a question mark '?'. If nothing
matches, the help list will be empty and you must backup until entering a '?' shows the
available options.
Two styles of help are provided:
1. Full help is available when you are ready to enter a command argument (e.g. 'show ?')
and describes each possible argument.
2. Partial help is provided when an abbreviated argument is entered and you want to know
what arguments match the input (e.g. 'show pr?'.)
?
Router# ?
Exec commands:
access-enable Create a temporary access-List entry
access-profile Apply user-profile to interface
access-template Create a temporary access-List entry
alps ALPS exec commands
archive manage archive files
<snip>
partial command?
Router(config)# zo?
zone zone-pair
partial command<Tab>
Router(config)# we<Tab> webvpn
command ?
Router(config-if)# pppoe ?
enable Enable pppoe
max-sessions Maximum PPPOE sessions
command keyword ?
Router(config-if)# pppoe enable ?
group attach a BBA group
<cr>
Understanding Command Syntax

Command syntax is the format in which a command should be entered in the CLI. Commands include
the name of the command, keywords, and arguments. Keywords are alphanumeric strings that are used
literally. Arguments are placeholders for values that a user must supply. Keywords and arguments may
be required or optional.
Specific conventions convey information about syntax and command elements. Table 3 describes these
conventions.
vi
Using the CLI
Table 3 CLI Syntax Conventions
Symbol/Text Function Notes

< > (angle brackets) Indicate that the option is an Sometimes arguments are displayed
argument. without angle brackets.
A.B.C.D. Indicates that you must enter a Angle brackets (< >) are not always
dotted decimal IP address. used to indicate that an IP address is
an argument.
WORD (all capital letters) Indicates that you must enter Angle brackets (< >) are not always
one word. used to indicate that a WORD is an
argument.
LINE (all capital letters) Indicates that you must enter Angle brackets (< >) are not always
more than one word. used to indicate that a LINE is an
argument.
<cr> (carriage return) Indicates the end of the list of —
available keywords and
arguments, and also indicates
when keywords and arguments
are optional. When <cr> is the
only option, you have reached
the end of the branch or the end
of the command if the command
has only one branch.
The following examples show syntax conventions:

Router(config)# ethernet cfm domain ?
WORD domain name
Router(config)# ethernet cfm domain dname ?

level
Router(config)# ethernet cfm domain dname level ?

<0-7> maintenance level number
Router(config)# ethernet cfm domain dname level 7 ?

<cr>
Router(config)# snmp-server file-transfer access-group 10 ?

protocol protocol options
<cr>
Router(config)# logging host ?

Hostname or A.B.C.D IP address of the syslog server
ipv6 Configure IPv6 syslog server
vii
Using the CLI
Understanding Enable and Enable Secret Passwords

Some privileged EXEC commands are used for actions that impact the system, and it is recommended
that you set a password for these commands to prevent unauthorized use. Two types of passwords, enable
(not encrypted) and enable secret (encrypted), can be set. The following commands set these passwords
and are issued in global configuration mode:
• enable password
• enable secret password
Using an enable secret password is recommended because it is encrypted and more secure than the
enable password. When you use an enable secret password, text is encrypted (unreadable) before it is
written to the config.text file. When you use an enable password, the text is written as entered (readable)
to the config.text file.
Each type of password is case sensitive, can contain from 1 to 25 uppercase and lowercase alphanumeric
characters, and can start with a number. Spaces are also valid password characters; for example,
“two words” is a valid password. Leading spaces are ignored, but trailing spaces are recognized.
Note Both password commands have numeric keywords that are single integer values. If you choose a number
for the first character of your password followed by a space, the system will read the number as if it were
the numeric keyword and not as part of your password.
When both passwords are set, the enable secret password takes precedence over the enable password.
To remove a password, use the no form of the commands: no enable password or
no enable secret password.
For more information about password recovery procedures for Cisco products, see
http://www.cisco.com/en/US/products/sw/iosswrel/ps1831/
products_tech_note09186a00801746e6.shtml.
Using the Command History Feature

The command history feature saves the commands that you enter during a session in a command history
buffer. The default number of commands saved is 10, but the number is configurable within the range of
0 to 256. This command history feature is particularly useful for recalling long or complex commands.
To change the number of commands saved in the history buffer for a terminal session, issue the
terminal history size command:
Router# terminal history size num
A command history buffer is also available in line configuration mode with the same default and
configuration options. To set the command history buffer size for a terminal session in line configuration
mode, issue the history command:
Router(config-line)# history [size num]
viii
Using the CLI
To recall commands from the history buffer, use the following methods:
• Press Ctrl-P or the Up Arrow key—Recalls commands beginning with the most recent command.
Repeat the key sequence to recall successively older commands.
• Press Ctrl-N or the Down Arrow key—Recalls the most recent commands in the history buffer after
they have been recalled using Ctrl-P or the Up Arrow key. Repeat the key sequence to recall
successively more recent commands.
Note The arrow keys function only on ANSI-compatible terminals such as the VT100.
• Issue the show history command in user EXEC or privileged EXEC mode—Lists the most recent
commands that you entered. The number of commands that are displayed is determined by the
setting of the terminal history size and history commands.
The command history feature is enabled by default. To disable this feature for a terminal session,
issue the terminal no history command in user EXEC or privileged EXEC mode or the no history
command in line configuration mode.
Abbreviating Commands
Typing a complete command name is not always required for the command to execute. The CLI
recognizes an abbreviated command when the abbreviation contains enough characters to uniquely
identify the command. For example, the show version command can be abbreviated as sh ver. It cannot
be abbreviated as s ver because s could mean show, set, or systat. The sh v abbreviation also is not valid
because the show command has vrrp as a keyword in addition to version.
Using Aliases for CLI Commands

To save time and the repetition of entering the same command multiple times, you can use a command
alias. An alias can be configured to do anything that can be done at the command line, but an alias cannot
move between modes, type in passwords, or perform any interactive functions.
Table 4 shows the default command aliases.
Table 4 Default Command Aliases
Command Alias Original Command

h help
lo logout
p ping
s show
u or un undebug
w where
ix
Using the CLI
To create a command alias, issue the alias command in global configuration mode. The syntax of the
command is alias mode command-alias original-command. Following are some examples:
• Router(config)# alias exec prt partition—privileged EXEC mode
• Router(config)# alias configure sb source-bridge—global configuration mode
• Router(config)# alias interface rl rate-limit—interface configuration mode
To view both default and user-created aliases, issue the show alias command.
For more information about the alias command, see
http://www.cisco.com/en/US/docs/ios/fundamentals/command/reference/cf_book.html.
Using the no and default Forms of Commands

Most configuration commands have a no form that is used to reset a command to its default value or
disable a feature or function. For example, the ip routing command is enabled by default. To disable this
command, you would issue the no ip routing command. To re-enable IP routing, you would issue the
ip routing command.
Configuration commands may also have a default form, which returns the command settings to their
default values. For commands that are disabled by default, using the default form has the same effect as
using the no form of the command. For commands that are enabled by default and have default settings,
the default form enables the command and returns the settings to their default values.
The no form is documented in the command pages of command references. The default form is
generally documented in the command pages only when the default form performs a different function
than the plain and no forms of the command. To see what default commands are available on your
system, enter default ? in the appropriate command mode.
Using the debug Command

A debug command produces extensive output that helps you troubleshoot problems in your network.
These commands are available for many features and functions within Cisco IOS XE software. Some
debug commands are debug all, debug aaa accounting, and debug mpls packets. To use debug
commands during a Telnet session with a device, you must first enter the terminal monitor command.
To turn off debugging completely, you must enter the undebug all command.
For more information about debug commands, see the Cisco IOS Debug Command Reference at
http://www.cisco.com/en/US/docs/ios/debug/command/reference/db_book.html.
Caution Debugging is a high priority and high CPU utilization process that can render your device unusable. Use
debug commands only to troubleshoot specific problems. The best times to run debugging are during
periods of low network traffic and when few users are interacting with the network. Debugging during
these periods decreases the likelihood that the debug command processing overhead will affect network
performance or user access or response times.
x
Using the CLI
Filtering Output Using Output Modifiers

Many commands produce lengthy output that may use several screens to display. You can use output
modifiers to filter this output to show only the information that you want to see.
The following three output modifiers are available:
• begin regular-expression—Displays the first line in which a match of the regular expression is found
and all lines that follow.
• include regular-expression—Displays all lines in which a match of the regular expression is found.
• exclude regular-expression—Displays all lines except those in which a match of the regular
expression is found.
To use one of these output modifiers, type the command followed by the pipe symbol (|), the modifier,
and the regular expression that you want to search for or filter. A regular expression is a case-sensitive
alphanumeric pattern. It can be a single character or number, a phrase, or a more complex string.
The following example illustrates how to filter output of the show interface command to display only
lines that include the expression “protocol.”
Router# show interface | include protocol
FastEthernet0/0 is up, line protocol is up

Serial4/0 is up, line protocol is up
Serial4/1 is up, line protocol is up
Serial4/2 is administratively down, line protocol is down
Serial4/3 is administratively down, line protocol is down
Understanding CLI Error Messages

You may encounter some error messages while using the CLI. Table 5 shows the common CLI error
messages.
Table 5 Common CLI Error Messages
Error Message Meaning How to Get Help

% Ambiguous command: You did not enter enough Reenter the command followed by a
“show con” characters for the command to space and a question mark (?). The
be recognized. keywords that you are allowed to
enter for the command appear.
% Incomplete command. You did not enter all the Reenter the command followed by a
keywords or values required space and a question mark (?). The
by the command. keywords that you are allowed to
enter for the command appear.
% Invalid input detected at “^” You entered the command Enter a question mark (?) to display
marker. incorrectly. The caret (^) all the commands that are available in
marks the point of the error. this command mode. The keywords
that you are allowed to enter for the
command appear.
For more system error messages, see the System Messages for Cisco IOS XE document.
xi
Saving Changes to a Configuration
Saving Changes to a Configuration

To save changes that you made to the configuration of a device, you must issue the copy running-config
startup-config command or the copy system:running-config nvram:startup-config command. When
you issue these commands, the configuration changes that you made are saved to the startup
configuration and saved when the software reloads or power to the device is turned off or interrupted.
The following example shows the syntax of the copy running-config startup-config command:
Router# copy running-config startup-config
Destination filename [startup-config]?
You press Enter to accept the startup-config filename (the default), or type a new filename and then press
Enter to accept that name. The following output is displayed indicating that the configuration was saved:
Building configuration...
[OK]
Router#
On most platforms, the configuration is saved to NVRAM. On platforms with a Class A flash file system,
the configuration is saved to the location specified by the CONFIG_FILE environment variable. The
CONFIG_FILE variable defaults to NVRAM.
Additional Information
• “Part 1: Using the Cisco IOS Command-Line Interface (CLI)” of the Cisco IOS XE Configuration
Fundamentals Configuration Guide
http://www.cisco.com/en/US/docs/ios/ios_xe/fundamentals/configuration/guide/2_xe/cf_xe_book.
html
or
“Using Cisco IOS XE Software” chapter of the Cisco ASR 1000 Series Aggregation Services Routers
Software Configuration Guide
http://www.cisco.com/en/US/docs/routers/asr1000/configuration/guide/chassis/Using_CLI.html
• Cisco Product Support Resources
http://www.cisco.com/go/techdocs
• Support area on Cisco.com (also search for documentation by task or product)
http://www.cisco.com/en/US/support/index.html
• Software Download Center (downloads; tools; licensing, registration, advisory, and general
information) (requires Cisco.com user ID and password)
http://www.cisco.com/kobayashi/sw-center/
• Error Message Decoder, a tool to help you research and resolve error messages for
Cisco IOS XE software
http://www.cisco.com/pcgi-bin/Support/Errordecoder/index.cgi
xii
• Command Lookup Tool, a tool to help you find detailed descriptions of Cisco IOS XE commands
(requires Cisco.com user ID and password)
http://tools.cisco.com/Support/CLILookup
• Output Interpreter, a troubleshooting tool that analyzes command output of supported
show commands
https://www.cisco.com/pcgi-bin/Support/OutputInterpreter/home.pl\
xiii
xiv
Basic MPLS
Multiprotocol Label Switching (MPLS) on Cisco
Routers
First Published: June 27, 2000

Last Updated: May 4, 2009
This document describes commands for configuring and monitoring Multiprotocol Label Switching
(MPLS) functionality on Cisco routers and switches. This document is a companion to other feature
modules describing other MPLS applications.
Finding Feature Information

For the latest feature information and caveats, see the release notes for your platform and software
release. To find information about the features documented in this module, and to see a list of the releases in
which each feature is supported, see the “Feature Information for MPLS on Cisco Routers” section on page 6.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS XE software
image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on
Cisco.com is not required.
Contents
This document includes the following sections:
• Feature Overview, page 2
• Supported Standards, MIBs, and RFCs, page 4
• Configuration Tasks, page 4
• Feature Information for MPLS on Cisco Routers, page 6
• Glossary, page 7
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Multiprotocol Label Switching (MPLS) on Cisco Routers
Feature Overview
Feature Overview
Multiprotocol label switching (MPLS) combines the performance and capabilities of Layer 2 (data link
layer) switching with the proven scalability of Layer 3 (network layer) routing. MPLS enables service
providers to meet the challenges of explosive growth in network utilization while providing the
opportunity to differentiate services without sacrificing the existing network infrastructure. The MPLS
architecture is flexible and can be employed in any combination of Layer 2 technologies. MPLS support
is offered for all Layer 3 protocols, and scaling is possible well beyond that typically offered in today’s
networks.
MPLS efficiently enables the delivery of IP services over an ATM switched network. MPLS supports the
creation of different routes between a source and a destination on a purely router-based Internet
backbone. By incorporating MPLS into their network architecture, service providers can save money,
increase revenue and productivity, provide differentiated services, and gain competitive advantages.
Functional Description of MPLS

Label switching is a high-performance packet forwarding technology that integrates the performance
and traffic management capabilities of data link layer (Layer 2) switching with the scalability, flexibility,
and performance of network layer (Layer 3) routing.
Label Switching Functions

In conventional Layer 3 forwarding mechanisms, as a packet traverses the network, each router extracts
all the information relevant to forwarding the packet from the Layer 3 header. This information is then
used as an index for a routing table lookup to determine the next hop for the packet.
In the most common case, the only relevant field in the header is the destination address field, but in
some cases, other header fields might also be relevant. As a result, the header analysis must be done
independently at each router through which the packet passes. In addition, a complicated table lookup
must also be done at each router.
In label switching, the analysis of the Layer 3 header is done only once. The Layer 3 header is then
mapped into a fixed length, unstructured value called a label.
Many different headers can map to the same label, as long as those headers always result in the same
choice of next hop. In effect, a label represents a forwarding equivalence class—that is, a set of packets
which, however different they may be, are indistinguishable by the forwarding function.
The initial choice of a label need not be based exclusively on the contents of the Layer 3 packet header;
for example, forwarding decisions at subsequent hops can also be based on routing policy.
Once a label is assigned, a short label header is added at the front of the Layer 3 packet. This header is
carried across the network as part of the packet. At subsequent hops through each MPLS router in the
network, labels are swapped and forwarding decisions are made by means of MPLS forwarding table
lookup for the label carried in the packet header. Hence, the packet header does not need to be
reevaluated during packet transit through the network. Because the label is of fixed length and
unstructured, the MPLS forwarding table lookup process is both straightforward and fast.
2
Feature Overview
Distribution of Label Bindings

Each label switching router (LSR) in the network makes an independent, local decision as to which label
value to use to represent a forwarding equivalence class. This association is known as a label binding.
Each LSR informs its neighbors of the label bindings it has made. This awareness of label bindings by
neighboring routers is facilitated by the following protocols:
• Tag Distribution Protocol (TDP)—Used to support MPLS forwarding along normally routed paths
• Resource Reservation Protocol (RSVP)—Used to support MPLS traffic engineering
• Border Gateway Protocol (BGP)—Used to support MPLS virtual private networks (VPNs)
When a labeled packet is being sent from LSR A to the neighboring LSR B, the label value carried by
the IP packet is the label value that LSR B assigned to represent the forwarding equivalence class of the
packet. Thus, the label value changes as the IP packet traverses the network.
Benefits of MPLS
MPLS provides the following major benefits to service provider networks:
• Scalable support for Virtual Private Networks (VPNs)—MPLS enables VPN services to be
supported in service provider networks, thereby greatly accelerating Internet growth.
The use of MPLS for VPNs provides an attractive alternative to the building of VPNs by means of
either ATM or Frame Relay permanent virtual circuits (PVCs) or various forms of tunneling to
interconnect routers at customer sites.
Unlike the PVC VPN model, the MPLS VPN model is highly scalable and can accommodate
increasing numbers of sites and customers. The MPLS VPN model also supports “any-to-any”
communication among VPN sites without requiring a full mesh of PVCs or the backhauling
(suboptimal routing) of traffic across the service provider network. For each MPLS VPN user, the
service provider’s network appears to function as a private IP backbone over which the user can
reach other sites within the VPN organization, but not the sites of any other VPN organization.
From a user perspective, the MPLS VPN model enables network routing to be dramatically
simplified. For example, rather than having to manage routing over a topologically complex virtual
backbone composed of many PVCs, an MPLS VPN user can generally employ the service provider’s
backbone as the default route in communicating with all of the other VPN sites.
• Explicit routing capabilities (also called constraint-based routing or traffic engineering)—Explicit
routing employs “constraint-based routing,” in which the path for a traffic flow is the shortest path
that meets the resource requirements (constraints) of the traffic flow.
In MPLS traffic engineering, factors such as bandwidth requirements, media requirements, and the
priority of one traffic flow versus another can be taken into account. These traffic engineering
capabilities enable the administrator of a service provider network to
– Control traffic flow in the network
– Reduce congestion in the network
– Make best use of network resources
Thus, the network administrator can specify the amount of traffic expected to flow between various
points in the network (thereby establishing a traffic matrix), while relying on the routing system to
– Calculate the best paths for network traffic
– Set up the explicit paths to carry the traffic
3
Supported Standards, MIBs, and RFCs
• Support for IP routing on ATM switches (also called IP and ATM integration)—MPLS enables an
ATM switch to perform virtually all of the functions of an IP router. This capability of an ATM
switch stems from the fact that the MPLS forwarding paradigm, namely, label swapping, is exactly
the same as the forwarding paradigm provided by ATM switch hardware.
The key difference between a conventional ATM switch and an ATM label switch is the control
software used by the latter to establish its virtual channel identifier (VCI) table entries. An ATM
label switch uses IP routing protocols and the Tag Distribution Protocol (TDP) to establish VCI table
entries.
An ATM label switch can function as a conventional ATM switch. In this dual mode, the ATM switch
resources (such as VCI space and bandwidth) are partitioned between the MPLS control plane and
the ATM control plane. The MPLS control plane provides IP-based services, while the ATM control
plane supports ATM-oriented functions, such as circuit emulation or PVC services.
Restrictions
Label switching on a Cisco router requires that Cisco Express Forwarding be enabled on that router (see
the “Configuration Tasks” section below).

The supported standards, MIBs, and RFCs applicable to the MPLS applications appear in the respective
feature module for the application.
Configuration Tasks
This section explains how to configure a router for MPLS forwarding by enabling Cisco Express
Forwarding on the router.
Configuration tasks for other MPLS applications are described in the feature module documentation for
the application.
Configuring a Router for MPLS Forwarding

MPLS forwarding on Cisco routers requires that Cisco Express Forwarding be enabled. To enable Cisco
Express Forwarding on a router, issue the following commands:
Router(config)# ip cef distributed
Note Cisco Express Forwarding is enabled by default on a Cisco ASR 1000 Series Aggregation
Services Router and cannot be disabled.
For more information about Cisco Express Forwarding commands, see the Cisco IOS Switching
Command Reference.
4
Configuration Tasks
Verifying Configuration of MPLS Forwarding

To verify that Cisco Express Forwarding has been configured properly, issue the show ip cef summary
command, which generates output similar to that shown below:
Router# show ip cef summary
IP CEF with switching (Table Version 49), flags=0x0

43 routes, 0 resolve, 0 unresolved (0 old, 0 new)
43 leaves, 49 nodes, 56756 bytes, 45 inserts, 2 invalidations
2 load sharing elements, 672 bytes, 2 references
1 CEF resets, 4 revisions of existing leaves
4 in-place modifications
refcounts: 7241 leaf, 7218 node
Adjacency Table has 18 adjacencies

Router#
5
Feature Information for MPLS on Cisco Routers
Feature Information for MPLS on Cisco Routers

Table 1 lists the release history for this feature and provides links to specific configuration information.
Use Cisco Feature Navigator to find information about platform support and software image support.
Cisco Feature Navigator enables you to determine which Cisco IOS XE software images support a
specific software release, feature set, or platform. To access Cisco Feature Navigator, go to
http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Note Table 1 lists only the Cisco IOS XE software release that introduced support for a given feature in a given
Cisco IOS XE software release train. Unless noted otherwise, subsequent releases of that Cisco IOS
XE software release train also support that feature.
Table 1 Feature Information for MPLS on Cisco Routers
Feature Name Releases Feature Information

MPLS (Multiprotocol Label Cisco IOS XE Multiprotocol label switching (MPLS) combines the performance and
Switching) Release 2.1 capabilities of Layer 2 (data link layer) switching with the proven
scalability of Layer 3 (network layer) routing. MPLS enables service
providers to meet the challenges of explosive growth in network
utilization while providing the opportunity to differentiate services
without sacrificing the existing network infrastructure.
The following sections provide information about this feature:
The following commands were introduced or modified: interface
atm, mpls atm control-vc, mpls atm vpi, mpls ip (global
configuration), mpls ip (interface configuration), mpls ip
default-route, mpls ip propagate-ttl, mpls ip ttl-expiration pop,
mpls label range, mpls mtu, show mpls forwarding-table, show
mpls interfaces, show mpls label range, debug mpls adjacency,
debug mpls events, debug mpls lfib cef, debug mpls lfib enc, debug
mpls lfib lsp, debug mpls lfib state, debug mpls lfib struct, debug
mpls packets.
6
Glossary
Glossary
ATM edge LSR—A router that is connected to the ATM-LSR cloud through LC-ATM interfaces. The
ATM edge LSR adds labels to unlabeled packets and strips labels from labeled packets.
ATM-LSR—A label switch router with a number of LC-ATM interfaces. The router forwards the cells
among these interfaces using labels carried in the VPI/VCI field of the ATM cell header.
CoS—Class of service. A feature that provides scalable, differentiated types of service across an MPLS
network.
IP precedence—A 3-bit value in a ToS byte used for assigning precedence to IP packets.
label—A short fixed-length label that tells switching nodes how to forward data (packets or cells).
label-controlled ATM interface (LC-ATM interface)—An interface on a router or switch that uses
label distribution procedures to negotiate label VCs.
label edge router (LER)—A router that performs label imposition.
label imposition—The action of putting the first label on a packet.
label switch—A node that forwards units of data (packets or cells) on the basis of labels.
label switched path (LSP)—A sequence of hops (Router 0...Router n) in which a packet travels from
R0 to Rn by means of label switching mechanisms. A label switched path can be chosen dynamically,
based on normal routing mechanisms, or it can be configured manually.
label switched path (LSP) tunnel—A configured connection between two routers, in which label
switching techniques are used for packet forwarding.
label switching router (LSR)—A Layer 3 router that forwards a packet based on the value of a label
encapsulated in the packet.
label VC (LVC)—An ATM virtual circuit that is set up through ATM LSR label distribution procedures.
LFIB—Label Forwarding Information Base. The data structure used by switching functions to switch
labeled packets.
LIB—Label information base. A database used by an LSR to store labels learned from other LSRs, as
well as labels assigned by the local LSR.
MPLS—Multiprotocol label switching. An emerging industry standard that defines support for MPLS
forwarding of packets along normally routed paths (sometimes called MPLS hop-by-hop forwarding).
QoS—quality of service. A measure of performance for a transmission system that reflects its
transmission quality and service availability.
tailend—The downstream, received end of a tunnel.
TDP—Tag Distribution Protocol. The protocol used to distribute label bindings to LSRs.
traffic engineering—The techniques and processes used to cause routed traffic to travel through the
network on a path other than the one that could have been chosen if standard routing methods had been
applied.
traffic engineering tunnel—A label-switched tunnel that is used for traffic engineering. Such a tunnel
is set up through means other than normal Layer 3 routing; it is used to direct traffic over a path different
from the one that Layer 3 routing could cause the tunnel to take.
VPN—Virtual Private Network. Enables IP traffic to use tunneling to travel securely over a public
TCP/IP network.
CCDE, CCSI, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect, Cisco Stackpower,
Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work,
Live, Play, and Learn and Cisco Store are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA,
7
Glossary
CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems,
Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step,
Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream,
Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX,
PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient,
TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other
countries.
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and
figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and
coincidental.
© 2000–2009 Cisco Systems, Inc. All rights reserved.
8
MPLS Static Labels
First Published: October 2002

This document describes the Cisco MPLS Static Labels feature. The MPLS Static Labels feature
provides the means to configure statically:
• The binding between a label and an IPv4 prefix
• The contents of an LFIB crossconnect entry

which each feature is supported, see the “Feature Information for MPLS Static Labels” section on page 9.
Contents
• MPLS Static Labels Feature Overview, page 2
• Prerequisites, page 2
• Monitoring and Maintaining MPLS Static Labels, page 5
• Configuration Examples, page 5
• Additional References, page 7
• Feature Information for MPLS Static Labels, page 9
MPLS Static Labels
MPLS Static Labels Feature Overview
MPLS Static Labels Feature Overview

Generally, label switching routers (LSRs) dynamically learn the labels they should use to label-switch
packets by means of label distribution protocols that include:
• Label Distribution Protocol (LDP), the Internet Engineering Task Force (IETF) standard, used to
bind labels to network addresses
• Resource Reservation Protocol (RSVP) used to distribute labels for traffic engineering (TE)
• Border Gateway Protocol (BGP) used to distribute labels for Multiprotocol Label Switching
(MPLS) Virtual Private Networks (VPNs)
To use a learned label to label-switch packets, an LSR installs the label into its Label Forwarding
Information Base (LFIB).
The MPLS Static Labels feature provides the means to configure statically:
Benefits
Static Bindings Between Labels and IPv4 Prefixes
Static bindings between labels and IPv4 prefixes can be configured to support MPLS hop-by-hop
forwarding through neighbor routers that do not implement LDP label distribution.
Static Crossconnects
Static crossconnects can be configured to support MPLS Label Switched Path (LSP) midpoints when
neighbor routers do not implement either the LDP or RSVP label distribution, but do implement an
MPLS forwarding path.
Restrictions
• The trouble shooting process for MPLS static labels is complex.
• On a provider edge (PE) router for MPLS VPNs, there is no mechanism for statically binding a label
to a customer network prefix (VPN IPv4 prefix).
• MPLS static crossconnect labels remain in the LFIB even if the router to which the entry points goes
down.
• MPLS static crossconnect mappings remain in effect even with topology changes.
• MPLS static labels are not supported for label-controlled Asynchronous Transfer Mode (lc-atm).
• MPLS static bindings are not supported for local prefixes.
Prerequisites
The network must support the following Cisco IOS features before you enable MPLS static labels:
• Multiprotocol Label Switching (MPLS)
• Cisco Express Forwarding
2
MPLS Static Labels
Configuration Tasks
Configuration Tasks
See the following sections for the configuration tasks for the this feature:
• Configuring MPLS Static Prefix/Label Bindings, page 3 (required)
• Verifying MPLS Static Prefix/Label Bindings, page 3 (optional)
• Configuring MPLS Static Crossconnects, page 4 (required)
• Verifying MPLS Static Crossconnect Configuration, page 4 (optional)
Configuring MPLS Static Prefix/Label Bindings

To configure MPLS static prefix/label bindings, use the following commands beginning in global
configuration mode:
Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# mpls label range Specifies a range of labels for use with MPLS Static Labels
min-label max-label [static feature.
min-static-label max-static-label]
(Default is no labels reserved for static assignment.)
Step 3 Router(config)# mpls static binding ipv4 Specifies static binding of labels to IPv4 prefixes.
prefix mask [input | output nexthop]
label Bindings specified are installed automatically in the MPLS
forwarding table as routing demands.
Verifying MPLS Static Prefix/Label Bindings

To verify the configuration for MPLS static prefix/label bindings, use this procedure:
Step 1 Enter show mpls label range command. The output shows that the new label ranges do not take effect
until a reload occurs:
Router# show mpls label range
Downstream label pool: Min/Max label: 16/100000

[Configured range for next reload: Min/Max label: 200/100000]
Range for static labels: Min/Max/Number: 16/199
The following output from the show mpls label range command, executed after a reload, indicates that
the new label ranges are in effect:

Step 2 Enter the show mpls static binding ipv4 command to show the configured static prefix/label bindings:
Router# show mpls static binding ipv4
10.17.17.17/32: Incoming label: 251 (in LIB)
3
MPLS Static Labels
Configuration Tasks
Outgoing labels:
10.0.0.1 18
Outgoing labels:
10.0.0.1implicit-null
Step 3 Use the show mpls forwarding-table command to determine which static prefix/label bindings are
currently in use for MPLS forwarding.
Router# show mpls forwarding-table
Local Outgoing Prefix Bytes tag Outgoing Next Hop

tag tag or VC or Tunnel Id switched interface
201 Pop tag 10.18.18.18/32 0 PO1/1/0 point2point
2/35 10.18.18.18/32 0 AT4/1/0.1 point2point
251 18 10.17.17.17/32 0 PO1/1/0 point2point
Configuring MPLS Static Crossconnects

To configure MPLS static crossconnects, use the following command beginning in global configuration
mode:
Command Purpose
Step 1 Router# configure terminal Enters global configuration mode.
Step 2 Router(config)# mpls label range Specifies a range of labels for use with MPLS Static Labels
min-label max-label [static feature.
min-static-label max-static-label]
(Default is no labels reserved for static assignment.)
Step 3 Router(config)# mpls static binding ipv4 Specifies static binding of labels to IPv4 prefixes.
prefix mask [input | output nexthop]
label Bindings specified are installed automatically in the MPLS
Verifying MPLS Static Crossconnect Configuration

To verify the configuration for MPLS static crossconnects, use this procedure:
Step 1 Use the show mpls static crossconnect command to display information about crossconnects that have
been configured:
Router# show mpls static crossconnect
Local Outgoing Outgoing Next Hop

label label interface
34 22 pos3/0/0 point2point (in LFIB)
4
MPLS Static Labels
Monitoring and Maintaining MPLS Static Labels
Monitoring and Maintaining MPLS Static Labels

To monitor and maintain MPLS static labels, use one or more of the following commands:
Command Purpose
Router# show mpls forwarding-table Displays the contents of the MPLS LFIB.
Router# show mpls label range Displays information about the static label range.
Router# show mpls static binding ipv4 Displays information about the configured static prefix/label
bindings.
Router# show mpls static crossconnect Displays information about the configured crossconnects.
Configuration Examples
This section provides the following configuration examples for the MPLS Static Labels feature:
• Configuring MPLS Static Prefixes/Labels: Example, page 5
• Configuring MPLS Static Crossconnects: Example, page 6
Configuring MPLS Static Prefixes/Labels: Example

In the following output, the mpls label range command reconfigures the range used for dynamically
assigned labels from 16 to 100000 to 200 to 100000 and configures a static label range of 16 to 199.
Enter configuration commands, one per line. End with CNTL/Z.

Router(config)# mpls label range 200 100000 static 16 199
% Label range changes take effect at the next reload.

Router(config)# end
In the following output, the show mpls label range command indicates that the new label ranges do not
take effect until a reload occurs:

In the following output, the show mpls label range command, executed after a reload, indicates that the
new label ranges are in effect:

5
MPLS Static Labels
In the following output, the mpls static binding ipv4 commands configure static prefix/label bindings.
They also configure input (local) and output (remote) labels for various prefixes:

Router(config)# mpls static binding ipv4 10.0.0.0 255.0.0.0 55
Router(config)# mpls static binding ipv4 10.0.0.0 255.0.0.0 output 10.0.0.66 2607
Router(config)# mpls static binding ipv4 10.6.0.0 255.255.0.0 input 17
Router(config)# mpls static binding ipv4 10.0.0.0 255.0.0.0 output 10.13.0.8 explicit-null
Router(config)# end
In the following output, the show mpls static binding ipv4 command displays the configured static
prefix/label bindings:
10.0.0.0/8: Incoming label: none;

Outgoing labels:
10.13.0.8 explicit-null
Outgoing labels:
10.0.0.66 2607
Outgoing labels: None
Configuring MPLS Static Crossconnects: Example

In the following output, the mpls static crossconnect command configures a crossconnect from
incoming label 34 to outgoing label 22 out interface pos3/0/0:

Router(config)# mpls static crossconnect 34 pos3/0/0 22
Router(config)# end
In the following output, the show mpls static crossconnect command displays the configured
crossconnect:
Router# show mpls static crossconnect
Local Outgoing Outgoing Next Hop

label label interface
34 22 pos3/0/0 point2point (in LFIB)
6
MPLS Static Labels
Additional References
The following sections provide references related to the MPLS Static Labels feature.
Related Documents
Related Topic Document Title
MPLS commands Multiprotocol Label Switching Command Reference
Standards
Standard Title
No new or modified standards are supported by this —
feature, and support for existing standards has not been
modified by this feature.
MIBs
MIB MIBs Link
No new or modified MIBs are supported by this To locate and download MIBs for selected platforms, Cisco IOS XE
feature, and support for existing MIBs has not been software releases, and feature sets, use Cisco MIB Locator found at
modified by this feature. the following URL:
RFCs
RFC Title
No new or modified RFCs are supported by this —
feature, and support for existing RFCs has not been
7
MPLS Static Labels
Technical Assistance
Description Link
The Cisco Support website provides extensive online http://www.cisco.com/techsupport
resources, including documentation and tools for
troubleshooting and resolving technical issues with
Cisco products and technologies.
To receive security and technical information about
your products, you can subscribe to various services,
such as the Product Alert Tool (accessed from Field
Notices), the Cisco Technical Services Newsletter, and
Really Simple Syndication (RSS) Feeds.
Access to most tools on the Cisco Support website
requires a Cisco.com user ID and password.
8
MPLS Static Labels
Feature Information for MPLS Static Labels
Feature Information for MPLS Static Labels

Note Table 1 lists only the Cisco IOS XE software release that introduced support for a given feature in a
given Cisco IOS XE software release train. Unless noted otherwise, subsequent releases of that
Cisco IOS XE software release train also support that feature.
Table 1 Feature Information for MPLS Static Labels

MPLS Static Labels Cisco IOS XE The MPLS Static Labels feature provides the means to configure the
Release 2.1 following items statically:
• MPLS Static Labels Feature Overview, page 2
The following commands were introduced or modified: debug mpls
static binding, mpls label range, mpls static binding ipv4, mpls
static crossconnect, show mpls label range, show mpls static
binding ipv4, show mpls static crossconnect.
9
MPLS Static Labels
Glossary
Glossary
BGP—Border Gateway Protocol. The predominant interdomain routing protocol used in IP networks.
Border Gateway Protocol—See BGP.
FIB—Forwarding Information Base. A table that contains a copy of the forwarding information in the
IP routing table.
Forwarding Information Base—See FIB.
label—A short, fixed-length identifier that tells switching nodes how the data (packets or cells) should
be forwarded.
label binding—An association between a label and a set of packets, which can be advertised to
neighbors so that a label switched path can be established.
Label Distribution Protocol—See LDP.
Label Forwarding Information Base—See LFIB.
label imposition—The act of putting the first label on a packet.
label switching router—See LSR.
LDP—Label Distribution Protocol. The protocol that supports MPLS hop-by-hop forwarding by
distributing bindings between labels and network prefixes.
LFIB—Label Forwarding Information Base. A data structure in which destinations and incoming labels
are associated with outgoing interfaces and labels.
LSR—label switching router. A Layer 3 router that forwards a packet based on the value of an identifier
MPLS—Multiprotocol Label Switching. An industry standard on which label switching is based.
MPLS hop-by-hop forwarding—The forwarding of packets along normally routed paths using MPLS
forwarding mechanisms.
Multiprotocol Label Switching—See MPLS.
Resource Reservation Protocol—See RSVP.
RIB—Routing Information Base. A common database containing all the routing protocols running on a
router.
Routing Information Base—See RIB.
RSVP—Resource Reservation Protocol. A protocol for reserving network resources to provide quality
of service guarantees to application flows.
traffic engineering—Techniques and processes used to cause routed traffic to travel through the
network on a path other than the one that would have been chosen if standard routing methods were used.
Virtual Private Network—See VPN.
VPN—Virtual Private Network. A network that enables IP traffic to use tunneling to travel securely over
a public TCP/IP network.
10
MPLS Static Labels
Glossary
countries.
coincidental.
11
MPLS Static Labels
Glossary
12
MPLS Quality of Service (QoS)
This feature module describes the use of the MPLS class of service (CoS) functionality in an MPLS
network.
Note MPLS Class of Service is referred to as MPLS Quality of Service (QoS). This name reflects the growth
of MPLS to encompass a wider meaning and highlight the path towards future enhancements.

which each feature is supported, use the “Feature Information for MPLS Quality of Service” section on
page 16.
Contents
The document contains the following major sections:
• Supported Standards, MIBs, and RFCs, page 5
• Prerequisites, page 5
• Configuration Examples, page 10
• Feature Information for MPLS Quality of Service, page 16

Feature Overview
Feature Overview
MPLS CoS functionality enables network administrators to provide differentiated services across an
MPLS network. Network administrators can satisfy a wide range of networking requirements by
specifying the class of service applicable to each transmitted IP packet. Different classes of service can
be established for IP packets by setting the IP precedence bit in the header of each packet.
MPLS CoS supports the following differentiated services in an MPLS network:
• Packet classification
• Congestion avoidance
• Congestion management
Table 1 describes the MPLS CoS services and functions.
Table 1 MPLS CoS Services and Functions
Service CoS Function Description

Packet Committed access rate (CAR). CAR uses the type of service (ToS) bits in the IP
classification Packets are classified at the edge header to classify packets according to input and
of the network before labels are output transmission rates. CAR is often configured
assigned. on interfaces at the edge of a network in order to
control traffic flowing into or out of the network.
You can use CAR classification commands to
classify or reclassify a packet.
Congestion Weighted random early WRED monitors network traffic to anticipate and
avoidance detection (WRED). Packet prevent congestion at common network and
classes are differentiated based internetwork bottlenecks. WRED can selectively
on drop probability. discard lower priority traffic when an interface
becomes congested; WRED can also provide
differentiated performance characteristics for
different classes of service.
Congestion Weighted fair queueing (WFQ). WFQ is an automated scheduling system that
management Packet classes are differentiated ensures fair bandwidth allocation to all network
based on bandwidth traffic. WFQ uses weights (priorities) to determine
requirements and finite delay how much bandwidth each class of traffic is
characteristics. allocated.
MPLS CoS enables you to duplicate Cisco IOS XE IP CoS (Layer 3) features as closely as possible in
MPLS devices, including label edge switch routers (edge LSRs) and label switch routers (LSRs). MPLS
CoS functions map nearly one-for-one to IP CoS functions on all types of interfaces.
Tag Switching/MPLS Terminology

Table 2 lists the existing legacy tag switching terms and the new, equivalent MPLS IETF terms used in
this document and other related Cisco publications.
2
Feature Overview
Table 2 Tag Switching Terms and Equivalent MPLS Terms
Old Designation New Designation

Tag switching Multiprotocol Label Switching
Tag (short for tag switching) MPLS
Tag (item or packet) Label
TDP (Tag Distribution Protocol) LDP (Label Distribution Protocol). Cisco TDP and LDP
(MPLS Label Distribution Protocol) closely parallel each
other in function, but differ in detail, such as message
formats and the commands required to configure the
respective protocols and to monitor their operation.
Tag switched Label switched
TFIB (tag forwarding information base) LFIB (label forwarding information base)
TSR (tag switching router) LSR (label switching router)
TVC (tag VC, tag virtual circuit) LVC (label VC, label virtual circuit)
TSP (tag switch path) LSP (label switch path)
Supporting CoS in an MPLS Backbone

This section describes the following types of MPLS CoS configurations:
• LSRs Used at the Edge of an MPLS Network, page 3
• LSRs Used at the Core of an MPLS Network, page 4
LSRs Used at the Edge of an MPLS Network

LSRs used at the edge of an MPLS network backbone are routers running MPLS software. The edge
LSRs can be at the ingress or the egress of the network.
At the ingress of an MPLS network, routers process packets as follows:
1. IP packets enter the edge of the MPLS network at the edge LSR.
2. The edge LSR uses a classification mechanism such as the Modular Quality of Service
Command-Line Interface (CLI) (MQC) to classify incoming IP packets and set the IP precedence
value. Alternatively, IP packets can be received with the IP precedence value already set.
3. For each packet, the router performs a lookup on the IP address to determine the next-hop LSR.
4. The appropriate label is inserted into the packet, and the IP precedence bits are copied into the
MPLS EXP bits in the label header.
5. The labeled packets are forwarded to the appropriate output interface for processing.
6. The packets are differentiated by class according to one of the following:
– Drop probability—Weighted random early detection (WRED)
– Bandwidth allocation and delay—Class-based weighted fair queueing (CBWFQ)
3
Feature Overview
In either case, LSRs enforce the defined differentiation by continuing to employ WRED or CBWFQ on
every ingress router.
At the egress of an MPLS network, routers process packets as follows:
1. MPLS-labeled packets enter the edge LSR from the MPLS network backbone.
2. The MPLS labels are removed and IP packets may be (re)classified.
3. For each packet, the router performs a lookup on the IP address to determine the packet’s destination
and forwards the packet to the destination interface for processing.
4. The packets are differentiated by the IP precedence values and treated appropriately, depending on
the WRED or CBWFQ drop probability configuration.
LSRs Used at the Core of an MPLS Network

LSRs used at the core of an MPLS network are routers running MPLS software. These routers at the core
of an MPLS network process packets as follows:
1. MPLS labeled packets coming from the edge routers or other core routers enter the core router.
2. A lookup is done at the core router to determine the next hop LSR.
3. An appropriate label is placed (swapped) on the packet and the MPLS EXP bits are copied.
4. The labeled packet is then forwarded to the output interface for processing.
5. The packets are differentiated by the MPLS EXP field marking and treated appropriately, depending
on the WRED and CBWFQ configuration.
Benefits of MPLS CoS in IP Backbones

You realize the following benefits when you use MPLS CoS in a backbone consisting of IP routers
running MPLS:
• Efficient resource allocation—WFQ is used to allocate bandwidth on a per-class and per-link basis,
thereby guaranteeing a percentage of link bandwidth for network traffic.
• Packet differentiation—When IP packets traverse an MPLS network, packets are differentiated by
mapping the IP precedence bits of the IP packets to the MPLS CoS bits in the MPLS EXP field. This
mapping of bits enables the service provider to maintain end-to-end network guarantees and meet
the provisions of customer service level agreements (SLAs).
• Future service enhancements—MPLS CoS provides building blocks for future service
enhancements (such as virtual leased lines) by meeting bandwidth requirements.
Related Features and Technologies

You can use MPLS CoS functionality in any MPLS network.
4
Related Documents
For additional information about MPLS commands and Quality of Service, see the following documents:
• Quality of Service Overview
• Cisco IOS Quality of Service Solutions Command Reference
• Cisco IOS Multiprotocol Label Switching Command Reference

Standards
No new or modified standards are supported by this MPLS CoS feature.
MIBs
• CISCO-WRED-MIB
• CISCO-CAR-MIB
To locate and download MIBs for selected platforms, Cisco IOS XE software releases, and feature sets,
use Cisco MIB Locator found at the following URL:
RFCs
No new or modified RFCs are supported by this MPLS CoS feature.
Prerequisites
To use MPLS CoS to full advantage in your network, the following functionality must be supported:
• Multiprotocol label switching (MPLS)—MPLS is the standardized label switching protocol defined
by the Internet Engineering Task Force (IETF).
• Cisco Express Forwarding—Cisco Express Forwarding is an advanced Layer 3 IP switching
technology that optimizes performance and scalability in networks that handle large volumes of
traffic and that exhibit dynamic traffic patterns.
• Asynchronous Transfer Mode (ATM)—ATM signaling support is required if you are using
ATM interfaces in your network.
Note If you are using only packet interfaces in your network, ATM functionality is not needed.
• QoS features:
– Weighted fair queueing (WFQ)—WFQ, a dynamic scheduling method that allocates bandwidth
fairly to all network traffic.
WFQ applies priorities, or weights, to traffic to classify the traffic into flows and determine how
much bandwidth to allow each flow. WFQ moves interactive traffic to the front of a queue to
reduce response time and fairly shares the remaining bandwidth among high-bandwidth flows.
5
Configuration Tasks
– Weighted random early detection (WRED)—WRED, a congestion avoidance mechanism,

extends RED functionality by allowing different RED parameters to be configured per IP
precedence value.
IP precedence bits, contained in the type of service (ToS) octet in the IP packet header, are used
to denote the relative importance or priority of an IP packet. WRED uses these IP precedence
values to classify packets into different discard priorities or classes of service.
– Committed access rate (CAR)—CAR is a QoS feature that limits the input or output
transmission rate on an interface and classifies packets by setting the IP precedence value or the
QoS group in the IP packet header.
Configuration Tasks
This section contains the procedures listed below. All the procedures are listed as optional. However,
once you decide to configure a specific MPLS QoS feature (for example, WRED) that procedure
becomes required.
• Configuring WRED, page 6 (optional)
• Verifying WRED, page 6 (optional)
• Configuring CAR, page 7 (optional)
• Verifying the CAR Configuration, page 7 (optional)
• Configuring CBWFQ, page 8 (optional)
• Verifying the CBWFQ Configuration, page 8 (optional)
Configuring WRED
To configure weighted random early detection (WRED), use the commands shown in the following table.
Command Purpose
Step 1 Router(config)# interface type number Specifies the interface type and number.
Step 2 Router(config-if)# random-detect Configures the interface to use
WRED/DWRED.
Step 3 Router(config-if)# random-detect precedence Configures WRED/DWRED parameters per
min-threshold max-threshold mark-probability precedence value.
Verifying WRED
To verify weighted random early detection (WRED), use a command of the form shown in the following
table. This example is based on “Router2” in the network topology shown in Figure 1.
6
Configuration Tasks
Command Purpose
Step 1 Router2# show queueing interface p6/0/0 Verifies the WRED configuration on
Interface POS6/0/0 queueing strategy:random early detection the specified interface.
(WRED)
Exp-weight-constant:9 (1/512)
Mean queue depth:0
Class Random Tail Minimum Maximum Mark

drop drop threshold threshold probability
0 85 0 20 40 1/10
1 22 0 22 40 1/10
2 0 0 24 40 1/10
3 0 0 26 40 1/10
4 0 0 28 40 1/10
5 0 0 31 40 1/10
6 0 0 33 40 1/10
7 0 0 35 40 1/10
rsvp 0 0 37 40 1/10
Configuring CAR
To configure CAR, use the commands shown in the following table.
Command Purpose
Step 1 Router(config)# interface name Designates the input interface.
Step 2 Router(config-int)# rate-limit input [access-group Specifies the action to take on packets during
[rate-limit]acl-index] bps burst-normal burst-max label imposition.
conform-action conform-action exceed-action
exceed-action
Step 3 Router(config-int)# end Exits interface configuration mode.
Verifying the CAR Configuration

To verify the CAR configuration, use a command of the following form. This example is based on
“Router 2” in the network topology shown in Figure 1.
Router2# show interfaces fe1/1/1 rate-limit
FastEthernet1/1/1
Input
matches:access-group 101
params: 496000 bps, 32000 limit, 64000 extended limit
conformed 2137 packets, 576990 bytes; action:set-prec-transmit 4
exceeded 363 packets, 98010 bytes; action:set-prec-transmit 0
last packet:11788ms ago, current burst:39056 bytes
last cleared 00:01:18 ago, conformed 58000 bps, exceeded 10000 bps
7
Configuration Tasks
Configuring CBWFQ
To configure CBWFQ, use the commands shown in the following table.
Command Purpose
Step 1 Router(config)# class-map class-map-name Creates a class-map.
Step 2 Router(config-cmap)# match type number Specifies the traffic on which the class-map is to
match.
Step 3 Router(config-cmap)# policy-map policy-map-name Creates a policy map.
Step 4 Router(config-pmap)# class class-map-name Associates class-map with policy-map.
Step 5 Router(config-pmap-c)# bandwidth number Associates bandwidth (CBWFQ) action to act
on traffic matched by class-map.
Step 6 Router(config-pmap-c)# interface type number Specifies the interface type and number.
Step 7 Router(config-if)# service-policy output policy-map-name Assigns policy-map to interface.
Verifying the CBWFQ Configuration

To verify the CBWFQ configuration, use a command of the following form. This example is based on
“Router 5” in the network topology shown in Figure 1.
Router5# show policy-map interface fe5/1/0
FastEthernet5/1/0
service-policy output:outputmap
class-map:prec_01 (match-all)
522 packets, 322836 bytes
5 minute rate 1000 bps
match:ip precedence 0 1
queue size 0, queue limit 1356
packet output 522, packet drop 0
tail/random drop 0, no buffer drop 0, other drop 0
bandwidth:class-based wfq, weight 10
random-detect:
Mean queue depth:0
Class Random Tail Minimum Maximum Mark Output
drop drop threshold threshold probability packets
0 0 0 3390 6780 1/10 522
1 0 0 3813 6780 1/10 0
2 0 0 4236 6780 1/10 0
3 0 0 4659 6780 1/10 0
4 0 0 5082 6780 1/10 0
5 0 0 5505 6780 1/10 0
6 0 0 5928 6780 1/10 0
7 0 0 6351 6780 1/10 0
0 packets, 0 bytes
5 minute rate 0 bps
random-detect:
8
Configuration Tasks
Mean queue depth:0
0 0 0 0 0 1/10 0
1 0 0 0 0 1/10 0
2 0 0 0 0 1/10 0
3 0 0 0 0 1/10 0
4 0 0 0 0 1/10 0
5 0 0 0 0 1/10 0
6 0 0 0 0 1/10 0
7 0 0 0 0 1/10 0
2137 packets, 576990 bytes
5 minute rate 16000 bps
random-detect:
Mean queue depth:0
0 0 0 3390 6780 1/10 0
1 0 0 3813 6780 1/10 0
2 0 0 4236 6780 1/10 0
3 0 0 4659 6780 1/10 0
4 0 0 5082 6780 1/10 2137
5 0 0 5505 6780 1/10 0
6 0 0 5928 6780 1/10 0
7 0 0 6351 6780 1/10 0
0 packets, 0 bytes
5 minute rate 0 bps
random-detect:
Mean queue depth:0
0 0 0 0 0 1/10 0
1 0 0 0 0 1/10 0
2 0 0 0 0 1/10 0
3 0 0 0 0 1/10 0
4 0 0 0 0 1/10 0
5 0 0 0 0 1/10 0
6 0 0 0 0 1/10 0
7 0 0 0 0 1/10 0
class-map:class-default (match-any)
0 packets, 0 bytes
5 minute rate 0 bps
match:any
0 packets, 0 bytes
5 minute rate 0 bps
9

Router5#
Router5# show queueing interface fa1/1/0
Interface FastEthernet1/1/0 queueing strategy:VIP-based fair queueing
FastEthernet1/1/0 queue size 0
pkts output 2756, wfq drops 0, nobuffer drops 0
WFQ:aggregate queue limit 13561 max available buffers 13561
Class 0:weight 30 limit 4068 qsize 0 pkts output 97 drops 0

This section provides the following configuration examples.
• Configuring Cisco Express Forwarding: Example, page 11
• Running IP on Router 1: Example, page 11
• Running MPLS on Router 2: Example, page 11
• Running IP on Router 6: Example, page 15
The configuration examples in this section are based on the sample network topology shown in Figure 1.
Figure 1 Sample Network Topology for Configuring MPLS CoS on Router Interfaces
Router 3 Router 4
Router 2 Router 5
p3/0/0 p1/2/1
p6/0/0
/0 p0/1/0 p3/0/0 fa5
Router 1 1
fe1/ p1/0/0 /1/0
0/1 Router 6
fe0/ fa2
/0/0
CPE
non-MPLS CPE
router non-MPLS
router
192765
10
Configuring Cisco Express Forwarding: Example

Cisco Express Forwarding is a prerequisite for using MPLS CoS; CEF must be running on all routers
and switches in the MPLS network. To enable Cisco Express Forwarding on a router or a switch, use the
following command:
Router(config)# ip cef
Running IP on Router 1: Example

The following commands enable IP routing on Router 1 (see Figure 1). All routers in Figure 1 must have
IP enabled.
Note Router 1 is not part of the MPLS network.
!
ip routing
!
hostname R1
!
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
interface FastEthernet0/0/1
ip address 10.0.0.1 255.0.0.0
!
router ospf 100
network 10.0.0.0 0.255.255.255 area 100
network 10.0.0.1 0.255.255.255 area 100
Running MPLS on Router 2: Example

Router 2 (see Figure 1) is a label edge router. Cisco Express Forwarding and MPLS must be enabled on
this router. CAR is also configured on Router 2 and interface e1/3. The CAR policy used at FastEthernet
interface 1/1/0 acts on incoming traffic matching access-list 101. If the traffic rate is less than the
committed information rate (in this example, 496000), the traffic will be sent with IP precedence 4.
Otherwise, this traffic will be sent with IP precedence 0.
!
ip routing
!
hostname R2
!
ip cef
mpls ip
tag-switching advertise-tags
!
interface Loopback0
ip address 10.10.10.10 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
rate-limit input access-group 101 496000 32000 64000 conform-action set-prec-transmit 4
exceed-action set-prec-transmit 0
!
11
interface POS6/0/0
ip address 10.0.0.1 255.0.0.0
mpls label protocol ldp
mpls ip
random-detect
clock source internal
!
router ospf 100
network 10.0.0.0 0.255.255.255 area 100
network 10.1.0.0 0.255.255.255 area 100
network 11.0.1.0 0.255.255.255 area 100
!
access-list 101 permit ip host 10.10.1.1 any

Router 3 (see Figure 1) is running MPLS. Cisco Express Forwarding and MPLS must be enabled on this
router.
!
ip routing
mpls ip
!
hostname R3
!
interface Loopback0
ip address 10.10.10.10 255.255.255.255
!
interface POS0/1/0
ip address 10.0.0.2 255.0.0.0
mpls ip
crc 16
!
interface POS3/0/0
ip address 10.0.0.1 255.0.0.0
mpls ip
crc 16
tx-cos stm16-rx
!
router ospf 100
network 10.0.1.0 0.255.255.255 area 100
network 10.0.0.1 0.255.255.255 area 100
network 10.1.0.0 0.255.255.255 area 100
!
cos-queue-group stm16-rx
precedence 0 random-detect-label 0
precedence 0 queue 0
precedence 7 queue low-latency
12
random-detect-label 0 250 1000 1

queue 0 50
queue 1 100
queue 2 150
queue low-latency alternate-priority 500

router.
!
ip routing
mpls ip
!
hostname R4
!
interface Loopback0
ip address 10.0.0.0 255.255.255.255
!
interface POS1/2/1
ip address 10.0.0.1 255.0.0.0
mpls ip
crc 16
tx-cos stm16-rx
!
router ospf 100
network 10.0.0.0 0.255.255.255 area 100
network 10.1.0.0 0.255.255.255 area 100
network 10.0.1.0 0.255.255.255 area 100
!
cos-queue-group stm16-rx
precedence 7 queue low-latency
queue 0 50
queue 1 100
queue 2 150
queue low-latency alternate-priority 200
13

router. Router 5 has CBWFQ enabled on FastEthernet interface 5/1/0. In this example, class-maps are
created, matching packets with various IP precedence values. These class-maps are then used in a
policy-map named “outputmap,” where CBWFQ is assigned to each class. Finally, the policy-map is
assigned to the outbound FastEthernet interface 5/1/0.
!
ip routing
mpls ip
!
hostname R5
!
!
class-map match-all prec_01
match ip precedence 0 1
!
!
policy-map outputmap
class prec_01
bandwidth 10000
random-detect
class prec_23
bandwidth 15000
random-detect
class prec_45
bandwidth 20000
random-detect
class prec_67
bandwidth 25000
random-detect
!
ip cef distributed
!
interface Loopback0
ip address 10.0.0.0 255.255.255.255
no ip directed-broadcast
!
interface POS1/1/0
ip address 10.0.0.2 255.0.0.0
ip route-cache distributed
mpls ip
!
ip address 10.0.0.1 255.0.0.0
full-duplex
service-policy output outputmap
!
router ospf 100
network 10.1.0.0 0.255.255.255 area 100
network 10.0.1.0 0.255.255.255 area 100
network 10.0.0.1 0.255.255.255 area 100
14
Running IP on Router 6: Example

Router 6 (see Figure 1) is running IP. Cisco Express Forwarding must be enabled on this router.
Note Router 6 is not part of the MPLS network.
!
ip routing
!
hostname R6
!
ip cef distributed
!
interface Loopback0
ip address 10.0.0.0 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
full-duplex
!
router ospf 100
network 10.0.0.0 0.255.255.255 area 100
network 10.1.0.0 0.255.255.255 area 100
!
15
Feature Information for MPLS Quality of Service
Feature Information for MPLS Quality of Service

Table 3 lists the release history for this feature lists and provides links to specific configuration
information.
Table 3 Feature Information for MPLS Quality of Service

MPLS Class of Service (CoS) Cisco IOS XE This feature was introduced on Cisco ASR 1000 Series Aggregation
Release 2.1 Services Routers.
16
Glossary
Glossary
ATM edge LSR—A router that is connected to the ATM-LSR cloud through LC-ATM interfaces. The
ATM edge LSR adds labels to unlabeled packets and strips labels from labeled packets.
ATM-LSR—A label switch router with a number of LC-ATM interfaces. The router forwards the cells
among these interfaces using labels carried in the VPI/VCI field.
CAR—Committed access rate (packet classification). CAR is the main feature supporting packet
classification. CAR uses the type of service (ToS) bits in the IP header to classify packets. You can use
the CAR classification commands to classify or reclassify a packet.
CoS—Class of service. A feature that provides scalable, differentiated types of service across an MPLS
network.
IP precedence—A 3-bit value in a ToS byte used for assigning precedence to IP packets.
label—A short, fixed-length construct that tells switching nodes how to forward data (packets or cells).
label-controlled ATM interface (LC-ATM interface)—An interface on a router or switch that uses
label distribution procedures to negotiate label VCs.
label imposition—The process of putting the first label on a packet.
label switch—A node that forwards units of data (packets or cells) on the basis of labels.
label-switched path (LSP)—An LSP results from a sequence of hops (Router 0...Router n) through
which a packet travels from R0 to Rn by means of label switching mechanisms. A label-switched path
can be determined dynamically (based on normal routing mechanisms), or it can be defined explicitly.
label-switched path (LSP) tunnel—A configured connection between two routers, in which label
switching techniques are used for packet forwarding.
label switching router (LSR)—A Layer 3 router that forwards a packet based on the value of a label
label VC (LVC)—An ATM virtual circuit that is set up through ATM LSR label distribution procedures.
LBR—Label bit rate. A service category defined by this document for label-VC traffic. Link and per-VC
bandwidth sharing can be controlled by relative bandwidth configuration at the edge and each switch
along a label-VC. No ATM traffic-related parameters are specified.
LDP—Label Distribution Protocol. The protocol used to distribute label bindings to LSRs.
LFIB—Label forwarding information base. The data structure used by switching functions to switch
labeled packets.
LIB—Label information base. A database used by an LSR to store labels learned from other LSRs, as
well as labels assigned by the local LSR.
MPLS—Multiprotocol label switching. An emerging industry standard that defines support for MPLS
forwarding of packets along normally routed paths (sometimes called MPLS hop-by-hop forwarding).
RED—Random early detection. A congestion avoidance algorithm in which a small percentage of
packets are dropped when congestion is detected and before the queue in question overflows completely.
ToS bits—Type of service bits. A byte in the IPv4 header.
network on a path other than the one that would have been chosen if standard routing methods had been
applied.
from the one that Layer 3 routing would cause the tunnel to take.
17
Glossary
VPN—Virtual private network. Enables IP traffic to use tunneling to transport data securely over a
public TCP/IP network.
WRED—Weighted random early detection. A variant of RED in which the probability of a packet being
dropped depends on either its IP precedence, CAR marking, or MPLS CoS (as well as other factors in
the RED algorithm).
WFQ—Weighted fair queueing. A queue management algorithm that provides a certain fraction of link
bandwidth to each of several queues, based on a relative bandwidth applied to each of the queues.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco Ironport, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect,
Cisco Stackpower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels, Flip for Good,
Flip Mino, Flip Video, Flip Video (Design), Flipshare (Design), Flip Ultra, and Welcome to the Human Network are trademarks; Changing the Way
We Work, Live, Play, and Learn, Cisco Store, and Flip Gift Card are service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting
To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS,
Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch,
Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the
IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers, Networking Academy,
Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to
Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the
United States and certain other countries.
coincidental.
18
MPLS—Multilink PPP Support
First Published: December 18, 2003

The MPLS—Multilink PPP Support feature ensures that MPLS Layer 3 Virtual Private Networks
(VPNs) with quality of service (QoS) can be enabled for bundled links. This feature supports
Multiprotocol Label Switching (MPLS) over Multilink PPP (MLP) links in the edge (provider edge
[PE]-to-customer edge [CE]) or in the MPLS core (PE-to-PE and PE-to-provider router [P]).
Service providers that use relatively low-speed links can use MLP to spread traffic across them in their
MPLS networks. Link fragmentation and interleaving (LFI) should be deployed in the CE-to-PE link for
efficiency, where traffic uses a lower link bandwidth (less than 768 kbps).

which each feature is supported, see the “Feature Information for MPLS—Multilink PPP Support” section
on page 21.
Contents
• Prerequisites for MPLS—Multilink PPP Support, page 2
• Information About MPLS—Multilink PPP Support, page 2
• How to Configure MPLS—Multilink PPP Support, page 7
• Configuration Examples for MPLS—Multilink PPP Support, page 17
Prerequisites for MPLS—Multilink PPP Support
• Feature Information for MPLS—Multilink PPP Support, page 21

Prerequisites for MPLS—Multilink PPP Support

The MPLS—Multilink PPP Support feature requires the following:
• Cisco Express Forwarding enabled
• MPLS enabled on PE and P routers
• Cisco Express Forwarding switching enabled on the interface with the ip route-cache cef command
Information About MPLS—Multilink PPP Support

This section contains information that you need to use the MPLS—Multilink PPP Support feature:
• MPLS Features Supported for Multilink PPP, page 2
• MPLS—Multilink PPP Support and PE-to-CE Links, page 4
• MPLS—Multilink PPP Support and Core Links, page 4
• MPLS—Multilink PPP Support in a CSC Network, page 5
• MPLS—Multilink PPP Support in an Interautonomous System, page 6
MPLS Features Supported for Multilink PPP

The following topics provide information about MPLS features supported for MLP:
• MPLS Layer 3 Virtual Private Network Features Supported for Multilink PPP, page 2
• MPLS Quality of Service Features Supported for Multilink PPP, page 3
MPLS Layer 3 Virtual Private Network Features Supported for Multilink PPP
Table 1 lists MPLS Layer 3 VPN features supported for MLP and indicates if the feature is supported on
CE-to-PE links, PE-to-P links, and Carrier Supporting Carrier (CSC) CE-to-PE links.
Table 1 MPLS Layer 3 VPN Features Supported for MLP
MPLS L3 VPN Feature CE-to-PE Links PE-to-P Links CSC CE-to-PE Links
1
Static routes Supported — —
External Border Gateway Protocol Supported Not applicable to Supported
(eBGP) this configuration
Intermediate System-to-Intermediate — Supported —
System (IS-IS)
Open Shortest Path first (OSPF) Supported Supported —
Enhanced Interior Gateway Routing Supported Supported —
Protocol (EIGRP)
2
Table 1 MPLS Layer 3 VPN Features Supported for MLP (continued)
MPLS L3 VPN Feature CE-to-PE Links PE-to-P Links CSC CE-to-PE Links
Interprovider (Inter-AS) VPNs (with Not applicable to Supported (MLP Not applicable to
Label Distribution Protocol [LDP]) this configuration between this configuration
Autonomous
System Border
routers {ASBRs])
Inter-AS VPNs with IPv4 Label Not applicable to Supported (MLP Not applicable to
Distribution this configuration between ASBRs] this configuration
CSC VPNs (with LDP) — Not applicable to Supported

this configuration
CSC VPNs with IPv4 label Supported Not applicable to Supported
distribution this configuration
External and internal BGP (eiBGP) — — Not applicable to
Multipath this configuration
Internal BGP (iBGP) Multipath Not applicable to — Not applicable to
this configuration this configuration
eBGP Multipath — — —
1. An em dash (—) indicates that the configuration is not supported.
MPLS Quality of Service Features Supported for Multilink PPP

Table 2 lists the MPLS QoS features supported for MLP and indicates if the feature is supported on
CE-to-PE links, PE-to-P links, and CSC-CE-to-CSC-PE links.
Table 2 MPLS QoS Features Supported for MLP
MPLS QoS Feature CE-to-PE Links PE-to-P Links CSC-CE-to-PE Links

1
Default copy of IP Precedence to Supported — —
EXP bits and the reverse
Set MPLS EXP bits using the Supported Supported Supported
modular QoS Command-Line
Interface (MQC)
Matching on MPLS EXP using MQC Supported Supported Supported
Low Latency Queueing (LLQ)/ Supported Supported Supported
Class-Based Weighted Fair Queueing
(CBWFQ) support
Weighted Random Early Detection Supported Supported Supported
(WRED) based on EXP bits using
MQC
3
Table 2 MPLS QoS Features Supported for MLP (continued)
MPLS QoS Feature CE-to-PE Links PE-to-P Links CSC-CE-to-PE Links

Policer with EXP bit-marking using Supported Supported Supported
MQC-3 action
Support for EXP bits in MPLS Supported Supported Supported
accounting
1. An em dash (—) indicates that the configuration is not supported.
MPLS—Multilink PPP Support and PE-to-CE Links

Figure 1 shows a typical MPLS network in which the PE router is responsible for label imposition (at
ingress) and disposition (at egress) of the MPLS traffic.
In this topology, MLP is deployed on the PE-to-CE links. The VPN routing and forwarding instance
(VRF) interface is in a multilink bundle. There is no MPLS interaction with MLP; all packets coming
into the MLP bundle are IP packets.
Figure 1 MLP and Traditional PE-to-CE Links
iBGP-VPNv4 label exchange
CE LDP CE
LDP P P LDP
PE PE
CE CE
192835
MLP interfaces handling
MPLS labeled packets
The PE-to-CE routing protocols that are supported for the MPLS—Multilink PPP Support feature are
eBGP, OSPF, and EIGRP. Static routes are also supported between the CE and PE routers.
QoS features that are supported for the MPLS—Multilink PPP Support feature on CE-to-PE links are
LFI, header compression, policing, marking, and classification.
MPLS—Multilink PPP Support and Core Links

Figure 2 shows a sample topology in which MPLS is deployed over MLP on PE-to-P and P-to-P links.
Enabling MPLS on MLP for PE-to-P links is similar to enabling MPLS on MLP for P-to-P links.
4
Figure 2 MLP on PE-to-P and P-to-P Links
CE LDP CE
LDP P P LDP
PE PE
CE CE
192836
You employ MLP in the PE-to-P or P-to-P links primarily so that you can reduce the number of Interior
Gateway Protocol (IGP) adjacencies and facilitate the load sharing of traffic.
In addition to requiring MLP on the PE-to-P links, the MPLS—Multilink PPP Support feature requires
the configuration of an IGP routing protocol and LDP.
MPLS—Multilink PPP Support in a CSC Network

Figure 3 shows a typical MPLS VPN CSC network where MLP is configured on the CSC-CE-to-CSC-PE
links.
Figure 3 MLP on CSC-CE-to-CSC-PE Links with MPLS VPN Carrier Supporting Carrier
LDP
LDP P1 P2 LDP
CSC-CE1 CSC-PE1 CSC-CE2

CSC-PE2 CSC-CE1
192837

The MPLS—Multilink PPP Support feature supports MLP between CSC-CE and CSC-PE links with
LDP or with EBGP IPv4 label distribution. This feature also supports LFI for an MPLS VPN CSC
configuration. Figure 4 shows all MLP links that this feature supports for CSC configurations.
5
Figure 4 MLP Supported Links with MPLS VPN Carrier Supporting Carrier
P1 P2
CSC-PE1 CSC-PE2
Backbone carrier
CE1 CSC-PE1
PE1 PE2
CSC-PE1 CE2
CSC-CE1 CSC-CE2
Customer carrier Customer carrier
192838
MPLS—Multilink PPP Support in an Interautonomous System

Figure 5 shows a typical MPLS VPN interautonomous system (Inter-AS) network where MLP is
configured on the PE-to-CE links.
Figure 5 MLP on ASBR-to-PE Links in an MPLS VPN Inter-AS Network
Multihop
multiprotocol
VPNv4
RR1 RR2
PE1 P1 P2 PE2
ASBR1 ASBR2
BGP IPv4
CE1 routes and labels CE2
VPN1 VPN2
192839

The MPLS—Multilink PPP Support feature supports MLP between ASBR links for Inter-AS VPNs with
LDP and with eBGP IPv4 label distribution.
6
How to Configure MPLS—Multilink PPP Support

This section contains the following procedures for configuring the MPLS—Multilink PPP Support
feature:
• Enabling Cisco Express Forwarding Switching, page 7 (required)
• Creating a Multilink Bundle for MPLS—Multilink PPP Support, page 8 (required)
• Assigning an Interface to a Multilink Bundle for MPLS—Multilink PPP Support, page 10 (required)
• Disabling PPP Multilink Fragmentation, page 13 (optional)
• Verifying the Multilink PPP Configuration, page 14 (optional)
Service providers that use relatively low-speed links can use MLP to spread traffic across them in their
MPLS networks. LFI should be deployed in the CE-to-PE link for efficiency, where traffic uses lower
link bandwidth (less than 768 kbps). The MPLS—Multilink PPP Support feature can reduce the number
of IGP adjacencies and facilitate load sharing of traffic.
The tasks in this section can be performed on CE-to-PE links, PE-to-P links, P-to-P links, and CSC
CSC-CE-to-CSC-PE links.
Enabling Cisco Express Forwarding Switching

Perform the following task to enable Cisco Express Forwarding switching. Cisco Express Forwarding is
required for the forwarding of MLP traffic.
Prerequisites
Multilink PPP requires the configuration of standard Cisco Express Forwarding. To find out if
Cisco Express Forwarding is enabled on your router, enter the show ip cef command. If
Cisco Express Forwarding is enabled, you receive output that looks like the following:
Router# show ip cef
Prefix Next Hop Interface

10.2.61.8/24 192.168.100.1 FastEthernet1/0/0
192.168.101.1 FastEthernet6/1/0
If Cisco Express Forwarding is not enabled on your platform, the output for the show ip cef command
looks like the following:
Router# show ip cef
%CEF not running
SUMMARY STEPS
1. enable
2. configure terminal
3. ip cef
4. exit
7
DETAILED STEPS
Command or Action Purpose

Step 1 enable Enables privileged EXEC mode.
• Enter your password if prompted.
Example:
Router> enable
Step 2 configure terminal Enters global configuration mode.
Example:
Step 3 ip cef Enables standard Cisco Express Forwarding switching.
Example:
Step 4 exit Exits to privileged EXEC mode.
Example:
Router(config)# exit
Creating a Multilink Bundle for MPLS—Multilink PPP Support

Perform this task to create a multilink bundle for the MPLS—Multilink PPP Support feature. This can
reduce the number of IGP adjacencies and facilitate load sharing of traffic.
SUMMARY STEPS
1. enable
3. interface multilink group-number
4. ip address address mask [secondary]
5. encapsulation encapsulation-type
6. ppp multilink
7. end
8
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface multilink group-number Creates a multilink bundle or enters multilink interface
configuration mode.
Example: • The group-number argument is the number of the
Router(config)# interface multilink 1 multilink bundle (a nonzero number).
Step 4 ip address address mask [secondary] Sets a primary or secondary IP address for an interface.
• The address argument is the IP address.
Example: • The mask argument is the mask for the associated IP
Router(config-if)# ip address address mask
subnet.
• The secondary keyword specifies that the configured
address is a secondary IP address. If this keyword is
omitted, the configured address is the primary IP
address.
This command is used to assign an IP address to the
multilink interface.
Step 5 encapsulation encapsulation-type Sets the encapsulation method used by the interface.
• The encapsulation-type argument specifies the
Example: encapsulation type. The keyword ppp enables PPP
Router(config-if)# encapsulation ppp encapsulation.
Step 6 ppp multilink Enables MLP on an interface.
Example:
Router(config-if)# ppp multilink
Step 7 end Exits to privileged EXEC mode.
Example:
Router(config-if)# end
9
Assigning an Interface to a Multilink Bundle for MPLS—Multilink PPP Support

Perform this task to assign an interface to a multilink bundle for the MPLS—Multilink PPP Support
feature.
SUMMARY STEPS
1. enable
3. controller {t1 | e1} slot/port
4. channel-group channel-number timeslots range
5. exit
6. interface serial slot/subslot/port[.subinterface]
7. ip route-cache [cef |distributed]
8. no ip address
9. keepalive [period [retries]]
11. multilink-group group-number
12. ppp multilink
13. ppp authentication chap
14. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 controller {t1 | e1} slot/port Configures a T1 or E1 controller and enters controller
configuration mode.
Example: • The t1 keyword indicates a T1 line card.
Router# controller t1 1/3
• The e1 keyword indicates an E1 line card.
• The slot/port arguments are the backplane slot number
and port number on the interface. Refer to your
hardware installation manual for the specific slot
numbers and port numbers.
10

Step 4 channel-group channel-number timeslots range Defines the time slots that belong to each T1 or E1 circuit.
• The channel-number argument is the channel-group
Example: number. When a T1 data line is configured,
Router(config-controller)# channel-group 1 channel-group numbers can be values from 0 to 23.
timeslots 1 When an E1 data line is configured, channel-group
numbers can be values from 0 to 30.
• The timeslots range keyword-argument pair specifies
one or more time slots or ranges of time slots belonging
to the channel group. The first time slot is numbered 1.
For a T1 controller, the time slot range is from 1 to 24.
For an E1 controller, the time slot range is from 1 to 31.
You can specify a time slot range (for example, 1–29),
individual time slots separated by commas (for example
1, 3, 5), or a combination of the two (for example 1–14,
15, 17–31).
Step 5 exit Exits to global configuration mode.
Example:
Router(config-controller)# exit
Step 6 interface serial Configures a serial interface and enters interface
slot/subslot/port[.subinterface] configuration mode.
Example:
Router(config)# interface serial 1/0/0:1
Step 7 ip route-cache [cef] Controls the use of switching methods for forwarding IP
packets
Example: • The cef keyword enables Cisco Express Forwarding
Router(confg-if)# ip route-cache cef operation on an interface after
Cisco Express Forwarding operation was disabled.
Step 8 no ip address Removes any specified IP address.
Example:
Router(config-if)# no ip address
11

Step 9 keepalive [period [retries]] Enables keepalive packets and specifies the number of times
that the Cisco IOS XE software tries to send keepalive
packets without a response before bringing down the
Example:
Router(config-if)# keepalive
interface or before bringing the tunnel protocol down for a
specific interface.
• The period argument is an integer value, in seconds,
greater than 0. The default is 10.
• The retries argument specifies the number of times that
the device will continue to send keepalive packets
without response before bringing the interface down.
Enter an integer value greater than 1 and less than 255.
If you do not enter a value, the value that was
previously set is used; if no value was specified
previously, the default of 5 is used.
If you are using this command with a tunnel interface,
the command specifies the number of times that the
device will continue to send keepalive packets without
response before bringing the tunnel interface protocol
down.
Step 10 encapsulation encapsulation-type Sets the encapsulation method used by the interface.
• The encapsulation-type argument specifies the
Example: encapsulation type. The keyword ppp enables PPP
Router(config-if)# encapsulation ppp encapsulation.
Step 11 multilink-group group-number Designates an interface as part of a multilink leased line
bundle.
Example: • The group-number argument is the number of the
Router(config-if)# multilink-group 1 multilink bundle (a nonzero number).
Step 12 ppp multilink Enables MLP on an interface.
Example:
Router(config-if)# ppp multilink
Step 13 ppp authentication chap (Optional) Enables Challenge Handshake Authentication
Protocol (CHAP) authentication on a serial interface.
Example:
Router(config-if)# ppp authentication chap
Example:
12
Disabling PPP Multilink Fragmentation

Perform this task to disable PPP multilink fragmentation. PPP multilink fragmentation is enabled by
default.
Enabling fragmentation reduces the delay latency among bundle links, but adds some load to the CPU.
Disabling fragmentation might produce better throughput.
If your data traffic is consistently of a similar size, we recommend disabling fragmentation. In this case,
the benefits of fragmentation can be outweighed by the added load on the CPU.
SUMMARY STEPS
1. enable
3. interface type number
4. ppp multilink fragmentation disable
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number Configures an interface type and enters interface
configuration mode.
Example: • The type argument indicates the type of interface to be
Router(config)# interface serial 1/0/0 configured.
• The number argument specifies the port, connector, or
interface card number. The numbers are assigned at the
factory at the time of installation or when the interface
is added to a system, and can be displayed with the
show interfaces command.
Step 4 ppp multilink fragmentation disable Disables packet fragmentation.
Example:
Router(config-if)# ppp multilink fragmentation
disable
Example:
13
Verifying the Multilink PPP Configuration

Perform the following task to verify the Multilink PPP configuration.
SUMMARY STEPS
1. enable
2. show ip interface brief
3. show ppp multilink
4. show ppp multilink interface interface-bundle
5. show interface interface-name interface-number
6. show mpls forwarding-table
7. exit
DETAILED STEPS
Step 1 enable
Use this command to enable privileged EXEC mode. Enter your password if prompted. For example:
Router> enable
Router#
Step 2 show ip interface brief

Use this command to verify logical and physical MLP interfaces. For example:
Router# show ip interface brief
Locolrface IP-Address OK? Method Status Prot

FastEthernet1/0/0 10.3.62.106 YES NVRAM up up
FastEthernet0/0/1 unassigned YES NVRAM administratively down down

Serial1/1/0:1 unassigned YES NVRAM administratively down down
Serial1/1/0:2 unassigned YES NVRAM administratively down down
Serial1/1/1:1 unassigned YES NVRAM up up
Serial1/1/1:2 unassigned YES NVRAM up down

Multilink6 10.30.0.2 YES NVRAM up up
Multilink8 unassigned YES NVRAM administratively down down

Multilink10 10.34.0.2 YES NVRAM up up
14
Loopback0 10.0.0.1 YES NVRAM up up
Step 3 show ppp multilink

Use this command to verify that you have created a multilink bundle. For example:
Router# show ppp multilink
Multilink1, bundle name is group 1

Bundle is Distributed
0 lost fragments, 0 reordered, 0 unassigned, sequence 0x0/0x0 rcvd/sent
0 discarded, 0 lost received, 1/255 load
Member links: 4 active, 0 inactive (max no set, min not set)
Serial1/0/0/:1
Serial1/0/0/:2
Serial1/0/0/:3
Serial1/0/0/:4
Step 4 show ppp multilink interface interface-bundle

Use this command to display information about a specific MLP interface. For example:
Router# show ppp multilink interface multilink6
Multilink6, bundle name is router

Bundle up for 00:42:46, 1/255 load
Receive buffer limit 24384 bytes, frag timeout 1524 ms
Bundle is Distributed
0/0 fragments/bytes in reassembly list
1 lost fragments, 48 reordered
0/0 discarded fragments/bytes, 0 lost received
0x4D7 received sequence, 0x0 sent sequence
Member links: 2 active, 0 inactive (max not set, min not set)
Se1/1/3:1, since 00:42:46, 240 weight, 232 frag size
Se1/1/3:2, since 00:42:46, 240 weight, 232 frag size
Step 5 show interface interface-name interface-number

Use this command to display information about serial interfaces in your configuration. For example:
Router# show interface serial 1/1/3:1
Serial1/1/3:1 is up, line protocol is up

Hardware is Multichannel T1
MTU 1500 bytes, BW 64 Kbit, DLY 20000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation PPP, LCP Open, multilink Open, crc 16, Data non-inverted
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:47:13
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/40 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
722 packets input, 54323 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
697 packets output, 51888 bytes, 0 underruns
0 output errors, 0 collisions, 1 interface resets
0 output buffer failures, 0 output buffers swapped out
1 carrier transitions no alarm present
Timeslot(s) Used:1, subrate: 64Kb/s, transmit delay is 0 flags
Transmit queue length 25
15
Router# show interface serial 1/1/3:2
Serial1/1/3:2 is up, line protocol is up

Hardware is Multichannel T1
Encapsulation PPP, LCP Open, multilink Open, crc 16, Data non-inverted
1 carrier transitions no alarm present
Timeslot(s) Used:2, subrate: 64Kb/s, transmit delay is 0 flags
Transmit queue length 26
You can also use the show interface command to display information about the multilink interface:
Router# show interface multilink6
Multilink6 is up, line protocol is up

Hardware is multilink group interface
Internet address is 10.30.0.2/8
Encapsulation PPP, LCP Open, multilink Open
Open: CDPCP, IPCP, TAGCP, loopback not set
DTR is pulsed for 2 seconds on reset
Last input 00:00:00, output never, output hang never
30 second input rate 0 bits/sec, 0 packets/sec
30 second output rate 0 bits/sec, 0 packets/sec
0 carrier transitions
Step 6 show mpls forwarding-table

Use this command to display contents of the MPLS Label Forwarding Information Base (LFIB) and look
for information on multilink interfaces associated with a point2point next hop. For example:

16 Untagged 10.30.0.1/32 0 Mu6 point2point
17 Pop tag 10.0.0.3/32 0 Mu6 point2point
18 Untagged 10.0.0.9/32[V] 0 Mu10 point2point
16
Configuration Examples for MPLS—Multilink PPP Support

21 Aggregate 10.34.0.0/8[V] 0
Use the show ip bgp vpnv4 command to display VPN address information from the Border Gateway
Protocol (BGP) table:
Router# show ip bgp vpnv4 all summary
BGP router identifier 10.0.0.1, local AS number 100

BGP table version is 21, main routing table version 21
10 network entries using 1210 bytes of memory
10 path entries using 640 bytes of memory
2 BGP path attribute entries using 120 bytes of memory
1 BGP extended community entries using 24 bytes of memory
0 BGP route-map cache entries using 0 bytes of memory
0 BGP filter-list cache entries using 0 bytes of memory
BGP using 1994 total bytes of memory
BGP activity 10/0 prefixes, 10/0 paths, scan interval 5 secs
10.0.0.3 4 100 MsgRc52 MsgSe52 TblV21 0 0 00:46:35 State/P5xRcd
Step 7 exit
Use this command to exit to user EXEC mode. For example:
Router# exit
Router>

The following are configuration examples for the MPLS—Multilink PPP Support feature:
• Sample Multilink PPP Configuration on an MPLS CSC PE Router, page 17
• Enabling Cisco Express Forwarding: Example, page 19
• Creating a Multilink Bundle for MPLS—Multilink PPP Support: Example, page 19
Sample Multilink PPP Configuration on an MPLS CSC PE Router

The following is a sample configuration for an MPLS CSC PE router. The configuration of MLP on an
interface is the same for PE-to-CE links, PE-to-P links, and P-to-P links. An eBGP session is configured
between the PE and CE routers.
Router# show running-config interface Serial1/0/0:1
!
ip cef
ip vrf vpn2
rd 200:1
route-target export 200:1
route-target import 200:1
!
17
controller T1 1/0
framing esf
linecode b8zs
channel-group 1 timeslots 1
channel-group 2 timeslots 2
no yellow generation
no yellow detection
!
interface Serial1/0:1
no ip address
encapsulation ppp
tx-ring-limit 26
ppp multilink
ppp multilink group 1
!
interface Serial1/0:2
no ip address
encapsulation ppp
tx-ring-limit 26
ppp multilink
!
interface Multilink1
ip vrf forwarding vpn2
ip address 10.35.0.2 255.0.0.0
no peer neighbor-route
load-interval 30
ppp multilink
ppp multilink interleave
!
!
router ospf 200
log-adjacency-changes
auto-cost reference-bandwidth 1000
redistribute connected subnets
passive-interface Multilink1
network 10.0.0.7 0.0.0.0 area 200
network 10.31.0.0 0.255.255.255 area 200
!
!
router bgp 200
no bgp default ipv4-unicast
bgp log-neighbor-changes
neighbor 10.0.0.11 remote-as 200
neighbor 10.0.0.11 update-source Loopback0
!
address-family vpnv4
neighbor 10.0.0.11 activate
neighbor 10.0.0.11 send-community extended
bgp scan-time import 5
exit-address-family
!
address-family ipv4 vrf vpn2
redistribute connected
neighbor 10.35.0.1 as-override
neighbor 10.35.0.1 advertisement-interval 5
no auto-summary
no synchronization
exit-address-family
18
Enabling Cisco Express Forwarding: Example

The following example shows how to enable Cisco Express Forwarding for MLP configurations:
enable
configure terminal
ip cef
Creating a Multilink Bundle for MPLS—Multilink PPP Support: Example

The following example shows how to create a multilink bundle for the MPLS—Multilink PPP Support
feature:
interface multilink 1
ip address 10.0.0.0 10.255.255.255
encapsulation ppp
ppp chap hostname group 1
ppp multilink
multilink-group 1
The following sections provide references related to the MPLS—Multilink PPP Support feature:
Related Documents
Description of commands associated with MPLS and Cisco IOS Multiprotocol Label Switching Command Reference
MPLS applications
Basic MPLS VPNs Configuring MPLS Layer 3 VPNs
Standards
Standards Title
MIBs
MIBs MIBs Link
19
RFCs
RFCs Title
RFC 1990 The PPP Multilink Protocol (MP)
Description Link
20
Feature Information for MPLS—Multilink PPP Support
Feature Information for MPLS—Multilink PPP Support

Table 3 Feature Information for MPLS—Multilink PPP Support

MPLS—Multilink PPP Support Cisco IOS XE The MPLS—Multilink PPP Support feature ensures that MPLS
Release 2.1 Layer 3 Virtual Private Networks (VPNs) with quality of service
(QoS) can be enabled for bundled links. This feature supports
Multiprotocol Label Switching (MPLS) over Multilink PPP (MLP)
links in the edge (provider edge [PE]-to-customer edge [CE]) or in the
MPLS core (PE-to-PE and PE-to-provider router [P]).
• Information About MPLS—Multilink PPP Support, page 2
• How to Configure MPLS—Multilink PPP Support, page 7
21
Glossary
Glossary
bundle—A group of interfaces connected by parallel links between two systems that have agreed to use
Multilink PPP (MLP) over those links.
CBWFQ—class-based weighted fair queueing. A queueing option that extends the standard Weighted
Fair Queueing (WFQ) functionality to provide support for user-defined traffic classes.
Cisco Express Forwarding—A proprietary form of switching that optimizes network performance and
scalability for networks with large and dynamic traffic patterns, such as the Internet, and for networks
characterized by intensive web-based applications or interactive sessions. Although you can use
Cisco Express Forwarding in any part of a network, it is designed for high-performance, highly resilient
Layer 3 IP backbone switching.
EIGRP—Enhanced Interior Gateway Routing Protocol. An advanced version of the Interior Gateway
Routing Protocol (IGRP) developed by Cisco. It provides superior convergence properties and operating
efficiency, and combines the advantages of link-state protocols with those of distance vector protocols.
IGP—Interior Gateway Protocol. An Internet protocol used to exchange routing information within an
autonomous system. Examples of common Internet IGPs include Interior Gateway Routing Protocol
(IGRP), Open Shortest Path First (OSPF), and Routing Information Protocol (RIP).
IGRP—Interior Gateway Routing Protocol. An Interior Gateway Protocol (IGP) developed by Cisco to
address the issues associated with routing in large, heterogeneous networks. Compare with Enhanced
Interior Gateway Routing Protocol (EIGRP).
IS-IS—Intermediate System-to-Intermediate System. An Open Systems Interconnection (OSI)
link-state hierarchical routing protocol, based on DECnet Phase V routing, in which IS-IS routers
exchange routing information based on a single metric to determine network topology.
LCP—Link Control Protocol. A protocol that establishes, configures, and tests data link connections for
use by PPP.
LFI—link fragmentation and interleaving. The Cisco IOS XE LFI feature reduces delay on slower-speed
links by breaking up large datagrams and interleaving low-delay traffic packets with the smaller packets
resulting from the fragmented datagram. LFI allows reserve queues to be set up so that Real-Time
Protocol (RTP) streams can be mapped into a higher priority queue in the configured weighted fair queue
set.
link—One of the interfaces in a bundle.
LLQ—low latency queueing. A quality of service QoS queueing feature that provides a strict priority
queue (PQ) for voice traffic and weighted fair queues for other classes of traffic. It is also called priority
queueing/class-based weighted fair queueing (PQ/CBWFQ).
MLP—Multilink PPP. A method of splitting, recombining, and sequencing datagrams across multiple
logical links. The use of MLP increases throughput between two sites by grouping interfaces and then
load balancing packets over the grouped interfaces (called a bundle). Splitting packets at one end,
sending them over the bundled interfaces, and recombining them at the other end achieves load
balancing.
MQC—Modular QoS CLI. MQC is a CLI structure that allows users to create traffic polices and attach
these polices to interfaces. MQC allows users to specify a traffic class independently of QoS policies.
NCP—Network Control Protocol. A series of protocols for establishing and configuring different
network layer protocols (such as for AppleTalk) over PPP.
OSPF—Open Shortest Path First. A link-state, hierarchical Interior Gateway Protocol (IGP) routing
algorithm proposed as a successor to Routing Information Protocol (RIP) in the Internet community.
OSPF features include least-cost routing, multipath routing, and load balancing. OSPF was derived from
an early version of the IS-IS protocol.
22
Glossary
PPP—Point-to-Point Protocol. A successor to the Serial Line Interface Protocol (SLIP) that provides
router-to-router and host-to-network connections over synchronous and asynchronous circuits. PPP
works with several network layer protocols (such as IP, Internetwork Packet Exchange [IPX], and
AppleTalk Remote Access [ARA]). PPP also has built-in security mechanisms (such as Challenge
Handshake Authentication Protocol [CHAP] and Password Authentication Protocol [PAP]). PPP relies
on two protocols: Link Control Protocol (LCP) and Network Control Protocol (NCP).
RIP—Routing Information Protocol. A version of Interior Gateway Protocol (IGP) that is supplied with
UNIX Berkeley Standard Distribution (BSD) systems. Routing Information Protocol (RIP) is the most
common IGP in the Internet. It uses hop count as a routing metric.
Virtual Bundle Interface—An interface that represents the master link of a bundle. It is not tied to any
physical interface. Data going over the bundle is transmitted and received through the master link.
WFQ—weighted fair queueing. A congestion management algorithm that identifies conversations (in
the form of traffic streams), separates packets that belong to each conversation, and ensures that capacity
is shared fairly among the individual conversations. WFQ is an automatic way of stabilizing network
behavior during congestion and results in improved performance and reduced retransmission.
WRED—weighted random early detection. A queueing method that ensures that high-precedence traffic
has lower loss rates than other traffic during times of congestion.
countries.
coincidental.
23
Glossary
24
MPLS Label Distribution Protocol
MPLS Label Distribution Protocol (LDP)
First Published: January 1, 1999

MPLS Label Distribution Protocol (LDP) enables peer label switch routers (LSRs) in an Multiprotocol
Label Switching (MPLS) network to exchange label binding information for supporting hop-by-hop
forwarding in an MPLS network. This module explains the concepts related to MPLS LDP and describes
how to configure MPLS LDP in a network.

which each feature is supported, see the “Feature Information for MPLS Label Distribution Protocol” section
on page 25.
Contents
• Prerequisites for MPLS Label Distribution Protocol, page 2
• Information About MPLS Label Distribution Protocol, page 2
• How to Configure MPLS Label Distribution Protocol, page 5
• Configuration Examples for MPLS Label Distribution Protocol, page 19
• Feature Information for MPLS Label Distribution Protocol, page 25
Prerequisites for MPLS Label Distribution Protocol
Prerequisites for MPLS Label Distribution Protocol

Label switching on a router requires that Cisco Express Forwarding (CEF) be enabled on that router.
Information About MPLS Label Distribution Protocol

To configure MPLS LDP, you should understand the following concepts:
• Introduction to MPLS Label Distribution Protocol, page 2
• MPLS Label Distribution Protocol Functional Overview, page 2
• Introduction to LDP Sessions, page 2
• Introduction to LDP Label Bindings, Label Spaces, and LDP Identifiers, page 4
Introduction to MPLS Label Distribution Protocol

MPLS LDP provides the means for LSRs to request, distribute, and release label prefix binding
information to peer routers in a network. LDP enables LSRs to discover potential peers and to establish
LDP sessions with those peers for the purpose of exchanging label binding information.
MPLS LDP enables one LSR to inform another LSR of the label bindings it has made. Once a pair of
routers communicate the LDP parameters, they establish a label switched path (LSP). MPLS LDP
enables LSRs to distribute labels along normally routed paths to support MPLS forwarding. This method
of label distribution is also called hop-by-hop forwarding. With IP forwarding, when a packet arrives at
a router the router looks at the destination address in the IP header, performs a route lookup, and
forwards the packet to the next hop. With MPLS forwarding, when a packet arrives at a router the router
looks at the incoming label, looks up the label in a table, and then forwards the packet to the next hop.
MPLS LDP is useful for applications that require hop-by-hop forwarding, such as MPLS VPNs.
MPLS Label Distribution Protocol Functional Overview

Cisco MPLS LDP provides the building blocks for MPLS-enabled applications, such as MPS Virtual
Private Networks (VPNs).
LDP provides a standard methodology for hop-by-hop, or dynamic label, distribution in an MPLS
network by assigning labels to routes that have been chosen by the underlying Interior Gateway Protocol
(IGP) routing protocols. The resulting labeled paths, called label switch paths (LSPs), forward label
traffic across an MPLS backbone to particular destinations. These capabilities enable service providers
to implement MPLS-based IP VPNs and IP+ATM services across multivendor MPLS networks.
Introduction to LDP Sessions

When you enable MPLS LDP, the LSRs send out messages to try to find other LSRs with which they can
create LDP sessions. The following sections explain the differences between directly connected LDP
sessions and nondirectly connected LDP sessions.
2
Directly Connected MPLS LDP Sessions

If an LSR is one hop from its neighbor, it is directly connected to its neighbor. The LSR sends out LDP
link Hello messages as User Datagram Protocol (UDP) packets to all the routers on the subnet
(multicast). A neighboring LSR may respond to the link Hello message, allowing the two routers to
establish an LDP session. This is called basic discovery.
To initiate an LDP session between routers, the routers determine which router will take the active role
and which router will take the passive role. The router that takes the active role establishes the LDP TCP
connection session and initiates the negotiation of the LDP session parameters. To determine the roles,
the two routers compare their transport addresses. The router with the higher IP address takes the active
role and establishes the session.
After the LDP TCP connection session is established, the LSRs negotiate the session parameters,
including the method of label distribution to be used. Two methods are available:
• Downstream Unsolicited: An LSR advertises label mappings to peers without being asked to.
• Downstream on Demand: An LSR advertises label mappings to a peer only when the peer asks for
them.
For information about creating LDP sessions, see the “Enabling Directly Connected LDP Sessions”
section on page 5.
Nondirectly Connected MPLS LDP Sessions

If the LSR is more than one hop from its neighbor, it is nondirectly connected to its neighbor. For these
nondirectly connected neighbors, the LSR sends out a targeted Hello message as a UDP packet, but as a
unicast message specifically addressed to that LSR. The nondirectly connected LSR responds to the
Hello message and the two routers begin to establish an LDP session. This is called extended discovery.
An MPLS LDP targeted session is a label distribution session between routers that are not directly
connected. When you create an MPLS traffic engineering tunnel interface, you need to establish a label
distribution session between the tunnel headend and the tailend routers. You establish nondirectly
connected MPLS LDP sessions by enabling the transmission of targeted Hello messages.
You can use the mpls ldp neighbor targeted command to set up a targeted session when other means
of establishing targeted sessions do not apply, such as configuring mpls ip on a traffic engineering (TE)
tunnel or configuring Any Transport over MPLS (AToM) virtual circuits (VCs). For example, you can
use this command to create a targeted session between directly connected MPLS label switch routers
(LSRs) when MPLS label forwarding convergence time is an issue.
The mpls ldp neighbor targeted command can improve label convergence time for directly connected
neighbor LSRs when the links directly connecting them are down. When the links between the neighbor
LSRs are up, both the link and targeted Hellos maintain the LDP session. If the links between the
neighbor LSRs go down, and there is an alternate route between neighbors, the targeted Hellos would
maintain the session, allowing the LSRs to retain labels learned from each other. When a link directly
connecting the LSRs comes back up, the LSRs can immediately reinstall labels for forwarding use
without having to reestablish their LDP session and exchange labels.
3
The exchange of targeted Hello messages between two nondirectly connected neighbors can occur in
several ways, including the following:
• Router 1 sends targeted Hello messages carrying a response request to Router 2. Router 2 sends
targeted Hello messages in response if its configuration permits. In this situation, Router 1 is
considered to be active and Router 2 is considered to be passive.
• Router 1 and Router 2 both send targeted Hello messages to each other. Both routers are considered
to be active. Both, one, or neither router can also be passive, if they have been configured to respond
to requests for targeted Hello messages from each other.
The default behavior of an LSR is to ignore requests from other LSRs that send targeted Hello messages.
You can configure an LSR to respond to requests for targeted Hello messages by issuing the mpls ldp
discovery targeted-hello accept command.
The active LSR mandates the protocol that is used for a targeted session. The passive LSR uses the
protocol of the received targeted Hello messages.
For information about creating MPLS LDP targeted sessions, see the “Establishing Nondirectly
Connected MPLS LDP Sessions” section on page 8.
Introduction to LDP Label Bindings, Label Spaces, and LDP Identifiers

An LDP label binding is an association between a destination prefix and a label. The label used in a label
binding is allocated from a set of possible labels called a label space.
LDP supports two types of label spaces:
• Interface-specific—An interface-specific label space uses interface resources for labels. For
example, label-controlled ATM (LC-ATM) interfaces use virtual path identifiers/virtual circuit
identifiers (VPIs/VCIs) for labels. Depending on its configuration, an LDP platform may support
zero, one, or more interface-specific label spaces.
• Platform-wide—An LDP platform supports a single platform-wide label space for use by interfaces
that can share the same labels. For Cisco platforms, all interface types, except LC-ATM, use the
platform-wide label space.
LDP uses a 6-byte quantity called an LDP Identifier (or LDP ID) to name label spaces. The LDP ID is
made up of the following components:
• The first four bytes, called the LPD router ID, identify the LSR that owns the label space.
• The last two bytes, called the local label space ID, identify the label space within the LSR. For the
platform-wide label space, the last two bytes of the LDP ID are always both 0.
The LDP ID takes the following form:
<LDP router ID> : <local label space ID>
The following are examples of LPD IDs:
• 172.16.0.0:0
• 192.168.0.0:3
The router determines the LDP router ID as follows, if the mpls ldp router-id command is not executed,
1. The router examines the IP addresses of all operational interfaces.
2. If these IP addresses include loopback interface addresses, the router selects the largest loopback
address as the LDP router ID.
4
How to Configure MPLS Label Distribution Protocol
3. Otherwise, the router selects the largest IP address pertaining to an operational interface as the LDP
router ID.
The normal (default) method for determining the LDP router ID may result in a router ID that is not
usable in certain situations. For example, the router might select an IP address as the LDP router ID that
the routing protocol cannot advertise to a neighboring router. The mpls ldp router-id command allows
you to specify the IP address of an interface as the LDP router ID. Make sure the specified interface is
operational so that its IP address can be used as the LDP router ID.
When you issue the mpls ldp router-id command without the force keyword, the router select selects
the IP address of the specified interface (provided that the interface is operational) the next time it is
necessary to select an LDP router ID, which is typically the next time the interface is shut down or the
address is configured.
When you issue the mpls ldp router-id command with the force keyword, the effect of the mpls ldp
router-id command depends on the current state of the specified interface:
• If the interface is up (operational) and if its IP address is not currently the LDP router ID, the LDP
router ID changes to the IP address of the interface. This forced change in the LDP router ID tears
down any existing LDP sessions, releases label bindings learned via the LDP sessions, and interrupts
MPLS forwarding activity associated with the bindings.
• If the interface is down (not operational) when the mpls ldp router-id force command is issued,
when the interface transitions to up, the LDP router ID changes to the IP address of the interface.
This forced change in the LDP router ID tears down any existing LDP sessions, releases label
bindings learned via the LDP sessions, and interrupts MPLS forwarding activity associated with the
bindings.

This section contains the following procedures:
• Enabling Directly Connected LDP Sessions, page 5 (required)
• Establishing Nondirectly Connected MPLS LDP Sessions, page 8 (optional)
• Specifying the LDP Router ID, page 10 (optional)
• Preserving QoS Settings with MPLS LDP Explicit Null, page 12 (optional)
• Protecting Data Between LDP Peers with MD5 Authentication, page 16 (optional)
Enabling Directly Connected LDP Sessions

This procedure explains how to configure MPLS LDP sessions between two directly connected routers.
SUMMARY STEPS
1. enable
3. mpls ip
4. mpls label protocol ldp
5. interface type slot/subslot/port[.subinterface-number]
6. mpls ip
5
7. exit
8. exit
9. show mpls interfaces [interface] [detail]
10. show mpls ldp discovery [all | vrf vpn-name] [detail]
11. show mpls ldp neighbor [[vrf vpn-name] [address | interface] [detail] | all]
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls ip Configures MPLS hop-by-hop forwarding globally.
• The mpls ip command is enabled by default; you do not
Example: have to specify this command.
Router(config)# mpls ip
• Globally enabling MPLS forwarding does not enable it
on the router interfaces. You must enable MPLS
forwarding on the interfaces as well as for the router.
Step 4 mpls label protocol ldp Configures the use of LDP on all interfaces.
Example:
Router(config)# mpls label protocol ldp
Step 5 Router(config)# interface type Specifies the interface to be configured and enters interface
slot/subslot/port[.subinterface-number] configuration mode.
Example:
Router(config)# interface fastethernet03/0
Step 6 mpls ip Configures MPLS hop-by-hop forwarding on the interface.
• You must enable MPLS forwarding on the interfaces as
Example: well as for the router.
Router(config-if)# mpls ip
Step 7 exit Exits interface configuration mode and enters global
configuration mode.
Example:
Router(config-if)# exit
Step 8 exit Exits global configuration mode and enters privileged
EXEC mode.
Example:
6

Step 9 show mpls interfaces [interface] [detail] Verifies that the interfaces have been configured to use
LDP,.
Example:
Router# show mpls interfaces
Step 10 show mpls ldp discovery [all | vrf vpn-name] Verifies that the interface is up and is sending Discovery
[detail] Hello messages.
Example:
Router# show mpls ldp discovery
Step 11 show mpls ldp neighbor [[vrf vpn-name] [address Displays the status of LDP sessions.
| interface] [detail] | all]
Example:
Router# show mpls ldp neighbor
Examples
The following show mpls interfaces command verifies that interfaces FastEthernet 0/3/0 and 0/3/1 have
been configured to use LDP:
Router# show mpls interfaces
Interface IP Tunnel BGP Static Operational

FastEthernet0/3/0 Yes (ldp) No No No Yes
FastEthernet0/3/1 Yes No No No Yes
The following show mpls ldp discovery command verifies that the interface is up and is sending LDP
Discovery Hello messages (as opposed to TDP Hello messages):
Local LDP Identifier:

172.16.12.1:0
Discovery Sources:
Interfaces:
FastEthernet0/3/0 (ldp): xmit
The following example shows that the LDP session between routers was successfully established:
Peer LDP Ident: 10.1.1.2:0; Local LDP Ident 10.1.1.1:0

TCP connection: 10.1.1.2.18 - 10.1.1.1.66
State: Oper; Msgs sent/rcvd: 12/11; Downstream
Up time: 00:00:10
LDP discovery sources:
FastEthernet0/1/0, Src IP addr: 10.20.10.2
Addresses bound to peer LDP Ident:
10.1.1.2 10.20.20.1 10.20.10.2
For examples on configuring directly connected LDP sessions, see the “Configuring Directly Connected
MPLS LDP Sessions: Example” section on page 19.
7
Establishing Nondirectly Connected MPLS LDP Sessions

This section explains how to configure nondirectly connected MPLS LDP sessions, which enable you to
establish an LDP session between routers that are not directly connected.
Prerequisites
• MPLS requires Cisco Express Forwarding.
• You must configure the routers at both ends of the tunnel to be active or enable one router to be
passive with the mpls ldp discovery targeted-hello accept command.
SUMMARY STEPS
1. enable
3. mpls ip
5. interface tunnel number
6. tunnel destination ip-address
7. mpls ip
8. exit
9. exit
10. show mpls ldp discovery [all | vrf vpn-name] [detail]
DETAILED STEPS

Example:
Router> enable
Example:
8

Example:
Step 5 interface tunnel number Configures a tunnel interface and enters interface
configuration mode.
Example:
Router(config)# interface tunnel1
Step 6 tunnel destination ip-address Assigns an IP address to the tunnel interface.
Example:
Router(config-if)# tunnel destination
172.16.1.1
configuration mode.
Example:
EXEC mode.
Example:
Step 10 show mpls ldp discovery [all | vrf vpn-name] Verifies that the interface is up and is sending Discovery
[detail] Hello messages.
Example:
Examples
The following example shows the output of the show mpls ldp discovery command for a nondirectly
connected LDP session:

172.16.0.0:0
Discovery Sources:
Interfaces:
POS1/2/0 (ldp): xmit/recv
LDP Id: 172.31.255.255:0
Tunnel1 (ldp): Targeted -> 192.168.255.255
Targeted Hellos:
172.16.0.0 -> 192.168.255.255 (ldp): active, xmit/recv
LDP Id: 192.168.255.255:0
172.16.0.0 -> 192.168.0.0 (ldp): passive, xmit/recv
LDP Id: 192.168.0.0:0
9
This command output indicates that:

• The local LSR (172.16.0.0) sent LDP link Hello messages on interface POS1/2/0 and discovered
neighbor 172.31.255.255.
• The local LSR sent LDP targeted Hello messages associated with interface Tunnel1 to target
192.168.255.255. The LSR was configured to use LDP.
• The local LSR is active for targeted discovery activity with 192.168.255.255; this means that the
targeted Hello messages it sends to 192.168.255.255 carry a response request. The local LSR was
configured to have an LDP session with the nondirectly connected LSR 192.168.255.255.
• The local LSR is not passive from the discovery activity with 192.168.255.255 for one of the
following reasons:
– The targeted Hello messages it receives from 192.168.255.255 do not carry a response request.
– The local LSR has not been configured to respond to such requests.
• The local LSR sent TDP directed Hello messages to the target LSR 192.168.0.0. This LSR uses TDP
because the Hello messages received from the target LSR 192.168.0.0 were TDP directed Hello
messages.
• The local LSR is passive in discovery activity with LSR 192.168.0.0. This means that the directed
Hello messages it receives from LSR 192.168.0.0 carry a response request and that the local LSR
has been configured with the mpls ldp discovery targeted-hello accept command to respond to
such requests from LSR 192.168.0.0.
• The local LSR is not active in discovery activity with LSR 192.168.0.0, because no application that
requires an LDP session with LSR 192.168.0.0 has been configured on the local LSR.
For examples of configuring LDP targeted sessions, see the “Establishing Nondirectly Connected MPLS
LDP Sessions: Example” section on page 20.
Specifying the LDP Router ID

The mpls ldp router-id command allows you to establish the IP address of an interface as the LDP router
ID.
Normal Process for Determining the LDP Router ID

The following steps describe the normal process for determining the LDP router ID:
1. The router considers all the IP addresses of all operational interfaces.
2. If these addresses include loopback interface addresses, the router selects the largest loopback
address. Configuring a loopback address helps ensure a stable LDP ID for the router, because the
state of loopback addresses does not change. However, configuring a loopback interface and
IP address on each router is not required.
The loopback IP address does not become the router ID of the local LDP ID under the following
circumstances:
– If the loopback interface has been explicitly shut down.
– If the mpls ldp router-id command specifies that a different interface should be used as the
LDP router ID.
10
If you use a loopback interface, make sure that the IP address for the loopback interface is
configured with a /32 network mask. In addition, make sure that the routing protocol in use is
configured to advertise the corresponding /32 network.
3. Otherwise, the router selects the largest interface address.
The router might select a router ID that is not usable in certain situations. For example, the router might
select an IP address that the routing protocol cannot advertise to a neighboring router.
The router implements the router ID the next time it is necessary to select an LDP router ID. The effect
of the command is delayed until the next time it is necessary to select an LDP router ID, which is
typically the next time the interface is shut down or the address is deconfigured.
If you use the force keyword with the mpls ldp router-id command, the router ID takes effect more
quickly. However, implementing the router ID depends on the current state of the specified interface:
• If the interface is up (operational) and its IP address is not currently the LDP router ID, the LDP
router ID is forcibly changed to the IP address of the interface. This forced change in the LDP router
ID tears down any existing LDP sessions, releases label bindings learned via the LDP sessions, and
interrupts MPLS forwarding activity associated with the bindings.
• If the interface is down, the LDP router ID is forcibly changed to the IP address of the interface when
the interface transitions to up. This forced change in the LDP router ID tears down any existing LDP
sessions, releases label bindings learned via the LDP sessions, and interrupts MPLS forwarding
activity associated with the bindings.
Prerequisites
Make sure the specified interface is operational before assigning it as the LDP router ID.
SUMMARY STEPS
1. enable
3. mpls ip
4. mpls label protocol {ldp | tdp | both}
5. mpls ldp router-id interface [force]
6. exit
7. show mpls ldp discovery [all | detail | vrf vpn-name]
DETAILED STEPS

Example:
Router> enable
Example:
11

Step 4 mpls label protocol ldp Configures the use of LDP on all interfaces. configuration
mode.
Example:
Step 5 mpls ldp router-id interface [force] Specifies the preferred interface for determining the LDP
router ID.
Example:
Router(config)# mpls ldp router-id pos2/0/0
EXEC mode.
Example:
Step 7 show mpls ldp discovery [all | detail |vrf Displays the LDP identifier for the local router.
vpn-name]
Example:
Example
The following example assigns interface pos2/0/0 as the LDP router ID:
Router> enable
Router(config)# mpls ldp router-id pos2/0/0 force
The following example displays the LDP router ID (10.15.15.15):


10.15.15.15:0
Discovery Sources:
Interfaces:
FastEthernet0/3/0 (ldp): xmit/recv
LDP Id: 10.14.14.14:0
Preserving QoS Settings with MPLS LDP Explicit Null

Normally, LDP advertises an Implicit Null label for directly connected routes. The Implicit Null label
causes the second last (penultimate) label switched router (LSR) to remove the MPLS header from the
packet. In this case, the penultimate LSR and the last LSR do not have access to the quality of service
12
(QoS) values that the packet carried before the MPLS header was removed. To preserve the QoS values,
you can configure the LSR to advertise an explicit NULL label (a label value of zero). The LSR at the
penultimate hop forwards MPLS packets with a NULL label instead of forwarding IP packets.
Note An explicit NULL label is not needed when the penultimate hop receives MPLS packets with a label
stack that contains at least two labels and penultimate hop popping is performed. In that case, the inner
label can still carry the QoS value needed by the penultimate and edge LSR to implement their QoS
policy.
When you issue the mpls ldp explicit-null command, Explicit Null is advertised in place of Implicit
Null for directly connected prefixes.
SUMMARY STEPS
1. enable
3. mpls ip
6. mpls ip
7. exit
8. mpls ldp explicit-null [for prefix-acl | to peer-acl | for prefix-acl to peer-acl]
9. exit
10. show mpls forwarding-table [network {mask | length} | labels label [- label] | interface interface
| next-hop address | lsp-tunnel [tunnel-id]] [vrf vpn-name] [detail]
DETAILED STEPS

Example:
Router> enable
Example:
13

Example:
Step 5 interface type Specifies the interface to be configured and enters interface
Example:
Router(config)# interface atm2/2/0
configuration mode.
Example:
Step 8 mpls ldp explicit-null [for prefix-acl | to Advertises an Explicit Null label in situations where it
peer-acl | for prefix-acl to peer-acl] would normally advertise an Implicit Null label.
Example:
Router(config)# mpls ldp explicit-null
Step 9 exit Exits global configuration mode and enter privileged EXEC
mode.
Example:
Step 10 show mpls forwarding-table [network {mask | Verifies that MPLS packets are forwarded with an
length} | labels label [- label] | interface explicit-null label (value of 0).
interface | next-hop address | lsp-tunnel
[tunnel-id]] [vrf vpn-name] [detail]
Example:
Examples
Enabling explicit-null on an egress LSR causes that LSR to advertise the explicit-null label to all
adjacent MPLS routers.
Router(config)# mpls ldp explicit-null
If you issue the show mpls forwarding-table command on an adjacent router, the output shows that
MPLS packets are forwarded with an explicit-null label (value of 0). In the following example, the
second column shows that entries have outgoing labels of 0, where once they were marked “Pop label”.
Local Outgoing Prefix Bytes label Outgoing Next Hop

label label or VC or Tunnel Id switched interface
14
19 Pop tag 10.12.12.12/32 0 Fa2/1/0 172.16.0.1

22 0 10.14.14.14/32 0 Fa2/0/0 192.168.0.2
23 0 172.24.24.24/32 0 Fa2/0/0 192.168.0.2
24 0 192.168.0.0/8 0 Fa2/0/0 192.168.0.2
25 0 10.15.15.15/32 0 Fa2/0/0 192.168.0.2
26 0 172.16.0.0/8 0 Fa2/0/0 192.168.0.2
27 25 10.16.16.16/32 0 Fa2/0/0 192.168.0.22
28 0 10.34.34.34/32 0 Fa2/0/0 192.168.0.2
Enabling explicit-null and specifying the for keyword with a standard access control list (ACL) changes
all adjacent MPLS routers' tables to swap an explicit-null label for only those entries specified in the
access-list. In the following example, an access-list is created that contains the 10.24.24.24/32 entry.
Explicit null is configured and the access list is specified.
Router(config)# access-list 24 permit host 10.24.24.24
Router(config)# mpls ldp explicit-null for 24
If you issue the show mpls forwarding-table command on an adjacent router, the output shows that the
only the outgoing labels for the addresses specified (172.24.24.24/32) change from Pop label to 0. All
other Pop label outgoing labels remain the same.

19 Pop tag 10.12.12.12/32 0 Fa2/1/0 172.16.0.1
22 0 10.14.14.14/32 0 Fa2/0/0 192.168.0.2
23 0 172.24.24.24/32 0 Fa2/0/0 192.168.0.2
24 0 192.168.0.0/8 0 Fa2/0/0 192.168.0.2
25 0 10.15.15.15/32 0 Fa2/0/0 192.168.0.2
26 0 172.16.0.0/8 0 Fa2/0/0 192.168.0.2
27 25 10.16.16.16/32 0 Fa2/0/0 192.168.0.22
28 0 10.34.34.34/32 0 Fa2/0/0 192.168.0.2
Enabling explicit null and adding the to keyword and an access list enables you to advertise explicit-null
labels to only those adjacent routers specified in the access-list.To advertise explicit-null to a particular
router, you must specify the router's LDP ID in the access-list.
In the following example, an access-list contains the 10.15.15.15/32 entry, which is the LDP ID of an
adjacent MPLS router. The router that is configured with explicit null advertises explicit-null labels only
to that adjacent router.

10.15.15.15:0
Discovery Sources:
Interfaces:
FastEthernet2/0/0(ldp): xmit/recv
TDP Id: 10.14.14.14:0

Router(config)# access-list 15 permit host 10.15.15.15
Router(config)# mpls ldp explicit-null to 15
If you issue the show mpls forwarding-table command, the output shows that explicit null labels are
going only to the router specified in the access list.
15

19 Pop tag 10.12.12.12/32 0 Fa2/1/0 172.16.0.1
22 0 10.14.14.14/32 0 Fa2/0/0 192.168.0.2
23 0 172.24.24.24/32 0 Fa2/0/0 192.168.0.2
24 0 192.168.0.0/8 0 Fa2/0/0 192.168.0.2
25 0 10.15.15.15/32 0 Fa2/0/0 192.168.0.2
26 0 172.16.0.0/8 0 Fa2/0/0 192.168.0.2
27 25 10.16.16.16/32 0 Fa2/0/0 192.168.0.22
28 0 10.34.34.34/32 0 Fa2/0/0 192.168.0.2
Enabling explicit-null with both the for and to keywords enables you to specify which routes to advertise
with explicit-null labels and to which adjacent routers to advertise these explicit-null labels.
Router# show access 15
Standard IP access list 15

permit 10.15.15.15 (7 matches)
Router# show access 24

permit 10.24.24.24 (11 matches)

Router(config)# mpls ldp explicit-null for 24 to 15
If you issue the show mpls forwarding-table command, the output shows that it receives explicit null
labels for 10.24.24.24/32.

17 0 <--- 10.24.24.24/32 0 Fe2/0/0 172.16.0.1
20 Pop tag 172.16.0.0/8 0 Fe2/0/0 172.16.0.1
21 20 10.12.12.12/32 0 Fe2/0/0 172.16.0.1
22 16 10.0.0.0/8 0 Fe2/0/0 172.16.0.1
23 21 10.13.13.13/32 0 Fe2/0/0 172.16.0.1
25 Pop tag 10.14.14.14/32 0 Fe2/0/0 172.16.0.1
27 Pop tag 192.168.0.0/8 0 Fe2/0/0 172.16.0.1
28 25 10.16.16.16/32 0 Fe2/0/0 172.16.0.1
29 Pop tag 192.168.34.34/32 0 Fe2/0/0 172.16.0.1
Protecting Data Between LDP Peers with MD5 Authentication

You can enable authentication between two LDP peers, which verifies each segment sent on the TCP
connection between the peers. You must configure authentication on both LDP peers using the same
password; otherwise, the peer session is not established.
Authentication uses the Message Digest 5 (MD5) algorithm to verify the integrity of the communication
and authenticate the origin of the message.
To enable authentication, issue the mpls ldp neighbor command with the password keyword. This
causes the router to generate an MD5 digest for every segment sent on the TCP connection and check
the MD5 digest for every segment received from the TCP connection.
16
When you configure a password for an LDP neighbor, the router tears down existing LDP sessions and
establishes new sessions with the neighbor.
If a router has a password configured for a neighbor, but the neighboring router does not have a password
configured, a message such as the following appears on the console who has a password configured
while the two routers attempt to establish an LDP session. The LDP session is not established.
%TCP-6-BADAUTH: No MD5 digest from [peer's IP address](11003) to [local router's IP
address](646)
Similarly, if the two routers have different passwords configured, a message such as the following
appears on the console. The LDP session is not established.
%TCP-6-BADAUTH: Invalid MD5 digest from [peer's IP address](11004) to [local router's IP
address](646)
SUMMARY STEPS
1. enable
3. mpls ip
5. mpls ldp neighbor [vrf vpn-name] ip-address [password [0-7] password-string]
6. show mpls ldp neighbor [[vrf vpn-name] [address | interface] [detail] | all]
DETAILED STEPS

Example:
Router> enable
Example:
Example:
17

Step 5 mpls ldp neighbor [vrf vpn-name] ip-address Specifies authentication between two LDP peers.
[password [0-7] password-string]
Example:
Router(config)# mpls ldp neighbor 172.27.0.15
password onethirty9
EXEC mode.
Example:
Step 7 show mpls ldp neighbor [[vrf vpn-name] [address Displays the status of LDP sessions.
| interface] [detail] | all]
If the passwords have been set on both LDP peers and the
passwords match, the show mpls ldp neighbor command
Example: displays that the LDP session was successfully established.
Router# show mpls ldp neighbor detail
Examples
The following example configures a router with the password cisco:
Router> enable
Router(config)# mpls ldp neighbor 10.1.1.1 password cisco
The following example shows that the LDP session between routers was successfully established:

TCP connection: 10.1.1.2.11118 - 10.1.1.1.646
Up time: 00:00:10
FastEthernet1/0/0, Src IP addr: 10.20.10.2
10.1.1.2 10.20.20.1 10.20.10.2
The following show mpls ldp neighbor detail command shows that MD5 (shown in bold) is used for
the LDP session.
Router# show mpls ldp neighbor 10.0.0.21 detail

TCP connection: 10.0.0.21.646 - 10.0.0.22.14709; MD5 on
State: Oper; Msgs sent/rcvd: 1020/1019; Downstream; Last TIB rev sent 2034
Up time: 00:00:39; UID: 3; Peer Id 1;
FastEthernet1/1/0; Src IP addr: 172.16.1.1
holdtime: 15000 ms, hello interval: 5000 ms
10.0.0.21 10.0.38.28 10.88.88.2 172.16.0.1
172.16.1.1
Peer holdtime: 180000 ms; KA interval: 60000 ms; Peer state: estab
18
Configuration Examples for MPLS Label Distribution Protocol

This section includes the following configuration examples:
• Configuring Directly Connected MPLS LDP Sessions: Example, page 19
• Establishing Nondirectly Connected MPLS LDP Sessions: Example, page 20
Configuring Directly Connected MPLS LDP Sessions: Example

Figure 1 shows a sample network for configuring directly connected LDP sessions.
This example configures the following:
• MPLS hop-by-hop forwarding for the POS links between Router 1 and Router 2 and between
Router 1 and Router 3.
• LDP for label distribution between Router 1 and Router 2.
• TDP for label distribution between Router 1 and Router 3.
• A loopback interface and IP address for each LSR that can be used as the LDP router ID.
Figure 1 Configuration of MPLS LDP
Router 2
POS2/0/0
10.0.0.33
POS0/3/0
10.0.0.44
Router 1
POS1/3/0
192.168.0.44/0
Router 3
192760
POS1/0/0
192.168.0.55
Note The configuration examples below show only the commands related to configuring LDP for Router 1,
Router 2, and Router 3 in the sample network shown in Figure 1.
Router 1 Configuration
ip cef distributed !Assumes R1 supports distributed CEF
interface Loopback0 !Loopback interface for LDP ID.
ip address 172.16.0.11 255.255.255.255
!
interface POS0/3/0
ip address 10.0.0.44 255.0.0.0
mpls ip !Enable hop-by-hop MPLS forwarding
19

!
interface POS1/3/0
ip address 192.168.0.44 255.0.0.0
ip cef distributed !Assumes R2 supports distributed CEF
!
ip address 172.16.0.22 255.255.255.255
!
interface POS2/0/0
ip address 10.0.0.33 255.0.0.0
ip cef !Assumes R3 does not support dCEF
!
ip address 172.16.0.33 255.255.255.255
!
interface POS1/0/0
ip address 192.168.0.55 255.0.0.0
The LDP configuration for Router 1 uses the mpls label protocol ldp command in interface
configuration mode. To specify LDP for all interfaces, use the mpls label protocol ldp command in
global configuration mode without any interface mpls label protocol commands.
The configuration of Router 2 also uses the mpls label protocol ldp command in interface configuration
mode. To specify LDP for all interfaces, use the mpls label protocol ldp command in global
configuration mode without any interface mpls label protocol commands.
Configuring the mpls ip command on an interface triggers the transmission of discovery Hello messages
for the interface.
Establishing Nondirectly Connected MPLS LDP Sessions: Example

The following examples illustrate the configuration of platforms for MPLS LDP nondirectly connected
sessions using the sample network shown in Figure 2. Note that Routers 1, 4, 5, and 6 in this sample
network are not directly connected to each other.
20
Figure 2 Sample Network for Configuring LDP for Targeted Sessions
Router 4
10.11.0.4
Router 1 Router 6
10.11.0.1 MPLS network 10.11.0.6
10.11.0.5
41142
Router 5
The configuration example shows the following:

• Targeted sessions between Routers 1 and 4 use LDP. Routers 1 and 4 are both active.
• Targeted sessions between Routers 1 and 6 use LDP. Router 1 is active and Router 6 is passive.
• Targeted sessions between Routers 1 and 5 use LDP. Router 5 is active.
These examples assume that the active ends of the nondirectly connected sessions are associated with
tunnel interfaces, such as MPLS traffic engineering tunnels. They show only the commands related to
configuring LDP targeted sessions. The examples do not show configuration of the applications that
initiate the targeted sessions.
Tunnel interfaces Tunnel14 and Tunnel16 specify LDP for targeted sessions associated with these
interfaces. The targeted session for Router 5 requires TDP. The mpls label protocol ldp command in
global configuration mode makes it unnecessary to explicitly specify LDP as part of the configuration
from the Tunnel14 and Tunnel16.
ip cef distributed !Router1 supports distributed CEF
mpls label protocol ldp !Use LDP for all interfaces

ip address 10.25.0.11 255.255.255.255
interface Tunnel14 !Tunnel to Router 4 requiring label distribution

tunnel destination 10.11.0.4 !Tunnel endpoint is Router 4
mpls ip !Enable hop-by-hop forwarding on the interface

mpls label protocol ldp !Use LDP for session with Router 5

21
The mpls label protocol ldp command in global configuration mode makes it unnecessary to explicitly
specify LDP as part of the configuration for the Tunnel41 targeted session with Router 1.
ip cef distributed !Router 4 supports distributed CEF

ip address 10.25.0.44 255.255.255.255

Router 5 uses LDP for all targeted sessions. Therefore, its configuration includes the mpls label
protocol ldp command.
ip cef !Router 5 supports CEF

ip address 10.25.0.55 255.255.255.255

By default, a router cannot be a passive neighbor in targeted sessions. Therefore, Router 1, Router 4, and
Router 5 are active neighbors in any targeted sessions. The mpls ldp discovery targeted-hello accept
command permits Router 6 to be a passive target in targeted sessions with Router 1. Router 6 can also
be an active neighbor in targeted sessions, although the example does not include such a configuration.
ip cef distributed !Router 6 supports distributed CEF

ip address 10.25.0.66 255.255.255.255
mpls ldp discovery targeted-hellos accept from LDP_SOURCES

!Respond to requests for targeted hellos
!from sources permitted by acl LDP_SOURCES
ip access-list standard LDP_SOURCES !Define acl for targeted hello sources.

permit 10.11.0.1 !Accept targeted hello request from Router 1.
deny any !Deny requests from other sources.
22
The following sections provide references related to the MPLS Label Distribution Protocol feature.
Related Documents
Configures LDP on every interface associated with a MPLS LDP Autoconfiguration
specified IGP instance.
Ensures that LDP is fully established before the IGP MPLS LDP-IGP Synchronization
path is used for switching.
Allows ACLs to control the label bindings that an LSR MPLS LDP Inbound Label Binding Filtering
accepts from its peer LSRs.
Enables standard, SNMP-based network management MPLS Label Distribution Protocol MIB Version 8 Upgrade
of the label switching features in Cisco IOS XE release
software.
MPLS LDP commands Cisco IOS Multiprotocol Label Switching Command Reference
Standards
Standard Title
MIBs
MIB MIBs Link
• MPLS Label Distribution Protocol MIB To locate and download MIBs for selected platforms, Cisco IOS XE
(draft-ietf-mpls-ldp-mib-08.txt) software releases, and feature sets, use Cisco MIB Locator found at
the following URL:
• SNMP-VACM-MIB
The View-based Access Control Model (ACM) http://www.cisco.com/go/mib
MIB for SNMP
RFCs
RFC Title
RFC 3036 LDP Specification
23
Description Link
24
Feature Information for MPLS Label Distribution Protocol

Table 1 lists the features in this module and provides links to specific configuration information.
Table 1 Feature Information for MPLS Label Distribution Protocol

MPLS Label Distribution Cisco IOS XE MPLS Label Distribution Protocol (LDP) enables peer label switch
Protocol (LDP) Release 2.1 routers (LSRs) in an Multiprotocol Label Switching (MPLS) network
to exchange label binding information for supporting hop-by-hop
forwarding in an MPLS network. This module explains the concepts
related to MPLS LDP and describes how to configure MPLS LDP in a
network.
In Cisco IOS XE Release 2.1, this feature was implemented on the
Cisco ASR 1000 Series Aggregation Services Router.
• Introduction to MPLS Label Distribution Protocol, page 2
• MPLS Label Distribution Protocol Functional Overview, page 2
• Introduction to LDP Sessions, page 2
• Introduction to LDP Label Bindings, Label Spaces, and LDP
Identifiers, page 4
• Enabling Directly Connected LDP Sessions, page 5
• Establishing Nondirectly Connected MPLS LDP Sessions, page 8
• Specifying the LDP Router ID, page 10
• Preserving QoS Settings with MPLS LDP Explicit Null, page 12
• Protecting Data Between LDP Peers with MD5 Authentication,
page 16
The following commands were introduced or modified: debug mpls
atm-ldp failure, mpls label protocol (global configuration), mpls ldp
advertise-labels, mpls ldp discovery, mpls ldp neighbor
implicit-withdraw, mpls ldp neighbor targeted-session, mpls ldp
router-id.
25
countries.
coincidental.
26
MPLS LDP Session Protection
First Published: November 8, 2004

The MPLS LDP Session Protection feature provides faster Label Distribution Protocol (LDP)
convergence when a link recovers following an outage. MPLS LDP Session Protection protects an LDP
session between directly connected neighbors or an LDP session established for a traffic engineering
(TE) tunnel.

which each feature is supported, see the “Feature Information for MPLS LDP Session Protection” section on
page 12.
Contents
• Prerequisites for MPLS LDP Session Protection, page 2
• Restrictions for MPLS LDP Session Protection, page 2
• Information About MPLS LDP Session Protection, page 2
• How to Configure MPLS LDP Session Protection, page 3
• Configuration Examples for MPLS LDP Session Protection, page 7
• Feature Information for MPLS LDP Session Protection, page 12
Prerequisites for MPLS LDP Session Protection
Prerequisites for MPLS LDP Session Protection

Label switch routers (LSRs) must be able to respond to LDP targeted hellos. Otherwise, the LSRs cannot
establish a targeted adjacency. All routers that participate in MPLS LDP Session Protection must be
enabled to respond to targeted hellos. Both neighbor routers must be configured for session protection
or one router must be configured for session protection and the other router must be configured to
respond to targeted hellos.
Restrictions for MPLS LDP Session Protection

This feature is not supported under the following circumstances:
• With extended access lists
• With LC-ATM routers
Information About MPLS LDP Session Protection

Before you configure the MPLS LDP Session Protection feature, you should understand the following:
• How MPLS LDP Session Protection Works, page 2
• MPLS LDP Session Protection Customization, page 3
How MPLS LDP Session Protection Works

MPLS LDP Session Protection maintains LDP bindings when a link fails. MPLS LDP sessions are
protected through the use of LDP hello messages. When you enable MPLS LDP, the LSRs send messages
to find other LSRs with which they can create LDP sessions.
If the LSR is one hop from its neighbor, it is directly connected to its neighbor. The LSR sends out LDP
Hello messages as User Datagram Protocol (UDP) packets to all the routers on the subnet. The hello
message is called an LDP Link Hello. A neighboring LSR responds to the hello message and the two
routers begin to establish an LDP session.
If the LSR is more than one hop from its neighbor, it is not directly connected to its neighbor. The LSR
sends out a directed hello message as a UDP packet, but as a unicast message specifically addressed to
that specific LSR. The hello message is called an LDP Targeted Hello. The nondirectly connected LSR
responds to the Hello message and the two routers establish an LDP session. (If the path between two
LSRs has been traffic engineered and has LDP enabled, the LDP session between them is called a
targeted session.)
MPLS LDP Session Protection uses LDP Targeted Hellos to protect LDP sessions. For example, two
directly connected routers have LDP enabled and can reach each other through alternate IP routes in the
network. An LDP session that exists between two routers is called an LDP Link Hello Adjacency. When
MPLS LDP Session Protection is enabled, an LDP Targeted Hello Adjacency is also established for the
LDP session. If the link between the two routers fails, the LDP Link Adjacency also fails. However, if
the LDP peer is still reachable through IP, the LDP session stays up, because the LDP Targeted Hello
Adjacency still exists between the routers. When the directly connected link recovers, the session does
not need to be reestablished, and LDP bindings for prefixes do not need to be relearned.
2
How to Configure MPLS LDP Session Protection
MPLS LDP Session Protection Customization

You can modify MPLS LDP Session Protection by using keywords in the mpls ldp session protection
command. The following sections explain how to customize the feature:
• How Long an LDP Targeted Hello Adjacency Should Be Retained, page 3
• Which Routers Should Have MPLS LDP Session Protection, page 3
How Long an LDP Targeted Hello Adjacency Should Be Retained

The default behavior of the mpls ldp session protection command allows an LDP Targeted Hello
Adjacency to exist indefinitely following the loss of an LDP Link Hello Adjacency. You can issue the
duration keyword to specify the number of seconds (from 30 to 2,147,483) that the LDP Targeted Hello
Adjacency is retained after the loss of the LDP Link Hello Adjacency. When the link is lost, a timer
starts. If the timer expires, the LDP Targeted Hello Adjacency is removed.
Which Routers Should Have MPLS LDP Session Protection

The default behavior of the mpls ldp session protection command allows MPLS LDP Session
Protection for all neighbor sessions. You can issue either the vrf or for keyword to limit the number of
neighbor sessions that are protected:
• You can use the vrf keyword to select which VRF is to be protected, if the router is configured with
at least one VPN routing and forwarding (VRF) instance, You cannot specify more than one VRF
with the mpls ldp session protection command. To specify multiple VRFs, issue the command
multiple times.
• You can create an access list that includes several peer routers. You can specify that access list with
the for keyword to enable LDP Session Protection for the peer routers in the access control list.

This section explains how to configure and verify MPLS LDP Session Protection:
• Enabling MPLS LDP Session Protection, page 3 (required)
• Verifying MPLS LDP Session Protection, page 6 (optional)
Enabling MPLS LDP Session Protection

To enable MPLS LDP session protection, perform the following task.
SUMMARY STEPS
1. enable
3. ip cef distributed
4. interface loop back number
5. ip address prefix mask
3
6. exit
8. mpls ip
10. exit
11. mpls ldp session protection [vrf vpn-name] [for acl] [duration {infinite | seconds}]
12. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef distributed Configures distributed Cisco Express Forwarding.
Example:
Step 4 interface loopback number Configures a loopback interface and enters interface
configuration mode.
Example:
Router(config)# interface Loopback0
Step 5 ip address prefix mask Assigns an IP address to the loopback interface.
Example:
Router(config-if)# ip address 10.25.0.11
255.255.255.255
Example:
Router(config-if) exit
Step 7 interface type Specifies the interface to configure and enters interface
Example:
Router(config)# interface POS0/3/0
Step 8 mpls ip Configures MPLS hop-by-hop forwarding for a specified
interface.
Example:
4

Step 9 mpls label protocol ldp Configures the use of LDP on a specific interface or on all
interfaces.
Example: • In interface configuration mode, the command sets the
Router(config-if)# mpls label protocol ldp the label distribution protocol for the interface.
• In global configuration mode, the command sets all the
interfaces to LDP.
Step 10 exit Exits from interface configuration mode and returns to
global configuration mode.
Example:
Step 11 mpls ldp session protection [vrf vpn-name] [for Enables MPLS LDP session protection.
acl] [duration {infinite | seconds}]
• The vrf vpn-name keyword-argument pair protects
LDP sessions for a specified VRF.
Example:
Router(config)# mpls ldp session protection
• The for acl keyword-argument pair specifies a standard
IP access control list (ACL) of prefixes to be protected.
• The duration keyword specifies how long the router
should retain the LDP Targeted Hello Adjacency
following the loss of the LDP Link Hello Adjacency.
• The infinite keyword specifies that the LDP Targeted
Hello Adjacency should be retained forever after a link
is lost.
• The seconds argument specifies the time in seconds that
the LDP Targeted Hello Adjacency should be retained
after a link is lost. The valid range of values is 30 to
2,147,483 seconds.
The mpls ldp session protection command entered without
a keyword protects all LDP sessions.
Example:
Troubleshooting Tips
Use the clear mpls ldp neighbor command if you need to terminate an LDP session after a link goes
down. This is useful for situations where the link needs to be taken out of service or needs to be
connected to a different neighbor.
To enable the display of events related to MPLS LDP Session Protection, use the debug mpls ldp session
protection command.
5
Verifying MPLS LDP Session Protection

To verify that LDP Session Protection has been correctly configured, perform the following steps.
SUMMARY STEPS
1. enable
2. show mpls ldp discovery
3. show mpls ldp neighbor
4. show mpls ldp neighbor detail
5. exit
DETAILED STEPS
Step 1 enable
Use this command to enable privileged EXEC mode. Enter your password, if prompted. For example:
Router> enable
Router#
Step 2 show mpls ldp discovery

Use this command to verify that the output contains the term xmit/recv for the peer router. For example:

10.0.0.5:0
Discovery Sources:
Interfaces:
ATM50/1/0.5 (ldp): xmit/recv
LDP Id: 10.0.0.1:0
Targeted Hellos:
LDP Id: 10.0.0.3:0
Step 3 show mpls ldp neighbor

Use this command to verify that the targeted hellos are active. For example:

TCP connection: 10.0.0.3.646 - 10.0.0.5.11005
Up time: 21:09:56
Targeted Hello 10.0.0.5 -> 10.0.0.3, active
10.3.104.3 10.0.0.2 10.0.0.3
Step 4 show mpls ldp neighbor detail

Use this command to verify that the MPLS LDP Session Protection state is Ready or Protecting. If the
second last line of the output shows Incomplete, the Targeted Hello Adjacency is not up yet. For
example:
6
Configuration Examples for MPLS LDP Session Protection

TCP connection: 10.16.16.16.11013 - 10.15.15.15.646
Targeted Hello 10.15.15.15 -> 10.16.16.16, active, passive;
holdtime: infinite, hello interval: 10000 ms
10.0.0.2 10.16.16.16 10.101.101.101 11.0.0.1
Clients: Dir Adj Client
LDP Session Protection enabled, state: Protecting
duration: infinite
Step 5 exit
Use this command to exit to user EXEC. For example:
Router# exit
Router>

This section contains the following configuration example for MPLS LDP Session Protection:
• Configuring MPLS LDP Session Protection: Example, page 7
Configuring MPLS LDP Session Protection: Example

Figure 1 shows a sample configuration for MPLS LDP Session Protection.
Figure 1 MPLS LDP Session Protection Example
R1 R2 R3
fe2/1/2 fe0/1/1 fe0/1/2 fe1/2/0
fe2/0/2 fe1/3/0
192859
The following configuration examples for R1, R2, and R3 are based on Figure 1.
R1
redundancy
no keepalive-enable
mode hsa
!
ip cef distributed
no ip domain-lookup
multilink bundle-name both
mpls ldp session protection
no mpls traffic-eng auto-bw timers frequency 0
mpls ldp router-id Loopback0 force
!
7
interface Loopback0
ip address 10.0.0.1 255.255.255.255
no ip mroute-cache
!
interface Multilink4
no ip address
no ip mroute-cache
load-interval 30
ppp multilink
multilink-group 4
!
ip address 10.3.123.1 255.255.0.0
!
no ip address
shutdown
!
description -- ip address 10.0.0.2 255.255.255.0
no ip address
shutdown
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 100
network 10.0.0.1 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
network 10.0.0.0 0.255.255.255 area 100
network 10.0.0.0 0.255.255.255 area 100
network 10.0.0.0 0.255.255.255 area 100
!
ip classless
R2
redundancy
no keepalive-enable
mode hsa
!
ip subnet-zero
8
ip cef distributed
mpls ldp session protection
!
interface Loopback0
ip address 10.0.0.3 255.255.255.255
!
no ip address
shutdown
full-duplex
!
ip address 10.0.0.1 255.0.0.0
full-duplex
mpls ip
!
ip address 10.0.0.2 255.0.0.0
ip load-sharing per-packet
full-duplex
mpls ip
!
ip address 10.3.123.112 255.255.0.0
!
router ospf 100
network 10.0.0.3 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
network 10.0.0.0 0.255.255.255 area 100
!
ip classless
R3
ip cef distributed
no ip domain-lookup
mpls label range 200 100000 static 16 199
!
interface Loopback0
ip address 10.0.0.5 255.255.255.255
!
no ip address
shutdown
half-duplex
!
9
ip address 10.0.0.2 255.0.0.0

full-duplex
mpls ip
!
ip address 10.0.0.2 255.0.0.0
full-duplex
mpls ip
!
router ospf 100
network 10.0.0.5 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
network 10.0.0.0 0.255.255.255 area 100
!
ip classless
The following sections provide references related to the MPLS LDP Session Protection feature.
Related Documents
MPLS LDP MPLS Label Distribution Protocol
MPLS LDP-IGP synchronization MPLS LDP-IGP Synchronization
LDP autoconfiguration LDP Autoconfiguration
Standards
Standards Title
10
MIBs
MIBs MIBs Link
MPLS LDP MIB To locate and download MIBs for selected platforms, Cisco IOS XE
software releases, and feature sets, use Cisco MIB Locator found at
the following URL:
RFCs
RFCs Title
RFC 3037 LDP Applicability
Description Link
11
Feature Information for MPLS LDP Session Protection

Table 1 Feature Information for MPLS LDP Session Protection

MPLS LDP Session Protection Cisco IOS XE The MPLS LDP Session Protection feature provides faster
Release 2.1 label distribution protocol convergence when a link
recovers following an outage. MPLS LDP Session
Protection protects a label distribution protocol (LDP)
session between directly connected neighbors or an LDP
session established for a traffic engineering (TE) tunnel.
In Cisco IOS XE Release 2.1, this feature was introduced on
the Cisco ASR 1000 Series Aggregation Services Routers.
The following sections provide information about this
feature:
• How MPLS LDP Session Protection Works, page 2
• MPLS LDP Session Protection Customization, page 3
• Enabling MPLS LDP Session Protection, page 3
• Verifying MPLS LDP Session Protection, page 6
The following commands were introduced or modified:
debug mpls ldp session protection, mpls ldp session
protection, show mpls ldp neighbor.
12
countries.
13
14
MPLS LDP—Autoconfiguration

The MPLS LDP —Autoconfiguration feature enables you to globally configure Label Distribution
Protocol (LDP) on every interface associated with a specified Interior Gateway Protocol (IGP) instance.

which each feature is supported, see the “Feature Information for MPLS LDP—Autoconfiguration” section
on page 13.
Contents
• Restrictions for MPLS LDP—Autoconfiguration, page 2
• Information About MPLS LDP—Autoconfiguration, page 2
• How to Configure MPLS LDP—Autoconfiguration, page 2
• Configuration Examples for MPLS LDP—Autoconfiguration, page 10
• Feature Information for MPLS LDP—Autoconfiguration, page 13
Restrictions for MPLS LDP—Autoconfiguration
Restrictions for MPLS LDP—Autoconfiguration

This feature has the following restrictions:
• If LDP is disabled globally, the mpls ldp autoconfig command fails and generates a console
message explaining that LDP must first be enabled globally by means of the global mpls ip
command.
• If the mpls ldp autoconfig command is configured for an IGP instance, you cannot issue the global
no mpls ip command. To disable LDP, you must first issue the no mpls ldp autoconfig command.
• For interfaces running IS-IS processes, you can enable Multiprotocol Label Switching (MPLS) for
each interface, using the router mode command mpls ldp autoconfig or mpls ldp igp autoconfig at
the interface level.
• You specify that the default label distribution protocol is LDP for a router or for an interface. Tag
Distribution Protocol (TDP) is not supported.
• The MPLS LDP—Autoconfiguration feature is not supported on traffic engineering tunnel
interfaces.
Information About MPLS LDP—Autoconfiguration

You should understand the following concept before you configure the MPLS LDP—Autoconfiguration
feature:
• MPLS LDP—Autoconfiguration Overview, page 2
MPLS LDP—Autoconfiguration Overview

To enable LDP, you should configure it globally and on each interface where it is needed. Configuring
LDP on many interfaces can be time consuming.
The MPLS LDP—Autoconfiguration feature enables you to globally enable LDP on every interface
associated with an IGP instance. This feature is supported on OSPF and IS-IS IGPs. Further, it provides
a means to block LDP from being enabled on interfaces that you do not want enabled. The goal of the
MPLS LDP—Autoconfiguration feature is to make configuration easier, faster, and error free.
You issue the mpls ldp autoconfig command to enable LDP on each interface that is running an OSPF
or IS-IS process. If you do not want some of the interfaces to have LDP enabled, you can issue the no
form of the mpls ldp igp autoconfig command on those interfaces.
How to Configure MPLS LDP—Autoconfiguration

• Configuring MPLS LDP—Autoconfiguration with OSPF Interfaces, page 3 (required)
• Disabling MPLS LDP—Autoconfiguration from Selected OSPF Interfaces, page 4 (optional)
• Verifying MPLS LDP—Autoconfiguration with OSPF, page 6 (optional)
• Configuring MPLS LDP—Autoconfiguration with IS-IS Interfaces, page 7 (required)
• Disabling MPLS LDP—Autoconfiguration from Selected IS-IS Interfaces, page 9 (optional)
2
Configuring MPLS LDP—Autoconfiguration with OSPF Interfaces

The following steps explain how to configure LDP for interfaces running OSPF processes.
SUMMARY STEPS
1. enable
3. mpls ip
7. exit
8. router ospf process-id
9. network ip-address wildcard-mask area area-id
10. mpls ldp autoconfig [area area-id]
11. exit
12. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls ip Globally enables hop-by-hop forwarding.
Example:
Step 4 mpls label protocol ldp Specifies LDP as the default label distribution protocol.
Example:
Example:
3

Step 6 ip address prefix mask Assigns an IP address to the interface.
Example:
255.255.255.255
Step 7 exit Exits interface configuration mode.
Example:
Step 8 router ospf process-id Enables OSPF routing and enters router configuration
mode.
Example:
Router(config)# router ospf 1
Step 9 network ip-address wildcard-mask area area-id Specifies the interface on which OSPF runs and defines the
area ID for that interface.
Example:
Router(config-router)# network 10.0.0.0
0.0.255.255 area 3
Step 10 mpls ldp autoconfig [area area-id] Enables the MPLS LDP—Autoconfiguration feature to
enable LDP on interfaces belonging to an OSPF process.
Example: • If no area is specified, the command applies to all
Router(config-router)# mpls ldp autoconfig interfaces associated with the OSPF process. If an area
area 3 ID is specified, then only interfaces associated with that
OSPF area are enabled with LDP.
Step 11 exit Exits router configuration mode and returns to global
configuration mode.
Example:
Router(config-router)# exit
Step 12 exit Exits global configuration mode and returns to privileged
EXEC mode.
Example:
Disabling MPLS LDP—Autoconfiguration from Selected OSPF Interfaces

When you issue the mpls ldp autoconfig command, all the interfaces that belong to an OSPF area are
enabled for LDP. To remove LDP from some interfaces, use the no mpls ldp igp autoconfig command
on those interfaces. The following configuration steps show how to disable LDP from some of the
interfaces after they were configured with MPLS LDP—Autoconfiguration with the mpls ldp
autoconfig command.
SUMMARY STEPS
1. enable
4

4. no mpls ldp igp autoconfig
5. exit
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 4 no mpls ldp igp autoconfig Disables LDP for that interface.
Example:
Router(config-if)# no mpls ldp igp autoconfig
Step 5 exit Exits interface configuration mode and returns to global
configuration mode.
Example:
EXEC mode.
Example:
5
Verifying MPLS LDP—Autoconfiguration with OSPF

The following steps explain how to verify the MPLS LDP—Autoconfiguration feature.
SUMMARY STEPS
1. enable
1. show mpls interfaces [detail]
2. show mpls ldp discovery [detail]
3. exit
DETAILED STEPS
Step 1 enable
Use this command to enter privileged EXEC mode. Enter your password if requested. For example:
Router> enable
Router#
Step 2 show mpls interfaces detail

The show mpls interfaces command lists the method that was used to enable LDP on an interface.
• If LDP is enabled by the mpls ldp autoconfig command, the output displays:
IP labeling enabled (ldp):
IGP config
• If LDP is enabled by the mpls ip command, the output displays:

Interface config
• If LDP is enabled by the mpls ip command and the mpls ldp autoconfig command, the output
displays:
Interface config
IGP config
The following example shows that LDP was enabled on the interface by both the mpls ip and mpls
ldp autoconfig commands:
Router# show mpls interfaces S2/0 detail
Interface Serial2/0/0:
Interface config
IGP config
LSP Tunnel labeling enabled
BGP labeling not enabled
MPLS operational
Fast Switching Vectors:
IP to MPLS Fast Switching Vector
MPLS Turbo Vector
MTU = 1500
Step 3 show mpls ldp discovery
6
The show mpls ldp discovery details command also show how LDP was enabled on the interface. In
the following example, LDP was enabled by both the mpls ip and mpls ldp autoconfig commands:
Router# show mpls ldp discovery detail

10.11.11.11:0
Discovery Sources:
Interfaces:
Serial2/0/0 (ldp): xmit/recv
Enabled: Interface config, IGP config;
Hello interval: 5000 ms; Transport IP addr: 10.11.11.11
LDP Id: 10.10.10.10:0
Src IP addr: 10.0.0.1; Transport IP addr: 10.10.10.10
Hold time: 15 sec; Proposed local/peer: 15/15 sec
Step 4 exit
Use this command to exit privileged EXEC mode and return to user EXEC mode. For example:
Router# exit
Router>
Configuring MPLS LDP—Autoconfiguration with IS-IS Interfaces

The following steps explain how to configure the MPLS LDP—Autoconfiguration feature for interfaces
running IS-IS processes.
SUMMARY STEPS
1. enable
5. ip router isis
6. exit
7. mpls ip
9. router isis
10. mpls ldp autoconfig [level-1 | level-2]
11. exit
12. exit
7
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example:
255.0.0.0
Step 5 ip router isis Enables IS-IS for IP on the interface.
Example:
Router(config-if)# ip router isis
Example:
Example:
Example:
Step 9 router isis Enables an IS-IS process on the router and enters router
configuration mode.
Example:
Router(config)# router isis
Step 10 mpls ldp autoconfig [level-1 | level-2] Enables the LDP for interfaces belonging to an IS-IS
process.
Example:
Router(config-router)# mpls ldp autoconfig
8

configuration mode.
Example:
EXEC mode.
Example:
Disabling MPLS LDP—Autoconfiguration from Selected IS-IS Interfaces

When you issue the mpls ldp autoconfig command, all the interfaces that belong to an IS-IS process are
enabled for LDP. To remove LDP from some interfaces, you can use the no form of the mpls ldp igp
autoconfig command on those interfaces. The following configuration steps show how to disable LDP
from some of the interfaces after they were configured with the MPLS LDP—Autoconfiguration through
the mpls ldp autoconfig command.
SUMMARY STEPS
1. enable
4. no mpls ldp igp autoconfig
5. exit
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
9
Configuration Examples for MPLS LDP—Autoconfiguration

Step 4 no mpls ldp igp autoconfig Disables LDP for that interface.
Example:
Router(config-if)# no mpls ldp igp autoconfig
configuration mode.
Example:
EXEC mode.
Example:
Configuration Examples for MPLS LDP—Autoconfiguration

The following sections show examples for MPLS LDP—Autoconfiguration with OSPF and IS-IS
processes.
• MPLS LDP—Autoconfiguration Examples with OSPF, page 10
• MPLS LDP—Autoconfiguration Examples with IS-IS, page 11
MPLS LDP—Autoconfiguration Examples with OSPF

The following configuration commands enable LDP for OSPF process 1 area 3. The mpls ldp
autoconfig area 3 command and the OSPF network commands enable LDP on interfaces POS0/0/0,
POS0/1/0, and POS1/1/0. The no mpls ldp igp autoconfig command on interface POS1/0/0 prevents
LDP from being enabled on interface POS1/0/0, even though OSPF is enabled for that interface.
configure terminal
interface POS0/0/0
ip address 10.0.0.1
!
interface POS0/1/0
ip address 10.0.1.1
!
interface POS1/1/0
ip address 10.1.1.1
!
interface POS1/0/0
ip address 10.1.0.1
exit
!
router ospf 1
network 10.0.0.0 0.0.255.255 area 3
network 10.1.0.0 0.0.255.255 area 3
mpls ldp autoconfig area 3
exit
interface POS1/0/0
no mpls ldp igp autoconfig
10
MPLS LDP—Autoconfiguration Examples with IS-IS

The following example shows the configuration of MPLS LDP—Autoconfiguration on interfaces
POS0/2/0 and POS0/3/0, which are running IS-IS processes:
configure terminal
interface POS0/2/0
ip address 10.0.0.1
ip router isis
!
interface POS0/3/0
ip address 10.1.1.1
ip router isis
exit
mpls ip
router isis
mpls ldp autoconfig
The following sections provide references related to the MPLS LDP—Autoconfiguration feature.
Related Documents
The MPLS LDP-IGP Synchronization feature MPLS LDP-IGP Synchronization
Configuring integrated IS-IS Integrated IS-IS Routing Protocol Overview
IS-IS commands Cisco IOS IP Routing Protocols Command Reference
Configuring OSPF Configuring OSPF
OSPF commands Cisco IOS IP Routing Protocols Command Reference
Standards
Standard Title
modified by this feature
11
MIBs
MIB MIBs Link
the following URL:
RFCs
RFC Title
Description Link
12
Feature Information for MPLS LDP—Autoconfiguration

Table 1 Feature Information for MPLS LDP—Autoconfiguration

MPLS LDP—Autoconfiguration Cisco IOS XE This feature enables you to globally configure LDP on every
Release 2.1 interface associated with a specified Interior Gateway
Protocol (IGP) instance.
feature:
• MPLS LDP—Autoconfiguration Overview, page 2
• Configuring MPLS LDP—Autoconfiguration with
OSPF Interfaces, page 3
• Disabling MPLS LDP—Autoconfiguration from
Selected OSPF Interfaces, page 4
• Verifying MPLS LDP—Autoconfiguration with OSPF,
page 6
• Configuring MPLS LDP—Autoconfiguration with
IS-IS Interfaces, page 7
• Disabling MPLS LDP—Autoconfiguration from
Selected IS-IS Interfaces, page 9
• Configuration Examples for MPLS
LDP—Autoconfiguration, page 10
In Cisco IOS XE Release 2.1, this feature was implemented
on the Cisco ASR 1000 Series Aggregation Services Router.
debug mpls ldp autoconfig, mpls ldp autoconfig, mpls
ldp igp autoconfig, show isis mpls ldp, show mpls ldp
discovery.
13
countries.
coincidental.
14
MPLS LDP-IGP Synchronization

The MPLS LDP-IGP Synchronization feature ensures that the Label Distribution Protocol (LDP) is fully
established before the Interior Gateway Protocol (IGP) path is used for switching.

which each feature is supported, see the “Feature Information for MPLS LDP-IGP Synchronization” section
on page 16.
Contents
• Prerequisites for MPLS LDP-IGP Synchronization, page 2
• Restrictions for MPLS LDP-IGP Synchronization, page 2
• Information About MPLS LDP-IGP Synchronization, page 2
• How to Configure MPLS LDP-IGP Synchronization, page 4
• Configuration Examples for MPLS LDP-IGP Synchronization, page 13
• Feature Information for MPLS LDP-IGP Synchronization, page 16
Prerequisites for MPLS LDP-IGP Synchronization
Prerequisites for MPLS LDP-IGP Synchronization

• This feature is supported only on interfaces running Open Shortest Path First (OSPF) or
Intermediate System-to-System (IS-IS) processes.
• This feature works when LDP is enabled on interfaces with either the mpls ip or mpls ldp
autoconfig command.
Restrictions for MPLS LDP-IGP Synchronization

• This feature is not supported on tunnel interfaces or LC-ATM interfaces.
• This feature is not supported with interface-local label space or downstream-on-demand (DoD)
requests.
• This feature does not support targeted LDP sessions. Therefore, Any Transport over MPLS (AToM)
sessions are not supported.
Information About MPLS LDP-IGP Synchronization

To configure the LDP-IGP synchronization feature, you should understand the following concepts:
• How MPLS LDP-IGP Synchronization Works, page 2
• MPLS LDP-IGP Synchronization with Peers, page 3
• MPLS LDP-IGP Synchronization Delay Timer, page 3
• MPLS LDP-IGP Synchronization Incompatibility with IGP Nonstop Forwarding, page 4
• MPLS LDP-IGP Synchronization Compatibility with LDP Graceful Restart, page 4
How MPLS LDP-IGP Synchronization Works

Packet loss can occur because the actions of the IGP and LDP are not synchronized. Packet loss can
occur in the following situations:
• When an IGP adjacency is established, the router begins forwarding packets using the new
adjacency before the LDP label exchange completes between the peers on that link.
• If an LDP session closes, the router continues to forward traffic using the link associated with the
LDP peer rather than an alternate pathway with a fully synchronized LDP session.
The MPLS LDP-IGP Synchronization feature does the following:
• Provides a means to synchronize LDP and IGPs to minimize Multiprotocol Label Switching (MPLS)
packet loss.
• Enables you to globally enable LDP-IGP synchronization on each interface associated with an IGP
OSPF or IS-IS process.
• Provides a means to disable LDP-IGP synchronization on interfaces that you do not want enabled.
• Prevents MPLS packet loss due to synchronization conflicts.
• Works when LDP is enabled on interfaces using either the mpls ip or mpls ldp autoconfig
command.
2
Information About MPLS LDP-IGP Synchronization
To enable LDP-IGP synchronization on each interface that belongs to an OSPF or IS-IS process, enter
the mpls ldp sync command. If you do not want some of the interfaces to have LDP-IGP synchronization
enabled, issue the no mpls ldp igp sync command on those interfaces.
If the LDP peer is reachable, the IGP waits indefinitely (by default) for synchronization to be achieved.
To limit the length of time the IGP session must wait, enter the mpls ldp igp sync holddown command.
If the LDP peer is not reachable, the IGP establishes the adjacency to enable the LDP session to be
established.
When an IGP adjacency is established on a link but LDP-IGP synchronization is not yet achieved or is
lost, the IGP advertises the max-metric on that link.
MPLS LDP-IGP Synchronization with Peers

When the MPLS LDP-IGP Synchronization feature is enabled on an interface, LDP determines if any
peer connected by the interface is reachable by looking up the peer's transport address in the routing
table. If a routing entry (including longest match or default routing entry) for the peer exists, LDP
assumes that LDP-IGP synchronization is required for the interface and notifies the IGP to wait for LDP
convergence.
LDP-IGP synchronization with peers requires that the routing table be accurate for the peer's transport
address. If the routing table shows there is a route for the peer's transport address, that route must be able
to reach the peer's transport address. However, if the route is a summary route, a default route, or a
statically configured route, it may not the correct route for the peer. You must verify that the route in the
routing table can reach the peer’s transport address.
When the routing table has an inaccurate route for the peer’s transport address, LDP cannot set up a
session with the peer, which causes the IGP to wait for LDP convergence unnecessarily for the sync
hold-down time.
MPLS LDP-IGP Synchronization Delay Timer

The MPLS LDP-IGP Synchronization feature provide the option to configure a delay time for MPLS
LDP and IGP synchronization on an interface-by-interface basis. If you want to configure a delay time
on an interface, use the mpls ldp igp sync delay delay-time command in interface configuration mode.
To remove the delay timer from a specified interface, enter the no mpls ldp igp sync delay command.
This command sets the delay time to 0 seconds, but leaves MPLS LDP IGP synchronization enabled.
When LDP is fully established and synchronized, LDP checks the delay timer:
• If you configured a delay time, LDP starts the timer. When the timer expires, LDP checks that
synchronization is still valid and notifies the OSPF process.
• If you did not configure a delay time, if synchronization is disabled or down, or if an interface was
removed from an IGP process, LDP stops the timer and immediately notifies the OSPF process.
If you configure a new delay time while a timer is running, LDP saves the new delay time but does not
reconfigure the running timer.
3
How to Configure MPLS LDP-IGP Synchronization
MPLS LDP-IGP Synchronization Incompatibility with IGP Nonstop Forwarding

The MPLS LDP-IGP Synchronization feature is not supported during the startup period if IGP nonstop
forwarding (NSF) is configured. The MPLS LDP-IGP Synchronization feature conflicts with IGP NSF
when the IGP is performing NSF during startup. After the NSF startup is complete, the MPLS LDP-IGP
Synchronization feature is supported.
MPLS LDP-IGP Synchronization Compatibility with LDP Graceful Restart

LDP Graceful Restart protects traffic when an LDP session is lost. If an interface that supports a Graceful
Restart-enabled LDP session fails, MPLS LDP-IGP synchronization is still achieved on the interface
while it is protected by Graceful Restart. MPLS LDP-IGP synchronization is eventually lost under the
following circumstances:
• If LDP fails to restart before the LDP Graceful Restart reconnect timer expires.
• If an LDP session restarts through other interfaces, but the LDP session on the protected interface
fails to recover when the LDP Graceful Restart recovery timer expires.

• Configuring MPLS LDP-IGP Synchronization with OSPF Interfaces, page 4 (required)
• Disabling MPLS LDP-IGP Synchronization from Some OSPF Interfaces, page 6 (optional)
• Verifying MPLS LDP-IGP Synchronization with OSPF, page 7 (optional)
• Configuring MPLS LDP-IGP Synchronization with IS-IS Interfaces, page 9 (required)
• Disabling MPLS LDP-IGP Synchronization from Some IS-IS Interfaces, page 12 (optional)
Configuring MPLS LDP-IGP Synchronization with OSPF Interfaces

To configure MPLS LDP-IGP synchronization with OFPF interfaces, perform the following steps.
SUMMARY STEPS
1. enable
3. mpls ip
7. mpls ip
8. exit
4
11. mpls ldp sync

12. exit
13. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example:
Example:
Example:
255.255.255.255
Step 7 mpls ip Enables hop-by-hop forwarding on the interface.
Example:
Example:
Step 9 router ospf process-id Enables OSPF routing and enters router configuration
mode.
Example:
5

Step 10 network ip-address wildcard-mask area area-id Defines an interface on which OSPF runs and defines the
area ID for that interface.
Example:
0.255.255.255 area 3
Step 11 mpls ldp sync Enables MPLS LDP-IGP synchronization for interfaces for
an OSPF or an IS-IS process.
Example:
Router(config-router)# mpls ldp sync
configuration mode.
Example:
EXEC mode.
Example:
Disabling MPLS LDP-IGP Synchronization from Some OSPF Interfaces

When you issue the mpls ldp sync command, all of the interfaces that belong to an OSPF process are
enabled for LDP-IGP synchronization. To remove LDP-IGP synchronization from some interfaces, use
the no form of the mpls ldp igp sync command on those interfaces.
Perform the following task to disable LDP-IGP synchronization from some OSPF interfaces after they
are configured with LDP-IGP synchronization through the mpls ldp sync command.
SUMMARY STEPS
1. enable
4. no mpls ldp igp sync
5. exit
6. exit
6
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 4 no mpls ldp igp sync Disables MPLS LDP-IGP synchronization for that
interface.
Example:
Router(config-if)# no mpls ldp igp sync
configuration mode.
Example:
EXEC mode.
Example:
Verifying MPLS LDP-IGP Synchronization with OSPF

After you configure the interfaces for LDP, OSPF, and LDP-IGP synchronization, verify that the
configuration is working correctly using the show mpls ldp igp sync and show ip ospf mpls ldp
interface commands.
SUMMARY STEPS
1. enable
2. show mpls ldp igp sync
3. show ip ospf mpls ldp interface
4. exit
7
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls ldp igp sync

Use this command to show that MPLS LDP-IGP synchronization is configured correctly, because LDP
is configured and the SYNC status shows that synchronization is enabled.
Router# show mpls ldp igp sync
FastEthernet0/0/0:
LDP configured; SYNC enabled.
SYNC status: sync achieved; peer reachable.
IGP holddown time: infinite.
Peer LDP Ident: 10.0.0.1:0
IGP enabled: OSPF 1
If MPLS LDP-IGP synchronization is not enabled on an interface, the output appears as follows:
FastEthernet0/3/1:
LDP configured; LDP-IGP Synchronization not enabled.
Step 3 show ip ospf mpls ldp interface

Use the output of the show ip ospf mpls ldp interface command to show that the interfaces are properly
configured:
Router# show ip ospf mpls ldp interface
FastEthernet0/3/1
Process ID 1, Area 0
LDP is configured through LDP autoconfig
LDP-IGP Synchronization: Yes
Holddown timer is not configured
Timer is not running
FastEthernet0/0/2
Process ID 1, Area 0
LDP is configured through LDP autoconfig
LDP-IGP Synchronization: Yes
Holddown timer is not configured
Timer is not running
Step 4 exit
Use this command to exit from privileged EXEC mode. For example:
Router# exit
Router>
8
Configuring MPLS LDP-IGP Synchronization with IS-IS Interfaces

The following sections contain the steps and examples for configuring MPLS LDP-IGP synchronization
for interfaces running IS-IS processes:
• Configuring MPLS LDP-IGP Synchronization on All IS-IS Interfaces, page 9
• Configuring MPLS LDP-IGP Synchronization on an IS-IS Interface, page 10
Configuring MPLS LDP-IGP Synchronization on All IS-IS Interfaces

Perform the following task to configure the MPLS LDP-IGP Synchronization feature on all interfaces
running IS-IS processes.
SUMMARY STEPS
1. enable
3. mpls ip
5. router isis process-name
6. mpls ldp sync
9. ip router isis process-name
10. exit
11. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
9

Example:
Step 5 router isis process-name Enables the IS-IS protocol on the router, specifies an IS-IS
process, and enters router configuration mode.
Example:
Router(config)# router isis ISIS
Step 6 mpls ldp sync Enables MPLS LDP-IGP synchronization on interfaces
belonging to an IS-IS process.
Example:
Example:
Router(config-router)# interface POS0/3/0
Example:
255.255.255.0
Step 9 ip router isis process-name Enables IS-IS.
Example:
Router(config-if)# ip router isis ISIS
configuration mode.
Example:
EXEC mode.
Example:
Configuring MPLS LDP-IGP Synchronization on an IS-IS Interface

This section contains the steps for configuring the MPLS LDP-IGP Synchronization feature on an
interface that is running an IS-IS process.
SUMMARY STEPS
1. enable
10

5. ip router isis
6. exit
7. router isis
8. mpls ldp sync
9. exit
10. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example:
255.0.0.0
Step 5 ip router isis Enables the IS-IS protocol for IP on the interface.
Example:
Step 6 Exit Exits to global configuration mode.
Example:
Step 7 router isis Enters router configuration mode and enables an IS-IS
process on the router.
Example:
Step 8 mpls ldp sync Enables LDP-IGP synchronization for interfaces belonging
to an IS-IS process.
Example:
11

configuration mode.
Example:
EXEC mode.
Example:
Disabling MPLS LDP-IGP Synchronization from Some IS-IS Interfaces

When you issue the mpls ldp sync command, all of the interfaces that belong to an IS-IS process are
enabled for LDP-IGP synchronization. To remove LDP-IGP synchronization from some interfaces, use
the no form of the mpls ldp igp sync command on those interfaces.
Perform the following task to disable LDP-IGP synchronization from some IS-IS interfaces after they
are configured with LDP-IGP synchronization through the mpls ldp sync command.
SUMMARY STEPS
1. enable
4. no mpls ldp igp sync
5. exit
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
12
Configuration Examples for MPLS LDP-IGP Synchronization

Step 4 no mpls ldp igp sync Disables MPLS LDP-IGP synchronization for that
interface.
Example:
configuration mode.
Example:
EXEC mode.
Example:
Use the debug mpls ldp igp sync command to display events related to MPLS LDP-IGP
synchronization.

The following sections show examples for the MPLS LDP-IGP synchronization feature with OSPF and
IS-IS processes:
• MPLS LDP-IGP Synchronization with OSPF: Examples, page 13
• MPLS LDP-IGP Synchronization with IS-IS: Examples, page 14
MPLS LDP-IGP Synchronization with OSPF: Examples

The following task shows how to enable LDP for OSPF process 1. The mpls ldp sync and the OSPF
network commands enable LDP on interfaces POS0/0/0, POS0/1/0, and POS1/1/0, respectively. The no
mpls ldp igp sync command on interface POS1/0/0 prevents LDP from being enabled on interface
POS1/0/0, even though OSPF is enabled for that interface.
!
!
!
!
13

Router(config-router)# network 10.0.0.0 0.0.255.255 area 3
Router(config-router)# network 10.1.0.0 0.0.255.255 area 3
MPLS LDP-IGP Synchronization with IS-IS: Examples

The following examples show the configuration commands you can use to configure MPLS LDP-IGP
synchronization on interfaces POS0/2 /0 and POS0/3/0, which are running IS-IS processes:


.
.
.

Router(config) exit
Router#
14
The following sections provide references related to the MPLS LDP-IGP Synchronization feature.
Related Documents
MPLS LDP Autoconfiguration MPLS LDP Autoconfiguration
Standards
Standards Title
MIBs
MIBs MIBs Link
the following URL:
RFCs
RFCs Title
15
Feature Information for MPLS LDP-IGP Synchronization
Description Link

16
Table 1 Feature Information for MPLS LDP-IGP Synchronization

MPLS LDP-IGP Synchronization Cisco IOS XE The MPLS LDP-IGP Synchronization feature ensures
Release 2.1 that the Label Distribution Protocol (LDP) is fully
established before the Interior Gateway Protocol
(IGP) path is used for switching.
In Cisco IOS XE Release 2.1, this feature was
integrated on the Cisco ASR 1000 Series Aggregation
Services Routers.
feature:
• How MPLS LDP-IGP Synchronization Works,
page 2
• MPLS LDP-IGP Synchronization with Peers,
page 3
• MPLS LDP-IGP Synchronization Delay Timer,
page 3
• MPLS LDP-IGP Synchronization Incompatibility
with IGP Nonstop Forwarding, page 4
• MPLS LDP-IGP Synchronization Compatibility
with LDP Graceful Restart, page 4
• Configuring MPLS LDP-IGP Synchronization
with OSPF Interfaces, page 4
• Disabling MPLS LDP-IGP Synchronization from
Some OSPF Interfaces, page 6
• Verifying MPLS LDP-IGP Synchronization with
OSPF, page 7
• Configuring MPLS LDP-IGP Synchronization
with IS-IS Interfaces, page 9
• Disabling MPLS LDP-IGP Synchronization from
Some IS-IS Interfaces, page 12
• Troubleshooting Tips, page 13
The following commands were modified: debug mpls
ldp igp sync, mpls ldp igp sync, mpls ldp igp sync
holddown, mpls ldp sync, show ip ospf mpls ldp
interface, show isis mpls ldp, and show mpls ldp igp
sync.
17
countries.
coincidental.
18
MPLS LDP Inbound Label Binding Filtering
First Published: August 26, 2003

The MPLS LDP Inbound Label Binding Filtering feature supports inbound label binding filtering. You
can use the Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) feature to
configure access control lists (ACLs) for controlling the label bindings a label switch router (LSR)
accepts from its peer LSRs.

which each feature is supported, see the “Feature Information for MPLS LDP Inbound Label Binding
Filtering” section on page 8.
Contents
• Restrictions for MPLS LDP Inbound Label Binding Filtering, page 2
• Information about MPLS LDP Inbound Label Binding Filtering, page 2
• How to Configure MPLS LDP Inbound Label Binding Filtering, page 2
• Configuration Examples for MPLS LDP Inbound Label Binding Filtering, page 5
• Feature Information for MPLS LDP Inbound Label Binding Filtering, page 8
Restrictions for MPLS LDP Inbound Label Binding Filtering
Restrictions for MPLS LDP Inbound Label Binding Filtering

Inbound label binding filtering does not support extended ACLs; it only supports standard ACLs.
Information about MPLS LDP Inbound Label Binding Filtering

Before you configure this feature, you should understand the following concept:
• MPLS LDP Inbound Label Binding Filtering Benefit, page 2
MPLS LDP Inbound Label Binding Filtering Benefit

The MPLS LDP Inbound Label Binding Filtering feature may be used to control the amount of memory
used to store LDP label bindings advertised by other routers. For example, in a simple MPLS Virtual
Private Network (VPN) environment, the VPN provider edge (PE) routers may require LSPs only to their
peer PE routers (that is, they do not need LSPs to core routers). Inbound label binding filtering enables
a PE router to accept labels only from other PE routers.
How to Configure MPLS LDP Inbound Label Binding Filtering

This section includes the following tasks:
• Configuring MPLS LDP Inbound Label Binding Filtering, page 2 (Required)
• Verifying that MPLS LDP Inbound Label Bindings are Filtered, page 3 (Optional)
Configuring MPLS LDP Inbound Label Binding Filtering

Perform this task to configure a router for inbound label filtering.
The following configuration allows the router to accept only the label for prefix 192.168.1.1 from LDP
neighbor router 10.12.12.12.
SUMMARY STEPS
1. enable
3. ip access-list standard access-list-number
4. permit {source [source-wildcard] | any} [log]
5. exit
6. mpls ldp neighbor [vrf vpn-name] nbr-address labels accept acl
7. end
2
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip access-list standard access-list-number Defines a standard IP access list with a number.
Example:
Router(config)# ip access-list standard 1
Step 4 permit {source [source-wildcard] | any} [log] Specifies one or more prefixes permitted by the access list.
Example:
Router(config-std-nacl)# permit 10.0.0.0
Step 5 exit Exits the current mode and goes to the next higher level.
Example:
Router(config-std-nacl)# exit
Step 6 mpls ldp neighbor [vrf vpn-name] nbr-address Specifies the ACL to be used to filter label bindings for the
labels accept acl specified LDP neighbor.
Example:
Router(config)# mpls ldp neighbor 10.12.12.12
labels accept 1
Step 7 end Exits the current mode and enters privileged Exec mode.
Example:
Router(config)# end
Verifying that MPLS LDP Inbound Label Bindings are Filtered

If inbound filtering is enabled, perform the following tasks to verify that inbound label bindings are
filtered.
SUMMARY STEPS
1. enable
2. show mpls ldp neighbor [vrf vpn-name] [address | interface] [detail]
3. show ip access-list [access-list-number | access-list-name]
4. show mpls ldp bindings
5. end
3
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls ldp neighbor [vrf vpn-name] [address | interface] [detail]
Enter the show mpls ldp neighbor command to show the status of the LDP session, including the name
or number of the ACL configured for inbound filtering.
Note To display information about inbound label binding filtering, you must enter the detail keyword.
Router# show mpls ldp neighbor 10.12.12.12 detail

TCP connection: 10.12.12.12.646 - 10.13.13.13.12592
Serial1/0/0; Src IP addr: 192.168.1.1
holdtime: 15000 ms, hello interval: 5000 ms
10.0.0.129 10.12.12.12 192.168.1.1
LDP inbound filtering accept acl: 1
Step 3 show ip access-list [access-list-number | access-list-name]

Enter the show ip access-list command to display the contents of all current IP access lists or of a
specified access list.
Note It is important that you enter this command to see how the access list is defined; otherwise, you
cannot verify inbound label binding filtering.
The following command output shows the contents of IP access list 1:

Router# show ip access 1

permit 10.0.0.0, wildcard bits 0.0.0.255 (1 match)
Step 4 show mpls ldp bindings

Enter the show mpls ldp bindings command to verify that the LSR has remote bindings only from a
specified peer for prefixes permitted by the access list.
Router# show mpls ldp bindings
tib entry: 10.0.0.0/8, rev 4

local binding: tag: imp-null
tib entry: 10.2.0.0/16, rev 1137
local binding: tag: 16
tib entry: 10.2.0.0/16, rev 1139
tib entry: 10.12.12.12/32, rev 1257
4
Configuration Examples for MPLS LDP Inbound Label Binding Filtering
tib entry: 10.13.13.13/32, rev 14

tib entry: 10.10.0.0/16, rev 711
tib entry: 10.0.0.0/8, rev 1135
remote binding: tsr: 10.12.12.12:0, tag: imp-null
tib entry: 10.0.0.0/8, rev 8
Step 5 exit
Router# exit
Router>
Configuration Examples for MPLS LDP Inbound Label Binding

Filtering
This section contains the following configuration example for MPLS LDP inbound label binding
filtering:
• Configuring MPLS LDP Inbound Label Binding Filtering: Example, page 5
Configuring MPLS LDP Inbound Label Binding Filtering: Example

In the following example, the mpls ldp neighbor labels accept command is configured with an access
control list to filter label bindings received on sessions with the neighbor 10.110.0.10.
Label bindings for prefixes that match 10.b.c.d are accepted, where b is less than or equal to 63, and c
and d can be any integer between 0 and 128. Other label bindings received from 10.110.0.10 are rejected.
Router(config)# access-list 1 permit 10.63.0.0 0.63.255.255
Router(config)# mpls ldp neighbor 10.110.0.10 labels accept 1
Router(config)# end
In the following example, the show mpls ldp bindings neighbor command displays label bindings that
were learned from 10.110.0.10. This example verifies that the LIB does not contain label bindings for
prefixes that have been excluded.
Router# show mpls ldp bindings neighbor 10.110.0.10
tib entry: 10.2.0.0/16, rev 4

tib entry: 10.43.0.0/16, rev 6
remote binding: tsr: 10.110.0.10:0, tag: 16
tib entry: 10.52.0.0/16, rev 8
5
The following sections provide additional references related to MPLS LDP inbound label binding filters.
Related Documents
Configuration information for MPLS LDP “MPLS Label Distribution Protocol (LDP)” chapter in the Cisco IOS
XE Multiprotocol Label Switching Configuration Guide
Standards
Standard Title
MIBs
MIB MIBs Link
MPLS Label Distribution Protocol MIB To locate and download MIBs for selected platforms, Cisco IOS XE
(draft-ietf-mpls-ldp-08.txt) software releases, and feature sets, use Cisco MIB Locator found at
the following URL:
RFCs
RFC Title
6
Description Link
7
Feature Information for MPLS LDP Inbound Label Binding Filtering
Feature Information for MPLS LDP Inbound Label Binding

Filtering
Table 1 Feature Information for MPLS LDP Inbound Label Bonding Filtering

MPLS LDP Inbound Label Binding Filtering Cisco IOS XE The MPLS LDP Inbound Label Binding Filtering feature
Release 2.1 supports inbound label binding filtering. You can use the
Multiprotocol Label Switching (MPLS) Label Distribution
Protocol (LDP) feature to configure access control lists
(ACLs) for controlling the label bindings a label switch
router (LSR) accepts from its peer LSRs.
In Cisco IOS XE Release 2.1, support was added for the
Cisco ASR 1000 Series Aggregation Services Routers.
feature:
• MPLS LDP Inbound Label Binding Filtering Benefit,
page 2
• Configuring MPLS LDP Inbound Label Binding
Filtering, page 2
• Verifying that MPLS LDP Inbound Label Bindings are
Filtered, page 3
clear mpls ldp neighbor, mpls ldp neighbor labels
accept, show mpls ldp neighbor.
8
Glossary
Glossary
CE router—customer edge router. A router that is part of a customer network and that interfaces to a
provider edge (PE) router.
inbound label binding filtering—Allows LSRs to control which label bindings it will accept from its
neighboring LSRs. Consequently, an LSR does not accept or store some label bindings that its neighbors
advertise.
label—A short fixed-length identifier that tells switching nodes how to forward data (packets or cells).
label binding—An association between a destination prefix and a label.
countries.
coincidental.
9
Glossary
10
MPLS LDP—Local Label Allocation Filtering

This feature introduces command-line interface (CLI) commands to modify the way in which
Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) handles local label
allocation. This MPLS LDP feature enhancement enables the configuration of filtering policies for
selective local label binding assignments by LDP to improve LDP scalability and convergence.
This document contains information about and instructions on how to configure the MPLS LDP—Local
Label Allocation Filtering feature.

which each feature is supported, see the “Feature Information for MPLS LDP—Local Label Allocation
Filtering” section on page 19.
Contents
• Prerequisites for MPLS LDP—Local Label Allocation Filtering, page 2
• Restrictions for MPLS LDP—Local Label Allocation Filtering, page 2
• Information About MPLS LDP—Local Label Allocation Filtering, page 2
• How to Configure MPLS LDP—Local Label Allocation Filtering, page 5
• Configuration Examples for MPLS LDP—Local Label Allocation Filtering, page 10
Prerequisites for MPLS LDP—Local Label Allocation Filtering
• Feature Information for MPLS LDP—Local Label Allocation Filtering, page 19

Prerequisites for MPLS LDP—Local Label Allocation Filtering

The MPLS LDP—Local Label Allocation Filtering feature requires the MPLS Forwarding Infrastructure
(MFI).
Restrictions for MPLS LDP—Local Label Allocation Filtering

The MPLS LDP—Local Label Allocation Filtering feature does not support access lists. This feature
supports prefix lists.
Restrictions for the MPLS LDP—Local Label Allocation Filtering feature in Cisco IOS XE
Release 2.3.1:
• LDP local label allocation configuration for prefix list or host routes is supported only in the global
routing table.
• LDP and RIB restart handling does not apply.
• Wildcard Forwarding Equalence Class (FEC) requests are not supported.
• Remote bindings are retained for LDP table entries that are filtered.
Information About MPLS LDP—Local Label Allocation Filtering

Before you configure the MPLS LDP—Local Label Allocation Filtering feature, you should understand
the following concepts:
• MPLS LDP Local Label Allocation Filtering Overview, page 2
• Prefix Lists for MPLS LDP Local Label Allocation Filtering: Benefits and Description, page 4
• Local Label Allocation Changes and LDP Actions, page 4
• LDP Local Label Filtering and BGP Routes, page 5
MPLS LDP Local Label Allocation Filtering Overview

LDP allocates a local label for every route learned from the Interior Gateway Protocol (IGP). In the
absence of inbound and outbound label filtering, these local labels are advertised to and learned by all
peers.
In most Layer 3 Virtual Private Network (VPN) configurations only the label switched paths (LSPs)
created to reach the /32 host routes or Border Gateway Protocol (BGP) next hops between the provider
edge (PE) routers carry traffic and are relevant to the Layer 3 VPNs. LSPs between the PE routers that
are not members of a VPN use more memory and create additional processing in LDP across the core.
With the load increases in the service provider domain in the last decade (1997–2007), scalability has
become more important in the service provider networks. Controlling the local label allocation could
off-load LDP processing of non-VPN LSPs in the service provider network core devices.
2
The MPLS LDP—Local Label Allocation Filtering feature introduces the mpls ldp label and allocate
commands that allow you to configure LDP to selectively allocate local labels for a subset of the prefixes
learned from the IGP. You can select that LDP allocate local labels for prefixes configured in a prefix
list in the global table or for host routes in the global table.
Local label allocation filtering reduces the number of local labels allocated and therefore the number of
messages exchanged with peers. This improves LDP scalability and convergence. Figure 1 and Figure 2
show how controlling local label allocation can reduce local label space size and greatly reduce the
number of advertisements to peers. Figure 1 shows default LDP label allocation behavior. LDP allocates
a local label for every route and advertises a label binding for every route learned from the IGP.
Figure 1 Default LDP Local Label Allocation Behavior
R1
Label
bindings
Lable Local
To R2
bindings labels
To R4
Global routing
table
To R3
185876
Label
bindings
Figure 2 shows LDP behavior with local label allocation control configured. The size of the local label
space and the number of label binding advertisements are reduced with local label allocation filtering
through the use of a prefix list. The decrease in the number of local labels and label binding
advertisement messages reduces the amount of memory use and improves convergence time for LDP.
The MPLS LDP—Local Label Allocation Filtering feature also allows for more efficient use of the label
space.
Figure 2 LDP Behavior with Local Label Allocation Controls
R1
Label
bindings
Local
Lable labels To R2
bindings
To R4 Prefix list
Global
routing
table To R3
185877
Label
bindings
Figure 2 shows that router R1 learns a number of routes from its IGP neighbors on routers R2, R3, and
R4. A prefix list defined on router R1 specifies the prefixes for which LDP allocates a local label.
3
Note In general, the number of Label Information Base (LIB) entries remains the same regardless of the kind
of label filtering. This is because the remote label bindings for the prefixes that are filtered are kept in
the LIB. Memory use is reduced because local label filtering decreases the number of local labels
allocated and the number of label bindings advertised to and stored by the peers of an LSR.
Prefix Lists for MPLS LDP Local Label Allocation Filtering: Benefits and
Description
The MPLS LDP—Local Label Allocation Filtering feature allows you to configure LDP to allocate local
labels for a subset of the learned prefixes. LDP accepts the prefix and allocates a local label if the prefix
is permitted by a prefix list. If the prefix list is not defined, LDP accepts all prefixes and allocates local
labels based on its default mode of operation.
The benefits of using prefix lists for LDP local label allocation filtering are as follows:
• Prefix lists provide more flexibility for specifying a subset of prefixes and masks.
• Prefix lists use a tree-based matching technique. This technique is more efficient than evaluating
prefixes or host routes sequentially.
• Prefix lists are easy to modify.
You configure a prefix list for the MPLS LDP—Local Label Allocation Filtering feature with the
ip prefix-list command. The format of the command is as follows: ip prefix-list {list-name |
list-number} [seq number] {deny network/length | permit network/length} [ge ge-length] [le le-length]
Local Label Allocation Changes and LDP Actions

The MPLS LDP—Local Label Allocation Filtering enhancement modifies the LDP’s local label
allocation handling. The feature supports local label allocation filtering through the specification of a
prefix list or host routes.
With the introduction of this feature, LDP needs to determine whether a prefix filter is already
configured to control the local label allocation on the local node. If a prefix list exists, the local label
allocation is confined to the list of prefixes permitted by the configured prefix list.
LDP also needs to respond to local label allocation configuration changes and to configuration changes
that affect the prefix list that LDP is using. Any of the following configuration changes can trigger LDP
actions:
• Creating a local label allocation configuration
• Deleting or changing a local label allocation configuration
• Creating a new prefix list for a local label allocation configuration
• Deleting or changing a prefix list for a local label allocation configuration
LDP responds to local label allocation configuration changes by updating the LIB and the forwarding
table in the global routing table. To update the LIB after a local label filter configuration change without
a session reset, LDP keeps all remote bindings.
If you create a local label allocation configuration without defining a prefix list, no LDP action is
required. The local label allocation configuration has no effect because the prefix list is created and
permits all prefixes.
4
How to Configure MPLS LDP—Local Label Allocation Filtering
If you create or change a prefix list and prefixes that were previously allowed are rejected, LDP goes
through a label withdraw and release procedure before the local labels for these prefixes are deallocated.
If you delete a prefix, LDP goes through the label withdraw and release procedure for the LIB local label.
If the associated prefix is one for which no LIB entry should be allocated, LDP bypasses this procedure.
The LDP default behavior is to allocate local labels for all non-BGP prefixes. This default behavior does
not change with the introduction of this feature and the mpls ldp label and allocate commands.
Note The local label allocation filtering has no impact on inbound label filtering because both provide LDP
filtering independently. The LDP Inbound Label Binding Filtering feature controls label bindings that a
label switch router (LSR) accepts from its peer LSRs through the use of access control lists (ACLs). The
MPLS LDP—Local Label Allocation Filtering feature controls the allocation of local labels through the
use of prefix lists or host routes.
LDP Local Label Filtering and BGP Routes

The LDP default behavior is to allocate local labels for all non-BGP prefixes.
LDP does not apply the configured local label filter to redistributed BGP routes in the global table for
which BGP allocates local label, but LDP does the advertisements (Inter-AS Option C). LDP neither
forwards these entries nor releases the local labels allocated by BGP.

Perform the following tasks to configure the MPLS LDP—Local Label Allocation Filtering feature:
• Creating a Prefix List for MPLS LDP Local Label Allocation Filtering, page 5 (optional)
• Configuring MPLS LDP Local Label Allocation Filtering, page 7 (required)
• Verifying MPLS LDP—Local Label Allocation Filtering Configuration, page 9 (optional)
Creating a Prefix List for MPLS LDP Local Label Allocation Filtering
Perform the following task to create a prefix list for LDP local label allocation filtering. A prefix list
allows LDP to selectively allocate local labels for a subset of the routes learned from the IGP. The
decrease in the number of local labels in the LDP LIB and the number of label mapping advertisements
reduces the amount of memory use and improves convergence time for LDP.
SUMMARY STEPS
1. enable
3. ip prefix-list {list-name | list-number} [seq number] {deny network/length | permit
network/length} [ge ge-length] [le le-length]
4. end
5
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip prefix-list {list-name | list-number} [seq Creates a prefix list or adds a prefix-list entry.
number] {deny network/length | permit
network/length} [ge ge-length] [le le-length] • The list-name argument configures a name to identify
the prefix list.
Example: • The list-number argument configures a number to

Router(config)# ip prefix-list list1 permit identify the prefix list.
192.168.0.0/16 le 20
• The seq number keyword and argument apply a
sequence number to a prefix-list entry. The range of
sequence numbers that can be entered is from 1 to
4294967294. If a sequence number is not entered when
this command is configured, a default sequence
numbering is applied to the prefix list. The number 5 is
applied to the first prefix entry, and subsequent
unnumbered entries are incremented by 5.
• The deny keyword denies access for a matching
condition.
• The permit keyword permits access for a matching
condition.
• The network/length arguments and keyword configure
the network address, and the length of the network
mask in bits. The network number can be any valid IP
address or prefix. The bit mask can be a number from
0 to 32.
• The ge ge-length keyword and argument specify the
lesser value of a range (the “from” portion of the range
description) by applying the ge-length argument to the
range specified. The ge-length argument represents the
minimum prefix length to be matched. The ge keyword
represents the greater than or equal to operator.
• The le le-length keyword and argument specify the
greater value of a range (the “to” portion of the range
description) by applying the le-length argument to the
range specified. The le-length argument represents the
maximum prefix length to be matched. The le keyword
represents the less than or equal to operator.
6

Example:
Router(config)# end
Configuring MPLS LDP Local Label Allocation Filtering

Perform the following task to configure LDP local allocation filtering. Configuring filtering policies for
selective local label binding assignments by LDP improves LDP scalability and convergence. You can
configure either a prefix list or host routes as a filter for local label allocation.
Note The host-routes keyword for the allocate command makes it convenient for you to specify a commonly
used set of prefixes.
Restrictions
A maximum of one local label allocation filter is supported for the global table.
SUMMARY STEPS
1. enable
3. mpls ldp label
4. allocate global prefix-list {list-name | list-number}
5. allocate global host-routes
6. no allocate global {prefix-list {list-name | list-number} | host -routes}
7. no mpls ldp label
8. exit
9. exit
DETAILED STEPS

Example:
Router> enable
Example:
7

Step 3 mpls ldp label Enters MPLS LDP label configuration mode to specify how
MPLS LDP handles local label allocation.
Example:
Router(config)# mpls ldp label
Step 4 allocate global prefix-list {list-name | Configures local label allocation filters for learned routes
list-number} for MPLS LDP.
• The global keyword specifies the global routing.
Example:
Router(config-ldp-lbl)# allocate global
• The prefix-list keyword specifies a prefix list to be
prefix-list list1 used as a filter for MPLS LDP local label allocation.
• The list-name argument indicates a name that identifies
the prefix list.
• The list-number argument indicates a number that
identifies the prefix list.
Step 5 allocate global host-routes Configures local label allocation filters for learned routes
for MPLS LDP.
Example: • The global keyword specifies the global routing.
Router(config-ldp-lbl)# allocate global
host-routes
• The host-routes keyword specifies that local label
allocation be done for host routes only.
Step 6 no allocate global {prefix-list {list-name | Removes the specific MPLS LDP local label allocation
list-number} | host-routes} filter without resetting the LDP session.
• The global keyword specifies the global routing.
Example:
Router(config-ldp-lbl)# no allocate global
• The prefix-list keyword specifies a prefix list to be
host-routes used as a filter for MPLS LDP local label allocation.
• The list-name argument indicates a name that identifies
the prefix list.
• The list-number argument indicates a number that
identifies the prefix list.
• The host-routes keyword specifies that host routes be
used as a filter for MPLS LDP local label allocation.
Step 7 no mpls ldp label Removes all local label allocation filters configured under
the MPLS LDP label configuration mode and restores LDP
default behavior for local label allocation without a session
Example:
Router(config-ldp-lbl)# no mpls ldp label
reset.
Step 8 exit Exits from MPLS LDP label configuration mode.
Example:
Router(config-ldp-lbl)# exit
Example:
8
Verifying MPLS LDP—Local Label Allocation Filtering Configuration

Perform the following task to verify the MPLS LDP—Local Label Allocation Filtering configuration.
SUMMARY STEPS
1. enable
2. show mpls ldp bindings detail
3. debug mpls ldp bindings filter
4. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls ldp bindings detail

Use this command to verify that local label allocation filtering is configured as you expect. For example:
Router# show mpls ldp bindings detail
Advertisement spec:
Prefix acl = bar
Local label filtering spec: host routes.
lib entry: 10.1.1.1/32, rev 9

lib entry: 10.10.7.0/24, rev 10
lib entry: 10.10.8.0/24, rev 11
lib entry: 10.10.9.0/24, rev 12
lib entry: 10.41.41.41/32, rev 17
lib entry: 10.50.50.50/32, rev 15
lib entry: 10.60.60.60/32, rev 18
lib entry: 10.70.70.70/32, rev 16
lib entry: 10.80.80.80/32, rev 14
The output of this command verifies that host routes are configured as the local label allocation filter for
the router.
Step 3 debug mpls ldp binding filter

Use this command to verify that local label allocation filtering was configured properly and to display
how LDP accepts or withdraw labels. For example:
Router# debug mpls ldp binding filter
LDP Local Label Allocation Filtering changes debugging is on

.
.
.
9
Configuration Examples for MPLS LDP—Local Label Allocation Filtering
Step 4 exit
Router# exit
Router>
Configuration Examples for MPLS LDP—Local Label Allocation

Filtering
This section contains the following configuration examples for the MPLS LDP—Local Label Allocation
Filtering feature:
• Creating a Prefix List for MPLS LDP Local Label Allocation Filtering: Examples, page 10
• Configuring MPLS LDP Local Label Allocation Filtering: Examples, page 11
• Sample MPLS LDP Local Label Allocation Filtering Configuration: Example, page 11
Creating a Prefix List for MPLS LDP Local Label Allocation Filtering: Examples
The following examples show how to configure a prefix list for MPLS LDP local label allocation
filtering.
In this example, prefix list List1 permits only 192.168.0.0/16 prefixes. LDP accepts 192.168.0.0/16
prefixes, but would not assign a local label for the following prefixes: 192.168.0.0/24 and
192.168.2.0/24. For example:
configure terminal
!
ip prefix-list List1 permit 192.168.0.0/16
end
In the following example, prefix list List2 permits a range of prefixes from 192.168.0.0/16 to /20
prefixes. LDP would accept 192.168.0.0/16 prefixes, but would not assign local labels for the following
prefixes: 192.168.0.0/24 and 192.168.2.0/24.
configure terminal
!
ip prefix-list List2 permit 192.168.0.0/16 le 20
end
In the following example, prefix list List3 permits a range of prefixes greater than /18. LDP would accept
192.168.17.0/20 and 192.168.2.0/24 prefixes, but would not assign a local label for 192.168.0.0/16.
configure terminal
!
ip prefix-list List3 permit 192.168.0.0/16 ge 18
end
10
Configuring MPLS LDP Local Label Allocation Filtering: Examples

The following examples show how to configure MPLS LDP local label allocation filtering.
This examples shows how to allocate a prefix list to be used as a local label allocation filter:
configure terminal
!
ip prefix-list List3 permit 192.168.0.0/16 ge 18
!
mpls ldp label
allocate global prefix-list List3
exit
exit
Prefix list List3, which permits a range of prefixes greater than /18, is configured as the local label
allocation filter for the router. LDP would allow 192.168.17.0/20 and 192.168.2.0/24 prefixes, but would
withdraw labels for prefixes not in the allowed range.
In the following example, host routes are configured as the local label allocation filter:
configure terminal
!
mpls ldp label
allocate global host-routes
exit
exit
LDP allocates local labels for host routes that are in the global routing table.
In the following example, a specific local label allocation filter is removed:
configure terminal
!
mpls ldp label
no allocate global host-routes
exit
exit
In the following example, all local label allocation filters configured in MPLS LDP label configuration
mode are removed and the default LDP local label allocation is restored without a session reset:
configure terminal
!
no mpls ldp label
exit
exit
Sample MPLS LDP Local Label Allocation Filtering Configuration: Example

Figure 3 is a sample configuration that is used in this section to show how MPLS LDP local label
allocation filtering works:
• Routers R1, R2, and R3 have loopback addresses 10.1.1.1, 10.2.2.2, and 10.3.3.3 defined and
advertised by the IGP, respectively.
• 10.1.1.1 is the router ID of Router R1, 10.2.2.2 is the router ID of Router R2, and 10.3.3.3 is the
router ID of Router R3.
• A prefix list is defined on Router R1 to specify the local labels for which LDP allocates a local label.
Router RI learns a number of routes from its IGP neighbors on Routers R2 and R3.
11
Figure 3 LDP Local Label Allocation Filtering Example
R1
Lo 10.1.1.1
Local
Lable labels Label
bindings
bindings
To R2 Prefix list To R3
Lo 10.2.2.2 Lo 10.3.3.3
Global
routing
table
185878
You can use LDP CLI commands to verify the following:
• Router R1 has allocated a local label for the correct subset of the prefixes.
• Routers R2 and R3 did not receive any remote bindings for the prefixes for which Router R1 did not
assign a local label.
Routing Table on Router R1

You can enter the show ip route command to display the current state of the routing table. The following
example shows the routing table on Router R1 based on Figure 3:
R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, 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
i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
ia - IS-IS inter area, * - candidate default, U - per-user static route
o - ODR, P - periodic downloaded static route
Gateway of last resort is not set
10.0.0.0/32 is subnetted, 1 subnets

C 10.1.1.1 is directly connected, Loopback0
O 10.2.2.2 [110/11] via 10.10.7.1, 00:00:36, FastEthernet1/0/0
C 10.10.7.0 is directly connected, FastEthernet1/0/0
[110/20] via 10.10.7.1, 00:00:36, FastEthernet1/0/0
C 10.10.9.0 is directly connected, FastEthernet3/0/0
Local Label Bindings on Router R1, Router R 2, and Router R3

You can enter the show mpls ldp bindings command on Routers R1, R2, and R3 to display the contents
of the LIB on each router. In the following examples, the default LDP allocation behavior is in operation;
that is, LDP allocates a local label for every route and advertises a label binding for every route learned
from the IGP.
12
LIB on Router R
This example shows the contents of the LIB on Router R1 based on the configuration in Figure 3:
R1# show mpls ldp bindings
lib entry: 10.1.1.1/32, rev 7

local binding: label: imp-null
remote binding: lsr: 10.3.3.3:0, label: 16
lib entry: 10.2.2.2/32, rev 13
local binding: label: 1000
remote binding: lsr: 10.2.2.2:0, label: imp-null
lib entry: 10.3.3.3/32, rev 15
lib entry: 10.10.7.0/24, rev 8
lib entry: 10.10.8.0/24, rev 11
lib entry: 10.10.9.0/24, rev 9
The local labels assigned to 10.2.2.2 and 10.3.3.3 on Router R1 are advertised to Routers R2 and R3.
LIB on Router R2
lib entry: 10.1.1.1/32, rev 11

lib entry: 10.2.2.2/32, rev 7
lib entry: 10.3.3.3/32, rev 15
lib entry: 10.10.7.0/24, rev 8
lib entry: 10.10.8.0/24, rev 9
lib entry: 10.10.9.0/24, rev 13
13
LIB on Router R3
lib entry: 10.1.1.1/32, rev 13

lib entry: 10.2.2.2/32, rev 15
lib entry: 10.3.3.3/32, rev 7
lib entry: 10.10.7.0/24, rev 11
lib entry: 10.10.8.0/24, rev 8
lib entry: 10.10.9.0/24, rev 9
Local Label Allocation Filtering Configuration on Router R1

You enter the mpls ldp label command to configure a local label allocation filter. The following
examples show how to configure a local label allocation filter by host routes only and by a prefix list.
Local Label Allocation Filter—Host Routes Only Configuration

This example shows the selection of host routes as the only filter.
The following local label allocation filtering is defined on Router R1 under MPLS LDP label
configuration mode:
configure terminal
!
mpls ldp label
allocate global host-routes
exit
exit
Local Label Allocation Filter—Prefix List Configuration

The following example shows how to configure a local label allocation filter that allows or denies
prefixes based on a prefix list:
configure terminal
!
mpls ldp label
allocate global prefix-list ListA
exit
end
14
ListA is a prefix list defined as:

configure terminal
!
ip prefix-list ListA permit 0.0.0.0/32 ge 32
Local Label Allocation Filtering Changes Label Bindings on Router R1, Router R 2, and Router R3
After configuring a local label allocation filter on Router R1, you can enter the show mpls ldp bindings
command again to see the changes in the local label bindings in the LIB on each router. Changes to the
output in the LIB entries are highlighted in bold text.
This sample prefix list is used for the examples in the this section:
ip prefix-list ListA permit 0.0.0.0/32 ge 32
LIB on Router R1 After Local Label Allocation Filtering

This example shows how the configuration of a local label allocation prefix-list filter changes the
contents of the LIB on Router R1:
lib entry: 10.1.1.1/32, rev 7

lib entry: 10.2.2.2/32, rev 13
lib entry: 10.3.3.3/32, rev 15
lib entry: 10.10.7.0/24, rev 8
no local binding
lib entry: 10.10.8.0/24, rev 11
no local binding
lib entry: 10.10.9.0/24, rev 9
no local binding
Local label bindings for all but 10.2.2.2 and 10.3.3.3 on Router R1 are advertised as withdrawn.

This example shows how the configuration of a local label allocation prefix-list filter on Router R1
changes the contents of the LIB on Router R2:
lib entry: 10.1.1.1/32, rev 11

lib entry: 10.2.2.2/32, rev 7
15

lib entry: 10.3.3.3/32, rev 15
lib entry: 10.10.7.0/24, rev 8
lib entry: 10.10.8.0/24, rev 9
lib entry: 10.10.9.0/24, rev 13
The 10.10.7.0/24, 10.10.8.0/24, and 10.10.9.0/24 prefixes are no longer assigned local labels. Therefore,
Router R1 sends no label advertisement for these prefixes.

This example shows how the configuration of a local label allocation prefix-list filter on Router R1
changes the contents of the LIB on Router R3:
lib entry: 10.1.1.1/32, rev 13

lib entry: 10.2.2.2/32, rev 15
lib entry: 10.3.3.3/32, rev 7
lib entry: 10.10.7.0/24, rev 11
lib entry: 10.10.8.0/24, rev 8
lib entry: 10.10.9.0/24, rev 9
The 10.10.7.0/24, 10.10.8.0/24, and 10.10.9.0/24 prefixes are no longer assigned local labels. Again,
Router R1 sends no label advertisement for these prefixes.
Command to Display the Local Label Allocation Filter

You can enter the show mpls ldp detail command to display the filter used for local label allocation. For
example:
Router# show mpls ldp bindings detail
Advertisement spec:
Prefix acl = List1
Local label filtering spec: host routes. ! <--- Local local label filtering spec
16
lib entry: 10.1.1.1/32, rev 9

lib entry: 10.10.7.0/24, rev 10
lib entry: 10.10.8.0/24, rev 11
lib entry: 10.10.9.0/24, rev 12
lib entry: 10.41.41.41/32, rev 17
lib entry: 10.50.50.50/32, rev 15
lib entry: 10.60.60.60/32, rev 18
lib entry: 10.70.70.70/32, rev 16
lib entry: 10.80.80.80/32, rev 14
The following sections provide references related to the MPLS LDP—Local Label Allocation Filtering
feature.
Related Documents
Configuration tasks for MPLS LDP MPLS Label Distribution Protocol Overview
Configuration tasks for inbound label binding filtering MPLS LDP Inbound Label Binding Filtering
for MPLS LDP
Standards
Standard Title
MIBs
MIB MIBs Link
17
RFCs
RFC Title
RFC 3815 Definitions of Managed Objects for the Multiprotocol Label
Switching (MPLS), Label Distribution Protocol (LDP)
Description Link
18
Feature Information for MPLS LDP—Local Label Allocation Filtering
Feature Information for MPLS LDP—Local Label Allocation

Filtering
Table 1 Feature Information for MPLS LDP—Local Label Allocation Filtering

MPLS LDP—Local Label Allocation Cisco IOS XE This feature introduces command-line interface (CLI)
Filtering Releases 2.1 commands to modify the way in which Multiprotocol Label
Switching (MPLS) Label Distribution Protocol (LDP)
handles local label allocation. This MPLS LDP feature
enhancement enables the configuration of filtering policies
for selective local label binding assignments by LDP to
improve LDP scalability and convergence. This document
contains information about and instructions on how to
configure the MPLS LDP—Local Label Allocation
Filtering feature.
In Cisco IOS XE Releases 2.1, the feature was introduced
on the Cisco ASR 1000 Series Aggregation Services
Routers.
feature:
• MPLS LDP Local Label Allocation Filtering Overview,
page 2
• Prefix Lists for MPLS LDP Local Label Allocation
Filtering: Benefits and Description, page 4
• Local Label Allocation Changes and LDP Actions,
page 4
• LDP Local Label Filtering and BGP Routes, page 5
• Creating a Prefix List for MPLS LDP Local Label
Allocation Filtering, page 5
19
Feature Information for MPLS LDP—Local Label Allocation Filtering
Table 1 Feature Information for MPLS LDP—Local Label Allocation Filtering (continued)

• Configuring MPLS LDP Local Label Allocation
Filtering, page 7
• Verifying MPLS LDP—Local Label Allocation
Filtering Configuration, page 9
allocate, debug mpls ldp bindings, mpls ldp label, show
mpls ldp bindings.
20
Glossary
Glossary
BGP—Border Gateway Protocol. An interdomain routing protocol that replaces Exterior Gateway
Protocol (EGP). A BGP system exchanges reachability information with other BGP systems. It is
defined by RFC 1163.
provider edge (PE) router. CE routers do not have routes to associated Virtual Private Networks (VPNs)
in their routing tables.
FEC—Forwarding Equivalency Class. A set of packets that can be handled equivalently for the purpose
of forwarding and thus is suitable for binding to a single label. The set of packets destined for an address
prefix is one example of an FEC.
IGP—Interior Gateway Protocol. Internet protocol used to exchange routing information within a single
autonomous system. Examples of common Internet IGP protocols include Interior Gateway Routing
Protocol (IGRP), Open Shortest Path First (OSPF), Intermediate System-to-Intermediate System
(IS-IS), and Routing Information protocol (RIP).
label—A short fixed-length label that tells switching nodes how to forward data (packets or cells).
LDP—Label Distribution Protocol. A standard protocol between Multiprotocol Label Switching
(MPLS)-enabled routers that is used for the negotiation of the labels (addresses) used to forward packets.
LIB—Label Information Base. A database used by a label switch router (LSR) to store labels learned
from other LSRs, and labels assigned by the local LSR.
LSP—label switched path. A sequence of hops in which a packet travels from one router to another
router by means of label switching mechanisms. A label switched path can be established dynamically,
based on normal routing mechanisms, or through configuration.
LSR—label switch router. A device that forwards Multiprotocol Label Switching (MPLS) packets based
on the value of a fixed-length label encapsulated in each packet.
MPLS—Multiprotocol Label Switching. A switching method that forwards IP traffic using a label. This
label instructs the routers and the switches in the network where to forward the packets. The forwarding
of MPLS packets is based on preestablished IP routing information
PE router—provider edge router. A router that is part of a service provider’s network connected to a
customer edge (CE) router. All Virtual Private Network (VPN) processing occurs in the PE router.
VPN—Virtual Private Network. A secure IP-based network that shares resources on one or more
physical networks. A VPN contains geographically dispersed sites that can communicate securely over
a shared backbone.
21
Glossary
countries.
22
MPLS LDP—Lossless MD5 Session
Authentication

The MPLS LDP—Lossless MD5 Session Authentication feature enables a Multiprotocol Label
Switching (MPLS) Label Distribution Protocol (LDP) session to be password-protected without tearing
down and reestablishing the LDP session.

which each feature is supported, see the “Feature Information for MPLS LDP—Lossless MD5 Session
Authentication” section on page 30.
Contents
• Prerequisites for MPLS LDP—Lossless MD5 Session Authentication, page 2
• Restrictions for MPLS LDP—Lossless MD5 Session Authentication, page 2
• Information About MPLS LDP—Lossless MD5 Session Authentication, page 2
• How to Configure MPLS LDP—Lossless MD5 Session Authentication, page 6
• Configuration Examples for MPLS LDP—Lossless MD5 Session Authentication, page 16
• Feature Information for MPLS LDP—Lossless MD5 Session Authentication, page 30
MPLS LDP—Lossless MD5 Session Authentication
Prerequisites for MPLS LDP—Lossless MD5 Session Authentication
Prerequisites for MPLS LDP—Lossless MD5 Session

Authentication
The MPLS LDP—Lossless MD5 Session Authentication feature is an enhancement to the MPLS LDP
MD5 Global Configuration feature. Before configuring the MPLS LDP—Lossless MD5 Session
Authentication feature, refer to the MPLS—LDP MD5 Global Configuration feature module for more
information on how the message digest algorithm 5 (MD5) works with MPLS LDP to ensure that LDP
segments remain properly protected.
Note The MPLS LDP—Lossless MD5 Session Authentication feature must be configured before MPLS LDP
is configured.
Configure the following features on the label switch router (LSR) before configuring the MPLS
LDP—Lossless MD5 Session Authentication feature:
• Distributed Cisco Express Forwarding
• Static or dynamic routing
• MPLS Virtual Private Network (VPN) routing and forwarding (VRFs) instances for MPLS VPNs
• MPLS LDP—Lossless MD5 Session Authentication for the MPLS VPN VRFs
Note If a VRF is deleted, then the lossless MD5 session authentication for that VRF is automatically removed.
Restrictions for MPLS LDP—Lossless MD5 Session

Authentication
MD5 protection applies to LDP sessions between peers.
Information About MPLS LDP—Lossless MD5 Session

Authentication
You should understand the following concepts before configuring the MPLS LDP—Lossless MD5
Session Authentication feature:
• How MPLS LDP Messages in MPLS LDP—Lossless MD5 Session Authentication are Exchanged,
page 3
• The Evolution of MPLS LDP MD5 Password Features, page 3
• Keychains Use with MPLS LDP—Lossless MD5 Session Authentication, page 4
• Application of Rules to Overlapping Passwords, page 4
• Password Rollover Period Guidelines, page 5
• Resolving LDP Password Problems, page 5
2
Information About MPLS LDP—Lossless MD5 Session Authentication
How MPLS LDP Messages in MPLS LDP—Lossless MD5 Session

Authentication are Exchanged
MPLS LDP messages (discovery, session, advertisement, and notification messages) are exchanged
between LDP peers through two channels:
• LDP discovery messages are transmitted as User Datagram Protocol (UDP) packets to the
well-known LDP port.
• Session, advertisement, and notification messages are exchanged through a TCP connection
established between two LDP peers.
The MPLS LDP—Lossless MD5 Session Authentication feature allows an LDP session to be
password-protected without tearing down and reestablishing the LDP session. The MD5 password can
be implemented and changed without interrupting the LDP session.
The Evolution of MPLS LDP MD5 Password Features

The initial version of LDP MD5 protection allowed authentication to be enabled between two LDP peers
and each segment sent on the TCP connection was verified between the peers. Authentication was
configured on both LDP peers using the same password; otherwise, the peer session was not established.
The mpls ldp neighbor command was issued with the password keyword. When MD5 protection was
enabled, the router tore down the existing LDP sessions and established new sessions with the neighbor
router.
An improved MD5 protection feature, called MPLS—LDP MD5 Global Configuration, was later
introduced that allowed LDP MD5 to be enabled globally instead of on a per-peer basis. Using this
feature, password requirements for a set of LDP neighbors could be configured. The MPLS LDP MD5
Global Configuration feature also improved the ability to maintain the LDP session. The LDP session
with a peer was not automatically torn down when the password for that peer was changed. The new
password was implemented the next time an LDP session was established with the peer.
The MPLS LDP—Lossless MD5 Session Authentication feature is based on the MPLS LDP MD5
Global Configuration feature. However, the MPLS LDP—Lossless MD5 Session Authentication feature
provides the following enhancements:
• Activate or change LDP MD5 session authentication without interrupting the LDP session.
• Configure multiple passwords, so one password can be used now and other passwords later.
• Configure asymmetric passwords, which allows one password to be used for incoming TCP
segments and a different password to be used for outgoing TCP segments.
• Configure passwords so that they overlap for a period of time. This functionality is beneficial when
the clocks on two LSRs are not synchronized.
These enhancements are available by using the key-chain command, which allows different key strings
to be used at different times according to the keychain configuration.
3
Keychains Use with MPLS LDP—Lossless MD5 Session Authentication

The MPLS LDP—Lossless MD5 Session Authentication feature allows keychains to be used to specify
different MD5 keys to authenticate LDP traffic exchanged in each direction.
In the following example, three passwords are configured:
key chain ldp-pwd
key 1
key-string lab
send-lifetime 10:00:00 Nov 2 2008 10:00:00 Dec 2 2008
accept-lifetime 00:00:00 Jan 1 1970 duration 1
key 2
key-string lab2
send-lifetime 00:00:00 Jan 1 1970 duration 1
accept-lifetime 10:00:00 Nov 2 2008 10:00:00 Nov 17 2008
key 3
key-string lab3
accept-lifetime 10:00:00 Nov 17 2008 10:00:00 Dec 2 2008
!
mpls ldp password option 1 for nbr-acl key-chain ldp-pwd
• Key 1 specifies the lab password. The send-lifetime command enables the lab password to
authenticate the outgoing TCP segments from November 2, 2008, at 10:00:00 a.m. until
December 2, 2008, at 10:00:00 a.m. The accept-lifetime command is configured so that the lab
password is never used to authenticate incoming TCP segments. The accept-lifetime command
enables the lab password for 1 second on January 1, 1970. By setting the date to the past and by
enabling a duration of 1 second, the password for incoming TCP segments immediately expires. If
the accept-lifetime command is omitted from the keychain configuration, then the password is
always valid for incoming TCP segments.
• Key 2 and key 3 specify the lab2 and lab3 passwords, respectively. The send-lifetime commands
enable the passwords for 1 second on January 1, 1970. By setting the date to the past and by enabling
a duration of 1 second, the passwords for outgoing TCP segments immediately expire. If the
send-lifetime commands are omitted from the keychain configuration, the passwords are always
valid for outgoing TCP segments. The accept-lifetime commands for key 2 and key 3 enable the
passwords to authenticate the incoming TCP segments from November 2, 2008, at 10:00:00 a.m.
until November 17, 2008, at 10:00:00 a.m. and from November 17, 2008, at 10:00:00 a.m. until
December 2, 2008, at 10:00:00 a.m., respectively.
Application of Rules to Overlapping Passwords

Overlapping passwords can be useful when two LSRs have clocks that are not synchronized. The
overlapping passwords provide a window to ensure that TCP packets are not dropped. The following
rules apply to overlapping passwords:
• If the send-lifetime value for the next password begins before the send-lifetime value of the current
password expires, the password with the shorter key ID is used during the overlap period. The
send-lifetime value of the current password can be shortened by configuring a shorter send-lifetime
value. Similarly, the send-lifetime value of the current password can be lengthened by configuring
a longer send-lifetime value.
4
• If the accept-lifetime value for the next password begins before the accept-lifetime value of the
current password expires, both the next password and the current password are used concurrently.
The next password information is passed to TCP. If TCP fails to authenticate the incoming segments
with the current password, it tries authenticating with the next password. If TCP authenticates a
segment using the new password, it discards the current password and uses the new password from
that point on.
• If a password for incoming or outgoing segments expires and no additional valid password is
configured, one of the following actions take place:
– If a password is required for the neighbor, LDP drops the existing session.
– If a password is not required for the neighbor, LDP attempts to roll over to a session that does
not require authentication. This attempt also fails unless the password expires on both LSRs at
the same time.
Password Rollover Period Guidelines

Both old and new passwords are valid during a rollover period. This ensures a smooth rollover when
clocks are not synchronized between two LDP neighbors. When passwords are configured using a
keychain, the rollover period is equal to the accept-lifetime overlap between two successive receive
passwords.
The minimum rollover period (the duration between two consecutive MD5 key updates) must be longer
than the value of the LDP keepalive interval time to ensure an update of new MD5 authentication keys.
If LDP session hold time is configured to its default value of 3 minutes, the LDP keepalive interval is
1 minute. The minimum rollover period should be 5 minutes. However, we recommend that the
minimum rollover period is set to between 15 and 30 minutes.
To ensure a seamless rollover, follow these guidelines:
• Ensure that the local time on the peer LSRs is the same before configuring the keychain.
• Check for error messages (TCP-6-BADAUTH) that indicate keychain misconfiguration.
• Validate the correct keychain configuration by checking for the following password messages:
%LDP-5-PWDCFG: Password configuration changed for 10.1.1.1:0
%LDP-5-PWDRO: Password rolled over for 10.1.1.1:0
Resolving LDP Password Problems

LDP displays error messages when an unexpected neighbor attempts to open an LDP session, or the LDP
password configuration is invalid. Some existing LDP debugs also display password information.
When a password is required for a potential LDP neighbor, but no password is configured for it, the LSR
ignores LDP hello messages from that neighbor. When the LSR processes the hello message and tries to
establish a TCP connection with the neighbor, it displays the error message and stops establishing the
LDP session with the neighbor. The error is rate-limited and has the following format:
00:00:57: %LDP-5-PWD: MD5 protection is required for peer 10.2.2.2:0(glbl), no password
configured
When passwords do not match between LDP peers, TCP displays the following error message on the
LSR that has the lower router ID; that is, the router that has the passive role in establishing TCP
connections:
00:01:07: %TCP-6-BADAUTH: Invalid MD5 digest from 10.2.2.2(11051) to 10.1.1.1(646)
5
How to Configure MPLS LDP—Lossless MD5 Session Authentication
If one peer has a password configured and the other one does not, TCP displays the following error
messages on the LSR that has a password configured:
00:02:07: %TCP-6-BADAUTH: No MD5 digest from 10.1.1.1(646) to 10.2.2.2(11099)
How to Configure MPLS LDP—Lossless MD5 Session

Authentication
• Configuring MPLS LDP—Lossless MD5 Session Authentication Using a Keychain, page 6
(optional)
• Enabling the Display of MPLS LDP Password Rollover Changes and Events, page 11 (optional)
• Changing MPLS LDP—Lossless MD5 Session Authentication Passwords, page 13 (optional)
Configuring MPLS LDP—Lossless MD5 Session Authentication Using a

Keychain
Perform the following task to configure the MPLS LDP—Lossless MD5 Session Authentication feature
using a keychain. Keychains allow a different key string to be used at different times according to the
keychain configuration. MPLS LDP queries the appropriate keychain to obtain the current live key and
key ID for the specified keychain.
SUMMARY STEPS
1. enable
3. access-list access-list-number {permit | deny} {type-code wildcard-mask | ip-address mask}
4. key chain name-of-chain
5. key key-id
6. key-string string
7. accept-lifetime {start-time | local start-time} {duration seconds | end-time | infinite}
8. send-lifetime {start-time | local start-time} {duration seconds | end-time | infinite}
9. exit
10. exit
11. mpls ldp [vrf vrf-name] password option number for acl {key-chain keychain-name | [0 | 7]
password}
12. exit
13. show mpls ldp neighbor [vrf vrf-name | all] [ip-address | interface] [detail] [graceful-restart]
6
DETAILED STEPS

• Enter the password if prompted.
Example:
Router> enable
Example:
Step 3 access-list access-list-number {permit | deny} Creates an access list.
{type-code wildcard-mask | ip-address mask}
Example:
Router(config)# access-list 10 permit 10.2.2.2
Step 4 key chain name-of-chain Enables authentication for routing protocols and
identifies a group of authentication keys.
Example: • Enters keychain configuration mode.
Router(config)# key chain ldp-pwd
Step 5 key key-id Identifies an authentication key on a keychain.
• The key-id value must be a numeral.
Example: • Enters keychain key configuration mode.
Router(config-keychain)# key 1
Step 6 key-string string Specifies the authentication string for a key.
• The string value can be 1 to 80 uppercase or
Example: lowercase alphanumeric characters; the first
Router(config-keychain-key)# key-string pwd1 character cannot be a numeral.
7

Step 7 accept-lifetime {start-time | local start-time} Specifies the time period during which the
{duration seconds | end-time | infinite} authentication key on a keychain can be used for
verifying incoming TCP segments.
Example: The start-time argument identifies the time to start
Router(config-keychain-key)# accept-lifetime 10:00:00 and the local start-time argument identifies the
Jan 13 2007 10:00:00 Jan 13 2009
time to start in the local time zone. Both arguments
have the same parameters:
Note The time reference depends on the clock
time zone configuration on the router. If no
time zone configured, then the default time
zone uses the Coordinated Universal Time
(UTC) time. If it is configured, either the
Eastern Standard Time (EST) or Pacific
Standard Time (PST) time zone is used.
• hh:mm:ss is the time format.

• Enter the number of days from 1 to 31.
• Enter the name of the month.
• Enter the year from the present to 2035.
Once the start time is entered, select from the
following:
• The duration keyword sets the key lifetime
duration in seconds.
• The end-time argument sets the time to stop.
These parameters are the same as those used
for the start-time argument.
• The infinite keyword allows the
accept-lifetime period to never expire.
If the no accept-lifetime value is defined, the
associated receive password is valid for
authenticating incoming TCP segments.
8

Step 8 send-lifetime {start-time | local start-time} Specifies the time period during which the
{duration seconds | end-time | infinite} authentication key on a keychain can be used for
verifying outgoing TCP segments. The start-time
Example: argument identifies the time to start and the local
Router(config-keychain-key)# send-lifetime 10:00:00 start-time argument identifies the time to start in
Jan 13 2007 10:00:00 Jan 13 2009 the local time zone. Both arguments have the same
parameters:
Note The time reference depends on the clock
time zone configuration on the router. If no
time zone configured, then the default time
zone uses the UTC time. If it is configured,
either the EST or PST time zone is used.
• hh:mm:ss is the time format.

• Enter the number of days from 1 to 31.
• Enter the name of the month.
• Enter the year from 1993 to 2035.
Once the start time is entered, select from the
following:
• The duration keyword sets the send lifetime
duration in seconds.
• The end-time argument sets the time to stop.
These parameters are the same as those used
for the start-time argument.
• The infinite keyword allows the send lifetime
period to never expire.
If the no send-lifetime value is defined, the
associated send password is valid for
authenticating outgoing TCP segments.
Step 9 exit Exits from keychain key configuration mode.
Example:
Router(config-keychain-key)# exit
Step 10 exit Exits from keychain configuration mode.
Example:
Router(config-keychain)# exit
9

Step 11 mpls ldp [vrf vrf-name] password option number for acl Configures an MD5 password for LDP sessions
{key-chain keychain-name | [0 | 7] password} with neighbors whose LDP router IDs are
permitted by a specified access list.
Example: • The vrf vrf-name keyword-argument pair
Router(config)# mpls ldp password option 1 for 10 specifies a VRF configured on the LSR.
keychain ldp-pwd
• The number argument defines the order in
which the access lists are evaluated in the
determination of a neighbor password. The
valid range is 1 to 32767.
• The for acl keyword-argument pair specifies
the name of the access list that includes the
LDP router IDs of those neighbors for which
the password applies. Only standard IP access
list values (1 to 99) can be used for the acl
argument.
• The key-chain keychain-name
keyword-argument pair specifies the name of
the keychain to use.
• The 0 and 7 keywords specify whether the
password that follows is hidden (encrypted);
– 0 specifies an unencrypted password.
– 7 specifies an encrypted password.
• The password argument specifies the MD5
password to be used for the specified LDP
sessions.
10

Step 12 exit Exits from global configuration mode.
Example:
Step 13 show mpls ldp neighbor [vrf vrf-name | all] Displays the status of LDP sessions.
[ip-address | interface] [detail] [graceful-restart]
• The vrf vrf-name keyword-argument pair
displays the LDP neighbors for the specified
Example: VRF instance.
• The ip-address argument identifies the
neighbor with the IP address for which
password protection is configured.
• The interface argument identifies the LDP
neighbors accessible over this interface.
• The detail keyword displays information in
long form, including password information for
this neighbor. Here are the items displayed:
– An indication as to whether a password is
mandatory for this neighbor (required/not
required)
– The password source
(neighbor/fallback/number [option
number])
– An indication as to whether the latest
configured password for this neighbor is
used by the TCP session (in use) or the
TCP session uses an old password (stale)
• The graceful-restart keyword displays
per-neighbor graceful restart information.
Enabling the Display of MPLS LDP Password Rollover Changes and Events
When a password is required for a neighbor, but no password is configured for the neighbor, the
following debug message is displayed:
00:05:04: MDSym5 protection is required for peer 10.2.2.2:0(glbl), but no password
configured.
To enable the display of events related to configuration changes and password rollover events, perform
the following task.
SUMMARY STEPS
1. enable
3. mpls ldp logging password configuration [rate-limit number]
4. mpls ldp logging password rollover [rate-limit number]
11
5. exit
6. debug mpls ldp transport events
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls ldp logging password configuration This command is used to enable the display of events
[rate-limit number] related to configuration changes.
• The output displays events when a new password is
Example: configured or an existing password has been changed or
Router(config)# mpls ldp logging password deleted. A rate limit of 1 to 60 messages a minute can
configuration rate-limit 30
be specified.
Step 4 mpls ldp logging password rollover [rate-limit This command is used to enable the display of events
number] related to password rollover events.
• Events are displayed when a new password is used for
Example: authentication or when authentication is disabled. A
Router(config)# mpls ldp logging password rate limit of 1 to 60 messages a minute can be specified.
rollover rate-limit 25
Step 5 exit This command exits global configuration mode.
Example:
Step 6 debug mpls ldp transport events This command displays notifications when a session TCP
MD5 option is changed.
Example: • You can also use the debug mpls ldp transport
Router# debug mpls ldp transport events connections command to display notifications when
the MD5 option is changed.
Example:
Router# debug mpls ldp transport events
00:03:44: ldp: MD5 setup for peer 10.2.2.2:0(glbl); password changed to adfas
00:05:04: ldp: MD5 setup for peer 10.52.52.2:0(vpn1(1)); password changed to [nil]
12
Changing MPLS LDP—Lossless MD5 Session Authentication Passwords

To change an MPLS LDP—Lossless MD5 Session Authentication password, perform the following task.
The MPLS LDP—Lossless MD5 Session Authentication feature allows MD5 passwords to be changed
for LDP session authentication without having to close and reestablish an existing LDP session.
SUMMARY STEPS
1. enable
3. mpls ldp [vrf vrf-name] password rollover duration minutes
4. mpls ldp [vrf vrf-name] password fallback {key-chain keychain-name | [0 | 7] password}
5. no mpls ldp neighbor [vrf vrf-name] ip-address password password
6. exit
7. show mpls ldp neighbor [vrf vrf-name] [ip-address | interface] [detail] [graceful-restart]
DETAILED STEPS

• Enter the password if prompted.
Example:
Router> enable
Example:
Step 3 mpls ldp [vrf vrf-name] password rollover duration Configures the duration before the new password
minutes takes effect.
Example: specifies a VRF configured on the LSR.
Router(config)# mpls ldp password rollover duration 7
• The minutes argument specifies the number of
minutes from 5 to 65535 before the password
rollover occurs on this router.
13

Step 4 mpls ldp [vrf vrf-name] password fallback {key-chain Configures an MD5 password for LDP sessions
keychain-name | [0 | 7] password} with peers.
Example: specifies a VRF configured on the LSR.
Router(config)# mpls ldp password fallback key-chain
fallback • The key-chain keychain-name
keyword-argument pair specifies the name of
the keychain used to specify the MD5 key that
authenticates the exchange of bidirectional
LDP traffic.
• The 0 and 7 keywords specify whether the
password that follows is hidden (encrypted);
– 0 specifies an unencrypted password.
– 7 specifies an encrypted password.
• The password argument specifies the MD5
password to be used for the specified LDP
sessions.
Step 5 no mpls ldp neighbor [vrf vrf-name] ip-address Disables the configuration of a password for
password password computing MD5 checksums for the session TCP
connection with the specified neighbor.
Example: • The vrf vrf-name argument optionally
Router(config)# no mpls ldp neighbor 10.11.11.11 specifies the VRF instance for the specified
password lab1
neighbor.
neighbor router ID.
• The password password keyword-argument
pair is necessary so that the router computes
MD5 checksums for the session TCP
connection with the specified neighbor.
14

Step 6 exit Exits from global configuration mode.
Example:
Step 7 show mpls ldp neighbor [vrf vrf-name] [ip-address | Displays the status of LDP sessions.
interface] [detail] [graceful-restart]
displays the LDP neighbors for the specified
Example: VRF instance.
neighbor with the IP address for which
password protection is configured.
• The interface argument lists the LDP
neighbors accessible over this interface.
• The detail keyword displays information in
long form, including password information for
this neighbor. Here are the items displayed:
– An indication as to whether a password is
mandatory for this neighbor (required/not
required)
– The password source
(neighbor/fallback/number [option
number])
– An indication as to whether the latest
configured password for this neighbor is
used by the TCP session (in use) or the
TCP session uses an old password (stale)
• The graceful-restart keyword displays
per-neighbor graceful restart information.
15
Configuration Examples for MPLS LDP—Lossless MD5 Session Authentication
Configuration Examples for MPLS LDP—Lossless MD5 Session

Authentication
This section provides the following configuration examples:
• Configuring MPLS LDP—Lossless MD5 Session Authentication Using a Keychain (Symmetrical):
Example, page 16
• Configuring MPLS LDP—Lossless MD5 Session Authentication Using a Keychain
(Asymmetrical): Example, page 17
• Changing MPLS LDP—Lossless MD5 Session Authentication Password: Example, page 18
• Changing MPLS LDP—Lossless MD5 Session Authentication Password Using a Rollover Without
Keychain: Example, page 19
• Changing MPLS LDP—Lossless MD5 Session Authentication Password Using a Rollover with a
Keychain: Example, page 20
• Changing MPLS LDP—Lossless MD5 Session Authentication Password Using a Fallback Password
with a Keychain: Example, page 22
• Changing MPLS LDP—Lossless MD5 Session Authentication: Common Misconfiguration
Examples, page 24
• Changing MPLS LDP—Lossless MD5 Session Authentication Using a Second Key to Avoid LDP
Session Failure: Examples, page 26

Keychain (Symmetrical): Example
The following example shows a configuration of two peer LSRs that use symmetrical MD5 keys:
LSR1
access-list 10 permit 10.2.2.2
mpls ldp password required for 10
mpls ldp password option 1 for 10 ldp-pwd
!
key chain ldp-pwd
key 1
key-string pwd1
send-lifetime 10:00:00 Jan 1 2009 10:00:00 Feb 1 2009
accept-lifetime 09:00:00 Jan 1 2009 11:00:00 Feb 1 2009
!
interface loopback0
ip address 10.1.1.1 255.255.255.255
!
ip address 10.0.1.1 255.255.255.254
mpls ip
LSR2
!
16
key chain ldp-pwd

key 1
key-string pwd1
!
interface loopback0
ip address 10.2.2.2 255.255.255.255
!
ip address 10.0.1.2 255.255.255.254
mpls ip

Keychain (Asymmetrical): Example
The following example shows a configuration of two peer LSRs that use asymmetrical MD5 keys:
LSR1
!
key chain ldp-pwd
key 1
key-string pwd1
key 2
key-string pwd2
!
interface loopback0
ip address 10.1.1.1 255.255.255.255
!
ip address 10.0.1.1 255.255.255.254
mpls ip
LSR2
!
key chain ldp-pwd
key 1
key-string pwd2
key 2
key-string pwd1
!
interface loopback0
ip address 10.2.2.2 255.255.255.255
17
!
ip address 10.0.1.2 255.255.255.254
mpls ip
Changing MPLS LDP—Lossless MD5 Session Authentication Password:

Example
The following example shows the existing password configuration for LSR A, LSR B, and LSR C:
LSR A Existing Configuration

mpls ldp router-id loopback0 force
mpls ldp neighbor 10.11.11.11 password lab1
!
interface loopback0
ip address 10.10.10.10 255.255.255.255
!
ip address 10.2.0.1 255.255.0.0
mpls ip
!
ip address 10.0.0.1 255.255.0.0
mpls ip
LSR B Existing Configuration

!
interface loopback0
ip address 10.11.11.11 255.255.255.255
!
ip address 10.2.0.2 255.255.0.0
mpls ip
LSR C Existing Configuration

!
interface loopback0
ip address 10.12.12.12 255.255.255.255
!
ip address 10.0.0.2 255.255.0.0
mpls ip
!
18
The following example shows how the lossless password change is configured using the
mpls ldp password rollover duration command for LSR A, LSR B, and LSR C so there is enough time
to change all the passwords on all of the routers:
LSR A New Configuration

mpls ldp password rollover duration 10
mpls ldp password fallback lab2
no mpls ldp neighbor 10.11.11.11 password lab1
LSR B New Configuration

LSR C New Configuration

After 10 minutes has elapsed, the password changes. The following system logging message for LSR A
confirms that the password rollover was successful:
Changing MPLS LDP—Lossless MD5 Session Authentication Password Using

a Rollover Without Keychain: Example
The MPLS LDP—Lossless MD5 Session Authentication password can be changed in a lossless way
(without tearing down an existing LDP session) by using a password rollover without a keychain.
The following example shows the existing password configuration for LSR A and LSR B:

!
interface loopback0
ip address 10.10.10.10 255.255.255.255
!
interface FastEthernet1/0/0 ip address 10.2.0.1 255.255.0.0
mpls ip

!
interface loopback0
ip address 10.11.11.11 255.255.255.255
!
ip address 10.2.0.2 255.255.0.0
mpls ip
19
The following example shows the new password configuration for LSR A and LSR B:
Note The rollover duration should be large enough so that the passwords can be changed on all impacted
routers.


After 10 minutes (rollover duration), the password changes and the following system logging message
confirms the password rollover at LSR A:

a Rollover with a Keychain: Example
The Book Title password can be changed in a lossless way by using a password rollover with a keychain.
The following configuration example shows the new password keychain configuration for LSR A, LSR
B, and LSR C, in which the new password is ldp-pwd.
In the example, the desired keychain is configured first. The first pair of keys authenticate incoming TCP
segments (recv key) and compute MD5 digests for outgoing TCP segments (xmit key). These keys
should be the same keys as those currently in use; that is, in lab 1. The second recv key in the keychain
should be valid after a few minutes. The second xmit key becomes valid at a future time.
routers.

!
key chain ldp-pwd
key 10
key-string lab1
send-lifetime 10:00:00 Jan 1 2009 10:30:00 Jan 1 2009
accept-lifetime 10:00:00 Jan 1 2009 10:45:00 Jan 1 2009
key 11
key-string lab2
key 12
key-string lab3
send-lifetime 10:30:00 Feb 1 2009 10:30:00 Mar 1 2009
accept-lifetime 10:15:00 Feb 1 2009 10:45:00 Mar 1 2009
!
20
mpls ldp password option 5 for 10 key-chain ldp-pwd


key chain ldp-pwd
key 10
key-string lab1
key 11
key-string lab2
key 12
key-string lab3
!

key chain ldp-pwd
key 10
key-string lab1
key 11
key-string lab2
key 12
key-string lab3
!
After 10 minutes, the password changes and the following system logging message confirms the
password rollover at LSR A.
21

a Fallback Password with a Keychain: Example
The Book Title password can be changed in a lossless way by using a fallback password when doing a
rollover with a keychain.
Note The fallback password is used only when there is no other keychain configured. If there is a keychain
configured, then the fallback password is not used.
The following example shows the existing password configuration for LSR A, LSR B, and LSR C:

!
interface loopback0
ip address 10.10.10.10 255.255.255.255
!
ip address 10.2.0.1 255.255.0.0
mpls ip
!
ip address 10.0.0.1 255.255.0.0
mpls ip
!
!
key chain ldp-pwd
key 10
key-string lab1
!

!
interface loopback0
ip address 10.11.11.11 255.255.255.255
!
ip address 10.2.0.2 255.255.0.0
mpls ip
!
key chain ldp-pwd
key 10
key-string lab1
!
22
LSR C Existing Configuration

!
interface loopback0
ip address 10.12.12.12 255.255.255.255
!
ip address 10.0.0.2 255.255.0.0
mpls ip
!
key chain ldp-pwd
key 10
key-string lab1
!
Note The fallback keychain is not used unless the keychain ldp-pwd is removed using the no mpls ldp
password option 5 for 10 key-chain ldp-pwd command.
The following example shows the new configuration for LSR A, LSR B, and LSR C, where one keychain
is configured with the name ldp-pwd and another keychain is configured with the name fallback for the
fallback password.
routers.

!
key chain fallback
key 10
key-string fbk1
!
mpls ldp password fallback key-chain fallback
!
no mpls ldp password option 5 for 10 key-chain ldp-pwd

!
key chain fallback
key 10
key-string fbk1
!
!
23

key chain fallback
key 10
key-string fbk1
!
!
After 10 minutes, the password changes and the following system logging message confirms the
password rollover at LSR A:
Changing MPLS LDP—Lossless MD5 Session Authentication: Common

Misconfiguration Examples
The following sections describe common misconfiguration examples that can occur when the Book Title
password is migrated in a lossless way. Misconfigurations can lead to undesired behavior in an LDP
session.
• Incorrect Keychain LDP Password Configuration: Example, page 24
• Avoiding Access List Configuration Problems, page 26
Incorrect Keychain LDP Password Configuration: Example

Possible misconfigurations can occur when keychain-based commands are used with the mpls ldp
password option for key-chain command. If the accept-lifetime or send-lifetime command is not
specified in this configuration, then a misconfiguration can occur when more than two keys are in a
keychain.
The following example shows an incorrect keychain configuration with three passwords for LSR A and
LSR B in the keychain:
LSR A Incorrect Keychain LDP Password Configuration

!
key chain ldp-pwd
key 10
key-string lab1
key 11
key-string lab2
key 12
key-string lab3
!
24
LSR B Incorrect Keychain LDP Password Configuration

key chain ldp-pwd
key 10
key-string lab1
key 11
key-string lab2
key 12
key-string lab3
!
In the example, for both LSR A and LSR B, during the period of the third send-lifetime 10:30:00 Feb
1 2009 10:30:00 Mar 1 2009 command, all three configured keys are valid as receive keys, and only the
last configured key is valid as a transmit key. The keychain resolution rules dictate that keys 10 and 11
are used as receive keys, and only the last key 12 can be used as the transmit key. Because the transmit
and receive keys are mismatched, the LDP session will not stay active.
Note When more than two passwords are configured in a keychain, the configuration needs to have both
accept-lifetime and send-lifetime commands configured correctly for effective rollovers.
The following example shows the correct keychain configuration with multiple passwords in the
keychain:
LSR A Correct Keychain LDP Password Configuration

!
key chain ldp-pwd
key 10
key-string lab1
key 11
key-string lab2
key 12
key-string lab3
!
LSR B Correct Keychain LDP Password Configuration

key chain ldp-pwd
key 10
key-string lab1
key 11
key-string lab2
key 12
25
key-string lab3
!
In the example above, for both LSR A and LSR B, during the period of the third send-lifetime 10:30:00
Feb 1 2009 10:30:00 Mar 1 2009 command, only the last key 12 is valid as transmit and receive keys.
Therefore, the LDP session remains active.
Avoiding Access List Configuration Problems

Use caution when modifying or deleting an access list. Any empty access list implies “permit any” by
default. So when either the mpls ldp password option for key-chain command or the mpls ldp
password option for command is used for MPLS LDP MD5 session authentication, if the access list
specified in the command becomes empty as a result of a modification or deletion, then all LDP sessions
on the router expect a password. This configuration may cause undesired behavior in LDP sessions. To
avoid this scenario, ensure that the proper access list is specified for each LSR.
Changing MPLS LDP—Lossless MD5 Session Authentication Using a Second

Key to Avoid LDP Session Failure: Examples
The Book Title feature works when a specified rollover period is configured. Typically, one rollover
period overlaps the two accept lifetime values that are configured for two consecutive receive keys. The
LDP process requests an update from the keychain manager for the latest valid transmit and receive keys
once every minute. LDP compares the latest key set with the keys from the previous update in its
database to determine if a key was removed, changed, or rolled over. When the rollover occurs, the LDP
process detects the rollover and programs TCP with the next receive key.
The LDP session can fail if LDP is configured to use two keys for the Book Title feature where the first
key uses a send and accept lifetime value and the second key is not configured. The configuration creates
a special case where there are two rollovers but there is only one rollover period.
The following sections provide an example of this problem and a solution:
• TCP Authentication and LDP Sessions Can Fail When a Second Rollover Period Is Missing:
Example, page 26
• Reconfigure a Keychain to Prevent TCP Authentication and LDP Session Failures: Example,
page 27
TCP Authentication and LDP Sessions Can Fail When a Second Rollover Period Is Missing: Example
In the following configuration, the first rollover is from “secondpass” to “firstpass.” The second rollover
is from “firstpass” back to “secondpass.” The only rollover period in this configuration is the overlapping
between the “firstpass” and “secondpass.” Because one rollover period is missing, LDP performs only
the first rollover and not the second rollover, causing TCP authentication to fail and the LDP session to
fail.
key chain ldp-pwd

key 1
key-string firstpass
accept-lifetime 01:03:00 Sep 10 2009 01:10:00 Sep 10 2009
send-lifetime 01:05:00 Sep 10 2009 01:08:00 Sep 10 2009
26
key 2
key-string secondpass
TCP authentication and LDP sessions can also fail if the second key has send and accept lifetime
configured. In this case the accept lifetime of the first key is a subset of the accept lifetime of the second
key. For example:
key chain ldp-pwd

key 1
key 2
Reconfigure a Keychain to Prevent TCP Authentication and LDP Session Failures: Example
If the configuration needs to specify the last key in the keychain to always be valid, then configure the
keychain to have at least two keys. Each key must be configured with both the send and accept lifetime
period. For example:
key chain ldp-pwd

key 1
key 2
key 3
key-string thirdpass
If the configuration needs to specify the first keychain for the time interval, then switch to use the second
key forever after that interval. This is done by configuring the start time for the second key to begin
shortly before the end time of the first key, and by configuring the second key to be valid forever after
that interval. For example:
key chain ldp-pwd

key 1
key 2
accept-lifetime 01:06:00 Sep 10 2008 infinite
send-lifetime 01:08:00 Sep 10 2008 infinite
If the configuration needs to specify the two keys in the order of the second key, first key, and second
key again, then specify three keys in that order with the proper rollover period. For example:
key chain ldp-pwd

key 1
27
key 2
key 3
accept-lifetime 01:13:00 Sep 10 2008 infinite
send-lifetime 01:15:00 Sep 10 2008 infinite
The following sections provide references related to the MPLS LDP—Lossless MD5 Session
Authentication feature.
Related Documents
MPLS Label Distribution Protocol (LDP) MPLS Label Distribution Protocol
LDP implementation enhancements for the MD5 MPLS—LDP MD5 Global Configuration
password
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
release, and support for existing RFCs has not been
28
Description Link
29
Feature Information for MPLS LDP—Lossless MD5 Session Authentication
Feature Information for MPLS LDP—Lossless MD5 Session

Authentication
Table 1 Feature Information for MPLS LDP—Lossless MD5 Session Authentication

MPLS LDP—Lossless MD5 Session Cisco IOS XE This feature allows an LDP session to be password-protected
Authentication Release 2.1 without tearing down and reestablishing the LDP session.
In Cisco IOS XE Release 2.1, this feature was introduced on the
• How MPLS LDP Messages in MPLS LDP—Lossless MD5
Session Authentication are Exchanged, page 3
• The Evolution of MPLS LDP MD5 Password Features,
page 3
• Keychains Use with MPLS LDP—Lossless MD5 Session
Authentication, page 4
• Application of Rules to Overlapping Passwords, page 4
• Password Rollover Period Guidelines, page 5
• Resolving LDP Password Problems, page 5
• Configuring MPLS LDP—Lossless MD5 Session
Authentication Using a Keychain, page 6
• Enabling the Display of MPLS LDP Password Rollover
Changes and Events, page 11Changing MPLS
LDP—Lossless MD5 Session Authentication Passwords,
page 13
• Changing MPLS LDP—Lossless MD5 Session
Authentication Passwords, page 13
30
Table 1 Feature Information for MPLS LDP—Lossless MD5 Session Authentication (continued)

The following commands were introduced or modified: mpls
ldp logging password configuration, mpls ldp logging
password rollover, mpls ldp neighbor password, mpls ldp
password fallback, mpls ldp password option, mpls ldp
password required, mpls ldp password rollover duration,
show mpls ldp discovery, show mpls ldp neighbor, show mpls
ldp neighbor password.
countries.
31
32
MPLS LDP–VRF-Aware Static Labels
First Published: October 28, 2002

This document explains how to configure the MPLS LDP–VRF-Aware Static Labels feature and
Multiprotocol Label Switching (MPLS) static labels. Virtual Private Network routing and forwarding
(VRF)-aware static labels can be used at the edge of an MPLS Virtual Private Network (VPN), whereas
MPLS static labels can be used only in the MPLS VPN provider core.

which each feature is supported, see the “Feature Information for MPLS LDP–VRF-Aware Static Labels”
section on page 9.
Contents
• Information About MPLS LDP–VRF-Aware Static Labels, page 2
• How to Configure MPLS LDP–VRF-Aware Static Labels, page 3
• Configuration Examples for MPLS LDP–VRF-Aware Static Labels, page 6
• Feature Information for MPLS LDP–VRF-Aware Static Labels, page 9
Information About MPLS LDP–VRF-Aware Static Labels
Information About MPLS LDP–VRF-Aware Static Labels

To configure and use VRF-aware static labels, you should understand the following concepts:
• Overview of MPLS Static Labels and MPLS LDP–VRF-Aware Static Labels, page 2
• Labels Reserved for Static Assignment, page 2
Overview of MPLS Static Labels and MPLS LDP–VRF-Aware Static Labels

Label switch routers (LSRs) dynamically learn the labels they should use to label-switch packets by
means of the following label distribution protocols:
• Label Distribution Protocol (LDP), the Internet Engineering Task Force (IETF) standard used to
bind labels to network addresses
• Resource Reservation Protocol (RSVP) used to distribute labels for traffic engineering (TE)
• Border Gateway Protocol (BGP) used to distribute labels for MPLS VPNs
The LSR installs the dynamically learned label into its Label Forwarding Information Base (LFIB).
You can configure static labels for the following purposes:
• To bind labels to IPv4 prefixes to support MPLS hop-by-hop forwarding through neighbor routers
that do not implement LDP label distribution. MPLS static labels allow you to configure entries in
the MPLS forwarding table and assign label values to forwarding equivalence classes (FECs)
learned by LDP. You can manually configure an LSP without running an LDP between the
endpoints.
• To create static cross connects to support MPLS label switched path (LSP) midpoints when neighbor
routers do not implement the LDP or RSVP label distribution, but do implement an MPLS
forwarding path.
• To statically bind a VRF-aware label on a provider edge (PE) router to a customer network prefix
(VPN IPv4 prefix). VRF-aware static labels can be used with nonglobal VRF tables, so the labels
can be used at the VPN edge. For example, with the Carrier Supporting Carrier (CSC) feature, the
backbone carrier can assign specific labels to FECs it advertises to the edge routers of customer
carriers. Then, backbone carrier can monitor backbone traffic coming from particular customer
carriers for billing or other purposes. Depending on how you configure VRF-aware static labels,
they are advertised one of the following ways:
– By LDP between PE and customer edge (CE) routers within a VRF instance
– In VPNv4 BGP in the service provider’s backbone
Labels Reserved for Static Assignment

Before you can manually assign labels, you must reserve a range of labels to be used for the manual
assignment. Reserving the labels ensures that the labels are not dynamically assigned.
2
How to Configure MPLS LDP–VRF-Aware Static Labels

This section contains the following tasks:
• Reserving Labels to Use for MPLS Static Labels and MPLS LDP–VRF-Aware Static Labels, page 3
(required)
• Configuring MPLS Static Labels in the MPLS VPN Provider Core, page 4 (optional)
• Configuring MPLS LDP–VRF-Aware Static Labels at the Edge of the VPN, page 5 (optional)
Reserving Labels to Use for MPLS Static Labels and MPLS LDP–VRF-Aware
Static Labels
To reserve the labels that are to be statically assigned so that the labels are not dynamically assigned,
perform the following task.
SUMMARY STEPS
1. enable
3. mpls label range minimum-value maximum-value [static minimum-static-value
maximum-static-value]
4. exit
5. show mpls label range
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls label range minimum-value maximum-value Reserves a range of labels for static labels assignment. The
[static minimum-static-value default is that no labels are reserved for static assignment.
maximum-static-value]
Note You might need to reload the router for the range of
labels you reserve to take effect.
Example:
Router(config)# mpls label range 200 100000
static 16 199
3

Step 4 exit Exits global configuration mode.
Example:
Step 5 show mpls label range Displays information about the range of values for local
labels, including those available for static assignment.
Example:
Configuring MPLS Static Labels in the MPLS VPN Provider Core

To configure MPLS static labels in the MPLS VPN provider core, perform the following task.
MPLS static labels allow you to configure entries in the MPLS forwarding table and assign label values
to FECs learned by LDP. You can manually configure an LSP without running a label distribution
protocol between the endpoints. In MPLS VPN networks, static labels can be used only in the MPLS
VPN provider core.
Prerequisites
• Globally enable MPLS on each LSR.
• Enable Cisco Express Forwarding on each LSR.
SUMMARY STEPS
1. enable
3. mpls static binding ipv4 prefix mask {label | input label | output nexthop {explicit-null |
implicit-null | label}}
4. exit
5. show mpls static binding ipv4
6. show mpls forwarding-table
DETAILED STEPS
Command Purpose
Example:
Router> enable
Step 2 configure terminal Enters global configuration mode and returns to privileged EXEC
mode.
Example:
4
Command Purpose
Step 3 mpls static binding ipv4 prefix mask Specifies static binding of labels to IPv4 prefixes.
{label | input label | output nexthop
{explicit-null | implicit-null | label}} Specified bindings are installed automatically in the MPLS
Example:
Router(config)# mpls static binding ipv4
10.2.2.0 255.255.255.255 input 17
Step 4 exit Exits global configuration mode and enters privileged EXEC
mode.
Example:
Step 5 show mpls static binding ipv4 Displays the configured static labels.
Example:
Step 6 show mpls forwarding-table Displays the static labels used for MPLS forwarding.
Example:
Configuring MPLS LDP–VRF-Aware Static Labels at the Edge of the VPN

To configure the MPLS LDP—VRF-Aware Static Labels feature at the edge of the VPN, perform the
following task.
You can statically bind a VRF-aware label on a PE router to a customer network prefix (VPN IPv4
prefix). VRF-aware static labels can be used with nonglobal VRF tables, so the labels can be used at the
VPN edge.
Restrictions
• The MPLS LDP–VRF-Aware Static Labels feature is supported only with MPLS VPN Carrier
Supporting Carrier networks that use MPLS LDP.
Prerequisites
• Globally enable MPLS on each LSR.
• Enable Cisco Express Forwarding on each LSR.
• Ensure the MPLS VPN is configured.
• Ensure that the provider network has MPLS LDP installed and running.
SUMMARY STEPS
1. enable
3. mpls static binding ipv4 vrf vpn-name prefix mask {input label | label}
5
Configuration Examples for MPLS LDP–VRF-Aware Static Labels
4. exit
5. show mpls static binding ipv4 vrf vpn-name
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls static binding ipv4 vrf vpn-name prefix Binds a prefix to a local label.
mask {input label | label}
Specified bindings are installed automatically in the MPLS
Example:
Router(config)# mpls static binding ipv4 vrf
Note You must configure the MPLS VPN and VRFs
vpn100 10.2.0.0 255.255.0.0 input 17 before creating VRF-aware static labels.
EXEC mode.
Example:
Step 5 show mpls static binding ipv4 vrf vpn-name Displays the configured MPLS static bindings.
Example:
Router(config)# show mpls static binding ipv4
vrf vpn100
To display information related to static binding events, use the debug mpls static binding vrf command.
Configuration Examples for MPLS LDP–VRF-Aware Static

Labels
• Reserving Labels to Use for MPLS Static Labels and MPLS LDP–VRF-Aware Static Labels:
Example, page 7
• Configuring MPLS Static Labels in the MPLS VPN Provider Core: Example, page 7
• Configuring MPLS LDP–VRF-Aware Static Labels at the VPN Edge: Example, page 7
6
Configuration Examples for MPLS LDP–VRF-Aware Static Labels
Reserving Labels to Use for MPLS Static Labels and MPLS LDP–VRF-Aware
Static Labels: Example
In the following example, the mpls label range command reserves a generic range of labels from 200
to 100000 and configures a static label range of 16 to 199:
Router(config)# mpls label range 200 100000 static 16 199
% Label range changes take effect at the next reload.
In this example, the output from the show mpls label range command indicates that the new label ranges
do not take effect until a reload occurs:

In the following output, the show mpls label range command, executed after a reload, indicates that the
new label ranges are in effect:

Configuring MPLS Static Labels in the MPLS VPN Provider Core: Example
The following example configures input and output labels for several prefixes:
Router(config)# mpls static binding ipv4 10.0.0.0 255.0.0.0 55
Router(config)# mpls static binding ipv4 10.0.0.0 255.0.0.0 output 10.0.0.66 167
Router(config)# mpls static binding ipv4 10.66.0.0 255.255.0.0 input 17
Router(config)# mpls static binding ipv4 10.66.0.0 255.255.0.0 output 10.13.0.8
explicit-null
The show mpls static binding ipv4 command displays the configured static labels:
10.0.0.0/8: Incoming label: 55

Outgoing labels:
10.0.0.66 167
10.66.0.0/24: Incoming label: 17
Outgoing labels:
10.13.0.8 explicit-null
Configuring MPLS LDP–VRF-Aware Static Labels at the VPN Edge: Example

In the following example, the mpls static binding ipv4 vrf commands configure static label bindings.
They also configure input (local) labels for various prefixes.
Router(config)# mpls static binding ipv4 vrf vpn100 10.0.0.0 10.0.0.0 55
Router(config)# mpls static binding ipv4 vrf vpn100 10.66.0.0 255.255.0.0 input 17
7
In the following output, the show mpls static binding ipv4 vrf command displays the configured
VRF-aware static bindings:
Router# show mpls static binding ipv4 vrf vpn100
10.0.0.0/8: (vrf: vpn100) Incoming label: 55

10.66.0.0/16: (vrf: vpn100) Incoming label: 17
The following sections provide references related to the MPLS LDP–VRF-Aware Static Labels feature.
Related Documents
MPLS commands Cisco IOS Multiprotocol Label Switching Command Reference
MPLS VPN configuration information Configuring MPLS Layer 3 VPNs
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
8
Feature Information for MPLS LDP–VRF-Aware Static Labels
Description Link

9
Table 1 Feature Information for MPLS LDP–VRF-Aware Static Labels

MPLS LDP–VRF-Aware Static Labels Cisco IOS XE The MPLS LDP-VRF-Aware Static Labels feature explains
Release 2.1 how to configure the MPLS LDP–VRF-Aware Static Labels
feature and MPLS static labels. VRF-aware static labels can
be used at the edge of an MPLS VPN, whereas MPLS static
labels can be used only in the MPLS VPN provider core.
on the Cisco ASR 1000 Series Aggregation Services Routers.
• Overview of MPLS Static Labels and MPLS
LDP–VRF-Aware Static Labels, page 2
• Labels Reserved for Static Assignment, page 2
• Reserving Labels to Use for MPLS Static Labels and
MPLS LDP–VRF-Aware Static Labels, page 3
• Configuring MPLS Static Labels in the MPLS VPN
Provider Core, page 4
• Configuring MPLS LDP–VRF-Aware Static Labels at the
Edge of the VPN, page 5
The following commands were introduced or modified: debug
mpls static binding, mpls label range, mpls static binding
ipv4, mpls static binding ipv4 vrf, show mpls label range,
show mpls static binding ipv4, and show mpls static
binding ipv4 vrf.
countries.
coincidental.
10
MPLS Traffic Engineering: Path
Calculation and Setup
MPLS Traffic Engineering and Enhancements
First Published: March 7, 2002

Multiprotocol Label Switching (MPLS) traffic engineering software enables an MPLS backbone to
replicate and expand upon the traffic engineering capabilities of Layer 2 ATM and Frame Relay
networks. MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2
features available to Layer 3, MPLS enables traffic engineering. Thus, you can offer in a one-tier
network what previously could be achieved only by overlaying a Layer 3 network on a Layer 2 network.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering and
Enhancements” section on page 24.
Contents
• Prerequisites for MPLS Traffic Engineering and Enhancements, page 2
• Restrictions for MPLS Traffic Engineering and Enhancements, page 2
• Information About MPLS Traffic Engineering and Enhancements, page 2
• How to Configure MPLS Traffic Engineering and Enhancements, page 11
• Configuration Examples for MPLS Traffic Engineering and Enhancements, page 19
• Feature Information for MPLS Traffic Engineering and Enhancements, page 24
Prerequisites for MPLS Traffic Engineering and Enhancements
Prerequisites for MPLS Traffic Engineering and Enhancements

Your network must support the following Cisco IOS XE features before you enable MPLS traffic
engineering:
• Multiprotocol Label Switching
• IP Cisco Express Forwarding
• Intermediate System-to-Intermediate System (IS-IS) or Open Shortest Path First (OSPF)
Restrictions for MPLS Traffic Engineering and Enhancements

• MPLS traffic engineering supports only a single IS-IS level or OSPF area.
• MPLS traffic engineering does not support ATM MPLS-controlled subinterfaces.
• The MPLS traffic engineering feature does not support routing and signaling of LSPs over
unnumbered IP links. Therefore, do not configure the feature over those links.
Information About MPLS Traffic Engineering and Enhancements

Before configuring the MPLS Traffic Engineering and Enhancements feature, you should understand the
following concepts:
• Introduction to MPLS Traffic Engineering and Enhancements, page 2
• Benefits of MPLS Traffic Engineering, page 3
• How MPLS Traffic Engineering Works, page 3
• Mapping Traffic into Tunnels, page 4
• Transition of an IS-IS Network to a New Technology, page 8
Introduction to MPLS Traffic Engineering and Enhancements

Multiprotocol Label Switching (MPLS) traffic engineering software enables an MPLS backbone to
replicate and expand upon the traffic engineering capabilities of Layer 2 ATM and Frame Relay
networks. MPLS is an integration of Layer 2 and Layer 3 technologies. By making traditional Layer 2
features available to Layer 3, MPLS enables traffic engineering. Thus, you can offer in a one-tier
network what now can be achieved only by overlaying a Layer 3 network on a Layer 2 network.
Traffic engineering is essential for service provider and Internet service provider (ISP) backbones. Such
backbones must support a high use of transmission capacity, and the networks must be very resilient so
that they can withstand link or node failures.
MPLS traffic engineering provides an integrated approach to traffic engineering. With MPLS, traffic
engineering capabilities are integrated into Layer 3, which optimizes the routing of IP traffic, given the
constraints imposed by backbone capacity and topology.
2
MPLS traffic engineering supports the following functionality:

• Enhances standard Interior Gateway Protocols (IGPs), such as IS-IS or OSPF, to automatically map
packets onto the appropriate traffic flows.
• Transports traffic flows across a network using MPLS forwarding.
• Determines the routes for traffic flows across a network based on the resources the traffic flow
requires and the resources available in the network.
• Employs “constraint-based routing,” in which the path for a traffic flow is the shortest path that
meets the resource requirements (constraints) of the traffic flow. In MPLS traffic engineering, the
traffic flow has bandwidth requirements, media requirements, a priority that is compared to the
priority of other flows, and so forth.
• Recovers from link or node failures by adapting to the new constraints presented by the changed
topology.
• Transports packets using MPLS forwarding crossing a multihop label switched path (LSP).
• Uses the routing and signaling capability of LSPs across a backbone topology that
– Understands the backbone topology and available resources
– Accounts for link bandwidth and for the size of the traffic flow when determining routes for
LSPs across the backbone
– Has a dynamic adaptation mechanism that enables the backbone to be resilient to failures, even
if several primary paths are precalculated off-line
– Includes enhancements to the IGP (IS-IS or OSPF) shortest path first (SPF) calculations to
automatically calculate what traffic should be sent over what LSPs.
Benefits of MPLS Traffic Engineering

WAN connections are an expensive item in an ISP budget. Traffic engineering enables ISPs to route
network traffic to offer the best service to their users in terms of throughput and delay. By making the
service provider more efficient, traffic engineering reduces the cost of the network.
Currently, some ISPs base their services on an overlay model. In the overlay model, transmission
facilities are managed by Layer 2 switching. The routers see only a fully meshed virtual topology,
making most destinations appear one hop away. If you use the explicit Layer 2 transit layer, you can
precisely control how traffic uses available bandwidth. However, the overlay model has numerous
disadvantages. MPLS traffic engineering achieves the traffic engineering benefits of the overlay model
without running a separate network, and without needing a nonscalable, full mesh of router
interconnects.
How MPLS Traffic Engineering Works

MPLS traffic engineering automatically establishes and maintains LSPs across the backbone by using
RSVP. The path that an LSP uses is determined by the LSP resource requirements and network resources,
such as bandwidth.
Available resources are flooded by means of extensions to a link-state based IGP.
Traffic engineering tunnels are calculated at the LSP head based on a fit between required and available
resources (constraint-based routing). The IGP automatically routes the traffic onto these LSPs.
Typically, a packet crossing the MPLS traffic engineering backbone travels on a single LSP that connects
the ingress point to the egress point.
3
MPLS traffic engineering is built on the following Cisco IOS XE mechanisms:

• IP tunnel interfaces
From a Layer 2 standpoint, an MPLS tunnel interface represents the head of an LSP. It is configured
with a set of resource requirements, such as bandwidth and media requirements, and priority.
From a Layer 3 standpoint, an LSP tunnel interface is the headend of a unidirectional virtual link to
the tunnel destination.
• MPLS traffic engineering path calculation module
This calculation module operates at the LSP head. The module determines a path to use for an LSP.
The path calculation uses a link-state database containing flooded topology and resource
information.
• RSVP with traffic engineering extensions
RSVP operates at each LSP hop and is used to signal and maintain LSPs based on the calculated
path.
• MPLS traffic engineering link management module
This module operates at each LSP hop, does link call admission on the RSVP signaling messages,
and bookkeeping of topology and resource information to be flooded.
• Link-state IGP (IS-IS or OSPF—each with traffic engineering extensions)
These IGPs are used to globally flood topology and resource information from the link management
module.
• Enhancements to the SPF calculation used by the link-state IGP (IS-IS or OSPF)
The IGP automatically routes traffic onto the appropriate LSP tunnel based on tunnel destination.
Static routes can also be used to direct traffic onto LSP tunnels.
• Label switching forwarding
This forwarding mechanism provides routers with a Layer 2-like ability to direct traffic across
multiple hops of the LSP established by RSVP signaling.
One approach to engineering a backbone is to define a mesh of tunnels from every ingress device to every
egress device. The MPLS traffic engineering path calculation and signaling modules determine the path
taken by the LSPs for these tunnels, subject to resource availability and the dynamic state of the network.
The IGP, operating at an ingress device, determines which traffic should go to which egress device, and
steers that traffic into the tunnel from ingress to egress.
A flow from an ingress device to an egress device might be so large that it cannot fit over a single link,
so it cannot be carried by a single tunnel. In this case, multiple tunnels between a given ingress and
egress can be configured, and the flow is load-shared among them.
Mapping Traffic into Tunnels

This section describes how traffic is mapped into tunnels; that is, how conventional hop-by-hop
link-state routing protocols interact with MPLS traffic engineering capabilities. In particular, this section
describes how the shortest path first (SPF) algorithm, sometimes called a Dijkstra algorithm, has been
enhanced so that a link-state IGP can automatically forward traffic over tunnels that MPLS traffic
engineering establishes.
4
Link-state protocols, like integrated IS-IS or OSPF, use an SPF algorithm to compute a shortest path tree
from the headend node to all nodes in the network. Routing tables are derived from this shortest path
tree. The routing tables contain ordered sets of destination and first-hop information. If a router does
normal hop-by-hop routing, the first hop is over a physical interface attached to the router.
New traffic engineering algorithms calculate explicit routes to one or more nodes in the network. The
originating router views these explicit routes as logical interfaces. In the context of this document, these
explicit routes are represented by LSPs and referred to as traffic engineering tunnels (TE tunnels).
The following sections describe how link-state IGPs can use these shortcuts, and how they can install
routes in the routing table that point to these TE tunnels. These tunnels use explicit routes, and the path
taken by a TE tunnel is controlled by the router that is the headend of the tunnel. In the absence of errors,
TE tunnels are guaranteed not to loop, but routers must agree on how to use the TE tunnels. Otherwise,
traffic might loop through two or more tunnels. See the following sections:
• Enhancement to the SPF Computation, page 5
• Special Cases and Exceptions for SPF Calculations, page 6
• Additional Enhancements to SPF Computation Using Configured Tunnel Metrics, page 6
Enhancement to the SPF Computation

During each step of the SPF computation, a router discovers the path to one node in the network.
• If that node is directly connected to the calculating router, the first-hop information is derived from
the adjacency database.
• If the node is not directly connected to the calculating router, the node inherits the first-hop
information from the parent(s) of that node. Each node has one or more parents, and each node is
the parent of zero or more downstream nodes.
For traffic engineering purposes, each router maintains a list of all TE tunnels that originate at this
headend router. For each of those TE tunnels, the router at the tailend is known to the head-end router.
During the SPF computation, the TENT (tentative) list stores paths that are possibly the best paths and
the PATH list stores paths that are definitely the best paths. When it is determined that a path is the best
possible path, the node is moved from TENT to PATH. PATH is thus the set of nodes for which the best
path from the computing router has been found. Each PATH entry consists of ID, path cost, and
forwarding direction.
The router must determine the first-hop information. There are several ways to do this:
• Examine the list of tailend routers directly reachable by a TE tunnel. If there is a TE tunnel to this
node, use the TE tunnel as the first hop.
• If there is no TE tunnel and the node is directly connected, use the first-hop information from the
adjacency database.
• If the node is not directly connected and is not directly reachable by a TE tunnel, copy the first-hop
information from the parent node(s) to the new node.
As a result of this computation, traffic to nodes that are the tail end of TE tunnels flows over the
TE tunnels. Traffic to nodes that are downstream of the tail-end nodes also flows over the TE tunnels. If
there is more than one TE tunnel to different intermediate nodes on the path to destination node X, traffic
flows over the TE tunnel whose tail-end node is closest to node X.
5
Special Cases and Exceptions for SPF Calculations

The SPF algorithm finds equal-cost parallel paths to destinations. The enhancement previously
described does not change this. Traffic can be forwarded over any of the following:
• One or more native IP paths
• One or more traffic engineering tunnels
• A combination of native IP paths and traffic engineering tunnels
A special situation occurs in the topology shown in Figure 1.
Figure 1 Sample Topology of Parallel Native Paths and Paths Over TE Tunnels
Router A Router B Router C
26682
Router D Router E
If parallel native IP paths and paths over TE tunnels are available, the following implementations allow
you to force traffic to flow over TE tunnels only or only over native IP paths. Assume that all links have
the same cost and that a TE tunnel is set up from Router A to Router D.
• When the SPF calculation puts Router C on the TENT list, it realizes that Router C is not directly
connected. It uses the first-hop information from the parent, which is Router B.
• When the SPF calculation on Router A puts Router D on the TENT list, it realizes that Router D is
the tail end of a TE tunnel. Thus Router A installs a route to Router D by the TE tunnel, and not by
Router B.
• When Router A puts Router E on the TENT list, it realizes that Router E is not directly connected,
and that Router E is not the tail end of a TE tunnel. Therefore Router A copies the first-hop
information from the parents (Router C and Router D) to the first-hop information of Router E.
Traffic to Router E now load balances over
• The native IP path by Router A to Router B to Router C
• The TE tunnel Router A to Router D
Additional Enhancements to SPF Computation Using Configured Tunnel Metrics

When traffic engineering tunnels install an IGP route in a Router Information Base (RIB) as next hops,
the distance or metric of the route must be calculated. Normally, you could make the metric the same as
the IGP metric over native IP paths as if the TE tunnels did not exist. For example, Router A can reach
Router C with the shortest distance of 20. X is a route advertised in IGP by Router C. Route X is installed
in Router A's RIB with the metric of 20. When a TE tunnel from Router A to Router C comes up, by
default the route is installed with a metric of 20, but the next-hop information for X is changed.
6
Although the same metric scheme can work well in other situations, for some applications it is useful to
change the TE tunnel metric (for instance, when there are equal cost paths through TE tunnel and native
IP links). You can adjust TE tunnel metrics to force the traffic to prefer the TE tunnel, to prefer the native
IP paths, or to load share among them.
Suppose that multiple TE tunnels go to the same destination or different destinations. TE tunnel metrics
can force the traffic to prefer some TE tunnels over others, regardless of IGP distances to those
destinations.
Setting metrics on TE tunnels does not affect the basic SPF algorithm. It affects only two questions:
1. Is the TE tunnel installed as one of the next hops to the destination routers?
2. What is the metric value of the routes being installed into the RIB?
You can modify the metrics for determining the first-hop information in one of the following ways:
• If the metric of the TE tunnel to the tailend routers is higher than the metric for the other TE tunnels
or native hop-by-hop IGP paths, this tunnel is not installed as the next hop.
• If the metric of the TE tunnel is equal to the metric of either other TE tunnels or native hop-by-hop
IGP paths, this tunnel is added to the existing next hops.
• If the metric of the TE tunnel is lower than the metric of other TE tunnels or native hop-by-hop IGP
paths, this tunnel replaces them as the only next hop.
In each of the above cases, the IGP assigns metrics to routes associated with those tailend routers and
their downstream routers.
The SPF computation is loop free because the traffic through the TE tunnels is basically source routed.
The end result of TE tunnel metric adjustment is the control of traffic loadsharing. If there is only one
way to reach the destination through a single TE tunnel, then no matter what metric is assigned, the
traffic has only one way to go.
You can represent the TE tunnel metric in two different ways: (1) as an absolute (or fixed) metric or (2)
as a relative (or floating) metric.
If you use an absolute metric, the routes assigned with the metric are fixed. This metric is used not only
for the routes sourced on the TE tunnel tailend router, but also for each route downstream of this tailend
router that uses this TE tunnel as one of its next hops.
For example, if you have TE tunnels to two core routers in a remote point of presence (POP), and one of
them has an absolute metric of 1, all traffic going to that POP traverses this low-metric TE tunnel.
If you use a relative metric, the actual assigned metric value of routes is based on the IGP metric. This
relative metric can be positive or negative, and is bounded by minimum and maximum allowed metric
values. For example, assume the topology shown in Figure 2.
Figure 2 Topology That Has No Traffic Engineering Tunnel
Router A Router B Router C Router D Router E

Metric = 10 Metric = 10 Metric = 10 Metric = 10
MPLS TE-tunnel T1 Subnet x Subnet y Subnet z

26511
7
If there is no TE tunnel, Router A installs routes x, y, and z and assigns metrics 20, 30, and 40
respectively. Suppose that Router A has a TE tunnel T1 to Router C. If the relative metric –5 is used on
tunnel T1, the routers x, y, and z have the installed metrics of 15, 25, and 35. If an absolute metric of 5
is used on tunnel T1, routes x, y and z have the same metric 5 installed in the RIB for Router A. The
assigning of no metric on the TE tunnel is a special case, a relative metric scheme where the metric is 0.
Transition of an IS-IS Network to a New Technology

IS-IS, as specified in RFC 1142, includes extensions for MPLS traffic engineering and for other
purposes. Running MPLS traffic engineering over IS-IS or taking advantage of these other extensions
requires transitioning an IS-IS network to this new technology. This section describes these extensions
and discusses two ways to migrate an existing IS-IS network from the standard ISO 10589 protocol
towards the version of IS-IS specified in RFC 1142.Running MPLS traffic engineering over an existing
IS-IS network requires a transition to the version of IS-IS specified in RFC 1142. However, running
MPLS traffic engineering over OSPF does not require any similar network transition.
This section contains information about the following topics:
• Extensions for the IS-IS Routing Protocol, page 8
• Problems with Old and New TLVs in Theory and in Practice, page 9
• First Solution for Transitioning an IS-IS Network to a New Technology, page 9
• Transition Actions During the First Solution, page 10
• Second Solution for Transitioning an IS-IS Network to a New Technology, page 10
• Transition Actions During the Second Solution, page 10
• TLV Configuration Commands, page 11
• Implementation in Cisco IOS XE Software, page 11
Extensions for the IS-IS Routing Protocol

Extensions for the IS-IS routing protocol serve the following purposes:
• Remove the 6-bit limit on link metrics.
• Allow interarea IP routes.
• Enable IS-IS to carry different kinds of information for traffic engineering. In the future, more
extensions might be needed.
To serve these purposes, two new TLVs (type, length, and value objects) have been defined:
• TLV 22 describes links (or rather adjacencies). It serves the same purpose as the “IS neighbor
option” in ISO 10589 (TLV 2).
• TLV 135 describes reachable IP prefixes. It is similar to the IP Neighbor options from RFC 1195
(TLVs 128 and 130).
Note For the purpose of briefness, these two new TLVs, 22 and 135, are referred to as “new-style TLVs.” TLVs
2, 128, and 130 are referred to as “old-style TLVs.”
8
Both new TLVs have a fixed length part, followed by optional sub-TLVs. The metric space in these new
TLVs has been enhanced from 6 bits to 24 or 32 bits. The sub-TLVs allow you to add new properties to
links and prefixes. Traffic engineering is the first technology to use this ability to add new properties to
a link.
Problems with Old and New TLVs in Theory and in Practice

Link-state routing protocols compute loop-free routes. This is guaranteed because all routers calculate
their routing tables based on the same information from the link-state database (LSPDB).
There is a problem when some routers look at old-style TLVs and some routers look at new-style TLVs
because the routers can base their SPF calculations on different information. This can cause routing
loops.
The easiest way to migrate from old-style TLVs towards new-style TLVs would be to introduce a “flag
day.” A flag day means that you reconfigure all routers during a short period of time, during which
service is interrupted. If the implementation of a flag day is not acceptable, a network administrator
needs to find a viable solution for modern existing networks.
Network administrators have the following problems related to TLVs:
• They need to run an IS-IS network where some routers are advertising and using the new-style TLVs
and, at the same time, other routers are capable only of advertising and using old-style TLVs.
• They need to test new traffic engineering software in existing networks on a limited number of
routers. They cannot upgrade all their routers in their production networks or in their test networks
before they start testing.
The new extensions allow a network administrator to use old-style TLVs in one area, and new-style TLVs
in another area. However, this is not a solution for administrators who need or want to run their network
in one single area.
The following sections describe two solutions to the network administrator’s problems.
First Solution for Transitioning an IS-IS Network to a New Technology

When you migrate from old-style TLVs towards new-style TLVs, you can advertise the same information
twice—once in old-style TLVs and once in new-style TLVs. This ensures that all routers can understand
what is advertised.
There are three disadvantages to using that approach:
• Size of the LSPs—During the transition, the LSPs grow to about twice their original size. This might
be a problem in networks where the LSPDB is large. An LSPDB might be large because
– There are many routers, and thus LSPs.
– There are many neighbors or IP prefixes per router. A router that advertises lots of information
causes the LSPs to be fragmented.
• Unpredictable results—In a large network, this solution can produce unpredictable results. A large
network in transition pushes the limits regarding LSP flooding and SPF scaling. During the
transition
– You can expect some extra network instability. At this time, you especially do not want to test
how far you can push an implementation.
– Traffic engineering extensions might cause LSPs to be reflooded frequently.
• Ambiguity—If a router encounters different information in the old-style TLVs and the new-style
TLVs, it may not be clear what the router should do.
9
These problems can be largely solved easily by using

• All information in old-style and new-style TLVs in an LSP
• The adjacency with the lowest link metric if an adjacency is advertised more than once
The main benefit to advertising the same information twice is that network administrators can use
new-style TLVs before all routers in the network can understand them.
Transition Actions During the First Solution

When transitioning from using IS-IS with old-style TLVs to new-style TLVs, you can perform the
following actions:
• If all routers run old software, advertise and use only old-style TLVs.
• Upgrade some routers to newer software.
• Configure some routers with new software to advertise both old-style and new-style TLVs. They
accept both styles of TLVs. Configure other routers (with old software) to continue advertising and
using only old-style TLVs.
• Test traffic engineering in parts of your network; however, new-style TLVs cannot be used yet.
• If the whole network needs to migrate, upgrade and configure all remaining routers to advertise and
accept both styles of TLVs.
• Configure all routers to advertise and accept only new-style TLVs.
• Configure metrics larger than 63.
For more information about how to perform these actions, see the “TLV Configuration Commands”
section on page 11.
Second Solution for Transitioning an IS-IS Network to a New Technology

Routers advertise only one style of TLVs at the same time, but can understand both types of TLVs during
migration. There are two main benefits to this approach:
• LSPs stay approximately the same size during migration.
• There is no ambiguity when the same information is advertised twice inside one LSP.
This method is useful when you are transitioning the whole network (or a whole area) to use wider
metrics (that is, you want a router running IS-IS to generate and accept only new-style TLVs). For more
information, see the metric-style wide command.
The disadvantage is that all routers must understand the new-style TLVs before any router can start
advertising new-style TLVs. It does not help the second problem, where network administrators want to
use the new-style TLVs for traffic engineering, while some routers are capable of understanding only
old-style TLVs.
Transition Actions During the Second Solution

If you use the second solution, you can perform the following actions:
• If all routers run old software, advertise and use only old-style TLVs.
• Upgrade all routers to newer software.
• Configure all routers one-by-one to advertise old-style TLVs, but to accept both styles of TLVs.
10
How to Configure MPLS Traffic Engineering and Enhancements
• Configure all routers one-by-one to advertise new-style TLVs, but to accept both styles of TLVs.
• Configure all routers one-by-one to advertise and to accept only new-style TLVs.
• Configure metrics larger than 63.
TLV Configuration Commands

Cisco IOS XE has a router isis command-line interface (CLI) command called metric-style. Once the
router is in IS-IS configuration mode, you have the option to choose the following:
• metric-style narrow—Enables the router to generate and accept only old-style TLVs
• metric-style transition—Enables the router to generate and accept both old-style and new-style
TLVs
• metric-style wide—Enables the router to generate and accept only new-style TLVs
You can use either of the following two transition schemes when you use the metric-style command to
configure:
• Narrow to transition to wide
• Narrow to narrow transition to wide transition to wide
Implementation in Cisco IOS XE Software

Cisco IOS XE implements both transitions solution. Network administrators can choose the solution that
suits them best. For test networks, the first solution is best (go to the “First Solution for Transitioning an
IS-IS Network to a New Technology” section on page 9). For a full transition, both solutions can be used.
The first solution requires fewer steps and less configuration. You would use the second solution for the
largest networks where a risk of doubling the LSPDB during transition exists, (go to the “Second
Solution for Transitioning an IS-IS Network to a New Technology” section on page 10).

To configure the MPLS Traffic Engineering and Enhancements feature, perform the following
configuration tasks:
• Configuring a Device to Support Tunnels, page 12 (required)
• Configuring an Interface to Support RSVP-Based Tunnel Signaling and IGP Flooding, page 12
(required)
• Configuring IS-IS for MPLS Traffic Engineering, page 14 (IS-IS or OSPF is required)
• Configuring OSPF for MPLS Traffic Engineering, page 15 (OSPF or IS-IS is required)
• Configuring an MPLS Traffic Engineering Tunnel, page 16 (required)
• Configuring an MPLS Traffic Engineering Tunnel that an IGP Can Use, page 18 (required)
11
Configuring a Device to Support Tunnels

To configure a device to support tunnels, perform the following task.
SUMMARY STEPS
1. enable
3. ip cef
4. mpls traffic-eng tunnels
5. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 ip cef Enables standard Cisco Express Forwarding
operation.
Example:
Step 4 mpls traffic-eng tunnels Enables the MPLS traffic engineering tunnel feature
on a device.
Example:
Router(config)# mpls traffic-eng tunnels
Example:
Configuring an Interface to Support RSVP-Based Tunnel Signaling and IGP

Flooding
To configure an interface to support RSVP-based tunnel signaling and IGP flooding, perform the
following task.
Note You must enable the tunnel feature on interfaces that you want to support MPLS traffic engineering.
12
SUMMARY STEPS
1. enable
5. ip rsvp bandwidth bandwidth
6. exit
7. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface type Configures an interface type and enters interface
Example:
Router(config)# interface serial 1/0/0
Step 4 mpls traffic-eng tunnels Enables MPLS traffic engineering tunnels on an
interface.
Example:
Router(config-if)# mpls traffic-eng tunnels
Step 5 ip rsvp bandwidth bandwidth Enables RSVP for IP on an interface and specifies
the amount of bandwidth that will be reserved.
Example:
Router(config-if)# ip rsvp bandwidth 1000
Step 6 exit Exits interface configuration mode and returns to
Example:
Step 7 exit Exits global configuration mode and returns to
privileged EXEC mode.
Example:
13
Configuring IS-IS for MPLS Traffic Engineering

To configure IS-IS for MPLS traffic engineering, perform the following task.
SUMMARY STEPS
1. enable
3. router isis
4. mpls traffic-eng level-1
5. mpls traffic-eng router-id loopback0
6. metric-style wide
7. exit
8. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router isis Enables IS-IS routing, specifies an IS-IS process for IP, and
enters router configuration mode.
Example:
Step 4 mpls traffic-eng level-1 Turns on MPLS traffic engineering for IS-IS level 1.
Example:
Router(config-router)# mpls traffic-eng level-1
Step 5 mpls traffic-eng router-id loopback0 Specifies that the traffic engineering router identifier for the
node is the IP address associated with interface loopback0.
Example:
Router(config-router)# mpls traffic-eng
router-id loopback0
Step 6 metric-style wide Configures a router to generate and accept only new-style
TLVs.
Example:
Router(config-router)# metric-style wide
14

TLVs.
Example:
configuration mode.
Example:
EXEC mode.
Example:
Configuring OSPF for MPLS Traffic Engineering

To configure OSPF for MPLS traffic engineering, perform the following task.
SUMMARY STEPS
1. enable
4. mpls traffic-eng area number
5. mpls traffic-eng router-id interface-name
6. exit
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
15

Step 3 Router(config)# router ospf process-id Configures an OSPF routing process for IP and enters router
configuration mode.
Example: • The process-id is an internally used identification
Router(config)# router ospf 3 parameter for an OSPF routing process. It is locally
assigned and can be any positive integer. Assign a
unique value for each OSPF routing process.
Step 4 mpls traffic-eng area number Configures a router running OSPF MPLS so that it floods
traffic engineering for the indicated OSPF area.
Example:
area 0
Step 5 mpls traffic-eng router-id interface-name Specifies that the traffic engineering router identifier
for the node is the IP address associated with
interface loopback0.
Example:
router-id loopback0
configuration mode.
Example:
EXEC mode.
Example:
Configuring an MPLS Traffic Engineering Tunnel

To configure an MPLS traffic engineering tunnel, perform the following task.
This tunnel has two path setup options: a preferred explicit path and a backup dynamic path.
SUMMARY STEPS
1. enable
4. ip unnumbered type number
6. tunnel mode mpls traffic-eng
7. tunnel mpls traffic-eng bandwidth bandwidth
8. tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name} | identifier
path-number} [lockdown]
9. exit
10. exit
16
DEFAULT STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface tunnel number Configures an interface type and enters interface configuration
mode.
Example:
Step 4 ip unnumbered type number Gives the tunnel interface an IP address.
• An MPLS traffic engineering tunnel interface should be
Example: unnumbered because it represents a unidirectional link.
Router(config-if)# ip unnumbered
loopback 0
Step 5 tunnel destination ip-address Specifies the destination for a tunnel.
• The ip-address keyword is the IP address of the host
Example: destination expressed in dotted decimal notation.
10.20.1.1
Step 6 tunnel mode mpls traffic-eng Sets the tunnel encapsulation mode to MPLS traffic engineering.
Example:
Router(config-if)# tunnel mode mpls
traffic-eng
Step 7 tunnel mpls traffic-eng bandwidth Configures the bandwidth for the MPLS traffic engineering tunnel.
bandwidth
Example:
Router(config-if)# tunnel mpls
traffic-eng bandwidth 1000
Step 8 tunnel mpls traffic-eng path-option Configures the tunnel to use a named IP explicit path or a path
number {dynamic | explicit {name dynamically calculated from the traffic engineering topology
path-name} | identifier path-number}
[lockdown]
database.
• A dynamic path is used if an explicit path is currently
unavailable.
Example:
traffic-eng path-option 1 explicit
identifier 1
17
Command Purpose
configuration mode.
Example:
Step 10 exit Exits global configuration mode and returns to privileged EXEC
mode.
Example:
Configuring an MPLS Traffic Engineering Tunnel that an IGP Can Use

To configure an MPLS traffic engineering tunnel that an IGP can use, perform the following task.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng autoroute announce
5. exit
6. exit
DEFAULT STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface tunnel number Configures an interface type and enters interface
configuration mode.
Example:
Step 4 tunnel mpls traffic-eng autoroute announce Causes the IGP to use the tunnel in its enhanced SPF
calculation.
Example:
Router(config-if)# tunnel mpls traffic-eng autoroute
announce
18
Configuration Examples for MPLS Traffic Engineering and Enhancements
Command Purpose
Example:
Example:
Configuration Examples for MPLS Traffic Engineering and

Enhancements
• Configuring MPLS Traffic Engineering Using IS-IS: Example, page 19
• Configuring MPLS Traffic Engineering Using OSPF: Example, page 20
• Configuring an MPLS Traffic Engineering Tunnel: Example, page 21
• Configuring Enhanced SPF Routing over a Tunnel: Example, page 22
Figure 3 illustrates a sample MPLS topology. This example specifies point-to-point outgoing interfaces.
The next sections contain sample configuration commands you enter to implement MPLS traffic
engineering and the basic tunnel configuration shown in Figure 3.
Figure 3 Sample MPLS Traffic Engineering Tunnel Configuration
Router 3
209.165.200.229
S0/1/1 S0/1/0
.2 .1
Tu .168
2.1 2
19
6.0
nn
17 nel
2
el 0
n
Tu
2
.
S0/1/3 S0/1/1 Tunnel 2

Tunnel 2 .1 .2
S0/1/2 .1 10.0.0.0 .2
192733
S0/1/0
S0/1/0 S0/1/0 S0/1/3 S0/1/0
.1 209.165.200.0 .2 Tunnel 1 Tunnel 1

Router 1 Tunnel 1 Router 2 Router 4 Router 5
209.165.200.225 209.165.200.226 209.165.200.227 209.165.200.228
Configuring MPLS Traffic Engineering Using IS-IS: Example

This example lists the commands you enter to configure MPLS traffic engineering with IS-IS routing
enabled (see Figure 3).
19
Note You must enter the following commands on every router in the traffic-engineered portion of your
network.
Router 1—MPLS Traffic Engineering Configuration

To configure MPLS traffic engineering, enter the following commands:
ip cef
mpls traffic-eng tunnels
interface loopback 0
ip address 10.0.0.0 255.255.255.254
ip router isis
interface s1/0/0
ip address 209.165.200.1 255.255.0.0
ip router isis
ip rsvp bandwidth 1000
Router 1—IS-IS Configuration

To enable IS-IS routing, enter the following commands:
router isis
network 47.0000.0011.0011.00
is-type level-1
metric-style wide
mpls traffic-eng router-id loopback0
mpls traffic-eng level-1
Configuring MPLS Traffic Engineering Using OSPF: Example

This example lists the commands you enter to configure MPLS traffic engineering with OSPF routing
enabled (see Figure 3).
Note You must enter the following commands on every router in the traffic-engineered portion of your
network.
Router 1—MPLS Traffic Engineering Configuration

To configure MPLS traffic engineering, enter the following commands:
ip cef
ip address 209.165.200.225 255.255.255.255
interface s1/0/0
ip address 209.165.200.1 255.255.0.0
20
Router 1—OSPF Configuration

To enable OSPF, enter the following commands:
router ospf 0
network 209.165.200.0.0.0.255.255 area 0
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 0
Configuring an MPLS Traffic Engineering Tunnel: Example

This example shows you how to configure a dynamic path tunnel and an explicit path in the tunnel.
Before you configure MPLS traffic engineering tunnels, you must enter the appropriate global and
interface commands on the specified router (in this case, Router 1).
Router 1—Dynamic Path Tunnel Configuration

In this section, a tunnel is configured to use a dynamic path.
interface tunnel1
ip unnumbered loopback 0
tunnel destination 209.165.200.228
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng bandwidth 100
tunnel mpls traffic-eng priority 1 1
tunnel mpls traffic-eng path-option 1 dynamic
Router 1—Dynamic Path Tunnel Verification

This section includes the commands you use to verify that the tunnel is up.
show mpls traffic-eng tunnels
show ip interface tunnel1
Router 1—Explicit Path Configuration

In this section, an explicit path is configured.
ip explicit-path identifier 1
next-address 209.165.200.1
Router 1—Explicit Path Tunnel Configuration

In this section, a tunnel is configured to use an explicit path.
interface tunnel2
tunnel mpls traffic-eng path-option 1 explicit identifier 1
21
Router 1—Explicit Path Tunnel Verification

This section includes the commands you use to verify that the tunnel is up.
show mpls traffic-eng tunnels
show ip interface tunnel2
Configuring Enhanced SPF Routing over a Tunnel: Example

This section includes the commands that cause the tunnel to be considered by the IGP’s enhanced SPF
calculation, which installs routes over the tunnel for appropriate network prefixes.
Router 1—IGP Enhanced SPF Consideration Configuration

In this section, you specify that the IGP should use the tunnel (if the tunnel is up) in its enhanced shortest
path first (SPF) calculation.
interface tunnel1
tunnel mpls traffic-eng autoroute announce
Router 1—Route and Traffic Verification

This section includes the commands you use to verify that the tunnel is up and that the traffic is routed
through the tunnel.
show traffic-eng tunnels tunnel1 brief
show ip route 209.165.200.228
show mpls traffic-eng autoroute
ping 209.165.200.228
show interface tunnel1 accounting
show interface s1/0/0 accounting
The following sections provide references related to the MPLS Traffic Engineering and Enhancements
feature.
Related Documents
Configuring Integrated IS-IS Cisco IOS XE IP Routing Protocols Configuration Guide
IS-IS commands Cisco IOS IP Routing Protocols Command Reference
Configuring OSPF Cisco IOS XE IP Routing Protocols Configuration Guide
OSPF command Cisco IOS IP Routing Protocols Command Reference
Configuring Multiprotocol Label Switching Cisco IOS XE Multiprotocol Label Switching Configuration Guide
MPLS TE commands Cisco IOS Multiprotocol Label Switching Command Reference
RSVP commands Cisco IOS Quality of Service Solutions Command Reference
22
Standards
Standard Title
None —
MIBs
MIB MIBs Link
None To locate and download MIBs for selected platforms, Cisco IOS XE
the following URL:
RFCs
RFC Title
1142 IS-IS
1195 Use of OSI IS-IS for Routing in TCP/IP and Dual Environments
2205 Resource ReSerVation Protocol (RSVP)
2328 OSPF Version 2
2370 The OSPF Opaque LSA Option
Description Link
23
Feature Information for MPLS Traffic Engineering and Enhancements
Feature Information for MPLS Traffic Engineering and

Enhancements
Table 1 Feature Information for MPLS Traffic Engineering and Enhancements

MPLS Traffic Engineering and Enhancements Cisco IOS XE Multiprotocol Label Switching (MPLS) traffic engineering
Release 2.3 software enables an MPLS backbone to replicate and
expand upon the traffic engineering capabilities of Layer 2
ATM and Frame Relay networks. MPLS is an integration of
Layer 2 and Layer 3 technologies. By making traditional
Layer 2 features available to Layer 3, MPLS enables traffic
engineering. Thus, you can offer in a one-tier network what
previously could be achieved only by overlaying a Layer 3
network on a Layer 2 network.
feature:
• Introduction to MPLS Traffic Engineering and
Enhancements, page 2Benefits of MPLS Traffic
Engineering, page 3
• How MPLS Traffic Engineering Works, page 3
• Mapping Traffic into Tunnels, page 4
• Transition of an IS-IS Network to a New Technology,
page 8Configuring a Device to Support Tunnels,
page 12
• Configuring an Interface to Support RSVP-Based
Tunnel Signaling and IGP Flooding, page 12.
• Configuring IS-IS for MPLS Traffic Engineering,
page 14
• Configuring OSPF for MPLS Traffic Engineering,
page 15
24
Feature Information for MPLS Traffic Engineering and Enhancements
Table 1 Feature Information for MPLS Traffic Engineering and Enhancements

• Configuring an MPLS Traffic Engineering Tunnel,
page 16
• Configuring an MPLS Traffic Engineering Tunnel that
an IGP Can Use, page 18
ip explicit-path, metric-style narrow, metric-style
transition, metric-style wide, mpls traffic-eng, mpls
traffic-eng area, mpls traffic-eng router-id, mpls
traffic-eng tunnels (configuration), mpls traffic-eng
tunnels (interface), show mpls traffic-eng autoroute,
show mpls traffic-eng tunnels, tunnel mode mpls
traffic-eng, tunnel mode mpls traffic-eng autoroute
announce, tunnel mpls traffic-eng bandwidth, tunnel
mpls traffic-eng path-option, tunnel mpls traffic-eng
priority.
25
Glossary
Glossary
affinity—An MPLS traffic engineering tunnel's requirements on the attributes of the links it will cross.
The tunnel's affinity bits and affinity mask bits must match the attribute bits of the various links carrying
the tunnel.
call admission precedence—An MPLS traffic engineering tunnel with a higher priority will, if
necessary, preempt an MPLS traffic engineering tunnel with a lower priority. Tunnels that are harder to
route are expected to have a higher priority and to be able to preempt tunnels that are easier to route. The
assumption is that lower-priority tunnels will be able to find another path.
constraint-based routing—Procedures and protocols that determine a route across a backbone take into
account resource requirements and resource availability instead of simply using the shortest path.
flow—A traffic load entering the backbone at one point—point of presence (POP)—and leaving it from
another, that must be traffic engineered across the backbone. The traffic load is carried across one or
more LSP tunnels running from the entry POP to the exit POP.
headend—The upstream, transmit end of a tunnel.
IGP—Interior Gateway Protocol. The Internet protocol used to exchange routing information within an
autonomous system. Examples of common IGPs include IGRP, OSPF, and RIP.
ip explicit path—A list of IP addresses, each representing a node or link in the explicit path.
IS-IS—Intermediate System-to-Intermediate System. OSI link-state hierarchical routing protocol that
calls for intermediate system (IS) routers to exchange routing information based on a single metric to
determine network topology.
label switched path (LSP)—A sequence of hops (R0...Rn) in which a packet travels from R0 to Rn
through label switching mechanisms. A label switched path can be chosen dynamically, based on normal
routing mechanisms, or through configuration.
label switched path (LSP) tunnel—A configured connection between two routers, in which label
switching is used to carry the packets.
label switching router (LSR)—A Layer 3 router that forwards packets based on the value of a label
encapsulated in the packets.
LCAC—Link-level (per hop) call admission control.
LSA—Link-state advertisement. Flooded packet used by OSPF that contains information about
neighbors and path costs. In IS-IS, receiving routers use LSAs to maintain their routing tables.
LSP—See label switched path.
OSPF protocol—Open Shortest Path First. A link state routing protocol used for routing IP.
reoptimization—Reevaluation of the most suitable path for a tunnel to use, given the specified
constraints.
tailend—The downstream, receive end of a tunnel.
traffic engineering—Techniques and processes that cause routed traffic to travel through the network
on a path other than the one that would have been chosen if standard routing methods were used.
26
Glossary
countries.
coincidental.
27
Glossary
28
MPLS Traffic Engineering—Configurable Path
Calculation Metric for Tunnels

The MPLS Traffic Engineering—Configurable Path Calculation Metric for Tunnels feature enables the
user to control the metric used in path calculation for traffic engineering (TE) tunnels on a per-tunnel
basis. Certain tunnels are used to carry voice traffic, which requires low delay, and other tunnels are used
to carry data. A TE link metric can be used to represent link delay and configure tunnels that carry voice
traffic for path calculation and configure tunnels that carry data to use the Interior Gateway Protocol
(IGP) metric for path calculation.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering—Configurable
Path Calculation Metrics for Tunnels” section on page 18.
Contents
• Prerequisites for MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels,
page 2
• Restrictions for MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels,
page 2
• Information About MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels,
page 2
MPLS Traffic Engineering—Configurable Path Calculation Metric for Tunnels
Prerequisites for MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels
• How to Configure MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels,
page 3
• Configuration Examples for Configuring a Path Calculation Metric for Tunnels, page 14
• Feature Information for MPLS Traffic Engineering—Configurable Path Calculation Metrics for
Tunnels, page 18
Prerequisites for MPLS Traffic Engineering—Configurable Path

Calculation Metrics for Tunnels
Before you configure tunnel path calculation metrics, your network must support the following
Cisco IOS XE features:
• Multiprotocol Label Switching (MPLS) traffic engineering tunnels
• Open Shortest Path First (OSPF) or Intermediate System-to-Intermediate System (IS-IS)
Restrictions for MPLS Traffic Engineering—Configurable Path

Calculation Metrics for Tunnels
Unless explicitly configured, the TE link metric for a given link is the IGP link metric. When the TE link
metric is used to represent a link property that is different from cost/distance, you must configure every
network link that can be used for TE tunnels with a TE link metric that represents that property by using
the mpls traffic-eng administrative-weight command. Failure to do so might cause tunnels to use
unexpected paths.
Information About MPLS Traffic Engineering—Configurable

Path Calculation Metrics for Tunnels
Before you configure path metrics for TE tunnels, you should understand the following concepts:
• MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels Overview, page 2
• MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels Benefits, page 3
MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels

Overview
When MPLS TE is configured in a network, the IGP floods two metrics for every link: the normal IGP
(OSPF or IS-IS) link metric and a TE link metric. The IGP uses the IGP link metric in the normal way
to compute routes for destination networks.
You can specify that the path calculation for a given tunnel be based on either of the following:
2
How to Configure MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels
• IGP link metrics.

• TE link metrics, which you can configure so that they represent the needs of a particular application.
For example, the TE link metrics can be configured to represent link transmission delay.
MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels

Benefits
When TE tunnels are used to carry two types of traffic, the Configurable Path Calculation Metric for
Tunnels feature allows you to tailor tunnel path selection to the requirements of each type of traffic.
For example, suppose certain tunnels are to carry voice traffic (which requires low delay) and other
tunnels are to carry data. In this situation, you can use the TE link metric to represent link delay and do
the following:
• Configure tunnels that carry voice to use the TE link metric set to represent link delay for path
calculation.
• Configure tunnels that carry data to use the IGP metric for path calculation.
How to Configure MPLS Traffic Engineering—Configurable

Path Calculation Metrics for Tunnels
Perform the following configuration tasks for the configurable path calculation metric feature:
• Configuring a Platform to Support Traffic Engineering Tunnels, page 3 (required)
• Configuring the IGP (IS-IS or OSPF) for MPLS Traffic Engineering, page 4 (required)
• Configuring Traffic Engineering Link Metrics, page 7 (required)
• Configuring the Metric Type for Tunnel Path Calculation, page 11 (required)
• Verifying the Tunnel Path Metric Configuration, page 12 (optional)
Configuring a Platform to Support Traffic Engineering Tunnels

To configure a platform to support traffic engineering tunnels, perform the following task.
SUMMARY STEPS
1. enable
5. exit
3
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef distributed Enables distributed Cisco Express Forwarding operation.
Example:
Step 4 mpls traffic-eng tunnels Enables the MPLS traffic engineering tunnel feature on a
device.
Example:
EXEC mode.
Example:
Configuring the IGP (IS-IS or OSPF) for MPLS Traffic Engineering

To configure the IGP for MPLS TE, perform one of the following tasks:
• Configuring IS-IS for MPLS Traffic Engineering, page 4
• Configuring OSPF for MPLS Traffic Engineering, page 6

To configure IS-IS for MPLS traffic engineering, perform the following task.
SUMMARY STEPS
1. enable
3. router isis
4. mpls traffic-eng {level-1 | level-2}
5. mpls traffic-eng {level-1 | level-2}
8. exit
4
9. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router isis Enables IS-IS routing, specifies an IS-IS process for IP, and
enters router configuration.
Example:
Step 4 mpls traffic-eng {level-1 | level-2} Configures a router running IS-IS so that it floods MPLS TE
link information into the indicated IS-IS level.
Example: • This commands turns on MPLS TE for IS-IS level 1.
Step 5 mpls traffic-eng {level-1 | level-2} Configures a router running IS-IS so that it floods MPLS TE
link information into the indicated IS-IS level.
Example: • This command turns on MPLS TE for IS-IS level 2.
Step 6 mpls traffic-eng router-id interface-name Specifies that the TE router identifier for the node is the IP
address associated with a given interface.
Example: • This command specifies the IP address of loopback0 as
Router(config-router)# mpls traffic-eng the TE router ID.
router-id loopback0
type, length, value objects (TLVs).
Example:
configuration mode.
Example:
EXEC mode.
Example:
5

To configure OSPF for MPLS traffic engineering, perform the following task.
SUMMARY STEPS
1. enable
3. router ospf process-id]
6. exit
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router ospf process-id Configures an OSPF routing process for IP and enters
router configuration mode.
Example: • The process-id argument is an internally used
Router(config)# router ospf 100 identification parameter for an OSPF routing process. It
is locally assigned and can be any positive integer.
Assign a unique value for each OSPF routing process.
Step 4 mpls traffic-eng area number Configures a router running OSPF MPLS so that it floods
traffic engineering for the indicated OSPF area.
Example: • The number argument specifies the OSPF area on
Router(config-router)# mpls traffic-eng area 0 which MPLS TE is enabled.
Step 5 mpls traffic-eng router-id interface-name Specifies that the TE router identifier for the node is the IP
address associated with a given interface.
Example: • The interface-name argument specifies the IP address
Router(config-router)# mpls traffic-eng of loopback0 as the TE router ID.
router-id loopback0
6

configuration mode.
Example:
EXEC mode.
Example:
Configuring Traffic Engineering Link Metrics

To configure the TE link metric, perform the following task.
Unless explicitly configured, the TE link metric is the IGP link metric.
SUMMARY STEPS
1. enable
4. mpls traffic-eng administrative-weight weight
5. exit
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
7

• The type argument is the type of interface to be
Example: configured.
Router(config)# interface pos2/0/0
• The slot argument is the chassis slot number. Refer to
the appropriate hardware manual for slot information.
For SIPs, refer to the platform-specific SPA hardware
installation guide or the corresponding “Identifying
Slots and Subslots for SIPs and SPAs” topic in the
platform-specific SPA software configuration guide.
• The /subslot keyword and argument pair is the
secondary slot number on a SIP where a SPA is
installed. The slash (/) is required.
Refer to the platform-specific SPA hardware
installation guide and the corresponding “Specifying
the Interface Address on a SPA” topic in the
platform-specific SPA software configuration guide for
subslot information.
• The /port keyword and argument pair is the port or
interface number. The slash (/) is required.
Refer to the appropriate hardware manual for port
information. For SPAs, refer to the corresponding
“Specifying the Interface Address on a SPA” topics in
the platform-specific SPA software configuration guide
• The .subinterface-number keyword and argument pair
is the subinterface number in the range 1 to
4294967293. The number that precedes the period (.)
must match the number to which this subinterface
belongs.
Step 4 mpls traffic-eng administrative-weight weight Overrides the IGP administrative weight (cost) of the link.
• The weight argument is the cost of the link.
Example:
Router(config-if)# mpls traffic-eng
administrative-weight 20
configuration mode.
Example:
EXEC mode.
Example:
8

SUMMARY STEPS
1. enable
8. tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name
| id path-number}} [lockdown]
9. exit
10. exit
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example: • The number argument is the number of the tunnel.
Router(config)# interface Tunnel0
Step 4 ip unnumbered type number Enables IP processing on an interface without assigning an
explicit IP address to the interface.
Example: • The type and number arguments name the type and
Router(config-if)# ip unnumbered loopback0 number of another interface on which the router has an
assigned IP address. It cannot be another unnumbered
interface.
unnumbered because it represents a unidirectional link.
9

Step 5 tunnel destination ip-address Specifies the destination for a tunnel interface.
• The ip-address argument must be the MPLS traffic
Example: engineering router ID of the destination device.
192.168.4.4
Step 6 tunnel mode mpls traffic-eng Sets the tunnel encapsulation mode to MPLS traffic
engineering.
Example:
Router(config-if)# tunnel mode mpls traffic-eng
Step 7 tunnel mpls traffic-eng bandwidth bandwidth Configures the bandwidth for the MPLS traffic engineering
tunnel.
Example: • The bandwidth argument is a number in kilobits per
Router(config-if)# tunnel mpls traffic-eng second that is set aside for the MPLS traffic
bandwidth 250 engineering tunnel. Range is from 1 to 4294967295.
Note If automatic bandwidth is configured for the tunnel,
use the tunnel mpls traffic-eng bandwidth
command to configure the initial tunnel bandwidth,
which is adjusted by the autobandwidth mechanism.
Step 8 tunnel mpls traffic-eng path-option number Configures the tunnel to use a named IP explicit path or a
{dynamic | explicit {name path-name | path dynamically calculated from the traffic engineering
identifier path-number}} [lockdown]
topology database.
• The number argument is the preference for this path
Example: option. When you configure multiple path options,
Router(config-if)# tunnel mpls traffic-eng
lower numbered options are preferred. Valid values are
path-option 10 explicit identifier 321
from 1 to 1000.
• The dynamic keyword indicates that the path of the
label switched path (LSP) is dynamically calculated.
• The explicit keyword indicates that the path of the LSP
is an IP explicit path.
• The name path-name keyword and argument are the
path name of the IP explicit path that the tunnel uses
with this option.
• The identifier path-number keyword and argument
pair names the path number of the IP explicit path that
the tunnel uses with this option. The range is from 1 to
65535.
• The lockdown keyword specifies that The LSP cannot
be reoptimized.
Note A dynamic path is used if an explicit path is
currently unavailable.
10

configuration mode.
Example:
EXEC mode.
Example:
Configuring the Metric Type for Tunnel Path Calculation

To configure the metric type for tunnel path calculation, perform the following task.
Unless explicitly configured, the TE link metric type is used for tunnel path calculation. Two commands
are provided for controlling the metric type to be used: an interface configuration command that
specifies the metric type to be used for a particular TE tunnel and a global configuration command that
specifies the metric type to be used for TE tunnels for which a metric type has not been specified by the
interface configuration command.
Note If you do not enter either of the path selection metrics commands, the traffic engineering (TE) metric is
used.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng path-selection metric {igp | te}
5. exit
6. mpls traffic-eng path-selection metric {igp | te}
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
11

configuration mode.
Example: • The number argument is the number of the tunnel.
Step 4 tunnel mpls traffic-eng path-selection metric Specifies the metric type to use for path calculation for a
{igp | te} tunnel.
• The igp keyword specifies the use of the Interior
Example: Gateway Protocol (IGP) metric.
path-selection metric igp • The te keyword specifies the use of the traffic
engineering (TE) metric. This is the default.
configuration mode.
Example:
Step 6 mpls traffic-eng path-selection metric {igp | Specifies the metric type to use if a metric type was not
te} explicitly configured for a given tunnel.
• The igp keyword specifies the use of the Interior
Example: Gateway Protocol (IGP) metric.
Router(config)# mpls traffic-eng path-selection
metric igp • The te keyword specifies the use of the traffic
engineering (TE) metric. This is the default.
EXEC mode.
Example:
Verifying the Tunnel Path Metric Configuration

Perform the following task to verify that the tunnel path metrics are what you configured.
SUMMARY STEPS
1. enable
2. show mpls traffic-eng topology
3. show mpls traffic-eng tunnels
4. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls traffic-eng topology
12
Use the show mpls traffic-eng topology command, which displays TE and IGP metrics for each link,
to verify that link metrics have been correctly configured for a network. For example:
Router# show mpls traffic-eng topology
My_System_id: 1440.0000.0044.00 (isis level-1)

IGP Id: 0090.0000.0009.00, MPLS TE Id:192.168.9.9 Router Node (isis level-1)
link[0 ]:Nbr IGP Id: 0090.0000.0009.03, gen:7
frag_id 0, Intf Address:10.0.0.99
TE metric:100, IGP metric:48, attribute_flags:0x0 !!Note TE and IGP metrics
physical_bw: 10000 (kbps), max_reservable_bw_global: 0 (kbps)
max_reservable_bw_sub: 0 (kbps)
.
.
.
link[1 ]:Nbr IGP Id: 0055.0000.0055.00, gen:7
frag_id 0, Intf Address:10.205.0.9, Nbr Intf Address:10.205.0.55
TE metric:120, IGP metric:10, attribute_flags:0x0 !!Note TE and IGP metrics
physical_bw: 155000 (kbps), max_reservable_bw_global: 500000 (kbps)
max_reservable_bw_sub: 0 (kbps)
.
.
.
Step 3 show mpls traffic-eng tunnels
Use the show mpls traffic-eng tunnels command, which displays the link metric used for tunnel path
calculation, to verify that the desired link metrics are being used for each tunnel. For example:
Router# show mpls traffic-eng tunnels
Name: te3640-17-c_t221 (Tunnel22) Destination: 192.168.100.22

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 1, type dynamic (Basis for Setup, path weight 10)
Config Parameters:
Bandwidth: 400 kps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF
Metric Type: IGP !!Note metric type
AutoRoute: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled(0/115) 0 Bandwidth Requested: 0
.
.
.
Name: te3640-17-c_t222 (Tunnel33) Destination: 192.168.100.22
Status:
path option 1, type dynamic (Basis for Setup, path weight 10)
Config Parameters:
Bandwidth: 200 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF
Metric Type: TE !!Note metric type
auto-bw: disabled(0/115) 0 Bandwidth Requested: 0
.
.
.
13
Configuration Examples for Configuring a Path Calculation Metric for Tunnels
Step 4 exit
Use this command to return to user EXEC mode. For example:
Router# exit
Router>
Configuration Examples for Configuring a Path Calculation

Metric for Tunnels
This section contains the following example for configuring path calculation metrics for tunnels:
• Configuring Link Type and Metrics for Tunnel Path Selection: Examples, page 14
Configuring Link Type and Metrics for Tunnel Path Selection: Examples
The section illustrates how to configure the link metric type to be used for tunnel path selection, and how
to configure the link metrics themselves. The configuration commands included focus on specifying the
metric type for path calculation and assigning metrics to links. Additional commands are required to
fully configure the example scenario: for example, the IGP commands for traffic engineering and the
link interface commands for enabling traffic engineering and specifying available bandwidth.
The examples in this section support the simple network technology shown in Figure 1.
Figure 1 Network Topology
igp: 10 R2 loopback0
192.168.2.2 / 255.255.255.0
te: 15 igp: 10
te: 40
pos0/3//0 pos1/3/1
pos0/2/0 pos2/0/0
R1 loopback0
igp: 15 igp: 10 192.168.4.4 / 255.255.255.0
te: 15 te: 5
pos0/1/0 pos2/1/0
loopback0 R4
192.168.1.1 / 255.255.255.0
pos2/2/0
pos2/0/0 pos0/1/1
igp: 10
te: 5
R3
loopback0 pos0/3/0
192.168.3.3 / 255.255.255.0
pos1/1/0
pos1/0/0
loopback0
192.168.5.5 / 255.255.255.0
192801
igp: 10
te: 15 R5
In Figure 1:
• Tunnel1 and Tunnel2 run from R1 (headend) to R4 (tailend).
14
Configuration Examples for Configuring a Path Calculation Metric for Tunnels
• Tunnel3 runs from R1 to R5.

• Path calculation for Tunnel1 and Tunnel3 should use a metric that represents link delay because
these tunnels carry voice traffic.
• Path calculation for Tunnel2 should use IGP metrics because MPLS TE carries data traffic with no
delay requirement.
Configuration fragments follow for each of the routers that illustrate the configuration relating to link
metrics and their use in tunnel path calculation. TE metrics that represent link delay must be configured
for the network links on each of the routers, and the three tunnels must be configured on R1.
These configuration fragments force Tunnel1 to take path R1-R3-R4, Tunnel2 to take path R1-R2-R4,
and Tunnel3 to take path R1-R3-R4-R5 (assuming the links have sufficient bandwidth to accommodate
the tunnels).
R1 Configuration
The following example shows how to configure the tunnel headend (R1) for Tunnel1, Tunnel2, and
Tunnel3 in Figure 1:
interface pos0/1/0
mpls traffic-eng administrative-weight 15 !TE metric different from IGP metric
interface pos0/2/0
interface Tunnel1 !Tunnel1 uses TE metric (default)

!for path selection
ip unnumbered loopback0
tunnel destination 192.168.4.4 255.255.255.0
interface Tunnel2 !Tunnel2 uses IGP metric

!for path selection
tunnel mpls traffic-eng path-selection-metric igp !Use IGP cost for path selection.
interface Tunnel3 !Tunnel3 uses TE metric (default)

!for path selection
R2 Configuration
The following example shows how to configure R2 in Figure 1:
interface pos0/3/0
interface pos1/3/1
R3 Configuration
15
interface pos2/0/0
interface pos0/3/0
interface pos0/1/1
R4 Configuration
interface pos2/0/0
interface pos2/1/0
interface pos2/2/0
R5 Configuration
interface pos1/0/0
interface pos1/1/0
The following sections provide references related to the MPLS Traffic Engineering—Configurable Path
Calculation Metrics for Tunnels feature.
Related Documents
Configuration tasks for IS-IS and OSPF Cisco IOS XE IP Routing Protocols Configuration Guide
IS-IS and OSPF commands Cisco IOS IP Routing Protocols Command Reference
Configuration tasks for MPLS and MPLS TE Cisco IOS XE Multiprotocol Label Switching Configuration Guide
Configuration tasks for tunnels • Cisco IOS XE Interface and Hardware Component
Configuration Guide
• Cisco IOS XE Multiprotocol Label Switching Configuration
Guide
Tunnel configuration commands • Cisco IOS Interface and Hardware Component Command
Reference
• Cisco IOS XE Multiprotocol Label Switching Command
Reference
16
Standards
Standard Title
No new or modified standards are supported by this –
MIBs
MIB MIBs Link
RFCs
RFC Title
No new or modified RFCs are supported by this –
modified.
Description Link
17
Feature Information for MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels
Feature Information for MPLS Traffic

Engineering—Configurable Path Calculation Metrics for
Tunnels
Table 1 lists the features in this module and provides links to specific configuration information
Table 1 Feature Information for MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels

MPLS Traffic Engineering—Configurable Path Cisco IOS XE The MPLS Traffic Engineering—Configurable Path
Calculation Metric for Tunnels Release 2.3 Calculation Metric for Tunnels feature enables the user
to control the metric used in path calculation for traffic
engineering (TE) tunnels on a per-tunnel basis. Certain
tunnels are used to carry voice traffic, which requires
low delay, and other tunnels are used to carry data. A
TE link metric can be used to represent link delay and
configure tunnels that carry voice traffic for path
calculation and configure tunnels that carry data to use
the Interior Gateway Protocol (IGP) metric for path
calculation.
introduced on the Cisco ASR 1000 Series Aggregation
Services Routers.
feature:
• MPLS Traffic Engineering—Configurable Path
Calculation Metrics for Tunnels Overview, page 2
• MPLS Traffic Engineering—Configurable Path
Calculation Metrics for Tunnels Benefits, page 3
• Configuring a Platform to Support Traffic
Engineering Tunnels, page 3
• Configuring the IGP (IS-IS or OSPF) for MPLS
Traffic Engineering, page 4
• Configuring Traffic Engineering Link Metrics,
page 7
18
Table 1 Feature Information for MPLS Traffic Engineering—Configurable Path Calculation Metrics for Tunnels

• Configuring an MPLS Traffic Engineering
Tunnel, page 9
• Configuring the Metric Type for Tunnel Path
Calculation, page 11
• Verifying the Tunnel Path Metric Configuration,
page 12
• Configuring Link Type and Metrics for Tunnel
Path Selection: Examples, page 14
The following commands were introduced or
modified: mpls traffic-eng path-selection metric,
tunnel mpls traffic-eng path-selection metric.
countries.
coincidental.
19
20
MPLS Traffic Engineering—Scalability
Enhancements
First Published: February 23, 2002

The MPLS Traffic Engineering—Scalability Enhancement feature improves scalability performance for
large numbers of traffic engineering tunnels.
These improvements allow an increase in the number of traffic engineering (TE) tunnels a router can
support when the router is configured as a tunnel headend. Additionally, when the router is configured
as a tunnel midpoint, the enhancements reduce the time required to establish large numbers of TE
tunnels.
This feature module contains information about and instructions on how to configure the Multiprotocol
Label Switching (MPLS) traffic engineering scalability enhancements.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering—Scalability
Enhancements” section on page 14.
Contents
• Prerequisites for MPLS Traffic Engineering—Scalability Enhancements, page 2
• Restrictions for MPLS Traffic Engineering—Scalability Enhancements, page 2
• Information About MPLS Traffic Engineering—Scalability Enhancements, page 2
• How to Configure MPLS Traffic Engineering—Scalability Enhancements, page 4
MPLS Traffic Engineering—Scalability Enhancements
Prerequisites for MPLS Traffic Engineering—Scalability Enhancements
• Configuration Examples for MPLS Traffic Engineering—Scalability Enhancements, page 11

• Feature Information for MPLS Traffic Engineering—Scalability Enhancements, page 14
Prerequisites for MPLS Traffic Engineering—Scalability

Enhancements
Your network must support the following Cisco IOS XE features before you enable MPLS traffic
engineering:
• MPLS
Restrictions for MPLS Traffic Engineering—Scalability

Enhancements
The number of tunnels that a particular platform can support can vary depending on:
• The types of interfaces that the tunnels traverse
• The manner in which the Resource Reservation Protocol (RSVP) message pacing feature is
configured
Information About MPLS Traffic Engineering—Scalability

Enhancements
The following sections describe user-observable scalability enhancements:
• Scalability Enhancements for Traffic Engineering Tunnels, page 2
• RSVP Rate Limiting, page 3
• Improved Recovery Response for Signaling and Management of MPLS Traffic Engineering
Tunnels, page 3
• IS-IS and MPLS Traffic Engineering Topology Database Interactions, page 3
• Improved Counter Capabilities for MPLS TE Tunnels Events and RSVP Signaling, page 4
• Benefits of MPLS Traffic Engineering—Scalability Enhancements, page 4
Scalability Enhancements for Traffic Engineering Tunnels

Scalability performance is improved for large numbers of traffic engineering tunnels, and includes the
following enhancements:
2
Information About MPLS Traffic Engineering—Scalability Enhancements
• Increase the number of traffic engineering tunnels a router can support when configured as a tunnel
headend and when configured as a tunnel midpoint
• Reduce the time required to establish large numbers of traffic engineering tunnels
RSVP Rate Limiting

A burst of RSVP traffic engineering signaling messages can overflow the input queue of a receiving
router, causing some messages to be dropped. Dropped messages cause a substantial delay in completing
label switched path (LSP) signaling.
This MPLS Traffic Engineering—Scalability Enhancements feature provides an enhancement
mechanism that controls the transmission rate for RSVP messages and reduces the likelihood of input
drops on the receiving router. The default transmission rate is 200 RSVP messages per second to a given
neighbor. The rate is configurable.
Improved Recovery Response for Signaling and Management of MPLS Traffic

Engineering Tunnels
The MPLS Traffic Engineering—Scalability Enhancements feature improves the recovery response for
signaling and management of MPLS TE tunnels. LSP recovery responsiveness is improved when a link
used by an LSP fails:
• When the upstream end of a failed link detects the failure, the software generates an RSVP No Route
path error message. This enables the LSP headend to detect the link failure and initiate recovery,
even when the Interior Gateway Protocol (IGP) update announcing the link failure is delayed.
• The LSP headend marks the link in question so that subsequent constraint-based shortest path
first (SPF) calculations ignore the link until either a new IGP update arrives or a configurable
timeout occurs. This ensures that resignaling to restore the LSP avoids the failed link.
IS-IS and MPLS Traffic Engineering Topology Database Interactions

The MPLS Traffic Engineering—Scalability Enhancements feature reduces the interval between when
the IS-IS protocol receives an IGP update and when it delivers the update to the MPLS traffic
engineering topology database.
Before the MPLS Traffic Engineering—Scalability Enhancements feature was introduced, when IS-IS
received a new LSP that contained traffic engineering type, length, value (TLV) objects, a delay of
several seconds could occur before IS-IS passed the traffic engineering TLVs to the traffic engineering
database. The purpose of the delay was to provide better scalability during periods of network instability
and to give the router an opportunity to receive more fragments of the LSP before passing the
information to the traffic engineering database. However, this delay increased the convergence time for
the traffic engineering database.
With the MPLS Traffic Engineering—Scalability Enhancements feature, IS-IS extracts traffic
engineering TLVs from received LSPs and passes them to the traffic engineering database immediately.
The exception to this occurs when there are large numbers of LSPs to process and it is important to limit
CPU consumption, such as during periods of network instability. The parameters that control IS-IS
delivery of traffic engineering TLVs to the traffic engineering topology database are configurable.
3
How to Configure MPLS Traffic Engineering—Scalability Enhancements
Improved Counter Capabilities for MPLS TE Tunnels Events and RSVP Signaling
With the MPLS Traffic Engineering—Scalability Enhancements feature, diagnostic and troubleshooting
capabilities for MPLS traffic engineering tunnels and RSVP are improved:
• Counters record tunnel headend error events such as no route (link down), preemption, and
insufficient bandwidth on a per-tunnel basis.
• Counters record RSVP messages. The counters are per-interface and record the number of RSVP
messages of each type sent and received on the interface.
Benefits of MPLS Traffic Engineering—Scalability Enhancements

The MPLS Traffic Engineering—Scalability Enhancements feature provides the following benefits:
• Increased scalability—Up to 600 MPLS traffic engineering tunnel headends are supported. Up to
10,000 traffic engineering tunnel midpoints are supported, with up to 5000 midpoints per interface.
• Faster recovery after failure conditions—Message pacing provides a mechanism to throttle RSVP
control messages so that they are less likely to be dropped. This results in a faster recovery from
failure conditions when many MPLS traffic engineering tunnels are being set up.
• Improved reroute time—When a traffic engineering tunnel is down, the headend router needs to be
notified so that it can signal for a new LSP for the tunnel along an alternate path. The headend router
does not have to wait for an IGP update to signal for a new LSP for the tunnel along an alternate path.
• Improved tunnel setup time—Fewer control messages and tunnel setup messages are dropped. This
reduces the average time required to set up tunnels.
How to Configure MPLS Traffic Engineering—Scalability

Enhancements
This section describes the following tasks:
• Enabling RSVP Rate Limiting for MPLS Traffic Engineering Scalability Enhancements, page 4
(required)
• Managing Link Failure Timeouts for MPLS Traffic Engineering Tunnels, page 6 (required)
• Controlling IS-IS Communication with the MPLS Traffic Engineering Topology Database, page 7
(required)
• Monitoring and Maintaining MPLS TE Scalability Enhancements, page 8 (optional)
Enabling RSVP Rate Limiting for MPLS Traffic Engineering Scalability

Enhancements
Perform the following task to enable RSVP rate limiting for MPLS traffic engineering scalability
enhancements. RSVP rate limiting maintains, on an outgoing interface basis, a count of messages that
were dropped because the output queue for the interface used for rate limiting was full.
4
SUMMARY STEPS
1. enable
3. ip rsvp signalling rate-limit [burst number] [limit number] [maxsize bytes] [period ms]
4. end
5. show ip rsvp neighbor
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling rate-limit [burst number] Controls the transmission rate for RSVP messages sent to a
[limit number] [maxsize bytes] [period ms] neighboring router during a specified amount of time.
• The burst number keyword and argument pair indicates
Example: the maximum number of RSVP messages sent to a
Router(config)# ip rsvp signalling rate-limit neighboring router during each interval. The range is
burst 5 maxsize 3 period 2
from 1 to 5000. The default is 8.
• The limit number keyword and argument pair indicates
the maximum number of messages to send per queue
interval when the number of messages sent is less than
the number of messages to be sent normally. The range
is 1 to 5000. The default is 37.
• The maxsize bytes keyword and argument pair
indicates the maximum size of the message queue, in
bytes. The range is 1 to 5000. The default is 2000.
• The period ms keyword and argument pair indicates the
length of the interval (time frame) in milliseconds (ms).
The range is 10 to 5000. The default is 20.
Example:
Router(config)# end
Step 5 show ip rsvp neighbor Displays current RSVP neighbors.
Use this command to verify that RSVP message pacing is
Example: enabled.
Router# show ip rsvp neighbor
5
Managing Link Failure Timeouts for MPLS Traffic Engineering Tunnels

Perform this task to manage link failure timeouts for MPLS traffic engineering tunnels.
This allows the configuration of a timeout during which the router ignores a link in its path calculation
to avoid paths that contain a failed link and are likely to fail when signaled.
SUMMARY STEPS
1. enable
3. mpls traffic-eng topology holddown sigerr seconds
4. end
5. show mpls traffic-eng topology [brief]
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng topology holddown sigerr Specifies the amount of time that a router ignores a link in
seconds its traffic engineering topology database in tunnel path
Constrained Shortest Path First (CSPF) computations
Example: following a traffic engineering tunnel error on the link.
Router(config)# mpls traffic-eng topology • The seconds argument specifies the length of time
holddown sigerr 15
(in seconds) a router should ignore a link during tunnel
path calculations following a traffic engineering tunnel
error on the link. The range is 0 to 300. The default is
10.
Example:
Router(config)# end
Step 5 show mpls traffic-eng topology [brief] Displays the MPLS traffic engineering global topology as
currently known at this node.
Example: • The brief keyword provides a less detailed version of
Router# show mpls traffic-eng topology brief the topology.
6
Controlling IS-IS Communication with the MPLS Traffic Engineering Topology

Database
Perform the following task to control IS-IS and MPLS traffic engineering topology database
interactions. This reduces the interval time between when the IS-IS protocol receives an IGP update and
when IS-IS delivers the update to the MPLS traffic engineering topology database, which reduces
convergence time for the database.
SUMMARY STEPS
1. enable
3. router isis [area-tag]
4. mpls traffic-eng scanner [interval seconds] [max-flash LSPs]
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router isis [area-tag] Enables the IS-IS routing protocol and specifies an IS-IS
process.
Example: • The area-tag argument is a meaningful name for a
Router(config)# router isis routing process. If it is not specified, a null tag is
assumed and the process is referenced with a null tag.
This name must be unique among all IP or
Connectionless Network Service (CLNS) router
processes for a given router.
Note This argument is Required for multiarea IS-IS
configuration and optional for conventional IS-IS
configuration.
7

Step 4 mpls traffic-eng scanner [interval seconds] Specifies how often IS-IS extracts traffic engineering TLVs
[max-flash LSPs] from flagged LSPs and passes them to the traffic
engineering topology database, and specifies the maximum
Example: number of LSPs that the router can process immediately.
Router(config-router)# mpls traffic-eng scanner • The interval seconds keyword and argument specify
interval 5 max-flash 100
the frequency, in seconds, at which IS-IS sends traffic
engineering TLVs into the traffic engineering database.
The range is 1 to 60. The default is 5.
• The max-flash LSPs keyword and argument specify the
maximum number of LSPs that the router can process
immediately without incurring a delay. The range is
0 to 200. The default is 15.
Example:
Router(config-router)# end
Monitoring and Maintaining MPLS TE Scalability Enhancements

Perform the following task to monitor and maintain the MPLS TE scalability enhancements.
SUMMARY STEPS
1. enable
2. show ip rsvp neighbor [detail]
3. show ip rsvp counters [summary]
4. clear ip rsvp counters
5. clear ip rsvp signalling rate-limit
6. show mpls traffic-eng tunnels statistics
7. clear mpls traffic-eng tunnels counters
8. show mpls traffic-eng topology [brief]
9. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show ip rsvp neighbor [detail]

Use this command to verify that RSVP message pacing is turned on. For example:
Router# show ip rsvp neighbor detail
8
Neighbor:10.0.0.1
Encapsulation:RSVP
Rate-Limiting:
Dropped messages:0
Refresh Reduction:
Remote epoch:0x1BFEA5
Out of order messages:0
Retransmitted messages:0
Highest rcvd message id:1059
Last rcvd message:00:00:04
Neighbor:10.0.0.2
Encapsulation:RSVP
Rate-Limiting:
Dropped messages:0
Refresh Reduction:
Remote epoch:0xB26B1
Out of order messages:0
Retransmitted messages:0
Highest rcvd message id:945
Last rcvd message:00:00:05
Step 3 show ip rsvp counters [summary]

Use this command to display the counts of RSVP messages that were sent and received. For example:
Router# show ip rsvp counters summary
All Interfaces Recv Xmit Recv Xmit

Path 110 15 Resv 50 28
PathError 0 0 ResvError 0 0
PathTear 0 0 ResvTear 0 0
ResvConf 0 0 RTearConf 0 0
Ack 0 0 Srefresh 0 0
Hello 5555 5554 IntegrityChalle 0 0
IntegrityRespon 0 0 DSBM_WILLING 0 0
I_AM_DSBM 0 0
Unknown 0 0 Errors 0 0
Recv Msg Queues Current Max

RSVP 0 2
Hello (per-I/F) 0 1
Awaiting Authentication 0 0
Step 4 clear ip rsvp counters

Use this command to clear (set to zero) all IP RSVP counters that are being maintained. For example:
Router# clear ip rsvp counters
Clear rsvp counters [confirm]
Step 5 clear ip rsvp signalling rate-limit

Use this command to clear (set to zero) counts of the messages that message pacing was forced to drop
because the output queue for the interface used for message pacing was full. For example:
Router# clear ip rsvp signalling rate-limit
Step 6 show mpls traffic-eng tunnels statistics

Use this command to display event counters for one or more MPLS traffic engineering tunnels. For
example:
9
Router# show mpls traffic-eng tunnels statistics
Tunnel1001 (Destination 10.8.8.8; Name Router_t1001)

Management statistics:
Path:25 no path, 1 path no longer valid, 0 missing ip exp path
5 path changes
State:3 transitions, 0 admin down, 1 oper down
Signalling statistics:
Opens:2 succeeded, 0 timed out, 0 bad path spec
0 other aborts
Errors:0 no b/w, 0 no route, 0 admin
0 bad exp route, 0 rec route loop, 0 other
.
.
.
Tunnel7050 (Destination 10.8.8.8; Name Router_t7050)
Management statistics:
Path: 19 no path, 1 path no longer valid, 0 missing ip exp path
3 path changes
State: 3 transitions, 0 admin down, 1 oper down
Signalling statistics:
Opens: 2 succeeded, 0 timed out, 0 bad path spec
0 other aborts
Errors:0 no b/w, 0 no route, 0 admin
0 bad exp route, 0 rec route loop, 0 other
Step 7 clear mpls traffic-eng tunnels counters

Use this command to clear counters for all MPLS traffic engineering tunnels. For example:
Router# clear mpls traffic-eng tunnels counters
Clear traffic engineering tunnel counters [confirm]
Step 8 show mpls traffic-eng topology [brief]

Use this command to display the MPLS traffic engineering topology database. For example:
Router# show mpls traffic-eng topology brief
My_System_id:0000.0000.0003.00 (isis level-2)
Signalling error holddown:10 sec Global Link Generation 9
IGP Id:0000.0000.0003.00, MPLS TE Id:10.0.3.1 Router Node (isis

level-2)
link[0]:Point-to-Point, Nbr IGP Id:0000.0000.0004.00,
nbr_node_id:2, gen:9
frag_id 0, Intf Address:10.0.0.33, Nbr Intf Address:10.0.0.34
TE metric:10, IGP metric:10, attribute_flags:0x0
SRLGs:1 2
Step 9 exit
Router# exit
Router>
10
Configuration Examples for MPLS Traffic Engineering—Scalability Enhancements
Configuration Examples for MPLS Traffic

Engineering—Scalability Enhancements
This section contains the following configuration examples for the MPLS traffic engineering scalability
enhancements:
• Enabling RSVP Rate Limiting for MPLS Traffic Engineering Scalability Enhancements: Examples,
page 11
• Managing Link Failure Timeouts for MPLS Traffic Engineering Tunnels: Example, page 11
• Controlling IS-IS Communication with the MPLS Traffic Engineering Topology Database:
Example, page 12
Enabling RSVP Rate Limiting for MPLS Traffic Engineering Scalability

Enhancements: Examples
The following examples show how to enable RSVP rate limiting for MPLS traffic engineering scalability
enhancements:
configure terminal
ip rsvp signalling rate-limit
end
The following is sample output that traffic engineering displays when RSVP rate limiting is enabled:
Router# show ip rsvp signalling rate-limit
Rate Limiting: enabled

Burst: 10
Limit: 37
Maxsize: 5000
Period (msec): 100
Max rate (msgs/sec): 100
The following example shows how to configure a router to send a maximum of 5 RSVP traffic
engineering signaling messages in 1 second to a neighbor. The size of the output queue is 35.
configure terminal
ip rsvp signalling rate-limit period 1 burst 5 maxsize 35
Managing Link Failure Timeouts for MPLS Traffic Engineering Tunnels:

Example
The following example shows how to manage link failure timeouts for MPLS traffic engineering tunnels:
configure terminal
mpls traffic-eng topology holddown sigerr 15

end
In this example, the link hold-down time for signaling errors is set to 15 seconds.
11
Controlling IS-IS Communication with the MPLS Traffic Engineering Topology

Database: Example
The following example shows how to control IS-IS communication with the MPLS traffic engineering
topology database:
configure terminal
router isis
mpls traffic-eng scanner interval 5 max-flash 50
end
In this example, the router is enabled to process up to 50 IS-IS LSPs without any delay.
The following sections provide references related to the MPLS Traffic Engineering (TE)—Scalability
Enhancements feature.
Related Documents
Quality of service • Cisco IOS Quality of Service Solutions Command Reference
• Cisco IOS XE Quality of Service Solutions Configuration Guide,
Release 2
MPLS • Cisco IOS Multiprotocol Label Switching Command Reference
• Cisco IOS XE Multiprotocol Label Switching Configuration Guide,
Release 2
Standards
Standard Title
MIBs
MIB MIBs Link
12
RFCs
RFC Title
Description Link
13
Feature Information for MPLS Traffic Engineering—Scalability Enhancements
Feature Information for MPLS Traffic Engineering—Scalability

Enhancements
Table 1 Feature Information for MPLS Traffic Engineering—Scalability Enhancements

MPLS Traffic Engineering—Scalability Cisco IOS XE The MPLS Traffic Engineering—Scalability Enhancements
Enhancements Release 2.3 feature improves scalability performance for large numbers
of traffic engineering tunnels.
These improvements allow an increase in the number of
traffic engineering (TE) tunnels a router can support when
the router is configured as a tunnel headend. Additionally,
when the router is configured as a tunnel midpoint, the
enhancements reduce the time required to establish large
numbers of TE tunnels.
This feature module contains information about and
instructions on how to configure the Multiprotocol Label
Switching (MPLS) traffic engineering scalability
enhancements.
feature:
• RSVP Rate Limiting, page 3
• Improved Recovery Response for Signaling and
Management of MPLS Traffic Engineering Tunnels,
page 3
• IS-IS and MPLS Traffic Engineering Topology
Database Interactions, page 3
• Improved Counter Capabilities for MPLS TE Tunnels
Events and RSVP Signaling, page 4
• Benefits of MPLS Traffic Engineering—Scalability
Enhancements, page 4
14
Feature Information for MPLS Traffic Engineering—Scalability Enhancements
Table 1 Feature Information for MPLS Traffic Engineering—Scalability Enhancements

• Enabling RSVP Rate Limiting for MPLS Traffic
Engineering Scalability Enhancements, page 4
• Monitoring and Maintaining MPLS TE Scalability
Enhancements, page 8
clear ip rsvp counters, clear ip rsvp signalling rate-limit,
clear mpls traffic-eng tunnel counters, ip rsvp signalling
rate-limit, mpls traffic-eng scanner, mpls traffic-eng
topology holddown sigerr, show ip rsvp counters, and
show mpls traffic-eng tunnels statistics.
15
Glossary
Glossary
Cisco Express Forwarding—A means for accelerating the forwarding of packets within a router, by
storing route lookup information in several data structures instead of in a route cache.
CLNS—Connectionless Network Services. The Open System Interconnection (OSI) network layer
service that does not require a circuit to be established before the data is transmitted. CLNS routes
messages to their destination independently of any other messages.
CSPF—Constrained Shortest Path First. A routing protocol that calculates the shortest path based on a
set of constraints, such as a minimum bandwidth requirement, maximum number of nodes, or nodes to
include or exclude.
enterprise network—A large and diverse network connecting most major points in a company or other
organization.
headend—The endpoint of a broadband network. All stations send toward the headend; the headend
then sends toward the destination stations.
IGP—Interior Gateway Protocol. An Internet protocol used to exchange routing information within an
autonomous system. Examples of common Internet IGPs include Interior Gateway Routing protocol
interface—A network connection.
IS-IS—Intermediate System-to-Intermediate System. OSI link-state hierarchical routing protocol based
on DECnet Phase V routing, where ISs (routers) exchange routing information based on a single metric,
to determine the network topology.
LSP—label switched path. A sequence of hops (R0...Rn) in which a packet travels from R0 to Rn
through label switching mechanisms. A label switched path can be chosen dynamically, based on normal
message-pacing—The former name of the rate limiting feature.
MPLS—Multiprotocol Label Switching (formerly known as tag switching). A method for directing
packets primarily through Layer 2 switching rather than Layer 3 routing. In MPLS, packets are assigned
short fixed-length labels at the ingress to an MPLS cloud by using the concept of forwarding equivalence
classes. Within the MPLS domain, the labels are used to make forwarding decisions mostly without
recourse to the original packet headers.
OSPF—Open Shortest Path First. A link-state, hierarchical Interior Gateway Protocol (IGP) routing
protocol. derived from the Intermediate System–Intermediate System (IS-IS) protocol. OSPF features
are least-cost routing, multipath routing, and load balancing.
router—A network layer device that uses one or more metrics to determine the optimal path along which
network traffic should be forwarded. Routers forward packets from one network to another based on
network layer information.
RSVP—Resource Reservation Protocol. A protocol that supports the reservation of resources across an
IP network.
scalability—An indicator showing how quickly some measure of resource usage increases as a network
gets larger.
TLV—type, length, value objects. TLVs are used in data communication to provide optional
information. The type field indicates the type of items in the value field. The length field indicates the
length of the value field. The value field is the data portion of the packet.
topology—The physical arrangement of network nodes and media within an enterprise networking
structure.
16
Glossary
countries.
17
Glossary
18
MPLS Traffic Engineering—LSP Attributes

This document describes how to configure label switched path (LSP) attributes for path options
associated with Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnels.
The MPLS Traffic Engineering—LSP Attributes feature is an extension to MPLS TE that provides an
LSP Attribute List feature and a Path Option for Bandwidth Override feature. These features provide
flexibility in the configuration of LSP attributes for MPLS TE tunnel path options. Several LSP attributes
can be applied to path options for TE tunnels using an LSP attribute list. If bandwidth is the only LSP
attribute you require, then you can configure a path option for bandwidth override.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering—LSP
Attributes” section on page 41.
Contents
• Prerequisites for MPLS Traffic Engineering—LSP Attributes, page 2
• Restrictions for MPLS Traffic Engineering—LSP Attributes, page 2
• Information About MPLS Traffic Engineering—LSP Attributes, page 2
• How to Configure MPLS Traffic Engineering—LSP Attributes, page 6
• Configuration Examples for MPLS Traffic Engineering—LSP Attributes, page 34
Prerequisites for MPLS Traffic Engineering—LSP Attributes
• Feature Information for MPLS Traffic Engineering—LSP Attributes, page 41

Prerequisites for MPLS Traffic Engineering—LSP Attributes

The MPLS Traffic Engineering—LSP Attributes feature requires that you configure an MPLS TE tunnel
before you configure either an LSP Attribute List or a Path Option for Bandwidth Override feature.
Restrictions for MPLS Traffic Engineering—LSP Attributes

Reoptimization between path options with different bandwidth pool types (subpool versus global pool)
and different priorities is not supported. Specifically,
• With the Path Option for Bandwidth Override feature, you need to configure bandwidth for path
options with the same bandwidth pool as configured for the tunnel.
• With the LSP Attribute List feature, you need to configure both a bandwidth pool and priority for
path options that are consistent with the bandwidth pool and priority configured on the tunnel or in
other path options used by the tunnel.
Information About MPLS Traffic Engineering—LSP Attributes

To configure the MPLS Traffic Engineering—LSP Attributes feature, you need the following
information:
• MPLS Traffic Engineering—LSP Attributes Benefits, page 2
• Traffic Engineering Bandwidth and Bandwidth Pools, page 3
• LSP Attribute Lists Usage and Management, page 3
• Autobandwidth and Path Option for Bandwidth Override, page 4
• Path Option Selection for MPLS TE Tunnel LSPs, page 5
MPLS Traffic Engineering—LSP Attributes Benefits

The MPLS Traffic Engineering—LSP Attributes provides an LSP Attribute List feature and a Path
Option for Bandwidth Override feature. These features have the following benefits:
• The LSP Attributes List feature provides the ability to configure values for several LSP-specific path
options for TE tunnels.
• One or more TE tunnels can specify specific path options by referencing an LSP attribute list.
2
• LSP attribute lists make the MPLS TE user interface more flexible, easier to use, and easier to extend
and maintain.
• The Path Option for Bandwidth Override feature provides a single command that allows a TE tunnel
to fall back temporarily to path options that can reduce bandwidth constraints.
Traffic Engineering Bandwidth and Bandwidth Pools

MPLS traffic engineering allows constraint-based routing (CBR) of IP traffic. One of the constraints
satisfied by CBR is the availability of required bandwidth over a selected path. Regular TE tunnel
bandwidth is called the global pool. Subpool bandwidth is a portion of the global pool. Subpool
bandwidth is not reserved from the global pool if it is not in use. Therefore, subpool tunnels require a
higher priority than nonsubpool tunnels.
You can configure the LSP Attributes bandwidth path option to use either global pool (default) or
subpool bandwidth. The bandwidth value for the path option may be any valid value and the pool does
not have to be the same as that configured on the tunnel.
Note When you configure bandwidth for path options with the bandwidth [sub-pool | global] kbps command,
use either all subpool bandwidths or all global-pool bandwidths.
You can configure bandwidth on both dynamic and explicit path options using either the LSP Attribute
List feature or the Path Option for Bandwidth Override feature. The commands that enable these features
are exclusive of each other. If bandwidth is the only LSP attribute that you need to set on the path option,
then use the command to enable the Path Option for Bandwidth Override feature. This is the simplest
way to configure multiple path options with decreasing bandwidth constraints. Once the bandwidth
keyword is entered on the tunnel mpls traffic-eng path-option command in interface configuration
mode, you cannot configure an LSP attribute list for that path option.
LSP Attribute Lists Usage and Management

This section contains the following topics about LSP attribute lists usage and management:
• Tunnel Attributes and LSP Attributes, page 3
• LSP Attributes and the LSP Attribute List, page 4
• LSP Attribute Lists Management, page 4
Tunnel Attributes and LSP Attributes

Cisco IOS XE tunneling interfaces have many parameters associated with MPLS TE. Typically, you
configure these parameters with tunnel mpls traffic-eng commands in interface configuration mode.
Many of these commands determine tunnel-specific properties, such as the load-sharing factor for the
tunnel. These commands configure parameters that are unrelated to the particular LSP in use by the
tunnel. However, some of the tunneling parameters apply to the LSP that the tunnel uses. You can
configure the LSP-specific properties using an LSP attribute list.
3
LSP Attributes and the LSP Attribute List

An LSP attribute list can contain values for each LSP-specific parameter that is configurable for a
TE tunnel. You configure an LSP attribute list with the mpls traffic-eng lsp attributes string command,
where string identifies the attribute list. The LSP attributes that you can specify include the following:
• Attribute flags for links that make up the LSP (affinity command)
• Automatic bandwidth configuration (auto-bw command)
• LSP bandwidth—global pool or subpool (bandwidth command)
• Disable reoptimization of the LSP (lockdown command)
• LSP priority (priority command)
• Protection failure (protection command)
• Record the route used by the LSP (record-route command)
LSP Attribute Lists Management

The MPLS Traffic Engineering—LSP Attributes feature also provides commands that help you manage
LSP attribute lists. You can do the following:
• Relist all attribute list entries (list command)
• Remove a specific attribute from the list (no attribute command)
The exit command exits from the LSP attributes configuration submode and returns you to global
configuration mode.
Based on your requirements, you can configure LSP attributes lists with different sets of attributes for
different path options. LSP attribute lists also provide an easy way to configure multiple TE tunnels to
use the same LSP attributes. That is, you can reference the same LSP attribute list to configure
LSP-specific parameters for one or more TE tunnels.
Autobandwidth and Path Option for Bandwidth Override

If Traffic Engineering automatic bandwidth (autobandwidth) adjustment is configured for a tunnel,
traffic engineering automatically adjusts the bandwidth allocation for the traffic engineering tunnel
based on its measured usage of the bandwidth of the tunnel.
Traffic engineering autobandwidth samples the average output rate for each tunnel marked for automatic
bandwidth adjustment. For each marked tunnel, it periodically adjusts the allocated bandwidth for the
tunnel to be the largest sample for the tunnel since the last adjustment. The default reoptimization setting
in the MPLS AutoBandwidth feature is every 24 hours
The frequency with which tunnel bandwidth is adjusted and the allowable range of adjustments is
configurable on a per-tunnel basis. In addition, the sampling interval and the interval over which to
average tunnel traffic to obtain the average output rate is user-configurable on a per-tunnel basis.
The Path Option for Bandwidth Override feature allows you to override the bandwidth configured on a
TE tunnel. This feature also overrides bandwidth configured or recalculated by automatic bandwidth
adjustment if the path option in effect has bandwidth override enabled.
4
Path Option Selection for MPLS TE Tunnel LSPs

This section contains the following topics about path option selection for MPLS TE Tunnel LSPs:
• Constraint-Based Routing and Path Option Selection, page 5
• Tunnel Reoptimization and Path Option Selection, page 5
• Path Option Selection with Bandwidth Override, page 6
Constraint-Based Routing and Path Option Selection

MPLS traffic engineering automatically establishes and maintains LSPs across the backbone by using
the Resource Reservation Protocol (RSVP). The path that an LSP uses is determined by the LSP resource
requirements and network resources, such as bandwidth. Traffic engineering tunnels are calculated at the
LSP head based on a fit between required and available resources (constraint-based routing).
Without the Path Option for Bandwidth Override feature, a TE tunnel establishes an LSP based on
dynamic or explicit path options in order of preference. However, the bandwidth and other attributes
configured on the TE tunnel allow the setup of an LSP only if LSP path options satisfy the constraints.
If a path cannot be found that satisfies the configured path options, then the tunnel is not set up.
The Path Option for Bandwidth Override feature provides a fallback path option that allows overriding
the bandwidth configured on the TE tunnel interface. For example, you can configure a path option that
sets the bandwidth to zero (0) effectively removing the bandwidth constraint imposed by the
constraint-based routing calculation.
Tunnel Reoptimization and Path Option Selection

Reoptimization occurs when a device with traffic engineering tunnels periodically examines tunnels with
established LSPs to learn if better LSPs are available. If a better LSP seems to be available, the device
attempts to signal the better LSP. If the signaling is successful, the device replaces the older LSP with
the new, better LSP.
Reoptimization can be triggered by a timer, the issuance of an mpls traffic-eng reoptimize command,
or a configuration change that requires the resignalling of a tunnel. The MPLS AutoBandwidth feature,
for example, uses a timer to set the frequency of reoptimization based on the bandwidth path option
attribute. The Path Option for Bandwidth Override feature allows for the switching between bandwidth
configured on the TE tunnel interface and bandwidth configured on a specific path option. This increases
the success of signaling an LSP for the TE tunnel.
With bandwidth override configured on a path option, the traffic engineering software attempts to
reoptimize the bandwidth every 30 seconds to reestablish the bandwidth configured on the tunnel (see
the “Configuring a Path Option for Bandwidth Override” section on page 26).
You can disable reoptimization of an LSP with the lockdown command in an LSP attribute list. You can
apply the LSP attribute list containing the lockdown command to a path option with the tunnel mpls
traffic-eng path-option command.
Note When you configure bandwidth for path options with the bandwidth [sub-pool | global] kpbs command,
use either all subpool bandwidths or all global-pool bandwidths. Do not mix subpool and nonsubpool
bandwidths, otherwise the path option does not reoptimize later.
5
How to Configure MPLS Traffic Engineering—LSP Attributes
Path Option Selection with Bandwidth Override

The Path Option for Bandwidth Override feature allows you to configure bandwidth parameters on a
specific path option with the bandwidth keyword on the tunnel mpls traffic-eng path-option
command. When an LSP is signaled using a path option with a configured bandwidth, the bandwidth
associated with the path option is signaled instead of the bandwidth configured directly on the tunnel.
This feature provides you with the ability to configure multiple path options that reduce the bandwidth
constraint each time the headend of a tunnel fails to establish an LSP.
The following configuration shows three tunnel mpls traffic-eng path-option commands:
tunnel mpls traffic-eng path-option 1 explicit name path1
tunnel mpls traffic-eng path-option 2 explicit name path2 bandwidth 500
tunnel mpls traffic-eng path-option 3 dynamic bandwidth 0
The device selects a path option for an LSP in order of preference, as follows:
• The device attempts to signal an LSP using path options starting with path option 1.
The device attempts to signal an LSP with the 1000 kbps bandwidth configured on the tunnel
interface because path-option 1 has no bandwidth configured.
• If 1000 kbps bandwidth is not available over the network, the device attempts to establish an LSP
using path-option 2.
Path option 2 has a bandwidth of 500 kbps configured. This reduces the bandwidth constraint from
the original 1000 kbps configured on the tunnel interface.
• If 500 kbps is not available, the device attempts to establish an LSP using path-option 3.
Path-option 3 is configured as dynamic and has bandwidth 0. The device establishes the LSP if an
IP path exists to the destination and all other tunnel constraints are met.

This section contains the following processes for configuring the MPLS Traffic Engineering—LSP
Attributes feature:
• Configuring MPLS Traffic Engineering LSP Attribute Lists, page 6
• Configuring a Path Option for Bandwidth Override, page 26
Configuring MPLS Traffic Engineering LSP Attribute Lists

Perform the following tasks to configure and verify MPLS traffic engineering LSP attributes lists:
• Configuring an LSP Attribute List, page 7 (required)
• Adding Attributes to an LSP Attribute List, page 9 (optional)
• Removing an Attribute from an LSP Attribute List, page 11 (optional)
• Modifying an Attribute in an LSP Attribute List, page 12 (optional)
• Deleting an LSP Attribute List, page 14 (optional)
• Verifying Attributes Within an LSP Attribute List, page 15 (optional)
• Verifying All LSP Attribute Lists, page 16 (optional)
6
• Associating an LSP Attribute List with a Path Option for an MPLS TE Tunnel, page 17 (required)
• Modifying a Path Option to Use a Different LSP Attribute List, page 21 (optional)
• Removing a Path Option for an LSP for an MPLS TE Tunnel, page 23 (optional)
• Verifying that LSP Is Signaled Using the Correct Attributes, page 25 (optional)
Configuring an LSP Attribute List

Perform this task to configure a label switched path (LSP) attribute list with the desired attributes to be
applied on a path option. Based on your requirements, you can configure LSP attributes lists with
different sets of attributes for different path options. The LSP attribute list provides a user interface that
is flexible, easy to use, and easy to extend and maintain for the configuration of MPLS TE tunnel path
options.
LSP attribute lists also provide an easy way to configure multiple TE tunnels to use the same LSP
attributes. That is, you can reference the same LSP attribute list to configure LSP-specific parameters
for one or more TE tunnels.
SUMMARY STEPS
1. enable
3. mpls traffic-eng lsp attributes string
4. affinity value [mask value]
5. auto-bw [frequency secs] [max-bw kbps] [min-bw kbps] [collect-bw]
6. bandwidth [sub-pool | global] kbps
7. list
8. lockdown
9. priority setup-priority [hold-priority]
10. protection fast-reroute
11. record-route
12. no sub-command
13. exit
14. end
DETAILED STEPS

Example:
Router> enable
Example:
7

Step 3 mpls traffic-eng lsp attributes string Configures an LSP attribute list and enters LSP Attributes
configuration mode.
Example: • The string argument identifies a specific LSP attribute
Router(config)# mpls traffic-eng lsp attributes list.
1
Step 4 affinity value [mask value] (Optional) Specifies attribute flags for links comprising an
LSP.
Example: • The value argument is a value required for links that
Router(config-lsp-attr)# affinity 0 mask 0 make up an LSP. Values of the bits are either 0 or 1.
• The mask value keyword argument combination
indicates which attribute values should be checked.
– If a bit in the mask is 0, an attribute value of the
link or that bit is irrelevant.
– If a bit in the mask is 1, the attribute value of that
link and the required affinity of the LSP for that bit
must match.
Step 5 auto-bw [frequency secs] [max-bw kbps] (Optional) Specifies automatic bandwidth configuration.
[min-bw kbps] [collect-bw]
• The frequency secs keyword argument combination
specifies the interval between bandwidth adjustments.
Example: The specified interval can be from 300 to
Router(config-lsp-attr)# auto-bw 604800 seconds.
• The max-bw kbps keyword argument combination
specifies the maximum automatic bandwidth, in kbps,
for this path option. The value can be from 0 to
4294967295.
• The min-bw kpbs keyword argument combination
specifies the minimum automatic bandwidth, in kbps,
for this path option. The value can be from 0 to
4294967295.
• The collect-bw keyword collects output rate
information for the path option, but does not adjust the
bandwidth of the path option.
Step 6 bandwidth [sub-pool | global] kbps (Optional) Specifies LSP bandwidth.
• The sub-pool keyword indicates a subpool path option.
Example: • The global keyword indicates a global pool path
Router(config-lsp-attr)# bandwidth 5000
option. Entering this keyword is not necessary, for all
path options are from the global pool in the absence of
the sub-pool keyword.
• The kbps argument is the number of kilobits per second
set aside for the path option. The range is from 1 to
4294967295.
Step 7 list (Optional) Displays the contents of the LSP attribute list.
Example:
Router(config-lsp-attr)# list
8

Step 8 lockdown (Optional) Disables reoptimization of the LSP.
Example:
Router(config-lsp-attr)# lockdown
Step 9 priority setup-priority [hold-priority] (Optional) Specifies the LSP priority.
• The setup-priority argument is used when signaling an
Example: LSP to determine which existing LSPs can be
Router(config-lsp-attr)# priority 1 1 preempted. Valid values are from 0 to 7, where a lower
number indicates a higher priority. Therefore, an LSP
with a setup priority of 0 can preempt any LSP with a
non-0 priority.
• The hold-priority argument is associated with an LSP
to determine if it should be preempted by other LSPs
that are being signaled. Valid values are from 0 to 7,
where a lower number indicates a higher priority.
Step 10 protection fast-reroute (Optional) Enables failure protection on the LSP.
Example:
Router(config-lsp-attr)# protection
fast-reroute
Step 11 record-route (Optional) Records the route used by the LSP.
Example:
Router(config-lsp-attr)# record-route
Step 12 no sub-command (Optional) Removes a specific attribute from the LSP
attributes list.
Example: • The sub-command argument names the LSP attribute to
Router(config-lsp-attr)# no record-route remove from the attributes list.
Step 13 exit (Optional) Exits from LSP Attributes configuration mode.
Example:
Router(config-lsp-attr)# exit
Step 14 end (Optional) Exits to privileged EXEC mode.
Example:
Router(config)# end
Adding Attributes to an LSP Attribute List

Perform this task to add attributes to an LSP attribute list. The LSP attribute list provides a user interface
that is flexible, easy to use, and that can be extended or changed at any time to meet the requirements of
your MPLS TE tunnel traffic. LSP Attributes configuration mode is used to display the specific LSP
attributes list and to add or change the required path option attribute.
9
SUMMARY STEPS
1. enable
5. bandwidth [sub-pool | global] kbps
6. priority setup-priority [hold-priority]
7. list
8. exit
9. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
1
Step 4 affinity value [mask value] (Optional) Specifies attribute flags for links comprising an
LSP.
Example: • The value argument is a value required for links that
Router(config-lsp-attr)# affinity 0 mask 0 make up an LSP. Values of the bits are either 0 or 1.
link and the required affinity of the LSP for that bit
must match.
10

Step 5 bandwidth [sub-pool | global] kbps Specifies an LSP bandwidth.
Example: • The global keyword indicates a global pool path
4294967295.
Step 6 priority setup-priority [hold-priority] Specifies the LSP priority.
• The setup-priority argument is used when signaling an
Example: LSP to determine which existing LSPs can be
Router(config-lsp-attr)# priority 2 2 preempted. Valid values are from 0 to 7, where a lower
number indicates a higher priority. Therefore, an LSP
with a setup priority of 0 can preempt any LSP with a
non-0 priority.
• The hold-priority argument is associated with an LSP
to determine if it should be preempted by other LSPs
that are being signaled. Valid values are from 0 to 7,
where a lower number indicates a higher priority.
• Use the list command to display the path option
Example: attributes added to the attribute list.
Step 8 exit (Optional) Exits LSP Attributes configuration mode.
Example:
Example:
Router(config)# end
Removing an Attribute from an LSP Attribute List

Perform this task to remove an attribute from an LSP attribute list. The LSP attributes list provides a
means to easily remove a path option attribute that is no longer required for your MPLS TE tunnel traffic.
LSP Attributes configuration mode is used to display the specific LSP attribute list and for the
no sub-command command, which is used to remove the specific attribute from the list. Replace the
sub-command argument with the command that you want to remove from the list.
SUMMARY STEPS
1. enable
11

4. no sub-command
5. list
6. exit
7. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
1
Step 4 no sub-command Removes a specific attribute from the LSP attribute list.
• The sub-command argument names the LSP attribute to
Example: remove from the attributes list.
Router(config-lsp-attr)# no priority
• Use the list command to verify that the path option
Example: attribute is removed from the attribute list.
Example:
Example:
Router(config)# end
Modifying an Attribute in an LSP Attribute List

Perform this task to modify an attribute in an LSP attribute list. The LSP attribute list provides a flexible
user interface that can be extended or modified an any time to meet the requirements of your MPLS TE
tunnel traffic. LSP Attributes configuration mode is used to display the specific LSP attributes list and
to modify the required path option attribute.
12
SUMMARY STEPS
1. enable
5. list
7. list
8. exit
9. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
1
Step 4 affinity value [mask value] Specifies attribute flags for links comprising an LSP.
• The value argument is a value required for links
Example: comprising an LSP. Values of bits are either 0 or 1.
Router(config-lsp-attr)# affinity 1 mask 1
link and the required affinity of the tunnel for that
bit must match.
• Use the list command to display the path option
Example: attributes configured in the attribute list.
13

Step 6 affinity value [mask value] Specifies attribute flags for links comprising an LSP.
• The value argument is a value required for links
Example: comprising an LSP. Values of bits are either 0 or 1.
Router(config-lsp-attr)# affinity 0 mask 0
link and the required affinity of the tunnel for that
bit must match.
• Use the list command to verify that the path option
Example: attributes is modified in the attribute list.
Example:
Example:
Router(config)# end
Deleting an LSP Attribute List

Perform this task to delete an LSP attribute list. You would perform this task when you no longer require
the LSP attribute path options specified in the LSP attribute list for an MPLS TE tunnel.
SUMMARY STEPS
1. enable
3. no mpls traffic-eng lsp attributes string
4. end
5. show mpls traffic-eng lsp attributes [string]
14
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 no mpls traffic-eng lsp attributes string Removes a specified LSP attribute list from the device
configuration.
Example: • The string argument identifies the specific LSP
Router(config)# no mpls traffic-eng lsp attribute list to remove.
attributes 1
Example:
Router(config)# end
Step 5 show mpls traffic-eng lsp attributes [string] (Optional) Displays information about configured LSP
attribute lists.
Example: • Use the show mpls traffic-eng lsp attributes
Router# show mpls traffic-eng lsp attributes command to verify that the LSP attribute list was
deleted from the router.
Verifying Attributes Within an LSP Attribute List

Perform this task to verify attributes within an LSP attribute list.
SUMMARY STEPS
1. enable
3. mpls traffic-eng lsp attributes string list
4. exit
5. end
DETAILED STEPS
Step 1 enable
Router> enable
Router#
15
Step 2 configure terminal

Use this command to enter global configuration mode. For example:
Router(config)#
Step 3 mpls traffic-eng lsp attributes string list

Use this command to enter LSP Attributes configuration mode for a specific LSP attribute list and to
verify that the contents of the attributes list are as expected. For example:
Router(config)# mpls traffic-eng lsp attributes 1 list
LIST 1
bandwidth 1000
priority 1 1
Step 4 exit
Use this command to exit LSP Attributes configuration mode. For example:
Router(config)#
Step 5 end
Use this command to exit to privileged EXEC mode. For example:
Router#
Verifying All LSP Attribute Lists

Perform this task to verify all configured LSP attribute lists. Use this task to display all LSP attribute
lists to verify that the attributes lists that you configured are in operation.
SUMMARY STEPS
1. enable
2. show mpls traffic-eng lsp attributes [string] [details]
3. show running-config | begin text-string
4. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls traffic-eng lsp attributes [string] [details]

Use this command to verify that all configured LSP attribute lists are as expected. For example:
Router# show mpls traffic-eng lsp attributes
16
LIST 1
affinity 1 mask 1
bandwidth 1000
priority 1 1
LIST 2
bandwidth 5000
LIST hipriority
priority 0 0
!
Step 3 show running-config | begin text-string

Use this command to verify that all configured LSP attribute lists are as expected. Use the begin
command modifier with the mpls traffic-eng lsp text-string to locate the LSP attributes information in
the configuration file. For example:
Router# show running-config | begin mpls traffic-eng lsp
mpls traffic-eng lsp attributes 1

affinity 1 mask 1
bandwidth 1000
priority 1 1
!
mpls traffic-eng lsp attributes 2
bandwidth 5000
!
mpls traffic-eng lsp attributes hipriority
priority 0 0
.
.
.
Router#
Step 4 exit
Router# exit
Router>
Associating an LSP Attribute List with a Path Option for an MPLS TE Tunnel
Perform this task to associate an LSP attribute list with a path option for an MPLS TE tunnel. This task
is required if you want to apply the LSP attribute list that you configured to path options for your MPLS
TE tunnels.
different path options. LSP attribute lists also provide an easy way to configure multiple TE tunnels to
use the same LSP attributes. That is, you can reference the same LSP attribute list to configure
LSP-specific parameters for one or more TE tunnels.
Default Path Option Attributes for TE Tunnels Using LSP Attribute Lists
Values for path option attributes for a TE tunnel are determined in this manner:
• LSP attribute list values referenced by the path option take precedence over the values configured
on the tunnel interface.
17
• If an attribute is not specified in the LSP attribute list, the device uses the attribute in the tunnel
configuration. LSP attribute lists do not have defaults.
• If the attribute is not configured on the tunnel, then the device uses the tunnel default value, as
follows:
{affinity= affinity 0 mask 0,
auto-bw= no auto-bw,
bandwidth= bandwidth 0,
lockdown= no lockdown,
priority= priority 7 7,
protection fast-reroute= no protection fast-reroute,
record-route= no record-route
.
.
.
}
SUMMARY STEPS
1. enable
4. tunnel destination {hostname | ip-address}
7. tunnel mpls traffic-eng bandwidth [sub-pool | global] kbps
8. tunnel mpls traffic-eng priority setup-priority [hold-priority]
9. tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name |
path-number} [verbatim]} [attributes string] [bandwidth [sub-pool | global] kbps] [lockdown]
10. end
DETAILED STEPS

Example:
Router> enable
Example:
18

configuration mode.
Example: • The type argument is the type of interface that you want
Router(config)# interface tunnel 1 to configure.
• The number argument is the number of the tunnel
interface that you want to create or configure.
Step 4 tunnel destination {hostname | ip-address} Specifies the destination of the tunnel for this path option.
• The hostname argument is the name of the host
Example: destination.
10.10.10.12
• The ip-address argument is the IP address of the host
destination expressed in decimal in four-part, dotted
notation.
Step 5 tunnel mode mpls traffic-eng Sets the encapsulation mode for the tunnel for MPLS TE.
Example:
Step 6 tunnel mpls traffic-eng autoroute announce Specifies that the IGP should use the tunnel (if the tunnel is
up) in its enhanced shortest path first (SPF) calculation.
Example:
autoroute announce
Step 7 tunnel mpls traffic-eng bandwidth [sub-pool | Configures the bandwidth required for an MPLS TE tunnel
global] bandwidth and assigns it either to the subpool or the global pool.
• The sub-pool keyword indicates a subpool tunnel.
Example:
• The global keyword indicates a global pool tunnel.
bandwidth 1000 Entering this keyword is not necessary, for all tunnels
are in the global pool in the absence of the sub-pool
keyword.
• The kbps argument is the bandwidth, in kilobits per
second, set aside for the MPLS TE tunnel. The range is
from 1 to 4294967295.
Step 8 tunnel mpls traffic-eng priority setup-priority Sets the priority to be used when the system determines
[hold-priority] which existing tunnels are eligible to be preempted.
• The setup-priority argument is the priority used when
Example: signaling an LSP for this tunnel to determine which
Router(config-if)# tunnel mpls traffic-eng existing tunnels can be preempted.
priority 1 1
Valid values are from 0 to 7. A lower number indicates
a higher priority. An LSP with a setup priority of 0 can
preempt any LSP with a non-0 priority.
• The hold-priority argument is the priority associated
with an LSP for this tunnel to determine if it should be
preempted by other LSPs that are being signaled.
Valid values are from 0 to 7, where a lower number
indicates a higher priority.
19

Step 9 tunnel mpls traffic-eng path-option number Adds an LSP attribute list to specify LSP-related
{dynamic | explicit {name path-name | parameters for a path options for an MPLS TE tunnel.
path-number} [verbatim]} [attributes string]
[bandwidth [sub-pool | global] kbps] [lockdown] • The number argument identifies the path option.
• The dynamic keyword indicates that the path option is
Example: dynamically calculated (the router figures out the best
Router(config-if)# tunnel mpls traffic-eng path).
path-option 1 dynamic attributes 1
• The explicit keyword indicates that the path option is
specified. You specify the IP addresses of the path.
• The name path-name keyword argument combination
identifies the name of the explicit path option.
• The path-number argument identifies the number of the
explicit path option.
• The verbatim keyword bypasses the topology database
verification.
Note You can use the verbatim keyword only with the
• The attributes string keyword argument combination

names an attribute list to specify path options for the
LSP.
• The bandwidth keyword specifies LSP bandwidth.
• The global keyword indicates a global pool path
4294967295.
• The lockdown keyword disables reoptimization of the
LSP.
Example:
20
Modifying a Path Option to Use a Different LSP Attribute List

Perform this task to modify the path option to use a different LSP attribute list.
different path options or change the set of attributes associated with a path option. You use the tunnel
mpls traffic-eng path-option number dynamic attributes string command in interface configuration
mode to modify the path option to use a different LSP attribute list. The attributes string keyword and
argument names the new LSP attribute list for the path option specified.
SUMMARY STEPS
1. enable
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number Configures the interface type and enters interface
configuration mode.
10.10.10.12
notation.
21

Step 5 tunnel mpls traffic-eng path-option number Adds an LSP attribute list to specify LSP-related
{dynamic | explicit {name path-name | parameters for a path options for an MPLS TE tunnel.
Router(config-if)# tunnel mpls traffic-eng path).
verification.

LSP.
4294967295.
LSP.
Example:
22
Removing a Path Option for an LSP for an MPLS TE Tunnel

Perform this task to remove a path option for an LSP for an MPLS TE tunnel. Use this task to remove a
path option for an LSP when your MPLS TE tunnel traffic requirements change.
SUMMARY STEPS
1. enable
5. no tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name |
6. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
10.10.10.12
notation.
23

Step 5 no tunnel mpls traffic-eng path-option number Removes an LSP attribute list that specifies LSP-related
{dynamic | explicit {name path-name | parameters for a path option for an MPLS TE tunnel.
Router(config-if)# no tunnel mpls traffic-eng path).
verification.

LSP.
4294967295.
LSP.
Example:
24
Verifying that LSP Is Signaled Using the Correct Attributes

Perform this task to verify that the LSP is signaled using the correct attributes.
SUMMARY STEPS
1. enable
2. show mpls traffic-eng tunnels tunnel-interface [brief]
3. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls traffic-eng tunnels tunnel-interface [brief]

Use this command to verify that the LSP is signaled using the correct attributes for the specified tunnel.
For example:
Router# show mpls traffic-eng tunnels tunnel1
Name: Router-t1 (Tunnel1) Destination: 10.10.10.12

Status:
path option 2, type explicit path2 (Basis for Setup, path weight 65834)
Config Parameters:
Metric Type: IGP (global)
auto-bw: disabled
Active Path Option Parameters:
State: explicit path option 2 is active
BandwidthOverride: enabled LockDown: disabled Verbatim: disabled
Bandwidth Override:
Signalling: 1 kbps (Global)
Overriding: 1000 kbps (Global) configured on tunnel
The output shows that the following attributes are signaled for tunnel tunnel1: affinity 0 mask 0, auto-bw
disabled, bandwidth 1000, lockdown disabled, and priority 1 1.
Step 3 exit
Router# exit
Router>
25
Configuring a Path Option for Bandwidth Override

This section contains the following tasks for configuring a path option for bandwidth override:
• Configuring Fallback Bandwidth Path Options for TE Tunnels, page 26 (required)
• Modifying the Bandwidth on a Path Option for Bandwidth Override, page 29 (optional)
• Removing a Path Option for Bandwidth Override, page 31 (optional)
• Verifying that LSP Is Signaled Using the Correct Bandwidth, page 33 (optional)
Note Once you configure bandwidth as a path-option parameter, you can no longer configure an LSP attribute
list as a path-option parameter.
Configuring Fallback Bandwidth Path Options for TE Tunnels

Perform this task to configure fallback bandwidth path options for a TE tunnel. Use this task to configure
path options that reduce the bandwidth constraint each time the headend of a tunnel fails to establish an
LSP.
Configuration of the Path Option for Bandwidth Override feature can reduce bandwidth constraints on
path options temporarily and improve the chances that an LSP is set up for the TE tunnel. When a TE
tunnel uses a path option with bandwidth override, the traffic engineering software attempts every
30 seconds to reoptimize the tunnel to use the preferred path option with the original configured
bandwidth. The Path Option for Bandwidth Override feature is designed as a temporary reduction in
bandwidth constraint. To force immediate reoptimization of all traffic engineering tunnels, you can use
the mpls traffic-eng reoptimize command. You can also configure the lockdown command with
bandwidth override to prevent automatic reoptimization.
SUMMARY STEPS
1. enable
5. tunnel mpls traffic-eng path-option number {dynamic | explicit {name path--name |
6. end
26
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
10.10.10.12
notation.
27

Step 5 tunnel mpls traffic-eng path-option number Adds a path option for bandwidth override to specify a
{dynamic | explicit {name path-name | bandwidth fallback for a path option for an MPLS TE
[bandwidth [sub-pool | global] kbps] [lockdown]
tunnel.
• The number argument identifies the path option.
Example: • The dynamic keyword indicates that the path option is
Router(config-if)# tunnel mpls traffic-eng dynamically calculated (the router figures out the best
path-option 1 dynamic bandwidth 500 path).
verification.

LSP.
4294967295.
LSP.
Example:
28
Modifying the Bandwidth on a Path Option for Bandwidth Override

Perform this task to modify the bandwidth on a path option for bandwidth override. You might need to
further reduce or modify the bandwidth constraint for a path option to ensure that the headend of a tunnel
establishes an LSP.
The Path Option for Bandwidth Override feature is designed as a temporary reduction in bandwidth
constraint. To force immediate reoptimization of all traffic engineering tunnels, you can use the
mpls traffic-eng reoptimize command. You can also configure the lockdown command with bandwidth
override to prevent automatic reoptimization.
SUMMARY STEPS
1. enable
6. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
10.10.10.12
notation.
29

Step 5 tunnel mpls traffic-eng path-option number Adds a path option for bandwidth override to specify a
{dynamic | explicit {name path-name | bandwidth fallback for a path option for an MPLS TE
tunnel.
Router(config-if)# tunnel mpls traffic-eng dynamically calculated (the router figures out the best
verification.

LSP.
4294967295.
LSP.
Example:
Step 7 show mpls traffic-eng tunnels tunnel-interface (Optional) Displays information about tunnels.
[brief]
• Use the show mpls traffic-eng tunnels command to
verify which bandwidth path option is in use by the
Example: LSP.
30
Removing a Path Option for Bandwidth Override

Perform this task to remove the bandwidth on the path option for bandwidth override. The Path Option
for Bandwidth Override feature is designed as a temporary reduction in bandwidth constraint. Use this
task to remove the bandwidth override when it is not required.
SUMMARY STEPS
1. enable
5. no tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name |
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel number Configures a tunnel interface type and enters interface
configuration mode.
Example: • The number argument is the number of the tunnel
Router(config)# interface tunnel 1 interface that you want to create or configure.
10.10.10.12
notation.
31

Step 5 no tunnel mpls traffic-eng path-option number Removes a path option for bandwidth override that specifies
{dynamic | explicit {name path-name | a bandwidth fallback for a path option for an MPLS TE
tunnel.
Router(config-if)# no tunnel mpls traffic-eng dynamically calculated (the router figures out the best
verification.

LSP.
4294967295.
LSP.
Example:
Step 7 show mpls traffic-eng tunnels tunnel-interface (Optional) Displays information about tunnels.
[brief]
• Use the show mpls traffic-eng tunnels command to
verify which bandwidth path option is in use by the
Example: LSP.
32
Verifying that LSP Is Signaled Using the Correct Bandwidth

Perform this task to verify that the LSP is signaled with the correct bandwidth.
SUMMARY STEPS
1. enable
3. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls traffic-eng tunnels tunnel-interface [brief]

Use this command to verify that the LSP is signaled with the correct bandwidth and to verify that the
bandwidth configured on the tunnel is overridden. For example:
Name: Router-t21 (Tunnel21) Destination: 10.10.10.12

Status:
path option 1, type explicit path1
Config Parameters:
Metric Type: IGP (global)
auto-bw: disabled
BandwidthOverride: enabled LockDown: disabled Verbatim: disabled
Bandwidth Override:
Signalling: 500 kbps (Global)
Overriding: 1000 kbps (Global) configured on tunnel
If bandwidth override is actively being signaled, the show mpls traffic-eng tunnel command displays
the bandwidth override information under the Active Path Option Parameters heading. The example
shows that BandwidthOverride is enabled and that the tunnel is signaled using path-option 2. The
bandwidth signaled is 500. This is the value configured on the path option 2 and it overrides the
1000 kbps bandwidth configured on the tunnel interface.
Step 3 exit
Router# exit
Router>
33
Configuration Examples for MPLS Traffic Engineering—LSP Attributes
If the tunnel state is down and you configured a path-option with bandwidth override enabled, the show
mpls traffic-eng tunnels command indicates other reasons why a tunnel is not established. For example:
• The tunnel destination is not in the routing table.
• If the bandwidth override value is not zero, the bandwidth constraint may still be too large.
• Other attributes configured on the tunnel, such as affinity, might prevent the calculation of a path
over the existing topology.
• TE might not be configured on all links necessary to reach tunnel destination.
Configuration Examples for MPLS Traffic Engineering—LSP

Attributes
This section contains the following configuration examples for the MPLS Traffic Engineering—LSP
Attributes features:
• Configuring LSP Attribute List: Examples, page 34
• Configuring a Path Option for Bandwidth Override: Examples, page 37
Configuring LSP Attribute List: Examples

This section contains the following examples for configuring LSP attribute lists:
• Configuring an LSP Attribute List: Example, page 34
• Adding Attributes to an LSP Attribute List: Example, page 35
• Removing an Attribute from an LSP Attribute List: Example, page 35
• Modifying an Attribute in an LSP Attribute List: Example, page 35
• Deleting an LSP Attribute List: Example, page 35
• Associating an LSP Attribute List with a Path Option for a TE Tunnel: Example, page 36
• Modifying a Path Option to Use a Different LSP Attribute List: Example, page 36
• Removing a Path Option for Bandwidth Override: Example, page 39
Configuring an LSP Attribute List: Example

This example shows the configuration of the affinity, bandwidth, and priority LSP-related attributes in
an LSP attribute list identified with the numeral 1:
Router(config)# mpls traffic-eng lsp attributes 1
Router(config-lsp-attr)# affinity 7 7
Router(config-lsp-attr)# priority 1 1
34
Adding Attributes to an LSP Attribute List: Example

This example shows the addition of protection attributes to the LSP attribute list identified with the
numeral 1:
Router(config-lsp-attr)# protection fast-reroute
Removing an Attribute from an LSP Attribute List: Example

The following example shows removing the priority attribute from the LSP attribute list identified by the
string simple:
Router(config)# mpls traffic-eng lsp attributes simple
LIST simple
priority 1 1
!
Router(config-lsp-attr)# no priority
LIST simple
!
Modifying an Attribute in an LSP Attribute List: Example

The following example shows modifying the bandwidth in an LSP attribute list identified by the
numeral 5:
LIST 5
bandwidth 1000
priority 1 1

LIST 5
bandwidth 500
priority 1 1
Deleting an LSP Attribute List: Example

The following example shows the deletion of an LSP attribute list identified by numeral 1:
35

!
Router(config)# no mpls traffic-eng lsp attributes 1
Associating an LSP Attribute List with a Path Option for a TE Tunnel: Example
The following example associates the LSP attribute list identified by the numeral 3 with path option 1:
Router(config-lsp-attr)# protection fast-reroute
!
!
Router(config)# interface Tunnel 1
Router(config-if)# ip unnumbered FastEthernet1/0/1
Router(config-if)# tunnel destination 10.112.0.12
Router(config-if)# tunnel mpls traffic-eng affinity 1
Router(config-if)# tunnel mpls traffic-eng bandwidth 5000
Router(config-if)# tunnel mpls traffic-eng path-option 1 dynamic attributes 3
In this configuration, the LSP will have the following attributes:

{bandwidth = 1000
priority = 2 2
affinity 1
reroute enabled.
}
The LSP attribute list referenced by the path option will take precedence over the values configured on
the tunnel interface.
Modifying a Path Option to Use a Different LSP Attribute List: Example

The following example modifies path option 1 to use an LSP attribute list identified by the numeral 1:


Router(config-if)# tunnel mpls traffic-eng path-option 1 dynamic attributes 1
In this configuration, the LSP will have the following attributes:

{affinity = 7 7
36
bandwidth = 500
priority = 1 1
}
Removing a Path Option for an LSP for an MPLS TE Tunnel: Example

The following example shows the removal of path option 1 for an LSP for a TE tunnel:
Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit path1 attributes 1
Router(config-if)# tunnel mpls traffic-eng path-option 2 explicit path2 attributes 2
!
!
Router(config-if)# no tunnel mpls traffic-eng path-option 1 explicit path1 attributes 1
Configuring a Path Option for Bandwidth Override: Examples

This section contains the following examples for configuring a path option for bandwidth override:
• Path Option for Bandwidth Override and LSP Attribute List Configuration Command Examples,
page 37
• Configuring Fallback Bandwidth Path Options for TE Tunnels: Example, page 38
• Modifying the Bandwidth on a Path Option for Bandwidth Override: Example, page 38
• Removing a Path Option for Bandwidth Override: Example, page 39
Path Option for Bandwidth Override and LSP Attribute List Configuration Command Examples
The following are examples of the Cisco IOS XE command-line interface (CLI) to use when you
configure a path option to override the bandwidth:
Router(config-if)# tunnel mpls traffic-eng path-option 3 explicit name path1 ?
attributes Specify an LSP attribute list

bandwidth override the bandwidth configured on the tunnel
lockdown not a candidate for reoptimization
<cr>
Router(config-if)# tunnel mpls traffic-eng path-option 3 explicit name path1 bandwidth ?
<0-4294967295> bandwidth requirement in kbps

sub-pool tunnel uses sub-pool bandwidth
Router(config-if)# tunnel mpls traffic-eng path-option 3 explicit name path1 bandwidth 500
?
lockdown not a candidate for reoptimization
<cr>
Note Once you configure bandwidth as a path-option parameter, you can no longer configure an LSP attribute
list as a path-option parameter.
37
Configuring Fallback Bandwidth Path Options for TE Tunnels: Example

The following example shows multiple path options configured with the tunnel mpls traffic-eng
path-option command:
interface Tunnel 1
ip unnumbered Loopback0
end
The device selects a path option for an LSP in order of preference, as follows:
• The device attempts to signal an LSP using path options starting with path-option 1.
The device attempts to signal an LSP with the 1000 kbps bandwidth configured on the tunnel
interface because path-option 1 has no bandwidth configured.
• If 1000 kbps bandwidth is not available over the network, the device attempts to establish an LSP
using path-option 2.
Path-option 2 has a bandwidth of 500 kbps configured. This reduces the bandwidth constraint from
the original 1000 kbps configured on the tunnel interface.
• If 500 kbps is not available, the device attempts to establish an LSP using path-option 3.
Path-option 3 is configured as dynamic and has bandwidth 0. The device establishes the LSP if an
IP path exists to the destination and all other tunnel constraints are met.
Modifying the Bandwidth on a Path Option for Bandwidth Override: Example

The following example shows modifying the bandwidth on a path option for bandwidth override.
Path-option 3 is changed to an explicit path with a bandwidth of 100 kbps. Path-option 4 is configured
with bandwidth 0.
interface Tunnel 1
!
!
Router(config)# tunnel mpls traffic-eng path-option 3 explicit name path3 bandwidth 100
Router(config)# tunnel mpls traffic-eng path-option 4 dynamic bandwidth 0
38
Removing a Path Option for Bandwidth Override: Example

The following example shows removing a path option for bandwidth override:
interface Tunnel 1
!
Router(config)# no tunnel mpls traffic-eng path-option 3 explicit name path3 bandwidth 100
The following sections provide references related to the MPLS Traffic Engineering—LSP Attributes
feature.
Related Documents
MPLS TE command descriptions Cisco IOS Multiprotocol Label Switching Command Reference
Standards
Standards Title
MIBs
MIBs MIBs Link
39
RFCs
RFCs Title
Description Link
40
Feature Information for MPLS Traffic Engineering—LSP Attributes
Feature Information for MPLS Traffic Engineering—LSP

Attributes
Table 1 Feature Information for MPLS Traffic Engineering—LSP Attributes

MPLS Traffic Engineering—LSP Attributes Cisco IOS XE This document describes how to configure label switched
Release 2.3 path (LSP) attributes for path options associated with
Multiprotocol Label Switching (MPLS) traffic engineering
(TE) tunnels.
The MPLS Traffic Engineering—LSP Attributes feature is
an extension to MPLS TE that provides an LSP Attribute
List feature and a Path Option for Bandwidth Override
feature. These features provide flexibility in the
configuration of LSP attributes for MPLS TE tunnel path
options. Several LSP attributes can be applied to path
options for TE tunnels using an LSP attribute list. If
bandwidth is the only LSP attribute you require, then you
can configure a path option for bandwidth override.
feature:
• MPLS Traffic Engineering—LSP Attributes Benefits,
page 2
• Traffic Engineering Bandwidth and Bandwidth Pools,
page 3
• LSP Attribute Lists Usage and Management, page 3
• Autobandwidth and Path Option for Bandwidth
Override, page 4
• Path Option Selection for MPLS TE Tunnel LSPs,
page 5
41
Feature Information for MPLS Traffic Engineering—LSP Attributes
Table 1 Feature Information for MPLS Traffic Engineering—LSP Attributes (continued)

• Configuring MPLS Traffic Engineering LSP Attribute
Lists, page 6
• Configuring a Path Option for Bandwidth Override,
page 26
affinity (LSP Attributes), auto-bw (LSP Attributes),
bandwidth (LSP Attributes), exit (LSP Attributes), list
(LSP Attributes), lockdown (LSP Attributes), mpls
traffic-eng lsp attributes, priority (LSP Attributes),
protection (LSP Attributes), record-route (LSP
Attributes), show mpls traffic-eng lsp attributes, and
show mpls traffic-eng tunnels.
42
Glossary
Glossary
bandwidth—The difference between the highest and lowest frequencies available for network signals.
The term also is used to describe the rated throughput capacity of a given network medium or protocol.
The frequency range necessary to convey a signal measured in units of hertz (Hz). For example, voice
signals typically require approximately 7 kHz of bandwidth and data traffic typically requires
approximately 50 kHz of bandwidth.
bandwidth reservation—The process of assigning bandwidth to users and applications served by a
network. This process involves assigning priority to different flows of traffic based on how critical and
delay-sensitive they are. This makes the best use of available bandwidth, and if the network becomes
congested, lower-priority traffic can be dropped. Sometimes called bandwidth allocation
global pool—The total bandwidth allocated to an Multiprotocol Label Switching (MPLS) traffic
engineering link.
label switched path (LSP) tunnel—A configured connection between two routers, using label
switching to carry the packets.
LSR—label switch router. A Multiprotocol Label Switching (MPLS) node that can forward native
Layer 3 packets. The LSR forwards a packet based on the value of a label attached to the packet.
MPLS TE—Multiprotocol Label Switching (MPLS) traffic engineering (formerly known as “RRR” or
Resource Reservation Routing). The use of label switching to improve traffic performance along with an
efficient use of network resources.
subpool—The more restrictive bandwidth in an Multiprotocol Label Switching (MPLS) traffic
engineering link. The subpool is a portion of the link's overall global pool bandwidth.
TE—traffic engineering. The techniques and processes used to cause routed traffic to travel through the
used. The application of scientific principles and technology to measure, model, and control internet
traffic in order to simultaneously optimize traffic performance and network resource utilization.
traffic engineering tunnel—A label-switched tunnel used for traffic engineering. Such a tunnel is set
up through means other than normal Layer 3 routing; it is used to direct traffic over a path different from
the one that Layer 3 routing could cause the tunnel to take.
tunnel—A secure communication path between two peers, such as two routers.
countries.
coincidental.
43
Glossary
44
MPLS Traffic Engineering—Verbatim Path
Support

The MPLS Traffic Engineering—Verbatim Path Support feature allows network nodes to support
Resource Reservation Protocol (RSVP) extensions without supporting Interior Gateway Protocol (IGP)
extensions for traffic engineering (TE), thereby bypassing the topology database verification process.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering—Verbatim Path
Support” section on page 9.
Contents
• Prerequisites for MPLS Traffic Engineering—Verbatim Path Support, page 2
• Restrictions for MPLS Traffic Engineering—Verbatim Path Support, page 2
• Information About MPLS Traffic Engineering—Verbatim Path Support, page 2
• How to Configure and Verify MPLS Traffic Engineering—Verbatim Path Support, page 2
• Configuration Example for MPLS Traffic Engineering—Verbatim Path Support, page 6
• Feature Information for MPLS Traffic Engineering—Verbatim Path Support, page 9
MPLS Traffic Engineering—Verbatim Path Support
Prerequisites for MPLS Traffic Engineering—Verbatim Path Support
Prerequisites for MPLS Traffic Engineering—Verbatim Path

Support
• A Multiprotocol Label Switching (MPLS) TE tunnel must be configured globally.
• MPLS TE must be enabled on all links.
Restrictions for MPLS Traffic Engineering—Verbatim Path

Support
• The verbatim keyword can be used only on a label-switched path (LSP) that is configured with the
• This release does not support reoptimization on the verbatim LSP.
Information About MPLS Traffic Engineering—Verbatim Path

Support
You should underrating the following concept be for configuring the MPLS Traffic
Engineering—Verbatim Path support feature:
• MPLS TE Verbatim Path Support Overview, page 2
MPLS TE Verbatim Path Support Overview

MPLS TE LSPs usually require that all the nodes in the network are TE aware, meaning they have IGP
extensions to TE in place. However, some network administrators want the ability to build TE LSPs to
traverse nodes that do not support IGP extensions to TE, but that do support RSVP extensions to TE.
Verbatim LSPs are helpful when all or some of the intermediate nodes in a network do not support IGP
extensions for TE.
When this feature is enabled, the IP explicit path is not checked against the TE topology database.
Because the TE topology database is not verified, a Path message with IP explicit path information is
routed using the shortest path first (SPF) algorithm for IP routing.
How to Configure and Verify MPLS Traffic

Engineering—Verbatim Path Support
• Configuring MPLS Traffic Engineering—Verbatim Path Support, page 3 (required)
• Verifying Verbatim LSPs for MPLS TE Tunnels, page 6 (optional)
2
How to Configure and Verify MPLS Traffic Engineering—Verbatim Path Support
Configuring MPLS Traffic Engineering—Verbatim Path Support

Perform this task to configure MPLS traffic engineering—verbatim path support.
SUMMARY STEPS
1. enable
4. ip unnumbered loopback number
5. tunnel destination {host-name | ip-address}
7. tunnel mpls traffic-eng bandwidth {sub-pool kbps | kbps}
9. tunnel mpls traffic-eng priority setup-priority [hold-priority]
10. tunnel mpls traffic-eng path-option preference-number {dynamic [attributes string | bandwidth
{sub-pool kbps | kbps} | lockdown | verbatim] | explicit {name path-name | identifier
path-number}}
11. exit
12. exit
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example: • The number argument identifies the tunnel number to
Router(config)# interface tunnel 1 be configured.
Step 4 ip unnumbered loopback number Configures an unnumbered IP interface, which enables IP
processing without an explicit address. A loopback
interface is usually configured with the router ID.
Example:
Router(config-if)# ip unnumbered loopback 1 Note An MPLS traffic engineering tunnel interface
should be unnumbered because it represents a
unidirectional link.
3

Step 5 tunnel destination {host-name | ip-address} Specifies the destination for a tunnel.
• The host-name argument is the name of the host
10.100.100.100
• The ip-address argument is the IP Version 4 address of
the host destination expressed in decimal in four-part,
dotted notation.
engineering.
Example:
Step 7 tunnel mpls traffic-eng bandwidth Configures the bandwidth required for an MPLS TE tunnel
{sub-pool kbps | kbps} and assigns it either to the sub-pool or the global pool.
• The sub-pool keyword indicates a subpool tunnel.
Example:
• The kbps argument is the bandwidth, in kilobits per
bandwidth 1000 second, set aside for the MPLS TE tunnel. The range is
from 1 to 4294967295.
Step 8 tunnel mpls traffic-eng autoroute announce Specifies that IGP should use the tunnel (if the tunnel is up)
in its enhanced SPF calculation.
Example:
autoroute announce
Step 9 tunnel mpls traffic-eng priority setup-priority Configures setup and reservation priority for a tunnel.
[hold-priority]
• The setup-priority argument is the priority used when
signaling an LSP for this tunnel to determine which
Example: existing tunnels can be preempted.
priority 1 1 Valid values are from 0 to 7. A lower number indicates
a higher priority. An LSP with a setup priority of 0 can
preempt any LSP with a non-0 priority.
• The hold-priority argument is the priority associated
with an LSP for this tunnel to determine if it should be
preempted by other LSPs that are being signaled.
Valid values are from 0 to 7, where a lower number
indicates a higher priority.
4

Step 10 tunnel mpls traffic-eng path-option Specifies LSP-related parameters, including the verbatim
preference-number {dynamic [attributes string | keyword used with an explicit path option, for an MPLS TE
bandwidth {sub-pool kbps | kbps} | lockdown |
verbatim] | explicit {name path-name |
tunnel.
identifier path-number}} • The preference-number argument identifies the path
option.
Example: • The protect keyword and preference-number argument
Router(config-if)# tunnel mpls traffic-eng identify the path option with protection.
path-option 1 explicit name test verbatim
dynamically calculated. (The router figures out the best
path.)
specified. The IP addresses are specified for the path.
verification.

LSP.
• The bandwidth keyword specifies the LSP bandwidth.
4294967295.
LSP.
configuration mode.
Example:
EXEC mode.
Example:
5
Configuration Example for MPLS Traffic Engineering—Verbatim Path Support
Verifying Verbatim LSPs for MPLS TE Tunnels

Perform this task to verify that the verbatim option is configured for the LSPs for MPLS TE tunnels.
SUMMARY STEPS
1. enable
3. disable
DETAILED STEPS

Example:
Router> enable
Step 2 show mpls traffic-eng tunnels tunnel-interface Displays information about tunnels including those
[brief] configured with an explicit path option using verbatim.
Example:
Step 3 disable (Optional) Exits to user EXEC mode.
Example:
Router# disable
Configuration Example for MPLS Traffic Engineering—Verbatim

Path Support
This section provides the following configuration example:
• Configuring MPLS Traffic Engineering—Verbatim Path Support: Example, page 6
Configuring MPLS Traffic Engineering—Verbatim Path Support: Example

The following example shows a tunnel that has been configured with an explicit path option using
verbatim:
interface tunnel 1
tunnel mpls traffic-eng path-option 1 explicit name path1 verbatim
6
The following sections provide references related to the MPLS Traffic Engineering—Verbatim Path
feature.
Related Documents
Interface commands Cisco IOS Interface and Hardware Component Command Reference
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
release.
7
Description Link
8
Feature Information for MPLS Traffic Engineering—Verbatim Path Support
Feature Information for MPLS Traffic Engineering—Verbatim

Path Support
Table 1 Feature Information for MPLS Traffic Engineering—Verbatim Path Support

MPLS Traffic Engineering—Verbatim Path Cisco IOS XE The MPLS Traffic Engineering—Verbatim Path Support
Support Release 2.3 feature allows network nodes to support Resource
Reservation Protocol (RSVP) extensions without
supporting Interior Gateway Protocol (IGP) extensions for
traffic engineering (TE), thereby bypassing the topology
database verification process.
This feature was integrated into Cisco IOS XE Release 2.3.
feature:
• Configuring MPLS Traffic Engineering—Verbatim
Path Support, page 3
• Verifying Verbatim LSPs for MPLS TE Tunnels, page 6
show mpls traffic-eng tunnels, tunnel mpls traffic-eng
path option.
9
Glossary
Glossary
Fast Reroute—Procedures that enable temporary routing around a failed link or node while a new
label-switched path (LSP) is being established at the head end.
headend—The router that originates and maintains a given label-switched path (LSP). This is the first
router in the LSP’s path.
IGP—Interior Gateway Protocol. Internet protocol used to exchange routing information within an
(IGRP), Open Shortest Path First (OSPF), and Routing Information protocol (RIP).
LSP—label-switched path. A configured connection between two routers, in which label switching is
used to carry the packets. The purpose of an LSP is to carry data packets.
LSR—label switching router. A device that forwards Multiprotocol Label Switching (MPLS) packets
based on the value of a fixed-length label encapsulated in each packet.
merge point—The backup tunnel’s tail.
MPLS—Multiprotocol Label Switching. A method for forwarding packets (frames) through a network.
It enables routers at the edge of a network to apply labels to packets (frames). ATM switches or existing
routers in the network core can switch packets according to the labels with minimal lookup overhead.
PLR—point of local repair. The head-end of the backup tunnel.
IP network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature
(bandwidth, jitter, maximum burst, and so on) of the packet streams they want to receive.
SPF—shortest path first. Routing algorithm that iterates on length of path to determine a shortest-path
spanning tree. Commonly used in link-state routing algorithms. Sometimes called Dijkstra’s algorithm.
tailend—The router upon which an label-switched path (LSP) is terminated. This is the last router in the
LSP’s path.
used.
tunnel—A secure communications path between two peers, such as routers.
countries.
coincidental.
10
MPLS Traffic Engineering—RSVP Hello State
Timer

The MPLS Traffic Engineering—RSVP Hello State Timer feature detects when a neighbor is down and
quickly triggers a state timeout, which frees resources such as bandwidth that can be reused by other
label switched paths (LSPs).
Resource Reservation Protocol (RSVP) hellos can be used to detect when a neighboring node is down.
The hello state timer then triggers a state timeout. As a result, network convergence time is reduced, and
nodes can forward traffic on alternate paths or assist in stateful switchover (SSO) operation.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering—RSVP Hello
State Timer” section on page 13.
Contents
• Prerequisites for MPLS Traffic Engineering—RSVP Hello State Timer, page 2
• Restrictions for MPLS Traffic Engineering—RSVP Hello State Timer, page 2
• Information About MPLS Traffic Engineering—RSVP Hello State Timer, page 2
• How to Configure MPLS Traffic Engineering—RSVP Hello State Timer, page 5
• Configuration Examples for MPLS Traffic Engineering—RSVP Hello State Timer, page 10
MPLS Traffic Engineering—RSVP Hello State Timer
Prerequisites for MPLS Traffic Engineering—RSVP Hello State Timer

• Feature Information for MPLS Traffic Engineering—RSVP Hello State Timer, page 13
Prerequisites for MPLS Traffic Engineering—RSVP Hello State

Timer
Perform the following tasks on routers before configuring the MPLS Traffic Engineering—RSVP Hello
State Timer feature:
• Configure Resource Reservation Protocol (RSVP).
• Enable Multiprotocol Label Switching (MPLS).
• Configure traffic engineering (TE).
• Enable hellos for state timeout.
Restrictions for MPLS Traffic Engineering—RSVP Hello State

Timer
• Hellos for state timeout are dependent on graceful restart, if it is configured; however, graceful
restart is independent of hellos for state timeout.
• Unnumbered interfaces are not supported.
• Hellos for state timeout are configured on a per-interface basis.
Information About MPLS Traffic Engineering—RSVP Hello State

Timer
You should understand the following concepts before configuring the MPLS TE—RSVP Hello State
Timer feature:
• Hellos for State Timeout, page 2
• Hellos for Nonfast-Reroutable TE LSP, page 3
• Hellos for Fast-Reroutable TE LSP with Backup Tunnel, page 4
• Hellos for Fast-Reroutable TE LSP Without Backup Tunnel, page 4
Hellos for State Timeout

When RSVP signals a TE LSP and there is a failure somewhere along the path, the failure can remain
undetected for as long as two minutes. During this time, bandwidth is held by the nonfunctioning LSP
on the nodes downstream from the point of failure along the path with the state intact. If this bandwidth
is needed by headend tunnels to signal or resignal LSPs, tunnels may fail to come up for several minutes
thereby negatively affecting convergence time.
2
Information About MPLS Traffic Engineering—RSVP Hello State Timer
Hellos enable RSVP nodes to detect when a neighboring node is not reachable. After a certain number
of intervals, hellos notice that a neighbor is not responding and delete its state. This action frees the
node’s resources to be reused by other LSPs.
Hellos must be configured both globally on the router and on the specific interface to be operational.
Hello Instance
A hello instance implements RSVP hellos for a given router interface address and a remote IP address.
A hello instance is expensive because of the large number of hello requests that are sent and the strains
they put on the router resources. Therefore, you should create a hello instance only when it is needed to
time out state and delete the hello instance when it is no longer necessary.
Hellos for Nonfast-Reroutable TE LSP

Figure 1 shows a nonfast-reroutable TE LSP from Router 1 to Router 3 via Router 2.
Figure 1 Nonfast-Reroutable TE LSP

LSP2
Alternate Path
Router 4
PathError
Router 0 Router 1 Router 2 Router 3

PathTear
117934
Hello Instance Hello Instance
LSP1
Assume that the link between Router 1 and Router 2 fails. This type of problem can be detected by
various means including interface failure, Interior Gateway Protocol (IGP) (Open Shortest Path First
(OSPF) or Intermediate System-to-Intermediate System (IS-IS)), and RSVP hellos. However, sometimes
interface failure cannot be detected; for example, when Router 1 and Router 2 are interconnected
through a Layer 2 switch. The IGP may be slow detecting the failure. Or there may be no IGP running
between Router 1 and Router 2; for example, between two Autonomous System Boundary Routers
(ASBRs) interconnecting two autonomous systems.
If hellos were running between Router 1 and Router 2, each router would notice that communication was
lost and time out the state immediately.
Router 2 sends a delayed PathTear message to Router 3 so that the state can be deleted on all nodes
thereby speeding up the convergence time.
Note The PathTear message is delayed one second because on some platforms data is being forwarded even
after the control plane is down.
Router 1 sends a destructive PathError message upstream to Router 0 with error code
ROUTING_PROBLEM and error value NO_ROUTE.
3
Information About MPLS Traffic Engineering—RSVP Hello State Timer
LSP1 goes from Router 0 to Router 1 to Router 2 to Router 3; LSP 2 goes from Router 0 to Router 1 to
Router 4 to Router 2 to Router 3.
Hellos for Fast-Reroutable TE LSP with Backup Tunnel

Figure 2 shows a fast reroutable TE LSP with a backup tunnel from Router1 to Router 2 to Router 3.
Figure 2 Fast Reroutable TE LSP with Backup Tunnel

Backup Tunnel
117935
Router 1 Router 2 Router 3
Merge Point
This TE LSP has a backup tunnel from Router 1 to Router 3 protecting the fast reroutable TE LSP against
a failure in the Router 1 to Router 2 link and node Router 2. However, assume that a failure occurs in the
link connecting Router 1 to Router 2. If hellos were running between Router 1 and Router 2, the routers
would notice that the link is down, but would not time out the state. Router 2 notices the failure, but
cannot time out the TE LSP because Router 2 may be a merge point, or another downstream node may
be a merge point. Router 1 notices the failure and switches to the backup LSP; however, Router 1 cannot
time out the state either.
Note A hello instance is not created in the preceding scenario because the neighbor is down and the hello
instance cannot take action.
Hellos for Fast-Reroutable TE LSP Without Backup Tunnel

On a fast-reroutable TE LSP with no backup tunnel, a hello instance can be created with the neighbor
downstream (next hop (NHOP)). On a nonfast-reroutable TE LSP, a hello instance can be created with
the neighbor downstream (NHOP) and the neighbor upstream (previous hop (PHOP)). This is in addition
to the existing hellos for Fast Reroute.
Note If both Fast Reroute and hellos for state timeout hello instances are needed on the same link, only one
hello instance is created. It will have the Fast Reroute configuration including interval, missed refreshes,
and differentiated services code point (DSCP). When a neighbor is down, Fast Reroute and the hello state
timer take action.
Figure 3 shows a fast-reroutable TE LSP. without a backup tunnel, from Router 1 (the point of local
repair (PLR)), to Router 2 to Router 3.
4
How to Configure MPLS Traffic Engineering—RSVP Hello State Timer
Figure 3 Fast Reroutable TE LSP Without Backup Tunnel
117936
PLR Merge Point
Assume that a failure occurs in the link connecting Router 1 to Router 3. Router 1 can time out the state
for the TE LSP because Router 1 knows there is no backup tunnel. However, Router 2 cannot time out
the state because Router 2 does not know whether a backup tunnel exists. Also, Router 2 may be a merge
point, and therefore cannot time out the state.
Note A hello instance is not created in the preceding scenario because the neighbor is down and the hello
instance cannot take action.
How to Configure MPLS Traffic Engineering—RSVP Hello State

Timer
Note The following tasks also enable Fast Reroute; however, this section focuses on the RSVP hello state
timer.
• Enabling the Hello State Timer Globally, page 5 (required)

• Enabling the Hello State Timer on an Interface, page 6 (required)
• Setting a DSCP Value on an Interface, page 7 (optional)
• Setting a Hello Request Interval on an Interface, page 8 (optional)
• Setting the Number of Hello Messages that can be Missed on an Interface, page 9 (optional)
• Verifying Hello for State Timer Configuration, page 10 (optional)
Enabling the Hello State Timer Globally

Perform this task to enable the RSVP hello state timer globally to reduce network convergence, allow
nodes to forward traffic on alternate paths, or assist in stateful switchover (SSO) operation.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello
4. end
5
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello Enables hellos for state timeout globally on a router.
Example:
Router(config)# ip rsvp signalling hello
Example:
Router(config)# end
Enabling the Hello State Timer on an Interface

Perform this task to enable the RSVP hello state timer on an interface.
SUMMARY STEPS
1. enable
4. ip rsvp signalling hello
5. end
DETAILED STEPS

Example:
Router> enable
Example:
6

Step 3 interface type Enters interface configuration mode.
slot/subslot/port[.subinterface-number]
• The type slot/subslot/port[.subinterface-number]
arguments identify the interface to be configured.
Example:
Router(config)# interface FastEthernet 0/0/0
Step 4 ip rsvp signalling hello Enables hellos for state timeout on an interface.
Example:
Router(config-if)# ip rsvp signalling hello
Example:
Setting a DSCP Value on an Interface

Perform this task to set a differentiated services code point DSCP value for hello messages on an
interface.
SUMMARY STEPS
1. enable
4. ip rsvp signalling hello reroute dscp num
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
7

Step 4 ip rsvp signalling hello reroute dscp num Sets a DSCP value for RSVP hello messages on an interface
of a router from 0 to 63 with hellos for state timeout
enabled.
Example:
reroute dscp 30
Example:
Setting a Hello Request Interval on an Interface

Perform this task to set a hello request interval on an interface.
SUMMARY STEPS
1. enable
4. ip rsvp signalling hello reroute refresh interval interval-value
5. end
DETAILED STEPS

Example:
Router> enable
Example:
argument identifies the interface to be configured.
Example:
8

Step 4 ip rsvp signalling hello reroute refresh Sets a hello request interval on an interface of a router with
interval interval-value hellos for state timer enabled.
Example:
reroute refresh interval 5000
Example:
Setting the Number of Hello Messages that can be Missed on an Interface

Perform this task to set the number of consecutive hello messages that are lost (missed) before hello
declares the neighbor down.
SUMMARY STEPS
1. enable
4. ip rsvp signalling hello reroute refresh misses msg-count
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
9
Configuration Examples for MPLS Traffic Engineering—RSVP Hello State Timer

Step 4 ip rsvp signalling hello reroute refresh misses Configures the number of consecutive hello messages that
msg-count are lost before hello declares the neighbor down.
Example:
reroute refresh misses 5
Example:
Verifying Hello for State Timer Configuration

Perform this task to verify the hello for state timer configuration.
SUMMARY STEPS
1. enable
2. show ip rsvp hello
DETAILED STEPS

Step 1 enable (Optional) Enables privileged EXEC mode.
Example:
Router> enable
Step 2 show ip rsvp hello Displays the status of RSVP TE hellos and statistics
including hello state timer (reroute).
Example:
Router# show ip rsvp hello
Configuration Examples for MPLS Traffic Engineering—RSVP

Hello State Timer
This section provides a configuration example for the MPLS TE—RSVP Hello State Timer feature:
• MPLS Traffic Engineering—RSVP Hello State Timer: Example, page 10
MPLS Traffic Engineering—RSVP Hello State Timer: Example

In the following example, the hello state timer is enabled globally and on an interface. Related
parameters, including a DSCP value, a refresh interval, and a missed refresh limit, are set on an interface.
10

Router(config-if)# ip rsvp signalling hello reroute dscp 30
Router(config-if)# ip rsvp signalling hello reroute refresh interval 5000
Router(config-if)# ip rsvp signalling hello reroute refresh misses 5
The following example verifies the status of the hello state timer (reroute):
Hello:
Fast-Reroute/Reroute:Enabled
Statistics:Enabled
Graceful Restart:Enabled (help-neighbor only)
The following sections provide references related to the MPLS Traffic Engineering—RSVP Hello State
Timer feature.
Related Documents
RSVP commands: complete command syntax, • Cisco IOS Quality of Service Solutions Command Reference
command mode, defaults, usage guidelines, and • Cisco IOS Multiprotocol Label Switching Command Reference
examples
Stateful Switchover Stateful Switchover
MPLS Label Distribution Protocol MPLS Label Distribution Protocol (LDP) Overview
Cisco nonstop forwarding Cisco Nonstop Forwarding
Information on backup tunnels, link and node failures, MPLS TE: Link and Node Protection, with RSVP Hellos Support
RSVP hellos (with Fast Tunnel Interface Down Detection)
Graceful restart NSF/SSO - MPLS TE and RSVP Graceful Restart
Standards
Standard Title
11
MIBs
MIB MIBs Link
No new or modified MIBS are supported by this To locate and download MIBs for selected platforms, Cisco IOS XE
RFCs
RFC Title
RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels
Description Link
12
Feature Information for MPLS Traffic Engineering—RSVP Hello State Timer
Feature Information for MPLS Traffic Engineering—RSVP Hello

State Timer
Table 1 Feature Information for MPLS Traffic Engineering—RSVP Hello State Timer

MPLS Traffic Engineering—RSVP Hello Cisco IOS XE The MPLS Traffic Engineering—RSVP Hello State Timer
State Timer Release 2.3 feature detects when a neighbor is down and quickly
triggers a state timeout, which frees resources such as
bandwidth that can be reused by other label switched paths
(LSPs).
feature:
• Hellos for State Timeout, page 2
• Hellos for Nonfast-Reroutable TE LSP, page 3
• Hellos for Fast-Reroutable TE LSP with Backup
Tunnel, page 4
• Enabling the Hello State Timer Globally, page 5
• Enabling the Hello State Timer on an Interface, page 6
• Setting a DSCP Value on an Interface, page 7
• Setting a Hello Request Interval on an Interface, page 8
• Setting the Number of Hello Messages that can be
Missed on an Interface, page 9
• Verifying Hello for State Timer Configuration, page 10
The following commands were introduced or modified: ip
rsvp signalling hello dscp, ip rsvp signalling hello
refresh interval, ip rsvp signalling hello refresh misses,
ip rsvp signalling hello reroute dscp, ip rsvp signalling
hello reroute refresh interval, ip rsvp signalling hello
reroute refresh misses, show ip rsvp hello.
13
Glossary
Glossary
autonomous system—A collection of networks that share the same routing protocol and that are under
the same system administration.
ASBR—autonomous system boundary router. A router that connects and exchanges information
between two or more autonomous systems.
backup tunnel—A Multiprotocol Label Switching (MPLS) traffic engineering tunnel used to protect
other (primary) tunnel traffic when a link or node failure occurs.
DSCP—differentiated services code point. Six bits in the IP header, as defined by the Internet
Engineering Task Force (IETF). These bits determine the class of service provided to the IP packet.
FRR—Fast Reroute. A mechanism for protecting Multiprotocol Label Switching (MPLS) traffic
engineering (TE) label switched paths (LSPs) from link and node failure by locally repairing the LSPs
at the point of failure, allowing data to continue to flow on them while their headend routers attempt to
establish end-to-end LSPs to replace them. FRR locally repairs the protected LSPs by rerouting them
over backup tunnels that bypass failed links or nodes.
graceful restart—A process for helping a neighboring Route Processor (RP) restart after a node failure
has occurred.
headend—The router that originates and maintains a given label switched paths (LSP). This is the first
autonomous system. Examples of common Internet IGPs include Internal Gateway Routing Protocol
IS-IS—Intermediate System-to-Intermediate System. Open systems Interconnection (OSI) link-state
hierarchical routing protocol whereby Intermediate System (IS) routers exchange routing information
based on a single metric to determine network topology.
instance—A mechanism that implements the RSVP hello extensions for a given router interface address
and remote IP address. Active hello instances periodically send Hello Request messages, expecting
Hello ACK messages in response. If the expected ACK message is not received, the active hello instance
declares that the neighbor (remote IP address) is unreachable (that is, it is lost). This can cause LSPs
crossing this neighbor to be fast rerouted.
label—A short, fixed-length data identifier that tells switching nodes how to forward data (packets or
cells).
LDP—Label Distribution Protocol. The protocol that supports Multiprotocol Label Switching (MPLS)
hop-by-hop forwarding by distributing bindings between labels and network prefixes. The Cisco
proprietary version of this protocol is the Tag Distribution Protocol (TDP).
LSP—label switched path is a configured connection between two routers, in which Multiprotocol Label
Switching (MPLS) is used to carry packets. The LSP is created by the concatenation of one or more
label-switched hops, allowing a packet to be forwarded by swapping labels from one MPLS node to
another MPLS node.
MPLS enables routers at the edge of a network to apply labels to packets (frames). ATM switches or
existing routers in the network core can switch packets according to the labels.
OSPF—Open Shortest Path First. A link-state routing protocol used for routing.
PLR—point of local repair. The headend of the backup tunnel.
14
Glossary
state—Information that a router must maintain about each LSP. The information is used for rerouting
tunnels.
tailend—The router upon which an LSP is terminated. This is the last router in the LSP’s path.
used.
structure.
tunnel—Secure communications path between two peers, such as two routers.
countries.
coincidental.
15
Glossary
16
MPLS Traffic Engineering Forwarding Adjacency

The MPLS Traffic Engineering Forwarding Adjacency feature allows a network administrator to handle
a traffic engineering (TE) label switched path (LSP) tunnel as a link in an Interior Gateway Protocol
(IGP) network based on the Shortest Path First (SPF) algorithm.
Both Intermediate System-to-Intermediate System (IS-IS) and Open Shortest Path First (OSPF) are
supported.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering Forwarding
Adjacency” section on page 11.
Contents
• Prerequisites for MPLS Traffic Engineering Forwarding Adjacency, page 2
• Restrictions for MPLS Traffic Engineering Forwarding Adjacency, page 2
• Information About MPLS Traffic Engineering Forwarding Adjacency, page 2
• How to Configure MPLS Traffic Engineering Forwarding Adjacency, page 3
• Configuration Examples for MPLS Traffic Engineering Forwarding Adjacency, page 7
• Feature Information for MPLS Traffic Engineering Forwarding Adjacency, page 11
Prerequisites for MPLS Traffic Engineering Forwarding Adjacency
Prerequisites for MPLS Traffic Engineering Forwarding

Adjacency
Your network must support the following Cisco IOS XE features:
• IS-IS
Restrictions for MPLS Traffic Engineering Forwarding

Adjacency
• Using the MPLS Traffic Engineering Forwarding Adjacency feature increases the size of the IGP
database by advertising a TE tunnel as a link.
• When the MPLS Traffic Engineering Forwarding Adjacency feature is enabled on a TE tunnel, the
link is advertised in the IGP network as a type, length, value (TLV) 22 object without any TE
sub-TLV.
• You must configure MPLS TE forwarding adjacency tunnels bidirectionally.
Information About MPLS Traffic Engineering Forwarding

Adjacency
To configure MPLS Traffic Engineering Forwarding Adjacency you should understand the following
concepts:
• MPLS Traffic Engineering Forwarding Adjacency Functionality, page 2
• MPLS Traffic Engineering Forwarding Adjacency Benefits, page 3
MPLS Traffic Engineering Forwarding Adjacency Functionality

The MPLS Traffic Engineering Forwarding Adjacency feature allows a network administrator to handle
a TE LSP tunnel as a link in an IGP network based on the SPF algorithm. A forwarding adjacency can
be created between routers regardless of their location in the network. The routers can be located
multiple hops from each other, as shown in Figure 1.
2
How to Configure MPLS Traffic Engineering Forwarding Adjacency
Figure 1 Forwarding Adjacency Topology
= Routers = Links
= Tunnels
59681
= IGP cloud
As a result, a TE tunnel is advertised as a link in an IGP network with the link’s cost associated with it.
Routers outside of the TE domain see the TE tunnel and use it to compute the shortest path for routing
traffic throughout the network.
MPLS Traffic Engineering Forwarding Adjacency Benefits

TE tunnel interfaces advertised for SPF—TE tunnel interfaces are advertised in the IGP network just like
any other links. Routers can then use these advertisements in their IGPs to compute the SPF even if they
are not the headend of any TE tunnels.
How to Configure MPLS Traffic Engineering Forwarding

Adjacency
• Configuring a Tunnel Interface for MPLS TE Forwarding Adjacency, page 4 (required)
• Configuring MPLS TE Forwarding Adjacency on Tunnels, page 4 (required)
• Verifying MPLS TE Forwarding Adjacency, page 6 (optional)
3
Configuring a Tunnel Interface for MPLS TE Forwarding Adjacency

To configure a tunnel interface for an MPLS TE forwarding adjacency, perform the following task.
SUMMARY STEPS
1. enable
4. exit
5. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel number Designates a tunnel interface for the forwarding adjacency, and
enters interface configuration mode.
Example:
Router(config)# interface tunnel 0
configuration mode.
Example:
mode.
Example:
Configuring MPLS TE Forwarding Adjacency on Tunnels

To configure an MPLS TE forwarding adjacency, perform the following task.
Note You must configure a forwarding adjacency on two LSP tunnels bidirectionally, from A to B and B to A.
Otherwise, the forwarding adjacency is advertised, but not used in the IGP network.
4
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng forwarding-adjacency [holdtime value]
5. isis metric {metric-value | maximum} {level-1 | level-2}
6. exit
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel number Designates a tunnel interface for the forwarding adjacency, and
enters interface configuration mode.
Example:
Step 4 tunnel mpls traffic-eng Advertises a TE tunnel as a link in an IGP network.
forwarding-adjacency [holdtime value]
Example:
traffic-eng forwarding-adjacency
Step 5 isis metric {metric-value | maximum} Configures the IS-IS metric for a tunnel interface to be used as a
{level-1 | level-2} forwarding adjacency.
• You should specify the isis metric command with level-1 or
Example:
Router(config-if)# isis metric 2 level-1 level-2 to be consistent with the IGP level at which you are
performing traffic engineering. Otherwise, the metric has the
default value of 10.
configuration mode.
Example:
mode.
Example:
5
Verifying MPLS TE Forwarding Adjacency

To verify MPLS TE forwarding adjacency on tunnels, perform the following task.
SUMMARY STEPS
1. enable
2. show mpls traffic-eng forwarding-adjacency [id-address]
3. show isis [process-tag] database [level-1] [level-2] [l1] [l2] [detail] [lspid]
4. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls traffic-eng forwarding-adjacency [ip-address]

Use this command to see the current tunnels. For example:
Router# show mpls traffic-eng forwarding-adjacency
destination 0168.0001.0007.00 has 1 tunnels

Tunnel7 (traffic share 100000, nexthop 192.168.1.7)
(flags:Announce Forward-Adjacency, holdtime 0)
Router# show mpls traffic-eng forwarding-adjacency 192.168.1.7
destination 0168.0001.0007.00 has 1 tunnels

Tunnel7 (traffic share 100000, nexthop 192.168.1.7)
(flags:Announce Forward-Adjacency, holdtime 0)
Step 3 show isis [process-tag] database [level-1] [level-2] [l1] [l2] [detail] [lspid]
Use this command to display information about the IS-IS link-state database. For example:
Router# show isis database
IS-IS Level-1 Link State Database
LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL

0000.0C00.0C35.00-00 0x0000000C 0x5696 792 0/0/0
0000.0C00.40AF.00-00 0x00000009 0x8452 1077 1/0/0
0000.0C00.62E6.00-00 0x0000000A 0x38E7 383 0/0/0
0000.0C00.62E6.03-00 0x00000006 0x82BC 384 0/0/0
0800.2B16.24EA.00-00 0x00001D9F 0x8864 1188 1/0/0
0800.2B16.24EA.01-00 0x00001E36 0x0935 1198 1/0/0
IS-IS Level-2 Link State Database

LSPID LSP Seq Num LSP Checksum LSP Holdtime ATT/P/OL
0000.0C00.0C35.03-00 0x00000005 0x04C8 792 0/0/0
0000.0C00.3E51.00-00 0x00000007 0xAF96 758 0/0/0
0000.0C00.40AF.00-00 0x0000000A 0x3AA9 1077 0/0/0
6
Configuration Examples for MPLS Traffic Engineering Forwarding Adjacency
Step 4 exit
Use this command to exit to user EXEC. For example:
Router# exit
Router>
Configuration Examples for MPLS Traffic Engineering

Forwarding Adjacency
This section provides a configuration example for the MPLS Traffic Engineering Forwarding Adjacency
feature using an IS-IS metric.
• MPLS TE Forwarding Adjacency: Example, page 7
MPLS TE Forwarding Adjacency: Example

The following output shows the configuration of a tunnel interface, a forwarding adjacency, and an IS-IS
metric:

Router(config-if)# tunnel mpls traffic-eng forwarding-adjacency
Router(config-if)# isis metric 2 level-1
Following is sample command output when a forwarding adjacency has been configured:
Router# show running-config
Current configuration :364 bytes
!
interface Tunnel7
tunnel mpls traffic-eng forwarding-adjacency
tunnel mpls traffic-eng path-option 10 explicit name short
isis metric 2 level 1
Note Do not specify the tunnel mpls traffic-eng autoroute announce command in your configuration when
you are using forwarding adjacency.
Following is an example where forwarding adjacency is configured with OFPF:

7
Configuration Examples for MPLS Traffic Engineering Forwarding Adjacency
Current configuration : 310 bytes
interface tunnel 1
!
interface Tunnel1
ip ospf cost 6
tunnel mpls traffic-eng forwarding-adjacency tunnel mpls
traffic-eng priority 7 7
end
Router# show mpls traffic-eng forwarding-adjacency
destination 172.16.255.5, area ospf 172 area 0, has 1 tunnels

Tunnel1 (load balancing metric 2000000, nexthop 172.16.255.5)
(flags: Forward-Adjacency, holdtime 0)
Router#
Usage Tips
In Figure 2, if you have no forwarding adjacencies configured for the TE tunnels between Band F and C
and F, all the traffic that A must forward to F goes through B because B is the shortest path from A to F.
(The cost from A to F is 15 through B and 20 through C.)
8
Figure 2 Using Forwarding Adjacencies

F
5 5
D G
6 6
5
5 E
B C
62884
5 5
A
5 = IS-IS metric for each physical link
6 = IS-IS metric for the TE tunnels
If you have forwarding adjacencies configured on the TE tunnels between B and F and C and F and also
on the TE tunnels between F and B and F and C, then when A computes the SPF algorithm, A sees two
equal cost paths of 11 to F. As a result, traffic across the A-B and A-C links is shared.
The following sections provide references related to the MPLS Traffic Engineering Forwarding
Adjacency feature.
Related Documents
MPLS traffic engineering commands Cisco IOS Multiprotocol Label Switching Command Reference
IP switching commands Cisco IOS IP Switching Command Reference
IS-IS TLVs Intermediate System-to-Intermediate System (IS-IS) TLVs (white
paper)
9
Standards
Standard Title
MIBs
MIB MIBs Link
feature, and support for existing standards has not been software releases, and feature sets, use Cisco MIB Locator found at
RFCs
RFC Title
Description Link
10
Feature Information for MPLS Traffic Engineering Forwarding Adjacency
Feature Information for MPLS Traffic Engineering Forwarding

Adjacency
Table 1 Feature Information for MPLS Traffic Engineering Forwarding Adjacency

MPLS Traffic Engineering Forwarding Cisco IOS XE The MPLS Traffic Engineering Forwarding Adjacency
Adjacency Release 2.3 feature allows a network administrator to handle a TE
LSP tunnel as a link in an IGP network based on the SPF
algorithm.
implemented on the Cisco ASR 1000 Series Aggregation
Services Routers.
feature:
• MPLS Traffic Engineering Forwarding Adjacency
Functionality, page 2
• MPLS Traffic Engineering Forwarding Adjacency
Benefits, page 3
• Configuring a Tunnel Interface for MPLS TE
Forwarding Adjacency, page 4
• Configuring MPLS TE Forwarding Adjacency on
Tunnels, page 4
• Verifying MPLS TE Forwarding Adjacency, page 6
The following commands were modified: debug mpls
traffic-eng forwarding-adjacency, show mpls
traffic-eng forwarding-adjacency, and tunnel mpls
traffic-eng forwarding-adjacency.
11
Glossary
Glossary
Cisco Express Forwarding—A scalable, distributed, Layer 3 switching solution designed to meet the
future performance requirements of the Internet and enterprise networks.
forwarding adjacency—A traffic engineering link (or LSP) into an IS-IS/OSPF network.
autonomous system. Examples of common IGPs include Interior Gateway Routing Protocol (IGRP),
Open Shortest Path First (OSPF), and Routing Information Protocol (RIP).
IS-IS—Intermediate System-to-Intermediate System. Open System Interconnection (OSI) link-state
hierarchical routing protocol whereby Intermediate System (IS) routers exchange routing information
based on a single metric to determine network topology.
label switched path (LSP)—A sequence of hops (R0...Rn) in which a packet travels from R0 to Rn
through label switching mechanisms. A switched path can be chosen dynamically, based on normal
MPLS—Multiprotocol Label Switching. A switching method that forwards IP traffic using a label. This
label instructs the routers and the switches in the network where to forward the packets based on
preestablished IP routing information.
OSPF—Open Shortest Path First. A link-state, hierarchical IGP routing algorithm proposed as a
successor to RIP in the Internet community. OSPF features include least-cost routing, multipath routing,
and load balancing. OSPF was derived from an early version of the IS-IS protocol. See also IS-IS.
SPF—Shortest Path First. A routing algorithm used as the basis for OSPF operations. When an SPF
router is powered up, it initializes its routing-protocol data structures and then waits for indications from
lower-layer protocols that its interfaces are functional.
TLV—type, length, value. A block of information embedded in Cisco Discovery Protocol
advertisements.
applied.
traffic engineering tunnel—A label switched tunnel that is used for traffic engineering. Such a tunnel
12
Glossary
countries.
coincidental.
13
Glossary
14
MPLS Traffic Engineering (TE)—Automatic
Bandwidth Adjustment for TE Tunnels

The MPLS Traffic Engineering (TE)—Automatic Bandwidth Adjustment for TE Tunnels feature allows
you to automatically adjust the bandwidth allocation for traffic engineering tunnels based on the tunnel’s
measured traffic load. The configured bandwidth in the running configuration is changed due to the
automatic bandwidth behavior.

which each feature is supported, see the “Feature Information for MPLS TE—Automatic Bandwidth
Adjustment for TE Tunnels” section on page 18.
Contents
• Prerequisites for MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels, page 2
• Restrictions for MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels, page 2
• Information About MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels, page 2
• How to Configure MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels, page 3
• Configuration Examples for MPLS TE—Automatic Bandwidth Adjustments for TE Tunnels,
page 15
MPLS Traffic Engineering (TE)—Automatic Bandwidth Adjustment for TE Tunnels
Prerequisites for MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels

• Feature Information for MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels, page 18
Prerequisites for MPLS TE—Automatic Bandwidth Adjustment

for TE Tunnels
Your network must support the following Cisco IOS XE features before configure the MPLS
TE—Automatic Bandwidth Adjustment for TE Tunnels feature:
• Multiprotocol Label Switching (MPLS) traffic engineering tunnels
Restrictions for MPLS TE—Automatic Bandwidth Adjustment

for TE Tunnels
• The automatic bandwidth adjustment feature treats each tunnel for which it has been enabled
independently. That is, it adjusts the bandwidth for each such tunnel according to the adjustment
frequency configured for the tunnel and the sampled output rate for the tunnel since the last
adjustment without regard for any adjustments previously made or pending for other tunnels.
• If a tunnel is brought down to calculate a new label switched path (LSP) because the LSP is not
operational, the configured bandwidth is not saved. If the router is reloaded, the last saved automatic
bandwidth value is used.
• You cannot configure MPLS TE over the logical generic routing encapsulation (GRE) tunnel
interface.
Information About MPLS TE—Automatic Bandwidth Adjustment

for TE Tunnels
Before you configure the MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels feature, you
should understand the following:
• MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels Overview, page 2
• MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels Benefits, page 3
MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels Overview

Traffic engineering autobandwidth samples the average output rate for each tunnel marked for automatic
bandwidth adjustment. For each marked tunnel, the feature periodically (for example, once per day)
adjusts the tunnel’s allocated bandwidth to be the largest sample for the tunnel since the last adjustment.
2
How to Configure MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels
The frequency with which tunnel bandwidth is adjusted and the allowable range of adjustments is
configurable on a per-tunnel basis. In addition, the sampling interval and the interval over which to
average tunnel traffic to obtain the average output rate is user-configurable on a per-tunnel basis.
MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels Benefits

The automatic bandwidth feature makes it easy to configure and monitor the bandwidth for MPLS TE
tunnels. If automatic bandwidth is configured for a tunnel, TE automatically adjusts the tunnel’s
bandwidth.
How to Configure MPLS TE—Automatic Bandwidth Adjustment

for TE Tunnels
This section contains the following tasks to configure MPLS TE automatic bandwidth adjustment for TE
tunnels:
• Configuring a Platform to Support Traffic Engineering Tunnels, page 3 (required)
• Configuring IS-IS or OSPF for MPLS Traffic Engineering, page 4 (required)
• Configuring Bandwidth on Each Link That the Tunnels Cross, page 9 (required)
• Configuring a Platform to Support Automatic Bandwidth Adjustment, page 10 (required)
• Configuring Automatic Bandwidth Adjustment for a Tunnel, page 11 (required)
• Configuring the Interval for Computing Tunnel Average Output Rate, page 12 (optional)
• Verifying the Automatic Bandwidth Configuration, page 13
Configuring a Platform to Support Traffic Engineering Tunnels

To configure a platform to support traffic engineering tunnels, perform the following task.
SUMMARY STEPS
1. enable
5. exit
3
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef distributed Enables distributed Cisco Express Forwarding operation.
Example:
Step 4 mpls traffic-eng tunnels Enables the MPLS traffic engineering tunnel feature on a
device.
Example:
Example:
Configuring IS-IS or OSPF for MPLS Traffic Engineering

Perform one of the follow tasks to configure Intermediate System-to-Intermediate System (IS-IS) or
Open Shortest Path First (OSPF) for MPLS TE:
• Configuring IS-IS for MPLS Traffic Engineering, page 4 (optional)
• Configuring OSPF for MPLS Traffic Engineering, page 6 (optional)

To configure IS-IS for MPLS traffic engineering, perform the following task:
SUMMARY STEPS
1. enable
3. router isis
4. mpls traffic-eng level-1
7. exit
4
8. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router isis Enables IS-IS routing and specifies an IS-IS process for IP.
This command places you in router configuration mode.
Example:
Step 4 mpls traffic-eng level-1 Turns on MPLS traffic engineering for IS-IS level 1.
Example:
Example:
router-id loopback0
type, length, value objects (TLVs).
Example:
Example:
Example:
5

To configure Open Shortest Path First (OSPF) for MPLS TE, perform the following task.
SUMMARY STEPS
1. enable
6. exit
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router ospf process-id Configures an OSPF routing process for IP and enters
Example: • The process-id is an internally used identification
Router(config)# router ospf 200 parameter for an OSPF routing process. It is locally
assigned and can be any positive integer. Assign a
unique value for each OSPF routing process.
Step 4 mpls traffic-eng area number Turns on MPLS traffic engineering for the indicated OSPF
area.
Example:
Router(config-router)# mpls traffic-eng area 0
Example:
router-id loopback0
6

Example:
Example:

The MPLS TE tunnel has two path setup options: a preferred explicit path and a backup dynamic path.
SUMMARY STEPS
1. enable
4. ip unnumbered interface-type interface-number
8. tunnel mpls traffic-eng path-option [protect] number {dynamic | explicit
{name path-name | identifier path-number}} [lockdown]
9. exit
10. exit
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
7

Step 4 ip unnumbered interface-type interface-number Gives the tunnel interface an IP address that is the same as
that of interface Loopback0.
Example: • An MPLS traffic engineering tunnel interface should be
Router(config-if)# ip unnumbered loopback 0 unnumbered because it represents a unidirectional link.
Note This command is not effective until Lookback0 has
been configured with an IP address.
Step 5 tunnel destination ip-address Specifies the destination for a tunnel. The destination must
be the MPLS traffic engineering router ID of the destination
device.
Example:
Step 6 tunnel mode mpls traffic-eng Sets the encapsulation mode of the tunnel to MPLS traffic
engineering.
Example:
tunnel.
Example: • The bandwidth argument is the bandwidth, in kilobits
Router(config-if)# tunnel mpls traffic-eng per second, set aside for the MPLS traffic engineering
bandwidth 250 tunnel. Range is from 1 to 4294967295. The default is
0.
• If automatic bandwidth is configured for the tunnel, the
tunnel mpls traffic-eng bandwidth command
configures the initial tunnel bandwidth, which will be
adjusted by the autobandwidth mechanism.
Note If you configure a tunnel’s bandwidth with the
tunnel mpls traffic-eng bandwidth command and
the minimum amount of automatic bandwidth with
the tunnel mpls traffic-eng auto-bw command, the
minimum amount of automatic bandwidth
adjustment is the lower of those two configured
values.
Step 8 tunnel mpls traffic-eng path-option [protect] Configures the tunnel to use a named IP explicit path or a
number {dynamic | explicit {name path-name | path dynamically calculated from the traffic engineering
identifier path-number}}[lockdown]
topology database.
• A dynamic path is used if an explicit path is currently
Example: unavailable.
path-option 10 explicit avoid-protected-link
Example:
Example:
8
Each tunnel mpls traffic-eng auto-bw command supersedes the previous one. Therefore, if you want
to specify multiple options for a tunnel, you must specify them all in a single tunnel mpls traffic-eng
auto-bw command.
Configuring Bandwidth on Each Link That the Tunnels Cross

To configure bandwidth on each link that the tunnels cross, perform the following task.
SUMMARY STEPS
1. enable
5. ip rsvp bandwidth [interface-kbps] [single-flow-kbps] [sub-pool kbps]
6. exit
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
slot/subslot/port[.subinterface-number] configuration mode
Example:
Router(config)# interface FastEthernet0/0/0
Step 4 mpls traffic-eng tunnels Enables MPLS traffic engineering tunnels on an interface.
Example:
9

Step 5 ip rsvp bandwidth [interface-kbps] Enables Resource reservation Protocol (RSVP) for IP on an
[single-flow-kbps] [sub-pool kbps] interface.
• The interface-kbps argument specifies the maximum
Example: amount of bandwidth (in kbps) that may be allocated by
Router(config-if)# ip rsvp bandwidth 1000 100 RSVP flows. The range is from 1 to 10,000,000.
• The single-flow-kbps argument is the maximum amount
of bandwidth, in kbps, that may be allocated to a single
flow. The range is from 1 to 10,000,000.
Example:
Example:
Configuring a Platform to Support Automatic Bandwidth Adjustment

To enable automatic bandwidth adjustment on a platform and initiate sampling the output rate for tunnels
configured for bandwidth adjustment, perform the following task.
SUMMARY STEPS
1. enable
3. mpls traffic-eng auto-bw timers [frequency seconds]
4. no mpls traffic-eng auto-bw timers
5. exit
DETAILED STEPS

Example:
Router> enable
Example:
10

Step 3 mpls traffic-eng auto-bw timers [frequency Enables automatic bandwidth adjustment on a platform and
seconds] begins sampling the output rate for tunnels that have been
configured for automatic bandwidth adjustment.
Example: • The frequency keyword specifies the interval, in
Router(config)# mpls traffic–eng auto–bw timers seconds, for sampling the output rate of each tunnel
frequency 300
configured for automatic bandwidth. The range is 1
through 604800. The recommended value is 300.
Step 4 no mpls traffic-eng auto-bw timers (Optional) Disables automatic bandwidth adjustment on a
platform.
Example: • Use the no version of the command, which terminates
Router(config)# no mpls traffic–eng auto–bw output rate sampling and the bandwidth adjustment for
timers tunnels. In addition, the no form of the command
restores the configured bandwidth for each tunnel
where configured bandwidth is determined as follows:
– If the tunnel bandwidth was explicitly configured
via the tunnel mpls traffic-eng bandwidth
command after the running configuration was
written (if at all) to the startup configuration, the
“configured bandwidth” is the bandwidth specified
by that command.
– Otherwise, the configured bandwidth is the
bandwidth specified for the tunnel in the startup
configuration.
Example:
Configuring Automatic Bandwidth Adjustment for a Tunnel

To enable automatic bandwidth adjustment for a tunnel and constrain the range of automatic bandwidth
adjustments applied to the tunnel, perform the following task.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng auto-bw [max-bw number] [min-bw number]
5. exit
6. exit
11
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 tunnel mpls traffic-eng auto-bw [max-bw number] Enables automatic bandwidth adjustment for the tunnel.
[min-bw number]
• The max-bw keyword specifies the maximum
automatic bandwidth, in kbps, for this tunnel. The
Example: range is from 0 to 4294967295.
auto-bw max-bw 2000 min-bw 1000 • The min-bw keyword specifies the minimum automatic
bandwidth, in kbps, for this tunnel. The range is from 0
to 4294967295.
Example:
Example:
Configuring the Interval for Computing Tunnel Average Output Rate

To specify the interval for computing the average output rate for an MPLS traffic engineering tunnel,
perform the following task.
SUMMARY STEPS
1. enable
4. load-interval seconds
5. exit
6. exit
12
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 load-interval seconds Configures the interval over which the input and output
rates for the interface are averaged.
Example: • The seconds argument is the length of time for which
Router(config-if)# load-interval 90 data is used to compute load statistics. The value is a
multiple of 30, from 30 to 600 (30, 60, 90, 120, and so
on). The default is 300 seconds.
Example:
Example:
Verifying the Automatic Bandwidth Configuration

To verify the automatic bandwidth configuration, perform the following task.
SUMMARY STEPS
1. enable
2. show mpls traffic-eng tunnels
3. show running-config
4. exit
13
DETAILED STEPS
Step 1 enable
Use this command to enter privileged EXEC mode. Enter you password if prompted. For example:
Router> enable
Router#
Step 2 show mpls traffic-eng tunnels

Use this command to show information about tunnels, including automatic bandwidth information for
tunnels that have the feature enabled. For example:
Router# show mpls traffic-eng tunnels
Name:tagsw4500-9_t1 (Tunnel1) Destination:10.0.0.11

Status:
Admin:up Oper:up Path:valid Signalling:connected
path option 1, type explicit pbr_south (Basis for Setup, path weight 30)
path option 2, type dynamic
Config Parameters:
Bandwidth:5000 kbps (Global) Priority:7 7 Affinity:0x0/0xFFFF
AutoRoute: disabled LockDown:disabled Loadshare:5000 bw-based
auto-bw:(86400/85477) 5347 Bandwidth Requested:5000
In the command output:

• The auto-bw line indicates that automatic bandwidth adjustment is enabled for the tunnel.
• 86400 is the time, in seconds, between bandwidth adjustments.
• 85477 is the time, in seconds, remaining until the next bandwidth adjustment.
• 5347 is the largest bandwidth sample since the last bandwidth adjustment.
• 5000 is the last bandwidth adjustment and the bandwidth currently requested for the tunnel.
Step 3 show running-config

Use this command to verify that the MPLS TE automatic bandwidth command is as you expected. For
example:
.
.
.
interface tunnel1
tunnel mpls traffic-eng auto bw max-bw 2000 min-bw 1000 !Enable automatic bandwidth
.
.
.
The sample output from the show running-config command shows that the value 1500, in the tunnel
mpls traffic-eng bandwidth 1500 command, changes after an adjustment is made.
14
Configuration Examples for MPLS TE—Automatic Bandwidth Adjustments for TE Tunnels
Step 4 exit
Router# exit
Router>
Configuration Examples for MPLS TE—Automatic Bandwidth

Adjustments for TE Tunnels
Figure 1 illustrates a sample MPLS topology. The following sections contain sample configuration
examples to configure automatic bandwidth adjustment for MPLS traffic engineering tunnels originating
on Router 1 and to enable automatic bandwidth adjustment for Tunnel1.
Figure 1 Sample MPLS Traffic Engineering Tunnel Configuration
Router 3
192.168.12.12 /255.255.255.0
192
.0
255
.16
55.
S1/1/0
8.3
S1/0/0
.1
5.2
.2
6.0
/25
/25
Tun
el 2
5.0
5.2
n
8.3
55.
el 2
Tun
.16
255
192
.0
S1/3/0 S1/1/0 192.168.33.0 /255.255.255.0

.1 .2
S1/0/0 Tunnel 2 S1/2/0 .1 Tunnel 2 .2
192864
S1/0/0 S1/0/0 S1/3/0 S1/0/0
.1 Tunnel 1 .2 Tunnel 1 Tunnel 1

192.168.31.0 /255.255.255.0 Router 4
Router 1 192.168.14.14 /255.255.255.0 Router 5
192.168.11.11 /255.255.255.0 Router 2 192.168.17.17 /255.255.255.0
192.168.15.15 /255.255.255.0
This section provides the following configuration examples based on Figure 1:

• Configuring MPLS Traffic Engineering Automatic Bandwidth: Example, page 15
• Tunnel Configuration for Automatic Bandwidth, page 16
The examples omit some configuration required for MPLS traffic engineering, such as the required
RSVP and Interior Gateway Protocol (IGP) (IS-IS or OSPF) configuration, because the purpose of these
examples is to illustrate the configuration for automatic bandwidth adjustment.
Configuring MPLS Traffic Engineering Automatic Bandwidth: Example

The following example shows how to use the mpls traffic-eng auto-bw timers command to enable
automatic bandwidth adjustment for Router 1. The command specifies that the output rate is to be
sampled every 10 minutes for tunnels configured for automatic bandwidth adjustment.
configure terminal
!
15
ip cef distributed
mpls traffic-eng auto-bw timers frequency 600 !Enable automatic bandwidth adjustment
ip address 192.168.11.11 255.255.255.0
Tunnel Configuration for Automatic Bandwidth

The following example shows how to use the tunnel mpls traffic-eng auto-bw command to enable
automatic bandwidth adjustment for Tunnel1. The command specifies a maximum allowable bandwidth
of 2000 kbps, a minimum allowable bandwidth of 1000 kbps, and that the default automatic bandwidth
adjustment frequency of once a day be used.
interface tunnel1
tunnel mpls traffic-eng auto bw max-bw 2000 min-bw 1000 !Enable automatic bandwidth
!adjustment for Tunnel1
The following sections provide references related to the MPLS Traffic Engineering—Automatic
Bandwidth Adjustment for TE Tunnels feature.
Related Documents
IS-IS and OSPF commands Cisco IOS IP Routing Protocols Command Reference
Quality of service solutions commands Cisco IOS Quality of Service Solutions Command Reference
Quality of service solutions configuration Quality of Service Overview
Standards
Standard Title
16
MIBs
MIB MIBs Link
MPLS Traffic Engineering MIB To locate and download MIBs for selected platforms, Cisco IOS XE
the following URL:
RFCs
RFC Title
modified.
Description Link
17
Feature Information for MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels
Feature Information for MPLS TE—Automatic Bandwidth

Adjustment for TE Tunnels
Table 1 Feature Information for MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels

MPLS Traffic Engineering (TE)—Automatic Cisco IOS XE The MPLS Traffic Engineering (TE)—Automatic
Bandwidth Adjustment for TE Tunnels Release 2.3 Bandwidth Adjustment for TE Tunnels feature provides
the means to automatically adjust the bandwidth
allocation for traffic engineering tunnels based on their
measured traffic load. The configured bandwidth in the
running configuration is changed due to the automatic
bandwidth behavior.
In Cisco IOS XE Release 2.1, this feature was introduced
Routers.
feature:
• MPLS TE—Automatic Bandwidth Adjustment for
TE Tunnels Overview, page 2
• MPLS TE—Automatic Bandwidth Adjustment for
TE Tunnels Benefits, page 3
• Configuring a Platform to Support Traffic
Engineering Tunnels, page 3
• Configuring IS-IS or OSPF for MPLS Traffic
Engineering, page 4
page 7
• Configuring Bandwidth on Each Link That the
Tunnels Cross, page 9
• Configuring a Platform to Support Automatic
Bandwidth Adjustment, page 10
• Configuring Automatic Bandwidth Adjustment for a
Tunnel, page 11
18
Table 1 Feature Information for MPLS TE—Automatic Bandwidth Adjustment for TE Tunnels (continued)

• Configuring the Interval for Computing Tunnel
Average Output Rate, page 12
• Verifying the Automatic Bandwidth Configuration,
page 13
clear mpls traffic-eng auto-bw timers, mpls
traffic-eng auto-bw timers, tunnel mpls traffic-eng
auto-bw.
countries.
19
20
RSVP Refresh Reduction and Reliable
Messaging

The RSVP Refresh Reduction and Reliable Messaging feature includes refresh reduction, which
improves the scalability, latency, and reliability of Resource Reservation Protocol (RSVP) signaling to
enhance network performance and message delivery.

which each feature is supported, see the “Feature Information for RSVP Refresh Reduction and Reliable
Messaging” section on page 12.
Contents
• Prerequisites for RSVP Refresh Reduction and Reliable Messaging, page 2
• Restrictions for RSVP Refresh Reduction and Reliable Messaging, page 2
• Information About RSVP Refresh Reduction and Reliable Messaging, page 2
• How to Configure RSVP Refresh Reduction and Reliable Messaging, page 4
• Configuration Examples for RSVP Refresh Reduction and Reliable Messaging, page 7
• Feature Information for RSVP Refresh Reduction and Reliable Messaging, page 12
RSVP Refresh Reduction and Reliable Messaging
Prerequisites for RSVP Refresh Reduction and Reliable Messaging
Prerequisites for RSVP Refresh Reduction and Reliable

Messaging
RSVP must be configured on two or more routers within the network before you can use the RSVP
Refresh Reduction and Reliable Messaging feature.
Restrictions for RSVP Refresh Reduction and Reliable

Messaging
Multicast flows are not supported for the reliable messages and summary refresh features.
Information About RSVP Refresh Reduction and Reliable

Messaging
To configure the RSVP Refresh Reduction and Reliable Messaging feature, you should understand the
following concepts:
• Feature Design of RSVP Refresh Reduction and Reliable Messaging, page 2
• Types of Messages in RSVP Refresh Reduction and Reliable Messaging, page 3
• Benefits of RSVP Refresh Reduction and Reliable Messaging, page 4
Feature Design of RSVP Refresh Reduction and Reliable Messaging

RSVP is a network-control, soft-state protocol that enables Internet applications to obtain special
qualities of service (QoS) for their data flows. As a soft-state protocol, RSVP requires that state be
periodically refreshed. If refresh messages are not transmitted during a specified interval, RSVP state
automatically times out and is deleted.
In a network that uses RSVP signaling, reliability and latency problems occur when an RSVP message
is lost in transmission. A lost RSVP setup message can cause a delayed or failed reservation; a lost RSVP
refresh message can cause a delay in the modification of a reservation or in a reservation timeout.
Intolerant applications can fail as a result.
Reliability problems can also occur when there is excessive RSVP refresh message traffic caused by a
large number of reservations in the network. Using summary refresh messages can improve reliability
by significantly reducing the amount of RSVP refresh traffic.
Note RSVP packets consist of headers that identify the types of messages, and object fields that contain
attributes and properties describing how to interpret and act on the content.
2
Information About RSVP Refresh Reduction and Reliable Messaging
Types of Messages in RSVP Refresh Reduction and Reliable Messaging

The RSVP Refresh Reduction and Reliable Messaging feature (Figure 1) includes refresh reduction,
which improves the scalability, latency, and reliability of RSVP signaling by introducing the following
extensions:
• Reliable messages (MESSAGE_ID, MESSAGE_ID_ACK objects, and ACK messages)
• Bundle messages (reception and processing only)
• Summary refresh messages (MESSAGE_ID_LIST and MESSAGE_ID_NACK objects)
Figure 1 RSVP Refresh Reduction and Reliable Messaging
MESSAGE_ID_ACK (desired flag)

0 seconds
MESSAGE_ID_ACK (successful response)
If an ACK for a Path or Reservation
message is received, go to normal
Retransmit MESSAGE_ID_ACK refresh state; for all other messages,
Rrt stop
Continue retransmission till Rm Refresh

Messages are missed. Increase Rrt by
factor of 2 for next transmission
Originating Node Destination Node

Retransmit MESSAGE_ID_ACK
n x Rrt
where n < Rm
Normal
Refresh State
Time
59206
Rrt = Retransmit Time
Rm = Successive Refresh Messages Missed
Reliable Messages
The reliable messages extension supports dependable message delivery among neighboring routers by
implementing an acknowledgment mechanism that consists of a MESSAGE_ID object and a
MESSAGE_ID_ACK object. The acknowledgments can be transmitted in an ACK message or
piggybacked in other RSVP messages.
Each RSVP message contains one MESSAGE_ID object. If the ACK_Desired flag field is set within the
MESSAGE_ID object, the receiver transmits a MESSAGE_ID_ACK object to the sender to confirm
delivery.
Bundle Messages
A bundle message consists of several standard RSVP messages that are grouped into a single RSVP
message.
A bundle message must contain at least one submessage. A submessage can be any RSVP message type
other than another bundle message. Submessage types include Path, PathErr, Resv, ResvTear, ResvErr,
ResvConf, and ACK.
3
How to Configure RSVP Refresh Reduction and Reliable Messaging
Bundle messages are addressed directly to the RSVP neighbor. The bundle header immediately follows
the IP header, and there is no intermediate transport header.
When a router receives a bundle message that is not addressed to one of its local IP addresses, it forwards
the message.
Note Bundle messages can be received, but not sent.
Summary Refresh Messages

A summary refresh message supports the refreshing of RSVP state without the transmission of
conventional Path and Resv messages. Therefore, the amount of information that must be transmitted
and processed to maintain RSVP state synchronization is greatly reduced.
A summary refresh message carries a set of MESSAGE_ID objects that identify the Path and Resv states
that should be refreshed. When an RSVP node receives a summary refresh message, the node matches
each received MESSAGE_ID object with the locally installed Path or Resv state. If the MESSAGE_ID
objects match the local state, the state is updated as if a standard RSVP refresh message were received.
However, if a MESSAGE_ID object does not match the receiver’s local state, the receiver notifies the
sender of the summary refresh message by transmitting a MESSAGE_ID_NACK object.
When a summary refresh message is used to refresh the state of an RSVP session, the transmission of
conventional refresh messages is suppressed. The summary refresh extension cannot be used for a Path
or Resv message that contains changes to a previously advertised state. Also, only a state that was
previously advertised in Path or Resv messages containing MESSAGE_ID objects can be refreshed by
using a summary refresh message.
Benefits of RSVP Refresh Reduction and Reliable Messaging

Enhanced Network Performance
Refresh reduction reduces the volume of steady-state network traffic generated, the amount of CPU
resources used, and the response time, thereby enhancing network performance.
Improved Message Delivery

The MESSAGE_ID and the MESSAGE_ID_ACK objects ensure the reliable delivery of messages and
support rapid state refresh when a network problem occurs. For example, MESSAGE_ID_ACK objects
are used to detect link transmission losses.
How to Configure RSVP Refresh Reduction and Reliable

Messaging
• Enabling RSVP on an Interface, page 5 (required)
• Enabling RSVP Refresh Reduction, page 5 (required)
• Verifying RSVP Refresh Reduction and Reliable Messaging, page 6 (optional)
4
Enabling RSVP on an Interface

To enable RSVP on an interface, complete the following steps.
SUMMARY STEPS
1. enable
4. ip rsvp bandwidth [interface-kbps [sub-pool]]
5. end
DETAILED STEPS

Example:
Router> enable
Example:
• The type and number arguments identify the interface
to be configured.
Example:
Step 4 ip rsvp bandwidth [interface-kbps [sub-pool]] Enables RSVP on an interface.
• The optional interface-kbps and sub-pool arguments
Example: specify the amount of bandwidth that can be allocated
Router(config-if)# ip rsvp bandwidth 7500 7500 by RSVP flows or to a single flow, respectively. Values
are from 1 to 10000000, and from 0 to 10000000,
respectively.
Step 5 end Returns to privileged EXEC mode.
Example:
Enabling RSVP Refresh Reduction

To enable RSVP refresh reduction, complete the following steps.
SUMMARY STEPS
1. enable
5
3. ip rsvp signalling refresh reduction
4. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling refresh reduction Enables refresh reduction.
Example:
Router(config)# ip rsvp signalling refresh
reduction
Example:
Router(config)# end
Verifying RSVP Refresh Reduction and Reliable Messaging

To verify that the RSVP Refresh Reduction and Reliable Messaging feature is functioning as expected,
complete the following steps.
SUMMARY STEPS
1. enable
2. clear ip rsvp counters [confirm]
3. show ip rsvp
4. show ip rsvp counters [interface interface-unit | summary | neighbor]
5. show ip rsvp interface [interface-type interface-number] [detail]
6. show ip rsvp neighbor [detail]
7. end
6
Configuration Examples for RSVP Refresh Reduction and Reliable Messaging
DETAILED STEPS

Example:
Router> enable
Step 2 clear ip rsvp counters [confirm] (Optional) Clears (sets to zero) all IP RSVP counters that are
being maintained by the router.
Example:
Router# clear ip rsvp counters
Step 3 show ip rsvp (Optional) Displays RSVP rate-limiting, refresh-reduction,
and neighbor information.
Example:
Router# show ip rsvp
Step 4 show ip rsvp counters [interface (Optional) Displays the number of RSVP messages that
interface-unit | summary | neighbor] were sent and received on each interface.
• The optional summary keyword displays the
Example: cumulative number of RSVP messages sent and
Router# show ip rsvp counters summary received by the router over all interfaces.
Step 5 show ip rsvp interface [interface-type (Optional) Displays information about interfaces on which
interface-number] [detail] RSVP is enabled including the current allocation budget and
maximum available bandwidth.
Example: • The optional detail keyword displays the bandwidth and
Router# show ip rsvp interface detail signaling parameters.
Step 6 show ip rsvp neighbor [detail] (Optional) Displays RSVP-neighbor information including
IP addresses.
Example: • The optional detail keyword displays the current RSVP
Router# show ip rsvp neighbor detail neighbors and identifies if the neighbor is using IP, User
Datagram Protocol (UDP), or RSVP encapsulation for a
specified interface or all interfaces.
Step 7 end Exits privileged EXEC mode.
Example:
Router# end
Configuration Examples for RSVP Refresh Reduction and

Reliable Messaging
• RSVP Refresh Reduction and Reliable Messaging: Example, page 8
7
Configuration Examples for RSVP Refresh Reduction and Reliable Messaging
RSVP Refresh Reduction and Reliable Messaging: Example

In the following example, RSVP refresh reduction is enabled:

Router(config-if)# ip rsvp bandwidth 7500 7500
Router(config)# ip rsvp signalling refresh reduction
Router(config)# end
The following example verifies that RSVP refresh reduction is enabled:

!
version 12.2
no service single-slot-reload-enable
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
service internal
!
hostname Router
!
no logging buffered
logging rate-limit console 10 except errors
!
ip subnet-zero
ip cef distributed
!
ip multicast-routing
no ip dhcp-client network-discovery
lcp max-session-starts 0
!
!
interface Loopback0
ip address 192.168.1.1 255.255.255.0
ip rsvp bandwidth 1705033 1705033
!
interface Tunnel777
no ip address
shutdown
!
ip address 192.168.0.195 255.0.0.0
no ip mroute-cache
media-type 10BaseT
!
ip address 192.168.5.2 255.255.255.0
no ip redirects
no ip proxy-arp
ip pim dense-mode
no ip mroute-cache
media-type 10BaseT
8
!
ip address 192.168.1.2 255.255.255.0
no ip redirects
no ip proxy-arp
ip pim dense-mode
no ip mroute-cache
media-type 10BaseT
!
ip address 192.168.2.2 255.255.255.0
ip pim dense-mode
media-type 10BaseT
!
!
router eigrp 17
network 192.168.0.0
network 192.168.5.0
network 192.168.12.0
network 192.168.30.0
auto-summary
no eigrp log-neighbor-changes
!
ip classless
no ip http server
ip rsvp signalling refresh reduction
!
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
login
transport input pad v120 telnet rlogin udptn
!
end
The following sections provide references related to the RSVP Refresh Reduction and Reliable
Messaging feature.
Related Documents
QoS commands: complete command syntax, command Cisco IOS Quality of Service Solutions Command Reference
modes, command history, defaults, usage guidelines,
and examples
9

QoS features including signaling, classification, and Quality of Service Overview module
congestion management
Information about and configuration tasks for MPLS MPLS Traffic Engineering and Enhancements
traffic engineering (TE)
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 2205 Resource Reservation Protocol
RFC 2206 RSVP Management Information Base Using SMIv2
RFC 2209 RSVP—Version 1 Message Processing Rules
RFC 2210 The Use of RSVP with IETF Integrated Services
RFC 2211/2212 Specification of the Controlled-Load Network Element Service
RFC 2702 Requirements for Traffic Engineering over MPLS
RFC 2749 Common Open Policy Service (COPS) Usage for RSVP
RFC 2750 RSVP Extensions for Policy Control
RFC 2814 SBM Subnet Bandwidth Manager: A Protocol for RSVP-based
Admission Control over IEEE 802-style Networks
RFC 2961 RSVP Refresh Overhead Reduction Extensions
RFC 2996 Format of the RSVP DCLASS Object
10
Description Link
11
Feature Information for RSVP Refresh Reduction and Reliable Messaging
Feature Information for RSVP Refresh Reduction and Reliable

Messaging
Table 1 Feature Information for RSVP Refresh Reduction and Reliable Messaging

RSVP Refresh Reduction and Reliable Cisco IOS XE The RSVP Refresh Reduction and Reliable Messaging feature
Messaging Release 2.3 includes refresh reduction, which improves the scalability,
latency, and reliability of Resource Reservation Protocol
(RSVP) signaling to enhance network performance and
message delivery.
feature:
• Feature Design of RSVP Refresh Reduction and Reliable
Messaging, page 2
• Types of Messages in RSVP Refresh Reduction and
Reliable Messaging, page 3
• Benefits of RSVP Refresh Reduction and Reliable
Messaging, page 4
• Enabling RSVP on an Interface, page 5
• Enabling RSVP Refresh Reduction, page 5
• Verifying RSVP Refresh Reduction and Reliable
Messaging, page 6
rsvp signalling rate-limit, show ip rsvp signalling
rate-limit.
12
countries.
13
14
MPLS Traffic Engineering: Path Link and
Node Protection
MPLS Traffic Engineering—Fast Reroute Link
and Node Protection

The MPLS Traffic Engineering—Fast Reroute Link and Node Protection feature provides link protection
(backup tunnels that bypass only a single link of the label-switched path (LSP)), node protection (backup
tunnels that bypass next-hop nodes along LSPs), and the following Fast Reroute (FRR) features:
• Backup tunnel support
• Backup bandwidth protection
• Resource Reservation Protocol (RSVP) Hellos

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering—Fast Reroute
Link and Node Protection” section on page 37.
Contents
• Prerequisites for MPLS Traffic Engineering—Fast Reroute Link and Node Protection, page 2
• Restrictions for MPLS Traffic Engineering—Fast Reroute Link and Node Protection, page 2
• Information About MPLS Traffic Engineering—Fast Reroute Link and Node Protection, page 3
• How to Configure MPLS Traffic Engineering—Fast Reroute (FRR) Link and Node Protection,
page 17
MPLS Traffic Engineering—Fast Reroute Link and Node Protection
Prerequisites for MPLS Traffic Engineering—Fast Reroute Link and Node Protection
• Configuration Examples for MPLS Traffic Engineering—Fast Reroute (FRR) Link and Node
Protection, page 32
• Feature Information for MPLS Traffic Engineering—Fast Reroute Link and Node Protection,
page 37
Prerequisites for MPLS Traffic Engineering—Fast Reroute Link

and Node Protection
Your network must support the following Cisco IOS XE features:
Your network must support at least one of the following protocols:
• Intermediate System-to-Intermediate System (IS-IS)
• Open Shortest Path First (OSPF)
Before configuring FRR link and node protection, it is assumed that you have done the following tasks
but you do not have to already have configured MPLS traffic engineering (TE) tunnels:
• Enabled MPLS TE on all relevant routers and interfaces
• Configured MPLS TE tunnels
Restrictions for MPLS Traffic Engineering—Fast Reroute Link

and Node Protection
• Interfaces must use MPLS Global Label Allocation.
• Backup tunnel headend and tailend routers must implement FRR as described in
draft-pan-rsvp-fastreroute-00.txt.
• Backup tunnels are not protected. If an LSP is actively using a backup tunnel and the backup tunnel
fails, the LSP is torn down.
• LSPs that are actively using backup tunnels are not considered for promotion. If an LSP is actively
using a backup tunnel and a better backup tunnel becomes available, the active LSP is not switched
to the better backup tunnel.
• You cannot enable FRR Hellos on a router that also has Resource Reservation Protocol (RSVP)
Graceful Restart enabled.
• MPLS TE LSPs that are fast reroutable cannot be successfully recovered if the LSPs are FRR active
and the Point of Local Repair (PLR) router experiences an SSO.
2
Information About MPLS Traffic Engineering—Fast Reroute Link and Node Protection
Information About MPLS Traffic Engineering—Fast Reroute Link

and Node Protection
To configure MPLS Traffic Engineering—Fast Reroute Link and Node Protection, you need to
understand the following concepts:
• Fast Reroute, page 3
• Link Protection, page 3
• Node Protection, page 4
• Bandwidth Protection, page 4
• RSVP Hello, page 5
• Features of MPLS Traffic Engineering—Fast Reroute Link and Node Protection, page 6
• Fast Reroute Operation, page 8
Fast Reroute
Fast Reroute (FRR) is a mechanism for protecting MPLS TE LSPs from link and node failures by locally
repairing the LSPs at the point of failure, allowing data to continue to flow on them while their headend
routers attempt to establish new end-to-end LSPs to replace them. FRR locally repairs the protected
LSPs by rerouting them over backup tunnels that bypass failed links or node.
Link Protection
Backup tunnels that bypass only a single link of the LSP’s path provide link protection. They protect
LSPs if a link along their path fails by rerouting the LSP’s traffic to the next hop (bypassing the failed
link). These are referred to as next-hop (NHOP) backup tunnels because they terminate at the LSP’s next
hop beyond the point of failure. Figure 1 illustrates an NHOP backup tunnel.
Figure 1 NHOP Backup Tunnel
Next-hop
backup tunnel
R1 R2 R3 R4
Next hop
59556
Primary Protected
LSP's path link
3
Node Protection
FRR provides node protection for LSPs. Backup tunnels that bypass next-hop nodes along LSP paths are
called next-next-hop (NNHOP) backup tunnels because they terminate at the node following the
next-hop node of the LSP paths, thereby bypassing the next-hop node. They protect LSPs if a node along
their path fails by enabling the node upstream of the failure to reroute the LSPs and their traffic around
the failed node to the next-next hop. FRR supports the use of RSVP Hellos to accelerate the detection of
node failures. NNHOP backup tunnels also provide protection from link failures, because they bypass
the failed link and the node.
Figure 2 illustrates an NNHOP backup tunnel.
Figure 2 NNHOP Backup Tunnel
Next-next hop
backup tunnel
R1 R2 R3 R4
Next-next hop
Primary Protected Protected

LSP's path link node
Backup tunnel
can protect against
link or node failures 59557
If an LSP is using a backup tunnel and something changes so that the LSP is no longer appropriate for
the backup tunnel, the LSP is torn down. Such changes are the following:
• Backup bandwidth of the backup tunnel is reduced.
• Backup bandwidth type of backup tunnel is changed to a type that is incompatible with the primary
LSP.
• Primary LSP is modified so that FRR is disabled. (The no mpls traffic-eng fast-reroute command
is entered.)
Bandwidth Protection
NHOP and NNHOP backup tunnels can be used to provide bandwidth protection for rerouted LSPs. This
is referred to as backup bandwidth. You can associate backup bandwidth with NHOP or NNHOP backup
tunnels. This informs the router of the amount of backup bandwidth a particular backup tunnel can
protect. When a router maps LSPs to backup tunnels, bandwidth protection ensures that an LSP uses a
given backup tunnel only if there is sufficient backup bandwidth. The router selects which LSPs use
which backup tunnels in order to provide maximum bandwidth protection. That is, the router determines
4
the best way to map LSPs onto backup tunnels in order to maximize the number of LSPs that can be
protected. For information about mapping tunnels and assigning backup bandwidth, see the “Backup
Tunnel Selection Procedure” section on page 10.
LSPs that have the “bandwidth protection desired” bit set have a higher right to select backup tunnels
that provide bandwidth protection; that is, those LSPs can preempt other LSPs that do not have that bit
set. For more information, see the “Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth
Protection” section on page 8.
RSVP Hello
This section contains the following topics about RSVP Hello:
• RSVP Hello Operation, page 5
• Hello Instance, page 5
RSVP Hello Operation

RSVP Hello enables RSVP nodes to detect when a neighboring node is not reachable. This provides
node-to-node failure detection. When such a failure is detected, it is handled in a similar manner as a
link-layer communication failure.
RSVP Hello can be used by FRR when notification of link-layer failures is not available (for example,
with Fast Ethernet), or when the failure detection mechanisms provided by the link layer are not
sufficient for the timely detection of node failures.
A node running Hello sends a Hello Request to a neighboring node every interval. If the receiving node
is running Hello, it responds with Hello Ack. If four intervals pass and the sending node has not received
an Ack or it receives a bad message, the sending node declares that the neighbor is down and notifies
FRR.
There are two configurable parameters:
• Hello interval—Use the ip rsvp signalling hello refresh interval command.
• Number of acknowledgment messages that are missed before the sending node declares that the
neighbor is down—Use the ip rsvp signalling hello refresh misses command
Hello Instance
A Hello instance implements RSVP Hello for a given router interface IP address and remote IP address.
A large number of Hello requests are sent; this puts a strain on the router resources. Therefore, create a
Hello instance only when it is necessary and delete it when it is no longer needed.
There are two types of Hello instances:
• Active Hello Instances
• Passive Hello Instances
Active Hello Instances

If a neighbor is unreachable when an LSP is ready to be fast rerouted, an active Hello instance is needed.
Create an active Hello instance for each neighbor with at least one LSP in this state.
5
Active Hello instances periodically send Hello Request messages, and expect Hello Ack messages in
response. If the expected Ack message is not received, the active Hello instance declares that the
neighbor (remote IP address) is unreachable (lost). LSPs traversing that neighbor may be fast rerouted.
If there is a Hello instance with no LSPs for an unreachable neighbor, do not delete the Hello instance.
Convert the active Hello instance to a passive Hello instance because there may be an active instance on
the neighboring router that is sending Hello requests to this instance.
Passive Hello Instances

Passive Hello instances respond to Hello Request messages (sending Ack messages), but do not initiate
Hello Request messages and do not cause LSPs to be fast rerouted. A router with multiple interfaces can
run multiple Hello instances to different neighbors or to the same neighbor.
A passive Hello instance is created when a Hello Request is received from a neighbor with a source IP
address/destination IP address pair in the IP header for which a Hello instance does not exist.
Delete passive instances if no Hello messages are received for this instance within 10 minutes.
Features of MPLS Traffic Engineering—Fast Reroute Link and Node Protection

MPLS Traffic Engineering—Fast Reroute Link and Node Protection has the following features:
• Backup Tunnel Support, page 6
• Backup Bandwidth Protection, page 7
Backup Tunnel Support

Backup tunnel support has the following capabilities:
• Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR, page 6
• Multiple Backup Tunnels Can Protect the Same Interface, page 6
• Backup Tunnels Provide Scalability, page 7
Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR

Backup tunnels that terminate at the next-next hop protect both the downstream link and node. This
provides protection for link and node failures. For more detailed information, see the “Node Protection”
section on page 4.
Multiple Backup Tunnels Can Protect the Same Interface

There is no limit (except memory limitations) to the number of backup tunnels that can protect a given
interface. In many topologies, support for node protection requires supporting multiple backup tunnels
per protected interface. These backup tunnels can terminate at the same destination or at different
destinations. That is, for a given protected interface, you can configure multiple NHOP or NNHOP
backup tunnels. This allows redundancy and load balancing.
In addition to being required for node protection, the protection of an interface by multiple backup
tunnels provides the following benefits:
• Redundancy—If one backup tunnel is down, other backup tunnels protect LSPs.
6
• Increased backup capacity—If the protected interface is a high-capacity link and no single backup
path exists with an equal capacity, multiple backup tunnels can protect that one high-capacity link.
The LSPs using this link will fail over to different backup tunnels, allowing all of the LSPs to have
adequate bandwidth protection during failure (rerouting). If bandwidth protection is not desired, the
router spreads LSPs across all available backup tunnels (that is, there is load balancing across
backup tunnels). For a more detailed explanation, see the “Backup Tunnel Selection Procedure”
section on page 10.
Examples are shown in the “Backup Tunnels Terminating at Different Destinations” section on page 9
and the “Backup Tunnels Terminating at the Same Destination” section on page 9.
Backup Tunnels Provide Scalability

A backup tunnel can protect multiple LSPs. Furthermore, a backup tunnel can protect multiple
interfaces. This is called many-to-one (N:1) protection. An example of N:1 protection is when one
backup tunnel protects 5000 LSPs, each router along the backup path maintains one additional tunnel.
One-to-one protection is when a separate backup tunnel must be used for each LSP needing protection.
N:1 protection has significant scalability advantages over one-to-one (1:1) protection. An example of 1:1
protection is when 5000 backup tunnels protect 5000 LSPs, each router along the backup path must
maintain state for an additional 5000 tunnels.
Backup Bandwidth Protection

Backup bandwidth protection allows you to give LSPs carrying certain kinds of data (such as voice)
priority for using backup tunnels. Backup bandwidth protection has the following capabilities:
• Bandwidth Protection on Backup Tunnels, page 7
• Bandwidth Pool Specifications for Backup Tunnels, page 7
• Semidynamic Backup Tunnel Paths, page 7
• Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth Protection, page 8
Bandwidth Protection on Backup Tunnels

Rerouted LSPs not only have their packets delivered during a failure, but the quality of service can also
be maintained.
Bandwidth Pool Specifications for Backup Tunnels

You can restrict the types of LSPs that can use a given backup tunnel. Backup tunnels can be restricted
so that only LSPs using subpool bandwidth can use them or only LSPs that use global-pool bandwidth
can use them. This allows different backup tunnels to be used for voice and data. Example: The backup
tunnel used for voice could provide bandwidth protection, and the backup tunnel used for data could not
provide bandwidth protection.
Semidynamic Backup Tunnel Paths

The path of a backup tunnel can be configured to be determined dynamically. This can be done by using
the IP explicit address exclusion feature that was added in Release 12.0(14)ST. If you use this feature,
semidynamic NHOP backup tunnel paths can be specified simply by excluding the protected link;
semidynamic NNHOP backup tunnel paths can be configured simply by excluding the protected node.
7
Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth Protection

In case there are not enough NHOP or NNHOP backup tunnels or they do not have enough backup
bandwidth to protect all LSPs, you can give an LSP priority in obtaining backup tunnels with bandwidth
protection. This is especially useful if you want to give LSPs carrying voice a higher priority than those
carrying data.
To activate this feature, enter the tunnel mpls traffic-eng fast-reroute bw-protect command to set the
“bandwidth protection desired” bit. See the “Enabling Fast Reroute on LSPs” section on page 17.
The LSPs do not necessarily receive bandwidth protection. They have a higher chance of receiving
bandwidth protection if they need it.
LSPs that do not have the bandwidth protection bit set can be demoted. Demotion is when one or more
LSPs are removed from their assigned backup tunnel to provide backup to an LSP that has its bandwidth
protection bit set. Demotion occurs only when there is a scarcity of backup bandwidth.
When an LSP is demoted, it becomes unprotected (that is, it no longer has a backup tunnel). During the
next periodic promotion cycle, an attempt is made to find the best possible backup tunnels for all LSPs
that do not currently have protection, including the LSP that was demoted. The LSP may get protection
at the same level or a lower level, or it may get no protection.
For information about how routers determine which LSPs to demote, see the “Backup Protection
Preemption Algorithms” section on page 14.
RSVP Hello
RSVP Hello enables a router to detect when a neighboring node has gone down but its interface to that
neighbor is still operational. This feature is useful when next-hop node failure is not detectable by link
layer mechanisms, or when notification of link-layer failures is not available (for example, Gigabit
Ethernet). This allows the router to switch LSPs onto its backup tunnels and avoid packet loss.
For a more detailed description of RSVP Hello, see the “RSVP Hello” section on page 5.
Fast Reroute Operation

This section describes the following:
• Fast Reroute Activation, page 8
• Backup Tunnels Terminating at Different Destinations, page 9
• Backup Tunnels Terminating at the Same Destination, page 9
• Backup Tunnel Selection Procedure, page 10
• Load Balancing on Limited-Bandwidth Backup Tunnels, page 11
• Load Balancing on Unlimited-Bandwidth Backup Tunnels, page 12
• Pool Type and Backup Tunnels, page 12
• Tunnel Selection Priorities, page 12
• Bandwidth Protection Considerations, page 14
Fast Reroute Activation
Two mechanisms cause routers to switch LSPs onto their backup tunnels:
• Interface down notification
8
• RSVP Hello neighbor down notification

When a router’s link or neighboring node fails, the router often detects this failure by an interface down
notification. On a GSR Packet over SONET (PoS) interface, this notification is very fast. When a router
notices that an interface has gone down, it switches LPSs going out that interface onto their respective
backup tunnels (if any).
RSVP Hellos can also be used to trigger FRR. If RSVP Hellos are configured on an interface, messages
are periodically sent to the neighboring router. If no response is received, Hellos declare that the
neighbor is down. This causes any LSPs going out that interface to be switched to their respective backup
tunnels.
Backup Tunnels Terminating at Different Destinations
Figure 3 illustrates an interface that has multiple backup tunnels terminating at different destinations and
demonstrates why, in many topologies, support for node protection requires supporting multiple backup
tunnels per protected interface.
Figure 3 Backup Tunnels That Terminate at Different Destinations
R1 R2 R3
R4
= Primary tunnels
59558
= Backup tunnels
In this illustration, a single interface on R1 requires multiple backup tunnels. LSPs traverse the following
routes:
• R1, R2, R3
• R1, R2, R4
To provide protection if node R2 fails, two NNHOP backup tunnels are required: one terminating at R3
and one terminating at R4.
Backup Tunnels Terminating at the Same Destination
Figure 4 shows how backup tunnels terminating at the same location can be used for redundancy and
load balancing. Redundancy and load balancing work for both NHOP and NNHOP backup tunnels.
9
Figure 4 Backup Tunnels That Terminate at the Same Destination
Backup tunnel
T2
T1
R1 R2 R3
59559
Primary
LSP's path
In this illustration, there are three routers: R1, R2, and R3. At R1 two NNHOP backup tunnels (T1 and
T2) go from R1 to R3 without traversing R2.
• Redundancy—If R2 fails or the link from R1 to R2 fails, either backup tunnel can be used. If one
backup tunnel is down, the other can be used. LSPs are assigned to backup tunnels when the LSPs
are first established. This is done before a failure.
• Load balancing—If neither backup tunnel has enough bandwidth to back up all LSPs, both tunnels
can be used. Some LSPs will use one backup tunnel, other LSPs will use the other backup tunnel.
The router decides the best way to fit the LSPs onto the backup tunnels.
Backup Tunnel Selection Procedure
When an LSP is signaled, each node along the LSP path that provides FRR protection for the LSP selects
a backup tunnel for the LSP to use if either of the following events occurs:
• The link to the next hop fails.
• The next hop fails.
By having the node select the backup tunnel for an LSP before a failure occurs, the LSP can be rerouted
onto the backup tunnel quickly if there is a failure.
For an LSP to be mapped to a backup tunnel, all of the following conditions must exist:
• The LSP is protected by FRR; that is, the LSP is configured with the tunnel mpls traffic-eng
fast-reroute command.
• The backup tunnel is up.
• The backup tunnel is configured to have an IP address, typically a loopback address.
• The backup tunnel is configured to protect this LSP’s outgoing interface; that is, the interface is
configured with the mpls traffic-eng backup-path command.
• The backup tunnel does not traverse the LSP’s protected interface.
• The backup tunnel terminates at the LSP’s NHOP or NNHOP. If it is an NNHOP tunnel, it does not
traverse the LSP’s NHOP.
• The bandwidth protection requirements and constraints, if any, for the LSP and backup tunnel are
met. For information about bandwidth protection considerations, see the “Bandwidth Protection”
section on page 11.
10
A backup tunnel can be configured to protect two types of backup bandwidth:

• Limited backup bandwidth—A backup tunnel provides bandwidth protection. The sum of the
bandwidth of all LSPs using this backup tunnel cannot exceed the backup tunnel’s backup
bandwidth. When you assign LSPs to this type of backup tunnel, sufficient backup bandwidth must
exist.
• Unlimited backup bandwidth—The backup tunnel does not provide any bandwidth protection (that
is, best-effort protection exists). There is no limit to the amount of bandwidth used by the LSPs that
are mapped to this backup tunnel. LSPs that allocate zero bandwidth can use only backup tunnels
that have unlimited backup bandwidth.
Load Balancing on Limited-Bandwidth Backup Tunnels
There may be more than one backup tunnel that has sufficient backup bandwidth to protect a given LSP.
In this case, the router chooses the one that has the least amount of backup bandwidth available. This
algorithm limits fragmentation, maintaining the largest amount of backup bandwidth available.
Specifying limited backup bandwidth does not “guarantee” bandwidth protection if there is a link or
node failure. For example, the set of NHOP and NNHOP backup tunnels that gets triggered when an
interface fails may all share some link on the network topology, and this link may not have sufficient
bandwidth to support all LSPs using this set of backup tunnels.
In Figure 5, both backup tunnels traverse the same links and hop. When the link between routers R1 and
R4 fails, backup tunnels for primary tunnel 1 and primary tunnel 2 are triggered simultaneously. The two
backup tunnels may share a link in the network.
Figure 5 Backup Tunnels Share a Link
Backup tunnel for Backup tunnel for

primary tunnel 1 primary tunnel 2
Primary tunnel 2
82033
R1 Primary tunnel 1 R4
Failed link
In Figure 6, the backup tunnel for primary tunnel 1 may traverse routers R1-R2-R3-R4, and the backup
tunnel for primary tunnel 2 may traverse routers R4-R2-R3-R1. In this case, the link R2-R3 may get
overloaded if R1-R4 fails.
11
Figure 6 Overloaded Link
R2
R3
Primary tunnel 2
82032
Load Balancing on Unlimited-Bandwidth Backup Tunnels
More than one backup tunnel, each having unlimited backup bandwidth, can protect a given interface.
In this case, when choosing a backup tunnel for a given LSP, the router chooses the backup tunnel that
has the least amount of backup bandwidth in use. This algorithm evenly distributes the LSPs across
backup tunnels based on an LSP’s bandwidth. If an LSP is requesting zero bandwidth, the router chooses
the backup tunnel that is protecting the fewest LSPs.
Pool Type and Backup Tunnels
By default, a backup tunnel provides protection for LSPs that allocate from any pool (that is, global or
subpool). However, a backup tunnel can be configured to protect only LSPs that use global-pool
bandwidth, or only those that use subpool bandwidth.
Tunnel Selection Priorities

• NHOP Versus NNHOP Backup Tunnels, page 12
• Promotion, page 14
• Backup Protection Preemption Algorithms, page 14
NHOP Versus NNHOP Backup Tunnels

More than one backup tunnel can protect a given LSP, where one backup tunnel terminates at the LSP’s
NNHOP, and the other terminates at the LSP’s NHOP. In this case, the router chooses the backup tunnel
that terminates at the NNHOP (that is, FRR prefers NNHOP over NHOP backup tunnels).
Table 1 lists the tunnel selection priorities. The first choice is an NNHOP backup tunnel that acquires its
bandwidth from a subpool or global pool, and has limited bandwidth. If there is no such backup tunnel,
the next choice (2) is a next-next hop backup tunnel that acquires a limited amount of bandwidth from
any pool. The preferences go from 1 (best) to 8 (worst), where choice 3 is for an NNHOP backup tunnel
with an unlimited amount of subpool or global-pool bandwidth.
12
Table 1 Tunnel Selection Priorities
Backup Tunnel
Preference Destination Bandwidth Pool Bandwidth Amount
1 (Best) NNHOP Subpool or global pool Limited
2 NNHOP Any Limited
3 NNHOP Subpool or global pool Unlimited
4 NNHOP Any Unlimited
5 NHOP Subpool or global pool Limited
6 NHOP Any Limited
7 NHOP Subpool or global pool Unlimited
8 (Worst) NHOP Any Unlimited
Figure 7 shows an example of the backup tunnel selection procedure based on the designated amount of
global pool and subpool bandwidth currently available.
Note If NHOP and NNHOP backup tunnels do not have sufficient backup bandwidth, no consideration is
given to the type of data that the LSP is carrying. For example, a voice LSP may not be protected unless
it is signaled before a data LSP. To prioritize backup tunnel usage, see the “Backup Protection
Figure 7 Choosing from Among Multiple Backup Tunnels
T1
T2
Global pool, unlimited T3
Subpool 100 T4
Subpool 50
Subpool 10 T5
Subpool 100
LSP subpool R1 R2 R3
59560
bandwidth,
20 units
In this example, an LSP requires 20 units (kilobits per second) of sub-pool backup bandwidth. The best
backup tunnel is selected as follows:
1. Backup tunnels T1 through T4 are considered first because they terminate at the NNHOP.
2. Tunnel T4 is eliminated because it has only ten units of sub-pool backup bandwidth.
3. Tunnel T1 is eliminated because it protects only LSPs using global-pool bandwidth.
13
4. Tunnel T3 is chosen over T2 because, although both have sufficient backup bandwidth, T3 has the
least backup bandwidth available (leaving the most backup bandwidth available on T2).
5. Tunnels T5 and T6 need not be considered because they terminate at an NHOP, and therefore are
less desirable than T3, which terminates at an NNHOP.
Promotion
After a backup tunnel has been chosen for an LSP, conditions may change that will cause us to reevaluate
this choice. This reevaluation, if successful, is called promotion. Such conditions may include:
1. A new backup tunnel comes up.
2. The currently chosen backup tunnel for this LSP goes down.
3. A backup tunnel’s available backup bandwidth increases. For example, an LSP protected by the
tunnel has been reoptimized by the headend to use another path.
For cases 1 and 2, the LSP’s backup tunnel is evaluated immediately. Case 3 is addressed by periodically
reevaluating LSP-to-backup tunnel mappings. By default, background reevaluation is performed every
5 minutes. This interval is configurable via the mpls traffic-eng fast-reroute timers command.
Backup Protection Preemption Algorithms

When you set the “bandwidth protection desired” bit for an LSP, the LSP has a higher right to select
backup tunnels that provide bandwidth protection and it can preempt other LSPs that do not have that
bit set.
If there is insufficient backup bandwidth on NNHOP backup tunnels but not on NHOP backup tunnels,
the bandwidth-protected LSP does not preempt NNHOP LSPs; it uses NHOP protection.
If there are multiple LSPs using a given backup tunnel and one or more must be demoted to provide
bandwidth, there are two user-configurable methods (algorithms) that the router can use to determine
which LSPs are demoted:
• Minimize amount of bandwidth that is wasted.
• Minimize the number of LSPs that are demoted.
For example, If you need ten units of backup bandwidth on a backup tunnel, you can demote one of the
following:
• A single LSP using 100 units of bandwidth—Makes available more bandwidth than needed, but
results in lots of waste
• Ten LSPs, each using one unit of bandwidth—Results in no wasted bandwidth, but affects more
LSPs
The default algorithm is to minimize the number of LSPs that are demoted. To change the algorithm to
minimize the amount of bandwidth that is wasted, enter the mpls traffic-eng fast-reroute
backup-prot-preemption optimize-bw command.
Bandwidth Protection Considerations
There are numerous ways in which bandwidth protection can be ensured. Table 2 describes the
advantages and disadvantages of three methods.
14
Table 2 Bandwidth Protection Methods
Method Advantages Disadvantages

Reserve bandwidth for It is simple. It is a challenge to allow bandwidth
backup tunnels explicitly. sharing of backup tunnels
protecting against independent
failures.
Use backup tunnels that are It provides a way to share It may be complicated to determine
signaled with zero bandwidth. bandwidth used for protection the proper placement of zero
against independent failures, so bandwidth tunnels.
it ensures more economical
bandwidth usage.
Backup bandwidth It ensures bandwidth protection An LSP that does not have backup
protection. for voice traffic. bandwidth protection can be
demoted at any time if there is not
enough backup bandwidth and an
LSP that has backup bandwidth
protection needs bandwidth.
Cisco implementation of FRR does not mandate a particular approach, and it provides the flexibility to
use any of the above approaches. However, given a range of configuration choices, be sure that the
choices are constant with a particular bandwidth protection strategy.
The following sections describe some important issues in choosing an appropriate configuration:
• Using Backup Tunnels with Explicitly Signaled Bandwidth, page 15
• Using Backup Tunnels Signaled with Zero Bandwidth, page 16
Using Backup Tunnels with Explicitly Signaled Bandwidth

Two bandwidth parameters must be set for a backup tunnel:
• Actual signaled bandwidth
• Backup bandwidth
To signal bandwidth requirements of a backup tunnel, configure the bandwidth of the backup tunnel by
using the tunnel mpls traffic-eng bandwidth command.
To configure the backup bandwidth of the backup tunnel, use the tunnel mpls traffic-eng backup-bw
command.
The signaled bandwidth is used by the LSRs on the path of the backup tunnel to perform admission
control and do appropriate bandwidth accounting.
The backup bandwidth is used by the point of local repair (PLR) (that is, the headend of the
backup tunnel) to decide how much primary traffic can be rerouted to this backup tunnel if there is a
failure.
Both parameters need to be set to ensure proper operation. The numerical value of the signaled
bandwidth and the backup bandwidth should be the same.
15
Protected Bandwidth Pools and the Bandwidth Pool from Which the Backup Tunnel Reserves Its Bandwidth
The tunnel mpls traffic-eng bandwidth command allows you to configure the following:
• Amount of bandwidth a backup tunnel reserves
• The DS-TE bandwidth pool from which the bandwidth needs to be reserved
Note Only one pool can be selected (that is, the backup tunnel can explicitly reserve bandwidth from either
the global pool or the subpool, but not both).
The tunnel mpls traffic-eng backup-bw command allows you to specify the bandwidth pool to which
the traffic must belong for the traffic to use this backup tunnel. Multiple pools are allowed.
There is no direct correspondence between the bandwidth pool that is protected and the bandwidth pool
from which the bandwidth of the backup tunnel draws its bandwidth.
Bandwidth protection for 10 Kbps of subpool traffic on a given link can be achieved by configuring any
of the following command combinations:
• tunnel mpls traffic-eng bandwidth sub-pool 10
tunnel mpls traffic-eng backup-bw sub-pool 10
• tunnel mpls traffic-eng bandwidth global-pool 10
tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool unlimited
tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool 30
Using Backup Tunnels Signaled with Zero Bandwidth

Frequently it is desirable to use backup tunnels with zero signaled bandwidth, even when bandwidth
protection is required. It may seem that if no bandwidth is explicitly reserved, no bandwidth guarantees
can be provided. However, that is not necessarily true.
In the following situation:
• Only link protection is desired.
• Bandwidth protection is desired only for sub-pool traffic.
For each protected link AB with a maximum reservable subpool value of n, there may be a path from
node A to node B such that the difference between the maximum reservable global and the maximum
reservable subpool is at least the value of n. If it is possible to find such paths for each link in the
network, you can establish all the backup tunnels along such paths without any bandwidth reservations.
If there is a single link failure, only one backup tunnel will use any link on its path. Because that path
has at least n available bandwidth (in the global pool), assuming that marking and scheduling is
configured to classify the subpool traffic into a priority queue, the subpool bandwidth is guaranteed.
This approach allows sharing of the global pool bandwidth between backup tunnels protecting
independent link failures. The backup tunnels are expected to be used for only a short period of time
after a failure (until the headends of affected LSPs reroute those LSPs to other paths with available
subpool bandwidth). The probability of multiple unrelated link failures is very small (in the absence of
node or shared risk link group (SRLG) failures, which result in multiple link failures). Therefore, it is
reasonable to assume that link failures are in practice independent with high probability. This
“independent failure assumption” in combination with backup tunnels signaled without explicit
bandwidth reservation enables efficient bandwidth sharing that yields substantial bandwidth savings.
16
How to Configure MPLS Traffic Engineering—Fast Reroute (FRR) Link and Node Protection
Backup tunnels protecting the subpool traffic do now draw bandwidth from any pool. Primary traffic
using the global pool can use the entire global pool, and primary traffic using the subpool can use the
entire subpool. Yet, subpool traffic has a complete bandwidth guarantee if there is a single link failure.
A similar approach can be used for node and SRLG protection. However, the decision of where to put
the backup tunnels is more complicated because both node and SRLG failures effectively result in the
simultaneous failure of several links. Therefore, the backup tunnels protecting traffic traversing all
affected links cannot be computed independently of each other. The backup tunnels protecting groups of
links corresponding to different failures can still be computed independently of each other, which results
in similar bandwidth savings.
Signaled Bandwidth Versus Backup Bandwidth

Backup bandwidth is used locally (by the router that is the headend of the backup tunnel) to determine
which, and how many, primary LSPs can be rerouted on a particular backup tunnel. The router ensures
that the combined bandwidth requirement of these LSPs does not exceed the backup bandwidth.
Therefore, even when the backup tunnel is signaled with zero bandwidth, the backup bandwidth must be
configured with the value corresponding to the actual bandwidth requirement of the traffic protected by
this backup tunnel. Unlike the case when bandwidth requirements of the backup tunnels are explicitly
signaled, the value of the signaled bandwidth (which is zero) is not the same value as the backup
bandwidth.
How to Configure MPLS Traffic Engineering—Fast Reroute

(FRR) Link and Node Protection
This section assumes that you want to add FRR protection to a network in which MPLS TE LSPs are
configured.
• Enabling Fast Reroute on LSPs (required)
• Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop (required)
• Assigning Backup Tunnels to a Protected Interface (required)
• Associating Backup Bandwidth and Pool Type with a Backup Tunnel (optional)
• Configuring Backup Bandwidth Protection (optional)
• Configuring an Interface for Fast Link and Node Failure Detection (optional)
• Verifying That Fast Reroute Is Operational (optional)
Enabling Fast Reroute on LSPs

LSPs can use backup tunnels only if they have been configured as fast reroutable. To do this, perform
the following task. Enter the commands at the headend of each LSP.
SUMMARY STEPS
1. enable
17
4. tunnel mpls traffic-eng fast-reroute [bw-protect]

5. exit
6. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface tunnel number Enters interface configuration mode for the specified
tunnel.
Example:
Step 4 tunnel mpls traffic-eng fast-reroute Enables an MPLS TE tunnel to use an established backup
[bw-protect] tunnel if there is a link or node failure.
Example:
fast-reroute bw-protect
configuration mode.
Example:
EXEC mode.
Example:
Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop

Creating a backup tunnel is basically no different from creating any other tunnel. To create a backup
tunnel to the next hop or to the next-next hop, enter the following commands on the node that will be the
headend of the backup tunnel (that is, the node whose downstream link or node may fail). The node on
which you enter these commands must be a supported platform. See the “Finding Feature Information”
section on page 1.
SUMMARY STEPS
1. enable
18

4. ip unnumbered interface-type interface-number
7. tunnel mpls traffic-eng path-option [protect] number {dynamic | explicit | {name path-name |
path-number}} [lockdown]
8. exit
9. ip explicit-path name word
10. exclude-address ip-address
11. exit
12. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface tunnel number Creates a new tunnel interface and enters interface
configuration mode.
Example:
Step 4 ip unnumbered interface-type interface-number Gives the tunnel interface an IP address that is the same as
that of interface Loopback0.
Example: Note This command is not effective until Lookback0 has
Router(config-if)# ip unnumbered loopback 0 been configured with an IP address.
Step 5 tunnel destination ip-address Specifies the IP address of the device where the tunnel will
terminate. This address should be the router ID of the
device that is the NHOP or NNHOP of LSPs to be
Example:
protected.
Step 6 tunnel mode mpls traffic-eng Sets the encapsulation mode of the tunnel to MPLS TE.
Example:
19
Command Purpose
Step 7 tunnel mpls traffic-eng path-option [protect] Configures a path option for an MPLS TE tunnel. Enters
preference-number {dynamic | explicit | {name router configuration mode.
path-name | path-number}}[lockdown]
Example:
path-option 10 explicit avoid-protected-link
configuration mode.
Example:
Step 9 ip explicit-path name word Enters the command mode for IP explicit paths and creates
the specified path.
Example:
Router(config)# ip explicit-path name
avoid-protected-link
Step 10 exclude-address ip-address For link protection, specify the IP address of the link to be
protected. For node protection, specify the router ID of the
node to be protected.
Example:
Router(cfg-ip-expl-path)# exclude-address Note Backup tunnel paths can be dynamic or explicit and
10.3.3.3 they do not have to use exclude-address. Because
backup tunnels must avoid the protected link or
node, it is convenient to use the exclude-address
command.
Note When using the exclude-address command to

specify the path for a backup tunnel, you must
exclude an interface IP address to avoid a link
(for creating an NHOP backup tunnel), or a router
ID address to avoid a node (for creating an NNHOP
backup tunnel).
Step 11 exit Exits IP Explicit Path mode and enters global configuration
mode.
Example:
Router(cfg-ip-expl-path)# exit
EXEC mode.
Example:
Assigning Backup Tunnels to a Protected Interface

To assign one or more backup tunnels to a protected interface, perform the following task.
Enter the commands on the node that will be the headend of the backup tunnel (that is, the node whose
downstream link or node may fail). The node on which you enter these commands must be a supported
platform. See the “Finding Feature Information” section on page 1.
20
Note You must configure the interface to have an IP address and to enable the MPLS TE tunnel feature.
SUMMARY STEPS
1. enable
4. mpls traffic-eng backup-path tunnel interface
5. exit
6. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Example:
Router(config)# interface POS 0/1/0
Step 4 mpls traffic-eng backup-path tunnel interface Allows LSPs going out this interface to use this backup
tunnel if there is a link or node failure.
Example: Note You can enter this command multiple times to
Router(config-if)# mpls traffic-eng backup-path associate multiple backup tunnels with the same
tunnel 2 protected interface.
configuration mode.
Example:
EXEC mode.
Example:
21
Associating Backup Bandwidth and Pool Type with a Backup Tunnel

To associate backup bandwidth with a backup tunnel and designate the type of LSP that can use a backup
tunnel, perform the following task.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng backup-bw {bandwidth | [sub-pool {bandwidth | Unlimited}]
[global-pool {bandwidth | Unlimited}]}
5. exit
6. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
tunnel.
Example:
Step 4 tunnel mpls traffic-eng backup-bw {bandwidth | Associates bandwidth with a backup tunnel and designates
[sub-pool {bandwidth | Unlimited}] [global-pool whether LSPs that allocate bandwidth from the specified
{bandwidth | Unlimited}]}
pool can use the tunnel.
Example:
backup-bw sub-pool 1000
configuration mode.
Example:
EXEC mode.
Example:
22
Configuring Backup Bandwidth Protection

To configure backup bandwidth protection, perform the following task.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng-fast-reroute [bw-protect]
5. exit
6. mpls traffic-eng fast-reroute backup-prot-preemption [optimize-bw]
7. exit
DETAILED STEPS

Example:
Router> enable
Step 2 configure terminal Enters interface configuration mode.
Example:
tunnel.
Example:
Step 4 tunnel mpls traffic-eng fast-reroute Enables an MPLS TE tunnel to use an established backup
[bw-protect] tunnel in the event of a link or node failure.
• The bw-protect keyword gives an LSP priority for
Example: using backup tunnels with bandwidth protection.
Router(config-if)# tunnel mpls traffic-eng Enters global configuration mode.
fast-reroute bw-protect
configuration mode.
Example:
23
Step 6 mpls traffic-eng fast-reroute Changes the backup protection preemption algorithm from
backup-prot-preemption [optimize-bw] minimize the number of LSPs that are demoted to minimize
the amount of bandwidth that is wasted.
Example:
Router(config)# mpls traffic-eng fast-reroute
backup-prot-preemption optimize-bw
EXEC mode.
Example:
Configuring an Interface for Fast Link and Node Failure Detection

To configure an interface for fast link and node failure detection, enter the following commands.
SUMMARY STEPS
1. enable
4. pos ais-shut
5. pos report {b1-tca | b2-tca | b3-tca | lais | lrdi | pais | plop | prdi | rdool | sd-ber
| sf-ber | slof | slos}
6. exit
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 4 pos ais-shut Sends the line alarm indication signal (LAIS) when the POS
interface is placed in any administrative shutdown state.
Example:
Router(config-if)# pos ais-shut
24
Step 5 pos report {b1-tca | b2-tca | b3-tca | lais | Permits selected SONET alarms to be logged to the console
lrdi | pais | plop | prdi | rdool | sd-ber | for a POS interface.
sf-ber | slof | slos}
Example:
Router(config-if)# pos report lrdi
configuration mode.
Example:
EXEC mode.
Example:
Verifying That Fast Reroute Is Operational

To verify that FRR can function, perform the following task.
SUMMARY STEPS
Note To determine if FRR has been configured correctly, perform Steps 1 and 2.
Note If you created LSPs and performed the required configuration tasks but do not have operational backup
tunnels (that is, the backup tunnels are not up or the LSPs are not associated with those backup tunnels),
perform Step 3.
1. show mpls traffic-eng tunnels brief

2. show ip rsvp sender detail
3. show mpls traffic-eng fast-reroute database
4. show mpls traffic-eng tunnels backup
6. show ip rsvp reservation
DETAILED STEPS
Step 1 show mpls traffic-eng tunnels brief

Use this command to verify that backup tunnels are up:
Router# show mpls traffic-eng tunnels brief
Following is sample output from the show mpls traffic-eng tunnels brief command:
Signalling Summary:
LSP Tunnels Process: running
25
RSVP Process: running

Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 1706 seconds
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
Router_t1 10.112.0.12 - PO1/0/1 up/up
Router_t2 10.112.0.12 - unknown up/down
Router_t3 10.112.0.12 - unknown admin-down
Router_t2000 10.110.0.10 - PO1/0/1 up/up
Displayed 5 (of 5) heads, 0 (of 0) midpoints, 0 (of 0) tails
Step 2 show ip rsvp sender detail

Use this command to verify that LSPs are protected by the appropriate backup tunnels.
Following is sample output from the show ip rsvp sender detail command when the command is entered
at the PLR before a failure.
Router# show ip rsvp sender detail
PATH:
Tun Dest: 10.10.0.6 Tun ID: 100 Ext Tun ID: 10.10.0.1
Tun Sender: 10.10.0.1 LSP ID: 31
Path refreshes:
arriving: from PHOP 10.10.7.1 on Et0/0 every 30000 msecs
Session Attr:
Setup Prio: 7, Holding Prio: 7
Flags: (0x7) Local Prot desired, Label Recording, SE Style
session Name: R1_t100
ERO: (incoming)
10.10.7.2 (Strict IPv4 Prefix, 8 bytes, /32)
RRO:
10.10.7.1/32, Flags:0x0 (No Local Protection)
10.10.4.1/32, Flags:0x9 (Local Prot Avail/to NNHOP) !Available to NNHOP
Traffic params - Rate: 10K bits/sec, Max. burst: 1K bytes
Min Policed Unit: 0 bytes, Max Pkt Size 4294967295 bytes
Fast-Reroute Backup info:
Inbound FRR: Not active
Outbound FRR: No backup tunnel selected
Path ID handle: 50000416.
Incoming policy: Accepted. Policy source(s): MPLS/TE
Status: Proxy-terminated
Step 3 show mpls traffic-eng fast-reroute database

Enter the clear ip rsvp hello instance counters command to verify the following:
• MPLS TE FRR node protection has been enabled.
• A certain type of LSP can use a backup tunnel.
The following command output displays the LSPs that are protected:
Router# show mpls traffic-eng fast-reroute database
Tunnel head end item frr information:

Protected Tunnel In-label intf/label FRR intf/label Status
Tunne1l0 Tun pos1/0/0:Untagged Tu0:12304 ready
Prefix item frr information:

Prefix Tunnel In-label Out intf/label FRR intf/label Status
10.0.0.11/32 Tu110 Tun hd pos1/0/0:Untagged Tu0:12304 ready
LSP midpoint frr information:
26
LSP identifier In-label Out intf/label FRR intf/label Status

10.0.0.12 1 [459] 16 pos0/1/1:17 Tu2000:19 ready
If LDP is not enabled, separate prefix items are not shown because all prefixes then use a single rewrite.
To confirm that a particular IP prefix is FRR protected, even though it is not shown in this display, enter
it within the show mpls forwarding-table ip-address detail command. The final line of the display will
tell whether that prefix is protected:
Router# show mpls forwarding-table 10.0.0.11 detail

Tun hd Untagged 10.0.0.11/32 48 pos1/0/0 point2point
MAC/Encaps=4/8, MTU=1520, Tag Stack{22}
48D18847 00016000
No output feature configured
Fast Reroute Protection via (Tu0, outgoing label 12304)
Step 4 show mpls traffic-eng tunnels backup

For backup tunnels to be operational, the LSP must be reroutable. At the headend of the LSP, enter the
show run int tunnel tunnel-number command. The output should include the tunnel mpls traffic-eng
fast-reroute command. If it does not, enter this command for the tunnel.
On the router where the backup tunnels originate, enter the show mpls traffic-eng tunnels backup
command. Following is sample command output:
Router# show mpls traffic-eng tunnels backup
Router_t578
LSP Head, Tunnel578, Admin: up, Oper: up
Src 10.55.55.55, Dest 10.88.88.88, Instance 1
Fast Reroute Backup Provided:
Protected i/fs: PO0/1/0, PO0/1/1, PO0/1/3
Protected lsps: 1
Backup BW: any pool unlimited; inuse: 100 kbps
Router_t5710
LSP Head, Tunnel5710, Admin: admin-down, Oper: down
Protected i/fs: PO0/1/1
Protected lsps: 0
Router_t5711
LSP Head, Tunnel5711, Admin up, Oper: up
Src 10.55.55.55,, Dest 10.7.7.7, Instance 1
Protected lsps: 2
The command output will allow you to verify the following:

• Backup tunnel exists—Verify that there is a backup tunnel that terminates at this LSP’s NHOP or
NNHOP. Look for the LSP’s NHOP or NNHOP in the Dest field.
• Backup tunnel is up—To verify that the backup tunnel is up, look for “Up” in the State field.
• Backup tunnel is associated with LSP’s interface—Verify that the interface for the LSP is allowed
to use this backup tunnel. Look for the LSP’s output interface in the “protects” field list.
• Backup tunnel has sufficient bandwidth—If you restricted the amount of bandwidth a backup tunnel
can hold, verify that the backup tunnel has sufficient bandwidth to hold the LSPs that would use this
backup tunnel if there is a failure. The bandwidth of an LSP is defined by the line tunnel mpls
27
traffic-eng bandwidth at the headend of the LSP. To determine the available bandwidth on a backup
tunnel, look at the “cfg” and “inuse” fields. If there is insufficient backup bandwidth to
accommodate the LSPs that would use this backup tunnel in the event of a failure, create an
additional backup tunnel or increase the backup bandwidth of the existing tunnel by using the tunnel
mpls traffic-eng bandwidth command.
Note To determine the sufficient amount of bandwidth, offline capacity planning may be required.
• Backup tunnel has appropriate bandwidth type—If you restricted the type of LSPs (subpool or
global pool) that can use this backup tunnel, verify that the LSP is the appropriate type for the
backup tunnel. The type of the LSP is defined by the line tunnel mpls traffic-eng bandwidth at the
headend of this LSP. If this line contains the word “subpool”, then it uses sub-pool bandwidth;
otherwise, it uses global pool bandwidth. Verify that the type matches the type the backup tunnel
can hold by looking in the output of the tunnel mpls traffic-eng bandwidth command.
You also can enable debug by entering the debug ip rsvp fast-reroute command and the debug mpls
traffic-eng fast-reroute command on the router that is the headend of the backup tunnel. Then do the
following:
1. Enter the shutdown command for the primary tunnel.
2. Enter the no shutdown command for the primary tunnel.
3. View the debug output.



10.0.0.12 1 [459] 16 pos0/1/1:17 Tu2000:19 ready
Note If LDP is not enabled, separate prefix items are not shown because all prefixes then use a single rewrite.
Router# show mpls forwarding-table 10.0.0.11 detail

28

48D18847 00016000
Step 6 show ip rsvp reservation

Following is sample output from the show ip rsvp reservation command entered at the headend of a
primary LSP. Entering the command at the headend of the primary LSP shows, among other things, the
status of FRR (that is, local protection) at each hop this LSP traverses. The per-hop information is
collected in the Record Route Object (RRO) that travels with the Resv message from the tail to the head.
Router# show ip rsvp reservation detail
Reservation:
Next Hop: 172.17.1.2 on POS1/0/0
Label: 18 (outgoing)
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 0 bits/sec, Maximum Burst is 1K bytes
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes
RRO:
172.18.1.1/32, Flags:0x1 (Local Prot Avail/to NHOP)
Label subobject: Flags 0x1, C-Type 1, Label 18
172.19.1.1/32, Flags:0x0 (Local Prot Avail/In Use/Has BW/to NHOP)
Resv ID handle: CD000404.
Policy: Accepted. Policy source(s): MPLS/TE
Notice the following about the primary LSP:

• It has protection that uses a NHOP backup tunnel at its first hop.
• It has protection and is actively using an NHOP backup tunnel at its second hop.
• It has no local protection at its third hop.
The RRO display shows the following information for each hop:
• Whether local protection is available (that is, whether the LSP has selected a backup tunnel)
• Whether local protection is in use (that is, whether the LSP is currently using its selected backup
tunnel)
• Whether the selected backup tunnel is an NHOP or NNHOP backup tunnel
• Whether the backup tunnel used at this hop provides bandwidth protection
• LSPs Do Not Become Active; They Remain Ready
• Primary Tunnel Does Not Select Backup Tunnel That Is Up
• Enhanced RSVP Commands Display Useful Information
• RSVP Hello Detects When a Neighboring Node Is Not Reachable
• Hello Instances Have Not Been Created
29
• “No entry at index” (error may self-correct, RRO may not yet have propagated from downstream
node of interest)” Error Message Is Printed at the Point of Local Repair
• “Couldn’t get rsbs” (error may self-correct when Resv arrives)” Error Message Is Printed at the
Point of Local Repair
LSPs Do Not Become Active; They Remain Ready

At a PLR, LSPs transition from Ready to Active if one of the following events occurs:
• Primary interface goes down—If the primary interface (LSP’s outbound interface) goes down and
the LSP is ready to use a backup tunnel, the LSP will transition to the active state causing its data
to flow over the backup tunnel. On some platforms and interface types (for example, GSR POS
interfaces), there is fast interface-down logic that detects this event very quickly. On other platforms
where this logic does not exist, detection time is slower. On such platforms, it may be desirable to
enable RSVP Hello (see the next bulleted item, “Hellos detect next hop is down”).
• Hellos detect next hop is down—If Hellos are enabled on the primary interface (LSP’s outbound
interface), and the LSP’s next hop is no longer reachable, the next hop is declared down. This event
will cause the LSP to begin actively using its backup tunnel. Notice that a next hop will be declared
down even if the primary interface does not go down. For example, if the next hop stops responding
due to a reboot or software orr hardware problem, Hellos will trigger the LSPs using this next hop
to switch to their backup tunnels. Hellos can also help trigger FRR on interfaces such as Gigabit
Ethernet where the interface remains up but is unusable (due to lack of link-layer liveness detection
mechanisms).
Primary Tunnel Does Not Select Backup Tunnel That Is Up

If a backup tunnel is up, but it is not selected as a backup tunnel by the primary tunnel (LSP), enter the
following commands for the backup tunnel:
• shutdown
• no shutdown
Note If you change the status of a backup tunnel, the backup tunnel selection algorithm is rerun for
the backup tunnel. LSPs that have currently selected (that is, are ready to use) that backup tunnel
will be disassociated from it, and then reassociated with that backup tunnel or another backup
tunnel. This is generally harmless and usually results in mapping the same LSPs to that backup
tunnel. However, if any LSPs are actively using that backup tunnel, shutting down the backup
tunnel will tear down those LSPs.
Enhanced RSVP Commands Display Useful Information

The following RSVP commands have been enhanced to display information that can be helpful when
you are examining the FRR state or troubleshooting FRR:
• show ip rsvp request—Displays upstream reservation state (that is, information related to the Resv
messages that this node will send upstream).
• show ip rsvp reservation—Displays information about Resv messages received.
• show ip rsvp sender—Displays information about path messages being received.
These commands show control plane state; they do not show data state. That is, they show information
about RSVP messages (Path and Resv) used to signal LSPs. For information about the data packets
being forwarded along LSPs, use the show mpls forwarding command.
30
RSVP Hello Detects When a Neighboring Node Is Not Reachable

The RSVP Hello feature enables RSVP nodes to detect when a neighboring node is not reachable. Use
this feature when notification of link-layer failures is not available and unnumbered links are not used,
or when the failure detection mechanisms provided by the link layer are not sufficient for timely node
failure detection. Hello must be configured both globally on the router and on the specific interface to
be operational.
Hello Instances Have Not Been Created

If Hello instances have not been created, do the following:
• Determine if RSVP Hello has been enabled globally on the router. Enter the ip rsvp signalling hello
(configuration) command.
• Determine if RSVP Hello has been enabled on an interface that the LSPs traverse. Enter the ip rsvp
signalling hello (interface) command.
• Verify that at least one LSP has a backup tunnel by displaying the output of the show ip rsvp sender
command. A value of “Ready” indicates that a backup tunnel has been selected.
“No entry at index” (error may self-correct, RRO may not yet have propagated from downstream node of interest)”
Error Message Is Printed at the Point of Local Repair
FRR relies on a RRO in Resv messages arriving from downstream. Routers receiving path messages with
the SESSION_ATTRIBUTE bit indicating that the LSP is fast-reroutable should include an RRO in the
corresponding Resv messages.
If an LSP is configured for FRR, but the Resv arriving from a downstream router contains an incomplete
RRO, the “No entry at index (error may self-correct, RRO may not yet have propagated from
downstream node of interest)” message is printed. An incomplete RRO is one in which the NHOP or the
NNHOP did not include an entry in the RRO.
This error typically means that backup tunnels to the NHOP or the NNHOP cannot be selected for this
LSP because there is insufficient information about the NHOP or NNHOP due to the lack of an RRO
entry.
Occasionally there are valid circumstances in which this situation occurs temporarily and the problem
is self-corrected. If subsequent Resv messages arrive with a complete RRO, ignore the error message.
To determine whether the error has been corrected, display the RRO in Resv messages by entering the
clear ip rsvp hello instance counters command. Use an output filter keyword to display only the LSP
of interest.
“Couldn’t get rsbs” (error may self-correct when Resv arrives)” Error Message Is Printed at the Point of Local
Repair
The PLR cannot select a backup tunnel for an LSP until a Resv message has arrived from downstream.
When this error occurs, it typically means that something is wrong. For example, no reservation exists
for this LSP. You can troubleshoot this problem by using the debug ip rsvp reservation command to
enable debug.
Occasionally there are valid circumstances in which this error message occurs and there is no need for
concern. One such circumstance is when an LSP experiences a change before any Resv message has
arrived from downstream. Changes can cause a PLR to try to select a backup tunnel for an LSP, and the
selection will fail (causing this error message) if no Resv message has arrived for this LSP.
31
Configuration Examples for MPLS Traffic Engineering—Fast Reroute (FRR) Link and Node Protection
Configuration Examples for MPLS Traffic Engineering—Fast

Reroute (FRR) Link and Node Protection
• Enabling Fast Reroute for all Tunnels: Example, page 32
• Creating an NHOP Backup Tunnel: Example, page 33
• Creating an NNHOP Backup Tunnel: Example, page 33
• Assigning Backup Tunnels to a Protected Interface: Example, page 33
• Associating Backup Bandwidth and Pool Type with Backup Tunnels: Example, page 34
• Configuring Backup Bandwidth Protection: Example, page 34
• Configuring an Interface for Fast Link and Node Failure Detection: Example, page 34
• Configuring RSVP Hello and POS Signals: Example, page 34
The examples relate to the illustration shown in Figure 8.
Figure 8 Backup Tunnels
NHOP backup tunnel 1 NHOP backup tunnel 2

on R2, global unlimited on R2, subpool 1000
10.3.3.3 10.4.4.4
POS1/0//0
R1 R2 R3 R4
Tunnel 172.16.1.2
1000
Tunnel 172.16.1.3
2000
= Primary tunnels
192742
= Backup tunnels
Enabling Fast Reroute for all Tunnels: Example

On router R1, enter interface configuration mode for each tunnel to be protected (Tunnel 1000 and
Tunnel 2000). Enable these tunnels to use a backup tunnel in case of a link or node failure along their
paths.
Tunnel 1000 will use 10 units of bandwidth from the subpool.
32
Tunnel 2000 will use five units of bandwidth from the global pool. The “bandwidth protection desired”
bit has been set by specifying bw-prot in the tunnel mpls traffic-eng fast-reroute command.
Router(config-if)# tunnel mpls traffic-eng fast-reroute
Router(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 10

Router(config-if)# tunnel mpls traffic-eng fast-reroute bw-prot
Creating an NHOP Backup Tunnel: Example

On router R2, create an NHOP backup tunnel to R3. This backup tunnel should avoid using the link
172.1.1.2.
Router(config)# ip explicit-path name avoid-protected-link
Router(cfg-ip-expl-path)# exclude-address 172.1.1.2
Explicit Path name avoid-protected-link:
____1: exclude-address 172.1.1.2
Router(cfg-ip_expl-path)# end

Router(config-if)# ip unnumbered loopback0
Router(config-if)# tunnel mpls traffic-eng path-option 10 explicit avoid-protected-link
Creating an NNHOP Backup Tunnel: Example

On router R2, create an NNHOP backup tunnel to R4. This backup tunnel should avoid R3.
Router(config)# ip explicit-path name avoid-protected-node
Explicit Path name avoid-protected-node:

Router(config-if)# tunnel mpls traffic-eng path-option 10 explicit avoid-protected-node
Assigning Backup Tunnels to a Protected Interface: Example

On router R2, associate both backup tunnels with interface POS 1/0/0:
Router(config-if)# mpls traffic-eng backup-path tunnel 1
33
Associating Backup Bandwidth and Pool Type with Backup Tunnels: Example
Backup tunnel 1 is to be used only by LSPs that take their bandwidth from the global pool. It does not
provide bandwidth protection. Backup tunnel 2 is to be used only by LSPs that take their bandwidth from
the subpool. Backup tunnel 2 provides bandwidth protection for up to 1000 units.
Router(config-if)# tunnel mpls traffic-eng backup-bw global-pool Unlimited

Router(config-if)# tunnel mpls traffic-eng backup-bw sub-pool 1000
Configuring Backup Bandwidth Protection: Example

In the following example, backup bandwidth protection is configured:
Note This global configuration is required only to change the backup protection preemption algorithm from
minimize the number of LSPs that are demoted to minimize the amount of bandwidth that is wasted.
Router(config-if)# tunnel mpls traffic-eng fast-reroute bw-protect

Router(config)# mpls traffic-eng fast-reroute backup-prot-preemption optimize-bw
Configuring an Interface for Fast Link and Node Failure Detection: Example
In the following example, pos ais-shut is configured:
Router(config)# interface pos 0/0/0
In the following example, report lrdi is configured on OS interfaces:

Configuring RSVP Hello and POS Signals: Example

Hello must be configured both globally on the router and on the specific interface on which you need
FRR protection. To configure Hello, use the following configuration commands:
• ip rsvp signalling hello (configuration)—Enables Hello globally on the router.
• ip rsvp signalling hello (interface)—Enables Hello on an interface where you need FRR protection.
The following configuration commands are optional:
• ip rsvp signalling hello dscp—Sets the differentiated services code point (DSCP) value that is in
the IP header of the Hello message.
• ip rsvp signalling hello refresh misses—Specifies how many acknowledgments a node can miss in
a row before the node considers that communication with its neighbor is down.
• ip rsvp signalling hello refresh interval—Configures the Hello request interval.
• ip rsvp signalling hello statistics—Enables Hello statistics on the router.
34
To configure POS signaling for detecting FRR failures, enter the pos report all command or enter the
following commands to request individual reports:
• pos ais-shut
• pos report rdool
• pos report lais
• pos report lrdi
• pos report pais
• pos report prdi
• pos report sd-ber
The following sections provide references related to the MPLS Traffic Engineering—Fast Reroute Link
and Node Protection feature.
Related Documents
IS-IS • Cisco IOS IP Routing Protocols Command Reference
• Configuring a Basic IS-IS Network
Link protection MPLS TE: Link and Node Protection, with RSVP Hellos Support
(with Fast Tunnel Interface Down Detection)
OSPF • Cisco IOS IP Routing Protocols Command Reference
• Configuring OSPF
RSVP Cisco IOS Quality of Service Solutions Command Reference
Standards
Standards Title
draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt Fast ReRoute Extensions to RSVP-TE for LSP Tunnels
MIBs
MIBs MIBs Link
35
RFCs
RFCs Title
draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Description Link
36
Feature Information for MPLS Traffic Engineering—Fast Reroute Link and Node Protection
Feature Information for MPLS Traffic Engineering—Fast Reroute

Link and Node Protection
Table 3 lists the release history for this feature.
Table 3 Feature Information for MPLS Traffic Engineering—Fast Reroute Link and Node Protection

MPLS Traffic Engineering—Fast Reroute Cisco IOS XE The MPLS Traffic Engineering—Fast Reroute Link and
Link and Node Protection Release 2.3 Node Protection feature supports link protection
(backup tunnels that bypass only a single link of the
label-switched path (LSP), node protection (backup
tunnels that bypass next-hop nodes along LSPs), and the
following FRR features: backup tunnel support, backup
bandwidth protection, and RSVP Hellos.
This feature was integrated into Cisco IOS XE
Release 2.3.
feature:
• Features of MPLS Traffic Engineering—Fast
Reroute Link and Node Protection, page 6
• Enabling Fast Reroute on LSPs, page 17
• Creating a Backup Tunnel to the Next Hop or to the
Next-Next Hop, page 18
• Assigning Backup Tunnels to a Protected Interface,
page 20
37
Feature Information for MPLS Traffic Engineering—Fast Reroute Link and Node Protection
Table 3 Feature Information for MPLS Traffic Engineering—Fast Reroute Link and Node Protection

• Associating Backup Bandwidth and Pool Type with
a Backup Tunnel, page 22
• Configuring Backup Bandwidth Protection,
page 23
• Configuring an Interface for Fast Link and Node
Failure Detection, page 24
clear ip rsvp hello instance counters, clear ip rsvp
hello instance statistics, clear ip rsvp hello statistics,
debug ip rsvp hello, ip rsvp signalling hello
(configuration), ip rsvp signalling hello (interface),
ip rsvp signalling hello dscp, ip rsvp signalling hello
refresh interval, ip rsvp signalling hello refresh
misses, ip rsvp signalling hello statistics, mpls
traffic-eng backup-path tunnel, mpls traffic-eng
fast-reroute backup-prot-preemption, mpls
traffic-eng fast-reroute timers, show ip rsvp fast
bw-protect, show ip rsvp fast detail, show ip rsvp
hello, show ip rsvp hello instance detail, show ip rsvp
hello instance summary, show ip rsvp hello statistics,
show ip rsvp interface detail, show ip rsvp request,
show ip rsvp reservation, show ip rsvp sender, show
mpls traffic tunnel backup, show mpls traffic-eng
fast-reroute database, show mpls traffic-eng tunnels,
show mpls traffic-eng tunnels summary, tunnel mpls
traffic-eng backup-bw, tunnel mpls traffic-eng
fast-reroute.
38
Glossary
Glossary
backup bandwidth—The usage of NHOP and NNHOP backup tunnels to provide bandwidth protection
for rerouted LSPs.
backup tunnel—An MPLS TE tunnel used to protect other (primary) tunnels’ traffic when a link or node
failure occurs.
bandwidth—The available traffic capacity of a link.
storing route lookup.
organization.
Fast Reroute—Procedures that enable temporary routing around a failed link or node while a new LSP
is being established at the headend.
global pool—The total bandwidth allocated to an MPLS traffic engineering link or node.
headend—The router that originates and maintains a given LSP. This is the first router in the LSP’s path.
hop—Passage of a data packet between two network nodes (for example, between two routers).
instance—A Hello instance implements the RSVP Hello extensions for a given router interface address
and remote IP address. Active Hello instances periodically send Hello Request messages, expecting
Hello ACK messages in response. If the expected ACK message is not received, the active Hello instance
Intermediate System-to-Intermediate System—IS-IS. Link-state hierarchical routing protocol that
link—A point-to-point connection between adjacent nodes. There can be more than one link between
adjacent nodes. A link is a network communications channel consisting of a circuit or transmission path
and all related equipment between a sender and a receiver. Sometimes referred to as a line or a
transmission link.
limited backup bandwidth—Backup tunnels that provide bandwidth protection.
load balancing—A configuration technique that shifts traffic to an alternative link if a certain threshold
is exceeded on the primary link. Load balancing is similar to redundancy in that if an event causes traffic
to shift directions, alternative equipment must be present in the configuration. In load balancing, the
alternative equipment is not necessarily redundant equipment that operates only in the event of a failure.
LSP—label-switched path. A connection between two routers in which MPLS forwards the packets.
MPLS—Multiprotocol Label Switching. Packet-forwarding technology, used in the network core, that
applies data link layer labels to tell switching nodes how to forward data, resulting in faster and more
scalable forwarding than network layer routing normally can do.
MPLS global label allocation—There is one label space for all interfaces in the router. For example,
label 100 coming in one interface is treated the same as label 100 coming in a different interface.
NHOP—next hop. The next downstream node along an LSP’s path.
39
Glossary
NHOP backup tunnel—next-hop backup tunnel. Backup tunnel terminating at the LSP’s next hop
beyond the point of failure, and originating at the hop immediately upstream of the point of failure. It
bypasses a failed link, and is used to protect primary LSPs that were using this link before the failure.
NNHOP—next-next hop. The node after the next downstream node along an LSP’s path.
NNHOP backup tunnel—next-next-hop backup tunnel. Backup tunnel terminating at the LSP’s
next-next hop beyond the point of failure, and originating at the hop immediately upstream of the point
of failure. It bypasses a failed link or node, and is used to protect primary LSPs that were using this link
or node before the failure.
node—Endpoint of a network connection or a junction common to two or more lines in a network. Nodes
can be interconnected by links, and serve as control points in the network. Nodes can be processors,
controllers, or workstations.
OSPF—Open Shortest Path First. A link-state hierarchical Interior Gateway Protocol routing algorithm,
derived from the IS-IS protocol. OSPF features include least-cost routing, multipath routing, and load
balancing.
primary LSP—The last LSP originally signaled over the protected interface before the failure. The
primary LSP is the LSP before the failure.
primary tunnel—Tunnel whose LSP may be fast rerouted if there is a failure. Backup tunnels cannot
be primary tunnels.
promotion—Conditions, such as a new backup tunnel comes up, cause a reevaluation of a backup tunnel
that was chosen for an LSP. If the reevaluation is successful, it is called a promotion.
protected interface—An interface that has one or more backup tunnels associated with it.
redundancy—The duplication of devices, services, or connections so that, in the event of a failure, the
redundant devices, services, or connections can perform the work of those that failed.
RSVP—Resource Reservation Protocol. A protocol used for signaling requests (setting up reservations)
for Internet services by a customer before that customer is permitted to transmit data over that portion
of the network.
gets larger.
SRLG—shared risk link group. Sets of links that are likely to go down together.
tunnels.
sub-pool—The more restrictive bandwidth in an MPLS traffic engineering link or node. The subpool is
a portion of the link or node’s overall global pool bandwidth.
structure.
unlimited backup bandwidth—Backup tunnels that provide no bandwidth (best-effort) protection (that
is, they provide best-effort protection).
40
Glossary
countries.
coincidental.
41
Glossary
42
MPLS TE: Link and Node Protection, with RSVP
Hellos Support (with Fast Tunnel Interface Down
Detection)
First Published: October 10, 2004

The MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down
Detection) feature provides the following Fast Reroute (FRR) capabilities:
• Backup tunnel that terminates at the next-next hop router to protect both the downstream link and
node to protect link and node failures. There is no limit (except memory limitations) to the number
of backup tunnels that can protect a given interface. A backup tunnel is scalable because it can
protect multiple label switched paths (LSPs) and multiple interfaces.
• Backup bandwidth protection allows a priority to be assigned to backup tunnels for LSPs carrying
certain kinds of data (such as voice).
• Fast Tunnel Interface Down detection, which forces a “generic” interface tunnel (not specifically a
Fast Reroute tunnel) to become disabled immediately if the headend router detects a failed link on
an LSP.
• Resource Reservation Protocol (RSVP) Hellos, which are used to accelerate the detection of node
failures.

which each feature is supported, see the “Feature Information for MPLS TE: Link and Node Protection, with
RSVP Hellos Support (with Fast Tunnel Interface Down Detection)” section on page 40.
MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down Detection)
Contents
Contents
• Prerequisites for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Interface Down Detection), page 2
• Restrictions for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
• Information About MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast
Tunnel Interface Down Detection), page 3
• How to Configure MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast
• Configuration Examples for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with
Fast Tunnel Interface Down Detection), page 35
• Feature Information for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast
Prerequisites for MPLS TE: Link and Node Protection, with RSVP
Hellos Support (with Fast Tunnel Interface Down Detection)
Your network must support the following Cisco IOS XE features to support features described in this
document:
• MPLS
Your network must support at least one of the following protocols:
Restrictions for MPLS TE: Link and Node Protection, with RSVP
Hellos Support (with Fast Tunnel Interface Down Detection)
• Interfaces must use MPLS Global Label Allocation.
• Backup tunnel headend and tailend routers must implement FRR as described in this document.
• Backup tunnels are not protected. If an LSP is actively using a backup tunnel and the backup tunnel
fails, the LSP is torn down.
• LSPs that are actively using backup tunnels are not considered for promotion. So, if an LSP is
actively using a backup tunnel and a better backup tunnel becomes available, the active LSP is not
switched to the better backup tunnel.
2
Information About MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down
Information About MPLS TE: Link and Node Protection, with

RSVP Hellos Support (with Fast Tunnel Interface Down
Detection)
To configure the MPLS TE Link and Node Protection with RSVP Hellos Support (with Fast Tunnel
Interface Down Detection) feature, you need to understand the following concepts:
• Fast Tunnel Interface Down Detection, page 5
• Features of MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Fast Reroute
Fast Reroute (FRR) is a mechanism for protecting MPLS TE LSPs from link and node failures by locally
repairing the LSPs at the point of failure, allowing data to continue to flow on them while their headend
routers attempt to establish new end-to-end LSPs to replace them. FRR locally repairs the protected
LSPs by rerouting them over backup tunnels that bypass failed links or nodes.
Link Protection
Backup tunnels that bypass only a single link of the LSP’s path provide Link Protection. They protect
hop beyond the point of failure. Figure 1 illustrates an NHOP backup tunnel.
Figure 1 NHOP Backup Tunnel
Next-hop
backup tunnel
R1 R2 R3 R4
Next hop
59556
Primary Protected
LSP's path link
3
Node Protection
FRR provides Node Protection for LSPs. Backup tunnels that bypass next-hop nodes along LSP paths
are called next-next-hop (NNHOP) backup tunnels because they terminate at the node following the
the failed link in addition to the node.
Figure 2 illustrates an NNHOP backup tunnel.
Figure 2 NNHOP Backup Tunnel
Next-next hop
backup tunnel
R1 R2 R3 R4
Next-next hop
Primary Protected Protected

LSP's path link node
Backup tunnel
can protect against
link or node failures 59557
If an LSP is using a backup tunnel and something changes so that the LSP is no longer appropriate for
the backup tunnel, the LSP is torn down. Such changes include the following:
• Backup bandwidth of the backup tunnel is reduced.
• Backup bandwidth type of backup tunnel is changed to a type that is incompatible with the primary
LSP.
• Primary LSP is modified so that FRR is disabled. (The no mpls traffic-eng fast-reroute command
is entered.)
which backup tunnels to provide maximum bandwidth protection. That is, the router determines the best
way to map LSPs onto backup tunnels to maximize the number of LSPs that can be protected. For
information about mapping tunnels and assigning backup bandwidth, see the “Backup Tunnel Selection
Procedure” section on page 11.
4
LSPs that have the “bandwidth protection desired” bit set have a higher right to select backup tunnels
that provide bandwidth protection; that is, those LSPs can preempt other LSPs that do not have that bit
set. For more information, see the “Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth
Protection” section on page 8.
Fast Tunnel Interface Down Detection

Fast Tunnel Interface Down detection forces a “generic” interface tunnel (not specifically a Fast Reroute
tunnel) to become disabled immediately if the headend router detects a failed link on an LSP.
This feature is configured with the tunnel mpls traffic-eng interface down delay command. If this
feature is not configured, there is a delay before the tunnel becomes unoperational and before the traffic
uses an alternative path chosen by the headend/midpoint router to forward the traffic. This is acceptable
for data traffic, but not for voice traffic because it relies on the TE tunnel to go down as soon as the LSP
goes down.
RSVP Hello
RSVP Hellos are described in the following sections:
• RSVP Hello Operation, page 5
• Hello Instance, page 6
• Hello Commands, page 6
RSVP Hello Operation

RSVP Hello enables RSVP nodes to detect when a neighboring node is not reachable. This provides
node-to-node failure detection. When such a failure is detected, it is handled in a similar manner as a
link-layer communication failure.
RSVP Hello can be used by FRR when notification of link-layer failures is not available (for example,
with Fast Ethernet), or when the failure detection mechanisms provided by the link layer are not
sufficient for the timely detection of node failures.
A node running Hello sends a Hello Request to a neighboring node every interval. If the receiving node
is running Hello, it responds with Hello Ack. If four intervals pass and the sending node has not received
an Ack or it receives a bad message, the sending node declares that the neighbor is down and notifies
FRR.
There are two configurable parameters:
• Hello interval, by using the ip rsvp signalling hello refresh interval command
• Number of acknowledgment messages that are missed before the sending node declares that the
neighbor is down, by using the ip rsvp signalling hello refresh misses command
Note If a router’s CPU utilization is high due to frequent RSVP Hello processing, there may be false failures
due to Hello messages that are not transmitted.
5
Hello Instance
A Hello instance implements RSVP Hello for a given router interface address and remote IP address. A
Hello instance is expensive because of the large number of Hello requests that are sent and the strains
they put on the router resources. Therefore, create a Hello instance only when it is necessary and delete
it when it is no longer needed.
There are two types of Hello instances:
• Active Hello Instances
• Passive Hello Instances
Active Hello Instances

If a neighbor is unreachable when an LSP is ready to be fast rerouted, an active Hello instance is needed.
Create an active Hello instance for each neighbor with at least one LSP in this state.
Active Hello instances periodically send Hello Request messages, and expect Hello Ack messages in
response. If the expected Ack message is not received, the active Hello instance declares that the
neighbor (remote IP address) is unreachable (lost). LSPs traversing that neighbor may be fast rerouted.
If there is a Hello instance with no LSPs for an unreachable neighbor, do not delete the Hello instance.
Convert the active Hello instance to a passive Hello instance because there may be an active instance on
the neighboring router that is sending Hello requests to this instance.
Passive Hello Instances

Passive Hello instances respond to Hello Request messages (sending Ack messages), but do not initiate
Hello Request messages and do not cause LSPs to be fast rerouted. A router with multiple interfaces can
run multiple Hello instances to different neighbors or to the same neighbor.
A passive Hello instance is created when a Hello Request is received from a neighbor with a source IP
address/destination IP address pair in the IP header for which a Hello instance does not exist.
Delete passive instances if no Hello messages are received for this instance within 10 minutes.
Hello Commands
RSVP Hello comprises the following commands. For detailed command descriptions, refer to Cisco IOS
Multiprotocol Label Switching Command Reference.
• RSVP Hello configuration commands
• RSVP Hello statistics commands
• RSVP Hello show commands
• RSVP Hello debug commands
Features of MPLS TE: Link and Node Protection, with RSVP Hellos Support
(with Fast Tunnel Interface Down Detection)
MPLS TE Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down
Detection) includes the following features:
• Backup Tunnel Support, page 7
• Backup Bandwidth Protection, page 7
6
Backup Tunnel Support

Backup tunnel support has the following capabilities:
• Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR, page 7
• Multiple Backup Tunnels Can Protect the Same Interface, page 7
• Scalability, page 7
Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR

Backup tunnel that terminates at the next-next hop router to protect both the downstream link and node
to protect link and node failures. For more detailed information, see the “Node Protection” section on
page 4.
Multiple Backup Tunnels Can Protect the Same Interface

There is no limit (except memory limitations) to the number of backup tunnels that can protect a given
interface. In many topologies, support for Node Protection requires supporting multiple backup tunnels
per protected interface. These backup tunnels can terminate at the same destination or at different
destinations. That is, for a given protected interface, you can configure multiple NHOP or NNHOP
backup tunnels. This allows redundancy and load balancing.
In addition to being required for Node Protection, this feature provides the following benefits:
• Redundancy—If one backup tunnel is down, other backup tunnels protect LSPs.
• Increased backup capacity—If the protected interface is a high-capacity link and no single backup
path exists with an equal capacity, multiple backup tunnels can protect that one high-capacity link.
The LSPs using this link will fail over to different backup tunnels, allowing all of the LSPs to have
adequate bandwidth protection during failure (rerouting). If bandwidth protection is not desired, the
router spreads LSPs across all available backup tunnels (that is, there is load balancing across
backup tunnels). For a more detailed explanation, see the “Backup Tunnel Selection Procedure”
section on page 11.
Examples are shown in the “Backup Tunnels Terminating at Different Destinations” section on page 9
and the “Backup Tunnels Terminating at the Same Destination” section on page 10.
Scalability
A backup tunnel is scalable because it can protect multiple LSPs and multiple interfaces. It provides
many-to-one (N:1) protection, which has significant scalability advantages over one-to-one (1:1)
protection, where a separate backup tunnel must be used for each LSP needing protection.
Example of 1:1 protection: When 5,000 backup tunnels protect 5,000 LSPs, each router along the backup
path must maintain state for an additional 5,000 tunnels.
Example of N:1 protection: When one backup tunnel protects 5,000 LSPs, each router along the backup
path maintains one additional tunnel.
Backup Bandwidth Protection

Backup bandwidth protection has the following capabilities:
• Bandwidth Protection on Backup Tunnels, page 8
• Bandwidth Pool Specifications for Backup Tunnels, page 8
7
• Semidynamic Backup Tunnel Paths, page 8

• Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth Protection, page 8
Bandwidth Protection on Backup Tunnels

Rerouted LSPs not only have their packets delivered during a failure, but the quality of service can also
be maintained.
Bandwidth Pool Specifications for Backup Tunnels

You can restrict the types of LSPs that can use a given backup tunnel. Backup tunnels can be restricted
so that only LSPs using subpool bandwidth can use them or only LSPs that use global pool bandwidth
can use them. This allows different backup tunnels to be used for voice and data. Example: The backup
tunnel used for voice could provide bandwidth protection, and the backup tunnel used for data could
(optionally) not provide bandwidth protection.
Semidynamic Backup Tunnel Paths

The path of a backup tunnel can be configured to be determined dynamically. This can be done by using
the IP explicit address exclusion feature that was added in Release 12.0(14)ST. Using this feature,
semidynamic NHOP backup tunnel paths can be specified simply by excluding the protected link;
semidynamic NNHOP backup tunnel paths can be configured simply by excluding the protected node.
Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth Protection

In case there are not enough NHOP or NNHOP backup tunnels or they do not have enough backup
bandwidth to protect all LSPs, you can give an LSP priority in obtaining backup tunnels with bandwidth
protection. This is especially useful if you want to give LSPs carrying voice a higher priority than those
carrying data.
To activate this feature, enter the tunnel mpls traffic-eng fast-reroute bw-protect command to set the
“bandwidth protection desired” bit. See the configuration task “Enabling Fast Reroute on LSPs”. The
LSPs do not necessarily receive bandwidth protection. They have a higher chance of receiving
bandwidth protection if they need it.
LSPs that do not have the bandwidth protection bit set can be demoted. Demotion is when one or more
LSPs are removed from their assigned backup tunnel to provide backup to an LSP that has its bandwidth
protection bit set. Demotion occurs only when there is a scarcity of backup bandwidth.
When an LSP is demoted, it becomes unprotected (that is, it no longer has a backup tunnel). During the
next periodic promotion cycle, an attempt is made to find the best possible backup tunnels for all LSPs
that do not currently have protection, including the LSP that was demoted. The LSP may get protection
at the same level or a lower level, or it may get no protection.
For information about how routers determine which LSPs to demote, see the “Backup Protection
RSVP Hello
RSVP Hello enables a router to detect when a neighboring node has gone down but its interface to that
neighbor is still operational. This feature is useful when next-hop node failure is not detectable by link
layer mechanisms, or when notification of link-layer failures is not available. This allows the router to
switch LSPs onto its backup tunnels and avoid packet loss.
For a more detailed description of RSVP Hello, see the “RSVP Hello” section on page 5.
8
Fast Reroute Operation

• Fast Reroute Activation, page 9
• Backup Tunnels Terminating at Different Destinations, page 9
• Backup Tunnels Terminating at the Same Destination, page 10
• Backup Tunnel Selection Procedure, page 11
• Load Balancing on Limited-bandwidth Backup Tunnels, page 11
• Load Balancing on Unlimited-bandwidth Backup Tunnels, page 12
• Pool Type and Backup Tunnels, page 13
• Tunnel Selection Priorities, page 13
• Bandwidth Protection Considerations, page 15
Fast Reroute Activation

Three mechanisms cause routers to switch LSPs onto their backup tunnels:
• Interface down notification
• Loss of Signal
• RSVP Hello neighbor down notification
When a router’s link or neighboring node fails, the router often detects this failure by an interface down
notification. On a Packet over SONET (POS) interface, this notification is very fast. When a router
notices that an interface has gone down, it switches LPSs going out that interface onto their respective
backup tunnels (if any).
Unlike POS interfaces, Gigabit Ethernet does not have any alarms to detect link failures. If a link is down
due to a cut cable or because the remote end shuts its laser, the optics module (GBIC or SFPs) on the
Gigabit Ethernet card detects a loss of signal (LOS). The LOS is used as a mechanism to detect the
failure and begin the switchover.
RSVP Hellos can also be used to trigger FRR. If RSVP Hellos are configured on an interface, messages
are periodically sent to the neighboring router. If no response is received, Hellos declare that the
neighbor is down. This causes any LSPs going out that interface to be switched to their respective backup
tunnels.
Fast Reroute also works over ATM interfaces. The interfaces must use RSVP Hello to detect failures.
Backup Tunnels Terminating at Different Destinations

Figure 3 illustrates an interface that has multiple backup tunnels terminating at different destinations and
demonstrates why, in many topologies, support for Node Protection requires supporting multiple backup
tunnels per protected interface.
9
Figure 3 Backup Tunnels that Terminate at Different Destinations
R1 R2 R3
R4
= Primary tunnels
59558
= Backup tunnels
In this illustration, a single interface on R1 requires multiple backup tunnels. LSPs traverse the following
routes:
• R1, R2, R3
• R1, R2, R4
To provide protection if node R2 fails, two NNHOP backup tunnels are required: one terminating at R3
and one terminating at R4.
Backup Tunnels Terminating at the Same Destination

Figure 4 shows how backup tunnels terminating at the same location can be used for redundancy and
load balancing. Redundancy and load balancing work for both NHOP and NNHOP backup tunnels.
Figure 4 Backup Tunnels that Terminate at the Same Destination
Backup tunnel
T2
T1
R1 R2 R3
59559
Primary
LSP's path
In this illustration, there are three routers: R1, R2, and R3. At R1, there are two NNHOP backup tunnels
(T1 and T2) that go from R1 to R3 without traversing R2.
With redundancy, if R2 fails or the link from R1 to R2 fails, either backup tunnel can be used. If one
backup tunnel is down, the other can be used. LSPs are assigned to backup tunnels when the LSPs are
first established. This is done before a failure.
10
With load balancing, if neither backup tunnel has enough bandwidth to back up all LSPs, both tunnels
can be used. Some LSPs will use one backup tunnel, other LSPs will use the other backup tunnel. The
router decides the best way to fit the LSPs onto the backup tunnels.
Backup Tunnel Selection Procedure

When an LSP is signaled, each node along the LSP path that provides FRR protection for the LSP selects
a backup tunnel for the LSP to use if either of the following events occurs:
• The link to the next hop fails.
• The next hop fails.
By having the node select the backup tunnel for an LSP before a failure occurs, the LSP can be rerouted
onto the backup tunnel quickly if there is a failure.
For an LSP to be mapped to a backup tunnel, all of the following conditions must exist:
• The LSP is protected by FRR; that is, the LSP is configured with the tunnel mpls traffic-eng
fast-reroute command.
• The backup tunnel is up.
• The backup tunnel is configured to have an IP address, typically a loopback address.
• The backup tunnel is configured to protect this LSP’s outgoing interface; that is, the interface is
configured with the mpls traffic-eng backup-path command.
• The backup tunnel does not traverse the LSP’s protected interface.
• The backup tunnel terminates at the LSP’s NHOP or NNHOP. If it is an NNHOP tunnel, it does not
traverse the LSP’s NHOP.
• The bandwidth protection requirements and constraints, if any, for the LSP and backup tunnel are
met. For information about bandwidth protection considerations, see the “Bandwidth Protection”
section on page 11.
A backup tunnel can be configured to protect two types of backup bandwidth:
• Limited backup bandwidth—A backup tunnel provides bandwidth protection. The sum of the
bandwidth of all LSPs using this backup tunnel cannot exceed the backup tunnel’s backup
bandwidth. When assigning LSPs to this type of backup tunnel, sufficient backup bandwidth must
exist.
• Unlimited backup bandwidth—The backup tunnel does not provide any bandwidth protection (that
is, best-effort protection exists). There is no limit to the amount of bandwidth used by the LSPs that
are mapped to this backup tunnel. LSPs that allocate zero bandwidth can only use backup tunnels
that have unlimited backup bandwidth.
Load Balancing on Limited-bandwidth Backup Tunnels

There may be more than one backup tunnel that has sufficient backup bandwidth to protect a given LSP.
In this case, the router chooses the one that has the least amount of backup bandwidth available. This
algorithm limits fragmentation, maintaining the largest amount of backup bandwidth available.
11
Specifying limited backup bandwidth does not “guarantee” bandwidth protection if there is a link or
node failure. For example, the set of NHOP and NNHOP backup tunnels that gets triggered when an
interface fails may all share some link on the network topology, and this link may not have sufficient
bandwidth to support all LSPs using this set of backup tunnels.
In Figure 5, both backup tunnels traverse the same links and hop. When the link between routers R1 and
R4 fails, backup tunnels for primary tunnel 1 and primary tunnel 2 are triggered simultaneously. The two
backup tunnels may share a link in the network.
Figure 5 Backup Tunnels Share a Link
Backup tunnel for Backup tunnel for

primary tunnel 1 primary tunnel 2
Primary tunnel 2
82033
Failed link
In Figure 6, the backup tunnel for primary tunnel 1 may traverse routers R1-R2-R3-R4, and the backup
tunnel for primary tunnel 2 may traverse routers R4-R2-R3-R1. In this case, the link R2-R3 may get
overloaded if R1-R4 fails.
Figure 6 Overloaded Link
R2
R3
Primary tunnel 2
82032
Load Balancing on Unlimited-bandwidth Backup Tunnels

More than one backup tunnel, each having unlimited backup bandwidth, can protect a given interface.
In this case, when choosing a backup tunnel for a given LSP, the router chooses the backup tunnel that
has the least amount of backup bandwidth in use. This algorithm evenly distributes the LSPs across
backup tunnels based on LSP’s bandwidth. If an LSP is requesting zero bandwidth, the router chooses
the backup tunnel that is currently protecting the fewest LSPs.
12
Pool Type and Backup Tunnels

By default, a backup tunnel provides protection for LSPs that allocate from any pool (that is, global or
subpool). However, a backup tunnel can be configured to protect only LSPs that use global pool
bandwidth, or only those that use subpool bandwidth.
Tunnel Selection Priorities

• NHOP Versus NNHOP Backup Tunnels, page 13
• Promotion, page 14
• Backup Protection Preemption Algorithms, page 15
NHOP Versus NNHOP Backup Tunnels

More than one backup tunnel can protect a given LSP, where one backup tunnel terminates at the LSP’s
NNHOP, and the other terminates at the LSP’s NHOP. In this case, the router chooses the backup tunnel
that terminates at the NNHOP (that is, FRR prefers NNHOP over NHOP backup tunnels).
Table 1 lists the tunnel selection priorities. The first choice is an NNHOP backup tunnel that acquires its
bandwidth from a subpool or global pool, and has limited bandwidth. If there is no such backup tunnel,
the next choice (2) is a next-next hop backup tunnel that acquires a limited amount of bandwidth from
any pool. The preferences go from 1 (best) to 8 (worst), where choice 3 is for an NNHOP backup tunnel
with an unlimited amount of subpool or global pool bandwidth.
Table 1 Tunnel Selection Priorities
Backup Tunnel
Preference Destination Bandwidth Pool Bandwidth Amount
1 (Best) NNHOP Subpool or global pool Limited
2 NNHOP Any Limited
3 NNHOP Subpool or global pool Unlimited
4 NNHOP Any Unlimited
5 NHOP Subpool or global pool Limited
6 NHOP Any Limited
7 NHOP Subpool or global pool Unlimited
8 (Worst) NHOP Any Unlimited
Figure 7 shows an example of the backup tunnel selection procedure based on the designated amount of
global pool and subpool bandwidth currently available.
Note If NHOP and NNHOP backup tunnels do not have sufficient backup bandwidth, no consideration is
given to the type of data that the LSP is carrying. For example, a voice LSP may not be protected unless
it is signalled before a data LSP. To prioritize backup tunnel usage, see the “Backup Protection
13
Figure 7 Choosing from Among Multiple Backup Tunnels
T1
T2
Subpool 100 T4
Subpool 50
Subpool 10 T5
Subpool 100
LSP subpool R1 R2 R3
59560
bandwidth,
20 units
In this example, an LSP requires 20 units (kilobits per second) of subpool backup bandwidth. The best
backup tunnel is selected as follows:
1. Backup tunnels T1 through T4 are considered first because they terminate at the NNHOP.
2. Tunnel T4 is eliminated because it only has 10 units of subpool backup bandwidth.
3. Tunnel T1 is eliminated because it protects only LSPs using global pool bandwidth.
4. Tunnel T3 is chosen over T2 because, although both have sufficient backup bandwidth, T3 has the
least backup bandwidth available (leaving the most backup bandwidth available on T2).
5. Tunnels T5 and T6 need not be considered because they terminate at an NHOP, and therefore are
less desirable than T3, which terminates at an NNHOP.
Promotion
After a backup tunnel has been chosen for an LSP, conditions may change that will cause us to reevaluate
this choice. This reevaluation, if successful, is called promotion. Such conditions may include:
1. A new backup tunnel comes up.
2. The currently chosen backup tunnel for this LSP goes down.
3. A backup tunnel’s available backup bandwidth increases. For example, an LSP protected by the
tunnel has been reoptimized by the headend to use another path.
4. A backup tunnel’s available backup-bandwidth decreases.
For cases 1 and 2, the LSP’s backup tunnel is evaluated immediately. Cases 3 and 4 are addressed by
periodically reevaluating LSP-to-backup tunnel mappings. By default, background reevaluation is
performed every 5 minutes. This interval is configurable via the mpls traffic-eng fast-reroute timers
command.
The response to case 4 is as follows:
When the backup tunnel’s bandwidth is reduced, promotion will not be run so long as the remaining
bandwidth is greater than the sum of the bandwidths of all primary paths for which this tunnel is the
backup. This policy prevents unnecessary disruption of protection of the primary paths.
When the backup tunnel’s bandwidth does fall below the required bandwidth needed for it to substitute
for all primary paths to which it has been assigned, promotion is run.
14
Backup Protection Preemption Algorithms

When you set the “bandwidth protection desired” bit for an LSP, the LSP has a higher right to select
backup tunnels that provide bandwidth protection and it can preempt other LSPs that do not have that
bit set.
If there is insufficient backup bandwidth on NNHOP backup tunnels but not on NHOP backup tunnels,
the bandwidth-protected LSP does not preempt NNHOP LSPs; it uses NHOP protection.
If there are multiple LSPs using a given backup tunnel and one or more must be demoted to provide
bandwidth, there are two user-configurable methods (algorithms) that the router can use to determine
which LSPs are demoted.
• Minimize amount of bandwidth that is wasted.
• Minimize the number of LSPs that are demoted.
For example, If you need 10 units of backup bandwidth on a backup tunnel, you can demote one of the
following:
• A single LSP using 100 units of bandwidth—Makes available more bandwidth than needed, but
results in lots of waste
• Ten LSPs, each using one unit of bandwidth—Results in no wasted bandwidth, but affects more
LSPs
The default algorithm minimizes the number of LSPs that are demoted. To change the algorithm to
minimize the amount of bandwidth that is wasted, enter the mpls traffic-eng fast-reroute
backup-prot-preemption optimize-bw command.
Bandwidth Protection Considerations

There are numerous ways in which bandwidth protection can be ensured. Table 2 describes the
advantages and disadvantages of three methods.
Table 2 Bandwidth Protection Methods
Method Advantages Disadvantages

Reserve bandwidth for It is simple. It is a challenge to allow bandwidth
backup tunnels explicitly. sharing of backup tunnels
protecting against independent
failures.
Use backup tunnels that are It provides a way to share It may be complicated to determine
signaled with zero bandwidth. bandwidth used for protection the proper placement of zero
against independent failures, so bandwidth tunnels.
it ensures more economical
bandwidth usage.
Backup bandwidth protection Ensures bandwidth protection An LSP that does not have backup
for voice traffic. bandwidth protection can be
demoted at any time if there is not
enough backup bandwidth and an
LSP that has backup bandwidth
protection needs bandwidth.
15
Cisco implementation of FRR does not mandate a particular approach, and it provides the flexibility to
use any of the above approaches. However, given a range of configuration choices, be sure that the
choices are constant with a particular bandwidth protection strategy.
The following sections describe some important issues in choosing an appropriate configuration:
• Backup Tunnels with Explicitly Signaled Bandwidth, page 16
• Backup Tunnels Signaled with Zero Bandwidth, page 17
Backup Tunnels with Explicitly Signaled Bandwidth
There are two bandwidth parameters that must be set for a backup tunnel:
• actual signaled bandwidth
• backup-bandwidth
To signal bandwidth requirements of a backup tunnel, configure the bandwidth of the backup tunnel by
using the tunnel mpls traffic-eng bandwidth command.
To configure the backup bandwidth of the backup tunnel, use the tunnel mpls traffic-eng backup-bw
command.
The signaled bandwidth is used by the LSRs on the path of the backup tunnel to perform admission
control and do appropriate bandwidth accounting.
The backup bandwidth is used by the PLR (the headend of the backup tunnel) to decide how much
primary traffic can be rerouted to this backup tunnel if there is a failure.
Both parameters need to be set to ensure proper operation. The numerical value of the signaled
bandwidth and the backup-bandwidth should be the same.
Protected Bandwidth Pools and the Bandwidth Pool from Which the Backup Tunnel Reserves Its Bandwidth
The tunnel mpls traffic-eng bandwidth command allows you to configure the following:
• Amount of bandwidth a backup tunnel reserves
• The DS-TE bandwidth pool from which the bandwidth needs to be reserved
Note Only one pool can be selected (that is, the backup tunnel can explicitly reserve bandwidth from either
the global pool or the subpool, but not both).
The tunnel mpls traffic-eng backup-bw command allows you to specify the bandwidth pool to which
the traffic must belong for the traffic to use this backup tunnel. Multiple pools are allowed.
There is no direct correspondence between the bandwidth pool that is protected and the bandwidth pool
from which the bandwidth of the backup tunnel draws its bandwidth.
Example: In this example, assume the following:
• Bandwidth protection is desired only for subpool traffic, but the best-effort traffic using the global
pool does not require bandwidth protection.
• Scheduling is configured so that subpool traffic uses the priority queue, and global pool traffic is
served at a lower priority.
Bandwidth protection for 10 Kbps of subpool traffic on a given link can be achieved by any of the
following combinations:
• tunnel mpls traffic-eng bandwidth sub-pool 10
tunnel mpls traffic-eng backup-bw sub-pool 10
16

tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool unlimited
tunnel mpls traffic-eng backup-bw sub-pool 10 global-pool 30
Backup Tunnels Signaled with Zero Bandwidth
Frequently it is desirable to use backup tunnels with zero signaled bandwidth, even when bandwidth
protection is required. It may seem that if no bandwidth is explicitly reserved, no bandwidth guarantees
can be provided. However, that is not necessarily true.
In the following situation:
• Only link protection is desired.
• Bandwidth protection is desired only for subpool traffic.
For each protected link AB with a max reservable subpool value of S, there may be a path from node A
to node B such that the difference between max reservable global and max reservable subpool is at least
S. If it is possible to find such paths for each link in the network, you can establish all the backup tunnels
along such paths without any bandwidth reservations. If there is a single link failure, only one backup
tunnel will use any link on its path. Because that path has at least S of available bandwidth (in the
global pool), assuming that marking and scheduling is configured to classify the subpool traffic into a
priority queue, the subpool bandwidth is guaranteed.
The above approach allows sharing of the global pool bandwidth between backup tunnels protecting
independent link failures. The backup tunnels are expected to be used for only a short period of time
after a failure (until the headends of affected LSPs reroute those LSPs to other paths with available
subpool bandwidth). The probability of multiple unrelated link failures is very small (in the absence of
node or SRLG failures, which result in multiple link failures). Therefore, it is reasonable to assume that
link failures are in practice independent with high probability. This “independent failure assumption” in
combination with backup tunnels signaled without explicit bandwidth reservation enables efficient
bandwidth sharing that yields substantial bandwidth savings.
Backup tunnels protecting the subpool traffic do now draw bandwidth from any pool. Primary traffic
using the global pool can use the entire global pool, and primary traffic using the subpool can use the
entire subpool. Yet, subpool traffic has a complete bandwidth guarantee if there is a single link failure.
A similar approach can be used for node and SRLG protection. However, the decision of where to put
the backup tunnels is more complicated because both node and SRLG failures effectively result in the
simultaneous failure of several links. Therefore, the backup tunnels protecting traffic traversing all
affected links cannot be computed independently of each other. The backup tunnels protecting groups of
links corresponding to different failures can still be computed independently of each other, which results
in similar bandwidth savings.
Signaled Bandwidth Versus Backup Bandwidth

Backup bandwidth is used locally (by the router that is the headend of the backup tunnel) to determine
which, and how many, primary LSPs can be rerouted on a particular backup tunnel. The router ensures
that the combined bandwidth requirement of these LSPs does not exceed the backup bandwidth.
Therefore, even when the backup tunnel is signaled with zero bandwidth, the backup bandwidth must be
configured with the value corresponding to the actual bandwidth requirement of the traffic protected by
this backup tunnel. Unlike the case when bandwidth requirements of the backup tunnels are explicitly
signaled, the value of the signaled bandwidth (which is zero) is not the same value as the backup
bandwidth.
17
How to Configure MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down
How to Configure MPLS TE: Link and Node Protection, with

Detection)
This section assumes that you want to add FRR protection to a network in which MPLS TE LSPs are
configured.
Make sure that the following tasks have been performed before you perform the configuration tasks, but
you do not have to already have configured MPLS TE tunnels:
• Enabled MPLS TE on all relevant routers and interfaces
• Configured MPLS TE tunnels
To review how to configure MPLS TE tunnels, see the Cisco IOS XE Multiprotocol Label Switching
Configuration Guide.
The following sections describe how to use FRR to protect LSPs in your network from link or node
failures. Each task is identified as either required or optional.
• Enabling Fast Reroute on LSPs, page 18 (required)
• Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop, page 19 (required)
• Assigning Backup Tunnels to a Protected Interface, page 21 (required)
• Associating Backup Bandwidth and Pool Type with a Backup Tunnel, page 23 (optional)
• Configuring Backup Bandwidth Protection, page 24 (optional)
• Configuring an Interface for Fast Link and Node Failure Detection, page 25 (optional)
• Configuring an Interface for Fast Tunnel Interface Down, page 26 (optional)
• Verifying That Fast Reroute Is Operational, page 27 (optional)
Note You can perform the configuration tasks in any order.
Note An NNHOP backup tunnel must not go via the NHOP.

LSPs can use backup tunnels only if they have been configured as fast reroutable. To enable fast reroute
on an LSP, perform the following task. Enter the commands at the headend of each LSP.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng fast-reroute [bw-protect] [node-protect]
5. end
18
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface tunnel number Enters interface configuration mode for the
specified tunnel.
Example:
Step 4 tunnel mpls traffic-eng fast-reroute [bw-protect] Enables an MPLS TE tunnel to use an established
[node-protect] backup tunnel if there is a link or node failure.
Example:
fast-reroute bw-protect node-protect
Example:

To create a backup tunnel to the next hop or to the next-next hop, perform the following task. Enter the
commands on the node that will be the headend of the backup tunnel (that is, the node whose downstream
link or node may fail).
Creating a backup tunnel is basically no different from creating any other tunnel. None of the commands
below is new.
Note When using the exclude-address command to specify the path for a backup tunnel, you must exclude
an interface address to avoid a link (for creating an NHOP backup tunnel), or a router-ID address to
avoid a node (for creating an NNHOP backup tunnel).
SUMMARY STEPS
1. enable
5. tunnel destination A.B.C.D
19

8. ip explicit-path name name
9. exclude-address address
10. end
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 ip unnumbered type number Gives the tunnel interface an IP address that is the
same as that of interface Loopback0.
Example: Note This command is not effective until
Router(config-if)# ip unnumbered loopback0 Lookback0 has been configured with an IP
address.
Step 5 tunnel destination A.B.C.D Specifies the IP address of the device where the
tunnel will terminate.
Example: • That address should be the router ID of the
Router(config-if)# tunnel destination 10.3.3.3 device that is the NHOP or NNHOP of LSPs
to be protected.
Step 6 tunnel mode mpls traffic-eng Sets encapsulation mode of the tunnel to MPLS
TE.
Example:
Step 7 tunnel mpls traffic-eng path-option number {dynamic | Configures a path option for an MPLS TE tunnel.
explicit {name path-name | path-number}} [lockdown]
Example:
Router(config-if)# tunnel mpls traffic-eng path-option
300 explicit name avoid-protected-link
20
Command Purpose
Step 8 ip explicit-path name name Enters the subcommand mode for IP explicit paths
to create the named path.
Example:
Router(config)# ip explicit-path name
Step 9 exclude-address address For Link Protection, specifies the IP address of the
link to be protected.
Example: • For Node Protection, this command specifies
Router(cfg-ip-expl-path)# exclude-address 10.3.3.3 the router ID of the node to be protected.
Note Backup tunnel paths can be dynamic or
explicit and they do not have to use
exclude-address. Because backup tunnels
must avoid the protected link or node, it is
convenient to use an exclude-address.
Example:
Router(cfg-ip-expl-path)# end

To assign one or more backup tunnels to a protected interface, perform the following task. Enter the
following commands on the node that will be the headend of the backup tunnel (that is, the node whose
downstream link or node may fail).
SUMMARY STEPS
1. enable
4. mpls traffic-eng backup-path tunnel tunnel-id
5. end
21
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface type slot/subslot/port[.subinterface-number] Configures an interface type and enters interface
configuration mode.
Example: • The type argument is the type of interface to
Router(config)# interface POS1/0/0 be configured.
• The slot argument is the chassis slot number.
Refer to the appropriate hardware manual for
slot information. For SIPs, refer to the
platform-specific SPA hardware installation
guide or the corresponding “Identifying Slots
and Subslots for SIPs and SPAs” topic in the
platform-specific SPA software configuration
guide.
secondary slot number on a SIP where a SPA
is installed. The slash (/) is required.
installation guide and the corresponding
“Specifying the Interface Address on a SPA”
topic in the platform-specific SPA software
configuration guide for subslot information.
• The /port keyword and argument pair is the
port or interface number. The slash (/) is
required.
port information. For SPAs, refer to the
corresponding “Specifying the Interface
Address on a SPA” topics in the
guide
• The .subinterface-number keyword and
argument pair is the subinterface number in
the range 1 to 4294967293. The number that
precedes the period (.) must match the number
to which this subinterface belongs.
22
Command Purpose
Step 4 mpls traffic-eng backup-path tunnel tunnel-id Allows LSPs going out this interface to use this
backup tunnel if there is a link or node failure.
Example: Note You can enter this command multiple
Router(config-if)# mpls traffic-eng backup-path times to associate multiple backup tunnels
tunnel2 with the same protected interface.
Step 5e end Exits to privileged EXEC mode.
Example:

tunnel, perform the following task.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng backup-bw {bandwidth | [sub-pool {bandwidth | unlimited}]
[global-pool {bandwidth | unlimited}]} [any {bandwidth | unlimited}]
5. end
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
specified tunnel.
Example:
23
Command Purpose
Step 4 tunnel mpls traffic-eng backup-bw {bandwidth | Associates bandwidth with a backup tunnel and
[sub-pool {bandwidth | unlimited}][global-pool designates whether LSPs that allocate bandwidth
{bandwidth | unlimited}]} [any {bandwidth |
unlimited}]
from the specified pool can use the tunnel.
Example:
Router(config-if)# tunnel mpls traffic-eng backup-bw
sub-pool 1000
Step 5e end Exits to privileged EXEC mode.
Example:

To configure the backup bandwidth protection, perform the following task.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng-fast-reroute [bw-protect]
5. exit
6. mpls traffic-eng fast-reroute backup-prot-preemption [optimize-bw]
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
specified tunnel.
Example:
24
backup tunnel in the event of a link or node failure.
Example: • The bw-protect keyword gives an LSP
Router(config-if)# tunnel mpls traffic-eng priority for using backup tunnels with
fast-reroute bw-protect bandwidth protection.
Example:
Step 6 mpls traffic-eng fast-reroute backup-prot-preemption Changes the backup protection preemption
[optimize-bw] algorithm from minimize the number of LSPs that
are demoted to minimize the amount of bandwidth
Example: that is wasted.
Step 7e exit Exits to privileged EXEC mode.
Example:
Configuring an Interface for Fast Link and Node Failure Detection

To configure an interface for fast link and node failure detection, perform the following task.
SUMMARY STEPS
1. enable
4. pos ais-shut
5. pos report {b1-tca | b2-tca | b3-tca | lais | lrdi | pais | plop | prdi | rdool | sd-ber | sf-ber | slof |
slos}
6. end
DETAILED STEPS

Example:
Router> enable
Example:
25
Step 3 interface type slot/subslot/port[.subinterface-number] Configures an interface type and enters interface
configuration mode.
Example:
Step 4 pos ais-shut Sends the line alarm indication signal (LAIS)
when the Packet-over-SONET (POS) interface is
placed in any administrative shutdown state.
Example:
Step 5 pos report {b1-tca | b2-tca | b3-tca | lais | lrdi | Permits selected SONET alarms to be logged to
pais | plop | prdi | rdool | sd-ber | sf-ber | slof | the console for a POS interface.
slos}
Example:
Example:
Configuring an Interface for Fast Tunnel Interface Down

To configure an interface for fast tunnel interface down, perform the following steps.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng interface down delay time
5. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
26
Step 4 tunnel mpls traffic-eng interface down delay time Forces a tunnel to go down as soon as the headend
router detects that the LSP is down.
Example:
Router(config-if)# tunnel mpls traffic-eng interface
down delay 0
Example:

SUMMARY STEPS
perform Step 3.

DETAILED STEPS

Signalling Summary:
Forwarding: enabled
Router_t1 10.112.0.12 - PO2/0/1 up/up
Router_t2000 10.110.0.10 - PO2/0/1 up/up
27

at the PLR before a failure:
PATH:
Path refreshes:
arriving: from PHOP 10.10.7.1 on FE0/0/0 every 30000 msecs
Session Attr:
ERO: (incoming)
RRO:

• MPLS TE FRR Node Protection has been enabled.

Protected tunnel In-label Out intf/label FRR intf/label Status
Tunnel500 Tun hd AT2/0/0.100:Untagg Tu501:20 ready

10.0.0.8/32 Tu500 18 AT2/0/0.100:Pop ta Tu501:20 ready
10.0.8.8/32 Tu500 19 AT2/0/0.100:Untagg Tu501:20 ready
LSP midpoint item frr information:

If LDP is not enabled, separate prefix items are not shown because all prefixes then use a single rewrite.
28
Router# show mpls forwarding-table 10.0.0.11 32 detail

48D18847 00016000
The following command output displays the LSPs that are protected when the FRR primary tunnel is
over an ATM interface and the backup tunnel is over a POS interface. As shown in Figure 8, interface
ATM2/0/0.100 is protected by backup tunnel 501.
Figure 8 Protected LSPs
Primary tunnel 500
ATM2/0/0.100
R1 R2 R3 R4
POS 0/2/0
192746
Backup tunnel 501
This figure displays the protected LSPs:

• The primary tunnel is 500 and the path is R1 via ATM2/0/0.100 to R2, from R2 to R3, and from R3
to R4.
• The FRR backup tunnel is 501 and the path is R1 via POS0/2/0 to R2.
• The interface ATM2/0/0.100 is protected by the backup tunnel 501.

Tunnel500 Tun hd AT2/0/0.100:Untagg Tu501:20 ready

10.0.0.8/32 Tu500 18 AT2/0/0.100:Pop ta Tu501:20 ready

The following command output displays the LSPs that are protected when the FRR backup tunnel is over
an ATM interface:

Tunnel500 Tun hd PO0/2/0:Untagged Tu501:20 ready
29

10.0.0.8/32 Tu500 18 PO0/2/0:Pop tag Tu501:20 ready
10.0.8.8/32 Tu500 19 PO0/2/0:Untagged Tu501:20 ready
10.8.9.0/24 Tu500 22 PO0/2/0:Untagged Tu501:20 ready


The following conditions must exist for backup tunnels to be operational:
• LSP is reroutable—At the headend of the LSP, enter the show run int tunnel tunnel-number
command. The output should include the tunnel mpls traffic-eng fast-reroute command. If it does
not, enter this command for the tunnel.
Router_t578
Protected i/fs: PO1/0/0, PO1/1/0, PO0/3/3
Protected lsps: 1
Router_t5710
Protected lsps: 0
Router_t5711
Protected lsps: 2

• Backup tunnel is up—To verify that the backup tunnel is up, look for “Up” in the State field.
• Backup tunnel is associated with LSP’s I/F—Verify that the interface for the LSP is allowed to use
this backup tunnel. Look for the LSP’s output interface in the “protects” field list.
30
Note To determine how much bandwidth is sufficient, offline capacity planning may be required.
• Backup tunnel has appropriate bandwidth type—If you restricted the type of LSPs (subpool or
global pool) that can use this backup tunnel, verify that the LSP is the appropriate type for the
backup tunnel. The type of the LSP is defined by the line tunnel mpls traffic-eng bandwidth at the
headend of this LSP. If this line contains the word “subpool”, then it uses subpool bandwidth;
otherwise, it uses global pool bandwidth. Verify that the type matches the type the backup tunnel
can hold by looking in the output of the above command.
If none of the above actions works, enable debug by entering the debug ip rsvp fast-reroute command
and the debug mpls traffic-eng fast-reroute command on the router that is the headend of the backup
tunnel. Then do the following:



10.0.0.12 1 [459] 16 pos0/1/0:17 Tu2000:19 ready
Note If LDP is not enabled, separate prefix items are not shown because all prefixes then use a single rewrite.

48D18847 00016000
31
Step 6 show ip rsvp reservation

Following is sample output from the show ip rsvp reservation command entered at the headend of a
primary LSP. Entering the command at the head-end of the primary LSP shows, among other things, the
status of FRR (that is, local protection) at each hop this LSP traverses. The per-hop information is
Reservation:
Next Hop: 10.1.1.2 on POS1/0/0
RRO:

• It has protection that uses a NHOP backup tunnel at its first hop.
• Whether local protection is in use (that is, whether the LSP is currently using its selected backup
tunnel)
• LSPs Do Not Become Active; They Remain Ready, page 33
• Primary Tunnel Does Not Select Backup Tunnel That Is Up, page 33
• Enhanced RSVP Commands, page 33
• Hello Instances Have Not Been Created, page 34
• No entry at index (error may self-correct, RRO may not yet have propagated from downstream node
of interest)” Error Message Is Printed at the Point of Local Repair, page 34
32
• Couldn’t get rsbs (error may self-correct when Resv arrives)” Error Message Is Printed at the Point
of Local Repair, page 34
LSPs Do Not Become Active; They Remain Ready

At a PLR, LSPs transition from Ready to Active if one of the following events occurs:
• Primary interface goes down—If the primary interface (LSP’s outbound interface) goes down and
the LSP is ready to use a backup tunnel, the LSP will transition to the active state causing its data
to flow over the backup tunnel. On some platforms and interface types (for example, GSR POS
interfaces), fast interface-down logic has been added to detect this event very quickly. On other
platforms where this logic does not exist, detection time is slower. On such platforms, it may be
desirable to enable RSVP Hello (see the next bulleted item, “Hellos detect next hop is down”).
• Hellos detect next hop is down—If Hellos are enabled on the primary interface (LSP’s outbound
interface), and the LSP’s next hop is no longer reachable, the next hop is declared down. This event
will cause the LSP to begin actively using its backup tunnel. Notice that a next hop will be declared
down even if the primary interface does not go down. For example, if the next hop stops responding
due to a reboot or software/hardware problem, Hellos will trigger the LSPs using this next hop to
switch to their backup tunnels. Hellos can also help trigger FRR on interfaces such as Gigabit
Ethernet where the interface remains up but is unusable (due to lack of link-layer liveness detection
mechanisms).
Primary Tunnel Does Not Select Backup Tunnel That Is Up

If a backup tunnel is up, but it is not selected as a backup tunnel by the primary tunnel (LSP), enter the
following commands for the backup tunnel:
• shutdown
• no shutdown
Note If you change the status of a backup tunnel, the backup tunnel selection algorithm is rerun for the backup
tunnel. LSPs that have currently selected (that is, are ready to use) that backup tunnel will be
disassociated from it, and then reassociated with that backup tunnel or another backup tunnel. This is
generally harmless and usually results in mapping the same LSPs to that backup tunnel. However, if any
LSPs are actively using that backup tunnel, shutting down the backup tunnel will tear down those LSPs.
Enhanced RSVP Commands

The following RSVP commands have been enhanced to display information that can be helpful when
examining FRR state or when troubleshooting FRR:
• show ip rsvp request—Displays upstream reservation state (that is, information related to the Resv
messages that this node will send upstream).
• show ip rsvp reservation—Displays information about Resv messages received.
• show ip rsvp sender—Displays information about Path messages being received.
These commands show control plane state; they do not show data state. That is, they show information
about RSVP messages (Path and Resv) used to signal LSPs. For information about the data packets
being forwarded along LSPs, use the show mpls forwarding command.
33
RSVP Hello
The RSVP Hello feature enables RSVP nodes to detect when a neighboring node is not reachable. Use
this feature when notification of link-layer failures is not available and unnumbered links are not used,
or when the failure detection mechanisms provided by the link layer are not sufficient for timely node
failure detection. Hello must be configured both globally on the router and on the specific interface to
be operational.
Hello Instances Have Not Been Created

If Hello instances have not been created, do the following:
• Determine if RSVP Hello has been enabled globally on the router. Enter the ip rsvp signalling hello
(configuration) command.
• Determine if RSVP Hello has been enabled on an interface that the LSPs traverse. Enter the ip rsvp
signalling hello (interface) command.
• Verify that at least one LSP has a backup tunnel by viewing the output of the show ip rsvp sender
command. A value of “Ready” indicates that a backup tunnel has been selected.
No entry at index (error may self-correct, RRO may not yet have propagated from downstream node of interest)”
Error Message Is Printed at the Point of Local Repair
FRR relies on a Record Route Object (RRO) in Resv messages arriving from downstream. Routers
receiving Path messages with the SESSION_ATTRIBUTE bit indicating that the LSP is fast-reroutable
should include an RRO in the corresponding Resv messages.
If an LSP is configured for FRR, but the Resv arriving from a downstream router contains an incomplete
RRO, the “No entry at index (error may self-correct, RRO may not yet have propagated from
downstream node of interest)” message is printed. An incomplete RRO is one in which the NHOP or the
NNHOP did not include an entry in the RRO.
This error typically means that backup tunnels to the NHOP or the NNHOP cannot be selected for this
LSP because there is insufficient information about the NHOP or NNHOP due to the lack of an RRO
entry.
Occasionally there are valid circumstances in which this situation occurs temporarily and the problem
is self-corrected. If subsequent Resv messages arrive with a complete RRO, ignore the error message.
To determine whether the error has been corrected, view the RRO in Resv messages by entering the clear
ip rsvp hello instance counters command. Use an output filter keyword to view only the LSP of interest.
Couldn’t get rsbs (error may self-correct when Resv arrives)” Error Message Is Printed at the Point of Local Repair
The PLR cannot select a backup tunnel for an LSP until a Resv message has arrived from downstream.
When this error occurs, it typically means that something is truly wrong. For example, no reservation
exists for this LSP. You can troubleshoot this problem by using the debug ip rsvp reservation command
to enable debug.
Occasionally there are valid circumstances in which this error message occurs and there is no need for
concern. One such circumstance is when an LSP experiences a change before any Resv message has
arrived from downstream. Changes can cause a PLR to try to select a backup tunnel for an LSP, and the
selection will fail (causing this error message) if no Resv message has arrived for this LSP.
34
Configuration Examples for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Configuration Examples for MPLS TE: Link and Node Protection,

with RSVP Hellos Support (with Fast Tunnel Interface Down
Detection)
• Enabling Fast Reroute for All Tunnels: Example, page 35
• Creating an NNHOP Backup Tunnel: Example, page 36
• Configuring an Interface for Fast Link and Node Failure Detection: Example, page 37
• Configuring an Interface for Fast Tunnel Interface Down: Example, page 37
• Configuring RSVP Hello and POS Signals: Example, page 37
The examples relate to the illustration shown in Figure 9.

10.3.3.3 10.4.4.4
POS1/0/0
R1 R2 R3 R4
Tunnel 172.16.1.2
1000
Tunnel 172.16.1.3
2000
= Primary tunnels
192747
= Backup tunnels
Enabling Fast Reroute for All Tunnels: Example

On router R1, enter interface configuration mode for each tunnel to be protected (Tunnel 1000 and
Tunnel 2000). Enable these tunnels to use a backup tunnel in case of a link or node failure along their
paths.
Tunnel 1000 will use 10 units of bandwidth from the subpool.
35
Configuration Examples for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface
Tunnel 2000 will use 5 units of bandwidth from the global pool. The “bandwidth protection desired” bit
and the “node protection desired bit” have been set by specifying bw-prot and node-prot, respectively,
in the tunnel mpls traffic-eng fast-reroute command.

Router(config-if)# tunnel mpls traffic-eng fast-reroute bw-prot node-prot
Creating an NHOP Backup Tunnel: Example

On router R2, create an NHOP backup tunnel to R3. This backup tunnel should avoid using the link
10.1.1.2.

Router(config-if)# tunnel mode mpls traffic-eng0
Router(config-if)# tunnel mpls traffic-eng path-option explicit avoid-protected-link

On router R2, create an NNHOP backup tunnel to R4. This backup tunnel should avoid R3.

Router(config-if)# tunnel mpls traffic-eng path-option explicit avoid-protected-node

On router R2, associate both backup tunnels with interface POS1/0/0.
Router(config-if)# mpls traffic-eng backup-path tunnel1
36
Configuration Examples for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Backup tunnel 1 is to be used only by LSPs that take their bandwidth from the global pool. It does not
provide bandwidth protection. Backup tunnel 2 is to be used only by LSPs that take their bandwidth from
the subpool. Backup tunnel 2 provides bandwidth protection for up to 1000 units.


In the following example, backup bandwidth protection is configured.

Configuring an Interface for Fast Link and Node Failure Detection: Example
In the following example, pos ais-shut is configured:
In the following example, report lrdi is configured on OS interfaces:

Configuring an Interface for Fast Tunnel Interface Down: Example

In the following example, tunnel 1000 goes down as soon as the headend router detects that the LSP is
down:
Router(config-if)# tunnel mpls traffic-eng interface down delay 0
Configuring RSVP Hello and POS Signals: Example

Hello must be configured both globally on the router and on the specific interface on which you need
FRR protection. To configure Hello, use the following configuration commands:
• ip rsvp signalling hello (configuration)—Enables Hello globally on the router.
• ip rsvp signalling hello (interface)—Enables Hello on an interface where you need FRR protection.
The following configuration commands are optional:
37
• ip rsvp signalling hello dscp—Sets the DSCP value that is in the IP header of the Hello message.
• ip rsvp signalling hello refresh misses—Specifies how many acknowledgments a node can miss in
a row before the node considers that communication with its neighbor is down.
• ip rsvp signalling hello refresh interval—Configures the Hello request interval.
• ip rsvp signalling hello statistics—Enables Hello statistics on the router.
To configure POS signaling for detecting FRR failures, enter pos report all or enter the following
commands to request individual reports:
• pos ais-shut
• pos report rdool
• pos report lais
• pos report lrdi
• pos report pais
• pos report prdi
• pos report sd-ber
The following sections provide references related to the MPLS TE: Link and Node Protection, with
RSVP Hellos Support (with Fast Tunnel Interface Down Detection) feature.
Related Documents
RSVP commands • Cisco IOS Multiprotocol Label Switching Command Reference
• Cisco IOS Quality of Service Solutions Command Reference
Standards
Standards Title
38
MIBs
MIBs MIBs Link
RFCs
RFCs Title
RFC 4090 Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Description Link
39
Feature Information for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface
Feature Information for MPLS TE: Link and Node Protection, with
Detection)
Table 3 Feature Information for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Interface Down Detection

MPLS TE: Link and Node Protection, Cisco IOS XE The MPLS TE: Link and Node Protection, with RSVP
with RSVP Hellos Support (with Fast Release 2.3 Hellos Support (with Fast Tunnel Interface Down Detection)
Tunnel Interface Down Detection feature provides the following Fast Reroute (FRR)
capabilities:
• A backup tunnel terminates at the next-next hop router
to protect both the downstream link and node to protect
link and node failures. There is no limit (except memory
limitations) to the number of backup tunnels that can
protect a given interface. A backup tunnel is scalable
because it can protect multiple LSPs and multiple
interfaces.
• Backup bandwidth protection allows a priority to be
assigned to backup tunnels for LSPs carrying certain
kinds of data (such as voice).
• Fast Tunnel Interface Down detection, which forces a
“generic” interface tunnel (not specifically a Fast
Reroute tunnel) to become disabled immediately if the
headend router detects a failed link on an LSP.
• Resource Reservation Protocol (RSVP) Hellos, which
are used to accelerate the detection of node failures.
In Cisco IOS Release XE 2.3, this feature was implemented
Routers.
40
Feature Information for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface
Table 3 Feature Information for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Interface Down Detection (continued)

feature:
• Fast Tunnel Interface Down Detection, page 5
• Features of MPLS TE: Link and Node Protection, with
Detection), page 6
• Creating a Backup Tunnel to the Next Hop or to the
Next-Next Hop, page 19
• Assigning Backup Tunnels to a Protected Interface,
page 21
• Associating Backup Bandwidth and Pool Type with a
Backup Tunnel, page 23
• Configuring Backup Bandwidth Protection, page 24
• Configuring an Interface for Fast Link and Node Failure
Detection, page 25
• Configuring an Interface for Fast Tunnel Interface
Down, page 26
• Verifying That Fast Reroute Is Operational, page 27
The following command was introduced or modified: tunnel
mpls traffic-eng interface down delay.
41
Glossary
Glossary
for rerouted LSPs.
failure occurs.
organization.
is being established at the head end.
Gigabit Ethernet—Standard for a high-speed Ethernet, approved by the IEEE (Institute of Electrical
and Electronics Engineers) 802.3z standards committee in 1996.
global pool—The total bandwidth allocated to an MPLS Traffic Engineering link or node.
Hello ACK messages in response. If the expected Ack message is not received, the active Hello instance
Intermediate System-to-Intermediate System—IS-IS. Link-state hierarchical routing protocol that
adjacent nodes. A network communications channel consisting of a circuit or transmission path and all
related equipment between a sender and a receiver. Sometimes referred to as a line or a transmission link.
limited backup bandwidth—Backup tunnels that provide bandwidth protection.
load balancing—A configuration technique that shifts traffic to an alternative link if a certain threshold
is exceeded on the primary link. Load balancing is similar to redundancy in that if an event causes traffic
to shift directions, alternative equipment must be present in the configuration. In load balancing, the
alternative equipment is not necessarily redundant equipment that only operates in the event of a failure.
LSP—label switched path. A configured connection between two routers, in which label switching is
MPLS global label allocation—There is one label space for all interfaces in the router. For example,
label 100 coming in one interface is treated the same as label 100 coming in a different interface.
42
Glossary
can be interconnected by links, and serve as control points in the network. Computers on a network, or
any endpoint or a junction common to two or more lines in a network. Nodes can be processors,
balancing.
primary LSP—The last LSP originally signaled over the protected interface before the failure. The LSP
before the failure.
be primary tunnels.
promotion—Conditions, such as a new backup tunnel comes up, cause a reevaluation of a backup tunnel
that was chosen for an LSP. If the reevaluation is successful, it is called a promotion.
RSVP—Resource Reservation Protocol. An IETF protocol used for signaling requests (setting up
reservations) for Internet services by a customer before that customer is permitted to transmit data over
that portion of the network.
gets larger.
tunnels.
subpool—The more restrictive bandwidth in an MPLS Traffic Engineering link or node. The subpool is
structure.
43
Glossary
countries.
coincidental.
44
MPLS Traffic Engineering (TE): Path Protection

The MPLS Traffic Engineering (TE): Path Protection feature provides an end-to-end failure recovery
mechanism (that is, full path protection) for Multiprotocol Label Switching (MPLS) traffic engineering
(TE) tunnels.

which each feature is supported, see the see the “Feature Information for MPLS Traffic Engineering (TE):
Path Protection” section on page 18.
Contents
• Prerequisites for MPLS Traffic Engineering (TE): Path Protection, page 2
• Restrictions for MPLS Traffic Engineering (TE): Path Protection, page 2
• Information About MPLS Traffic Engineering (TE): Path Protection, page 2
• How to Configure MPLS Traffic Engineering (TE): Path Protection, page 4
• Configuration Examples for MPLS Traffic Engineering (TE): Path Protection, page 10
• Feature Information for MPLS Traffic Engineering (TE): Path Protection, page 18
Prerequisites for MPLS Traffic Engineering (TE): Path Protection
Prerequisites for MPLS Traffic Engineering (TE): Path Protection

• Ensure that your network supports MPLS TE, Cisco Express Forwarding, and Intermediate
System-to-Intermediate System (IS-IS) or Open Shortest Path First (OSPF).
• Enable MPLS.
• Configure TE on the routers.
• Configure a TE tunnel with a primary path option by using the tunnel mpls traffic-eng path-option
command.
• If your router supports SSO, configure Resource Reservation Protocol (RSVP) Graceful Restart in
full mode on the routers.
• If your router supports SSO, for NSF operation you must have configured SSO on the device.
Restrictions for MPLS Traffic Engineering (TE): Path Protection

• There can be only one secondary path for each primary path option.
• The secondary path will not be signaled with the FRR flag.
• Dynamic diverse paths are not supported.
• Do not use link and node protection with path protection on the headend router.
• Do not configure path protection on an automesh tunnel template because the destinations are
different and you cannot use the same path option to reach multiple destinations.
Information About MPLS Traffic Engineering (TE): Path

Protection
To configure the MPLS Traffic Engineering (TE): Path Protection feature, you should understand the
following concepts:
• Traffic Engineering Tunnels, page 2
• Path Protection, page 3
• ISSU, page 3
• NSF/SSO, page 3
Traffic Engineering Tunnels

MPLS TE lets you build label switched paths (LSPs) across your network for forwarding traffic.
MPLS TE LSPs, also called TE tunnels, let the headend of a TE tunnel control the path its traffic takes
to a particular destination. This method is more flexible than forwarding traffic based only on a
destination address.
Some tunnels are more important than others. For example, you may have tunnels carrying VoIP traffic
and tunnels carrying data traffic that are competing for the same resources. MPLS TE allows you to have
some tunnels preempt others. Each tunnel has a priority, and more-important tunnels take precedence
over less-important tunnels.
2
Information About MPLS Traffic Engineering (TE): Path Protection
Path Protection
Path protection provides an end-to-end failure recovery mechanism (that is, full path protection) for
MPLS TE tunnels. A secondary LSP is established, in advance, to provide failure protection for the
protected LSP that is carrying a tunnel’s TE traffic. When there is a failure on the protected LSP, the
headend router immediately enables the secondary LSP to temporarily carry the tunnel’s traffic. If there
is a failure on the secondary LSP, the tunnel no longer has path protection until the failure along the
secondary path is cleared. Path protection can be used with a single area (OSPF or IS-IS), or Inter-AS
(Border Gateway Protocol (BGP), external BGP (eBGP,) and static).
The failure detection mechanisms that trigger a switchover to a secondary tunnel include the following:
• Path error or resv tear from Resource Reservation Protocol (RSVP) signaling
• Notification from the RSVP hello that a neighbor is lost
• Notification from the Bidirectional Forwarding Detection (BFD) protocol that a neighbor is lost
• Notification from the Interior Gateway Protocol (IGP) that the adjacency is down
• Local teardown of the protected tunnel’s LSP due to preemption in order to signal higher priority
LSPs, a Packet over SONET (POS) alarm, online insertion and removal (OIR), and so forth
An alternate recovery mechanism is Fast Reroute (FRR), which protects MPLS TE LSPs only from link
and node failures by locally repairing the LSPs at the point of failure.
Although not as fast as link or node protection, presignaling a secondary LSP is faster than configuring
a secondary primary path option or allowing the tunnel’s headend router to dynamically recalculate a
path. The actual recovery time is topology-dependent, and affected by delay factors such as propagation
delay or switch fabric latency.
ISSU
Cisco ISSU allows you to perform a Cisco IOS XE software upgrade or downgrade while the system
continues to forward packets. ISSU takes advantage of the Cisco IOS XE high availability
infrastructure—Cisco NSF with SSO and hardware redundancy—and eliminates downtime associated
with software upgrades or version changes by allowing changes while the system remains in service.
That lowers the impact that planned maintenance activities have on network service availability; there is
less downtime and better access to critical systems.
When Path Protection is enabled and an ISSU upgrade is performed, path protection performance is
similar to other TE features.
NSF/SSO
Cisco NSF with SSO provides continuous packet forwarding, even during a network processor hardware
or software failure.
SSO takes advantage of Route Processor (RP) redundancy to increase network availability by
establishing one of the RPs as the active processor while the other RP is designated as the secondary
processor, and then synchronizing critical state information between them. Following an initial
synchronization between the two processors, SSO dynamically maintains RP state information between
them. A switchover from the active to the secondary processor occurs when the active RP fails, is
removed from the networking device, or is manually taken down for maintenance.
3
How to Configure MPLS Traffic Engineering (TE): Path Protection
Cisco NSF works with SSO to minimize the amount of time a network is unavailable to users after a
switchover. The main purpose of NSF is to continue forwarding IP packets after an RP switchover.
Cisco NSF helps to suppress routing flaps in SSO-enabled devices, thus reducing network instability.
The MPLS Traffic Engineering: Path Protection feature can recover after SSO. A tunnel configured for
path protection may have two LSPs signaled simultaneously: the primary LSP that is carrying the traffic
and the secondary LSP that carries traffic in case there is a failure along the primary path. Only
information associated with one of those LSPs, the one that is currently carrying traffic, is synched to
the standby RP. The standby RP, upon recovery, can determine from the checkpointed information
whether the LSP was the primary or secondary.
If the primary LSP was active during the switchover, only the primary LSP is recovered. The secondary
LSP that was signaled and that provided path protection is resignaled after the TE recovery period is
complete. This does not impact traffic on the tunnel because the secondary LSP was not carrying traffic.
How to Configure MPLS Traffic Engineering (TE): Path

Protection
This section contains the following tasks which are shown in Figure 1.
• Configuring Explicit Paths for Secondary Paths, page 4 (required)
• Assigning a Secondary Path Option to Protect a Primary Path Option, page 5 (required)
• Verifying the Configuration of MPLS Traffic Engineering Path Protection, page 6 (optional)
Figure 1 Network Topology
R4
10.2.0.2 10.10.0.1
10.2.0.1 10.10.0.2
10.0.0.1 10.0.0.2 10.0.1.1 10.0.1.2

186193
R1 R2 R3
Configuring Explicit Paths for Secondary Paths

To specify a secondary path that does not include common links or nodes associated with the primary
path in case those links or nodes go down, configure an explicit path by performing the following steps.
SUMMARY STEPS
1. enable
4
3. ip explicit-path {name path-name | identifier number} [enable | disable]

4. index index command ip-address
5. exit
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip explicit-path {name path-name | identifier Creates or modifies the explicit path and enters IP explicit
number} [enable | disable] path command mode.
Example:
Router(config)# ip explicit-path name path3441
enable
Step 4 index index command ip-address Inserts or modifies a path entry at a specific index. The IP
address represents the node ID.
Example: Note Enter this command once for each router.
Router(cfg-ip-exp1-path)# index 1 next-address
10.0.0.1
Step 5 exit Exits IP explicit path command mode and enters global
configuration mode.
Example:
Router(cfg-ip-exp1-path)# exit
EXEC mode.
Example:
Assigning a Secondary Path Option to Protect a Primary Path Option

Assign a secondary path option in case there is a link or node failure along a path and all interfaces in
your network are not protected.
SUMMARY STEPS
1. enable
5
4. tunnel mpls traffic-eng path-option protect number explicit {name path-name | identifier
path-number} [verbatim] [attributes string] [bandwidth kb/s | sub-pool kb/s]
5. exit
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 tunnel mpls traffic-eng path-option protect Configures a secondary path option for an MPLS TE tunnel.
number explicit {name path-name | identifier
path-number} [verbatim] [attributes string]
[bandwidth kb/s | sub-pool kb/s]
Example:
path-option protect 10 explicit name path344
configuration mode.
Example:
EXEC mode.
Example:
Verifying the Configuration of MPLS Traffic Engineering Path Protection

To verify the configuration of path protection, perform the following steps. In Steps 1 and 2, refer to
Figure 2.
6
Figure 2 Network Topology Verification
R4
10.10.0.1
10.2.0.2
10.2.0.1 10.10.0.2
10.0.0.1 10.0.0.2 10.0.1.1 10.0.1.2

R1 R2 R3
= Primary path
186181
= Secondary path
SUMMARY STEPS
1. show running interface tunnel tunnel-number

2. show mpls traffic-eng tunnels tunnel-interface
3. show mpls traffic-eng tunnels tunnel-interface [brief] protection
4. show ip rsvp high-availability database {hello | link-management {interfaces | system} | lsp
[filter destination ip-address | filter lsp-id lsp-id | filter source ip-address | filter tunnel-id
tunnel-id] | lsp-head [filter number] | summary}
DETAILED STEPS
Step 1 show running interface tunnel tunnel-number

This command shows the configuration of the primary path and protection path options.
Note To show the status of both LSPs (that is, both the primary path and the protected path), use the show
mpls traffic-eng tunnels command with the protection keyword.
Router# show running interface tunnel500

!
interface Tunnel500
tunnel mpls traffic-eng path-option protect 10 explicit name path3441
7

end
Step 2 show mpls traffic-eng tunnels tunnel-interface

This command shows tunnel path information.
The Common Link(s) field shows the number of links shared by both the primary and secondary paths,
from the headend router to the tailend router.
The Common Node(s) field shows the number of nodes shared by both the primary and secondary paths,
excluding the headend and tailend routers.
As shown in the following output, there are no common links or nodes:
Name: R1_t500 (Tunnel500) Destination: 10.0.0.9

Status:
Path Protection: 0 Common Link(s), 0 Common Node(s)
path protect option 10, type explicit path3441 (Basis for Protect, path weight 20)
path protect option 20, type explicit path348
Config Parameters:
Bandwidth: 100 kb/s (Global) Priority: 7 7 Affinity: 0x0/0xFFFF
Metric Type: TE (default)
auto-bw: disabled
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : FastEthernet1/0/0, 16
RSVP Signalling Info:
Src 10.1.1.1, Dst 10.0.0.9, Tun_Id 500, Tun_Instance 19
RSVP Path Info:
My Address: 10.2.0.1
Explicit Route: 10.2.0.2 10.10.0.1 10.10.0.2 10.0.0.9
Record Route: NONE
Tspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=100 kbits, burst=1000 bytes, peak rate=100 kbits
Shortest Unconstrained Path Info:
Path Weight: 20 (TE)
Explicit Route: 10.2.0.1 10.2.0.2 10.10.0.1 10.10.0.2 10.0.0.9
History:
Tunnel:
Time since created: 11 minutes, 17 seconds
Time since path change: 8 minutes, 5 seconds
Number of LSP IDs (Tun_Instances) used: 19
Current LSP:
Uptime: 8 minutes, 5 seconds
Step 3 show mpls traffic-eng tunnels tunnel-interface [brief] protection
Use this command, with the protection keyword specified, to show the status of both LSPs (that is, both
the primary path and the protected path).
8
Note Deleting a primary path option has the same effect as shutting down a link. Traffic will move to the
protected path in use.
The following command output shows that the primary LSP is up, and the secondary LSP is up and
providing protection:
Router# show mpls traffic-eng tunnels tunnel500 protection
R1_t500
Fast Reroute Protection: None
Primary lsp path:10.2.0.1 10.2.0.2
10.10.0.1 10.10.0.2
10.0.0.9
Protect lsp path:10.0.0.1 10.0.0.2
10.0.1.1 10.0.1.2
10.0.0.9
Path Protect Parameters:
InLabel : -
RSVP Path Info:
Explicit Route: 10.0.0.2 10.0.1.1 10.0.1.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
The following command output shows that the primary LSP is down, and the secondary LSP is up and
is actively carrying traffic:
R1_t500
Path Protection: Backup lsp in use.
Step 4 show ip rsvp high-availability database {hello | link-management {interfaces | system} | lsp [filter
destination ip-address | filter lsp-id lsp-id | filter source ip-address | filter tunnel-id tunnel-id] |
lsp-head [filter number] | summary}
The show ip rsvp high-availability database command displays the contents of the RSVP high
availability (HA) read and write databases used in TE. If you specify the lsp-head keyword, the
command output includes path protection information.
Router# show ip rsvp high-availability database lsp-head
LSP_HEAD WRITE DB
Tun ID: 500
Header:
State: Checkpointed Action: Add
Seq #: 3 Flags: 0x0
9
Configuration Examples for MPLS Traffic Engineering (TE): Path Protection
Data:
lsp_id: 5, bandwidth: 100, thead_flags: 0x1, popt: 1
feature_flags: path protection active
output_if_num: 5, output_nhop: 10,0,0,1
RRR path setup info
Destination: 10.0.0.9, Id: 10.0.0.9 Router Node (ospf) flag:0x0
IGP: ospf, IGP area: 0, Number of hops: 5, metric: 2
Hop 0: 10.0.0.1, Id: 10.0.0.1 Router Node (ospf), flag:0x0
Configuration Examples for MPLS Traffic Engineering (TE): Path

Protection
This section provides the following configuration examples for MPLS TE path protection:
• Configuring Explicit Paths for Secondary Paths: Example, page 10
• Assigning a Secondary Path Option to Protect a Primary Path Option: Example, page 11
• Configuring Tunnels Before and After Path Protection: Example, page 12
Configuring Explicit Paths for Secondary Paths: Example

Figure 3 illustrates a primary path and a secondary path. If there is a failure, the secondary path is used.
Figure 3 Primary Path and Secondary Path
R4
10.10.0.1
10.2.0.2
10.2.0.1 10.10.0.2
10.0.0.1 10.0.0.2 10.0.1.1 10.0.1.2

R1 R2 R3
= Primary path
186181
= Secondary path
10
In the following example the explicit path is named path3441. There is an index command for each
router. If there is failure, the secondary path is used.
Router(config)# ip explicit-path name path3441 enable
Router(cfg-ip-expl-path)# index 1 next 10.0.0.1
Explicit Path name path3441:
1: next-address 10.0.0.1



Assigning a Secondary Path Option to Protect a Primary Path Option: Example

In the following example a traffic engineering tunnel is configured:
Router> enable
Router(config-if)# interface tunnel500
Router(config-if)# tunnel mpls traffic-eng path-option protect 10 explicit name path344
The following show running interface command output shows that path protection has been configured.
Tunnel 500 has path option 10 using path344 and protected by path 3441, and path option 20 using
path345 and protected by path348.
Router# show running interface tunnel500
Router# interface tunnel 500

!
interface Tunnel500
end
11
Configuring Tunnels Before and After Path Protection: Example

The show mpls traffic-eng tunnels command shows information about the primary (protected) path.
The following sample output shows that path protection has been configured.

Status:
Config Parameters:
auto-bw: disabled
InLabel : -
RSVP Path Info:
Explicit Route: 10.2.0.2 10.10.0.1 10.10.0.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Explicit Route: 10.0.0.1 10.0.0.2 10.0.1.1 10.0.1.2
10.0.0.9
History:
Tunnel:
Time since path change: 19 seconds
Current LSP:
Uptime: 22 seconds
Selection: reoptimization
Prior LSP:
ID: path option 10 [27]
Removal Trigger: reoptimization completed
The following show mpls traffic-eng tunnels command output shows information about the secondary
path. Tunnel500 is protected. The protection path is used, and the primary path is down. The command
output shows the IP explicit paths of the primary LSP and the secondary LSP.
R1_t500
12

10.10.0.1 10.10.0.2
10.0.0.9
Protect lsp path:10.0.0.1 10.0.0.2
10.0.1.1 10.0.1.2
10.0.0.9
InLabel : -
RSVP Path Info:
Explicit Route: 10.0.0.2 10.0.1.1 10.0.1.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
R1#
The following shutdown command shuts down the interface to use path protection:
Router(config)# interface fastethernet1/0/0
Router(config-if)# shutdown
Router#
The following show mpls traffic-eng tunnels command shows that the protection path is used, and the
primary path is down:

Status:
Config Parameters:
auto-bw: disabled
InLabel : -
RSVP Path Info:
13
Explicit Route: 10.0.0.2 10.0.1.1 10.0.1.2 10.0.0.9

Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Explicit Route: 10.0.0.1 10.0.0.2 10.0.1.1 10.0.1.2 10.0.0.9
History:
Tunnel:
Current LSP:
Uptime: 5 minutes, 24 seconds
Selection:
Prior LSP:
Removal Trigger: path error
Last Error: PCALC:: Explicit path has unknown address, 10.2.0.1
R1#
The up value in the Oper field of the show mpls traffic-eng tunnels command, with the protection
keyword specified, shows that protection is enabled:
R1_t500
R1#
The no shutdown command in the following command sequence causes the interface to be up again and
activates the primary path:
Router> enable

Router(config)# interface fastethernet1/0/0
Router(config-if)# no shutdown
The following command output shows that path protection has been reestablished and the primary path
is being used:

Status:
Config Parameters:
14

auto-bw: disabled
InLabel : -
RSVP Path Info:
Explicit Route: 10.2.0.2 10.10.0.1 10.10.0.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Explicit Route: 10.0.0.1 10.0.0.2 10.0.1.1 10.0.1.2 10.0.0.9
History:
Tunnel:
Current LSP:
Uptime: 26 seconds
Selection: reoptimization
Prior LSP:
Removal Trigger: reoptimization completed
R1#
Following is sample show mpls traffic-eng tunnels command output. Tunnel500 is protected. After a
failure, the primary LSP is protected.
R1_t500
10.10.0.1 10.10.0.2
10.0.0.9
Protect lsp path:10.0.0.1 10.0.2
10.0.1.1 10.0.1.2
10.0.0.9
InLabel : -
RSVP Path Info:
Explicit Route: 10.0.0.2 10.0.1.1 10.0.1.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
15
Record Route: NONE

R1#
The following sections provide references related to the MPLS Traffic Engineering (TE): Path Protection
feature.
Related Documents
RSVP commands Cisco IOS Quality of Service Solutions Command Reference
ISSU Cisco IOS XE In Service Software Upgrade Support
NSF/SSO • Cisco Nonstop Forwarding
• Stateful Switchover
Standards
Standard Title
MIBs
MIB MIBs Link
16
RFCs
RFC Title
Description Link
17
Feature Information for MPLS Traffic Engineering (TE): Path Protection
Feature Information for MPLS Traffic Engineering (TE): Path

Protection
Table 1 Feature Information for MPLS Traffic Engineering (TE): Path Protection

MPLS Traffic Engineering (TE): Path Cisco IOS XE The MPLS Traffic Engineering (TE): Path
Protection Release 2.3 Protection feature provides an end-to-end failure
recovery mechanism (that is, full path protection)
for MPLS TE tunnels.
Release 2.3.
The following sections provide information about
this feature:
• Traffic Engineering Tunnels, page 2
• Path Protection, page 3
• Configuring Explicit Paths for Secondary
Paths, page 4
• Assigning a Secondary Path Option to Protect
a Primary Path Option, page 5
• Verifying the Configuration of MPLS Traffic
Engineering Path Protection, page 6
The following commands were introduced or
modified: show ip rsvp high-availability
database, tunnel mpls traffic-eng path-option,
tunnel mpls traffic-eng path-option protect.
ISSU—MPLS Traffic Engineering (TE)—Path Cisco IOS XE Cisco ISSU allows you to perform a Cisco IOS XE
Protection Release 2.3 software upgrade or downgrade while the system
continues to forward packets.
Release 2.3.
The following section provides information about
this feature:
• ISSU, page 3
18
Feature Information for MPLS Traffic Engineering (TE): Path Protection
Table 1 Feature Information for MPLS Traffic Engineering (TE): Path Protection (continued)

NSF/SSO—MPLS Traffic Engineering Cisco IOS XE Cisco NSF with SSO provides continuous packet
(TE)—Path Protection Release 2.3 forwarding, even during a network processor
hardware or software failure.
Release 2.3.
The following section provides information about
this feature:
• NSF/SSO, page 3
19
Glossary
Glossary
autotunnel mesh group—An autotunnel mesh group (referred to as a mesh group) is a set of connections
between edge LSRs in a network.
failure occurs.
BGP—Border Gateway Protocol. An interdomain routing protocol designed to provide loop-free routing
between separate routing domains that contain independent routing policies (autonomous systems).
graceful restart—A process for helping an RP restart after a node failure has occurred.
IS-IS—Intermediate System-to-Intermediate System. Link-state hierarchical routing protocol that calls
for intermediate system (IS) routers to exchange routing information based on a single metric to
ISSU—In Service Software Upgrade. The ISSU process allows Cisco IOS XE software at the router
level to be updated or otherwise modified while packet forwarding continues.
adjacent nodes. A link is a network communications channel consisting of a circuit or transmission path
and all related equipment between a sender and a receiver. Sometimes referred to as a line or a
transmission link.
LSP—label switched path. A configured connection between two routers, in which label switching is
NHOP backup tunnel—next-hop backup tunnel. The backup tunnel terminating at the LSP’s next hop
NNHOP backup tunnel—next-next-hop backup tunnel. The backup tunnel terminating at the LSP’s
node—The endpoint of a network connection or a junction common to two or more lines in a network.
Nodes can be interconnected by links, and serve as control points in the network. Nodes can be
processors, controllers, or workstations.
20
Glossary
NSF—Cisco nonstop forwarding. Cisco NSF always runs with stateful switchover (SSO) and provides
redundancy for Layer 3 traffic. NSF works with SSO to minimize the amount of time that a network is
unavailable to its users following a switchover. The main purpose of NSF is to continue forwarding IP
packets following a supervisor engine switchover.
balancing.
primary LSP—The last LSP originally signaled over the protected interface before the failure. A
primary LSP is signaled by configuring a primary path option.
primary tunnel—A tunnel whose LSP may be fast rerouted if there is a failure. Backup tunnels cannot
be primary tunnels.
router—A network layer device that uses one or more metrics to determine the optimal path along which
network traffic should be forwarded. Routers forward packets from one network to another based on
network layer information.
RP—Route Processor. A generic term for the centralized control unit in a chassis.
secondary LSP—The LSP that is signaled to provide path protection. A secondary LSP protects a
primary LSP.
secondary path option—Configuration of the path option that provides protection.
SRLG—Shared Risk Link Group. Sets of links that are likely to go down together (for example, because
they have the same underlying fiber).
tunnels.
used.
structure.
VoIP—Voice over IP. The capability of a router to carry voice traffic (for example, telephone calls and faxes)
over an IP network. Cisco’s voice support is implemented by using voice packet technology.
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect,
21
Glossary
22
MPLS Traffic Engineering: BFD-triggered Fast
Reroute

The MPLS Traffic Engineering: BFD-triggered Fast Reroute feature allows you to obtain link and node
protection by using the Bidirectional Forwarding Detection (BFD) protocol to provide fast forwarding
path failure detection times for all media types, encapsulations, topologies, and routing protocols. In
addition to fast forwarding path failure detection, BFD provides a consistent failure detection method
for network administrators.
To obtain link and node protection by using the Resource Reservation Protocol (RSVP) with Hellos
support, refer to the MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Interface Down Detection) process module. RSVP Hellos enable a router to detect when a neighboring
node has gone down but its interface to that neighbor is still operational.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering: BFD-triggered
Fast Reroute” section on page 28.
Contents
• Prerequisites for MPLS Traffic Engineering: BFD-triggered Fast Reroute, page 2
• Restrictions for MPLS Traffic Engineering: BFD-triggered Fast Reroute, page 2
• Information About MPLS Traffic Engineering: BFD-triggered Fast Reroute, page 2
MPLS Traffic Engineering: BFD-triggered Fast Reroute
Prerequisites for MPLS Traffic Engineering: BFD-triggered Fast Reroute
• How to Configure MPLS Traffic Engineering: BFD-triggered Fast Reroute, page 4

• Configuration Examples for MPLS Traffic Engineering: BFD-triggered Fast Reroute, page 23
• Feature Information for MPLS Traffic Engineering: BFD-triggered Fast Reroute, page 28
Prerequisites for MPLS Traffic Engineering: BFD-triggered Fast

Reroute
• Configure BFD. Refer to the Bidirectional Forwarding Detection process module.
• Enable MPLS TE on all relevant routers and interfaces.
• Configure MPLS TE tunnels.
• For additional prerequisites, refer to the MPLS TE: Link and Node Protection, with RSVP Hellos
Support (with Fast Tunnel Interface Down Detection) process module.
Restrictions for MPLS Traffic Engineering: BFD-triggered Fast

Reroute
• You cannot configure BFD and RSVP Hellos on the same interface.
• BFD may not be supported on some interfaces.
• For additional restrictions, refer to the MPLS TE: Link and Node Protection, with RSVP Hellos
Support (with Fast Tunnel Interface Down Detection) process module.
Information About MPLS Traffic Engineering: BFD-triggered Fast

Reroute
To configure the MPLS Traffic Engineering: BFD-triggered Fast Reroute feature, you need to understand
• Bidirectional Forwarding Detection, page 3
2
Information About MPLS Traffic Engineering: BFD-triggered Fast Reroute
Bidirectional Forwarding Detection

Bidirectional Forwarding Detection (BFD) is a detection protocol designed to provide fast forwarding
path failure detection times for all media types, encapsulations, topologies, and routing protocols. In
addition to fast forwarding path failure detection, BFD provides a consistent failure detection method
for network administrators. Because the network administrator can use BFD to detect forwarding path
failures at a uniform rate, rather than the variable rates for different routing protocol Hello mechanisms,
network profiling and planning will be easier, and reconvergence time will be consistent and predictable.
Fast Reroute
Fast Reroute (FRR) is a mechanism for protecting Multiprotocol Label Switching (MPLS) traffic
engineering (TE) label switched paths (LSPs) from link and node failures by locally repairing the LSPs
at the point of failure, allowing data to continue to flow on them while their headend routers attempt to
establish new end-to-end LSPs to replace them. FRR locally repairs the protected LSPs by rerouting
them over backup tunnels that bypass failed links or nodes.
Link Protection
Backup tunnels that bypass only a single link of the LSP’s path provide link protection. They protect
hop beyond the point of failure.
Node Protection
FRR provides node protection for LSPs. Backup tunnels that bypass next-hop nodes along LSP paths are
called next-next-hop (NNHOP) backup tunnels because they terminate at the node following the
the failed link as well as the node.
which backup tunnels in order to provide maximum bandwidth protection. That is, the router determines
the best way to map LSPs onto backup tunnels in order to maximize the number of LSPs that can be
protected.
3
How to Configure MPLS Traffic Engineering: BFD-triggered Fast Reroute
How to Configure MPLS Traffic Engineering: BFD-triggered Fast

Reroute
This section shows you how to add FRR protection to a network in which MPLS TE LSPs are configured.
The following sections describe how to use FRR to protect LSPs in your network from link or node
failures. Each task is identified as either required or optional.
Note You can perform the configuration tasks in any order.
Note An NNHOP backup tunnel must not go via the NHOP backup tunnel.
• Enabling BFD Support on the Router, page 4 (required)

• Enabling Fast Reroute on LSPs, page 5 (required)
• Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop, page 6 (required)
• Assigning Backup Tunnels to a Protected Interface, page 9 (required)
• Enabling BFD on the Protected Interface, page 11 (required)
• Associating Backup Bandwidth and Pool Type with a Backup Tunnel, page 13 (optional)
• Configuring Backup Bandwidth Protection, page 14 (optional)
• Verifying That Fast Reroute Is Operational, page 15 (optional)
Enabling BFD Support on the Router

To enable support for Bidirectional Forwarding on the router, enter the following commands.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello bfd
4. exit
4
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello bfd Enables the BFD protocol on the router for MPLS
TE link and node protection.
Example:
Router(config)# ip rsvp signalling hello bfd
Example:

LSPs can use backup tunnels only if the LSPs have been configured as fast reroutable. To enable FRR
on the LSP, enter the following commands at the headend of each LSP.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng fast-reroute [bw-protect] [node-protect]
5. exit
6. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
5
Command Purpose
specified tunnel.
Example: • The number argument is the number of the
Router(config)# interface tunnel 1000 tunnel.
[node-protect] backup tunnel if there is a link or node failure.
• The bw-protect keyword sets the “bandwidth
Example: protection desired” bit so that backup
Router(config-if)# tunnel mpls traffic-eng bandwidth protection is enabled.
fast-reroute bw-protect node-protect
• The node-protect keyword sets the “node
protection desired” bit so that backup
bandwidth protection is enabled.
Example:
Example:

To create a backup tunnel to the next hop or to the next-next hop, perform the following task.
downstream link or node may fail). The node on which you enter the commands must be a supported
Creating a backup tunnel is basically no different from creating any other tunnel.
Note When using the exclude-address command to specify the path for a backup tunnel, you must exclude
an interface address to avoid a link (for creating an NHOP backup tunnel), or a router-ID address to
avoid a node (for creating an NNHOP backup tunnel).
SUMMARY STEPS
1. enable
6

path-number}}[lockdown]
8. exit
9. ip explicit-path name name
10. exclude-address address
11. exit
12. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
configuration mode.
Step 4 ip unnumbered type number Enables IP processing on an interface without
assigning an explicit IP address to the interface.
Example: • The type and number arguments name the
Router(config-if)# ip unnumbered loopback 0 type and number of another interface on
which the router has an assigned IP address. It
cannot be another unnumbered interface.
Note The ip unnumbered loopback 0
command gives the tunnel interface an IP
address that is the same as that of interface
loopback 0. This command is not effective
until loopback 0 has been configured with
an IP address.
Step 5 tunnel destination ip-address Specifies the destination for a tunnel interface.
• The ip-address argument specifies the IP
Example: address of the device, expressed in dotted
Router(config-if)# tunnel destination 10.3.3.3 decimal notation, where the tunnel will
terminate. That address should be the router
ID of the device that is the NHOP or NNHOP
of LSPs to be protected.
Step 6 tunnel mode mpls traffic-eng Sets encapsulation mode of the tunnel to
MPLS TE.
Example:
7
Command Purpose
Step 7 tunnel mpls traffic-eng path-option number {dynamic | Configures the tunnel to use a named IP explicit
explicit {name path-name | path-number}}[lockdown] path or a path dynamically calculated from the
traffic engineering topology database.
Example: • The number argument is the preference for
Router(config-if)# tunnel mpls traffic-eng path-option this path option. When you configure multiple
10 explicit name avoid-protected-link
path options, lower numbered options are
preferred. Valid values are from 1 to 1000.
• The dynamic keyword indicates that the path
of the label switched path (LSP) is
dynamically calculated.
• The explicit keyword indicates that the path
of the LSP is an IP explicit path.
• The name path-name keyword and argument
are the path name of the IP explicit path that
the tunnel uses with this option.
• The identifier path-number keyword and
argument pair names the path number of the
IP explicit path that the tunnel uses with this
option. The range is from 1 to 65535.
• The lockdown keyword specifies that The
LSP cannot be reoptimized.
Note A dynamic path is used if an explicit path
is currently unavailable.
Step 8 exit Exits interface configuration mode and enter
Example:
Step 9 ip explicit-path name name Enters IP explicit path mode for IP explicit paths
to create the named path.
Example: • The name argument is the name of the explicit
Router(config)# ip explicit-path name path.
Step 10 exclude-address address Excludes an address from an explicit-path.
• The address argument specifies the IP address
Example: of the link to be protected for link protection.
Router(cfg-ip-expl-path)# exclude-address 10.3.3.3 For node protection, it specifies the router ID
of the node to be protected.
Note Backup tunnel paths can be dynamic or
explicit and they do not have to use an
excluded address. Because backup tunnels
must avoid the protected link or node, it is
convenient to use an excluded address.
8
Command Purpose
Step 11 exit Exits IP explicit path configuration mode and
returns to global configuration mode.
Example:
Router(cfg-ip-expl-path))# exit
Example:

To assign one or more backup tunnels to a protected interface, perform the following task.
downstream link or node may fail). The node on which you enter the commands must be a supported
SUMMARY STEPS
1. enable
3. interface type slot/subslot/port [.subinterface]
4. mpls traffic-eng backup-path tunnel tunnel-id
5. exit
6. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
9
Command Purpose
Step 3 interface type slot/subslot/port[.subinterface] Configures an interface type and enters interface
configuration mode.
Router(config)# interface Gigabitethernet 2/1/0 be configured.
guide.
required.
guide
Step 4 mpls traffic-eng backup-path tunnel tunnel-id Configures the physical interface to use for a
backup tunnel in the event of a detected failure on
that interface.
Example:
Router(config-if)# mpls traffic-eng backup-path • The tunnel-id argument is a string that
tunnel2 identifies a backup tunnel to use if there is a
link or node failure for LSPs going out the
configured interface.
Note You can enter this command multiple
times to associate multiple backup tunnels
with the same protected interface.
10
Command Purpose
Example:
Router(config-if))# exit
Example:
Enabling BFD on the Protected Interface

SUMMARY STEPS
1. enable
3. interface type slot/subslot/port [.subinterface]
4. ip rsvp signalling hello bfd
5. bfd interval milliseconds min_rx milliseconds multiplier interval-multiplier
6. exit
7. exit
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
11
Command Purpose
configuration mode.
Router(config)# interface Gigabitethernet 2/1/0 be configured.
guide.
required.
guide
Step 4 ip rsvp signalling hello bfd Enables the BFD protocol on an interface for
MPLS TE link and node protection.
Example:
Router(config-if)# ip rsvp signalling hello bfd
12
Command Purpose
Step 5 bfd interval milliseconds min_rx milliseconds Sets the BFD session parameters for an interface.
multiplier interval-multiplier
• The interval milliseconds keyword and
argument pair specifies the rate at which BFD
Example: control packets will be sent to BFD peers. The
Router(config-if)# bfd interval 100 min_rx 100 configurable time period for the milliseconds
multiplier 4
argument is from 50 to 999.
• The min_rx millisecond keyword and
argument pair specifies the rate at which BFD
control packets will be expected to be
received from BFD peers. The configurable
time period for the milliseconds argument is
from 1 to 999.
• The multiplier interval-multiplier keyword
and argument pair specifies the number of
consecutive BFD control packets that must be
missed from a BFD peer before BFD declares
that the peer is unavailable and the Layer 3
BFD peer is informed of the failure. The
configurable value range for the
multiplier-value argument is from 3 to 50.
Example:
Example:

tunnel, enter the following tasks.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng backup-bw {bandwidth | [sub-pool {bandwidth | Unlimited}]
[global-pool {bandwidth | Unlimited}]} [any {bandwidth | Unlimited}]
5. exit
6. exit
13
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
specified tunnel.
Step 4 tunnel mpls traffic-eng backup-bw {bandwidth | Associates bandwidth with a backup tunnel and
[sub-pool {bandwidth | Unlimited}] [global-pool designates whether LSPs that allocate bandwidth
{bandwidth | Unlimited}]} [any {bandwidth |
Unlimited}]
from the specified pool can use the tunnel.
Example:
Router(config-if)# tunnel mpls traffic-eng backup-bw
sub-pool 1000
Example:
Example:

To configure the backup bandwidth protection, perform the following task.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng fast-reroute [bw-protect]
5. exit
6. mpls traffic-eng fast-reroute backup-prot-preemption optimize-bw
7. exit
14
DETAILED STEPS

Example:
Router> enable
Example:
specified tunnel.
backup tunnel in the event of a link or node failure.
Example: • The bw-protect keyword gives an LSP
Router(config-if)# tunnel mpls traffic-eng priority for using backup tunnels with
fast-reroute bw-protect bandwidth protection.
Example:
Step 6 mpls traffic-eng fast-reroute backup-prot-preemption Changes the backup protection preemption
optimize-bw algorithm from minimize the number of LSPs that
are demoted to minimize the amount of bandwidth
Example: that is wasted.
Example:

SUMMARY STEPS
15
perform Step 3.
Note To determine the status of BFD, perform Steps 9 through 11.

7. show ip rsvp hello
8. show ip rsvp interface detail
9. show ip rsvp hello bfd nbr
10. show ip rsvp hello bfd nbr detail
11. show ip rsvp hello bfd nbr summary
DETAILED STEPS

Signalling Summary:
Forwarding: enabled
Router_t1 10.112.0.12 - Gi4/0/1 up/up
Router_t2000 10.110.0.10 - Gi4/0/1 up/up

at the router acting as the point of local repair (PLR) before a failure:
PATH:
16
Path refreshes:
arriving: from PHOP 10.10.7.1 on Et0/0 every 30000 msecs
Session Attr:
ERO: (incoming)
RRO:


Tunnel500 Tun hd AT4/0.100:Untagg Tu501:20 ready

10.0.0.8/32 Tu500 18 AT4/0.100:Pop ta Tu501:20 ready
10.0.8.8/32 Tu500 19 AT4/0.100:Untagg Tu501:20 ready

If Label Distribution Protocol (LDP) is not enabled, separate prefix items are not shown because all
prefixes then use a single rewrite. To confirm that a particular IP prefix is FRR protected, even though
it is not shown in this display, enter it within the show mpls forwarding-table ip-address detail
command. The final line of the display will tell whether that prefix is protected:

Tun hd Untagged 10.0.0.11/32 48 5/0 Gi5/0 point2point
48D18847 00016000
17
The following command output displays the LSPs that are protected when the FRR primary tunnel is
over a Gigabit Ethernet interface and the backup tunnel is over a Gigabit Ethernet interface. As shown
in Figure 1, interface Gigabit Ethernet 2/1/0 is protected by backup tunnel 501.
Figure 1 Protected LSPs
Primary tunnel 500
Gi2/1/0
R1 R2 R3 R4
Gi1/1/0
192705
Backup tunnel 501
Figure 1 shows the following:

• Primary tunnel 500—Path is R1 via Gigabit Ethernet2/1/0 to R2 to R3 to R4.
• FRR backup tunnel 501—Path is R1 via Gigabit Ethernet1/1/0 to R2.
• Interface Gigabit Ethernet1/1/0—Protected by backup tunnel 501.

Tunnel500 Tun hd AT4/0.100:Untagg Tu501:20 ready

10.0.0.8/32 Tu500 18 AT4/0.100:Pop ta Tu501:20 ready

The following command output displays the LSPs that are protected when the FRR backup tunnel is over
a Gigabit Ethernet interface.

Tunnel500 Tun hd PO2/0:Untagged Tu501:20 ready

10.0.0.8/32 Tu500 18 PO2/0:Pop tag Tu501:20 ready
10.0.8.8/32 Tu500 19 PO2/0:Untagged Tu501:20 ready
10.8.9.0/24 Tu500 22 PO2/0:Untagged Tu501:20 ready

18
For backup tunnels to be operational, the LSP must be reroutable. At the headend of the LSP, enter the
show run interface tunnel tunnel-number command. The output should include the tunnel mpls
traffic-eng fast-reroute command. If it does not, enter this command for the tunnel.
Router_t578
Protected i/fs: PO1/0, PO1/1, PO3/3
Protected lsps: 1
Router_t5710
Protected i/fs: PO1/1
Protected lsps: 0
Router_t5711
Protected i/fs: PO1/0
Protected lsps: 2

• Backup tunnel is up—To verify that the backup tunnel is up, look for “Up” in the Oper field.
• Backup tunnel is associated with the LSP’s interface—Verify that the interface for the LSP is
allowed to use this backup tunnel. Look for the LSP’s output interface in the protected i/fs field list.
Note In order to determine how much bandwidth is sufficient, offline capacity planning may be required.
Backup tunnel has appropriate bandwidth type—If you restricted the type of LSPs (subpool or global
pool) that can use this backup tunnel, verify that the LSP is the appropriate type for the backup tunnel.
The type of the LSP is defined by the line tunnel mpls traffic-eng bandwidth at the headend of this
LSP. If this line contains the word “sub pool”, then it uses subpool bandwidth; otherwise, it uses global
pool bandwidth. Verify that the type matches the type the backup tunnel can hold by looking in the output
of the tunnel mpls traffic-eng bandwidth command.
19
If none of the verification actions described succeed, enable debug by entering the debug ip rsvp
fast-reroute command and the debug mpls traffic-eng fast-reroute command on the router that is the
headend of the backup tunnel. Then do the following:


Tunne1l0 Tun Gi0/1/0:Untagged Tu0:12304 ready

10.0.0.11/32 Tu110 Tun hd Gi0/1/0:Untagged Tu0:12304 ready

10.0.0.12 1 [459] 16 Gi0/1/1:17 Tu2000:19 ready
Note If Label Distribution Protocol (LDP) is not enabled, separate prefix items are not shown because all
prefixes then use a single rewrite. To confirm that a particular IP prefix is FRR protected, even though
it is not shown in this display, enter it within the show mpls forwarding-table ip-address detail
command. The final line of the display will tell whether that prefix is protected.

Tun hd Untagged 10.0.0.11/32 48 Gi0/1/0 point2point
48D18847 00016000
Step 6 show ip rsvp reservation detail

Following is sample output from the show ip rsvp reservation detail command entered at the headend
of a primary LSP. Entering the command at the headend of the primary LSP shows, among other things,
the status of FRR (that is, local protection) at each hop this LSP traverses. The per-hop information is
Reservation:
Next Hop: 10.1.1.2 on Gi1/0/2
20
RRO:

• It has protection that uses an NHOP backup tunnel at its first hop.
• Whether local protection is in use (that is, whether the LSP is using its selected backup tunnel)
Step 7 show ip rsvp hello

Use this command to display hello status and statistics for FRR, reroute (hello state timer), and graceful
restart. Following is sample output:
Hello:
RSVP Hello for Fast-Reroute/Reroute: Enabled
Statistics: Disabled
BFD for Fast-Reroute/Reroute: Enabled
RSVP Hello for Graceful Restart: Disabled
Step 8 show ip rsvp interface detail

Use this command to display the interface configuration for Hello. Following is sample output:
Router# show ip rsvp interface detail
Gi2/1/1:
RSVP: Enabled
Interface State: Up
Bandwidth:
Curr allocated: 0 bits/sec
Max. allowed (total): 0 bits/sec
Max. allowed (per flow): 0 bits/sec
Max. allowed for LSP tunnels using sub-pools (pool 1): 0 bits/sec
Set aside by policy (total): 0 bits/sec
Signalling:
DSCP value used in RSVP msgs: 0x3F
Number of refresh intervals to enforce blockade state: 4
Authentication: disabled
Key chain: <none>
Type: md5
21
Window size: 1
Challenge: disabled
FRR Extension:
Backup Path: Configured (or "Not Configured")
BFD Extension:
State: Disabled
Interval: Not Configured
RSVP Hello Extension:
State: Disabled
Refresh Interval: FRR: 200 , Reroute: 2000
Missed Acks: FRR: 4 , Reroute: 4
DSCP in HELLOs: FRR: 0x30 , Reroute: 0x30
Step 9 show ip rsvp hello bfd nbr

Use this command to display information about all MPLS traffic engineering link and node protected
neighbors that use the BFD protocol. Following is sample output. The command output is the same as
the show ip rsvp hello bfd nbr summary command output.
Router# show ip rsvp hello bfd nbr
Client Neighbor I/F State LostCnt LSPs

FRR 10.0.0.6 Gi2/1/1 Up 0 1
Step 10 show ip rsvp hello bfd nbr detail

Use this command to display detailed information about all MPLS traffic engineering link and node
protected neighbors that use the BFD protocol:
Router# show ip rsvp hello bfd nbr detail
Hello Client Neighbors
Remote addr 10.0.0.6, Local addr 10.0.0.7

Type: Active
I/F: Gi2/1/1
State: Up (for 00:09:41)
Clients: FRR
LSPs protecting: 1 (frr: 1, hst upstream: 0 hst downstream: 0)
Communication with neighbor lost: 0
Step 11 show ip rsvp hello bfd nbr summary

Use this command to display summarized information about all MPLS traffic engineering link and node
protected neighbors that use the BFD protocol. The command output is the same as the show ip rsvp
hello bfd nbr summary command output.
Router# show ip rsvp hello bfd nbr summary
Client Neighbor I/F State LostCnt LSPs

FRR 10.0.0.6 Gi2/1/1 Up 0 1
22
Configuration Examples for MPLS Traffic Engineering: BFD-triggered Fast Reroute
Configuration Examples for MPLS Traffic Engineering:

BFD-triggered Fast Reroute
This section provides configuration examples for the MPLS Traffic Engineering: BFD-triggered Fast
Reroute feature. The examples in this section are based on the backup tunnels shown in Figure 2.

10.3.3.3 10.4.4.4
Gi1/1/0
R1 R2 R3 R4
Tunnel 172.16.1.2
1000
Tunnel 172.16.1.3
2000
= Primary tunnels
192706
= Backup tunnels
This section contains the following examples:

• Enabling BFD Support on the Router: Example, page 23
• Enabling Fast Reroute on LSPs: Example, page 24
• Creating a Backup Tunnel to the Next Hop: Example, page 24
• Enabling BFD on the Protected Interface: Example, page 25
Enabling BFD Support on the Router: Example

The following example enables the BFD protocol on the router:
Router(config)# ip rsvp signalling hello bfd
23
Configuration Examples for MPLS Traffic Engineering: BFD-triggered Fast Reroute
Enabling Fast Reroute on LSPs: Example

On router R1 in Figure 2, enter interface configuration mode for each tunnel to be protected
(Tunnel 1000 and Tunnel 2000). Enable these tunnels to use a backup tunnel in case of a link or node
failure along their paths.
Tunnel 1000 will use ten units of bandwidth from the subpool.
Tunnel 2000 will use five units of bandwidth from the global pool. The “bandwidth protection desired”
bit and the “node protection desired bit” have been set by specifying bw-prot and node-prot,
respectively, in the tunnel mpls traffic-eng fast-reroute command.

Router(config-if)# tunnel mpls traffic-eng fast-reroute bw-protect node-protect
Creating a Backup Tunnel to the Next Hop: Example

On router R2 in Figure 2, create an NHOP backup tunnel to R3. This backup tunnel should avoid using
the link 10.1.1.2.
Router(cfg-ip_expl-path)# exit

Router(config-if)# ip unnumbered loopback 0
Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit avoid-protected-link

On router R2 in Figure 2, create an NNHOP backup tunnel to R4. This backup tunnel should avoid R3.

Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit avoid-protected-node
24

On router R2 in Figure 2, both backup tunnels are associated with interface Gigabit Ethernet 0/1/0:
Router(config)# interface Gi0/1/0
Enabling BFD on the Protected Interface: Example

In Figure 2, BFD is enabled on interface Gigabit Ethernet 2/1/1:
Router(config)# interface Gi2/1/1
Router(config-if)# ip rsvp signalling hello bfd
Router(config-if)# bfd interval 100 min_rx 100 multiplier 4
In Figure 2. backup tunnel 1 is to be used only by LSPs that take their bandwidth from the global pool.
It does not provide bandwidth protection. Backup tunnel 2 is to be used only by LSPs that take their
bandwidth from the subpool. Backup tunnel 2 provides bandwidth protection for up to 1000 units.


In the following example, backup bandwidth protection is configured:

The following sections provide references related to the MPLS Traffic Engineering: BFD-triggered Fast
Reroute feature.
25
Related Documents
Link and node protection MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Interface Down Detection)
Multiprotocol Label Switching Cisco IOS Multiprotocol Label Switching Command Reference
commands
Bidirectional Forwarding Direction “Bidirectional Forwarding Detection” chapter in the Cisco IOS XE IP Routing
configuration information Configuration Guide
Standards
Standard Title
MIBs
MIB MIBs Link
26
RFCs
RFC Title
Description Link
27
Feature Information for MPLS Traffic Engineering: BFD-triggered Fast Reroute
Feature Information for MPLS Traffic Engineering:

BFD-triggered Fast Reroute
28
Feature Information for MPLS Traffic Engineering: BFD-triggered Fast Reroute
Table 1 Feature Information for MPLS Traffic Engineering: BFD-triggered Fast Reroute

MPLS Traffic Engineering: BFD-triggered Fast Cisco IOS XE The MPLS Traffic Engineering: BFD-triggered Fast
Reroute Release 2.3 Reroute feature allows you to obtain link and node
protection by using the Bidirectional Forwarding
Detection (BFD) protocol to provide fast forwarding
path failure detection times for all media types,
encapsulations, topologies, and routing protocols. In
addition to fast forwarding path failure detection, BFD
provides a consistent failure detection method for
network administrators.
feature:
• Bidirectional Forwarding Detection, page 3
• Enabling BFD Support on the Router, page 4
• Creating a Backup Tunnel to the Next Hop or to
the Next-Next Hop, page 6
• Assigning Backup Tunnels to a Protected
Interface, page 9
• Enabling BFD on the Protected Interface, page 11
• Associating Backup Bandwidth and Pool Type
with a Backup Tunnel, page 13
• Configuring Backup Bandwidth Protection,
page 14
• Verifying That Fast Reroute Is Operational,
page 15
introduced on the Cisco ASR 1000 Series Aggregation
Services Routers.
The following commands were introduced or modified
by this feature: clear ip rsvp hello bfd, ip rsvp
signalling hello bfd (configuration), ip rsvp
signalling hello bfd (interface), show ip rsvp hello,
show ip rsvp hello bfd nbr, show ip rsvp hello bfd
nbr detail, show ip rsvp hello bfd nbr summary, and
show ip rsvp interface detail.
29
Glossary
Glossary
for rerouted LSPs.
failure occurs.
fast reroute—Procedures that enable temporary routing around a failed link or node while a new LSP
global pool—The total bandwidth allocated to an MPLS traffic engineering link or node.
Hello ACK messages in response. If the expected Ack message is not received, the active Hello instance
adjacent nodes. A network communications channel consisting of a circuit or transmission path and all
related equipment between a sender and a receiver. Sometimes referred to as a line or a transmission link.
LSP—label-switched path. A configured connection between two routers, in which label switching is
can be interconnected by links, and serve as control points in the network. Computers on a network, or
any endpoint or a junction common to two or more lines in a network. Nodes can be processors,
primary LSP—The last LSP originally signaled over the protected interface before the failure. The LSP
before the failure.
be primary tunnels.
30
Glossary
tunnels.
subpool—The more restrictive bandwidth in an MPLS traffic engineering link or node. The subpool is
countries.
coincidental.
31
Glossary
32
MPLS Traffic Engineering (TE)—IP Explicit
Address Exclusion

The MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion feature provides a means to
exclude a link or node from the path for a Multiprotocol Label Switching (MPLS) TE label switched
path (LSP).
The feature is enabled through the ip explicit-path command that allows you to create an IP explicit path
and enter a configuration submode for specifying the path. The feature adds to the submode commands
the exclude-address command for specifying addresses to exclude from the path.
If the excluded address for an MPLS TE LSP identifies a flooded link, the constraint-based shortest path
first (CSPF) routing algorithm does not consider that link when computing paths for the LSP. If the
excluded address specifies a flooded MPLS TE router ID, the CSPF routing algorithm does not allow
paths for the LSP to traverse the node identified by the router ID.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering (TE)—IP
Explicit Address Exclusion” section on page 9.
MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion
Contents
Contents
• Prerequisites for MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion, page 2
• Restrictions for MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion, page 2
• Information About MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion, page 2
• How to Configure MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion, page 3
• Configuration Examples for MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion,
page 6
• Feature Information for MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion, page 9
Prerequisites for MPLS Traffic Engineering (TE)—IP Explicit

Address Exclusion
Your network must support the following Cisco IOS XE features in order to support IP explicit address
exclusion:
• MPLS
Restrictions for MPLS Traffic Engineering (TE)—IP Explicit

Address Exclusion
MPLS TE will accept an IP explicit path comprised of either all excluded addresses configured by the
exclude-address command or all included addresses configured by the next-address command, but not
a combination of both.
Information About MPLS Traffic Engineering (TE)—IP Explicit

Address Exclusion
To configure the MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion feature, you need to
• MPLS Traffic Engineering, page 3
• Cisco Express Forwarding, page 3
2
How to Configure MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion
MPLS Traffic Engineering

MPLS is an Internet Engineering Task Force (IETF)-specified framework that provides for the efficient
designation, routing, forwarding, and switching of traffic flows through the network.MPLS is a method
that forwards IP traffic using a label. This label instructs the routers and the switches in the network
where to forward the packets based on preestablished IP routing information.
Traffic engineering (TE) is the process of adjusting bandwidth allocations to ensure that enough is left
for high-priority traffic.
In MPLS TE, the upstream router creates a network tunnel for a particular traffic stream, then fixes the
bandwidth available for that tunnel.
Cisco Express Forwarding

Cisco Express Forwarding is an advanced, Layer 3 switching technology inside a router. It defines the
fastest method by which a Cisco router forwards packets from ingress to egress interfaces. The ip cef
command enables Cisco Express Forwarding globally, and the ip route-cache cef command enables
Cisco Express Forwarding on an interface.
How to Configure MPLS Traffic Engineering (TE)—IP Explicit

Address Exclusion
• Configuring IP Explicit Address Exclusion (required)
• Configuring an MPLS Traffic Engineering Tunnel (required)
Configuring IP Explicit Address Exclusion

To configure IP Explicit Address Exclusion, perform the following task.
SUMMARY STEPS
1. enable
3. ip explicit-path {name path-name | identifier number} [enable | disable]
4. exclude-address ip-address
5. exit
6. exit
7. show ip explicit-path
3
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 ip explicit-path {name path-name | identifier Specifies the name or number of the explicit path, and
number} [enable | disable] enables the path, and enters explicit-path configuration
mode.
Example:
Router(config)# ip explicit-path name OmitR12
Step 4 exclude-address ip-address Excludes the specified link or node from consideration by
the constraint-based SPF.
Example: • The ip-address is a link address or the router ID for a
Router(cfg-ip-expl-path)# exclude-address node.
10.12.12.12
Step 5 exit Exits from explicit-path configuration mode, and returns to
Example:
Step 6e exit Exits from global configuration mode, and returns to
Example:
Step 7 show ip explicit-path Displays information about configured IP explicit paths.
Example:
Router# show ip explicit-path

To configure an MPLS traffic engineering tunnel, perform the following steps.
SUMMARY STEPS
1. enable
4. ip unnumbered loopback0
4

8. tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name | ID
9. exit
10. show mpls traffic eng tunnels
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 ip unnumbered loopback0 Assigns the tunnel interface an IP address.
Example: unnumbered because it represents a unidirectional link.
Step 5 tunnel destination ip-address Specifies the destination for a tunnel.
• The destination of the tunnel must be the MPLS traffic
Example: engineering router ID of the destination device.
10.11.11.11
engineering.
Example:
tunnel.
Example:
bandwidth 100
5
Configuration Examples for MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion
Command Purpose
Step 8 tunnel mpls traffic-eng path-option number Configures the tunnel to use a named IP explicit path or a
{dynamic | explicit {name path-name | ID path dynamically calculated from the traffic engineering
topology database.
• A dynamic path is used if an explicit path is
Example: unavailable.
path-option 2 dynamic Note To configure a path option that specifies an exclude
address, specify the explicit keyword (not the
dynamic keyword) and specify an IP explicit path
configured according to the steps in the
“Configuring IP Explicit Address Exclusion”
section.
Step 9 exit Exits from interface configuration mode.
Example:
Example:
Step 11 show mpls traffic eng tunnels Shows information about tunnels, including the current
tunnel path if a tunnel is operational.
Example: • By viewing the command output, you can determine
Router# show mpls traffic eng tunnels the path that was used to build a tunnel. If you entered
the exclude-address command, the specified link or
node should not be listed.
Configuration Examples for MPLS Traffic Engineering (TE)—IP

Explicit Address Exclusion
This section includes the following configuration examples:
• Configuring IP Explicit Address Exclusion: Example, page 6
• Configuring an MPLS Traffic Engineering Tunnel: Example, page 7
Configuring IP Explicit Address Exclusion: Example

The following example shows how to configure an MPLS TE tunnel with two path options: a preferred
explicit path with an excluded address and a backup dynamic path.
Configure the IP explicit path named OmitR12, which excludes the router with router ID 10.12.12.12:
ip explicit-path name OmitR12
exclude-address 10.12.12.12
Explicit Path name OmitR12:
1: exclude-address 10.12.12.12
exit
6
To verify the configuration of the explicit path, use the show ip explicit-path command.
show ip explicit-paths name OmitR12
PATH OmitR12 (loose source route, path complete, generation 3)
1: exclude-address 10.12.12.12
Note You must know the router IDs for LSRs (nodes) in the network; in this example, that 10.12.12.12 is a
router ID. Otherwise, it will not be apparent whether the specified address is the IP address of a link or
a router ID.
Configuring an MPLS Traffic Engineering Tunnel: Example

The following example configures Tunnel11 with its two options, where the preferred path option is the
IP explicit path OmitR2:
interface tunnel11
tunnel mpls traffic-eng path-option 1 explicit name OmitR12
Note There are additional commands for configuring properties for TE tunnels such as bandwidth and priority.
For descriptions of those commands, refer to the Cisco IOS Multiprotocol Label Switching Command
Reference.
The following sections provide references related to the MPLS Traffic Engineering (TE)—IP Explicit
Address Exclusion feature.
Related Documents
MPLS configuration information Cisco IOS XE Multiprotocol Label Switching Configuration Guide
Standards
Standard Title
7
MIBs
MIB MIBs Link
RFCs
RFC Title
Description Link
8
Feature Information for MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion
Feature Information for MPLS Traffic Engineering (TE)—IP

Explicit Address Exclusion
Table 1 Feature Information for MPLS Traffic Engineering (TE)—IP Explicit Address Exclusion
Feature Name Releases Feature Configuration Information

MPLS Traffic Engineering (TE)—IP Cisco IOS XE The MPLS Traffic Engineering (TE)—IP Explicit Address
Explicit Address Exclusion Release 2.3 Exclusion feature provides a means to exclude a link or node
from the path for Multiprotocol Label Switching (MPLS) TE
label switched path (LSP).
feature:
• MPLS Traffic Engineering, page 3
• Cisco Express Forwarding, page 3
• Configuring IP Explicit Address Exclusion, page 3
page 4
The following command was introduced by this feature:
exclude-address.
9
Glossary
Glossary
storing route lookup information in several data structures instead of in a route cache.
IP explicit path—A list of IP addresses, each representing a node or link in the explicit path.
link—Network communications channel consisting of a circuit or transmission path and all related
equipment between a sender and a receiver. Sometimes referred to as a line or a transmission link.
MPLS—Multiprotocol Label Switching. Switching method that forwards IP traffic using a label. This
can be interconnected by links, and serve as control points in the network.
countries.
coincidental.
10
MPLS Layer 2 VPNs
Any Transport over MPLS

Last Updated: June 25, 2009
Any Transport over MPLS (AToM) transports data link layer (Layer 2) packets over a Multiprotocol
Label Switching (MPLS) backbone. AToM enables service providers to connect customer sites with
existing Layer 2 networks by using a single, integrated, packet-based network infrastructure—a Cisco
MPLS network. Instead of using separate networks with network management environments, service
providers can deliver Layer 2 connections over an MPLS backbone. AToM provides a common
framework to encapsulate and transport supported Layer 2 traffic types over an MPLS network core.
AToM supports the following like-to-like transport types:
• ATM Adaptation Layer Type-5 (AAL5) over MPLS
• ATM Cell Relay over MPLS
• Ethernet over MPLS (VLAN and port modes)
• Frame Relay over MPLS
• PPP over MPLS
• High-Level Data Link Control (HDLC) over MPLS

which each feature is supported, see the “Feature Information for Any Transport over MPLS” section on
page 80.
Contents
Contents
• Prerequisites for Any Transport over MPLS, page 2
• Restrictions for Any Transport over MPLS, page 2
• Information About Any Transport over MPLS, page 3
• How to Configure Any Transport over MPLS, page 12
• Configuration Examples for Any Transport over MPLS, page 68
• Feature Information for Any Transport over MPLS, page 80
Prerequisites for Any Transport over MPLS

Before configuring AToM, ensure that the network is configured as follows:
• Configure IP routing in the core so that the provider edge (PE) routers can reach each other via IP.
• Configure MPLS in the core so that a label-switched path (LSP) exists between the PE routers.
• Enable Cisco Express Forwarding before configuring any Layer 2 circuits.
• Configure a loopback interface for originating and terminating Layer 2 traffic. Make sure the PE
routers can access the other router’s loopback interface. Note that the loopback interface is not
needed in all cases. For example, tunnel selection does not need a loopback interface when AToM
is directly mapped to a traffic engineering (TE) tunnel.
Restrictions for Any Transport over MPLS

General Restrictions
The following general restrictions pertain to all transport types under AToM:
• Address format: Configure the Label Distribution Protocol (LDP) router ID on all PE routers to be
a loopback address with a /32 mask. Otherwise, some configurations might not function properly.
• Layer 2 virtual private networks (L2VPN) features (AToM and Layer 2 Tunnel Protocol Version 3
(L2TPv3)) are not supported on an ATM interface.
ATM Cell Relay over MPLS Restrictions

The following restrictions pertain to ATM Cell Relay over MPLS:
• For ATM Cell Relay over MPLS, if you have TE tunnels running between the PE routers, you must
enable LDP on the tunnel interfaces.
• The F4 end-to-end OAM cells are transparently transported along with the ATM cells. When a
permanent virtual path (PVP) or PVC is down on one PE router, the label associated with that PVP
or PVC is withdrawn. Subsequently, the peer PE router detects the label withdrawal and sends an F4
AIS/RDI signal to its corresponding CE router. The PVP or PVC on the peer PE router remains in
the up state.
2
Information About Any Transport over MPLS
Ethernet over MPLS (EoMPLS) Restrictions

The following restrictions pertain to the Ethernet over MPLS:
• Ethernet over MPLS supports VLAN packets that conform to the IEEE 802.1Q standard. The
802.1Q specification establishes a standard method for inserting VLAN membership information
into Ethernet frames. The Inter-Switch Link (ISL) protocol is not supported between the PE and CE
routers.
• The AToM control word is supported. However, if the peer PE does not support a control word, the
control word is disabled. This negotiation is done by LDP label binding.
• Ethernet packets with hardware-level cyclic redundancy check (CRC) errors, framing errors, and
runt packets are discarded on input.
Frame Relay ov MPLS Restrictions

For Frame Relay over MPLS, Frame Relay traffic shaping is not supported with AToM switched VCs.
Remote Ethernet Port Shutdown Restrictions

This feature is not symmetrical if the remote PE router is running an older version image or is on another
platform that does not support the EoMPLS remote Ethernet port shutdown feature and the local PE is
running an image which supports this feature.

To configure AToM, you must understand the following concepts:
• How AToM Transports Layer 2 Packets, page 3
• Benefits of AToM, page 4
• MPLS Traffic Engineering Fast Reroute, page 4
• Maximum Transmission Unit Guidelines for Estimating Packet Size, page 5
• Frame Relay over MPLS and DTE, DCE, and NNI Connections, page 7
• QoS Features Supported with AToM, page 9
• Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown, page 11
How AToM Transports Layer 2 Packets

AToM encapsulates Layer 2 frames at the ingress PE and sends them to a corresponding PE at the other
end of a pseudowire, which is a connection between the two PE routers. 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 due to the configuration of the
PE routers. You set up the connection, called a pseudowire, between the routers. You specify the
following information on each PE router:
• The type of Layer 2 data that will be transported across the pseudowire, such as Ethernet, Frame
Relay, or ATM
• The IP address of the loopback interface of the peer PE router, which enables the PE routers to
communicate
• A unique combination of peer PE IP address and VC ID that identifies the pseudowire
3
The following example shows the basic configuration steps on a PE router that enable the transport of
Layer 2 packets. Each transport type has slightly different steps.
Step 1 defines the interface or subinterface on the PE router:
Router# interface interface-type interface-number
Step 2 specifies the encapsulation type for the interface, such as dot1q:
Router(config-if)# encapsulation encapsulation-type
Step 3 does the following:

• Makes a connection to the peer PE router by specifying the LDP router ID of the peer PE router.
• Specifies a 32-bit unique identifier, called the VC ID, which is shared between the two PE routers.
The combination of the peer router ID and the VC ID must be unique on the router. Two circuits
cannot use the same combination of peer router ID and VC ID.
• Specifies the tunneling method used to encapsulate data in the pseudowire. AToM uses MPLS as the
tunneling method.
Router(config-if)# xconnect peer-router-id vcid encapsulation mpls
As an alternative, you can set up a pseudowire class to specify the tunneling method and other
characteristics. For more information, see the “Configuring the Pseudowire Class” section on page 13.
Benefits of AToM
The following list explains some of the benefits of enabling Layer 2 packets to be sent in the MPLS
network:
• The AToM product set accommodates many types of Layer 2 packets, including Ethernet and Frame
Relay, across multiple Cisco router platforms. This enables the service provider to transport all types
of traffic over the backbone and accommodate all types of customers.
• AToM adheres to the standards developed for transporting Layer 2 packets over MPLS. (See the
“Standards” section on page 77 for the specific standards that AToM follows.) This benefits the
service provider that wants to incorporate industry-standard methodologies in the network. Other
Layer 2 solutions are proprietary, which can limit the service provider’s ability to expand the
network and can force the service provider to use only one vendor’s equipment.
• Upgrading to AToM is transparent to the customer. Because the service provider network is separate
from the customer network, the service provider can upgrade to AToM without disruption of service
to the customer. The customers assume that they are using a traditional Layer 2 backbone.
MPLS Traffic Engineering Fast Reroute

AToM can use MPLS traffic engineering (TE) tunnels with fast reroute (FRR) support. AToM VCs can
be rerouted around a failed link or node at the same time as MPLS and IP prefixes.
Enabling fast reroute on AToM does not require any special commands; you can use standard fast reroute
commands. At the ingress PE, an AToM tunnel is protected by fast reroute when it is routed to an
FRR-protected TE tunnel. Both link and node protection are supported for AToM VCs at the ingress PE.
You can issue the debug mpls l2transport fast-reroute command to debug fast reroute with AToM.
4
Note This command does not display output on platforms where AToM fast reroute is implemented in the
forwarding code.
In the following example, the primary link is disabled, which causes the backup tunnel (Tunnel 1) to
become the primary path. In the following example, bolded output show the status of the tunnel:
Router# execute-on slot 3 debug mpls l2transport fast-reroute
========= Line Card (Slot 3) =========

AToM fast reroute debugging is on
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Processing TFIB FRR event for 10.4.0.1
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Finished processing TFIB FRR event for 10.4.0.1
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Processing TFIB FRR event for Tunnel41
SLOT 3:Sep 16 17:58:56.346: AToM SMGR: Finished processing TFIB FRR event for Tunnel41
Sep 16 17:58:58.342: %LINK-3-UPDOWN: Interface POS0/0/0, changed state to down
Sep 16 17:58:58.342: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on POS0/0 from FULL to DOWN,
Neighbor Down: Interface down or detached
Sep 16 17:58:59.342: %LINEPROTO-5-UPDOWN: Line protocol on Interface POS0/0/0, changed
state to down
Maximum Transmission Unit Guidelines for Estimating Packet Size

The following calculation helps you determine the size of the packets traveling through the core network.
You set the maximum transmission unit (MTU) on the core-facing interfaces of the P and PE routers to
accommodate packets of this size. The MTU should be greater than or equal to the total bytes of the items
in the following equation:
Core MTU >= (Edge MTU + Transport header + AToM header + (MPLS label stack * MPLS label
size))
The following sections describe the variables used in the equation.
Edge MTU
The edge MTU is the MTU for the customer-facing interfaces.
Transport Header
The Transport header depends on the transport type. Table 1 lists the specific sizes of the headers.
Table 1 Header Size of Packets
Transport Type Packet Size

AAL5 0–32 bytes
Ethernet VLAN 18 bytes
Ethernet Port 14 bytes
Frame Relay DLCI 2 bytes for Cisco encapsulation, 8 bytes for Internet
Engineering Task Force (IETF) encapsulation
HDLC 4 bytes
PPP 4 bytes
5
AToM Header
The AToM header is 4 bytes (control word). The control word is optional for Ethernet, PPP, HDLC, and
cell relay transport types. However, the control word is required for Frame Relay and ATM AAL5
transport types.
MPLS Label Stack

The MPLS label stack size depends on the configuration of the core MPLS network:
• AToM uses one MPLS label to identify the AToM VCs (VC label). Therefore, the minimum MPLS
label stack is one for directly connected AToM PEs, which are PE routers that do not have a P router
between them.
• If LDP is used in the MPLS network, the label stack size is two (the LDP label and the VC label).
• If a TE tunnel instead of LDP is used between PE routers in the MPLS network, the label stack size
is two (the TE label and the VC label).
• If a TE tunnel and LDP are used in the MPLS network (for example, a TE tunnel between P routers
or between P and PE routers, with LDP on the tunnel), the label stack is three (TE label, LDP label,
VC label).
• If you use MPLS fast reroute in the MPLS network, you add a label to the stack. The maximum
MPLS label stack in this case is four (FRR label, TE label, LDP label, VC label).
• If AToM is used by the customer carrier in an MPLS VPN Carrier Supporting Carrier environment,
you add a label to the stack. The maximum MPLS label stack in the provider carrier network is five
(FRR label, TE label, LDP label, VPN label, VC label).
• If an AToM tunnel spans different service providers that exchange MPLS labels using IPv4 Border
Gateway Protocol (BGP) (RFC 3107), you add a label to the stack. The maximum MPLS label stack
is five (FRR label, TE label, Border Gateway Protocol (BGP) label, LDP label, VC label).
Other circumstances can increase the MPLS label stack size. Therefore, analyze the complete data path
between the AToM tunnel endpoints and determine the maximum MPLS label stack size for your
network. Then multiply the label stack size by the size of the MPLS label.
Estimating Packet Size: Example

Thee size of packets is estimate in the following example, which uses the following assumptions:
• The edge MTU is 1500 bytes.
• The transport type is Ethernet VLAN, which designates 18 bytes for the transport header.
• The AToM header is 0, because the control word is not used.
• The MPLS label stack is 2, because LDP is used. The MPLS label is 4 bytes.
Edge MTU + Transport header + AToM header + (MPLS label stack * MPLS label) = Core MTU
1500 + 18 + 0 + (2 * 4 ) = 1526
You must configure the P and PE routers in the core to accept packets of 1526 bytes.
Once you determine the MTU size to set on your P and PE routers, you can issue the mtu command on
the routers to set the MTU size. The following example specifies an MTU of 1526 bytes:
Router(config-if)# mtu 1526
6
mpls mtu Command Changes

Some interfaces (such as Fast Ethernet) require the mpls mtu command to change the MTU size.
If the interface MTU is ferwer than 1524 bytes, you can set the maximum MPLS MTU to 24 bytes more
than the interface MTU. For example, if the interface MTU is set to 1510 bytes, then you can set the
maximum MPLS MTU to 1534 bytes (1510 + 24).
Caution Although you can set the MPLS MTU to a value greater than the interface MTU, set the MPLS MTU
less than or equal to the interface MTU to prevent data corruption, dropped packets, and high CPU rates.
If the interface MTU is greater than or equal to 1524 bytes, then you can set the maximum MPLS MTU
as high as the interface MTU. For example, if the interface MTU is set to 1600 bytes, then you can set
the MPLS MTU to a maximum of 1600 bytes. If you set the MPLS MTU higher than the interface MTU,
traffic is dropped.
For interfaces that do not allow you to configure the interface MTU value and the interface MTU is
1500 bytes, the MPLS MTU range is 64 to 1524 bytes.
Frame Relay over MPLS and DTE, DCE, and NNI Connections
You can configure an interface as a DTE device or a DCE switch, or as a switch connected to a switch
with network-to-network interface (NNI) connections. Use the following command in interface
configuration mode:
frame-relay intf-type [dce | dte | nni]
The keywords are explained in Table 2.
.
Table 2 frame-relay intf-type Command Keywords
Keyword Description
dce Enables the router or access server to function as a switch connected to a router.
dte Enables the router or access server to function as a DTE device. DTE is the default.
nni Enables the router or access server to function as a switch connected to a switch.
Local Management Interface and Frame Relay over MPLS

Local Management Interface (LMI) is a protocol that communicates status information about PVCs.
When a PVC is added, deleted, or changed, the LMI notifies the endpoint of the status change. LMI also
provides a polling mechanism that verifies that a link is up.
How LMI Works
To determine the PVC status, LMI checks that a PVC is available from the reporting device to the Frame
Relay end-user device. If a PVC is available, LMI reports that the status is “Active,” which means that
all interfaces, line protocols, and core segments are operational between the reporting device and the
Frame Relay end-user device. If any of those components is not available, the LMI reports a status of
“Inactive.”
7
Note Only the DCE and NNI interface types can report LMI status.
Figure 1 is a sample topology that helps illustrate how LMI works.
Figure 1 Sample Topology
59525
CE1 PE1 P PE2 CE2
In Figure 1, note the following:

• CE1 and PE1 and PE2 and CE2 are Frame Relay LMI peers.
• CE1 and CE2 can be Frame Relay switches or end-user devices.
• Each Frame Relay PVC comprises multiple segments.
• The DLCI value is local to each segment and is changed as traffic is switched from segment to
segment. Two Frame Relay PVC segments exist in Figure 1; one is between PE1 and CE1 and the
other is between PE2 and CE2.
The LMI protocol behavior depends on whether you have DLCI-to-DLCI or port-to-port connections.
DLCI-to-DLCI Connections
If you have DLCI-to-DLCI connections, LMI runs locally on the Frame Relay ports between the PE and
CE devices:
• CE1 sends an active status to PE1 if the PVC for CE1 is available. If CE1 is a switch, LMI checks
that the PVC is available from CE1 to the user device attached to CE1.
• PE1 sends an active status to CE1 if the following conditions are met:
– A PVC for PE1 is available.
– PE1 received an MPLS label from the remote PE router.
– An MPLS tunnel label exists between PE1 and the remote PE.
For DTE or DCE configurations, the following LMI behavior exists: The Frame Relay device accessing
the network (DTE) does not report PVC status. Only the network device (DCE) or NNI can report status.
Therefore, if a problem exists on the DTE side, the DCE is not aware of the problem.
Port-to-Port Connections
If you have port-to-port connections, the PE routers do not participate in the LMI status-checking
procedures. LMI operates between the CE routers only. The CE routers must be configured as DCE-DTE
or NNI-NNI.
8
QoS Features Supported with AToM

The following tables list the QoS features supported by AToM:
• Table 3, QoS Features Supported with Ethernet over MPLS
• Table 4, QoS Features Supported with Frame Relay over MPLS
• Table 5, QoS Features Supported with ATM Cell Relay and AAL5 over MPLS
Table 3 QoS Features Supported with Ethernet over MPLS
QoS Feature Ethernet over MPLS

Service policy Can be applied to:
• Interface (input and output)
• Subinterface (input and output)
Classification Supports the following commands:
• match cos (on interfaces and subinterfaces)
• match mpls experimental (on interfaces and subinterfaces)
• match qos-group (on interfaces) (output policy)
Marking Supports the following commands:
• set cos (output policy)
• set discard-class (input policy)
• set mpls experimental (input policy) (on interfaces and subinterfaces)
• set qos-group (input policy)
Policing Supports the following:
• Single-rate policing
• Two-rate policing
• Color-aware policing
• Multiple-action policing
Queueing and Supports the following:
shaping
• Low Latency Queueing (LLQ)
• Weighted Random Early Detection (WRED)
• Byte-based WRED
9
Table 4 QoS Features Supported with Frame Relay over MPLS
QoS Feature Frame Relay over MPLS

• PVC (input and output)
• match fr-de (on interfaces and VCs)
• match fr-dlci (on interfaces)
• match qos-group
• frame-relay congestion management (output)
• set discard-class
• set fr-de (output policy)
• set fr-fecn-becn (output)
• set mpls experimental
• set qos-group
• threshold ecn (output)
Queueing and Supports the following:
shaping • LLQ
• WRED
• Traffic shaping
• Cclass-based weighted fair queueing (CBWFQ)
• Byte-based WRED
• random-detect discard-class-based command
10
Table 5 QoS Features Supported with ATM Cell Relay and AAL5 over MPLS
QoS Feature ATM Cell Relay and AAL5 over MPLS

• Subinterface (input and output)
• PVC (input and output)
• match mpls experimental (on VCs)
• match qos-group (output)
• random-detect discard-class-based (input)
• set clp (output) (on interfaces, subinterfaces, and VCs)
• set discard-class (input)
• set mpls experimental (input) (on interfaces, subinterfaces, and
VCs)
• set qos-group (input)
Queueing and shaping Supports the following:
• LLQ
• WRED
• CBWFQ
• Byte-based WRED
• random-detect discard-class-based command
• Class-based shaping support on ATM PVCs
Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown

This Cisco IOS XE feature allows a service provider edge (PE) router on the local end of an Ethernet
over MPLS (EoMPLS) pseudowire to detect a remote link failure and cause the shutdown of the Ethernet
port on the local customer edge (CE) router. Because the Ethernet port on the local CE router is shut
down, the router does not lose data by continuously sending traffic to the failed remote link. This is
beneficial if the link is configured as a static IP route.
Figure 2 illustrates a condition in an EoMPLS WAN, with a down Layer 2 tunnel link between a CE
router (Customer Edge 1) and the PE router (Provider Edge 1). A CE router on the far side of the Layer
2 tunnel (Customer Edge 2), continues to forward traffic to Customer Edge 1 through the L2 tunnel.
11
How to Configure Any Transport over MPLS
Figure 2 Remote Link Outage in EoMPLS Wide Area Network
Ethernet Ethernet over MPLS Ethernet

(EoMPLS)
192856
Customer Edge 1 Provider Edge 1 Provider Edge 2 Customer Edge 2
Previous to this feature, the Provider Edge 2 router could not detect a failed remote link. Traffic
forwarded from Customer Edge 2 to Customer Edge 1 would be lost until routing or spanning tree
protocols detected the down remote link. If the link was configured with static routing, the remote link
outage would be even more difficult to detect.
With Book Title, the Provider Edge 2 router detects the remote link failure and causes a shutdown of the
local Customer Edge 2 Ethernet port. When the remote L2 tunnel link is restored, the local interface is
automatically restored as well. The possibility of data loss is thus diminished.
With reference to Figure 2, the Remote Ethernet Shutdown sequence is generally described as follows:
1. The remote link between Customer Edge 1 and Provider Edge 1 fails.
2. Provider Edge 2 detects the remote link failure and disables the transmit laser on the line card
interface connected to Customer Edge 2.
3. An RX_LOS error alarm is received by Customer Edge 2 causing Customer Edge 2 to bring down
the interface.
4. Provider Edge 2 maintains its interface with Customer Edge 2 in an up state.
5. When the remote link and EoMPLS connection is restored, the Provider Edge 2 router enables the
transmit laser.
6. The Customer Edge 2 router brings up its downed interface.
The Book Title feature is enabled by default for Ethernet over MPLS (EoMPLS), and can be disabled
using no remote link failure notification command in the xconnect configuration mode. Use the show
ip interface brief privileged EXEC command to display the status of all remote L2 tunnel links. Use the
show interface slot/number privileged EXEC command to show the status of the L2 tunnel on a specific
interface.
Note The no remote link failure notification command will not give notification to clients for remote
attachment circuit status down.

This section explains how to perform a basic AToM configuration and includes the following procedures:
• Configuring the Pseudowire Class, page 13 (required)
• Configuring ATM AAL5 over MPLS on PVCs, page 14 (optional)
• Configuring ATM AAL5 over MPLS in VC Class Configuration Mode, page 16 (optional)
• Configuring OAM Cell Emulation for ATM AAL5 over MPLS, page 19 (optional)
• Configuring OAM Cell Emulation for ATM AAL5 over MPLS on PVCs, page 19 (optional)
• Configuring OAM Cell Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode,
page 22 (optional)
12
• Configuring ATM Cell Relay over MPLS in VC Mode, page 25 (optional)

• Configuring ATM Cell Relay over MPLS in VC Mode Using VC Class Configuration Mode,
page 26 (optional)
• Configuring ATM Cell Relay over MPLS in PVP Mode, page 28 (optional)
• Configuring in Port Mode, page 31 (optional)
• Configuring ATM Single Cell Relay over MPLS, page 33 (optional)
• Configuring ATM Packed Cell Relay over MPLS, page 34 (optional)
• Configuring Ethernet over MPLS in VLAN Mode, page 46 (optional)
• Configuring Ethernet over MPLS in Port Mode, page 47 (optional)
• Configuring Ethernet over MPLS with VLAN ID Rewrite, page 49 (optional)
• Configuring per-Subinterface MTU for Ethernet over MPLS, page 52 (optional)
• Configuring Frame Relay over MPLS with DLCI-to-DLCI Connections, page 54 (optional)
• Configuring Frame Relay over MPLS with Port-to-Port Connections, page 56 (optional)
• Configuring HDLC and PPP over MPLS, page 57 (optional)
• Configuring Tunnel Selection, page 59 (optional)
• Setting Experimental Bits with AToM, page 64 (optional)
• Configuring MPLS AToM Remote Ethernet Port Shutdown, page 66 (optional)
Configuring the Pseudowire Class

PE routers. You set up the connection, called a pseudowire, between the routers.
Note In simple configurations, this task is optional. You do not need to specify a pseudowire class if you
specify the tunneling method as part of the xconnect command.
The pseudowire-class configuration group specifies the following characteristics of the tunneling
mechanism:
• Encapsulation type
• Control protocol
• Payload-specific options
You must specify the encapsulation mpls command as part of the pseudowire class or as part of the
xconnect command for the AToM VCs to work properly. If you omit the encapsulation mpls command
as part of the xconnect command, you receive the following error:
% Incomplete command.
Once you specify the encapsulation mpls command, you cannot remove it using the no encapsulation
mpls command. Nor can you change the command's setting using the encapsulation l2tpv3 command.
Those methods result in the following error message:
Encapsulation changes are not allowed on an existing pw-class.
13
To remove the command, you must delete the pseudowire with the no pseudowire-class command. To
change the type of encapsulation, remove the pseudowire with the no pseudowire-class command and
reestablish the pseudowire and specify the new encapsulation type.
SUMMARY STEPS
1. enable
3. pseudowire-class name
4. encapsulation mpls
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class name Establishes a pseudowire class with a name that you specify and enters
pseudowire class configuration mode.
Example:
Router(config)# pseudowire-class atom
Step 4 encapsulation mpls Specifies the tunneling encapsulation.
Example:
Router(config-pw)# encapsulation mpls
Configuring ATM AAL5 over MPLS on PVCs

ATM AAL5 over MPLS for permanent virtual circuits encapsulates ATM AAL5 service data unit
(SDUs) in MPLS packets and forwards them across the MPLS network. Each ATM AAL5 SDU is
transported as a single packet.
Restrictions
AAL5 over MPLS is supported only in SDU mode.
SUMMARY STEPS
1. enable
3. interface type slot/subslot/port[.subinterface]
14
4. pvc [name] vpi/vci l2transport

5. encapsulation aal5
6. xconnect peer-router-id vcid encapsulation mpls
7. exit
8. exit
9. exit
10. show mpls l2transport vc
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/subslot/port[.subinterface] Specifies the interface type and enters interface
configuration mode.
Example:
Step 4 pvc [name] vpi/vci l2transport Creates or assigns a name to an ATM PVC and enters
L2transport configuration mode.
Example: • The l2transport keyword indicates that the PVC is
Router(config-if)# pvc 1/200 l2transport a switched PVC instead of a terminated PVC.
Step 5 encapsulation aal5 Specifies ATM AAL5 encapsulation for the PVC. Make
sure you specify the same encapsulation type on the PE
and customer edge (CE) routers.
Example:
Router(config-if-atm-l2trans-pvc)# encapsulation
aal5
Step 6 xconnect peer-router-id vcid encapsulation mpls Binds the attachment circuit to a pseudowire VC.
Example:
Router(config-if-atm-l2trans-pvc)# xconnect
10.13.13.13 100 encapsulation mpls
Step 7 exit Exits L2transport configuration mode.
Example:
Router(config-if-atm-l2trans-pvc)# exit
15

Example:
Example:
Step 10 show mpls l2transport vc Displays output that shows ATM AAL5 over MPLS is
configured on a PVC.
Example:
Router# show mpls l2transport vc
Examples
The following example enables ATM AAL5 over MPLS on an ATM PVC:
enable
configure terminal
interface atm1/0/0
pvc 1/200 l2transport
encapsulation aal5
xconnect 10.13.13.13 100 encapsulation mpls
The following is example output from the show mpls l2transport vc, which shows that ATM AAL5 over
MPLS is configured on a PVC:
Local intf Local circuit Dest address VC ID Status

--------- ------------- ------------ ----- ------
ATM1/0 ATM AAL5 1/100 10.4.4.4 100 UP
Configuring ATM AAL5 over MPLS in VC Class Configuration Mode

You can create a VC class that specifies the AAL5 encapsulation and then attach the encapsulation type
to an interface, subinterface, or PVC. The following task creates a VC class and attaches it to a main
interface.
Restriction
AAL5 over MPLS is supported only in SDU mode.
SUMMARY STEPS
1. enable
3. vc-class atm vc-class-name
4. encapsulation layer-type
16
5. exit
7. class-int vc-class-name
10. exit
11. exit
12. exit
13. show atm class-links
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 vc-class atm vc-class-name Creates a VC class and enters VC class configuration
mode.
Example:
Router(config)# vc-class atm aal5class
Step 4 encapsulation layer-type Configures the AAL and encapsulation type.
Example:
Router(config-vc-class)# encapsulation aal5
Step 5 exit Exits VC class configuration mode.
Example:
Router(config-vc-class)# exit
Step 6 interface type slot/subslot/port[.subinterface] Specifies the interface type enters interface configuration
mode.
Example:
Step 7 class-int vc-class-name Applies a VC class to the ATM main interface or
subinterface.
Example: Note You can also apply a VC class to a PVC.
Router(config-if)# class-int aal5class
17

L2transport VC configuration mode.
Example:
Example:
Example:
Example:
Step 13 show atm class-links Displays the type of encapsulation and that the VC class
was applied to an interface.
Example:
Router# show atm class-links
Examples
The following example configures ATM AAL5 over MPLS in VC class configuration mode. The VC
class is then applied to an interface.
enable
configure terminal
vc-class atm aal5class
encapsulation aal5
interface atm1/0/0
class-int aal5class
The following example configures ATM AAL5 over MPLS in VC class configuration mode. The VC
class is then applied to a PVC.
enable
configure terminal
vc-class atm aal5class
encapsulation aal5
interface atm1/0/0
class-vc aal5class
18
In the following example, the command output of the show atm class-links command verifies that ATM
AAL5 over MPLS is configured as part of a VC class. The command output shows the type of
encapsulation and that the VC class was applied to an interface.
Router# show atm class-links 1/100
Displaying vc-class inheritance for ATM1/0/0.0, vc 1/100:

no broadcast - Not configured - using default
encapsulation aal5 - VC-class configured on main interface
Configuring OAM Cell Emulation for ATM AAL5 over MPLS

If a PE router does not support the transport of Operation, Administration, and Maintenance (OAM) cells
across a label switched path (LSP), you can use OAM cell emulation to locally terminate or loop back
the OAM cells. You configure OAM cell emulation on both PE routers, which emulates a VC by forming
two unidirectional LSPs. You use the oam-ac emulation-enable and oam-pvc manage commands on
both PE routers to enable OAM cell emulation.
After you enable OAM cell emulation on a router, you can configure and manage the ATM VC in the
same manner as you would a terminated VC. A VC that has been configured with OAM cell emulation
can send loopback cells at configured intervals toward the local CE router. The endpoint can be either of
the following:
• End-to-end loopback, which sends OAM cells to the local CE router.
• Segment loopback, which responds to OAM cells to a device along the path between the PE and CE
routers.
The OAM cells include the following cells:
• Alarm indication signal (AIS)
• Remote defect indication (RDI)
These cells identify and report defects along a VC. When a physical link or interface failure occurs,
intermediate nodes insert OAM AIS cells into all the downstream devices affected by the failure. When
a router receives an AIS cell, it marks the ATM VC down and sends an RDI cell to let the remote end
know about the failure.
This section contains two tasks:
• Configuring OAM Cell Emulation for ATM AAL5 over MPLS on PVCs, page 19
• Configuring OAM Cell Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode,
page 22
Configuring OAM Cell Emulation for ATM AAL5 over MPLS on PVCs
Perform this task to configure OAM cell emulation for ATM AAL5 over MPLS on a PVC.
Note For AAL5 over MPLS, you can configure the oam-pvc manage command only after you issue the
oam-ac emulation-enable command.
19
SUMMARY STEPS
1. enable
7. oam-ac emulation-enable [ais-rate]
8. oam-pvc manage [frequency]
9. exit
10. exit
11. exit
12. show atm pvc
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/subslot/port[.subinterface] Specifies the interface type enters interface configuration
mode.
Example:
Step 5 encapsulation aal5 Specifies ATM AAL5 encapsulation for the PVC. Make
and CE routers.
Example:
aal5
Example:
20

Step 7 oam-ac emulation-enable [ais-rate] Enables OAM cell emulation for AAL5 over MPLS. The
ais-rate argument lets you specify the rate at which AIS
cells are sent. The default is one cell every second. The
Example:
Router(config-if-atm-l2trans-pvc)# oam-ac
range is 0 to 60 seconds.
emulation-enable 30
Step 8 oam-pvc manage [frequency] Enables the PVC to generate end-to-end OAM loopback
cells that verify connectivity on the virtual circuit.
Example: The optional frequency argument is the interval between
Router(config-if-atm-l2trans-pvc)# oam-pvc transmission of loopback cells and ranges from 0 to
manage 600 seconds. The default value is 10 seconds.
Example:
Example:
Example:
Step 12 show atm pvc Displays output that shows OAM cell emulation is
enabled on the ATM PVC.
Example:
Router# show atm pvc
Examples
The following example enables OAM cell emulation on an ATM PVC:
interface ATM 1/0/0
encapsulation aal5
oam-ac emulation-enable
oam-pvc manage
The following example sets the rate at which an AIS cell is sent every 30 seconds:
interface ATM 1/0/0
encapsulation aal5
oam-ac emulation-enable 30
oam-pvc manage
The output of the show atm pvc command in the following example shows that OAM cell emulation is
enabled on the ATM PVC:
Router# show atm pvc 5/500
21
ATM4/1/0.200: VCD: 6, VPI: 5, VCI: 500

UBR, PeakRate: 1
AAL5-LLC/SNAP, etype:0x0, Flags: 0x34000C20, VCmode: 0x0
OAM Cell Emulation: enabled, F5 End2end AIS Xmit frequency: 1 second(s)
OAM frequency: 0 second(s), OAM retry frequency: 1 second(s)
OAM up retry count: 3, OAM down retry count: 5
OAM Loopback status: OAM Disabled
OAM VC state: Not ManagedVerified
ILMI VC state: Not Managed
InPkts: 564, OutPkts: 560, InBytes: 19792, OutBytes: 19680
InPRoc: 0, OutPRoc: 0
InFast: 4, OutFast: 0, InAS: 560, OutAS: 560
InPktDrops: 0, OutPktDrops: 0
CrcErrors: 0, SarTimeOuts: 0, OverSizedSDUs: 0
Out CLP=1 Pkts: 0
OAM cells received: 26
F5 InEndloop: 0, F5 InSegloop: 0, F5 InAIS: 0, F5 InRDI: 26
OAM cells sent: 77
F5 OutEndloop: 0, F5 OutSegloop: 0, F5 OutAIS: 77, F5 OutRDI: 0
OAM cell drops: 0
Status: UP
Configuring OAM Cell Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode
The following steps explain how to configure OAM cell emulation as part of a VC class. You can then
apply the VC class to an interface, a subinterface, or a VC. When you configure OAM cell emulation in
VC class configuration mode and then apply the VC class to an interface, the settings in the VC class
apply to all the VCs on the interface, unless you specify a different OAM cell emulation value at a lower
level, such as the subinterface or VC level. For example, you can create a VC class that specifies OAM
cell emulation and sets the rate of AIS cells to every 30 seconds. You can apply the VC class to an
interface. Then, for one PVC, you can enable OAM cell emulation and set the rate of AIS cells to every
15 seconds. All the PVCs on the interface use the cell rate of 30 seconds, except for the one PVC that
was set to 15 seconds.
Perform this task to enable OAM cell emulation as part of a VC class and apply it to an interface.
Note For AAL5 over MPLS, you can configure the oam-pvc manage command only after you issue the
oam-ac emulation-enable command.
SUMMARY STEPS
1. enable
3. vc-class atm name
5. oam-ac emulation-enable [ais-rate]
6. oam-pvc manage [frequency]
7. exit
22
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 vc-class atm name Creates a VC class and enters VC class configuration
mode.
Example:
Router(config)# vc-class atm oamclass
Example:
Step 5 oam-ac emulation-enable [ais-rate] Enables OAM cell emulation for AAL5 over MPLS. The
ais-rate argument lets you specify the rate at which AIS
cells are sent. The default is one cell every second. The
Example:
Router(config-vc-class)# oam-ac emulation-enable
range is 0 to 60 seconds.
30
Step 6 oam-pvc manage [frequency] Enables the PVC to generate end-to-end OAM loopback
cells that verify connectivity on the virtual circuit.
Example: The optional frequency argument is the interval between
Router(config-vc-class)# oam-pvc manage transmission of loopback cells and ranges from 0 to
600 seconds. The default value is 10 seconds.
Example:
configuration mode.
Example:
subinterface.
Router(config-if)# class-int oamclass
23

Example:
Examples
The following example configures OAM cell emulation for ATM AAL5 over MPLS in VC class
configuration mode. The VC class is then applied to an interface.
enable
configure terminal
vc-class atm oamclass
encapsulation aal5
oam-pvc manage
interface atm1/0/0
class-int oamclass
configuration mode. The VC class is then applied to a PVC.
enable
configure terminal
encapsulation aal5
oam-pvc manage
interface atm1/0/0
class-vc oamclass
configuration mode. The VC class is then applied to an interface. One PVC is configured with OAM cell
emulation at an AIS rate of 10. That PVC uses the AIS rate of 10 instead of 30.
enable
configure terminal
encapsulation aal5
oam-pvc manage
interface atm1/0/0
class-int oamclass
24
Configuring ATM Cell Relay over MPLS in VC Mode

Perform this task to configure ATM cell relay on the permanent virtual circuits.
SUMMARY STEPS
1. enable
3. interface atm slot/subslot/port[.subinterface]
4. pvc vpi/vci l2transport
7. exit
8. exit
9. exit
10. show atm vc
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface atm slot/subslot/port[.subinterface] Specifies an ATM interface and enters interface
configuration mode.
Example:
Step 4 pvc vpi/vci l2transport Assigns a virtual path identifier (VPI) and virtual circuit
identifier (VCI) and enters L2transport VC configuration
mode.
Example:
Router(config-if)# pvc 0/100 l2transport • The l2transport keyword indicates that the PVC is a
switched PVC instead of a terminated PVC.
Step 5 encapsulation aal0 For ATM cell relay, specifies raw cell encapsulation for the
interface. Make sure you specify the same encapsulation
type on the PE and CE routers.
Example:
Router(config-if-atm-l2trans-pvc)#
encapsulation aal0
25

Example:
Example:
Example:
Example:
Step 10 show atm vc Verifies that OAM cell emulation is enabled on the ATM
VC.
Example:
Router# show atm vc
Example
The output of the following show atm vc command shows that the interface is configured for VC mode
cell relay:
Router# show atm vc 7
ATM3/0: VCD: 7, VPI: 23, VCI: 100

UBR, PeakRate: 149760
AAL0-Cell Relay, etype:0x10, Flags: 0x10000C2D, VCmode: 0x0
OAM Cell Emulation: not configured
InBytes: 0, OutBytes: 0
Status: UP
Configuring ATM Cell Relay over MPLS in VC Mode Using VC Class

Configuration Mode
You can create a VC class that specifies the ATM cell relay encapsulation and then attach the VC class
to an interface, subinterface, or VC. The following task creates a VC class that specifies the ATM cell
relay encapsulation and attaches it to a main interface.
Note You can configure VC class configuration mode only in VC mode. VC class configuration mode is not
supported on VP or port mode.
26
SUMMARY STEPS
1. enable
5. exit
DETAILED STEPS

Example:
Router> enable
Example:
mode.
Example:
Router(config)# vc-class atm cellrelay
Example:
Example:
configuration mode.
Example:
subinterface.
Router(config-if)# class-int cellrelay
27

Example:
Examples
The following example configures ATM cell relay over MPLS in VC class configuration mode. The VC
class is then applied to an interface.
enable
configure terminal
vc-class atm cellrelay
encapsulation aal0
interface atm1/0/0
class-int cellrelay
The following example configures ATM cell relay over MPLS in VC class configuration mode. The VC
class is then applied to a PVC.
enable
configure terminal
vc-class atm cellrelay
encapsulation aal0
interface atm1/0/0
class-vc cellrelay
Configuring ATM Cell Relay over MPLS in PVP Mode

VP mode allows cells coming into a predefined PVP on the ATM interface to be transported over the
MPLS backbone to a predefined PVP on the egress ATM interface. You can use VP mode to send single
cells or packed cells over the MPLS backbone.
To configure VP mode, you must specify the following:
• The VP for transporting cell relay cells.
• The IP address of the peer PE router and the VC ID.
When configuring in VP mode, use the following guidelines:
• You do not need to enter the encapsulation aal0 command in VP mode.
• One ATM interface can accommodate multiple types of ATM connections. VP cell relay, VC cell
relay, and ATM AAL5 over MPLS can coexist on one ATM interface.
• If a VPI is configured for VP cell relay, you cannot configure a PVC using the same VPI.
28
• VP trunking (mapping multiple VPs to one emulated VC label) is not supported. Each VP is mapped
to one emulated VC.
• Each VP is associated with one unique emulated VC ID. The AToM emulated VC type is ATM VP
cell transport.
• The AToM control word is supported. However, if a peer PE does not support the control word, it is
disabled. This negotiation is done by LDP label binding.
• VP mode (and VC mode) drop idle cells.
Perform this task to configure ATM cell relay in PVP mode.
SUMMARY STEPS
1. enable
4. atm pvp vpi l2transport
6. exit
7. exit
8. exit
9. show atm vp
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface atm Defines the interface and enters interface configuration mode.
slot/subslot/port[.subinterface]
Example:
Step 4 atm pvp vpi l2transport Specifies that the PVP is dedicated to transporting ATM cells and
enters l2transport PVP configuration submode.
Example: The l2transport keyword indicates that the PVP is for cell relay.
Router(config-if)# atm pvp 1 l2transport This submode is for Layer 2 transport only; it is not for regular
PVPs.
29

Step 5 xconnect peer-router-id vcid Binds the attachment circuit to a pseudowire VC. The syntax for
encapsulation mpls this command is the same as for all other Layer 2 transports.
Example:
Router(config-if-atm-l2trans-pvp)#
Example:
Example:
Example:
Step 9 show atm vp Displays output that shows OAM cell emulation is enabled on the
ATM VP.
Example:
Router# show atm vp
Examples
The following example transports single ATM cells over a virtual path:
pseudowire-class vp-cell-relay
encapsulation mpls
interface atm 5/0
atm pvp 1 l2transport
xconnect 10.0.0.1 123 pw-class vp-cell-relay
The following show atm vp command in the following example shows that the interface is configured
for VP mode cell relay:
Router# show atm vp 1
ATM5/0 VPI: 1, Cell Relay, PeakRate: 149760, CesRate: 0, DataVCs: 1, CesVCs: 0, Status:
ACTIVE
VCD VCI Type InPkts OutPkts AAL/Encap Status

6 3 PVC 0 0 F4 OAM ACTIVE
TotalInPkts: 0, TotalOutPkts: 0, TotalInFast: 0, TotalOutFast: 0,

TotalBroadcasts: 0 TotalInPktDrops: 0, TotalOutPktDrops: 0
30
Configuring in Port Mode

Port mode cell relay allows cells coming into an ATM interface to be packed into an MPLS packet and
transported over the MPLS backbone to an egress ATM interface.
To configure port mode, issue the xconnect command from an ATM main interface and specify the
destination address and the VC ID. The syntax of the xconnect command is the same as for all other
transport types. Each ATM port is associated with one unique pseudowire VC label.
When configuring in port mode, use the following guidelines:
• The pseudowire VC type is set to ATM transparent cell transport (AAL0).
• The AToM control word is supported. However, if the peer PE does not support a control word, the
control word is disabled. This negotiation is done by LDP label binding.
• Port mode and VP and VC mode are mutually exclusive. If you enable an ATM main interface for
cell relay, you cannot enter any PVP or PVC commands.
• If the pseudowire VC label is withdrawn due to an MPLS core network failure, the PE router sends
a line AIS to the CE router.
SUMMARY STEPS
1. enable
5. exit
6. exit
7. show atm route
DETAILED STEPS

Example:
Router> enable
Example:
31

configuration mode.
Example:
Step 4 xconnect peer-router-id vcid encapsulation mpls Binds the attachment circuit to the interface.
Example:
Router(config-if)# xconnect 10.0.0.1 123
encapsulation mpls
Example:
Example:
Step 7 show atm route Displays output that shows ATM cell relay in port mode
has been enabled.
Example:
Router# show atm route
Step 8 show mpls l2transport vc Displays the attachment circuit and the interface.
Example:
Examples
The following example shows interface ATM 5/0/0 configured to transport ATM cell relay packets:
pseudowire-class atm-cell-relay
encapsulation mpls
interface atm 5/0/0
xconnect 10.0.0.1 123 pw-class atm-cell-relay
The show atm route command in the following example displays port mode cell relay state. The
following example shows that atm interface 1/0/0 is for cell relay, the VC ID is 123 and the tunnel is
down.
Router# show atm route
Input Intf Output Intf Output VC Status

ATM1/0/0 ATOM Tunnel 123 DOWN
The show mpls l2transport vc command in the following example also shows configuration
information.
32

------------- -------------------- --------------- ---------- ----------
ATM1/0/0 ATM CELL ATM1/0 10.1.1.121 1121 UP
The debug atm l2transport and debug mpls l2transport vc display troubleshooting information.
Configuring ATM Single Cell Relay over MPLS

The single cell relay feature allows you to insert one ATM cell in each MPLS packet. You can use single
cell relay in both VP and VC mode. The configuration steps show how to configure single cell relay in
VC mode. For VP mode, see the “Configuring ATM Cell Relay over MPLS in PVP Mode” section on
page 28.
SUMMARY STEPS
1. enable
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
33

Step 4 pvc vpi/vci l2transport Assigns a VPI and VCI and enters L2transport VC
configuration mode.
Example: The l2transport keyword indicates that the PVC is a
Router(config-if)# pvc 1/100 l2transport switched PVC instead of a terminated PVC.
Step 5 encapsulation aal0 Specifies raw cell encapsulation for the interface. Make
and CE routers.
Example:
aal0
Example:
Configuring ATM Packed Cell Relay over MPLS

The packed cell relay feature allows you to insert multiple concatenated ATM cells in an MPLS packet.
The packed cell relay feature is more efficient than single cell relay, because each ATM cell is 52 bytes,
and each AToM packet is at least 64 bytes.
At a high level, packed cell relay configuration consists of the following steps:
1. You specify the amount of time a PE router can wait for cells to be packed into an MPLS packet.
You can set up three timers by default with different amounts of time attributed to each timer.
2. You enable packed cell relay, specify how many cells should be packed into each MPLS packet, and
choose which timer to use during the cell packing process.
Restrictions
• The cell-packing command is available only if you use AAL0 encapsulation in VC mode. If the
command is configured with ATM AAL5 encapsulation, the command is not valid.
• Only cells from the same VC, VP, or port can be packed into one MPLS packet. Cells from different
connections cannot be concatenated into the same MPLS packet.
• When you change, enable, or disable the cell-packing attributes, the ATM VC, VP, or port and the
MPLS emulated VC are reestablished.
• If a PE router does not support packed cell relay, the PE router sends only one cell per MPLS packet.
• The number of packed cells does not need to match between the PE routers. The two PE routers
agree on the lower of the two values. For example, if PE1 is allowed to pack 10 cells per MPLS
packet and PE2 is allowed to pack 20 cells per MPLS packet, the two PE routers would agree to send
no more than 10 cells per packet.
• If the number of cells packed by the peer PE router exceeds the limit, the packet is dropped.
• Issue the atm mcpt-timers command on an ATM interface before issuing the cell-packing
command.
34
See the following sections for configuration information:

• Configuring ATM Packed Cell Relay over MPLS in VC Mode, page 35
• Configuring ATM Packed Cell Relay over MPLS in VC Mode Using VC Class Configuration Mode,
page 37
• Configuring ATM Packed Cell Relay over MPLS in VP Mode, page 41
• Configuring ATM Packed Cell Relay over MPLS in Port Mode, page 43
Configuring ATM Packed Cell Relay over MPLS in VC Mode

Perform this task to configure the ATM packed cell relay over MPLS feature in VC mode.
SUMMARY STEPS
1. enable
4. shutdown
5. atm mcpt-timers [timer1-timeout timer2-timeout timer3-timeout]
6. no shutdown
10. cell-packing [cells] [mcpt-timer timer]
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 shutdown Shuts down the interface.
Example:
35

Step 5 atm mcpt-timers [timer1-timeout timer2-timeout Sets up the cell-packing timers, which specify how long the
timer3-timeout] PE router can wait for cells to be packed into an MPLS
packet.
Example: You can set up to three timers. For each timer, you specify
Router(config-if)# atm mcpt-timers 100 200 250 the maximum cell-packing timeout (MCPT). This value
gives the cell-packing function a limited amount of time to
complete. If the timer expires before the maximum number
of cells are packed into an AToM packet, the packet is sent
anyway. The timeout’s default and range of acceptable
values depends on the ATM link speed.
The respective default values for the PA-A3 port adapters
are:
• OC-3: 30, 60, and 90 microseconds
• T3: 100, 200, and 300 microseconds
• E3: 130, 260, and 390 microseconds
You can specify either the number of microseconds or use
the default.
The respective range of values for the PA-A3 port adapters
are:
• OC-3: 10 to 4095 microseconds
• T3: 30 to 4095 microseconds
• E3: 40 to 4095 microseconds
Step 6 no shutdown Enables the interface.
Example:
configuration mode.
Example: • The l2transport keyword indicates that the PVC is a
Router(config-if)# pvc 1/100 l2transport switched PVC instead of a terminated PVC.
Step 8 encapsulation aal0 Specifies raw cell encapsulation for the interface. Make
routers.
Example:
Router(config-if-atm-l2trans-pvc)#
encapsulation aal0
36

Example:
Step 10 cell-packing [cells] [mcpt-timer timer] Enables cell packing and specifies the cell-packing
parameters.
Example: The cells argument represents the maximum number of
Router(config-if-atm-l2trans-pvc)# cell-packing cells to be packed into an MPLS packet. The range is from
10 mcpt-timer 1 2 to the MTU of the interface divided by 52. The default is
MTU/52.
The timer argument allows you to specify which timer to
use. The default is timer 1.
See the cell-packing command page for more information.
Examples
The following example shows that ATM PVC 1/100 is an AToM cell relay PVC. There are three timers
set up, with values of 1000 milliseconds, 800 milliseconds, and 500 milliseconds, respectively. The
cell-packing command specifies that five ATM cells are to be packed into an MPLS packet. The
cell-packing command also specifies that timer 1 is to be used.
interface atm 1/0/0
shutdown
atm mcpt-timer 1000 800 500
no shutdown
encapsulation aal0
cell-packing 5 mcpt-timer 1
Configuring ATM Packed Cell Relay over MPLS in VC Mode Using VC Class Configuration Mode
You can create a VC class that specifies the ATM cell relay encapsulation and the cell packing
parameters and then attach the VC class to an interface, subinterface, or VC. The following task creates
a VC class that specifies the ATM cell relay encapsulation and cell packing and attaches it to a main
interface.
Note You can configure VC class configuration mode only in VC mode. VC class configuration mode is not
supported on VP or port mode.
When you configure cell packing in VC class configuration mode and then apply the VC class to an
interface, the settings in the VC class apply to all the VCs on the interface, unless you specify a different
cell packing value at a lower level, such as the subinterface or VC level. For example, you can create a
VC class that specifies three cells to be packed. You can apply the VC class to an interface. Then, for
one PVC, you can specify two cells to be packed. All the PVCs on the interface pack three cells, except
for the one PVC that was set to set two cells.
37
SUMMARY STEPS
1. enable
6. exit
8. shutdown
10. no shutdown
DETAILED STEPS

Example:
Router> enable
Example:
mode.
Example:
Router(config)# vc-class atm cellpacking
Example:
38

parameters.
Router(config-vc-class)# cell-packing 10 cells to be packed into an MPLS packet. The range is
mcpt-timer 1 from 2 to the MTU of the interface divided by 52. The
default is MTU/52.
See the cell-packing command page for more
information.
Example:
Step 7 interface atm slot/subslot/port[.subinterface] Specifies the ATM interface and enters interface
configuration mode.
Example:
Example:
39

Step 9 atm mcpt-timers [timer1-timeout timer2-timeout Sets up the cell-packing timers, which specify how long
timer3-timeout] the PE router can wait for cells to be packed into an
MPLS packet.
Example: You can set up to three timers. For each timer, you
Router(config-if)# atm mcpt-timers 100 200 250 specify the MCPT. This value gives the cell-packing
function a limited amount of time to complete. If the
timer expires before the maximum number of cells are
packed into an AToM packet, the packet is sent anyway.
The timeout’s default and range of acceptable values
depends on the ATM link speed.
are:
You can specify either the number of microseconds or
use the default.
The respective range of values for the PA-A3 port
adapters are:
Example:
subinterface.
Router(config-if)# class-int cellpacking
Example:
40
Examples
The following example configures with cell packing in VC class configuration mode. The VC class is
then applied to an interface.
enable
configure terminal
vc-class atm cellpacking
encapsulation aal0
interface atm1/0/0
shutdown
atm mcpt-timers 100 200 250
no shutdown
class-int cellpacking
The following example configures in VC class configuration mode. The VC class is then applied to a
PVC.
enable
configure terminal
vc-class atm cellpacking
encapsulation aal0
interface atm1/0/0
shutdown
atm mcpt-timers 100 200 250
no shutdown
class-vc cellpacking
Configuring ATM Packed Cell Relay over MPLS in VP Mode

Perform this task to configure the ATM cell-packing feature in VP mode.
SUMMARY STEPS
1. enable
4. shutdown
6. no shutdown
41
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface atm Specifies the ATM interface and enters interface configuration
slot/subslot/port[.subinterface] mode.
Example:
Example:
Step 5 atm mcpt-timers [timer1-timeout Sets up the cell-packing timers, which specify how long the PE
timer2-timeout timer3-timeout] router can wait for cells to be packed into an MPLS packet.
You can set up to three timers. For each timer, you specify the
Example: MCPT. This value gives the cell-packing function a limited
Router(config-if)# atm mcpt-timers 100 amount of time to complete. If the timer expires before the
200 250
maximum number of cells are packed into an AToM packet, the
packet is sent anyway. The timeout’s default and range of
acceptable values depends on the ATM link speed.
The respective default values for the PA-A3 port adapters are:
You can specify either the number of microseconds or use the
default.
The respective range of values for the PA-A3 port adapters are:
Example:
42

enters L2transport PVP configuration submode.
Example: The l2transport keyword indicates that the PVP is for cell relay.
Router(config-if)# atm pvp 1 l2transport This submode is for Layer 2 transport only; it is not for regular
PVPs.
Example:
Router(cfg-if-atm-l2trans-pvp)# xconnect
Step 9 cell-packing [cells] [mcpt-timer timer] Enables cell packing and specifies the cell-packing parameters.
The cells argument represents the maximum number of cells to be
Example: packed into an MPLS packet. The range is from 2 to the MTU of
Router(cfg-if-atm-l2trans-pvp)# the interface divided by 52. The default is MTU/52.
The timer argument allows you to specify which timer to use. The
default is timer 1.
Examples
The following example shows packed cell relay enabled on an interface configured for PVP mode. The
cell-packing command specifies that 10 ATM cells are to be packed into an MPLS packet. The
interface atm 1/0
shutdown
no shutdown
Configuring ATM Packed Cell Relay over MPLS in Port Mode

Perform this task to configure ATM packed cell relay over MPLS in port mode.
SUMMARY STEPS
1. enable
4. shutdown
6. no shutdown
9. exit
43
10. exit
11. show atm cell-packing
12. show atm vp
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Example:
Step 5 atm mcpt-timers [timer1-timeout timer2-timeout Sets up the cell-packing timers, which specify how long
timer3-timeout] the PE router can wait for cells to be packed into an
MPLS packet.
Example: You can set up to three timers. For each timer, you
Router(config-if)# atm mcpt-timers 100 200 250 specify the MCPT. This value gives the cell-packing
function a limited amount of time to complete. If the
timer expires before the maximum number of cells are
packed into an AToM packet, the packet is sent anyway.
The timeout’s default and range of acceptable values
depends on the ATM link speed.
are:
You can specify either the number of microseconds or
use the default.
The respective range of values for the PA-A3 port
adapters are:
44

Example:
parameters.
Router(config-if)# cell-packing 10 mcpt-timer 1 cells to be packed into an MPLS packet. The range is
from 2 to the MTU of the interface divided by 52. The
default is MTU/52.
Step 8 xconnect peer-router-id vcid encapsulation mpls Binds the attachment circuit to the interface.
Example:
encapsulation mpls
Example:
Example:
Step 11 show atm cell-packing Displays cell-packing statistics.
Example:
Router# show atm cell-packing
Step 12 show atm vp Displays cell-packing information.
Example:
Router#show atm vp
Examples
The following example shows packed cell relay enabled on an interface set up for port mode. The
cell-packing command specifies that 10 ATM cells are to be packed into an MPLS packet. The
interface atm 5/0/0
shutdown
no shutdown
45
The show atm cell-packing command in the following example displays the following statistics:
• The number of cells that are to be packed into an MPLS packet on the local and peer routers
• The average number of cells sent and received
• The timer values associated with the local router
Router# show atm cell-packing
average average
circuit local nbr of cells peer nbr of cells MCPT
type MNCP rcvd in one pkt MNCP sent in one pkt (us)
==============================================================================
atm 1/0/0 vc 1/200 20 15 30 20 60
atm 1/0/0 vp 2 25 21 30 24 100
The show atm vp command in the following example displays the cell packing information at the end
of the output:
Router# show atm vp 12
ATM5/0/0 VPI: 12, Cell Relay, PeakRate: 149760, CesRate: 0, DataVCs: 1, CesVCs: 0, Status:
ACTIVE
VCD VCI Type InPkts OutPkts AAL/Encap Status

TotalInPkts: 0, TotalOutPkts: 0, TotalInFast: 0, TotalOutFast: 0,

TotalBroadcasts: 0 TotalInPktDrops: 0, TotalOutPktDrops: 0
Local MNCP: 5, average number of cells received: 3
Peer MNCP: 1, average number of cells sent: 1
Local MCPT: 100 us
To debug ATM cell packing, issue the debug atm cell-packing command.
Configuring Ethernet over MPLS in VLAN Mode

A VLAN is a switched network that is logically segmented by functions, project teams, or applications
regardless of the physical location of users. Ethernet over MPLS allows you to connect two VLAN
networks that are in different locations. You configure the PE routers at each end of the MPLS backbone
and add a point-to-point VC. Only the two PE routers at the ingress and egress points of the MPLS
backbone know about the VCs dedicated to transporting Layer 2 VLAN traffic. All other routers do not
have table entries for those VCs. Ethernet over MPLS in VLAN mode transports Ethernet traffic from a
source 802.1Q VLAN to a destination 802.1Q VLAN over a core MPLS network.
Note You must configure Ethernet over MPLS (VLAN mode) on the subinterfaces.
SUMMARY STEPS
1. enable
3. interface gigabitethernet slot/subslot/port.[subinterface]
46
4. encapsulation dot1q vlan-id

DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface gigabitethernet Specifies the Gigabit Ethernet subinterface and enters
slot/subslot/port.[subinterface] subinterface configuration mode. Make sure the
subinterface on the adjoining CE router is on the same
Example: VLAN as this PE router.
Router(config)# interface gigabitethernet4/0/0.1
Step 4 encapsulation dot1q vlan-id Enables the subinterface to accept 802.1Q VLAN
packets.
Example: The subinterfaces between the CE and PE routers that are
Router(config-subif)# encapsulation dot1q 100 running Ethernet over MPLS must be in the same subnet.
All other subinterfaces and backbone routers do not.
Step 5 xconnect peer-router-id vcid encapsulation mpls Binds the attachment circuit to a pseudowire VC. The
syntax for this command is the same as for all other
Layer 2 transports.
Example:
Router(config-subif)# xconnect 10.0.0.1 123
encapsulation mpls
Configuring Ethernet over MPLS in Port Mode

Port mode allows a frame coming into an interface to be packed into an MPLS packet and transported
over the MPLS backbone to an egress interface. The entire Ethernet frame without the preamble or FCS
is transported as a single packet. To configure port mode, you use the xconnect command in interface
configuration mode and specify the destination address and the VC ID. The syntax of the xconnect
command is the same as for all other transport types. Each interface is associated with one unique
pseudowire VC label.
When configuring Ethernet over MPLS in port mode, use the following guidelines:
• The pseudowire VC type is set to Ethernet.
• Port mode and Ethernet VLAN mode are mutually exclusive. If you enable a main interface for
port-to-port transport, you cannot also enter commands on a subinterface.
47
SUMMARY STEPS
1. enable
5. exit
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface gigabitethernet Specifies the Gigabit Ethernet interface and enters interface
slot/subslot/port.[subinterface] configuration mode. Make sure the interface on the adjoining CE
router is on the same VLAN as this PE router.
Example:
Router(config)# interface
gigabitethernet4/0/0
Example:
encapsulation mpls
Example:
Step 6 exit Exits router configuration mode.
Example:
Step 7 show mpls l2transport vc Displays information about Ethernet over MPLS port mode.
Example:
48
Examples
The following example configures VC 123 in Ethernet port mode:
pseudowire-class ethernet-port
encapsulation mpls
int gigabitethernet1/0/0
xconnect 10.0.0.1 123 pw-class ethernet-port
The command output in the following example shows two VCs for Ethernet over MPLS:
• VC 2 is in Ethernet VLAN mode.
• VC 8 is in Ethernet port mode.

------------- -------------------- --------------- ---------- ----------
Gi4/0/0.1 Eth VLAN 2 10.1.1.1 2 UP
Gi8/0/1 Ethernet 10.1.1.1 8 UP
If you issue the show mpls l2transport vc detail command, the output is similar:
Router# show mpls l2transport vc detail
Local interface: Gi4/0/0.1 up, line protocol up, Eth VLAN 2 up

Destination address: 10.1.1.1, VC ID: 2, VC status: up
.
.
.
Local interface: Gi8/0/1 up, line protocol up, Ethernet up
Configuring Ethernet over MPLS with VLAN ID Rewrite

The VLAN ID rewrite feature enables you to use VLAN interfaces with different VLAN IDs at both ends
of the tunnel.
SUMMARY STEPS
1. enable
3. interface gigabitethernet slot/subslot/port[.subinterface]
6. remote circuit id remote-vlan-id
7. exit
8. exit
9. exit
10. show controllers eompls forwarding-table
49
DETAILED STEPS

Example:
Router> enable
Example:
slot/subslot/port[.subinterface] subinterface configuration mode.
Make sure the subinterfaces between the CE and PE
Example: routers that are running Ethernet over MPLS are in the
Router(config)# interface gigabitethernet4/0/0.1 same subnet. All other subinterfaces and backbone
routers do not need to be in the same subnet.
packets.
Example: Make sure the subinterface on the adjoining CE router is
Router(config-subif)# encapsulation dot1q 100 on the same VLAN as this PE router.
Step 5 xconnect peer-router-id vcid encapsulation mpls Binds the attachment circuit to a pseudowire VC and
enters xconnect configuration mode. The syntax for this
command is the same as for all other Layer 2 transports.
Example:
encapsulation mpls
Step 6 remote circuit id remote-vlan-id (Optional) Enables you to use VLAN interfaces with
different VLAN IDs at both ends of the tunnel.
Example:
Router(config-subif-xconn)# remote circuit id
101
Step 7 exit Exits xconnect configuration mode.
Example:
Router(config-subif-xconn)# exit
Step 8 exit Exits subinterface configuration mode.
Example:
Router(config-subif)# exit
50

Example:
Step 10 show controllers eompls forwarding-table Displays information about VLAN ID rewrite.
Example:
Router# execute slot 0 show controllers eompls
forwarding-table
Examples
The following example configures VLAN ID rewrite on peer PE routers with 2 3-port Gigabit Ethernet
line cards.
PE1 PE2
interface GigabitEthernet0/0/0.2 interface GigabitEthernet3/0/0.2
encapsulation dot1Q 2 encapsulation dot1Q 3
no ip directed-broadcast no ip directed-broadcast
no cdp enable no cdp enable
xconnect 10.5.5.5 2 encapsulation mpls xconnect 10.3.3.3 2 encapsulation mpls
remote circuit id 3 remote circuit id 2
The command output of the show controllers eompls forwarding-table command in the following
example shows VLAN ID rewrite configured on a router with an engine 2 3-port Gigabit Ethernet line
card. In the following example, the bolded command output show the VLAN ID rewrite information.
On PE1
Router# execute slot 0 show controllers eompls forwarding-table 0 2
Port # 0, VLAN-ID # 2, Table-index 2

EoMPLS configured: 1
tag_rew_ptr = D001BB58
Leaf entry? = 1
FCR index = 20
**tagrew_psa_addr = 0006ED60
**tagrew_vir_addr = 7006ED60
**tagrew_phy_addr = F006ED60
[0-7] loq 8800 mtu 4458 oq 4000 ai 3 oi 04019110 (encaps size 4)
cw-size 4 vlanid-rew 3
gather A30 (bufhdr size 32 EoMPLS (Control Word) Imposition profile 81)
2 tag: 18 18
counters 1182, 10 reported 1182, 10.
Local OutputQ (Unicast): Slot:2 Port:0 RED queue:0 COS queue:0
Output Q (Unicast): Port:0 RED queue:0 COS queue:0
On PE2
Router# execute slot 0 show controllers eompls forwarding-table 0 3
Port # 0, VLAN-ID # 3, Table-index 3

EoMPLS configured: 1
tag_rew_ptr = D0027B90
51
Leaf entry? = 1
FCR index = 20
**tagrew_psa_addr = 0009EE40
**tagrew_vir_addr = 7009EE40
**tagrew_phy_addr = F009EE40
[0-7] loq 9400 mtu 4458 oq 4000 ai 8 oi 84000002 (encaps size 4)
cw-size 4 vlanid-rew 2
gather A30 (bufhdr size 32 EoMPLS (Control Word) Imposition profile 81)
2 tag: 17 18
counters 1182, 10 reported 1182, 10.
Local OutputQ (Unicast): Slot:5 Port:0 RED queue:0 COS queue:0
Output Q (Unicast): Port:0 RED queue:0 COS queue:0
Configuring per-Subinterface MTU for Ethernet over MPLS

Cisco IOS XE software includes the ability to specify MTU values in xconnect subinterface
configuration mode. When you use xconnect subinterface configuration mode to set the MTU value, you
establish a pseudowire connection for situations where the interfaces have different MTU values that
cannot be changed.
If you specify an MTU value in xconnect subinterface configuration mode that is outside the range of
supported MTU values (64 bytes to the maximum number of bytes supported by the interface), the
command might be rejected. If you specify an MTU value that is out of range in xconnect subinterface
configuration mode, the router enters the command in subinterface configuration mode.
For example, if you specify an MTU of 1501 in xconnect subinterface configuration mode, and that value
is out of range, the router enters the command in subinterface configuration mode, where it is accepted:
Router(config-subif)# xconnect 10.10.10.1 100 encapsulation mpls
Rrouter(config-subif-xconn)# mtu ?
<64 - 1500> MTU size in bytes
Router(config-subif-xconn)# mtu 1501
Router(config-subif)# mtu ?
If the MTU value is not accepted in either xconnect subinterface configuration mode or subinterface
configuration mode, then the command is rejected, as shown in the following example:
Router(config-subif)# xconnect 10.10.10.1 100 encapsulation mpls
Router(config-subif-xconn)# mtu ?
Router(config-subif-xconn)# mtu 63
% Invalid input detected at ^ marker
Restrictions
Configuring the MTU value in xconnect subinterface configuration mode has the following restrictions:
• The following features do not support MTU values in xconnect subinterface configuration mode:
– Layer 2 Tunnel Protocol Version 3 (L2TPv3)
– Virtual Private LAN services (VPLS)
– L2VPN Pseudowire Switching
52
• The MTU value can be configured in xconnect subinterface configuration mode only on the
following interfaces and subinterfaces:
– Fast Ethernet
– Gigabit Ethernet
• The router uses an MTU validation process for remote VCs established through LDP, which
compares the MTU value configured in xconnect subinterface configuration mode to the MTU value
of the remote customer interface. If an MTU value has not been configured in xconnect subinterface
configuration mode, then the validation process compares the MTU value of the local customer
interface to the MTU value of the remote xconnect, either explicitly configured or inherited from
the underlying interface or subinterface.
• When you configure the MTU value in xconnect subinterface configuration mode, the specified
MTU value is not enforced by the dataplane. The dataplane enforces the MTU values of the interface
(port mode) or subinterface (VLAN mode).
• Ensure that the interface MTU is larger than the MTU value configured in xconnect subinterface
configuration mode. If the MTU value of the customer-facing subinterface is larger than the MTU
value of the core-facing interface, traffic may not be able to travel across the pseudowire.
SUMMARY STEPS
1. enable
4. mtu mtu-value
8. mtu mtu-value
9. end
10. show mpls l2transport binding
DETAILED STEPS

Example:
Router> enable
Example:
53

slot/subslot/port[.subinterface] configuration mode.
Example:
Router(config)# interface gigabitethernet4/0/0
Step 4 mtu mtu-value Specifies the MTU value for the interface. The MTU value
specified at the interface level can be inherited by a
subinterface.
Example:
Router(config-if)# mtu 2000
slot/subslot/port[.subinterface] subinterface configuration mode.
Make sure the subinterface on the adjoining CE router is on
Example: the same VLAN as this PE router.
Router(config-if)# interface
gigabitethernet4/0/0.1
Step 6 encapsulation dot1q vlan-id Enables the subinterface to accept 802.1Q VLAN packets.
The subinterfaces between the CE and PE routers that are
Example: running Ethernet over MPLS must be in the same subnet.
Router(config-subif)# encapsulation dot1q 100 All other subinterfaces and backbone routers need not be.
The syntax for this command is the same as for all other
Example: Layer 2 transports. Enters xconnect subinterface
Router(config-subif)# xconnect 10.0.0.1 123 configuration mode.
encapsulation mpls
Step 8 mtu mtu-value Specifies the MTU for the VC.
Example:
Router(config-if-xconn)# mtu 1400
Step 9 end Exits xconnect subinterface configuration mode and returns
to global configuration mode.
Example:
Router(config-if-xconn)# end
Step 10 show mpls l2transport binding Displays the MTU values assigned to the local and remote
interfaces.
Example:
Router# show mpls l2transport binding
Configuring Frame Relay over MPLS with DLCI-to-DLCI Connections

Frame Relay over MPLS encapsulates Frame Relay PDUs in MPLS packets and forwards them across
the MPLS network. For Frame Relay, you can set up data-link connection identifier (DLCI)-to-DLCI
connections or port-to-port connections. With DLCI-to-DLCI connections, the PE routers manipulate
the packet by removing headers, adding labels, and copying control word elements from the header to
the PDU.
Perform this task to configure Frame Relay over MPLS with DLCI-to-DLCI connections.
54
SUMMARY STEPS
1. enable
3. frame-relay switching
5. encapsulation frame-relay [cisco | ietf]
6. frame-relay intf-type dce
7. exit
8. connect connection-name interface dlci l2transport
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 frame-relay switching Enables PVC switching on a Frame Relay device.
Example:
Router(config)# frame-relay switching
Step 4 interface serial Specifies a serial interface and enters interface configuration
Example:
Router(config)# interface serial3/1/0
Step 5 encapsulation frame-relay [cisco | ietf] Specifies Frame Relay encapsulation for the interface. You can
specify different types of encapsulations. You can set one interface
to Cisco encapsulation and the other interface to IETF
Example:
Router(config-if)# encapsulation
encapsulation.
frame-relay ietf
Step 6 frame-relay intf-type dce Specifies that the interface is a DCE switch. You can also specify
the interface to support Network-to-Network Interface (NNI) and
DTE connections.
Example:
Router(config-if)# frame-relay intf-type
dce
55

Step 7 exit Exits from interface configuration mode.
Example:
Step 8 connect connection-name interface dlci Defines connections between Frame Relay PVCs and enters
l2transport connect configuration submode. Using the l2transport keyword
specifies that the PVC will not be a locally switched PVC, but will
Example: be tunneled over the backbone network.
Router(config)# connect fr1 serial5/0 The connection-name argument is a text string that you provide.
1000 l2transport
The interface argument is the interface on which a PVC
connection will be defined.
The dlci argument is the DLCI number of the PVC that will be
connected.
Step 9 xconnect peer-router-id vcid Creates the VC to transport the Layer 2 packets. In a DLCI-to
encapsulation mpls DLCI connection type, Frame Relay over MPLS uses the xconnect
command in connect configuration submode.
Example:
Router(config-fr-pw-switching)# xconnect
Configuring Frame Relay over MPLS with Port-to-Port Connections

Frame Relay over MPLS encapsulates Frame Relay PDUs in MPLS packets and forwards them across
the MPLS network. For Frame Relay, you can set up DLCI-to-DLCI connections or port-to-port
connections. With port-to-port connections, you use HDLC mode to transport the Frame Relay
encapsulated packets. In HDLC mode, the whole HDLC packet is transported. Only the HDLC flags and
FCS bits are removed. The contents of the packet are not used or changed, including the backward
explicit congestion notification (BECN), forward explicit congestion notification (FECN) and discard
eligibility (DE) bits.
Perform this task to set up Frame Relay port-to-port connections.
SUMMARY STEPS
1. enable
4. encapsulation hdlc
56
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 4 encapsulation hdlc Specifies that Frame Relay PDUs will be encapsulated in HDLC
packets.
Example:
Router(config-if)# encapsulation hdlc
Step 5 xconnect peer-router-id vcid Creates the VC to transport the Layer 2 packets.
encapsulation mpls
Example:
encapsulation mpls
Configuring HDLC and PPP over MPLS

With HDLC over MPLS, the whole HDLC packet is transported. The ingress PE router removes only the
HDLC flags and FCS bits. The contents of the packet are not used or changed.
With PPP over MPLS, the ingress PE router removes the flags, address, control field, and the FCS.
Restrictions
The following restrictions pertain to the HDLC over MPLS feature:
• Asynchronous interfaces are not supported.
• You must configure HDLC over MPLS on router interfaces only. You cannot configure HDLC over
MPLS on subinterfaces.
The following restrictions pertain to the PPP over MPLS feature:
• Zero hops on one router is not supported. However, you can have back-to-back PE routers.
• Asynchronous interfaces are not supported. The connections between the CE and PE routers on both
ends of the backbone must have similar link layer characteristics. The connections between the CE
and PE routers must both be synchronous.
• Multilink PPP (MLP) is not supported.
57
• You must configure PPP on router interfaces only. You cannot configure PPP on subinterfaces.
SUMMARY STEPS
1. enable
DETAILED STEPS

Example:
Router> enable
Example:
slot/subslot/port[.subinterface] mode. You must configure HDLC and PPP over MPLS on router
interfaces only. You cannot configure HDLC over MPLS on
Example: subinterfaces.
Step 4 encapsulation ppp Specifies HDLC or PPP encapsulation and enters connect
or configuration mode.
encapsulation hdlc
Example:
Router(config-if)# encapsulation ppp
or
Example:
Router(config-if)# encapsulation hdlc
encapsulation mpls
Example:
Router(config-fr-pw-switching)# xconnect
58
Configuring Tunnel Selection

The tunnel selection feature allows you to specify the path that traffic uses. You can specify either an
MPLS TE tunnel or destination IP address or domain name server (DNS) name.
You also have the option of specifying whether the VCs should use the default path (the path LDP uses
for signaling) if the preferred path is unreachable. This option is enabled by default; you must explicitly
disable it.
You configure tunnel selection when you set up the pseudowire class. You enable tunnel selection with
the preferred-path command. Then, you apply the pseudowire class to an interface that has been
configured to transport AToM packets.
The following guidelines provide more information about configuring tunnel selection:
• The preferred-path command is available only if the pseudowire encapsulation type is MPLS.
• This tunnel selection feature is enabled when you exit from pseudowire submode.
• The selected path should be an LSP destined to the peer PE router.
• The selected tunnel must be an MPLS TE tunnel.
• If you select a tunnel, the tunnel tailend must be on the remote PE router.
• If you specify an IP address, that address must be the IP address of the loopback interface on the
remote PE router. The address must have a /32 mask. There must be an LSP destined to that selected
address. The LSP need not be a TE tunnel.
SUMMARY STEPS
1. enable
5. preferred-path {interface tunnel tunnel-number | peer {ip-address | host-name}}
[disable-fallback]
6. exit
9. xconnect peer-router-id vcid pw-class name
DETAILED STEPS

Example:
Router> enable
Example:
59

Step 3 pseudowire-class name Establishes a pseudowire class with a name that you specify and
enters pseudowire configuration mode.
Example:
Router(config)# pseudowire-class ts1
Step 4 encapsulation mpls Specifies the tunneling encapsulation. For AToM, the encapsulation
type is mpls.
Example:
Step 5 preferred-path {interface tunnel Specifies the MPLS traffic engineering tunnel or IP address or
tunnel-number | peer {ip-address | hostname to be used as the preferred path.
host-name}} [disable-fallback]
Example:
Router(config-pw)# preferred path
peer 10.18.18.18
Step 6 exit Exits from pseudowire configuration mode.
Example:
Router(config-pw)# exit
Step 7 interface type Specifies an interface type and enters interface configuration mode.
Example:
Step 8 encapsulation encapsulation-type Specifies the encapsulation for the interface.
Example:
Router(config-if)# encapsulation aal5
Step 9 xconnect peer-router-id vcid pw-class Binds the attachment circuit to a pseudowire VC.
name
Example:
Router(config-if)# xconnect 10.0.0.1
123 pw-class ts1
60
Examples
The following example sets up two preferred paths for PE1. One preferred path specifies an MPLS traffic
engineering tunnel. The other preferred path specifies an IP address of a loopback address on PE2. There
is a static route configured on PE1 that uses a TE tunnel to reach the IP address on PE2.
PE1 Configuration
tag-switching tdp router-id Loopback0
pseudowire-class pw1
encapsulation mpls
preferred-path interface Tunnel1 disable-fallback
!
pseudowire-class pw2
encapsulation mpls
preferred-path peer 10.18.18.18
!
interface Loopback0
ip address 10.2.2.2 255.255.255.255
no ip mroute-cache
!
interface Tunnel1
tunnel mpls traffic-eng path-option 1 explicit name path-tu1
!
interface Tunnel2
!
interface gigabitethernet0/0/0
no ip address
no negotiation auto
!
interface gigabitethernet0/0/0.1
encapsulation dot1Q 222
xconnect 10.16.16.16 101 pw-class pw1
!
interface ATM1/0/0
no ip address
no atm enable-ilmi-trap
no atm ilmi-keepalive
encapsulation aal5
xconnect 10.16.16.16 150 pw-class pw2
!
ip address 10.0.0.1 255.255.255.0
61
tag-switching ip
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 10.2.2.2 0.0.0.0 area 0
!
ip route 10.18.18.18 255.255.255.255 Tunnel2
!
ip explicit-path name path-tu1 enable
index 3 next-address 10.0.0.1
PE2 Configuration
mpls ldp router-id Loopback0
interface Loopback0
ip address 10.16.16.16 255.255.255.255
no ip mroute-cache
!
interface Loopback2
ip address 10.18.18.18 255.255.255.255
!
ip address 10.0.0.2 255.255.255.0
mpls ip
no cdp enable
!
no ip address
no cdp enable
!
interface FastEthernet1/1/1.1
no cdp enable
mpls l2transport route 10.2.2.2 101
!
interface ATM5/0/0
no ip address
encapsulation aal5
!
router ospf 1
network 10.0.0.0 0.0.0.255 area 0
network 10.16.16.16 0.0.0.0 area 0
62

In the following example, the show mpls l2transport vc command shows the following information
about the VCs:
• VC 101 has been assigned a preferred path called Tunnel1. The default path is disabled, because the
preferred path specified that the default path should not be used if the preferred path fails.
• VC 150 has been assigned an IP address of a loopback address on PE2. The default path can be used
if the preferred path fails.
In the following example, command output that is bolded shows the preferred path information.
Preferred path: Tunnel1, active
Default path: disabled
Tunnel label: 3, next hop point2point
Output interface: Tu1, imposed label stack {17 16}
Create time: 00:27:31, last status change time: 00:27:31
Signaling protocol: LDP, peer 10.16.16.16:0 up
MPLS VC labels: local 25, remote 16
Group ID: local 0, remote 6
MTU: local 1500, remote 1500
Remote interface description:
Sequencing: receive disabled, send disabled
VC statistics:
packet totals: receive 10, send 10
byte totals: receive 1260, send 1300
packet drops: receive 0, send 0
Local interface: ATM1/0/0 up, line protocol up, ATM AAL5 0/50 up
Preferred path: 10.18.18.18, active
Default path: ready
Tunnel label: 3, next hop point2point
Output interface: Tu2, imposed label stack {18 24}
VC statistics:
You can use the debug mpls l2transport vc event command to troubleshoot tunnel selection. For
example, if the tunnel interface that is used for the preferred path is shut down, the default path is
enabled. The debug mpls l2transport vc event command provides the following output:
AToM SMGR [10.2.2.2, 101]: Processing imposition update, vc_handle 62091860, update_action
3, remote_vc_label 16
AToM SMGR [10.2.2.2, 101]: selected route no parent rewrite: tunnel not up
AToM SMGR [10.2.2.2, 101]: Imposition Programmed, Output Interface: Fe3/2/1
63
Setting Experimental Bits with AToM

MPLS AToM uses the three experimental bits in a label to determine the queue of packets. You statically
set the experimental bits in both the VC label and the LSP tunnel label, because the LSP tunnel label
might be removed at the penultimate router. The following sections explain the transport-specific
implementations of the EXP bits.
Restrictions
The following restrictions apply to ATM AAL5 over MPLS with EXP bits:
• ATM AAL5 over MPLS allows you to statically set the experimental bits.
• If you do not assign values to the experimental bits, the priority bits in the header’s “tag control
information” field are set to zero.
The following restrictions apply to with EXP bits:
• allows you to statically set the experimental bits in VC, PVP, and port modes.
• If you do not assign values to the experimental bits, the priority bits in the header’s “tag control
information” field are set to zero.
For Frame Relay over MPLS and EXP bits, if you do not assign values to the experimental bits, the
priority bits in the header's “tag control information” field are set to zero.
For HDLC over MPLS and PPP over MPLS and EXP bits, if you do not assign values to the experimental
bits, zeros are written into the experimental bit fields.
Set the experimental bits in both the VC label and the LSP tunnel label. You set the experimental bits in
the VC label, because the LSP tunnel label might be removed at the penultimate router. Perform this task
to set the experimental bits.
SUMMARY STEPS
1. enable
3. class-map class-name
4. match any
5. policy-map policy-name
6. class class-name
7. set mpls experimental value
8. exit
9. exit
11. service-policy input policy-name
12. exit
13. exit
14. show policy-map interface interface-name [vc [vpi/] vci] [dlci dlci] [input | output]
64
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 class-map class-name Specifies the user-defined name of the traffic class and enters
class map configuration mode.
Example:
Router(config)# class-map class1
Step 4 match any Specifies that all packets will be matched. Use only the any
keyword. Other keywords might cause unexpected results.
Example:
Router(config-cmap)# match any
Step 5 policy-map policy-name Specifies the name of the traffic policy to configure and
enters policy-map configuration mode.
Example:
Router(config-cmap)# policy-map policy1
Step 6 class class-name Specifies the name of a predefined traffic class, which was
configured with the class-map command, used to classify
traffic to the traffic policy and enters policy-map class
Example:
Router(config-pmap)# class class1
configuration mode.
Step 7 set mpls experimental value Designates the value to which the MPLS bits are set if the
packets match the specified policy map.
Example:
Router(config-pmap-c)# set mpls experimental
7
Step 8 exit Exits policy-map class configuration mode.
Example:
Router(config-pmap-c)# exit
Step 9 exit Exits policy-map configuration mode.
Example:
Router(config-pmap)# exit
Step 10 interface type Specifies the interface type and enters interface configuration
Example:
65

Step 11 service-policy input policy-name Attaches a traffic policy to an interface.
Example:
Router(config-if)# service-policy input
policy1
Example:
Example:
Step 14 show policy-map interface interface-name [vc Displays the traffic policy attached to an interface.
[vpi/] vci] [dlci dlci] [input | output]
Example:
Router# show policy-map interface serial3/0/0
Configuring MPLS AToM Remote Ethernet Port Shutdown

The Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown feature is automatically
enabled by default when an image with the feature supported is loaded on the router. This section
contains the instructions for disabling and enabling the MPLS AToM Remote Ethernet Port Shutdown:
SUMMARY STEPS
1. enable
3. pseudowire-class [pw-class-name]
5. exit
7. xconnect peer-ip-address vc-id pw-class pw-class-name
8. [no] remote link failure notification
9. remote link failure notification
10. end
66
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class [pw-class-name] Specifies the name of a Layer 2 pseudowire class and enters
Example: • The pw-class-name argument is the name of a Layer 2
Router(config)# pseudowire-class eompls pseudowire class. If you want to configure more than
one pseudowire class, you must enter a value for the
pw-class-name argument.
Step 4 encapsulation mpls Specifies that MPLS is used as the data encapsulation
method for tunneling Layer 2 traffic over the pseudowire.
Example:
Example:
configuration mode.
Example:
Router# interface GigabitEthernet1/0/0
Step 7 xconnect peer-ip-address vc-id pw-class Binds an attachment circuit to a pseudowire, and configures
pw-class-name an Any Transport over MPLS (AToM) static pseudowire.
Example:
Router(config-if)# xconnect 10.1.1.1 1 pw-class
eompls
Step 8 no remote link failure notification Disables MPLS AToM remote link failure notification and
shutdown.
Example:
Router(config-if-xconn)# remote link failure
notification
67
Configuration Examples for Any Transport over MPLS

Step 9 remote link failure notification Enables MPLS AToM remote link failure notification and
shutdown.
Example:
Router(config-if-xconn)# remote link failure
notification
Example:
Router(config-if-xconn)# end

This section contains the following configuration examples:
• ATM over MPLS: Example, page 68
• Ethernet over MPLS with MPLS Traffic Engineering Fast Reroute: Example, page 69
• Configuring per-Subinterface MTU for Ethernet over MPLS: Example, page 71
• Configuring MTU Values in xconnect Configuration Mode for L2VPN Interworking: Example,
page 73
• Configuring Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown: Examples,
page 76
ATM over MPLS: Example

Example 1 shows the configuration of ATM over MPLS on two PE routers.
Example 1 ATM over MPLS Configuration Example
PE1 PE2
mpls label protocol ldp mpls label protocol ldp
mpls ldp router-id Loopback0 force mpls ldp router-id Loopback0 force
! !
interface Loopback0 interface Loopback0
ip address 10.16.12.12 255.255.255.255 ip address 10.13.13.13 255.255.255.255
!
interface ATM4/0/0 interface ATM4/0/0
pvc 0/100 l2transport pvc 0/100 l2transport
encapsulation aal0 encapsulation aal0
! !
interface ATM4/0/0.300 point-to-point interface ATM4/0/0.300 point-to-point
no atm enable-ilmi-trap no atm enable-ilmi-trap
pvc 0/300 l2transport pvc 0/300 l2transport
encapsulation aal0 encapsulation aal0
68
Ethernet over MPLS with MPLS Traffic Engineering Fast Reroute: Example
The following configuration example and Figure 3 show the configuration of Ethernet over MPLS with
fast reroute on AToM PE routers.
Routers PE1 and PE2 have the following characteristics:
• A TE tunnel called Tunnel41 is configured between PE1and PE2, using an explicit path through a
link called L1. AToM VCs are configured to travel through the FRR-protected tunnel Tunnel41.
• The link L1 is protected by FRR, the backup tunnel is Tunnel1.
• PE2 is configured to forward the AToM traffic back to PE1 through the L2 link.
Figure 3 Fast Reroute Configuration
10.0.0.27 10.0.0.1 10.0.0.4

CE 1 PE 1 P PE 2 CE
L1
88263
L2
PE1 Configuration
!
pseudowire-class T41
encapsulation mpls
preferred-path interface Tunnel41 disable-fallback
!
pseudowire-class IP1
encapsulation mpls
preferred-path peer 10.4.0.1 disable-fallback
!
interface Loopback1
ip address 10.0.0.27 255.255.255.255
!
interface Tunnel1
tunnel mpls traffic-eng path-option 1 explicit name FRR
!
interface Tunnel41
tunnel mpls traffic-eng path-option 1 explicit name name-1
tunnel mpls traffic-eng fast-reroute
!
interface POS0/0/0
description pe1name POS8/0/0
ip address 10.1.0.2 255.255.255.252
mpls traffic-eng backup-path Tunnel1
69
crc 16
pos ais-shut
pos report lrdi
!
interface POS0/3/0
description pe1name POS10/1/0
ip address 10.1.0.14 255.255.255.252
crc 16
!
xconnect 10.0.0.4 2 pw-class IP1
!
xconnect 10.0.0.4 4 pw-class T41
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
!
ip classless
ip route 10.4.0.1 255.255.255.255 Tunnel41
!
ip explicit-path name xxxx-1 enable
P Configuration
ip cef
!
interface Loopback1
ip address 10.0.0.1 255.255.255.255
!
ip address 10.4.1.2 255.255.255.0
!
interface POS8/0/0
description xxxx POS0/0
ip address 10.1.0.1 255.255.255.252
pos ais-shut
pos report lrdi
!
interface POS10/1/0
description xxxx POS0/3
ip address 10.1.0.13 255.255.255.252
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
70
PE2 Configuration
ip cef
!
interface Loopback1
ip address 10.0.0.4 255.255.255.255
!
ip address 10.4.0.1 255.255.255.255
!
interface Tunnel27
tunnel mpls traffic-eng path-option 1 explicit name xxxx-1
!
!
!
ip address 10.4.1.1 255.255.255.0
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 0
!
ip explicit-path name xxxx-1 enable
Configuring per-Subinterface MTU for Ethernet over MPLS: Example

Figure 4 shows a configuration that enables matching MTU values between VC endpoints.
As shown in Figure 4, PE1 is configured in xconnect subinterface configuration mode with an MTU
value of 1500 bytes in order to establish an end-to-end VC with PE2, which also has an MTU value of
1500 bytes. If PE1 was not set with an MTU value of 1500 bytes, in xconnect subinterface configuration
mode, the subinterface would inherit the MTU value of 2000 bytes set on the interface. This would cause
a mismatch in MTU values between the VC endpoints, and the VC would not come up.
71
Figure 4 Configuring MTU Values in xconnect Subinterface Configuration Mode
CE1 PE1 PE2 CE2

MPLS Core
MTU 2000 Bytes
192802
subinterface g0/0/0.1 subinterface g0/0/0.2 interface g1/0/0 subinterface f0/0/0.1
xconnect mode MTU 2000 bytes MTU 2000 bytes MTU 1500 bytes
MTU 1500 bytes
The following examples show the router configurations in Figure 4:
CE1 Configuration
mtu 1500
no ip address
!
ip address 10.181.182.1 255.255.255.0
PE1 Configuration
mtu 2000
no ip address
!
mtu 1500
!
ip address 10.151.100.1 255.255.255.0
mpls ip
PE2 Configuration
mtu 2000
no ip address
!
ip address 10.100.152.2 255.255.255.0
mpls ip
!
interface fastethernet0/0/0
no ip address
!
interface fastethernet0/0/0.1
description default MTU of 1500 for FastEthernet
72
CE2 Configuration
no ip address
ip address 10.181.182.2 255.255.255.0
The show mpls l2transport binding command, issued from router PE1, shows a matching MTU value
of 1500 bytes on both the local and remote routers:
Destination Address: 10.1.1.152, VC ID: 100

Local Label: 100
Cbit: 1, VC Type: FastEthernet, GroupID: 0
MTU: 1500, Interface Desc: n/a
VCCV: CC Type: CW [1], RA [2]
CV Type: LSPV [2]
Remote Label: 202
VCCV: CC Type: RA [2]
CV Type: LSPV [2]
Output interface: Gi0/0/0.2, imposed label stack {202}
Preferred path: not configured
Default path: active
Next hop: 10.151.152.2
Create time: 1d11h, last status change time: 1d11h
Targeted Hello: 10.1.1.151(LDP Id) -> 10.1.1.152
VC statistics:
Configuring MTU Values in xconnect Configuration Mode for L2VPN

Interworking: Example
The following example shows an L2VPN Interworking example. The PE1 router has a serial interface
configured with an MTU value of 1492 bytes. The PE2 router uses xconnect configuration mode to set
a matching MTU of 1492 bytes, which allows the two routers to form an interworking VC. If the PE2
router did not set the MTU value in xconnect configuration mode, the interface would be set to
1500 bytes by default and the VC would not come up.
PE1 Configuration
pseudowire-class atom-ipiw
encapsulation mpls
interworking ip
73
!
interface Loopback0
ip address 10.1.1.151 255.255.255.255
!
interface Serial2/0/0
mtu 1492
no ip address
encapsulation ppp
no fair-queue
serial restart-delay 0
xconnect 10.1.1.152 123 pw-class atom-ipiw
!
ip address 10.151.100.1 255.255.255.252
encapsulation ppp
mpls ip
!
router ospf 1
network 10.1.1.151 0.0.0.0 area 0
network 10.151.100.0 0.0.0.3 area 0
!
PE2 Configuration
pseudowire-class atom-ipiw
encapsulation mpls
interworking ip
!
interface Loopback0
ip address 10.1.1.152 255.255.255.255
!
no ip address
xconnect 10.1.1.151 123 pw-class atom-ipiw
mtu 1492
!
ip address 10.100.152.2 255.255.255.252
encapsulation ppp
mpls ip
!
router ospf 1
network 10.1.1.152 0.0.0.0 area 0
network 10.100.152.0 0.0.0.3 area 0
!
The show mpls l2transport binding command shows that the MTU value for the local and remote
routers is 1492 bytes.
PE1

Local Label: 105
Cbit: 1, VC Type: PPP, GroupID: 0
74
CV Type: LSPV [2]

Remote Label: 205
CV Type: LSPV [2]
Local interface: Serial2/0/0 up, line protocol up, PPP up

MPLS VC type is PPP, interworking type is IP
Output interface: Serial4/0/0, imposed label stack {1003 205}
Next hop: point2point
Status TLV support (local/remote) : enabled/supported
Label/status state machine : established, LruRru
Last local dataplane status rcvd: no fault
Last local SSS circuit status rcvd: no fault
Last local SSS circuit status sent: no fault
Last local LDP TLV status sent: no fault
Last remote LDP TLV status rcvd: no fault
Group ID: local n/a, remote 0
VC statistics:
PE2

Local Label: 205
CV Type: LSPV [2]
Remote Label: 105
CV Type: LSPV [2]
Local interface: Fe0/0/0 up, line protocol up, FastEthernet up

MPLS VC type is FastEthernet, interworking type is IP
Output interface: Se4/0/0, imposed label stack {1002 105}
75

Label/status state machine : established, LruRru
Last local dataplane status rcvd: no fault
Last local SSS circuit status rcvd: no fault
Last local SSS circuit status sent: no fault
Last local LDP TLV status sent: no fault
Last remote LDP TLV status rcvd: no fault
Group ID: local n/a, remote 0
VC statistics:
Configuring Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown:
Examples
The following example show how to enable remote Ethernet port shutdown:
configure terminal
!
pseudowire-class eompls
encapsulation mpls
!
interface GigabitEthernet1/0/0
xconnect 10.1.1.1 1 pw-class eompls
remote link failure notification
The following example show how to disable remote Ethernet port shutdown:
configure terminal
!
pseudowire-class eompls
encapsulation mpls
!
xconnect 10.1.1.1 1 pw-class eompls
no remote link failure notification
The related show command output reports operational status for all remote L2 Tunnels by interface.
Router# show interface G1/0/0
GigabitEthernet1/0/0 is L2 Tunnel remote down, line protocol is up

Hardware is GigMac 4 Port GigabitEthernet, address is 0003.ff4e.12a8 (bia 0003.ff4e.12a8)
MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec, rely 255/255, load 1/255
.
.
.
Router# show ip interface brief
Interface IP-Address OK? Method Status Protocol

GigabitEthernet2/0/0 unassigned YES NVRAM L2 Tunnel remote down up
GigabitEthernet2/1/0 unassigned YES NVRAM administratively down down
.
.
.
76
The following sections provide references related to the Any Transport over MPLS feature.
Related Documents
Description of commands associated with MPLS and MPLS Cisco IOS Multiprotocol Label Switching Command
applications Reference
Standards
Standard Title
draft-martini-l2circuit-trans-mpls-08.txt Transport of Layer 2 Frames Over MPLS
draft-martini-l2circuit-encap-mpls-04.txt Encapsulation Methods for Transport of Layer 2 Frames
Over MPLS
77
MIBs
MIB MIBs Link
ATM AAL5 over MPLS and : To locate and download MIBs for selected platforms, Cisco IOS XE
• MPLS LDP MIB (MPLS-LDP-MIB.my) software releases, and feature sets, use Cisco MIB Locator found at
the following URL:
• ATM MIB (ATM-MIB.my)
• CISCO AAL5 MIB (CISCO-AAL5-MIB.my)
• Cisco Enterprise ATM Extension MIB
(CISCO-ATM-EXT-MIB.my)
• Supplemental ATM Management Objects
(CISCO-IETF-ATM2-PVCTRAP-MIB.my)
• Interfaces MIB (IF-MIB.my)
Ethernet over MPLS
• CISCO-ETHERLIKE-CAPABILITIES.my
• Ethernet MIB (ETHERLIKE-MIB.my)
• MPLS LDP MIB (MPLS-LDP-MIB.my)
Frame Relay over MPLS
• Cisco Frame Relay MIB
(CISCO-FRAME-RELAY-MIB.my)
HDLC and PPP over MPLS
• Interface MIB (IF-MIB.my)
RFCs
RFC Title
RFC 3032 MPLS Label Stack Encoding
78
Description Link
79
Feature Information for Any Transport over MPLS

http://www.cisco.com/go/cfn. An account on Cisco.com is not required
Table 6 Feature Information for Any Transport over MPLS

AToM Tunnel Selection Cisco IOS XE The AToM Tunnel Selection feature allows you to specify the path that traffic
Release 2.3 uses. You can specify either an MPLS TE tunnel or destination IP address or
domain name server (DNS) name.
You also have the option of specifying whether the VCs should use the default
path (the path LDP uses for signaling) if the preferred path is unreachable. This
option is enabled by default; you must explicitly disable it.
In Cisco IOS XE Release 2.3, this feature was introduced on the Cisco ASR 1000
Series Aggregation Services Routers.
AToM: ATM Cell Relay Cisco IOS XE The AToM: ATM Cell Relay over MPLS: VP Mode feature allows you to insert
over MPLS: VP Mode Release 2.3 one ATM cell in each MPLS packet in VP mode.
Series Routers.
AToM: Single Cell Cisco IOS XE The AToM Single Cell Relay–VC Mode feature allows you to insert one ATM
Relay–VC Mode Release 2.3 cell in each MPLS packet in VC mode.
Series Routers.
80
Table 6 Feature Information for Any Transport over MPLS (continued)

ATM VC Class Support Cisco IOS XE The ATM VC Class Support feature allows you to specify AAL5 and AAL0
Release 2.3 encapsulations as part of a VC class. You can also enable cell-packing and OAM
emulation as part of a VC class. A VC class can be attached to an interface,
subinterface, or VC.
Series Routers.
Any Transport over Cisco IOS XE This feature provides support for Quality of Service (QoS) features such as
MPLS (AToM): Layer 2 Release 2.3 traffic policing, traffic shaping, packet marking, and mapping of the packets.
Quality of Service (QoS)
Series Routers.
The following section provides information about this feature:
• QoS Features Supported with AToM, page 9
Any Transport over Cisco IOS XE This feature allows you to transport Layer 2 Ethernet VLAN packets from
MPLS (AToM): Ethernet Release 2.4 various sources over an MPLS backbone. Ethernet over MPLS extends the
over MPLS (EoMPLS) usability of the MPLS backbone by enabling it to offer Layer 2 services in
addition to already existing Layer 3 services. You can enable the MPLS
backbone network to accept Layer 2 VLAN packets by configuring the PE
routers at the both ends of the MPLS backbone.
Series Routers.
Any Transport over Cisco IOS XE Ethernet over MPLS (EoMPLS) is the transport of Ethernet frames across an
MPLS (AToM): Ethernet Release 2.4 MPLS core. It transports all frames received on a particular Ethernet or virtual
over MPLS: Port Mode LAN (VLAN) segment, regardless of the destination Media Access Control
(EoMPLS) (MAC) information. It does not perform MAC learning or MAC look up for
forwarding packets from the Ethernet interface. Port mode allows a frame
coming into an interface to be packed into an MPLS packet and transported over
the MPLS backbone to an egress interface.
Series Routers.
81
Table 6 Feature Information for Any Transport over MPLS (continued)

Any Transport over Cisco IOS XE AToM can use MPLS traffic engineering (TE) tunnels with fast reroute (FRR)
MPLS–Ethernet over Release 2.4 support. This features enhances FRR functionality for Ethernet over MPLS
MPLS Enhancements: (EoMPLS).
Fast Reroute
Series Routers.
• MPLS Traffic Engineering Fast Reroute, page 4
VLAN ID Rewrite Cisco IOS XE The VLAN ID rewrite feature enables you to use VLAN interfaces with different
Release 2.4 VLAN IDs at both ends of the tunnel.
Series Routers.
• Configuring Ethernet over MPLS with VLAN ID Rewrite, page 49
Any Transport over Cisco IOS XE This Cisco IOS feature allows a service provider edge (PE) router on the local
MPLS (AToM): Remote Release 2.4 end of an Ethernet over MPLS (EoMPLS) pseudowire to detect a remote link
Ethernet Port Shutdown failure and cause the shutdown of the Ethernet port on the local customer edge
(CE) router. Because the Ethernet port on the local CE router is shut down, the
router does not lose data by continuously sending traffic to the failed remote
link. This is beneficial if the link is configured as a static IP route.
Series Routers.
• Any Transport over MPLS (AToM): Remote Ethernet Port Shutdown,
page 11
• Configuring MPLS AToM Remote Ethernet Port Shutdown, page 66
Per-Subinterface MTU Cisco IOS XE This feature provides you with the ability to specify maximum transmission unit
for Ethernet over MPLS Release 2.4 (MTU) values in xconnect subinterface configuration mode. When you use
(EoMPLS) xconnect subinterface configuration mode to set the MTU value, you establish a
pseudowire connection for situations where the interfaces have different MTU
values that cannot be changed.
Series Aggregation Services Routers.
• Configuring per-Subinterface MTU for Ethernet over MPLS, page 52
No commands were new or modified for this release.
82
countries.
coincidental.
83
84
L2VPN Interworking

Layer 2 Virtual Private Network (L2VPN) Interworking allows you to connect disparate attachment
circuits. This feature module explains how to configure the following L2VPN Interworking features:
• Ethernet to VLAN Interworking
• Ethernet/VLAN to ATM virtual channel identifier (VPI) and virtual channel identifier (VCI)
Interworking

which each feature is supported, see the “Feature Information for L2VPN Interworking” section on page 10.
Contents
• Prerequisites for L2VPN Interworking, page 2
• Restrictions for L2VPN Interworking, page 2
• Information About L2VPN Interworking, page 3
• How to Configure L2VPN Interworking, page 5
• Configuration Examples for L2VPN Interworking, page 7
• Feature Information for L2VPN Interworking, page 10
L2VPN Interworking
Prerequisites for L2VPN Interworking
Prerequisites for L2VPN Interworking

Before you configure L2VPN Interworking on a router you must enable Cisco Express Forwarding.
Restrictions for L2VPN Interworking

The following sections list the L2VPN Interworking restrictions:
• General Restrictions for L2VPN Interworking, page 2
• Ethernet/VLAN Interworking Restrictions, page 2
• AToM Interworking Restrictions, page 3
General Restrictions for L2VPN Interworking

This section lists general restrictions that apply to L2VPN Interworking. Other restrictions that are
platform-specific or device-specific are listed in the following sections.
• The interworking type on one provider edge (PE) router must match the interworking type on the
peer PE router.
• Only the following QoS features are supported with L2VPN Interworking:
– Static IP type of service (ToS) or Multiprotocol Label Switching (MPLS) experimental bit
(EXP) setting in tunnel header
– One-to-one mapping of VLAN priority bits to MPLS EXP bits
Ethernet/VLAN Interworking Restrictions

The following restrictions apply to Ethernet/VLAN interworking:
• Ethernet interworking for a raw Ethernet port or a VLAN trunk is not supported. Traffic streams are
not kept separate when traffic is sent between transport types.
• In routed mode, only one CE router can be attached to an Ethernet PE router.
• There must be a one-to-one relationship between an attachment circuit and the pseudowire.
Point-to-multipoint or multipoint-to-point configurations are not supported.
• Configure routing protocols for point-to-point operation on the CE routers when configuring an
Ethernet to non-Ethernet setup.
• In the IP interworking mode, the IPv4 (0800) translation is supported. The PE router captures ARP
(0806) packets and responds with its own MAC address (proxy ARP). Everything else is dropped.
• The Ethernet or VLAN must contain only two IP devices: PE router and CE router. The PE router
performs proxy ARP and responds to all ARP requests it receives. Therefore, only one CE and one
PE router should be on the Ethernet or VLAN segment.
• If the CE routers are doing static routing, you can perform the following tasks:
– The PE router needs to learn the MAC address of the CE router to correctly forward traffic to
it. The Ethernet PE router sends an Internet Control Message Protocol (ICMP) Router discovery
protocol (RDP) solicitation message with the source IP address as zero. The Ethernet CE router
responds to this solicitation message. To configure the Cisco CE router’s Ethernet or VLAN
2
L2VPN Interworking
Information About L2VPN Interworking
interface to respond to the ICMP RDP solicitation message, issue the ip irdp command in
interface configuration mode. If you do not configure the CE router, traffic is dropped until the
CE router sends traffic toward the PE router.
– To disable the CE routers from running the router discovery protocol, issue the ip irdp
maxadvertinterval 0 command in interface mode.
• When the PE router on the Ethernet side receives a VLAN tagged packet from the CE router, the PE
router removes the VLAN tag from the Ethernet frame from the CE router. In the reverse direction,
the PE router adds the VLAN tag to the frames before sending the frame to the CE router. The VLAN
tag needs to be inserted or removed in this way when you configure VLAN to Ethernet interworking,
VLAN to Frame Relay, or ATM using Ethernet (bridged) interworking.
This restriction applies if you configure interworking between Ethernet and VLAN with Catalyst
switches as the CE routers. The spanning tree protocol is supported for Ethernet interworking.
Ethernet interworking between an Ethernet port and a VLAN supports spanning tree protocol only
on VLAN 1. Configure VLAN 1 as a nonnative VLAN.
• In bridged interworking from VLAN to Frame Relay, the Frame Relay PE router does not strip off
VLAN tags from the Ethernet traffic it receives.
• When you change the interworking configuration on an Ethernet PE router, clear the ARP entry on
the adjacent CE router so that it can learn the new MAC address. Otherwise, you might experience
traffic drops.
AToM Interworking Restrictions

PFC-based EoMPLS is not supported on ES40 line cards. SVI and EVC/scalable EoMPLS are the
alternative options.

The following sections provide an introduction to L2VPN interworking.
• Overview of L2VPN Interworking, page 3
• L2VPN Interworking Modes, page 3
Overview of L2VPN Interworking

Layer 2 transport over MPLS and IP already exists for like-to-like attachment circuits, such as
Ethernet-to-Ethernet or PPP-to-PPP. L2VPN Interworking builds on this functionality by allowing
disparate attachment circuits to be connected. An interworking function facilitates the translation
between the different Layer 2 encapsulations.
The L2VPN Interworking feature supports Ethernet to VLAN ( 802.1Q) over AToM. The features and
restrictions for like-to-like functionality also apply to L2VPN Interworking.
L2VPN Interworking Modes

L2VPN Interworking works in either Ethernet (“bridged”) mode or IP (“routed”) mode. You specify the
mode by issuing the interworking {ethernet | ip} command in pseudowire-class configuration mode.
3
L2VPN Interworking
The interworking command causes the attachment circuits to be terminated locally. The two keywords
perform the following functions:
• The ethernet keyword causes Ethernet frames to be extracted from the attachment circuit and sent
over the pseudowire. Ethernet end-to-end transmission is assumed. Attachment circuit frames that
are not Ethernet are dropped. In the case of VLAN, the VLAN tag is removed, leaving an untagged
Ethernet frame.
• The ip keyword causes IP packets to be extracted from the attachment circuit and sent over the
pseudowire. Attachment circuit frames that do not contain IPv4 packets are dropped.
The following sections explain more about Ethernet and IP interworking modes.
Ethernet Interworking
Ethernet Interworking is also called bridged interworking. Ethernet frames are bridged across the
pseudowire. The CE routers could be natively bridging Ethernet or could be routing using a bridged
encapsulation model, such as Bridge Virtual Interface (BVI) or RBE. The PE routers operate in Ethernet
like-to-like mode.
This mode is used to offer the following services:
• LAN services—An example is an enterprise that has several sites, where some sites have Ethernet
connectivity to the service provider (SP) network and others have ATM connectivity. The enterprise
wants LAN connectivity to all its sites. In this case, traffic from the Ethernet or VLAN of one site
can be sent through the IP/MPLS network and encapsulated as bridged traffic over an ATM VC of
another site.
• Connectivity services—An example is an enterprise that has different sites that are running an
Internal Gateway Protocol (IGP) routing protocol, which has incompatible procedures on broadcast
and nonbroadcast links. The enterprise has several sites that are running an IGP, such as Open
Shortest Path First (OSPF) or Intermediate System to Intermediate System (IS-IS), between the
sites. In this scenario, some of the procedures (such as route advertisement or designated router)
depend on the underlying Layer 2 protocol and are different for a point-to-point ATM connection
versus a broadcast Ethernet connection. Therefore, the bridged encapsulation over ATM can be used
to achieve homogenous Ethernet connectivity between the CE routers running the IGP.
IP Interworking
IP Interworking is also called routed interworking. The CE routers encapsulate IP on the link between
the CE and PE routers. A new VC type is used to signal the IP pseudowire in MPLS. Translation between
the Layer 2 and IP encapsulations across the pseudowire is required. Special consideration needs to be
given to address resolution and routing protocol operation, because these are handled differently on
different Layer 2 encapsulations.
This mode is used to provide IP connectivity between sites, regardless of the Layer 2 connectivity to
these sites. It 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.
Address resolution is encapsulation dependent:
• Ethernet uses ARP
• Frame Relay and ATM use Inverse ARP
• PPP uses IPCP
4
L2VPN Interworking
How to Configure L2VPN Interworking
Therefore, address resolution must be terminated on the PE router. End-to-end address resolution is not
supported. Routing protocols operate differently over broadcast and point-to-point media. For Ethernet,
the CE routers must either use static routing or configure the routing protocols to treat the Ethernet side
as a point-to-point network.

The following sections explain the tasks you can perform to configure L2VPN Interworking:
• Configuring L2VPN Interworking, page 5 (required)
• Verifying the L2VPN Interworking Configuration, page 6 (optional)
Configuring L2VPN Interworking

L2VPN Interworking allows you to connect disparate attachment circuits. Configuring the L2VPN
Interworking feature requires that you add the interworking command to the list of commands that make
up the pseudowire. The steps for configuring the pseudowire for L2VPN Interworking are included in
this section. You use the interworking command as part of the overall AToM configuration. For specific
instructions on configuring AToM, see the Any Transport over MPLS document.
SUMMARY STEPS
1. enable
4. encapsulation {mpls | l2tpv3}
5. interworking {ethernet | ip}
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class name Establishes a pseudowire class with a name that you specify
and enters pseudowire class configuration mode.
Example:
Router(config)# pseudowire-class class1
5
L2VPN Interworking

Step 4 encapsulation {mpls | l2tpv3} Specifies the tunneling encapsulation, which is either mpls
or l2tpv3.
Example:
Step 5 interworking {ethernet | ip} Specifies the type of pseudowire and the type of traffic that
can flow across it.
Example:
Router(config-pw)# interworking ip
Verifying the L2VPN Interworking Configuration

To verify the L2VPN Interworking configuration, you can use the following commands.
SUMMARY STEPS
1. show arp
2. ping
3. show mpls l2transport vc detail
DETAILED STEPS
Step 1 show arp

You can issue the show arp command between the CE routers to ensure that data is being sent:
Router# show arp
Protocol Address Age (min) Hardware Addr Type Interface

Internet 10.1.1.5 134 0005.0032.0854 ARPA FastEthernet0/0/0
Internet 10.1.1.7 - 0005.0032.0000 ARPA FastEthernet0/0/0
Step 2 ping
You can issue the ping command between the CE routers to ensure that data is being sent:
Router# ping 10.1.1.5
Type escape sequence to abort.

Sending 5, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Step 3 show mpls l2transport vc detail (AToM only)

You can verify the AToM configuration by using the show mpls l2transport vc detail command. In the
following example, the interworking type is shown in bold.
6
L2VPN Interworking
Configuration Examples for L2VPN Interworking
PE1 PE2
Router# show mpls l2transport vc detail Router# show mpls l2transport vc detail
Local interface: Fa1/1/0 up, line protocol up, Local interface: Fa2/0/0.3 up, line protocol up, Eth
FastEthernet up VLAN 10 up
Destination address: 10.9.9.9, VC ID: 123, VC MPLS VC type is FastEthernet, interworking type is
status: up FastEthernet
Preferred path: not configured Destination address: 10.8.8.8, VC ID: 123, VC status:
Default path: active up
Tunnel label: 17, next hop 10.1.1.3 Preferred path: not configured
Output interface: Fa4/0/0, imposed label Default path: active
stack {17 20} Tunnel label: 16, next hop 10.1.1.3
Create time: 01:43:50, last status change time: Output interface: Fa6/0/0, imposed label stack {16
01:43:33 16}
Signaling protocol: LDP, peer 10.9.9.9:0 up Create time: 00:00:26, last status change time:
MPLS VC labels: local 16, remote 20 00:00:06
Group ID: local 0, remote 0 Signaling protocol: LDP, peer 10.8.8.8:0 up
MTU: local 1500, remote 1500 MPLS VC labels: local 20, remote 16
Remote interface description: Group ID: local 0, remote 0
Sequencing: receive disabled, send disabled MTU: local 1500, remote 1500
VC statistics: Remote interface description:
packet totals: receive 15, send 4184 Sequencing: receive disabled, send disabled
byte totals: receive 1830, send 309248 VC statistics:
packet drops: receive 0, send 0 packet totals: receive 5, send 0
Configuration Examples for L2VPN Interworking

The following section shows an example of L2VPN Interworking:
• Ethernet to VLAN over AToM (Bridged): Example, page 7
Ethernet to VLAN over AToM (Bridged): Example

The following example shows the configuration of Ethernet to VLAN over AToM:
7
L2VPN Interworking
PE1 PE2
ip cef ip cef
! !
! !
pseudowire-class atom-eth-iw pseudowire-class atom
encapsulation mpls encapsulation mpls
interworking ethernet !
! interface Loopback0
interface Loopback0 ip address 10.9.9.9 255.255.255.255
ip address 10.8.8.8 255.255.255.255 !
! interface FastEthernet0/0/0
interface FastEthernet1/0/0.1 no ip address
encapsulation dot1q 100 !
xconnect 10.9.9.9 123 pw-class atom-eth-iw interface FastEthernet1/0
xconnect 10.9.9.9 123 pw-class atom
The following sections provide references related to the L2VPN Interworking feature.
Related Documents
MPLS commands Multiprotocol Label Switching Command Reference
Any Transport over MPLS Any Transport over MPLS
Standards
Standards Title
draft-ietf-l2tpext-l2tp-base-03.txt Layer Two Tunneling Protocol (Version 3) 'L2TPv3'
draft-martini-l2circuit-trans-mpls-09.txt Transport of Layer 2 Frames Over MPLS
draft-ietf-pwe3-frame-relay-03.txt. Encapsulation Methods for Transport of Frame Relay over MPLS
Networks
draft-martini-l2circuit-encap-mpls-04.txt. Encapsulation Methods for Transport of Layer 2 Frames Over IP
and MPLS Networks
draft-ietf-pwe3-ethernet-encap-08.txt. Encapsulation Methods for Transport of Ethernet over MPLS
Networks
draft-ietf-pwe3-hdlc-ppp-encap-mpls-03.txt. Encapsulation Methods for Transport of PPP/HDLC over MPLS
Networks
draft-ietf-ppvpn-l2vpn-00.txt. An Architecture for L2VPNs
8
L2VPN Interworking
MIBs
MIBs MIBs Link
RFCs
RFCs Title
Description Link
9
L2VPN Interworking
Feature Information for L2VPN Interworking
Feature Information for L2VPN Interworking

Table 1 Feature Information for L2VPN Interworking

L2VPN Cisco IOS XE This feature allows disparate attachment circuits to be connected. An
Interworking–Ethernet-to Release 2.4 interworking function facilitates the translation between the different
-VLAN Interworking Layer 2 encapsulations.
• Restrictions for L2VPN Interworking, page 2
• Information About L2VPN Interworking, page 3
• How to Configure L2VPN Interworking, page 5
The following commands were introduced or modified: debug frame-relay
pseudowire, debug ssm, interworking, mtu, pseudowire-class, show l2tun
session, show l2tun tunnel, show mpls l2transport vc, show platform.
Cisco Pulse, Cisco StackPower, Cisco StadiumVision, Cisco TelePresence, Cisco Unified Computing System, Cisco WebEx, DCE, Flip Channels,
Flip for Good, Flip Mino, Flipshare (Design), Flip Ultra, Flip Video, Flip Video (Design), Instant Broadband, and Welcome to the Human Network
are trademarks; Changing the Way We Work, Live, Play, and Learn, Cisco Capital, Cisco Capital (Design), Cisco:Financed (Stylized), Cisco Store,
and Flip Gift Card are service marks; and Access Registrar, Aironet, AllTouch, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP,
CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems,
Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Continuum, EtherFast, EtherSwitch, Event Center,
Explorer, Fast Step, Follow Me Browsing, FormShare, GainMaker, GigaDrive, HomeLink, iLYNX, Internet Quotient, IOS, iPhone, iQuick Study,
IronPort, the IronPort logo, Laser Link, LightStream, Linksys, MediaTone, MeetingPlace, MeetingPlace Chime Sound, MGX, Networkers,
Networking Academy, Network Registrar, PCNow, PIX, PowerKEY, PowerPanels, PowerTV, PowerTV (Design), PowerVu, Prisma, ProConnect,
ROSA, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx,
and the WebEx logo are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
coincidental.
10
L2VPN Pseudowire Redundancy
First Published: April 20, 2005

The L2VPN Pseudowire Redundancy feature enables you to configure your network to detect a failure
in the network and reroute the Layer 2 (L2) service to another endpoint that can continue to provide
service. This feature provides the ability to recover from a failure either of the remote provider edge (PE)
router or of the link between the PE and customer edge (CE) routers. This feature also provides the
ability to set up multiple backup pseudowires.

which each feature is supported, see the “Feature Information for L2VPN Pseudowire Redundancy” section
on page 14.
Contents
• Prerequisites for L2VPN Pseudowire Redundancy, page 2
• Restrictions for L2VPN Pseudowire Redundancy, page 2
• Information About L2VPN Pseudowire Redundancy, page 3
• How to Configure L2VPN Pseudowire Redundancy, page 4
• Configuration Examples for L2VPN Pseudowire Redundancy, page 11
• Feature Information for L2VPN Pseudowire Redundancy, page 14
Prerequisites for L2VPN Pseudowire Redundancy
Prerequisites for L2VPN Pseudowire Redundancy

• This feature module requires that you understand how to configure basic L2 Virtual Private
Networks (VPNs).
• The L2VPN Pseudowire Redundancy feature requires that the following mechanisms be in place to
enable you to detect a failure in the network:
– Label-switched paths (LSP) Ping/Traceroute and Any Transport over MPLS Virtual Circuit
Connection Verification (AToM VCCV)
– Local Management Interface (LMI)
– Operation, Administration, and Maintenance (OAM)
Restrictions for L2VPN Pseudowire Redundancy

• The default Label Distribution Protocol (LDP) session hold-down timer will enable the software to
detect failures in about 180 seconds. That time can be configured so that the software can detect
failures more quickly. See the mpls ldp holdtime command for more information.
• Pseudowire redundancy is not supported for Layer 2 Tunnel Protocol Version 3 (L2TPv3) xconnect
configurations.
• The primary and backup pseudowires must run the same type of transport service. The primary and
backup pseudowires must be configured with AToM.
• Only static, on-box provisioning is supported in this release.
• If you use L2VPN Pseudowire Redundancy with L2VPN Interworking, the interworking method
must be the same for the primary and backup pseudowires.
• L2VPN Pseudowire Redundancy does support setting the experimental (EXP) bit on the
Multiprotocol Label Switching (MPLS) pseudowire.
• L2VPN Pseudowire Redundancy does not support different pseudowire encapsulation types on the
MPLS pseudowire.
• The mpls l2transport route command is not supported. Use the xconnect command instead.
• The ability to have the backup pseudowire fully operational at the same time that the primary
pseudowire is operational is not supported. The backup pseudowire becomes active only after the
primary pseudowire fails.
• The AToM VCCV feature is supported only on the active pseudowire.
• In Cisco IOS XE Release 2.3, only one backup pseudowire is supported. In Cisco IOS XE Release
2.4 and later releases, up to three backup pseudowires are supported.
• A primary pseudowire in L2VPN Pseudowire Redundancy feature cannot be backed up by a Layer
2 local switched interface.
• In Cisco IOS XE Release 2.4, the L2VPN Pseudowire Redundancy: Multiple Backup Pseudowires
feature supports only ATM interfaces.
2
Information About L2VPN Pseudowire Redundancy
Information About L2VPN Pseudowire Redundancy

Make sure that you understand the following concept before configuring the L2VPN Pseudowire
Redundancy feature:
• Introduction to L2VPN Pseudowire Redundancy, page 3
Introduction to L2VPN Pseudowire Redundancy

L2VPNs can provide pseudowire resiliency through their routing protocols. When connectivity between
end-to-end PE routers fails, an alternative path to the directed LDP session and the user data can take
over. However, there are some parts of the network where this rerouting mechanism does not protect
against interruptions in service. Figure 1 shows those parts of the network that are vulnerable to an
interruption in service.
Figure 1 Points of Potential Failure in an L2VPN Network
X2 X4
X1 X3
CE1 PE1 P1 P2 PE2 CE2
X1 = End-to-end routing failure
135057
X2 = PE hardware or software failure
X3 = Attachment circuit failure from a line break
X4 = CE hardware or software failure
The L2VPN Pseudowire Redundancy feature provides the ability to ensure that the CE2 router in
Figure 1 can always maintain network connectivity, even if one or all the failures in the figure occur.
The L2VPN Pseudowire Redundancy feature enables you to set up backup pseudowires. You can
configure the network with redundant pseudowires (PWs) and redundant network elements, which are
shown in Figure 2, Figure 3, and Figure 4.
Figure 2 shows a network with redundant pseudowires and redundant attachment circuits.
Figure 2 L2 VPN Network with Redundant PWs and Attachment Circuits
Primary
pseudowire
Redundant
CE1 PE1 PE2 attachment CE2
135058
circuits
Backup
pseudowire
Figure 3 shows a network with redundant pseudowires, attachment circuits, and CE routers.
3
How to Configure L2VPN Pseudowire Redundancy
Figure 3 L2 VPN Network with Redundant PWs, Attachment Circuits, and CE Routers
Redundant
CE routers
Primary
pseudowire
CE2a
CE1 PE1 PE2

Redundant
attachment
135059
Backup circuits CE2b
pseudowire
Figure 4 shows a network with redundant pseudowires, attachment circuits, CE routers, and PE routers.
Figure 4 L2 VPN Network with Redundant PWs, Attachment Circuits, CE Routers,

and PE Routers
Primary
pseudowire
Redundant Redundant
PE routers CE routers
Redundant
PE2a CE2a
attachment
circuits
CE1 PE1
PE2b CE2b
135060
Backup
pseudowire

The L2VPN Pseudowire Redundancy feature enables you to configure a backup pseudowire in case the
primary pseudowire fails. When the primary pseudowire fails, the PE router can switch to the backup
pseudowire. You can have the primary pseudowire resume operation after it comes back up.
Note In Cisco IOS XE Release 2.3, only one backup pseudowire is supported. In Cisco IOS XE Release 2.4
and later releases, up to three backup pseudowires are supported.
The following sections explain how to configure the L2VPN Pseudowire Redundancy feature:
• Configuring the Pseudowire Attributes, page 5 (required)
• Configuring a Single Backup Pseudowire, page 6 (required)
• Configuring Multiple Backup Pseudowires, page 7 (required)
• Forcing a Manual Switchover to the Backup Pseudowire VC, page 9 (optional)
• Verifying the L2VPN Pseudowire Redundancy Configuration, page 10 (optional)
4
Configuring the Pseudowire Attributes

PE routers. You set up the connection, called a pseudowire, between the routers.
The pseudowire-class configuration group specifies the characteristics of the tunneling mechanism,
which are:
You must specify the encapsulation mpls command as part of the pseudowire class for the AToM VCs
to work properly. If you omit the encapsulation mpls command as part of the xconnect command, you
receive the following error:
Perform this task to configure a pseudowire class.
SUMMARY STEPS
1. enable
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class name Establishes a pseudowire class with a name that you specify. Enters
Example:
5

type is mpls.
Example:
Router(config-pw-class)#
encapsulation mpls
Step 5 interworking {ethernet | ip} (Optional) Enables the translation between the different Layer 2
encapsulations.
Example:
Router(config-pw-class)# interworking
ip
Configuring a Single Backup Pseudowire

In Cisco IOS XE Release 2.3, only one backup pseudowire is supported. In Cisco IOS XE Release 2.4
and later releases, up to three backup pseudowires are supported. Use the following steps to configure a
single backup pseudowire.
Prerequisites
For each transport type, the xconnect command is configured slightly differently. The following
configuration steps use Ethernet VLAN over MPLS, which is configured in subinterface configuration
mode. See Any Transport over MPLS to determine how to configure the xconnect command for other
transport types.
SUMMARY STEPS
1. enable
3. interface gigabitethernet slot/subslot/interface.[subinterface]
5. xconnect peer-router-id vcid {encapsulation mpls | pw-class pw-class-name}
6. backup peer peer-router-ip-addr vcid [pw-class pw-class-name]
7. backup delay enable-delay {disable-delay | never}
DETAILED STEPS

Example:
Router> enable
Example:
6

slot/subslot/interface.[subinterface] subinterface configuration mode.
Make sure that the subinterface on the adjoining CE
Example: router is on the same VLAN as this PE router.
packets.
Example: The subinterfaces between the CE and PE routers that are
Router(config-subif)# encapsulation dot1q 100 running Ethernet over MPLS must be in the same subnet.
All other subinterfaces and backbone routers do not.
Step 5 xconnect peer-router-id vcid {encapsulation mpls | Binds the attachment circuit to a pseudowire VC.
pw-class pw-class-name}
Layer 2 transports.
Example:
Enters xconnect configuration mode.
pw-class atom
Step 6 backup peer peer-router-ip-addr vcid [pw-class Specifies a redundant peer for the pseudowire VC.
pw-class-name]
The pseudowire class name must match the name you
specified when you created the pseudowire class, but you
Example: can use a different pw-class in the backup peer
Router(config-if-xconn)# backup peer 10.0.0.3 125 command than the name that you used in the primary
pw-class atom
xconnect command.
Step 7 backup delay enable-delay {disable-delay | never} Specifies how long (in seconds) the backup pseudowire
VC should wait to take over after the primary pseudowire
VC goes down. The range is 0 to 180.
Example:
Router(config-if-xconn)# backup delay 5 never Specifies how long the primary pseudowire should wait
after it becomes active to take over for the backup
pseudowire VC. The range is 0 to 180 seconds. If you
specify the never keyword, the primary pseudowire VC
never takes over for the backup.
Configuring Multiple Backup Pseudowires

In Cisco IOS XE Release 2.4 and later releases, up to three backup pseudowires are supported. You can
assign priorities to the backup pseudowires to specify which pseudowire to use first if the primary
pseudowire fails. Use the following steps to configure multiple backup pseudowires.
Restrictions
In Cisco IOS XE Release 2.4, the L2VPN Pseudowire Redundancy: Multiple Backup Pseudowires
feature supports only ATM interfaces.
SUMMARY STEPS
1. enable
7
3. interface atm slot/port

6. xconnect peer-router-id vcid {encapsulation mpls | pw-class pw-class-name}
7. backup peer peer-router-ip-addr vcid [pw-class pw-class-name] [priority value]
8. backup delay enable-delay {disable-delay | never}
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface atm slot/port/ Specifies the atm interface and enters interface
configuration mode.
Example:
Router(config)# interface atm1/0
configuration mode.
Example:
Router(config-if)# pvc 1/100 l2transport
• The l2transport keyword indicates that the PVC is
a switched PVC instead of a terminated PVC.
Step 5 encapsulation layer-type Enables the interface to accept ATM packets.
Example:
aal5snap
Step 6 xconnect peer-router-id vcid {encapsulation mpls | Binds the attachment circuit to a pseudowire VC.
pw-class pw-class-name}
Layer 2 transports.
Example:
Enters xconnect configuration mode.
10.0.0.1 123 pw-class atom
8

Step 7 backup peer peer-router-ip-addr vcid [pw-class Specifies a redundant peer for the pseudowire VC and
pw-class-name] [priority value] specifies the priority of the backup pseudowire. If you
use multiple backup pseudowires, assigning a priority to
Example: the backup pseudowires determines which backup
Router(config-if-xconn)# backup peer 10.0.0.3 125 pseudowire to use first.
pw-class atom priority 2
The pseudowire class name must match the name you
specified when you created the pseudowire class, but you
can use a different pseudowire class in the backup peer
command than the name that you used in the primary
xconnect command.
Step 8 backup delay enable-delay {disable-delay | never} Specifies how long (in seconds) the backup pseudowire
VC should wait to take over after the primary pseudowire
VC goes down. The range is 0 to 180.
Example:
Router(config-if-xconn)# backup delay 5 never Specifies how long the primary pseudowire should wait
after it becomes active to take over for the backup
pseudowire VC. The range is 0 to 180 seconds. If you
specify the never keyword, the primary pseudowire VC
never takes over for the backup.
Forcing a Manual Switchover to the Backup Pseudowire VC

To force the router switch over to the backup or primary pseudowire, you can enter the xconnect backup
force switchover command in privileged EXEC mode. You can specify either the interface of the
primary attachment circuit (AC) to switch to or the IP-address and VC ID of the peer router.
A manual switchover can be made only if the interface or peer specified in the command is actually
available and the xconnect will move to the fully active state when the command is entered.
SUMMARY STEPS
1. enable
2. xconnect backup force-switchover interface {type number| peer ip-address vcid}
DETAILED STEPS

Example:
Router> enable
Step 2 xconnect backup force-switchover {interface type Specifies that the router should switch to the backup or
number| peer ip-address vcid} to the primary pseudowire.
Example:
Router# xconnect backup force-switchover peer
10.10.10.1 123
9
Verifying the L2VPN Pseudowire Redundancy Configuration

Use the following commands to verify that the L2VPN Pseudowire Redundancy feature is correctly
configured.
SUMMARY STEPS

2. show xconnect all
3. xconnect logging redundancy
DETAILED STEPS
Step 1 show mpls l2transport vc

In this example, the primary attachment circuit is up. The backup attachment circuit is available, but not
currently selected. The show output displays as follows:

------------- ----------------------- --------------- ---------- ----------
Fe0/0/0.1 Fe VLAN 101 10.0.0.2 101 UP
Fe0/0/0.1 Fe VLAN 101 10.0.0.3 201 STANDBY
Local interface: fe0/0/0.1 up, line protocol up, fe VLAN 101 up

Destination address 10.0.0.2 VC ID: 101, VC status UP
.
.
.
Local interface: fe0/0/0.1 down, line protocol down, fe VLAN 101 down
Destination address 10.0.0.3 VC ID: 201, VC status down
.
.
.
Step 2 show xconnect all

In this example, the topology is Attachment Circuit 1 to Pseudowire 1 with a Pseudowire 2 as a backup:
Router# show xconnect all
Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State

UP=Up, DN=Down, AD=Admin Down, IA=Inactive, NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
UP pri ac fe0/0/0(FastEthernet) UP mpls 10.55.55.2:1000 UP
IA sec ac fe0/0/0(FastEthernet) UP mpls 10.55.55.3:1001 DN
In this example, the topology is Attachment Circuit 1 to Attachment Circuit 2 with a Pseudowire backup
for Attachment Circuit 2:
Legend: XC ST=Xconnect State, S1=Segment1 State, S2=Segment2 State

UP=Up, DN=Down, AD=Admin Down, IA=Inactive, NH=No Hardware
XC ST Segment 1 S1 Segment 2 S2
------+---------------------------------+--+---------------------------------+--
10
Configuration Examples for L2VPN Pseudowire Redundancy
UP pri ac Se6/0/0:150(FR DLCI) UP ac Se8/0:150(FR DLCI) UP

IA sec ac Se6/0/0:150(FR DLCI) UP mpls 10.55.55.3:7151 DN
Step 3 xconnect logging redundancy

In addition to the show mpls l2transport vc command and the show xconnect command, you can use
the xconnect logging redundancy command to track the status of the xconnect redundancy group:
Router(config)# xconnect logging redundancy
When this command is configured, the following messages will be generated during switchover events:
Activating the primary member:
00:01:07: %XCONNECT-5-REDUNDANCY: Activating primary member 10.55.55.2:1000
Activating the backup member:

00:01:05: %XCONNECT-5-REDUNDANCY: Activating secondary member 10.55.55.3:1001
Configuration Examples for L2VPN Pseudowire Redundancy

The following sections show the L2VPN Pseudowire Redundancy feature examples. These configuration
examples show how the L2VPN Pseudowire Redundancy feature can be configured with the AToM
(like-to-like) and L2VPN Interworking features.
• L2VPN Pseudowire Redundancy and AToM (Like-to-Like): Examples, page 11
• L2VPN Pseudowire Redundancy and L2VPN Interworking: Examples, page 12
• L2VPN Pseudowire Redundancy—Multiple Backup Pseudowires: Example, page 12
Each of the configuration examples refers to one of the following pseudowire classes:
• AToM (like-to-like) pseudowire class:
pseudowire-class mpls
encapsulation mpls
• L2VPN IP interworking:
pseudowire-class mpls-ip
encapsulation mpls
interworking ip
L2VPN Pseudowire Redundancy and AToM (Like-to-Like): Examples

The following example shows a High-Level Data Link Control (HDLC) attachment circuit xconnect with
a backup pseudowire:
xconnect 10.55.55.2 4000 pw-class mpls
backup peer 10.55.55.3 4001 pw-class mpls
The following example shows a Frame Relay attachment circuit xconnect with a backup pseudowire:
connect fr-fr-pw Serial6/0/0 225 l2transport
backup peer 10.55.55.3 5226 pw-class mpls
11
L2VPN Pseudowire Redundancy and L2VPN Interworking: Examples

The following example shows a Fast Ethernet attachment circuit xconnect with L2VPN IP interworking
and a backup pseudowire:
xconnect 10.55.55.2 1000 pw-class mpls-ip
backup peer 10.55.55.3 1001 pw-class mpls-ip
The following example shows an Fast Ethernet VLAN attachment circuit xconnect with L2VPN IP
interworking and a backup pseudowire:
xconnect 10.55.55.2 5200 pw-class mpls-ip
backup peer 10.55.55.3 5201 pw-class mpls-ip
L2VPN Pseudowire Redundancy—Multiple Backup Pseudowires: Example

The following example shows a pseudowire with two backup pseudowires:
interface ATM4/0.1 point-to-point
encapsulation aal5snap
backup peer 10.1.1.1 101
backup peer 10.10.1.1 110 priority 2
backup peer 10.20.1.1 111 priority 9
The following sections provide references related to the L2VPN Pseudowire Redundancy feature.
Related Documents
MPLS applications
High Availability for AToM AToM Graceful Restart
Standards
Standards Title
No new or modified standards are supported, and —
support for existing standards has not been modified by
this feature.
12
MIBs
MIBs MIBs Link
No new or modified MIBs are supported, and support To locate and download MIBs for selected platforms, Cisco IOS XE
for existing MIBs has not been modified. software releases, and feature sets, use Cisco MIB Locator found at
the following URL:
RFCs
RFCs Title
No new or modified RFCs are supported, and support —
for existing RFCs has not been modified.
Description Link
13
Feature Information for L2VPN Pseudowire Redundancy

Cisco IOS XE software release train. Unless noted otherwise, subsequent releases of that Cisco IOS XE
software release train also support that feature.
Table 1 Feature Information for L2VPN Pseudowire Redundancy

L2VPN Pseudowire Redundancy Cisco IOS XE This feature enables you to set up your network to detect
Release 2.3 a failure in the network and reroute the Layer 2 service to
another endpoint that can continue to provide service.
feature:
• Introduction to L2VPN Pseudowire Redundancy,
page 3
• Configuring the Pseudowire Attributes, page 5
• Configuring a Single Backup Pseudowire, page 6
• Forcing a Manual Switchover to the Backup
Pseudowire VC, page 9
• Verifying the L2VPN Pseudowire Redundancy
Configuration, page 10
backup delay (L2VPN local switching), backup peer,
show xconnect, xconnect backup force-switchover,
xconnect logging redundancy.
L2VPN Pseudowire Redundancy: Multiple Cisco IOS XE This feature enables multiple backup pseudowires. The
Backup Pseudowires Release 2.4 following command was modified: backup peer.
countries.
14
coincidental.
15
16
L2VPN: Pseudowire Preferential Forwarding

The L2VPN: Pseudowire Preferential Forwarding feature allows you to configure the pseudowires so
that you can use ping and show commands to find status information of the pseudowires before, during,
and after a switchover.

which each feature is supported, see the “Feature Information for L2VPN: Pseudowire Preferential
Forwarding” section on page 9.
Contents
• Prerequisites for L2VPN: Pseudowire Preferential Forwarding, page 2
• Restrictions for L2VPN: Pseudowire Preferential Forwarding, page 2
• Information About L2VPN: Pseudowire Preferential Forwarding, page 2
• How to Configure L2VPN: Pseudowire Preferential Forwarding, page 3
• Configuration Examples for L2VPN: Pseudowire Preferential Forwarding, page 5
• Feature Information for L2VPN: Pseudowire Preferential Forwarding, page 9
Prerequisites for L2VPN: Pseudowire Preferential Forwarding
Prerequisites for L2VPN: Pseudowire Preferential Forwarding

• Before configuring the L2VPN: Pseudowire Preferential Forwarding feature, you should understand
the concepts in the following documents:
– Preferential Forwarding Status Bit Definition (draft-ietf-pwe3-redundancy-bit-xx.txt)
– MPLS Pseudowire Status Signaling
– L2VPN Pseudowire Redundancy
– NSF/SSO—Any Transport over MPLS and AToM Graceful Restart
– MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
• The PE routers must be configured with the following features:
– L2VPN Pseudowire Redundancy
– NSF/SSO—Any Transport over MPLS and AToM Graceful Restart
• The L2VPN: Pseudowire Preferential Forwarding feature requires that the following mechanisms be
in place to enable you to detect a failure in the network:
– Label switched paths (LSP) Ping/Traceroute and Any Transport over MPLS Virtual Circuit
Connection Verification (AToM VCCV)
– Local Management Interface (LMI)
– Operation, Administration, and Maintenance (OAM)
Restrictions for L2VPN: Pseudowire Preferential Forwarding

• Only ATM attachment circuits are supported.
• The following features are not supported:
– Port mode cell relay
– Any Transport over MPLS: AAL5 over MPLS
– VC cell packing
– OAM emulation
– ILMI/PVC-D
– Permanent virtual circuit (PVC) Range
– L2TPv3 Pseudowire Redundancy
– Local switching
– Multiple backup pseudowires
– Static pseudowires
Information About L2VPN: Pseudowire Preferential Forwarding

The following section provides information about the L2VPN: Pseudowire Preferential Forwarding
feature:
• Overview of L2VPN: Pseudowire Preferential Forwarding, page 3
2
How to Configure L2VPN: Pseudowire Preferential Forwarding
Overview of L2VPN: Pseudowire Preferential Forwarding

The L2VPN: Pseudowire Preferential Forwarding feature allows you to configure pseudowires so that
you can use ping, traceroute, and show commands to find status information before, during, and after
a switchover. The implementation of this feature is based on Preferential Forwarding Status Bit
Definition (draft-ietf-pwe3-redundancy-bit-xx.txt). The L2VPN: Pseudowire Preferential Forwarding
feature provides these enhancements for displaying information about the pseudowires:
• You can issue ping mpls commands on the backup pseudowires.
• You can display status of the pseudowires before, during, and after a switchover, using the show
xconnect and show mpls l2transport vc commands.
Note In a single-segment pseudowire, the PE routers at each end of the pseudowire serve as the termination
points. In multisegment pseudowires, the terminating PE routers serve as the termination points.

The following section explains how to configure the L2VPN: Pseudowire Preferential Forwarding
feature:
• Configuring the Pseudowire Connection Between PE Routers, page 3 (required)
Configuring the Pseudowire Connection Between PE Routers

You set up a connection, called a pseudowire, between the routers to transmit Layer 2 frames between
PE routers.
As part of the pseudowire configuration, issue the status redundancy master command to make it the
master. This enables the L2VPN: Pseudowire Preferential Forwarding feature to display the status of the
active and backup pseudowires. By default, the PE router is in slave mode.
Note One pseudowire must be the master and the other must be assigned the slave. You cannot configure both
pseudowires as master or slave.
Note You must specify the encapsulation mpls command as part of the pseudowire class for the AToM VCs
to work properly. If you omit the encapsulation mpls command, you receive the following error:
Prerequisites
The PE routers must be configured for the L2VPN Pseudowire Redundancy and NSF/SSO—Any
Transport over MPLS and AToM Graceful Restart features. See the following documents for
configuration instructions.
• L2VPN Pseudowire Redundancy
• NSF/SSO—Any Transport over MPLS and AToM Graceful Restart
3
SUMMARY STEPS
1. enable
5. status redundancy {master | slave}
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class name Establishes a pseudowire class with a name that you specify, and enters
Example:
• For AToM, the encapsulation type is mpls.
Example:
Step 5 status redundancy {master | slave} Specifies the pseudowire as the master or slave. This enables the
L2VPN: Pseudowire Preferential Forwarding feature to display the
status of the active and backup pseudowires.
Example:
Router(config-pw)# status redundancy • By default, the PE router is in slave mode.
master
Note One pseudowire must be the master and the other must be
assigned the slave. You cannot configure both pseudowires as
master or slave.
Step 6 interworking {ethernet | ip} (Optional) Enables the translation between the different Layer 2
encapsulations.
Example:
Router(config-pw)# interworking ip
4
Configuration Examples for L2VPN: Pseudowire Preferential Forwarding
Configuration Examples for L2VPN: Pseudowire Preferential

Forwarding
• L2VPN: Pseudowire Preferential Forwarding Configuration: Example, page 5
• Displaying the Status of the Pseudowires: Example, page 5
L2VPN: Pseudowire Preferential Forwarding Configuration: Example

The following commands configure a PE router with the L2VPN: Pseudowire Preferential Forwarding
feature:
mpls ldp graceful-restart
mpls ip
mpls ldp advertise-labels
!
pseudowire-class mpls
encapsulation mpls
status redundancy master
interface ATM0/2/0.1 multipoint

logging event subif-link-status
xconnect 10.1.1.2 100 encap mpls
backup peer 10.1.1.3 100 encap mpls
end
Displaying the Status of the Pseudowires: Example

The following examples show the status of the active and backup pseudowires before, during, and after
a switchover.
The show mpls l2transport vc command on the active PE router displays the status of the pseudowires:

------------- -------------------------- --------------- ---------- ----------
AT0/2/0/0.1 ATM VPC CELL 50 10.1.1.2 100 UP
AT0/2/0/0.1 ATM VPC CELL 50 10.1.1.3 100 STANDBY
The show mpls l2transport vc command on the backup PE router displays the status of the pseudowires.
The active pseudowire on the backup PE router has the HOTSTANDBY status.
Router1-standby# show mpls l2transport vc

------------- -------------------------- --------------- ---------- ----------
AT0/2/0/0.1 ATM VPC CELL 50 10.1.1.2 100 HOTSTANDBY
AT0/2/0/0.1 ATM VPC CELL 50 10.1.1.3 100 DOWN
5
Configuration Examples for L2VPN: Pseudowire Preferential Forwarding
During a switchover, the status of the active and backup pseudowires changes:

------------- -------------------------- --------------- ---------- ----------
AT0/2/0/0.1 ATM VPC CELL 50 10.1.1.2 100 RECOVERING
AT0/2/0/0.1 ATM VPC CELL 50 10.1.1.3 100 DOWN
After the switchover is complete, the recovering pseudowire shows a status of UP:

------------- -------------------------- --------------- ---------- ----------
AT0/2/0/0.1 ATM VPC CELL 50 10.1.1.2 100 UP
AT0/2/0/0.1 ATM VPC CELL 50 10.1.1.3 100 STANDBY
The show xconnect command displays the standby (SB) state for the backup pseudowire, which is
independent of the stateful switchover mode of the router:
Legend: XC ST=Xconnect State S1=Segment1 State S2=Segment2 State

UP=Up DN=Down AD=Admin Down IA=Inactive
SB=Standby HS=Hot Standby RV=Recovering NH=No Hardware
XC ST Segment 1 S1 Segment 2
S2
------+---------------------------------+--+---------------------------------+---------
UP pri ac AT1/1/0/0.1/1/1:220/220(ATM V UP mpls 10.193.193.3:330 UP
IA sec ac AT1/1/0/0.1/1/1:220/220(ATM V UP mpls 10.193.193.3:331 SB
The ping mpls and traceroute mpls commands show that the dataplane is active on the backup
pseudowire:
Router# ping mpls pseudowire 10.193.193.22 331
%Total number of MS-PW segments is less than segment number; Adjusting the segment number
to 1
Sending 5, 100-byte MPLS Echos to 10.193.193.22,
timeout is 2 seconds, send interval is 0 msec:
Codes: '!' - success, 'Q' - request not sent, '.' - timeout,

'L' - labeled output interface, 'B' - unlabeled output interface,
'D' - DS Map mismatch, 'F' - no FEC mapping, 'f' - FEC mismatch,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no label entry,
'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

!!!!!
Router# traceroute mpls pseudowire 10.193.193.22 331 segment 1
Tracing MS-PW segments within range [1-1] peer address 10.193.193.22 and timeout 2 seconds

6


! 1 10.193.33.22 4 ms [Labels: 23 Exp: 0]
local 10.193.193.3 remote 10.193.193.22 vc id 331
The following sections provide references related to the L2VPN: Pseudowire Preferential Forwarding
feature.
Related Documents
MPLS applications
L2VPN Pseudowires • L2VPN Pseudowire Redundancy
• MPLS Pseudowire Status Signaling
NSF/SSO for L2VPNs NSF/SSO—Any Transport over MPLS and AToM Graceful Restart
Ping and Traceroute for L2VPNs MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
Standards
Standard Title
draft-ietf-pwe3-redundancy-bit-xx.txt Preferential Forwarding Status Bit Definition
MIBs
MIB MIBs Link
No new or modified MIBs are supported by this feature, To locate and download MIBs for selected platforms, Cisco IOS XE
and support for existing MIBs has not been modified by software releases, and feature sets, use Cisco MIB Locator found at
this feature. the following URL:
RFCs
RFC Title
7
Description Link
The Cisco Support website provides extensive http://www.cisco.com/techsupport
online resources, including documentation and
tools for troubleshooting and resolving technical
issues with Cisco products and technologies.
your products, you can subscribe to various
services, such as the Product Alert Tool (accessed
from Field Notices), the Cisco Technical Services
Newsletter, and Really Simple Syndication (RSS)
Feeds.
8
Feature Information for L2VPN: Pseudowire Preferential Forwarding
Feature Information for L2VPN: Pseudowire Preferential

Forwarding
Table 1 Feature Information for L2VPN: Pseudowire Preferential Forwarding

L2VPN: Pseudowire Preferential Forwarding Cisco IOS XE This feature allows you to configure the pseudowires so that
Release 2.3 you can use ping and show commands to find status
information of the pseudowires before, during, and after a
switchover.
feature:
• Information About L2VPN: Pseudowire Preferential
Forwarding, page 2
• How to Configure L2VPN: Pseudowire Preferential
Forwarding, page 3
show mpls l2transport vc, show xconnect, status
redundancy.
9
Feature Information for L2VPN: Pseudowire Preferential Forwarding
coincidental.
10
L2VPN Multisegment Pseudowires

The L2VPN Multisegment Pseudowires feature enables you to configure two or more Layer 2
pseudowire segments that function as a single pseudowire. The L2VPN Multisegment Pseudowires
feature span multiple cores or autonomous systems of the same or different carrier networks.

which each feature is supported, see the “Feature Information for L2VPN Multisegment Pseudowires”
section on page 11.
Contents
• Prerequisites for L2VPN Multisegment Pseudowires, page 2
• Restrictions for L2VPN Multisegment Pseudowires, page 2
• Information About L2VPN Multisegment Pseudowires, page 2
• How to Configure L2VPN Multisegment Pseudowires, page 4
• Feature Information for L2VPN Multisegment Pseudowires, page 11
Prerequisites for L2VPN Multisegment Pseudowires
Prerequisites for L2VPN Multisegment Pseudowires

Before configuring this feature, see the following documents:
• Any Transport over MPLS
• L2VPN Pseudowire Switching
• MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
• Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP) (RFC 4447)
Restrictions for L2VPN Multisegment Pseudowires

• Only Mutliprotocol (MPLS) Layer 2 pseudowires are supported.
• Only manual configuration of the pseudowires (including S-PE and T-PE routers) is supported.
• The L2VPN Pseudowire Switching feature is supported for pseudowires advertised with FEC 128.
FEC 129 is not supported.
• The S-PE router is limited to 1600 pseudowires.
Information About L2VPN Multisegment Pseudowires

Before configuring the L2VPN Multisegment Pseudowires feature, you should understand the following
concepts:
• L2VPN Pseudowire Defined, page 2
• L2VPN Multisegment Pseudowire Defined, page 3
L2VPN Pseudowire Defined

An L2VPN pseudowire (PW) is a tunnel established between two provider edge (PE) routers across the
core carrying the Layer 2 payload encapsulated as MPLS data, as shown in Figure 1. This helps carriers
migrate from traditional Layer 2 networks such as Frame Relay and ATM to an MPLS core. In the
L2VPN pseudowire shown in Figure 1, the PWs between two PE routers are located within the same
autonomous system. Routers PE1 and PE2 are called terminating PE routers (T-PEs). Attachment
circuits are bounded to the PW on these PE routers.
2
Information About L2VPN Multisegment Pseudowires
Figure 1 An L2VPN Pseudowire

PW
CE1 CE1
PE1 PE2
PE1 PE2
243510
CE2 CE2
L2VPN Multisegment Pseudowire Defined

An L2VPN multisegment pseudowire (MS-PW) is a set of two or more PW segments that function as a
single PW. It is also known as switched PW. MS-PWs span multiple cores or autonomous systems of the
same or different carrier networks. A L2VPN MS-PW can include up to 254 PW segments.
Figure 2 is an example of a Multisegment Pseudowire topology.
Figure 2 A Multisegment Pseudowire
PW segment PW segment PW segment
CE1 CE1
T-PE1 T-PE2
S-PE1 S-PE2
243511
CE2 CE2
The end routers are called terminating PE routers (T-PEs), and the switching routers are called S-PE
routers. The S-PE router terminates the tunnels of the preceding and succeeding PW segments in an
MS-PW. The S-PE router can switch the control and data planes of the preceding and succeeding PW
segments of the MS-PW. An MS-PW is declared to be up when all the single-segment PWs are up. For
more information, see the L2VPN Pseudowire Switching document.
3
How to Configure L2VPN Multisegment Pseudowires

The following sections outline the tasks for creating and maintaining L2VPN Multisegment
Pseudowires:
• Configuring L2VPN Multisegment Pseudowires, page 4 (required)
• Displaying Information About the L2VPN Multisegment Pseudowires, page 6 (optional)
• Performing ping mpls and trace mpls Operations on the L2VPN Multisegment Pseudowires, page 7
(optional)
Configuring L2VPN Multisegment Pseudowires

Perform the following steps on the S-PE routers to create L2VPN Multisegment Pseudowires.
SUMMARY STEPS
1. enable
4. mpls ldp router-id interface force
7. switching tlv
8. exit
9. l2 vfi name point-to-point
10. description string
11. neighbor ip-address vcid {encapsulation mpls | pw-class pw-class-name}
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls label protocol ldp Configures the use of Label Distribution Protocol (LDP) on all
interfaces.
Example:
Router(config)# mpls label protocol
ldp
4

Step 4 mpls ldp router-id interface force Specifies the preferred interface for determining the LDP router ID.
Example:
Router(config)# mpls ldp router-id
loopback0 force
Step 5 pseudowire-class name Establishes a pseudowire class with a name that you specify, and enters
Example:
• For MPLS L2VPNs, the encapsulation type is mpls.
Example:
Router(config-pw-class)#
encapsulation mpls
Step 7 switching tlv (Optional) Enables the advertisement of the switching point
type-length variable (TLV) in the label binding.
Example: • This command is enabled by default.
Router(config-pw-class)# switching
tlv
Step 8 exit Exits pseudowire class configuration mode.
Example:
Router(config-pw-class)# exit
Step 9 l2 vfi name point-to-point Creates a point-to-point Layer 2 virtual forwarding interface (VFI) and
enters VFI configuration mode.
Example:
Router(config)# l2 vfi atomtunnel
point-to-point
Step 10 description string Provides a description of the switching provider edge router for a
multisegment pseudowire.
Example:
Router(config-vfi)# description
segment1
Step 11 neighbor ip-address vcid Sets up an emulated VC.
{encapsulation mpls | pw-class
pw-class-name} • Specify the IP address and the VC ID of the peer router. Also
specify the pseudowire class to use for the emulated VC.
Example: Note Only two neighbor commands are allowed for each l2 vfi
Router(config-vfi)# neighbor 10.0.0.1 point-to-point command.
100 pw-class mpls
5
Displaying Information About the L2VPN Multisegment Pseudowires

The following commands show the status of L2VPN Multisegment Pseudowires.
SUMMARY STEPS

DETAILED STEPS
Step 1 show mpls l2transport binding

Use the show mpls l2transport binding command to display information about the pseudowire
switching point, as shown in bold in the output. (In the following examples PE1 and PE4 are the T-PE
routers.)

Local Label: 17
VCCV: CC Type: CW [1], RA [2], TTL [3]
CV Type: LSPV [2]
Remote Label: 16
VCCV: CC Type: CW [1], RA [2], TTL [3]
CV Type: LSPV [2]
PW Switching Point:
Vcid local IP addr remote IP addr Description
101 10.11.11.11 10.20.20.20 PW Switching Point PE3
100 10.20.20.20 10.11.11.11 PW Switching Point PE2
Step 2 show mpls l2transport vc detail

Use the show mpls l2transport vc detail command to display status of the pseudowire switching point.
In the following example, the output (shown in bold) displays the segment that is the source of the fault
of the multisegment pseudowire:
Local interface: Se3/0/0 up, line protocol up, HDLC up

Destination address: 12.1.1.1, VC ID: 100, VC status: down
Output interface: Se2/0, imposed label stack {23}
Targeted Hello: 10.1.1.4(LDP Id) -> 10.1.1.1, LDP is UP
LDP route watch : enabled
Label/status state machine : established, LruRrd
Last local dataplane status rcvd: No fault
Last local SSS circuit status rcvd: No fault
Last local SSS circuit status sent: DOWN(PW-tx-fault)
Last local LDP TLV status sent: No fault
6
Last remote LDP TLV status rcvd: DOWN(PW-tx-fault)

PW Switching Point:
Fault type Vcid local IP addr remote IP addr Description
PW-tx-fault 101 10.1.1.1 10.1.1.1 S-PE2
Last remote LDP ADJ status rcvd: No fault
VC statistics:
packet drops: receive 0, seq error 0, send 0
Performing ping mpls and trace mpls Operations on the L2VPN Multisegment
Pseudowires
You can use the ping mpls and trace mpls commands to verify that all the segments of the MPLS
multisegment pseudowire are operating.
You can use the ping mpls command to verify connectivity at the following pseudowire points:
• From one end of the pseudowire to the other
• From one of the pseudowires to a specific segment
• The segment between two adjacent S-PE routers
You can use the trace mpls command to verify connectivity at the following pseudowire points:
• From one end of the pseudowire to the other
• From one of the pseudowires to a specific segment
• The segment between two adjacent S-PE routers
• A range of segments
SUMMARY STEPS
1. ping mpls pseudowire destination-address vc-id [segment segment-number]

2. trace mpls pseudowire peer-address vc-id segment segment-number segment-number
DETAILED STEPS
Step 1 ping mpls pseudowire destination-address vc-id [segment segment-number]

Where:
• destination-address is the address of the S-PE router, which is the end of the segment from the
direction of the source.
• vc-id is the VC ID of the segment from the source to the next PE router.
• segment segment-number is optional and specifies the segment you want to ping.
7
The following examples use the topology shown in Figure 2:

• To perform an end-to-end ping operation from T-PE1 to T-PE2, enter the following command:
ping mpls pseudowire <addr-of-S-PE1> <vc-id between T-PE1 and S-PE1>
• To perform a ping operation from T-PE1 to segment 2, enter the following command:
ping mpls pseudowire <addr-of-S-PE1> <vc-id between T-PE1 and S-PE1> segment 2
Step 2 trace mpls pseudowire destination-address vc-id segment segment-number segment-number

Where:
• destination-address is the address of the next S-PE router from the original of the trace.
• vc-id is the VC ID of the segment from which the trace command is issued.
• segment-number indicates the segment upon which the trace operation will act. If you enter two
segment numbers, the traceroute operation will perform a trace on that range of routers.
The following examples use the topology shown in Figure 2:
• To perform a trace operation from T-PE1 to segment 2 of the multisegment pseudowire, enter the
following command:
trace mpls pseudowire <addr-of-S-PE1> <vc-id between T-PE1 and S-PE1> segment 2
This example performs a trace from T-PE1 to S-PE2.
• To perform a trace operation on a range of segments, enter the following command. This example
performs a trace from S-PE2 to T-PE2.
trace mpls pseudowire <addr-of-S-PE1> <vc-id between T-PE1 and S-PE1> segment 2 4
The following command performs a trace operation on S-PE router 10.10.10.9, on segment 1 and then
on segment 2:
router# trace mpls pseudowire 10.10.10.9 220 segment 1


L 1 10.10.9.9 0 ms [Labels: 18 Exp: 0]
router# trace mpls pseudowire 10.10.10.9 220 segment 2

8

L 1 10.10.9.9 4 ms [Labels: 18 Exp: 0]
! 2 10.10.3.3 4 ms [Labels: 16 Exp: 0]

The following sections provide references related to the L2VPN Multisegment Pseudowires feature.
Related Documents
MPLS applications
Layer 2 VPNS • Any Transport over MPLS
• L2VPN Pseudowire Switching
• MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for
VCCV
Standards
Standard Title
RFC 4777 Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)
MIBs
MIB MIBs Link
RFCs
RFC Title
9
Description Link
10
Feature Information for L2VPN Multisegment Pseudowires

Table 1 Feature Information for L2VPN Multisegment Pseudowires

MPLS Support for Multisegment Cisco IOS XE The L2VPN Multisegment Pseudowires feature enables you to
PWs–MPLS OAM/VCCV Release 2.3 configure two or more Layer 2 pseudowire segments that function
as a single pseudowire. The L2VPN Multisegment Pseudowires
feature span multiple cores or autonomous systems of the same or
different carrier networks.
• Information About L2VPN Multisegment Pseudowires,
page 2
• How to Configure L2VPN Multisegment Pseudowires,
page 4
description (l2 vfi), ping mpls, show mpls l2transport binding,
show mpls l2transport vc, switching tlv, trace mpls.
coincidental.
11
12
L2VPN Pseudowire Switching

This feature module explains how to configure L2VPN Pseudowire Switching, which extends layer 2 virtual
private network (L2VPN) pseudowires across an interautonomous system (inter-AS) boundary or across
two separate multiprotocol label switching (MPLS) networks.

which each feature is supported, see the “Feature Information for L2VPN Pseudowire Switching” section on
page 9.
Contents
• Restrictions for L2VPN Pseudowire Switching, page 2
• Information About L2VPN Pseudowire Switching, page 2
• How to Configure L2VPN Pseudowire Switching, page 3
• Configuration Examples for L2VPN Pseudowire Switching, page 6
• Feature Information for L2VPN Pseudowire Switching, page 9
Restrictions for L2VPN Pseudowire Switching
Restrictions for L2VPN Pseudowire Switching

• In Cisco IOS XE Release 2.4, Pseudowire Switching is supported on Ethernet over MPLS
attachment circuits.
• L2VPN Pseudowire Switching is supported with AToM.
• Only static, on-box provisioning is supported.
• Sequencing numbers in AToM packets are not processed by L2VPN Pseudowire Switching. The
feature blindly passes the sequencing data through the xconnect packet paths, a process that is called
transparent sequencing. The endpoint PE-CE connections enforce the sequencing.
• You can ping the adjacent next-hop PE router. End-to-end LSP pings are not supported.
• Do not configure IP or Ethernet interworking on a router where L2VPN Pseudowire Switching is
enabled. Instead, configure interworking on the routers at the edge PEs of the network.
• The control word negotiation results must match. If either segment does not negotiate the control
word, the control word is disabled for both segments.
• AToM Graceful Restart is negotiated independently on each pseudowire segment. If there is a
transient loss of the LDP session between two AToM PE routers, packets continue to flow.
• Per-pseudowire quality of service (QoS) is not supported. Traffic Engineering (TE) tunnel selection
is supported.
• Attachment circuit interworking is not supported.
Information About L2VPN Pseudowire Switching

To configure the L2VPN Pseudowire Switching feature, you should understand the following concepts:
• How L2VPN Pseudowire Switching Works, page 2
• How Packets Are Manipulated at the L2VPN Pseudowire Switching Aggregation Point, page 3
How L2VPN Pseudowire Switching Works

L2VPN Pseudowire Switching allows the user to extend L2VPN pseudowires across an inter-AS
boundary or across two separate MPLS networks, as shown in Figure 1 and Figure 2. L2VPN
Pseudowire Switching connects two or more contiguous pseudowire segments to form an end-to-end
multihop pseudowire. This end-to-end pseudowire functions as a single point-to-point pseudowire.
As shown in Figure 2, L2VPN Pseudowire Switching enables you to keep the IP addresses of the edge
PE routers private across inter-AS boundaries. You can use the IP address of the autonomous system
boundary routers (ASBRs) and treat them as pseudowire aggregation (PE-agg) routers. The ASBRs join
the pseudowires of the two domains.
L2VPN Pseudowire Switching also enables you to keep different administrative or provisioning domains
to manage the end-to-end service. At the boundaries of these networks, PE-agg routers delineate the
management responsibilities.
2
How to Configure L2VPN Pseudowire Switching
Figure 1 L2VPN Pseudowire Switching in an Intra-AS Topology
MPLS PW MPLS PW
CE1 PE1 PE-A gg PE2 CE2

MPLS Pseudowire MPLS Pseudowire
Network Network
127912
End-to-End Layer 2 Service
Figure 2 L2VPN Pseudowire Switching in an Inter-AS Topology
Service Provider ABC Service Provider XYZ

Autonomous System 1 Autonomous System 2
MPLS PW MPLS PW
CE1 PE1 PE-agg1 PE-agg2 PE2 CE2

MPLS Pseudowire MPLS Pseudowire
Network Network
127913
End-to-End Layer 2 Service
How Packets Are Manipulated at the L2VPN Pseudowire Switching

Aggregation Point
Switching AToM packets between two AToM pseudowires is the same as switching any MPLS packet.
The MPLS switching data path switches AToM packets between two AToM pseudowires. The following
list explains exceptions:
• The outgoing virtual circuit (VC) label replaces the incoming VC label in the packet. New Internal
Gateway Protocol (IGP) labels and Layer 2 encapsulation are added.
• The incoming VC label time-to-live (TTL) field is decremented by one and copied to the outgoing
VC label TTL field.
• The incoming VC label EXP value is copied to the outgoing VC label EXP field.
• The outgoing VC label ‘Bottom of Stack’ S bit in the outgoing VC label is set to1.
• AToM control word processing is not performed at the L2VPN Pseudowire Switching aggregation
point. Sequence numbers are not validated. Use the Router Alert label for LSP Ping; do not require
control word inspection to determine an LSP Ping packet.

This section explains how to perform the following tasks:
• Configuring L2VPN Pseudowire Switching, page 4
3
Configuring L2VPN Pseudowire Switching

Use the following procedure to configure L2VPN Pseudowire Switching on each of the PE-agg routers.
Prerequisites
• This procedure assumes that you have configured basic AToM L2VPNs. This procedure does not
explain how to configure basic AToM L2VPNs that transport Layer 2 packets over an MPLS
backbone. For information on the basic configuration, see Any Transport over MPLS.
• For inter-Autonomous configurations, ASBRs require a labeled interface.
Restrictions
In this configuration, you are limited to two neighbor commands after entering the l2 vfi command.
SUMMARY STEPS
1. enable
3. l2 vfi name point-to-point
4. neighbor ip-address vcid encapsulation mpls | pw-class pw-class-name
5. exit
6. exit
7. show mpls l2transport vc [vcid [vc-id | vc-id-min vc-id-max]] [interface name [local-circuit-id]]
[destination ip-address | name] [detail]
8. show vfi [vfi-name]
9. ping [protocol] [tag] {host-name | system-address}
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 l2 vfi name point-to-point Creates a point-to-point Layer 2 virtual forwarding
interface (VFI) and enters VFI configuration mode.
Example:
Router(config)# l2 vfi atomtunnel
point-to-point
4

Step 4 neighbor ip-address vcid encapsulation mpls | Sets up an emulated VC. Specify the IP address and the VC
pw-class pw-class-name ID of the remote router. Also specify the pseudowire class
to use for the emulated VC.
Example: Note Only two neighbor commands are allowed for each
Router(config-vfi)# neighbor 10.0.0.1 100 l2 vfi point-to-point command.
pw-class mpls
Step 5 exit Exits VFI configuration mode.
Example:
Router(config-vfi)# exit
Example:
Step 7s show mpls l2transport vc [vcid [vc-id | Verifies that the L2VPN Pseudowire Switching session has
[vc-id-min vc-id-max]] [interface name been established.
[local-circuit-id]] [destination ip-address |
name] [detail]
Example:
Step 8 show vfi [vfi-name] Verifies that a point-to-point VFI has been established.
Example:
Router# show vfi atomtunnel
Step 9 ping [protocol] [tag] {host-name | When issued from the CE routers, this command verifies
system-address} end-to-end connectivity.
Example:
Router# ping 10.1.1.1
Examples
The following example displays the output of the show mpls l2transport vc command:

------------- -------------------------- --------------- ----- ----
MPLS PW 10.0.1.1:100 10.0.1.1 100 UP
MPLS PW 10.0.1.1:100 10.0.1.1 100 UP
The following example displays the output of the show vfi command:
Router# show vfi
VFI name: test, type: point-to-point

Neighbors connected via pseudowires:
Router ID Pseudowire ID
10.0.1.1 100
10.0.1.1 100
5
Configuration Examples for L2VPN Pseudowire Switching
Configuration Examples for L2VPN Pseudowire Switching

• L2VPN Pseudowire Switching in an Inter-AS Configuration: Example, page 6
L2VPN Pseudowire Switching in an Inter-AS Configuration: Example

Two separate autonomous systems are able to pass L2VPN packets, because the two PE-agg routers have
been configured with L2VPN Pseudowire Switching. This example configuration is shown in Figure 3.
Figure 3 L2VPN Pseudowire Switching in an InterAutonomous System
AS 65016 AS 65017
172.16.255.3 172.17.255.3
172.16.255.2 172.17.255.2
A-P1 172.16.0.4/30 172.17.0.4/30 B-P1
.1 .2 .1 .2 S0/0/0 S0/0/0
S0/0/0 S0/0/0 S1/0/0 S1/0/0 .2 .1
.2 S1/0/0 PE-agg1 PE-agg2
PE-agg2 S1/0/0 .2
172.16.0.0/30 192.168.0.0/30 172.17.0.0/30
172.16.255.1 172.17.255.1
.1 S1/0/0 S1/0/0 .1
PE1 PE2
Fe0/0/0 Fe0/0/0
Fe0/0/0 .1 .2 Fe0/0/0
274871
CE1 10.0.0.0/30 10.0.0.0/30 CE2
6
CE1 CE2
version 12.0 version 12.0
service timestamps debug uptime service timestamps debug uptime
service timestamps log uptime service timestamps log uptime
service password-encryption service password-encryption
! !
hostname [ce1] hostname [ce2]
! !
boot-start-marker boot-start-marker
boot-end-marker boot-end-marker
! !
enable secret 5 $1$o9N6$LSrxHufTn0vjCY0nW8hQX. enable secret 5 $1$YHo6$LQ4z5PdrF5B9dnL75Xvvm1
! !
ip subnet-zero ip subnet-zero
ip cef ip cef
no ip domain-lookup no ip domain-lookup
! !
interface FastEthernet0/0/0 interface FastEthernet0/0/0
! !
ip classless ip classless
! !
control-plane control-plane
! !
line con 0 line con 0
exec-timeout 0 0 exec-timeout 0 0
line aux 0 line aux 0
line vty 0 4 line vty 0 4
login login
! !
no cns aaa enable no cns aaa enable
end end
The following sections provide references related to L2VPN Pseudowire Switching.
Related Documents
MPLS applications
Pseudowire redundancy L2VPN Pseudowire Redundancy
High availability for AToM AToM Graceful Restart
L2VPN interworking L2VPN Interworking
Layer 2 local switching Layer 2 Local Switching
7

PWE3 MIB Pseudowire Emulation Edge-to-Edge MIBs for Ethernet and Frame
Relay Services
Packet sequencing Any Transport over MPLS (AToM) Sequencing Support
Standards
Standard Title
draft-ietf-pwe3-control-protocol-14.txt Pseudowire Setup and Maintenance using LDP
draft-martini-pwe3-pw-switching-01.txt Pseudo Wire Switching
MIBs
MIB MIBs Link
• CISCO-IETF-PW-MIB To locate and download MIBs for selected platforms, Cisco IOS XE
• CISCO-IETF-PW-MPLS-MIB
the following URL:
• CISCO-IETF-PW-ENET-MIB
• CISCO-IETF-PW-FR-MIB
RFCs
RFCs Title
Description Link
8
Feature Information for L2VPN Pseudowire Switching

Table 1 Feature Information for L2VPN Pseudowire Switching

L2VPN Pseudowire Switching Cisco IOS XE The L2VPN Pseudowire Switching feature extends layer 2 virtual
Release 2.4 private network (L2VPN) pseudowires across an
interautonomous system (inter-AS) boundary or across two
separate multiprotocol label switching (MPLS) networks.
In Cisco IOS XE Release 2.4, The L2VPN Pseudowire Switching
feature is supported with Ethernet over MPLS.
• Information About L2VPN Pseudowire Switching, page 2
• How to Configure L2VPN Pseudowire Switching, page 3
The following commands were introduced or modified: l2 vfi
point-to-point, neighbor (L2VPN Pseudowire Switching),
show vfi.
coincidental.
9
10
QoS Policy Support on L2VPN ATM PVPs

This feature enables you to configure Quality of Service (QoS) service policies in ATM permanent
virtual path (PVP) mode for Layer 2 Virtual Private Networks (L2VPNs).

which each feature is supported, see the “Feature Information for QoS Policy Support on L2VPN ATM
PVPs” section on page 10.
Contents
• Prerequisites for QoS Policy Support on L2VPN ATM PVPs, page 2
• Restrictions for QoS Policy Support on L2VPN ATM PVPs, page 2
• Information About QoS Policy Support on L2VPN ATM PVPs, page 2
• How to Configure QoS Policy Support on L2VPN ATM PVPs, page 3
• Configuration Examples for QoS Policy Support on L2VPN ATM PVPs, page 7
• Feature Information for QoS Policy Support on L2VPN ATM PVPs, page 10
Prerequisites for QoS Policy Support on L2VPN ATM PVPs
Prerequisites for QoS Policy Support on L2VPN ATM PVPs

Before configuring QoS policies on L2VPN ATM PVPs, you should understand the concepts and
configuration instructions in the following documents:
• Any Transport over MPLS
• Applying QoS Features Using the MQC
Restrictions for QoS Policy Support on L2VPN ATM PVPs

The following restrictions apply to the QoS Policy Support on L2VPN ATM PVPs feature:
• Queueing-based policies are not supported in ATM PVP mode and virtual circuit (VC) mode at the
same time under the same main interface. However, nonqueueing policies can be mixed. For
example, you can configure a nonqueueing policy in PVP mode and configure queueing policies on
in VC mode under the same main interface. Similarly, you can configure a queueing policy in PVP
mode and configure nonqueueing policies in VC mode in the input or output direction.
• ATM PVP mode does not support sessions.
• When you enable a policy in PVP mode, do not configure ATM rates on the VCs that are part of the
PVP. The VCs should be unspecified bit rate (UBR) VCs only.
• If VCs are part of a PVP that has a policy configured, you cannot configure ATM VC traffic shaping.
• You cannot configure a queueing policy on an ATM PVP with UBR.
• You cannot configure queueing-based policies with UBR traffic shaping.
Information About QoS Policy Support on L2VPN ATM PVPs

Before configuring the QoS Policy Support on L2VPN ATM PVPs feature, you should understand the
following concepts:
• The MQC Structure, page 2
• Elements of a Traffic Class, page 3
• Elements of a Traffic Policy, page 3
The MQC Structure

The MQC structure allows you to define a traffic class, create a traffic policy, and attach the traffic policy
to an interface.
The MQC structure consists of the following three high-level steps.
Step 1 Define a traffic class by using the class-map command. A traffic class is used to classify traffic.
Step 2 Create a traffic policy by using the policy-map command. (The terms traffic policy and policy map are
often synonymous.) A traffic policy (policy map) contains a traffic class and one or more QoS features
that will be applied to the traffic class. The QoS features in the traffic policy determine how to treat the
classified traffic.
Step 3 Attach the traffic policy (policy map) to the interface by using the service-policy command.
2
How to Configure QoS Policy Support on L2VPN ATM PVPs
Elements of a Traffic Class

A traffic class contains three major elements: a traffic class name, a series of match commands, and, if
more than one match command is used in the traffic class, instructions on how to evaluate these match
commands.
The match commands are used for classifying packets. Packets are checked to determine whether they
meet the criteria specified in the match commands; if a packet meets the specified criteria, that packet is
considered a member of the class. Packets that fail to meet the matching criteria are classified as
members of the default traffic class.
Elements of a Traffic Policy

A traffic policy contains three elements: a traffic policy name, a traffic class (specified with the class
command), and the command used to enable the QoS feature.
The traffic policy (policy map) applies the enabled QoS feature to the traffic class once you attach the
policy map to the interface (by using the service-policy command).
Note A packet can match only one traffic class within a traffic policy. If a packet matches more than one traffic
class in the traffic policy, the first traffic class defined in the policy will be used.

The following sections explain how to configure QOS operations in ATM PVP mode.
• Enabling a Service Policy in ATM PVP Mode, page 3 (required)
• Enabling Traffic Shaping in ATM PVP Mode, page 4 (required)
• Enabling Matching of ATM VCIs, page 6 (required)
Enabling a Service Policy in ATM PVP Mode

You can enable a service policy in ATM PVP mode. You can also enable a service policy on PVP on a
multipoint subinterface.
Restrictions
The show policy-map interface command does not display service policy information for ATM
interfaces.
SUMMARY STEPS
1. enable
3
5. service-policy [input | output] policy-map-name

7. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
enters l2transport PVP configuration mode.
Example: • The l2transport keyword indicates that the PVP is for cell
Router(config-if)# atm pvp 1 l2transport relay. This mode is for Layer 2 transport only; it is not for
regular PVPs.
Step 5 service-policy [input | output] Enables a service policy on the specified PVP.
policy-map-name
Example:
service policy input pol1
Step 6 xconnect peer-router-id vcid Binds the attachment circuit to a pseudowire VC.
encapsulation mpls
• The syntax for this command is the same as for all other Layer
2 transports.
Example:
Step 7 end Exits l2transport PVP configuration mode and returns to
Example:
Router(config-if-atm-l2trans-pvp)# end
Enabling Traffic Shaping in ATM PVP Mode

Traffic shaping commands are supported in PVP mode. For egress VP shaping, one configuration
command is supported for each ATM service category. The supported service categories are constant bit
rate (CBR), UBR, variable bit rate-nonreal time (VBR-NRT), and variable bit rate real-time(VBR-RT).
4
SUMMARY STEPS
1. enable
5. ubr pcr
or
cbr pcr
or
vbr-nrt pcr scr mbs
or
vbr-rt pcr scr mbs
DETAILED STEPS

Example:
Router> enable
Example:
Example:
enters l2transport PVP configuration mode.
Example: • The l2transport keyword indicates that the PVP is for cell
Router(config-if)# atm pvp 1 l2transport relay. This mode is for Layer 2 transport only; it is not for
regular PVPs.
5

Step 5 ubr pcr Enables traffic shaping in ATM PVP mode.
or
cbr pcr • pcr = peak cell rate
or
vbr-nrt pcr scr mbs
• scr = sustain cell rate
or • mbs = maximum burst size
vbr-rt pcr scr mbs
Example:
Router(config-if-atm-l2trans-pvp)# cbr
1000
Step 6 xconnect peer-router-id vcid Binds the attachment circuit to a pseudowire VC.
encapsulation mpls
• The syntax for this command is the same as for all other Layer
2 transports.
Example:
Enabling Matching of ATM VCIs

You can match on an ATM VCI or range of VCIs, using the match atm-vci command in class-map
configuration mode.
Restrictions
When you configure the match atm-vci command in class-map configuration mode, you can add this
class map to a policy map that can be attached only to an ATM VP.
SUMMARY STEPS
1. enable
3. class-map class-map-name [match-all | match-any]
4. match atm-vci vc-id [- vc-id]
5. end
DETAILED STEPS

Example:
Router> enable
Example:
6
Configuration Examples for QoS Policy Support on L2VPN ATM PVPs

Step 3 class-map class-map-name [match-all | Creates a class map to be used for matching traffic to a specified
match-any] class, and enters class-map configuration mode.
Example:
Router(config)# class-map class1
Step 4 match atm-vci vc-id [- vc-id] Enables packet matching on an ATM VCI or range of VCIs. The
range is 32 to 65535.
Example: Note You can use the match not command to remove the match
Router(config-cmap)# match atm-vci 50 criteria.
Step 5 end (Optional) Returns to privileged EXEC mode.
Example:
Router(config-cmap)# end
Configuration Examples for QoS Policy Support on L2VPN ATM

PVPs
The following section shows an example of the QoS Policy Support on L2VPN ATM PVPs feature:
• Enabling Traffic Shaping in ATM PVP Mode: Example, page 7
Enabling Traffic Shaping in ATM PVP Mode: Example

The following example enables traffic shaping in ATM PMP mode.
int atm 1/0/0
ubr 1000
cbr 1000
vbr-nrt 1200 800 128
7
The following sections provide references related to the QoS Policy Support on L2VPN ATM PVPs
feature.
Related Documents
MPLS applications
Modular Quality of Service (QoS) Command-Line Applying QoS Features Using the MQC
Interface (CLI) (MQC)
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
8
Description Link
9
Feature Information for QoS Policy Support on L2VPN ATM PVPs

Table 1 Feature Information for QoS Policy Support on L2VPN ATM PVPs

QoS Policy Support on L2VPN ATM PVPs Cisco IOS XE This feature enables you to configure Quality of Service
Release 2.3 (QoS) service policies in ATM permanent virtual path
(PVP) mode for Layer 2 Virtual Private Networks
(L2VPNs).
feature:
• Information About QoS Policy Support on L2VPN
ATM PVPs, page 2
• How to Configure QoS Policy Support on L2VPN ATM
PVPs, page 3
The following commands were introduced or modified: cbr,
match atm-vci, service-policy, ubr, vbr-nrt, vbr-rt.
Cell-Based ATM Shaping per PVP Cisco IOS XE This feature was introduced for Cisco ASR 1000 Series
Release 2.3 Aggregation Services Routers.
feature:
• Information About QoS Policy Support on L2VPN
ATM PVPs, page 2
• How to Configure QoS Policy Support on L2VPN ATM
PVPs, page 3
• Enabling Traffic Shaping in ATM PVP Mode, page 4
10
coincidental.
11
12
MPLS Pseudowire Status Signaling

The MPLS Pseudowire Status Signaling feature enables you to configure the router so it can send
pseudowire status to a peer router, even when the attachment circuit is down.

which each feature is supported, see the “Feature Information for MPLS Pseudowire Status Signaling”
section on page 9.
Contents
• Prerequisites for MPLS Pseudowire Status Signaling, page 2
• Restrictions for MPLS Pseudowire Status Signaling, page 2
• Information About MPLS Pseudowire Status Signaling, page 2
• How to Configure MPLS Pseudowire Status Signaling, page 4
• Configuration Examples for MPLS Pseudowire Status Signaling, page 6
• Feature Information for MPLS Pseudowire Status Signaling, page 9
Prerequisites for MPLS Pseudowire Status Signaling
Prerequisites for MPLS Pseudowire Status Signaling

• Before configuring this feature, make sure that both peer routers are capable of sending and
receiving pseudowire status messages.
Restrictions for MPLS Pseudowire Status Signaling

• Both peer routers must support the ability to send and receive pseudowire status messages in label
advertisement and label notification messages. If both peer routers do not support pseudowire status
messages, Cisco recommends that you disable the messages with the no status command.
• This feature is not integrated with Any Transport over MPLS (AToM) Virtual Circuit Connection
Verification (VCCV).
• This feature is not integrated with Bidirectional Forwarding Detection (BFD).
• The standby and required switchover values from IETF draft-muley-pwe3-redundancy-02.txt are not
supported.
Information About MPLS Pseudowire Status Signaling

Before configuring MPLS Pseudowire Status Signaling, you should understand the following concepts:
• How MPLS Pseudowire Status Signaling Works
How MPLS Pseudowire Status Signaling Works

The pseudowire status messages are sent in label advertisement and label notification messages if the
peer also supports the MPLS Pseudowire Status Signaling feature. You can issue the show mpls
l2transport vc detail command to show that both the local and remote routers support pseudowire status
messages. The following example shows the line of output to look for:
.
.
.
status TLV support (local/remote): enabled/supported
When One Router Does Not Support MPLS Pseudowire Status Signaling
The peer routers must support the ability to send and receive pseudowire status messages in label
advertisement and label notification messages. If one router does not support pseudowire status
messages, Cisco recommends that you disable the messages with the no status command. This returns
the router to label withdraw mode.
2
Information About MPLS Pseudowire Status Signaling
If the peer does not support the MPLS Pseudowire Status Signaling feature, the local router changes its
mode of operation to label withdraw mode. You can issue the show mpls l2transport vc detail
command to show that the remote router does not support pseudowire status messages. The following
example shows the line of output to look for:
.
.
.
status TLV support (local/remote): enabled/not supported
When you issue the following debug mpls l2transport vc commands, the messages show that the peer
router does not supportthe MPLS Pseudowire Status Signaling feature and that the local router is
changing to withdraw mode, as shown in bold in the following example:
Router# debug mpls l2transport vc event
Router# debug mpls l2transport vc status event
Router# debug mpls l2transport vc status fsm
Router# debug mpls l2transport vc ldp
*Feb 26 13:41:40.707: AToM LDP [10.1.1.2]: Sending label withdraw msg

*Feb 26 13:41:40.707: AToM LDP [10.1.1.2]: VC Type 5, mtu 1500
*Feb 26 13:41:40.707: AToM LDP [10.1.1.2]: VC ID 100, label 18
*Feb 26 13:41:40.707: AToM LDP [10.1.1.2]: Status 0x0000000A [PW Status NOT supported]
Status Messages Indicating That the Attachment Circuit Is Down

When the attachment circuit is down between the two routers, the output of the show mpls l2transport
vc detail command shows the following status:
.
.
.
Last remote LDP TLV status rcvd: AC DOWN(rx,tx faults)
The debug messages also indicate that the attachment circuit is down, as shown in bold in the command
output:
Router# debug mpls l2transport vc event
Router# debug mpls l2transport vc status event
Router# debug mpls l2transport vc status fsm
Router# debug mpls l2transport vc ldp
*Feb 26 11:51:42.427: AToM LDP [10.1.1.1]: Received notif msg, id 88
*Feb 26 11:51:42.427: AToM LDP [10.1.1.1]: Status 0x00000007 [PW Status]
*Feb 26 11:51:42.427: AToM LDP [10.1.1.1]: PW Status 0x00000006 [AC DOWN(rx,tx faults)]
Other pseudowire status messages include not-forwarding, pw-tx-fault, and pw-rx-fault.
Message Codes in the Pseudowire Status Messages

The debug mpls l2transport vc and the show mpls l2transport vc detail commands show output that
contains message codes. For example:
Label/status state machine: established, LruRru
AToM MGR [10.9.9.9, 100]: S:Evt local up, LndRru->LnuRru
3
How to Configure MPLS Pseudowire Status Signaling
The message codes (LruRru, LndRru, and LnuRru) indicate the status of the local and remote routers.
You can use the following key to interpret the message codes:
• L—local router
• R—remote router
• r or n—ready (r) or not ready (n)
• u or d—up (u) or down (d) status
The output also includes other values:
• D—Dataplane
• S—Local shutdown

This section explains how to perform the following tasks:
• Enabling MPLS Pseudowire Status Signaling, page 4 (required)
Enabling MPLS Pseudowire Status Signaling

Perform the following task to enable the router to send pseudowire status to a peer router even when the
attachment circuit is down. If both routers do not support pseudowire status messages, then disable the
messages with the no status command.
SUMMARY STEPS
1. enable
4. status
6. exit
7. exit
4
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class name Establishes a pseudowire class with a name that you specify
and enters pseudowire class configuration mode.
Example:
Step 4 status (Optional) Enables the router to send pseudowire status
messages to the peer router through label advertisement and
label notification messages.
Example:
Router(config-pw)# status Note By default, status messages are enabled. This step is
included only in case status messages have been
disabled.
If you need to disable status messages because both peer

routers do not support this functionality, enter the no status
command.
Example:
Step 6 exit Exits pseudowire class configuration mode.
Example:
Example:
Step 8 show mpls l2transport vc detail Validates that pseudowire messages can be sent and
received.
Example:
5
Configuration Examples for MPLS Pseudowire Status Signaling
Configuration Examples for MPLS Pseudowire Status Signaling

• MPLS Pseudowire Status Signaling: Example
• Verifying That Both Routers Support Pseudowire Status Messages: Example
MPLS Pseudowire Status Signaling: Example

The following example configures the MPLS Pseudowire Status Signaling feature on two PE routers. By
default, status messages are enabled. The status command is included in this example in case status
messages have been disabled.
PE1
interface Loopback0
ip address 10.1.1.1 255.255.255.255
!
pseudowire-class atomstatus
encapsulation mpls
status
!
xconnect 10.1.1.2 123 pw-class atomstatus
PE2
interface Loopback0
ip address 10.1.1.2 255.255.255.255
!
pseudowire-class atomstatus
encapsulation mpls
status
!
xconnect 10.1.1.1 123 pw-class atomstatus
Verifying That Both Routers Support Pseudowire Status Messages: Example

You can issue the show mpls l2transport vc detail command to show that both the local and remote
routers support pseudowire status messages. The following example shows the line of output to look for:
.
.
.
status TLV support (local/remote): enabled/supported
6
The following sections provide references related to the MPLS Pseudowire Status Signaling feature.
Related Documents
MPLS applications
Standards
Standard Title
draft-ietf-pwe3-control-protocol-15.txt Pseudowire Setup and Maintenance Using LDP
draft-ietf-pwe3-iana-allocation-08.txt IANA Allocations for Pseudo Wire Edge to Edge Emulation (PWE3)
draft-martini-pwe3-pw-switching-03.txt Pseudo Wire Switching
MIBs
MIB MIBs Link
Pseudowire Emulation Edge-to-Edge MIBs for To locate and download MIBs for selected platforms, Cisco IOS XE
Ethernet, Frame Relay, and ATM Services software releases, and feature sets, use Cisco MIB Locator found at
the following URL:
RFCs
RFC Title
7
Description Link
8
Feature Information for MPLS Pseudowire Status Signaling

Table 1 Feature Information for MPLS Pseudowire Status Signaling

MPLS Pseudowire Status Signaling Cisco IOS XE The MPLS Pseudowire Status Signaling feature enables you
Release 2.3 to configure the router so it can send pseudowire status to a
peer router, even when the attachment circuit is down.
feature:
• Information About MPLS Pseudowire Status Signaling,
page 2
• How to Configure MPLS Pseudowire Status Signaling,
page 4
debug mpls l2transport vc, show mpls l2transport vc,
status (pseudowire class).
countries.
coincidental.
9
10
IEEE 802.1Q Tunneling (QinQ) for AToM

This feature allows you to configure IEEE 802.1Q Tunneling (QinQ) for AToM. It also permits the
rewriting of QinQ tags for Multiple Protocol Label Switching (MPLS) Layer 2 VPNs (L2VPNs).

which each feature is supported, see the “Feature Information for IEEE 802.1Q Tunneling (QinQ) for
AToM” section on page 11.
Contents
• Prerequisites for IEEE 802.1Q Tunneling (QinQ) for AToM, page 2
• Restrictions for IEEE 802.1Q Tunneling (QinQ) for AToM, page 2
• Information About IEEE 802.1Q Tunneling (QinQ) for AToM, page 2
• How to Configure IEEE 802.1Q Tunneling (QinQ) for AToM, page 4
• Configuration Examples for IEEE 801.2 Tunneling (QinQ) for ATM, page 8
• Feature Information for IEEE 802.1Q Tunneling (QinQ) for AToM, page 11
Prerequisites for IEEE 802.1Q Tunneling (QinQ) for AToM
Prerequisites for IEEE 802.1Q Tunneling (QinQ) for AToM

The QinQ (short for 802.1Q-in-802.1Q) tunneling and tag rewrite feature is supported on the following
line cards:
• 8-port Fast Ethernet line card (ESR-HH-8FE-TX)
• 2-port half-height Gigabit Ethernet line card (ESR-HH-1GE)
• 1-port full-height Gigabit Ethernet line card (ESR-1GE)
Restrictions for IEEE 802.1Q Tunneling (QinQ) for AToM

The IEEE 802.1Q Tunneling (QinQ) for AToM feature has the following restrictions:
• Up to a maximum of 447 outer-VLAN IDs and up to 4095 inner VLAN IDs can be supported by this
feature.
• Only Unambiguous VLAN tagged Ethernet QinQ interfaces are supported in this release. That is,
the Ethernet VLAN QinQ rewrite of both VLAN Tags capability is supported only on Ethernet
subinterfaces with a QinQ encapsulation and explicit pair of VLAN IDs defined.
Note Ambiguous inner VLAN IDs are not supported in this release.
Information About IEEE 802.1Q Tunneling (QinQ) for AToM

To configure the IEEE 802.1Q Tunneling (QinQ) for AToM feature, you should understand the following
concepts:
• Ethernet VLAN QinQ AToM, page 2
• QinQ Tunneling Based on Inner and Outer VLAN Tags, page 3
• Rewritten Inner and Outer VLAN Tags on QinQ Frames, page 4
Ethernet VLAN QinQ AToM

In Metro Ethernet deployment, in which CE routers and PE routers are connected through an Ethernet
switched access network, packets that arrive at PE routers can contain up to two IEEE 802.1q VLAN
tags (one inner VLAN tag which identifies the customer; and another outer VLAN tag which denotes the
customer's service provider). This technique of allowing multiple VLAN tagging on the same Ethernet
packet and creating a stack of VLAN IDs is known as QinQ (short for 802.1Q-in-802.1Q). Figure 1
shows how different edge devices can do L2 switching on the different levels of the VLAN stack.
2
Information About IEEE 802.1Q Tunneling (QinQ) for AToM
Figure 1 Ethernet VLAN QinQ
Stacked ETH
VLAN VLA Port MPLS
PE1 PW PE
192860
Inner vlan Outer vlan or
or Customer- Service Provider-
vlan-id vlan-id
When the outer VLAN tag is the service-delimiting VLAN tag, QinQ packets are processed similar to
the ones with one VLAN tag (case previously named Ethernet VLAN Q-in-Q modified, which is already
supported in the 12.2(31) SB release). However, when a customer must use a combination of the outer
and inner VLAN tags to delimit service for customers, the edge device should be able to choose a unique
pseudowire based on a combination of the inner and outer VLAN IDs on the packet shown in Figure 2.
The customer may want to be able to rewrite both the inner and the outer VLAN IDs on the traffic egress
side.
Figure 2 Ethernet VLAN QinQ Header
802.1Q 802.1Q
Type/ Type/
Tag Tag
Length= Length= Type/
Dest MAC SRC MAC Control Control
802.1Q Tag 802.1Q Tag Length Data
(6 Bytes) (6 Bytes) Info Info
Type Type (2 Bytes)
192862
(2 Bytes) (2 Bytes)
(2 Bytes) (2 Bytes)
The IEEE 802.1Q Tunneling (QinQ) for AToM can be further explained as follows:
• QinQ Tunneling Based on Inner and Outer VLAN Tags, page 3
• Rewritten Inner and Outer VLAN Tags on QinQ Frames, page 4
QinQ Tunneling Based on Inner and Outer VLAN Tags

When handling incoming QinQ Ethernet traffic, the edge router allows a customer to choose a unique
pseudowire endpoint to switch the traffic based on the combination of inner and outer VLAN IDs. For
example, Figure 3 shows how a unique pseudowire is selected depending upon the combination of inner
(customer edge) and outer (service provider) VLAN IDs. Thus, traffic for different customers can be kept
separate.
3
How to Configure IEEE 802.1Q Tunneling (QinQ) for AToM
Figure 3 QinQ Connection
PE1 PE2
Outer
vlan id MPLS
PW
Pwire1
Pwire2 Pwire3
Pwire4
192861
Cust Service
Provider
Rewritten Inner and Outer VLAN Tags on QinQ Frames

When managing incoming AToM Ethernet QinQ traffic, the edge router does the following tasks:
1. Strips off the MPLS labels.
2. Allows the customer to rewrite both the inner and outer VLAN IDs before sending the packets to the
egress QinQ interface. Note this capability is provided only for AToM like-to-like Ethernet QinQ
traffic.
The QinQ AToM feature is a like-to-like interworking case over AToM. This feature requires changes to
the microcode to allow it to overwrite two layers of VLAN tags on Ethernet QinQ traffic, transported
across AToM pseudowires.
• On the ingress side—The packets preserve their L2 header with the two VLAN tags, and it is sent
across the pseudowire with VC type of 4.
• On the egress side—The MPLS label is stripped, and up to two levels of VLAN tags are rewritten
per the configuration.
Only Unambiguous VLAN tagged Ethernet QinQ interfaces are supported in this release. The Ethernet
VLAN Q-in-Q rewrite of both VLAN Tags capability is supported only on Ethernet subinterfaces with
a QinQ encapsulation and explicit pair of VLAN IDs defined.

This section explains how to configure IEEE 802.1Q Tunneling (QinQ) for AToM and includes the
following procedures. While all of the procedures are listed as optional, you must choose one of the first
two listed.
• Configuring Unambiguous IEEE 802.1Q Tunneling (QinQ) for AToM, page 5 (optional)
• Configuring Ambiguous IEEE 802.1Q Tunneling (QinQ) for AToM, page 6 (optional)
• Verifying the IEEE 802.1Q Tunneling (QinQ) for ATM Configuration, page 7 (optional)
4
Configuring Unambiguous IEEE 802.1Q Tunneling (QinQ) for AToM

To configure unambiguous IEEE 802.1Q tunneling (QinQ) for AToM, complete the following steps:
SUMMARY STEPS
1. enable
4. encapsulation dot1q vlan-id second-dot1q {any | vlan-id[,vlan-id[-vlan-id]]}
DETAILED STEPS

Example:
Router> enable
Example:
slot/subslot/port.[subinterface] configuration mode.
Example:
GigabitEthernet1/0/0.100
Step 4 encapsulation dot1q vlan-id Defines the matching criteria to map Q-in-Q ingress frames on an
second-dot1q {any | interface to the appropriate service instance.
vlan-id[,vlan-id[-vlan-id]]}
Example:
dot1q 100 second-dot1q 200
encapsulation mpls
Example:
410 encapsulation mpls
5
Configuring Ambiguous IEEE 802.1Q Tunneling (QinQ) for AToM

To configure ambiguous IEEE 802.1Q tunneling (QinQ) for AToM, complete the following steps:
SUMMARY STEPS
1. enable
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface gigabitethernet Specifies the Gigabit Ethernet subinterface and enters interface
Example:
Example:
dot1q 200 second-dot1q
1000-2000,3000,3500-4000
encapsulation mpls
Example:
6

Example:
Step 7 interface gigabitethernet Specifies the next Gigabit Ethernet interface and enters interface
Example:
Example:
dot1q 201 second-dot1q any
encapsulation mpls
Example:
Verifying the IEEE 802.1Q Tunneling (QinQ) for ATM Configuration

To verify the IEEE 802.1Q tunneling (QinQ) for AToM, complete the following steps.
SUMMARY STEPS
1. enable
DETAILED STEPS

Example:
Router> enable
Step 2 show mpls l2transport vc Displays information about Any Transport over MPLS (AToM) virtual
circuits (VCs) and static pseudowires that have been enabled to route
Layer 2 packets on a router.
Example:
7
Configuration Examples for IEEE 801.2 Tunneling (QinQ) for ATM
Configuration Examples for IEEE 801.2 Tunneling (QinQ) for ATM

• Configuring Unambiguous IEEE 802.1Q Tunneling (QinQ) for ATM: Example, page 8
• Configuring Ambiguous IEEE 802.1Q Tunneling (QinQ) for ATM: Example, page 8
• Verifying the IEEE 802.1Q Tunneling (QinQ) for ATM: Configuration: Example, page 8
Configuring Unambiguous IEEE 802.1Q Tunneling (QinQ) for ATM: Example

The following is an example of an unambiguous IEEE 802.1Q Tunneling (QinQ) for ATM configuration.
Router> enable
Router(config)# interface GigabitEthernet1/0/0.100
Router(config-if)# encapsulation dot1q 100 second-dot1q 200
Router(config-if)# xconnect 10.0.0.16 410 encapsulation mpls
Configuring Ambiguous IEEE 802.1Q Tunneling (QinQ) for ATM: Example

The following is an example of an ambiguous IEEE 802.1Q Tunneling (QinQ) for ATM configuration.
Router> enable
Router(config-if)# encapsulation dot1q 200 second-dot1q 1000-2000,3000,3500-4000
Router(config-if)# xconnect 10.0.0.16 420 encapsulation mpls
Router(config-if) encapsulation dot1q 201 second-dot1q any
Router(config-if) xconnect 10.0.0.16 430 encapsulation mpls
Verifying the IEEE 802.1Q Tunneling (QinQ) for ATM: Configuration: Example
The following is sample output of the show mpls l2transport vc command, which is used to verify the
VC set up in EoMPLS QinQ mode.
router# show mpls l2transport vc

------------- -------------------------- --------------- ---------- ----------
Gi1/0/0.1 Eth VLAN:100/200 10.1.1.2 1 UP
The following sections provide references related to the IEEE 802.1Q Tunneling (QinQ) for ATM
feature.
8
Related Documents
MPLS applications
AToM and MPLS Any Transport over MPLS
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title
9
Description Link
10
Feature Information for IEEE 802.1Q Tunneling (QinQ) for AToM

Table 1 Feature Information for IEEE 802.1Q Tunneling (QinQ) for AToM

IEEE 802.1Q Tunneling Cisco IOS XE This feature allows you to configure IEEE 802.1Q Tunneling (QinQ) for
(QinQ) for AToM Release 2.4 AToM. It also permits the rewriting of QinQ tags for Multiple Protocol Label
Switching (MPLS) layer 2 VPNs (L2VPNs).
• Information About IEEE 802.1Q Tunneling (QinQ) for AToM, page 2
• How to Configure IEEE 802.1Q Tunneling (QinQ) for AToM, page 4
The following commands were introduced or modified: interface,
encapsulation dot1q second-dot1q, xconnect.
countries.
coincidental.
11
12
NSF/SSO—Any Transport over MPLS and AToM
Graceful Restart

The NSF/SSO—Any Transport over MPLS and AToM Graceful Restart feature allows Any Transport
over MPLS (AToM) to use Cisco nonstop forwarding (NSF), stateful switchover (SSO), and Graceful
Restart (GR) to allow a Route Processor (RP) to recover from a disruption in control plane service
without losing its Multiprotocol Label Switching (MPLS) forwarding state.
NSF with SSO is effective at increasing availability of network services. Cisco NSF with SSO provides
continuous packet forwarding, even during a network processor hardware or software failure. In a
redundant system, the secondary processor recovers control plane service during a critical failure in the
primary processor. SSO synchronizes the network state information between the primary and the
secondary processor.
Note In this document, the NSF/SSO—Any Transport over MPLS and AToM Graceful Restart feature is
referred to as AToM NSF for brevity.
In Cisco IOS XE software, AToM NSF supports the following attachment circuits:
• ATM
• Ethernet to Ethernet VLAN interworking

which each feature is supported, see the “Feature Information for AToM NSF” section on page 9.
NSF/SSO—Any Transport over MPLS and AToM Graceful Restart
Contents
Contents
• Prerequisites for AToM NSF, page 2
• Restrictions for AToM NSF, page 2
• Information About AToM NSF, page 3
• How to Configure AToM NSF, page 4
• Configuration Examples for AToM NSF, page 6
• Feature Information for AToM NSF
Prerequisites for AToM NSF

Before you can configure AToM NSF, make sure the following tasks have been completed:
• AToM virtual circuits (VCs) have been configured on the router. See the Any Transport over MPLS
for information on configuring AToM. For configuring L2VPN Interworking, see the L2VPN
Interworking feature module.
• SSO has been configured on the RPs. See the Stateful Switchover feature module for configuration
information.
• Nonstop forwarding has been configured on the routers. You must enable nonstop forwarding on the
routing protocols running between the P routers, PE routers, and CE routers. The routing protocols
are the following:
– Open Shortest Path First (OSPF),
– Intermediate System-to-Intermediate System (IS-IS), and
– Border Gateway Protocol (BGP).
See the Cisco Nonstop Forwarding feature module for configuration information.
• AToM NSF requires that neighbor networking devices be able to perform AToM GR.
Restrictions for AToM NSF

AToM NSF includes the following restrictions:
• AToM NSF cannot be configured on label-controlled ATM (LC-ATM) interfaces.
• AToM NSF supports AToM Layer 2 Virtual Private Network (L2VPN) Interworking. However,
Layer 2 Tunnel Protocol Version 3 (L2TPv3) Interworking is not supported.
• AToM NSF interoperates with Layer 2 local switching. However, AToM NSF has no effect on
interfaces configured for local switching.
• To allow distributed Cisco Express Forwarding to work on the interfaces, disable fair queueing on
serial interfaces.
2
Information About AToM NSF
Information About AToM NSF

To configure AToM NSF, you should understand the following concepts:
• How AToM NSF Works, page 3
• AToM Information Checkpointing, page 3
• NSF/SSO Support for Ethernet to Ethernet VLAN Interworking, page 4
• ISSU Support for AToM NSF, page 4
How AToM NSF Works

AToM NSF improves the availability of a service provider’s network that uses AToM to provide Layer 2
VPN services to its customers. HA provides the ability to detect failures and handle them with minimal
disruption to the service being provided. AToM NSF is achieved by SSO and NSF mechanisms. A
standby RP provides control-plane redundancy. The control plane state and data plane provisioning
information for the attachment circuits (ACs) and AToM pseudowires (PWs) are checkpointed to the
standby RP to provide NSF for AToM L2VPNs.
AToM Information Checkpointing

Checkpointing is a function that copies state information from the active RP to the backup RP, thereby
ensuring that the backup RP has the latest information. If the active RP fails, the backup RP can take
over.
For the AToM NSF feature, the checkpointing function copies the active RP’s information bindings to
the backup RP. The active RP sends updates to the backup RP when information is modified.
To display checkpointing data, issue the show acircuit checkpoint command on the active and backup
RPs. The active and backup RPs have identical copies of the information.
Checkpointing Troubleshooting Tips for AToM NSF

To help troubleshoot checkpointing errors, use the following commands:
• Use the debug acircuit checkpoint command to enable checkpointing debug messages for ACs.
• Use the debug mpls l2transport checkpoint command to enable checkpointing debug messages for
AToM.
• Use the show acircuit checkpoint command to display the AC checkpoint information.
• Use the show mpls l2transport checkpoint command to display whether checkpointing is allowed,
how many AToM VCs were bulk-synchronized (on the active RP), and how many AToM VCs have
checkpoint data (on the standby RP).
• Use the show mpls l2transport vc detail command to display details of VC checkpointed
information.
3
How to Configure AToM NSF
NSF/SSO Support for Ethernet to Ethernet VLAN Interworking

The NSF/SS0—Ethernet to Ethernet VLAN Interworking features enables SSO and NSF capabilities for
Ethernet to VLAN attachment circuits. Changes in the learned MAC address for interworking are
reflected on the standby RP so that identical values exist on the active and standby RPs.
ISSU Support for AToM NSF

AToM NSF supports In Service Software Upgrade (ISSU) capability. Virtual Private LAN Services
(VPLS) NSF/SSO and HA with ISSU work together to enable upgrades or downgrades of a
Cisco IOS XE image without control and data plane outages. With ISSU, all message data structures that
are used for checkpointing and exchanges between the active RP and standby RP are versioned.

There is no AToM-specific configuration for AToM NSF. Before you configure AToM NSF, you need to
configure MPLS LDP Graceful Restart. You enable MPLS LDP Graceful Restart to assist a neighboring
router configured with AToM NSF to maintain its forwarding state while the LDP session is disrupted.
See the LDP Graceful Restart document for information about how MPLS LDP Graceful Restart works
and how you can customize it for your network.
MPLS LDP Graceful Restart is enabled globally. When you enable MPLS LDP Graceful Restart, it has
no effect on existing LDP sessions. MPLS LDP Graceful Restart is enabled for new sessions that are
established after the feature has been globally enabled.
This section contains the following task:
• Configuring MPLS LDP Graceful Restart, page 4 (required)
Configuring MPLS LDP Graceful Restart

To configure MPLS LDP Graceful Restart, perform the following task.
SUMMARY STEPS
1. enable
4. mpls ldp graceful-restart
6. mpls ip
8. exit
9. exit
4
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef distributed Enables distributed Cisco Express Forwarding.
Example:
Note In Cisco ASR 1000 Series Aggregation Services
Routers, the distributed keyword is mandatory.
Step 4 mpls ldp graceful-restart Enables the router to protect the LDP bindings and MPLS
forwarding state during a disruption in service.
Example:
Router (config)# mpls ldp graceful-restart
Step 5 interface type Specifies an interface and enters interface configuration
slot/subslot/port[.subinterface-number] mode.
Example:
Step 6 mpls ip Configures MPLS hop-by-hop forwarding for an interface.
Example:
Step 7 mpls label protocol ldp Configures the use of LDP for an interface.
• You can also issue the mpls label protocol ldp
Example: command in global configuration mode, which enables
Router(config-if)# mpls label protocol ldp LDP on all interfaces configured for MPLS.
configuration mode.
Example:
EXEC mode.
Example:
5
Configuration Examples for AToM NSF
Configuration Examples for AToM NSF

• Ethernet to VLAN Interworking with AToM NSF: Example, page 6
Ethernet to VLAN Interworking with AToM NSF: Example

The following example shows how to configure AToM NSF on two PE routers:
PE1 PE2
ip cef distributed ip cef distributed
! !
redundancy redundancy
mode sso mode sso
! !
boot system flash disk2:rsp-pv-mz boot system flash disk2:rsp-pv-mz
!
mpls ldp graceful-restart mpls ldp graceful-restart
mpls ip mpls ip
mpls ldp advertise-labels mpls ldp advertise-labels
! !
pseudowire-class atom-eth pseudowire-class atom-eth
encapsulation mpls encapsulation mpls
interworking ethernet interworking eth
! !
interface Loopback0 interface Loopback0
! !
interface FastEthernet1/1/0 interface FastEthernet0/3/0
xconnect 10.9.9.9 123 encap mpls pw-class atom-eth ip route-cache cef
!
interface POS0/1/0 interface FastEthernet0/3/0.3
ip address 10.1.1.1 255.255.255.0 encapsulation dot1Q 10
mpls ip xconnect 10.8.8.8 123 encap mpls pw-class atom-eth
clock source internal interface POS1/0/0
crc 32 ip address 10.1.1.2 255.255.255.0
! mpls ip
interface Loopback0 mpls label protocol ldp
ip address 10.8.8.8 255.255.255.255 clock source internal
no shutdown crc 32
! !
router ospf 10 interface Loopback0
nsf ip address 10.9.9.9 255.255.255.255
network 10.8.8.8 0.0.0.0 area 0 !
network 10.19.1.1 0.0.0.0 area 0 router ospf 10
nsf
network 10.9.9.9 0.0.0.0 area 0
network 10.1.1.2 0.0.0.0 area 0
6
The following sections provide references related to AToM NSF.
Related Documents
Stateful switchover Stateful Switchover
MPLS Label Distribution Protocol MPLS Label Distribution Protocol (LDP)
L2VPN Interworking configuration L2VPN Interworking
MPLS AToM and LDP commands Cisco IOS Multiprotocol Label Switching Command Reference
High availability commands Cisco IOS High Availability Command Reference
Standards
Standards Title
MIBs
MIBs MIBs Link
MPLS Label Distribution Protocol MIB Version 8 To locate and download MIBs for selected platforms, Cisco IOS XE
Upgrade software releases, and feature sets, use Cisco MIB Locator found at
the following URL:
RFCs
RFCs Title
RFC 3478 Graceful Restart Mechanism for Label Distribution
7
Description Link
8
Feature Information for AToM NSF

Table 1 Feature Information for AToM NSF Any Transport over MPLS and AToM Graceful Restart

NSF/SSO—AToM ATM Attachment Cisco IOS XE This feature provides support for AToM NSF/SSO support
Circuit Release 2.3 for ATM over MPLS (ATMoMPLS), which allows
ATMoMPLS to use Cisco nonstop forwarding (NSF),
stateful switchover (SSO), and Graceful Restart (GR) to
allow a Route Processor (RP) to recover from a disruption
in control plane service without losing its Multiprotocol
Label Switching (MPLS) forwarding state.
Routers.
feature:
• Configuring MPLS LDP Graceful Restart, page 4
debug acircuit checkpoint, debug mpls l2transport
checkpoint, show acircuit checkpoint, show mpls
l2transport checkpoint, show mpls l2transport vc.
9
Table 1 Feature Information for AToM NSF Any Transport over MPLS and AToM Graceful Restart

ISSU—AToM ATM Attachment Circuit Cisco IOS XE This feature supports In Service Software Upgrade (ISSU)
Release 2.3 capability. Virtual Private LAN Services (VPLS) NSF/SSO
and HA with ISSU work together to enable upgrades or
downgrades of a Cisco IOS XE image without control and
data plane outages. With ISSU, all message data structures
that are used for checkpointing and exchanges between the
active RP and standby RP are versioned.
Routers.
feature:
• ISSU Support for AToM NSF, page 4
No commands were introduced or modified for this feature.
NSF/SSO—Ethernet to Ethernet VLAN Cisco IOS XE The NSF/SS0—Ethernet to Ethernet VLAN Interworking
Interworking Release 2.4 features enables stateful switchover (SSO) and nonstop
forwarding (NSF) capabilities for Ethernet to VLAN
attachment circuits. Changes in the learned MAC address
for interworking are reflected on the standby RP so that
identical values exist on the Active and Standby RPs.
the Cisco ASR 1000 Series Aggregation Routers.
feature:
• NSF/SSO Support for Ethernet to Ethernet VLAN
Interworking, page 4
• Ethernet to VLAN Interworking with AToM NSF:
Example, page 6
countries.
10
11
12
MPLS Layer 3 VPNs
Configuring MPLS Layer 3 VPNs
First Published: May 2, 2005

A Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) consists of a set of sites that
are interconnected by means of an MPLS provider core network. At each customer site, one or more
customer edge (CE) routers attach to one or more provider edge (PE) routers. This module explains how
to create an MPLS VPN.

which each feature is supported, see the “Feature Information for MPLS Layer 3 VPNs” section on page 36.
Contents
• Prerequisites for MPLS Layer 3 VPNs, page 2
• Restrictions for MPLS Layer 3 VPNs, page 2
• Information About MPLS Layer 3 VPNs
• How to Configure MPLS Layer 3 VPNs
• Configuration Examples for MPLS VPNs, page 28
• Feature Information for MPLS Layer 3 VPNs, page 36
Prerequisites for MPLS Layer 3 VPNs
Prerequisites for MPLS Layer 3 VPNs

Before configuring MPLS Layer 3 VPNs, you should have MPLS, Label Distribution Protocol (LDP),
and Cisco Express Forwarding installed in your network. All routers in the core, including the PE
routers, must be able to support Cisco Express Forwarding and MPLS forwarding. See the “Assessing
the Needs of MPLS VPN Customers” section on page 9 for more information.
Restrictions for MPLS Layer 3 VPNs

When configuring static routes in an MPLS or MPLS VPN environment, some variations of the ip route
and ip route vrf commands are not supported. These variations of the commands are not supported in
Cisco IOS XE releases that support the Tag Forwarding Information Base (TFIB). The TFIB cannot
resolve prefixes when the recursive route over which the prefixes travel disappears and then reappears.
However, the command variations are supported in Cisco IOS XE releases that support the MPLS
Forwarding Infrastructure (MFI). Use the following guidelines when configuring static routes.
Supported Static Routes in an MPLS Environment

The following ip route command is supported when you configure static routes in MPLS environment:
ip route destination-prefix mask interface next-hop-address
The following ip route commands are supported when you configure static routes in an MPLS
environment and configure load sharing with static nonrecursive routes and a specific outbound
interface:
ip route destination-prefix mask interface1 next-hop1
Unsupported Static Routes in an MPLS Environment that Uses the TFIB

The following ip route command is not supported when you configure static routes in an MPLS
environment:
ip route destination-prefix mask next-hop-address
environment and enable load sharing where the next hop can be reached through two paths:
ip route destination-prefix mask next-hop-address
environment and enable load sharing where the destination can be reached through two next hops:
ip route destination-prefix mask next-hop1
ip route destination-prefix mask next-hop2
Use the interface an next-hop arguments when specifying static routes.
2
Restrictions for MPLS Layer 3 VPNs
Supported Static Routes in an MPLS VPN Environment

The following ip route vrf commands are supported when you configure static routes in a MPLS VPN
environment, and the next hop and interface are in the same VRF:
– ip route vrf vrf-name destination-prefix mask next-hop-address
– ip route vrf vrf-name destination-prefix mask interface next-hop-address
– ip route vrf vrf-name destination-prefix mask interface1 next-hop1
ip route vrf vrf-name destination-prefix mask interface2 next-hop2
The following ip route vrf commands are supported when you configure static routes in a MPLS VPN
environment, and the next hop is in the global table in the MPLS cloud in the global routing table. For
example, these commands are supported when the next hop is pointing to the Internet Gateway.
– ip route vrf vrf-name destination-prefix mask next-hop-address global
– ip route vrf vrf-name destination-prefix mask interface next-hop-address
(This command is supported when the next hop and interface are in the core.)
The following ip route commands are supported when you configure static routes in a MPLS VPN
environment and enable load sharing with static nonrecursive routes and a specific outbound interfaces:
Unsupported Static Routes in an MPLS VPN Environment that Uses the TFIB
The following ip route command is not supported when you configure static routes in a MPLS VPN
environment, the next hop is in the global table in the MPLS cloud within the core, and you enable load
sharing where the next hop can be reached through two paths:
ip route vrf destination-prefix mask next-hop-address global
The following ip route commands are not supported when you configure static routes in a MPLS VPN
environment, the next hop is in the global table in the MPLS cloud within the core, and you enable load
sharing where the destination can be reached through two next hops:
ip route vrf destination-prefix mask next-hop1 global
ip route vrf destination-prefix mask next-hop2 global
The following ip route vrf commands are not supported when you configure static routes in an MPLS
VPN environment, and the next hop and interface are in the same VRF:
ip route vrf vrf-name destination-prefix mask next-hop1
ip route vrf vrf-name destination-prefix mask next-hop2
Supported Static Routes in an MPLS VPN Environment Where the Next Hop Resides in the Global Table on the CE
Router
The following ip route vrf command is supported when you configure static routes in a MPLS VPN
environment, and the next hop is in the global table on the CE side. For example, the following command
is supported when the destination-prefix is the CE router’s loopback address, as in EBGP multihop cases.
ip route vrf vrf-name destination-prefix mask interface next-hop-address
The following ip route commands are supported when you configure static routes in a MPLS VPN
environment, the next hop is in the global table on the CE side, and you enable load sharing with static
non-recursive routes and a specific outbound interfaces:
ip route destination-prefix mask interface1 nexthop1
ip route destination-prefix mask interface2 nexthop2
3
Information About MPLS Layer 3 VPNs

Before configuring MPLS Layer 3 VPNs, you should understand the following concepts:
• MPLS VPN Definition, page 4
• How an MPLS VPN Works, page 5
• Major Components of MPLS VPNs, page 7
• Benefits of an MPLS VPN, page 7
MPLS VPN Definition

Before defining an MPLS VPN, you need to define a VPN in general. A VPN is:
• An IP-based network delivering private network services over a public infrastructure
• A set of sites that are allowed to communicate with each other privately over the Internet or other
public or private networks
Conventional VPNs are created by configuring a full mesh of tunnels or permanent virtual circuits
(PVCs) to all sites in a VPN. This type of VPN is not easy to maintain or expand, because adding a new
site requires changing each edge device in the VPN.
MPLS-based VPNs are created in Layer 3 and are based on the peer model. The peer model enables the
service provider and the customer to exchange Layer 3 routing information. The service provider relays
the data between the customer sites without the customer's involvement.
MPLS VPNs are easier to manage and expand than conventional VPNs. When a new site is added to an
MPLS VPN, only the service provider’s edge router that provides services to the customer site needs to
be updated.
The different parts of the MPLS VPN are described as follows:
• Provider (P) router—Router in the core of the provider network. P routers run MPLS switching, and
do not attach VPN labels (MPLS label in each route assigned by the PE router) to routed packets.
VPN labels are used to direct data packets to the correct egress router.
• PE router—Router that attaches the VPN label to incoming packets based on the interface or
subinterface on which they are received. A PE router attaches directly to a CE router.
• Customer (C) router—Router in the ISP or enterprise network.
• Customer edge router—Edge router on the network of the ISP that connects to the PE router on the
network. A CE router must interface with a PE router.
Figure 1 shows a basic MPLS VPN.
4
Figure 1 Basic MPLS VPN Terminology
MPLS Backbone
Customer Site Customer Site

Provider (P)
routers
Customer Provider Edge Provider Edge Customer

Edge (PE) router (PE) router Edge
(CE) router (CE) router
Provider (P)
routers
103875
How an MPLS VPN Works
MPLS VPN functionality is enabled at the edge of an MPLS network. The PE router performs the
following:
• Exchanges routing updates with the CE router
• Translates the CE routing information into VPNv4 routes
• Exchanges VPNv4 routes with other PE routers through the Multiprotocol Border Gateway Protocol
(MP-BGP)
How Virtual Routing and Forwarding Tables Work in an MPLS VPN

Each VPN is associated with one or more virtual routing and forwarding (VRF) instances. A VRF
defines the VPN membership of a customer site attached to a PE router. A VRF consists of the following
components:
• An IP routing table
• A derived Cisco Express Forwarding table
• A set of interfaces that use the forwarding table
• A set of rules and routing protocol parameters that control the information that is included in the
routing table
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A site can be a
member of multiple VPNs. However, a site can associate with only one VRF. A site’s VRF contains all
the routes available to the site from the VPNs of which it is a member.
Packet forwarding information is stored in the IP routing table and the Cisco Express Forwarding table
for each VRF. A separate set of routing and Cisco Express Forwarding tables is maintained for each
VRF. These tables prevent information from being forwarded outside a VPN, and also prevent packets
that are outside a VPN from being forwarded to a router within the VPN.
5
How VPN Routing Information Is Distributed in an MPLS VPN

The distribution of VPN routing information is controlled through the use of VPN route target
communities, implemented by BGP extended communities. VPN routing information is distributed as
follows:
• When a VPN route that is learned from a CE router is injected into BGP, a list of VPN route target
extended community attributes is associated with it. Typically the list of route target community
extended values is set from an export list of route targets associated with the VRF from which the
route was learned.
• An import list of route target extended communities is associated with each VRF. The import list
defines route target extended community attributes that a route must have in order for the route to
be imported into the VRF. For example, if the import list for a particular VRF includes route target
extended communities A, B, and C, then any VPN route that carries any of those route target
extended communities—A, B, or C—is imported into the VRF.
BGP Distribution of VPN Routing Information

A PE router can learn an IP prefix from the following sources:
• A CE router by static configuration
• A BGP session with the CE router
• A Routing Information Protocol (RIP) exchange with the CE router
The IP prefix is a member of the IPv4 address family. After the PE router learns the IP prefix, the PE
converts it into a VPN-IPv4 prefix by combining it with an 8-byte route distinguisher (RD). The
generated prefix is a member of the VPN-IPv4 address family. It uniquely identifies the customer
address, even if the customer site is using globally nonunique (unregistered private) IP addresses. The
route distinguisher used to generate the VPN-IPv4 prefix is specified by a configuration command
associated with the VRF on the PE router.
BGP distributes reachability information for VPN-IPv4 prefixes for each VPN. BGP communication
takes place at two levels:
• Within IP domains, known as an autonomous system (interior BGP [IBGP])
• Between autonomous systems (external BGP [EBGP]).
PE-PE or PE-RR (route reflector) sessions are IBGP sessions, and PE-CE sessions are EBGP sessions.
BGP propagates reachability information for VPN-IPv4 prefixes among PE routers by means of the BGP
multiprotocol extensions (see RFC 2283, Multiprotocol Extensions for BGP-4), which define support for
address families other than IPv4. Using the extensions ensures that the routes for a given VPN are
learned only by other members of that VPN, enabling members of the VPN to communicate with each
other.
MPLS Forwarding
Based on routing information stored in the VRF IP routing table and VRF Cisco Express Forwarding
table, packets are forwarded to their destination using MPLS.
A PE router binds a label to each customer prefix learned from a CE router and includes the label in the
network reachability information for the prefix that it advertises to other PE routers. When a PE router
forwards a packet received from a CE router across the provider network, it labels the packet with the
label learned from the destination PE router. When the destination PE router receives the labeled packet,
6
it pops the label and uses it to direct the packet to the correct CE router. Label forwarding across the
provider backbone is based on either dynamic label switching or traffic engineered paths. A customer
data packet carries two levels of labels when traversing the backbone:
• The top label directs the packet to the correct PE router.
• The second label indicates how that PE router should forward the packet to the CE router.
Major Components of MPLS VPNs

An MPLS-based VPN network has three major components:
• VPN route target communities—A VPN route target community is a list of all members of a VPN
community. VPN route targets need to be configured for each VPN community member.
• Multiprotocol BGP (MP-BGP) peering of VPN community PE routers—MP-BGP propagates VRF
reachability information to all members of a VPN community. MP-BGP peering needs to be
configured in all PE routers within a VPN community.
• MPLS forwarding—MPLS transports all traffic between all VPN community members across a
VPN service-provider network.
A one-to-one relationship does not necessarily exist between customer sites and VPNs. A given site can
be a member of multiple VPNs. However, a site can associate with only one VRF. A customer-site VRF
contains all the routes available to the site from the VPNs of which it is a member.
Benefits of an MPLS VPN

MPLS VPNs allow service providers to deploy scalable VPNs and build the foundation to deliver
value-added services, such as the following:
Connectionless Service
A significant technical advantage of MPLS VPNs is that they are connectionless. The Internet owes its
success to its basic technology, TCP/IP. TCP/IP is built on packet-based, connectionless network
paradigm. This means that no prior action is necessary to establish communication between
hosts, making it easy for two parties to communicate. To establish privacy in a connectionless IP
environment, current VPN solutions impose a connection-oriented, point-to-point overlay on the
network. Even if it runs over a connectionless network, a VPN cannot take advantage of the ease of
connectivity and multiple services available in connectionless networks. When you create a
connectionless VPN, you do not need tunnels and encryption for network privacy, thus eliminating
significant complexity.
Centralized Service
Building VPNs in Layer 3 allows delivery of targeted services to a group of users represented by a VPN.
A VPN must give service providers more than a mechanism for privately connecting users to intranet
services. It must also provide a way to flexibly deliver value-added services to targeted customers.
Scalability is critical, because customers want to use services privately in their intranets and extranets.
Because MPLS VPNs are seen as private intranets, you may use new IP services such as:
• Multicast
• Quality of service (QoS)
• Telephony support within a VPN
• Centralized services including content and web hosting to a VPN
7
You can customize several combinations of specialized services for individual customers. For example,
a service that combines IP multicast with a low-latency service class enables video conferencing within
an intranet.
Scalability
If you create a VPN using connection-oriented, point-to-point overlays, Frame Relay, or ATM virtual
connections (VCs), the VPN's key deficiency is scalability. Specifically, connection-oriented VPNs
without fully meshed connections between customer sites are not optimal. MPLS-based VPNs instead
use the peer model and Layer 3 connectionless architecture to leverage a highly scalable VPN solution.
The peer model requires a customer site to peer with only one PE router as opposed to all other customer
edge (CE) routers that are members of the VPN. The connectionless architecture allows the creation of
VPNs in Layer 3, eliminating the need for tunnels or VCs.
Other scalability issues of MPLS VPNs are due to the partitioning of VPN routes between PE routers
and the further partitioning of VPN and IGP routes between PE routers and provider (P) routers in a core
network.
• PE routers must maintain VPN routes for those VPNs who are members.
• P routers do not maintain any VPN routes.
This increases the scalability of the provider's core and ensures that no one device is a scalability
bottleneck.
Security
MPLS VPNs offer the same level of security as connection-oriented VPNs. Packets from one VPN do
not inadvertently go to another VPN.
Security is provided in the following areas:
• At the edge of a provider network, ensuring packets received from a customer are placed on the
correct VPN.
• At the backbone, VPN traffic is kept separate. Malicious spoofing (an attempt to gain access to a PE
router) is nearly impossible because the packets received from customers are IP packets. These IP
packets must be received on a particular interface or subinterface to be uniquely identified with a
VPN label.
Easy to Create
To take full advantage of VPNs, customers must be able to easily create new VPNs and user
communities. Because MPLS VPNs are connectionless, no specific point-to-point connection maps or
topologies are required. You can add sites to intranets and extranets and form closed user groups.
Managing VPNs in this manner enables membership of any given site in multiple VPNs, maximizing
flexibility in building intranets and extranets.
Flexible Addressing
To make a VPN service more accessible, customers of a service provider can design their own addressing
plan, independent of addressing plans for other service provider customers. Many customers use private
address spaces, as defined in RFC 1918, and do not want to invest the time and expense of converting to
public IP addresses to enable intranet connectivity. MPLS VPNs allow customers to continue to use their
present address spaces without network address translation (NAT) by providing a public and private view
of the address. A NAT is required only if two VPNs with overlapping address spaces want to
communicate. This enables customers to use their own unregistered private addresses, and communicate
freely across a public IP network.
8
How to Configure MPLS Layer 3 VPNs
Integrated Quality of Service (QoS) Support

QoS is an important requirement for many IP VPN customers. It provides the ability to address two
fundamental VPN requirements:
• Predictable performance and policy implementation
• Support for multiple levels of service in an MPLS VPN
Network traffic is classified and labeled at the edge of the network before traffic is aggregated according
to policies defined by subscribers and implemented by the provider and transported across the provider
core. Traffic at the edge and core of the network can then be differentiated into different classes by drop
probability or delay.
Straightforward Migration
For service providers to quickly deploy VPN services, use a straightforward migration path. MPLS
VPNs are unique because you can build them over multiple network architectures, including IP, ATM,
Frame Relay, and hybrid networks.
Migration for the end customer is simplified because there is no requirement to support MPLS on the
CE router and no modifications are required to a customer's intranet.

To configure and verify VPNs, perform the tasks described in the following sections:
• Configuring the Core Network, page 9 (required)
• Connecting the MPLS VPN Customers, page 12 (required)
• Verifying Connectivity Between MPLS VPN Sites, page 26 (optional)
Configuring the Core Network

Configuring the core network includes the following tasks:
• Assessing the Needs of MPLS VPN Customers, page 9 (required)
• Configuring Routing Protocols in the Core, page 10 (required)
• Configuring MPLS in the Core, page 10 (required)
• Determining if Cisco Express Forwarding Is Enabled in the Core, page 10 (required)
• Configuring Multiprotocol BGP on the PE Routers and Route Reflectors, page 10 (required)
Assessing the Needs of MPLS VPN Customers

Before you configure an MPLS VPN, you need to identify the core network topology so that it can best
serve MPLS VPN customers. Perform this task to identify the core network topology.
SUMMARY STEPS
1. Identify the size of the network.

2. Identify the routing protocols.
3. Determine if you need MPLS High Availability support.
9
4. Determine if you need BGP load sharing and redundant paths.
DETAILED STEPS

Step 1 Identify the size of the network. Identify the following to determine the number of routers
and ports you need:
• How many customers do you need to support?
• How many VPNs are needed per customer?
• How many virtual routing and forwarding instances are
there for each VPN?
Step 2 Identify the routing protocols in the core. Determine which routing protocols you need in the core
network.
Step 3 Determine if you need MPLS VPN High Availability MPLS VPN Nonstop Forwarding and Graceful Restart are
support. supported on select routers and Cisco IOS XE releases.
Contact Cisco Support for the exact requirements and
hardware support.
Step 4 Determine if you need BGP load sharing and See Load Sharing MPLS VPN Traffic for configuration
redundant paths in the MPLS VPN core. steps.
Configuring Routing Protocols in the Core

To configure a routing protocol—BGP, OSPF, IS-IS, EIGRP, static—see Configuring IP Routing
Protocols.
Configuring MPLS in the Core

To enable MPLS on all routers in the core, you must configure a label distribution protocol. You can use
either of the following as a label distribution protocol:
• MPLS Label Distribution Protocol (LDP). For more information, see MPLS Label Distribution
Protocol (LDP).
• MPLS Traffic Engineering Resource Reservation Protocol (RSVP). For more information, see
MPLS Traffic Engineering - RSVP Hello State Timer.
Determining if Cisco Express Forwarding Is Enabled in the Core

Cisco Express Forwarding must be enabled all routers in the core, including the PE routers. For
information about how to determine if Cisco Express Forwarding is enabled, see Configuring Basic
Cisco Express Forwarding—Improving Performance, Scalability, and Resiliency in Dynamic Network.
Configuring Multiprotocol BGP on the PE Routers and Route Reflectors

Perform this task to configure multiprotocol BGP (MP-BGP) connectivity on the PE routers and route
reflectors.
10
SUMMARY STEPS
1. enable
3. router bgp as-number
4. no bgp default ipv4-unicast
5. neighbor {ip-address | peer-group-name} remote-as as-number
6. neighbor {ip-address | peer-group-name} activate
7. address-family vpnv4 [unicast]
8. neighbor {ip-address | peer-group-name} send-community extended
10. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Configures a BGP routing process and enters router
configuration mode.
Example: • The as-number argument indicates the number of an
Router(config)# router bgp 100 autonomous system that identifies the router to other
BGP routers and tags the routing information passed
along. Valid numbers are from 0 to 65535. Private
autonomous system numbers that can be used in
internal networks range from 64512 to 65535.
Step 4 no bgp default ipv4-unicast (Optional) Disables the IPv4 unicast address family on all
neighbors.
Example: • Use the no form of the bgp default ipv4-unicast
Router(config-router)# no bgp default command if you are using this neighbor for MPLS
ipv4-unicast routes only.
Step 5 neighbor {ip-address | peer-group-name} Adds an entry to the BGP or multiprotocol BGP neighbor
remote-as as-number table.
• The ip-address argument specifies the IP address of the
Example: neighbor.
Router(config-router)# neighbor 10.0.0.1
remote-as 100 • The peer-group-name argument specifies the name of a
BGP peer group.
• The as-number argument specifies the autonomous
system to which the neighbor belongs.
11

Step 6 neighbor {ip-address | peer-group-name} Enables the exchange of information with a neighboring
activate BGP router.
Example: neighbor.
Router(config-router)# neighbor 10.0.0.1
activate • The peer-group-name argument specifies the name of a
BGP peer group.
Step 7 address-family vpnv4 [unicast] Enters address family configuration mode for configuring
routing sessions, such as BGP, that use standard VPNv4
address prefixes.
Example:
Router(config-router)# address-family vpnv4 • The optional unicast keyword specifies VPNv4 unicast
address prefixes.
Step 8 neighbor {ip-address | peer-group-name} Specifies that a communities attribute should be sent to a
send-community extended BGP neighbor.
Example: BGP-speaking neighbor.
Router(config-router-af)# neighbor 10.0.0.1
send-community extended • The peer-group-name argument specifies the name of a
BGP peer group.
Step 9 neighbor {ip-address | peer-group-name} Enables the exchange of information with a neighboring
activate BGP router.
Example: neighbor.
activate • The peer-group-name argument specifies the name of a
BGP peer group.
Example:
Router(config-router-af)# end
You can enter a show ip bgp neighbor command to verify that the neighbors are up and running. If this
command is not successful, enter a debug ip bgp x.x.x.x events command, where x.x.x.x is the
IP address of the neighbor.
Connecting the MPLS VPN Customers

To connect the MPLS VPN customers to the VPN, perform the following tasks:
• Defining VRFs on the PE Routers to Enable Customer Connectivity, page 13 (required)
• Configuring VRF Interfaces on PE Routers for Each VPN Customer, page 14 (required)
• Configuring Routing Protocols Between the PE and CE Routers, page 15 (required)
12
Defining VRFs on the PE Routers to Enable Customer Connectivity

To define VPN routing and forwarding (VRF) instances, perform this task.
SUMMARY STEPS
1. enable
3. ip vrf vrf-name
4. rd route-distinguisher
5. route-target {import | export | both} route-target-ext-community
6. import map route-map
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip vrf vrf-name Defines the VPN routing instance by assigning a VRF name
and enters VRF configuration mode.
Example: • The vrf-name argument is the name assigned to a VRF.
Router(config)# ip vrf vpn1
Step 4 rd route-distinguisher Creates routing and forwarding tables.
• The route-distinguisher argument adds an 8-byte value
Example: to an IPv4 prefix to create a VPN IPv4 prefix. You can
Router(config-vrf)# rd 100:1 enter an RD in either of these formats:
– 16-bit AS number: your 32-bit number, for
example, 101:3
– 32-bit IP address: your 16-bit number, for example,
10.0.0.1:1
13

Step 5 route-target {import |export | both} Creates a route-target extended community for a VRF.
route-target-ext-community
• The import keyword imports routing information from
the target VPN extended community.
Example:
Router(config-vrf)# route-target import 100:1
• The export keyword exports routing information to the
target VPN extended community.
• The both keyword imports routing information from
and exports routing information to the target VPN
extended community.
• The route-target-ext-community argument adds the
route-target extended community attributes to the
VRF's list of import, export, or both (import and export)
route-target extended communities.
Step 6 import map route-map (Optional) Configures an import route map for a VRF.
• The route-map argument specifies the route map to be
Example: used as an import route map for the VRF.
Router(config-vrf)# import map vpn1-route-map
Step 7 exit (Optional) Exits to global configuration mode.
Example:
Router(config-vrf)# exit
Configuring VRF Interfaces on PE Routers for Each VPN Customer

To associate a VRF with an interface or subinterface on the PE routers, perform this task.
SUMMARY STEPS
1. enable
4. ip vrf forwarding vrf-name
5. end
14
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number Specifies the interface to configure and enters interface
configuration mode.
Example: • The type argument specifies the type of interface to be
Router(config)# interface FastEthernet 1/0/0 configured.
• The number argument specifies the port, connector, or
interface card number.
Step 4 ip vrf forwarding vrf-name Associates a VRF with the specified interface or
subinterface.
Example: • The vrf-name argument is the name assigned to a VRF.
Router(config-if)# ip vrf forwarding vpn1
Configuring Routing Protocols Between the PE and CE Routers

Configure the PE router with the same routing protocol that the CE router uses. You can configure the
following routing protocols:
• Configuring BGP as the Routing Protocol Between the PE and CE Routers, page 15
• Configuring RIPv2 as the Routing Protocol Between the PE and CE Routers, page 17
• Configuring Static Routes Between the PE and CE Routers, page 19
• Configuring OSPF as the Routing Protocol Between the PE and CE Routers, page 20
• Configuring EIGRP as the Routing Protocol Between the PE and CE Routers, page 22
• Configuring EIGRP Redistribution in the MPLS VPN, page 24
Configuring BGP as the Routing Protocol Between the PE and CE Routers
To configure PE-to-CE routing sessions using BGP, perform this task.
SUMMARY STEPS
1. enable
15
4. address-family ipv4 [multicast | unicast | vrf vrf-name]

7. exit-address-family
8. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Configures a BGP routing process and enters
Example: • The as-number argument indicates the
Router(config)# router bgp 100 number of an autonomous system that
identifies the router to other BGP routers and
tags the routing information passed along.
Valid numbers are from 0 to 65535. Private
autonomous system numbers that can be used
in internal networks range from 64512 to
65535.
Step 4 address-family ipv4 [multicast | unicast | vrf Specifies the IPv4 address family type and enters
vrf-name] address family configuration mode.
• The multicast keyword specifies IPv4
Example: multicast address prefixes.
Router(config-router)# address-family ipv4 vrf vpn1
• The unicast keyword specifies IPv4 unicast
address prefixes.
• The vrf vrf-name keyword and argument
specify the name of the VRF to associate with
subsequent IPv4 address family configuration
mode commands.
Step 5 neighbor {ip-address | peer-group-name} remote-as Adds an entry to the BGP or multiprotocol BGP
as-number neighbor table.
• The ip-address argument specifies the IP
Example: address of the neighbor.
Router(config-router-af)# neighbor 10.0.0.1 remote-as
200 • The peer-group-name argument specifies the
name of a BGP peer group.
• The as-number argument specifies the
autonomous system to which the neighbor
belongs.
16

Step 6 neighbor {ip-address | peer-group-name} activate Enables the exchange of information with a
neighboring BGP router.
Example: • The ip-address argument specifies the IP
Router(config-router-af)# neighbor 10.0.0.1 activate address of the neighbor.
• The peer-group-name argument specifies the
name of a BGP peer group.
Step 7 exit-address-family Exits address family configuration mode.
Example:
Router(config-router-af)# exit-address-family
Example:
Configuring RIPv2 as the Routing Protocol Between the PE and CE Routers
To configure PE-to-CE routing sessions using RIPv2, perform this task.
SUMMARY STEPS
1. enable
3. router rip
4. version {1 | 2}
6. network ip-address
7. redistribute protocol [process-id] {level-1 | level-1-2 | level-2} [as-number] [metric metric-value]
[metric-type type-value] [match {internal | external 1 | external 2}] [tag tag-value] [route-map
map-tag] [subnets]
9. end
DETAILED STEPS

Example:
Router> enable
Example:
17

Step 3 router rip Enables RIP.
Example:
Router(config)# router rip
Step 4 version {1 | 2} Specifies a Routing Information Protocol (RIP)
version used globally by the router.
Example:
Router(config-router)# version 2
address prefixes.
specifies the name of the VRF to associate
with subsequent IPv4 address family
configuration mode commands.
Step 6 network ip-address Enables RIP on the PE-to-CE link.
Example:
Router(config-router-af)# network 192.168.7.0
Step 7 redistribute protocol [process-id] {level-1 | Redistributes routes from one routing domain into
level-1-2 | level-2} [as-number] [metric metric-value] another routing domain.
[metric-type type-value] [match {internal | external 1
| external 2}] [tag tag-value] [route-map map-tag] • For the RIPv2 routing protocol, use the
[subnets] redistribute bgp as-number command.
Example:
Router(config-router-af)# redistribute bgp 200
Example:
Example:
18
Configuring Static Routes Between the PE and CE Routers
To configure PE-to-CE routing sessions that use static routes, perform this task.
SUMMARY STEPS
1. enable
3. ip route vrf vrf-name
map-tag] [subnets]
map-tag] [subnets]
8. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip route vrf vrf-name Defines static route parameters for every
PE-to-CE session.
Example:
Router(config)# ip route vrf 200
address prefixes.
specifies the name of the VRF to associate
with subsequent IPv4 address family
configuration mode commands.
19

| external 2}] [tag tag-value] [route-map map-tag] • To redistribute VRF static routes into the VRF
[subnets] BGP table, use the redistribute static
command.
Example: See the command for information about other
Router(config-router-af)# redistribute static arguments and keywords.
| external 2}] [tag tag-value] [route-map map-tag] • To redistribute directly connected networks
[subnets] into the VRF BGP table, use the redistribute
connected command.
Example:
Router(config-router-af)# redistribute connected
Example:
Example:
Configuring OSPF as the Routing Protocol Between the PE and CE Routers
To configure PE-to-CE routing sessions that use OSPF, perform this task.
SUMMARY STEPS
1. enable
3. router ospf process-id [vrf vpn-name]
map-tag] [subnets]
8. end
20
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router ospf process-id [vrf vpn-name] Enables OSPF routing and enters router
configuration mode.
Example: • The process-id argument identifies the OSPF
Router(config)# router ospf 1 vrf grc process.
• The vrf keyword and vpn-name argument
identify a VPN. Create a separate OSPF
process for each VRF that will receive VPN
routes.
Step 4 network ip-address wildcard-mask area area-id Defines the interfaces on which OSPF runs and to
defines the area ID for those interfaces.
Example: • The ip-address argument identifies the IP
Router(config-router)# network 10.0.0.1 0.0.0.3 area address.
20
• The wildcard-mask argument identifies the
IP-address-type mask that includes “don't
care” bits.
• The area-id argument identifies the area that
is to be associated with the OSPF address
range. It can be specified as either a decimal
value or as an IP address. To associate areas
with IP subnets, specify a subnet address as
the value of the area-id argument.
address prefixes.
specify the name of the VRF to associate with
subsequent IPv4 address family configuration
mode commands.
21

| external 2}] [tag tag-value] [route-map map-tag] You may need to include several protocols to
[subnets] ensure that all IBGP routes are distributed into the
VRF.
Example:
Router(config-router-af)# redistribute rip metric 1
subnets
Example:
Example:
Configuring EIGRP as the Routing Protocol Between the PE and CE Routers
Using Enhanced Interior Gateway Routing Protocol (EIGRP) between the PE and CE routers allows you
to transparently connect EIGRP customer networks through an MPLS-enabled BGP core network so that
EIGRP routes are redistributed through the VPN across the BGP network as internal BGP (iBGP) routes.
To configure PE-to-CE routing sessions that use EIGRP, perform this task.
Prerequisites
BGP must be configured in the network core.
SUMMARY STEPS
1. enable
4. no synchronization
5. neighbor ip-address remote-as as-number
6. neighbor ip-address update-source loopback interface-number
7. address-family vpnv4
8. neighbor ip-address activate
9. neighbor ip-address send-community extended
11. address-family ipv4 vrf vrf-name
12. redistribute eigrp as-number [metric metric-value] [route-map map-name]
13. no synchronization
22
15. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Enters router configuration mode, and creates a BGP
routing process.
Example:
Router(config)# router bgp 10
Step 4 no synchronization Configures BGP to send advertisements without waiting to
synchronize with the IGP.
Example:
Router(config-router)# no synchronization
Step 5 neighbor ip-address remote-as as-number Establishes peering with the specified neighbor or
peer-group.
Example: • In this step, you are establishing an iBGP session with
Router(config-router)# neighbor 10.0.0.1 the PE router that is connected to the CE router at the
remote-as 10 other CE site.
Step 6 neighbor ip-address update-source loopback Configures BGP to use any operational interface for TCP
interface-number connections.
• This configuration step is not required. However, the
Example: BGP routing process will be less susceptible to the
Router(config-router)# neighbor 10.0.0.1 affects of interface or link flapping.
update-source loopback 0
Step 7 address-family vpnv4 Enters address family configuration mode for configuring
routing sessions that use standard IPv4 address prefixes,
such as BGP, RIP, and static routing sessions.
Example:
Router(config-router)# address-family vpnv4
Step 8 neighbor ip-address activate Establishes peering with the specified neighbor or
peer-group.
Example: • In this step, you are activating the exchange of VPNv4
Router(config-router-af)# neighbor 10.0.0.1 routing information between the PE routers.
activate
Step 9 neighbor ip-address send-community extended Configures the local router to send extended community
attribute information to the specified neighbor.
Example: • This step is required for the exchange of EIGRP
Router(config-router-af)# neighbor 10.0.0.1 extended community attributes.
send-community extended
23

Step 10 exit-address-family Exits address family configuration mode and enters router
configuration mode.
Example:
Step 11 address-family ipv4 vrf vrf-name Configures an IPv4 address-family for the EIGRP VRF and
enters address family configuration mode.
Example: • An address-family VRF needs to be configured for each
Router(config-router)# address-family ipv4 vrf EIGRP VRF that runs between the PE and CE routers.
RED
Step 12 redistribute eigrp as-number [metric Redistributes the EIGRP VRF into BGP.
metric-value] [route-map map-name]
• The autonomous system number from the CE network
is configured in this step.
Example:
Router(config-router-af)# redistribute eigrp
101
Step 13 no synchronization Configures BGP to send advertisements without waiting to
synchronize with the IGP.
Example:
Router(config-router-af)# no synchronization
configuration mode.
Example:
Step 15 end Exits router configuration mode and enters privileged
EXEC mode.
Example:
Configuring EIGRP Redistribution in the MPLS VPN
Perform this task to every PE router that provides VPN services to enable EIGRP redistribution in the
MPLS VPN.
Prerequisites
The metric must be configured for routes from external EIGRP autonomous systems and non-EIGRP
networks before these routes can be redistributed into an EIGRP CE router. The metric can be configured
in the redistribute statement using the redistribute (IP) command or configured with the default-metric
(EIGRP) command. If an external route is received from another EIGRP autonomous system or a
non-EIGRP network without a configured metric, the route will not be advertised to the CE router.
Restrictions
Redistribution between native EIGRP VRFs is not supported. This is designed behavior.
24
SUMMARY STEPS
1. enable
3. router eigrp as-number
5. network ip-address wildcard-mask
6. redistribute bgp {as-number} [metric bandwidth delay reliability load mtu] [route-map
map-name]
7. autonomous-system as-number
9. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router eigrp as-number Enters router configuration mode and creates an EIGRP
routing process.
Example: • The EIGRP routing process for the PE router is created
Router(config)# router eigrp 1 in this step.
Step 4 address-family ipv4 [multicast | unicast | vrf Enters address-family configuration mode and creates a
vrf-name] VRF.
• The VRF name must match the VRF name that was
Example: created in the previous section.
Router(config-router)# address-family ipv4 vrf
RED
Step 5 network ip-address wildcard-mask Specifies the network for the VRF.
• The network statement is used to identify which
Example: interfaces to include in EIGRP. The VRF must be
Router(config-router-af)# network 172.16.0.0 configured with addresses that fall within the
0.0.255.255 wildcard-mask range of the network statement.
25

Step 6 redistribute bgp {as-number} [metric bandwidth Redistributes BGP into the EIGRP.
delay reliability load mtu] [route-map
map-name] • The autonomous system number and metric of the BGP
network is configured in this step. BGP must be
redistributed into EIGRP for the CE site to accept the
Example: BGP routes that carry the EIGRP information. A metric
Router(config-router-af)# redistribute bgp 10
must also be specified for the BGP network and is
metric 10000 100 255 1 1500
configured in this step.
Step 7 autonomous-system as-number Specifies the autonomous system number of the EIGRP
network for the customer site.
Example:
Router(config-router-af)# autonomous-system 101
configuration mode.
Example:
Step 9 end Exits router configuration mode and enters privileged
EXEC mode.
Example:
Verifying the VPN Configuration

A route distinguisher must be configured for the VRF, and MPLS must be configured on the interfaces
that carry the VRF. Use the show ip vrf command to verify the route distinguisher (RD) and interface
that are configured for the VRF.
SUMMARY STEPS
1. show ip vrf
DETAILED STEPS
Step 1 show ip vrf

Use this command to display the set of defined VRF instances and associated interfaces. The output also
maps the VRF instances to the configured route distinguisher.
Verifying Connectivity Between MPLS VPN Sites

To verify that the local and remote CE routers can communicate across the MPLS core, perform the
following tasks:
• Verifying IP Connectivity from CE Router to CE Router Across the MPLS Core, page 27
• Verifying that the Local and Remote CE Routers Are in the Routing Table, page 27
26
Verifying IP Connectivity from CE Router to CE Router Across the MPLS Core

Perform this task to verify IP connectivity from CE router to CE router across the MPLS VPN.
SUMMARY STEPS
1. enable
2. ping [protocol] {host-name | system-address}
3. trace [protocol] [destination]
4. show ip route [ip-address [mask] [longer-prefixes] | protocol [process-id] | [list access-list-number
| access-list-name]
5. disable
DETAILED STEPS
Step 1 enable
Use this command to enable privileged EXEC mode.
Step 2 ping [protocol] {host-name | system-address}
Use this command to diagnoses basic network connectivity on AppleTalk, CLNS, IP, Novell, Apollo,
VINES, DECnet, or XNS networks. Use the ping command to verify the connectivity from one CE
router to another.
Step 3 trace [protocol] [destination]
Use this command to discover the routes that packets take when traveling to their destination. Use the
trace command to verify the path that a packet goes through before reaching the final destination. The
trace command can help isolate a trouble spot if two routers cannot communicate.
Step 4 show ip route [ip-address [mask] [longer-prefixes] | protocol [process-id] | [list access-list-number |
access-list-name]
Use this command to display the current state of the routing table. Use the ip-address argument to verify
that CE1 has a route to CE2. Verify the routes learned by CE1. Make sure that the route for CE2 is listed.
Verifying that the Local and Remote CE Routers Are in the Routing Table
Perform this task to check that the local and remote CE routers are in the routing table of the PE routers.
SUMMARY STEPS
1. enable
2. show ip route vrf vrf-name [prefix]
3. show ip cef vrf vrf-name [ip-prefix]
4. exit
Step 1 enable
27
Configuration Examples for MPLS VPNs
Use this command to enable privileged EXEC mode.

Step 2 show ip route vrf vrf-name [prefix]
Use this command to display the IP routing table associated with a VRF. Check that the loopback
addresses of the local and remote CE routers are in the routing table of the PE routers.
Step 3 show ip cef vrf vrf-name [ip-prefix]
Use this command to display the Cisco Express Forwarding forwarding table associated with a VRF.
Check that the prefix of the remote CE router is in the Cisco Express Forwarding table.
Step 4 exit

• Configuring an MPLS VPN Using BGP: Example, page 28
• Configuring an MPLS VPN Using RIP: Example, page 30
• Configuring an MPLS VPN Using Static Routes: Example, page 31
• Configuring an MPLS VPN Using OSPF: Example, page 32
• Configuring an MPLS VPN Using EIGRP: Example, page 33
Configuring an MPLS VPN Using BGP: Example

This example shows an MPLS VPN that is configured using BGP.
28
PE Configuration CE Configuration
ip vrf vpn1 ip cef
rd 100:1 mpls ldp router-id Loopback0 force
route-target export 100:1 mpls label protocol ldp
route-target import 100:1 !
ip cef ip address 10.0.0.9 255.255.255.255
mpls ldp router-id Loopback0 force !
mpls label protocol ldp interface FastEthernet0/0
! ip address 10.0.0.1 255.0.0.0
interface Loopback0 no cdp enable
ip address 10.0.0.1 255.255.255.255 !
! router bgp 200
interface FastEthernet0/0/0 bgp log-neighbor-changes
ip vrf forwarding vpn1 neighbor 10.0.0.2 remote-as 100
ip address 10.0.0.2 255.0.0.0 !
no cdp enable address-family ipv4
! redistribute connected
interface FastEthernet 1/1/0 neighbor 10.0.0.2 activate
ip address 10.0.0.1 255.0.0.0 neighbor 10.0.0.2 advertisement-interval 5
mpls label protocol ldp no auto-summary
mpls ip no synchronization
! exit-address-family
router ospf 100
network 10.0.0. 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
!
router bgp 100
no synchronization
bgp log-neighbor changes
no auto-summary
!
exit-address-family
!
neighbor 10.0.0.1 as-override
neighbor 10.0.0.1 advertisement-interval 5
no auto-summary
no synchronization
exit-address-family
29
Configuring an MPLS VPN Using RIP: Example

This example shows an MPLS VPN that is configured using RIP.
ip vrf vpn1 ip cef
ip cef ip address 10.0.0.9 255.255.255.255
mpls label protocol ldp interface FastEthernet0/0/0
! ip address 10.0.0.1 255.0.0.0
ip address 10.0.0.1 255.255.255.255
! router rip
interface FastEthernet0/0/0 version 2
ip vrf forwarding vpn1 timers basic 30 60 60 120
ip address 10.0.0.2 255.0.0.0 redistribute connected
no cdp enable network 10.0.0.0
interface FastEthernet 1/1/0 network 10.0.0.1
ip address 10.0.0.1 255.0.0.0 no auto-summary
mpls ip
!
router rip
version 2
timers basic 30 60 60 120
!
version 2
redistribute bgp 100 metric transparent
network 10.0.0.0
distribute-list 20 in
no auto-summary
exit-address-family
!
router bgp 100
no synchronization
no auto-summary
!
exit-address-family
!
redistribute rip
no auto-summary
no synchronization
exit-address-family
30
Configuring an MPLS VPN Using Static Routes: Example

This example shows an MPLS VPN that is configured using static routes.
ip vrf vpn1 ip cef
rd 100:1 !
route-target export 100:1 interface Loopback0
route-target import 100:1 ip address 10.0.0.9 255.255.255.255
! !
ip cef interface FastEthernet0/0/0
mpls ldp router-id Loopback0 force ip address 10.0.0.1 255.0.0.0
mpls label protocol ldp no cdp enable
! !
interface Loopback0 ip route 10.0.0.9 255.255.255.255 10.0.0.2 3
ip address 10.0.0.1 255.255.255.255 ip route 10.0.0.0 255.0.0.0 10.0.0.2 3
!
ip address 10.0.0.2 255.0.0.0
no cdp enable
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 100
network 10.0.0. 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
!
router bgp 100
no synchronization
no auto-summary
!
exit-address-family
!
redistribute static
no auto-summary
no synchronization
exit-address-family
!
ip route vrf vpn1 10.0.0.9 255.255.255.255
10.0.0.1
ip route vrf vpn1 10.0.0.0 255.0.0.0 10.0.0.1
31
Configuring an MPLS VPN Using OSPF: Example

This example shows an MPLS VPN that is configured using OSPF.
ip vrf vpn1 ip cef
ip cef ip address 10.0.0.9 255.255.255.255
! ip address 10.0.0.1 255.0.0.0
ip address 10.0.0.1 255.255.255.255 !
! router ospf 1000
interface FastEthernet0/0/0 log-adjacency-changes
ip vrf forwarding vpn1 auto-cost reference-bandwidth 1000
ip address 10.0.0.2 255.0.0.0 redistribute connected subnets
no cdp enable network 10.0.0.0 0.255.255.255 area 1000
! network 10.0.0.0 0.0.0.0 area 1000
router ospf 1000 vrf vpn1
redistribute bgp 100 metric-type 1 subnets
network 10.0.0.13 0.0.0.0 area 10000
network 10.0.0.0 0.255.255.255 area 10000
!
router bgp 100
no synchronization
no auto-summary
!
exit-address-family
!
redistribute ospf 1000 match internal
external 1 external 2
no auto-summary
no synchronization
exit-address-family
32
Configuring an MPLS VPN Using EIGRP: Example

This example shows an MPLS VPN that is configured using EIGRP.
ip vrf vpn1 ip cef
ip cef ip address 10.0.0.9 255.255.255.255
! ip address 10.0.0.1 255.0.0.0
ip address 10.0.0.1 255.255.255.255 !
interface FastEthernet0/0/0 router eigrp 1000
ip vrf forwarding vpn1 network 10.0.0.0
ip address 10.0.0.2 255.0.0.0 auto-summary
no cdp enable
ip address 10.0.0.1 255.0.0.0
mpls ip
router eigrp 1000
auto-summary
!
redistribute bgp 100 metric 10000 100 255
1 1500
network 10.0.0.0
distribute-list 20 in
no auto-summary
autonomous-system 1000
exit-address-family
!
router bgp 100
no synchronization
no auto-summary
!
exit-address-family
!
redistribute eigrp
no auto-summary
no synchronization
exit-address-family
33
The following sections provide references related to MPLS VPNs.
Related Documents
MPLS applications
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 2283 Multiprotocol Extensions for BGP-4
RFC 2547 BGP/MPLS VPNs
34
Description Link
35
Feature Information for MPLS Layer 3 VPNs

Table 1 Feature Information for MPLS Layer 3 VPNs

MPLS Virtual Private Networks Cisco IOS XE This feature allows a set of sites that to be interconnected by
Release 2.1 means of an MPLS provider core network. At each
customer site, one or more customer edge (CE) routers
attach to one or more provider edge (PE) routers.
feature:
• How to Configure MPLS Layer 3 VPNs, page 9
MPLS VPN–OSPF PE-CE Support Cisco IOS XE This feature was introduced on Cisco ASR 1000 Series
Release 2.1 Routers.
The following section provides information about this
feature:
• Configuring OSPF as the Routing Protocol Between the
PE and CE Routers, page 20
MPLS VPN Support for EIGRP Between Cisco IOS XE This feature allows you to connect customers running
Provider Edge and Customer Edge Release 2.1 EIGRP to an MPLS VPN.
feature:
• Configuring EIGRP as the Routing Protocol Between
the PE and CE Routers, page 22
• Configuring EIGRP Redistribution in the MPLS VPN,
page 24
36
Table 1 Feature Information for MPLS Layer 3 VPNs

VPN Routing/Forwarding (VRF) ARP Entry Cisco IOS XE This feature was introduced on Cisco ASR 1000 Series
Support Release 2.1 Routers.
feature:
• How Virtual Routing and Forwarding Tables Work in an
MPLS VPN, page 5
• How VPN Routing Information Is Distributed in an
MPLS VPN, page 6
• Defining VRFs on the PE Routers to Enable Customer
Connectivity, page 13
Multi-protocol BGP (MP-BGP)–MPLS Cisco IOS XE This feature was introduced on Cisco ASR 1000 Series
VPN Release 2.1 Routers.
feature:
• How to Configure MPLS Layer 3 VPNs, page 9
coincidental.
© 2005–2009 Cisco Systems, Inc. All rights reserved
37
38
Assigning an ID Number to a VPN

You can identify Virtual Private Networks (VPNs) by a VPN identification number, as described in
RFC 2685. This implementation of the VPN ID feature is used for identifying a VPN.

which each feature is supported, see the “Feature Information for Assigning an ID Number to a VPN” section
on page 9.
Contents
• Information About VPN ID, page 2
• How to Configure a VPN ID, page 3
• Configuration Examples for Assigning an ID Number to a VPN, page 6
• Feature Information for Assigning an ID Number to a VPN, page 9

Information About VPN ID
Information About VPN ID

Before configuring this feature, you should understand the following concepts:
• Introduction to VPN ID, page 2
• Components of the VPN ID, page 2
• Management Applications That Use VPN IDs, page 3
Introduction to VPN ID
You can identify VPNs by a VPN identification number, as described in RFC 2685. This implementation
of the VPN ID feature is used for identifying a VPN. The VPN ID feature is not used to control the
distribution of routing information or to associate IP addresses with VPN ID numbers in the MP-BGP
VPNv4 routing updates.
Multiple VPNs can be configured in a router. A VPN is private and uses a private address space that
might also be used by another VPN or by the Internet. The IP address used in a VPN is only significant
to the VPN in which it exists. You can use a VPN name (a unique ASCII string) to reference a specific
VPN configured in the router. Alternately, you can use a VPN ID to identify a particular VPN in the
router. The VPN ID follows a standard specification (RFC 2685). To ensure that the VPN has a consistent
VPN ID, assign the same VPN ID to all the routers in the service provider network that services that
VPN.
Note Configuration of a VPN ID for a VPN is optional. You can still use a VPN name to identify configured
VPNs in the router. The VPN name is not affected by the VPN ID configuration. These are two
independent mechanisms to identify VPNs.
Components of the VPN ID

Each VPN ID defined by RFC 2685 consists of the following elements:
• An Organizational Unique Identifier (OUI), a three-octet hex number
The IEEE Registration Authority assigns OUIs to any company that manufactures components
under the ISO/IEC 8802 standard. The OUI is used to generate universal LAN MAC addresses and
protocol identifiers for use in local and metropolitan area network applications. For example, an
OUI for Cisco Systems is 00-03-6B (hex).
• A VPN index, a four-octet hex number, which identifies the VPN within the company.
Use the following vpn id command and specify the VPN ID:
vpn id oui:vpn-index
A colon separates the OUI from the VPN index.
2
How to Configure a VPN ID
Management Applications That Use VPN IDs

You can use several applications to manage VPNs by VPN ID. Remote access applications, such as the
Remote Authentication Dial-In User Service (RADIUS) and Dynamic Host Configuration Protocol
(DHCP), can use the VPN ID feature to identify a VPN. RADIUS can use the VPN ID to assign dial-in
users to the proper VPN, based on each user’s authentication information.
Dynamic Host Configuration Protocol

Using DHCP network administrators can centrally manage and automate the assignment of IP addresses
in an organization’s network. The DHCP application uses the VPN ID as follows:
1. A VPN DHCP client requests a connection to a provider edge (PE) router from a VRF interface.
2. The PE router determines the VPN ID associated with that interface.
3. The PE router sends a request with the VPN ID and other information for assigning an IP address to
the DHCP server.
4. The DHCP server uses the VPN ID and IP address information to process the request.
5. The DHCP server sends a response back to the PE router, allowing the VPN DHCP client access to
the VPN.
Remote Authentication Dial-In User Service

A RADIUS server (or daemon) provides authentication and accounting services to one or more client
network access servers (NASs). RADIUS servers authenticate users and return all configuration
information necessary for the client to deliver service to the users.
Typically, a user login consists of a query (Access-Request) from the NAS to the RADIUS server and a
corresponding response (Access-Accept or Access-Reject) from the server.
• The Access-Request packet contains the username, encrypted password, NAS IP address, VPN ID,
and port. The format of the request also provides information on the type of session that the user
wants to initiate.
• The RADIUS server returns an Access-Accept response if it finds the username and verifies the
password. The response includes a list of attribute-value pairs that describe the parameters to be
used for this session. If the user is not authenticated, an Access-Reject is sent by the RADIUS server
and access is denied.

• Specifying a VPN ID, page 4 (required)
• Verifying the VPN ID Configuration, page 5 (optional)
3
Specifying a VPN ID
Use this procedure to specify a VPN ID.
Restrictions
The VPN ID feature is not used to control the distribution of routing information or to associate IP
addresses with VPN ID numbers in the MP-BGP VPNv4 routing updates.
Prerequisites
Each VRF configured on a PE router can have a VPN ID configured. Configure all the PE routers that
belong to the same VPN with the same VPN ID. Make sure the VPN ID is unique to the service provider
network.
SUMMARY STEPS
1. enable
3. ip vrf vrf-name
4. vpn id oui:vpn-index
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 ip vrf vrf-name Creates a VRF routing table and a CEF forwarding
table and enters VRF configuration mode.
Example: • vrf-name—Name assigned to a VRF.
Router(config)# ip vrf vrf1
Step 4 vpn id oui:vpn-index Assigns the VPN ID to the VRF.
• oui:—An organizationally unique identifier.
Example: The IEEE organization assigns this identifier
Router(config-vrf)# vpn id a1:3f6c to companies. The OUI is restricted to three
octets.
• vpn-index—This value identifies the VPN
within the company. This VPN index is
restricted to four octets.
4
Verifying the VPN ID Configuration

To verify the VPN ID configuration, perform the following steps.
SUMMARY STEPS
1. enable
2. show ip vrf
3. show ip vrf id
4. show ip vrf detail
DETAILED STEPS
Step 1 enable
Step 2 show ip vrf
Use this command to display information about the VRF tables on the PE router. This example displays
three VRF tables called vpn1, vpn2, and vpn5.
Router# show ip vrf
Name Default RD Interfaces

vpn1 100:1 FastEthernet1/1/1
FastEthernet1/0/0
vpn2 <not set>
vpn5 500:1 Loopback2
Step 3 show ip vrf id

Use this command to ensure that the PE router contains the VPN ID you specified. The following
example shows that only VRF tables vpn1 and vpn2 have VPN IDs assigned. The VRF table called vpn5
is not displayed, because it does not have a VPN ID.
Router# show ip vrf id
VPN Id Name RD
2:3 vpn2 <not set>
A1:3F6C vpn1 100:1
Step 4 show ip vrf detail

Use this command to see all the VRFs on a PE router. This command displays all the VPN IDs that are
configured on the router, their associated VRF names, and VRF route distinguishers (RDs). If a VRF
table in the PE router has not been assigned a VPN ID, that VRF entry is not included in the output.
Router# show ip vrf detail
VRF vpn1; default RD 100:1; default VPNID A1:3F6C

Interfaces:
FastEthernet1/1/1 FastEthernet1/0/1
Connected addresses are not in global routing table
Export VPN route-target communities
RT:100:1
Import VPN route-target communities
RT:100:1 RT:500:1
No import route-map
No export route-map
VRF vpn2; default RD <not set>; default VPNID 2:3
5
Configuration Examples for Assigning an ID Number to a VPN
No interfaces
No Export VPN route-target communities
No Import VPN route-target communities
No import route-map
No export route-map
VRF vpn5; default RD 500:1; default VPNID <not set>
Interfaces:
Configuration Examples for Assigning an ID Number to a VPN

• Specifying a VPN ID: Example, page 6
• Verifying the VPN ID Configuration: Example, page 6
Specifying a VPN ID: Example

The following example specifies the VPN ID assigned to the VRF table called vpn1:
Router(config-vrf)# vpn id a1:3f6c
Verifying the VPN ID Configuration: Example

The following is sample output of the show ip vrf detail command, one of the commands that can be
used to verify the VPN ID configuration. Use this command to see all the VRFs on a PE router. This
command displays all the VPN IDs that are configured on the router, their associated VRF names, and
VRF route distinguishers (RDs). If a VRF table in the PE router has not been assigned a VPN ID, that
VRF entry is not included in the output.
Router# show ip vrf detail
VRF vpn1; default RD 100:1; default VPNID A1:3F6C

Interfaces:
FastEthernet1/1/1 FastEthernet1/0/1
RT:100:1
RT:100:1 RT:500:1
No import route-map
No export route-map
VRF vpn2; default RD <not set>; default VPNID 2:3
No interfaces
No Import VPN route-target communities
No import route-map
No export route-map
VRF vpn5; default RD 500:1; default VPNID <not set>
Interfaces:
6
The following sections provide references related to assigning an ID number to a VPN.
Related Documents
MPLS applications
Basic MPLS VPNs Configuring MPLS Layer 3 VPNs
Standards
Standard Title
IEEE Std 802-1990 IEEE Local and Metropolitan Area Networks: Overview and
Architecture
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 2685 Virtual Private Networks Identifier
7
Description Link
8
Feature Information for Assigning an ID Number to a VPN

Table 1 Feature Information for Assigning an ID Number to a VPN
Feature Name Releases Feature Configuration Information

MPLS VPN ID Cisco IOS XE You can identify VPNs by a VPN identification number, as
Release 2.1 described in RFC 2685. This implementation of the VPN ID
feature is used for identifying a VPN.
on Cisco ASR 1000 Series Aggregation Services Routers.
feature:
• Components of the VPN ID, page 2
• Management Applications That Use VPN IDs, page 3
• How to Configure a VPN ID, page 3
countries.
coincidental.
9
10
MPLS Multi-VRF (VRF-Lite)

The MPLS Multi-VRF feature allows you to configure and maintain more than one instance of a routing
and forwarding table within the same customer edge (CE) router.

which each feature is supported, see the “Feature Information for MPLS Multi-VRF” section on page 17.
Contents
• Prerequisites for MPLS Multi-VRF, page 2
• Restrictions for MPLS Multi-VRF, page 2
• Information About MPLS Multi-VRF, page 2
• How to Configure MPLS Multi-VRF, page 4
• Configuration Examples for MPLS Multi-VRF, page 12
• Feature Information for MPLS Multi-VRF, page 17
Prerequisites for MPLS Multi-VRF
Prerequisites for MPLS Multi-VRF

The network’s core and provider edge routers must be configured for MPLS Virtual Private Network
(VPN) operation.
Restrictions for MPLS Multi-VRF

You can configure the MPLS Multi-VRF feature only on Layer 3 interfaces.
The MPLS Multi-VRF feature is not supported by Interior Gateway Routing Protocol (IGRP) nor IS-IS.
Label distribution for a given VPN routing and forwarding (VRF) instance on a given router can be
handled by either Border Gateway Protocol (BGP) or Label Distribution Protocol (LDP), but not by both
protocols at the same time.
Multicast cannot operate on a Layer 3 interface that is configured with the MPLS Multi-VRF feature.
Information About MPLS Multi-VRF

To configure subscription-based Cisco IOS XE content filtering, you should understand the following
concepts:
• How the MPLS Multi-VRF Feature Works, page 2
• How Packets Are Forwarded in a Network Using the MPLS Multi-VRF Feature, page 3
• Points to Consider When Configuring the MPLS Multi-VRF Feature, page 4
How the MPLS Multi-VRF Feature Works

The MPLS Multi-VRF feature enables a service provider to support two or more VPNs, where the IP
addresses can overlap several VPNs. The MPLS Multi-VRF feature uses input interfaces to distinguish
routes for different VPNs and forms virtual packet-forwarding tables by associating one or more Layer 3
interfaces with each VRF. Interfaces in a VRF can be either physical, such as FastEthernet ports, or
logical, such as VLAN Switched Virtual Interfaces (SVIs), but a Layer 3 interface cannot belong to more
than one VRF at any one time. The Multi-VRF feature allows an operator to support two or more routing
domains on a CE router, with each routing domain having its own set of interfaces and its own set of
routing and forwarding tables. The MPLS Multi-VRF feature makes it possible to extend the Label
Switched Paths (LSPs) to the CE and into each routing domain that the CE supports.
The MPLS Multi-VRF feature works as follows:
• Each CE router advertises its site’s local routes to a provider edge (PE) router and learns the remote
VPN routes from that PE router.
• PE routers exchange routing information with CE routers by using static routing or a routing
protocol such as BGP, RIPv1, or RIPv2.
• PE routers exchange MPLS label information with CE routers through LDP or BGP.
2
Information About MPLS Multi-VRF
• The PE router needs to maintain VPN routes only for those VPNs to which it is directly attached,
eliminating the requirement that the PE maintain all of the service provider’s VPN routes. Each PE
router maintains a VRF for each of its directly connected sites. Two or more interfaces on a PE router
can be associated with a single VRF if all the sites participate in the same VPN. Each VPN is
mapped to a specified VRF. After learning local VPN routes from CE routers, the PE router
exchanges VPN routing information with other PE routers through internal BGP (iBPG).
With the MPLS Multi-VRF feature, two or more customers can share one CE router, and only one
physical link is used between the CE and the PE routers. The shared CE router maintains separate VRF
tables for each customer and routes packets for each customer based on that customer’s own routing
table. The MPLS Multi-VRF feature extends limited PE router functionality to a CE router, giving it the
ability, through the maintenance of separate VRF tables, to extend the privacy and security of a VPN to
the branch office.
Figure 1 shows a configuration where each CE router acts as if it were two CE routers. Because the
MPLS Multi-VRF feature is a Layer 3 feature, each interface associated with a VRF must be a Layer 3
interface.
Figure 1 Each CE Router Acting as Several Virtual CE Routers
VPN 1 VPN 1
CE PE PE CE
MPLS
network
VPN 2 VPN 2
135228
CE = Customer edge router
PE = Provider edge router
How Packets Are Forwarded in a Network Using the MPLS Multi-VRF Feature
Following is the packet-forwarding process in an MPLS Multi-VRF CE-enabled network, as illustrated
in Figure 1:
• When the CE receives a packet from a VPN, it looks up the routing table based on the input interface.
When a route is found, the CE imposes the MPLS label it received from the PE for that route and
forwards the packet to the PE.
• When the ingress PE receives a packet from the CE, it swaps the incoming label with the
corresponding label stack and sends it to the MPLS network.
• When an egress PE receives a packet from the network, it swaps the VPN label with the label it
earlier had received for the route from the CE, and forwards it to the CE.
• When a CE receives a packet from an egress PE, it uses the incoming label on the packet to forward
the packet to the correct VPN.
To configure Multi-VRF, you create a VRF table and then specify the Layer 3 interface associated with
that VRF. Next, you configure the routing protocols within the VPN, and between the CE and the PE.
BGP is the preferred routing protocol for distributing VPN routing information across the provider's
backbone. For more information, see the “How to Configure MPLS Multi-VRF” section on page 4.
3
How to Configure MPLS Multi-VRF
The Multi-VRF network has three major components:

• VPN route target communities: These are lists of all other members of a VPN community. You need
to configure VPN route targets for each VPN community member.
• Multiprotocol BGP peering of VPN community PE routers: This propagates VRF reachability
information to all members of a VPN community. You need to configure BGP peering in all PE
routers within a VPN community.
• VPN forwarding: This transports all traffic between VPN community members across a VPN
service-provider network.
Points to Consider When Configuring the MPLS Multi-VRF Feature

Consider these points when configuring the MPLS Multi-VRF feature in your network:
• A router with the MPLS Multi-VRF feature is shared by several customers, and each customer has
its own routing table.
• Because each customer uses a different VRF table, the same IP addresses can be reused.
Overlapping IP addresses are allowed in different VPNs.
• The MPLS Multi-VRF feature lets several customers share the same physical link between the PE
and the CE routers. Trunk ports with several VLANs separate packets among the customers. Each
customer has its own VLAN.
• For the PE router, there is no difference between using the MPLS Multi-VRF feature or using several
CE routers.
• The MPLS Multi-VRF feature does not affect the packet switching rate.

• Configuring VRFs, page 4 (required)
• Configuring BGP as the Routing Protocol, page 6 (required)
• Configuring PE-to-CE MPLS Forwarding and Signalling with BGP, page 8 (Required)
• Configuring a Routing Protocol Other than BGP, page 10 (required)
• Configuring PE-to-CE MPLS Forwarding and Signalling with LDP, page 11 (required)
Configuring VRFs
To configure VRFs, complete the following procedure. Be sure to configure VRFs on both the PE and
the CE routers.
Restrictions
Multicast cannot be configured at the same time on the same Layer 3 interface as the MPLS Multi-VRF
feature.
4
Default VRF Configuration

If a VRF has not been configured, the router has the following default configuration:
• No VRFs have been defined.
• No import maps, export maps, or route maps have been defined.
• No VRF maximum routes exist.
• Only the global routing table exists on the interface.
SUMMARY STEPS
1. enable
3. ip routing
4. ip vrf vrf-name
6. route-target {export | import | both} route-target-ext-community
7. import map route-map
8. exit
11. show ip vrf
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip routing Enables IP routing.
Example:
Router(config)# ip routing
Step 4 ip vrf vrf-name Names the VRF, and enters VRF configuration mode.
Example:
Router(config)# ip vrf v1
5

Step 5 rd route-distinguisher Creates a VRF table by specifying a route distinguisher.
Enter either an autonomous system number and an arbitrary
Example: number (xxx:y), or an IP address and an arbitrary number
Router(config-vrf)# rd 100:1 (A.B.C.D:y).
Step 6 route-target {export | import | both} Creates a list of import, export, or import and export route
route-target-ext-community target communities for the specified VRF.
Enter either an autonomous system number and an arbitrary
Example: number (xxx:y), or an IP address and an arbitrary number
Router(config-vrf)# route-target export 100:1 (A.B.C.D:y).
Note This command works only if BGP is running.
Step 7 import map route-map (Optional) Associates a route map with the VRF.
Example:
Router(config-vrf)# import map importmap1
Step 8 exit Returns to global configuration mode.
Example:
Router(config-vrf)# exit
Step 9 interface type slot/subslot/port[.subinterface] Specifies the Layer 3 interface to be associated with the
VRF and enters interface configuration mode.
Example: The interface can be a routed port or an SVI.
Router(config)# interface fastethernet3/0/0.10
Step 10 ip vrf forwarding vrf-name Associates the VRF with the Layer 3 interface.
Example:
Router(config-if)# ip vrf forwarding v1
Step 11 show ip vrf Displays the settings of the VRFs.
Example:
Router# show ip vrf
Configuring BGP as the Routing Protocol

Most routing protocols can be used between the CE and the PE routers. However, external BGP (eBGP)
is recommended, because:
– BGP does not require more than one algorithm to communicate with many CE routers.
– BGP is designed to pass routing information between systems run by different administrations.
– BGP makes it easy to pass attributes of the routes to the CE router.
When BGP is used as the routing protocol, it can also be used to handle the MPLS label exchange
between the PE and CE routers. By contrast, if OSPF, EIGRP, RIP, or static routing is used, LDP must
be used to signal labels.
To configure a BGP PE-to-CE routing session, perform the following steps on the CE and on the PE
routers.
6
SUMMARY STEPS
1. enable
3. router bgp autonomous-system-number
4. network ip-address mask network-mask
5. redistribute ospf process-id match internal
6. network ip-address area area-id
9. neighbor address activate
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 router bgp autonomous-system-number Configures the BGP routing process with the autonomous
system number passed to other BGP routers, and enters router
configuration mode.
Example:
Step 4 network ip-address mask network-mask Specifies a network and mask to announce using BGP.
Example:
mask 255.255.255.0
Step 5 redistribute ospf process-id match internal Sets the router to redistribute OSPF internal routes.
Example:
Router(config-router)# redistribute ospf 2
match internal
Step 6 network ip-address area area-id Identifies the network address and mask on which OSPF is
running, and the area ID of that network address.
Example:
255.255.255.0 area 0
7
Command Purpose
Step 7 address-family ipv4 vrf vrf-name Identifies the name of the VRF instance that will be associated
with the next two commands, and enters VRF address-family
mode.
Example:
Router(config-router)# address-family ipv4
vrf v12
Step 8 neighbor {ip-address | peer-group-name} Informs this router’s BGP neighbor table of the neighbor’s
remote-as as-number address (or peer group name) and the neighbor’s autonomous
system number.
Example:
remote-as 100
Step 9 neighbor address activate Activates the advertisement of the IPv4 address-family
neighbors.
Example:
activate
Configuring PE-to-CE MPLS Forwarding and Signalling with BGP

If BGP is used for routing between the PE and the CE routers, configure BGP to signal the labels on the
VRF interfaces of both the CE and the PE routers. You must enable signalling globally at the router
configuration level and for each interface:
• At the router-configuration level, to enable MPLS label signalling via BGP, use the neighbor
send-label command).
• At the interface level, to enable MPLS forwarding on the interface used for the PE-to-CE eBGP
session, use the mpls bgp forwarding command.
SUMMARY STEPS
1. enable
3. router bgp autonomous-system-number
5. neighbor address send-label
6. neighbor address activate
7. end
10. mpls bgp forwarding
8
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 router bgp autonomous-system-number Configures the BGP routing process with the autonomous
system number passed to other BGP routers and enters router
configuration mode.
Example:
Step 4 address-family ipv4 vrf vrf-name Identifies the name of the VRF instance that will be associated
with the next two commands and enters address family
configuration mode.
Example:
Router(config-router)# address-family ipv4
vrf v12
Step 5 neighbor address send-label Enables the router to use BGP to distribute MPLS labels along
with the IPv4 routes to the peer router(s).
Example: If a BGP session is running when you issue this command, the
Router(config-router-af)# neighbor 10.0.0.3 command does not take effect until the BGP session is
remote-as 100 restarted.
Step 6 neighbor address activate Activates the advertisement of the IPv4 address-family
neighbors.
Example:
activate
Example:
Router(config-router-af)# end
Example:
9
Command Purpose
Step 9 interface type Enters interface configuration mode for the interface to be used
slot/subslot/port[.subinterface] for the BGP session.
The interface can be a routed port or an SVI.
Example:
fastethernet3/0/0.10
Step 10 mpls bgp forwarding Enables MPLS forwarding on the interface.
Example:
Router(config-if)# mpls bgp forwarding
Configuring a Routing Protocol Other than BGP

You can use RIP, EIGRP, OSPF or with static routing. This configuration uses OSPF, but the process is
the same for other protocols. If OSPF, EIGRP, RIP, or static routing is used, LDP must be used to signal
labels.
If you use OSPF as the routing protocol between the PE and the CE routers, issue the capability vrf-lite
command in router configuration mode. See OSPF Support for Multi-VRF in CE Routers for more
information.
Restrictions
If OSPF, EIGRP, RIP, or static routing is used, LDP must be used to signal labels.
The MPLS Multi-VRF feature is not supported by IGRP nor IS-IS.
Multicast cannot be configured on the same Layer 3 interface as the MPLS Multi-VRF feature is
configured.
SUMMARY STEPS
1. enable
3. router ospf process-id [vrf vrf-name]
4. log-adjacency-changes
5. redistribute bgp autonomous-system-number subnets
6. network ip-address subnet-mask area area-id
7. show ip ospf
10
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router ospf process-id [vrf vpn-name] Enables OSPF routing, specifies a VRF table, and enters
Example:
Router(config)# router ospf 100 vrf v1
Step 4 log-adjacency-changes (Optional) Logs changes in the adjacency state.
This is the default state.
Example:
Router(config-router)# log-adjacency-changes
Step 5 redistribute bgp autonomous-system-number Sets the router to redistribute information from the BGP
subnets network to the OSPF network.
Example:
Router(config-router)# redistribute bgp 800
subnets
Step 6 network ip-address subnet-mask area area-id Indicates the network address and mask on which OSPF
runs, and the area ID of that network address.
Example:
255.255.255.0 area 0
Step 7 show ip ospf Displays information about the OSPF routing processes.
Example:
Router# show ip ospf
Configuring PE-to-CE MPLS Forwarding and Signalling with LDP

To configure PE-to-CE MPLS forwarding and signalling with LDP, complete the following steps.
SUMMARY STEPS
1. enable
4. mpls ip
11
Configuration Examples for MPLS Multi-VRF
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/subslot/port[.subinterface] Enters interface configuration mode for the interface
associated with the VRF. The interface can be a routed port
or an SVI.
Example:
Router(config)# interface fastethernet3/0/0.10
Step 4 mpls ip Enables MPLS forwarding of IPv4 packets along normally
routed paths for this interface.
Example:

• Configuring MPLS Multi-VRF on the PE Router: Example, page 13
• Configuring MPLS Multi-VRF on the CE Router, page 14
Figure 2 is an example of an MPLS Multi-VRF topology.
Figure 2 MPLS Multi-VRF Configuration Topology
VPN 1 10.0.0.0
fe3/8/0 PE
10.1.1.1 CE
fe3/7/0 fe3/0/0
Core
fe3/11/0 fe3/0/0
192.168.1.1
fe3/3/0
192842
VPN 2
192.168.10.10
12
Configuring MPLS Multi-VRF on the PE Router: Example

Configuring VRFs
configure terminal
ip vrf v1
rd 100:1
exit
ip vrf v2
rd 100:2
exit
Configuring PE-to-CE Connections Using BGP for Both Routing and Label Exchange
router bgp 100
address-family ipv4 vrf v2
neighbor 10.0.0.8 send-label
exit
address-family ipv4 vrf vl
end
configure terminal
ip vrf forwarding v1
ip address 10.0.0.3 255.255.255.0
mpls bgp forwarding
exit
ip address 10.0.0.3 255.255.255.0
mpls bgp forwarding
exit
Configuring PE-to-CE Connections Using OSPF for Routing and LDP for Label Exchange
router ospf 100 vrf v1
network 10.0.0.0 255.255.255.0 area 0
exit
network 10.0.0.0 255.255.255.0 area 0
exit
ip address 10.0.0.3 255.255.255.0
mpls ip
exit
ip address 10.0.0.3 255.255.255.0
mpls ip
exit
13
Configuring MPLS Multi-VRF on the CE Router

Configuring VRFs
configure terminal
ip routing
ip vrf v11
rd 800:1
exit
ip vrf v12
rd 800:2
exit
Configuring CE Router VPN Connections

ip address 10.0.0.8 255.255.255.0
exit
ip address 10.0.0.8 255.255.255.0
exit
network 10.0.0.0 255.255.255.0 area 0
network 10.0.0.0 255.255.255.0 area 0
exit
network 10.0.0.0 255.255.255.0 area 0
network 10.0.0.0 255.255.255.0 area 0
exit
Note If BGP is used for routing between the PE and CE routers, the BGP-learned routes from the PE router
can be redistributed into OSPF using the commands in the following example.

redistribute bgp 800 subnets
exit
redistribute bgp 800 subnets
exit
Configuring PE-to-CE Connections Using BGP for Both Routing and Label Exchange
router bgp 800
address-family ipv4 vrf v12
exit
address-family ipv4 vrf vl1
end
14
ip address 10.0.0.8 255.255.255.0
mpls bgp forwarding
exit
ip address 10.0.0.8 255.255.255.0
mpls bgp forwarding
exit
Configuring PE-to-CE Connections Using OSPF for Routing and LDP for Label Exchange
network 10.0.0.0 255.255.255.0 area 0
exit
network 10.0.0.0 255.255.255.0 area 0
exit
ip address 10.0.0.3 255.255.255.0
mpls ip
exit
ip address 10.0.0.3 255.255.255.0
mpls ip
exit
The following sections provide references related to the MPLS Multi-VRF feature.
Related Documents
Description of commands associated with MPLS Cisco IOS Multiprotocol Label Switching Command Reference
and MPLS application
OSPF with Multi-VRF OSPF Support for Multi-VRF in CE Routers
Standards
Standard Title
15
MIBs
MIB MIBs Link
RFCs
RFC Title
Description Link
16
Feature Information for MPLS Multi-VRF

Table 1 Feature Information for MPLS Multi-VRF

MPLS Multi-VRF Cisco IOS XE The MPLS Multi-VRF feature allows you to configure and
Release 2.1 maintain more than one instance of a routing and forwarding
table within the same CE router.
• Information About MPLS Multi-VRF, page 2
• How to Configure MPLS Multi-VRF, page 4
countries.
coincidental.
17
18
Multi-VRF Selection Using Policy-Based Routing
(PBR)

The Multi-VRF Selection Using Policy-Based Routing (PBR) feature allows a specified interface on a
provider edge (PE) router to route packets to Virtual Private Networks (VPNs) based on packet length
or match criteria defined in an IP access list.
You can enable VPN routing and forwarding (VRF) selection by policy routing packets through a route
map, through the global routing table, or to a specified VRF.
You can enable policy-routing packets for VRF instances by using route map commands with set
commands.

which each feature is supported, see the “Feature Information for Multi-VRF Selection Using
Policy-Based Routing (PBR)” section on page 17.
Contents
• Prerequisites for Multi-VRF Selection Using Policy-Based Routing (PBR), page 2
• Restrictions for Multi-VRF Selection Using Policy-Based Routing (PBR), page 2
• Information About Multi-VRF Selection Using Policy-Based Routing (PBR), page 2
• How to Configure Multi-VRF Selection Using Policy-Based Routing (PBR), page 5
Multi-VRF Selection Using Policy-Based Routing (PBR)
Prerequisites for Multi-VRF Selection Using Policy-Based Routing (PBR)
• Configuration Examples for Multi-VRF Selection Using Policy-Based Routing (PBR), page 13
• Feature Information for Multi-VRF Selection Using Policy-Based Routing (PBR), page 17
Prerequisites for Multi-VRF Selection Using Policy-Based

Routing (PBR)
• The router must support policy-based routing (PBR) in order for you to configure this feature.
• A VRF must be defined before you configure this feature. An error message is displayed on the
console if no VRF exists.
Restrictions for Multi-VRF Selection Using Policy-Based

Routing (PBR)
• All commands that aid in routing also support hardware switching, except for the set ip next-hop
verify availability command because Cisco Discovery Protocol information is not available in the
line cards.
• Protocol Independent Multicast (PIM) and multicast packets do not support PBR and cannot be
configured for a source IP address that is a match criterion for this feature.
• The set vrf and set ip global next-hop commands can be configured with the set default interface,
set interface, set ip default next-hop, and set ip next-hop commands. But the set vrf and set ip
global next-hop commands take precedence over the set default interface, set interface, set ip
default next-hop, and set ip next-hop commands. No error message is displayed if you attempt to
configure the set vrf command with any of these three set commands.
• The Multi-VRF Selection Using Policy-Based Routing (PBR) feature cannot be configured with IP
prefix lists.
• The set global and set vrf commands cannot be simultaneously applied to a route map.
• The Multi-VRF Selection Using Policy-Based Routing (PBR) feature supports VRF-lite; that is,
only IP routing protocols run on the router. Multiprotocol Label Switching (MPLS) and VPN cannot
be configured.
Information About Multi-VRF Selection Using Policy-Based

Routing (PBR)
Before using the Multi-VRF Selection Using Policy-Based Routing (PBR) feature, you need to
• Policy Routing of VPN Traffic Based on Match Criteria, page 3
• Policy-Based Routing set Commands, page 3
2
Information About Multi-VRF Selection Using Policy-Based Routing (PBR)
Policy Routing of VPN Traffic Based on Match Criteria

The Multi-VRF Selection Using Policy-Based Routing (PBR) feature is an extension of the VRF
Selection Based on Source IP Address feature. The PBR implementation of the VRF selection feature
allows you to policy route VPN traffic based on match criteria. Match criteria are defined in an IP access
list and/or are based on packet length. The following match criteria are supported in Cisco IOS XE
software:
• IP access lists—Define match criteria based on IP addresses, IP address ranges, and other IP packet
access list filtering options. Named, numbered, standard, and extended access lists are supported.
All IP access list configuration options in Cisco IOS XE software can be used to define match
criteria.
• Packet lengths—Define match criteria based on the length of a packet, in bytes. The packet length
filter is defined in a route map with the match length route-map configuration command.
Policy routing is defined in the route map. The route map is applied to the incoming interface with the
ip policy route-map interface configuration command. An IP access list is applied to the route map with
the match ip address route-map configuration command. Packet length match criteria are applied to the
route map with the match length route-map configuration command. The set action is defined with the
set vrf route-map configuration command. The match criteria are evaluated, and the appropriate VRF is
selected by the set command. This combination allows you to define match criteria for incoming VPN
traffic and policy route VPN packets out to the appropriate VRF.
Policy-Based Routing set Commands

The following sections provide information about set commands:
• Policy-routing Packets for VRF Instances, page 3
• Change of Normal Routing and Forwarding Behavior, page 4
• Support of Inherit-VRF, Inter-VRF, and VRF-to-Global Routing, page 4
Policy-routing Packets for VRF Instances

To enable policy-routing packets for VRF instances, you can use route map commands with the
following set commands. They are listed in the order in which the router uses them during the routing
of packets.
• set TOS—Sets the Type of Service (TOS) bits in the header of an IP packet.
• set DF—Sets the Don’t Fragment (DF) bit in the header of an IP packet.
• set vrf—Routes packets through the specified interface. The interface can belong to the global
routing table or to any other VRF instance.
• set global—Routes packets through the global routing table. This command is useful for routing
ingress packets belonging to a specific VRF through the global routing table.
• set ip vrf next-hop—Indicates where to output packets that pass a match criteria of a route map for
policy routing when the next hop must be under a specified VRF.
• set ip global next-hop—Indicates where to forward packets that pass a match criterion of a route
map for policy routing and for which the Cisco IOS XE software uses the global routing table.
3
Information About Multi-VRF Selection Using Policy-Based Routing (PBR)
• set interface—When packets enter a VRF, routes the packets out of the egress interface under the
same VRF according to the set interface policy, provided that the Layer 2 rewrite information is
available.
• set ip default vrf—Provides inherit-VRF and inter-VRF routing. With inherit-VRF routing, packets
arriving at a VRF interface are routed by the same outgoing VRF interface. With inter-VRF routing,
packets arriving at a VRF interface are routed via any other outgoing VRF interface.
• set ip default global—Provides VRF to global routing.
• set default interface—Indicates where to output packets that pass a match criterion of a route map for
policy routing and have no explicit route to the destination. The interface can belong to any VRF.
• set ip global next-hop—Routes packets through the global routing table, where the next hop lookup
will be in the global routing table.
• set ip default next-hop—Indicates where to output packets that pass a match criterion of a route map
for policy routing and for which the Cisco IOS XE software has no explicit route to a destination.
• set ip precedence—Sets the IP precedence bit in the header of an IP packet.
Change of Normal Routing and Forwarding Behavior

When you configure PBR, you can use the following four set commands to change normal routing and
forwarding behavior. Configuring any of these set commands overrides the routing behavior of packets
entering the interface if the packets do not belong to a VRF. The packets are routed from the egress
interface across the global routing table.
• set default interface—Indicates where to output packets that pass a match criterion of a route map for
policy routing and have no explicit route to the destination.
same VRF according to the set interface policy, provided that the Layer 2 rewrite information is
available.
Note The interface must be a peer-to-peer (P2P) interface.
• set ip default next-hop—Indicates where to output packets that pass a match criterion of a route map
for policy routing and for which the Cisco IOS XE software has no explicit route to a destination.
• set ip next-hop—Indicates where to output packets that pass a match criterion of a route map for policy
routing.
Support of Inherit-VRF, Inter-VRF, and VRF-to-Global Routing

The Multi-VRF Selection Using Policy-Based Routing (PBR) feature supports inherit-VRF and
inter-VRF. With inherit-VRF routing, packets arriving at a VRF interface are routed by the same
outgoing VRF interface. With inter-VRF routing, packets arriving at a VRF interface are routed via any
other outgoing VRF interface.
VRF-to-global routing causes packets that enter any VRF interface to be routed via the global routing
table. When a packet arrives on a VRF interface, the destination lookup normally is done only in the
corresponding VRF table. If a packet arrives on a global interface, the destination lookup is done in the
global routing table.
4
How to Configure Multi-VRF Selection Using Policy-Based Routing (PBR)
The Multi-VRF Selection Using Policy-Based Routing (PBR) feature modifies the following set
commands to support inherit-VRF, inter-VRF, and VRF-to-global routing. The commands are listed in
the order in which the router uses them during the routing of packets.
• set global—Routes packets through the global routing table. This command is useful for routing
ingress packets belonging to a specific VRF through the global routing table.
• set ip global next-hop—Indicates where to forward packets that pass a match criterion of a route
map for policy routing and for which the Cisco IOS XE software uses the global routing table.
• set ip vrf next-hop—Causes the router to look up the next hop in the VRF table. If a packet arrives
on an interface that belongs to a VRF and the packet needs to be routed via a different VRF, you can
use the set ip vrf next-hop command.
• set ip default vrf—Provides inherit-VRF and inter-VRF routing. With inherit-VRF routing, packets
arriving at a VRF interface are routed by the same outgoing VRF interface. With inter-VRF routing,
packets arriving at a VRF interface are routed via any other outgoing VRF interface.
same VRF, according to the set interface policy, provided that the Layer 2 rewrite information is
available.
• set default interface—Indicates where to output packets that pass a match criterion of a route map
for policy routing and have no explicit route to the destination. The interface can belong to any VRF.
• set ip next-hop—Routes packets through the global routing table in an IP-to-IP routing and
forwarding environment.
• set vrf—Selects the appropriate VRF after a successful match occurs in the route map. VRS-aware
PSV allows only inter-VRF (or VRF-to-VRF) switching.
How to Configure Multi-VRF Selection Using Policy-Based

Routing (PBR)
• Defining the Match Criteria for Multi-VRF Selection Using PBR, page 5 (required)
• Configuring Multi-VRF Selection in a Route Map, page 8 (required)
• Configuring Multi-VRF Selection Using PBR and IP VRF on the Interface, page 11 (required)
• Verifying the Configuration of Multi-VRF Selection Using PBR, page 12 (optional)
Defining the Match Criteria for Multi-VRF Selection Using PBR

Define the match criteria for multi-VRF selection using PBR so that you can selectively route the packets
instead of using their default routing and forwarding.
The match criteria for multi-VRF selection using PBR are defined in an access list. Standard, named,
and extended access lists are supported. The following sections explain how to configure PBR route
selection:
• Configuring Multi-VRF Selection Using PBR with a Standard Access List, page 6
• Configuring Multi-VRF Selection Using PBR with a Named Extended Access List, page 7
5
You can define the match criteria based on the packet length by configuring the match length route-map
configuration command. This configuration option is defined entirely within a route map.
Prerequisites
The tasks in the following sections assume that the VRF and associated IP address are already defined.
Configuring Multi-VRF Selection Using PBR with a Standard Access List

This procedure uses a standard access list. The access list defines the match criteria for the route map.
The match criteria can be based on IP addresses, IP address ranges, and other IP packet access list
filtering options. Named, numbered, standard, and extended access lists are supported.
SUMARY STEPS
1. enable
3. access-list access-list-number {deny | permit} [source source-wildcard] [log]
6
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 access-list access-list-number {deny | permit} Creates an access list and defines the match criteria for the
[source source-wildcard] [log] route map.
• Match criteria can be defined based on IP addresses, IP
Example: address ranges, and other IP packet access list filtering
Router(config)# access-list 40 permit source options. Named, numbered, standard, and extended
10.1.1.0/24 0.0.0.255
access lists are supported. You can use all IP access list
configuration options in Cisco IOS XE software to
define match criteria.
• The example creates a standard access list numbered
40. This filter permits traffic from any host with an IP
address in the 10.1.1.0/24 subnet.
Configuring Multi-VRF Selection Using PBR with a Named Extended Access List
To configure Multi-VRF Selection using PBR with a named extended access list, complete the following
steps.
SUMMARY STEPS
1. enable
3. ip access-list {standard | extended} [access-list-name | access-list-number]
4. [sequence-number] {permit | deny} protocol source source-wildcard destination
destination-wildcard [option option-value] [precedence precedence] [tos tos] [ttl operator-value]
[log] [time-range time-range-name] [fragments]
7
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip access-list {standard | extended} Specifies the IP access list type and enters the
[access-list-name | access-list-number] corresponding access list configuration mode.
• You can specify a standard, extended, or named access
Example: list.
Router(config)# ip access-list extended
NAMEDACL
Step 4 [sequence-number] {permit | deny} protocol Defines the criteria for which the access list will permit or
source source-wildcard destination deny packets.
destination-wildcard [option
option-value][precedence precedence] [tos tos] • Match criteria can be defined based on IP addresses, IP
[ttl operator-vaue] [log] [time-range address ranges, and other IP packet access list filtering
time-range-name] [fragments]
options. Named, numbered, standard, and extended
access lists are supported. You can use all IP access list
Example: configuration options in Cisco IOS XE software to
Router(config-ext-nacl)# permit ip any any define match criteria.
option any-options
• The example creates a named access list that permits
any configured IP option.
Configuring Multi-VRF Selection in a Route Map

Incoming packets are filtered through the match criteria that are defined in the route map. After a
successful match occurs, the set vrf command configuration determines the VRF through which the
outbound VPN packets will be policy routed.
Prerequisites
You must define the VRF before you configure the route map; otherwise an error message appears on
the console.
A receive entry must be added to the VRF selection table with the ip vrf receive command. If a match
and set operation occurs in the route map but there is no receive entry in the local VRF table, the packet
will be dropped if the packet destination is local.
SUMMARY STEPS
1. enable
3. route-map map-tag [permit | deny] [sequence-number]
8
4. set ip vrf vrf-name next-hop ip-address [... ip-address]

or
set ip next-hop recursive vrf vrf-name ip-address [ip-address]
or
set ip global next-hop ip-address [ip-address]
5. match ip address {acl-number | acl-name | acl-number ]
or
match length minimum-length maximum-length
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 route-map map-tag [permit | deny] Defines the conditions for redistributing routes from one
[sequence-number] routing protocol into another, or enables policy routing.
• Enters route-map configuration mode.
Example:
Router(config)# route-map map1 permit 10
9

Step 4 set ip vrf vrf-name next-hop ip-address Indicates where to output packets that pass a match criterion
[...ip-address] of a route map for policy routing when the next hop must be
under a specified VRF.
or
or
set ip next-hop recursive vrf ip-address [... Indicates which destination or next hop will be used for
ip-address]
packets that pass the match criterion configured in the route
map.
or
set ip global next-hop ip-address [ip-address] or
Indicates where to output packets that pass a match criterion
of a route map for policy routing and for which the
Example:
Router(config-route-map)# set ip vrf myvrf
Cisco IOS XE software uses the global routing table.
next-hop 10.0.0.0
or
Example:
Router(config-route-map)# set ip next-hop
recursive vrf 10.0.0.0
or
Example:
Router(config-route-map)# set ip global
next-hop 10.0.0.0
Step 5 match ip address {acl-number | acl-name | Distributes any routes that have a destination network
acl-number ] number address that is permitted by a standard or extended
access list, and performs policy routing on matched packets.
or
IP access lists are supported.
• The example configures the route map to use standard
access list 1 to define match criteria.
Example: or
Router(config-route-map)# match ip address 1
Specifies the Layer 3 packet length in the IP header as a
or match criterion in a class map.
• The example configures the route map to match packets
Example: that are 3 to 200 bytes in length.
Router(config-route-map)# match length 3 200
Step 6 end Exits route-map configuration mode and returns to
Example:
Router(config-route-map)# end
10
Configuring Multi-VRF Selection Using PBR and IP VRF on the Interface

The route map is attached to the incoming interface with the ip policy route-map interface configuration
command.
The source IP address must be added to the VRF selection table. VRF selection is a one-way
(unidirectional) feature. It is applied to the incoming interface. If a match and set operation occurs in
the route map but there is no receive entry in the local VRF table, the packet is dropped if the packet
destination is local.
SUMMARY STEPS
1. enable
3. interface type number [name-tag]
4. ip policy route-map map-tag
5. ip vrf receive vrf-name
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number [name-tag] Configures an interface and enters interface configuration
mode.
Example:
Step 4 ip policy route-map map-tag Identifies a route map to use for policy routing on an
interface.
Example: • The configuration example attaches the route map
Router(config-if)# ip policy route-map map1 named map1 to the interface.
Step 5 ip vrf receive vrf-name Adds the IP addresses that are associated with an interface
into the VRF table.
Example: • This command must be configured for each VRF that
Router(config-if)# ip vrf receive VRF-1 will be used for VRF selection.
Step 6 end Exits interface configuration mode and returns to privileged
EXEC mode.
Example:
11
Verifying the Configuration of Multi-VRF Selection Using PBR

To verify the configuration of the Multi-VRF Selection Using Policy-Based Routing (PBR) feature,
perform the following steps. You can enter the commands in any order.
SUMMARY STEPS

2. show route-map [map-name]
3. show ip policy
DETAILED STEPS
Step 1 show ip access-list [access-list-number | access-list-name]
To verify the configuration of match criteria for PBR multi-VRF selection, use the show ip access-list
command. The following show ip access-list command output displays three subnet ranges defined as
match criteria in three standard access lists:
Router# show ip access-list

10 permit 10.1.0.0, wildcard bits 0.0.255.255
Step 2 show route-map [map-name]

Use this command to verify match and set commands within the route map:
Router# show route-map
To verify the route-map configuration, use the show route-map command. The output displays the
match criteria and set action for each route-map sequence. The output also displays the number of
packets and bytes that have been policy routed per each route-map sequence.
Router# show route-map map1
route-map map1, permit, sequence 10

Match clauses:
Set clauses:
ip next-hop vrf myvrf 10.5.5.5 10.6.6.6 10.7.7.7
ip next-hop global 10.8.8.8 10.9.9.9
Policy routing matches: 0 packets, 0 bytes

Match clauses:
Set clauses:
vrf myvrf

Match clauses:
12
Configuration Examples for Multi-VRF Selection Using Policy-Based Routing (PBR)
Set clauses:
global
The following show route-map command displays output from the set ip vrf next-hop command:
Router(config)# route-map test
Router(config-route-map)# set ip vrf myvrf next-hop
Router(config-route-map)# set ip vrf myvrf next-hop 192.168.3.2
Router(config-route-map)# match ip address 255 101
route-map test, permit, sequence 10

Match clauses:
ip address (access-lists): 101
Set clauses:
ip vrf myvrf next-hop 192.168.3.2
The following show route-map command displays output from the set ip global command:
Router(config)# route-map test
Router(config-route-map)# match ip address 255 101
Router(config-route-map)# set ip global next-hop 192.168.4.2
*May 25 13:45:55.551: %SYS-5-CONFIG_I: Configured from console by consoleout-map

route-map test, permit, sequence 10
Match clauses:
Set clauses:
ip global next-hop 192.168.4.2
Step 3 show ip policy

To verify the PBR multi-VRF selection policy, use the show ip policy command:
Router# show ip policy
The following show ip policy command output displays the interface and associated route map that is
configured for policy routing:
Interface Route map

FastEthernet0/1/0 PBR-VRF-Selection
Configuration Examples for Multi-VRF Selection Using

Policy-Based Routing (PBR)
• Defining the Match Criteria for Multi-VRF Selection Using PBR: Example, page 14
• Configuring Multi-VRF Selection in a Route Map: Example, page 14
13
Defining the Match Criteria for Multi-VRF Selection Using PBR: Example
In the following example, three standard access lists are created to define match criteria for three
different subnetworks. Any packets received on FastEthernet interface 0/1/0 will be policy routed
through the PBR-VRF-Selection route map to the VRF that is matched in the same route-map sequence.
If the source IP address of the packet is part of the 10.1.0.0/24 subnet, VRF1 will be used for routing
and forwarding.
access-list 40 permit source 10.1.0.0 0.0.255.255
route-map PBR-VRF-Selection permit 10

match ip address 40
set vrf VRF1
!
match ip address 50
set vrf VRF2
!
match ip address 60
set vrf VRF3
!
interface FastEthernet 0/1/0
ip address 192.168.1.6 255.255.255.252
ip vrf forwarding VRF4
ip policy route-map PBR-VRF-Selection
ip vrf receive VRF1
ip vrf receive VRF2
ip vrf receive VRF3
Configuring Multi-VRF Selection in a Route Map: Example

The following example shows a set ip vrf next-hop command that applies policy-based routing to the
VRF interface named myvrf and specifies that the IP address of the next hop is 10.0.0.2:
Router(config)# route-map map1 permit
Router(config)# set vrf myvrf
Router(config-route-map)# set ip vrf myvrf next-hop 10.0.0.2
Router(config-route-map)# match ip address 101
The following example shows a set ip global command that specifies that the router should use the next
hop address 10.0.0.1 in the global routing table:
Router(config-route-map)# set ip global next-hop 10.0.0.1
The following sections provide references related to the Multi-VRF Selection Using Policy-Based
Routing (PBR) feature.
14
Related Documents
MPLS commands: complete command syntax, Cisco IOS Multiprotocol Label Switching Command Reference
command modes, command history, defaults, usage
guidelines, and examples
IP access list commands Cisco IOS Security Command Reference
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
15
Description Link
16
Feature Information for Multi-VRF Selection Using Policy-Based Routing (PBR)
Feature Information for Multi-VRF Selection Using Policy-Based

Routing (PBR)
Table 1 Feature Information for Multi-VRF Selection Using Policy-Based Routing (PBR)

Multi-VRF Selection Using Cisco IOS XE The Multi-VRF Selection Using Policy-Based Routing
Policy-Based Routing (PBR) Release 2.2 (PBR) feature allows a specified interface on a provider
edge (PE) router to route packets to VPNs based on packet
length or match criteria defined in an IP access list. This
feature and the VRF Selection Based on Source IP Address
feature can be configured together on the same interface.
Routers.
The following commands were modified: set ip global, set
ip vrf next-hop, and set vrf.
17
Glossary
Glossary
Inherit-VRF routing—Packets arriving at a VRF interface are routed by the same outgoing VRF
interface.
Inter-VRF routing—Packets arriving at a VRF interface are routed via any other outgoing VRF
interface.
IP—Internet Protocol. Network layer protocol in the TCP/IP stack offering a connectionless
internetwork service. IP provides features for addressing, type-of-service specification, fragmentation
and reassembly, and security. Defined in RFC 791.
PBR—policy-based routing. PBR allows a user to manually configure how received packets should be
routed.
PE router—provider edge router. A router that is part of a service provider’s network and that is
connected to a CE router. It exchanges routing information with CE devices by using static routing or a
routing protocol such as BGP, RIPv1, or RIPv2.
VPN—Virtual Private Network. A collection of sites sharing a common routing table. A VPN provides
a secure way for customers to share bandwidth over an ISP backbone network.
VRF—A VPN routing and forwarding instance. A VRF consists of an IP routing table, a derived
forwarding table, a set of interfaces that use the forwarding table, and a set of rules and routing protocols
that determine what goes into the forwarding table.
VRF-lite—A feature that enables a service provider to support two or more VPNs, where IP addresses
can be overlapped among the VPNs.
countries.
coincidental.
© 2007–2008 Cisco Systems, Inc. All rights reserved
18
MPLS VPN: VRF Selection Using Policy-Based
Routing

The MPLS VPN: VRF Selection Using Policy-Based Routing feature is an extension of the MPLS VPN:
VRF Selection Based on Source IP Address feature. This feature introduces a policy-based routing
(PBR) mechanism to classify and forward Virtual Private Network (VPN) traffic based on multiple VPN
routing and forwarding (VRF) selection match criteria.

which each feature is supported, use the “Feature Information for VRF Selection Using Policy-Based
Routing” section on page 14.
Contents
• Prerequisites for VRF Selection Using Policy-Based Routing, page 2
• Restrictions for VRF Selection Using Policy-Based Routing, page 2
• Information About VRF Selection Using Policy-Based Routing, page 2
• How to Configure VRF Selection Using Policy-Based Routing, page 3
• Configuration Examples for VRF Selection Using Policy-Based Routing, page 10
• Feature Information for VRF Selection Using Policy-Based Routing, page 14
MPLS VPN: VRF Selection Using Policy-Based Routing
Prerequisites for VRF Selection Using Policy-Based Routing
• Feature Information for VRF Selection Using Policy-Based Routing, page 14

Prerequisites for VRF Selection Using Policy-Based Routing

The router must support PBR.
A VRF must be defined prior to the configuration of this feature. An error message is displayed on the
console if no VRF exists.
This document assumes that multiprotocol BGP (mBGP), Multiprotocol Label Switching (MPLS), and
Cisco Express Forwarding are enabled in your network.
Restrictions for VRF Selection Using Policy-Based Routing

The VRF Selection Using Policy-Based Routing feature is supported only in service provider (-p-)
images.
The VRF Selection Using Policy-Based Routing feature can coexist with the VRF Selection Based on
Source IP address feature on the same router, but these features cannot be configured together on the
same interface. This is designed behavior to prevent VRF table selection conflicts that could occur if
these features were misconfigured together. An error message is displayed on the console if you attempt
to configure the ip vrf select source and the ip policy route-map commands on the same interface.
Protocol Independent Multicast (PIM) and multicast packets do not support PBR and cannot be
configured for a source IP address that is a match criterion for this feature.
The VRF Selection Using Policy-Based Routing feature cannot be configured with IP prefix lists.
Information About VRF Selection Using Policy-Based Routing

Before configuring VRF Selection Using Policy-Based Routing, you should understand the following
concepts:
• Introduction to VRF Selection Using Policy-Based Routing, page 2
• Policy-Based Routing Set Clauses: Overview, page 3
Introduction to VRF Selection Using Policy-Based Routing

The VRF Selection Using Policy-Based Routing feature is an extension of the VRF Selection Based on
Source IP Address feature. The PBR implementation of the VRF selection feature allows you to policy
route VPN traffic based on match criteria. Match criteria are defined in an IP access list or based on
packet length. The following match criteria are supported in Cisco IOS XE software:
• IP access lists—Define match criteria based on IP addresses, IP address ranges, and other IP packet
access list filtering options. Named, numbered, standard, and extended access lists are supported.
All IP access-list configuration options in Cisco IOS XE software can be used to define match
criteria.
• Packet lengths—Define match criteria based on the length of a packet in bytes. The packet length
filter is defined in a route map with the match length route-map configuration command.
2
How to Configure VRF Selection Using Policy-Based Routing
Policy routing is defined in the route map. The route map is applied to the incoming interface with the
ip policy route-map interface configuration command. An IP access list is applied to the route map with
the match ip address route-map configuration command. Packet length match criteria are applied to the
route map with the match length route-map configuration command. The set action is defined with the
set vrf route-map configuration command. The match criteria are evaluated, and the appropriate VRF is
selected by the set clause. This combination allows you to define match criteria for incoming VPN traffic
and policy route VPN packets out to the appropriate VRF.
Policy-Based Routing Set Clauses: Overview

When you are configuring PBR, the following four set clauses can be used to change normal routing and
forwarding behavior:
• set default interface
• set interface
• set ip default next-hop
• set ip next-hop
Configuring any of the set clauses will overwrite normal routing forwarding behavior of a packet.
The VRF Selection Using Policy-Based Routing feature introduces the fifth set clause that can be used
to change normal routing and forwarding behavior. The set vrf command is used to select the appropriate
VRF after the successful match occurs in the route map.

• Defining the Match Criteria for PBR VRF Selection, page 3 (required)
• Configuring PBR VRF Selection in a Route Map, page 5 (required)
• Configuring PBR on the Interface, page 7 (required)
• Configuring IP VRF Receive on the Interface, page 8 (required)
• Verifying the Configuration of the VRF Selection Using Policy-Based Routing, page 9 (optional)
Defining the Match Criteria for PBR VRF Selection

The match criteria for PBR VRF route selection are defined in an access list. Standard and named access
lists are supported. The following sections explain how to configure PBR route selection:
• Configuring PBR VRF Selection with a Standard Access List, page 4 (required)
• Configuring PBR VRF Selection with a Named Access List, page 4 (required)
Match Criteria Defined Based on Packet Length

Match criteria can also be defined based on the packet length using the match length route-map
configuration command. This configuration option is defined entirely within a route map.
3
Prerequisites
Before you perform this task, make sure that the VRF and associated IP address are already defined.
Configuring PBR VRF Selection with a Standard Access List

Use the following commands to create a standard access list and define the PBR VRF route selection
match criteria in it in order to permit or deny the transmission of VPN traffic data packets.
SUMMARY STEPS
1. enable
3. access-list access-list-number {deny | permit} source-addr [source-wildcard] [log]
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 access-list access-list-number {deny | permit} Creates an access list and defines the match criteria for the
source-addr [source-wildcard] [log] route map.
• Match criteria can be defined based on IP addresses, IP
Example: address ranges, and other IP packet access-list filtering
Router(config)# access-list 40 permit options. Named, numbered, standard, and extended
10.1.0.0/24 0.0.0.255
access lists are supported. All IP access list
configuration options in Cisco IOS XE software can be
used to define match criteria.
• The example creates a standard access list numbered
40. This filter will permit traffic from any host with an
IP address in the 10.1.0.0/24 subnet.
Configuring PBR VRF Selection with a Named Access List

Use the following commands to define the PBR VRF route selection match criteria in a named access
list in order to permit or deny the transmission of VPN traffic data packets.
SUMMARY STEPS
1. enable
4
3. ip access-list {standard | extended} [access-list-name | access-list-number]

4. [sequence-number] {permit | deny} protocol source-addr source-wildcard destination-addr
destination-wildcard [option option-value] [precedence precedence] [tos tos] [log] [time-range
time-range-name] [fragments]
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip access-list {standard | extended} Specifies the IP access list type and enters the
[access-list-name | access-list-number] corresponding access-list configuration mode.
• A standard, extended, or named access list can be used.
Example:
Router(config)# ip access-list extended
NAMEDACL
Step 4 [sequence-number] {permit | deny} protocol Defines the criteria for which the access list will permit or
source-addr source-wildcard destination-addr deny packets.
destination-wildcard [option
option-value][precedence precedence] [tos tos] • Match criteria can be defined based on IP addresses, IP
[log] [time-range time-range-name] [fragments] address ranges, and other IP packet access-list filtering
options. Named, numbered, standard, and extended
Example: access lists are supported. All IP access-list
Router(config-ext-nacl)# permit ip any any configuration options in Cisco IOS XE software can be
option any-options used to define match criteria.
• The example creates a named access list that permits
any configured IP option.
Configuring PBR VRF Selection in a Route Map

Use the following commands to configure the VRF through which the outbound VPN packets will be
policy routed in order to permit or deny the transmission of VPN traffic data packets.
Incoming packets are filtered through the match criteria that are defined in the route map. After a
successful match occurs, the set vrf command configuration determines the VRF through which the
outbound VPN packets will be policy routed.
5
Prerequisites
• The VRF must be defined prior to the configuration of the route map; otherwise an error message is
displayed on the console.
• A receive entry must be added to the VRF selection table with the ip vrf receive command. If a
match and set operation occurs in the route map but there is no receive entry in the local VRF table,
the packet will be dropped if the packet destination is local.
SUMMARY STEPS
1. enable
3. route-map map-tag [permit | deny] [sequence-number]
4. match ip address {acl-number [acl-number ... | acl-name ...] | acl-name
[acl-name ... | acl-number ...]}
or
5. set vrf vrf-name
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 route-map map-tag [permit | deny] Enters route map configuration mode.
[sequence-number]
Defines the conditions for redistributing routes from one
routing protocol into another, or enables policy routing.
Example:
Router(config)# route-map map1 permit 10
6

Step 4 match ip address {acl-number [acl-number ... | Distributes any routes that have a destination network
acl-name ...] | acl-name [acl-name ... | number address that is permitted by a standard or extended
acl-number ...]}
access list, and performs policy routing on matched packets.
or
• IP access lists are supported.
• The example configures the route map to use standard
access list 1 to define match criteria.
Example:
Router(config-route-map)# match ip address 1 or
or
Specifies the Layer 3 packet length in the IP header as a
match criterion in a class map.
Example: • The example configures the route map to match packets
Router(config-route-map)# match length 3 200
that are 3 to 200 bytes in size.
Step 5 set vrf vrf-name Defines which VRF to route VPN packets that are
successfully matched in the same route map sequence for
PBR VRF selection.
Example:
Router(config-route-map)# set vrf map1 • The example policy routes matched packets out to the
VRF named map1.
Step 6 exit Exits route-map configuration mode and enters global
configuration mode.
Example:
Router(config-route-map)# exit
Configuring PBR on the Interface

Use the following commands to filter incoming VPN traffic data packets. Incoming packets are filtered
through the match criteria that are defined in the route map.
The route map is applied to the incoming interface. The route map is attached to the incoming interface
with the ip policy route-map global configuration command.
Restrictions
• The VRF Selection Using Policy-Based Routing feature can coexist with the VRF Selection Based
on Source IP address feature on the same router, but the two features cannot be configured together
on the same interface. This is designed behavior to prevent VRF table selection conflicts that could
occur if these features were misconfigured together. An error message is displayed on the console
if you attempt to configure the ip vrf select source and the ip policy route-map commands on the
same interface.
SUMMARY STEPS
1. enable
7

6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number [name-tag] Configures an interface and enters interface configuration
mode.
Example:
Step 4 ip policy route-map map-tag Identifies a route map to use for policy routing on an
interface.
Example: • The configuration example attaches the route map
Router(config-if)# ip policy route-map map1 named map1 to the interface.
Step 5 ip vrf receive vrf-name Adds the IP addresses that are associated with an interface
into the VRF table.
Example: • This command must be configured for each VRF that
Router(config-if)# ip vrf receive VRF1 will be used for VRF selection.
configuration mode.
Example:
Configuring IP VRF Receive on the Interface

Use the following commands to insert the IP address of an interface as a connected route entry in a VRF
routing table. This will prevent dropped packets.
The source IP address must be added to the VRF selection table. VRF selection is a one-way
(unidirectional) feature. It is applied to the incoming interface. If a match and set operation occurs in the
route map but there is no VRF receive entry in the local VRF table, the packet will be dropped if the
packet destination is local.
SUMMARY STEPS
1. enable
8

6. end
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface type number [name-tag] Configures an interface and enters interface configuration mode.
Example:
FastEthernet 0/1/0
Step 4 ip policy route-map map-tag Identifies a route map to use for policy routing on an interface.
• The configuration example attaches the route map named
Example: map1 to the interface.
Router(config-if)# ip policy route-map
map1
Step 5 ip vrf receive vrf-name Adds the IP addresses that are associated with an interface into
the VRF table.
Example: • This command must be configured for each VRF that will be
Router(config-if)# ip vrf receive VRF1 used for VRF selection.
Step 6 end Exits interface configuration mode, and enters privileged EXEC
mode.
Example:
Verifying the Configuration of the VRF Selection Using Policy-Based Routing

To verify the configuration of the VRF Selection Using Policy-Based Routing feature, perform each of
the following steps in this section in the order specified.
SUMMARY STEPS
1. enable
3. show route-map [map-name]
4. show ip policy
9
Configuration Examples for VRF Selection Using Policy-Based Routing
DETAILED STEPS

Example:
Router> enable
Step 2 show ip access-list [access-list-number | Displays the contents of all current IP access lists.
access-list-name]
• This command is used to verify the match criteria that
are defined in the access list. Both named and
Example: numbered access lists are supported.
Step 3 show route-map [map-name] Displays all route maps configured or only the one
specified.
Example: • This command is used to verify match and set clauses
Router# show route-map within the route map.
Step 4 show ip policy Displays the route map used for policy routing.
• This command can be used to display the route map and
Example: the associated interface.
Configuration Examples for VRF Selection Using Policy-Based

Routing
• Defining PBR VRF Selection in Access List: Example, page 10
• Verifying VRF Selection Using Policy-Based Routing: Example, page 11
Defining PBR VRF Selection in Access List: Example

In the following example, three standard access lists are created to define match criteria for three
different subnets. Any packets received on the FastEthernet 0/1/0 interface will be policy routed through
the PBR-VRF-Selection route map to the VRF that is matched in the same route map sequence. If the
source IP address of the packet is part of the 10.1.0.0/24 subnet, VRF1 will be used for routing and
forwarding.
access-list 40 permit 10.1.0.0 0.0.255.255


match ip address 40
set vrf VRF1
!
match ip address 50
set vrf VRF2
10
Configuration Examples for VRF Selection Using Policy-Based Routing
!
match ip address 60
set vrf VRF3
!
ip address 10.1.0.0/24 255.255.255.252
ip policy route-map PBR-VRF-Selection
ip vrf receive VRF1
ip vrf receive VRF2
ip vrf receive VRF3
Verifying VRF Selection Using Policy-Based Routing: Example

The following verification examples show defined match criteria and route-map policy configuration.
Verifying Match Criteria

To verify the configuration of match criteria for PBR VRF selection, use the show ip access-list
command.
The following show ip access-list command output displays three subnet ranges defined as match
criteria in three standard access lists:

Verifying Route-Map Configuration

To verify route-map configuration, use the show route-map command. The output displays the match
criteria and set action for each route-map sequence. The output also displays the number of packets and
bytes that have been policy routed per each route-map sequence.
route-map PBR-VRF-Selection, permit, sequence 10

Match clauses:
Set clauses:
vrf VRF1
Match clauses:
Set clauses:
vrf VRF2
Match clauses:
Set clauses:
vrf VRF3
11
Verifying PBR VRF Selection Policy

The following show ip policy command output displays the interface and associated route map that is
configured for policy routing:
Interface Route map

FastEthernet0/1/0 PBR-VRF-Selection
The following sections provide references related to the MPLS VPN: VRF Selection Using Policy-Based
Routing feature.
Related Documents
MPLS commands: complete command syntax, Cisco IOS Multiprotocol Label Switching Command Reference
command modes, command history, defaults, usage
Route-map configuration commands Cisco IOS IP Routing Protocols Command Reference
Standards
Standard Title
MIBs
MIB MIBs Link
feature, and support for existing MIBs has not been software releases , and feature sets, use Cisco MIB Locator found at
12
RFCs
RFC Title
Description Link
13
Feature Information for VRF Selection Using Policy-Based Routing
Feature Information for VRF Selection Using Policy-Based

Routing
Table 1 Feature Information for VRF Selection Using Policy-Based Routing

MPLS VPN: VRF Selection Using Cisco IOS XE The MPLS VPN: VRF Selection Using Policy-Based
Policy-Based Routing Release 2.2 Routing feature is an extension of the MPLS VPN: VRF
Selection Based on Source IP Address feature. This feature
introduces a policy-based routing (PBR) mechanism to
classify and forward Virtual Private Network (VPN) traffic
based on multiple VPN routing and forwarding (VRF)
selection match criteria.
ip vrf receive, set vrf.
14
Glossary
Glossary
PBR—policy-based routing.
VPN—Virtual Private Network.
VRF—virtual routing and forwarding.
countries.
coincidental.
15
Glossary
16
VRF Aware System Message Logging (Syslog)

The VRF Aware System Message Logging (Syslog) feature allows a router to send system logging
(syslog) messages to a syslog server host connected through a Virtual Private Network (VPN) routing
and forwarding (VRF) interface.
You can use logging information for network monitoring and troubleshooting. This feature extends this
capability to network traffic connected through VRFs.

which each feature is supported, use the “Feature Information for VRF Aware System Message Logging”
section on page 14.
Contents
• Prerequisites for VRF Aware System Message Logging, page 2
• Restrictions for VRF Aware System Message Logging, page 2
• Information About VRF Aware System Message Logging, page 2
• How to Configure and Verify VRF Aware System Message Logging, page 5
• Configuration Examples for VRF Aware System Message Logging, page 11
Prerequisites for VRF Aware System Message Logging
• Feature Information for VRF Aware System Message Logging, page 14

Prerequisites for VRF Aware System Message Logging

You must configure a VRF on a routing device and associate the VRF with an interface (see the
“Associating a VRF with an Interface” section on page 7) before you can configure the VRF Aware
System Message Logging feature.
Restrictions for VRF Aware System Message Logging

You cannot specify a source address for VRF system logging messages. The VRF Aware System
Message Logging feature uses the VRF interface address as the source address for all VRF-aware system
logging messages.
Information About VRF Aware System Message Logging

You should understand the following concepts before configuring the VRF Aware System Message
Logging feature:
• VRF Aware System Message Logging Benefit—Monitoring and Troubleshooting Network Traffic
Connected Through a VRF, page 2
• VRF Aware System Message Logging on a Provider Edge Router in an MPLS VPN Network, page 3
• VRF Aware System Message Logging on a Customer Edge Device with VRF-Lite Configured,
page 3
• Message Levels for Logging Commands, page 4
VRF Aware System Message Logging Benefit—Monitoring and

Troubleshooting Network Traffic Connected Through a VRF
A VPN routing and VRF instance is an extension of IP routing that provides multiple routing instances.
A VRF provides a separate IP routing and forwarding table to each VPN. You must configure a VRF on
a routing device before you configure the VRF Aware System Message Logging feature.
After you configure the VRF Aware System Message Logging feature on a routing device, the device
can send syslog messages to a syslog host through a VRF interface. Then you can use logging messages
to monitor and troubleshoot network traffic connected through a VRF. Without the VRF Aware System
Message Logging feature on a routing device, you do not have this benefit; the routing device can send
syslog messages to the syslog host only through the global routing table.
2
You can receive system logging messages through a VRF interface on any router where you can
configure a VRF, that is:
• On a provider edge (PE) router that is used with Multiprotocol Label Switching (MPLS) and
multiprotocol Border Gateway Protocol (BGP) to provide a Layer 3 MPLS VPN network service.
• On a customer edge (CE) device (switch or router) that is configured for VRF-Lite, which is a VRF
implementation without multiprotocol BGP.
VRF Aware System Message Logging on a Provider Edge Router in an MPLS

VPN Network
You can configure the VRF Aware System Message Logging feature on a PE router in a Layer 3 MPLS
VPN network. The PE router can then send syslog messages through a VRF interface to a syslog server
located in the VPN.
Figure 1 shows an MPLS VPN network and the VRF Aware System Message Logging feature configured
on a PE router associated with VRF VPN1. The PE router sends log messages through a VRF interface
to a syslog server located in VPN1. You can display the messages from the syslog server on a terminal.
Figure 1 MPLS VPN and VRF Aware System Message Logging Configured on a Customer Edge
Router
Syslog server MPLS core CE2

CE1 PE1 PE2
VPN1 VRF router Global routing table
146382
Log file display
VRF Aware System Message Logging on a Customer Edge Device with VRF-Lite
Configured
You can configure the VRF Aware System Message Logging feature on a CE device where you have
configured the VRF-Lite feature. The CE device can then send syslog messages through a VRF interface
to syslog servers in multiple VPNs. The CE device can be either a router or a switch.
Figure 2 shows the VRF Aware System Message Logging feature configured on a VRF-Lite CE device.
The CE device can send VRF syslog messages to syslog servers in VPN1 or VPN2 or to servers in both
VPN1 and VPN2. You can configure multiple VRFs on a VRF-Lite CE device, and the device can serve
many customers.
3
Figure 2 VRF Aware System Message Logging Configured on a VRF-Lite Customer Edge
Device
R1
Syslog server1
VPN1
CE Log file display
VRF-lite
VRF router
device R2
VPN2
Syslog server2
146383
Log file display
Message Levels for Logging Commands

Table 1 lists message levels for logging commands that you can use when you configure the VRF Aware
System Message Logging feature. Information provided by Table 1 includes keyword level names and
numbers, their description, and the associated syslog definitions. You can use either the level keyword
name or number with the logging trap level and logging buffered severity-level commands.
Table 1 Message Levels for logging Commands
Level Name Level Number Description Syslog Definition

emergencies 0 System unusable LOG_EMERG
alerts 1 Immediate action needed LOG_ALERT
critical 2 Critical conditions LOG_CRIT
errors 3 Error conditions LOG_ERR
warnings 4 Warning conditions LOG_WARNING
notifications 5 Normal but significant condition LOG_NOTICE
informational 6 Informational messages only LOG_INFO
debugging 7 Debugging messages LOG_DEBUG
4
How to Configure and Verify VRF Aware System Message Logging
How to Configure and Verify VRF Aware System Message

Logging
• Configuring a VRF on a Routing Device, page 5 (required)
• Associating a VRF with an Interface, page 7 (required)
• Configuring VRF Aware System Message Logging on a Routing Device, page 8 (required)
• Verifying VRF Aware System Message Logging Operation, page 9 (optional)
Configuring a VRF on a Routing Device

Configuring a VRF on a routing device helps provides customer connectivity to a VPN. The routing
device can be a PE router connected to an MPLS VPN network or a CE (switch or router) that is
configured for VRF-Lite.
SUMMARY STEPS
1. enable
3. ip vrf-name
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip vrf vrf-name Defines a VRF and enters VRF configuration mode.
• The vrf-name argument is a name assigned to the VRF.
Example:
5

Step 4 rd route-distinguisher Creates routing and forwarding tables for a VRF.
• The route-distinguisher argument adds an 8-byte value
Example: to an IPv4 prefix to create a VPN IPv4 prefix.
Router(config-vrf)# rd 100:1
• The route distinquisher (RD) is either an autonomous
system number (ASN)-relative RD, in which case it is
composed of an autonomous system number and an
arbitrary number, or it is an IP-address-relative RD, in
which case it is composed of an IP address and an
arbitrary number.
• You can enter an RD in either of these formats:
– 16-bit autonomous system number: your 32-bit
number
For example, 101:3.
– 32-bit IP address: your 16-bit number
For example, 10.0.0.1:1.
Step 5 route-target {import | export | both} Creates a route-target extended community for a VRF.
• The import keyword imports routing information from
the target VPN extended community.
Example:
Router(config-vrf)# route-target both 100:1
• The export keyword exports routing information to the
target VPN extended community.
• The both keyword imports routing information from
and exports routing information to the target VPN
extended community.
VRF's list of import, export, or both (import and export)
route-target extended communities.
The route target specifies a target VPN extended
community. Like a route distinguisher, an extended
community is composed of either an autonomous system
number and an arbitrary number or an IP address and an
arbitrary number. You can enter the numbers in either of
these formats:
• 16-bit autonomous system 1 32-bit number
For example, 101:3.
• 32-bit IP address: your 16-bit number
For example, 10.0.0.2.15: 1.
Example:
Router(config-vrf)# end
6
Associating a VRF with an Interface

Perform this task to associate a VRF instance with an interface. A VRF must be associated with an
interface before you can forward VPN traffic.
Note You cannot configure a source address for VRF system logging messages. The VRF Aware System
Message Logging feature uses the VRF interface address as the source address for all VRF-aware system
logging messages.
After configuring the VRF and associating it with an interface, you can configure the VRF Aware System
Message Logging feature on the routing device.
SUMMARY STEPS
1. enable
5. end
6. copy running-config startup-config
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example: • The type argument is the type of interface to be
Router(config)# interface FastEthernet 0/0/0 configured.
• The number argument is the port, connector, or
interface card number. The numbers are assigned at the
factory at the time of installation or when the port,
connector, or interface card is added to a system, and
can be displayed with the show interfaces command.
Step 4 ip vrf forwarding vrf-name Associates a VRF with an interface or subinterface.
• The vrf-name argument associates the interface with
Example: the specified VRF.
Router(config-if)# ip vrf forwarding vpn1
7

Example:
Step 6 copy running-config startup-config (Optional) Saves configuration changes to NVRAM.
Example:
Router# copy running-config startup-config
Configuring VRF Aware System Message Logging on a Routing Device

Configure the VRF Aware System Message Logging feature on a routing device so that logging
messages can be used to monitor and troubleshoot network traffic connected through VRF instances.
Prerequisites
You must perform the following tasks before you perform this task:
• Configuring a VRF on a Routing Device, page 5
• Associating a VRF with an Interface, page 7
SUMMARY STEPS
1. enable
3. logging host {ip-address | hostname} [vrf vrf-name]
4. logging trap level
5. logging facility facility-type
6. logging buffered [buffer-size | severity-level]
7. end
DETAILED STEPS

Example:
Router> enable
Example:
8

Step 3 logging host {ip-address | hostname} [vrf Specifies a host to receive syslog messages.
vrf-name]
• The ip-address argument is the IP address of the syslog
server host.
Example:
Router(config)# logging host 10.0.150.63 vrf
• The hostname argument is the name of the IP or IPv6
vpn1 host that receives the syslog messages.
• The vrf vrf-name keyword argument pair specifies a
VRF that connects to the syslog server host.
Step 4 logging trap level Limits messages logged to the syslog servers based on
severity.
Example: • The level argument limits the logging of messages to
Router(config)# logging trap debugging the syslog servers to a specified level. You can enter the
level number or level name. See Table 1 for a
description of acceptable keywords.
Step 5 logging facility facility-type (Optional) Configures the syslog facility in which error
messages are sent.
Example: • The facility-type argument names the syslog facility
Router(config)# logging facility local6 type keyword. For locally defined messages, the range
of acceptable keywords is local0 to local7. The default
is local7.
Step 6 logging buffered [buffer-size | severity-level] (Optional) Limits messages logged to an internal buffer on
the router based on severity.
Example: • The buffer-size argument is the size of the buffer from
Router(config)# logging buffered debugging 4096 to 4,294,967,295 bytes. The default size varies by
platform.
• The severity-level argument limits the logging of
messages to the buffer to a specified level. You can
enter the level name or level number. See Table 1 for a
list of the acceptable level name or level number
keywords. The default logging level varies by platform,
but is generally 7, meaning that messages at all
levels (0–7) are logged to the buffer.
Example:
Router(config)# end
Verifying VRF Aware System Message Logging Operation

Perform this task to verify VRF Aware System Message Logging operation.
SUMMARY STEPS
1. enable
2. show running-config | include logging
9
3. show ip vrf interfaces

4. show running-config [interface type number]
5. ping vrf vrf-name target-ip-address
6. exit
DETAILED STEPS
Step 1 enable
Use this command to enable privileged EXEC mode. You can also enter this command in user EXEC
mode. Enter your password if prompted. For example:
Router> enable
Router#
Step 2 show running-config | include logging

Use this command to display the logging configuration for the router and the logging host for a VRF.
For example:
Router# show running-config | include logging
logging queue-limit 100

logging buffered 100000 debugging
mpls ldp logging neighbor-changes
logging trap debugging
logging facility local6
logging host vrf vpn1 10.0.0.3
Router#
This example shows the configuration of a syslog server in VRF vpn1 with a server host address of
10.0.0.3.
Step 3 show ip vrf interfaces
Use this command to display the interfaces associated with the VRF that links to a syslog server host.
The following example displays a list of VRF interfaces and their associated IP addresses that are
configured on the router:
Router# show ip vrf interfaces
Interface IP-Address VRF Protocol

FastEthernet0/0/0 10.0.0.0 vpn1 up
Loopback1 10.0.0.6 vpn1 up
Step 4 show running-config [interface type number]

Use this command to display interface specific configuration information for an interface associated
with a VRF. For example:
Router# show running-config interface FastEthernet 0/0/0
Router#
.
.
.
!
!
10
Configuration Examples for VRF Aware System Message Logging
ip address 10.0.0.98 255.0.0.0
duplex half
no cdp enable
end
This example displays configuration information for Fast Ethernet interface 0/0/0 in VRF vpn1.
Step 5 ping vrf vrf-name target-ip-address
Use this command to verify that you can reach the syslog server host, the target-ip-address, through the
specified VRF. For example:
Router# ping vrf vpn1 10.3.0.1

Sending 5, 100-byte ICMP Echos to 10.3.0.1, timeout is 2 seconds:
.!!!!
In this example, the syslog server has an IP address of 10.3.0.1 and the VRF is named vpn1. The server
is reached successfully four of five times.
Step 6 exit
Use this command to exit privileged EXEC mode. For example:
Router# exit
Router>
Configuration Examples for VRF Aware System Message

Logging
This section contains the following configuration examples for the VRF Aware System Message
Logging feature:
• Configuring a VRF on a Routing Device: Example, page 11
• Associating a VRF with an Interface: Example, page 12
• Configuring VRF Aware System Message Logging on a Routing Device: Example, page 12
Configuring a VRF on a Routing Device: Example

The following example shows how to configure a VRF on a routing device:
enable
configure terminal
!
ip vrf vpn1
rd 100:1
route-target both 100:1
end
11
Associating a VRF with an Interface: Example

The following example shows how to associate a VRF with an interface:
enable
configure terminal
!
interface FastEthernet 0/0/0
end
Configuring VRF Aware System Message Logging on a Routing Device:

Example
The following example shows how to configure the VRF Aware System Message Logging feature on a
routing device. The IP address of the syslog server host is 10.0.1.3 and the VRF is vpn1.
enable
configure terminal
!
logging host 10.0.1.3 vrf vpn1
logging trap debugging
logging facility local6
logging buffered 10000
logging buffered debugging
end
The following example shows how to turn off logging to the syslog server:
enable
configure terminal
!
no logging 10.0.1.3
end
The following sections provide references related to configuring the VRF Aware System Message
Logging feature.
Related Documents
MPLS applications
Concepts and tasks for configuring MPLS VPNs Configuring MPLS Layer 3 VPNs
12
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
Description Link
13
Feature Information for VRF Aware System Message Logging
Feature Information for VRF Aware System Message Logging

Note Table 2 Use Cisco Feature Navigator to find information about platform support and software image
support. Cisco Feature Navigator enables you to determine which Cisco IOS XE software images
support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to
Table 2 Feature Information for VRF Aware System Message Logging

VRF Aware System Message Logging Cisco IOS XE The VRF Aware System Message Logging feature allows
(Syslog) Release 2.2 a router to send syslog messages to a syslog server host
connected through a VPN VRF interface.
Routers.
The following command was modified: logging host.
14
Glossary
Glossary
CE router—customer edge router. A router on the border between a VPN provider and a VPN customer
that belongs to the customer.
LSR—label switching router. A device that forwards MPLS packets based on the value of a fixed-length
label encapsulated in each packet.
MPLS VPN—Multiprotocol Label Switching Virtual Private Network. An IP network infrastructure
delivering private network services over a public infrastructure using a Layer 3 backbone. Using MPLS
VPNs in a Cisco IOS XE network provides the capability to deploy and administer scalable Layer 3 VPN
backbone services including applications, data hosting network commerce, and telephony services to
business customers.
PE router—provider edge router. A router on the border between a VPN provider and a VPN customer
that belongs to the provider.
VPN—Virtual Private Network. A group of sites that, as the result of a set of administrative policies, are
able to communicate with each other over a shared backbone network. A VPN is a secure IP-based
network that shares resources on one or more physical networks. A VPN contains geographically
dispersed sites that can communicate securely over a shared backbone. See also MPLS VPN.
VRF—VPN routing and forwarding instance. A VRF consists of an IP routing table, a derived
that determine what goes into the forwarding table. In general, a VRF includes the routing information
that defines a customer VPN site that is attached to a PE router.
countries.
coincidental.
15
Glossary
16
MPLS VPN—L3VPN over GRE
First Published: September 29, 2008

Last Updated: February 27, 2009
The MPLS VPN—L3VPN over GRE feature provides a mechanism for tunneling Multiprotocol Label
Switching (MPLS) packets over a non-MPLS network.
The MPLS VPN—L3VPN over GRE feature utilizes MPLS over generic routing encapsulation
(MPLSoGRE) to encapsulate MPLS packets inside IP tunnels. This action creates a virtual
point-to-point link across non-MPLS networks.

Your software release may not support all the features documented in this module. For the latest feature
information and caveats, see the release notes for your platform and software release. To find information
about the features documented in this module, and to see a list of the releases in which each feature is
supported, see the “Feature Information for MPLS VPN—L3VPN over GRE” section on page 10.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS and Catalyst OS
software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An
account on Cisco.com is not required.
Contents
• Prerequisites for MPLS VPN—L3VPN over GRE, page 2
• Restrictions for MPLS VPN—L3VPN over GRE, page 2
• Information About MPLS VPN—L3VPN over GRE, page 2
• How to Configure MPLS VPN—L3VPN over GRE, page 4
• Configuration Examples for MPLS VPN—L3VPN over GRE, page 6
• Command Reference, page 9
• Feature Information for MPLS VPN—L3VPN over GRE, page 10
Prerequisites for MPLS VPN—L3VPN over GRE
Prerequisites for MPLS VPN—L3VPN over GRE

Before you configure the MPLS VPN—L3VPN over GRE feature, ensure that your MPLS Virtual
Private Network (VPN) is configured and working properly. See the Configuring MPLS Layer 3 VPNs
module for information about setting up MPLS VPNs.
Ensure that the following routing protocols are configured and working properly:
• Label Distribution Protocol (LDP)—for MPLS label distribution. See MPLS Label Distribution
Protocol Overview.
• Multiprotocol Border Gateway Protocol (MP-BGP)—for VPN route and label distribution. See
Configuring MPLS Layer 3 VPNs.
Restrictions for MPLS VPN—L3VPN over GRE

The MPLS VPN—L3VPN over GRE feature does not support the following:
• Quality of service (QoS) service policies configured on the tunnel interface; they are supported on
the physical or subinterface
• GRE options: sequencing, checksum, and source route
• IPv6 GRE
• Advanced features such as Carrier Supporting Carrier (CSC) and Interautonomous System
(Inter-AS)
Information About MPLS VPN—L3VPN over GRE

The MPLS VPN—L3VPN over GRE feature provides a mechanism for tunneling MPLS packets over
non-MPLS networks.
MPLS VPN—L3VPN over GRE allows you to create a GRE tunnel across a non-MPLS network. The
MPLS packets are encapsulated within the GRE tunnel packets, and the encapsulated packets traverse
the non-MPLS network through the GRE tunnel. When GRE tunnel packets are received at the other side
of the non-MPLS network, the GRE tunnel packet header is removed and the inner MPLS packet is
forwarded to its final destination.
The MPLS VPN—L3VPN over GRE feature supports three GRE tunnel configurations:
• PE-to-PE Tunneling, page 2
• P-to-PE Tunneling, page 3
• P-to-P Tunneling, page 4
PE-to-PE Tunneling
The provider edge-to-provider edge (PE-to-PE) tunneling configuration provides a scalable way to
connect multiple customer networks across a non-MPLS network. With this configuration, traffic that is
destined to multiple customer networks is multiplexed through a single GRE tunnel.
2
Information About MPLS VPN—L3VPN over GRE
Note A similar nonscalable alternative is to connect each customer network through separate GRE tunnels (for
example, connecting one customer network for each GRE tunnel).
As shown in Figure 1, the PE routers assign VPN routing and forwarding (VRF) numbers to the customer
edge (CE) routers on each side of the non-MPLS network.
The PE routers use routing protocols such as BGP, OSPF, or Routing Information Protocol (RIP) to learn
about the IP networks behind the CE routers. The routes to the IP networks behind the CE routers are
stored in the associated CE router’s VRF routing table.
The PE router on one side of the non-MPLS network uses the routing protocols (that are operating within
the non-MPLS network) to learn about the PE router on the other side of the non-MPLS network. The
learned routes that are established between the PE routers are then stored in the main or default routing
table.
The opposing PE router uses BGP to learn about the routes that are associated with the customer
networks behind the PE routers. These learned routes are not known to the non-MPLS network.
For this example, BGP defines a static route to the BGP neighbor (the opposing PE router) through the
GRE tunnel that spans the non-MPLS network. Because the routes that are learned by the BGP neighbor
include the GRE tunnel next hop, all customer network traffic is sent using the GRE tunnel.
Figure 1 PE-to-PE Tunneling
BGP BGP
OSPF OSPF
RIP BGP RIP
VPN1 VPN1
IPv4 cloud OSPF
CE-11 GRE Tunnel CE-21
PE-1 No MPLS PE-2
188951
CE-12 CE-22
P-to-PE Tunneling
As shown in Figure 2, the provider-to-provider edge (P-to-PE) tunneling configuration provides a way
to connect a PE router (P1) to an MPLS segment (PE-2) across a non-MPLS network. In this
configuration, MPLS traffic that is destined to the other side of the non-MPLS network is sent through
a single GRE tunnel.
Figure 2 P-to-PE Tunneling
MPLS/VPN
MPLS/GRE
IPv4 cloud
MPLS GRE Tunnel
188952
No MPLS
PE-1 P1 PE-2
3
How to Configure MPLS VPN—L3VPN over GRE
P-to-P Tunneling
As shown in Figure 3, the provider-to-provider (P-to-P) configuration provides a method of connecting
two MPLS segments (P1 to P2) across a non-MPLS network. In this configuration, MPLS traffic that is
destined to the other side of the non-MPLS network is sent through a single GRE tunnel.
Figure 3 P-to-P Tunneling
Any MPLS Applications (MPLS/VPN)
MPLS/GRE
IPv4 cloud
MPLS GRE Tunnel MPLS
188953
No MPLS
PE-1 P1 P2 PE-2

This section contains the following procedure:
• Configuring the MPLS VPN—L3VPN over GRE Tunnel Interface, page 4 (required)
Configuring the MPLS VPN—L3VPN over GRE Tunnel Interface

To configure the MPLS VPN—L3VPN over GRE feature, you must create a GRE tunnel to span the
non-MPLS networks. You must perform this procedure on the devices located at both ends of the GRE
tunnel.
Prerequisites
Before configuring the MPLS VPN—L3VPN over GRE feature, ensure that your MPLS VPN and the
appropriate routing protocols are configured and working properly. See the “Prerequisites for MPLS
VPN—L3VPN over GRE” section on page 2.
SUMMARY STEPS
1. enable
3. interface tunnel tunnel-number
4. ip address ip-address
5. tunnel source source-address
6. tunnel destination destination-address
7. mpls ip
4
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel tunnel-number Creates a tunnel on the specified interface and enters
interface configuration mode.
Example:
Step 4 ip address ip-address Assigns an IP address to the tunnel interface.
Example:
255.255.255.0
Step 5 tunnel source source-address Specifies the tunnel’s source IP address.
Example:
Router(config-if)# tunnel source 10.1.1.1
Step 6 tunnel destination destination-address Specifies the tunnel’s destination IP address.
Example:
Step 7 mpls ip Enables MPLS on the tunnel’s physical interface.
Example:
Examples
The following example shows a GRE tunnel configuration that spans a non-MPLS network. This
example shows the tunnel configuration on the PE devices (PE1 and PE2) located at both ends of the
tunnel:
PE1 Configuration
Router(config-if)# ip address 10.1.1.1 255.255.255.0
5
Configuration Examples for MPLS VPN—L3VPN over GRE
PE2 Configuration

This section provides the following configuration example for the MPLS VPN—L3VPN over GRE
feature:
• MPLS Configuration with MPLS VPN—L3VPN over GRE: Example, page 6
MPLS Configuration with MPLS VPN—L3VPN over GRE: Example

The following basic MPLS configuration example uses a GRE tunnel to span a non-MPLS network. This
example is similar to the configuration shown in Figure 1 on page 3.
PE1 Configuration
!
mpls ip
!
ip vrf vpn1
rd 100:1
!
ip address 10.2.2.2 255.255.255.255
!
interface GigabitEthernet 0/1/2
ip address 10.1.1.1 255.255.255.0
!
interface Tunnel 1
ip address 10.0.0.1 255.255.255.0
tunnel source 10.1.1.1
mpls ip
!
ip address 10.10.0.1 255.255.255.0
!
router bgp 100
neighbor 10.5.5.5 update-source loopback0
!
neighbor 10.5.5.5 send community-extended
!
!
6
PE2 Configuration
!
mpls ip
!
ip vrf vpn1
rd 100:1
!
ip address 10.5.5.5 255.255.255.255
!
ip address 10.1.1.2 255.255.255.0
!
interface Tunnel 1
ip address 10.0.0.2 255.255.255.0
tunnel source 10.1.1.2
mpls ip
!
ip address 10.1.2.1 255.255.255.0
!
router bgp 100
neighbor 10.2.2.2 update-source loopback0
!
neighbor 10.2.2.2 send community-extended
!
!
7
The following sections provide references related to the MPLS VPN—L3VPN over GRE feature.
Related Documents
Setting up MPLS VPN networks Configuring MPLS Layer 3 VPNs
Label Distribution Protocol MPLS Label Distribution Protocol Overview
Multiprotocol Border Gateway Protocol (MP-BGP) Configuring MPLS Layer 3 VPNs
Standards
Standard Title
MIBs
MIB MIBs Link
No new or modified MIBs are supported by this To locate and download MIBs for selected platforms, Cisco IOS
feature, and support for existing MIBs has not been releases, and feature sets, use Cisco MIB Locator found at the
modified by this feature. following URL:
RFCs
RFC Title
None —
8
Command Reference
Description Link
Command Reference
This feature uses no new or modified commands.
9
Feature Information for MPLS VPN—L3VPN over GRE
Feature Information for MPLS VPN—L3VPN over GRE

Not all commands may be available in your Cisco IOS software release. For release information about a
specific command, see the command reference documentation.
Cisco Feature Navigator enables you to determine which Cisco IOS and Catalyst OS software images
support a specific software release, feature set, or platform. To access Cisco Feature Navigator, go to
Note Table 1 lists only the Cisco IOS software release that introduced support for a given feature in a given
Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS
Table 1 Feature Information for MPLS VPN—L3VPN over GRE

MPLS VPN—L3VPN over GRE feature The MPLS VPN—L3VPN over GRE feature
provides a mechanism for tunneling Multiprotocol
Label Switching (MPLS) packets over a non-MPLS
network.
This feature uses no new or modified commands.
CCDE, CCENT, Cisco Eos, Cisco HealthPresence, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence,
Cisco WebEx, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn and Cisco Store are
service marks; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP,
CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo,
Cisco Unity, Collaboration Without Limitation, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive,
HomeLink, Internet Quotient, IOS, iPhone, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace,
MeetingPlace Chime Sound, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare,
SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo
are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
coincidental.
© 2008-2009 Cisco Systems, Inc. All rights reserved.
10
MPLS VPN Half-Duplex VRF

The MPLS VPN Half-Duplex VRF feature provides scalable hub-and-spoke connectivity for subscribers
of an Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) service. This feature
addresses the limitations of hub-and-spoke topologies by removing the requirement of one virtual
routing and forwarding (VRF) instance per spoke. This feature also ensures that subscriber traffic always
traverses the central link between the wholesale service provider and the Internet service provider (ISP),
whether the subscriber traffic is being routed to a remote network by way of the upstream ISP or to
another locally or remotely connected subscriber.

which each feature is supported, see the “Feature Information for MPLS VPN Half-Duplex VRF” section on
page 18.
Contents
• Prerequisites for Configuring MPLS VPN Half-Duplex VRF, page 2
• Restrictions for MPLS VPN Half-Duplex VRF, page 2
• Information About Configuring MPLS VPN Half-Duplex VRF, page 2
• How to Configure MPLS VPN Half-Duplex VRF, page 4
• Configuration Examples for MPLS VPN Half-Duplex VRF, page 10

Prerequisites for Configuring MPLS VPN Half-Duplex VRF
• Feature Information for MPLS VPN Half-Duplex VRF, page 18
Prerequisites for Configuring MPLS VPN Half-Duplex VRF

You must have a working MPLS core network.
Restrictions for MPLS VPN Half-Duplex VRF

The following features are not supported on interfaces configured with the MPLS VPN Half-Duplex
VRF feature:
• Multicast
• MPLS VPN Carrier Supporting Carrier
• MPLS VPN Interautonomous Systems
Information About Configuring MPLS VPN Half-Duplex VRF

To configure this feature, you need to understand the following concepts:
• MPLS VPN Half-Duplex VRF Overview, page 2
• Upstream and Downstream VRFs, page 3
• Reverse Path Forwarding Check, page 4
MPLS VPN Half-Duplex VRF Overview

The MPLS VPN Half-Duplex VRF feature provides:
• The MPLS VPN Half-Duplex VRF feature prevents local connectivity between subscribers at the
spoke provider edge (PE) router and ensures that a hub site provides subscriber connectivity. Any
sites that connect to the same PE router must forward intersite traffic using the hub site. This ensures
that the routing done at the spoke site moves from the access-side interface to the network-side
interface or from the network-side interface to the access-side interface, but never from the
access-side interface to the access-side interface.
• The MPLS VPN Half-Duplex VRF feature prevents situations where the PE router locally switches
the spokes without passing the traffic through the upstream ISP. This prevents subscribers from
directly connecting to each other, which causes the wholesale service provider to lose revenue.
• The MPLS VPN Half-Duplex VRF feature improves scalability by removing the requirement of one
VRF per spoke. If the feature is not configured, when spokes are connected to the same PE router
each spoke is configured in a separate VRF to ensure that the traffic between the spokes traverses
the central link between the wholesale service provider and the ISP. However, this configuration is
not scalable. When many spokes are connected to the same PE router, configuration of VRFs for
each spoke becomes quite complex and greatly increases memory usage. This is especially true in
large-scale wholesale service provider environments that support high-density remote access to
Layer 3 VPNs.
Figure 1 shows a sample hub-and-spoke topology.
2
Information About Configuring MPLS VPN Half-Duplex VRF
Figure 1 Hub-and-Spoke Topology
Spokes
Spoke PE Hub PE Hub CE

Router P Router Router Router
CE1
ISP
104543
MPLS Core
CE2
Upstream and Downstream VRFs

The MPLS VPN Half-Duplex VRF feature uses two unidirectional VRFs to forward IP traffic between
the spokes and the hub PE router:
• The upstream VRF forwards IP traffic from the spokes toward the hub PE router. This VRF typically
contains only a default route but might also contain summary routes and several default routes. The
default route points to the interface on the hub PE router that connects to the upstream ISP. The
router dynamically learns about the default route from the routing updates that the hub PE router or
home gateway sends.
Note Although the upstream VRF is typically populated from the hub, it is possible also to have
a separate local upstream interface on the spoke PE for a different local service that would
not be required to go through the hub: for example, a local Domain Name System (DNS) or
game server service.
• The downstream VRF forwards traffic from the hub PE router back to the spokes. This VRF can
contain:
– PPP peer routes for the spokes and per-user static routes received from the authentication,
authorization, and accounting (AAA) server or from the Dynamic Host Control Protocol
(DHCP) server
– Routes imported from the hub PE router
– Border Gateway Protocol (BGP), Open Shortest Path First (OSPF), Routing Information
Protocol (RIP), or Enhanced Interior Gateway Routing Protocol (EIGRP) dynamic routes for
the spokes
The spoke PE router redistributes routes from the downstream VRF into Multiprotocol Border
Gateway Protocol (MP-BGP). That router typically advertises a summary route across the MPLS
core for the connected spokes. The VRF configured on the hub PE router imports the advertised
summary route.
3
How to Configure MPLS VPN Half-Duplex VRF
Reverse Path Forwarding Check

The Reverse Path Forwarding (RPF) check ensures that an IP packet that enters a router uses the correct
inbound interface. The MPLS VPN Half-Duplex VRF feature supports unicast RPF check on the
spoke-side interfaces. Because different VRFs are used for downstream and upstream forwarding, the
RPF mechanism ensures that source address checks occur in the downstream VRF.
Unicast RPF is not on by default. You need to enable it, as described in Configuring Unicast Reverse
Path Forwarding.

• Configuring the Upstream and Downstream VRFs on the Spoke PE Router, page 4 (required)
• Associating a VRF with an Interface, page 6 (required)
• Configuring the Downstream VRF for an AAA Server, page 7 (optional)
• Verifying MPLS VPN Half-Duplex VRF Configuration, page 7 (optional)
Configuring the Upstream and Downstream VRFs on the Spoke PE Router

To configure the upstream and downstream VRFs on the spoke PE router, use the following procedure.
SUMMARY STEPS
1. enable
3. vrf definition vrf-name
5. address-family {ipv4 | ipv6}
8. end
DETAILED STEPS

Example:
Router> enable
Example:
4

Step 3 vrf definition vrf-name Configures a VRF routing table and enters VRF
configuration mode.
Example: • The vrf-name argument is the name of the VRF.
Router(config)# vrf definition vrf1
Step 4 rd route-distinguisher Creates routing and forwarding tables for a VRF.
• The route-distinguisher argument specifies to add an
Example: 8-byte value to an IPv4 prefix to create a VPN IPv4
Router(config-vrf)# rd 100:1 prefix. You can enter a route distinguisher in either of
these formats:
– 16-bit autonomous system number (ASN): your
32-bit number
For example, 101:3.
– 32-bit IP address: your 16-bit number
For example, 192.168.122.15:1.
Step 5 address-family {ipv4 | ipv6} Enters VRF address family configuration mode to specify
an address family for a VRF.
Example: • The ipv4 keyword specifies an IPv4 address family for
Router(config-vrf) address-family ipv4 a VRF.
• The ipv6 keyword specifies an IPv6 address family for
a VRF.
Note The MPLS VPN Half Duplex VRF feature supports
only the IPv4 address family.
Step 6 route-target {import | export | both} Creates a route-target extended community for a VRF.
• The import keyword specifies to import routing
information from the target VPN extended community.
Example:
Router(config-vrf-af)# route-target both 100:2
• The export keyword specifies to export routing
information to the target VPN extended community.
• The both keyword specifies to import both import and
export routing information to the target VPN extended
community.
VRF’s list of import, export, or both (import and
export) route-target extended communities.
Step 7 exit-address-family Exits VRF address family configuration mode.
Example:
Router(config-vrf-af)# exit-address-family
Example:
5
Associating a VRF with an Interface

Perform the following task to associate a VRF with an interface, which activates the VRF.
SUMMARY STEPS
1. enable
4. vrf forwarding vrf-name [downstream vrf-name2]
5. ip address ip-address mask [secondary]
6. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example: • The type argument identifies the type of interface to be
Router(config)# interface Ethernet 0/1 configured.
• The number argument identifies the port, connector, or
interface card number.
Step 4 vrf forwarding vrf-name [downstream vrf-name2] Associates a VRF with an interface or subinterface.
• The vrf-name argument is the name of the VRF.
Example: • The downstream vrf-name2 keyword and argument
Router(config-if)# vrf forwarding vrf1
combination is the name of the downstream VRF into
which peer and per-user routes are installed.
6

Step 5 ip address ip-address mask [secondary] Sets a primary or secondary IP address for an interface.
• The ip-address argument is the IP address.
Example: • The mask argument is the mask of the associated IP
255.255.255.255
subnet.
• The secondary keyword specifies that the configured
address is a secondary IP address. If this keyword is
omitted, the configured address is the primary IP
address.
Example:
Router(config-if) end
Configuring the Downstream VRF for an AAA Server

To configure the downstream VRF for an AAA (RADIUS) server in broadband or remote access
situations, enter the following Cisco attribute value:
lcp:interface-config=ip vrf forwarding U downstream D
In standard VPN situations, enter instead the following Cisco attribute value:
ip:vrf-id=U downstream D
Verifying MPLS VPN Half-Duplex VRF Configuration

To verify a MPLS VPN half-duplex VRF configuration, perform the following steps.
SUMMARY STEPS
1. show vrf [ipv4 | ipv6] [brief | detail | id | interfaces | lock | select] [vrf-name]
2. show ip route vrf vrf-name
3. show running-config [interface type number]
DETAILED STEPS
Step 1 show vrf [ipv4 | ipv6] [brief | detail | id | interfaces | lock | select ] [vrf-name]
Use this command to display information about all of the VRFs configured on the router, including the
downstream VRF for each associated interface or virtual access interface (VAI):
Router# show vrf
Name Default RD Interfaces

Down 100:1 POS3/0/3 [D]
POS3/0/1 [D]
100:3 Loopback2
Virtual-Access3 [D]
7
Virtual-Access4 [D]
Up 100:2 POS3/0/3
POS3/0/1
100:4 Virtual-Access3
Use the show vrf detail vrf-name command to display detailed information about the VRF you specify,
including all interfaces, subinterfaces, and VAIs associated with the VRF.
If you do not specify a value for the vrf-name argument, detailed information about all of the VRFs
configured on the router appears.
The following example shows how to display detailed information for the VRF called vrf1, in a
broadband or remote access case:
Router# show vrf detail vrf1
VRF D; default RD 2:0; default VPNID <not set>

Interfaces:
Loopback2 Virtual-Access3 [D] Virtual-Access4 [D]
RT:2:0
RT:2:1
No import route-map
No export route-map
VRF U; default RD 2:1; default VPNID <not set>
Interfaces:
Virtual-Access3 Virtual-Access4
RT:2:1
No import route-map
No export route-map
The following example shows the VRF detail in a standard VPN situation:
Router# show vrf detail
VRF Down; default RD 100:1; default VPNID <not set> VRF Table ID = 1
Description: import only from hub-pe
Interfaces:
Pos3/0/3 [D] Pos3/0/1:0.1 [D]
RT:100:0
RT:100:1
No import route-map
No export route-map
VRF label distribution protocol: not configured
VRF Up; default RD 100:2; default VPNID <not set> VRF Table ID = 2
Interfaces:
Pos3/0/1 Pos3/0/3
RT:100:1
No import route-map
No export route-map
VRF label distribution protocol: not configured
Step 2 show ip route vrf vrf-name
8
Use this command to display the IP routing table for the VRF you specify, and information about the
per-user routes installed in the downstream VRF.
The following example shows how to display the routing table for the downstream VRF named D, in a
broadband or remote access situation:
Router# show ip route vrf D
Routing Table: D
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS interarea
* - candidate default, U - per-user static route, o - ODR
P - periodic downloaded static route
10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks

U 10.0.0.2/32 [1/0] via 10.0.0.1
S 10.0.0.0/8 is directly connected, Null0
U 10.0.0.5/32 [1/0] via 10.0.0.2
C 10.8.1.2/32 is directly connected, Virtual-Access4
C 10.8.1.1/32 is directly connected, Virtual-Access3
The following example shows how to display the routing table for the downstream VRF named Down,
in a standard VPN situation:
Router# show ip route vrf Down
Routing Table: Down

Gateway of last resort is 10.13.13.13 to network 0.0.0.0
C 10.2.0.0/8 is directly connected, Pos3/0/3

B 10.4.16.16 [200/0] via 10.13.13.13, 1w3d
B 10.6.0.0/8 [200/0] via 10.13.13.13, 1w3d
C 10.0.0.0/8 is directly connected, Pos3/0/1
B 10.7.0.0 [20/0] via 10.0.0.2, 1w3d
B 10.0.6.14 [20/0] via 10.0.0.2, 1w3d
B 10.8.15.15 [20/0] via 10.0.0.2, 1w3d
B* 0.0.0.0/0 [200/0] via 10.0.0.13, 1w3d
The following example shows how to display the routing table for the upstream VRF named U in a
broadband or remote access situation:
Router# show ip route vrf U
Routing Table: U
9
Configuration Examples for MPLS VPN Half-Duplex VRF

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS interarea

C 10.0.0.8 is directly connected, Loopback2
B* 0.0.0.0/0 [200/0] via 192.168.0.20, 1w5d
The following example shows how to display the routing table for the upstream VRF named Up in a
standard VPN situation:
Router# show ip route vrf Up
Routing Table: Up

C 10.2.0.1 is directly connected, Pos3/0/3
B 10.3.16.16 [200/0] via 10.13.13.13, 1w3d
B 10.6.0.0/8 [200/0] via 10.13.13.13, 1w3d
C 10.0.0.1 is directly connected, Pos3/0/1
B* 0.0.0.0/0 [200/0] via 10.13.13.13, 1w3d
Step 3 show running-config [interface type number]

Use this command to display information about the interface you specify, including information about
the associated upstream and downstream VRFs.
The following example shows how to display information about subinterface POS 3/0/1:
Router# show running-config interface POS 3/0/1

!
interface POS3/0/1
ip vrf forwarding Up downstream Down
ip address 10.0.0.1 255.0.0.0
end

10
• Configuring the Upstream and Downstream VRFs on the Spoke PE Router: Example, page 11
• Associating a VRF with an Interface: Example, page 11
• Configuring MPLS VPN Half-Duplex VRF: Example Using Static CE-PE Routing, page 11
• Configuring MPLS VPN Half-Duplex VRF: Example Using RADIUS Server and Static CE-PE
Routing, page 13
• Configuring MPLS VPN Half-Duplex VRF: Example Using Dynamic CE-PE Routing, page 14
Configuring the Upstream and Downstream VRFs on the Spoke PE Router:

Example
The following example configures an upstream VRF named Up:
Router> enable
Router(config)# vrf definition Up
Router(config-vrf)# address-family ipv4
Router(config-vrf-af)# route-target import 1:0
The following example configures a downstream VRF named Down:

Router> enable
Router(config)# vrf definition Down
Router(config-vrf)# address-family ipv4
Router(config-vrf-af)# route-target import 1:8
Associating a VRF with an Interface: Example

The following example associates the VRF named Up with POS 3/0/1 subinterface and specifies the
downstream VRF named Down:
Router> enable
Router(config-if)# vrf forwarding Up downstream Down
Configuring MPLS VPN Half-Duplex VRF: Example Using Static CE-PE Routing
This example uses the hub-and-spoke topology shown in Figure 2 with local authentication (that is, the
RADIUS server is not used):
11
Figure 2 Sample Topology
RADIUS Server
Spokes
Spoke PE Hub PE Hub

P Router
Router Router Router
Router A
ATM ISP
Router D
Router C Router E Router F
242701
MPLS Core
Router B
vrf definition D
rd 1:8
address-family ipv4
exit-address-family
!
vrf definition U
rd 1:0
address-family ipv4
exit-address-family
!
ip cef
vpdn enable
!
vpdn-group U
accept-dialin
protocol pppoe
virtual-template 1
!
interface Loopback 2
vrf forwarding U
ip address 10.0.0.8 255.255.255.255
!
interface ATM 2/0
description Mze ATM3/1/2
no ip address
pvc 0/16 ilmi
!
pvc 3/100
protocol pppoe
!
pvc 3/101
protocol pppoe
!
12
Configuring MPLS VPN Half-Duplex VRF: Example Using RADIUS Server and
Static CE-PE Routing
The following example shows how to connect two Point-to-Point Protocol over Ethernet (PPPoE) clients
to a single VRF pair on the spoke PE router named Router C. Although both PPPoE clients are
configured in the same VRF, all communication occurs using the hub PE router. Half-duplex VRFs are
configured on the spoke PE. The client configuration is downloaded to the spoke PE from the RADIUS
server.
This example uses the hub-and-spoke topology shown in Figure 2.
Note The wholesale provider can forward the user authentication request to the corresponding ISP. If the ISP
authenticates the user, the wholesale provider appends the VRF information to the request that goes back
to the PE router.
aaa new-model
!
aaa group server radius R
server 10.0.20.26 auth-port 1812 acct-port 1813
!
aaa authentication ppp default group radius
aaa authorization network default group radius
!
vrf defintion D
description Downstream VRF - to spokes
rd 1:8
address-family ipv4
exit-address-family
!
vrf definition U
description Upstream VRF - to hub
rd 1:0
address-family ipv4
exit-address-family
!
ip cef
vpdn enable
!
vpdn-group U
accept-dialin
protocol pppoe
virtual-template 1
!
interface Loopback2
vrf forwarding U
ip address 10.0.0.8 255.255.255.255
!
interface ATM2/0
pvc 3/100
protocol pppoe
!
pvc 3/101
protocol pppoe
!
interface virtual-template 1
no ip address
ppp authentication chap
13
!
router bgp 1
no synchronization
no auto-summary
!
auto-summary
exit-address-family
!
address-family ipv4 vrf U
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf D
redistribute static
no auto-summary
no synchronization
exit-address-family
!
ip local pool U-pool 10.8.1.1 2.8.1.100
ip route vrf D 10.0.0.0 255.0.0.0 Null0
!
radius-server host 10.0.20.26 auth-port 1812 acct-port 1813
radius-server key cisco
Configuring MPLS VPN Half-Duplex VRF: Example Using Dynamic CE-PE

Routing
The following example shows how to use OSPF to dynamically advertise the routes on the spoke sites.
This example uses the hub-and-spoke topology shown in Figure 2.
Creating the VRFs

vrf definition Down
rd 100:1
address-family ipv4
exit-address-family
!
vrf definition Up
rd 100:2
address-family ipv4
exit-address-family
Enabling MPLS
Configuring BGP Toward Core

router bgp 100
no bgp default ipv4-unicast
14
bgp log-neighbor-changes
bgp graceful-restart restart-time 120
bgp graceful-restart stalepath-time 360
bgp graceful-restart
!
exit-address-family
Configuring BGP Toward Edge

address-family ipv4 vrf Up
no auto-summary
no synchronization
exit-address-family
!
address-family ipv4 vrf Down
redistribute ospf 1000 vrf Down
no auto-summary
no synchronization
exit-address-family
Spoke PE’s Core-Facing Interfaces and Processes

ip address 10.11.11.11 255.255.255.255
!
interface POS 3/0/2
ip address 10.0.1.1 255.0.0.0
mpls ip
!
router ospf 100
nsf enforce global
network 10.11.11.11 0.0.0.0 area 100
network 10.0.1.0 0.255.255.255 area 100
Spoke PE’s Edge-Facing Interfaces and Processes

vrf forwarding Down
ip address 10.22.22.22 255.255.255.255
!
interface POS 3/0/1
vrf forwarding Up downstream Down
ip address 10.0.0.1 255.0.0.0
!
interface POS 3/0/3
vrf forwarding Up downstream Down
ip address 10.2.0.1 255.0.0.0
!
router ospf 1000 vrf Down
router-id 10.22.22.22
nsf enforce global
15
redistribute bgp 100 metric-type 1 subnets

network 10.22.22.22 0.0.0.0 area 300
network 10.0.0.0 0.255.255.255 area 300
network 10.2.0.0 0.255.255.255 area 300
default-information originate
The following sections provide references related to the MPLS VPN Half-Duplex VRFs feature.
Related Documents
MPLS VPNs Configuring MPLS Layer 3 VPNs
Unicast Reverse Path Forwarding Configuring Unicast Reverse Path Forwarding
Standards
Standard Title
MIBs
MIB MIBs Link
16
RFCs
RFCs
RFC Title
Description Link
The Cisco Support website provides extensive online http://www.cisco.com/cisco/web/support/index.html
17
Feature Information for MPLS VPN Half-Duplex VRF
Feature Information for MPLS VPN Half-Duplex VRF

Table 1 Feature Information for MPLS VPN Half-Duplex VRF

MPLS VPN - Half Duplex VRF (HDVRF) Cisco IOS XE This feature ensures that VPN clients that connect to the
Support with Static Routing Release 2.5 same PE router at the edge of the MPLS VPN use the hub
site to communicate.
MPLS VPN Half-Duplex VRF Cisco IOS XE In Cisco IOS XE Release 2.5, this feature, with support for
Release 2.5 dynamic routing protocols, was integrated into the XE train.
vrf forwarding (interface configuration), show ip
interface, show vrf.
coincidental.
18
MPLS Embedded Management and MIBs
MPLS Enhancements to Interfaces MIB

This document describes the Multiprotocol Label Switching (MPLS) enhancements to the existing
Interfaces MIB (RFC 2233) to support an MPLS layer. This layer provides counters and statistics
specifically for MPLS.

which each feature is supported, see the “Feature Information for MPLS Enhancements to Interfaces MIB”
section on page 12.
Contents
• Prerequisites for MPLS Enhancements to Interfaces MIB, page 2
• Restrictions for MPLS Enhancements to Interfaces MIB, page 2
• Information About MPLS Enhancements to Interfaces MIB, page 3
• How to Configure MPLS Enhancements to Interfaces MIB, page 8
• Configuration Examples for the MPLS Enhancements to Interfaces MIB, page 10
• Feature Information for MPLS Enhancements to Interfaces MIB, page 12
Prerequisites for MPLS Enhancements to Interfaces MIB
Prerequisites for MPLS Enhancements to Interfaces MIB

• Simple Network Management Protocol (SNMP) must be installed and enabled on the label
switching routers (LSRs)
• MPLS must be enabled on the LSRs
• MPLS IP must be enabled on an interface or an MPLS traffic engineering (TE) tunnel enabled on
an interface
Restrictions for MPLS Enhancements to Interfaces MIB

• Link up and link down traps for the MPLS layer are not supported in this release.
• Write capability using the SNMP SET command is not supported for the MPLS layer in this release.
• Some counters, including discard and multicast, increment on the underlying physical layer;
therefore, they equal 0 because they never reach the MPLS layer.
• The high-capacity counters for the MPLS layer interfaces of the Interfaces MIB contain 64 bits of
counter data. In previous versions, the high capacity counters displayed 32 bits of counter data.
The following MIB objects are affected:
– ifHCInOctets
– ifHCOutOctets
– ifHCInUcastPkts
– ifHCOutUcastPkts
When the 64-bit values are less than the value of 232, the 32-bit and 64-bit values are identical.
After the counter increases to more than 232, the counters are different; the 64-bit value is computed
by the following formula:
X * (232) + Y
where:
– X is the number of times the 32-bit counter has rolled.
– Y is the residual value of the counter after the roll occurred. The Y value equals the 32-bit value.
When the high-capacity counter values are compared to their 32-bit values, there is a period of time
that the counter values are not equal. The 64-bit values lag the 32-bit values when the counters poll
the 32-bit hardware counters and computing the correct counter value. During the polling and
computation interval, the following high-capacity counter values counters might be inconsistent:
– ifInOctets
– ifOutOctets
– ifInUcastPkts
– ifOutUcastPkts
The inconsistent values can occur if traffic is constantly flowing over an interface and a MIB walk
is performed. The 32-bit value is correct at that moment. The 64-bit value lags slightly, because of
the polling computations needed to generate it. Once traffic stops flowing over the interface, and a
polling period has passed, the two counters are identical and correct.
2
Information About MPLS Enhancements to Interfaces MIB
The lag time depends on the following factors:

– The polling interval used by the Interfaces MIB. The less time the polling interval takes, the
more accurate the value is.
– The size of the Interfaces MIB. A large MIB takes a long time to walk and might affect the
values found at that instant.
– The number of computations needed to generate the 64-bit value. The number of MPLS-enabled
interfaces increases the number of 64-bit counter values that need to be computed.

To configure the MPLS Enhancements to Interfaces MIB, you need to understand the following
concepts:
• Feature Design of the MPLS Enhancements to Interfaces MIB, page 3
• Interfaces MIB Scalar Objects, page 5
• Stacking Relationships for MPLS Layer Interfaces, page 5
• Stacking Relationships for Traffic Engineering Tunnels, page 6
• MPLS Label Switching Router MIB Enhancements, page 7
• Benefits of the MPLS Enhancements to Interfaces MIB, page 8
Feature Design of the MPLS Enhancements to Interfaces MIB

The Interfaces MIB (IF MIB) provides an SNMP-based method for managing interfaces. Each entry in
the IF MIB establishes indexing, statistics, and stacking relationships among underlying physical
interfaces, subinterfaces, and Layer 2 protocols that exist within Cisco IOS XE software.
The enhancements add an MPLS layer to the IF MIB as a Layer 2 protocol to provide statistics for traffic
encapsulated as MPLS on an interface. In this structure, MPLS-specific data such as MPLS-encapsulated
traffic counters and the MPLS maximum transmission unit (MTU) resides on top of the underlying
physical or virtual interface to allow separation from non-MPLS data.
The enhancements also allow you to display indexing, statistics, and stacking relationships using the
ifStackTable. MPLS layer interfaces are stacked above the underlying physical or virtual interface that
is actually forwarding the MPLS traffic. MPLS traffic engineering tunnels are then stacked above those
MPLS layers.
The IF MIB supports several types of interfaces. A virtual interface that provides protocol statistics for
MPLS-encapsulated traffic has been added. This interface is stacked above real Cisco IOS XE interfaces
or subinterfaces, such as Fast Ethernet (fe0/1/0) or ATM (at1/1.1).
Cisco IOS XE software creates a corresponding MPLS layer above each interface capable of supporting
MPLS when the MPLS encapsulation is enabled by issuing the mpls ip interface configuration
command.
You can also create the interface layer if you enable MPLS TE by using the mpls traffic-eng tunnels
command in interface configuration mode.
Note You must also issue these commands in global configuration mode for MPLS IP or MPLS TE to be
enabled.
3
An IF MIB entry is created when you enable either MPLS IP or MPLS TE tunnels on an interface; the
entry is removed when you disable both MPLS IP and MPLS TE.
ifStackTable Objects
Table 1 defines the ifStackTable objects.
Table 1 ifStackTable Objects and Definitions
Object Definition
ifStackHigherLayer The value of ifIndex corresponding to the higher sublayer of the
relationship; that is, the sublayer that runs on top of the
sublayer identified by the corresponding instance of the
ifStackLowerLayer.
Note Index objects are not accessible in a MIB walk. This
value is part of the object identifier (OID) for every
object in the ifStackTable.
ifStackLowerLayer The value of ifIndex corresponding to the lower sublayer of the
relationship; that is, the sublayer that runs below the sublayer
identified by the corresponding instance of the
ifStackHigherLayer.
value is part of the OID for every object in the
ifStackTable.
ifStackStatus Used to create and delete rows in the ifStackTable; status is
always active(1) for MPLS.
ifRcvAddressTable Objects
Table 2 defines the ifRcvAddressTable objects.
Note Entries for the MPLS layer do not appear in the ifRcvAddressTable.
Table 2 ifRcvAddressTable Objects and Descriptions
Object Definition
ifRcvAddressAddress An address for which the system accepts packets and frames on
this entry’s interface.
value is part of the OID for every object in the
ifRcvAddressTable.
ifRcvAddressStatus Used to create and delete rows in the ifRcvAddressTable.
ifRcvAddressType Type of storage used for each entry in the ifRcvAddressTable.
4
Interfaces MIB Scalar Objects

The IF MIB supports the following scalar objects:
• ifStackLastChange—The value of sysUpTime at the time of the last change of the entire interface stack.
A change of the interface stack is defined to be any creation, deletion, or change in value of any instance
of ifStackStatus. If the interface stack has been unchanged since the last reinitialization of the local
network management subsystem, then this object contains a zero value.
• ifTableLastChange—The value of sysUpTime at the time of the last creation or deletion of an entry in
the ifTable. If the number of entries has been unchanged since the last reinitialization of the local network
management subsystem, then this object contains a zero value.
Stacking Relationships for MPLS Layer Interfaces

The ifStackTable within the IF MIB provides a conceptual stacking relationship between the interfaces
and subinterfaces represented as entries in the ifTable.
The ifStackTable is indexed like a linked list. Each entry shows a relationship between two interfaces
providing the ifIndexes of the upper and the lower interface. The entries chain together to show the entire
stacking relationship. Each entry links with one another until the stack terminates with an ifIndex of 0
at the highest and lowest ends of the stack. For example, in Figure 1, the indexes .10.5 show that ifIndex
10 is stacked upon ifIndex 5. There are 0 entries at the highest and lowest ends of the stack; in Figure 1,
the indexes .0.15 and .72.0 are the highest and lowest ends of the stack, respectively.
Figure 1 Sample ATM Stacking Relationship in the ifStackTable
Conceptual Stacking ifStackTable Indexing

Relationship ifStackHigherLayer ifStackLowerLayer
ifIndex 0
.0.15
TE Interface
ifIndex 15
.15.10
MPLS Layer
ifIndex 10
.10.5
ATM-AAL5
ifIndex 5
.5.55
ATM Subinterface
ifIndex 55
.55.72
ATM
ifIndex 72
82272
.72.0
ifIndex 0
5
Table 3 describes the indexing of the ifStackTable for the layer relationships shown in Figure 1.
Note The order of the entries in Table 3 may not be the same as that seen in the MIB walk, which has to follow
SNMP ordering rules.
Table 3 Layer Relationships
Layer Relationship (in Descending Order) ifStackHigherLayer/ifStackLowerLayer

TE interface as top layer .0.15
TE interface stacked upon MPLS layer .15.10
MPLS layer stacked upon ATM-AAL5 .10.5
ATM-AAL5 layer stacked upon ATM subinterface .5.55
ATM subinterface stacked upon ATM .55.72
ATM as bottom layer .72.0
Stacking Relationships for Traffic Engineering Tunnels

MPLS TE tunnels are represented in Cisco IOS XE software and the IF MIB as virtual interfaces. When
properly signaled, TE tunnels pass traffic through MPLS over a physical interface. This process dictates
that a TE tunnel is to be stacked on an MPLS layer that is stacked on an underlying interface.
TE tunnels can also change paths in response to different error or network conditions. These changes are
instigated by using the RSVP-TE signaling protocol. When a change occurs, a tunnel can switch to a
different MPLS interface. If no signaling path exists, no paths will be chosen and thus no MPLS interface
will be used.
Because a TE tunnel is represented as an IF MIB ifTable entry, the ifStackTable also contains an entry
corresponding to the TE tunnel. If the TE tunnel is successfully signaled, the ifStackTable also contains
a link between the tunnel interface and one MPLS interface. Note that because it is possible for a TE
tunnel to not have a corresponding signaled path, it is thus possible for a TE tunnel's ifStackTable entry
to not have a corresponding lower layer. In this case, the lower layer variable contains the value of 0.
Figure 2 shows a TE tunnel before (left) and after (right) being rerouted and the effect on the
ifStackTable. When ifIndex 2 fails, the TE tunnel is rerouted through ifIndex1, the 15.2 entry is removed
from the ifStackTable, and the 15.1 entry is added.
6
Figure 2 Sample TE Tunnel Stacking Relationship
ifStackTable
ifStackTable
15.2
15.2
TE Tunnel *15.1
ifIndex 15 = new
*
ifIndex 2
ifIndex 2
ifIndex 1
82271
ifIndex 1
TE Tunnel
ifIndex 15
MPLS Label Switching Router MIB Enhancements

All of the ifIndex references in the MPLS-LSR-MIB tables have changed from the ifIndex of the
underlying physical or virtual interface to the ifIndex of the MPLS layer.
Table 4 shows the specific changes.
Table 4 MPLS-LSR-MIB ifIndex Objects Enhanced
Table ifIndex
MPLS interface configuration table mplsInterfaceConfIndex
(mplsInterfaceConfTable)
MPLS in-segment table (mplsInSegmentTable) mplsInSegmentIfIndex
MPLS cross-connect table (mplsXCTable) mplsInSegmentIfIndex
MPLS out-segment table (mplsOutSegmentTable) mplsOutSegmentIfIndex
The following objects from the mplsInterfaceConfTable are affected:

• mplsInterfaceOutPackets—Count only MPLS-encapsulated out packets
• mplsInterfaceInPackets—Count only MPLS-encapsulated in packets
7
How to Configure MPLS Enhancements to Interfaces MIB
Benefits of the MPLS Enhancements to Interfaces MIB

Improved Accounting Capability
By viewing the MPLS layer, you get MPLS-encapsulated traffic counters that do not include non-MPLS
encapsulated traffic (for example, IP packets). Therefore, the counters are more useful for MPLS-related
statistics.
TE Tunnel Interfaces
For TE tunnel interfaces, the stacking relationship reflects the current underlying MPLS interface that
is in use and dynamically changes as TE tunnels reoptimize and reroute.
MPLS-Specific Information
The MPLS layer shows MPLS-specific information including the following:
• If MPLS is enabled
• MPLS counters
• MPLS MTU
• MPLS operational status

• Enabling the SNMP Agent, page 8 (required)
Enabling the SNMP Agent

Perform the following task to enable the SNMP agent.
SUMMARY STEPS
1. enable
4. snmp-server community string [view view-name] [ro] [number]
5. end
6. write memory
8
DETAILED STEPS

Example:
Router> enable
Step 2 show running-config Displays the running configuration of the router so that you
can determine if an SNMP agent is already running on the
device.
Example:
Router# show running-config If no SNMP information is displayed, continue with the
next step.
If any SNMP information is displayed, you can modify the
information or change it as desired.
Example:
Step 4 snmp-server community string [view view-name] Configures read-only (ro) community strings for the MPLS
[ro] [number] Label Distribution Protocol (LDP) MIB.
• The string argument functions like a password,
Example: permitting access to SNMP functionality on label
Router(config)# snmp-server community public ro switch routers (LSRs) in an MPLS network.
• The optional ro keyword configures read-only (ro)
access to the objects in the MPLS LDP MIB.
Example:
Router(config)# end
Step 6 write memory Writes the modified SNMP configuration into NVRAM of
the router, permanently saving the SNMP settings.
Example:
Router# write memory
device.
Example:
Router# show running-config If you see any snmp-server statements, SNMP has been
enabled on the router.
9
Configuration Examples for the MPLS Enhancements to Interfaces MIB
Configuration Examples for the MPLS Enhancements to

Interfaces MIB
• MPLS Enhancements to Interfaces MIB: Examples, page 10
MPLS Enhancements to Interfaces MIB: Examples

The following example shows how to enable an SNMP agent:
Router(config)# snmp-server community
In the following example, SNMPv1 and SNMPv2C are enabled. The configuration permits any SNMP
manager to access all objects with read-only permissions using the community string public.
Router(config)# snmp-server community public
In the following example, read-only access is allowed for all objects to members of access list 4 that
specify the comaccess community string. No other SNMP managers have access to any objects.
Router(config)# snmp-server community comaccess ro 4
The following sections provide references related to the MPLS Enhancements to Interfaces MIB feature.
Related Documents
SNMP commands Cisco IOS Network Management Command Reference
SNMP configuration “Configuring SNMP Support” in the Cisco IOS XE
Network Management Configuration Guide, Release 2
A description of SNMP agent support in Cisco IOS XE MPLS Traffic Engineering (TE) MIB
for the MPLS Traffic Engineering MIB (MPLS TE
MIB)
Standards
Standards Title
10
MIBs
MIBs MIBs Link
Interfaces Group MIB (IF MIB) To locate and download MIBs for selected platforms, Cisco IOS XE
the following URL:
RFCs
RFCs Title
RFC 1156 Management Information Base for Network Management of
TCP/IP-based internets
RFC 1157 A Simple Network Management Protocol (SNMP)
TCP/IP-based internets: MIB-II
RFC 1229 Extensions to the Generic-Interface MIB
RFC 2233 Interfaces MIB
Description Link
11
Feature Information for MPLS Enhancements to Interfaces MIB
Feature Information for MPLS Enhancements to Interfaces MIB

Table 5 Feature Information for MPLS Enhancements to Interfaces MIB

MPLS Enhancements to Interfaces MIB Cisco IOS XE This document describes the Multiprotocol Label Switching
Release 2.1 (MPLS) enhancements to the existing Interfaces MIB (RFC
2233) to support an MPLS layer. This layer provides counters
and statistics specifically for MPLS.
feature:
• Feature Design of the MPLS Enhancements to
Interfaces MIB, page 3>
• Interfaces MIB Scalar Objects, page 5
• Stacking Relationships for MPLS Layer Interfaces,
page 5
• Stacking Relationships for Traffic Engineering
Tunnels, page 6
• MPLS Label Switching Router MIB Enhancements,
page 7
• Benefits of the MPLS Enhancements to Interfaces MIB,
page 8
• Enabling the SNMP Agent, page 8
The following command was introduced or modified:
snmp-server community.
12
Glossary
Glossary
ATM—Asynchronous Transfer Mode. The international standard for cell relay in which multiple service
types (such as voice, video, or data) are conveyed in fixed-length (53-byte) cells. Fixed-length cells
allow cell processing to occur in hardware, thereby reducing transit delays. ATM is designed to take
advantage of high-speed transmission media, such as E3, SONET, and T3.
ATM-AAL5—ATM adaptation layer 5. One of four AALs recommended by the ITU-T. AAL5 supports
connection-oriented variable bit rate (VBR) services and is used predominantly for the transfer of
classical IP over ATM and LAN emulation (LANE) traffic. AAL5 uses simple and efficient AAL (SEAL)
and is the least complex of the current AAL recommendations. It offers low bandwidth overhead and
simpler processing requirements in exchange for reduced bandwidth capacity and error-recovery
capability.
encapsulation—Wrapping of data in a particular protocol header. For example, Ethernet data is wrapped
in a specific Ethernet header before network transit. Also, when bridging dissimilar networks, the entire
frame from one network is simply placed in the header used by the data link layer protocol of the other
network.
IETF—Internet Engineering Task Force. A task force (consisting of more than 80 working groups) that
is developing standards for the Internet and the IP suite of protocols.
interface—The boundary between adjacent layers of the ISO model.
label—A short, fixed-length identifier that is used to determine the forwarding of a packet.
label switching—A term used to describe the forwarding of IP (or other network layer) packets using a
label swapping algorithm based on network layer routing algorithms. The forwarding of these packets
uses the exact match algorithm and rewrites the label.
LSR—label switching router. A device that forwards Multiprotocol Label Switching (MPLS) packets
based on the value of a fixed-length label encapsulated in each packet.
MIB—Management Information Base. A database of network management information that is used and
maintained by a network management protocol such as Simple Network Management Protocol (SNMP).
The value of a MIB object can be changed or retrieved by means of SNMP commands, usually through
a network management system. MIB objects are organized in a tree structure that includes public
(standard) and private (proprietary) branches.
MPLS interface—An interface on which Multiprotocol Label Switching (MPLS) traffic is enabled.
MTU—maximum transmission unit. Maximum packet size, in bytes, that a particular interface can
handle.
NMS—network management system. System responsible for managing at least part of a network. An
NMS is generally a reasonably powerful and well-equipped computer, such as an engineering
workstation. NMSs communicate with agents to help keep track of network statistics and resources.
OID—object identifier. Values are defined in specific MIB modules. The Event MIB allows you or an
NMS to watch over specified objects and to set event triggers based on existence, threshold, and Boolean
tests. An event occurs when a trigger is fired; this means that a specified test on an object returns a value
of true. To create a trigger, you or a network management system (NMS) configures a trigger entry in
the mteTriggerTable of the Event MIB. This trigger entry specifies the OID of the object to be watched.
For each trigger entry type, corresponding tables (existence, threshold, and Boolean tables) are
13
Glossary
populated with the information required for carrying out the test. The MIB can be configured so that
when triggers are activated (fired) either a Simple Network Management Protocol (SNMP) Set is
performed, a notification is sent out to the interested host, or both.
SNMP—Simple Network Management Protocol. A management protocol used almost exclusively in
TCP/IP networks. SNMP provides a means for monitoring and controlling network devices, and for
managing configurations, statistics collection, performance, and security.
from the one that Layer 3 routing could cause the tunnel to take.
trap—A message sent by a Simple Network Management Protocol (SNMP) agent to a network
management station, console, or terminal, indicating that a significant event occurred. Traps are less
reliable than notification requests, because the receiver does not send an acknowledgment when it
receives a trap. The sender cannot determine if the trap was received.
tunnel—A secure communication path between two peers, such as routers.
countries.
14
MPLS LSP Ping/Traceroute for LDP/TE, and LSP
Ping for VCCV

The MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV feature helps service providers
monitor label switched paths (LSPs) and quickly isolate Multiprotocol Label Switching (MPLS)
forwarding problems.
The feature provides the following capabilities:
• MPLS LSP ping to test LSP connectivity for IPv4 Label Distribution Protocol (LDP) prefixes,
Resource Reservation Protocol (RSVP) traffic engineering (TE), and Any Transport over MPLS
(AToM) forwarding equivalence classes (FECs).
• MPLS LSP traceroute to trace the LSPs for IPv4 LDP prefixes and RSVP TE prefixes.

which each feature is supported, see the “Feature Information for MPLS LSP Ping/Traceroute for
LDP/TE, and LSP Ping for VCCV” section on page 60.
Contents
• Prerequisites for MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV, page 2
• Restrictions for MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV, page 2
• Information About MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV, page 3
MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
Prerequisites for MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
• How to Configure MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV, page 10
• Configuration Examples for MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV,
page 31
• Feature Information for MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV, page 60
Prerequisites for MPLS LSP Ping/Traceroute for LDP/TE, and

LSP Ping for VCCV
Before you use the MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV feature, you
should:
• Determine the baseline behavior of your MPLS network. For example:
– Expected MPLS experimental (EXP) treatment.
– Expected maximum size packet or maximum transmission unit (MTU) of the LSP.
– The topology, expected label switched path, and number of links in the LSP. Trace the paths of
the label switched packets including the paths for load balancing.
• Understand how to use MPLS and MPLS applications. You need to:
– Know how LDP is configured.
– Understand AToM concepts.
• Understand label switching, forwarding, and load balancing.
Before using the ping mpls or trace mpls command, you must ensure that the router is configured to
encode and decode MPLS echo packets in a format that all receiving routers in the network can
understand.
Restrictions for MPLS LSP Ping/Traceroute for LDP/TE, and LSP

Ping for VCCV
• You cannot use MPLS LSP traceroute to trace the path taken by AToM packets. MPLS LSP
traceroute is not supported for AToM. (MPLS LSP ping is supported for AToM.) However, you can
use MPLS LSP traceroute to troubleshoot the Interior Gateway Protocol (IGP) LSP that is used by
AToM.
• You cannot use MPLS LSP ping to validate or trace MPLS Virtual Private Networks (VPNs).
• You cannot use MPLS LSP traceroute to troubleshoot LSPs that employ time-to-live (TTL) hiding.
• MPLS supports per-destination and per-packet (round robin) load balancing. If per-packet load
balancing is in effect, you should not use MPLS LSP traceroute because LSP traceroute at a transit
router consistency checks the information supplied in the previous echo response from the directly
connected upstream router. When round robin is employed, the path that an echo request packet
takes cannot be controlled in a way that allows a packet to be directed to TTL expire at a given router.
Without that ability, the consistency checking may fail during an LSP traceroute. A consistency
check failure return code may be returned.
2
Information About MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
• A platform must support LSP ping and traceroute in order to respond to an MPLS echo request
packet.
• Unless the MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV feature is enabled
along the entire path, you cannot get a reply if the request fails along the path at any node.
• There are certain limitations when a mixture of draft versions are implemented within a network.
The version of the draft must be compatible with Cisco’s implementation. Due to the way the LSP
Ping draft was written, earlier versions may not be compatible with later versions because of
changes to type, length, values (TLVs) formats without sufficient versioning information. Cisco
attempts to compensate for this in its implementations by allowing the sending and responding
routers to be configured to encode and decode echo packets assuming a certain version.
• If you want to use MPLS LSP traceroute, the network should not use TTL hiding.
Information About MPLS LSP Ping/Traceroute for LDP/TE, and

LSP Ping for VCCV
Before using the MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV feature, you should
• MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV Functionality, page 3
• MPLS LSP Ping Operation, page 4
• MPLS LSP Traceroute Operation, page 5
• MPLS Network Management with MPLS LSP Ping and MPLS LSP Traceroute, page 7
• Any Transport over MPLS Virtual Circuit Connection, page 7
• IP Does Not Forward MPLS Echo Request Packets, page 9
MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV Functionality
Internet Control Message Protocol (ICMP) ping and traceroute are often used to help diagnose the root
cause when a forwarding failure occurs. However, they are not well suited for identifying LSP failures
because an ICMP packet can be forwarded via IP to the destination when an LSP breakage occurs.
The MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV feature is well suited for
identifying LSP breakages for the following reasons:
• An MPLS echo request packet cannot be forwarded via IP because IP TTL is set to 1 and the IP
destination address field is set to a 127/8 address.
• The FEC being checked is not stored in the IP destination address field (as is the case of ICMP).
MPLS echo request and reply packets test LSPs. There are two methods by which a downstream router
can receive packets:
• The Cisco implementation of MPLS echo request and echo reply that was previously based on the
Internet Engineering Task Force (IETF) Internet Draft Detecting MPLS Data Plane Failures
(draft-ietf-mpls-lsp-ping-03.txt).
3
• Features described in this document that are based on the IETF RFC 4379 Detecting Multi-Protocol
Label Switched (MPLS) Data Plane Failures:
– Echo request output interface control
– Echo request traffic pacing
– Echo request end-of-stack explicit-null label shimming
– Echo request request-dsmap capability
– Request-fec checking
– Depth limit reporting
MPLS LSP Ping Operation

MPLS LSP ping uses MPLS echo request and reply packets to validate an LSP. You can use MPLS LSP
ping to validate IPv4 LDP, AToM, and IPv4 RSVP FECs by using appropriate keywords and arguments
with the ping mpls command.
The MPLS echo request packet is sent to a target router through the use of the appropriate label stack
associated with the LSP to be validated. Use of the label stack causes the packet to be forwarded over
the LSP itself.
The destination IP address of the MPLS echo request packet is different from the address used to select
the label stack. The destination IP address is defined as a 127.x.y.z/8 address. The 127.x.y.z/8 address
prevents the IP packet from being IP switched to its destination if the LSP is broken.
An MPLS echo reply is sent in response to an MPLS echo request. The reply is sent as an IP packet and
it is forwarded using IP, MPLS, or a combination of both types of switching. The source address of the
MPLS echo reply packet is an address obtained from the router generating the echo reply. The
destination address is the source address of the router that originated the MPLS echo request packet.
The MPLS echo reply destination port is set to the echo request source port.
Figure 1 shows MPLS LSP ping echo request and echo reply paths.
Figure 1 MPLS LSP Ping Echo Request and Echo Reply Paths
LSP
LSP headend LSP tailend

LSR1 LSR2 LSR5 LSR6
LSR3 LSR4
MPLS echo request MPLS echo reply
Originating Target router
router
LSR10 LSR9 LSR8 LSR7

103387
MPLS echo reply via IP, MPLS, or a combination of IP + MPLS
If you initiate an MPLS LSP ping request at LSR1 to a FEC at LSR6, you get the results shown in
Table 1.
4
Table 1 MPLS LSP Ping Example from Figure 1
Step Router Action

1. LSR1 Initiates an MPLS LSP ping request for an FEC at the target router LSR6 and
sends an MPLS echo request to LSR2.
2. LSR2 Receives the MPLS echo request packet and forwards it through transit routers
LSR3 and LSR4 to the penultimate router LSR5.
3. LSR5 Receives the MPLS echo request, pops the MPLS label, and forwards the packet
to LSR6 as an IP packet.
4. LSR6 Receives the IP packet, processes the MPLS echo request, and sends an MPLS
echo reply to LSR1 through an alternate route.
5. LSR7 to Receives the MPLS echo reply and forwards it back toward LSR1, the originating
LSR10 router.
6. LSR1 Receives the MPLS echo reply in response to its MPLS echo request.
MPLS LSP Traceroute Operation

MPLS LSP traceroute uses MPLS echo request and reply packets to validate an LSP. You can use MPLS
LSP traceroute to validate IPv4 LDP and IPv4 RSVP FECs by using appropriate keywords and
arguments with the trace mpls command.
The MPLS LSP Traceroute feature uses TTL settings to force expiration of the TTL along an LSP. MPLS
LSP Traceroute incrementally increases the TTL value in its MPLS echo requests (TTL = 1, 2, 3, 4) to
discover the downstream mapping of each successive hop. The success of the LSP traceroute depends
on the transit router processing the MPLS echo request when it receives a labeled packet with a TTL =
1. On Cisco routers, when the TTL expires, the packet is sent to the Route Processor (RP) for processing.
The transit router returns an MPLS echo reply containing information about the transit hop in response
to the TTL-expired MPLS packet.
The MPLS echo reply destination port is set to the echo request source port.
Note When a router traces an IPV4 FEC that goes over a traffic engineering tunnel, intermediate routers may
return U (unreachable) if LDP is not running in those intermediate routers.
Figure 2 shows an MPLS LSP traceroute example with an LSP from LSR1 to LSR4.
5
Figure 2 MPLS LSP Traceroute Example
LSP
TTL=1 1
LSR1 2 LSR2 LSR3 LSR4
LSP
TTL=2 3 4
LSP
TTL=3 6 7 8
103388
If you enter an LSP traceroute to an FEC at LSR4 from LSR1, you get the results shown in Table 2.
Table 2 MPLS LSP Traceroute Example Based on Figure 2
Step Router MPLS Packet Type and Description Router Action (Receive or Send)
1. LSR1 MPLS echo request—With a target • Sets the TTL of the label stack to 1
FEC pointing to LSR4 and to a • Sends the request to LSR2
downstream mapping
2. LSR2 MPLS echo reply • Receives the packet with a TTL = 1
• Processes the User Datagram Protocol (UDP) packet as an
MPLS echo request
• Finds a downstream mapping and replies to LSR1 with its own
downstream mapping, based on the incoming label
3. LSR1 MPLS echo request—With the same • Sets the TTL of the label stack to 2
target FEC and the downstream • Sends the request to LSR2
mapping received in the echo reply
from LSR2
4. LSR2 MPLS echo request • Receives the packet with a TTL = 2
• Decrements the TTL
• Forwards the echo request to LSR3
5. LSR3 MPLS reply packet • Receives the packet with a TTL = 1
• Processes the UDP packet as an MPLS echo request
• Finds a downstream mapping and replies to LSR1 with its own
downstream mapping based on the incoming label
6. LSR1 MPLS echo request—With the same • Sets the TTL of the packet to 3
target FEC and the downstream
• Sends the request to LSR2
mapping received in the echo reply
from LSR3
6
Table 2 MPLS LSP Traceroute Example Based on Figure 2 (continued)
Step Router MPLS Packet Type and Description Router Action (Receive or Send)
9. LSR4 MPLS echo reply • Receives the packet with a TTL = 1
• Processes the UDP packet as an MPLS echo request
• Finds a downstream mapping and also finds that the router is
the egress router for the target FEC
• Replies to LSR1
MPLS Network Management with MPLS LSP Ping and MPLS LSP Traceroute
To manage an MPLS network, you must have the ability to monitor LSPs and quickly isolate MPLS
forwarding problems. You need ways to characterize the liveliness of an LSP and reliably detect when
an LSP fails to deliver user traffic.
You can use MPLS LSP ping to verify the LSP that is used to transport packets destined for IPv4 LDP
prefixes, and AToM PW FECs. You can use MPLS LSP traceroute to trace LSPs that are used to carry
packets destined for IPv4 LDP prefixes.
An MPLS echo request is sent through an LSP to validate it. A TTL expiration or LSP breakage causes
the transit router to process the echo request before it gets to the intended destination. The router returns
an MPLS echo reply that contains an explanatory reply code to the originator of the echo request.
The successful echo request is processed at the egress of the LSP. The echo reply is sent via an IP path,
an MPLS path, or a combination of both back to the originator of the echo request.
Any Transport over MPLS Virtual Circuit Connection

AToM Virtual Circuit Connection Verification (VCCV) allows you to send control packets inband of an
AToM PW from the originating provider edge (PE) router. The transmission is intercepted at the
destination PE router, instead of being forwarded to the customer edge (CE) router. This capability
allows you to use MPLS LSP ping to test the PW section of AToM virtual circuits (VCs).
LSP ping allows verification of AToM VC setup by FEC 128 or FEC 129. FEC 128-based AToM VCs
can be set up by using LDP for signaling or by using a static pseudowire configuration without using any
signaling component on the two endpoints. Cisco IOS XE software does not distinguish between
FEC 128 and FEC 129 static pseudowires while issuing MPLS ping; the same commands are used.
AToM VCCV consists of the following:
• A signaled component in which the AToM VCCV capabilities are advertised during VC label
signaling
• A switching component that causes the AToM VC payload to be treated as a control packet
7
AToM VCCV Signaling

One of the steps involved in AToM VC setup is the signaling or communication of VC labels and AToM
VCCV capabilities between AToM VC endpoints. To communicate the AToM VCCV disposition
capabilities of each endpoint, the router uses an optional parameter, defined in the IETF Internet Draft
Pseudo Wire (PW) Virtual Circuit Connection Verification (VCCV) (draft-ieft-pwe3-vccv-01).
The AToM VCCV disposition capabilities are categorized as follows:
• Applications—MPLS LSP ping and ICMP ping are applications that AToM VCCV supports to send
packets inband of an AToM PW for control purposes.
• Switching modes—Type 1 and Type 2 are switching modes that AToM VCCV uses for
differentiating between control and data traffic.
Table 3 describes AToM VCCV Type 1 and Type 2 switching modes.
Table 3 Type 1 and Type 2 AToM VCCV Switching Modes
Switching Mode Description

Type 1 Uses a Protocol ID (PID) field in the AToM control word to identify an AToM
VCCV packet
Type 2 Uses an MPLS Router Alert Label above the VC label to identify an AToM VCCV
packet
Selection of AToM VCCV Switching Types

Cisco routers always use Type 1 switching, if available, when they send MPLS LSP ping packets over
an AToM VC control channel. Type 2 switching accommodates those VC types and implementations that
do not support or interpret the AToM control word.
Table 4 shows the AToM VCCV switching mode advertised and the switching mode selected by the
AToM VC.
Table 4 AToM VCCV Switching Mode Advertised and Selected by AToM VC
Type Advertised Type Selected

AToM VCCV not supported —
Type 1 AToM VCCV switching Type 1 AToM VCCV switching
Type 2 AToM VCCV switching Type 2 AToM VCCV switching
Type 1 and Type 2 AToM VCCV Type 1 AToM VCCV switching
switching
An AToM VC advertises its AToM VCCV disposition capabilities in both directions: that is, from the
originating router (PE1) to the destination router (PE2), and from PE2 to PE1.
In some instances, AToM VCs might use different switching types if the two endpoints have different
AToM VCCV capabilities. If PE1 supports Type 1 and Type 2 AToM VCCV switching and PE2 supports
only Type 2 AToM VCCV switching, there are two consequences:
• LSP ping packets sent from PE1 to PE2 are encapsulated with Type 2 switching.
• LSP ping packets sent from PE2 to PE1 use Type 1 switching.
8
You can determine the AToM VCCV capabilities advertised to and received from the peer by entering
the show mpls l2transport binding command at the PE router.
Information Provided by the Router Processing LSP Ping or LSP Traceroute

Table 5 describes the characters that the router processing an LSP ping or LSP traceroute packet returns
to the sender about the failure or success of the request.
You can also display the return code for an MPLS LSP Ping operation if you enter the verbose keyword
in the ping mpls command.
Table 5 Echo Reply Return Codes
Echo Return
Output Code Code Meaning
x 0 No return code.
M 1 Malformed echo request.
m 2 Unsupported TLVs.
! 3 Success.
F 4 No FEC mapping.
D 5 DS Map mismatch.
I 6 Unknown Upstream Interface index.
U 7 Reserved.
L 8 Labeled output interface.
B 9 Unlabeled output interface.
f 10 FEC mismatch.
N 11 No label entry.
P 12 No receive interface label protocol.
p 13 Premature termination of the LSP.
X unknown Undefined return code.
Note Echo return codes 6 and 7 are accepted only for Version 3 (draft-ieft-mpls-ping-03).
IP Does Not Forward MPLS Echo Request Packets

MPLS echo request packets sent during an LSP ping are never forwarded by IP. The IP header destination
address field in an MPLS echo request packet is a 127.x.y.z/8 address. Routers should not forward
packets using a 127.x.y.z/8 address. The 127.x.y.z/8 address corresponds to an address for the local host.
Use of a 127.x.y.z address as the destination address of the UDP packet is significant because the MPLS
echo request packet fails to make it to the target router if a transit router does not label switch the LSP.
The use of the 127.x.y.z address allows for the detection of LSP breakages. The following occurs at the
transit router:
9
How to Configure MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
• If an LSP breakage occurs at a transit router, the MPLS echo packet is not forwarded; it is consumed
by the router.
• If the LSP is intact, the MPLS echo packet reaches the target router and is processed by the terminal
point of the LSP.
Figure 3 shows the path of the MPLS echo request and reply when a transit router fails to label switch a
packet in an LSP.
Figure 3 Path when Transit Router Fails to Label Switch a Packet
LSP breakage
103389
MPLS echo
request PE1 PE2
Target router
MPLS echo reply
Note An AToM payload does not contain usable forwarding information at a transit router because the payload
may not be an IP packet. An MPLS VPN packet, although an IP packet, does not contain usable
forwarding information at a transit router because the destination IP address is significant only to the
virtual routing and forwarding (VRF) instances at the endpoints of the MPLS network.
How to Configure MPLS LSP Ping/Traceroute for LDP/TE, and

LSP Ping for VCCV
• Enabling Compatibility Between the MPLS LSP and Ping or Traceroute Implementation, page 11
(required)
• Validating an FEC by Using MPLS LSP Ping and MPLS LSP Traceroute, page 13 (required)
• Using DSCP to Request a Specific Class of Service in an Echo Reply, page 15 (optional)
• Controlling How a Responding Router Replies to an MPLS Echo Request, page 16 (optional)
• Preventing Loops when Using MPLS LSP Ping and LSP Traceroute Command Options, page 18
(optional)
• Detecting LSP Breaks, page 20 (optional)
10
Enabling Compatibility Between the MPLS LSP and Ping or Traceroute

Implementation
LSP ping drafts after Version 3 (draft-ietf-mpls-ping-03) have undergone numerous TLV format
changes, but the versions of the draft do not always interoperate.
To allow later Cisco implementations to interoperate with draft Version 3 Cisco and non-Cisco
implementations, use a global configuration mode to decode echo packets in formats understood by draft
Version 3 implementations.
Unless configured otherwise, a Cisco implementation encodes and decodes echo requests assuming the
version on which the IETF implementations is based.
To prevent failures reported by the replying router due to TLV version issues, you should configure all
routers in the core. Encode and decode MPLS echo packets in the same draft version. For example, if
the network is running RFC 4379 (Cisco Version 4) implementations but one router is capable of only
Version 3 (Cisco Revision 3), configure all routers in the network to operate in Revision 3 mode.
The Cisco implementation of MPLS echo request and echo reply is based on the IETF RFC 4379. IEFT
drafts subsequent to this RFC (drafts 3, 4, 5, 6, and 7) introduced TLV format differences. These
differences could not be identified because the echo packet had no way to differentiate between one TLV
format and another TLV format. To allow interoperability, a revision keyword was added for the ping
mpls and trace mpls commands. The revision keyword enables Cisco IOS XE releases to support the
existing draft changes and any changes from future versions of the IETF LSP Ping draft.
Note We recommend that you use the mpls oam global configuration command instead of the revision option.
Note No images are available on cisco.com to support Revision 2. It is recommended that you use only images
supporting Version 3 and later when configuring TLV encode and decode modes. MPLS Multipath LSP
traceroute requires Cisco Revision 4 or later.
Cisco Vendor Extensions
In Cisco’s Version 3 (draft-ietf-mpls-ping-03.txt) implementations, Cisco defined a vendor extension

TLV in the ignore-if-not-understood TLV space. It is used for the following purposes:
• Provide an ability to track TLV versions.
• Provide an experimental Reply TOS capability.
The first capability was defined before the existence of the global configuration command for setting the
echo packet encode and decode behavior. TLV version information in an echo packet overrides the
configured decoding behavior. Using this TLV for TLV versions is no longer required since the
introduction of the global configuration capability.
The second capability controls the reply DSCP. Draft Version 8 defines a Reply TOS TLV, so the use of
the reply DSCP is no longer required.
11
To enable compatibility between the MPLS LSP and ping or traceroute implementation by customizing
the default behavior of echo packets, perform the following steps.
SUMMARY STEPS
1. enable
3. mpls oam
4. echo revision {3 | 4}
5. echo vendor-extension
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls oam Enters MPLS OAM configuration mode for customizing the
default behavior of echo packets.
Example:
Router(config)# mpls oam
Step 4 echo revision {3 | 4} Specifies the revision number of the echo packet’s default
values.
Example: • 3—draft-ietf-mpls-ping-03 (Revision 2).
Router(config-mpls)# echo revision 4
• 4—RFC 4379 compliant (default).
Step 5 echo vendor-extension Sends the Cisco-specific extension of TLVs with echo
packets.
Example:
Router(config-mpls)# echo vendor-extension
Step 6 exit Returns to global configuration mode.
Example:
Router(config-mpls)# exit
12
Validating an FEC by Using MPLS LSP Ping and MPLS LSP Traceroute
An LSP is formed by labels. Routers learn labels through LDP, AToM, or some other MPLS applications.
You can use MPLS LSP ping or traceroute to validate an LSP used for forwarding traffic for a given FEC.
This section describes the following tasks:
• Validating an LDP IPv4 FEC by Using MPLS LSP Ping and MPLS LSP Traceroute, page 13
• Validating a Layer 2 FEC by Using MPLS LSP Ping and MPLS LSP Traceroute, page 14
Validating an LDP IPv4 FEC by Using MPLS LSP Ping and MPLS LSP Traceroute
To ensure that the router will be able to forward MPLS packets for IPv4 FEC prefixes advertised by LDP,
perform the following steps.
SUMMARY STEPS
1. enable
2. ping mpls ipv4 destination-address/destination-mask-length [repeat count] [exp exp-bits]
[verbose]
or
trace mpls ipv4 destination-address/destination-mask-length
3. exit
DETAILED STEPS

Example:
Router> enable
13

Step 2 ping mpls ipv4 destination-address Selects an LDP IPv4 prefix FEC for validation.
/destination-mask-length [repeat count] [exp
exp-bits] [verbose]
or
trace mpls ipv4 destination-address
/destination-mask-length
Example:
Router# ping mpls ipv4 10.131.191.252/32 exp 5
repeat 5 verbose
or
Example:
Router# trace mpls ipv4 10.131.191.252/32
Step 3 exit Returns to user EXEC mode.
Example:
Router# exit
Validating a Layer 2 FEC by Using MPLS LSP Ping and MPLS LSP Traceroute
To ensure that the router will be able to forward MPLS packets for Layer 2 FEC prefixes advertised by
LDP, perform the following steps.
SUMMARY STEPS
1. enable
2. ping mpls pseudowire ipv4-address vc-id vc-id
3. exit
DETAILED STEPS

Example:
Router> enable
14

Step 2 ping mpls pseudowire ipv4-address vc-id vc-id Selects a Layer 2 FEC for validation.
Example:
Router# ping mpls pseudowire 10.131.191.252
vc-id 333
Example:
Router# exit
Using DSCP to Request a Specific Class of Service in an Echo Reply

Cisco IOS XE software includes a reply differentiated services code point (DSCP) option that lets you
request a specific class of service (CoS) in an echo reply.
The reply DSCP option is supported in the experimental mode for IETF draft-ietf-mpls-lsp-ping-03.txt.
Cisco implemented a vendor-specific extension for the reply DSCP option rather than using a Reply TOS
TLV. A Reply TOS TLV serves the same purpose as the reply dscp command in RFC 4379. This draft
provides a standardized method of controlling the reply DSCP.
Note Before draft Version 8, Cisco implemented the Reply DSCP option as an experimental capability using
a Cisco vendor extension TLV. If a router is configured to encode MPLS echo packets for draft Version 3
implementations, a Cisco vendor extension TLV is used instead of the Reply TOS TLV that was defined
in draft Version 8.
To use DSCP to request a specific CoS in an echo reply, perform the following steps.
SUMMARY STEPS
1. enable
2. ping mpls {ipv4 destination-address/destination-mask-length | pseudowire ipv4-address vc-id
vc-id } [reply dscp dscp-value]
or
trace mpls ipv4 destination-address/destination-mask-length [reply dscp dscp-value]
3. exit
15
DETAILED STEPS

Example:
Router> enable
Step 2 ping mpls {ipv4 destination-address Controls the DSCP value of an echo reply.
/destination-mask-length | pseudowire
ipv4-address vc-id vc-id} [reply dscp
dscp-value]
or
/destination-mask-length [reply dscp
dscp-value]
Example:
Router# ping mpls ipv4 10.131.191.252/32 reply
dscp 50
or
Example:
Router# trace mpls ipv4 10.131.191.252/32 reply
dscp 50
Example:
Router# exit
Controlling How a Responding Router Replies to an MPLS Echo Request

To control how a responding router replies to an MPLS echo request, see the “Reply Modes for an MPLS
LSP Ping and LSP Traceroute Echo Request Response” section.
Reply Modes for an MPLS LSP Ping and LSP Traceroute Echo Request Response
The reply mode controls how a responding router replies to an MPLS echo request sent by a ping mpls
or trace mpls command. There are two reply modes for an echo request packet:
• ipv4—Reply with an IPv4 UDP packet (default)
• router-alert—Reply with an IPv4 UDP packet with router alert
Note It is useful to use ipv4 and router-alert reply modes in conjunction with each other to prevent false
negatives. If you do not receive a reply via the ipv4 mode, it is useful to send a test with the router-alert
reply mode. If both fail, something is wrong in the return path. The problem may be only that the Reply
TOS is not set correctly.
16
ipv4 Reply Mode
IPv4 packet is the most common reply mode used with a ping mpls or trace mpls command when you
want to periodically poll the integrity of an LSP. With this option, you do not have explicit control over
whether the packet traverses IP or MPLS hops to reach the originator of the MPLS echo request. If the
originating (headend) router fails to receive a reply to an MPLS echo request when you use the reply
mode ipv4 keywords, use the reply mode router-alert keywords.
Router-alert Reply Mode
The router-alert reply mode adds the router alert option to the IP header. When an IP packet that contains
an IP router alert option in its IP header or an MPLS packet with a router alert label as its outermost label
arrives at a router, the router punts (redirects) the packet to the Route Processor (RP) level for handling.
This forces the Cisco router to handle the packet at each intermediate hop as it moves back to the
destination. Hardware and line-card forwarding inconsistencies are bypassed. Router-alert reply mode
is more expensive than IPv4 mode because the reply goes hop-by-hop. It also is slower, so the sender
receives a reply in a relatively longer period of time.
Table 6 describes how IP and MPLS packets with an IP router alert option are handled by the router
switching path processes.
Table 6 Path Process Handling of IP and MPLS Router Alert Packets
Incoming Packet Normal Switching Action Process Switching Action Outgoing Packet
IP packet—Router alert Router alert option in IP header Forwards the packet as is IP packet—Router alert
option in IP header causes the packet to be punted to option in IP header
the process switching path.
Forwards the packet as is MPLS packet
MPLS packet— If the router alert label is the Removes the outermost router IP packet—Router alert
Outermost label contains outermost label, it causes the alert label and forwards the option in IP header
a router alert packet to be punted to the process packet as an IP packet
switching path.
Preserves the outermost router MPLS packet—
alert label and forwards the Outermost label contains
MPLS packet a router alert.
SUMMARY STEPS
1. enable
2. ping mpls {ipv4 destination-address/destination-mask-length | pseudowire ipv4-address vc-id
vc-id} reply mode {ipv4 | router-alert}
or
trace mpls ipv4 destination-address/destination-mask reply mode {ipv4 | router-alert}
3. exit
17
DETAILED STEPS

Example:
Router> enable
Step 2 ping mpls {ipv4 destination-address Checks MPLS LSP connectivity.
/destination-mask-length | pseudowire
ipv4-address vc-id vc-id} reply mode {ipv4 | or
router-alert}
Discovers MPLS LSP routes that packets actually take
or when traveling to their destinations.
trace mpls ipv4 destination-address Note To specify the reply mode, you must enter the reply
/destination-mask reply mode {ipv4 | mode keyword with the ipv4 or router-alert
router-alert} keyword.
Example:
Router# ping mpls ipv4 10.131.191.252/32 reply
mode ipv4
or
Router# trace mpls ipv4 10.131.191.252/32 reply
mode router-alert
Example:
Router# exit
Preventing Loops when Using MPLS LSP Ping and LSP Traceroute Command
Options
The interaction of the MPLS Embedded Management—LSP Ping for LDP feature options can cause
loops. See the following sections for a description of the loops you may encounter with the ping mpls
and trace mpls commands:
• Using MPLS LSP Ping to Discover Possible Loops, page 18
• Using MPLS LSP Traceroute to Discover Possible Loops, page 19
Using MPLS LSP Ping to Discover Possible Loops

With the MPLS LSP Ping feature, loops can occur if you use the UDP destination address range, repeat
option, or sweep option.
To use MPLS LSP ping to discover possible loops, perform the following steps.
18
SUMMARY STEPS
1. enable
2. ping mpls {ipv4 destination-address/destination-mask [destination address-start address-end
increment] | [pseudowire ipv4-address vc-id vc-id address-end increment] } [repeat count] [sweep
minimum maximum size-increment]
3. exit
DETAILED STEPS

Example:
Router> enable
/destination-mask [destination address-start
address-end increment] |[pseudowire
ipv4-address vc-id vc-id address-end
increment]} [repeat count] [sweep minimum
maximum size-increment]
Example:
Router# ping mpls ipv4 10.131.159.251/32
destination 127.0.0.1 127.0.0.2 1 repeat 2
sweep 1450 1475 25
Example:
Router# exit
Using MPLS LSP Traceroute to Discover Possible Loops

With the MPLS LSP Traceroute feature, loops can occur if you use the UDP destination address range
option and the time-to-live option.
By default, the maximum TTL is set to 30. Therefore, the traceroute output may contain 30 lines if the
target of the traceroute is not reached, which can happen when an LSP problem exists. If an LSP problem
occurs, there may be duplicate entries. The router address of the last point that the trace reaches is
repeated until the output is 30 lines. You can ignore the duplicate entries.
SUMMARY STEPS
1. enable
2. trace mpls ipv4 destination-address/destination-mask [destination address-start address-end
address-increment] [ttl maximum-time-to-live]
3. exit
19
DETAILED STEPS

Example:
Router> enable
Step 2 trace mpls ipv4 destination-address Discovers MPLS LSP routes that packets take when
/destination-mask [destination address-start traveling to their destinations. The example shows how a
address-end address increment] [ttl
maximum-time-to-live]
loop can occur.
Example:
destination 127.0.0.1 127.0.0.3 1 ttl 5
Example:
Router# exit
Detecting LSP Breaks

If there is a problem forwarding MPLS packets in your network, you can determine where there are LSP
breaks. This section describes MTU discovery in an LSP.
Untagged output interfaces at a penultimate hop do not impact the forwarding of IP packets through an
LSP because the forwarding decision is made at the penultimate hop through use of the incoming label.
However, untagged output interfaces cause AToM and MPLS VPN traffic to be dropped at the
penultimate hop.
During an MPLS LSP ping, MPLS echo request packets are sent with the IP packet attribute set to “do
not fragment.” That is, the Don’t Fragment (DF) bit is set in the IP header of the packet. This allows you
to use the MPLS echo request to test for the MTU that can be supported for the packet through the LSP
without fragmentation.
Figure 4 shows a sample network with a single LSP from PE1 to PE2 formed with labels advertised by
the LDP.
Figure 4 Sample Network with LSP—Labels Advertised by LDP
10.131.191.251 10.131.159.251
10.131.191.253 10.131.191.252 10.131.159.252 10.131.159.253
FE2/0/0 FE0/0/0 FE1/0/0 FE0/0/0 FE2/0/0
FE2/0/0 FE0/0/0 FE1/0/0 FE0/0/0 FE2/0/0
192821
CE1 10.0.0.1 PE1 P1 P2 PE2 10.0.0.2 CE2
You can determine the maximum receive unit (MRU) at each hop by using the MPLS Traceroute feature
to trace the LSP. The MRU is the maximum size of a labeled packet that can be forwarded through an
LSP.
20

• Tracking Packets Tagged as Implicit Null, page 21
• Tracking Untagged Packets, page 22
• Determining Why a Packet Could Not Be Sent, page 22
• Detecting LSP Breaks when Load Balancing Is Enabled for IPv4 LDP LSPs, page 23
• Specifying the Interface Through Which Echo Packets Leave a Router, page 24
• Pacing the Transmission of Packets, page 25
• Interrogating the Transit Router for Its Downstream Information by Using Echo Request
request-dsmap, page 26
• Interrogating a Router for Its DSMAP, page 27
• Requesting that a Transit Router Validate the Target FEC Stack, page 28
• Enabling LSP Ping to Detect LSP Breakages Caused by Untagged Interfaces, page 29
• Viewing the AToM VCCV Capabilities Advertised to and Received from the Peer, page 30
Tracking Packets Tagged as Implicit Null

To track packets tagged as implicit null, perform the following steps.
SUMMARY STEPS
1. enable
2. trace mpls ipv4 destination-address /destination-mask
3. exit
DETAILED STEPS

Example:
Router> enable
Step 2 trace mpls ipv4 destination-address Discovers MPLS LSP routes that packets actually take
/destination-mask when traveling to their destinations.
Example:
Example:
Router# exit
21
Tracking Untagged Packets

To track untagged packets, perform the following steps.
SUMMARY STEPS
1. enable
2. show mpls forwarding-table destination-address/destination-mask
3. show mpls ldp discovery
4. exit
DETAILED STEPS

Example:
Router> enable
Step 2 show mpls forwarding-table Displays the content of the MPLS Label Forwarding
destination-address/destination-mask Information Base (LFIB) and displays whether the LDP is
properly configured.
Example:
10.131.159.252/32
Step 3 show mpls ldp discovery Displays the status of the LDP discovery process and
displays whether the LDP is properly configured.
Example:
Example:
Router# exit
Determining Why a Packet Could Not Be Sent

The Q return code means that the packet could not be sent. The problem can be caused by insufficient
processing memory, but it probably results because an LSP could not be found that matches the FEC
information that was entered on the command line.
You need to determine the reason why the packet was not forwarded so that you can fix the problem in
the path of the LSP. To do so, look at the Routing Information Base (RIB), the Forwarding Information
Base (FIB), the Label Information Base (LIB), and the MPLS LFIB. If there is no entry for the FEC in
any of these routing or forwarding bases, there is a Q return code.
To determine why a packet could not be transmitted, perform the following steps.
22
SUMMARY STEPS
1. enable
2. show ip route [ip-address [mask]]
3. show mpls forwarding-table [network {mask | length} | labels label [- label] | interface interface
| next-hop address | lsp-tunnel [tunnel-id]]
4. exit
DETAILED STEPS

Example:
Router> enable
Step 2 show ip route [ip-address [mask]] Displays the current state of the routing table.
When the MPLS echo reply returns a Q, troubleshooting
Example: occurs on the routing information database.
Router# show ip route 10.0.0.1
Step 3 show mpls forwarding-table [network {mask | Displays the content of the MPLS LFIB. When the MPLS
length} | labels label [-label] | interface echo reply returns a Q, troubleshooting occurs on a label
interface | next-hop address | lsp-tunnel
[tunnel-id]]
information database and an MPLS forwarding information
database.
Example:
Router# show mpls forwarding-table 10.0.0.1/32
Example:
Router# exit
Detecting LSP Breaks when Load Balancing Is Enabled for IPv4 LDP LSPs
An ICMP ping or trace follows one path from the originating router to the target router. Round robin load
balancing of IP packets from a source router discovers the various output paths to the target IP address.
For MPLS ping and traceroute, Cisco routers use the source and destination addresses in the IP header
for load balancing when multiple paths exist through the network to a target router. The Cisco
implementation of MPLS may check the destination address of an IP payload to accomplish load
balancing (the type of checking depends on the platform).
To detect LSP breaks when load balancing is enabled for IPv4 LDP LSPs, perform the following steps.
SUMMARY STEPS
1. enable
2. ping mpls ipv4 destination-address/destination-mask-length [destination address-start
address-end increment]
3. exit
23
DETAILED STEPS

Example:
Router> enable
Step 2 ping mpls ipv4 destination-address Checks for load balancing paths.
/destination-mask-length [destination
address-start address-end increment] Enter the 127.z.y.x/8 destination address.
Example:
destination 127.0.0.1/8
Example:
Router# exit
Specifying the Interface Through Which Echo Packets Leave a Router

To specify the interface through which echo packets leave a router, perform the following steps.
Echo Request Output Interface Control
You can control the interface through which packets leave a router. Path output information is used as
input to LSP ping and traceroute.
The echo request output interface control feature allows you to force echo packets through the paths that
perform detailed debugging or characterizing of the LSP. This feature is useful if a PE router connects
to an MPLS cloud and there are broken links. You can direct traffic through a certain link. The feature
also is helpful for troubleshooting network problems.
To specify the output interface for echo requests, perform the following steps.
SUMMARY STEPS
1. enable
2. ping mpls {ipv4 destination-address/destination-mask | pseudowire ipv4-address vc-id vc-id}
[output interface tx-interface]
or
trace mpls ipv4 destination-address/destination-mask [output interface tx-interface]
3. exit
24
DETAILED STEPS

Example:
Router> enable
/destination-mask | pseudowire ipv4-address
vc-id vc-id} [output interface tx-interface] or
or
when traveling to their destinations.
trace mpls ipv4
destination-address/destination-mask [output Note For this task, you must specify the output interface
interface tx-interface] keyword.
Example:
Router# ping mpls ipv4 10.131.159.251/32 output
or
output interface fastethernet0/0/0
Example:
Router# exit
Pacing the Transmission of Packets

Echo request traffic pacing allows you to pace the transmission of packets so that the receiving router
does not drop packets. To perform echo request traffic pacing, perform the following steps.
SUMMARY STEPS
1. enable
[interval ms]
or
trace mpls ipv4 destination-address/destination-mask
3. exit
25
DETAILED STEPS

Example:
Router> enable
vc-id vc-id} [interval ms] or
Discovers MPLS LSP routes that packets take when
or
traveling to their destinations.
/destination-mask Note In this task, if you use the ping mpls command you
must specify the interval keyword.
Example:
interval 2
or
Example:
Example:
Router# exit
Interrogating the Transit Router for Its Downstream Information by Using Echo Request
request-dsmap
The echo request request-dsmap capability troubleshooting feature, used in conjunction with the TTL
flag, allows you to selectively interrogate a transit router. If there is a failure, you do not have to enter
an lsp traceroute command for each previous failure; you can focus just on the failed hop.
A request-dsmap flag in the downstream mapping flags field, and procedures that specify how to trace
noncompliant routers allow you to arbitrarily time-to-live (TTL) expire MPLS echo request packets with
a wildcard downstream map (DSMAP).
Echo request DSMAPs received without labels indicate that the sender did not have any DSMAPs to
validate. If the downstream router ID field of the DSMAP TLV in an echo request is set to the
ALLROUTERs address (224.0.0.2) and there are no labels, the source router can arbitrarily query a
transit router for its DSMAP information.
The ping mpls command allows an MPLS echo request to be TTL-expired at a transit router with a
wildcard DSMAP for the explicit purpose of troubleshooting and querying the downstream router for its
DSMAPs. The default is that the DSMAP has an IPv4 bitmap hashkey. You also can select hashkey 0
(none). The purpose of the ping mpls command is to allow the source router to selectively TTL expire
an echo request at a transit router to interrogate the transit router for its downstream information. The
ability to also select a multipath (hashkey) type allows the transmitting router to interrogate a transit
router for load-balancing information as is done with multipath LSP traceroute, but without having to
26
interrogate all subsequent nodes traversed between the source router and the router on which each echo
request TTL expires. Use an echo request in conjunction with the TTL setting because if an echo request
arrives at the egress of the LSP with an echo request, the responding routers never return DSMAPs.
To interrogate the transit router for its downstream information so that you can focus just on the failed
hop if there is a failure, perform the following steps.
SUMMARY STEPS
1. enable
[dsmap [hashkey {none | ipv4 bitmap bitmap-size}]]
3. exit
DETAILED STEPS

Example:
Router> enable
vc-id vc-id} [dsmap [hashkey {none | ipv4 Note In this task, you must specify the dsmap and
bitmap bitmap-size}]] hashkey keywords.
Example:
Router# ping mpls ipv4 10.161.251/32 dsmap
hashkey ipv4 bitmap 16
Example:
Router# exit
Interrogating a Router for Its DSMAP

The router can interrogate the software or hardware forwarding layer for the depth limit that needs to be
returned in the DSMAP TLV. If forwarding does not provide a value, the default is 255.
To determine the depth limit, specify the dsmap and ttl keywords in the ping mpls command. The transit
router will be interrogated for its DSMAP. The depth limit is returned with the echo reply DSMAP. A
value of 0 means that the IP header is used for load balancing. Another value indicates that the IP header
load balances up to the specified number of labels.
To interrogate a router for its DSMAP, perform the following steps.
SUMMARY STEPS
1. enable
2. ping mpls {ipv4 destination-address/destination-mask | pseudowire ipv4-address vc-id vc-id} ttl
time-to-live dsmap
27
3. exit
DETAILED STEPS

Example:
Router> enable
vc-id vc-id} ttl time-to-live dsmap Note You must specify the ttl and dsmap keywords.
Example:
Router# ping mpls ipv4 10.131.159.252/32 ttl 1
dsmap
Example:
Router# exit
Requesting that a Transit Router Validate the Target FEC Stack

An MPLS echo request tests a particular LSP. The LSP to be tested is identified by the FEC stack.
To request that a transit router validate the target FEC stack, set the V flag from the source router by
entering the flags fec keyword in the ping mpls and trace mpls commands. The default is that echo
request packets are sent with the V flag set to 0.
To request that a transit router validate the target FEC stack, perform the following steps.
SUMMARY STEPS
1. enable
flags fec
or
trace mpls ipv4 destination-address/destination-mask flags fec
3. exit
28
DETAILED STEPS

Example:
Router> enable
vc-id vc-id} flags fec or
or
/destination-mask flags fec Note You must enter the flags fec keyword.
Example:
Router# ping mpls ipv4 10.131.159.252/32 flags
fec
or
Example:
Router# trace mpls ipv4 10.131.159.252/32 flags
fec
Example:
Router# exit
Enabling LSP Ping to Detect LSP Breakages Caused by Untagged Interfaces

For MPLS LSP ping and traceroute of LSPs carrying IPv4 FECs, you can force an explicit null label to
be added to the MPLS label stack even though the label was unsolicited. This allows LSP ping to detect
LSP breakages caused by untagged interfaces. LSP ping does not report that an LSP is operational when
it is unable to send MPLS traffic.
An explicit null label is added to an MPLS label stack if MPLS echo request packets are forwarded from
untagged interfaces that are directly connected to the destination of the LSP ping or if the IP TTL value
for the MPLS echo request packets is set to 1.
When you enter an lsp ping command, you are testing the LSP’s ability to carry IP traffic. Failure at
untagged output interfaces at the penultimate hop are not detected. Explicit-null shimming allows you
to test an LSP’s ability to carry MPLS traffic.
To enable LSP ping to detect LSP breakages caused by untagged interfaces, specify the
force-explicit-null keyword in the ping mpls or trace mpls commands as shown in the following steps.
29
SUMMARY STEPS
1. enable
force-explicit-null
or
trace mpls ipv4 destination-address/destination-mask force-explicit-null
3. exit
DETAILED STEP

Example:
Router> enable
vc-id vc-id} force-explicit-null or
or
/destination-mask force-explicit-null Note You must enter the force-explicit-null keyword.
Example:
force-explicit null
or
Example:
force-explicit-null
Example:
Router# exit
Viewing the AToM VCCV Capabilities Advertised to and Received from the Peer
To view the AToM VCCV capabilities advertised to and received from the peer, perform the following
steps.
SUMMARY STEPS
1. enable
3. exit
30
Configuration Examples for MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
DETAILED STEPS

Example:
Router> enable
Step 2 show mpls l2transport binding Displays VC label binding information.
Example:
Example:
Router# exit
Configuration Examples for MPLS LSP Ping/Traceroute for

LDP/TE, and LSP Ping for VCCV
Examples for the MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV feature are based
on the sample topology shown in Figure 5.
Figure 5 Sample Topology for Configuration Examples
10.131.191.253 10.131.191.252 10.131.191.251 10.131.159.251 10.131.159.252 10.131.159.253

FE2/0/0 FE0/0/0 FE1/0/0 FE1/0/0 FE0/0/0 FE0/0/0 FE2/0/0
192823
FE1/1/0 FE1/1/0 FE0/1/0 FE0/1/0
FE2/0/0 FE0/0/0 FE2/0/0
CE1 10.0.0.1 PE1 P1 P2 PE2 10.0.0.2 CE2
LSP

• Enabling Compatibility Between the MPLS LSP and Ping or Traceroute Implementation: Example,
page 32
• Validating an FEC by Using MPLS LSP Ping and LSP Traceroute: Example, page 32
• Using DSCP to Request a Specific Class of Service in an Echo Reply: Example, page 33
• Controlling How a Responding Router Replies to an MPLS Echo Request: Example, page 33
• Preventing Loops when Using MPLS LSP Ping and LSP Traceroute Command Options: Example,
page 33
• Detecting LSP Breaks: Example, page 37
• Viewing the AToM VCCV Capabilities Advertised to and Received from the Peer: Example, page 58
31
Enabling Compatibility Between the MPLS LSP and Ping or Traceroute

Implementation: Example
The following example shows how to configure MPLS multipath LSP traceroute to interoperate with a
vendor implementation that does not interpret RFC 4379 as Cisco does:
configure terminal
!
mpls oam
echo revision 4
no echo vendor-extension
exit
The default echo revision number is 4, which corresponds to the IEFT draft 11.
Validating an FEC by Using MPLS LSP Ping and LSP Traceroute: Example
This section describes the following procedures:
• Validating an LDP IPv4 FEC by Using MPLS LSP Ping and MPLS LSP Traceroute: Example,
page 32
• Validating a Layer 2 FEC by Using MPLS LSP Ping: Example, page 32
Validating an LDP IPv4 FEC by Using MPLS LSP Ping and MPLS LSP Traceroute: Example
The following example shows how to use the ping mpls command to test connectivity of an
IPv4 LDP LSP:
Router# ping mpls ipv4 10.131.191.252/32 repeat 5 exp 5 verbose
Sending 5, 100-byte MPLS Echos to 10.131.191.252, timeout is 2 seconds:
Codes:
'!' - success, 'Q' - request not sent, '.' - timeout,
'M' - malformed request, 'm' - unsupported tlvs, 'N' - no rx label,
'R' - transit router, 'X' - unknown return code, 'x' - return code 0

! 10.131.191.230, return code 3
! 10.131.191.230, return code 3
! 10.131.191.230, return code 3
! 10.131.191.230, return code 3
! 10.131.191.230, return code 3
Success rate is 100 percent (5/5), round-trip min/avg/max = 100/10
Validating a Layer 2 FEC by Using MPLS LSP Ping: Example

The following example validates a Layer 2 FEC:
Router# ping mpls pseudowire 10.10.10.15 108 vc-id 333
Sending 5, 100-byte MPLS Echos to 10.10.10.15,

32


!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/32/40 ms PE-802#
Using DSCP to Request a Specific Class of Service in an Echo Reply: Example

The following example shows how to use DSCP to request a specific CoS in an echo reply:
Router# ping mpls ipv4 10.131.159.252/32 reply dscp 50
<0-63> Differentiated services codepoint value

af11 Match packets with AF11 dscp (001010)
cs1 Match packets with CS1(precedence 1) dscp (001000)
default Match packets with default dscp (000000)
ef Match packets with EF dscp (101110)
Controlling How a Responding Router Replies to an MPLS Echo Request:

Example
The following example checks MPLS LSP connectivity by using ipv4 reply mode:
Router# ping mpls ipv4 10.131.191.252/32 reply mode ipv4
Preventing Loops when Using MPLS LSP Ping and LSP Traceroute Command
Options: Example
• Possible Loops with MPLS LSP Ping: Example, page 34
• Possible Loop with MPLS LSP Traceroute: Example, page 35
33
Possible Loops with MPLS LSP Ping: Example

The following example shows how a loop operates if you use the following ping mpls command:
Router# ping mpls ipv4 10.131.159.251/32 destination 127.0.0.1 127.0.0.2 1 repeat 2
sweep 1450 1475 25
Sending 2, [1450..1500]-byte MPLS Echos to 10.131.159.251/32,

Codes:

Destination address 127.0.0.1
!
!
!
!
!
!
!
!
A ping mpls command is sent for each packet size range for each destination address until the end
address is reached. For this example, the loop continues in the same manner until the destination address,
127.0.0.5, is reached. The sequence continues until the number is reached that you specified with the
repeat count keyword and argument. For this example, the repeat count is 2. The MPLS LSP ping loop
sequence is as follows:
repeat = 1
destination address 1 (address-start)
for (size from sweep minimum to maximum, counting by size-increment)
send an lsp ping
destination address 2 (address-start + address-increment)

send an lsp ping
destination address 3 (address-start + address-increment + address-increment)

send an lsp ping
.
.
.
until destination address = address-end
.
.
.
until repeat = count 2
34
Possible Loop with MPLS LSP Traceroute: Example

The following example shows how a loop occurs if you use the following trace mpls command:
Router# trace mpls ipv4 10.131.159.251/32 destination 127.0.0.1 127.0.0.3 1 ttl 5
Tracing MPLS Label Switched Path to 10.131.159.251/32, timeout is 2 seconds
Codes:

0 10.131.191.230 MRU 1500 [Labels: 19 Exp: 0]
R 1 10.131.159.226 MRU 1504 [implicit-null] 40 ms
! 2 10.131.159.225 40 ms
0 10.131.191.230 MRU 1500 [Labels: 19 Exp: 0]
! 2 10.131.159.225 40 ms
0 10.131.191.230 MRU 1500 [Labels: 19 Exp: 0]
! 2 10.131.159.225 48 ms
An mpls trace command is sent for each TTL from 1 to the maximum TTL (ttl maximum-time-to-live
keyword and argument) for each destination address until the address specified with the destination
end-address argument is reached. In this example, the maximum TTL is 5 and the end destination
address is 127.0.0.3. The MPLS LSP traceroute loop sequence is as follows:
destination address 1 (address-start)
for (ttl from 1 to maximum-time-to-live)
send an lsp trace
destination address 2 (address-start + address-increment)

for (ttl from 1 to 5)
send an lsp trace
destination address 3 (address-start + address-increment + address-increment)

for (ttl from 1 to maximum-time-to-live)
send an lsp trace
.
.
.
until destination address = 4
The following example shows that the trace encountered an LSP problem at the router that has an IP
address of 10.6.1.6:
Router# traceroute mpls ipv4 10.6.7.4/32
Codes:
35


0 10.6.1.14 MRU 4470 [Labels: 22 Exp: 0]
R 1 10.6.1.5 MRU 4470 [Labels: 21 Exp: 0] 2 ms
R 2 10.6.1.6 4 ms <------ Router address repeated for 2nd to 30th TTL.
R 3 10.6.1.6 1 ms
R 4 10.6.1.6 1 ms
R 5 10.6.1.6 3 ms
R 6 10.6.1.6 4 ms
R 7 10.6.1.6 1 ms
R 8 10.6.1.6 2 ms
R 9 10.6.1.6 3 ms
R 10 10.6.1.6 4 ms
R 11 10.6.1.6 1 ms
R 12 10.6.1.6 2 ms
R 13 10.6.1.6 4 ms
R 14 10.6.1.6 5 ms
R 15 10.6.1.6 2 ms
R 16 10.6.1.6 3 ms
R 17 10.6.1.6 4 ms
R 18 10.6.1.6 2 ms
R 19 10.6.1.6 3 ms
R 20 10.6.1.6 4 ms
R 21 10.6.1.6 1 ms
R 22 10.6.1.6 2 ms
R 23 10.6.1.6 3 ms
R 24 10.6.1.6 4 ms
R 25 10.6.1.6 1 ms
R 26 10.6.1.6 3 ms
R 27 10.6.1.6 4 ms
R 28 10.6.1.6 1 ms
R 29 10.6.1.6 2 ms
R 30 10.6.1.6 3 ms <------ TTL 30.
If you know the maximum number of hops in your network, you can set the TTL to a lower value with
the trace mpls ttl maximum-time-to-live command. The following example shows the same traceroute
command as the previous example, except that this time the TTL is set to 5:
Router# traceroute mpls ipv4 10.6.7.4/32 ttl 5
Codes:

0 10.6.1.14 MRU 4470 [Labels: 22 Exp: 0]
R 1 10.6.1.5 MRU 4474 [No Label] 3 ms
R 2 10.6.1.6 4 ms <------ Router address repeated for 2nd to 5th TTL.
R 3 10.6.1.6 1 ms
R 4 10.6.1.6 3 ms
R 5 10.6.1.6 4 ms
36
Detecting LSP Breaks: Example

• Troubleshooting with LSP Ping or Traceroute: Example, page 37
• MTU Discovery in an LSP: Example, page 47
• Tracking Packets Tagged as Implicit Null: Example, page 48
• Tracking Untagged Packets: Example, page 49
• Determining Why a Packet Could Not Be Sent: Example, page 50
• Detecting LSP Breaks when Load Balancing Is Enabled for IPv4 LSPs: Example, page 51
• Specifying the Interface Through Which Echo Packets Leave a Router: Example, page 52
• Pacing the Transmission of Packets: Example, page 54
• Interrogating the Transit Router for Its Downstream Information: Example, page 54
• Interrogating a Router for Its DSMAP: Example, page 56
• Requesting that a Transit Router Validate the Target FEC Stack: Example, page 56
• Enabling LSP Ping to Detect LSP Breakages Caused by Untagged Interfaces: Example, page 57
Troubleshooting with LSP Ping or Traceroute: Example

ICMP ping and trace commands are often used to help diagnose the root cause of a failure. When an
LSP is broken, the packet may reach the target router by IP forwarding, thus making the ICMP ping and
traceroute features unreliable for detecting MPLS forwarding problems. The MPLS LSP ping or
traceroute and AToM VCCV features extend this diagnostic and troubleshooting ability to the MPLS
network and handle inconsistencies (if any) between the IP and MPLS forwarding tables, inconsistencies
in the MPLS control and data plane, and problems with the reply path.
Figure 6 shows a sample topology with an LDP LSP.
Figure 6 Sample Topology with LDP LSP
10.131.191.253 10.131.191.252 10.131.191.251 10.131.159.251 10.131.159.252 10.131.159.253

FE2/0/0 FE0/0/0 FE1/0/0 FE0/0/0 FE2/0/0
FE2/0/0 FE0/0/0 FE1/0/0 FE0/0/0 FE2/0/0
CE1 10.0.0.1 PE1 PE2 10.0.0.2 CE2
192822
P1 P2
FE1/0/0 FE1/0/0
This section contains the following subsections:

• Configuration for Sample Topology, page 37
• Verification That the LSP Is Configured Correctly, page 44
• Discovery of LSP Breaks, page 45
Configuration for Sample Topology
These are sample topology configurations for the troubleshooting examples in the following sections
(see Figure 6). There are the six sample router configurations.
37
Router CE1 Configuration

Following is the configuration for the CE1 router:
!
version 2.3
service timestamps debug datetime msec
service timestamps log datetime msec
!
hostname CE1
!
boot-start-marker
boot-end-marker
!
enable password lab
!
clock timezone EST -5
ip subnet-zero
!
!
!
interface Loopback0
ip address 10.131.191.253 255.255.255.255
no clns route-cache
!
!
no ip address
no keepalive
no cdp enable
no clns route-cache
!
ip address 10.0.0.1 255.255.255.0
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password lab
login
!
end
Router PE1 Configuration

Following is the configuration for the PE1 router:
!
version 2.3
!
hostname PE1
!
boot-start-marker
boot-end-marker
38
!
logging snmp-authfail
enable password lab
!
ip subnet-zero
ip cef
no ip domain-lookup
!
mpls ldp discovery targeted-hello accept
!
!
!
interface Loopback0
ip address 10.131.191.252 255.255.255.255
no clns route-cache
!
ip address 10.131.191.230 255.255.255.252
ip rsvp signalling dscp 0
!
ip address 10.131.159.246 255.255.255.252
shutdown
no clns route-cache
!
no ip address
no cdp enable
no clns route-cache
!
!
!
router ospf 1
passive-interface Loopback0
network 10.131.159.244 0.0.0.3 area 0
network 10.131.191.228 0.0.0.3 area 0
network 10.131.191.232 0.0.0.3 area 0
network 10.131.191.252 0.0.0.0 area 0
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password lab
login
!
!
end
39
Router P1 Configuration
Following is the configuration for the P1 router:
version 2.3
!
hostname P1
!
boot-start-marker
boot-end-marker
!
enable password lab
!
ip subnet-zero
ip cef
no ip domain-lookup
!
!
!
!
!
no clns route-cache
!
interface Loopback0
ip address 10.131.191.251 255.255.255.255
no clns route-cache
!
ip address 10.131.191.229 255.255.255.252
no clns route-cache
!
ip address 10.131.159.226 255.255.255.252
no clns route-cache
!
ip address 10.131.159.222 255.255.255.252
no clns route-cache
!
!
router ospf 1
network 10.131.159.220 0.0.0.3 area 0
network 10.131.159.224 0.0.0.3 area 0
network 10.131.191.228 0.0.0.3 area 0
network 10.131.191.251 0.0.0.0 area 0
40
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password lab
login
!
end
Router P2 Configuration
Following is the configuration for the P2 router:
!
version 2.3
!
hostname P2
!
boot-start-marker
boot-end-marker
!
enable password lab
!
ip subnet-zero
ip cef
no ip domain-lookup
!
!
!
!
interface Loopback0
ip address 10.131.159.251 255.255.255.255
!
ip address 10.131.159.229 255.255.255.252
!
ip address 10.131.159.233 255.255.255.252
!
ip address 10.131.159.225 255.255.255.252
!
ip address 10.131.159.221 255.255.255.252
41

!
!
router ospf 1
network 10.131.159.220 0.0.0.3 area 0
network 10.131.159.224 0.0.0.3 area 0
network 10.131.159.228 0.0.0.3 area 0
network 10.131.159.232 0.0.0.3 area 0
network 10.131.159.251 0.0.0.0 area 0
!
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password lab
login
!
end
Router PE2 Configuration

Following is the configuration for the PE2 router:
!
version 2.3
!
hostname PE2
!
boot-start-marker
boot-end-marker
!
enable password lab
!
ip subnet-zero
ip cef
no ip domain-lookup
!
!
!
!
interface Loopback0
ip address 10.131.159.252 255.255.255.255
no clns route-cache
!
ip address 10.131.159.230 255.255.255.252
no clns route-cache
!
42
ip address 10.131.159.234 255.255.255.252

no clns route-cache
!
ip address 10.131.159.245 255.255.255.252
mpls ip
no clns route-cache
!
no ip address
no cdp enable
no clns route-cache
!
no snmp trap link-status
no cdp enable
!
!
router ospf 1
network 10.131.122.0 0.0.0.3 area 0
network 10.131.159.228 0.0.0.3 area 0
network 10.131.159.232 0.0.0.3 area 0
network 10.131.159.236 0.0.0.3 area 0
network 10.131.159.244 0.0.0.3 area 0
network 10.131.159.252 0.0.0.0 area 0
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password lab
login
!
!
end
Router CE2 Configuration

Following is the configuration for the CE2 router:
!
version 2.3
!
hostname CE2
!
boot-start-marker
boot-end-marker
!
enable password lab
!
ip subnet-zero
ip cef
43
no ip domain-lookup
!
!
interface Loopback0
ip address 10.131.159.253 255.255.255.255
no clns route-cache
!
no ip address
no keepalive
no cdp enable
no clns route-cache
!
ip address 10.0.0.2 255.255.255.0
!
!
line con 0
exec-timeout 0 0
line aux 0
line vty 0 4
exec-timeout 0 0
password lab
login
!
end
Verification That the LSP Is Configured Correctly
Use the output from the show commands in this section to verify that the LSP is configured correctly.
A show mpls forwarding-table command shows that tunnel 1 is in the MPLS forwarding table.
PE1# show mpls forwarding-table 10.131.159.252

22 18 [T] 10.131.159.252/32 0 Tu1 point2point
[T] Forwarding through a TSP tunnel.

View additional tagging info with the 'detail' option
A trace mpls command issued at PE1 verifies that packets with 16 as the outermost label and 18 as the
end-of-stack label are forwarded from PE1 to PE2.
PE1# trace mpls ipv4 10.131.159.252/32
Codes:
44

0 10.131.191.252 MRU 1496 [Labels: 16/18 Exp: 0/0] L 1 10.131.191.229
MRU 1508 [Labels: 18 Exp: 0] 0 ms L 2 10.131.159.225
MRU 1504 [Labels: implicit-null Exp: 0] 0 ms ! 3 10.131.159.234 20 ms
PE1#
The MPLS LSP Traceroute to PE2 is successful, as indicated by the exclamation point (!).
Discovery of LSP Breaks
Use the output of the commands in this section to discover LSP breaks.
An LDP target session is established between routers PE1 and P2, as shown in the output of the following
show mpls ldp discovery command:
PE1# show mpls ldp discovery

10.131.191.252:0
Discovery Sources:
Interfaces:
LDP Id: 10.131.191.251:0
Targeted Hellos:
10.131.191.252 -> 10.131.159.252 (ldp): active/passive, xmit/recv
LDP Id: 10.131.159.252:0
LDP Id: 10.131.159.251:0
Enter the following command on the P2 router in global configuration mode:

P2(config)# no mpls ldp discovery targeted-hello accept
The LDP configuration change causes the targeted LDP session between the headend and tailend of the
TE tunnel to go down. Labels for IPv4 prefixes learned by P2 are not advertised to PE1. Thus, all IP
prefixes reachable by P2 are reachable by PE1 only through IP (not MPLS). In other words, packets
destined for those prefixes through Tunnel 1 at PE1 will be IP switched at P2 (which is undesirable).
The following show mpls ldp discovery command shows that the LDP targeted session is down:
PE1# show mpls ldp discovery

10.131.191.252:0
Discovery Sources:
Interfaces:
LDP Id: 10.131.191.251:0
Targeted Hellos:
10.131.191.252 -> 10.131.159.252 (ldp): active/passive, xmit/recv
LDP Id: 10.131.159.252:0
10.131.191.252 -> 10.131.159.251 (ldp): active, xmit
Enter the show mpls forwarding-table command at the PE1 router. The display shows that the outgoing
packets are untagged as a result of the LDP configuration changes.

22 Untagged[T] 10.131.159.252/32 0 Tu1 point2point
45
[T] Forwarding through a TSP tunnel.

View additional tagging info with the 'detail' option
A ping mpls command entered at the PE1 router displays the following:
PE1# ping mpls ipv4 10.131.159.252/32 repeat 1
Sending 1, 100-byte MPLS Echos to 10.131.159.252/32,

Codes:

R
Success rate is 0 percent (0/1)
The ping mpls command fails. The R indicates that the sender of the MPLS echo reply had a routing
entry but no MPLS FEC. Entering the verbose keyword with the ping mpls command displays the
MPLS LSP echo reply sender address and the return code. You should be able to determine where the
breakage occurred by telnetting to the replying router and inspecting its forwarding and label tables. You
might need to look at the neighboring upstream router as well, because the breakage might be on the
upstream router.
PE1# ping mpls ipv4 10.131.159.252/32 repeat 1 verbose

Codes:

R 10.131.159.225, return code 6
Alternatively, use the LSP traceroute command to figure out which router caused the breakage. In the
following example, for subsequent values of TTL greater than 2, the same router keeps responding
(10.131.159.225). This suggests that the MPLS echo request keeps getting processed by the router
regardless of the TTL. Inspection of the label stack shows that P1 pops the last label and forwards the
packet to P2 as an IP packet. This explains why the packet keeps getting processed by P2. MPLS echo
request packets cannot be forwarded by use of the destination address in the IP header because the
address is set to a 127/8 address.
PE1# trace mpls ipv4 10.131.159.252/32 ttl 5
46
Codes:

0 10.131.191.230 MRU 1496 [Labels: 22/19 Exp: 0/0]
! 3 10.131.159.230 40 ms
pe1#
MTU Discovery in an LSP: Example

The following example shows the results of a trace mpls command when the LSP is formed with labels
created by LDP:
PE1# trace mpls ipv4 10.131.159.252/32
Codes:

0 10.131.191.230 MRU 1496 [Labels: 22/19 Exp: 0/0]
! 3 10.131.159.230 40 ms
pe1#
You can determine the MRU for the LSP at each hop through the use of the show mpls forwarding detail
command:
PE1# show mpls forwarding 10.131.159.252 detail

22 19 10.131.159.252/32 0 Tu1 point2point
MAC/Encaps=14/22, MRU=1496, Tag Stack{22 19}, via Et0/0
AABBCC009700AABBCC0098008847 0001600000013000
To determine how large an echo request will fit on the LSP, first calculate the size of the IP MTU by
using the show interface interface-name command:
PE1# show interface e0/0
FastEthernet0/0/0 is up, line protocol is up

Hardware is Lance, address is aabb.cc00.9800 (bia aabb.cc00.9800)
MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255
Encapsulation ARPA, loopback not set
Keepalive set (10 sec)
ARP type: ARPA, ARP Timeout 04:00:00
47

Last clearing of “show interface” counters never
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
0 input packets with dribble condition detected
0 babbles, 0 late collision, 0 deferred
0 lost carrier, 0 no carrier
The IP MTU in the show interface interface-name example is 1500 bytes. Subtract the number of bytes
corresponding to the label stack from the MTU number. The output of the show mpls forwarding
command indicates that the Tag stack consists of one label (21). Therefore, the largest MPLS echo
request packet that can be sent in the LSP is 1500 – (2 x 4) = 1492.
You can validate this by using the following mpls ping command:
PE1# ping mpls ipv4 10.131.159.252/32 sweep 1492 1500 1 repeat 1
Sending 1, [1492..1500]-byte MPLS Echos to 10.131.159.252/32,

Codes:

!QQQQQQQQ
In this command, echo packets that have a range in size from 1492 to 1500 bytes are sent to the
destination address. Only packets of 1492 bytes are sent successfully, as indicated by the exclamation
point (!). Packets of byte sizes 1493 to 1500 are source-quenched, as indicated by the Qs.
You can pad an MPLS echo request so that a payload of a given size can be tested. The pad TLV is useful
when you use the MPLS echo request to discover the MTU that is supportable by an LSP. MTU discovery
is extremely important for applications like AToM that contain non-IP payloads that cannot be
fragmented.
Tracking Packets Tagged as Implicit Null: Example

In the following example, Tunnel 1 is shut down, and only an LSP formed with LDP labels is established.
An implicit null is advertised between the P2 and PE2 routers. Entering an MPLS LSP traceroute
command at the PE1 router results in the following output that shows that packets are forwarded from
P2 to PE2 with an implicit-null label. Address 10.131.159.229 is configured for the P2 Fast Ethernet
0/0/0 out interface for the PE2 router.
PE1# trace mpls ipv4 10.131.159.252/32
48
Codes:

0 10.131.191.230 MRU 1496 [Labels: 22/19 Exp: 0/0]
! 3 10.131.159.230 40 ms
pe1#
Tracking Untagged Packets: Example

Untagged cases are valid configurations for IGP LSPs that could cause problems for MPLS VPNs.
A show mpls forwarding-table command and a show mpls ldp discovery command issued at the P2
router show that LDP is properly configured:
P2# show mpls forwarding-table 10.131.159.252

19 Pop tag 10.131.159.252/32 0 fe0/0/0 10.131.159.230
P2# show mpls ldp discovery

10.131.159.251:0
Discovery Sources:
Interfaces:
LDP Id: 10.131.159.252:0
LDP Id: 10.131.191.251:0
The show mpls ldp discovery command output shows that Fast Ethernet interface 0/0/0, which connects
PE2 to P2, is sending and receiving packets.
If a no mpls ip command is entered on Fast Ethernet interface 0/0/0, this could prevent an LDP session
between the P2 and PE2 routers from being established. A show mpls ldp discovery command entered
on the PE router shows that the MPLS LDP session with the PE2 router is down.
P2# show mpls ldp discovery

10.131.159.251:0
Discovery Sources:
Interfaces:
FastEthernet0/0/0 (ldp): xmit
LDP Id: 10.131.191.251:0
If the MPLS LDP session to PE2 goes down, the LSP to 10.131.159.252 becomes untagged, as shown
by the show mpls forwarding-table command:
P2# show mpls forwarding-table 10.131.159.252/32
49

19 Untagged 10.131.159.252/32 864 fe0/0/0 10.131.159.230
Untagged cases would provide an MPLS LSP traceroute reply with packets tagged with No Label, as
shown in the following display. You may need to reestablish an MPLS LSP session from interface P2 to
PE2 by entering an mpls ip command on the output interface from P2 to PE2, which is Fast Ethernet
0/0/0 in this example:
PE1# trace mpls ipv4 10.131.159.252/32
Codes:

0 10.131.191.230 MRU 1500 [Labels: 20 Exp: 0]
R 2 10.131.159.229 MRU 1504 [No Label] 28 ms <----No MPLS session from P2 to PE2.
! 3 10.131.159.230 40 ms
Determining Why a Packet Could Not Be Sent: Example

The following example shows a ping mpls command when an MPLS echo request is not sent. The
transmission failure is shown by the returned Qs.
PE1# ping mpls ipv4 10.0.0.1/32

Codes:

QQQQQ
The following show mpls forwarding-table command and show ip route command demonstrate that
the IPv4 address (10.0.0.1)address is not in the LFIB or RIB routing table. Therefore, the MPLS echo
request is not sent.

PE1# show ip route 10.0.0.1
% Subnet not in table
50
Detecting LSP Breaks when Load Balancing Is Enabled for IPv4 LSPs: Example
In the following examples, different paths are followed to the same destination. The output from these
examples demonstrates that load balancing occurs between the originating router and the target router.
To ensure that Fast Ethernet interface 1/0/0 on the PE1 router is operational, enter the following
commands on the PE1 router:
PE1# configure terminal
PE1(config)# interface fastethernet 1/0/0
PE1(config-if)# no shutdown
PE1(config-if)# end
*Dec 31 19:14:10.034: %LINK-3-UPDOWN: Interface FastEthernet1/0/0, changed state to up

*Dec 31 19:14:11.054: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEthernet1/0/0,
changed state to upend
PE1#
*Dec 31 19:14:12.574: %SYS-5-CONFIG_I: Configured from console by console
*Dec 31 19:14:19.334: %OSPF-5-ADJCHG: Process 1, Nbr 10.131.159.252 on FastEthernet1/0/0
from LOADING to FULL, Loading Done
PE1#
The following show mpls forwarding-table command displays the possible outgoing interfaces and
next hops for the prefix 10.131.159.251/32:
PE1# show mpls forwarding-table 10.131.159.251/32

21 19 10.131.159.251/32 0 fe0/0/0 10.131.191.229
20 10.131.159.251/32 0 fe1/0/0 10.131.159.245
The following ping mpls command to 10.131.159.251/32 with a destination UDP address of 127.0.0.1
shows that the selected path has a path index of 0:
Router# ping mpls ipv4 10.131.159.251/32 destination 127.0.0.1/32

Codes:

!
PE1#
*Dec 29 20:42:40.638: LSPV: Echo Request sent on IPV4 LSP, load_index 2,
pathindex 0, size 100
*Dec 29 20:42:40.638: 46 00 00 64 00 00 40 00 FF 11 9D 03 0A 83 BF FC
*Dec 29 20:42:40.638: 7F 00 00 01 94 04 00 00 0D AF 0D AF 00 4C 14 70
*Dec 29 20:42:40.638: 00 01 00 00 01 02 00 00 1A 00 00 1C 00 00 00 01
*Dec 29 20:42:40.638: C3 9B 10 40 A3 6C 08 D4 00 00 00 00 00 00 00 00
*Dec 29 20:42:40.638: 00 01 00 09 00 01 00 05 0A 83 9F FB 20 00 03 00
51
*Dec 29 20:42:40.638: 13 01 AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*Dec 29 20:42:40.638: AB CD AB CD
*Dec 29 20:42:40.678: LSPV: Echo packet received: src 10.131.159.225,
dst 10.131.191.252, size 74
*Dec 29 20:42:40.678: AA BB CC 00 98 01 AA BB CC 00 FC 01 08 00 45 C0
*Dec 29 20:42:40.678: 00 3C 32 D6 00 00 FD 11 15 37 0A 83 9F E1 0A 83
*Dec 29 20:42:40.678: BF FC 0D AF 0D AF 00 28 D1 85 00 01 00 00 02 02
*Dec 29 20:42:40.678: 03 00 1A 00 00 1C 00 00 00 01 C3 9B 10 40 A3 6C
*Dec 29 20:42:40.678: 08 D4 C3 9B 10 40 66 F5 C3 C8
The following ping mpls command to 10.131.159.251/32 with a destination UDP address of 127.0.0.3
shows that the selected path has a path index of 1:
PE1# ping mpls ipv4 10.131.159.251/32 destination 127.0.0.3/32

Codes:

!
PE1#
*Dec 29 20:43:09.518: LSPV: Echo Request sent on IPV4 LSP, load_index 13,
pathindex 1, size 100
*Dec 29 20:43:09.518: 46 00 00 64 00 00 40 00 FF 11 9D 01 0A 83 BF FC
*Dec 29 20:43:09.518: 7F 00 00 03 94 04 00 00 0D AF 0D AF 00 4C 88 58
*Dec 29 20:43:09.518: 00 01 00 00 01 02 00 00 38 00 00 1D 00 00 00 01
*Dec 29 20:43:09.518: C3 9B 10 5D 84 B3 95 84 00 00 00 00 00 00 00 00
*Dec 29 20:43:09.518: 00 01 00 09 00 01 00 05 0A 83 9F FB 20 00 03 00
*Dec 29 20:43:09.518: 13 01 AB CD AB CD AB CD AB CD AB CD AB CD AB CD
*Dec 29 20:43:09.518: AB CD AB CD
*Dec 29 20:43:09.558: LSPV: Echo packet received: src 10.131.159.229,
dst 10.131.191.252, size 74
*Dec 29 20:43:09.558: AA BB CC 00 98 01 AA BB CC 00 FC 01 08 00 45 C0
*Dec 29 20:43:09.558: 00 3C 32 E9 00 00 FD 11 15 20 0A 83 9F E5 0A 83
*Dec 29 20:43:09.558: BF FC 0D AF 0D AF 00 28 D7 57 00 01 00 00 02 02
*Dec 29 20:43:09.558: 03 00 38 00 00 1D 00 00 00 01 C3 9B 10 5D 84 B3
*Dec 29 20:43:09.558: 95 84 C3 9B 10 5D 48 3D 50 78
To see the actual path chosen, enter the debug mpls lspv command with the packet and data keywords.
Note The load balancing algorithm attempts to uniformly distribute packets across the available output paths
by hashing based on the IP header source and destination addresses. The selection of the address-start,
address-end, and address-increment arguments for the destination keyword may not provide the
expected results.
Specifying the Interface Through Which Echo Packets Leave a Router: Example
The following example tests load balancing from the upstream router:
Router# ping mpls ipv4 10.131.161.251/32 ttl 1 repeat 1 dsmap hashkey ipv4 bitmap 8
52



L
Echo Reply received from 10.131.131.2
DSMAP 0, DS Router Addr 10.131.141.130, DS Intf Addr 10.131.141.130
Depth Limit 0, MRU 1500 [Labels: 54 Exp: 0]
Multipath Addresses:
127.0.0.3 127.0.0.5 127.0.0.7 127.0.0.8

127.0.0.1 127.0.0.2 127.0.0.4 127.0.0.6
The following example validates that the transit router reported the proper results by determining the
Echo Reply sender address two hops away and checking the rx label advertised upstream:
Router# trace mpls ipv4 10.131.161.251/32 destination 127.0.0.6 ttl 2


0 10.131.131.1 10.131.131.2 MRU 1500 [Labels: 37 Exp: 0]
L 1 10.131.131.2 10.131.141.2 MRU 1500 [Labels: 40 Exp: 0] 0 ms, ret code 8
L 2 10.131.141.2 10.131.150.2 MRU 1504 [Labels: implicit-null Exp: 0] 0 ms, ret code 8
Router#
Router# telnet 10.131.141.2
Trying 10.131.141.2 ... Open
User Access Verification
Password:
Router> enable
The following example shows how the output interface keyword forces an LSP traceroute out
FastEthernet interface 0/0/0:
Router# show mpls forwarding-table 10.131.159.251
Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or VC or Tunnel Id Switched interface
20 19 10.131.159.251/32 0 fe1/0/0 10.131.159.245
18 10.131.159.251/32 0 fe0/0/0 10.131.191.229
53

0 10.131.159.246 MRU 1500 [Labels: 19 Exp: 0]
L 1 10.131.159.245 MRU 1504 [Labels: implicit-null Exp: 0] 4 ms
! 2 10.131.159.229 20 ms
Router# trace mpls ipv4 10.131.159.251/32 output-interface fastethernet0/0/0

0 10.131.191.230 MRU 1500 [Labels: 18 Exp: 0]
! 2 10.131.159.225 1 ms
Pacing the Transmission of Packets: Example

The following example shows the pace of the transmission of packets:
Router# ping mpls ipv4 10.5.5.5/32 interval 100



!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 28/29/36 ms PE-802
Interrogating the Transit Router for Its Downstream Information: Example

The following example shows sample output when a router with two output paths is interrogated:
Router# ping mpls ipv4 10.161.251/32 ttl 4 repeat 1 dsmap hashkey ipv4 bitmap 16



L
127.0.0.3 127.0.0.6 127.0.0.9 127.0.0.10
127.0.0.12 127.0.0.13 127.0.0.14 127.0.0.15
127.0.0.16
54

127.0.0.1 127.0.0.2 127.0.0.4 127.0.0.5
127.0.0.7 127.0.0.8 127.0.0.11
The multipath addresses cause a packet to transit to the router with the output label stack. The ping mpls
command is useful for determining the number of output paths, but when the router is more than one hop
away a router cannot always use those addresses to get the packet to transit through the router being
interrogated. This situation exists because the change in the IP header destination address may cause the
packet to be load-balanced differently by routers between the source router and the responding router.
Load balancing is affected by the source address in the IP header. The following example tests
load-balancing reporting from the upstream router:
Router# ping mpls ipv4 10.131.161.251/32 ttl 1 repeat 1 dsmap hashkey ipv4 bitmap 8



L
127.0.0.3 127.0.0.5 127.0.0.7 127.0.0.8

127.0.0.1 127.0.0.2 127.0.0.4 127.0.0.6
To validate that the transit router reported the proper results, determine the Echo Reply
sender address that is two hops away and consistently check the rx label that is
advertised upstream. The following is sample output:
Router# trace mpls ipv4 10.131.161.251/32 destination 127.0.0.6 ttl 2


0 10.131.131.1 10.131.131.2 MRU 1500 [Labels: 37 Exp: 0]
L 1 10.131.131.2 10.131.141.2 MRU 1500 [Labels: 40 Exp: 0] 0 ms, ret code 8
L 2 10.131.141.2 10.131.150.2 MRU 1504 [Labels: implicit-null Exp: 0] 0 ms, ret code 8
55
Router#
Trying 10.131.141.2 ... Open
User Access Verification
Password:
Router> enable
Router# show mpls forwarding-table 10.131.161.251

40 Pop tag 10.131.161.251/32 268 fe1/0/0 10.131.150.2
Router#
Interrogating a Router for Its DSMAP: Example

The following example interrogates the software and hardware forwarding layer for their depth limit that
needs to be returned in the DSMAP TLV.
Router# ping mpls ipv4 10.131.159.252/32 ttl 1 dsmap

Codes:

L
127.0.0.1 127.0.0.2 127.0.0.3 127.0.0.4
127.0.0.5 127.0.0.6 127.0.0.7 127.0.0.8
127.0.0.9 127.0.0.10 127.0.0.11 127.0.0.12
127.0.0.13 127.0.0.14 127.0.0.15 127.0.0.16
127.0.0.17 127.0.0.18 127.0.0.19 127.0.0.20
127.0.0.21 127.0.0.22 127.0.0.23 127.0.0.24
127.0.0.25 127.0.0.26 127.0.0.27 127.0.0.28
127.0.0.29 127.0.0.30 127.0.0.31 127.0.0.32
Requesting that a Transit Router Validate the Target FEC Stack: Example
The following example causes a transit router to validate the target FEC stack by which an LSP to be
tested is identified:
Router# trace mpls ipv4 10.5.5.5/32 flags fec
56


0 10.2.3.2 10.2.3.3 MRU 1500 [Labels: 19 Exp: 0] L 1 10.2.3.3 10.3.4.4 MRU 1500 [Labels:
19 Exp: 0] 40 ms, ret code 8 L 2 10.3.4.4 10.4.5.5 MRU 1504 [Labels: implicit-null Exp: 0]
32 ms, ret code 8 ! 3 10.4.5.5 40 ms, ret code 3
Sending 5, 100-byte MPLS Echos to 10.5.5.5/32


! size 100, reply addr 10.4.5.5, return code 3
Enabling LSP Ping to Detect LSP Breakages Caused by Untagged Interfaces: Example
The following example shows the extra label that is added to the end of the label stack when there is
explicit-null label shimming:
Router# trace mpls ipv4 10.131.159.252/32 force-explicit-null
Codes:

0 10.131.191.252 MRU 1492 [Labels: 16/18/explicit-null Exp: 0/0/0]
L 1 10.131.191.229 MRU 1508 [Labels: 18/explicit-null Exp: 0/0] 0 ms
L 2 10.131.159.225 MRU 1508 [Labels: explicit-null Exp: 0] 0 ms
! 3 10.131.159.234 4 ms
The following example shows the command output when there is not explicit-null label shimming:
57


0 10.131.191.252 MRU 1496 [Labels: 16/18 Exp: 0/0]
L 1 10.131.191.229 MRU 1508 [Labels: 18 Exp: 0] 4 ms
! 3 10.131.159.234 4 ms
Viewing the AToM VCCV Capabilities Advertised to and Received from the
Peer: Example
The following example shows that router PE1 advertises both AToM VCCV Type 1 and Type 2 switching
capabilities and that the remote router PE2 advertises only a Type 2 switching capability.

Local Label: 16
VCCV Capabilities: Type 1, Type 2 <----- Locally advertised VCCV capabilities
Remote Label: 19
VCCV Capabilities: Type 2 <-----Remotely advertised VCCV capabilities
The following sections provide references related to the MPLS LSP Ping/Traceroute for LDP/TE, and
LSP Ping for VCCV feature.
Related Documents
MPLS applications
AToM and MPLS Any Transport over MPLS
Standards
Standard Title
58
MIBs
MIB MIBs Link
No new or modified MIBs are supported, and support To locate and download MIBs for selected platforms, Cisco IOS XE
for existing MIBs has not been modified. software releases, and feature sets, use Cisco MIB Locator found at
the following URL:
RFCs
RFC Title
draft-ietf-pwe3-vccv-01.txt Pseudo-Wire (PW) Virtual Circuit Connection Verification (VCCV)
RFC 2113 IP Router Alert Option
RFC 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
Description Link
59
Feature Information for MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
Feature Information for MPLS LSP Ping/Traceroute for LDP/TE,

and LSP Ping for VCCV
Table 7 Feature Information for MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV

MPLS Embedded Management —LSP Cisco IOS XE This feature was introduced on Cisco ASR 1000 Series
Ping/Traceroute for LDP Release 2.1 Aggregation Services Routers.
MPLS Embedded Management—LSP Cisco IOS XE The MPLS Embedded Management—LSP Ping/Trace for LDP
Ping/Trace for LDP and Resource Release 2.3 feature was modified to include support for RSVP IPv4 FECs.
Reservation Protocol (RSVP) IPv4
Forwarding Equivalence Classes
(FECs)
MPLS LSP Ping/Traceroute for Cisco IOS XE The MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for
LDP/TE, and LSP Ping for VCCV Release 2.3 VCCV feature helps service providers monitor label switched
paths and quickly isolate MPLS forwarding problems.
• Information About MPLS LSP Ping/Traceroute for
LDP/TE, and LSP Ping for VCCV, page 3
• How to Configure MPLS LSP Ping/Traceroute for
LDP/TE, and LSP Ping for VCCV, page 10
The following commands were introduced or modified: debug
mpls lspv, echo, mpls oam, ping mpls, show mpls oam, echo
statistics, trace mpls.
60
Glossary
Glossary
FEC—forwarding equivalence class. A set of packets that can be handled equivalently for forwarding
purposes and are thus suitable for binding to a single label. Examples include the set of packets destined
for one address prefix and the packets in any flow.
flow—A set of packets traveling between a pair of hosts, or between a pair of transport protocol ports
on a pair of hosts. For example, packets with the same source address, source port, destination address,
and destination port might be considered a flow.
A flow is also a stream of data traveling between two endpoints across a network (for example, from one
LAN station to another). Multiple flows can be transmitted on a single circuit.
fragmentation—The process of breaking a packet into smaller units when they are to be transmitted
over a network medium that cannot support the original size of the packet.
ICMP— Internet Control Message Protocol. A network layer Internet protocol that reports errors and
provides other information relevant to IP packet processing. It is documented in RFC 792.
LFIB—Label Forwarding Information Base. A data structure and way of managing forwarding in which
destinations and incoming labels are associated with outgoing interfaces and labels.
localhost—A name that represents the host router (device). The localhost uses the reserved loopback IP
address 127.0.0.1.
LSP—label switched path. A connection between two routers in which MPLS forwards the packets.
LSPV—Label Switched Path Verification. An LSP Ping subprocess. It encodes and decodes MPLS echo
requests and replies, and it interfaces with IP, MPLS, and AToM switching for sending and receiving
MPLS echo requests and replies. At the MPLS echo request originator router, LSPV maintains a
database of outstanding echo requests for which echo responses have not been received.
MPLS router alert label—An MPLS label of 1. An MPLS packet with a router alert label is redirected
by the router to the Route Processor (RP) processing level for handling. This allows these packets to
bypass any forwarding failures in hardware routing tables.
MRU—maximum receive unit. Maximum size, in bytes, of a labeled packet that can be forwarded
through an LSP.
MTU—maximum transmission unit. Maximum packet size, in bytes, that a particular interface can send
or receive.
punt—Redirect packets with a router alert from the line card or interface to Route Processor (RP) level
processing for handling.
PW—pseudowire. A form of tunnel that carries the essential elements of an emulated circuit from one
provider edge (PE) router to another PE router over a packet-switched network.
RP—Route Processor. The processor module in a Cisco 7000 series router that contains the CPU, system
software, and most of the memory components that are used in the router. It is sometimes called a
supervisory processor.
(bandwidth, jitter, maximum burst, and so on) of the packet streams they want to receive. RSVP depends
on IPv6. Is is also known as Resource Reservation Setup Protocol.
TLV—type, length, values. A block of information included in a Cisco Discovery Protocol address.
TTL hiding—Time-to-live is a parameter you can set that indicates the maximum number of hops a
packet should take to reach its destination.
61
Glossary
UDP—User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack.
UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery,
so error processing and retransmission must be handled by other protocols. UDP is defined in RFC 768.
countries.
coincidental.
62
MPLS EM—MPLS LSP Multipath Tree Trace

The MPLS EM—MPLS LSP Multipath Tree Trace feature provides the means to discover all possible
equal-cost multipath (ECMP) routing paths of a label switched path (LSP) between an egress and ingress
router. Once discovered, these paths can be retested on a periodic basis using Multiprotocol Label
Switching (MPLS) LSP ping or traceroute. This feature is an extension to the MPLS LSP traceroute
functionality for the tracing of IPv4 LSPs.
You can use the MPLS EM—MPLS LSP Multipath Tree Trace feature to discover all paths for an IPv4
LSP.
This implementation of the MPLS EM—MPLS LSP Multipath Tree Trace feature is based on RFC 4379,
Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures.
For information on the use of MPLS LSP ping and traceroute, see the MPLS LSP Ping/Traceroute for
LDP/TE, and LSP Ping for VCCV feature module.
Cisco IOS XE MPLS Embedded Management (EM) is a set of standards and value-added services that
facilitate the deployment, operation, administration, and management of MPLS-based networks
according to the fault, configuration, accounting, performance, and security (FCAPS) model.

which each feature is supported, see the “Feature Information for MPLS EM—MPLS LSP Multipath Tree
Trace” section on page 33.
Contents
Contents
• Prerequisites for MPLS EM—MPLS LSP Multipath Tree Trace, page 2
• Restrictions for MPLS EM—MPLS LSP Multipath Tree Trace, page 2
• Information About MPLS EM—MPLS LSP Multipath Tree Trace, page 3
• How to Configure MPLS EM—MPLS LSP Multipath Tree Trace, page 4
• Configuration Examples for MPLS EM—MPLS LSP Multipath Tree Trace, page 22
• Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace, page 33
Prerequisites for MPLS EM—MPLS LSP Multipath Tree Trace

The following are prerequisites for using the MPLS EM—MPLS LSP Multipath Tree Trace feature:
• You must understand the concepts and know how to use MPLS LSP ping or traceroute as described
in the MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV document.
• The routers in your network must be using an implementation based on RFC 4379, Detecting
Multi-Protocol Label Switched (MPLS) Data Plane Failures.
• You should know the following about your MPLS network:
– The topology
– The number of links in your network
– The expected number of LSPs, and how many LSPs
• Understand label switching, forwarding, and load balancing.
Restrictions for MPLS EM—MPLS LSP Multipath Tree Trace

• All restrictions that apply to the MPLS LSP Ping and LSP Traceroute features also apply to the
MPLS EM—MPLS LSP Multipath Tree Trace feature:
– You cannot use the MPLS LSP Multipath Tree Trace feature to trace the path taken by AToM
packets. The MPLS LSP Multipath Tree Trace feature is not supported for AToM. (MPLS LSP
Ping is supported for AToM.) However, you can use the MPLS LSP Multipath Tree Trace
feature to troubleshoot the Interior Gateway Protocol (IGP) LSP that is used by AToM.
– You cannot use the MPLS LSP Multipath Tree Trace feature to validate or trace MPLS Virtual
Private Networks (VPNs). Multiple LSP paths are not discovered unless all routers in the MPLS
core support an RFC 4379 implementation of Detecting Multi-Protocol Label Switched (MPLS)
Data Plane Failures.
• MPLS LSP multipath tree trace is not expected to operate in networks that support time-to-live
(TTL) hiding.
2
Information About MPLS EM—MPLS LSP Multipath Tree Trace
Information About MPLS EM—MPLS LSP Multipath Tree Trace

Before using the MPLS EM—MPLS LSP Multipath Tree Trace feature, you need an understanding of
• Overview of MPLS LSP Multipath Tree Trace, page 3
• Discovery of IPv4 Load Balancing Paths by MPLS LSP Multipath Tree Trace, page 3
• Echo Reply Return Codes Sent by the Router Processing Multipath LSP Tree Trace, page 4
Overview of MPLS LSP Multipath Tree Trace

As the number of MPLS deployments increases, the number of traffic types the MPLS networks carry
could increase. In addition, load balancing on label switch routers (LSRs) in the MPLS network provides
alternate paths for carrying MPLS traffic to a target router. The ability of service providers to monitor
LSPs and quickly isolate MPLS forwarding problems is critical to their ability to offer services.
Prior to the release of the MPLS EM—MPLS LSP Multipath Tree Trace feature no automated way
existed to discover all paths between provider edge (PE) routers. Troubleshooting forwarding problems
between PEs was cumbersome.
The release of the MPLS EM—MPLS LSP Multipath Tree Trace feature provides an automated way to
discover all paths from the ingress PE router to the egress PE router in multivendor networks that use
IPv4 load balancing at the transit routers. Once the PE-to-PE paths are discovered, use MPLS LSP ping
and MPLS LSP traceroute to periodically test them.
The MPLS EM—MPLS LSP Multipath Tree Trace feature requires the Cisco RFC-compliant
implementation that is based on RFC 4379. If you do not have a Cisco IOS XE software release that
supports RFC 379, MPLS LSP multipath tree trace does not operate to discover all PE-to-PE paths.
Discovery of IPv4 Load Balancing Paths by MPLS LSP Multipath Tree Trace
IPv4 load balancing at a transit router is based on the incoming label stack and the source and destination
addresses in the IP header. The outgoing label stack and IP header source address remain constant for
each branch being traced.
When you execute MPLS LSP multipath tree trace on the source LSR, the router needs to find the set of
IP header destination addresses to use all possible output paths. The source LSR starts path discovery by
sending a transit router a bitmap in an MPLS echo request. The transit router returns information in an
MPLS echo request that contains subsets of the bitmap in a downstream map (DS Map) in an echo reply.
The source router can then use the information in the echo reply to interrogate the next router. The source
router interrogates each successive router until it finds one bitmap setting that is common to all routers
along the path. The router uses TTL expiry to interrogate the routers to find the common bits.
For example, you could start path discovery by entering the following command at the source router:
Router# trace mpls multipath ipv4 10.131.101.129/32 hashkey ipv4 bitmap 16
This command sets the IP address of the target router as 10.131.101.192 255.255.255.255 and
configures:
• The default hash key type to 8, which requests that an IPv4 address prefix and bit mask address set
be returned in the DS Map in the echo reply.
3
How to Configure MPLS EM—MPLS LSP Multipath Tree Trace
• The bitmap size to 16. This means that MPLS LSP multipath tree trace uses 16 addresses (starting
with 127.0.0.1) in the discovery of all paths of an LSP between the source router and the target
router.
If you enter the trace mpls multipath ipv4 10.131.101.129/32 command, MPLS LSP multipath tree
trace uses the default hash type of 8 or IPv4 and a default bitmap size of 32. Your choice of a bitmap size
depends on the number of routes in your network. If you have a large number of routes, you might need
to use a larger bitmap size.
Echo Reply Return Codes Sent by the Router Processing Multipath LSP Tree
Trace
Table 1 describes the characters that the router processing a multipath LSP tree trace packet returns to
the sender about the failure or success of the request.
Table 1 Echo Reply Return Codes
Echo Return
Output Code Code Meaning
Period “.” — A timeout occurred before the target router could reply.
x 0 No return code.
M 1 Malformed request.
m 2 Unsupported type, length, values (TLVs).
! 3 Success.
F 4 No Forwarding Equivalence Class (FEC) mapping.
D 5 DS Map mismatch.
R 6 Downstream router but not target.
U 7 Reserved.
L 8 Labeled output interface.
B 9 Unlabeled output interface.
f 10 FEC mismatch.
N 11 No label entry.
P 12 No receive interface label protocol.
p 13 Premature termination of the LSP.
X unknown Undefined return code.

• Customizing the Default Behavior of MPLS Echo Packets, page 5 (optional)
• Configuring MPLS LSP Multipath Tree Trace, page 7 (required)
• Discovering IPv4 Load Balancing Paths Using MPLS LSP Multipath Tree Trace, page 9 (required)
4
• Monitoring LSP Paths Discovered by MPLS LSP Multipath Tree Trace Using MPLS LSP
Traceroute, page 10 (optional)
• Using DSCP to Request a Specific Class of Service in an Echo Reply, page 13 (optional)
• Controlling How a Responding Router Replies to an MPLS Echo Request, page 14 (optional)
• Specifying the Output Interface for Echo Packets Leaving a Router for MPLS LSP Multipath Tree
Trace, page 16 (optional)
• Setting the Pace of MPLS Echo Request Packet Transmission for MPLS LSP Multipath Tree Trace,
page 17 (optional)
• Enabling MPLS LSP Multipath Tree Trace to Detect LSP Breakages Caused by an Interface That
Lacks an MPLS Configuration, page 18 (optional)
• Requesting That a Transit Router Validate the Target FEC Stack for MPLS LSP Multipath Tree
Trace, page 19 (optional)
• Setting the Number of Timeout Attempts for MPLS LSP Multipath Tree Trace, page 21 (optional)
Customizing the Default Behavior of MPLS Echo Packets

Perform the following task to customize the default behavior of MPLS echo packets. You might need to
customize the default echo packet encoding and decoding behavior to allow later implementations of the
Detecting MPLS Data Plane Failures (RFC 4379) to be deployed in networks running earlier versions
of the draft.
MPLS Embedded Management Configuration

Before using the ping mpls, trace mpls, or trace mpls multipath command, you should consider
ensuring that the router is configured to encode and decode MPLS echo packets in a format that all
receiving routers in the network can understand.
LSP ping drafts after Version 3 (draft-ietf-mpls-ping-03) have undergone numerous TLV format
changes, but the implementations based on different drafts might not interoperate properly.
To allow later Cisco implementations to interoperate with draft Version 3 Cisco and non-Cisco
implementations, a global configuration mode (MPLS OAM configuration) allows you to encode and
decode echo packets in formats specified by draft Version 3 implementations.
Unless configured otherwise, a Cisco implementation encodes and decodes echo requests assuming the
version on which the Internet Engineering Task Force (IETF) implementation is based.
To allow for seamless interoperability with earlier Revision 1 and 3 images, you can use MPLS
Operation, Administration, and Maintenance (OAM) configuration mode parameters to force the default
behavior of the Revision 4 images to be compliant or compatible in networks with Revision 1 or Revision
3 images.
To prevent failures reported by the replying router due to TLV version issues, you should configure all
routers in the core. Encode and decode MPLS echo packets in the same draft version. For example, if
the network is running RFC 4379 (Cisco Revision 4) implementations but one router is capable of only
Version 3 (Cisco Revision 3), configure all routers in the network to operate in Revision 3 mode.
Cisco Revision 4 is the default version. The default version is the latest LSP Ping version supported by
the image on the router.
5
Prerequisites
MPLS LSP Multipath Tree Trace requires RFC 4379 (Revision 4).
SUMMARY STEPS
1. enable
3. mpls oam
4. echo revision {3 | 4}
5. [no] echo vendor-extension
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls oam Enters MPLS OAM configuration mode and customizes the
default behavior of echo packets.
Example:
Step 4 echo revision {3 | 4} Customizes the default behavior of echo packets.
• The revision keyword set echo packet attributes to one
Example: of the following:
– 3 = draft-ietf-mpls-ping-03 (Revision 2)
– 4 = RFC 4379 compliant (default)
Note The MPLS LSP Multipath Tree Trace feature
requires Revision 4.
6

Step 5 [no] echo vendor-extension Customizes the default behavior of echo packets.
• The vendor-extension keyword sends the
Example: Cisco-specific extension of TLVs with the echo
Router(config-mpls)# echo vendor-extension packets.
• The no form of the command allows you to disable a
Cisco vendor’s extension TLVs that another vendor’s
noncompliant implementations may not support.
The router default is echo vendor-extension.
Example:
Router(config-mpls)# end
Configuring MPLS LSP Multipath Tree Trace

Perform the following task to configure MPLS multipath LSP traceroute. This task helps discover all
LSPs from an egress router to an ingress router.
Prerequisites
Cisco LSP ping or traceroute implementations based on draft-ietf-mpls-lsp-ping-11 are capable in some
cases of detecting the formatting of the sender of an MPLS echo request. However, certain cases exist in
which an echo request or echo reply might not contain the Cisco extension TLV. To avoid complications
due to certain cases where the echo packets are decoded assuming the wrong TLV formats, configure all
routers in the network to operate in the same mode.
For an MPLS LSP multipath tree trace to be successful, the implementation in your routers must support
RFC 4379 on all core routers.
If all routers in the network support RFC-4379 and another vendor’s implementation exists that is not
capable of properly handling Cisco’s vendor TLV, the routers supporting the RFC-compliant or later
configuration must include commands to disable the Cisco vendor TLV extensions.
SUMMARY STEPS
1. enable
3. mpls oam
4. echo revision 4
5. [no] echo vendor-extension
6. end
7. trace mpls multipath ipv4 destination-ip-address/destination-mask-length
8. debug mpls lspv multipath
7
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls oam Enters MPLS OAM configuration mode.
Example:
Step 4 echo revision 4 Customizes the default behavior of echo packets.
• The revision 4 keywords set echo packet attributes to
Example: the default Revision 4 (RFC 4379 compliant).
Step 5 [no] echo vendor-extension (Optional) Customizes the default behavior of echo packets.
• The vendor-extension keyword sends the
Example: Cisco-specific extension of TLVs with the echo
Router(config-mpls) echo vendor-extension packets.
• The no form of the command allows you to disable a
Cisco vendor’s extension TLVs that another vendor’s
noncompliant implementations may not support.
The router default is echo vendor-extension.
Example:
Step 7 trace mpls multipath ipv4 Discovers all LSPs from an egress router to an ingress
destination-ip-address/destination-mask-length router.
• The ipv4 keyword specifies the destination type as an
Example: LDP IPv4 address.
Router# trace mpls multipath ipv4
10.131.161.251/32 • The destination-ip-address argument is the address
prefix of the target to be tested.
• The destination-mask-length argument is the number of
bits in the network mask of the target address. The
/ keyword before this argument is required.
Step 8 debug mpls lspv multipath Displays multipath information related to the MPLS LSP
Multipath Tree Trace feature.
Example:
Router# debug mpls lspv multipath
8
Discovering IPv4 Load Balancing Paths Using MPLS LSP Multipath Tree Trace
Perform the following task to discover IPv4 load balancing paths using MPLS LSP multipath tree trace.
MPLS Multipath LSP Traceroute Path Discovery

A Cisco router load balances MPLS packets based on the incoming label stack and the source and
destination addresses in the IP header. The outgoing label stack and IP header source address remain
constant for each path being traced. The router needs to find the set of IP header destination addresses
to use all possible output paths. This might require exhaustive searching of the 127.x.y.z/8 address space.
Once you discover all paths from the source LSR to the target or destination LSR with MPLS LSP
multipath tree trace, you can use MPLS LSP traceroute to monitor these paths.
Figure 1 shows how MPLS LSP multipath tree trace discovers LSP paths in a sample network. In
Figure 1, the bitmap size is 16 and the numbers 0 to 15 represent the bitmapped addresses that MPLS
LSP multipath tree trace uses to discover all the paths from the source LSR R-101 to the target LSR
R-150. Figure 1 illustrates how the trace mpls multipath command discovers all LSP paths in the
sample network.
Figure 1 MPLS LSP Multipath Tree Trace Path Discovery in a Sample Network
Address: 1, 2,
R-120 4, 15 R-131 Address: 1, 4 R-141 Address: 4
Address: 1, 2, 3, 4,
5, 7, 13, 15
Address: 2, 15
Target R-150
Address: 3, 5, 7, 13 R-130 R-140
Address: 15
R-111
Source Address 7, 13 Address 7
Source R-101
R-101
Address: 14
Address: 0, 6, 8, 9, Address: 6, 9, 14
10, 11, 12, 14
170601
R-121 Address: 6, 9, R-132
12, 14
SUMMARY STEPS
1. enable
3. mpls oam
4. echo revision 4
5. end
6. trace mpls multipath ipv4 destination-ip-address/destination-mask-length hashkey ipv4 bitmap
bitmap-size
9
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls oam Enters MPLS OAM configuration mode and sets the echo
packet attribute to Revision 4 (RFC 4379 compliant).
Example:
Step 4 echo revision 4 Customizes the default behavior of echo packets.
• The revision 4 keywords set echo packet attributes to
Example: the default Revision 4 (RFC 4379 compliant).
Example:
Step 6 trace mpls multipath ipv4 destination-address/ Discovers all MPLS LSPs from an egress router to an
destination-mask-length hashkey ipv4 bitmap ingress router.
bitmap-size
LDP IPv4 address.
Example:
Router# trace mpls multipath ipv4 • The destination-address argument is the address prefix
10.131.161.251/32 hashkey ipv4 bitmap 16 of the target to be tested.
• The hashkey ipv4 keywords set the hashkey type to
IPv4 addresses.
• The bitmap bitmap-size keyword and arguments set the
bitmap size for multipath discovery.
Monitoring LSP Paths Discovered by MPLS LSP Multipath Tree Trace Using
MPLS LSP Traceroute
Perform the following task to monitor LSP paths discovered by MPLS LSP multipath tree trace using
MPLS LSP traceroute. You can take output directly from the trace mpls multipath command and add
it to a trace mpls command periodically to verify that the path is still operating.
10
Figure 2 shows the mapping of the output of a trace mpls multipath command to a trace mpls
command.
Figure 2 Mapping of trace mpls multipath Command Output to a trace mpls Command
output interface Et0/0 source 10.1.111.101 destination 127.0.0.7
Router# trace mpls ipv4 10.1.1.1.150/32 output interface Et0/0 source 10.1.111.101 destination 127.0.0.7
trace mpls {ipv4 destination -add res s/destina tion-mask [destinatio n ad dres s-start [ad dres s-end]
[address-incremen t]] |traffic-eng tu nnel-interface tu nnel-number} [revis ion {1 | 2 | 3 | 4}]
[so urce source-ad dress] [timeout seconds] [reply dscp dscp-va lu e] [reply pad-tlv]
[reply mode reply-mo de] [ttl ma ximum-time-to-live] [exp exp-bits] [revision
170602
tlv-revision -nu mber] [force-ex plicit-null] [output interface tx-interface] [fla gs fec]
Each path you discover with MPLS LSP Multipath Tree Trace can be tested in this manner periodically
to monitor the LSP paths in your network.
SUMMARY STEPS
1. enable
2. trace mpls multipath ipv4 destination-address/destination-mask-length hashkey ipv4 bitmap
bitmap-size
3. trace mpls ipv4 destination-address/destination-mask-length [output interface tx-interface]
[source source-address] [destination address-start]
4. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 trace mpls multipath ipv4 destination-address/destination-mask-length hashkey ipv4 bitmap

bitmap-size
Use this command to discover all MPLS LSPs from an egress router to an ingress router. For example:
Starting LSP Multipath Traceroute for 10.1.1.150/32

11


LLLL!
Path 0 found,
output interface Fe0/0/0 source 10.1.111.101 destination 127.0.0.0
LLL!
Path 1 found,
L!
Path 2 found,
LL!
Path 3 found,
Paths (found/broken/unexplored) (4/0/0)

Echo Request (sent/fail) (14/0)
Echo Reply (received/timeout) (14/0)
Total Time Elapsed 468 ms
The output of the trace mpls multipath command in the example shows the result of path discovery
with MPLS LSP multipath tree trace. In this example, the command sets the bitmap size to 16. Path
discovery starts by MPLS LSP multipath tree trace using 16 bitmapped addresses as it locates LSP paths
from the source router to the target router with prefix and mask 10.1.1.150/32. MPLS LSP multipath tree
trace starts using the 127.x.y.z/8 address space with 127.0.0.1.
Step 3 trace mpls ipv4 destination-address/destination-mask-length [output interface tx-interface] [source

source-address] [destination address-start]
Use this command to verify that the paths discovered when you entered a trace mpls multipath
command are still operating. For example, the output for Path 0 in the previous trace mpls multipath
command in Step 2 is:
If you put the output for path 0 in the trace mpls command, you see the following results:
Router# trace mpls ipv4 10.1.1.150/32 output interface Fe0/0/0 source 10.1.111.101
destination 127.0.0.0


0 10.1.111.101 MRU 1500 [Labels: 33 Exp: 0]
! 5 10.5.150.50 20 ms
You can take output directly from the trace mpls multipath command and add it to a trace mpls
command periodically to verify that the path is still operating (see Figure 2).
12
Step 4 exit
Use this command to exit to user EXEC mode. for example:
Router# exit
Router>
Using DSCP to Request a Specific Class of Service in an Echo Reply

A reply differentiated services code point (DSCP) option lets you request a specific class of service
(CoS) in an echo reply.
The reply DSCP option is supported in the experimental mode for IETF draft-ietf-mpls-lsp-ping-03.txt.
Cisco implemented a vendor-specific extension for the reply DSCP option rather than using a Reply TOS
TLV. A Reply TOS TLV serves the same purpose as the reply dscp command in IETF
draft-ietf-mpls-lsp-ping-11.txt. This draft provides a standardized method of controlling the reply DSCP.
Note Before RFC 4379, Cisco implemented the Reply DSCP option as an experimental capability using a
Cisco vendor extension TLV. If a router is configured to encode MPLS echo packets for draft Version 3
implementations, a Cisco vendor extension TLV is used instead of the = Reply TOS TLV that was
defined in draft Version 8.
To use DSCP to request a specific CoS in an echo reply, perform the following steps.
SUMMARY STEPS
1. enable
2. trace mpls multipath ipv4 destination-address/destination-mask-length [reply dscp dscp-value]
3. exit
13
DETAILED STEPS

Example:
Router> enable
Step 2 trace mpls multipath ipv4 destination-address/ Discovers all MPLS LSPs from an ingress router to an
destination-mask-length [reply dscp dscp-value] egress router and controls the DSCP value of an echo reply.
10.131.191.252/32 reply dscp 50 • The destination-address argument is the address prefix
of the target to be tested.
• The reply dscp dscp-value keywords and argument are
the DSCP value of an echo reply. A Reply TOS TLV
serves the same purpose as the reply dscp command in
IETF draft-ietf-mpls-lsp-ping-11.txt.
Note To specify a DSCP value, you must enter the reply
dscp dscp-value keywords and argument.
Example:
Router# exit
Controlling How a Responding Router Replies to an MPLS Echo Request

This section contains information about and instructions for controlling how a responding router replies
to an MPLS echo request. You should understand the following information before you configure a reply
mode for the echo request response:
• Reply Modes for an MPLS LSP Multipath Tree Trace Echo Request Response, page 14
Reply Modes for an MPLS LSP Multipath Tree Trace Echo Request Response
The reply mode controls how a responding router replies to an MPLS echo request sent by a trace mpls
multipath command. There are two reply modes for an echo request packet:
• ipv4—Reply with an IPv4 User Datagram Protocol (UDP) packet (default)
• router-alert—Reply with an IPv4 UDP packet with router alert
Note Use the ipv4 and router-alert reply modes with each other to prevent false negatives. If you do not receive
a reply via the ipv4 mode, send a test with the router-alert reply mode. If both fail, something is wrong
in the return path. The problem might be due to an incorrect ToS setting.
14
IPv4 UDP Reply Mode
The IPv4 UDP reply mode is the most common reply mode used with a trace mpls multipath command
when you want to periodically poll the integrity of an LSP. With this option, you do not have explicit
control over whether the packet traverses IP or MPLS hops to reach the originator of the MPLS echo
request. If the originating (headend) router fails to receive a reply to an MPLS echo request when you
use the reply mode ipv4 keywords, use the reply mode router-alert keywords.
Router-alert Reply Mode
The router-alert reply mode adds the router alert option to the IP header. When an IP packet that contains
an IP router alert option in its IP header or an MPLS packet with a router alert label as its outermost label
arrives at a router, the router punts (redirects) the packet to the Route Processor (RP) process level for
handling. This forces the RP of each intermediate router to specifically handle the packet at each
intermediate hop as it moves back to the destination. Hardware and line-card forwarding inconsistencies
are thus bypassed. Router-alert reply mode is slower than IPv4 mode because the reply requires
process-level RP handling at each hop.
Table 2 describes how an incoming IP packet with an IP router alert is handled by the router switching
path processes when the outgoing packet is an IP packet or an MPLS packet. It also describes how an
MPLS packet with a router alert option is handled by the router switching path processes when the
outgoing packet is an IP packet or an MPLS packet.
Table 2 Path Process Handling of IP and MPLS Router Alert Packets
Incoming Packet Outgoing Packet Normal Switching Action Process Switching Action
IP packet—Router alert IP packet—Router alert Router alert option in IP header Forwards the packet as is
option in IP header option in IP header causes the packet to be punted to
the process switching path.
MPLS packet Forwards the packet as is
MPLS packet— IP packet—Router alert If the router alert label is the Removes the outermost router
Outermost label contains option in IP header outermost label, it causes the alert label and forwards the
a router alert packet to be punted to the process packet as an IP packet
switching path.
MPLS packet— Preserves the outermost router
Outermost label contains alert label and forwards the
a router alert MPLS packet
SUMMARY STEPS
1. enable
2. trace mpls multipath ipv4 destination-address/destination-mask-length reply mode {ipv4 |
router-alert}
3. exit
15
DETAILED STEPS

Example:
Router> enable
destination-mask-length reply mode {ipv4 | egress router and specifies the reply mode.
router-alert}
LDP IPv4 address.
Example:
10.131.191.252/32 reply mode router-alert of the target to be tested.
• The reply mode keyword requires that you enter one of
the following keywords to specify the reply mode:
– The ipv4 keyword—Reply with an IPv4 UDP
packet (default).
– The router-alert keyword—Reply with an IPv4
UDP packet with router alert.
Note To specify the reply mode, you must enter the reply
mode keyword with the ipv4 or router-alert
keyword.
Example:
Router# exit
Specifying the Output Interface for Echo Packets Leaving a Router for MPLS
LSP Multipath Tree Trace
Perform the following task to specify the output interface for echo packets leaving a router for the MPLS
LSP Multipath Tree Trace feature. You can use this task to test the LSPs reachable through a given
interface.
Echo Request Output Interface Control

You can control the interface through which packets leave a router. Path output information is used as
input to LSP ping and traceroute.
The echo request output interface control feature allows you to force echo packets through the paths that
perform detailed debugging or characterizing of the LSP. This feature is useful if a PE router connects
to an MPLS cloud and there are broken links. You can direct traffic through a certain link. The feature
also is helpful for troubleshooting network problems.
16
SUMMARY STEPS
1. enable
2. trace mpls multipath ipv4 destination-address/destination-mask-length [output interface
tx-interface]
3. exit
DETAILED STEPS

Example:
Router> enable
destination-mask-length [output interface egress router and specifies the interface through which echo
tx-interface]
packets leave a router.
10.131.159.251/32 output interface • The destination-address argument is the address prefix
fastethernet0/0/0 of the target to be tested.
• The output interface tx-interface keywords and
argument specify the output interface for the MPLS
echo request.
Note You must specify the output interface keywords.
Example:
Router# exit
Setting the Pace of MPLS Echo Request Packet Transmission for MPLS LSP
Multipath Tree Trace
Perform the following task to set the pace of MPLS echo request packet transmission for the MPLS LSP
Multipath Tree Trace feature. Echo request traffic pacing allows you to set the pace of the transmission
of packets so that the receiving router does not drop packets. If you have a large amount of traffic on
your network you might increase the size of the interval to help ensure that the receiving router does not
drop packets.
SUMMARY STEPS
1. enable
2. trace mpls multipath ipv4 destination-address/destination-mask-length [interval milliseconds]
17
3. exit
DETAILED STEPS

Example:
Router> enable
destination-mask-length [interval milliseconds] ingress router and sets the time in milliseconds between
successive MPLS echo requests.
Example: • The ipv4 keyword specifies the destination type as an
Router# trace mpls multipath ipv4 LDP IPv4 address.
10.131.159.251/32 interval 100
• The destination-address argument is the address prefix
• The destination-mask argument is the number of bits in
the network mask of the target address. The / keyword
before this argument is required.
• The interval milliseconds keyword and argument set
the time between successive MPLS echo requests in
milliseconds. The default is 0 milliseconds.
Note To pace the transmission of packets, you must
specify the interval keyword.
Example:
Router# exit
Enabling MPLS LSP Multipath Tree Trace to Detect LSP Breakages Caused by
an Interface That Lacks an MPLS Configuration
Perform the following task to enable MPLS LSP multipath tree trace to detect LSP breakages caused by
an interface that lacks an MPLS configuration. If an interface is not configured for MPLS, then it cannot
forward MPLS packets.
Explicit Null Label Shimming Tests LSP Ability to Carry MPLS Traffic
For an MPLS LSP multipath tree trace of LSPs carrying IPv4 FECs, you can force an explicit null label
to be added to the MPLS label stack even though the label was unsolicited. This allows MPLS LSP
multipath tree trace to detect LSP breakages caused by an interface that is not configured for MPLS.
MPLS LSP multipath tree trace does not report that an LSP is functioning when it is unable to send
MPLS traffic.
An explicit null label is added to an MPLS label stack if MPLS echo request packets are forwarded from
an interface not configured for MPLS that is directly connected to the destination of the MPLS LSP
multipath tree trace or if the IP TTL value for the MPLS echo request packets is set to 1.
18
When you enter a trace mpls multipath command, you are looking for all MPLS LSP paths from an
egress router to an ingress router. Failure at output interfaces that are not configured for MPLS at the
penultimate hop are not detected. Explicit-null shimming allows you to test an LSP’s ability to carry
MPLS traffic.
SUMMARY STEPS
1. enable
2. trace mpls multipath ipv4 destination-address/destination-mask-length force-explicit-null
3. exit
DETAILED STEP

Example:
Router> enable
destination-mask-length force-explicit-null ingress router and forces an explicit null label to be added
to the MPLS label stack.
Example: • The ipv4 keyword specifies the destination type as an
Router# trace mpls multipath ipv4 LDP IPv4 address.
10.131.191.252/32 force-explicit-null
• The destination-address argument is the address prefix
• The force-explicit-null keyword forces an explicit null
label to be added to the MPLS label stack even though
the label was unsolicited.
Note You must enter the force-explicit-null keyword to
enable MPLS LSP multipath tree trace to detect
LSP breakages caused by an interface that is not
configured for MPLS.
Example:
Router# exit
Requesting That a Transit Router Validate the Target FEC Stack for MPLS LSP
Multipath Tree Trace
Perform the following task to request that a transit router validate the target FEC stack for the MPLS
LSP Multipath Tree Trace feature.
An MPLS echo request tests a particular LSP. The LSP to be tested is identified by the FEC stack.
19
During an MPLS LSP multipath tree trace, the echo packet validation rules do not require that a transit
router validate the target FEC stack TLV. A downstream map TLV containing the correct received labels
must be present in the echo request for target FEC stack checking to be performed.
To request that a transit router validate the target FEC stack, set the V flag from the source router by
entering the flags fec keywords in the trace mpls multipath command. The default is that echo request
packets are sent with the V flag set to 0.
SUMMARY STEPS
1. enable
2. trace mpls multipath ipv4 destination-address/destination-mask-length [flags fec] [ttl
3. exit
DETAILED STEPS

Example:
Router> enable
destination-mask-length [flags fec] [ttl ingress router and requests validation of the target FEC
stack by a transit router.
10.131.159.252/32 flags fec ttl 5 • The destination-address argument is the address prefix
• The flags fec keywords requests that target FEC stack
validation be done at a transit router.
• The ttl maximum-time-to-live keyword and argument
pair specify a maximum hop count.
Note For a transit router to validate the target FEC stack,
you must enter the flags fec and ttl keywords.
Example:
Router# exit
20
Setting the Number of Timeout Attempts for MPLS LSP Multipath Tree Trace
Perform the following task to set the number of timeout attempts for the MPLS LSP Multipath Tree
Trace feature.
A retry is attempted if an outstanding echo request times out waiting for the corresponding echo reply.
SUMMARY STEPS
1. enable
2. trace mpls multipath ipv4 destination-address/destination-mask-length [retry-count
retry-count-value]
3. exit
DETAILED STEPS

Example:
Router> enable
Step 2 trace mpls multipath ipv4 destination-address/ Sets the number of retry attempts during an MPLS LSP
destination-mask-length [retry-count multipath tree trace.
retry-count-value]
LDP IPv4 address.
Example:
10.131.159.252/32 retry-count 4 of the target to be tested.
• The retry-count retry-count-value keyword and
argument sets the number of retry attempts after a
timeout occurs.
A retry-count value of “0” means infinite retries. A
retry-count value from 0 to10 is suggested. You might
want to increase the retry value to greater than 10, if 10
is too small a value. The default retry-count value is 3.
Note To set the number of retries after a timeout, you
must enter the retry-count keyword.
Example:
Router# exit
21
Configuration Examples for MPLS EM—MPLS LSP Multipath Tree Trace
Configuration Examples for MPLS EM—MPLS LSP Multipath

Tree Trace
This section includes the following configuration examples for the MPLS EM—MPLS LSP Multipath
Tree Trace feature:
• Customizing the Default Behavior of MPLS Echo Packets: Example, page 22
• Configuring MPLS LSP Multipath Tree Trace: Example, page 22
• Using DSCP to Request a Specific Class of Service in an Echo Reply: Example, page 24
• Controlling How a Responding Router Replies to an MPLS Echo Request: Example, page 25
• Specifying the Output Interface for Echo Packets Leaving a Router for MPLS LSP Multipath Tree
Trace: Example, page 25
• Setting the Pace of MPLS Echo Request Packet Transmission for MPLS LSP Multipath Tree Trace:
Example, page 26
• Enabling MPLS LSP Multipath Tree Trace to Detect LSP Breakages Caused by an Interface That
Lacks an MPLS Configuration: Example, page 27
• Requesting That a Transit Router Validate the Target FEC Stack for MPLS LSP Multipath Tree
Trace: Example, page 29
• Setting the Number of Timeout Attempts for MPLS LSP Multipath Tree Trace: Example, page 29
Customizing the Default Behavior of MPLS Echo Packets: Example

The following example shows how to customize the behavior of MPLS echo packets so that the MPLS
LSP Multipath Tree Trace feature interoperates with a vendor implementation that does not interpret
RFC 4379 as Cisco does:
configure terminal
!
mpls oam
echo revision 4
end
The echo revision command is included in this example for completeness. The default echo revision
number is 4, which corresponds to RFC 4379.
Configuring MPLS LSP Multipath Tree Trace: Example

The following example shows how to configure the MPLS LSP Multipath Tree Trace feature to
interoperate with a vendor implementation that does not interpret RFC 4379 as Cisco does:
configure terminal
!
mpls oam
echo revision 4
end
!
trace mpls multipath ipv4 10.131.161.151/32
22
The echo revision command is included in this example for completeness. The default echo revision
number is 4, which corresponds to the RFC 4379.
Discovering IPv4 Load Balancing Paths Using MPLS LSP Multipath Tree Trace:
Example
The following example shows how to use the MPLS LSP Multipath Tree Trace feature to discover IPv4
load balancing paths. The example is based on the sample network shown in Figure 3. In this example,
the bitmap size is set to 16. Therefore, path discovery starts by the MPLS LSP Multipath Tree Trace
feature using 16 bitmapped addresses as it locates LSP paths from the source router R-101 to the target
router R-150 with prefix and mask 10.1.1.150/32. The MPLS LSP Multipath Tree Trace feature starts
using the 127.x.y.z/8 address space with 127.0.0.0.


LLLL!
Path 0 found,
LLL!
Path 1 found,
L!
Path 2 found,
LL!
Path 3 found,

The output of the trace mpls multipath command in the example shows the result of path discovery
with the MPLS LSP Multipath Tree Trace feature as shown in Figure 3.
23
Figure 3 MPLS LSP Multipath Tree Trace Path Discovery in a Sample Network
Address: 1, 2,
R-120 5, 15 R-131 Address: 2, 5
R-141 Address: 5
Address: 1, 2, 3, 4,
5, 7, 13, 15
Address: 1, 15
Target R-150
Address: 3, 5, 7, 13 R-130 R-140
Address: 1
R-111
Source Address 7, 13 Address 7
Source R-101
R-101
Address: 0
Address: 0, 6, 8, 9, Address: 6, 9, 14
10, 11, 12, 14
170603
R-121 Address: 6, 9, R-132
12, 14
Using DSCP to Request a Specific Class of Service in an Echo Reply: Example

The following example shows how to use DSCP to request a specific CoS in an echo reply:
Router# trace mpls multipath ipv4 10.1.1.150/32 reply dscp 50


LLLL!
Path 0 found,
LLL!
Path 1 found,
L!
Path 2 found,
LL!
Path 3 found,

24
Controlling How a Responding Router Replies to an MPLS Echo Request:

Example
The following example shows how to control how a responding router replies to an MPLS echo request:
Router# trace mpls multipath ipv4 10.1.1.150/32 reply mode router-alert


LLLL!
Path 0 found,
LLL!
Path 1 found,
L!
Path 2 found,
LL!
Path 3 found,

Echo Reply (received/timeout) (14/0
Specifying the Output Interface for Echo Packets Leaving a Router for MPLS
LSP Multipath Tree Trace: Example
The following example shows how to specify the output interface for echo packets leaving a router for
the MPLS LSP Multipath Tree Trace feature:
Router# trace mpls multipath ipv4 10.1.1.150/32 output interface fastethernet0/0/0


0 10.1.111.101 MRU 1500 [Labels: 33 Exp: 0]
L
1 10.1.111.111 MRU 1500 [Labels: 33 Exp: 0] 40 ms
L
25
2 10.2.120.120 MRU 1500 [Labels: 33 Exp: 0] 20 ms

L
3 10.3.131.131 MRU 1500 [Labels: 34 Exp: 0] 20 ms
L
4 10.4.141.141 MRU 1504 [Labels: implicit-null Exp: 0] 20 ms !
5 10.5.150.150 16 ms
Setting the Pace of MPLS Echo Request Packet Transmission for MPLS LSP
Multipath Tree Trace: Example
The following examples show how set the pace of MPLS echo request packet transmission for the MPLS
LSP Multipath Tree Trace feature. The time between successive MPLS echo requests is set to
300 milliseconds in the first example and 400 milliseconds in the second example:
Router# trace mpls multipath ipv4 10.131.159.252/32 interval 300


LL!
Path 0 found,

Router# trace mpls multipath ipv4 10.131.159.252/32 interval 400


LL!
Path 0 found,

Notice that the elapsed time increases as you increase the interval size.
26
Enabling MPLS LSP Multipath Tree Trace to Detect LSP Breakages Caused by
an Interface That Lacks an MPLS Configuration: Example
The following examples shows how to enable the MPLS LSP Multipath Tree Trace feature to detect LSP
breakages caused by an interface that lacks an MPLS configuration:
Router# trace mpls multipath ipv4 10.1.1.150/32 force-explicit-null


LLLL!
Path 0 found,
LLL!
Path 1 found,
L!
Path 2 found,
LL!
Path 3 found,

This example shows the additional information provided when you add the verbose keyword to the
command:
Router# trace mpls multipath ipv4 10.1.1.150/32 force-explicit-null verbose


LLLL!
Path 0 found,
0 10.1.111.101 10.1.111.111 MRU 1500 [Labels: 33/explicit-null Exp: 0/0] multipaths 0
L
1 10.1.111.111 10.2.121.121 MRU 1500 [Labels: 34/explicit-null Exp: 0/0] ret code 8
multipaths 2
L
27
multipaths 1
L
multipaths 1
L
4 10.4.140.240 10.5.150.50 MRU 1504 [Labels: explicit-null Exp: 0] ret code 8 multipaths
1 !
5 10.5.150.50, ret code 3 multipaths 0
LLL!
Path 1 found,
L
multipaths 2
L
multipaths 2
L
multipaths 2
L
4 10.4.141.141 10.5.150.150 MRU 1504 [Labels: explicit-null Exp: 0] ret code 8
multipaths 1
!
L!
Path 2 found,
L
multipaths 2
L
multipaths 2
L
multipaths 2
L
1 ! 5 10.5.150.50, ret code 3 multipaths 0
LL!
Path 3 found,
L
multipaths 2
L
multipaths 2
L
multipaths 1
L
1
!

28

Requesting That a Transit Router Validate the Target FEC Stack for MPLS LSP
Multipath Tree Trace: Example
The following example shows how to request that a transit router validate the target FEC stack for the
MPLS LSP Multipath Tree Trace feature:
Router# trace mpls multipath ipv4 10.1.1.150/32 flags fec ttl 5


LLLL!
Path 0 found,
LLL!
Path 1 found,
L!
Path 2 found,
LL!
Path 3 found,

Target FEC stack validation is always done at the egress router when the flags fec keywords are specified
in the trace mpls multipath command.
Setting the Number of Timeout Attempts for MPLS LSP Multipath Tree Trace:
Example
The following example sets the number of timeout attempts for the MPLS LSP Multipath Tree Trace
feature to four:
Router# trace mpls multipath ipv4 10.1.1.150/32 retry-count 4

29


LLLL!
Path 0 found,
LLL!
Path 1 found,
L!
Path 2 found,
LL!
Path 3 found,

The following output shows a trace mpls multipath command that found one unexplored path, one
successful path, and one broken path:
Router# trace mpls multipath ipv4 10.1.1.150/32 retry-count 4


LLL....
Path 0 Unexplorable,
LLL!
Path 1 found,
output interface Fe0/0/0 source 10.1.111.101 destination 127.0.0.1 B
Path 2 Broken,

30
The following sections provide references related to the MPLS EM—MPLS LSP Multipath Tree Trace
feature.
Related Documents
Concepts and configuration tasks for MPLS LSP ping MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
or traceroute
Concepts and configuration for MPLS and other MPLS Cisco IOS XE Multiprotocol Label Switching Configuration Guide,
applications Release 2
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 2113 IP Router Alert Option
RFC 3443 Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS)
Networks
RFC 4377 Operations and Management (OAM) Requirements for Multi-Protocol Label
Switched (MPLS) Networks
RFC 4378 A Framework for Multi-Protocol Label Switching (MPLS) Operations and
Management (OAM)
RFC 4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures
31
Related Documents
Description Link
32
Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace
Feature Information for MPLS EM—MPLS LSP Multipath Tree

Trace
Table 3 Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace

MPLS EM—MPLS LSP Multipath Tree Cisco IOS XE The MPLS EM—MPLS LSP Multipath Tree Trace feature
Trace Release 2.3 provides the means to discover all the possible paths of a
label switched path (LSP) between an egress and ingress
router. Once discovered, these paths can be retested on a
periodic basis using Multiprotocol Label Switching
(MPLS) LSP ping or traceroute. This feature is an extension
to the MPLS LSP traceroute functionality for the tracing of
IPv4 LSPs.
Cisco IOS XE MPLS Embedded Management (EM) is a set
of standards and value-added services that facilitate the
deployment, operation, administration, and management of
MPLS-based networks in line with the fault, configuration,
accounting, performance, and security (FCAPS) model.
feature:
• Overview of MPLS LSP Multipath Tree Trace, page 3
• Discovery of IPv4 Load Balancing Paths by MPLS LSP
Multipath Tree Trace, page 3
• Echo Reply Return Codes Sent by the Router
Processing Multipath LSP Tree Trace,
page 4Customizing the Default Behavior of MPLS
Echo Packets, page 5
• Configuring MPLS LSP Multipath Tree Trace, page 7
• Discovering IPv4 Load Balancing Paths Using MPLS
LSP Multipath Tree Trace, page 9Monitoring LSP
Paths Discovered by MPLS LSP Multipath Tree Trace
Using MPLS LSP Traceroute, page 10
33
Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace
Table 3 Feature Information for MPLS EM—MPLS LSP Multipath Tree Trace (continued)

• Using DSCP to Request a Specific Class of Service in
an Echo Reply, page 13
• Controlling How a Responding Router Replies to an
MPLS Echo Request, page 14
• Specifying the Output Interface for Echo Packets
Leaving a Router for MPLS LSP Multipath Tree Trace,
page 16
• Setting the Pace of MPLS Echo Request Packet
Transmission for MPLS LSP Multipath Tree Trace,
page 17
• Enabling MPLS LSP Multipath Tree Trace to Detect
LSP Breakages Caused by an Interface That Lacks an
MPLS Configuration, page 18
• Requesting That a Transit Router Validate the Target
FEC Stack for MPLS LSP Multipath Tree Trace,
page 19
• Setting the Number of Timeout Attempts for MPLS
LSP Multipath Tree Trace, page 21
debug mpls lspv, echo, mpls oam, trace mpls, trace mpls
multipath.
34
Glossary
Glossary
ECMP—equal-cost multipath. Multiple routing paths of equal cost that may be used for packet
forwarding.
FEC—Forwarding Equivalence Class. A set of packets that can be handled equivalently for forwarding
purposes and are thus suitable for binding to a single label. Examples include the set of packets destined
for one address prefix and the packets in any flow.
flow—A set of packets traveling between a pair of hosts, or between a pair of transport protocol ports
on a pair of hosts. For example, packets with the same source address, source port, destination address,
and destination port might be considered a flow.
A flow is also a stream of data traveling between two endpoints across a network (for example, from one
LAN station to another). Multiple flows can be transmitted on a single circuit.
localhost—A name that represents the host router (device). The localhost uses the reserved loopback IP
address 127.0.0.1.
LSP—label switched path. A connection between two routers in which Multiprotocol Label Switching
(MPLS) forwards the packets.
LSPV—Label Switched Path Verification. An LSP ping subprocess. It encodes and decodes
Multiprotocol Label Switching (MPLS) echo requests and replies, and it interfaces with IP, MPLS, and
AToM switching for sending and receiving MPLS echo requests and replies. At the MPLS echo request
originator router, LSPV maintains a database of outstanding echo requests for which echo responses
have not been received.
MPLS router alert label—An Multiprotocol Label Switching (MPLS) label of 1. An MPLS packet with
a router alert label is redirected by the router to the Route Processor (PR) processing level for handling.
This allows these packets to bypass any forwarding failures in hardware routing tables.
OAM—Operation, Administration, and Management.
punt—Redirect packets with a router alert from the line card or interface to Route Processor (RP) level
processing for handling.
RP—Route Processor. The processor module contains the CPU, system software, and most of the
memory components that are used in the router.
TTL—time-to-live. A parameter you can set that indicates the maximum number of hops a packet should
take to reach its destination.
TLV—type, length, values. A block of information included in a Cisco Discovery Protocol address.
UDP—User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack.
UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery,
so error processing and retransmission must be handled by other protocols. UDP is defined in RFC 768.
XDR—eXternal Data Representation. Standard for machine-independent data structures developed by
Sun Microsystems. Used to transport messages between the Route Processor (RP) and the line card.
35
Glossary
countries.
36
MPLS Label Distribution Protocol MIB

This document describes the Simple Network Management Protocol (SNMP) agent support provided in
Cisco IOS XE software for the MPLS Label Distribution Protocol Management Information Base
(MPLS LDP MIB).

which each feature is supported, see the “Feature Information for MPLS Label Distribution MIB” section on
page 16.
Contents
• Restrictions for MPLS LDP MIB, page 2
• Information About MPLS LDP MIB, page 2
• How to Configure MPLS LDP MIB, page 8
• Configuration Examples for MPLS LDP MIB, page 13
• Feature Information for MPLS Label Distribution MIB, page 16
Restrictions for MPLS LDP MIB
Restrictions for MPLS LDP MIB

The MPLS LDP MIB is limited to read-only (RO) permission for MIB objects, except for MIB object
mplsLdpSessionUpDownTrapEnable, which is writable by the SNMP agent.
Setting this object to a value of true enables both the mplsLdpSessionUp and mplsLdpSessionDown
notifications on the Label Switched Router (LSR); conversely, setting this object to a value of false
disables both of these notifications. The value of the mplsLdpSessionUpDownTrapEnable object is
stored in NVRAM on the MPLS LDP MIB host.
For a description of notification events, see the “Events Generating MPLS LDP MIB Notifications”
section on page 6.
Most MPLS LDP MIB objects are set up automatically during the LDP peer discovery (Hello) process
and the subsequent negotiation of parameters and establishment of LDP sessions between the LDP peers.
Information About MPLS LDP MIB

Before enabling the MPLS LDP MIB, you should understand the following concepts:
• MPLS LDP Overview, page 2
• MPLS LDP MIB Overview, page 3
• Benefits of Using MPLS LDP MIB, page 4
• Description of MPLS LDP MIB Elements, page 4
• MPLS LDP MIB Object Categories, page 6
• Events Generating MPLS LDP MIB Notifications, page 6
MPLS LDP Overview

Multiprotocol Label Switching (MPLS) is a packet forwarding technology that uses a short, fixed-length
value called a label in packets to determine the next hop for packet transport through an MPLS network
by means of label switching routers (LSRs).
A fundamental MPLS principle is that LSRs in an MPLS network must agree on the definition of the
labels being used for packet forwarding operations. Label agreement is achieved in an MPLS network
by means of procedures defined in the Label Distribution Protocol (LDP).
LDP operations begin with a discovery (Hello) process, during which an LDP entity (a local LSR) finds
a cooperating LDP peer in the network and negotiates basic operating procedures between them. The
recognition and identification of a peer by means of this discovery process results in a Hello adjacency,
which represents the context within which label binding information is exchanged between the local
LSR and its LDP peer. An LDP function then creates an active LDP session between the two LSRs to
effect the exchange of label binding information. The result of this process, when carried to completion
with respect to all the LSRs in an MPLS network, is a label switched path (LSP), which constitutes an
end-to-end packet transmission pathway between the communicating network devices.
By means of LDP, LSRs can collect, distribute, and release label binding information to other LSRs in
an MPLS network, thereby enabling the hop-by-hop forwarding of packets in the network along
normally routed paths.
2
MPLS LDP MIB Overview

The MPLS LDP MIB has been implemented to enable standard, SNMP-based network management of
the label switching features in Cisco IOS XE software. Providing this capability requires SNMP agent
code to execute on a designated network management station (NMS) in the network. The NMS serves
as the medium for user interaction with the network management objects in the MPLS LDP MIB.
The SNMP agent embodies a layered structure that is compatible with Cisco IOS XE software and
presents a network administrative and management interface to the objects in the MPLS LDP MIB and,
thence, to the rich set of label switching capabilities supported by Cisco IOS XE software.
By means of an SNMP agent, you can access MPLS LDP MIB objects using standard SNMP get
operations to accomplish a variety of network management tasks. All the objects in the MPLS LDP MIB
follow the conventions defined in the Internet Engineering Task Force (IETF) draft MIB entitled
draft-ietf-mpls-ldp-mib-08.txt, which defines network management objects in a structured and
standardized manner. This draft MIB is continually evolving toward the status of a standard.
Accordingly, the MPLS LDP MIB will be implemented in a manner that tracks the evolution of this IETF
document.
Slight differences that exist between the IETF draft MIB and the implementation of equivalent functions
in Cisco IOS XE software require some minor translations between the MPLS LDP MIB objects and the
internal data structures of Cisco IOS XE software. Such translations are accomplished by the SNMP
agent, which runs in the background on the NMS workstation as a low priority process.
The MPLS LDP MIB provides the following functions:
• The MPLS LDP MIB can generate and send event notification messages to signal changes in the
status of LDP sessions.
• You can enable and disable event notification messages by using SNMP CLI commands.
• You can specify the name or the IP address of an NMS workstation where event notification
messages are sent to serve network administrative and management purposes.
• You can store the configuration pertaining to an event notification message in nonvolatile memory
(NVRAM) of the NMS.
The structure of the MPLS LDP MIB conforms to Abstract Syntax Notation One (ASN.1), thereby
forming a highly structured and idealized database of network management objects.
Using any standard SNMP application, you can retrieve and display information from the
MPLS LDP MIB by means of standard SNMP GET operations. Similarly, you can traverse and display
information in the MIB by means of SNMP GETNEXT operations.
Note Because the MPLS LDP MIB was not given an Internet Assigned Numbers Authority (IANA)
Experimental OID at the time of its implementation, Cisco chose to implement the MIB under the
Cisco Experimental OID number:
ciscoExperiment 1.3.6.1.4.1.9.10
mplsLdpMIB 1.3.6.1.4.1.9.10.65
If the MPLS LDP MIB is assigned an IANA Experimental OID number, Cisco will deprecate all objects
in the MIB under the Cisco Experimental OID and reposition the objects under the IANA Experimental
OID.
3
Benefits of Using MPLS LDP MIB

The MPLS LDP MIB provides the following benefits:
• Establishing LDP sessions between peer devices in an MPLS network
• Retrieving MIB parameters relating to the operation of LDP entities, such as:
– Well-known LDP discovery port
– Maximum transmission unit (MTU)
– Proposed KeepAlive timer interval
– Loop detection
– Session establishment thresholds
– Range of VPI/VCI pairs to be used in forming labels
• Gathering statistics related to LDP operations, such as:
– Count of the total established sessions for an LDP entity
– Count of the total attempted sessions for an LDP entity
• Monitoring the time remaining for Hello adjacencies
• Monitoring the characteristics and status of LDP peers, such as:
– Type of internetwork layer address of LDP peers
– Actual internetwork layer address of LDP peers
– Default MTU of the LDP peer
– Number of seconds the LDP peer proposes as the value of the KeepAlive interval
– Establishment of VPI/VCI label ranges to be made known to LDP peers
• Monitoring the characteristics and status of LDP sessions, such as:
– Determining the LDP version being used by the LDP session
– Determining the KeepAlive hold time remaining for an LDP session
– Determining the state of an LDP session (whether the session is active or not)
– Determining the range of VPI/VCI pairs to be used by an LDP session
– Determining the last active interface of an LDP session
Description of MPLS LDP MIB Elements

The MPLS LDP MIB includes the following elements:
• LDP entity—Relates to an instance of LDP for purposes of exchanging label spaces.
• LDP peer—Refers to a remote LDP entity (that is, a nonlocal LSR).
• LDP session—Refers to an active LDP process between a local LSR and a remote LDP peer.
• Hello adjacency—Refers to the result of an LDP discovery process which affirms the state of two
LSRs in an MPLS network as being adjacent to each other (that is, as being LDP peers).
A Hello adjacency constitutes the working context between two LSRs in an MPLS network. The
adjacency is used for the exchange of label binding information.
These MPLS LDP MIB elements are briefly described under separate headings below.
4
In effect, the MPLS LDP MIB provides a network management database that supports real-time access
to the various MIB objects within, reflecting the current state of MPLS LDP operations in the network.
This network management information database is accessible by means of standard SNMP commands
issued from an NMS in the MPLS/LDP operating environment.
The MPLS LDP MIB supports the following network management and administrative activities:
• Retrieving MPLS LDP MIB parameters pertaining to LDP operations
• Monitoring the characteristics and the status of LDP peers
• Monitoring the status of LDP sessions between LDP peers
• Monitoring Hello adjacencies in the network
• Gathering statistics regarding LDP sessions
LDP Entities
An LDP entity is uniquely identified by an LDP identifier having the object name mplsLdpEntityLdpId.
This object consists of the router ID (four octets) and an interface number (two octets). The router ID
encodes an IP address assigned to the LSR. The interface number identifies a specific label space
available within the LSR.
An LDP entity represents a label space that is targeted for distribution to an LDP peer. In the case of an
interface-specific LDP entity, the label space is distributed to a single LDP peer by means of a single
LDP session.
Conversely, a platform-wide LDP entity can be associated with multiple LDP peers. In this case, the
label space is distributed to multiple LDP peers by means of a separate LDP session pertaining to each
peer.
LDP Peers
If an LSR has a label space to advertise to another LSR, or to multiple LSRs, there would be one LDP
session for each LSR receiving the label space information. The receiver of the label space information
is referred to as an LDP peer.
Per-interface label spaces are advertised to a single LDP peer by means of a single LDP session.
Per-platform label spaces are advertised to multiple LDP peers by means of multiple LDP sessions.
The possible existence of multiple per-platform LDP peers dictates not only that an LDP entity be
identified by its unique LDP tag, but also by its LDP index. In this case, the label space is the same, but
the LDP Index differentiates the LDP session over which the label space is distributed to multiple LDP
peers.
LDP Sessions
LDP sessions between local entities and remote peers distribute label spaces. There is always a
one-to-one correspondence between an LDP peer and an LDP session. A single LDP session is a label
distribution protocol instance that communicates across one or more network links with a single LDP
peer. In the case of a platform-wide local LDP entity, there may be multiple LDP sessions and a
corresponding number of remote LDP peers.
5
LDP Hello Adjacencies

An LDP session is an LDP instance that communicates across one or more network links to a peer
protocol instance. An LDP Hello adjacency exists for each link on which LDP runs. Multiple link
adjacencies exist whenever there are multiple links to the same LDP peer. In the case of a platform-wide
label space, for example, there is a separate LDP peer/LDP session relationship for each LSR to which
a label space may be advertised.
MPLS LDP MIB Object Categories

The MPLS LDP MIB contains numerous definitions of managed objects for the MPLS Label
Distribution Protocol, as defined in the IETF draft document entitled draft-ietf-mpls-ldp-08.txt.
The managed objects in the MPLS LDP MIB are structured according to the following categories:
• MPLS LDP Textual Conventions
• MPLS LDP Objects
• MPLS Label Distribution Protocol Entity Objects
• LDP Entity Objects for Generic Labels
• LDP Entity Objects for ATM
• MPLS LDP Entity Configured ATM Label Range Table
• MPLS Entity Objects for Frame Relay
• Frame Relay Label Range Components
• MPLS LDP Entity Statistics Table
• MPLS LDP Entity Peer Table
• MPLS LDP Hello Adjacency Table
• MPLS LDP Sessions Table
• MPLS LDP ATM Session Information
• MPLS LDP Frame Relay Session Information
• MPLS LDP Session Statistics Table
• Address Message/Address Withdraw Message Information
• MPLS LDP LIB Table
• MPLS LDP FEC Table
• Notifications
• Module Conformance Statement
Events Generating MPLS LDP MIB Notifications

When you enable MPLS LDP MIB notification functionality by issuing the snmp-server enable traps
mpls ldp command, notification messages are generated and sent to a designated NMS in the network
to signal the occurrence of specific events within Cisco IOS XE software.
6
The MPLS LDP MIB objects that announce LDP status transitions and event notifications include the
following:
• mplsLdpSessionUp—This message is generated when an LDP entity (a local LSR) establishes an
LDP session with another LDP entity (an adjacent LDP peer in the network).
• mplsLdpSessionDown—This message is generated when an LDP session between a local LSR and
its adjacent LDP peer is terminated.
The up and down notifications indicate the last active interface in the LDP session.
• mplsLdpPathVectorLimitMismatch—This message is generated when a local LSR establishes an
LDP session with its adjacent peer LSR, but the two LSRs have dissimilar path vector limits.
The value of the path vector limit can range from 0 to 255; a value of 0 indicates that loop detection
is off; any value other than 0 up to 255 indicates that loop detection is on and, in addition, specifies
the maximum number of hops through which an LDP message can pass before a loop condition in
the network is sensed.
We recommend that all LDP-enabled routers in the network be configured with the same path vector
limit. Accordingly, the mplsLdpPathVectorLimitMismatch object exists in the MPLS LDP MIB to
provide a warning message to the NMS when two routers engaged in LDP operations have a
dissimilar path vector limits.
• mplsLdpFailedInitSessionThresholdExceeded—This message is generated when a local LSR and an
adjacent LDP peer attempt to set up an LDP session between them, but fail to do so after a specified
number of attempts. The default number of attempts is 8. This default value is implemented in
Cisco IOS XE software and cannot be changed by either the CLI or an SNMP agent.
Eight failed attempts to establish an LDP session between a local LSR and an LDP peer, due to any
type of incompatibility between the devices, causes this notification message to be generated.
In general, Cisco routers support the same features across multiple platforms. Therefore, the most
likely incompatibility to occur between Cisco LSRs is a mismatch of their respective ATM VPI/VCI
label ranges.
For example, if you specify a range of valid labels for an LSR that does not overlap the range of its
adjacent LDP peer, the routers try eight times to create an LDP session between themselves before
the mplsLdpFailedInitSessionThresholdExceeded notification is generated and sent to the NMS as
an informational message.
Operationally, the LSRs whose label ranges do not overlap continue their attempt to create an LDP
session between themselves after the eight retry limit is exceeded. In such cases, the LDP threshold
exceeded notification alerts the network administrator to the existence of a condition in the network
that may warrant attention.
RFC 3036, LDP Specification, details the incompatibilities that can exist between Cisco routers
and/or other vendor LSRs in an MPLS network. Among such incompatibilities, for example, are the
following:
– Nonoverlapping ATM VPI/VCI ranges (as noted above) or nonoverlapping Frame-Relay DLCI
ranges between LSRs attempting to set up an LDP session
– Unsupported label distribution method
– Dissimilar protocol data unit (PDU) sizes
– Dissimilar LDP feature support
7
How to Configure MPLS LDP MIB

This section describes the tasks for configuring the MPLS LDP MIB:
• Configuring the Router to Send SNMP Traps, page 9 (required)
• Verifying the Status of the SNMP Agent, page 12 (optional)

By default, the SNMP agent for the MPLS LDP MIB is disabled. To enable the SNMP agent on the host
NMS workstation, perform the following procedure.
SUMMARY STEPS
1. enable
4. snmp-server community string [view view-name] [ro | rw] [acl-number]
5. do copy running-config startup-config
6. exit
7. show-running config [interface | map-class]
DETAILED STEPS

Example:
Router> enable
Step 2 show running-config Displays the running configuration to determine if an
SNMP agent is already running.
Example: • If no SNMP information is displayed, continue with the
Router# show running-config next step. If any SNMP information is displayed, you
can modify the information or change it as needed.
Example:
8

Step 4 snmp-server community string [view view-name] Sets up the community access string to permit access to the
[ro | rw] [acl-number] SNMP protocol.
• The string argument acts like a password and permits
Example: access to the SNMP protocol.
Router(config)# snmp-server community comaccess
ro • The view view-name keyword argument pair specifies
the name of a previously defined view. The view
defines the objects available to the community.
• The ro keyword specifies read-only access. Authorized
management stations are only able to retrieve MIB
objects.
• The rw keyword specifies read/write access.
Authorized management stations are able to both
retrieve and modify MIB objects.
• The acl-number argument is an integer from 1 to 99 that
specifies an access list of IP addresses that are allowed
to use the community string to gain access to the SNMP
agent.
Step 5 do copy running-config startup-config Saves the modified configuration to nonvolatile memory
(NVRAM) as the startup configuration file.
Example: • The do command allows you to perform EXEC level
Router(config)# do copy running-config commands in configuration mode.
startup-config
Step 6 exit Returns to privileged EXEC mode.
Example:
Step 7 show running-config [interface | map-class] (Optional) Displays the configuration information currently
on the router, the configuration for a specific interface, or
map-class information.
Example:
Router# show running-config | include • Use the show running-config command to check that
smnp-server the snmp-server statements appear in the output.
Configuring the Router to Send SNMP Traps

Perform this task to configure the router to send traps to a host.
The snmp-server host command specifies which hosts receive traps. The snmp-server enable traps
command globally enables the trap production mechanism for the specified traps.
For a host to receive a trap, an snmp-server host command must be configured for that host, and,
generally, the trap must be enabled globally through the snmp-server enable traps command.
Note Although you can set the community-string argument using the snmp-server host command by itself,
we recommend that you define this string using the snmp-server community command prior to using
the snmp-server host command.
9
SUMMARY STEPS
1. enable
3. snmp-server host host-addr [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}]
community-string [udp-port port] [notification-type] [vrf vrf-name]
4. snmp-server enable traps mpls ldp [session-down] [session-up] [pv-limit] [threshold]
5. exit
DETAILED STEPS

Example:
Router> enable
Example:
10

Step 3 snmp-server host host-addr [traps | informs] Specifies the recipient of an SNMP notification operation.
[version {1 | 2c | 3 [auth | noauth | priv]}]
community-string [udp-port port] • The host-addr argument specifies the name or Internet
[notification-type] [vrf vrf-name] address of the host (the targeted recipient).
• The traps keyword sends SNMP traps to this host. This
Example: is the default.
Router(config)# snmp-server host 172.20.2.160
• The informs keyword sends SNMP informs to this
traps comaccess mpls-ldp
host.
• The version keyword specifies the version of the
SNMP used to send the traps. Version 3 is the most
secure model, because it allows packet encryption with
the priv keyword. If you use the version keyword, you
must specify one of the following:
– 1 —SNMPv1. This option is not available with
informs.
– 2c —SNMPv2C.
– 3 —SNMPv3. The following three optional
keywords can follow the version 3 keyword (auth,
noauth, priv).
• The community-string argument is a password-like
community string sent with the notification operation.
• The udp-port port keyword argument pair names the
UDP port of the host to use. The default is 162.
• The notification-type argument specifies the type of
notification to be sent to the host. If no type is specified,
all notifications are sent.
• The vrf vrf-name keyword argument pair specifies the
VRF table that should be used to send SNMP
notifications.
11

Step 4 snmp-server enable traps mpls ldp Enables the router to send MPLS VPN- specific SNMP
[session-down][session-up] notifications (traps and informs).
[pv-limit][threshold]
• The session-down keyword controls (enables or
disables) LDP session down notifications
Example: (mplsLdpSessionDown). This message is generated
Router(config)# snmp-server enable traps mpls
when an LDP session between the router and its
ldp session-down session-up
adjacent LDP peer is terminated.
• The session-up keyword controls (enables or disables)
LDP session up notifications (mplsLdpSessionUp).
This notification is generated when the router
establishes an LDP session with another LDP entity (an
adjacent LDP peer in the network).
• The pv-limit keyword controls (enables or disables)
path-vector (PV) limit notifications
(mplsLdpPathVectorLimitMismatch). This notification
is generated when the router establishes an LDP session
with its adjacent peer LSR, but the two LSRs have
dissimilar path vector limits.
• The threshold keyword controls (enables or disables)
PV limit notifications
(mplsLdpFailedInitSessionThresholdExceeded). This
notification is generated after eight failed attempts to
establish an LDP session between the router and an
LDP peer. The failure can be the result of any type of
incompatibility between the devices.
Step 5 exit (Optional) Exits to privileged EXEC mode.
Example:
Verifying the Status of the SNMP Agent

To verify that the SNMP agent has been enabled on the host NMS workstation, perform the following
steps.
SUMMARY STEPS
1. enable
3. exit
12
Configuration Examples for MPLS LDP MIB
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show running-config

Use this command to display the running configuration on the host NMS and examine the output for
SNMP information. For example:
.
.
.
snmp-server community public RO
snmp-server community private RO
The presence of any snmp-server statement in the output that takes the form shown above verifies that
the SNMP agent has been enabled on the host NMS workstation.
Step 3 exit
Router# exit
Router>
Configuration Examples for MPLS LDP MIB

This section contains the following configuration example for the MPLS LDP MIB:
• Enabling the SNMP Agent: Examples, page 13
Enabling the SNMP Agent: Examples

The following example shows how to enable an SNMP agent on the host NMS:
The following example shows how to enable SNMPv1 and SNMPv2C on the host NMS. The
configuration permits any SNMP agent to access all MPLS LDP MIB objects with read-only permission
using the community string public.
The following example shows how to allow read-only access to all MPLS LDP MIB objects relating to
members of access list 4 that specify the comaccess community string. No other SNMP agents will have
access to any of the MPLS LDP MIB objects.
The following example shows how to enable the session up and session down LDP notifications:
13
Router(config)# snmp-server enable traps mpls ldp session-up

Router(config)# snmp-server enable traps mpls ldp session-down
The following sections provide references related to the MPLS LDP MIB.
Related Documents
MPLS LDP configuration tasks MPLS Label Distribution Protocol (LDP)
MPLS LDP commands: complete command syntax, Cisco IOS Multiprotocol Label Switching Command Reference
command mode, command history, defaults, usage
Network Management Configuration Guide, Release 2
Standards
Standards Title
MIBs
MIBs MIBs Link
• MPLS LDP MIB To locate and download MIBs for selected platforms, Cisco IOS XE
the following URL:
RFCs
RFCs Title
14
Description Link
15
Feature Information for MPLS Label Distribution MIB

Table 1 Feature Information for MPLS Label Distribution MIB

MPLS Label Distribution Protocol (LDP) Cisco IOS XE This document describes the Simple Network Management
MIB Release 2.1 Protocol (SNMP) agent support provided in Cisco IOS
software for the MPLS Label Distribution Protocol
Management Information Base (MPLS LDP MIB).
feature:
• Benefits of Using MPLS LDP MIB, page 4
• Description of MPLS LDP MIB Elements, page 4
• MPLS LDP MIB Object Categories, page 6
• Events Generating MPLS LDP MIB Notifications,
page 6
• Configuring the Router to Send SNMP Traps, page 9
• Verifying the Status of the SNMP Agent, page 12
snmp-server enable traps mpls ldp.
16
Table 1 Feature Information for MPLS Label Distribution MIB (continued)

MPLS LDP—MIB Notifications Cisco IOS XE This feature provides SNMP traps for critical MPLS LDP
Release 2.1 events.
feature:
• Events Generating MPLS LDP MIB Notifications,
page 6
• Configuring the Router to Send SNMP Traps, page 9
snmp-server enable traps mpls ldp.
countries.
17
18
MPLS Label Distribution Protocol MIB Version 8
Upgrade

The MPLS Label Distribution Protocol (LDP) MIB Version 8 Upgrade feature enhances the LDP MIB
to support the Internet Engineering Task Force (IETF) draft Version 8.

which each feature is supported, see the “Feature Information for MPLS LDP MIB Version 8 Upgrade”
section on page 38.
Contents
• Prerequisites for MPLS LDP MIB Version 8 Upgrade, page 2
• Restrictions for MPLS LDP MIB Version 8 Upgrade, page 2
• Information About MPLS LDP MIB Version 8 Upgrade, page 2
• How to Configure MPLS LDP MIB Version 8 Upgrade, page 24
• Configuration Examples for MPLS LDP MIB Version 8 Upgrade, page 34
• Feature Information for MPLS LDP MIB Version 8 Upgrade, page 38
MPLS Label Distribution Protocol MIB Version 8 Upgrade
Prerequisites for MPLS LDP MIB Version 8 Upgrade
Prerequisites for MPLS LDP MIB Version 8 Upgrade

• Simple Network Management Protocol (SNMP) must be installed and enabled on the label switch
routers (LSRs).
• Multiprotocol Label Switching (MPLS) must be enabled on the LSRs.
• LDP must be enabled on the LSRs.
Restrictions for MPLS LDP MIB Version 8 Upgrade

This implementation of the MPLS LDP MIB is limited to read-only (RO) permission for MIB objects,
except for MIB object mplsLdpSessionUpDownTrapEnable, which has been extended to be writable by
the SNMP agent.
Setting this object to a value of true enables both the mplsLdpSessionUp and mplsLdpSessionDown
notifications on the LSR; conversely, setting this object to a value of false disables both of these
notifications.
For a description of notification events, see the “Events Generating MPLS LDP MIB Notifications in
MPLS LDP MIB Version 8 Upgrade” section on page 9.
Most MPLS LDP MIB objects are set up automatically during the LDP peer discovery (hello) process
and the subsequent negotiation of parameters and establishment of LDP sessions between the LDP peers.
The following tables are not implemented in this feature:
• mplsLdpEntityFrParmsTable
• mplsLdpEntityConfFrLRTable
• mplsLdpFrameRelaySesTable
• mplsFecTable
• mplsLdpSesInLabelMapTable
• mplsXCsFecsTable
• mplsLdpSesPeerAddrTable
Information About MPLS LDP MIB Version 8 Upgrade

To configure MPLS LDP MIB Version 8 Upgrade, you need to understand the following concepts:
• Feature Design of MPLS LDP MIB Version 8 Upgrade, page 2
• Enhancements in Version 8 of the MPLS LDP MIB, page 4
• Benefits of MPLS LDP MIB Version 8 Upgrade, page 4
Feature Design of MPLS LDP MIB Version 8 Upgrade

MPLS is a packet forwarding technology that uses a short, fixed-length value called a label in packets
to specify the next hop for packet transport through an MPLS network by means of label switch routers
(LSRs).
2
A fundamental MPLS principle is that LSRs in an MPLS network must agree on the definition of the
labels being used for packet forwarding operations. Label agreement is achieved in an MPLS network
by means of procedures defined in the LDP.
LDP operations begin with a discovery (hello) process, during which an LDP entity (a local LSR) finds
a cooperating LDP peer in the network, and the two negotiate basic operating procedures. The
recognition and identification of a peer by means of this discovery process results in a hello adjacency,
which represents the context within which label binding information is exchanged between the local
LSR and its LDP peer. LDP then creates an active LDP session between the two LSRs to effect the
exchange of label binding information. When this process is carried to completion with respect to all of
the LSRs in an MPLS network, the result is a label-switched path (LSP), which constitutes an end-to-end
packet transmission pathway between the communicating network devices.
By means of LDP, LSRs can collect, distribute, and release label binding information to other LSRs in
an MPLS network, thereby enabling the hop-by-hop forwarding of packets in the network along
normally routed paths.
The MPLS LDP MIB has been implemented to enable standard, SNMP-based network management of
the label switching features in Cisco IOS XE software. Providing this capability requires SNMP agent
code to execute on a designated network management station (NMS) in the network. The NMS serves
as the medium for user interaction with the network management objects in the MPLS LDP MIB.
The SNMP agent code has a layered structure that is compatible with Cisco IOS XE software and
presents a network administrative and management interface to the objects in the MPLS LDP MIB and,
thence, to the rich set of label switching capabilities supported by Cisco IOS XE software.
By means of an SNMP agent, you can access MPLS LDP MIB objects using standard SNMP GET
operations, and you can use those objects to accomplish a variety of network management tasks. All the
objects in the MPLS LDP MIB follow the conventions defined in the IETF draft MIB entitled
draft-ietf-mpls-ldp-mib-08.txt, which defines network management objects in a structured and
standardized manner. This draft MIB is evolving and is soon expected to be a standard. Accordingly, the
MPLS LDP MIB will be implemented in such a way that it tracks the evolution of this IETF document.
However, slight differences exist between the IETF draft MIB and the implementation of equivalent
Cisco IOS XE functions. As a result, some minor translations between the MPLS LDP MIB objects and
the internal Cisco IOS XE data structures are needed. Such translations are accomplished by the SNMP
agent, which runs in the background on the NMS workstation as a low-priority process.
The extensive Cisco IOS XE label switching capabilities provide an integrated approach to managing the
large volumes of traffic carried by WANs. These capabilities are integrated into the Layer 3 network
services, thus optimizing the routing of high-volume traffic through Internet service provider backbones
while, at the same time, ensuring the resistance of the network to link or node failures.
The MPLS Label Distribution Protocol MIB Version 8 Upgrade supports the following functions:
• Generation and sending of event notification messages that signal changes in the status of LDP
sessions
• Enabling and disabling of event notification messages by means of extensions to existing SNMP CLI
commands
• Specification of the name or the IP address of an NMS workstation in the operating environment to
which Cisco IOS XE event notification messages are to be sent to serve network administrative and
management purposes
• Storage of the configuration pertaining to an event notification message in NVRAM of the NMS
The structure of the MPLS LDP MIB conforms to Abstract Syntax Notation One (ASN.1), so the MIB
forms a highly structured and idealized database of network management objects.
3
Using any standard SNMP application, you can retrieve and display information from the
MPLS LDP MIB by means of standard SNMP GET and GETNEXT operations.
Note Because the MPLS LDP MIB was not given an Internet Assigned Numbers Authority (IANA)
experimental object identifier (OID) at the time of its implementation, Cisco chose to implement the
MIB under the ciscoExperimental OID number, as follows:
ciscoExperimental
1.3.6.1.4.1.9.10
mplsLdpMIB
1.3.6.1.4.1.9.10.65
If the MPLS LDP MIB is assigned an IANA Experimental OID number, Cisco will replace all objects
in the MIB under the ciscoExperimental OID and reposition the objects under the IANA Experimental
OID.
Enhancements in Version 8 of the MPLS LDP MIB

Version 8 of the MPLS LDP MIB contains the following enhancements:
• Upgraded objects
• New indexing that is no longer based on the number of sessions
• Multiple SNMP context support for Virtual Private Networks (VPNs)
Benefits of MPLS LDP MIB Version 8 Upgrade

• Establishes LDP sessions between peer devices in an MPLS network
• Retrieves MIB parameters relating to the operation of LDP entities, such as:
– Well-known LDP discovery port
– Maximum transmission unit (MTU)
– Proposed keepalive timer interval
– Loop detection
– Session establishment thresholds
– Range of virtual path identifier/virtual channel identifier (VPI/VCI) pairs to be used in forming
labels
• Gathers statistics related to LDP operations, such as error counters (Table 5)
• Monitors the time remaining for hello adjacencies
• Monitors the characteristics and status of LDP peers, such as:
– Internetwork layer address of LDP peers
– Loop detection of the LDP peers
– Default MTU of the LDP peer
– Number of seconds the LDP peer proposes as the value of the keepalive interval
• Monitors the characteristics and status of LDP sessions, such as:
4
Description of MPLS LDP MIB Elements for MPLS LDP MIB Version 8 Upgrade
– Displaying the error counters (Table 10)

– Determining the LDP version being used by the LDP session
– Determining the keepalive hold time remaining for an LDP session
– Determining the state of an LDP session (whether the session is active or not)
– Displaying the label ranges (Table 2) for platform-wide and interface-specific sessions
– Displaying the ATM parameters (Table 3)
Description of MPLS LDP MIB Elements for MPLS LDP MIB

Version 8 Upgrade
LDP operations related to an MPLS LDP MIB involve the following functional elements:
• LDP entity—Relates to an instance of LDP for purposes of exchanging label spaces; describes a
potential session.
• LDP peer—Refers to a remote LDP entity (that is, a nonlocal LSR).
• LDP session—Refers to an active LDP process between a local LSR and a remote LDP peer.
• Hello adjacency—Refers to the result of an LDP discovery process that affirms the state of two LSRs
in an MPLS network as being adjacent to each other (that is, as being LDP peers). When the
neighbor is discovered, the neighbor becomes a hello adjacency. An LDP session can be established
with the hello adjacency. After the session is established, label bindings can be exchanged between
the LSRs.
These MPLS LDP MIB elements are briefly described under separate headings below.
In effect, the MPLS LDP MIB provides a network management database that supports real-time access
to the various MIB objects in the database. This database reflects the current state of MPLS LDP
operations in the network. You can access this network management information database by means of
standard SNMP commands issued from an NMS in the MPLS LDP operating environment.
The MPLS LDP MIB supports the following network management and administrative activities:
• Retrieving MPLS LDP MIB parameters pertaining to LDP operations
• Monitoring the characteristics and the status of LDP peers
• Monitoring the status of LDP sessions between LDP peers
• Monitoring hello adjacencies in the network
• Gathering statistics regarding LDP sessions
LDP Entities
An LDP entity is uniquely identified by an LDP identifier that consists of the mplsLdpEntityLdpId and
the mplsLdpEntityIndex (see Figure 1).
• The mplsLdpEntityLdpId consists of the local LSR ID (four octets) and the label space ID (two
octets). The label space ID identifies a specific label space available within the LSR.
• The mplsLdpEntityIndex consists of the IP address of the peer active hello adjacency, which is the
32-bit representation of the IP address assigned to the peer LSR.
The mplsldpEntityProtocolVersion is a sample object from the mplsLdpEntityTable.
5
Figure 1 shows the following indexing:

• mplsLdpEntityLdpId = 10.10.10.10.0.0
• LSR ID = 10.10.10.10
• Label space ID = 0.0
The mplsLdpEntityLdpId or the LDP ID consists of the LSR ID and the label space ID.
• The IP address of peer active hello adjacency or the mplsLdpEntityIndex = 3232235777, which is
the 32-bit representation of the IP address assigned to the peer’s active hello adjacency.
Figure 1 Sample Indexing for an LDP Entity

IP address of peer active
LDP MIB mplsLdpEntityLdpId hello adjacency (mplsLdpEntityIndex)
(mplsLdpEntityTable)
mplsLdpEntityProtocolVersion.10.10.10.10.0.0.3232235777
LSR ID Label
space ID
88214
mplsLdpEntityProtocolVersion.10.10.10.10.0.0.3232236034
An LDP entity represents a label space that has the potential for a session with an LDP peer. An LDP
entity is set up when a hello adjacency receives a hello message from an LDP peer.
In Figure 2, Router A has potential sessions with two remote peers, Routers B and C. The
mplsLdpEntityLdpId is 10.10.10.10.0.0, and the IP address of the peer active hello adjacency
(mplsLdpEntityIndex) is 3232235777, which is the 32-bit representation of the IP address 192.168.1.1
for Router B.
Figure 2 LDP Entity
IP address 192.168.1.1
mplsLdpEntityLdpId 10.10.10.10.0.0 Potential session
Router A (local LDP) (entity)
Router B (peer)
IP address 192.168.2.2
Potential session
(entity)
88213
Router C (peer)
LDP Sessions and Peers

LDP sessions exist between local entities and remote peers for the purpose of distributing label spaces.
There is always a one-to-one correspondence between an LDP peer and an LDP session. A single LDP
session is an LDP instance that communicates across one or more network links with a single LDP peer.
LDP supports the following types of sessions:
6
• Interface-specific—An interface-specific session uses interface resources for label space

distributions. For example, each label-controlled ATM (LC-ATM) interface uses its own VPIs/VCIs
for label space distributions. Depending on its configuration, an LDP platform can support zero, one,
or more interface-specific sessions. Each LC-ATM interface has its own interface-specific label
space and a nonzero label space ID.
• Platform-wide—An LDP platform supports a single platform-wide session for use by all interfaces
that can share the same global label space. For Cisco platforms, all interface types except LC-ATM
use the platform-wide session and have a label space ID of zero.
When a session is established between two peers, entries are created in the mplsLdpPeerTable and the
mplsLdpSessionTable because they have the same indexing.
In Figure 3, Router A has two remote peers, Routers B and C. Router A has a single platform-wide
session that consists of two serial interfaces with Router B and another platform-wide session with
Router C. Router A also has two interface-specific sessions with Router B.
Figure 3 LDP Sessions

Platform-wide session
LSR ID 10.10.10.10 LSR ID 10.11.11.11
Router A (local LDP) Serial Router B (peer)
Serial
LC-ATM
LC-ATM
Interface-
Platform-wide session specific
sessions
Serial
88215
LSR ID 10.12.12.12
Router C (peer)
Figure 4 shows entries that correspond to the mplsLdpPeerTable and the mplsLdpSessionTable in
Figure 3.
In Figure 4, mplsLdpSesState is a sample object from the mplsLdpSessionTable on Router A. There are
four mplsLdpSesState sample objects shown (top to bottom). The first object represents a platform-wide
session associated with two serial interfaces. The next two objects represent interface-specific sessions
for the LC-ATM interfaces on Routers A and B. These interface-specific sessions have nonzero peer
label space IDs. The last object represents a platform-wide session for the next peer, Router C.
The indexing is based on the entries in the mplsLdpEntityTable. It begins with the indexes of the
mplsLdpEntityTable and adds the following:
• Peer LDP ID = 10.11.11.11.0.0
The peer LDP ID consists of the peer LSR ID (four octets) and the peer label space ID (two octets).
• Peer LSR ID = 10.11.11.11
• Peer label space ID = 0.0
The peer label space ID identifies a specific peer label space available within the LSR.
7
Figure 4 Sample Indexing for an LDP Session
mpIsLdpSessionTable Peer LDP ID
mpIsLdpSesState.10.10.10.10.0.0.3232235777.10.11.11.11.0.0
Indexing of Peer label space ID
Peer LSR ID
mpIsLdpEntityTable
mplsLdpSesState.10.10.10.10.0.0.3232236034.10.12.12.12.0.0
88216
LDP Hello Adjacencies

An LDP hello adjacency is a network link between a router and its peers. An LDP hello adjacency
enables two adjacent peers to exchange label binding information.
An LDP hello adjacency exists for each link on which LDP runs. Multiple LDP hello adjacencies exist
whenever there is more than one link in a session between a router and its peer, such as in a
platform-wide session.
A hello adjacency is considered active if it is currently engaged in a session, or nonactive if it is not
currently engaged in a session.
A targeted hello adjacency is not directly connected to its peer and has an unlimited number of hops
between itself and its peer. A linked hello adjacency is directly connected between two routers.
In Figure 5, Router A has two remote peers, Routers B and C. Router A has a platform-wide session with
Router B that consists of three serial interfaces, one of which is active and another platform-wide
(targeted) session with Router C.
Figure 5 Hello Adjacency

LSR ID 10.10.10.10 Platform-wide session LSR ID 10.11.11.11
Router A (local LDP) Router B (peer)
Serial Serial (active)
Serial
LSR ID 10.12.12.12
Platform-wide Router C (peer)
session (targeted)
88217
Figure 6 shows entries in the mplsLdpHelloAdjacencyTable. There are four

mplsLdpHelloAdjHoldTime sample objects (top to bottom). They represent the two platform-wide
sessions and the four serial links shown in Figure 5.
The indexing is based on the mplsLdpSessionTable. When the mplsLdpHelloAdjIndex enumerates the
different links within a single session, the active link is mplsLdpHelloAdjIndex = 1.
8
Events Generating MPLS LDP MIB Notifications in MPLS LDP MIB Version 8 Upgrade
Figure 6 Sample Indexing for an LDP Hello Adjacency

mplsLdpHelloAdjacencyTable
mplsLdpHelloAdjHoldTimeRem.10.10.10.10.0.0.3232235777.10.11.11.11.0.0.1
Indexing of mpIsLdpSessionTable mplsLdpHelloAdjIndex
88218
Events Generating MPLS LDP MIB Notifications in MPLS LDP

MIB Version 8 Upgrade
When you enable MPLS LDP MIB notification functionality by issuing the snmp-server enable traps
mpls ldp command, notification messages are generated and sent to a designated NMS in the network
to signal the occurrence of specific events within Cisco IOS XE network.
The MPLS LDP MIB objects involved in LDP status transitions and event notifications include the
following:
• mplsLdpSessionUp—This message is generated when an LDP entity (a local LSR) establishes an
LDP session with another LDP entity (an adjacent LDP peer in the network).
• mplsLdpSessionDown—This message is generated when an LDP session between a local LSR and
its adjacent LDP peer is terminated.
• mplsLdpPathVectorLimitMismatch—This message is generated when a local LSR establishes an
LDP session with its adjacent peer LSR, but the two LSRs have dissimilar path vector limits.
The value of the path vector limit can range from 0 through 255; a value of 0 indicates that loop
detection is off; any value other than zero up to 255 indicates that loop detection is on and, in
addition, specifies the maximum number of hops through which an LDP message can pass before a
loop condition in the network is sensed.
We recommend that all LDP-enabled routers in the network be configured with the same path vector
limit. Accordingly, the mplsLdpPathVectorLimitMismatch object exists in the MPLS LDP MIB to
provide a warning message to the NMS when two routers engaged in LDP operations have different
path vector limits.
Note This notification is generated only if the distribution method is downstream-on-demand.
• mplsLdpFailedInitSessionThresholdExceeded—This message is generated when a local LSR and an

adjacent LDP peer attempt to set up an LDP session between them, but fail to do so after a specified
number of attempts. The default number of attempts is 8. This default value is implemented and
cannot be changed.
Eight failed attempts to establish an LDP session between a local LSR and an LDP peer, due to any
type of incompatibility between the devices, causes this notification message to be generated.
Cisco routers support the same features across multiple platforms.
Therefore, the most likely incompatibility to occur between Cisco LSRs is a mismatch of their
respective ATM VPI/VCI label ranges.
9
MIB Tables in MPLS LDP MIB Version 8 Upgrade
For example, if you specify a range of valid labels for an LSR that does not overlap the range of its
adjacent LDP peer, the routers try eight times to create an LDP session between themselves before
the mplsLdpFailedInitSessionThresholdExceeded notification is generated and sent to the NMS as
an informational message.
The LSRs whose label ranges do not overlap continue their attempt to create an LDP session
between themselves after the eight-retry threshold is exceeded.
In such cases, the LDP threshold exceeded notification alerts the network administrator about a
condition in the network that might warrant attention.
RFC 3036, LDP Specification, details the incompatibilities that can exist between Cisco routers
and/or other vendor LSRs in an MPLS network.
Among such incompatibilities, for example, are the following:
– Nonoverlapping ATM VPI/VCI ranges (as noted above) or nonoverlapping Frame-Relay DLCI
ranges between LSRs attempting to set up an LDP session
– Unsupported label distribution method
– Dissimilar protocol data unit (PDU) sizes
– Dissimilar types of LDP feature support

Version 8 of the MPLS LDP MIB consists of the following tables:
• mplsLdpEntityTable (Table 1)—Contains entries for every active LDP hello adjacency. Nonactive
hello adjacencies appear in the mplsLdpHelloAdjacencyTable, rather than this table. This table is
indexed by the local LDP identifier for the interface and the IP address of the peer active hello
adjacency. (See Figure 1.)
The advantage of showing the active hello adjacency instead of sessions in this table is that the active
hello adjacency can exist even if an LDP session is not active (cannot be established). Previous
implementations of the IETF MPLS-LDP MIB used sessions as the entries in this table. This
approach was inadequate because as sessions went down, the entries in the entity table would
disappear completely because the agent code could no longer access them. This resulted in the MIB
failing to provide information about failed LDP sessions.
Directed adjacencies are also shown in this table. These entries, however, are always up
administratively (adminStatus) and operationally (operStatus), because the adjacencies disappear if
the directed session fails. Nondirected adjacencies might disappear from the MIB on some
occasions, because adjacencies are deleted if the underlying interface becomes operationally down,
for example.
• mplsLdpEntityConfGenLRTable (Table 2)—Contains entries for every LDP-enabled interface that
is in the global label space. (For Cisco, this applies to all interfaces except LC-ATM. LC-ATM
entities are shown in the mplsLdpEntityConfAtmLRTable instead.) Indexing is the same as it is for
the mplsLdpEntityTable, except two indexes have been added, mplsLdpEntityConfGenLRMin and
mplsLdpEntityConfGenLRMax. These additional indexes allow more than one label range to be
defined. However, in the current Cisco IOS XE implementation, only one global label range is
allowed.
• mplsLdpEntityAtmParmsTable (Table 3)—Contains entries for every LDP-enabled LC-ATM
interface. This table is indexed the same as the mplsLdpEntityTable although only LC-ATM
interfaces are shown.
10
• mplsLdpEntityConfAtmLRTable (Table 4)—Contains entries for every LDP-enabled LC-ATM

interface. Indexing is the same as it is for the mplsLdpEntityTable, except two indexes have been
added, mplsLdpEntityConfAtmLRMinVpi and mplsLdpEntityConfAtmLRMinVci. These
additional indexes allow more than one label range to be defined. However, in the current
Cisco IOS XE implementation, only one label range per LC-ATM interface is allowed.
• mplsLdpEntityStatsTable (Table 5)—Augments the mplsLdpEntityTable and shares the exact same
indexing for performing GET and GETNEXT operations. This table shows additional statistics for
entities.
• mplsLdpPeerTable (Table 6)—Contains entries for all peer sessions. This table is indexed by the
local LDP identifier of the session, the IP address of the peer active hello adjacency, and the peer’s
LDP identifier. (See Figure 4.)
• mplsLdpHelloAdjacencyTable (Table 7)—Contains entries for all hello adjacencies. This table is
indexed by the local LDP identifier of the associated session, the IP address of the peer active hello
adjacency, the LDP identifier for the peer, and an arbitrary index that is set to the list position of the
adjacency. (See Figure 6.)
• mplsLdpSessionTable (Table 8)—Augments the mplsLdpPeerTable and shares the same indexing for
performing GET and GETNEXT operations. This table shows all sessions.
• mplsLdpAtmSesTable (Table 9)—Contains entries for LC-ATM sessions. Indexing is the same as it
is for the mplsLdpPeerTable, except two indexes have been added,
mplsLdpSesAtmLRLowerBoundVpi and mplsLdpSesAtmLRLowerBoundVci. These additional
indexes allow more than one label range to be defined. However, in the current Cisco IOS XE
implementation, only one label range per LC-ATM interface is allowed.
• mplsLdpSesStatsTable (Table 10)—Augments the mplsLdpPeerTable and shares the exact same
indexing for performing GET and GETNEXT operations. This table shows additional statistics for
sessions.
mplsLdpEntityTable
Table 1 lists the mplsLdpEntityTable objects and their descriptions.
Table 1 mplsLdpEntityTable Objects and Descriptions
Object Description
mplsLdpEntityEntry Represents an LDP entity, which is a potential session between
two peers.
mplsLdpEntityLdpId The LDP identifier (not accessible) consists of the local LSR ID
(four octets) and the label space ID (two octets).
mplsLdpEntityIndex A secondary index that identifies this row uniquely. It consists
of the IP address of the peer active hello adjacency, which is the
32-bit representation of the IP address assigned to the LSR (not
accessible).
mplsLdpEntityProtocolVersion The version number of the LDP protocol to be used in the
session initialization message.
mplsLdpEntityAdminStatus The administrative status of this LDP entity is always up. If the
hello adjacency fails, this entity disappears from the
mplsLdpEntityTable.
11
Table 1 mplsLdpEntityTable Objects and Descriptions (continued)
Object Description
mplsLdpEntityOperStatus The operational status of this LDP entity. Values are
unknown(0), enabled(1), and disabled(2).
mplsLdpEntityTcpDscPort The TCP discovery port for LDP or TDP. The default value is
646 (LDP).
mplsLdpEntityUdpDscPort The UDP discovery port for LDP or TDP. The default value is
646 (LDP).
mplsLdpEntityMaxPduLength The maximum PDU length that is sent in the common session
parameters of an initialization message.
mplsLdpEntityKeepAliveHoldTimer The two-octet value that is the proposed keepalive hold time for
this LDP entity.
mplsLdpEntityHelloHoldTimer The two-octet value that is the proposed hello hold time for this
LDP entity.
mplsLdpEntityInitSesThreshold The threshold for notification when this entity and its peer are
engaged in an endless sequence of initialization messages.
The default value is 8 and cannot be changed by SNMP or CLI.
mplsLdpEntityLabelDistMethod The specified method of label distribution for any given LDP
session. Values are downstreamOnDemand(1) and
downstreamUnsolicited(2).
mplsLdpEntityLabelRetentionMode Can be configured to use either conservative(1) for LC-ATM or
liberal(2) for all other interfaces.
mplsLdpEntityPVLMisTrapEnable Indicates whether the mplsLdpPVLMismatch trap should be
generated.
If the value is enabled(1), the trap is generated. If the value is
disabled(2), the trap is not generated. The default is
disabled(2).
Note The mplsLdpPVLMismatch trap is generated only if
mplsLdpEntityLabelDistMethod is
downstreamOnDemand(1).
mplsLdpEntityPVL If the value of this object is 0, loop detection for path vectors is
disabled. Otherwise, if this object has a value greater than zero,
loop detection for path vectors is enabled, and the path vector
limit is this value.
Note The mplsLdpEntityPVL object is non-zero only if
mplsLdpEntityLabelDistMethod is
mplsLdpEntityHopCountLimit If the value of this object is 0, loop detection using hop counters
is disabled.
If the value of this object is greater than 0, loop detection using
hop counters is enabled, and this object specifies this entity's
maximum allowable value for the hop count.
Note The mplsLdpEntityHopCountLimit object is non-zero
only if mplsLdpEntityLabelDistMethod is
12
Table 1 mplsLdpEntityTable Objects and Descriptions (continued)
Object Description
mplsLdpEntityTargPeer If this LDP entity uses a targeted adjacency, this object is set to
true(1). The default value is false(2).
mplsLdpEntityTargPeerAddrType The type of the internetwork layer address used for the
extended discovery. This object indicates how the value of
mplsLdpEntityTargPeerAddr is to be interpreted.
mplsLdpEntityTargPeerAddr The value of the internetwork layer address used for the
targeted adjacency.
mplsLdpEntityOptionalParameters Specifies the optional parameters for the LDP initialization
message. If the value is generic(1), no optional parameters are
sent in the LDP initialization message associated with this
entity.
LC-ATM uses atmParameters(2) to specify that a row in the
mplsLdpEntityAtmParmsTable corresponds to this entry.
Note Frame Relay parameters are not supported.
mplsLdpEntityDiscontinuityTime The value of sysUpTime on the most recent occasion when one
or more of this entity’s counters suffered a discontinuity. The
relevant counters are the specific instances of any Counter32 or
Counter64 object contained in the mplsLdpEntityStatsTable
that are associated with this entity. If no such discontinuities
have occurred since the last reinitialization of the local
management subsystem, this object contains a 0 value.
mplsLdpEntityStorType The storage type for this entry is a read-only implementation
that is always volatile.
mplsLdpEntityRowStatus This object is a read-only implementation that is always active.
mplsLdpEntityConfGenLRTable
Table 2 lists the mplsLdpEntityConfGenLRTable objects and their descriptions.
Table 2 mplsLdpEntityConfGenLRTable Objects and Descriptions
Object Description
mplsLdpEntityConfGenLREntry A row in the LDP Entity Configurable Generic Label Range
table. One entry in this table contains information on a single
range of labels; the range is defined by an upper boundary
(VPI/VCI pair) and a lower boundary (VPI/VCI pair).
The current implementation supports one label range per
entity.
mplsLdpEntityConfGenLRMin The minimum label configured for this range (not
accessible).
mplsLdpEntityConfGenLRMax The maximum label configured for this range (not
accessible).
13
Table 2 mplsLdpEntityConfGenLRTable Objects and Descriptions (continued)
Object Description
mplsLdpEntityConfGenIfIndxOrZero This value represents the SNMP IF-MIB index for the
platform-wide entity. If the active hello adjacency is targeted,
the value is 0.
mplsLdpEntityConfGenLRStorType The storage type for this entry is a read-only implementation
mplsLdpEntityConfGenLRRowStatus This object is a read-only implementation that is always
active.
mplsLdpEntityAtmParmsTable
Table 3 lists the mplsLdpEntityAtmParmsTable objects and their descriptions.
Table 3 mplsLdpEntityAtmParmsTable Objects and Descriptions
Object Description
mplsLdpEntityAtmParmsEntry Represents the ATM parameters and ATM information for
this LDP entity.
mplsLdpEntityAtmIfIndxOrZero This value represents the SNMP IF-MIB index for the
interface-specific LC-ATM entity.
mplsLdpEntityAtmMergeCap Denotes the merge capability of this entity.
mplsLdpEntityAtmLRComponents Number of label range components in the initialization
message. This also represents the number of entries in the
mplsLdpEntityConfAtmLRTable that correspond to this
entry.
mplsLdpEntityAtmVcDirectionality If the value of this object is bidirectional(0), a given VCI
within a given VPI is used as a label for both directions
independently of one another.
If the value of this object is unidirectional(1), a given VCI
within a VPI designates one direction.
mplsLdpEntityAtmLsrConnectivity The peer LSR can be connected indirectly by means of an
ATM VP, so that the VPI values can be different on the
endpoints. For that reason, the label must be encoded entirely
within the VCI field.
Values are direct(1), the default, and indirect(2).
mplsLdpEntityDefaultControlVpi The default VPI value for the non-MPLS connection.
mplsLdpEntityDefaultControlVci The default VCI value for the non-MPLS connection.
mplsLdpEntityUnlabTrafVpi VPI value of the VCC supporting unlabeled traffic. This
non-MPLS connection is used to carry unlabeled (IP)
packets.
mplsLdpEntityUnlabTrafVci VCI value of the VCC supporting unlabeled traffic. This
non-MPLS connection is used to carry unlabeled (IP)
packets.
14
Table 3 mplsLdpEntityAtmParmsTable Objects and Descriptions (continued)
Object Description
mplsLdpEntityAtmStorType The storage type for this entry is a read-only implementation
mplsLdpEntityAtmRowStatus This object is a read-only implementation that is always
active.
mplsLdpEntityConfAtmLRTable
Table 4 lists the mplsLdpEntityConfAtmLRTable objects and their descriptions.
Table 4 mplsLdpEntityConfAtmLRTable Objects and Descriptions
Object Description
mplsLdpEntityConfAtmLREntry A row in the LDP Entity Configurable ATM Label Range
Table. One entry in this table contains information on a single
range of labels; the range is defined by an upper boundary
(VPI/VCI pair) and a lower boundary (VPI/VCI pair). This is
the same data used in the initialization message. This label
range should overlap the label range of the peer.
mplsLdpEntityConfAtmLRMinVpi The minimum VPI number configured for this range (not
accessible).
mplsLdpEntityConfAtmLRMinVci The minimum VCI number configured for this range (not
accessible).
mplsLdpEntityConfAtmLRMaxVpi The maximum VPI number configured for this range (not
accessible).
mplsLdpEntityConfAtmLRMaxVci The maximum VCI number configured for this range (not
accessible).
mplsLdpEntityConfAtmLRStorType The storage type for this entry is a read-only implementation
mplsLdpEntityConfAtmLRRowStatus This object is a read-only implementation that is always
active.
mplsLdpEntityStatsTable
Table 5 lists the mplsLdpEntityStatsTable objects and their descriptions.
Table 5 mplsLdpEntityStatsTable Objects and Descriptions
Object Description
mplsLdpEntityStatsEntry These entries augment the mplsLdpEntityTable by providing
additional information for each entry.
mplsLdpAttemptedSessions Not supported in this feature.
mplsLdpSesRejectedNoHelloErrors A count of the session rejected/no hello error notification
messages sent or received by this LDP entity.
15
Table 5 mplsLdpEntityStatsTable Objects and Descriptions (continued)
Object Description
mplsLdpSesRejectedAdErrors A count of the session rejected/parameters advertisement
mode error notification messages sent or received by this
LDP entity.
mplsLdpSesRejectedMaxPduErrors A count of the session rejected/parameters max PDU length
error notification messages sent or received by this LDP
entity.
mplsLdpSesRejectedLRErrors A count of the session rejected/parameters label range
notification messages sent or received by this LDP entity.
mplsLdpBadLdpIdentifierErrors A count of the number of bad LDP identifier fatal errors
detected by the session associated with this LDP entity.
mplsLdpBadPduLengthErrors A count of the number of bad PDU length fatal errors
mplsLdpBadMessageLengthErrors A count of the number of bad message length fatal errors
mplsLdpBadTlvLengthErrors A count of the number of bad Type-Length-Value (TLV)
length fatal errors detected by the session associated with this
LDP entity.
mplsLdpMalformedTlvValueErrors A count of the number of malformed TLV value fatal errors
mplsLdpKeepAliveTimerExpErrors A count of the number of session keepalive timer expired
errors detected by the session associated with this LDP entity.
mplsLdpShutdownNotifReceived A count of the number of shutdown notifications received
related to the session associated with this LDP entity.
mplsLdpShutdownNotifSent A count of the number of shutdown notifications sent related
to the session associated with this LDP entity.
mplsLdpPeerTable
Table 6 lists the mplsLdpPeerTable objects and their descriptions.
Table 6 mplsLdpPeerTable Objects and Descriptions
Object Description
mplsLdpPeerEntry Information about a single peer that is related to a session
(not accessible).
Note This table is augmented by the mplsLdpSessionTable.
mplsLdpPeerLdpId The LDP identifier of this LDP peer (not accessible) consists
of the peer LSR ID (four octets) and the peer label space ID
(two octets).
mplsLdpPeerLabelDistMethod For any given LDP session, the method of label distribution.
Values are downstreamOnDemand(1) and
downstreamUnsolicited(2).
16
Table 6 mplsLdpPeerTable Objects and Descriptions (continued)
Object Description
mplsLdpPeerLoopDetectionForPV An indication of whether loop detection based on path
vectors is disabled or enabled for this peer.
For downstream unsolicited distribution
(mplsLdpPeerLabelDistMethod is
downstreamUnsolicited(2)), this object always has a value of
disabled(0) and loop detection is disabled.
For downstream-on-demand distribution
(mplsLdpPeerLabelDistMethod is
downstreamOnDemand(1)), this object has a value of
enabled(1), provided that loop detection based on path
vectors is enabled.
mplsLdpPeerPVL If the value of mplsLdpPeerLoopDetectionForPV for this
entry is enabled(1), this object represents that path vector
limit for this peer.
If the value of mplsLdpPeerLoopDetectionForPV for this
entry is disabled(0), this value should be 0.
mplsLdpHelloAdjacencyTable
Table 7 lists the mplsLdpHelloAdjacencyTable objects and their descriptions.
Table 7 mplsLdpHelloAdjacencyTable Objects and Descriptions
Object Description
mplsLdpHelloAdjacencyEntry Each row represents a single LDP hello adjacency. An LDP
session can have one or more hello adjacencies (not
accessible).
mplsLdpHelloAdjIndex An identifier for this specific adjacency (not accessible). The
active hello adjacency has mplsLdpHelloAdjIndex equal to 1.
mplsLdpHelloAdjHoldTimeRem The time remaining for this hello adjacency. This interval
changes when the next hello message, which corresponds to
this hello adjacency, is received.
mplsLdpHelloAdjType This adjacency is the result of a link hello if the value of this
object is link(1). Otherwise, this adjacency is a result of a
targeted hello and its value is targeted(2).
mplsLdpSessionTable
Table 8 lists the mplsLdpSessionTable objects and their descriptions.
17
Table 8 mplsLdpSessionTable Objects and Descriptions
Object Description
mplsLdpSessionEntry An entry in this table represents information on a single
session between an LDP entity and an LDP peer. The
information contained in a row is read-only. This table
augments the mplsLdpPeerTable.
mplsLdpSesState The current state of the session. All of the states are based on
the LDP or TDP state machine for session negotiation
behavior.
The states are as follows:
• nonexistent(1)
• initialized(2)
• openrec(3)
• opensent(4)
• operational(5)
mplsLdpSesProtocolVersion The version of the LDP protocol which this session is using.
This is the version of the LDP protocol that has been
negotiated during session initialization.
mplsLdpSesKeepAliveHoldTimeRem The keepalive hold time remaining for this session.
mplsLdpSesMaxPduLen The value of maximum allowable length for LDP PDUs for
this session. This value could have been negotiated during the
session initialization.
mplsLdpSesDiscontinuityTime The value of sysUpTime on the most recent occasion when
one or more of this session’s counters suffered a
discontinuity. The relevant counters are the specific instances
of any Counter32 or Counter64 object contained in the
mplsLdpSesStatsTable associated with this session.
The initial value of this object is the value of sysUpTime
when the entry was created in this table.
mplsLdpAtmSesTable
Table 9 lists the mplsLdpAtmSesTable objects and their descriptions.
Table 9 mplsLdpAtmSesTable Objects and Descriptions
Objects Description
mplsLdpAtmSesEntry An entry in this table represents information on a single label
range intersection between an LDP entity and an LDP peer
(not accessible).
mplsLdpAtmSesLRLowerBoundVpi The minimum VPI number for this range (not accessible).
mplsLdpAtmSesLRLowerBoundVci The minimum VCI number for this range (not accessible).
18
Table 9 mplsLdpAtmSesTable Objects and Descriptions (continued)
Objects Description
mplsLdpAtmSesLRUpperBoundVpi The maximum VPI number for this range (read-only).
mplsLdpAtmSesLRUpperBoundVci The maximum VCI number for this range (read-only).
mplsLdpSesStatsTable
Table 10 lists the mplsLdpSesStatsTable objects and their descriptions.
Table 10 mplsLdpSesStatsTable Objects and Descriptions
Object Description
mplsLdpSesStatsEntry An entry in this table represents statistical information on a
single session between an LDP entity and an LDP peer. This
table augments the mplsLdpPeerTable.
mplsLdpSesStatsUnkMesTypeErrors This object is the count of the number of unknown message
type errors detected during this session.
mplsLdpSesStatsUnkTlvErrors This object is the count of the number of unknown TLV errors
detected during this session.
VPN Contexts in MPLS LDP MIB Version 8 Upgrade

Within an MPLS Border Gateway Protocol (BGP) 4 Virtual Private Network (VPN) environment,
separate LDP processes can be created for each VPN. These processes and their associated data are
called LDP contexts. Each context is independent from all others and contains data specific only to that
context.
This feature adds support for different contexts for different MPLS VPNs. Users of the MIB can view
MPLS LDP processes for a given MPLS VPN. The VPN Aware LDP MIB feature does not change the
syntax of the IETF MPLS-LDP MIB. It changes the number and types of entries within the tables.
The IETF MPLS-LDP MIB can show information about only one context at a time. You can specify a
context, either a global context or an MPLS VPN context, using an SMNP security name.
The following sections describe topics related to the VPN Aware LDP MIB feature:
• SNMP Contexts, page 19
• VPN Aware LDP MIB Sessions, page 20
• VPN Aware LDP MIB Notifications, page 22
SNMP Contexts
SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated
with a context, that VPN’s specific MIB data exists in that context. Associating a VPN with a context
enables service providers to manage networks with multiple VPNs. Creating and associating a context
with a VPN enables a provider to prevent the users of one VPN from accessing information about users
of other VPNs on the same networking device.
19
VPN-aware SNMP requires that SNMP manager and agent entities operating in a VPN environment
agree on mapping between the SNMP security name and the VPN name. This mapping is created by
using different contexts for the SNMP data of different VPNs, which is accomplished through the
configuration of the SNMP View-based Access Control Model MIB (SNMP-VACM-MIB). The
SNMP-VACM-MIB is configured with views so that a user on a VPN with a security name is allowed
access to the restricted object space within the context of only that VPN.
SNMP request messages undergo three phases of security and access control before a response message
is sent back with the object values within a VPN context:
• The first security phase is authentication of the username. During this phase, the user is authorized
for SNMP access.
• The second phase is access control. During this phase, the user is authorized for SNMP access to the
group objects in the requested SNMP context.
• In the third phase, the user can access a particular instance of a table entry. With this third phase,
complete retrieval can be based on the SNMP context name.
IP access lists can be configured and associated with SNMP community strings. This feature enables you
to configure an association between VRF instances and SNMP community strings. When a VRF instance
is associated with an SNMP community string, SNMP processes requests coming in for a particular
community string only if they are received from the configured VRF. If the community string contained
in the incoming packet does not have a VRF associated with it, it is processed only if it came in through
a non-VRF interface.
You can also enable or disable authentication traps for SNMP packets dropped due to VRF mismatches.
By default, if SNMP authentication traps are enabled, VRF authentication traps are also enabled.
VPN Aware LDP MIB Sessions

Before the VPN Aware LDP MIB features, an SNMP query to the MPLS LDP MIB returned information
about global sessions only. A query did not return information about LDP sessions in a VPN context.
The IETF MPLS LDP MIB retrieved information from global routing tables, but did not retrieve
information from VPN routing and forwarding instances (VRFs) that store per-VPN routing data. The
MPLS LDP MIB looked only at LDP processes in the global context and ignored all other sessions. A
query on a VRF returned no information. You can view LDP processes in a VPN context.
Figure 7 shows a sample MPLS VPN network with the MPLS LDP sessions prior to the implementation
of the VPN Aware LDP MIB feature.
20
Figure 7 MPLS LDP Sessions Setup Before VPN Aware LDP MIB Feature
LDP sessions on PE1

PE1 PE2 MIB walk on PE1 (global context)
PE1 CE1-1 PE1 PE2
Site 1 PE1 CE1-2 Site 2
CE1-1 CE2-1
VPN1 VPN1
Global LDP session

VPN1 LDP session
VPN2 LDP session PE1 P PE2
Core
VPN2 VPN2
103281
CE1-2 CE2-2
Site 1 LDP sessions Site 2
A MIB walk prior to this Cisco IOS XE release displayed only global session information.
With the VPN Aware LDP MIB enhancement, an SNMP query to the IETF MPLS-LDP-MIB supports
both global and VPN contexts. This feature allows you to enter LDP queries on any VRF and on the core
(global context). A query can differentiate between LDP sessions from different VPNs. LDP session
information for a VPN stays in the context of that VPN. Therefore, the information from one VPN is not
available to a user of a different VPN. The VPN Aware update to the LDP MIB also allows you to view
LDP processes operating in a Carrier Supporting Carrier (CSC) network.
In an MPLS VPN, a service provider edge router (PE) might contain VRFs for several VPNs as well as
a global routing table. To set up separate LDP processes for different VPNs on the same device, you need
to configure each VPN with a unique securityName, contextName, and View-based Access Control
Model (VACM) view. The VPN securityName must be configured for the IETF MPLS LDP MIB.
Figure 8 shows LDP sessions for a sample MPLS VPN network with the VPN Aware LDP MIB feature.
21
Figure 8 MPLS LDP Sessions with the VPN Aware LDP MIB Feature
LDP sessions on PE1 MIB walk on PE1 MIB walk on PE1 MIB walk on PE1
PE1 PE2 (global context) (VPN1 context) (VPN2 context)
PE1 CE1-1 PE1 PE2 PE1 CE1-1 PE1 CE2-1
PE1 CE1-2
Site 1 Site 2
CE1-1 CE2-1
VPN1 VPN1
Global LDP session

VPN1 LDP session
Core
VPN2 VPN2
103282
CE1-2 CE2-2
Site 1 LDP sessions Site 2
With the VPN Aware LDP MIB feature, you can do MIB queries or MIB walks for an MPLS VPN LDP
session or a global LDP session.
Note To verify LDP session information for a specific VPN, use the show mpls ldp neighbor vrf vpn-name
detail command.
VPN Aware LDP MIB Notifications

Before the VPN Aware LDP MIB feature, all notification messages for MPLS LDP sessions were sent
to the same designated network management station (NMS) in the network. The notifications were
enabled with the snmp-server enable traps mpls ldp command.
Figure 9 shows LDP notifications that were sent before the implementation of the VPN Aware LDP MIB
feature.
22
Figure 9 LDP Notifications Sent Before the VPN Aware LDP MIB Feature
SNMP manager
VPN2 LDP session down

Global LDP session down
Site 1 Site 2
CE1-1 VPN1 LDP session down CE2-1
VPN1 VPN1
Global LDP session

VPN1 LDP session
Core
VPN2 VPN2
103283
CE1-2 LDP session down CE2-2
Site 1 Site 2
Notification sent
The VPN Aware LDP MIB feature supports LDP notifications for multiple LDP contexts for VPNs. LDP
notifications can be generated for the core (global context) and for different VPNs. You can cause
notifications be sent to different NMS hosts for different LDP contexts. LDP notifications associated
with a specific VRF are sent to the NMS designated for that VRF. LDP global notifications are sent to
the NMS configured to receive global traps.
To enable LDP context notifications for the VPN Aware LDP MIB feature, use either the SNMP object
mplsLdpSessionsUpDownEnable (in the global LDP context only) or the following extended global
configuration commands.
To enable LDP notifications for the global context, use the following commands on a PE router:
Router(config)# snmp-server host host-address traps community mpls-ldp
Router(config)# snmp-server enable traps mpls ldp
To enable LDP notifications for a VPN context, use the following commands on a PE router:
Router(config)# snmp-server host host-address vrf vrf-name version {v1|v2c|v3}
community community-string udp-port upd-port mpls-ldp
Router(config)# snmp-server enable traps mpls ldp
Figure 10 shows LDP notifications with the VPN Aware LDP MIB feature.
23
How to Configure MPLS LDP MIB Version 8 Upgrade
Figure 10 LDP Notifications With the VPN Aware LDP MIB Feature
VPN2 LDP VPN1 context LDP Global context LDP

session down session down session down
SNMP managers SNMP managers
Site 1 Site 2
CE1-1 CE2-1
VPN1 VPN1
Global LDP session

VPN1 LDP session
Core
VPN2 VPN2
103284
CE1-2 LDP session down CE2-2
Site 1 Site 2
Notification sent

• Enabling Distributed Cisco Express Forwarding, page 25 (required)
• Enabling MPLS Globally, page 26 (required)
• Enabling LDP Globally, page 27 (required)
• Enabling MPLS on an Interface, page 27 (required)
• Enabling LDP on an Interface, page 28 (required)
• Configuring a VPN Aware LDP MIB, page 29 (required)
• Verifying MPLS LDP MIB Version 8 Upgrade, page 34 (optional)

Perform this task to enable the SNMP agent.
SUMMARY STEPS
1. enable
4. snmp-server community string [view view-name] [ro] [number]
24
5. end
6. write memory
DETAILED STEPS

Example:
Router> enable
device.
Example:
next step.
Example:
Step 4 snmp-server community string [view view-name] Configures read-only (ro) community strings for the MPLS
[ro] [number] LDP MIB.
• The string argument functions like a password,
Example: permitting access to SNMP functionality on label
Router(config)# snmp-server community public ro switch routers (LSRs) in an MPLS network.
access to the objects in the MPLS LDP MIB.
Example:
Router(config)# end
Example:
Enabling Distributed Cisco Express Forwarding

Perform this task to enable distributed Cisco Express Forwarding.
SUMMARY STEPS
1. enable
25
4. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example:
Router(config)# end
Enabling MPLS Globally

Perform this task to enable MPLS globally.
SUMMARY STEPS
1. enable
3. mpls ip
4. end
DETAILED STEPS

Example:
Router> enable
Example:
26

routed paths for the platform.
Example:
Example:
Router(config)# end
Enabling LDP Globally

Perform this task to enable LDP globally.
SUMMARY STEPS
1. enable
4. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls label protocol ldp Specifies the platform default label distribution protocol.
Example:
Example:
Router(config)# end
Enabling MPLS on an Interface

Perform this task to enable MPLS on an interface.
27
SUMMARY STEPS
1. enable
4. mpls ip
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
routed paths for a particular interface.
Example:
Example:
Enabling LDP on an Interface

Perform this task to enable LDP on an interface.
SUMMARY STEPS
1. enable
3. interface type slot/subslot/port[.subinterface-number
4. mpls label protocol ldp |
5. end
28
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 4 mpls label protocol ldp Specifies the label distribution protocol to be used on a
given interface.
Example:
Router(config-if)# mpls label protocol ldp
Example:
Configuring a VPN Aware LDP MIB

To configure a VPN Aware LDP MIB, perform the following tasks:
• Configuring SNMP Support for a VPN, page 29 (required)
• Configuring an SNMP Context for a VPN, page 30 (required)
• Associating an SNMP VPN Context with SNMPv1 or SNMPv2, page 32 (required)
Configuring SNMP Support for a VPN

Perform this task to configure SNMP support for a Virtual Private Network (VPN) or a remote VPN.
SUMMARY STEPS
1. enable
3. snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}]
4. snmp-server engineID remote ip-address [udp-port udp-port-number] [vrf vrf-name]
engineid-string
5. end
29
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 snmp-server host host-address [traps | informs] Specifies the recipient of an SNMP notification operation
[version {1 | 2c | 3 [auth | noauth | priv]}] and specifies the Virtual Private Network (VPN) routing
community-string [udp-port port]
[notification-type] [vrf vrf-name]
and forwarding (VRF) instance table to be used for the
sending of SNMP notifications.
Example:
Router(config)# snmp-server host example.com
vrf trap-vrf
Step 4 snmp-server engineID remote ip-address Configures a name for the remote SNMP engine on a router.
[udp-port udp-port-number] [vrf vrf-name]
engineid-string
Example:
Router(config)# snmp-server engineID remote
172.16.20.3 vrf traps-vrf
80000009030000B064EFE100
Example:
Router(config)# end
What to Do Next
Proceed to the “Configuring an SNMP Context for a VPN” section on page 30.
Configuring an SNMP Context for a VPN

Perform this task to configure an SNMP context for a VPN. This sets up a unique SNMP context for a
VPN, which allows you to access the VPN’s LDP session information.
SNMP Context
SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated
with a context, that VPN’s specific MIB data exists in that context. Associating a VPN with a context
enables service providers to manage networks with multiple VPNs. Creating and associating a context
with a VPN enables a provider to prevent the users of one VPN from accessing information about users
of other VPNs on the same networking device.
30
VPN Route Distinguishers
A route distinguisher (RD) creates routing and forwarding tables for a VPN. Cisco IOS XE software
adds the RD to the beginning of the customer’s IPv4 prefixes to change them into globally unique
VPN-IPv4 prefixes.
Either the RD is an autonomous system number (ASN)-relative RD, in which case it is composed of an
autonomous system number and an arbitrary number, or it is an IP-address-relative RD, in which case it
is composed of an IP address and an arbitrary number. You can enter an RD in either of these formats:
• 16-bit ASN: your 32-bit number, for example, 101:3.
• 32-bit IP address: your 16-bit number, for example, 192.168.122.15:1.
SUMMARY STEPS
1. enable
3. snmp-server context context-name
4. ip vrf vrf-name
6. context context-name
8. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 snmp-server context context-name Creates and names an SNMP context.
Example:
Router(config)# snmp-server context context1
Step 4 ip vrf vrf-name Configures a Virtual Private Network (VPN) routing and
forwarding instance (VRF) table and enters VRF
configuration mode.
Example:
Router(config)# ip vrf vrf1
Step 5 rd route-distinguisher Creates a VPN route distinguisher.
Example:
31

Step 6 context context-name Associates an SNMP context with a particular VRF.
Example:
Router(config-vrf)# context context1
Step 7 route-target {import | export | both} (Optional) Creates a route-target extended community for a
route-target-ext-community VRF.
Example:
Router(config-vrf)# route-target export
100:1000
Example:
Router(config)# end
What to Do Next
Proceed to the “Associating an SNMP VPN Context with SNMPv1 or SNMPv2” section on page 32.
Associating an SNMP VPN Context with SNMPv1 or SNMPv2

Perform this task to associate an SNMP VPN context with SNMPv1 or SNMPv2. This allows you to
access LDP session information for a VPN using SNMPv1 or SNMPv2.
SNMPv1 or SNMPv2 Security
SNMPv1 and SNMPv2 are not as secure as SNMPv3. SNMP Versions 1 and 2 use plain text communities
and do not perform the authentication or security checks that SNMP Version 3 performs.
To configure the VPN Aware LDP MIB feature when using SNMP Version 1 or SNMP Version 2, you
need to associate a community name with a VPN. This association causes SNMP to process requests
coming in for a particular community string only if they come in from the configured VRF. If the
community string contained in the incoming packet does not have an associated VRF, the packet is
processed only if it came in through a non-VRF interface. This process prevents users outside the VPN
from using a clear text community string to query the VPN data. However, this is not as secure as using
SNMPv3.
SUMMARY STEPS
1. enable
3. snmp-server user username group-name [remote host [udp-port port]] {v1 | v2c | v3 [encrypted]
[auth {md5 | sha} auth-password]} [access access-list]
4. snmp-server group group-name {v1 | v2c | v3 {auth | noauth | priv}} [context context-name]
[read readview] [write writeview] [notify notifyview] [access access-list]
5. snmp-server view view-name oid-tree {included | excluded}
6. snmp-server enable traps [notification-type]
32
7. snmp-server host host-address [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}]

8. snmp mib community-map community-name [context context-name] [engineid engine-id]
[security-name security-name] target-list vpn-list-name
9. snmp mib target list vpn-list-name {vrf vrf-name | host ip-address}
10. no snmp-server trap authentication vrf
11. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 snmp-server user username group-name [remote Configures a new user to an SNMP group.
host [udp-port port]] {v1 | v2c | v3
[encrypted] [auth {md5 | sha} auth-password]}
[access access-list]
Example:
Router(config)# snmp-server user customer1
group1 v1
Step 4 snmp-server group group-name {v1 | v2c | v3 Configures a new SNMP group or a table that maps SNMP
{auth | noauth | priv}} [context context-name] users to SNMP views.
[read readview] [write writeview] [notify
notifyview] [access access-list] • Use the context context-name keyword and argument
to associate the specified SNMP group with a
configured SNMP context.
Example:
Router(config)# snmp-server group group1 v1
context context1 read view1 write view1 notify
view1
Step 5 snmp-server view view-name oid-tree {included | Creates or updates a view entry.
excluded}
Example:
Router(config)# snmp-server view view1
ipForward included
Step 6 snmp-server enable traps [notification-type] Enables all SNMP notifications (traps or informs) available
on your system.
Example:
Router(config)# snmp-server enable traps
33
Configuration Examples for MPLS LDP MIB Version 8 Upgrade

Step 7 snmp-server host host-address [traps | informs] Specifies the recipient of an SNMP notification operation.
community-string [udp-port port]
[notification-type] [vrf vrf-name]
Example:
Router(config)# snmp-server host 10.0.0.1 vrf
customer1 public udp-port 7002
Step 8 snmp mib community-map community-name [context Associates an SNMP community with an SNMP context,
context-name] [engineid engine-id] Engine ID, or security name.
[security-name security-name] target-list
vpn-list-name
Example:
Router(config)# snmp mib community-maps
community1 context context1 target-list
commAVpn
Step 9 snmp mib target list vpn-list-name {vrf Creates a list of target VRFs and hosts to associate with an
vrf-name | host ip-address} SNMP community.
Example:
Router(config)# snmp mib target list commAVpn
vrf vrf1
Step 10 no snmp-server trap authentication vrf (Optional) Disables all SNMP authentication notifications
(traps and informs) generated for packets received on VRF
interfaces.
Example:
Router(config)# no snmp-server trap • Use this command to disable authentication traps only
authentication vrf for those packets on VRF interfaces with incorrect
community associations.
Example:
Router(config) exit
Verifying MPLS LDP MIB Version 8 Upgrade

Perform a MIB walk using your SNMP management tool to verify that the MPLS LDP MIB Version 8
Upgrade feature is functioning.

• MPLS LDP MIB Version 8 Upgrade Examples, page 35
• Configuring a VPN Aware SNMP Context for SNMPv1 or SNMPv2: Example, page 35
34
MPLS LDP MIB Version 8 Upgrade Examples

The following example shows how to enable SNMPv1 and SNMPv2C on the host NMS. The
configuration permits any SNMP agent to access all MPLS LDP MIB objects that have read-only
permission using the community string public.
The following example shows how to allow read-only access to all MPLS LDP MIB objects relating to
access to any of the MPLS LDP MIB objects.
The following example shows how to enable LDP globally and then on an interface:

Configuring a VPN Aware SNMP Context for SNMPv1 or SNMPv2: Example

The following configuration example shows how to configure a VPN Aware SNMP context for the
MPLS LDP MIB Version 8 with SNMPv1 or SNMPv2:
snmp-server context A
snmp-server context B
ip vrf CustomerA
rd 100:110
context A
!
ip vrf CustomerB
rd 100:120
context B
!
description Belongs to VPN A
ip vrf forwarding CustomerA
ip address 10.0.0.0 255.255.0.0
35
description Belongs to VPN B
ip vrf forwarding CustomerB
ip address 10.0.0.1 255.255.0.0
snmp-server user commA grp1A v1

snmp-server user commA grp2A v2c
snmp-server user commB grp1B v1
snmp-server user commB grp2B v2c
snmp-server group grp1A v1 context A read viewA write viewA notify viewA
snmp-server group grp1B v1 context B read viewB write viewB notify viewB
snmp-server view viewA ipForward included

snmp-server view viewA ciscoPingMIB included
snmp-server view viewB ipForward included
snmp-server view viewB ciscoPingMIB included
snmp-server enable traps

snmp-server host 10.0.0.3 vrf CustomerA commA udp-port 7002
snmp-server host 10.0.0.4 vrf CustomerB commB udp-port 7002
snmp mib community-map commA context A target-list commAvpn

! Configures source address validation
snmp mib community-map commB context B target-list commBvpn
! Configures source address validation
snmp mib target list commAvpn vrf CustomerA
! Configures a list of VRFs or from which community commA is valid
snmp mib target list commBvpn vrf CustomerB
! Configures a list of VRFs or from which community commB is valid
The following sections provide references related to the MPLS LDP MIB Version 8 Upgrade feature.
Related Documents
MPLS LDP configuration tasks MPLS Label Distribution Protocol (LDP)
software for the MPLS Traffic Engineering MIB
(MPLS TE MIB)
A description of MPLS differentiated types of service MPLS Quality of Service
across an MPLS network
SNMP configuration Configuring SNMP Support
SNMP Support for VPNs
36
Standards
Standards Title
MIBs
MIBs MIBs Link
• MPLS Label Distribution Protocol MIB To locate and download MIBs for selected platforms,
(draft-ietf-mpls-ldp-mib-08.txt) Cisco IOS XE software releases, and feature sets, use
• SNMP-VACM-MIB Cisco MIB Locator found at the following URL:
The View-based Access Control Model (ACM) MIB for http://www.cisco.com/go/mibs
SNMP
RFCs
RFCs Title
RFC 2233 Interfaces MIB
The LDP implementation supporting the MPLS LDP
MIB fully complies with the provisions of Section 10
of RFC 2026, which, in effect, states that the
implementation of LDP is recommended for network
devices that perform MPLS forwarding along normally
routed paths, as determined by destination-based
routing protocols.
Description Link
37
Feature Information for MPLS LDP MIB Version 8 Upgrade

Table 11 Feature Information for MPLS LDP MIB Version 8 Upgrade

MPLS Label Distribution Protocol MIB Cisco IOS XE The MPLS Label Distribution Protocol (LDP) MIB Version
Release 2.1 8 Upgrade feature enhances the LDP MIB to support the
Internet Engineering Task Force (IETF) draft Version 8.
feature:
• Feature Design of MPLS LDP MIB Version 8 Upgrade,
page 2
• Enhancements in Version 8 of the MPLS LDP MIB,
page 4
• Benefits of MPLS LDP MIB Version 8 Upgrade, page 4
• LDP Entities, page 5
• LDP Sessions and Peers, page 6
• LDP Hello Adjacencies, page 8
• mplsLdpEntityTable, page 11
• mplsLdpEntityConfGenLRTable, page 13
• mplsLdpEntityAtmParmsTable, page 14
• mplsLdpEntityConfAtmLRTable, page 15
• mplsLdpEntityStatsTable, page 15
• mplsLdpPeerTable, page 16
• mplsLdpHelloAdjacencyTable, page 17
• mplsLdpSessionTable, page 17
• mplsLdpAtmSesTable, page 18
• mplsLdpSesStatsTable, page 19
38
Table 11 Feature Information for MPLS LDP MIB Version 8 Upgrade (continued)

• VPN Contexts in MPLS LDP MIB Version 8 Upgrade,
page 19
• SNMP Contexts, page 19
• VPN Aware LDP MIB Sessions, page 20
• VPN Aware LDP MIB Notifications, page 22
• Enabling Distributed Cisco Express Forwarding,
page 25
• Enabling MPLS Globally, page 26
• Enabling LDP Globally, page 27
• Enabling MPLS on an Interface, page 27
• Enabling LDP on an Interface, page 28
• Configuring a VPN Aware LDP MIB, page 29
• Verifying MPLS LDP MIB Version 8 Upgrade, page 34
context, show mpls ldp neighbor, snmp mib
community-map, snmp mib target list, snmp-server
community, snmp-server context, snmp-server enable
traps (MPLS), snmp-server group, snmp-server host,
snmp-server trap authentication vrf.
39
Glossary
Glossary
ATM—Asynchronous Transfer Mode. The international standard for cell relay in which multiple service
advantage of high-speed transmission media, such as E3, SONET, and T3.
downstream-on-demand distribution—A label distribution method in which a downstream label
switch router (LSR) sends a binding upstream only if the upstream LSR requests it.
downstream unsolicited distribution—A label distribution method in which labels are dispersed if a
downstream label switch router (LSR) needs to establish a new binding with its neighboring upstream
LSR. For example, an edge LSR might enable a new interface with another subnet. The LSR then
announces to the upstream router a binding to reach this network.
informs—A type of notification message that is more reliable than a conventional trap notification
message, because the informs message notification requires acknowledgment, but a trap notification
does not.
cells).
label distribution—The techniques and processes that are used by label switch routers (LSRs) to
exchange label binding information for supporting hop-by-hop forwarding along normally routed paths.
hop-by-hop forwarding and the distribution of bindings between labels and network prefixes.
LSP—label switched path. A configured connection between two label switch routers (LSRs) in which
label-switching techniques are used for packet forwarding; also a specific path through an Multiprotocol
Label Switching (MPLS) network.
LSR—label switch router. A Multiprotocol Label Switching (MPLS) node that can forward native Layer 3
packets. The LSR forwards a packet based on the value of a label attached to the packet.
The value of a MIB object can be changed or retrieved by the use of SNMP commands, usually through
a network management system. MIB objects are organized in a tree structure that includes public
MPLS—Multiprotocol Label Switching. A switching method for the forwarding of IP traffic through
the use of a label. This label instructs the routers and the switches in the network where to forward the
packets based on preestablished IP routing information.
MPLS label distribution—A constraint-based routing algorithm for routing label-switched path (LSP)
tunnels.
NMS—network management station. A powerful, well-equipped computer (typically an engineering
workstation) that is used by a network administrator to communicate with other devices in the network.
An NMS is typically used to manage network resources, gather statistics, and perform a variety of
network administration and configuration tasks. In the context of Simple Network Management Protocol
(SNMP), an NMS is a device that performs SNMP queries to the SNMP agent of a managed device to
retrieve or modify information.
notification—A message sent by a Simple Network Management Protocol (SNMP) agent to a network
management station, console, or terminal to indicate that a significant network event has occurred. See
also trap.
40
Glossary
RSVP—Resource Reservation Protocol. A protocol that supports the reservation of resources across an IP
network. Applications running on IP end systems can use RSVP to indicate to other nodes the nature of the
packet streams they want to receive by specifying such items as bandwidth, jitter, and maximum burst.
RTR—Response Time Reporter. A tool that allows you to monitor network performance, network
resources, and applications by measuring response times and availability.
SNMP—Simple Network Management Protocol. A network management protocol used almost
exclusively in TCP/IP networks. SNMP enables a user to monitor and control network devices, manage
configurations, collect statistics, monitor performance, and ensure network security.
SNMP communities—Authentication scheme that enables an intelligent network device to validate
SNMP requests.
SNMPv2c—Version 2c of the Simple Network Management Protocol. SNMPv2c supports centralized
as well as distributed network management strategies and includes improvements in the Structure of
Management Information (SMI), protocol operations, management architecture, and security.
SNMPv3—Version 3 of the Simple Network Management Protocol. Interoperable standards-based
protocol for network management. SNMPv3 provides secure access to devices by a combination of
authenticating and encrypting packets over the network.
TLV—Type-Length-Value. A mechanism used by several routing protocols to carry a variety of
attributes. Cisco Discovery Protocol (CDP), Label Discovery Protocol (LDP), and Border Gateway
Protocol (BGP) are examples of protocols that use TLVs. BGP uses TLVs to carry attributes such as
Network Layer Reachability Information (NLRI), Multiple Exit Discriminator (MED), and local
preference.
management station, console, or terminal to indicate that a significant network event has occurred. Traps
(notifications) are less reliable than inform requests, because the receiver of the trap does not send an
acknowledgment of receipt; furthermore, the sender of the trap cannot determine if the trap was received.
See also notification.
VCC—virtual channel connection. A logical circuit, made up of virtual channel links (VCLs), that
carries data between two endpoints in an ATM network. Sometimes called a virtual circuit connection.
VCI—virtual channel identifier. A 16-bit field in the header of an ATM cell. The VCI, together with the
virtual path identifier (VPI), is used to identify the next network virtual channel link (VCL) as the cell
passes through a series of ATM switches on its way to its final destination.
VCL—virtual channel link. The logical connection that exists between two adjacent switches in an ATM
network.
VPI—virtual path identifier. An 8-bit field in the header of an ATM cell. The VPI, together with the
virtual channel identifier (VCI), is used to identify the next network virtual channel link (VCL) as the
cell passes through a series of ATM switches on its way to its final destination.
VPN—Virtual Private Network. A network that enables IP traffic to use tunneling to travel securely over
a public TCP/IP network.
41
Glossary
countries.
42
MPLS VPN—MIB Support

This document describes the Simple Network Management Protocol (SNMP) agent support in
Cisco IOS XE software for Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN)
management, as implemented in the draft MPLS/BGP Virtual Private Network Management Information
Base Using SMIv2 (draft-ietf-ppvpn-mpls-vpn-mib-05.txt). This document also describes the
cMplsNumVrfRouteMaxThreshCleared notification, which is implemented as part of the proprietary
MIB CISCO-IETF-PPVNP-MPLS-VPN-MIB.

which each feature is supported, see the “Feature Information for MPLS VPN—MIB Support” section on
page 28.
Contents
• Prerequisites for MPLS VPN—MIB Support, page 2
• Restrictions for MPLS VPN—MIB Support, page 2
• Information About MPLS VPN—MIB Support, page 2
• How to Configure MPLS VPN—MIB Support, page 19
• Configuration Examples for MPLS VPN—MIB Support, page 25
• Feature Information for MPLS VPN—MIB Support, page 28
Prerequisites for MPLS VPN—MIB Support
Prerequisites for MPLS VPN—MIB Support

The MPLS VPN MIB agent requires the following:
• SNMP is installed and enabled on the label switching routers.
• MPLS is enabled on the label switching routers.
• Multiprotocol Border Gateway Protocol (BGP) is enabled on the label switching routers.
• Cisco Express Forwarding is enabled on the label switching routers.
Restrictions for MPLS VPN—MIB Support

The following restrictions apply to the PPVPN-MPLS-VPN MIB:
• Configuration of the MIB using the snmp set command is not supported, except for trap-related
objects, such as mplsVpnNotificationEnable and mplsVpnVrfSecIllegalLabelRcvThresh.
• The mplsVpnVrfBgpNbrPrefixTable is not supported.
Information About MPLS VPN—MIB Support

This section contains the following topics:
• MPLS VPN Overview, page 2
• MPLS VPN MIB Overview, page 3
• MPLS VPN MIB and the IETF, page 3
• Capabilities Supported by PPVPN-MPLS-VPN MIB, page 4
• Functional Structure of the PPVPN-MPLS-VPN MIB, page 4
• Supported Objects in PPVPN-MPLS-VPN MIB, page 4
• Unsupported Objects in PPVPN-MPLS-VPN MIB, page 18
MPLS VPN Overview

The MPLS VPN technology allows service providers to offer intranet and extranet VPN services that
directly connect their customers’ remote offices to a public network with the same security and service
levels that a private network offers. Each VPN is associated with one or more VPN routing and
forwarding (VRF) instances. A VRF is created for each VPN defined on a router and contains most of
the information needed to manage and monitor MPLS VPNs: an IP routing table, a derived
Cisco Express Forwarding table, a set of interfaces that use this forwarding table, and a set of rules and
routing protocol parameters that control the information that is included in the routing table.
2
MPLS VPN MIB Overview

The Provider-Provisioned VPN (PPVPN)-MPLS-VPN MIB provides access to MPLS VRF information,
and interfaces included in the VRF, and other configuration and monitoring information.
The PPVPN-MPLS-VPN MIB provides the following benefits:
• A standards-based SNMP interface for retrieving information about critical MPLS VPN events.
• VRF information to assist in the management and monitoring of MPLS VPNs.
• Information, in conjunction with the Interfaces MIB, about interfaces assigned to VRFs.
• Performance statistics for all VRFs on a router.
• The generation and queueing of notifications that call attention to major changes in the operational
status of MPLS VPN enabled interfaces; the forwarding of notification messages to a designated
network management system (NMS) for evaluation and action by network administrators.
• Advanced warning when VPN routing tables are approaching or exceed their capacity.
• Warnings about the reception of illegal labels on a VRF-enabled interface. Such receptions may
indicate misconfiguration or an attempt to violate security.
This document also describes the CISCO-IETF-PPVPN-MPLS-VPN-MIB, which contains the
cMplsNumVrfRouteMaxThreshCleared notification.
MPLS VPN MIB and the IETF

SNMP agent code operating with the PPVPN-MPLS-VPN MIB enables a standardized, SNMP-based
approach to managing MPLS VPNs in Cisco IOS XE software.
The PPVPN-MPLS-VPN MIB is based on the Internet Engineering Task Force draft MIB specification
draft-ietf-ppvpn-mpls-vpn-mib-05.txt, which includes objects describing features that support MPLS
VPN events. This IETF draft MIB, which undergoes revisions from time to time, is becoming a standard.
Accordingly, the Cisco implementation of the PPVPN-MPLS-VPN MIB is expected to track the
evolution of the IETF draft MIB, and may change accordingly.
Some slight differences between the IETF draft MIB and the actual implementation of MPLS VPNs
within Cisco IOS XE software require some minor translations between the PPVPN-MPLS-VPN MIB
and the internal data structures of Cisco IOS XE software. These translations are accomplished by means
of the SNMP agent code. Also, while running as a low priority process, the SNMP agent provides a
management interface to Cisco IOS XE software. SNMP adds little overhead on the normal functions of
the device.
The SNMP objects defined in the PPVPN-MPLS-VPN MIB can be viewed by any standard SNMP
utility. The network administrator can retrieve information in the PPVPN-MPLS-VPN MIB using
standard SNMP get and getnext operations for SNMP v1, v2, and v3.
All PPVPN-MPLS-VPN MIB objects are based on the IETF draft MIB; thus, no Cisco-specific SNMP
application is required to support the functions and operations pertaining to the PPVPN-MPLS-VPN
MIB features.
3
Capabilities Supported by PPVPN-MPLS-VPN MIB

The PPVPN-MPLS-VPN MIB provides you with the ability to do the following:
• Gather routing and forwarding information for MPLS VPNs on a router.
• Expose information in the VRF routing table.
• Gather information on BGP configuration related to VPNs and VRF interfaces and statistics.
• Emit notification messages that signal changes when critical MPLS VPN events occur.
• Enable, disable, and configure notification messages for MPLS VPN events by using extensions to
existing SNMP command-line interface (CLI) commands.
• Specify the IP address of NMS in the operating environment to which notification messages are sent.
• Write notification configurations into nonvolatile memory.
Functional Structure of the PPVPN-MPLS-VPN MIB

The SNMP agent code supporting the PPVPN-MPLS-VPN MIB follows the existing model for such
code in Cisco IOS XE software and is, in part, generated by the Cisco IOS XE software tool set, based
on the MIB source code.
The SNMP agent code, which has a layered structure that is common to MIB support code in
Cisco IOS XE software, consists of four layers:
• Platform-independent layer—This layer is generated primarily by the MIB development
Cisco IOS XE software tool set and incorporates platform- and implementation-independent
functions. The Cisco IOS XE MIB development tool set creates a standard set of files associated
with a MIB.
• Application interface layer—The functions, names, and template code for MIB objects in this layer
are also generated by the MIB development Cisco IOS XE software tool set.
• Application-specific layer—This layer provides an interface between the application interface layer
and the API and data structures layer below and performs tasks needed to retrieve required
information from Cisco IOS XE software, such as searching through data structures.
• API and data structures layer—This layer contains the data structures or APIs within Cisco IOS XE
software that are retrieved or called in order to set or retrieve SNMP management information.
Supported Objects in PPVPN-MPLS-VPN MIB

The PPVPN-MPLS-VPN MIB contains numerous tables and object definitions that provide read-only
SNMP management support for the MPLS VPN feature in Cisco IOS XE software. The
PPVPN-MPLS-VPN MIB conforms to Abstract Syntax Notation One (ASN.1), thus reflecting an
idealized MPLS VPN database.
Using any standard SNMP network management application, you can retrieve and display information
from the PPVPN-MPLS-VPN MIB using GET operations; similarly, you can traverse information in the
MIB database for display using GETNEXT operations.
The PPVPN-MPLS-VPN MIB tables and objects are described briefly in the following sections:
• Scalar Objects, page 5
• MIB Tables, page 6
4
• Notifications, page 15
Objects that are not supported are listed in the “Unsupported Objects in PPVPN-MPLS-VPN MIB”
section on page 18.
Figure 1 shows a simple MPLS VPN configuration. This configuration includes two customer MPLS
VPNs, labeled VPN1 and VPN2, and a simple provider network that consists of two provider edge (PE)
routers, labeled PE1 and PE2, and a provider core router labeled P. Figure 1 shows the following sample
configuration:
• VRF names—VPN1 and VPN2
• Interfaces associated with VRFs—Fet1/0/0, Fet2/0/0, and Atm3/0/0
• Routing protocols—Open Shortest Path First. Link-state (OSPF), Routing Information Protocol
(RIP), and internal Border Gateway Protocol (IBGP)
• Routes associated with VPN1—10.1.0.0, 10.2.0.0, and 10.3.0.0
• Routes associated with VPN2—172.16.1.0 and 172.16.2.0
• Routes associated with the provider network—192.168.1.0, 192.168.2.0, and 192.168.3.0
This configuration is used in this document to explain MPLS VPN events that are monitored and
managed by the PPVPN-MPLS-VPN MIB.
Figure 1 Sample MPLS VPN Configuration
VPN1 VPN1
CE VPN1
10.1.0.0 OSPF
VPN1, Fet1/0/0 CE VPN1
OSPF 192.168.2.0 10.3.0.0
CE VPN1
VPN1, Fet2/0/0 IBGP IBGP
10.2.0.0 172.16.2.0
PE1 P PE2
192.168.1.0 192.168.3.0
RIP
CE VPN2 VPN2, Atm3/0/0
172.16.1.0 CE VPN2
RIP
193011
VPN2
VPN2
Scalar Objects
Table 1 shows the supported PPVPN-MPLS-VPN MIB scalar objects.
Table 1 PPVPN-MPLS-VPN MIB Scalar Objects
MIB Object Function

mplsVpnConfiguredVrfs The number of VRFs configured on the router, including VRFs recently deleted.
mplsVpnActiveVrfs The number of VRFs that are active on the router. An active VRF is assigned to
at least one interface that is in the operationally up state.
mplsVpnConnectedInterfaces The total number of interfaces assigned to any VRF.
5
Table 1 PPVPN-MPLS-VPN MIB Scalar Objects (continued)
MIB Object Function

mplsVpnNotificationEnable A value that indicates whether all the PPVPN-MPLS-VPN MIB notifications
are enabled:
• Setting this object to true enables all notifications defined in the
PPVPN-MPLS-VPN MIB.
• Setting this object to false disables all notifications defined in the MIB.
This is one of the few objects that is writable.
mplsVpnVrfConfMaxPossibleRoutes A number that indicates the amount of routes that this router is capable of
storing. This value cannot be determined because it is based on the amount of
available memory in the system. Therefore, this object is set to zero (0).
MIB Tables
The PPVPN-MPLS-VPN MIB implementation supports the following tables described in this section:
• mplsVpnVrfTable, page 6
• mplsVpnInterfaceConfTable, page 8
• mplsVpnVrfRouteTargetTable, page 9
• mplsVpnVrfBgpNbrAddrTable, page 11
• mplsVpnVrfSecTable, page 12
• mplsVpnVrfPerfTable, page 12
• mplsVpnVrfRouteTable, page 12
mplsVpnVrfTable
Entries in the VRF configuration table (mplsVpnVrfTable) represent the VRFs that are defined on the
router. This includes recently deleted VRFs. The information in this table is also displayed with the show
ip vrf command.
Each VRF is referenced by its VRF name (mplsVpnVrfName).
Table 2 lists the MIB objects and their functions for this table.
Table 2 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfTable
MIB Object Function

mplsVpnVrfName The name associated with this VRF. When this object is used as an index to a
table, the first octet is the string length, and subsequent octets are the ASCII codes
of each character. For example, “vpn1” is represented as 4.118.112.110.49.
mplsVpnVrfDescription The description of the VRF. This is specified with the following configuration
command:
Router(config)# ip vrf vrf-name
Router(config-vrf)# description vrf-description
6
Table 2 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfTable (continued)
MIB Object Function

mplsVpnVrfRouteDistinguisher The route distinguisher for this VRF. This is specified with the following
configuration command:
Router(config-vrf)# rd route-distinguisher
mplsVpnVrfCreationTime The value of the sysUpTime when this VRF entry was created.
mplsVpnVrfOperStatus The operational status of this VRF. A VRF is up (1) when at least one interface
associated with the VRF is up. A VRF is down (2) when:
• No interfaces exist whose ifOperStatus = up (1).
• No interfaces are associated with this VRF.
mplsVpnVrfActiveInterfaces The number of interfaces assigned to this VRF that are operationally up.
mplsVpnVrfAssociatedInterfaces The number of interfaces assigned to this VRF, independent of the operational
status.
mplsVpnVrfConfMidRouteThreshold The middle route threshold. If the amount of routes in the VRF crosses this
threshold, an mplsNumVrfRouteMidThreshExceeded notification is sent (if
notifications are enabled and configured). You can set this value in
configuration mode as a percentage of the maximum with the maximum routes
limit {warn-threshold | warn-only} command, as follows:
Router(config-vrf)# maximum routes 1000 50
The middle or warn threshold is set for VRF vpn1 as 50 percent of the
maximum route threshold.
The following command sets a middle threshold of 1000 routes. An
mplsNumVrfRouteMidThreshExceeded notification is sent when this threshold
is exceeded. However, additional routes are still allowed because a maximum
route threshold is not set with this command.
Router(config-vrf)# maximum routes 1000 warn-only
mplsVpnVrfConfHighRouteThreshold The maximum route threshold. If the number of routes in the VRF crosses this
threshold, an mplsNumVrfRouteMaxThreshExceeded notification is sent (if
notifications are enabled and configured). You can set this value in
configuration mode with the maximum routes limit {warn-threshold |
warn-only} command as follows:
The maximum route threshold is set for 1000 routes for VRF vpn2 with a
middle or warn threshold of 75 percent of this threshold.
mplsVpnVrfConfMaxRoutes This value is the same as the mplsVpnVrfConfHighRouteThreshold.
mplsVpnVrfConfLastChanged The value of sysUpTime when the configuration of the VRF changes or
interfaces are assigned or unassigned from the VRF.
Note This object is updated only when values in this table change.
7
Table 2 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfTable (continued)
MIB Object Function

mplsVpnVrfConfRowStatus Read-only implementation. This object normally reads “active (1),” but may
read “notInService (2),” if a VRF was recently deleted.
mplsVpnVrfConfStorageType Read-only implementation. This object always reads “volatile (2).”
mplsVpnInterfaceConfTable
In Cisco IOS XE software, a VRF is associated with one MPLS VPN. Zero or more interfaces can be
associated with a VRF. A VRF uses an interface that is defined in the ifTable of the Interfaces Group of
MIB II (IFMIB). The IFMIB defines objects for managing interfaces. The ifTable of this MIB contains
information on each interface in the network. The mplsVpnInterfaceConfTable associates a VRF from
the mplsVpnVrfTable with a forwarding interface from the ifTable. Figure 2 shows the relationship
between VRFs and interfaces defined in the ifTable and the mplsVpnInterfaceConfTable.
Figure 2 VRFs, the Interfaces MIB, and the mplsVpnInterfaceConfTable
ifTable
mplsL3VpnVrfTable
ifName
VPN1
ifIndex Value
VPN2 5 Et1
6 Et2
A mplsL3VpnVrfName
B mplsL3VpnIfConfIndex 10 At3/0
mplsL3VpnIfConfTable
A B
VPN1 5
VPN1 6
VPN2 10
Use in Cisco IOS software

Fet1/0/0
VPN1
Note: The mplsL3VpnVrfName is actually an Fet2/0/0 Interfaces
VRFs
octet string that represents the string length
(4) and the ASCII codes for each character. VPN2 Atm3/0/0
193010
For example, VPN1 is represented as

4.86.80.78.49.
Entries in the VPN interface configuration table (mplsVpnInterfaceConfTable) represent the interfaces
that are assigned to each VRF. The information available in this table is also displayed with the
show ip vrf command.
The mplsVpnInterfaceConfTable shows how interfaces are assigned to VRFs. A label switch router
(LSR) creates an entry in this table for every interface capable of supporting MPLS VPNs.
8
The mplsVpnInterfaceConfTable is indexed by the following:

• mplsVpnVrfName—The VRF name
• mplsVpnInterfaceConfIndex—An identifier that is the same as the ifIndex from the Interface MIB
of the interface assigned to the VRF
Table 3 PPVPN-MPLS-VPN MIB Objects for the mplsVpnInterfaceConfTable
MIB Object Function

mplsVpnInterfaceConfIndex Provides the interface MIB ifIndex of this interface that is assigned to a VRF.
mplsVpnInterfaceLabelEdgeType Indicates whether the interface is a provider edge interface (1) or a customer
edge interface (2).
This value is always providerEdge (1) because in Cisco IOS XE software,
customerEdge interfaces are not assigned to VRFs and do not appear in this
table.
mplsVpnInterfaceVpnClassification Specifies what type of VPN this interface is providing: carrier supporting
carrier (CSC) (1), enterprise (2), or InterProvider (3).
This value is set to enterprise (2) if MPLS is not enabled and to carrier
supporting carrier (1) if MPLS is enabled on this interface.
mplsVpnInterfaceVpnRouteDistProtocol Indicates the route distribution protocols that are being used to redistribute
routes with BGP on this interface: BGP (2), OSPF (3), or RIP (4).
In Cisco IOS XE software, router processes are defined and redistributed on a
per-VRF basis, not per-interface. Therefore, all interfaces assigned to the same
VRF have the same value for this object.
mplsVpnInterfaceConfStorageType Read-only implementation. This object always reads “volatile (2).”
mplsVpnInterfaceConfRowStatus Read-only implementation. This object normally reads “active (1),” but may
mplsVpnVrfRouteTargetTable
The route target table (mplsVpnVrfRouteTargetTable) describes the route target communities that are
defined for a particular VRF. An LSR creates an entry in this table for each target configured for a VRF
supporting an MPLS VPN instance.
The distribution of VPN routing information is controlled through the use of VPN route target
communities, implemented by BGP extended communities. Distribution of VPN routing information
works as follows:
• When a VPN route learned from a customer edge (CE) router is injected into BGP, a list of VPN
route target extended community attributes is associated with it. Typically the list of route target
community values is set from an export list of route targets associated with the VRF from which the
route was learned.
• An import list of route target extended communities is associated with each VRF. The import list
defines route target extended community attributes a route must have for the route to be imported
into the VRF. For example, if the import list for a particular VRF includes route target communities
A, B, and C, then any VPN route that carries any of those route target extended communities—A,
B, or C—is imported into the VRF.
9
Figure 3 shows a sample configuration and its relationship to an mplsVpnVrfRouteTargetTable. A route

target table exists on each PE router. Routers with route distinguishers (RDs) 100:1, 100:2, and 100:3
are shown in the sample configuration. Routers with RDs 100:4 and 100:5 are not shown in Figure 3, but
are included in the route targets for PE2 and in the mplsVpnVrfRouteTargetTable.
Figure 3 Sample Configuration and the mplsVpnVrfRouteTargetTable
VPN1 VPN1
PE2
PE1
VPN2 100:1 100:2 VPN2
PE3
100:3
A VRF
B mplsL3VpnVrfRTIndex
C mplsL3VpnVrfRTType VRF VPN1
D mplsL3VpnVrfRT import 100:1
export 100:1
import 100:2
mplsL3VpnVrfRTTable
export 100:2
import 100:3
A B C D
export:100:3
VPN1 1 both 100:1 import 100:4
export 100:5
VPN1 2 both 100:2
VRF VPN2
VPN1 4 import 100:4 export 100:1
import 100:2
VPN1 5 export 100:5 export 100:2
export 100:3
VPN2 2 both 100:2
62825
VPN2 3 both 100:3
Note: The mplsL3VpnVrfName is actually an

octet string that represents the string length
(4) and the ASCII codes for each character.
4.86.80.78.49.
The mplsVpnVrfRouteTargetTable shows the import and export route targets for each VRF. The table is
indexed by the following:
• mplsVpnVrfRouteTargetIndex—The route target entry identifier
• mplsVpnVrfRouteTargetType—A value specifying whether the entry is an import route target, export
route target, or is defined as both
10
Table 4 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfRouteTargetTable
MIB Object Function

mplsVpnVrfRouteTargetIndex A value that defines each route target’s position in the table.
mplsVpnVrfRouteTargetType Determines which type of route target the entry represents: import (1),
export (2), or both (3).
mplsVpnVrfRouteTarget Determines the route distinguisher for this target.
mplsVpnVrfRouteTargetDescr Description of the route target. This object is not supported. Therefore, the
object is the same as mplsVpnVrfRouteTarget.
mplsVpnVrfRouteTargetRowStatus Read-only implementation. This object normally reads “active (1),” but may
mplsVpnVrfBgpNbrAddrTable
The BGP neighbor address table (mplsVpnVrfBgpNbrAddrTable) represents the MPLS external Border
Gateway Protocol (eBGP) neighbors that are defined for a particular VRF. An LSR creates an entry for
every BGP neighbor that is defined in the VRF’s address-family.
The mplsVpnVrfBgpNbrAddrTable is indexed by the following:
• mplsVpnInterfaceConfIndex—An identifier that is the same as the ifIndex from the Interface MIB
of the interface assigned to the VRF
• mplsVpnVrfBgpNbrIndex—The IP address of the neighbor
Table 5 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfBgpNbrAddrTable
MIB Object Function

mplsVpnVrfBgpNbrIndex The IPv4 address of the eBGP neighbor.
mplsVpnVrfBgpNbrRole The role of this eBGP neighbor: customer edge (1) or provider edge (2). If the
object mplsVpnInterfaceVpnClassification is CSC, then this value is provider
edge (2); otherwise, this value is customer edge (1).
mplsVpnVrfBgpNbrType Address type of this eBGP neighbor. The MIB supports only IPv4 (1).
Therefore, this object returns “ipv4 (1).”
mplsVpnVrfBgpNbrAddr IP address of the eBGP neighbor.
mplsVpnVrfBgpNbrRowStatus Read-only implementation. This object normally reads “active (1),” but may
read “notInService (2)” if a VRF was recently deleted.
mplsVpnVrfBgpNbrStorageType Read-only implementation. This object always reads “volatile (2).”
11
mplsVpnVrfSecTable
The VRF security table (mplsVpnVrfSecTable) provides information about security for each VRF. An
LSR creates an entry in this table for every VRF capable of supporting MPLS VPN.
The mplsVpnVrfSecTable augments the mplsVpnVrfTable and has the same indexing.
Table 6 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfSecTable
MIB Object Function

mplsVpnVrfSecIllegalLabelViolations The number of illegally received labels on a VRF interface. Only illegal labels
are counted by this object, therefore the object only applies to a VRF interface
that is MPLS enabled (CSC situation).
This counter is incremented whenever a label is received that is above or below
the valid label range, not in the global label forwarding table, or is received on
the wrong VRF (that is, table IDs for the receiving interface and appropriate
VRF label forwarding table do not match).
mplsVpnVrfSecIllegalLabelRcvThresh Notification threshold for illegal labels received on this VRF. When the number
of illegal labels received on this interface crosses this threshold, an
mplsNumVrfSecIllegalLabelThreshExceeded notification is sent (if the
notification is enabled and configured).
This object is one of the few in this MIB agent that supports the SNMP SET
operation, which allows you to change this value.
mplsVpnVrfPerfTable
The VRF performance table (mplsVpnVrfPerfTable) provides statistical performance information for
each VRF. An LSR creates an entry in this table for every VRF capable of supporting MPLS VPN.
The mplsVpnVrfPerfTable augments the mplsVpnVrfTable and has the same indexing.
Table 7 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfPerfTable
MIB Objects Functions

mplsVpnVrfPerfRoutesAdded The number of routes added to this VRF over the course of its lifetime.
mplsVpnVrfPerfRoutesDeleted The number of routes removed from this VRF.
mplsVpnVrfPerfCurrNumRoutes The number of routes currently defined within this VRF.
mplsVpnVrfRouteTable
The VRF routing table (mplsVpnVrfRouteTable) provides the IP routing table information for each VRF.
The information available in this table can also be accessed with the show ip route vrf vrf-name command.
For example, for PE1 in Figure 1:
• With the show ip route vrf vpn1 command, you would see results like the following:
Router# show ip route vrf vpn1
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

12

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
!
!
B 10.3.0.0 [200/0] via 192.168.2.1, 04:36:33
C 10.1.0.0/16 is directly connected, FastEthernet1
C 10.2.0.0/16 [200/0] directly connected FastEthernet2, 04:36:33
• With the show ip route vrf vpn2 command, you would see results like the following:
Router# show ip route vrf vpn2
Codes: C - connected, S - static, I - IGRP, R - RIP, M - mobile, B - BGP

E1 - OSPF external type 1, E2 - OSPF external type 2, E - EGP
i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
!
!
B 172.16.2.0 [200/0] via 192.168.2.1, 04:36:33
C 172.16.1.0 is directly connected, ATM 3/0
Figure 4 shows the relationship of the routing tables, the VRFs, and the mplsVpnVrfRouteTable. You
can display information about the VPN1 and VPN2 route tables using the show ip route vrf vrf-name
command. The global route table is the same as ipCidrRouteTable in the IP-FORWARD-MIB. You can
display information about the global route table with the show ip route command.
13
Figure 4 Route Table, VRFs, and the mplsVpnVrfRouteTable
A mplsL3VpnVrfName Route Tables

VPN1
mplsL3VpnVrfTable B mplsL3VpnVrfRteInetCidrDest
10.1.0.0
VPN1 mplsL3VpnVrfRteTable
10.2.0.0
VPN2 A B
10.3.0.0
VPN1 10.1.0.0
VPN1 10.2.0.0
VPN2
VPN1 10.3.0.0
VPN2 172.16.1.0 172.16.1.0
VPN2 172.16.2.0 172.16.2.0
Global Routing Table
192.168.1.0
Note: The mplsL3VpnVrfName is actually an
octet string that represents the string length 192.168.2.0
(4) and the ASCII codes for each character.
62824
192.168.3.0
4.86.80.78.49.
(ipCidrRouteTable)
An LSR creates an entry in this table for every route that is configured, either dynamically or statically,
within the context of a specific VRF capable of supporting MPLS VPN.
The mplsVpnVrfRouteTable is indexed by the following:
• mplsVpnVrfName—The VRF name, which provides the VRF routing context
• mplsVpnVrfRouteDest—The IP destination address
• mplsVpnVrfRouteMask—The IP destination mask
• mplsVpnVrfRouteTos—The IP header ToS bits
• mplsVpnVrfRouteNextHop—The IP address of the next hop for each route entry
Note The ToS bits are not supported and, therefore, are always 0.
Table 8 lists the MIB objects and their functions for the mplsVpnVrfRouteTable. This table represents
VRF-specific routes. The global routing table is the ipCidrRouteTable in the IP-FORWARD-MIB.
Table 8 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfRouteTable
MIB Object Function

mplsVpnVrfRouteDest The destination IP address defined for this route.
mplsVpnVrfRouteDestAddrType The address type of the IP destination address (mplsVpnVrfRouteDest). This
MIB implementation supports only IPv4 (1). Therefore, this object has a value
of “ipv4 (1).”
mplsVpnVrfRouteMask The destination IP address mask defined for this route.
14
Table 8 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfRouteTable (continued)
MIB Object Function

mplsVpnVrfRouteMaskAddrType The address type of the destination IP address mask. This MIB implementation
supports only IPv4 (1). Therefore, this object has a value of “ipv4 (1).”
mplsVpnVrfRouteTos The ToS bits from the IP header for this route. Cisco IOS XE software supports
only ToS bits of zero. Therefore, the object is always 0.
mplsVpnVrfRouteNextHop The next hop IP address defined for this route.
mplsVpnVrfRouteNextHopAddrType The address type of the next hop IP address. This MIB implementation only
supports only IPv4 (1). Therefore, this object has a value of “ipv4 (1).”
mplsVpnVrfRouteIfIndex The interface MIB ifIndex for the interface through which this route is
forwarded. The object is 0 if no interface is defined for the route.
mplsVpnVrfRouteType Defines if this route is a local or remotely defined route.
mplsVpnVrfRouteProto The routing protocol that was responsible for adding this route to the VRF.
mplsVpnVrfRouteAge The number of seconds since this route was last updated.
mplsVpnVrfRouteInfo A pointer to more information from other MIBs. This object is not supported
and always returns “nullOID (0.0).”
mplsVpnVrfRouteNextHopAS The autonomous system number of the next hop for this route. This object is not
supported and is always 0.
mplsVpnVrfRouteMetric1 The primary routing metric used for this route.
mplsVpnVrfRouteMetric2 Alternate routing metrics used for this route. These objects are supported only
mplsVpnVrfRouteMetric3 for Cisco Interior Gateway Routing Protocol (IGRP) and Cisco Enhanced
mplsVpnVrfRouteMetric4 Interior Gateway Routing Protocol (EIGRP). These objects display the
mplsVpnVrfRouteMetric5 bandwidth metrics used for the route. Otherwise, these values are set to –1.
mplsVpnVrfRouteRowStatus Read-only implementation. This object normally reads “active (1),” but may
mplsVpnVrfRouteStorageType Read-only implementation. This object always reads “volatile (2).”
Notifications
This section provides the following information about supported PPVPN-MPLS-VPN MIB
notifications:
• PPVPN-MPLS-VPN MIB Notification Events, page 15
• Notification Specification, page 17
• Monitoring the PPVPN-MPLS-VPN MIB Notifications, page 18
PPVPN-MPLS-VPN MIB Notification Events
The following notifications of the PPVPN-MPLS-VPN MIB are supported:

• mplsVrfIfUp—Sent to an NMS when an interface comes up and is assigned a VRF instance.
• mplsVrfIfDown—Generated and sent to the NMS when a VRF is removed from an interface or the
interface transitions from an operationally “up” state to a “down” state.
15
• mplsNumVrfRouteMidThreshExceeded—Generated and sent when the middle (warning) threshold

is crossed. You can configure this threshold in the CLI by using the following commands:
Router(config-vrf)# maximum routes limit warn-threshold (% of max)
The warn-threshold argument is a percentage of the maximum routes specified by the limit
argument. You can also configure a middle threshold with the following command, in which the limit
argument represents the warning threshold:
Router(config-vrf)# maximum routes limit warn-only
This notification is sent to the NMS only at the time the threshold is exceeded. (See Figure 5 for a
comparison of the warning and maximum thresholds.) Whenever the number of routes falls below
this threshold and exceeds the threshold again, a notification is sent to the NMS.
• MplsNumVrfRouteMaxThreshExceeded—Generated and sent when you attempt to create a route
on a VRF that already contains the maximum number of routes as defined by the limit argument of
the maximum routes commands:
Router(config-vrf)# maximum routes limit warn-threshold (% of max)
A trap notification is sent to the NMS when you attempt to exceed the maximum threshold. Another
MplsNumVrfRouteMaxThreshExceeded notification is not sent until the number of routes falls
below the maximum threshold and reaches the maximum threshold again. (See Figure 5 for an
example of how this notification works and for a comparison of the maximum and warning
thresholds.)
Note The maximum routes command sets the number of routes for a VRF. You cannot exceed the
number of routes in the VRF that you set with the maximum routes limit warn-threshold
command.
Prior to implementation of the PPVPN-MPLS-VPN MIB, you were not notified when this
threshold (or the warning threshold) was reached.
• mplsNumVrfSecIllegalLabelThreshExceeded—Generated and sent when the number of illegal

labels received on a VRF interface exceeds the threshold mplsVpnVrfSecIllegalLabelRcvThresh.
This threshold is defined with a value of 0. Therefore, a notification is sent when the first illegal
label is received on a VRF. Labels are considered illegal if they are outside of the valid label range,
do not have a Label Forwarding Information Base (LFIB) entry, or the table ID of the message does
not match the table ID for the label in the LFIB.
CISCO-IETF-PPVPN-MPLS-VPN MIB Notification Events
The following notification of the CISCO-IETF-PPVPN-MPLS-VPN MIB is supported in Cisco IOS XE:
• cMplsNumVrfRouteMaxThreshCleared—Generated and sent when the number of routes on a VRF
attempts to exceed the maximum number of routes and then drops below the maximum number of
routes. If you attempt to create a route on a VRF that already contains the maximum number of
routes, the mplsNumVrfRouteMaxThreshExceeded notification is sent (if enabled). When you
remove routes from the VRF so that the number of routes falls below the set limit, the
16
cMplsNumVrfRouteMaxThreshCleared notification is sent. You can clear all routes from the VRF
by using the clear ip route vrf command. (See Figure 5 to see when the
cMplsNumVrfRouteMaxThreshCleared notification is sent.)
Figure 5 Comparison of Warning and Maximum Thresholds
Maximum threshold
Maximum threshold-1
Number of routes
Warning (middle) threshold

(as a percentage of the maximum threshold)
Time
= Number of routes created in VRF

= Warning threshold exceeded
= Maximum threshold limit reached
59562
= Maximum threshold limit cleared
= Notification sent to NMS
For information on the Cisco IOS XE CLI commands for configuring PPVPN-MPLS-VPN MIB
notifications that are to be sent to an NMS, see the “How to Configure MPLS VPN—MIB Support”
section on page 19 and the “Feature Information for MPLS VPN—MIB Support” section on page 28.
Notification Specification
In an SNMPv1 notification, each VPN notification has a generic type identifier and an
enterprise-specific type identifier for identifying the notification type.
• The generic type for all VPN notifications is “enterpriseSpecific” because this is not one of the
generic notification types defined for SNMP.
• The enterprise-specific type is identified as follows:
– 1 for mplsVrfIfUp
– 2 for mplsVrfIfDown
– 3 for mplsNumVrfRouteMidThreshExceeded
– 4 for mplsNumVrfRouteMaxThreshExceeded
– 5 for mplsNumVrfSecIllegalLabelThreshExceeded
– 6 for cMplsNumVrfRouteMaxThreshCleared
17
In SNMPv2, the notification type is identified by an SnmpTrapOID varbind (variable binding consisting
of an object identifier [OID] type and value) included within the notification message.
Each notification also contains two additional objects from the PPVPN-MPLS-VPN MIB. These objects
provide additional information about the event, as follows:
• The VRF interface up/down notifications provide additional
variables—mplsVpnInterfaceConfIndex and mplsVpnVrfName—in the notification. These variables
describe the SNMP interface index and the VRF name, respectively.
• The mid and max threshold notifications include the mplsVpnVrfName variable (VRF name) and the
mplsVpnVrfPerfCurrNumRoutes variable that indicates the current number of routes within the
VRF.
• The illegal label notification includes the mplsVpnVrfName variable (VRF name) and the
mplsVpnVrfSecIllegalLabelViolations variable that maintains the current count of illegal labels on a
VPN.
Monitoring the PPVPN-MPLS-VPN MIB Notifications
When PPVPN-MPLS-VPN MIB notifications are enabled (see the snmp-server enable traps mpls vpn
command in the Cisco IOS Multiprotocol Label Switching Command Reference), notification messages
relating to specific MPLS VPN events within Cisco IOS XE software are generated and sent to a
specified NMS in the network. Any utility that supports SNMPv1 or SNMPv2 notifications can receive
notification messages. X-REF?
To monitor PPVPN-MPLS-VPN MIB notification messages, log in to an NMS that supports a utility that
displays SNMP notifications, and start the display utility.
Unsupported Objects in PPVPN-MPLS-VPN MIB

The following objects from the mplsVpnVrfBgpPathAttrTable are not supported with SNMP
management for MPLS VPN features in Cisco IOS XE software:
• mplsVpnVrfBgpPathAttrPeer
• mplsVpnVrfBgpPathAttrIpAddrPrefixLen
• mplsVpnVrfBgpPathAttrIpAddrPrefix
• mplsVpnVrfBgpPathAttrOrigin
• mplsVpnVrfBgpPathAttrASPathSegment
• mplsVpnVrfBgpPathAttrNextHop
• mplsVpnVrfBgpPathAttrMultiExitDisc
• mplsVpnVrfBgpPathAttrLocalPref
• mplsVpnVrfBgpPathAttrAtomicAggregate
• mplsVpnVrfBgpPathAttrAggregatorAS
• mplsVpnVrfBgpPathAttrAggregatorAddr
• mplsVpnVrfBgpPathAttrCalcLocalPref
• mplsVpnVrfBgpPathAttrBest
• mplsVpnVrfBgpPathAttrUnknown
18
How to Configure MPLS VPN—MIB Support

This section describes configuration tasks for the MPLS VPN—MIB Support feature. Each task in the
list is identified as either required or optional.
• Configuring the SNMP Community, page 19 (required)
• Configuring the Router to Send SNMP Traps, page 20 (required)
• Configuring Threshold Values for MPLS VPN—SNMP Notifications, page 23 (required)
The MPLS VPN notifications are enabled or disabled using the extended CLI commands (see the
“Feature Information for MPLS VPN—MIB Support” section on page 28).
Configuring the SNMP Community

An SNMP community string defines the relationship between the SNMP manager and the agent. The
community string acts like a password to regulate access to the agent on the router.
Perform this task to configure an SNMP community.
SUMMARY STEPS
1. enable
2. show running-config [options]
4. snmp-server community string [view view-name] [ro | rw] [acl-number]
5. do copy running-config startup-config
6. exit
7. show-running config [interface | map-class]
DETAILED STEPS

Example:
Router> enable
Step 2 show running-config [options] Displays the running configuration to determine if an
Example: • If no SNMP information is displayed, continue with the
Router# show running-config next step. If any SNMP information is displayed, you
can modify the information or change it as needed.
Example:
19

Step 4 snmp-server community string [view view-name] Sets up the community access string to permit access to the
[ro | rw] [acl-number] SNMP protocol.
• The string argument acts like a password and permits
Example: access to the SNMP protocol.
ro • The view view-name keyword argument pair specifies
the name of a previously defined view. The view
defines the objects available to the community.
• The ro keyword specifies read-only access. Authorized
management stations are only able to retrieve MIB
objects.
• The rw keyword specifies read/write access.
Authorized management stations are able to both
retrieve and modify MIB objects.
• The acl-number argument is an integer from 1 to 99 that
specifies an access list of IP addresses that are allowed
to use the community string to gain access to the SNMP
agent.
Step 5 do copy running-config startup-config Saves the modified configuration to NVRAM as the startup
configuration file.
Example: • The do command allows you to perform EXEC level
Router(config)# do copy running-config commands in configuration mode.
startup-config
Step 6 exit Returns to privileged EXEC mode.
Example:
Step 7 show running-config [options] (Optional) Displays the configuration information currently
on the router, the configuration for a specific interface, or
map-class information.
Example:
Router# show-running config | include • Use the show running-config command to check that
smnp-server the snmp-server statements appear in the output.
Configuring the Router to Send SNMP Traps

Perform this task to configure the router to sendm SNMP traps to a host.
The snmp-server host command specifies which hosts receive traps. The snmp-server enable traps
command globally enables the trap production mechanism for the specified traps.
For a host to receive a trap, an snmp-server host command must be configured for that host, and,
generally, the trap must be enabled globally through the snmp-server enable traps command.
Note Although you can set the community-string argument using the snmp-server host command by itself,
we recommend you define this string using the snmp-server community command before using the
snmp-server host command.
20
SUMMARY STEPS
1. enable
3. snmp-server host host-addr [traps | informs] [version {1 | 2c | 3 [auth | noauth | priv]}]
4. snmp-server enable traps mpls vpn [illegal-label] [max-thresh-cleared] [max-threshold]
[mid-threshold] [vrf-down] [vrf-up]
5. end
DETAILED STEPS

Example:
Router> enable
Example:
21

Step 3 snmp-server host host-addr [traps | informs] Specifies the recipient of an SNMP notification operation.
community-string [udp-port port] • The host-addr argument specifies the name or Internet
[notification-type] [vrf vrf-name] address of the host (the targeted recipient).
• The traps keyword sends SNMP traps to this host. This
Example: is the default.
Router(config)# snmp-server host 172.20.2.160
• The informs keyword sends SNMP informs to this
traps comaccess mpls-vpn
host.
• The version keyword specifies the version of the
SNMP used to send the traps. Version 3 is the most
secure model, because it allows packet encryption with
the priv keyword. If you use the version keyword, you
must specify one of the following:
– 1 —SNMPv1. This option is not available with
informs.
– 2c —SNMPv2C.
– 3 —SNMPv3. The following three optional
keywords can follow the version 3 keyword (auth,
noauth, priv).
• The community-string argument is a password-like
community string sent with the notification operation.
• The udp-port port keyword argument pair names the
User Datagram Protocol (UDP) port of the host to use.
The default is 162.
• The notification-type argument specifies the type of
notification to be sent to the host. If no type is specified,
all notifications are sent.
• The vrf vrf-name keyword argument pair specifies the
VRF table that should be used to send SNMP
notifications.
22

Step 4 snmp-server enable traps mpls vpn Enables the router to send MPLS VPN-specific SNMP
[illegal-label][max-thresh-cleared] notifications (traps and informs).
[max-threshold][mid-threshold][vrf-down]
[vrf-up] • The illegal-label keyword enables a notification for any
illegal labels received on a VRF interface. Labels are
illegal if they are outside the legal range, do not have an
Example:
LFIB entry, or do not match table IDs for the label.
vpn vrf-down vrf-up • The max-thresh-cleared keyword enables a
notification when the number of routes falls below the
limit after the maximum route limit was attempted.
• The max-threshold keyword enables a notification that
a route creation attempt was unsuccessful because the
maximum route limit was reached. Another
MplsNumVrfRouteMaxThreshExceeded notification is
not sent until the number of routes falls below the
maximum threshold and reaches the maximum
threshold again. The max-threshold value is determined
by the maximum routes command in VRF
configuration mode.
• The mid-threshold keyword enables a notification of a
warning that the number of routes created has crossed
the warning threshold. This warning is sent only at the
time the warning threshold is exceeded.
• The vrf-down keyword enables a notification for the
removal of a VRF from an interface or the transition of
an interface to the down state.
• The vrf-up keyword enables a notification for the
assignment VRF to an interface that is operational or
for the transition of a VRF interface to the operationally
up state.
Example:
Router(config)# end
Configuring Threshold Values for MPLS VPN—SNMP Notifications

Perform this task to configure the following threshold values for MPLS VPN—SNMP notifications:
• The mplsNumVrfRouteMidThreshExceeded notification event is generated and sent when the
middle (warning) threshold is crossed. You can configure this threshold in the CLI by using the
maximum routes command in VRF configuration mode. This notification is sent to the NMS only
at the time the threshold is exceeded. Whenever the number of routes falls below this threshold and
exceeds the threshold again, a notification is sent to the NMS.
• The mplsNumVrfRouteMaxThreshExceeded notification event is generated and sent when you
attempt to create a route on a VRF that already contains the maximum number of routes as defined
by the maximum routes command in VRF configuration mode. A trap notification is sent to the
23
NMS when you attempt to exceed the maximum threshold. Another

MplsNumVrfRouteMaxThreshExceeded notification is not sent until the number of routes falls
below the maximum threshold and reaches the maximum threshold again.
See Figure 5 for an example of how this notification works and for a comparison of the maximum
and warning thresholds.
Note The maximum routes command sets the number of routes for a VRF. You cannot exceed the
number of routes in the VRF that you set with the maximum routes limit warn-threshold
command.
Prior to the implementation of the PPVPN-MPLS-VPN MIB, you were not notified when this
threshold (or the warning threshold) was reached.
SUMMARY STEPS
1. enable
3. ip vrf vrf-name
4. maximum routes limit {warn-threshold | warn-only}
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip vrf vrf-name Configures a VRF routing table and enters VRF
configuration mode.
Example: • The vrf-name argument specifies the name assigned to
Router(config)# ip vrf vpn1 a VRF.
24
Configuration Examples for MPLS VPN—MIB Support

Step 4 maximum routes limit {warn-threshold | Limits the maximum number of routes in a VRF to prevent
warn-only} a PE router from importing too many routes.
• The limit argument specifies the maximum number of
Example: routes allowed in a VRF. The range is from 1 to
Router(config-vrf)# maximum routes 10000 80 4,294,967,295.
• The warn-threshold argument generates a warning
when the number of routes set by the warn-threshold
argument is reached and rejects routes that exceed the
maximum number set in the limit argument. The
warning threshold is a percentage from 1 to 100 of the
maximum number of routes specified in the limit
argument.
• The warn-only keyword specifies that a system logging
error message is issued when the maximum number of
routes allowed for a VRF exceeds the limit threshold.
However, additional routes are still allowed.
Example:
Configuration Examples for MPLS VPN—MIB Support

This section contains the following configuration examples for the MPLS VPN—MIB Support feature.
• Configuring the SNMP Community: Examples, page 25
• Configuring the Router to Send SNMP Traps: Example, page 26
• Configuring Threshold Values for MPLS VPN—SNMP Notifications: Examples, page 26
Configuring the SNMP Community: Examples

The following example shows enabling a simple SNMP community group. This configuration permits
any SNMP client to access all PPVPN-MPLS-VPN MIB objects with read-only access using the
community string comaccess.
Router(config)# snmp-server community comaccess ro
Verify that the SNMP master agent is enabled for the MPLS VPN—MIB Support feature:
Router# show running-config | include snmp-server
.
snmp-server community comaccess RO
Note If you do not see any “snmp-server” statements, SNMP is not enabled on the router.
25
Configuring the Router to Send SNMP Traps: Example

The following example shows you how to enable the router to send MPLS VPN notifications to host
172.20.2.160 using the comaccess community string if a VRF transitions from an up or down state:
Router(config)# snmp-server host 172.20.2.160 traps comaccess mpls-vpn
Router(config)# snmp-server enable traps mpls vpn vrf-down vrf-up
Configuring Threshold Values for MPLS VPN—SNMP Notifications: Examples

The following example shows how to set a maximum threshold of 10,000 routes and a warning threshold
that is 80 percent of the maximum threshold for a VRF named vpn1 on a router:
The following example shows how to set a warning threshold of 10,000 routes for a VRF named vpn2
on a router. An error message is generated; however, additional routes are still allowed because a
maximum route threshold is not set with this command.
Router(config-vrf)# maximum routes 10000 warn-only
The following sections provide additional references related to the MPLS MPN-MIB Support feature.
Related Documents
MPLS applications
MPLS VPN configuration tasks Configuring MPLS Layer 3 VPNs
software for the MPLS Traffic Engineering MIB
(MPLS TE MIB)
Overview and configuration tasks for the MPLS MPLS Label Distribution Protocol
distribution protocol
Standards
Standard Title
draft-ietf-ppvpn-mpls-vpn-mib-05 MPLS/BGP Virtual Private Network Management Information Base
Using SMIv2
26
MIBs
MIB MIBs Link
• MPLS-VPN-MIB To locate and download MIBs for selected platforms, Cisco IOS XE
• CISCO-IETF-PPVPN-MPLS-VPN-MIB
the following URL:
RFCs
RFC Title
RFC 2233 The Interfaces Group MIB using SMIv2
Description Link
27
Feature Information for MPLS VPN—MIB Support
Feature Information for MPLS VPN—MIB Support

Table 9 Feature Information for MPLS VPN—MIB Support

MPLS VPN—MIB Support Cisco IOS XE The following sections provide information about this feature:
Release 2.1 • Information About MPLS VPN—MIB Support, page 2
• How to Configure MPLS VPN—MIB Support, page 19
snmp-server enable traps mpls vpn
28
Glossary
Glossary
ASN.1—Abstract Syntax Notation One. The data types independent of particular computer structures
and representation techniques. Described by ISO International Standard 8824.
BGP—Border Gateway Protocol. The exterior Border Gateway Protocol used to exchange routing
information between routers in separate autonomous systems. BGP uses TCP. Because TCP is a reliable
protocol, BGP does not experience problems with dropped or fragmented data packets.
BGP prefixes—A route announcement using the BGP. A prefix is composed of a path of autonomous
system numbers, indicating which networks the packet must pass through, and the IP block that is being
routed. A BGP prefix would look something like: 701 1239 42 206.24.14.0/24. (The /24 part is referred
to as a CIDR mask.) The /24 indicates that there are 24 ones in the netmask for this block starting from
the left side. A /24 corresponds to the natural mask 255.255.255.0.
Cisco Express Forwarding—An advanced Layer 3 IP switching technology. Cisco Express Forwarding
optimizes network performance and scalability for networks with large and dynamic traffic patterns.
CE router—customer edge router. A router on the border between a VPN provider and a VPN customer
that belongs to the customer.
CIDR—classless interdomain routing. A technique supported by BGP4 and based on route aggregation.
CIDR allows routers to group routes to reduce the quantity of routing information carried by the core
routers. With CIDR, several IP networks appear to networks outside the group as a single, larger entity.
With CIDR, IP addresses and their subnet masks are written as four octets, separated by periods,
followed by a forward slash and a two-digit number that represents the subnet mask.
community—In SNMP, a logical group of managed devices and NMSs in the same administrative
domain.
community name—See community string.
community string—A text string that acts as a password and is used to authenticate messages sent
between a managed station and a router containing an SNMP agent. The community string is sent in
every packet between the manager and the client. Also called a community name.
IETF—Internet Engineering Task Force. A task force consisting of over 80 working groups responsible
for developing Internet standards. The IETF operates under the auspices of ISOC. See also ISOC.
message, because the informs message notification requires acknowledgment, and a trap notification
does not.
ISOC—Internet Society. An international nonprofit organization, founded in 1992, that coordinates the
evolution and use of the Internet. In addition, ISOC delegates authority to other groups related to the
Internet, such as the IAB. ISOC is headquartered in Reston, Virginia (United States).
label—A short, fixed-length data construct that tells switching nodes how to forward data (packets or
cells).
LDP—Label Distribution Protocol. A standard protocol between MPLS-enabled routers that is used for
the negotiation of the labels (addresses) used to forward packets.
LFIB—Label Forwarding Information Base. In the Cisco Label Switching system, the data structure for
storing information about incoming and outgoing tags (labels) and associated equivalent packets suitable
for labeling.
LSR—label switch router. A device that forwards MPLS packets based on the value of a fixed-length
29
Glossary
maintained by a network management protocol such as SNMP or CMIP. The value of a MIB object can
be changed or retrieved using SNMP or CMIP commands, usually through a GUI network management
system. MIB objects are organized in a tree structure that includes public (standard) and private
(proprietary) branches.
MPLS interface—An interface on which MPLS traffic is enabled.
MPLS VPN—Multiprotocol Label Switching Virtual Private Network. An IP network infrastructure
delivering private network services over a public infrastructure using a Layer 3 backbone. Using MPLS
VPNs in a Cisco IOS XE network provides the capability to deploy and administer scalable Layer 3 VPN
backbone services including applications, data hosting network commerce, and telephony services to
business customers.
For an MPLS VPN solution, an MPLS VPN is a set of provider edge routers that are connected by means
of a common “backbone” network to supply private IP interconnectivity between two or more customer
sites for a given customer. Each VPN has a set of provisioning templates and policies and can span
multiple provider administrative domains (PADs).
NMS—network management system. A powerful, well-equipped computer (typically an engineering
network administration and configuration tasks.
notification—A message sent by an SNMP agent to a network management station, console, or terminal
to indicate that a significant event within Cisco IOS XE software has occurred. See also trap.
PE router—provider edge router. A router on the border between a VPN provider and a VPN customer
that belongs to the provider.
PPVPN—Provider-Provisioned VPN. The name of the IETF working group that is developing the
PPVPN-MPLS-VPN MIB.
QoS—quality of service. A measure of performance for a transmission system that reflects its
transmission quality and service availability.
RT—route target. An extended community attribute that identifies a group of routers and, in each router
of that group, a subset of forwarding tables maintained by the router that can be populated with a BGP
route carrying that extended community attribute. The RT is a 64-bit value by which Cisco IOS XE
discriminates routes for route updates in VRFs.
SNMP—Simple Network Management Protocol. The network management protocol used almost
exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices, and
to manage configurations, statistics collection, performance, and security. See also SNMP2.
SNMP2—SNMP Version 2. Version 2 of the popular network management protocol. SNMP2 supports
centralized and distributed network management strategies, and includes improvements in the Structure
of Management Information (SMI), protocol operations, management architecture, and security. See
also SNMP.
used.
30
Glossary
trap—A message sent by an SNMP agent to a network management station, console, or terminal,
indicating that a significant event occurred. Traps (notifications) are less reliable than inform requests,
because the receiver does not send an acknowledgment when it receives a trap. The sender cannot
determine if the trap was received. See also notification.
VPN—Virtual Private Network. A group of sites that, as the result of a set of administrative policies, are
able to communicate with each other over a shared backbone network. A VPN is a secure IP-based
network that shares resources on one or more physical networks. A VPN contains geographically
dispersed sites that can communicate securely over a shared backbone. See also MPLS VPN.
VPN ID—A mechanism that identifies a VPN based on RFC 2685. A VPN ID consists of an
Organizational Unique Identifier (OUI), a three-octet hex number assigned by the IEEE Registration
Authority, and a VPN index, a four-octet hex number, which identifies the VPN within the company.
coincidental.
31
Glossary
32
Pseudowire Emulation Edge-to-Edge MIBs for
Ethernet, Frame Relay, and ATM Services

The Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM Services feature
provides Simple Network Management Protocol (SNMP) support within an Any Transport over
Multiprotocol Label Switching (AToM) infrastructure emulating Ethernet, Frame Relay, and ATM
services over packet switched networks (PSNs). The Pseudowire Emulation Edge-to-Edge (PWE3)
MIBs are the following:
• CISCO-IETF-PW-MIB (PW-MIB)
• CISCO-IETF-PW-MPLS-MIB (PW-MPLS-MIB)
• CISCO-IETF-PW-ENET-MIB (PW-ENET-MIB)
• CISCO-IETF-PW-FR-MIB (PW-FR-MIB)
• CISCO-IETF-PW-ATM-MIB (PW-ATM-MIB)

which each feature is supported, see the “Feature Information for Pseudowire Emulation Edge-to-Edge MIBs
for Ethernet, Frame Relay, and ATM Services” section on page 27.
Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM Services
Contents
Contents
• Prerequisites for Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM
Services, page 2
• Restrictions for Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM
Services, page 2
• Information About Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM
Services, page 3
• How to Configure Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM
Services, page 20
• Configuration Examples for the Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame
Relay, and ATM Services, page 23
• Feature Information for Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and
ATM Services, page 27
Prerequisites for Pseudowire Emulation Edge-to-Edge MIBs for

• SNMP must be enabled on the label switch routers (LSRs).
• MPLS must be enabled on the LSRs.
• Pseudowires must be configured with Ethernet, Frame Relay, or ATM access circuits. (For more
detailed information, see the “Any Transport over MPLS” module.
Restrictions for Pseudowire Emulation Edge-to-Edge MIBs for

The PWE3 MIBs are limited to read-only (RO) permission for MIB objects except for the cpwVcUp and
cpwVcDown notification enable object, cpwVcUpDownNotifEnable, which has been extended to be
writable by the SNMP agent.
• The following tables in the PW-MIB are not supported:
– cpwVcPerfCurrentTable
– cpwVcPerfIntervalTable
• The following objects in the PW-MPLS-MIB are not supported:
– cpwVcMplsOutboundIndexNext
– cpwVcMplsInboundIndexNext
• The following tables in the PW-ENET-MIB are not supported:
– cpwVcEnetMplsPriMappingTable
– cpwVcEnetStatsTable
2
Information About Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM Services
• The following table in the PW-FR-MIB is not supported:

– cpwVcFrPMTable
• The PW-ATM-MIB does not support a high-capacity cell counter per virtual path (VP) or cells per
port.
• The PW-ATM-MIB virtual path identifier (VPI)/virtual channel identifier (VCI) value for port mode
cell relay is 0.
• The PW-ATM-MIB VP cell relay VCI value is 0.
• The PW-ATM-MIB VP does not support ATM adaptation layer 5 (AAL5); therefore, all packet
counters are invalid.
Note This feature is not supported over Ethernet, Frame Relay, and ATM in all releases. See the “Feature
Information for Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM
Services” section on page 27 for more detailed information.
Information About Pseudowire Emulation Edge-to-Edge MIBs

for Ethernet, Frame Relay, and ATM Services
To configure the Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM
Services feature, you should understand the following concepts:
• The Function of a Pseudowire in the PWE3 MIBs, page 3
• PWE3 MIBs Architecture, page 4
• Components and Functions of the PWE3 MIBs, page 5
• Tables in the PW-MIB, page 6
• Tables in the PW-MPLS-MIB, page 11
• Tables in the PW-ENET-MIB, page 15
• Tables in the PW-FR-MIB, page 16
• Tables in the PW-ATM-MIB, page 17
• Objects in the PWE3 MIBs, page 18
• Scalar Objects in the PWE3 MIBs, page 19
• Notifications in the PWE3 MIBs, page 19
• Benefits of the PWE3 MIBs, page 19
The Function of a Pseudowire in the PWE3 MIBs

A pseudowire is a point-to-point connection between pairs of provider edge (PE) routers (as shown in
Figure 1). Its primary function is to emulate services like Ethernet over an underlying core MPLS
network through encapsulation into a common MPLS format. By encapsulating services into a common
MPLS format, a pseudowire allows carriers to converge their services to an MPLS network.
3
Figure 1 Sample Pseudowire Topology
Fast MPLS Fast

Ethernet Core Ethernet
CE1 PE1 PW PW PE2 CE2
PW = Pseudowire
CE = Customer Edge Router
192009
PE = Provider Edge Router
MPLS = Multiprotocol Label Switching
PWE3 MIBs Architecture

The PWE3 MIBs architecture shown in Figure 2 categorizes three groups of MIBs that, when used
together, provide the complete emulated service; the native transport, which carries the service across
the core network; and the relationship between the two.
Figure 2 PWE3 MIBs Architecture
Native Service MIBs Etherlike-MIB PW-FR-MIB PW-ATM-MIB
CISCO-IETF-PW-ENET-MIB CISCO-IETF-PW- CISCO-IETF-PW-

(PW-ENET-MIB) FR-MIB ATM-MIB
(PW-FR-MIB) (PW-ATM-MIB)
PW Specific MIBs CISCO-IETF-PW-MIB

(PW-MIB)
CISCO-IETF-PW-MPLS-MIB
CISCO-IETF-PW-L2TPv3
(PW-MPLS-MIB)
Native Transport MIBs
MPLS-LSR-STD-MIB MPLS-TE-STD-MIB
CISCO-IETF-L2TPv3-MIB
(RFC 3813) (RFC 3812)
135236
Exist
Future
The architecture is modular in that once deployed, new emulated service MIB modules or additional
transport MIB modules “plug in” to or extend the existing infrastructure rather than require a new and
unique one. This allows you to build management applications without the concern of a new service
requiring the deployment of a completely different management strategy. Because the architecture is a
generalized association mechanism between existing service and transport MIB modules, native MIB
modules work in the absence of the associated PWE3-specific MIBs. The advantage is that if a
4
PWE3-specific MIB has not yet been deployed in Cisco IOS XE software, which associates a service or
transport with pseudowires, these MIB modules can still be queried. However, the only drawback is that
the associations with the pseudowires are absent.
Components and Functions of the PWE3 MIBs

The PWE3 MIBs have the following components and functions:
• PW-MIB (the pseudowire MIB)
This MIB binds the PW-MPLS-MIB and the PW-ENET-MIB together, and provides status of the
pseudowire emulation and statistics and configuration information. The PW-MIB also defines the
notifications for pseudowire fault and event monitoring.
• PW-MPLS-MIB (the pseudowire MPLS-MIB)
This MIB contains managed objects that can be used by a network manager to monitor pseudowire
emulation MPLS services, such as MPLS-traffic engineering (TE)-PSN and MPLS-non-TE-PSN.
This MIB shows the following:
– Cross-connect (XC) indexes for virtual circuits (VCs) that are Label Distribution Protocol
(LDP)-signaled and have a preferred path that is not set to an MPLS TE tunnel.
– Tunnel indexes for VCs with a preferred path set to a TE tunnel and an output interface that is
a TE tunnel.
• PW-ENET-MIB (the pseudowire Ethernet services MIB)
emulation Ethernet services.
• PW-FR-MIB (the pseudowire Frame Relay services MIB)
emulation Frame Relay services.
This MIB uses a Frame Relay over pseudowire (FRoPW) connection that consists of two segments:
the Frame Relay segment and the pseudowire segment. The PW-FR-MIB provides hooks to those
segments. The PW MIB contains information about the pseudowire segment, and the PW-FR-MIB
contains information about the Frame Relay segment.
The PW-FR-MIB is defined at the Pseudowire Service Emulation Layer and resides on top of the
generic PW-MIB as shown in Figure 2. Therefore, the PW-FR-MIB is highly dependent on the
existence and the service provided by the PW-MIB. In addition, an existing PW-FR connection entry
must associate with an existing VC entry in the PW-MIB.
The PW-FR-MIB and the generic PW-MIB are logically tied by the PW VC Index, which is an
internal index defined to support the PW-MIB. Each PW VC index uniquely maps into an existing
VC entry in the PW-MIB and the PW-FR-MIB.
• PW-ATM-MIB (the pseudowire ATM services MIB)
emulation ATM services.
This MIB uses an ATM over pseudowire (ATMoPW) connection that consists of two segments: the
ATM segment and the pseudowire segment. The PW-ATM-MIB provides hooks to those segments.
The PW MIB contains information about the pseudowire segment, and the PW-ATM-MIB contains
information about the ATM segment called the attachment circuit.
5
The PW-ATM-MIB is defined at the Pseudowire Service Emulation Layer and resides on top of the
generic PW-MIB as shown in Figure 2. Therefore, the PW-ATM-MIB is highly dependent on the
existence and the service provided by the PW-MIB. In addition, an existing PW-ATM connection
entry must associate with an existing VC entry in the PW-MIB.
The PW-ATM-MIB and the generic PW-MIB are logically tied by the PW VC Index, which is an
internal index defined to support the PW-MIB. Each PW VC index uniquely maps into an existing
VC entry in the PW-MIB and the PW-ATM-MIB.
Tables in the PW-MIB

The PW-MIB consists of the following tables:
• cpwVcTable (Table 1)—Contains high-level generic parameters related to VC creation. This table
is implemented as read only and is indexed by the cpwVcIndex, which uniquely identifies a singular
connection. A row in this table represents an emulated virtual connection. This table is used for all
VC types.
• cpwVcPerfTotalTable (Table 2)—Provides per-VC performance information from the VC start time.
This table is indexed by the cpwVcIndex.
• cpwVcIdMappingTable (Table 3)—Provides reverse mapping of the existing VCs based on VC type
and VC ID ordering. This table is typically useful for element manager software (EMS) ordered
query of existing VCs. This table is indexed by cpwVcIdMappingVcType, cpwVcIdMappingVcID,
cpwVcIdMappingPeerAddrType, and cpwVcIdMappingPeerAddr. This table is implemented as
read only.
• cpwVcPeerMappingTable (Table 4)—Provides reverse mapping of the existing VCs based on VC
type and VC ID ordering. This table is typically useful for EMS ordered query of existing VCs. This
table is indexed by cpwVcPeerMappingPeerAddrType, cpwVcPeerMappingPeerAddr,
cpwVcPeerMappingVcType, and cpwVcPeerMappingVcID. This table is implemented as read only.
cpwVcTable
Table 1 lists the cpwVcTable objects and their descriptions.
Table 1 cpwVcTable Objects and Descriptions
Objects Description
cpwVcType Indicates the service to be carried over this VC. This is circuit
type information.
cpwVcOwner Set by the operator to indicate the protocol responsible for
establishing this VC. Values are the following:
• manual(1)—Used when no maintenance protocol (PW
signaling) is needed to set up the VC, such as configuration
of entries in the VC tables including VC labels, and so
forth.
• maintenanceProtocol(2)—Used for standard signaling of
the VC for the specific PSN; for example, LDP for MPLS
PSN as specified in draft-martini-l2circuit-trans-mpls or
the Layer 2 Tunneling Protocol (L2TP).
• other(3)—Used for all other types of signaling.
6
Table 1 cpwVcTable Objects and Descriptions (continued)
Objects Description
cpwVcPsnType Set by the operator to indicate the PSN type on which this VC
is carried. Based on this object, the relevant PSN table entries
are created in the PSN-specific MIB modules. For example, if
mpls(1) is defined, the agent creates an entry in the
cpwVcMplsTable, which further defines the MPLS PSN
configuration.
cpwVcSetUpPriority Defines the relative setup priority of the VC in a
lowest-to-highest manner, where 0 is the highest priority. This
value is significant if there are competing resources between
VCs and the implementation supports this feature. Because this
is not implemented in AToM, the value of 0 is used.
cpwVcHoldingPriority Defines the relative holding priority of the VC in a
lowest-to-highest manner, where 0 is the highest priority. This
value is significant if there are competing resources between
VCs and the implementation supports this feature. Because this
is not implemented in AToM, the value of 0 is used.
cpwVcInboundMode Enables greater security for implementations that use
per-platform VC label space. Modes are the following:
• strict(1)
• loose(2)
In strict mode, packets coming from the PSN are accepted only
from tunnels that are associated to the same VC via the inbound
tunnel table in the case of MPLS, or as identified by the source
IP address in the case of L2TP or IP PSN. The entries in the
inbound tunnel table are either explicitly configured or
implicitly known by the maintenance protocol used for VC
setup.
If such association is not known, not configured, or not desired,
loose mode should be configured, and the node should accept
the packet based on the VC label only, regardless of the outer
tunnel used to carry the VC.
cpwVcPeerAddrType Denotes the address type of the peer node maintenance protocol
(signaling) address if the PW maintenance protocol is used for
the VC creation. It should be set to unknown if the PW
maintenance protocol is not used; for example, cpwVcOwner is
set to manual.
cpwVcPeerAddr Contains the value of the peer node address of the PW
maintenance protocol entity. This object should contain a value
of 0 if not relevant (manual configuration of the VC).
cpwVcID Use in the outgoing VC ID field within the VC forward
equivalence class (FEC) element with LDP signaling or the PW
ID attribute-value (AV) pair for the L2TP.
cpwVcLocalGroupID Use in the Group ID field sent to the peer PW within the
maintenance protocol for VC setup; 0 if not used.
7
Objects Description
cpwVcControlWord Defines if the control word is sent with each packet by the local
node.
cpwVcLocalIfMtu If not = 0, the optional IfMtu object in the maintenance protocol
is sent with this value, representing the locally supported
maximum transmission unit (MTU) size over the interface (or
the virtual interface) associated with the VC.
cpwVcLocalIfString Each VC is associated to an interface (or a virtual interface) in
the ifTable of the node as part of the service configuration. This
object defines if the maintenance protocol sends the interface’s
name as it appears in the ifTable in the name object as part of
the maintenance protocol. If this object is set to false, the
optional element is not sent.
cpwVcRemoteGroupID Obtained from the Group ID field as received via the
maintenance protocol used for VC setup; 0 if not used. The
value of 0xFFFF is used if the object is not defined by the VC
maintenance protocol.
cpwVcRemoteControlWord If the maintenance protocol is used for VC establishment, this
parameter indicates the received status of the control word
usage; that is, if packets are received with the control word or
not. The value of notYetKnown is used while the maintenance
protocol has not yet received the indication from the remote
node. In a manual configuration of the VC, this parameter
indicates to the local node the expected encapsulation for the
received packets.
cpwVcRemoteIfMtu The remote interface MTU as received from the remote node
via the maintenance protocol. This object should be 0 if this
parameter is not available or not used.
cpwVcRemoteIfString Indicates the interface description string as received by the
maintenance protocol; it must be a NULL string if not
applicable or not known yet.
cpwVcOutboundVcLabel The VC label used in the outbound direction toward the PSN.
This object may be set up manually if the owner is manual;
otherwise, it is automatic. Examples; for MPLS PSN, the label
represents the 20 bits of the VC tag; for L2TP, it represents the
32 bits of the session ID. If the label is not yet known (signaling
in process), the object should return a value of 0xFFFF.
cpwVcInboundVcLabel The VC label used in the inbound direction for packets received
from the PSN. This object may be set up manually if the owner
is manual; otherwise, it is automatic. Examples; for MPLS
PSN, the label represents the 20 bits of VC tag; for L2TP, the
label represents the 32 bits of the session ID. If the label is not
yet known (signaling in process), the object should return a
value of 0xFFFF.
cpwVcName The canonical name assigned to the VC.
cpwVcDescr A textual string containing information about the VC. If there
is no description, this object contains a 0 length string.
8
Objects Description
cpwVcCreateTime System time when this VC was created.
cpwVcUpTime Number of consecutive ticks that this VC has been up in both
directions together. (Up is observed in cpwVcOperStatus.)
cpwVcAdminStatus The desired operational status of this VC.
cpwVcOperStatus Indicates the actual combined operational status of this VC.
This object is up if both cpwVcInboundOperStatus and
cpwVcOutboundOperStatus are in the up state. For all other
values, if the VCs in both directions are of the same value, this
object reflects that value; otherwise, it is set to the more severe
status of the two. The order of severity from most severe to less
severe is as follows: unknown, notPresent, down,
lowerLayerDown, dormant, testing, and up. The operator can
consult the direction of OperStatus for fault isolation.
cpwVcInboundOperStatus Indicates the actual operational status of this VC in the inbound
direction. Values are the following:
• up—The VC is established and ready to pass packets.
• down—PW signaling has not yet finished or indications
available at the service level show that the VC is not
passing packets.
• testing—AdminStatus at the VC level is set to test.
• dormant—The VC is not available because the required
resources are occupied by higher priority VCs.
• notPresent—Some component needed for the setup of the
VC is missing.
• lowerLayerDown—The underlying PSN is not in
OperStatus up.
cpwVcOutboundOperStatus Indicates the actual operational status of this VC in the
outbound direction. Values are the following:
• up—The VC is established and ready to pass packets.
• down—PW signaling has not yet finished or indications
available at the service level show that the VC is not
passing packets.
• testing—AdminStatus at the VC level is set to test.
• dormant—The VC is not available because the required
resources are occupied by higher priority VCs.
• notPresent—Some component needed for the setup of the
VC is missing.
• lowerLayerDown—The underlying PSN is not in
OperStatus up.
9
Objects Description
cpwVcTimeElapsed The number of seconds, including partial seconds, that have
elapsed since the beginning of the current measurement period.
If, for some reason, such as an adjustment in the system’s
time-of-day clock, and the current interval exceeds the
maximum value, the agent returns the maximum value. Because
cpwVcPerfIntervalTable is not implemented, this is 0.
cpwVcValidIntervals The number of previous 15-minute intervals for which data was
collected. An agent with PW capability must be capable of
supporting at least x intervals. The minimum value of x is 4; the
default of x is 32, and the maximum value of x is 96. The value
is x unless the measurement was (re)started within the last x*15
minutes, in which case the value will be the number of complete
15-minute intervals; for example, in the case where the agent is
a proxy, some intervals may be unavailable. In this case, this
interval is the maximum interval number for which data is
available. This interval is set to 0.
cpwVcRowStatus A read-only implementation that is always active(1). It is used
for creating, modifying, and deleting.
cpwVcStorageType The storage type for this object is a read-only implementation
that is always volatile(2).
cpwVcPerfTotalTable
Table 2 lists the cpwVcPerfTotalTable objects and their descriptions.
Table 2 cpwVcPerfTotalTable Objects and Descriptions
Objects Description
cpwVcPerfTotalInHCPackets High-capacity counter for the number of packets received by
the VC from the PSN.
cpwVcPerfTotalInHCBytes High-capacity counter for the number of bytes received by the
VC from the PSN.
cpwVcPerfTotalOutHCPackets High-capacity counter for the number of packets forwarded by
the VC to the PSN.
cpwVcPerfTotalOutHCBytes High-capacity counter for the number of bytes forwarded by the
VC (to the PSN).
cpwVcPerfTotalDiscontinuityTime The value of sysUpTime on the most recent occasion when one
or more of this object’s counters suffered a discontinuity. The
relevant counters are the specific instances of any Counter32 or
Counter64. If no such discontinuities have occurred since the
last reinitialization of the local management subsystem, this
object contains a 0 value.
cpwVcIdMappingTable
Table 3 lists the cpwVcIdMappingTable objects and their descriptions.
10
Table 3 cpwVcIdMappingTable Objects and Descriptions
Objects Description
cpwVcIdMappingVcType The VC type (indicates the service) of this VC.
cpwVcIdMappingVcID The VC ID of this VC; 0 if the VC is configured manually.
cpwVcIdMappingPeerAddrType IP address type of the peer node.
cpwVcIdMappingPeerAddr IP address of the peer node.
cpwVcIdMappingVcIndex The value that represents the VC in the cpwVcTable.
cpwVcPeerMappingTable
Table 4 lists the cpwVcPeerMappingTable objects and their descriptions.
Table 4 cpwVcPeerMappingTable Objects and Descriptions
Objects Description
cpwVcPeerMappingPeerAddrType IP address type of the peer node.
cpwVcPeerMappingPeerAddr IP address of the peer node.
cpwVcPeerMappingVcType The VC type (indicates the service) of this VC.
cpwVcPeerMappingVcID The VC ID of this VC; 0 if the VC is configured manually.
cpwVcPeerMappingVcIndex The value that represents the VC in the cpwVcTable.
Tables in the PW-MPLS-MIB

The PW-MPLS-MIB consists of the following tables:
• cpwVcMplsTable (Table 5)—Specifies information for the VC to be carried over an MPLS PSN.
This table is indexed on cpwVcIndex.
• cpwVcMplsOutboundTable (Table 6)—Associates VCs using an MPLS PSN with the outbound
MPLS tunnels toward the PSN or the physical interface in the case of the VC only. A row in this
table represents a link between PW VCs that require MPLS tunnels and an MPLS tunnel toward the
PSN. This table is indexed by the cpwVcIndex and an additional index that is not supported;
consequently, its value is 1. The operator creates at least one entry in this table for each PW VC that
requires an MPLS PSN. The VC-only case and the cpwVcMplsOutboundIndex is not supported.
• cpwVcMplsInboundTable (Table 7)—Associates VCs using an MPLS PSN with the inbound MPLS
tunnels for packets coming from the PSN, if such association is desired mainly for security reasons.
A row in this table represents a link between PW VCs that require MPLS tunnels and an MPLS
tunnel for packets arriving from the PSN. This table is indexed by the set of indexes used to identify
the VC, cpwVcIndex, and an additional index that is not supported; consequently, its value is 1. An
entry is created in this table either automatically by the local agent or manually by the operator when
strict mode is required. This table points to the appropriate MPLS MIB. For MPLS-TE, the four
variables relevant to the indexing of an MPLS TE tunnel are set. The VC-only case and the
cpwVcMplsInboundIndex are not supported.
• cpwVcMplsNonTeMappingTable (Table 8)—Maps an inbound or outbound tunnel to a VC in
non-TE applications. A row in this table represents the association between a PW VC and its non-TE
MPLS outer tunnel. An application can use this table to retrieve the PW carried over a specific
11
non-TE MPLS outer tunnel quickly. This table is indexed by the xconnect index for the MPLS
non-TE tunnel and the direction of the VC in the specific entry. The same table is used in both
inbound and outbound directions, but in a different row for each direction. If the inbound association
is not known, no rows should exist for it. Rows are created by the local agent when all the association
data is available for display.
• cpwVcMplsTeMappingTable (Table 9)—Maps an inbound or outbound tunnel to a VC in MPLS-TE
applications. A row in this table represents the association between a PW VC and its MPLS-TE outer
tunnel. An application can use this table to retrieve the PW carried over a specific TE MPLS outer
tunnel quickly. This table is indexed by the four indexes of a TE tunnel, the direction of the VC
specific entry, and the VcIndex. The same table is used in both inbound and outbound directions,
but a different row for each direction. If the inbound association is not known, no rows should exist
for it. Rows are created by the local agent when all the association data is available for display. This
table shows mappings between pseudowires and the xconnect index for non-TE outer tunnel or
index.
cpwVcMplsTable
Table 5 lists the cpwVcMplsTable objects and their descriptions.
Table 5 cpwVcMplsTable Objects and Descriptions
Objects Description
cpwVcMplsMplsType Set by the operator to indicate the outer tunnel types, if they
exist. Values are the following:
• mplsTe(0)—Used when the outer tunnel is set up by
MPLS-TE.
• mplsNonTe(1)—Used when the outer tunnel is set up by
LDP or manually.
cpwVcMplsExpBitsMode Set by the operator to indicate the way the VC shim label EXP
bits are to be determined. The value is the following:
• outerTunnel(1)—Used when there is an outer tunnel and
cpwVcMplsMplsType is mplsTe or mplsNonTe.
cpwVcMplsExpBits Set by the operator to indicate the MPLS EXP bits to be used
on the VC shim label if cpwVcMplsExpBitsMode is specified;
value = 0.
cpwVcMplsTtl Set by the operator to indicate the VC time-to-live (TTL) bits to
be used on the VC shim label; value = 0.
cpwVcMplsLocalLdpID The local LDP identifier of the LDP entity creating this VC in
the local node. Because the VC labels are always set from the
per-platform label space, the last two octets in the LDP ID must
be 0s.
cpwVcMplsLocalLdpEntityID The local LDP entity index of the LDP entity to be used for this
VC on the local node; this should be set to all 0s when this
object is not used.
cpwVcMplsPeerLdpID The peer LDP identifier as identified by the LDP session; this
should be zero if not relevant or not known yet.
cpwVcMplsStorageType The storage type for this object is a read-only implementation
12
cpwVcMplsOutboundTable
Table 6 lists the cpwVcMplsOutboundTable objects and their descriptions.
Table 6 cpwVcMplsOutboundTable Objects and Descriptions
Objects Description
cpwVcMplsOutboundIndex An arbitrary index for enabling multiple rows per VC in this
table. The next available free index can be retrieved using
cpwVcMplsOutboundIndexNext. The value = 1, because this
object is not supported.
cpwVcMplsOutboundLsrXcIndex Set by the operator. If the outer label is defined in the
MPL-LSR-MIB, that is, set by LDP or manually, this object
points to the xconnect index of the outer tunnel. Otherwise,
this object is set to 0.
cpwVcMplsOutboundTunnelIndex Part of the set of indexes for an outbound tunnel, specifically
an MPLS-TE outer tunnel; otherwise, this object is set to 0.
cpwVcMplsOutboundTunnelInstance Part of the set of indexes for an outbound tunnel, specifically
an MPLS-TE outer tunnel; otherwise, this object is set to 0.
cpwVcMplsOutboundTunnelLclLSR Part of the set of indexes for an outbound tunnel, specifically
an MPLS-TE outer tunnel; otherwise, this object is set to
NULL.
cpwVcMplsOutboundTunnelPeerLSR Part of the set of indexes for an outbound tunnel, specifically
an MPLS-TE outer tunnel; otherwise, this object is set to
NULL.
cpwVcMplsOutboundIfIndex For a VC only with no outer tunnel, this object holds the
ifIndex of the outbound port. The value = 0.
cpwVcMplsOutboundRowStatus A read-only implementation that is always active(1). It is
used for creating, modifying, and deleting.
cpwVcMplsOutboundStorageType The storage type for this object is a read-only implementation
cpwVcMplsInboundTable
Table 7 lists the cpwVcMplsInboundTable objects and their descriptions.
Table 7 cpwVcMplsInboundTable Objects and Descriptions
Objects Description
cpwVcMplsInboundIndex An arbitrary index for enabling multiple rows per VC in this
table. The next available free index can be retrieved using
cpwVcMplsInboundIndexNext. the value = 1, because this
object is not supported.
cpwVcMplsInboundLsrXcIndex If the outer label is defined in the MPL-LSR-MIB; that is, set
by LDP or manually, this object points to the xconnect index of
the outer tunnel. The xconnect index represents the pseudowire
in the inbound direction retrieving 0 if information for this
object is not known.
13
Table 7 cpwVcMplsInboundTable Objects and Descriptions (continued)
Objects Description
cpwVcMplsInboundTunnelIndex Part of the set of indexes for an inbound tunnel, specifically an
MPLS-TE outer tunnel; value = 0. This object does not support
TE tunnels at the ingress router.
cpwVcMplsInboundTunnelInstance Part of the set of indexes for an inbound tunnel, specifically an
MPLS-TE outer tunnel; value = 0. This object does not support
TE tunnels at the ingress router.
cpwVcMplsInboundTunnelLclLSR Part of the set of indexes for an inbound tunnel, specifically an
MPLS-TE outer tunnel; otherwise, set to NULL. This object
does not support TE tunnels at the ingress router.
cpwVcMplsInboundTunnelPeerLSR Part of the set of indexes for an inbound tunnel, specifically an
MPLS-TE outer tunnel; otherwise, this object is set to NULL.
This object does not support TE tunnels at the ingress router.
cpwVcMplsInboundIfIndex In the case of a VC only (no outer tunnel), this object holds the
ifIndex of the inbound port. The value = 0.
cpwVcMplsInboundRowStatus A read-only implementation that is always active(1). It is used
for creating, modifying, and deleting.
cpwVcMplsInboundStorageType The storage type for this object is a read-only implementation
cpwVcMplsNonTeMappingTable
Table 8 lists the cpwVcMplsNonTeMappingTable objects and their descriptions.
Table 8 cpwVcMplsNonTeMappingTable Objects and Descriptions
Objects Description
cpwVcMplsNonTeMappingTunnelDirection Identifies if the row represents an outbound or inbound
mapping.
cpwVcMplsNonTeMappingXcTunnelIndex XC index in the MPLS-LSR-MIB of the pseudowire
LDP-generated XC entry.
cpwVcMplsNonTeMappingIfIndex Identifies the port on which the VC is carried for VC
only; the value = 0.
cpwVcMplsNonTeMappingVcIndex Represents the VC in the cpwVcTable.
cpwVcMplsTeMappingTable
Table 9 lists the cpwVcMplsTeMappingTable objects and their descriptions.
Table 9 cpwVcMplsTeMappingTable Objects and Descriptions
Objects Description
cpwVcMplsTeMappingTunnelDirection Identifies if the row represents an outbound mapping.
cpwVcMplsTeMappingTunnelIndex Index for the conceptual row identifying an MPLS-TE
tunnel.
14
Table 9 cpwVcMplsTeMappingTable Objects and Descriptions (continued)
Objects Description
cpwVcMplsTeMappingTunnelInstance Identifies an instance of an MPLS-TE tunnel.
cpwVcMplsTeMappingTunnelPeerLsrID Identifies a peer LSR when the outer tunnel is MPLS-TE
based.
cpwVcMplsTeMappingTunnelLocalLsrID Identifies the local LSR.
cpwVcMplsTeMappingVcIndex Represents the VC in the cpwVcTable.
Tables in the PW-ENET-MIB

The PW-ENET-MIB consists of the following table:
• cpwVcEnetTable (Table 10)—Provides Ethernet port mapping and VLAN configuration for each
Ethernet emulated virtual connection. This table is indexed on cpwVcIndex, which uniquely
identifies a singular connection. The second level index for this table is cpwVcEnetPwVlan, which
indicates VLANs on this VC. This table is used only for Ethernet VC types—ethernetVLAN,
ethernet, or ethernet virtual private LAN service (VPLS), and is implemented as read-only.
cpwVcEnetTable
Table 10 lists the cpwVcEnetTable objects and their descriptions.
Table 10 cpwVcEnetTable Objects and Descriptions
Objects Description
cpwVcEnetPwVlan The VLAN value for frames on a VC. This is one of the
indexes to the table so multiple VLAN values can be
configured for a PW VC. This value is 4096 to indicate
untagged frames; that is, if the cpwVcEnetVlanMode
value is removeVlan. This value is the VLAN value of
the access circuit if the cpwVcEnetVlanMode value is
noChange. The value of 4097 is used if the object is not
applicable; for example, when mapping all packets from
an Ethernet port to the VC.
cpwVcEnetVlanMode Indicates the way the VLAN field is handled between the
access circuit and the PW VC. The possible values for
this field are as follows:
• noChange—Indicates that the VC contains the
original user VLAN, as specified in
cpwVcEnetPortVlan.
• changeVlan—Indicates that the VLAN field on the
VC may be different from the VLAN field on the
user’s port.
• removeVlan—Indicates that the encapsulation on
the VC does not include the original VLAN field.
15
Table 10 cpwVcEnetTable Objects and Descriptions (continued)
Objects Description
cpwVcEnetPortVlan Defines the VLAN value on the physical port (or VPLS
virtual port) if a change is required to the VLAN value
between the VC and the physical or virtual port. It is
equal to cpwVcEnetPwVlan if the cpwVcEnetVlanMode
value is noChange. A value of 4096 indicates that no
VLAN is associated with the VC; that is, assigning
Default VLAN to untagged frames. If all traffic from the
VC is being forwarded to the port, then this value is 4097
indicating it is not relevant.
cpwVcEnetPortIfIndex The ifIndex value of the Ethernet port associated with
this PW VC for point-to-point Ethernet service. For
VPLS, this value is an ifIndex value for a virtual
interface for the VPLS instance.
cpwVcEnetVcIfIndex Models the VC as a virtual interface in the ifTable. This
value is always 0 to indicate no virtual interface is
created.
cpwVcEnetRowStatus A read-only implementation that is always active(1). It is
cpwVcEnetStorageType The storage type for this object is a read-only
implementation that is always volatile(2).
Tables in the PW-FR-MIB

The PW-FR-MIB consists of the following table:
• cpwVcFrTable (Table 11)—Contains entries that represent an FRoPW connection operating in
one-to-one mapping mode in which there is a one-to-one correspondence between a Frame Relay
VC and a pair of unidirectional pseudowires.
cpwVcFrTable
Table 11 lists the cpwVcFrTable objects and their descriptions.
Table 11 cpwVcFrTable Objects and Descriptions
Objects Description
cpwVcFrIfIndex Returns the interface ifIndex of the Frame Relay (FR)
segment of the FRoPW connection.
cpwVcFrDlci Returns the data-link connection identifier (DLCI) of the
Frame Relay segment of an FRoPW connection.
cpwVcFrAdminStatus Returns the administrative status of an FRoPW
connection.
cpwVcFrOperStatus Returns the combined operational status of an FRoPW
connection.
16
Table 11 cpwVcFrTable Objects and Descriptions (continued)
Objects Description
cpwVcFrPw2FrOperStatus Returns the operational status of the PW-to-FR direction
in an FRoPW connection.
cpwVcFrRowStatus A read-only implementation that is always active(1). It is
cpwVcFrStorageType The storage type for this object is a read-only
implementation that is always volatile(2).
Tables in the PW-ATM-MIB

The PW-ATM-MIB consists of the following tables:
• cpwVcAtmTable (Table 12)—Specifies information for an ATM VC to be carried over the PSN.
• cpwVcAtmPerfTable (Table 13)—Specifies performance-related attributes for an ATM VC.
cpwVcAtmTable
Table 12 lists the cpwVcAtmTable objects and their descriptions.
Table 12 cpwVcAtmTable Objects and Descriptions
Objects Description
cpwAtmIf Specifies the ATM interface that sends and receives cells
from the ATM network.
cpwAtmVpi Specifies the VPI value of the ATM VC.
cpwAtmVci Specifies the VCI value of the ATM VC.
cpwAtmClpQosMapping Indicates the presence of cell loss priority (CLP) bits
determining the value in quality of service (QoS) fields
of the encapsulating protocol. The value could be used
only for outbound traffic, which means traffic going out
to the PSN.
cpwAtmRowStatus A read-only implementation that is always active(1). It is
cpwAtmOamCellSupported Indicates whether operation, administration, and
maintenance (OAM) cells are transported on this VC.
cpwAtmQosScalingFactor Represents the scaling factor to be applied to ATM QoS
rates when calculating QoS rates for the PSN domain.
cpwAtmCellPacking Identifies if the VC is configured to do cell packing.
cpwAtmMncp Identifies the number of cells that need to be packed.
cpwAtmEncap Provides information on whether MPLS or Layer 2
Tunneling Protocol Version 3 (L2TPv3) is used as the
transport.
17
Table 12 cpwVcAtmTable Objects and Descriptions (continued)
Objects Description
cpwAtmPeerMncp Represents the maximum number of cells that can be
packed in one packet for a peer interface.
cpwAtmMcptTimeout Represents the maximum cell packing timeout (MCPT)
value used.
cpwVcAtmPerfTable
Table 13 lists the cpwVcAtmPerfTable objects and their descriptions.
Table 13 cpwVcAtmPerfTable Objects and Descriptions
Objects Description
cpwAtmCellsReceived Obtains information on the number of cells that were
received and sent to the PSN.
cpwAtmCellsSent Provides information on the number of cells sent to the
ATM network.
cpwAtmCellsRejected Indicates the number of cells that were rejected by
this VC because of policing.
cpwAtmCellsTagged Indicates the number of cells that were tagged.
cpwAtmHCCellsReceived Provides the high-capacity counter for the number of
cells received by this VC.
cpwAtmHCCellsRejected Provides the high-capacity counter for the number of
cells rejected by this VC.
cpwAtmHCCellsTagged Provides the high-capacity counter for number of cells
that were tagged.
cpwAtmAvgCellsPacked Provides the average number of cells that were packed.
cpwAtmPktsReceived Indicates the number of ATM AAL5 packets that are
actually sent into the ATM network as packets when the
VC is configured to do AAL5 over PW.
cpwAtmPktsSent Gets the number of packets that are reconstructed from
the cells, assigns a VC label, and sends the packets into
the PSN.
cpwAtmPktsRejected Indicates the number of packets that were rejected
because of policing.
Objects in the PWE3 MIBs

The PWE3 MIBs represent an ASN.1 notation reflecting specific components of the pseudowire
services. The MIBs enable a network management application using SNMP to get this information for
display. The MIBs support the standard GETNEXT and GETBULK functionality, but do not support
configuration capabilities (via SET) in the current implementation.
18
Scalar Objects in the PWE3 MIBs

The PWE3 MIBs contain the following supported scalar object:
• cpwVcUpDownNotifEnable—This object reflects the configuration of the cpwVcUp and
cpwVcDown notifications. If either of the notifications is configured via the command-line interface
(CLI), then this object has a value of true(1). If this object is set via SNMP to true(1), then it enables
the emission of both the cpwVcUp and cpwVcDown notifications; if the object is set via SNMP to
false(2), these notifications are not emitted.
Note cpwVcUpDownNotifEnable can be set only if RW is configured for the snmp-server

community string [view view-name] [ro | rw] [ipv6 nacl] [access-list-number] command.
The PWE3 MIBs contain the following unsupported scalar objects:

• cpwVcIndexNext—Indicates the next cpwVcIndex value to use when you add rows to the cpwVcTable.
• cpwVcNotifRate—Indicates the rate at which cpwVcUp/Down notifications can be issued from the
device.
• cpwVcMplsOutboundIndexNext—Contains an appropriate value to be used for
cpwVcMplsOutboundIndex when you create entries in the cpwVcMplsOutboundTable. The value 0
indicates that no unassigned entries are available. To obtain the cpwVcMplsOutboundIndex value
for a new entry, the manager issues a management protocol retrieval operation to obtain the current
value of this object. After each retrieval, the software agent should modify the value to the next
unassigned index; however, the software agent must not assume such retrieval will be done for each
row created.
• cpwVcMplsInboundIndexNext—Contains an appropriate value to be used for
cpwVcMplsInboundIndex when you create entries in the cpwVcMplsInboundTable. The value 0
indicates that no unassigned entries are available. To obtain the cpwVcMplsInboundIndex value for
a new entry, the manager issues a management protocol retrieval operation to obtain the current
value of this object. After each retrieval, the software agent should modify the value to the next
unassigned index; however, the agent must not assume such retrieval will be done for each row
created.
Notifications in the PWE3 MIBs

The cpwVcUp and cpwVcDown notifications in the PW-MIB indicate when the operStatus values for a
range of PW VCs have changed state.
The definition of these objects in the PW-MIB indicates that events of the same type, either up or down,
must be able to be correlated into ranges. The implementation of these notifications does not do any of
this correlation. A notification is generated for each individual VC that has an operational state change
if that notification is enabled. A notification does not signal an operational state change for a group of
VCs as described in the MIB.
Benefits of the PWE3 MIBs

The PWE3 MIBs provide the ability to manage pseudowire emulation edge-to-edge by providing
MPLS-related information about the service and a mechanism to monitor the Ethernet, Frame Relay, or
ATM access circuits.
19
How to Configure Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM Services
How to Configure Pseudowire Emulation Edge-to-Edge MIBs for

• Enabling the SNMP Agent for the PWE3 MIBs, page 20 (required)
• Configuring the Pseudowire Class, page 21 (required)
Enabling the SNMP Agent for the PWE3 MIBs

Perform this task to enable the SNMP agent.
SUMMARY STEPS
1. enable
2. show running-config [interface | map-class]
4. snmp-server community string [view view-name] [ro | rw] [ipv6 nacl] [access-list-number]
5. end
6. write memory
DETAILED STEPS

Example:
Router> enable
Step 2 show running-config [interface | map-class] Displays the running configuration of the router so that you
device.
Example:
next step.
• The optional interface keyword displays
interface-specific configuration information.
• The optional map-class keyword displays dialer or
Frame Relay map-class information.
Example:
20

Step 4 snmp-server community string [view view-name] Sets up the community access string to permit access to
[ro | rw] [ipv6 nacl] [access-list-number] SNMP for the MIBs.
• The string argument consists of 1 to 32 alphanumeric
Example: characters and functions much like a password,
Router(config)# snmp-server community public ro permitting access to SNMP. Blank spaces are not
permitted in the community string.
• The optional view view-name keyword argument
combination specifies a previously defined view. The
view defines the objects available to the SNMP
community.
access to the objects in the MIBs.
• The optional rw keyword specifies read-write access.
Authorized management stations can both retrieve and
modify MIB objects.
• The optional ipv6 nacl keyword argument combination
specifies an IPv6 named access list.
• The optional access-list-number argument is an integer
from 1 to 99 that specifies a standard access list of IP
addresses or a string (not to exceed 64 characters) that
is the name of a standard access list of IP addresses
allowed access to the SNMP agent. Alternatively, it is
an integer from 1300 to 1999 that specifies a list of IP
addresses in the expanded range of standard access list
numbers that are allowed to use the community string
to gain access to the SNMP agent.
Example:
Router(config)# end
Example:
Configuring the Pseudowire Class

PE routers. You configure the connection, called a pseudowire, between the routers.
Note In simple configurations, this task is optional. You do not need to specify a pseudowire class if you
specify the tunneling method as part of the xconnect command.
21
The pseudowire-class configuration group specifies the following characteristics of the tunneling
mechanism:
You must specify the encapsulation mpls command as part of the pseudowire class or as part of the
xconnect command for the AToM VCs to work properly. If you omit the encapsulation mpls command
as part of the xconnect command, you receive the following error:
Once you specify the encapsulation mpls command, you cannot remove it using the no encapsulation
mpls command. Nor can you change the command's setting using the encapsulation l2tpv3 command.
Those methods result in the following error message:
Encapsulation changes are not allowed on an existing pw-class.
To remove the command, you must delete the pseudowire with the no pseudowire-class command. To
change the type of encapsulation, remove the pseudowire with the no pseudowire-class command and
reestablish the pseudowire and specify the new encapsulation type.
Note There are many options that you can configure. For detailed information, see the “Any Transport over
MPLS” module.
SUMMARY STEPS
1. enable
DETAILED STEPS

Example:
Router> enable
Example:
22
Configuration Examples for the Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM

Step 3 pseudowire-class name Establishes a pseudowire class with a name that you specify and enters
Example:
type is mpls.
Example:
What to Do Next
Perform a MIB walk using your SNMP management tool on cpwVcMIB, cpwVcMplsMIB,
cpwVcEnetMIB, cpwVcFrMIB, and cpwVcAtmMIB to verify that the PW-MIB, the PW-MPLS-MIB,
the PW-ENET-MIB, the PW-FR-MIB, and the PW-ATM-MIB objects, respectively, are populated
correctly.
Note SNMPv1 and SNMPv2c are supported.
Configuration Examples for the Pseudowire Emulation

Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM
Services
• PWE3 MIBs: Example, page 23
PWE3 MIBs: Example

In the following example, the configuration permits any SNMP manager to access all objects with
read-only permissions using the community string public.
Router(config)# snmp-server community public ro
Note There is no explicit way to configure the PWE3 MIBs. However, for information on AToM configuration
tasks and examples, see the “Any Transport over MPLS” module.
There are notifications specific to the PWE3 MIBs. For detailed information on the commands used to
configure them, see the “Additional References” section on page 24.
23
The following sections provide references related to the Pseudowire Emulation Edge-to-Edge MIBs for
Ethernet, Frame Relay, and ATM Services feature.
Related Documents
Description of commands associated with MPLS Cisco IOS Multiprotocol Label Switching Command Reference
and MPLS applications
AToM and MPLS “Any Transport over MPLS” module
Pseudowire-related Internet drafts • An Architecture for Multi-Segment Pseudo Wire Emulation
Edge-to-Edge, Internet draft, December 2007
[draft-ietf-pwe3-ms-arch-03.txt]
• Definitions for Textual Conventions and OBJECT-IDENTITIES for
Pseudo-Wires Management, Internet draft, August 10, 2007
[draft-ietf-pwe3-pw-tc-mib-09.txt]
• Ethernet Pseudo Wire (PW) Management Information Base, Internet
draft, August 30, 2007 [draft-pwe3-enet-mib-10.txt]
• Managed Objects for ATM over Packet Switched Network (PSN),
Internet draft, August 8, 2007 [draft-ietf-pwe3-pw-atm-mib-02.txt]
• Pseudo Wire (PW) Management Information Base, Internet draft,
May 31, 2007 [draft-ietf-pwe3-pw-mib-11.txt]
• Pseudo Wire (PW) over MPLS PSN Management Information Base,
Internet draft, August 11, 2007 [draft-ietf-pwe3-pw-mpls-mib-11.txt]
Note For information on using SNMP MIB features, see the appropriate
documentation for your network management system.
24
Standards
Standard Title
MIBs
MIB MIBs Link
SNMP-VACM-MIB To locate and download MIBs for selected platforms, Cisco IOS XE
the following URL:
RFCs
RFC Title
TCP/IP-based Internets
RFC 1157 A Simple Network Management Protocol (SNMP)
TCP/IP-based Internets: MIB-II
RFC 1315 Management Information Base for Frame Relay DTEs
RFC 3815 Definitions of Managed Objects for the Multiprotocol Label
Switching (MPLS), Label Distribution Protocol (LDP)
RFC 3916 Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)
RFC 4619 Encapsulation Methods for Transport of Frame Relay over
Multiprotocol Label Switching (MPLS) Networks
25
Description Link
26
Feature Information for Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM Services
Feature Information for Pseudowire Emulation Edge-to-Edge

MIBs for Ethernet, Frame Relay, and ATM Services
Table 14 Feature Information for Pseudowire Emulation Edge-to-Edge MIBs for Ethernet, Frame Relay, and ATM
Services

Pseudowire Emulation Edge-to-Edge MIBs Cisco IOS The Pseudowire Emulation Edge-to-Edge MIBs for
for Ethernet, Frame Relay, and ATM Release XE 2.3 Ethernet, Frame Relay, and ATM Services feature provides
Services Simple Network Management Protocol (SNMP) support
within an Any Transport over Multiprotocol Label
Switching (AToM) infrastructure emulating Ethernet,
Frame Relay, and ATM services over packet switched
networks (PSNs).
In Cisco IOS Release XE 2.3, this feature was integrated
into the releases as the Pseudowire Emulation Edge-to-Edge
(PWE3) MIBs providing SNMP support within an Any
Transport over Multiprotocol Label Switching (AToM)
infrastructure emulating Ethernet, Frame Relay, and ATM
services over packet switched networks (PSNs).
27
Glossary
Glossary
AAL—ATM adaptation layer. AAL defines the conversion of user information into cells. AAL1 and
AAL2 handle isochronous traffic, such as voice and video; AAL3/4 and AAL5 pertain to data
communications through the segmentation and reassembly of packets.
ATM—asynchronous transfer mode. A cell-based data transfer technique in which channel demand
determines packet allocation. This is an international standard for cell relay in which multiple service
advantage of high-speed transmission media such as E3, SONET, and T3.
DLCI—data-link connection identifier. A unique number assigned to a PVC endpoint in a Frame Relay
network. Identifies a particular PVC endpoint within an access channel in a Frame Relay network and
has local significance only to that channel.
encapsulation—Wrapping of data in a particular protocol header. For example, Ethernet data is wrapped
in a specific Ethernet header before network transit. Also, when bridging occurs in dissimilar networks,
the entire frame from one network is simply placed in the header used by the data link layer protocol of
the other network.
EoMPLS—Ethernet over multiprotocol label switching (MPLS). A tunneling mechanism that allows a
service provider to tunnel customer Layer 2 traffic through a Layer 3 MPLS network. EoMPLS is a
point-to-point solution only. EoMPLS is also known as Layer 2 tunneling.
Frame Relay—The industry standard, switched data link layer protocol that handles multiple virtual
circuits using High-Level Data Link Control (HDLC) encapsulation between connected devices. Frame
Relay is more efficient than X.25, the protocol for which it is generally considered a replacement.
IETF—internet engineering task force. A task force (consisting of more than 80 working groups) that
is developing standards for the Internet and the IP suite of protocols.
LDP—label distribution protocol. The protocol that supports MPLS hop-by-hop forwarding and the
distribution of bindings between labels and network prefixes. The Cisco proprietary version of this
protocol is the Tag Distribution Protocol (TDP).
LSP—label switched path. A configured connection between two label switch routers (LSRs) in which
label-switching techniques are used for packet forwarding; also a specific path through an MPLS network.
LSR—label switch router. A Multiprotocol Label Switching (MPLS) node that can forward native Layer 3
packets. The LSR forwards a packet based on the value of a label attached to the packet.
MIB—management information base. A database of network management information that is used and
maintained by a network management protocol such as simple network management protocol (SNMP).
The value of a MIB object can be changed or retrieved by using SNMP commands, usually through a
network management system. MIB objects are organized in a tree structure that includes public
MPLS—multiprotocol label switching. A switching method for the forwarding of IP traffic through the
use of a label. This label instructs the routers and the switches in the network where to forward the
packets based on preestablished IP routing information.
MTU—maximum transmission unit. Maximum packet size, in bytes, that a particular interface can
handle.
NMS—network management system. System responsible for managing at least part of a network. An
NMS is generally a reasonably powerful and well-equipped computer, such as an engineering
workstation. An NMS communicates with agents to help keep track of network statistics and resources.
28
Glossary
management station, console, or terminal to indicate that a significant network event has occurred. See
also trap.
balancing.
PE router—provider edge router. A router that is part of a service provider’s network and is connected
to a customer edge (CE) router.
primary tunnel—A tunnel whose label-switched path (LSP) may be fast rerouted if there is a failure.
Backup tunnels cannot be primary tunnels.
pseudowire—PW. A mechanism that carries the elements of an emulated service from one provider edge
(PE) to one or more PEs over a packet switched network (PSN).
SNMP—simple network management protocol. A management protocol used almost exclusively in
TCP/IP networks. SNMP provides a means for monitoring and controlling network devices, and for
managing configurations, statistics collection, performance, and security.
trap—A message sent by an SNMP agent to a network management station, console, or terminal,
indicating that a significant event occurred. Traps are less reliable than notification requests because the
receiver does not send an acknowledgment when it receives a trap. The sender cannot determine if the
trap was received.
tunnel—A secure communication path between two peers, such as routers.
VC—virtual circuit. A logical circuit created to ensure reliable communication between two network
devices. A virtual circuit can be either permanent (PVC) or switched (SVC).
countries.
coincidental.
29
Glossary
30
MPLS Traffic Engineering—Fast Reroute MIB

The MPLS Traffic Engineering—Fast Reroute MIB provides Simple Network Management Protocol
(SNMP)-based network management of the Multiprotocol Label Switching (MPLS) Fast Reroute (FRR)
feature in Cisco IOS XE software.
The Fast Reroute MIB has the following features:
• Notifications can be created and queued.
• Command-line interface (CLI) commands enable notifications, and specify the IP address to where
the notifications will be sent.
• The configuration of the notifications can be written into nonvolatile memory.
The MIB includes objects describing features within MPLS FRR, and it includes the following tables:
• cmplsFrrConstTable
• cmplsFrrLogTable
• cmplsFrrFacRouteDBTable
The MIB also includes scalar objects (that is, objects that are not in a table). For more information, see
the “FRR MIB Scalar Objects” section on page 4.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering—Fast Reroute
MIB” section on page 17.
Contents
Contents
• Prerequisites for the MPLS Traffic Engineering—Fast Reroute MIB, page 2
• Restrictions for the MPLS Traffic Engineering—Fast Reroute MIB, page 2
• Information About the MPLS Traffic Engineering—Fast Reroute MIB, page 3
• How to Configure the MPLS Traffic Engineering—Fast Reroute MIB, page 8
• Configuration Examples for the MPLS Traffic Engineering—Fast Reroute MIB, page 13
• Feature Information for MPLS Traffic Engineering—Fast Reroute MIB, page 17
Prerequisites for the MPLS Traffic Engineering—Fast Reroute

MIB
• The network must support the Intermediate System-to-Intermediate System (IS-IS) or Open Shortest
Path First (OSPF) protocol.
• The SNMP is installed and enabled on the label switch routers (LSRs).
• MPLS is enabled globally on each LSR.
• Cisco Express Forwarding is enabled on the LSRs.
• Traffic engineering (TE) tunnels are enabled.
• MPLS FRR is enabled on one of the TE tunnels.
• The Resource Reservation Protocol (RSVP) is enabled.
Restrictions for the MPLS Traffic Engineering—Fast Reroute

MIB
• The implementation of the FRR MIB is limited to read-only (RO) permission for MIB objects.
• The following tables are not implemented:
– mplsFrrOne2OnePlrTable
– mplsFrrDetourTable.
2
Information About the MPLS Traffic Engineering—Fast Reroute MIB
Information About the MPLS Traffic Engineering—Fast Reroute

MIB
To use the MPLS Traffic Engineering—Fast Reroute MIB, you need to understand the following
concepts:
• Feature Design of the MPLS Traffic Engineering—Fast Reroute MIB, page 3
• Functional Structure of the MPLS Traffic Engineering—Fast Reroute MIB, page 3
• System Flow of SNMP Protocol Requests and Response Messages, page 4
• FRR MIB Scalar Objects, page 4
• FRR MIB Notifications, page 5
• MIB Tables in the MPLS Traffic Engineering—Fast Reroute MIB, page 6
Feature Design of the MPLS Traffic Engineering—Fast Reroute MIB

The FRR MIB enables standard, SNMP-based network management of FRR in Cisco IOS XE software.
This capability requires that SNMP agent code executes on a designated network management station
(NMS) in the network. The NMS serves as the medium for user interaction with the network
management objects in the MIB.
The FRR MIB is based on the Internet Engineering Task Force (IETF) draft MIB specification
draft-ietf-mpls-fastreroute-mib-02.txt. The IETF draft MIB, which undergoes revisions periodically, is
evolving toward becoming a standard. The Cisco implementation of the FRR MIB is expected to track
the evolution of the IETF draft MIB, and may change accordingly.
Slight differences between the IETF draft MIB and the implementation of FRR within Cisco IOS XE
software require some minor translations between the FRR MIB objects and the internal data structures
of Cisco IOS XE software. These translations are accomplished by the SNMP agent, which runs in the
background on the NMS workstation as a low priority process and provides a management interface to
Cisco IOS XE software.
You can use an SNMP agent to access FRR MIB objects using standard SNMP GET operations. All the
objects in the FRR MIB follow the conventions defined in the IETF draft MIB.
Functional Structure of the MPLS Traffic Engineering—Fast Reroute MIB

The SNMP agent code supporting the FRR MIB follows the existing model for such code in
Cisco IOS XE software and is, in part, generated by the Cisco IOS XE tool set, based on the MIB source
code. The basis for the generated code is the Cisco IOS XE version of the FRR MIB CISCO-ietf-frr-mib.
The SNMP agent code, which has a layered structure that is common to MIB support code in
Cisco IOS XE software, consists of the following layers:
• Platform-independent layer—This layer is generated primarily by the MIB development
Cisco IOS XE tool set and incorporates platform- and implementation-independent functions. These
functions handle SNMP standard functionality in the context of the specific MIB. This layer handles
indexes and range or enumeration value checks for GET, GET-NEXT, and SET SNMP operations.
A function is generated for each SNMP table or group of objects. This layer calls into the next layer.
• Application interface layer—The Cisco IOS XE tool set generates the function names and template
code for MIB objects.
3
• Application-specific layer—This layer provides the mechanism for retrieving relevant data from the
managed application layer. It includes an entry point function for each table. This function calls two
other functions; one that searches the TE tunnel database that RSVP maintains for the relevant data
according to the indexes, and another function that fills the data into the structure.
• Managed application layer—This layer includes all the structures and mechanisms, and is managed
by the MIB.
System Flow of SNMP Protocol Requests and Response Messages

All SNMP protocol requests and response messages are ultimately handled by the SNMP master agent.
When such a message is received on a router, the master agent parses the requests and identifies the MIB
to which the request refers. The master agent then queries the subagent responsible for the MIB with a
GET, GET-NEXT, or SET request. The FRR MIB subagent retrieves the appropriate data, and returns it
to the master agent. The master agent is then responsible for returning an SNMP response to the NMS.
All queries occur within the IP SNMP Cisco IOS XE process, which runs as a low priority task.
FRR MIB Scalar Objects

Scalar objects are objects that are not in tables. A scalar object has one instance (that is, one occurrence).
Table 1 describes the FRR MIB scalar objects.
Table 1 Scalar Objects
MIB Object Function

cmplsFrrDetourIncoming Number of detour link-state packets (LSPs) entering the device. This object
returns 0 because cmplsFrrConstProtectionMethod is set to facilityBackup(1).
cmplsFrrDetourOutgoing Number of detour LSPs leaving the device. This object returns 0 because
cmplsFrrConstProtectionMethod is set to facilityBackup(1).
cmplsFrrDetourOriginating Number of detour LSPs originating from the device. This object returns 0
because cmplsFrrConstProtectionMethod is set to facilityBackup(1).
cmplsFrrSwitchover Number of tunnels that are being backed up because
cmplsFrrNumOfConfIfs Number of MPLS interfaces FRR configured for protection; 0 indicates that LSPs
traversing any interface can be protected.
cmplsFrrActProtectedIfs Number of interfaces FRR is protecting because
cmplsFrrConfProtectingTuns Number of backup Fast Reroute-protected tunnels configured because
cmplsFrrActProtectedTuns Number of tunnels protected by the Fast Reroute feature. This object returns 0
because cmplsFrrConstProtectionMethod is set to facilityBackup(1).
cmplsFrrActProtectedLSPs Number of LSPs that FRR is protecting. If cmplsFrrConstProtectionMethod is
set to facilityBackup(1), this object returns 0.
cmplsFrrConstProtectionMethod This object always returns facilityBackup(1) because Cisco IOS XE supports
only the facility backup protection method.
4
Table 1 Scalar Objects (continued)
MIB Object Function

cmplsFrrNotifsEnabled A value that indicates whether FRR notifications defined in this MIB are enabled
or disabled. This object returns True(1) for enabled, or False(2) for disabled. The
default is that notifications are disabled.
cmplsFrrLogTableMaxEntries Maximum number of entries allowed in the FRR log table.
cmplsFrrLogTableCurrEntries Current number of entries in the FRR log table. This object always returns 0.
cmplsFrrNotifMaxRate Maximum interval rate between FRR MIB notifications. This object always
returns 0.
FRR MIB Notifications

Notifications are issued after particular FRR events occur. This section provides the following
information about FRR MIB notifications:
• Notification Generation Events, page 5
• Notification Specification, page 5
• Notification Monitoring, page 6
Notification Generation Events

When you enable FRR MIB notification functionality by issuing the snmp-server enable traps mpls
fast-reroute command, FRR events generate notification messages that are sent to a designated NMS in
the network to signal the occurrence of specific events in Cisco IOS XE software.
The FRR MIB objects involved in FRR status transitions and event notifications include
cmplsFrrProtected. This message is sent to an NMS if there is a major TE tunnel change (that is, fast
rerouting of TE tunnels).
Notification Specification
Each FRR notification has a generic type identifier and an enterprise-specific type identifier for
identifying the notification type. The generic type for all FRR notifications is “enterprise Specific”
because this is not one of the generic notification types defined for SNMP. The enterprise-specific type
is 1 for cmplsFrrProtected.
Each notification contains the following objects from the FRR MIB so that the FRR tunnel can be easily
identified:
• cmplsFrrConstNumProtectingTunOnIf
• cmplsFrrConstNumProtectedTunOnIf
• cmplsFrrConstBandwidth
Upon being invoked, the appropriate FRR interface indexes have already been retrieved by existing FRR
code. The FRR interfaces are then used to fill in data for the three objects included in the notification.
5
Notification Monitoring
When FRR MIB notifications are enabled (see the snmp-server enable traps command), notification
messages relating to specific FRR events within Cisco IOS XE software are generated and sent to a
specified NMS in the network. Any utility that supports SNMPv1 or SNPv2 notifications can receive
notification messages.
To monitor FRR MIB notifications, log in to an NMS that supports a utility that displays SNMP
notifications, and start the display utility.
MIB Tables in the MPLS Traffic Engineering—Fast Reroute MIB

The FRR MIB consists of the following tables:
• cmplsFrrConstTable, page 6
• cmplsFrrLogTable, page 7
• cmplsFrrFacRouteDBTable, page 7
The tables access various data structures to obtain information regarding detours, the FRR database, and
logging.
cmplsFrrConstTable
cmplsFrrConstTable displays the configuration of an FRR-enabled tunnel and the characteristics of its
accompanying backup tunnels. For each protected tunnel, there can be multiple backup tunnels.
The table is indexed by the following:
• cmplsFrrConstIfIndex
• cmplsFrrConstTunnelIndex
• cmplsFrrConstTunnelInstance
Table 2 describes the MIB objects for cmplsFrrConstTable.
Table 2 cmplsFrrConstTable Objects
MIB Object Function

cmplsFrrConstIfIndex Uniquely identifies an interface on which FRR is configured. If an index has
a value of 0, the configuration applies to all interfaces on the device on which
the FRR feature can operate.
cmplsFrrConstTunnelIndex Tunnel for which FRR is requested.
cmplsFrrConstTunnelInstance Tunnel for which FRR is requested. The value always is 0 because only
tunnel heads are represented, and tunnel heads have an instance value of 0.
cmplsFrrConstSetupPrio Setup priority of the backup tunnel.
cmplsFrrConstHoldingPrio Holding priority of the backup tunnel.
cmplsFrrConstInclAnyAffinity Attribute bits that must be set for the tunnel to traverse a link.
cmplsFrrConstInclAllAffinity Attribute bits that must not be set for the tunnel to traverse a link.
cmplsFrrConstExclAllAffinity A link satisfies the exclude-all constraint only if the link contains none of the
administrative groups specified in the constraint.
6
Table 2 cmplsFrrConstTable Objects (continued)
MIB Object Function

cmplsFrrConstHopLimit The maximum number of hops that the backup tunnel can traverse.
cmplsFrrConstBandwidth The bandwidth of the backup tunnels for this tunnel, in thousands of bits per
second (kbps).
cmplsFrrConstRowStatus Creates, modifies, and deletes a row in this table.
cmplsFrrLogTable
cmplsFrrLogTable is indexed by the object cmplsFrrLogIndex. The index corresponds to a log entry in
the FRR feature’s show mpls traffic-eng fast-reroute log reroutes command. That show command
stores up to 32 entries at a time. If entries are added, the oldest entry is overwritten with new log
information.
cmplsFrrLogTable can store up to 32 entries at a time, overwriting older entries as newer ones are added.
The index cmplsFrrLogIndex is incremented to give each log table entry of the MIB a unique index
value. Therefore, it is possible to have indexes greater than 32 even though only 32 entries are displaying.
Table 3 describes the MIB objects for cmplsFrrLogTable.
Table 3 cmplsFrrLogTable Objects
MIB Object Function

cmplsFrrLogIndex Number of the FRR event.
cmplsFrrLogEventTime Number of milliseconds that elapsed from bootstrap time to the time that the
event occurred.
cmplsFrrLogInterface Identifies the interface that was affected by this FRR event. The value can be
set to 0 if mplsFrrConstProtectionMethod is set to oneToOneBackup(0).
cmplsFrrLogEventType The type of FRR event that occurred. The object returns Protected or Other.
cmplsFrrLogEventDuration Duration of the event, in milliseconds.
cmplsFrrLogEventReasonString Implementation-specific explanation of the event. The object returns
interface down event or interface other event.
cmplsFrrFacRouteDBTable
The following indexes specify which interface and tunnel are being protected by the FRR feature:
• cmplsFrrFacRouteProtectedIfIndex
• cmplsFrrFacRouteProtectedTunIndex
The following indexes specify the backup tunnel that provides protection to the protected tunnel:
• cmplsFrrFacRouteProtectedIfIndex
• cmplsFrrFacRouteProtectingTunIndex
• cmplsFrrFacRouteProtectedTunIndex
• cmplsFrrFacRouteProtectedTunInstance
• cmplsFrrFacRouteProtectedTunIngressLSRId
• cmplsFrrFacRouteProtectedTunEgressLSRId
7
How to Configure the MPLS Traffic Engineering—Fast Reroute MIB
This version of the MIB will attempt to leverage the work already done for the MPLS TE MIB because
it contains similar lookup functions for TE tunnels.
Table 4 describes the MIB objects for cmplsFrrFacRouteDBTable.
Table 4 cmplsFrrFacRouteDBTable Objects
MIB Object Function

cmplsFrrFacRouteProtectedIfIndex Interface configured for FRR protection.
cmplsFrrFacRouteProtectingTunIndex The tunnel number of the protecting (backup) tunnel.
cmplsFrrFacRouteProtectedTunIndex The mplsTunnelEntry primary index for the tunnel head interface
designated to protect the interface specified in
mplsFrrFacRouteIfProtIdx (and all the tunnels using this interface).
cmplsFrrFacRouteProtectedTunInstance An mplsTunnelEntry that is being protected by FRR. An instance
uniquely identifies a tunnel.
cmplsFrrFacRouteProtectedTunIngressLSRId Inbound label for the backup LSR.
cmplsFrrFacRouteProtectedTunEgressLSRId Outbound label for the backup LSR.
cmplsFrrFacRouteProtectedTunStatus State of the protected tunnel. Valid values are:
• active—Tunnel label has been placed in the Label Forwarding
Information Base (LFIB) and is ready to be applied to incoming
packets.
• ready—Tunnel’s label entry has been created, but is not in the
LFIB.
• partial—Tunnel’s label entry has not been fully created.
cmplsFrrFacRouteProtectingTunResvBw Amount of bandwidth, in megabytes per second, that is reserved by the
backup tunnel.
cmplsFrrFacRouteProtectingTunProtectionType Type of protection: 0 designates link protection; 1 designates node
protection.
How to Configure the MPLS Traffic Engineering—Fast Reroute

MIB
• Enabling the SNMP Agent for FRR MIB Notifications, page 8 (required)
• Enabling Cisco Express Forwarding, page 10 (required)
• Enabling TE Tunnels, page 10 (required)
• Enabling MPLS FRR on Each TE Tunnel, page 11 (required)
• Enabling a Backup Tunnel on an Interface, page 12 (required)
Enabling the SNMP Agent for FRR MIB Notifications

To enable the SNMP agent for FRR MIB notifications, perform the following steps.
8
SUMMARY STEPS
1. enable
4. snmp-server community string [view view-name] [ro] [access-list-number]
5. snmp-server enable traps mpls fast-reroute protected
6. end
7. write memory
DETAILED STEPS

Example:
Router> enable
Step 2 show running-config Displays the running configuration of the router to
determine if an SNMP agent is already running on
the device.
Example:
Router# show running-config If no SNMP information is displayed, continue with
the next step.
If any SNMP information is displayed, you can
modify or change the information.
Example:
Step 4 snmp-server community string [view view-name] [ro] Configures read-only (ro) SNMP community strings
[access-list-number] for the FRR MIB.
Example:
Router(config)# snmp-server community public ro
Step 5 snmp-server enable traps mpls fast-reroute protected Enables Fast Reroute traps.
Example:
fast-reroute protected
9

Example:
Router(config)# end
Step 7 write memory Writes the modified SNMP configuration into
NVRAM of the router, permanently saving the
SNMP settings.
Example:
Enabling Cisco Express Forwarding

To enable Cisco Express Forwarding, perform the following steps.
SUMMARY STEPS
1. enable
4. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example:
Router(config)# end
Enabling TE Tunnels
To enable TE tunnels, perform the following steps.
10
SUMMARY STEPS
1. enable
3. ip cef
7. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef Enables standard Cisco Express Forwarding operations.
Example:
Step 4 mpls traffic-eng tunnels Enables the MPLS TE tunnel feature on a device.
Example:
Step 5 interface type slot/subslot/port[.subinterface] Specifies the interface and enters interface configuration
mode.
Example:
Step 6 mpls traffic-eng tunnels Enables the MPLS TE tunnel feature on an interface.
Example:
Example:
Enabling MPLS FRR on Each TE Tunnel

To enable MPLS FRR on each TE tunnel, perform the following steps.
11
SUMMARY STEPS
1. enable
5. tunnel mpls traffic-eng fast-reroute
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/subslot/port[.subinterface] Specifies the interface and enters interface
configuration mode.
Example:
Step 4 tunnel mode mpls traffic-eng Sets the mode of a tunnel to MPLS for traffic
engineering.
Example:
Step 5 tunnel mpls traffic-eng fast-reroute Enables Fast Reroute on the TE tunnel being
protected.
Example:
Example:
Enabling a Backup Tunnel on an Interface

To enable a backup tunnel on an interface, perform the following steps.
SUMMARY STEPS
1. enable
12
Configuration Examples for the MPLS Traffic Engineering—Fast Reroute MIB

4. mpls traffic-eng backup-path tunnel interface
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/subslot/port[.subinterface] Specifies the interface and enters interface
configuration mode.
Example:
Step 4 mpls traffic-eng backup-path tunnel interface Enables a backup tunnel on a specified interface.
Example:
Example:
Configuration Examples for the MPLS Traffic Engineering—Fast

Reroute MIB
• Enabling an SNMP Agent on a Host NMS: Example, page 13
• Enabling Cisco Express Forwarding: Example, page 14
• Enabling TE Tunnels: Example, page 14
• Enabling MPLS FRR on Each TE Tunnel: Example, page 14
• Enabling a Backup Tunnel on an Interface: Example, page 14
Enabling an SNMP Agent on a Host NMS: Example

enable
show running-config
configure terminal
snmp-server community public ro
snmp-server enable traps mpls fast-reroute protected
13
end
write memory
Enabling Cisco Express Forwarding: Example

The following example shows how to enable Cisco Express Forwarding:
enable
configure terminal
ip cef
end
Enabling TE Tunnels: Example

The following example shows how to enable traffic engineering tunnels:
enable
configure terminal
ip cef
end
Enabling MPLS FRR on Each TE Tunnel: Example

The following example shows how to enable MPLS Fast Reroute on each TE tunnel:
enable
configure terminal
interface POS1/0/0
tunnel mpls traffic-eng fast-reroute
end
Enabling a Backup Tunnel on an Interface: Example

The following example shows how to enable a backup tunnel on an interface:
enable
configure terminal
interface POS1/0/0
mpls traffic-eng backup-path tunnel1
end
The following sections provide references related to the MPLS Traffic Engineering—Fast Reroute MIB
feature.
14
Related Documents
MPLS applications
SNMP agent support for the MPLS Traffic Engineering MPLS Traffic Engineering MIB
MIB
Fast Reroute MPLS Traffic Engineering: Fast Reroute Link and Node Protection
Standards
Standard Title
MPLS-FRR-MIB draft-ietf-mpls-fastreroute-mib-02.txt
MIBs
MIB MIBs Link
MPLS Traffic Engineering (TE) MIB To locate and download MIBs for selected platforms, Cisco IOS XE
the following URL:
RFCs
RFC Title
No new or modified RFCs are supported by this feature, —
and support for existing RFCs has not been modified by
this feature.
15
Description Link
16
Feature Information for MPLS Traffic Engineering—Fast Reroute MIB
Feature Information for MPLS Traffic Engineering—Fast Reroute

MIB
Table 5 Feature Information for MPLS Traffic Engineering—Fast Reroute MIB

MPLS Embedded Management—MPLS Cisco IOS XE The Fast Reroute MIB provides SNMP-based network
Fast Reroute MIB (IETF draft v01) Release 2.3 management of the Multiprotocol Label Switching (MPLS)
Fast Reroute (FRR) feature in Cisco IOS XE software.
feature.
• Information About the MPLS Traffic
Engineering—Fast Reroute MIB, page 3
• How to Configure the MPLS Traffic Engineering—Fast
Reroute MIB, page 8
17
Glossary
Glossary
Cisco Express Forwarding—An advanced Layer 3 IP switching technology. Cisco Express Forwarding
optimizes network performance and scalability for networks with large and dynamic traffic patterns.
index—A method of uniquely identifying a tunnel.
instance—An occurrence. An object can have one or more instances.
IS-IS—Intermediate System-to-Intermediate System. IS-IS is an OSI link-state hierarchical routing
protocol based on DECnet Phase V routing where intermediate system (IS) routers exchange routing
information based on a single metric to determine network topology.
cells).
LFIB—Label Forwarding Information Base. The data structure for storing information about incoming
and outgoing tags (labels) and associated equivalent packets suitable for labeling.
LSR—label switching router. A device that forwards MPLS packets based on the value of a fixed-length
The value of a MIB object can be changed or retrieved by using SNMP commands, usually through a
network management system. MIB objects are organized in a tree structure that includes public
NMS—network management station. A powerful, well-equipped computer (typically an engineering
network administration and configuration tasks.
management station, console, or terminal to indicate that a significant event within Cisco IOS XE
software has occurred.
object—A variable that has a specific instance associated with it.
OSPF—Open Shortest Path First. Link-state, hierarchical Interior Gateway Protocol (IGP) routing
algorithm proposed as a successor to Routing Information Protocol (RIP) in the Internet community.
OSPF features include least-cost routing, multipath routing, and load balancing.
RSVP—Resource Reservation Protocol. Protocol for reserving network resources to provide quality of
service (QoS) guarantees to application flows.
scalar object—Objects that are not instances. A scalar object has one instance.
exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices,
manage configurations, collect statistics, monitor performance, and ensure network security.
SNMP agent—A managed node or device. The router that has the MIB implementation on it.
18
Glossary
coincidental.
19
Glossary
20
MPLS Traffic Engineering MIB

The MPLS Traffic Engineering MIB enables Simple Network Management Protocol (SNMP) agent
support in Cisco IOS XE software for Multiprotocol Label Switching (MPLS) traffic engineering (TE)
management, as implemented in the MPLS Traffic Engineering MIB (MPLS TE MIB). The SNMP agent
code operating in conjunction with the MPLS TE MIB enables a standardized, SNMP-based approach
to be used in managing the MPLS TE features in Cisco IOS XE software.

which each feature is supported, see the “Feature Information for the MPLS Traffic Engineering MIB”
section on page 15.
Contents
• Restrictions for the MPLS Traffic Engineering MIB, page 2
• Information About the MPLS Traffic Engineering MIB, page 2
• How to Configure the MPLS Traffic Engineering MIB, page 11
• Configuration Examples for the MPLS Traffic Engineering MIB, page 13
• Feature Information for the MPLS Traffic Engineering MIB, page 15
Restrictions for the MPLS Traffic Engineering MIB
Restrictions for the MPLS Traffic Engineering MIB

The following restrictions apply to the MPLS TE MIB for Cisco IOS XE releases:
• Supports read-only (RO) permission for MIB objects.
• Contains no configuration support by means of SET functions, except for the
mplsTunnelTrapEnable object (which has been made writable). Accordingly, the MPLS TE MIB
contains indexing support for the Interfaces MIB.
• Supports only SNMP GET, GETNEXT, and GETBULK retrieval functions, except in the case of the
mplsTunnelTrapEnable object (which has been made writable by means of SET functions).
• Contains no support for Guaranteed Bandwidth Traffic Engineering (GBTE) or Auto Bandwidth
features.
Information About the MPLS Traffic Engineering MIB

• MPLS Traffic Engineering MIB Cisco Implementation, page 2
• Capabilities Supported by the MPLS Traffic Engineering MIB, page 3
• Notification Implementation, page 4
• Benefits of the MPLS Traffic Engineering MIB, page 4
• MPLS Traffic Engineering MIB Layer Structure, page 4
• Features and Technologies Related to the MPLS Traffic Engineering MIB, page 5
• Supported Objects in the MPLS Traffic Engineering MIB, page 5
• CLI Access to MPLS Traffic Engineering MIB Information, page 9
MPLS Traffic Engineering MIB Cisco Implementation

The MPLS TE MIB is based on the Internet Engineering Task Force (IETF) draft MIB entitled
draft-ietf-mpls-te-mib-05.txt which includes objects describing features that support MPLS TE.
Slight differences between the IETF draft MIB and the implementation of the TE capabilities within
Cisco IOS XE software require some minor translations between the MPLS TE MIB and the internal
data structures of Cisco IOS XE software. These translations are made by the SNMP agent code that is
installed and operating on various hosts within the network. This SNMP agent code, running in the
background as a low priority process, provides a management interface to Cisco IOS XE software.
The SNMP objects defined in the MPLS TE MIB can be displayed by any standard SNMP utility. All
MPLS TE MIB objects are based on the IETF draft MIB; thus, no specific Cisco SNMP application is
required to support the functions and operations pertaining to the MPLS TE MIB.
MPLS Traffic Engineering Overview

MPLS TE capabilities in Cisco IOS XE software enable an MPLS backbone to replicate and expand
upon the TE capabilities of Layer 2 ATM and Frame Relay networks.
2
TE capabilities are essential to effective management of service provider and Internet service provider
(ISP) backbones. Such backbones must support high transmission capacities, and the networks
incorporating backbones must be extremely resilient to link or node failures.
The MPLS TE facilities built into Cisco IOS XE software provide a feature-rich, integrated approach to
managing the large volumes of traffic that typically flow through WANs. The MPLS TE facilities are
integrated into Layer 3 network services, thereby optimizing the routing of IP traffic in the face of
constraints imposed by existing backbone transmission capacities and network topologies.
Capabilities Supported by the MPLS Traffic Engineering MIB

The following functionality is supported in the MPLS Traffic Engineering MIB:
• The ability to generate and queue notification messages that signal changes in the operational status
of MPLS TE tunnels.
• Extensions to existing SNMP commands that provide the ability to enable, disable, and configure
notification messages for MPLS TE tunnels.
• The ability to specify the name or the IP address of a network management station (NMS) in the
operating environment to which notification messages are to be sent.
• The ability to write notification configurations into nonvolatile memory.
Notification Generation Events

When MPLS TE notifications are enabled (see the snmp-server enable traps (mpls) command),
notification messages relating to specific events within Cisco IOS XE software are generated and sent
to a specified NMS in the network.
For example, an mplsTunnelUp notification is sent to an NMS when an MPLS TE tunnel is configured
and the tunnel transitions from an operationally “down” state to an “up” state.
Conversely, an mplsTunnelDown notification is generated and sent to an NMS when an MPLS TE tunnel
transitions from an operationally “up” state to a “down” state.
An mplstunnelRerouted notification is sent to the NMS under the following conditions:
• The signaling path of an existing MPLS TE tunnel fails for some reason and a new path option is
signaled and placed into effect (that is, the tunnel is rerouted).
• The signaling path of an existing MPLS TE tunnel is fully operational, but a better path option can
be signaled and placed into effect (that is, the tunnel can be reoptimized). This reoptimazation can
be triggered by:
– A timer
– The issuance of an mpls traffic-eng reoptimize command
– A configuration change that requires the resignaling of a tunnel
The mplsTunnelReoptimized notification is not generated when an MPLS traffic engineering tunnel is
reoptimized. However, an mplsTunnelReroute notification is generated. Thus, at the NMS, you cannot
distinguish between a tunnel reoptimization event and tunnel reroute event.
3
Path options are configurable parameters that you can use to specify the order of priority for establishing
a new tunnel path. For example, you can create a tunnel head configuration and define any one of many
path options numbered 1 through n, with “1” being the highest priority option and “n” being an unlimited
number of lower priority path options. Thus, there is no limit to the number of path options that you can
specify in this manner.
Notification Implementation
When an MPLS TE tunnel interface (or any other device interface, such as an FastEthernet or Packet
over SONET (POS) interface) transitions between an up and down state, an Interfaces MIB (ifMIB) link
notification is generated. When such a notification occurs in an MPLS TE MIB environment, the
interface is checked by software to determine if the notification is associated with an MPLS TE tunnel.
If so, the interfaces MIB link notification is interlinked with the appropriate mplsTunnelUp or
mplsTunnelDown notification to provide notification to the NMS regarding the operational event
occurring on the tunnel interface. Hence, the generation of an Interfaces MIB link notification pertaining
to an MPLS traffic engineering tunnel interface begets an appropriate mplsTunnelUp or
mplsTunnelDown notification that is transmitted to the specified NMS.
An mplsTunnelRerouted notification is generated whenever the signaling path for an MPLS TE tunnel
changes. However, software intelligence in the MPLS TE MIB prevents the reroute notification from
being sent to the NMS when a TE tunnel transitions between an up or down state during an administrative
or operational status check of the tunnel. Either an up or down notification or a reroute notification can
be sent in this instance, but not both. This action prevents unnecessary traffic on the network.
Benefits of the MPLS Traffic Engineering MIB

The MPLS Traffic Engineering MIB provides the following benefits:
• Provides a standards-based SNMP interface for retrieving information about MPLS TE.
• Provides information about the traffic flows on MPLS TE tunnels.
• Presents MPLS TE tunnel routes, including the configured route, the Interior Gateway Protocol
(IGP) calculated route, and the actual route traversed.
• Provides information, in conjunction with the Interfaces MIB, about how a tunnel was rerouted in
the event of a link failure.
• Provides information about the configured resources used for an MPLS TE tunnel.
• Supports the generation and queueing of notifications that call attention to major changes in the
operational status of MPLS TE tunnels;
• Forwards notification messages to a designated NMS for evaluation or action by network
administrators.
MPLS Traffic Engineering MIB Layer Structure

The SNMP agent code supporting the MPLS TE MIB follows the existing model for such code in
Cisco IOS XE software and is, in part, generated by the Cisco IOS XE tool set, based on the MIB source
code.
The SNMP agent code, which has a layered structure similar to that of the MIB support code in
Cisco IOS XE software, consists of four layers:
4
• Platform independent layer—This layer is generated primarily by the Cisco IOS XE MIB
development tool set and incorporates platform and implementation independent functions. The
Cisco IOS XE MIB development tool set creates a standard set of files associated with a MIB.
• Application interface layer—The functions, names, and template code for MIB objects in this layer
are also generated by the Cisco IOS XE MIB development tool set.
• Application specific layer—This layer provides an interface between the application interface layer
and the application program interface (API) and data structures layer and performs tasks needed to
retrieve required information from Cisco IOS XE software, such as searching through data
structures.
• API and data structures layer—This layer contains the data structures or APIs within Cisco IOS XE
software that are retrieved or called in order to set or retrieve SNMP management information.
Features and Technologies Related to the MPLS Traffic Engineering MIB

The MPLS TE MIB feature is used in conjunction with the following features and technologies:
• Standards-based SNMP network management application
• MPLS
• MPLS TE
Supported Objects in the MPLS Traffic Engineering MIB

The MPLS TE MIB contains numerous tables and object definitions that provide read-only SNMP
management support for the MPLS TE features in Cisco IOS XE software. The MPLS TE MIB conforms
to Abstract Syntax Notation One (ASN.1), thus reflecting an idealized MPLS TE database.
Using any standard SNMP network management application, you can retrieve and display information
from the MPLS TE MIB by using GET operations; similarly, you can traverse information in the MIB
database for display by using GETNEXT operations.
The MPLS TE MIB tables and objects supported in Cisco IOS XE software follow. Important MIB tables
(those highlighted in bold type) are described briefly in accompanying text.
• mplsTunnelConfigured—Total number of tunnel configurations that are defined on this node.
• mplsTunnelActive—Total number of label switched paths (LSPs) that are defined on this node.
• mplsTunnelTEDistProto—The IGP distribution protocol in use.
• mplsTunnelMaxHops—The maximum number of hops any given tunnel can utilize.
• mplsTunnelIndexNext—Unsupported; set to 0.
• mplsTunnelTable—Entries in this table with an instance of 0 and a source address of 0 represent
tunnel head configurations. All other entries in this table represent instances of LSPs, both signaled
and standby. If a tunnel instance is signaled, its operating status (operStatus) is set to “up” (1) and
its instance corresponds to an active LSP.
Tunnel configurations exist only on the tunnel head where the tunnel interface is defined. LSPs
traverse the network and involve tunnel heads, tunnel midpoints, and tunnel tails.
Pointers in the tunnel table refer to corresponding entries in other MIB tables. By using these
pointers, you can find an entry in the mplsTunnelTable and follow a pointer to other tables for
additional information. The pointers are the following: mplsTunnelResourcePointer,
mplsTunnelHopTableIndex, mplsTunnelARHopTableIndex, and mplsTunnelCHopTableIndex.
5
The tunnel table is indexed by tunnel ID, tunnel instance, tunnel source address, and tunnel
destination address. The description of each entry has an alphabetic suffix (a), (b), or (c), if
appropriate, to indicate the applicability of the entry:
a. For tunnel head configurations only
b. For LSPs only
c. For both tunnel head configurations and LSPs
Following is a list and description of each entry.
– mplsTunnelIndex—Same as tunnel ID (c).
– mplsTunnelInstance—Tunnel instance of the LSP; 0 for head configurations (b).
– mplsTunnelIngressLSRId—Source IP address of the LSP; 0 for head configurations (b).
– mplsTunnelEgressLSRId—Destination IP address of the tunnel (c).
– mplsTunnelName—Command name for the tunnel interfaces (a).
– mplsTunnelDescr—Descriptive name for tunnel configurations and LSPs (c).
– mplsTunnelIsIf—Indicator of whether the entry represents an interface (c).
– mplsTunnelIfIndex—Index of the tunnel interface within the ifMIB (a).
– mplsTunnelXCPointer—(For midpoints only – no tails) Pointer for the LSP within the
mplsXCTable of the MPLS LSR MIB (b).
– mplsTunnelSignallingProto—Signaling protocol used by tunnels (c).
– mplsTunnelSetupPrio—Setup priority of the tunnel (c).
– mplsTunnelHoldingPrio—Holding priority of the tunnel (c).
– mplsTunnelSessionAttributes—Session attributes (c).
– mplsTunnelOwner—Tunnel owner (c).
– mplsTunnelLocalProtectInUse—Not implemented (c).
– mplsTunnelResourcePointer—Pointer into the Resource Table (b).
– mplsTunnelInstancePriority—Not implemented (b).
– mplsTunnelHopTableIndex—Index into the Hop Table (a).
– mplsTunnelARHopTableIndex—Index into the AR Hop Table (b).
– mplsTunnelCHopTableIndex—Index into the C Hop Table (b).
– mplsTunnelPrimaryTimeUp—Amount of time, in seconds, that the current path has been up (a).
– mplsTunnelPathChanges—Number of times a tunnel has been resignalled (a).
– mplsTunnelLastPathChange—Amount of time, in seconds, since the last path resignaling
occurred (a).
– mplsTunnelCreationTime—Time stamp when the tunnel was created (a).
– mplsTunnelStateTransitions—Number of times the tunnel has changed state (a).
– mplsTunnelIncludeAnyAffinity—Not implemented (a).
– mplsTunnelIncludeAllAffinity—Attribute bits that must be set for the tunnel to traverse a
link (a).
– mplsTunnelExcludeAllAffinity—Attribute bits that must not be set for the tunnel to traverse a
link (a).
6
– mplsTunnelPathInUse—Path option number being used for the tunnel’s path. If no path option
is active, this object will be 0 (a).
– mplsTunnelRole—Role of the tunnel on the router; that is, head, midpoint, or tail (c).
– mplsTunneltotalUptime—Amount of time, in seconds, that the tunnel has been operationally up
(a).
– mplsTunnelInstanceUptime—Not implemented (b).
– mplsTunnelAdminStatus—Administrative status of a tunnel (c).
– mplsTunnelOperStatus—Actual operating status of a tunnel (c).
– mplsTunnelRowStatus—This object is used in conjunction with configuring a new tunnel. This
object will always be seen as “active” (a).
– mplsTunnelStorageType—Storage type of a tunnel entry (c).
• mplsTunnelHopListIndexNext—Next valid index to use as an index in the mplsTunnelHopTable.
• mplsTunnelHopTable—Entries in this table exist only for tunnel configurations and correspond to
the path options defined for the tunnel. Two types of path options exist: explicit and dynamic. This
table shows all hops listed in the explicit path options, while showing only the destination hop for
dynamic path options. The tunnel hop table is indexed by tunnel ID, path option, and hop number.
Following is a list and description of each table entry.
– mplsTunnelHopListIndex—Primary index into the table.
– mplsTunnelHopIndex—Secondary index into the table.
– mplsTunnelHopAddrType—Indicates if the address of this hop is the type IPv4 or IPv6.
– mplsTunnelHopIpv4Addr—The IPv4 address of this hop.
– mplsTunnelHopIpv4PrefixLen—The prefix length of the IPv4 address.
– mplsTunnelHopIpv6Addr—The IPv6 address of this hop.
– mplsTunnelHopIpv6PrefixLen—The prefix length of the IPv6 address.
– mplsTunnelHopAsNumber—This object will contain 0 or the autonomous system number of
the hop, depending on the value of mplsTunnelHopAddrType.
– mplsTunnelHopLspId—This object will contain 0 or the LSPID of the tunnel, depending on the
value of mplsTunnelHopAddrType.
– mplsTunnelHopType—Denotes whether this tunnel hop is routed in a strict or loose fashion.
– mplsTunnelHopRowStatus—This object is used in conjunction with the configuring of a new
row in the table.
– mplsTunnelHopStorageType—The storage type of this MIB object.
• mplsTunnelResourceIndexNext—This object contains the next appropriate value to be used for
mplsTunnelResourceIndex when creating entries in the mplsTunnelResourceTable
• mplsTunnelResourceTable—Entries in this table correspond to the “Tspec” information displayed
when you execute the show mpls traffic-eng tunnels command. These entries exist only for LSPs.
The tunnel resource table is indexed by address and hop number. Following the
mplsTunnelResourcePointer pointer from the tunnel table is the best way to retrieve information
from this table.
Following is a list and description of each table entry.
– mplsTunnelResourceIndex—The primary index into this table.
7
– mplsTunnelResourceMaxRate—The maximum rate, in bits per second, supported by this

tunnel.
– mplsTunnelResourceMeanRate—The mean rate, in bits per second, supported by this tunnel.
– mplsTunnelResourceMaxBurstSize—The maximum burst size, in bytes, allowed by this tunnel.
– mplsTunnelResourceRowStatus—This object is used in conjunction with the configuration of a
new row in the table.
– mplsTunnelResourceStorageType—The storage type of this MIB object.
• mplsTunnelARHopTable—Entries in this table correspond to the actual route taken by the tunnel,
and whose route was successfully signaled by the network. The hops present in this table correspond
to those present in the record route object (RRO) in Resource Reservation Protocol (RSVP). You can
also display the information in this table by executing the show mpls traffic-eng tunnels command.
The actual route hop table is indexed by address and hop number. Following the
mplsTunnelARHopTableIndex pointer from the tunnel table is the best way to retrieve information
from this table.
Following is a list and description of each table entry:
– mplsTunnelARHopListIndex—The primary index into this table.
– mplsTunnelARHopIndex—The secondary index into this table.
– mplsTunnelARHopIpv4Addr—The IPv4 address of this hop.
– mplsTunnelARHopIpv4PrefixLen—The prefix length of the IPv4 address.
– mplsTunnelARHopIpv6Addr—The IPv6 address of this hop.
– mplsTunnelARHopIpv6PrefixLen—The prefix length of the IPv6 address.
– mplsTunnelARHopAsNumber—This object will contain 0 or the AS number of the hop,
depending on the value of mplsTunnelARHopAddrType.
– mplsTunnelARHopAddrType—The type of address for this MIB entry, either IPv4 or IPv6.
– mplsTunnelARHopType—Denotes whether this tunnel hop is routed in a strict or loose manner.
• mplsTunnelCHopTable—Entries in this table correspond to the explicit route object (ERO) in
RSVP, which is used to signal the LSP. The list of hops in this table will contain those hops that are
computed by the constraint-based shortest path first (SPF) algorithm. In those cases where “loose”
hops are specified for the tunnel, this table will contain the hops that are “filled-in” between the
loose hops to complete the path. If you specify a complete explicit path, the computed hop table
matches your specified path.
The computed hop table is indexed by address and hop number. Following the
mplsTunnelCHopTableIndex pointer from the tunnel table is the best way to retrieve information
from this table.
Following is a list and description of each table entry:
– mplsTunnelCHopListIndex—The primary index into this table.
– mplsTunnelCHopIndex—The secondary index into this table.
– mplsTunnelCHopAddrType—Indicates if the address of this hop is the type IPv4 or IPv6.
– mplsTunnelCHopIpv4Addr—The IPv4 address of this hop.
– mplsTunnelCHopIpv4PrefixLen—The prefix length of the IPv4 address.
– mplsTunnelCHopIpv6Addr—The IPv6 address of this hop.
– mplsTunnelCHopIpv6PrefixLen—The prefix length of the IPv6 address.
8
– mplsTunnelCHopAsNumber—This object will contain 0 or the autonomous system number of

the hop, depending on the value of mplsTunnelHopAddrType.
– mplsTunnelCHopType—Denotes whether this tunnel hop is routed in a strict or loose way.
• mplsTunnelPerfTable—The tunnel performance table, which augments the mplsTunnelTable,
provides packet and byte counters for each tunnel. This table contains the following packet and byte
counters:
– mplsTunnelPerfPackets—This packet counter works only for tunnel heads.
– mplsTunnelPerfHCPackets—This packet counter works only for tunnel heads.
– mplsTunnelPerfErrors—This packet counter works only for tunnel heads.
– mplsTunnelPerfBytes—This byte counter works for tunnel heads and tunnel midpoints, but not
for tunnel tails.
– mplsTunnelPerfHCBytes—This byte counter works for tunnel heads and tunnel midpoints, but
not for tunnel tails.
• mplsTunnelTrapEnable—The object type mplsTunnelTrapEnable is enhanced to be writable.
Accordingly, if this object type is set to “TRUE,” the following notifications are enabled, thus giving
you the ability to monitor changes in the operational status of MPLS TE tunnels:
– mplsTunnelUp
– mplsTunnelDown
– mplsTunnelRerouted
If the mplsTunnelTrapEnable object is set to “FALSE,” such operational status notifications are not
generated. These notification functions are based on the definitions (mplsTeNotifications) contained
in the IETF draft document entitled draft-ietf-mpls-te-mib-05.txt.
CLI Access to MPLS Traffic Engineering MIB Information

Figure 1 shows commands that you can use to retrieve information from specific tables in the MPLS TE
MIB. As noted in this figure, some information in the MPLS TE MIB is not retrievable by commands.
9
Figure 1 Commands for Retrieving MPLS TE MIB Information
s
el
s
nn
el
tu
nn
d
an
g
tu
en
m
s
g
th
m
c-
en
pa
co
ffi
c-
it-
in
ffi
s
y tr
ce
ic
tra
e
ar ls
pl
rfa
bl
m p
ex
s
m m
la
pl
te
ai
ip
su how
m
in
av
ow
ow
ow
ot
s
sh
sh
sh
N
mplsTunnelTable x x
mplsTunnelHopTable x x
mplsTunnelResourceTable x
mplsTunnelARHopTable x
mplsTunnelCHopTable x
mplsTunnelPerfTable x x
Scalars x x x
52510
Retrieving Information from the MPLS Traffic Engineering MIB
This section describes how to efficiently retrieve information about TE tunnels. Such information can be
useful in large networks that contain many TE tunnels.
Traverse across a single column of the mplsTunnelTable, such as mplsTunnelName. This action provides
the indexes of every tunnel configuration, and any LSPs involving the host router. Using these indexes,
you can perform a GET operation to retrieve information from any column and row of the
mplsTunnelTable.
The mplsTunnelTable provides pointers to other tables for each tunnel. The column
mplsTunnelResourcePointer, for example, provides an object ID (OID) that you can use to access
resource allocation information in the mplsTunnelResourceTable. The columns
mplsTunnelHopTableIndex, mplsTunnelARHopTableIndex, and mplsTunnelCHopTableIndex provide the
primary index into the mplsTunnelHopTable, mplsTunnelARHopTable, and mplsTunnelCHopTable,
respectively. By traversing the MPLS TE MIB in this manner using a hop table column and primary
index, you can retrieve information pertaining to the hops of that tunnel configuration.
Because tunnels are treated as interfaces, the tunnel table column (mplsTunnelIfIndex) provides an index
into the Interfaces MIB that you can use to retrieve interface-specific information about a tunnel.
10
How to Configure the MPLS Traffic Engineering MIB

• Enabling the SNMP Agent to Help Manage Various MPLS TE Tunnel Characteristics of Tunnels on
the Local Router, page 11 (required)
• Verifying the Status of the SNMP Agent, page 12 (optional)
Enabling the SNMP Agent to Help Manage Various MPLS TE Tunnel

Characteristics of Tunnels on the Local Router
The SNMP agent for the MPLS TE MIB is disabled by default. To enable the SNMP agent for the MPLS
TE MIB, perform the following task.
SUMMARY STEPS
1. telnet host
2. enable
5. snmp-server community string [view view-name] [ro | rw] [ipv6 nacl] [access-list-number]
6. snmp-server enable traps [identification-type] [notification-option]
7. exit
8. write memory
DETAILED STEPS

Step 1 telnet host Telnets to the router identified by the specified IP address
(represented as xxx.xxx.xxx.xxx).
Example:
Router> telnet 192.172.172.172
Example:
Router# enable
Step 3 show running-config Displays the running configuration to determine if an
Example: • If no SNMP information is displayed, go to Step 4. If
Router# show running-config any SNMP information is displayed, you can modify
the information or change it as needed.
11

Example:
Step 5 snmp-server community string [view view-name] Enables the read-only (RO) community string.
[ro | rw] [ipv6 nacl] [access-list-number]
Example:
ro 4
Step 6 snmp-server enable traps [identification-type] Enables an LSR to send SNMP notifications or informs to
[notification-option] an SNMP host.
Note This command is optional. After SNMP is enabled,
Example: all MIBs (not just the TE MIB) are available for the
Router(config)# snmp-server enable traps user to query.
EXEC mode.
Example:
Step 8 write memory Writes the modified configuration to NVRAM, permanently
saving the settings.
Example:
Verifying the Status of the SNMP Agent

To verify that the SNMP agent has been enabled on a host network device, perform the following steps.
SUMMARY STEPS
1. telnet host
2. enable
12
Configuration Examples for the MPLS Traffic Engineering MIB
DETAILED STEPS

Step 1 telnet host Telnets to the target device identified by the specified IP
address (represented as xxx.xxx.xxx.xxx).
Example:
Step 2 enable Enables SNMP on the target device.
Example:
Router# enable
Step 3 show running-config Displays the running configuration on the target device and
is used to examine the output for displayed SNMP
information.
Example:
Examples
The follows example displays the running configuration on the target device and its SNMP information.
.
.
.
snmp-server community public ro
snmp-server community private ro
Any snmp-server statement that appears in the output and takes the form shown here verifies that SNMP
has been enabled on that device.
Configuration Examples for the MPLS Traffic Engineering MIB

• Enabling the SNMP Agent to Help Manage Various MPLS TE Tunnel Characteristics of Tunnels on
the Local Router: Example, page 13
Enabling the SNMP Agent to Help Manage Various MPLS TE Tunnel

Characteristics of Tunnels on the Local Router: Example
The following example shows how to enable an SNMP agent on a host network device:
Router(config)# snmp-server community private
The following example shows how to enable SNMPv1 and SNMPv2C. The configuration permits any
SNMP agent to access all MPLS TE MIB objects with read-only permissions using the community string
public.
13
The following example shows how to allow read-only access to all MPLS TE MIB objects relating to
access to any MPLS TE MIB objects.
The following sections provide references related to the MPLS Traffic Engineering MIB.
Related Documents
Information about MPLS TE and enhancements MPLS Traffic Engineering and Enhancements
Network Management Configuration Guide. Release 2
Standards
Standard Title
draft-ietf-mpls-te-mib-05 MPLS Traffic Engineering Management Information Base Using
SMIv2
MIBs
MIB MIBs Link
• MPLS TE MIB To locate and download MIBs for selected platforms, Cisco IOS XE
• Interfaces MIB
the following URL:
RFCs
RFC Title
RFC 2026 The Internet Standards Process
14
Feature Information for the MPLS Traffic Engineering MIB
Description Link

15
Table 1 Feature Information for the MPLS Traffic Engineering MIB

MPLS Traffic Engineering MIB Cisco IOS XE The MPLS Traffic Engineering MIB feature enables the
Release 2.3 SNMP agent support in Cisco IOS XE software for MPLS
TE management, as implemented in the MPLS TE MIB.
feature:
• MPLS Traffic Engineering MIB Cisco Implementation,
page 2
• Capabilities Supported by the MPLS Traffic
Engineering MIB, page 3
• Notification Implementation, page 4
• Benefits of the MPLS Traffic Engineering MIB, page 4
• MPLS Traffic Engineering MIB Layer Structure,
page 4
• Features and Technologies Related to the MPLS Traffic
Engineering MIB, page 5
• Supported Objects in the MPLS Traffic Engineering
MIB, page 5
• CLI Access to MPLS Traffic Engineering MIB
Information, page 9
• Enabling the SNMP Agent to Help Manage Various
MPLS TE Tunnel Characteristics of Tunnels on the
Local Router, page 11
• Verifying the Status of the SNMP Agent, page 12
snmp-server community, snmp-server enable traps
(MPLS), snmp-server host.
16
Glossary
Glossary
affinity bits—A Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnel’s requirements
on the attributes of the links it will cross. The tunnel’s affinity bits and affinity mask must match with
the attributes of the various links carrying the tunnel.
call admission precedence—An Multiprotocol Label Switching (MPLS) traffic engineering tunnel with
a higher priority will, if necessary, preempt an MPLS traffic engineering tunnel with a lower priority. An
expected use is that tunnels that are more difficult to route will have a higher priority, and can preempt
tunnels that are less difficult to route, on the assumption that those lower priority tunnels can find another
path.
constraint-based routing—Procedures and protocols used to determine a route across a backbone
taking into account resource requirements and resource availability, instead of simply using the shortest
path.
flow—A traffic load entering the backbone at one point—point of presence (POP)—and leaving it from
another that must be traffic engineered across the backbone. The traffic load will be carried across one
or more LSP tunnels running from the entry POP to the exit POP.
headend—The label switch router (LSR) at which the tunnel originates. The tunnel’s “head” or tunnel
interface will reside at this LSR as well.
message because an informs message requires acknowledgment.
cells).
LSP—label switched path. A path that is followed by a labeled packet over several hops, starting at an
ingress label switch router (LSR) and ending at an egress LSR.
LSR—label switch router. A Layer 3 router that forwards a packet based on the value of a label
MIB—Management Information Base. A database of network management information (consisting of
MIB objects) that is used and maintained by a network management protocol such as Simple Network
Management Protocol (SNMP). The value of a MIB object can be changed or retrieved using SNMP
commands, usually by a GUI-based network management system. MIB objects are organized in a tree
structure that includes public (standard) and private (proprietary) branches.
MPLS—Multiprotocol Label Switching. Switching method that forwards IP traffic using a label. This
NMS—network management station. An NMS is a powerful, well-equipped computer (typically an
engineering workstation) that is used by a network administrator to communicate with other devices in
the network. An NMS is typically used to manage network resources, gather statistics, and perform a
variety of network administration and configuration tasks.
notification —A message sent by a Simple Network Management Protocol (SNMP) agent to a network
software has occurred (see traps).
OSPF—Open Shortest Path First. A link-state routing protocol used for routing IP.
RSVP—Resource Reservation Protocol. Protocol for reserving network resources to provide quality of
service (QoS) guarantees to application flows.
17
Glossary

exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices,
manage configurations, collect statistics, monitor performance, and ensure network security.
tailend—The downstream, receive end of a tunnel.
software has occurred. Traps (notifications) are less reliable than inform requests, because the receiver
of the trap does not send an acknowledgment of receipt; furthermore, the sender of the trap cannot
determine if the trap was received (see notification).
VCC—virtual channel connection. A VCC is a logical circuit consisting of VCLs that carries data
between two endpoints in an ATM network. Sometimes called a virtual circuit connection.
VCI—virtual channel identifier. A 16-bit field in the header of an ATM cell. The VCI, together with the
VPI, is used to identify the next network VCL as the cell passes through a series of ATM switches on its
way to its final destination.
VCL—virtual channel link. A VCL is the logical connection that exists between two adjacent switches
in an ATM network.
VPI—virtual path identifier. An 8-bit field in the header of an ATM cell. The VPI, together with the VCI,
is used to identify the next network VCL as the cell passes through a series of ATM switches on its way
to its final destination.
countries.
18
MPLS High Availablity
MPLS LDP Graceful Restart

When a router is configured with Multiprotocol Label Switching (MPLS) Label Distribution Protocol
(LDP) Graceful Restart (GR), it assists a neighboring router that has MPLS LDP Stateful
Switchover/Nonstop Forwarding (SSO/NSF) Support and Graceful Restart to recover gracefully from an
interruption in service. MPLS LDP GR functions strictly in helper mode, which means it can only help
other routers that are enabled with MPLS SSO/NSF and GR to recover. If the router with LDP GR fails,
its peer routers cannot help the router recover.
For brevity, the following are used in this document:
• MPLS LDP SSO/NSF Support and Graceful Restart is called LDP SSO/NSF.
• The MPLS LDP GR feature described in this document refers to helper mode.
When you enable MPLS LDP GR on a router that peers with an MPLS LDP SSO/NSF-enabled router,
the SSO/NSF-enabled router can maintain its forwarding state when the LDP session between them is
interrupted. While the SSO/NSF-enabled router recovers, the peer router forwards packets using stale
information. This enables the SSO/NSF-enabled router to become operational more quickly.

which each feature is supported, see the “Feature Information for MPLS LDP Graceful Restart” section on
page 12.
Contents
Contents
• Prerequisites for MPLS LDP Graceful Restart, page 2
• Restrictions for MPLS LDP Graceful Restart, page 2
• Information About MPLS LDP Graceful Restart, page 2
• How to Configure MPLS LDP Graceful Restart, page 4
• Configuration Examples for MPLS LDP Graceful Restart, page 6
• Feature Information for MPLS LDP Graceful Restart, page 12
Prerequisites for MPLS LDP Graceful Restart

You must enable MPLS LDP GR on all route processors for an LDP session to be preserved during an
Restrictions for MPLS LDP Graceful Restart

• MPLS LDP GR is supported in strict helper mode.
• MPLS LDP GR cannot be configured on label-controlled ATM (LC-ATM) interfaces.
Information About MPLS LDP Graceful Restart

To configure MPLS LDP GR, you need to understand the following concepts:
• How MPLS LDP Graceful Restart Works, page 2
• How a Route Processor Advertises That It Supports MPLS LDP Graceful Restart, page 3
• What Happens If a Route Processor Does Not Have MPLS LDP Graceful Restart, page 3
How MPLS LDP Graceful Restart Works

MPLS LDP GR works in strict helper mode, which means it helps a neighboring route processor that has
MPLS LDP SSO/NSF to recover from disruption in service without losing its MPLS forwarding state.
The disruption in service could be the result of a TCP or UDP event or the stateful switchover of a route
processor. When the neighboring router establishes a new session, the LDP bindings and MPLS
forwarding states are recovered.
In the topology shown in Figure 1, the following elements have been configured:
• LDP sessions are established between Router 1 and Router 2, as well as between Router 2 and
Router 3.
• Router 2 has been configured with MPLS LDP SSO/NSF. Routers 1 and 3 have been configured with
MPLS LDP GR.
• A label switched path (LSP) has been established between Router 1 and Router 3.
2
Information About MPLS LDP Graceful Restart
Figure 1 Example of a Network Using LDP Graceful Restart
95974
The following process shows how Routers 1 and 3, which have been configured with MPLS LDP GR,
help Router 2, which has been configured with LDP SSO/NSF, recover from a disruption in service:
1. Router 1 notices an interruption in service with Router 2. (Router 3 also performs the same actions
in this process.)
2. Router 1 marks all the label bindings from Router 2 as stale, but it continues to use the bindings for
MPLS forwarding.
Router 1 reestablishes an LDP session with Router 2, but keeps its stale label bindings. If you issue a
show mpls ldp neighbor command with the graceful-restart keyword, the command output displays
the recovering LDP sessions.
3. Both routers readvertise their label binding information. If Router 1 relearns a label from Router 2
after the session has been established, the stale flags are removed. The show mpls forwarding-table
command displays the information in the MPLS forwarding table, including the local label,
outgoing label or VC, prefix, label-switched bytes, outgoing interface, and next hop.
You can set various graceful restart timers. See the following commands for more information:
• mpls ldp graceful-restart timers neighbor-liveness
• mpls ldp graceful-restart timers max-recovery
How a Route Processor Advertises That It Supports MPLS LDP Graceful Restart
A Route Processor (RP) that is configured to perform MPLS LDP GR includes the Fault Tolerant (FT)
Type Length Value (TLV) in the LDP initialization message. The RP sends the LDP initialization
message to a neighbor to establish an LDP session.
The FT session TLV includes the following information:
• The Learn from Network (L) flag is set to 1, which indicates that the route processor is configured
to perform MPLS LDP GR.
• The Reconnect Timeout field shows the time (in milliseconds) that the neighbor should wait for a
reconnection if the LDP session is lost. In this release, the timer is set to 0, which indicates that if
the local router fails, its peers should not wait for it to recover. The timer setting indicates that the
local router is working in helper mode.
• The Recovery Time field shows the time (in milliseconds) that the neighbor should retain the MPLS
forwarding state during a recovery. If a neighbor did not preserve the MPLS forwarding state before
the restart of the control plane, the neighbor sets the recovery time to 0.
What Happens If a Route Processor Does Not Have MPLS LDP Graceful Restart
If two route processors establish an LDP session and one route processor is not configured for
MPLS LDP GR, the two route processors create a normal LDP session but do not have the ability to
perform MPLS LDP GR. Both route processors must be configured for MPLS LDP GR.
3
How to Configure MPLS LDP Graceful Restart

• Verifying the MPLS LDP Graceful Restart Configuration, page 5 (optional)

To configure MPLS LDP Graceful Restart, perform the following task.
You must enable MPLS LDP GR on all route processors for an LDP session to be preserved during an
MPLS LDP GR is enabled globally. When you enable MPLS LDP GR, it has no effect on existing LDP
sessions. New LDP sessions that are established can perform MPLS LDP GR.
Note You can also issue the mpls label protocol ldp command in global configuration mode, which enables
LDP on all interfaces configured for MPLS.
SUMMARY STEPS
1. enable
6. mpls ip
8. exit
9. exit
DETAILED STEPS

Example:
Router> enable
Example:
4

Example:
Example:
Router(config)# mpls ldp graceful-restart
Example:
Example:
Step 7 mpls label protocol ldp Configures the use of LDP for an interface.
Example:
configuration mode.
Example:
EXEC mode.
Example:
Verifying the MPLS LDP Graceful Restart Configuration

To verify that MPLS LDP Graceful Restart is configured correctly, perform the following task.
SUMMARY STEPS
1. enable
2. show mpls ldp neighbor graceful-restart
3. show mpls ldp graceful restart
4. exit
5
Configuration Examples for MPLS LDP Graceful Restart
DETAILED STEPS
Step 1 enable
Use this command to enable privileged ECEC mode. Enter your password if prompted. For example:
Router>? enable
Router#
Step 2 show mpls ldp neighbor graceful restart

Use this command to display graceful restart information for LDP sessions. For example:
Router# show mpls ldp neighbor graceful restart

TCP connection: 10.20.20.20.16510 - 10.17.17.17.646
Up time: 00:04:39
Graceful Restart enabled; Peer reconnect time (msecs): 120000
TCP connection: 10.19.19.19.11007 - 10.17.17.17.646
Up time: 00:04:30
Step 3 show mpls ldp graceful-restart

Use this command to display graceful restart sessions and session parameters. For example:
Router# show mpls ldp graceful-restart
LDP Graceful Restart is enabled

Neighbor Liveness Timer: 5 seconds
Max Recovery Time: 200 seconds
Down Neighbor Database (0 records):
Graceful Restart-enabled Sessions:
VRF default:
Peer LDP Ident: 10.18.18.18:0, State: estab
Step 4 exit
Router# exit
Router>

This section contains the following example for configuring the MPLS LDP Graceful Restart feature:
• Configuring MPLS LDP Graceful Restart: Example, page 7
6
Configuring MPLS LDP Graceful Restart: Example

Figure 2 shows a configuration where MPLS LDP GR is enabled on Router 1 and MPLS LDP SSO/NSF
is enabled on Routers 2 and 3. In this configuration example, Router 1 creates an LDP session with
Router 2. Router 1 also creates a targeted session with Router 3 through a traffic engineering tunnel using
Router 2.
Figure 2 MPLS LDP Graceful Restart Configuration Example
LDP2
10.20.20.20 172.16.17.17 192.168.19.19
LDP1
95975
TE Tunnel
Router 1 configured with LDP GR:

!
ip subnet-zero
ip cef
!
interface Loopback0
ip address 20.20.20.20 255.255.255.255
no ip mroute-cache
!
interface Tunnel1
mpls ip
!
interface ATM5/1/0
no ip address
atm clock INTERNAL
!
interface ATM5/1/0.5 point-to-point
ip address 10.12.0.2 255.0.0.0
pvc 6/100
7
mpls ip
!
router ospf 100
network 10.12.0.0 0.255.255.255 area 100
network 10.20.20.20 0.0.0.0 area 100
Router 2 configured with LDP SSO/NSF:

!
redundancy
mode sso
!
ip cef
no ip domain-lookup
no mpls advertise-labels
!
interface Loopback0
ip address 10.17.17.17 255.255.255.255
!
interface ATM4/0/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.12.0.1 255.0.0.0
pvc 6/100
mpls ip
!
interface POS5/1/0
ip address 10.11.0.1 255.0.0.0
encapsulation ppp
mpls ip
8

!
router ospf 100
nsf enforce global
network 10.11.0.0 0.255.255.255 area 100
network 10.12.0.0 0.255.255.255 area 100
network 10.17.17.17 0.0.0.0 area 100
!
ip classless
Router 3 configured with LDP SSO/NSF:

!
redundancy
mode sso
!
ip subnet-zero
ip cef
!
no ip finger
no ip domain-lookup
mpls ldp neighbor 10.11.11.11 targeted ldp
mpls ldp discovery directed-hello interval 12
mpls ldp discovery directed-hello holdtime 130
mpls ldp discovery directed-hello accept
!
interface Loopback0
ip address 10.19.19.19 255.255.255.255
!
interface POS1/0
ip address 10.11.0.2 255.0.0.0
encapsulation ppp
mpls ip
!
router ospf 100
nsf enforce global
network 10.11.0.0 0.255.255.255 area 100
network 10.19.19.19 0.0.0.0 area 100
!
ip classless
9
The following sections provide references related to MPLS LDP GR.
Related Documents
LDP commands Cisco IOS Multiprotocol Label Switching Command Reference
Standards
Standards Title
MIBs
MIBs MIBs Link
the following URL:
RFCs
RFCs Title
10
Description Link
11
Feature Information for MPLS LDP Graceful Restart

Table 1 Feature Information for MPLS LDP Graceful Restart

MPLS LDP Graceful Restart Cisco IOS XE When a router is configured with Multiprotocol Label
Release 2.1 Switching (MPLS) Label Distribution Protocol (LDP)
Graceful Restart (GR), it assists a neighboring router that
has MPLS LDP Stateful Switchover/Nonstop Forwarding
(SSO/NSF) Support and Graceful Restart to recover
gracefully from an interruption in service. MPLS LDP GR
functions strictly in helper mode, which means it can only
help other routers that are enabled with MPLS SSO/NSF
and GR to recover. If the router with LDP GR fails, its peer
routers cannot help the router recover.
feature:
• How MPLS LDP Graceful Restart Works, page 2
• How a Route Processor Advertises That It Supports
MPLS LDP Graceful Restart, page 3
• What Happens If a Route Processor Does Not Have
MPLS LDP Graceful Restart, page 3
• Verifying the MPLS LDP Graceful Restart
debug mpls ldp graceful-restart, mpls ldp
graceful-restart, mpls ldp graceful-restart timers
max-recovery, mpls ldp graceful-restart timers
neighbor-liveness, show mpls ip binding, show mpls ldp
bindings, show mpls ldp graceful-restart, show mpls ldp
neighbor.
12
countries.
13
14
NSF/SSO—MPLS LDP and LDP Graceful Restart

Cisco Nonstop Forwarding (NSF) with Stateful Switchover (SSO) provides continuous packet
forwarding, even during a network processor hardware or software failure. In a redundant system, the
secondary processor recovers control plane service during a critical failure in the primary processor. SSO
synchronizes the network state information between the primary and the secondary processor.
Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) uses SSO, NSF, and graceful
restart to allow a Route Processor (RP) to recover from disruption in control plane service (specifically,
the LDP component) without losing its MPLS forwarding state. LDP NSF works with LDP sessions
between directly connected peers and with peers that are not directly connected (targeted sessions).
Note In this document, the NSF/SSO—MPLS LDP and LDP Graceful Restart feature is called LDP NSF for
brevity.

which each feature is supported, see the “Feature Information for NSF/SSO—MPLS LDP and LDP Graceful
Restart” section on page 12.
Contents
Contents
• Prerequisites for NSF/SSO—MPLS LDP and LDP Graceful Restart, page 2
• Restrictions for NSF/SSO—MPLS LDP and LDP Graceful Restart, page 2
• Information About NSF/SSO—MPLS LDP and LDP Graceful Restart, page 2
• How to Configure and Use NSF/SSO—MPLS LDP and LDP Graceful Restart, page 5
• Configuration Examples for NSF/SSO—MPLS LDP and LDP Graceful Restart, page 8
• Feature Information for NSF/SSO—MPLS LDP and LDP Graceful Restart, page 12
Prerequisites for NSF/SSO—MPLS LDP and LDP Graceful

Restart
MPLS high availability (HA) requires that neighbor networking devices be NSF-aware.
To perform LDP NSF, RPs must be configured for SSO. See the Stateful Switchover feature module for
more information:
You must enable nonstop forwarding on the routing protocols running between the provider (P) routers,
provider edge (PE) routers, and customer edge (CE) routers. The routing protocols are:
• Border Gateway Protocol (BGP)
See the Cisco Nonstop Forwarding feature module for more information.
Restrictions for NSF/SSO—MPLS LDP and LDP Graceful Restart

LDP NSF has the following restriction:
• LDP NSF cannot be configured on label-controlled ATM (LC-ATM) interfaces.
Information About NSF/SSO—MPLS LDP and LDP Graceful

Restart
To configure LDP NSF, you need to understand the following concepts:
• How NSF/SSO—MPLS LDP and LDP Graceful Restart Works, page 3
• What Happens During an LDP Restart and an LDP Session Reset, page 3
• How a Route Processor Advertises That It Supports NSF/SSO—MPLS LDP and LDP Graceful
Restart, page 4
• What Happens if a Route Processor Does Not Have LDP Graceful Restart, page 4
• Checkpointing for NSF/SSO—MPLS LDP and LDP Graceful Restart, page 4
2
Information About NSF/SSO—MPLS LDP and LDP Graceful Restart
How NSF/SSO—MPLS LDP and LDP Graceful Restart Works

LDP NSF allows an RP to recover from disruption in service without losing its MPLS forwarding state.
LDP NSF works under the following circumstances:
• LDP restart—An LDP Restart occurs after an SSO event interrupts LDP communication with all
LDP neighbors. If the RPs are configured with LDP NSF, the backup RP retains the MPLS
forwarding state and reestablishes communication with the LDP neighbors. Then the RP ensures
that the MPLS forwarding state is recovered.
• LDP session reset—An LDP session reset occurs after an individual LDP session has been
interrupted, but the interruption is not due to an SSO event. The LDP session might have been
interrupted due to a TCP or UDP communication problem. If the RP is configured with MPLS LDP
NSF support and graceful restart, the RP associates a new session with the previously interrupted
session. The LDP bindings and MPLS forwarding states are recovered when the new session is
established.
If an SSO event occurs on an LSR, that LSR performs an LDP restart. The adjacent LSRs perform
an LDP session reset.
See the following section for more information about LDP restart and reset.
What Happens During an LDP Restart and an LDP Session Reset

In the topology shown in Figure 1, the following elements have been configured:
• LDP sessions are established between Router 1 and Router 2, as well as between Router 2 and
Router 3.
• A label switched path (LSP) has been established between Router 1 and Router 3.
• The routers have been configured with LDP NSF.
Figure 1 Example of a Network Using LDP Graceful Restart

95974
The following process shows how LDP recovers when one of the routers fails:
1. When an RP fails on Router 2, communications between the routers is interrupted.
2. Router 1 and Router 3 mark all the label bindings from Router 2 as stale, but they continue to use
the bindings for MPLS forwarding.
3. Router 1 and Router 3 attempt to reestablish an LDP session with Router 2.
4. Router 2 restarts and marks all of its forwarding entries as stale. If you enter a show mpls ldp
graceful-restart command, the command output includes the following line:
LDP is restarting gracefully.
5. Router 1 and Router 3 reestablish LDP sessions with Router 2, but they keep their stale label
bindings. If you enter a show mpls ldp neighbor command with the graceful-restart keyword, the
command output displays the recovering LDP sessions.
3
Information About NSF/SSO—MPLS LDP and LDP Graceful Restart
6. All three routers readvertise their label binding information. If a label has been relearned after the
session has been established, the stale flags are removed. The show mpls forwarding-table
command displays the information in the MPLS forwarding table, including the local label,
outgoing label or VC, prefix, label-switched bytes, outgoing interface, and next hop.
You can set various timers to limit how long the routers wait for an LDP session to be reestablished
before restarting the router. See the following commands for more information:
• mpls ldp graceful-restart timers forwarding-holding
• mpls ldp graceful-restart timers max-recovery
• mpls ldp graceful-restart timers neighbor-liveness
How a Route Processor Advertises That It Supports NSF/SSO—MPLS LDP and

LDP Graceful Restart
An RP that is configured to perform LDP NSF includes the Fault Tolerant (FT) Type Length Value (TLV)
in the LDP initialization message. The RP sends the LDP initialization message to a neighbor to establish
an LDP session.
The FT session TLV includes the following information:
• The Learn from Network (L) flag is set to 1, which indicates that the RP is configured to perform
LDP Graceful Restart.
• The Reconnect Timeout field shows the time (in milliseconds) that the neighbor should wait for a
reconnection if the LDP session is lost. This field is set to 120 seconds and cannot be configured.
• The Recovery Time field shows the time (in milliseconds) that the neighbor should retain the MPLS
forwarding state during a recovery. If a neighbor did not preserve the MPLS forwarding state before
the restart of the control plane, the neighbor sets the recovery time to 0.
What Happens if a Route Processor Does Not Have LDP Graceful Restart
If an RP is not configured for MPLS LDP Graceful Restart and it attempts to establish an LDP session
with an RP that is configured with LDP Graceful Restart, the following events occur:
1. The RP that is configured with MPLS LDP Graceful Restart sends an initialization message that
includes the FT session TLV value to the RP that is not configured with MPLS LDP Graceful
Restart.
2. The RP that is not configured for MPLS LDP Graceful Restart receives the LDP initialization
message and discards the FT session TLV.
3. The two RPs create a normal LDP session but do not have the ability to perform MPLS LDP
Graceful Restart.
You must enable all RPs with MPLS LDP Graceful Restart for an LDP session to be preserved during
an interruption in service.
Checkpointing for NSF/SSO—MPLS LDP and LDP Graceful Restart

Checkpointing is a function that copies state information from the active RP to the backup RP, thereby
ensuring that the backup RP has the latest information. If the active RP fails, the backup RP can take
over.
4
How to Configure and Use NSF/SSO—MPLS LDP and LDP Graceful Restart
For the LDP NSF feature, the checkpointing function copies the active RP’s LDP local label bindings to
the backup RP. The active RP sends updates to the backup RP when local label bindings are modified as
a result of routing changes.
Note Local label bindings that are allocated by BGP and null local label bindings are not included in the
checkpointing operation.
The checkpointing function is enabled by default.

To display checkpointing data, issue the show mpls ldp graceful-restart command on the active RP.
To check that the active and backup RPs have identical copies of the local label bindings, you can issue
the show mpls ldp bindings command with the detail keyword on the active and backup RPs. This
command displays the local label bindings that have been saved. The active RP and the backup RP should
have the same local label bindings.
You can use the debug mpls ldp graceful-restart command to enable the display of MPLS LDP
checkpoint events and errors.
How to Configure and Use NSF/SSO—MPLS LDP and LDP

Graceful Restart
• Verifying the MPLS LDP Graceful Restart Configuration, page 7 (optional)

To configure MPLS LDP Graceful Restart, perform the following task. MPLS LDP Graceful Restart
(GR) is enabled globally. When you enable LDP GR, it has no effect on existing LDP sessions. LDP GR
is enabled for new sessions that are established after the feature has been globally enabled.
Prerequisites
• RPs must be configured for SSO. See the Stateful Switchover feature module for more information:
• You must enable Nonstop Forwarding on the routing protocols running between the P, PE, routers,
and CE routers. See the Cisco Nonstop Forwarding feature module for more information.
SUMMARY STEPS
1. enable
3. ip cef [distributed]
5
6. mpls ip
8. exit
9. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef [distributed] Enables distributed Cisco Express Forwarding.
Example:
Example:
Router (config)# mpls ldp graceful-restart
Example:
Example:
Step 7 mpls label protocol ldp Configures the use of LDP for an interface. You must use
LDP. You can also issue the mpls label protocol ldp
command in global configuration mode, which enables LDP
Example:
on all interfaces configured for MPLS.
configuration mode.
Example:
EXEC mode.
Example:
6
Verifying the MPLS LDP Graceful Restart Configuration

Use the following procedure to verify that MPLS LDP Graceful Restart has been configured correctly.
SUMMARY STEPS
1. enable
2. show mpls ldp graceful-restart
3. show mpls ldp neighbor graceful restart
4. show mpls ldp checkpoint
5. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls ldp graceful-restart

The command output displays Graceful Restart sessions and session parameters:
Router# show mpls ldp graceful-restart
LDP Graceful Restart is enabled

Neighbor Liveness Timer: 5 seconds
Max Recovery Time: 200 seconds
Down Neighbor Database (0 records):
Graceful Restart-enabled Sessions:
VRF default:

Step 3 show mpls ldp neighbor graceful restart

The command output displays the Graceful Restart information for LDP sessions:
Router# show mpls ldp neighbor graceful-restart

TCP connection: 10.20.20.20.16510 - 10.17.17.17.646
Up time: 00:04:39
TCP connection: 10.19.19.19.11007 - 10.17.17.17.646
Up time: 00:04:30
Step 4 show mpls ldp checkpoint

The command output displays the summary of the checkpoint information:
Router# show mpls ldp checkpoint
7
Configuration Examples for NSF/SSO—MPLS LDP and LDP Graceful Restart
Checkpoint status: dynamic-sync

Checkpoint resend timer: not running
5 local bindings in add-skipped
9 local bindings in added
1 of 15+ local bindings in none
Step 5 exit
Router# exit
Router>
Configuration Examples for NSF/SSO—MPLS LDP and LDP Graceful

Restart
This section contains the following configuration examples for LDP NSF:
• Configuring NSF/SSO—MPLS LDP and LDP Graceful Restart: Example, page 8
Configuring NSF/SSO—MPLS LDP and LDP Graceful Restart: Example

The following configuration example shows the LDP NSF feature configured on three routers. (See
Figure 2.) In this configuration example, Router 1 creates an LDP session with Router 2. Router 1 also
creates a targeted session with Router 3 through a TE tunnel using Router 2.
Figure 2 MPLS LDP: NSF/SSO Support and Graceful Restart Configuration Example
LDP2
10.20.20.20 172.16.17.17 192.168.19.19
LDP1
95975
TE Tunnel
Router 1
redundancy
mode sso
ip subnet-zero
ip cef distributed
!
interface Loopback0
8
ip address 172.20.20.20 255.255.255.255

no ip mroute-cache
!
interface Tunnel1
mpls ip
!
interface ATM0/1/0
no ip address
atm clock INTERNAL
!
ip address 172.17.0.2 255.255.0.0
pvc 6/100
mpls ip
!
router ospf 100
nsf enforce global
network 172.17.0.0 0.255.255.255 area 100
network 172.20.20.20 0.0.0.0 area 100
Router 2
redundancy
mode sso
!
ip cef distributed
no ip domain-lookup
no mpls advertise-labels
!
interface Loopback0
ip address 172.18.17.17 255.255.255.255
!
interface ATM0/3/0
9
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 172.17.0.1 255.255.0.0
pvc 6/100
mpls ip
!
interface POS0/1/0
ip address 10.0.0.1 255.0.0.0
encapsulation ppp
mpls ip
!
router ospf 100
nsf enforce global
network 10.0.0.0 0.255.255.255 area 100
network 172.17.0.0 0.255.255.255 area 100
network 172.18.17.17 0.0.0.0 area 100
!
ip classless
Router 3
redundancy
mode sso
!
ip subnet-zero
ip cef distributed
!
no ip finger
no ip domain-lookup
mpls ldp neighbor 10.11.11.11 targeted ldp
mpls ldp discovery directed-hello interval 12
mpls ldp discovery directed-hello holdtime 130
mpls ldp discovery directed-hello accept
!
10
interface Loopback0
ip address 172.19.19.19 255.255.255.255
!
interface POS1/1/0
ip address 10.0.0.2 255.0.0.0
encapsulation ppp
mpls ip
!
router ospf 100
nsf enforce global
network 10.0.0.0 0.255.255.255 area 100
network 172.19.19.19 0.0.0.0 area 100
!
ip classless
The following sections provide references related to the NSF/SSO—MPLS LDP and LDP Graceful
Restart feature.
Related Documents
Standards
Standard Title
11
Feature Information for NSF/SSO—MPLS LDP and LDP Graceful Restart
MIBs
MIB MIBs Link
the following URL:
RFCs
RFC Title
Description Link
Feature Information for NSF/SSO—MPLS LDP and LDP Graceful

Restart
12
Table 1 Feature Information for NSF/SSO—MPLS LDP and LDP Graceful Restart

NSF/SSO—MPLS LDP and MPLS LDP Cisco IOS XE Cisco Nonstop Forwarding (NSF) with Stateful Switchover
Graceful Restart Release 2.1 (SSO) provides continuous packet forwarding, even during
a network processor hardware or software failure. In a
redundant system, the secondary processor recovers control
plane service during a critical failure in the primary
processor. SSO synchronizes the network state information
between the primary and the secondary processor.
Multiprotocol Label Switching (MPLS) Label Distribution
Protocol (LDP) uses SSO, NSF, and graceful restart to allow
a Route Processor (RP) to recover from disruption in control
plane service (specifically, the LDP component) without
losing its MPLS forwarding state. LDP NSF works with
LDP sessions between directly connected peers and with
peers that are not directly connected (targeted sessions).
feature:
• How NSF/SSO—MPLS LDP and LDP Graceful
Restart Works, page 3
• What Happens During an LDP Restart and an LDP
Session Reset, page 3
• How a Route Processor Advertises That It Supports
NSF/SSO—MPLS LDP and LDP Graceful Restart,
page 4
• What Happens if a Route Processor Does Not Have
LDP Graceful Restart, page 4
• Checkpointing for NSF/SSO—MPLS LDP and LDP
Graceful Restart, page 4
• Verifying the MPLS LDP Graceful Restart
debug mpls ldp graceful-restart, mpls label protocol
(global configuration), mpls ldp graceful-restart, mpls
ldp graceful-restart timers forwarding-holding, mpls
ldp graceful-restart timers max-recovery, mpls ldp
graceful-restart timers neighbor-liveness, show mpls ip
binding, show mpls ldp bindings, show mpls ldp
checkpoint, show mpls ldp graceful-restart, show mpls
ldp neighbor.
13
countries.
14
ISSU MPLS Clients

MPLS applications can be upgraded using the In Service Software Upgrade (ISSU) process. Thus, MPLS
applications are considered ISSU’s MPLS clients. The ISSU process allows Cisco IOS XE software to
be updated or otherwise modified while packet forwarding continues.

which each feature is supported, see the “Feature Information for ISSU MPLS Clients” section on page 16.
Contents
• Prerequisites for ISSU MPLS Clients, page 2
• Information About ISSU MPLS Clients, page 2
• How to Verify that an MPLS Client Can Support an In Service Software Upgrade, page 4
• Configuration Examples for ISSU MPLS Clients, page 5
• Feature Information for ISSU MPLS Clients, page 16
ISSU MPLS Clients
Prerequisites for ISSU MPLS Clients
Prerequisites for ISSU MPLS Clients

Before you perform an upgrade, you need to verify that the clients you are concerned about are
compatible with the intended switchover. Use the commands listed in the “Verifying the ISSU Process
for an MPLS Client” section on page 4 to determine compatibility.
The success performance of some clients in the upgraded network will depend upon their compatibility
with other clients as described in Table 1.
Table 1 MPLS Client Interdependencies
This client . . . ...can only work when this client is shown to be compatible
MPLS VPN LSD Label Manager High Availability
LDP LSD Label Manager High Availability
VRF (“Table ID”) LSD Label Manager High Availability
LSD Label Manager High Base clients: Checkpointing and Redundancy Facility
Availability
MFI Pull XDR
MFI Push XDR
LSPV Push within OAM XDR
TE Base clients:
• Checkpointing and Redundancy Facility
• MPLS TE High Availability
Information About ISSU MPLS Clients

Before examining ISSU coordination of MPLS clients, you should understand the following concepts:
• ISSU-Capable Protocols and Applications: Clients, page 2
• ISSU-Capable MPLS Feature Sets, page 3
This section provides information about upgrading MPLS-related applications through ISSU. Those
MPLS applications are considered ISSU’s MPLS “clients.”
For more information on the ISSU procedure, see Cisco IOS XE In Service Software Upgrade Process
document and see the Cisco ASR 1000 Series Aggregation Services Routers Software Configuration
Guide.
ISSU-Capable Protocols and Applications: Clients

Protocols and applications that can be upgraded through the ISSU process are considered clients of
ISSU. These include at least the following:
• Address Resolution Protocol (ARP)
• Asynchronous Transfer Mode (ATM)
2
ISSU MPLS Clients
Information About ISSU MPLS Clients
• Dynamic Host Configuration Protocol (DHCP)

• EtherChannel—port aggregration protocol (PagP) and Link Aggregration Control Protocol (LACP)
• Frame Relay (FR)
• Gateway Load Balancing Protocol (GLBP)
• High-Level Data Link Control (HDLC)
• Hot Standby Router Protocol (HSRP)
• IEEE 802.1x and 802.3af
• Internet Group Management Protocol (IGMP) snooping
• IP host
• PPP and Multilink PPP
• Port security
• Quality of service (QoS)
• Remote File System (RFS) versioning
• Simple Network Management Protocol (SNMP)
• Spanning Tree Protocol (STP)
Note For a complete list of ISSU- compliant protocols and applications that are supported for the
Cisco ASR Series Routers for your release, see the Release Notes for Cisco ASR Series Aggregation
Services Routers.
ISSU-Capable MPLS Feature Sets

Within the MPLS technology, ISSU supports the following feature sets as clients:
• Label Distribution Protocol (LDP)
• MPLS Virtual Private Network (MPLS VPN)
• VPN routing and forwarding (VRF), also called the “Table ID” client
• Label Switching Database Label Manager for high availability, usually called “LSD Label Manager
for HA”
• MPLS Forwarding Infrastructure Pull, called “MFI Pull”
• MPLS Forwarding Infrastructure Push, called “MFI Push”
• Label Switched Path Verification Push within Operation, Administration, and Management (OAM),
called “LSPV Push”
• TE
3
ISSU MPLS Clients
How to Verify that an MPLS Client Can Support an In Service Software Upgrade
How to Verify that an MPLS Client Can Support an In Service

Software Upgrade
• Verifying the ISSU Process for an MPLS Client, page 4 (required)
Note For the complete task sequence that accomplishes ISSU see the Cisco ASR 1000 Series Aggregation
Services Routers Software Configuration Guide.
Verifying the ISSU Process for an MPLS Client

Perform this task to verify that a particular MPLS client can be upgraded successfully during a particular
ISSU session. The commands in this task also can be used to display other details about the ISSU MPLS
clients, and should be entered in the order described.
Prerequisites
Ensure that you have successfully loaded new Cisco IOS XE software onto the standby processor as
described in the Cisco ASR 1000 Series Aggregation Services Routers Software Configuration Guide.
SUMMARY STEPS
1. enable
2. show issu clients
3. show issu sessions clientID
4. show issu negotiated version sessionID
5. show issu negotiated capability sessionID
6. show issu message types clientID
DETAILED STEPS

Example:
Router> enable
Step 2 show issu clients Lists network applications and protocols currently supported by ISSU.
• You can use this command to discover the client ID that you will
Example: need to enter in Steps 3 and 6.
Router# show issu clients
4
ISSU MPLS Clients
Configuration Examples for ISSU MPLS Clients

Step 3 show issu sessions clientID Displays detailed information about a particular ISSU client that
includes whether a particular client is compatible with the intended
upgrade.
Example:
Router# show issu sessions 2002 • You can use this command to discover the session ID that you will
need to enter in Steps 4 and 5.
Step 4 show issu negotiated version Displays details of the session’s negotiated message version.
sessionID
Example:
Router# show issu negotiated version
33
Step 5 show issu negotiated capability Displays results of a negotiation about the client application’s
sessionID capabilities.
Example:
Router# show issu negotiated
capability 33
Step 6 show issu message types clientID Displays the message formats (“types”) and versions supported by the
specified client.
Example:
Router# show issu message types 2002

This section contains the following examples for ISSU MPLS clients:
• Verifying the ISSU Process for an MPLS LDP Client: Example, page 7
• Verifying the ISSU Process for an MPLS VPN Client: Example, page 8
• Verifying the ISSU Process for an MPLS VRF (“Table ID”) Client: Example, page 9
• Verifying the ISSU Process for an MPLS LSD Label Manager HA Client: Example, page 9
• Verifying the ISSU Process for an MPLS MFI Pull Client: Example, page 10
• Verifying the ISSU Process for an MPLS MFI Push Client: Example, page 11
• Verifying the ISSU Process for an MPLS LSPV Push Client: Example, page 12
• Verifying the ISSU Process for an MPLS TE Client: Example, page 13
To examine any ISSU client, you must specify its unique client ID when entering the show issu sessions
command. If you do not already know that client ID, enter the show issu clients command in user EXEC
or privileged EXEC mode. Each ISSU client on the network will then be listed, with its client ID and
client name on the same line, as shown in the following example:
Router# show issu clients
Client_ID = 2, Client_Name = ISSU Proto client, Entity_Count = 1

Client_ID = 3, Client_Name = ISSU RF, Entity_Count = 1
Client_ID = 4, Client_Name = ISSU CF client, Entity_Count = 1
Client_ID = 5, Client_Name = ISSU Network RF client, Entity_Count = 1
Client_ID = 7, Client_Name = ISSU CONFIG SYNC, Entity_Count = 1
Client_ID = 8, Client_Name = ISSU ifIndex sync, Entity_Count = 1
5
ISSU MPLS Clients
Client_ID = 9, Client_Name = ISSU IPC client, Entity_Count = 1

Client_ID = 10, Client_Name = ISSU IPC Server client, Entity_Count = 1
Client_ID = 11, Client_Name = ISSU Red Mode Client, Entity_Count = 1
Client_ID = 12, Client_Name = ISSU EHSA services client, Entity_Count = 1
Client_ID = 100, Client_Name = ISSU rfs client, Entity_Count = 1
Client_ID = 110, Client_Name = ISSU ifs client, Entity_Count = 1
Client_ID = 1001, Client_Name = OC3POS-6, Entity_Count = 4
Client_ID = 1002, Client_Name = C10K ATM, Entity_Count = 1
Client_ID = 1003, Client_Name = C10K CHSTM1, Entity_Count = 1
Client_ID = 1004, Client_Name = C10K CT3, Entity_Count = 1
Client_ID = 1005, Client_Name = C10K GE, Entity_Count = 1
Client_ID = 1006, Client_Name = C10K ET, Entity_Count = 1
Client_ID = 1007, Client_Name = C10K CHE1T1, Entity_Count = 1
Client_ID = 1009, Client_Name = C10K MFE, Entity_Count = 1
Client_ID = 1010, Client_Name = C10K APS, Entity_Count = 1
Client_ID = 1013, Client_Name = C10K CARD OIR, Entity_Count = 1
Client_ID = 2002, Client_Name = CEF Push ISSU client, Entity_Count = 1
Client_ID = 2003, Client_Name = ISSU XDR client, Entity_Count = 1
Client_ID = 2004, Client_Name = ISSU SNMP client, Entity_Count = 1
Client_ID = 2005, Client_Name = ISSU HDLC Client, Entity_Count = 1
Client_ID = 2006, Client_Name = ISSU QoS client, Entity_Count = 1
Client_ID = 2007, Client_Name = ISSU LSD Label Mgr HA Client, Entity_Count = 1
Client_ID = 2008, Client_Name = ISSU Tableid Client, Entity_Count = 1
Client_ID = 2009, Client_Name = ISSU MPLS VPN Client, Entity_Count = 1
Client_ID = 2010, Client_Name = ARP HA, Entity_Count = 1
Client_ID = 2011, Client_Name = ISSU LDP Client, Entity_Count = 1
Client_ID = 2012, Client_Name = ISSU HSRP Client, Entity_Count = 1
Client_ID = 2013, Client_Name = ISSU ATM Client, Entity_Count = 1
Client_ID = 2014, Client_Name = ISSU FR Client, Entity_Count = 1
Client_ID = 2015, Client_Name = ISSU REDSSOC client, Entity_Count = 1
Client_ID = 2019, Client_Name = ISSU TCP client, Entity_Count = 1
Client_ID = 2020, Client_Name = ISSU BGP client, Entity_Count = 1
Client_ID = 2021, Client_Name = XDR Int Priority ISSU client, Entity_Count = 1
Client_ID = 2022, Client_Name = XDR Proc Priority ISSU client, Entity_Count = 1
Client_ID = 2023, Client_Name = FIB HWIDB ISSU client, Entity_Count = 1
Client_ID = 2024, Client_Name = FIB IDB ISSU client, Entity_Count = 1
Client_ID = 2025, Client_Name = FIB HW subblock ISSU client, Entity_Count = 1
Client_ID = 2026, Client_Name = FIB SW subblock ISSU client, Entity_Count = 1
Client_ID = 2027, Client_Name = Adjacency ISSU client, Entity_Count = 1
Client_ID = 2028, Client_Name = FIB IPV4 ISSU client, Entity_Count = 1
Client_ID = 2030, Client_Name = MFI Pull ISSU client, Entity_Count = 1
Client_ID = 2031, Client_Name = MFI Push ISSU client, Entity_Count = 1
Client_ID = 2051, Client_Name = ISSU CCM Client, Entity_Count = 1
Client_ID = 2052, Client_Name = ISSU PPP SIP CCM Client, Entity_Count = 1
Client_ID = 2053, Client_Name = ISSU MPLS TE Client, Entity_Count = 1
Client_ID = 2054, Client_Name = ISSU process client, Entity_Count = 1
Client_ID = 2089, Client_Name = MPLS LSPV Push client, Entity_Count = 1
.
.
.
.
Base Clients:
Client_Name = ISSU Proto client
Client_Name = ISSU RF
Client_Name = ISSU CF client
Client_Name = ISSU Network RF client
Client_Name = ISSU CONFIG SYNC
Client_Name = ISSU ifIndex sync
Client_Name = ISSU IPC client
Client_Name = ISSU IPC Server client
Client_Name = ISSU Red Mode Client
Client_Name = ISSU EHSA services client
Client_Name = ISSU rfs client
Client_Name = ISSU ifs client
6
ISSU MPLS Clients
Client_Name = ISSU EM client

Client_Name = ISSU Platform Medialayer Client
Client_Name = ISSU FM Client
Client_Name = ISSU TCAM Manager Client
Client_Name = ISSU L2 Cmn Client
Client_Name = ISSU L3 Manager HA Client
Client_Name = ISSU L3 Manager Client
Client_Name = ISSU CFIB BASE Client
Client_Name = ISSU PF CONFIG SYNC Client
Client_Name = ISSU MLS CEF Client
Client_Name = ISSU Cat6k Logger Client
Verifying the ISSU Process for an MPLS LDP Client: Example

This example shows how to verify the ISSU process for an LDP client.
The first command shows you whether the LDP client’s old and new software versions are compatible,
and therefore are able to make use of the ISSU opportunity:
Router# show issu sessions 2011
---------------------------------------------------------------------
Client_ID = 2011, Entity_ID = 1 :
*** Session_ID = 46, Session_Name = LDP Session :
Peer Peer Negotiate Negotiated Cap Msg Session

UniqueID Sid Role Result GroupID GroupID Signature
4 34 PRIMARY COMPATIBLE 1 1 0
(no policy)
Negotiation Session Info for This Message Session:

Nego_Session_ID = 46
Nego_Session_Name = LDP Session
Transport_Mtu = 3948
Now you can take the session ID displayed in the previous command’s output and enter it into the next
command, to see the negotiated message version:
Router# show issu negotiated version 46
Session_ID = 46 :
Message_Type = 1, Negotiated_Version = 2, Message_MTU = 20
Next you can enter the same session ID into the following command to display the capability negotiation
result:
Router# show issu negotiated capability 46
Session_ID = 46 :
Negotiated_Cap_Entry = 1
Finally, to see which message types and versions are supported by this particular client, you enter the
client ID into the following command:
---------------------------------------------------------------------
Message_Type = 1, Version_Range = 2 ~ 2
7
ISSU MPLS Clients
Message_Ver = 2, Message_Mtu = 20
Verifying the ISSU Process for an MPLS VPN Client: Example

This example shows how to verify the ISSU process for an MPLS VPN client.
The first command shows you whether the VPN client’s old and new software versions are compatible,
---------------------------------------------------------------------
*** Session_ID = 39, Session_Name = MPLS VPN ISSU Session :

3 33 PASSIVE COMPATIBLE 1 1 0
(no policy)

Nego_Session_Name = MPLS VPN ISSU Session
command, in order to see the negotiated message version:
Session_ID = 39 :
result:
Session_ID = 39 :
Finally,= to see which message types and versions are supported by this particular client, you enter the
---------------------------------------------------------------------
8
ISSU MPLS Clients
Verifying the ISSU Process for an MPLS VRF (“Table ID”) Client: Example
This example shows how to verify the ISSU process for an MPLS VRF (“Table ID”) client.
The first command shows you whether the VRF client’s old and new software versions are compatible,
---------------------------------------------------------------------
*** Session_ID = 19, Session_Name = TABLEID ISSU CF :

(no policy)

Nego_Session_Name = TABLEID ISSU CF
Session_ID = 19 :
result:
Session_ID = 19 :
---------------------------------------------------------------------
Verifying the ISSU Process for an MPLS LSD Label Manager HA Client: Example
This example shows how to verify the ISSU process for an MPLS LSD Label Manager HA client.
The first command shows you whether the LSD client’s old and new software versions are compatible,
9
ISSU MPLS Clients
---------------------------------------------------------------------
*** Session_ID = 40, Session_Name = lsd_ha :

(policy)

Nego_Session_Name = lsd_ha
Compat_Result: raw_result = COMPATIBLE, policy_result = COMPATIBLE
Session_ID = 40 :
result:
---------------------------------------------------
Client_ID = 2007, Entity_ID = 1, Session_ID = 40 :
---------------------------------------------------------------------
Verifying the ISSU Process for an MPLS MFI Pull Client: Example
This example shows how to verify the ISSU process for an MPLS MFI Pull client.
The first command shows you whether the MFI Pull client’s old and new software versions are
compatible, and therefore are able to make use of the ISSU opportunity:
---------------------------------------------------------------------
*** Session_ID = 131073, Session_Name = MFI Pull (6):
10
ISSU MPLS Clients

(no policy)

Nego_Session_Name = MFI Pull (6)
Session_ID = 131073:
result:
Session_ID = 131073 :
Finally to see which message types and versions are supported by this particular client, you enter the
---------------------------------------------------------------------
Verifying the ISSU Process for an MPLS MFI Push Client: Example
This example shows how to verify the ISSU process for an MPLS MFI Push client.
The first command shows you whether the MFI Push client’s old and new software versions are
---------------------------------------------------------------------
*** Session_ID = 196646, Session_Name = MFI Push (6):

(no policy)
11
ISSU MPLS Clients

Nego_Session_Name = MFI Push (6)
Session_ID = 196646:
result:
Session_ID = 196646 :
---------------------------------------------------------------------
Verifying the ISSU Process for an MPLS LSPV Push Client: Example
This example shows how to verify the ISSU process for an MPLS LSVP Push client.
The first command shows you whether the LSPV Push client’s old and new software versions are
---------------------------------------------------------------------
*** Session_ID = 45, Session_Name = MPLS LSPV Push (6 ):

(no policy)

Nego_Session_Name = MPLS LSPV Push (6 )
12
ISSU MPLS Clients
Session_ID = 45:
result:
Session_ID = 45:
Cap_Type = 0 Cap_Result = 1 No cap value assigned
---------------------------------------------------------------------
Verifying the ISSU Process for an MPLS TE Client: Example

This example shows how to verify the ISSU process for an MPLS TE client.
The first command shows you whether the TE client’s old and new software versions are compatible,
---------------------------------------------------------------------
*** Session_ID = 84, Session_Name = RSVP HA Session :

(no policy)

Nego_Session_Name = RSVP HA Session
13
ISSU MPLS Clients
Session_ID = 84 :
result:
Session_ID = 84 :
Cap_Type = 0, Cap_Result = 1 No cap value assigned
---------------------------------------------------------------------
The following sections provide references related to the ISSU MPLS Clients feature.
Related Documents
ISSU process • Cisco IOS XE In Service Software Upgrade Process
• Cisco ASR 1000 Series Aggregation Services Routers Software
Configuration Guide
Standards
Standard Title
14
ISSU MPLS Clients
MIBs
MIB MIBs Link
modified by this feature the following URL:
RFCs
RFC Title
Description Link
15
ISSU MPLS Clients
Feature Information for ISSU MPLS Clients

Table 2 Feature Information for ISSU MPLS Clients

ISSU MPLS—LDP Cisco IOS XE This feature allows In Service Software Upgrade (ISSU)
Release 2.1 support for the Label Distribution Protocol (LDP) and
Multiprotocol Label Switching (MPLS) Forwarding.
MPLS applications can be upgraded using the In Service
Software Upgrade (ISSU) process. Thus, MPLS
applications are considered ISSU’s MPLS clients. The
ISSU process allows Cisco IOS XE software to be updated
or otherwise modified while packet forwarding continues.
feature:
• ISSU-Capable Protocols and Applications: Clients,
page 2
• Verifying the ISSU Process for an MPLS Client, page 4
• Verifying the ISSU Process for an MPLS LDP Client:
Example, page 7
• Verifying the ISSU Process for an MPLS LSD Label
Manager HA Client: Example, page 9
• Verifying the ISSU Process for an MPLS MFI Pull
Client: Example, page 10
• Verifying the ISSU Process for an MPLS MFI Push
• Verifying the ISSU Process for an MPLS LSPV Push
16
ISSU MPLS Clients
Table 2 Feature Information for ISSU MPLS Clients

• Verifying the ISSU Process for an MPLS TE Client:
Example, page 13
show issu clients, show issu entities, show issu message
types, show issu negotiated, show issu outage, show issu
sessions.
ISSU—MPLS VPN (Support for IPv4 VPNs) Cisco IOS XE This feature supports In Service Software Upgrade (ISSU)
Release 2.1 for Multiprotocol Label Switching (MPLS) Virtual Private
networks (VPNs) for IPv4 address families only.
feature:
• Verifying the ISSU Process for an MPLS VPN Client:
Example, page 8
• Verifying the ISSU Process for an MPLS VRF (“Table
ID”) Client: Example, page 9
ISSU—MPLS TE Cisco IOS XE This feature allows upgrade or downgrade of compatible
Release 2.3 Cisco IOS XE software images on the back up Route
Processor (RP) while the device is operational and passing
traffic on Multiprotocol Label Switching (MPLS) traffic
engineering (TE) tunnels.
feature:
• Verifying the ISSU Process for an MPLS TE Client:
Example, page 13
17
ISSU MPLS Clients
Glossary
Glossary
IS—intermediate system.
ISSU—In Service Software Upgrade.
LACP—Link Aggregration Control Protocol.
LDP—Label Distribution Protocol.
MFI—Multiprotocol Label Switching Forwarding Infrastructure.
MPLS—Multiprotocol Label Switching.
OAM—Operation, Administration, and Management.
PagP—port aggregation Protocol.
PPP—Point to Point protocol.
RP—Route Processor.
RSVP GR—Resource Reservation Protocol graceful restart.
TE—traffic engineering.
VPN—Virtual Private Network.
VRF—virtual routing and forwarding.
countries.
18
MPLS Traffic Engineering—RSVP Graceful
Restart

The MPLS Traffic Engineering—RSVP Graceful Restart feature allows a neighboring Route Processor
(RP) to recover from disruption in control plane service (specifically, the Label Distribution Protocol
[LDP] component) without losing its Multiprotocol Label Switching (MPLS) forwarding state.

which each feature is supported, see the “Feature Information for MPLS Traffic Engineering—RSVP
Graceful Restart” section on page 11.
Contents
• Prerequisites for MPLS TE—RSVP Graceful Restart, page 2
• Restrictions for MPLS TE—RSVP Graceful Restart, page 2
• Information About MPLS TE—RSVP Graceful Restart, page 2
• How to Configure MPLS TE—RSVP Graceful Restart, page 4
• Configuration Examples for MPLS TE—RSVP Graceful Restart, page 8
• Feature Information for MPLS Traffic Engineering—RSVP Graceful Restart, page 11
MPLS Traffic Engineering—RSVP Graceful Restart
Prerequisites for MPLS TE—RSVP Graceful Restart
Prerequisites for MPLS TE—RSVP Graceful Restart

Perform the following tasks on routers before configuring the MPLS Traffic Engineering—RSVP
Graceful Restart feature:
• Configure the Resource Reservation Protocol (RSVP).
• Enable MPLS.
• Enable graceful restart.
Restrictions for MPLS TE—RSVP Graceful Restart

The MPLS Traffic Engineering—RSVP Graceful Restart feature has the following restrictions:
• Graceful restart supports node failure only.
• Graceful restart does not support restart or recovery on Cisco nodes, but helps in recovering a
neighbor that is restart capable. Cisco routers advertise a restart time of 5 milliseconds (ms) and a
recovery time of 0 in hello messages.
Information About MPLS TE—RSVP Graceful Restart

Understand the following concepts to configure the MPLS TE—RSVP Graceful Restart feature:
• Graceful Restart, page 2
• Graceful Restart Benefits, page 4
Graceful Restart
Graceful restart allows RSVP TE enabled nodes to start gracefully following a node failure in the
network such that the RSVP state after the failure is restored as quickly as possible. The node failure
may be completely transparent to other nodes in the network as far as the RSVP state is concerned.
Graceful restart preserves the label values and forwarding information and works with third-party or
Cisco routers seamlessly.
Graceful restart depends on RSVP hello messages that include Hello Request or Hello Acknowledgment
(ACK) objects between two neighbors.
Figure 1 shows the graceful restart extension to these messages that an object called Restart_Cap, which
tells neighbors that a node, may be capable of restarting if a failure occurs. The time-to-live (TTL) in
these messages is set to 255 so that adjacencies can be maintained through alternate paths even if the
link between two neighbors goes down.
Book Title
2
Information About MPLS TE—RSVP Graceful Restart
Figure 1 How Graceful Restart Works

Help Neighbor
Full SSO Help SSO Help Neighbor

Tunnel
Router 1 Router 4
Router 2 Router 3
117933
Hello Restart_Cap Hello Restart_Cap
Router 5
The Restart_Cap object has two values—the restart time, which is the sender’s time to restart the
RSVP_TE component and exchange hello messages after a failure; and the recovery time, which is the
desired time that the sender wants the receiver to synchronize the RSVP and MPLS databases.
In Figure 1, graceful restart is enabled on Router 1, Router 2, Router 3, and Router 4. For simplicity,
assume that all routers are restart capable. A TE label switched path (LSP) is signaled from Router 1 to
Router 4.
Router 2 and Router 3 exchange periodic graceful restart hello messages every 10,000 ms (10 seconds),
and so do Router 2 and Router 1 and Router 3 and Router 4. Assume that Router 2 advertises its restart
time as 60,000 ms (60 seconds) and its recovery time as 60,000 ms (60 seconds) as shown in the
following example:
23:33:36: Outgoing Hello:
23:33:36: version:1 flags:0000 cksum:883C ttl:255 reserved:0 length:32
23:33:36: HELLO type HELLO REQUEST length 12:
23:33:36: Src_Instance: 0x6EDA8BD7, Dst_Instance: 0x00000000
23:33:36: RESTART_CAP type 1 length 12:
23:33:36: Restart_Time: 0x0000EA60, Recovery_Time: 0x0000EA60
Note The restart and recovery time are shown in bold in the last entry.
Router 3 records this into its database. Also, both neighbors maintain the neighbor status as UP.
However, Router 3’s control plane fails at some point (for example, a Primary Route Processor failure).
As a result, RSVP and TE lose their signaling information and states although data packets continue to
be forwarded by the line cards.
When four ACK messages are missed from Router 2 (40 seconds), Router 3 declares communication
with Router 2 lost “indicated by LOST” and starts the restart time to wait for the duration advertised in
Router 2’s restart time previously and recorded (60 seconds). Router 1 and Router 2 suppress all RSVP
messages to Router 3 except hellos. Router 3 keeps sending the RSVP Path and Resv refresh messages
to Router 4 and Router 5 so that they do not expire the state for the LSP; however, Router 3 suppresses
these messages for Router 2.
Note A node restarts if it misses four ACKs or its hello src_instance (last source instance sent to its neighbor)
changes so that its restart time = 0.
Before the restart time expires, Router 2 restarts and loads its configuration and graceful restart makes
the configuration of router 2 send the hello messages with a new source instance to all the data links
attached. However, because Router 2 has lost the neighbor states, it does not know what destination
instance it should use in those messages; therefore, all destination instances are set to 0.
Book Title
3
How to Configure MPLS TE—RSVP Graceful Restart
When Router 3 sees the hello from Router 2, Router 3 stops the restart time for Router 2 and sends an
ACK message back. When Router 3 sees a new source instance value in Router 2’s hello message, Router
3 knows that Router 2 had a control plane failure. Router 2 gets Router 3’s source instance value and
uses it as the destination instance going forward.
Router 3 also checks the recovery time value in the hello message from Router 2. If the recovery time is
0, Router 3 knows that Router 2 was not able to preserve its forwarding information and Router 3 deletes
all RSVP state that it had with Router 2.
If the recovery time is greater than 0, Router 1 sends Router 2 Path messages for each LSP that it had
previously sent through Router 2. If these messages were previously refreshed in summary messages,
they are sent individually during the recovery time. Each of these Path messages includes a
Recovery_Label object containing the label value received from Router 2 before the failure.
When Router 3 receives a Path message from Router 2, Router 3 sends a Resv message upstream.
However, Router 3 suppresses the Resv message until it receives a Path message.
Graceful Restart Benefits

This feature has the following benefits:
• Graceful restart allows a node to recover state information from its neighbor when there is an RP
failure or the device has undergone a stateful switchover (SSO).
• Graceful restart allows session information recovery with minimal disruption to the network.
• A node can perform a graceful restart to help a neighbor recover its state by keeping the label
bindings and state information to provide a quick recovery of the failed node and not affect the
traffic that is currently forwarded.

• Enabling Graceful Restart, page 4 (required)
• Setting a DSCP Value on a Router for MPLS TE Graceful Restart, page 5 (optional)
• Setting a Hello Refresh Interval for MPLS TE Graceful Restart, page 6 (optional)
• Setting a Missed Refresh Limit for MPLS TE Graceful Restart, page 7 (optional)
• Verifying Graceful Restart Configuration, page 7 (optional)
Enabling Graceful Restart

Perform this task to enable graceful restart.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello graceful-restart mode help-neighbor
4. exit
Book Title
4
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello graceful-restart mode Sets the number of DSCP hello messages on a neighboring
help-neighbor router with restart capability.
Example:
graceful-restart mode help-neighbor
Example:
Setting a DSCP Value on a Router for MPLS TE Graceful Restart

Perform this task to set a DSCP value on a Router for MPLS TE graceful restart.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello graceful-restart dscp num
4. exit
DETAILED STEPS

Example:
Router> enable
Example:
Book Title
5

Step 3 ip rsvp signalling hello graceful-restart dscp Sets the number of DSCP hello messages on a graceful
num restart-enabled router.
Example:
graceful-restart dscp 30
Example:
Setting a Hello Refresh Interval for MPLS TE Graceful Restart

Perform this task to set a hello refresh interval for MPLS TE graceful restart.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello graceful-restart refresh interval interval-value
4. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello graceful-restart Sets a hello refresh interval on a router with graceful restart
refresh interval interval-value enabled.
Example:
graceful-restart refresh interval 5000
Example:
Router(config)# end
Book Title
6
Setting a Missed Refresh Limit for MPLS TE Graceful Restart

Perform this task to set a missed refresh limit for MPLS TE graceful restart.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello graceful-restart refresh misses msg-count
4. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello graceful-restart Sets a refresh limit on a router with graceful restart enabled.
refresh misses msg-count
Example:
graceful-restart refresh misses 5
Example:
Router(config)# end
Verifying Graceful Restart Configuration

Perform this task to verify graceful restart configuration.
SUMMARY STEPS
1. enable
2. show ip rsvp hello graceful-restart
3. exit
Book Title
7
Configuration Examples for MPLS TE—RSVP Graceful Restart
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show ip rsvp hello graceful-restart

Use this command to display information about the status of graceful restart and related parameters. For
example:
Router# show ip rsvp hello graceful-restart
Graceful Restart:Enabled (help-neighbor only)

Refresh interval:10000 msecs
Refresh misses:4
DSCP:0x30
Advertised restart time:0 secs
Advertised recovery time:0 secs
Maximum wait for recovery:3600000 secs
Step 3 exit
Router# exit
Router>
Configuration Examples for MPLS TE—RSVP Graceful Restart

This section provides the following configuration example for the MPLS TE—RSVP Graceful Restart
feature:
• MPLS TE—RSVP Graceful Restart: Example, page 8
MPLS TE—RSVP Graceful Restart: Example

In the following example, graceful restart is enabled, and related parameters, including a DSCP value, a
refresh interval, and a missed refresh limit are set:

Router(config)# ip rsvp signalling hello graceful-restart mode help-neighbor
Router(config)# ip rsvp signalling hello graceful-restart dscp 30
Router(config)# ip rsvp signalling hello graceful-restart refresh interval 10000
Router(config)# ip rsvp signalling hello graceful-restart refresh misses 4
Router(config)# end
Book Title
8
The following sections provide references related to the MPLS TE—RSVP Graceful Restart feature.
Related Documents
RSVP commands: complete command syntax, Cisco IOS Quality of Service Solutions Command Reference
command mode, defaults, usage guidelines, and
examples
Quality of service (QoS) features including signaling, Cisco IOS XE Quality of Service Solutions Configuration Guide,
classification, and congestion management Release 2
Information on stateful switchover, Cisco nonstop MPLS LDP: SSO/NSF Support and Graceful Restart
forwarding, graceful restart
Hellos for state timeout MPLS TE—RSVP Hello State Timer
Standards
Standards Title
MIBs
MIBs MIBs Link
Book Title
9
RFCs
RFCs Title
RFC 3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions
Description Link
Book Title
10
Feature Information for MPLS Traffic Engineering—RSVP Graceful Restart
Feature Information for MPLS Traffic Engineering—RSVP

Graceful Restart
Table 1 Feature Information for MPLS Traffic Engineering—RSVP Graceful Restart

MPLS Traffic Engineering—RSVP Cisco IOS XE The MPLS TE—RSVP Graceful Restart feature allows a
Graceful Restart Release 2.3 neighboring Route Processor (RP) to recover from disruption in
control plane service (specifically, the Label Distribution
Protocol (LDP) component) without losing its MPLS forwarding
state.
• Graceful Restart, page 2
• Graceful Restart Benefits, page 4
• Enabling Graceful Restart, page 4
• Setting a DSCP Value on a Router for MPLS TE Graceful
Restart, page 5
• Setting a Hello Refresh Interval for MPLS TE Graceful
Restart, page 6
• Setting a Missed Refresh Limit for MPLS TE Graceful
Restart, page 7
• Verifying Graceful Restart Configuration, page 7
The following commands were introduced or modified: ip rsvp
signalling hello graceful-restart dscp, ip rsvp signalling hello
graceful-restart mode help-neighbor, ip rsvp signalling hello
graceful-restart refresh interval, ip rsvp signalling hello
graceful-restart refresh misses, show ip rsvp counters, show
ip rsvp counters state teardown, show ip rsvp hello, show ip
rsvp hello client lsp detail, show ip rsvp hello client lsp
summary, show ip rsvp hello client neighbor detail, show ip
rsvp hello client neighbor summary, show ip rsvp hello
graceful-restart, show ip rsvp hello instance detail, show ip
rsvp hello instance summary.
Book Title
11
Glossary
Glossary
ASBR—Autonomous System Boundary Router. A router that connects and exchanges information
between two or more autonomous systems.
backup tunnel—A Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnel used to
protect other (primary) tunnels’ traffic when a link or node failure occurs.
Fast Reroute—A mechanism for protecting Multiprotocol Label Switching (MPLS) traffic engineering
(TE) label switched paths (LSPs) from link and node failure by locally repairing the LSPs at the point
of failure, allowing data to continue to flow on them while their headend routers attempt to establish
end-to-end LSPs to replace them. Fast Reroute (FRR) locally repairs the protected LSPs by rerouting
graceful restart—A process for helping a neighboring Route Processor (RP) restart after a node failure
has occurred.
headend—The router that originates and maintains a given label switched path (LSP). This is the first
instance—A mechanism that implements the Resource Reservation Protocol. (RSVP) hello extensions
for a given router interface address and remote IP address. Active hello instances periodically send Hello
Request messages, expecting Hello ACK messages in response. If the expected ACK message is not
received, the active hello instance declares that the neighbor (remote IP address) is unreachable (that is,
it is lost). This can cause label switched paths (LSPs) crossing this neighbor to be fast rerouted.
cells).
hop-by-hop forwarding by distributing bindings between labels and network prefixes.
LSP—label switched path. A configured connection between two routers, in which Multiprotocol Label
Switching (MPLS) is used to carry packets. A path created by the concatenation of one or more label
switched hops, allowing a packet to be forwarded by swapping labels from an MPLS node to another
MPLS node.
merge point—The tail of the backup tunnel.
PLR—point of local repair. The headend of the backup tunnel.
state—Information that a router must maintain about each label switched path (LSP). The information
is used for rerouting tunnels.
Book Title
12
Glossary
tailend—The router upon which an label switched path (LSP) is terminated. This is the last router in the
LSP’s path.
used.
structure.
countries.
© 2004– 2009 Cisco Systems, Inc. All rights reserved.
Book Title
13
Glossary
Book Title
14
NSF/SSO—MPLS TE and RSVP Graceful Restart

The NSF/SSO—MPLS TE and RSVP Graceful Restart feature allows a Route Processor (RP) to recover
from disruption in control plane service without losing its Multiprotocol Label Switching (MPLS)
forwarding state.
Cisco nonstop forwarding (NSF) with stateful switchover (SSO) provides continuous packet forwarding,
even during a network processor hardware or software failure. In a redundant system, the secondary
processor recovers control plane service during a critical failure in the primary processor. SSO
synchronizes the network state information between the primary and the secondary processor.

which each feature is supported, see the “Feature Information for NSF/SSO—MPLS TE and RSVP Graceful
Restart” section on page 13.
Contents
• Prerequisites for NSF/SSO—MPLS TE and RSVP Graceful Restart, page 2
• Restrictions for NSF/SSO—MPLS TE and RSVP Graceful Restart, page 2
• Information About NSF/SSO—MPLS TE and RSVP Graceful Restart, page 3
• How to Configure NSF/SSO—MPLS TE and RSVP Graceful Restart, page 5
• Configuration Examples for NSF/SSO—MPLS TE and RSVP Graceful Restart, page 10
Prerequisites for NSF/SSO—MPLS TE and RSVP Graceful Restart
• Feature Information for NSF/SSO—MPLS TE and RSVP Graceful Restart, page 13

Prerequisites for NSF/SSO—MPLS TE and RSVP Graceful

Restart
• Configure Resource Reservation Protocol (RSVP) graceful restart in full mode.
• Configure RSVP graceful restart on all interfaces of the neighbor that you want to be restart-capable.
• Configure the redundancy mode as SSO. See the Stateful Switchover feature module for more
information.
• Enable NSF on the routing protocols running among the provider routers (P), provider edge (PE)
routers, and customer edge (CE) routers. The routing protocols are as follows:
– Border Gateway Protocol (BGP)
– Open Shortest Path First (OSPF)
– Intermediate System-to-Intermediate System (IS-IS)
See the Cisco Nonstop Forwarding feature module for more information.
• Enable MPLS.
Restrictions for NSF/SSO—MPLS TE and RSVP Graceful Restart

• RSVP graceful restart supports node failure only.
• You cannot enable RSVP fast reroute (FRR) hello messages and RSVP graceful restart on the same
router.
• You cannot enable primary one-hop autotunnels, backup autotunnels, or autotunnel mesh groups on
a router that is also configured with SSO and Route Processor Redundancy Plus (RPR+). This
restriction does not prevent an MPLS TE tunnel that is automatically configured by TE autotunnel
from being successfully recovered if any midpoint router along the label-switched path (LSP) of the
router experiences an SSO.
• MPLS TE LSPs that are fast reroutable cannot be successfully recovered if the LSPs are FRR active
and the Point of Local Repair (PLR) router experiences an SSO.
• When you configure RSVP graceful restart, you must use the neighbor’s interface IP address.
2
Information About NSF/SSO—MPLS TE and RSVP Graceful Restart
Information About NSF/SSO—MPLS TE and RSVP Graceful

Restart
To configure the NSF/SSO—MPLS TE and RSVP Graceful Restart feature, you should understand the
following concepts:
• Overview of MPLS TE and RSVP Graceful Restart, page 3
• Benefits of MPLS TE and RSVP Graceful Restart, page 4
Overview of MPLS TE and RSVP Graceful Restart

RSVP graceful restart allows RSVP TE-enabled nodes to recover gracefully following a node failure in
the network such that the RSVP state after the failure is restored as quickly as possible. The node failure
may be completely transparent to other nodes in the network.
RSVP graceful restart preserves the label values and forwarding information and works with third-party
or Cisco routers seamlessly.
RSVP graceful restart depends on RSVP hello messages to detect that a neighbor went down. Hello
messages include Hello Request or Hello Acknowledgment (ACK) objects between two neighbors.
As shown in Figure 1, the RSVP graceful restart extension to these messages adds an object called Hello
Restart_Cap, which tells neighbors that a node may be capable of recovering if a failure occurs.
Figure 1 How RSVP Graceful Restart Works

SSO Help Neighbor
Full SSO Help SSO Help Neighbor

Tunnel
Router 1 Router 4
Router 2 Router 3
117933
Hello Restart_Cap Hello Restart_Cap

Router 5
The Hello Restart_Cap object has two values: the restart time, which is the sender’s time to restart the
RSVP_TE component and exchange hello messages after a failure; and the recovery time, which is the
desired time that the sender wants the receiver to synchronize the RSVP and MPLS databases.
In Figure 1, RSVP graceful restart help neighbor support is enabled on Routers 1 and 3 so that they can
help a neighbor recover after a failure, but they cannot perform self recovery. Router 2 has full SSO help
support enabled, meaning it can perform self recovery after a failure or help its neighbor to recover.
Router 2 has two RPs, one that is active and one that is standby (backup). A TE LSP is signaled from
Router 1 to Router 4.
Router 2 performs checkpointing; that is, it copies state information from the active RP to the standby
RP, thereby ensuring that the standby RP has the latest information. If an active RP fails, the standby RP
can take over.
3
Information About NSF/SSO—MPLS TE and RSVP Graceful Restart
Routers 2 and 3 exchange periodic graceful restart hello messages every 10,000 milliseconds (ms)
(10 seconds), and so do Routers 2 and 1 and Routers 3 and 4. Assume that Router 2 advertises its restart
time = 60,000 ms (60 seconds) and its recovery time = 60,000 ms (60 seconds) as shown in the following
example:
23:33:36: Outgoing Hello:
23:33:36: version:1 flags:0000 cksum:883C ttl:255 reserved:0 length:32
23:33:36: HELLO type HELLO REQUEST length 12:
23:33:36: Src_Instance: 0x6EDA8BD7, Dst_Instance: 0x00000000
23:33:36: RESTART_CAP type 1 length 12:
23:33:36: Restart_Time: 0x0000EA60, Recovery_Time: 0x0000EA60
Router 3 records this into its database. Also, both neighbors maintain the neighbor status as UP.
However, Router 3’s control plane fails at some point (for example, a primary RP failure). As a result,
RSVP and TE lose their signaling information and states although data packets continue to be forwarded
by the line cards.
When Router 3 declares communication with Router 2 lost, Router 3 starts the restart time to wait for
the duration advertised in Router 2’s restart time previously recorded (60 seconds). Routers 1 and 2
suppress all RSVP messages to Router 3 except hellos. Router 3 keeps sending the RSVP PATH and
RESV refresh messages to Routers 4 and 5 so that they do not expire the state for the LSP; however,
Routers 1 and 3 suppress these messages for Router 2.
When Routers 1 and 3 receive the hello message from Router 2, Routers 1 and 3 check the recovery time
value in the message. If the recovery time is 0, Router 3 knows that Router 2 was not able to preserve its
forwarding information, and Routers 1 and 3 delete all RSVP state that they had with Router 2.
If the recovery time is greater than 0, Router 1 sends Router 2 PATH messages for each LSP that it had
previously sent through Router 2. If these messages were previously refreshed in summary messages,
they are sent individually during the recovery time. Each of these PATH messages includes a
Recovery_Label object containing the label value received from Router 2 before the failure.
When Router 3 receives a PATH message from Router 2, Router 3 sends a RESV message upstream.
However, Router 3 suppresses the RESV message until it receives a PATH message. When Router 2
receives the RESV message, it installs the RSVP state and reprograms the forwarding entry for the LSP.
Benefits of MPLS TE and RSVP Graceful Restart

State Information Recovery
RSVP graceful restart allows a node to perform self recovery or to help its neighbor recover state
information when there is an RP failure or the device has undergone an SSO.
Session Information Recovery

RSVP graceful restart allows session information recovery with minimal disruption to the network.
Increased Availability of Network Services

A node can perform a graceful restart to help itself or a neighbor recover its state by keeping the label
bindings and state information, thereby providing a faster recovery of the failed node and not affecting
currently forwarded traffic.
4
How to Configure NSF/SSO—MPLS TE and RSVP Graceful Restart
How to Configure NSF/SSO—MPLS TE and RSVP Graceful

Restart
• Enabling RSVP Graceful Restart Globally, page 5 (required)
• Enabling RSVP Graceful Restart on an Interface, page 6 (required)
• Setting a DSCP Value for RSVP Graceful Restart, page 7 (optional)
• Setting a Value to Control the Refresh Interval for RSVP Hello Messages, page 8 (optional)
• Setting a Value to Control the Missed Refresh Limit for RSVP Graceful Restart Hello
Acknowledgements, page 9 (optional)
• Verifying the RSVP Graceful Restart Configuration, page 9 (optional)
Enabling RSVP Graceful Restart Globally

Perform this task to enable RSVP graceful restart globally.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello graceful-restart mode {help-neighbor | full}
4. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello graceful-restart mode Enables RSVP TE graceful restart capability on an RP.
(help-neighbor | full)
• Enter the help-neighbor keyword to enable a
neighboring router to restart after a failure.
Example:
• Enter the full keyword to enable a router to perform self
graceful-restart mode full recovery or to help a neighbor recover after a failure.
Step 4 exit (Optional) Returns to privileged EXEC mode.
Example:
5
Enabling RSVP Graceful Restart on an Interface

Perform this task to enable RSVP graceful restart on an interface.
Note You must repeat this procedure for each of the neighbor router’s interfaces.
SUMMARY STEPS
1. enable
4. Repeat Step 3 as needed to configure additional interfaces.
5. ip rsvp signalling hello graceful-restart neighbor ip-address
6. Repeat Step 5 as needed to configure additional IP addresses on a neighbor router’s interfaces.
7. exit
8. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type Configures the interface type and number and enters
slot/subslot/port[.subinterface-number] interface configuration mode.
Example:
Step 4 Repeat Step 3 as needed to configure additional (Optional) Configures additional interfaces.
interfaces.
Step 5 ip rsvp signalling hello graceful-restart Enables support for RSVP graceful restart on routers
neighbor ip-address helping their neighbors recover TE tunnels following SSO.
Note The IP address must be that of the neighbor’s
Example: interface.
graceful-restart neighbor 10.0.0.0
Step 6 Repeat Step 5 as needed to configure additional IP (Optional) Configures additional IP addresses on a neighbor
addresses on a neighbor router's interfaces. router’s interfaces.
6

configuration mode.
Example:
Step 8 exit (Optional) Exits global configuration mode and returns to
Example:
Setting a DSCP Value for RSVP Graceful Restart

Perform this task to set a differentiated services code point (DSCP) value for RSVP Graceful Restart.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello graceful-restart dscp num
4. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello graceful-restart dscp Sets a DSCP value on a router with RSVP graceful restart
num enabled.
Example:
graceful-restart dscp 30
Example:
7
Setting a Value to Control the Refresh Interval for RSVP Hello Messages
Perform this task to set a value to control the refresh interval for RSVP hello messages.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello graceful-restart refresh interval interval-value
4. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello graceful-restart Sets the value to control the request interval in graceful
refresh interval interval-value restart hello messages. This interval represents the
frequency at which RSVP hello messages are sent to a
Example: neighbor; for example, one hello message is sent per each
Router(config)# ip rsvp signalling hello interval.
graceful-restart refresh interval 5000
Note If you change the default value for this command
and you also changed the RSVP refresh interval
using the ip rsvp signalling refresh interval
command, ensure that the value for the ip rsvp
signalling hello graceful-restart refresh interval
command is less than the value for the ip rsvp
signalling hello refresh interval command.
Otherwise, some or all of the label-switched paths
(LSPs) may not be recovered after an SSO has
occurred.
Example:
8
Setting a Value to Control the Missed Refresh Limit for RSVP Graceful Restart
Hello Acknowledgements
Perform this task to set a value to control the missed refresh limit for RSVP graceful restart hello
acknowledgements.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello graceful-restart refresh misses msg-count
4. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip rsvp signalling hello graceful-restart Specifies how many sequential RSVP TE graceful restart
refresh misses msg-count hello acknowledgments (ACKs) a node can miss before the
node considers communication with its neighbor lost.
Example: Note If you change the default value for this command
Router(config)# ip rsvp signalling hello and you are also using the ip rsvp signalling hello
graceful-restart refresh misses 5
refresh misses command, ensure that the value for
the ip rsvp signalling hello graceful-restart
refresh misses command is less than the value for
the ip rsvp signalling hello refresh misses
command. Otherwise, some or all of the LSPs may
not be recovered after an SSO has occurred.
Example:
Verifying the RSVP Graceful Restart Configuration

Perform this task to verify the RSVP graceful restart configuration.
9
Configuration Examples for NSF/SSO—MPLS TE and RSVP Graceful Restart
SUMMARY STEPS
1. enable
2. show ip rsvp hello graceful-restart
3. exit
DETAILED STEPS

Step 1 enable (Optional) Enables privileged EXEC mode.
Example:
Router> enable
Step 2 show ip rsvp hello graceful-restart Displays information about the status of RSVP graceful
restart and related parameters.
Example:
Step 3 exit (Optional) Returns to user EXEC mode.
Example:
Router# exit
Configuration Examples for NSF/SSO—MPLS TE and RSVP

Graceful Restart
• Configuring NSF/SSO—MPLS TE and RSVP Graceful Restart: Example, page 10
• Verifying the NSF/SSO—MPLS TE and RSVP Graceful Restart Configuration: Example, page 11
Configuring NSF/SSO—MPLS TE and RSVP Graceful Restart: Example

In the following example, RSVP graceful restart is enabled globally and on a neighbor router’s interfaces as
shown in Figure 2. Related parameters, including a DSCP value, a refresh interval, and a missed refresh limit
are set.
Figure 2 Sample Network Configuration
10.0.0.1 10.0.0.2
170320
192.168.0.0 192.168.0.1
10
enable
configure terminal
ip rsvp signalling hello graceful-restart mode full
interface POS 1/0/0
ip rsvp signalling hello graceful-restart neighbor 10.0.0.1
ip rsvp signalling hello graceful-restart neighbor 10.0.0.2
exit
ip rsvp signalling hello graceful-restart dscp 30
ip rsvp signalling hello graceful-restart refresh interval 50000
ip rsvp signalling hello graceful-restart refresh misses 5
exit
Verifying the NSF/SSO—MPLS TE and RSVP Graceful Restart Configuration:

Example
The following example verifies the status of RSVP graceful restart and the configured parameters:
Graceful Restart: Enabled (full mode)

Refresh interval: 10000 msecs
Refresh misses: 4
DSCP:0x30
Advertised restart time: 30000 msecs
Advertised recovery time: 120000 msecs
Maximum wait for recovery: 3600000 msecs
The following sections provide references related to the NSF/SSO—MPLS TE and RSVP Graceful
Restart feature.
Related Documents
RSVP commands: complete command syntax, Cisco IOS Quality of Service Solutions Command Reference
command mode, defaults, usage guidelines, and
examples
Quality of service (QoS) features including signaling, Cisco IOS XE Quality of Service Solutions Configuration Guide,
classification, and congestion management Release 2
Information on stateful switchover, Cisco nonstop NSF/SSO - MPLS LDP and LDP Graceful Restart
forwarding, graceful restart
Hello messages for state timeout MPLS Traffic Engineering—RSVP Hello State Timer
11
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title
RFC 3473 Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Resource Reservation Protocol-Traffic Engineering (RSVP-TE)
Extensions
RFC 4558 Node-ID Based Resource Reservation Protocol (RSVP) Hello: A
Clarification Statement
Description Link
12
Feature Information for NSF/SSO—MPLS TE and RSVP Graceful Restart
Feature Information for NSF/SSO—MPLS TE and RSVP

Graceful Restart
Table 1 Feature Information for NSF/SSO—MPLS TE and RSVP Graceful Restart

NSF/SSO—MPLS TE and RSVP Graceful Cisco IOS XE The NSF/SSO—MPLS TE and RSVP Graceful Restart
Restart Release 2.3 feature allows a Route Processor (RP) to recover from
disruption in control plane service without losing its
Multiprotocol Label Switching (MPLS) forwarding
state.
Cisco nonstop forwarding (NSF) with stateful
switchover (SSO) provides continuous packet
forwarding, even during a network processor hardware
or software failure. In a redundant system, the
secondary processor recovers control plane service
during a critical failure in the primary processor. SSO
synchronizes the network state information between
the primary and the secondary processor.
implemented on the Cisco ASR 1000 Series
Aggregation Services Routers.
feature:
• Overview of MPLS TE and RSVP Graceful
Restart, page 3
• Benefits of MPLS TE and RSVP Graceful Restart,
page 4
• Enabling RSVP Graceful Restart Globally, page 5
• Enabling RSVP Graceful Restart on an Interface,
page 6
• Setting a DSCP Value for RSVP Graceful Restart,
page 7
• Setting a Value to Control the Refresh Interval for
RSVP Hello Messages, page 8
13
Feature Information for NSF/SSO—MPLS TE and RSVP Graceful Restart
Table 1 Feature Information for NSF/SSO—MPLS TE and RSVP Graceful Restart

• Setting a Value to Control the Missed Refresh
Limit for RSVP Graceful Restart Hello
Acknowledgements, page 9
• Verifying the RSVP Graceful Restart
clear ip rsvp high-availability counters, debug ip
rsvp high-availability, debug ip rsvp sso, debug mpls
traffic-eng ha sso, ip rsvp signalling hello
graceful-restart dscp, ip rsvp signalling hello
graceful-restart mode, ip rsvp signalling hello
graceful-restart mode help-neighbor, ip rsvp
signalling hello graceful-restart neighbor, ip rsvp
signalling hello graceful-restart refresh interval, ip
rsvp signalling hello graceful-restart refresh misses,
show ip rsvp counters, show ip rsvp counters state
teardown, show ip rsvp hello, show ip rsvp hello
client lsp detail, show ip rsvp hello client lsp
summary, show ip rsvp hello client neighbor detail,
show ip rsvp hello client neighbor summary, show ip
rsvp hello graceful-restart, show ip rsvp hello
instance detail, show ip rsvp hello instance
summary, show ip rsvp high-availability counters,
show ip rsvp high-availability database, show ip
rsvp high-availability summary.
14
Glossary
Glossary
Fast Reroute—A mechanism for protecting Multiprotocol Label Switching (MPLS) traffic engineering
(TE) label switched paths (LSPs) from link and node failure by locally repairing the LSPs at the point
of failure, allowing data to continue to flow on them while their headend routers attempt to establish
end-to-end LSPs to replace them. Fast reroute (FRR) locally repairs the protected LSPs by rerouting
graceful restart—A process for helping a Route Processor (RP) restart after a node failure has occurred.
headend—The router that originates and maintains a given label switched path (LSP). This is the first
hello instance—A mechanism that implements the Resource Reservation Protocol (RSVP) hello
extensions for a given router interface address and remote IP address. Active hello instances periodically
send hello request messages, expecting Hello ACK messages in response. If the expected ACK message
is not received, the active hello instance declares that the neighbor (remote IP address) is unreachable
(that is, it is lost). This can cause LSPs crossing this neighbor to be fast rerouted.
ISSU—In Service Software Upgrade. Software upgrade without service interruption.
cells).
LSP—label switched path. A configured connection between two routers, in which Multiprotocol Label
Switching (MPLS) is used to carry packets.
state—Information that a router must maintain about each label switched path (LSP). The information
is used for rerouting tunnels.
tailend—The router upon which a label switched path (LSP) is terminated. This is the last router in the
LSP’s path.
used.
15
Glossary
countries.
© 2004—2009 Cisco Systems, Inc. All rights reserved.
16
AToM Graceful Restart

The AToM Graceful Restart feature assists neighboring routers that have nonstop forwarding (NSF),
stateful switchover (SSO) and graceful restart (GR) for Any Transport over MPLS (AToM) to recover
gracefully from an interruption in service. AToM GR functions strictly in helper mode, which means it
helps other routers that are enabled with the NSF/SSO: Any Transport over MPLS and AToM Graceful
Restart feature to recover. If the router with AToM GR fails, its peers cannot help it recover. AToM GR
is based on the MPLS Label Distribution Protocol (LDP) Graceful Restart feature.
Keep the following points in mind when reading this document:
• The AToM GR feature described in this document refers to helper mode.
• For brevity, the NSF/SSO: Any Transport over MPLS and AToM Graceful Restart feature is called
AToM SSO/NSF in this document.

which each feature is supported, see the “Feature Information for AToM Graceful Restart” section on page 8.
Contents
• Prerequisites for AToM Graceful Restart, page 2
• Restrictions for AToM Graceful Restart, page 2
• Information About AToM Graceful Restart, page 2
• How to Configure AToM Graceful Restart, page 2
Prerequisites for AToM Graceful Restart
• Configuration Examples for AToM Graceful Restart, page 3

• Feature Information for AToM Graceful Restart, page 8
Prerequisites for AToM Graceful Restart

AToM must be configured. For information about setting up or configuring AToM, see the Any Transport
over MPLS document.
Restrictions for AToM Graceful Restart

• AToM GR is supported in strict helper mode.
• MPLS LDP GR cannot be configured on label-controlled ATM (LC-ATM) interfaces.
Information About AToM Graceful Restart

To configure AToM GR, you should understand the following concept:
• How AToM Graceful Restart Works, page 2
How AToM Graceful Restart Works

AToM GR works in strict helper mode, which means it helps a neighboring Route Processor (RP) that
has AToM NSF/SSO to recover from a disruption in service without losing its MPLS forwarding state.
The disruption in service could result from a TCP or User Datagram Protocol (UDP) event or the stateful
switchover of a route processor. AToM GR is based on the MPLS LDP Graceful Restart feature, which
preserves forwarding information for AToM circuits during an LDP session interruption. When the
neighboring router establishes a new session, the LDP bindings and MPLS forwarding state are
recovered. For more information related to how the LDP Graceful Restart feature works, see the MPLS
LDP Graceful Restart feature module.
How to Configure AToM Graceful Restart

• Configuring AToM Graceful Restart, page 2 (required)
Configuring AToM Graceful Restart

To configure AToM Graceful Restart, perform the following task.
2
Configuration Examples for AToM Graceful Restart
There is no AToM-specific configuration for AToM GR. You enable LDP GR to assist a neighboring
router configured with AToM NSF/SSO to maintain its forwarding state while the LDP session is
disrupted. See the LDP Graceful Restart document for information about how LDP GR works and how
you can customize it for your network.
SUMMARY STEPS
1. enable
5. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example: • AToM GR is enabled globally. When you enable AToM
Router(config)# mpls ldp graceful-restart GR, it has no effect on existing LDP sessions. New
LDP sessions that are established can perform AToM
GR.
Example:

• Configuring AToM Graceful Restart: Example, page 4
• AToM Graceful Restart—Recovering from an LDP Session Disruption: Examples, page 5
3
Configuring AToM Graceful Restart: Example

The following example shows a Fast Ethernet VLAN over MPLS configuration. PE1 is configured with
AToM Graceful Restart. PE2 is configured with AToM NSF/SSO. The commands for configuring AToM
GR and NSF/SSO are shown in bold.
PE1 with AToM GR PE2 with AToM NSF/SSO

ip cef distributed redundancy
! mode sso
mpls label protocol ldp ip cef distributed
mpls ldp graceful-restart !
mpls ldp router-id Loopback0 mpls label protocol ldp
! mpls ldp graceful-restart
pseudowire-class atom mpls ldp router-id Loopback0
encapsulation mpls !
! pseudowire-class atom
interface Loopback0 encapsulation mpls
ip address 10.1.1.2 255.255.255.255 !
interface FastEthernet2/1/1 ip address 10.2.2.2 255.255.255.255
no ip address !
! interface FastEthernet0/3/2
interface FastEthernet2/1/1.2 no ip address
description “xconnect to PE2” !
encapsulation dot1Q 2 native interface FastEthernet0/3/2.2
xconnect 10.2.2.2 1002 pw-class mpls description “xconnect to PE1”
! encapsulation dot1Q 2
! IGP for MPLS xconnect 10.1.1.2 1002 pw-class mpls
router ospf 10 !
log-adjacency-changes ! IGP for MPLS
auto-cost reference-bandwidth 1000 router ospf 10
network 10.1.1.2 10.0.0.0 area 0 log-adjacency-changes
network 10.1.1.0 10.0.0.255 area 0 nsf enforce global
network 10.2.2.2 10.0.0.0 area 0
network 10.1.1.0 10.0.0.255 area 0
4
AToM Graceful Restart—Recovering from an LDP Session Disruption:

Examples
The following examples show the output of the show mpls l2transport vc command during normal
operation and when an LDP session is recovering from a disruption.
The following example shows the status of the VC on PE1 with AToM GR during normal operation:

------------- -------------------- --------------- ---------- ----------
Fa2/1/1.2 Eth VLAN 2 10.2.2.2 1002 UP
The following example shows the status of the VC on PE1 with AToM GR while the VC is recovering
from an LDP session disruption. The forwarding state for the circuit remains as it was before the
disruption.

------------- -------------------- --------------- ---------- ----------
Fa2/1/1.2 Eth VLAN 2 10.2.2.2 1002 RECOVERING
The following example shows the status of the VC on PE1 with AToM GR after the LDP session
disruption was cleared. The AToM label bindings were advertised within the allotted time and the status
returned to UP.

------------- -------------------- --------------- ---------- ----------
Fa2/1/1.2 Eth VLAN 2 10.2.2.2 1002 UP
The following example shows the detailed status of the VC on PE1 with AToM GR during normal
operation:
Local interface: Fa2/1/1.2 up, line protocol up, Eth VLAN 2 up

Tunnel label: imp-null, next hop point2point
Output interface: Se2/0/2, imposed label stack {16}
Create time: 1d00h, last status change time: 1d00h
Remote interface description: "xconnect to PE2"
VC statistics:
5
The following example shows the detailed status of the VC on PE1 with AToM GR while the VC is
recovering.
Local interface: Fa2/1/1.2 up, line protocol up, Eth VLAN 2 up

Destination address: 10.2.2.2, VC ID: 1002, VC status: recovering
Tunnel label: imp-null, next hop point2point
Output interface: Se2/0/2, imposed label stack {16}
Create time: 1d00h, last status change time: 00:00:03
Signaling protocol: LDP, peer 10.2.2.2:0 down
Remote interface description: "xconnect to PE2"
VC statistics:
The following sections provide references related to the AToM GR feature.
Related Documents
MPLS LDP graceful restart MPLS LDP Graceful Restart
Configuring AToM Any Transport over MPLS
Nonstop forwarding and stateful switchover for AToM NSF/SSO—Any Transport over MPLS and AToM Graceful Restart
MPLS AToM and LDP commands Cisco IOS Multiprotocol Label Switching Command Reference
High availability commands Cisco IOS HIgh Availability Command Reference
Standards
Standards Title
6
MIBs
MIBs MIBs Link
the following URL:
http://www.cisco.com/go/mib
RFCs
RFCs Title
Description Link
7
Feature Information for AToM Graceful Restart

Table 1 Feature Information for AToM Graceful Restart

AToM Graceful Restart Cisco IOS XE The AToM Graceful Restart feature assists neighboring
Release 2.3 routers that have nonstop forwarding (NSF), stateful
switchover (SSO) and graceful restart (GR) for Any
Transport over MPLS (AToM) to recover gracefully from an
interruption in service. AToM GR functions strictly in
helper mode, which means it helps other routers that are
enabled with the NSF/SSO: Any Transport over MPLS and
AToM Graceful Restart feature to recover. If the router with
AToM GR fails, its peers cannot help it recover. AToM GR
is based on the MPLS Label Distribution Protocol (LDP)
Graceful Restart feature.
In Cisco IOS Release XE 2.3, this feature was implemented
Routers.
feature:
• How AToM Graceful Restart Works, page 2
• Configuring AToM Graceful Restart, page 2
This feature uses no new or modified commands
8
countries.
9
10

Cisco IOS XE Multi Protocol Label Switching Configuration Guide, Release 2

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Cisco IOS XE Multi Protocol Label Switching Configuration Guide, Release 2

Uploaded by

Copyright:

Available Formats

Cisco IOS XE Multiprotocol Label

Switching Configuration Guide

Cisco IOS XE Multiprotocol Label Switching Configuration Guide

Last Updated: December 1, 2009

Command Syntax Conventions

Reader Alert Conventions

Cisco IOS XE Documentation Set

Cisco IOS XE Documentation on Cisco.com

New Features List

Cisco IOS XE Supplementary Documents and Resources

Configuration Guides, Command References, and Supplementary Resources

Table 1 Cisco IOS XE Configuration Guides and Command References

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS XE Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS XE Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS XE Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS XE Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 2 Cisco IOS XE Software Supplementary Documents and Resources

Document Title or Resource Description

Additional Resources and Documentation Feedback

© 2009 Cisco Systems, Inc. All rights reserved.

Last Updated: December 1, 2009

Initially Configuring a Device

Changing the Default Settings for a Console or AUX Port

Using the CLI

Understanding Command Modes

Table 1 CLI Command Modes

Command Access Method Prompt Exit Method Mode Usage

Table 1 CLI Command Modes (continued)

Command Access Method Prompt Exit Method Mode Usage

Note A keyboard alternative to the end command is Ctrl-Z.

Using the Interactive Help Feature

Table 2 CLI Interactive Help Commands

The following examples show how to use the help commands:

Understanding Command Syntax

Table 3 CLI Syntax Conventions

Symbol/Text Function Notes

The following examples show syntax conventions:

Router(config)# ethernet cfm domain dname ?

Router(config)# ethernet cfm domain dname level ?

Router(config)# ethernet cfm domain dname level 7 ?

Router(config)# snmp-server file-transfer access-group 10 ?

Router(config)# logging host ?

Understanding Enable and Enable Secret Passwords

Using the Command History Feature

Using Aliases for CLI Commands

Table 4 Default Command Aliases

Command Alias Original Command

Using the no and default Forms of Commands

Using the debug Command

Filtering Output Using Output Modifiers

FastEthernet0/0 is up, line protocol is up

Understanding CLI Error Messages

Table 5 Common CLI Error Messages

Error Message Meaning How to Get Help

Saving Changes to a Configuration

© 2009 Cisco Systems, Inc. All rights reserved.

First Published: June 27, 2000

Finding Feature Information