Mpls 12 2sr Book PDF

Cisco IOS Multiprotocol Label Switching
Configuration Guide
Release 12.2SR
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 UCBs 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 Multiprotocol Label Switching Configuration Guide

2010 Cisco Systems, Inc. All rights reserved.
Using the Command-Line Interface in Cisco IOS
Software
Last Updated: October 14, 2009
This document provides basic information about the command-line interface (CLI) in Cisco IOS
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 xi
Additional Information, page xii
For more information about using the CLI, see the Using the Cisco IOS Command-Line Interface
section of the Cisco IOS Configuration Fundamentals Configuration Guide.
For information about the software documentation set, see the About Cisco IOS 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/Technologies 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 Software
Using the CLI
Changing the Default Settings for a Console or AUX Port

There are only two changes that you can make to a console port and 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 vii
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 x
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 Mode Access Method Prompt Exit Method Mode Usage

User EXEC Log in. Router> Issue the logout or exit Change terminal
command. settings.
Perform basic tests.
Display device status.
Privileged EXEC From user EXEC Router# Issue the disable Issue show and debug
mode, 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
configuration configuration mode, to return to global terminal lines.
issue the line vty or configuration mode or
line console the end command to
command. return to privileged
EXEC mode.
iii
Using the CLI
Table 1 CLI Command Modes (continued)
Command Mode Access Method Prompt Exit Method Mode Usage

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 process Inspect various states on
(available only on enters diagnostic mode failure is the reason for the router, including the
Cisco ASR 1000 in the following entering diagnostic Cisco IOS state.
series routers) scenarios. When a mode, the failure must Replace or roll back the
Cisco IOS process or be resolved and the configuration.
processes fail, in most router must be rebooted
scenarios the router to exit diagnostic mode. Provide methods of
will reload. restarting the Cisco IOS
If the router is in
software or other
A user-configured diagnostic mode
processes.
access policy was because of a
configured using transport-map Reboot hardware (such
the configuration, access as the entire router, an
transport-map the router through RP, an ESP, a SIP, a SPA)
command, which another port or use a or other hardware
directed the user method that is components.
into diagnostic configured to connect to Transfer files into or off
mode. the Cisco IOS CLI. of the router using
The router was If the RP auxiliary port remote access methods
accessed using an was used to access the such as FTP, TFTP, and
RP auxiliary port. router, use another port SCP.
A break signal for access. Accessing
(Ctrl-C, the router through the
Ctrl-Shift-6, or auxiliary port is not
the send break useful for customer
command) was purposes.
entered, and the
router was
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 the purpose of the CLI interactive Help
commands.
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
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
vii
Using the CLI
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 numeral. 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 numeral
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, in a command history buffer, the commands that you enter during
a session. The default number of saved commands 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]
To recall commands from the history buffer, use the following methods:
Press Ctrl-P or the Up Arrow keyRecalls commands beginning with the most recent command.
Repeat the key sequence to recall successively older commands.
Press Ctrl-N or the Down Arrow keyRecalls 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 modeLists 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.
viii
Using the CLI
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. (Command and keyword
examples are from Cisco IOS Release 12.4(13)T.)
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
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 partitionprivileged EXEC mode
Router(config)# alias configure sb source-bridgeglobal configuration mode
Router(config)# alias interface rl rate-limitinterface 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_a1.html.
ix
Using the CLI
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 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.
Filtering Output Using Output Modifiers

Many commands produce lengthy output that may use several screens to display. Using output modifiers,
you can filter this output to show only the information that you want to see.
The following three output modifiers are available:
begin regular-expressionDisplays the first line in which a match of the regular expression is found
and all lines that follow.
include regular-expressionDisplays all lines in which a match of the regular expression is found.
exclude regular-expressionDisplays 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.
x
Saving Changes to a Configuration
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 in- Enter a question mark (?) to display
marker. correctly. The caret (^) marks all the commands that are available in
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 following document:

Cisco IOS Release 12.4T System Message Guide
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.
xi
Additional Information
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
Using the Cisco IOS Command-Line Interface section of the Cisco IOS Configuration
Fundamentals Configuration Guide
http://www.cisco.com/en/US/docs/ios/fundamentals/configuration/guide/cf_cli-basics.html
Cisco Product/Technology Support
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
software
http://www.cisco.com/pcgi-bin/Support/Errordecoder/index.cgi
Command Lookup Tool, a tool to help you find detailed descriptions of Cisco IOS 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
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.
xii
About Cisco IOS Software Documentation
Last Updated: November 20, 2009
This document describes the objectives, audience, conventions, and organization used in Cisco IOS
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 i
Documentation Organization, page iii
Additional Resources and Documentation Feedback, page xi
Documentation Objectives
Cisco IOS documentation describes the tasks and commands available to configure and maintain Cisco
networking devices.
Audience
The Cisco IOS 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 documentation set is also intended for those users experienced with
Cisco IOS software who need to know about new features, new configuration options, and new software
characteristics in the current Cisco IOS release.
Documentation Conventions
In Cisco IOS 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
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.
i
Documentation Conventions
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 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 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, that is enclosed within braces or square brackets
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 software uses the following program code 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
Cisco IOS software for certain processes.
[ ] Square brackets enclose default responses to system prompts.
Reader Alert Conventions

Cisco IOS 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 documentation set, how it is organized, and how to access it on
Cisco.com. It also lists the configuration guides, command references, and supplementary references and
resources that comprise the documentation set. It contains the following topics:
Cisco IOS Documentation Set, page iv
Cisco IOS Documentation on Cisco.com, page iv
Configuration Guides, Command References, and Supplementary Resources, page v
iii
Cisco IOS Documentation Set

The Cisco IOS 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 select severity 3 (moderate)
defects in released Cisco IOS 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 release.
Configuration guidesCompilations of documents that provide conceptual and task-oriented
descriptions of Cisco IOS features.
Command referencesCompilations of command pages in alphabetical order that provide
detailed information about the commands used in the Cisco IOS features and the processes that
comprise the related configuration guides. For each technology, there is a single command
reference that supports all Cisco IOS releases and that is updated at each standard release.
Lists of all the commands in a specific release and all commands that are new, modified, removed,
or replaced in the release.
Command reference book for debug commands. Command pages are listed in alphabetical order.
Reference book for system messages for all Cisco IOS releases.
Cisco IOS Documentation on Cisco.com

The following sections describe the organization of the Cisco IOS documentation set and how to access
various document types.
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.
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.
Feature Guides
Cisco IOS features are documented in feature guides. Feature guides describe one feature or a group of
related features that are supported on many different software releases and platforms. Your Cisco IOS
software release or platform may not support all the features documented in a feature guide. See the
Feature Information table at the end of the feature guide for information about which features in that
guide are supported in your software release.
Configuration Guides
Configuration guides are provided by technology and release and comprise a set of individual feature
guides relevant to the release and technology.
iv
Command References
Command reference books contain descriptions of Cisco IOS 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 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 Supplementary Documents and Resources

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

Table 1 lists, in alphabetical order, Cisco IOS software configuration guides and command references,
including brief descriptions of the contents of the documents. The Cisco IOS command references
contain commands for Cisco IOS software for all releases. The configuration guides and command
references support many different software releases and platforms. Your Cisco IOS software release or
platform may not support all these technologies.
Table 2 lists documents and resources that supplement the Cisco IOS 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 Configuration Guides and Command References
Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Cisco IOS AppleTalk Configuration Guide AppleTalk protocol.
Cisco IOS AppleTalk Command Reference
Cisco IOS Asynchronous Transfer Mode LAN ATM, multiprotocol over ATM (MPoA), and WAN ATM.
Configuration Guide
Cisco IOS Asynchronous Transfer Mode
Command Reference
v
Table 1 Cisco IOS Configuration Guides and Command References (continued)

Cisco IOS Bridging and IBM Networking Transparent and source-route transparent (SRT) bridging,
Configuration Guide source-route bridging (SRB), Token Ring Inter-Switch Link
(TRISL), and token ring route switch module (TRRSM).
Cisco IOS Bridging Command Reference
Cisco IOS IBM Networking Command Reference Data-link switching plus (DLSw+), serial tunnel (STUN), block
serial tunnel (BSTUN); logical link control, type 2 (LLC2),
synchronous data link control (SDLC); IBM Network Media
Translation, including Synchronous Data Logical Link Control
(SDLLC) and qualified LLC (QLLC); downstream physical unit
(DSPU), Systems Network Architecture (SNA) service point,
SNA frame relay access, advanced peer-to-peer networking
(APPN), native client interface architecture (NCIA)
client/server topologies, and IBM Channel Attach.
Cisco IOS Broadband Access Aggregation and DSL PPP over ATM (PPPoA) and PPP over Ethernet (PPPoE).
Configuration Guide
Cisco IOS Broadband Access Aggregation and DSL
Command Reference
Cisco IOS Carrier Ethernet Configuration Guide Connectivity fault management (CFM), Ethernet Local
Management Interface (ELMI), IEEE 802.3ad link bundling,
Cisco IOS Carrier Ethernet Command Reference
Link Layer Discovery Protocol (LLDP), media endpoint
discovery (MED), and Operation, Administration, and
Maintenance (OAM).
Cisco IOS 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
Cisco IOS DECnet Configuration Guide DECnet protocol.
Cisco IOS DECnet Command Reference
Cisco IOS Dial Technologies Configuration Guide Asynchronous communications, dial backup, dialer technology,
dial-in terminal services and AppleTalk remote access (ARA),
Cisco IOS Dial Technologies Command Reference
dial-on-demand routing, dial-out, ISDN, large scale dial-out,
modem and resource pooling, Multilink PPP (MLP), PPP, and
virtual private dialup network (VPDN).
Cisco IOS Flexible NetFlow Configuration Guide Flexible NetFlow.
Cisco IOS Flexible NetFlow Command Reference
Cisco IOS 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 Integrated Session Border Controller A VoIP-enabled device that is deployed at the edge of networks.
Command Reference An SBC is a toolkit of functions, such as signaling interworking,
network hiding, security, and quality of service (QoS).
vi

Cisco IOS Intelligent Services Gateway Subscriber identification, service and policy determination,
Configuration Guide session creation, session policy enforcement, session life-cycle
management, accounting for access and service usage, and
Cisco IOS Intelligent Services Gateway
session state monitoring.
Command Reference
Cisco IOS 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 IP Addressing Services Address Resolution Protocol (ARP), Network Address
Configuration Guide Translation (NAT), Domain Name System (DNS), Dynamic
Cisco IOS IP Addressing Services Host Configuration Protocol (DHCP), and Next Hop Address
Command Reference Resolution Protocol (NHRP).
Cisco IOS IP Application Services Enhanced Object Tracking (EOT), Gateway Load Balancing
Configuration Guide Protocol (GLBP), Hot Standby Router Protocol (HSRP), IP
Services, Server Load Balancing (SLB), Stream Control
Cisco IOS IP Application Services
Transmission Protocol (SCTP), TCP, Web Cache
Command Reference
Communication Protocol (WCCP), User Datagram Protocol
(UDP), and Virtual Router Redundancy Protocol (VRRP).
Cisco IOS IP Mobility Configuration Guide Mobile ad hoc networks (MANet) and Cisco mobile networks.
Cisco IOS IP Mobility Command Reference
Cisco IOS 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 IP Routing: BFD Configuration Guide Bidirectional forwarding detection (BFD).
Cisco IOS IP Routing: BGP Configuration Guide Border Gateway Protocol (BGP), multiprotocol BGP,
multiprotocol BGP extensions for IP multicast.
Cisco IOS IP Routing: BGP Command Reference
Cisco IOS IP Routing: EIGRP Configuration Guide Enhanced Interior Gateway Routing Protocol (EIGRP).
Cisco IOS IP Routing: EIGRP Command Reference
Cisco IOS IP Routing: ISIS Configuration Guide Intermediate System-to-Intermediate System (IS-IS).
Cisco IOS IP Routing: ISIS Command Reference
Cisco IOS IP Routing: ODR Configuration Guide On-Demand Routing (ODR).
Cisco IOS IP Routing: ODR Command Reference
Cisco IOS IP Routing: OSPF Configuration Guide Open Shortest Path First (OSPF).
Cisco IOS IP Routing: OSPF Command Reference
Cisco IOS 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
vii

Cisco IOS IP Routing: RIP Configuration Guide Routing Information Protocol (RIP).
Cisco IOS IP Routing: RIP Command Reference
Cisco IOS IP SLAs Configuration Guide Cisco IOS IP Service Level Agreements (IP SLAs).
Cisco IOS IP SLAs Command Reference
Cisco IOS IP Switching Configuration Guide Cisco Express Forwarding, fast switching, and Multicast
Distributed Switching (MDS).
Cisco IOS IP Switching Command Reference
Cisco IOS IPv6 Configuration Guide For IPv6 features, protocols, and technologies, go to the IPv6
Start Here document.
Cisco IOS IPv6 Command Reference
Cisco IOS ISO CLNS Configuration Guide ISO Connectionless Network Service (CLNS).
Cisco IOS ISO CLNS Command Reference
Cisco IOS LAN Switching Configuration Guide VLANs, Inter-Switch Link (ISL) encapsulation, IEEE 802.10
encapsulation, IEEE 802.1Q encapsulation, and multilayer
Cisco IOS LAN Switching Command Reference
switching (MLS).
Cisco IOS Mobile Wireless Gateway GPRS Support Cisco IOS Gateway GPRS Support Node (GGSN) in a
Node Configuration Guide 2.5-generation general packet radio service (GPRS) and
Cisco IOS Mobile Wireless Gateway GPRS Support 3-generation universal mobile telecommunication system (UMTS)
Node Command Reference network.
Cisco IOS Mobile Wireless Home Agent Cisco Mobile Wireless Home Agent, an anchor point for mobile
Configuration Guide terminals for which mobile IP or proxy mobile IP services are
provided.
Cisco IOS Mobile Wireless Home Agent
Command Reference
Cisco IOS Mobile Wireless Packet Data Serving Node Cisco Packet Data Serving Node (PDSN), a wireless gateway that
Configuration Guide is between the mobile infrastructure and standard IP networks and
Cisco IOS Mobile Wireless Packet Data Serving Node
that enables packet data services in a code division multiple access
Command Reference (CDMA) environment.
Cisco IOS Mobile Wireless Radio Access Networking Cisco IOS radio access network products.
Configuration Guide
Cisco IOS Mobile Wireless Radio Access Networking
Command Reference
Cisco IOS 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 Multi-Topology Routing Unicast and multicast topology configurations, traffic
Configuration Guide classification, routing protocol support, and network
Cisco IOS Multi-Topology Routing management support.
Command Reference
Cisco IOS NetFlow Configuration Guide Network traffic data analysis, aggregation caches, and export
features.
Cisco IOS NetFlow Command Reference
viii

Cisco IOS Network Management Configuration Guide Basic system management; system monitoring and logging;
troubleshooting, logging, and fault management;
Cisco IOS Network Management Command Reference
Cisco Discovery Protocol; Cisco IOS Scripting with Tool
Control Language (Tcl); Cisco networking services (CNS);
DistributedDirector; Embedded Event Manager (EEM);
Embedded Resource Manager (ERM); Embedded Syslog
Manager (ESM); HTTP; Remote Monitoring (RMON); SNMP;
and VPN Device Manager Client for Cisco IOS software
(XSM Configuration).
Cisco IOS Novell IPX Configuration Guide Novell Internetwork Packet Exchange (IPX) protocol.
Cisco IOS Novell IPX Command Reference
Cisco IOS Optimized Edge Routing Optimized edge routing (OER) monitoring; Performance
Configuration Guide Routing (PfR); and automatic route optimization and load
Cisco IOS Optimized Edge Routing distribution for multiple connections between networks.
Command Reference
Cisco IOS Quality of Service Solutions Traffic queueing, traffic policing, traffic shaping, Modular QoS
Configuration Guide CLI (MQC), Network-Based Application Recognition (NBAR),
Cisco IOS Quality of Service Solutions Multilink PPP (MLP) for QoS, header compression, AutoQoS,
Command Reference Resource Reservation Protocol (RSVP), 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;
network data encryption with router authentication; public key
infrastructure (PKI); RADIUS; TACACS+; terminal access
security; and traffic filters.
Cisco IOS Security Configuration Guide: Securing the Access Control Lists (ACLs); Firewalls: Context-Based Access
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 Security Configuration Guide: Securing the Control Plane Policing, Neighborhood Router Authentication.
Control Plane
Cisco IOS Security Configuration Guide: Securing AAA (includes 802.1x authentication and Network Admission
User Services Control [NAC]); Security Server Protocols (RADIUS and
TACACS+); Secure Shell (SSH); Secure Access for Networking
Devices (includes Autosecure and Role-Based CLI access);
Lawful Intercept.
Cisco IOS Security Configuration Guide: Secure Internet Key Exchange (IKE) for IPsec VPNs; IPsec Data Plane
Connectivity features; IPsec Management features; Public Key Infrastructure
(PKI); Dynamic Multipoint VPN (DMVPN); Easy VPN; Cisco
Group Encrypted Transport VPN (GETVPN); SSL VPN.
ix

Cisco IOS Service Advertisement Framework Cisco Service Advertisement Framework.
Configuration Guide
Cisco IOS Service Advertisement Framework
Command Reference
Cisco IOS Service Selection Gateway Subscriber authentication, service access, and accounting.
Configuration Guide
Cisco IOS Service Selection Gateway
Command Reference
Cisco IOS Software Activation Configuration Guide An orchestrated collection of processes and components to
activate Cisco IOS software feature sets by obtaining and
Cisco IOS Software Activation Command Reference
validating Cisco software licenses.
Cisco IOS Software Modularity Installation and Installation and basic configuration of software modularity
Configuration Guide images, including installations on single and dual route
processors, installation rollbacks, software modularity binding,
Cisco IOS Software Modularity Command Reference
software modularity processes, and patches.
Cisco IOS Terminal Services Configuration Guide DEC, local-area transport (LAT), and X.25 packet
assembler/disassembler (PAD).
Cisco IOS Terminal Services Command Reference
Cisco IOS Virtual Switch Command Reference Virtual switch redundancy, high availability, and packet handling;
converting between standalone and virtual switch modes; virtual
switch link (VSL); Virtual Switch Link Protocol (VSLP).
Note For information about virtual switch configuration, see
the product-specific software configuration information
for the Cisco Catalyst 6500 series switch or for the
Metro Ethernet 6500 series switch.
Cisco IOS Voice Configuration Library Cisco IOS support for voice call control protocols, interoperability,
physical and virtual interface management, and troubleshooting.
Cisco IOS Voice Command Reference
The library includes documentation for IP telephony applications.
Cisco IOS VPDN Configuration Guide Layer 2 Tunneling Protocol (L2TP) dial-out load balancing and
redundancy; L2TP extended failover; L2TP security VPDN;
Cisco IOS VPDN Command Reference
multihop by Dialed Number Identification Service (DNIS);
timer and retry enhancements for L2TP and Layer 2 Forwarding
(L2F); RADIUS Attribute 82 (tunnel assignment ID);
shell-based authentication of VPDN users; tunnel authentication
via RADIUS on tunnel terminator.
Cisco IOS Wide-Area Networking Frame Relay; Layer 2 Tunnel Protocol Version 3 (L2TPv3);
Configuration Guide L2VPN Pseudowire Redundancy; L2VPN Interworking; Layer 2
Cisco IOS Wide-Area Networking Local Switching; Link Access Procedure, Balanced (LAPB);
Command Reference and X.25.
Cisco IOS Wireless LAN Configuration Guide Broadcast key rotation, IEEE 802.11x support, IEEE 802.1x
authenticator, IEEE 802.1x local authentication service for
Cisco IOS Wireless LAN Command Reference
Extensible Authentication Protocol-Flexible Authentication via
Secure Tunneling (EAP-FAST), Multiple Basic Service Set ID
(BSSID), Wi-Fi Multimedia (WMM) required elements, and
Wi-Fi Protected Access (WPA).
x
Additional Resources and Documentation Feedback
Table 2 lists documents and resources that supplement the Cisco IOS software configuration guides and
command references.
Table 2 Cisco IOS 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 releases.
Cisco IOS New, Modified, Removed, and List of all the new, modified, removed, and replaced commands
Replaced Commands for a Cisco IOS release.
Cisco IOS System Message Guide List of Cisco IOS 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 system software.
Cisco IOS Debug Command Reference Alphabetical list of debug commands including brief
descriptions of use, command syntax, and usage guidelines.
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 software releases.
MIBs Files used for network monitoring. To locate and download
MIBs for selected platforms, Cisco IOS releases, and feature
sets, use Cisco MIB Locator.
RFCs Standards documents maintained by the Internet Engineering
Task Force (IETF) that Cisco IOS documentation references
where applicable. The full text of referenced RFCs may be
obtained at the following URL:
http://www.rfc-editor.org/

Whats New in Cisco Product Documentation is released monthly and describes all new and revised
Cisco technical documentation. The Whats 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 technical documentation includes embedded feedback forms where you can rate documents
and provide suggestions for improvement. Your feedback helps us improve our documentation.
xi
xii
Basic MPLS
MPLS Static Labels
First Published: October 2002

Last Updated: July 13, 2007
This document describes the Cisco MPLS Static Labels feature. It identifies the supported platforms,
provides configuration examples, and lists related Cisco IOS command-line interface (CLI) commands.
Finding Support Information for Platforms and Cisco IOS and Catalyst OS Software Images
History for the MPLS Static Labels feature

Release Modification
12.0(23)S This feature was introduced.
12.2(33)SRA This feature was integrated into Cisco IOS Release 12.2(33)SRA.
12.2(33)SXH This feature was integrated into Cisco IOS Release 12.2(33)SXH.
Contents
Feature Overview, page 2
Prerequisites, page 2
Configuration Tasks, page 3
Monitoring and Maintaining MPLS Static Labels, page 4
Configuration Examples, page 5
Additional References, page 6
Command Reference, page 7
Glossary, page 9
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA

MPLS Static Labels
Feature Overview
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:
The binding between a label and an IPv4 prefix
The contents of an LFIB crossconnect entry
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)
IP 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
Monitoring and Maintaining MPLS Static Labels
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
forwarding table as routing demands.
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 point2point (in LFIB)
Monitoring and Maintaining MPLS Static Labels

Refer to the following Table to monitor and maintain MPLS Static Labels.
4
MPLS Static Labels
Configuration Examples
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.
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 to100000 to 200 to100000 and configures a static label range of 16 to199.
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:

[Configured range for next reload: Min/Max label: 200/100000]
In the following output, the show mpls label range command, executed after a reload, indicates that the
new label ranges are in effect:

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
5
MPLS Static Labels
Additional References
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:
Router# show mpls static binding ipv4
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:

Router(config)# mpls static crossconnect 34 pos3/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 point2point (in LFIB)
The following sections provide references related to the MPLS Static Labels feature.
6
MPLS Static Labels
Command Reference
Related Documents
Related Topic Document Title
MPLS commands Multiprotocol Label Switching Command Reference
Standards
Standard Title
None
MIBs
MIB MIBs Link
None To locate and download MIBs for selected platforms, Cisco IOS
releases, and feature sets, use Cisco MIB Locator found at the
following URL:
http://www.cisco.com/go/mibs
RFCs
RFC Title
None
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.
Command Reference
The following commands are introduced or modified in the feature or features documented in this
7
MPLS Static Labels
Command Reference
module. For information about these commands, see the Cisco IOS Multiprotocol Label Switching
Command Reference at http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_book.html.
For information about all Cisco IOS commands, go to the Command Lookup Tool at
http://tools.cisco.com/Support/CLILookup or to the Cisco IOS Master Commands List.
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
8
MPLS Static Labels
Glossary
Glossary
BGPBorder Gateway Protocol. The predominant interdomain routing protocol used in IP networks.
Border Gateway ProtocolSee BGP.
FIBForwarding Information Base. A table that contains a copy of the forwarding information in the
IP routing table.
Forwarding Information BaseSee FIB.
labelA short, fixed-length identifier that tells switching nodes how the data (packets or cells) should
be forwarded.
label bindingAn 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 ProtocolSee LDP.
Label Forwarding Information BaseSee LFIB.
label impositionThe act of putting the first label on a packet.
label switching routerSee LSR.
LDPLabel Distribution Protocol. The protocol that supports MPLS hop-by-hop forwarding by
distributing bindings between labels and network prefixes.
LFIBLabel Forwarding Information Base. A data structure in which destinations and incoming labels
are associated with outgoing interfaces and labels.
LSRlabel switching router. A Layer 3 router that forwards a packet based on the value of an identifier
encapsulated in the packet.
MPLSMultiprotocol Label Switching. An industry standard on which label switching is based.
MPLS hop-by-hop forwardingThe forwarding of packets along normally routed paths using MPLS
forwarding mechanisms.
Multiprotocol Label SwitchingSee MPLS.
Resource Reservation ProtocolSee RSVP.
RIBRouting Information Base. A common database containing all the routing protocols running on a
router.
Routing Information BaseSee RIB.
RSVPResource Reservation Protocol. A protocol for reserving network resources to provide quality
of service guarantees to application flows.
traffic engineeringTechniques 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 NetworkSee VPN.
VPNVirtual Private Network. A network that enables IP traffic to use tunneling to travel securely over
a public TCP/IP network.
9
MPLS Static Labels
Glossary
CCVP, the Cisco logo, and Welcome to the Human Network are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is
a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco
Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS,
iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networkers,
Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient,
and TransPath 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. (0711R)
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.
10
NetFlow MPLS Label Export
First Published: February 23, 2006

Last Updated: February 15, 2008
The NetFlow MPLS Label Export feature allows a label switch router (LSR) to collect and export
Multiprotocol Label Switching (MPLS) labels allocated by the LSR when an adjacent router pushes that
label on the top of the label stack of a transit packet. At the same time, the LSR collects the prefix
associated with the MPLS label and the application that allocated the label. The router collects the
information in a table called the MPLS Prefix/Application/Label (PAL) table and exports this data to a
NetFlow collector as the label is allocated or, if so configured, periodically exports the full MPLS PAL
table.
You can use this information to create a provider edge (PE)-to-PE matrix, which is useful for network
traffic planning and billing. To realize this benefit, you must export the MPLS label information to a
NetFlow collector for analysis. This feature also provides information that a NetFlow collector can use
to create a Virtual Private Network (VPN) routing and forwarding instance (VRF)-to-PE and PE-to-VRF
matrix.
Finding Feature Information in This Module

Your Cisco IOS software release may not support all of the features documented in this module. To reach
links to specific feature documentation in this module and to see a list of the releases in which each feature is
supported, use the Feature Information for NetFlow MPLS Label Export section on page 16.
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and software image support.
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
http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
Prerequisites for NetFlow MPLS Label Export, page 2
Restrictions for NetFlow MPLS Label Export, page 2
Information About NetFlow MPLS Label Export, page 3

Prerequisites for NetFlow MPLS Label Export
How to Configure NetFlow MPLS Label Export, page 7

Configuration Examples for NetFlow MPLS Label Export, page 12
Feature Information for NetFlow MPLS Label Export, page 16
Glossary, page 17
Prerequisites for NetFlow MPLS Label Export

The NetFlow MPLS Label Export feature requires the following:
NetFlow configured on the LSR
MPLS enabled on the LSR
If you are exporting data to a Cisco NetFlow collector, the following requirements apply:
NetFlow Version 9 export format configured on the LSR
NetFlow collector and analyzer that can use MPLS PAL records exported in NetFlow Version 9
format
Restrictions for NetFlow MPLS Label Export

The following restrictions apply to the NetFlow MPLS Label Export feature for Cisco IOS 12.2S
releases and Cisco IOS Release 12.5(1):
The MPLS PAL table does not support the export of information for the following:
IP Version 6 (IPv6) labels
IP Multicast labels
Quality of service (QoS) labels
Traffic engineering (TE) tunnel headend labels
The ability to create a VRF-to-VRF traffic matrix is not supported.
If one application deallocates a label and a second application soon reallocates the same label, the
NetFlow collector might not be able to determine how many packets flowed while the label was
owned by each application.
In MPLS PAL table records, for labels allocated by VPNs, Border Gateway Protocol (BGP) IPv4,
or BGP VPN Version 4 (VPNv4), the stored prefix can be either 0.0.0.0 or a route distinguisher
(RD)-specific address:
If you do not configure the mpls export vpnv4 prefixes command, VPN prefixes are not tracked
in the MPLS PAL table. These prefixes are displayed by the show mpls flow mappings
command as 0.0.0.0.
If you configure the mpls export vpnv4 prefixes command, VPN prefixes are tracked and
RD-specific addresses are displayed by the show mpls flow mappings command.
2
Information About NetFlow MPLS Label Export

The following sections contain useful information for understanding how to configure and use the
NetFlow MPLS Label Export feature:
MPLS Label Information Gathering and Exporting, page 3
Labels Allocated by VPNs, BGP IPv4, or BGP VPNv4 in the MPLS PAL Table, page 4
MPLS PAL Table Record Export, page 4
MPLS PAL and NetFlow Statistics Correlation on a NetFlow Collector, page 6
MPLS Label Mapping on a Line Card, page 7
MPLS Label Information Gathering and Exporting

In a Cisco IOS 12.0S, 12.3T, or 12.4T release that supports the MPLS-Aware NetFlow feature, the
mapping of the MPLS label to a prefix and an MPLS application is achieved through the use of the Label
Forwarding Information Base (LFIB). You can display this information with the show ip cache verbose
flow command. These releases do not support the NetFlow MPLS Label Export feature.
In a Cisco IOS 12.2(28)SB release or later release that supports the NetFlow MPLS Label Export feature,
the mapping of the MPLS label to a destination prefix or Forwarding Equivalence Class (FEC) and to
the MPLS application currently using the label is achieved through the use of an MPLS PAL table. Each
supported MPLS application on the router where the NetFlow MPLS Label Export feature is configured
registers its label values, prefixes, and owning applications as the labels are allocated. This
label-tracking functionality operates on the Route Processor (RP) software.
The MPLS label information (label to prefix and application) mapping is exported to a NetFlow collector
at the time when the label is allocated. You can configure periodic export of the full MPLS PAL table to
a collector for further processing and analysis through the use of the mpls export interval command.
An interval argument to the mpls export interval command controls the time in minutes between full
MPLS PAL table exports to the NetFlow collector. You can configure an interval in the range of
0 to 10080 (1 week) minutes:
If you want to export MPLS PAL table information only when the label is allocated, then configure
this command with a 0 time interval with the mpls export interval 0 command.
If you want to trigger an immediate export of the full MPLS PAL table, reconfigure the command
with an interval argument that is different from the interval that is configured. For example, if you
have configured the mpls export interval 1440 command, reconfigure the command with any
nonzero number except 1440.
If you have a complex network that generates a large amount of traffic, configure a large interval
between MPLS PAL table exports. You might want to configure an interval from 6 to 12 hours (360
and 720 minutes).
The interval argument that you specify is the least amount of time that passes before another export of
the MPLS PAL table occurs. The system could delay the MPLS PAL table export for 10 minutes if the
PAL export queue already contains a large number of entries. This could happen if the export occurred
at a time when thousands of routes just came up, or if NetFlow did not have the time to clear the export
queue from either a previous export of the full table or a previous time when thousands of routes came
up in a brief period of time.
After you have entered the mpls export interval command, you can use the show mpls flow mappings
command to display MPLS PAL table entries. To display information about the number of MPLS PAL
records exported to the collector, use the show ip flow export verbose command.
3
Labels Allocated by VPNs, BGP IPv4, or BGP VPNv4 in the MPLS PAL Table
If you want to see VPN prefix information, that is, labels allocated by VPN, BGP IPv4, or BGP VPNv4,
you need to configure the mpls export vpnv4 prefixes command. If you do not configure the mpls
export vpnv4 prefixes command, MPLS PAL stores labels allocated by these application as
prefix 0.0.0.0.
After you configure the mpls export vpnv4 prefixes command, the VPN prefix and the associated RD
are stored in the MPLS PAL table. VPN addresses are made unique by adding an RD to the front of the
address. The RD removes any ambiguity when the same VPN prefix is used for more than one VRF.
Note To export VPN prefixes and associated RDs from the MPLS PAL table, the first time you configure the
mpls export vpnv4 prefixes command you need to save the configuration and reboot the router or clear
all routes from the table.
To display the VPN prefix entries in the MPLS PAL table, use the show mpls flow mappings command.
With the mpls export vpnv4 prefixes command configured, a line of the output might look like this:
Router# show mpls flow mappings
Label Owner Route-Distinguisher Prefix Allocated

.
.
.
27 BGP 100:1 10.34.0.0 00:57:48
The format of the Route-Distinguisher field in the output depends on how the RD was configured. The
RD can be configured in the as-number:network number (ASN:nn) format, as shown in the example, or
it can be configured in the IP address:network number format (IP-address:nn).
If you did not configure the mpls export vpnv4 prefixes command, a line of the output looks like this:
.
.
.
21 BGP 0.0.0.0 00:52:18
The Route-Distinguisher field is not populated and the Prefix is displayed as 0.0.0.0.
If the MPLS PAL table tracks a per-VRF aggregate label and you configured the mpls export vpnv4
prefixes command, the show mpls flow mappings command displays the RD associated with the
per-VRF aggregate label, but the prefix for the per-VRF aggregate label is reported as 0.0.0.0. If the mpls
export vpnv4 prefixes command is not configured, the per-VRF aggregate label is reported with no RD
and prefix 0.0.0.0, and you cannot distinguish the per-VRF aggregate label from a normal BGP label.
MPLS PAL Table Record Export

In Cisco IOS Release 12.0S and later releases, the export of MPLS-Aware NetFlow cache records makes
use of the NetFlow Version 9 export format data and template. The export of MPLS PAL table entries
also uses the NetFlow Version 9 export format. MPLS PAL packets are exported as NetFlow options
packets rather than NetFlow data packets. NetFlow options packets are defined in Cisco Systems
NetFlow Services Export Version 9, Request for Comments (RFC) 3954.
4
The RP on the PE router learns and queues the MPLS PAL table records for export. The RP can combine
large numbers of PAL table entries in a single Version 9 record and send the record to the NetFlow
collector. The information exported by the RP contains instances of the following for each tracked label:
Label, allocating-application (Owner), Route-Distinguisher, Prefix, time stamp (Allocated)
Because the mapping may change as labels expire and are reused, each PAL record contains a time stamp
indicating the system uptime at which the label was allocated.
NetFlow Export Template Format Used for MPLS PAL Entries

This is the NetFlow Version 9 export template format used for MPLS PAL entries:
MPLS label: 3 bytes
MPLS label application type: 1 byte
MPLS label IP prefix: 4 bytes
MPLS VPN prefix RD: 8 bytes
MPLS label allocation time: 4 bytes
MPLS Application Types Exported

The following MPLS application types are exported in the MPLS label application type field:
TE = 1
ATOM = 2
VPN = 3
BGP = 4
LDP = 5
Options Template and Options Data Record for MPLS PAL Record Export
Figure 1 shows an example of the options template and options data record for MPLS PAL record export.
This example shows that MPLS label 44 was allocated by a VPN 0x03 at 08:50:20 and is associated with
the IP address 10.20.0.20 and with RD 100:1.
5
Figure 1 MPLS PAL Export Format Record
Options template (16 bits)
FlowsSet ID = 1
Length = 38 Options data record (32 bits)
Template ID = 276 Template ID = 276 Length = 28 bytes
Options scope Length = 4 bytes 192.168.62.44
Options Length = 20 bytes 44 0x03
System (0x0001)
10.20.0.20
Length = 4 bytes
MPLS_LABEL 1 (0x0046)
100
Length = 3 bytes
MPLS_TOP_LABEL_TYPE (0x002E) :1
Length = 1 byte
MPLS_TOP_LABEL_IP_ADDR (0x002F)
08:50:20
Length = 4 bytes
MPLS_PAL_RD (0x005A)
Length = 8 bytes
146612
FIRST_SWITCHED (0x0015)
Length = 4 bytes
MPLS PAL and NetFlow Statistics Correlation on a NetFlow Collector

A NetFlow collector can gather the PAL NetFlow packets from a PE router and correlate the label
mappings with the recent NetFlow records from adjacent provider core (P) routers.
For example, the MPLS PAL export packet contains MPLS label mappings over a period of time, as each
label is allocated and reallocated on the PE router. The packet might contain the following information:
label 5, prefix 10.0.0.0, type LDP, 12:00:00
label 4, prefix 10.10.0.0, type LDP, 13:00:00
label 5, prefix 10.9.0.0, type VPN, 14:00:00
The NetFlow collector then receives a NetFlow packet from the adjacent P router indicating the
following:
label 5, 123 packets, 9876 bytes, time 12:22:15.
The collector would match the time range known from the PAL packets with the line card (LC) packet
time stamp. This would result in the correct mapping for label 5 at time 12:22:15, as follows:
label 5, application LDP, prefix 10.0.0.0.
The NetFlow collector needs to be able to handle relative differences in the time stamps caused by
different reboot times of the P and PE routers.
6
How to Configure NetFlow MPLS Label Export
To implement the offline label mapping checks in the NetFlow collector, the collector needs to maintain
a history of label mappings obtained from the MPLS PAL NetFlow packets sent by the RP. If a label is
deallocated and reallocated, the collector should track both the old and the new MPLS PAL information
for the label.
Note On a rare occasion, the collector might not be able to accurately track how many packets flowed for a
label that has been deallocated by one application and soon reallocated by another application.
MPLS Label Mapping on a Line Card

Label to prefix and application mapping is registered and exported from the router RP. This functionality
does not occur on the line card. If you want to see the mapping for a particular label on a line card and
the label of interest is tracked by the MPLS PAL table, then you can do the following:
Enter the show mpls forwarding command on the line card.
Enter the show mpls flow mappings on the RP.
Compare the output of the two commands.
You might find the | include keyword to the commands useful in this case. For example, You could enter
the show mpls flow mappings | include 777 command to see the information for any label with
substring 777.

Perform the following tasks to configure the NetFlow MPLS Label Export feature on an LSR. This
feature provides the label, prefix, and application mapping through the MPLS PAL table that collects
and exports the data to a NetFlow collector.
Configuring NetFlow MPLS Label Export and MPLS PAL Table Export, page 7 (required)
Displaying Information About the MPLS PAL Table, page 9 (optional)
Configuring the Export of MPLS VPN Version 4 Label Information from the MPLS PAL Table to a
NetFlow Collector, page 10 (optional)
Configuring NetFlow MPLS Label Export and MPLS PAL Table Export
Perform this task to configure the NetFlow MPLS Label Export feature and MPLS PAL table export to
a NetFlow collector. You can use the information generated for network traffic planning and billing.
The following task must be completed before MPLS labels are allocated by the router for the MPLS PAL
table to be exported to a NetFlow collector.
SUMMARY STEPS
1. enable
2. configure terminal
3. mpls export interval interval
4. end
7
5. copy running-config startup-config

6. exit
7. Reboot the router.
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 mpls export interval interval Configures a periodic time interval for the export of the
entire MPLS PAL table to a NetFlow collector.
Example: The interval argument specifies the time in minutes
Router(config)# mpls export interval 360 between full PAL table exports. The range of valid time
intervals is 0 to 10,080 minutes.
We recommend that you select a time interval from
360 minutes (6 hours) to 1440 minutes (24 hours)
depending on the size of your network and how often
the NetFlow collector might be restarted.
If you enter an interval of 0, full PAL table exports are
disabled. PAL information is exported only as labels
are allocated.
If you need to restart your NetFlow collector and want
to learn PAL information immediately, you can change
the interval argument. When you change the time
interval, the application exports the full PAL table.
Note Allocated labels are tracked only after you enter the
mpls export interval command. Any labels
allocated before you enter this command are not
tracked.
Step 4 end Exits to privileged EXEC mode.
Example:
Router(config)# end
Step 5 copy running-config startup-config Copies the modified configuration into router NVRAM,
permanently saving the settings.
Example: The next time the router is reloaded or rebooted the
Router# copy running-config startup-config NetFlow MPLS Label Export feature is already part of the
configuration.
8

Step 6 exit Exits to user EXEC mode.
Example:
Router# exit
Step 7 Reboot the router. (Optional) Saves the configuration and reboots the router to
ensure that the information collected by this feature is
complete.
Displaying Information About the MPLS PAL Table

Perform this task to display information about the MPLS PAL table. The information displayed includes
the label, the application that allocated the label, an RD and destination prefix associated with the label,
and the time the label was allocated by the application.
SUMMARY STEPS
1. enable
2. show mpls flow mappings
3. show ip flow export verbose | include PAL
4. 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 flow mappings

Use this command to display entries in the MPLS PAL table. For example:

18 LDP 10.0.0.5 00:52:10
21 BGP 0.0.0.0 00:52:18
22 BGP 0.0.0.0 00:52:18
25 BGP 0.0.0.0 00:51:44
26 LDP 10.32.0.0 00:52:10
27 TE-MIDPT 10.30.0.2 00:52:06
28 LDP 10.33.0.0 00:52:10
29 LDP 10.0.0.1 00:52:10
30 LDP 10.0.0.3 00:52:10
In this example, the mpls export vpnv4 prefixes command was not configured. Therefore, the
MPLS PAL functionality did not export an RD for the BGP application, and the associated prefix is
exported as 0.0.0.0.
The following shows sample output from the show mpls flow mappings command if you previously
entered the mpls export vpnv4 prefixes command:
9

16 LDP 10.0.0.3 00:58:03
17 LDP 10.33.0.0 00:58:03
19 TE-MIDPT 10.30.0.2 00:58:06
20 LDP 10.0.0.5 00:58:03
23 LDP 10.0.0.1 00:58:03
24 LDP 10.32.0.0 00:58:03
27 BGP 100:1 10.34.0.0 00:57:48
31 BGP 100:1 10.0.0.9 00:58:21
32 BGP 100:1 10.3.3.0 00:58:21
Step 3 show ip flow export verbose | include PAL

Use this command to display the number of MPLS PAL records that were exported to the NetFlow
collector. For example:
Router# show ip flow verbose | include PAL
6 MPLS PAL records exported
When you specify the verbose keyword and MPLS PAL records have been exported using NetFlow
Version 9 data format, the command output contains an additional line that precedes the x records
exported in y UDP datagrams line.
Step 4 exit
Use this command to exit to user EXEC mode. For example:
Router# exit
Router>
Configuring the Export of MPLS VPN Version 4 Label Information from the MPLS
PAL Table to a NetFlow Collector
Perform the following task to configure the export of VPNv4 label information from the MPLS PAL
table to a NetFlow collector.
This allows you to track VPN prefix information for MPLS labels allocated by VPNs, BGP IPv4, and
BGP VPNv4. You can use the data analyzed by the collector to assist in network traffic planning and
billing.
Prerequisites
A VRF must be configured on the router.
SUMMARY STEPS
1. enable
3. mpls export interval interval
4. mpls export vpnv4 prefixes
10
5. end
7. exit
8. Reboot the router.
9. enable
10. show mpls flow mappings
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls export interval interval Configures the collection and export of MPLS PAL
information to a NetFlow collector.
Example: The interval argument specifies the time in minutes
Router(config)# mpls export interval 1440 between full PAL table exports. The range of valid time
intervals is 0 to 10,080 minutes.
We recommend that you select a time interval of
6 hours (360 minutes) to 24 hours (1440 minutes)
depending on the size of your network.
If you enter an interval of 0, full PAL table exports are
disabled. PAL information is exported only as labels
are allocated.
If you need to restart your NetFlow collector and want
to learn PAL information immediately, you can change
the interval argument. When you change the time
interval, the application exports the full PAL table.
Step 4 mpls export vpnv4 prefixes Configures the tracking and export of VPNv4 label
information from the MPLS PAL table to a NetFlow
collector.
Example:
Router(config)# mpls export vpnv4 prefixes
Example:
Router(config)# end
11
Configuration Examples for NetFlow MPLS Label Export

Step 6 copy running-config startup-config Copies the modified configuration into router NVRAM,
permanently saving the settings.
Example: The next time the router is rebooted the tracking and export
Router# copy running-config startup-config of VPNv4 label information from the MPLS PAL table to a
NetFlow collector is already part of the configuration.
Step 7 exit Exits to user EXEC mode.
Example:
Router# exit
Step 8 Reboot the router. (Optional) Saves the configuration and reboots the router to
ensure that the information collected by this feature is
complete.
Example:
Router> enable
Step 10 show mpls flow mappings Displays MPLS PAL table entries that include VPNv4
prefixes and VPN RDs.
Example:
Configuration Examples for NetFlow MPLS Label Export

This section contains the following configuration examples for the NetFlow MPLS Label Export feature:
Configuring NetFlow MPLS Prefix/Application/Label Table Export: Examples, page 12
Configuring the Export of MPLS VPNv4 Label Information from the MPLS PAL Table: Example,
page 13
Configuring NetFlow MPLS Prefix/Application/Label Table Export: Examples

The following examples show how to configure NetFlow MPLS PAL table export on a PE router.
This example shows how to configure the export of the full MPLS PAL table every 480 minutes
(8 hours):
configure terminal
!
mpls export interval 480
end
copy running-config startup-config
exit
This example shows how to configure MPLS PAL information export only as the labels are allocated:
configure terminal
!
end
12

exit
In this example, the full MPLS PAL table is not exported repeatedly.
Configuring the Export of MPLS VPNv4 Label Information from the MPLS PAL
Table: Example
The following example shows how to configure the export of MPSL VPNv4 label information from the
MPLS PAL table:
configure terminal
!
mpls export vpnv4 prefixes
end
exit
The full MPLS PAL table with MPLS VPNv4 label information is configured to export to the NetFlow
collector every 720 minutes (12 hours).
The following sections provide references related to the NetFlow MPLS Label Export feature.
Related Documents
Tasks for configuring MPLS-aware NetFlow Configuring MPLS-aware NetFlow
Overview of the NetFlow application and advanced Cisco IOS NetFlow Overview
NetFlow features and services
Tasks for configuring NetFlow to capture and export Configuring NetFlow and NetFlow Data Export
network traffic data
Tasks for configuring MPLS egress NetFlow Configuring MPLS Egress NetFlow Accounting
accounting
Detailed information about the fields available in Cisco IOS NetFlow Version 9 Flow-Record Format
Version 9 export format and about export format
architecture
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.
13
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
RFC 3954 Cisco Systems NetFlow Services Export Version 9
RFC 2547 BGP/MPLS VPNs
Description Link
14
Command Reference
Command Reference
mpls export interval
mpls export vpnv4 prefixes
show ip flow export
show mpls flow mappings
15
Feature Information for NetFlow MPLS Label Export
Feature Information for NetFlow MPLS Label Export

Table 1 lists the release history for this feature.
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 IOS software images are specific to a Cisco IOS software release, a feature set, and a platform.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image
support. 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 software release that introduced support for a given feature in a given
Cisco IOS software release. Unless noted otherwise, subsequent releases of that Cisco IOS software
release also support that feature.
Table 1 Feature Information for NetFlow MPLS Label Export
Feature Name Releases Feature Information

NetFlow MPLS Label Export 12.2(28)SB The NetFlow MPLS Label Export feature provides the
12.2(33)SRA label switch router (LSR) with the capability of collecting
and exporting the top label in the MPLS label stack along
with its prefix or Forwarding Equivalence Class (FEC) and
the application allocating the label to a NetFlow collector
for supported MPLS applications.
In 12.2(28)SB, this feature was introduced.
In 12.2(33)SRA, this feature was integrated into a 12.2SRA
release.
The following sections provide information about this
feature:
MPLS Label Information Gathering and Exporting,
page 3
Labels Allocated by VPNs, BGP IPv4, or BGP VPNv4
in the MPLS PAL Table, page 4
MPLS PAL Table Record Export, page 4
MPLS PAL and NetFlow Statistics Correlation on a
NetFlow Collector, page 6
MPLS Label Mapping on a Line Card, page 7
Configuring NetFlow MPLS Label Export and MPLS
PAL Table Export, page 7
Displaying Information About the MPLS PAL Table,
page 9
Configuring the Export of MPLS VPN Version 4 Label
Information from the MPLS PAL Table to a NetFlow
Collector, page 10
16
Glossary
Glossary
BGPBorder 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.
export packetA type of packet built by a device (for example, a router) with NetFlow services
enabled. The packet is addressed to another device (for example, the NetFlow Collection Engine). The
packet contains NetFlow statistics. The other device processes the packet (parses, aggregates, and stores
information on IP flows).
FECForward 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. A flow is another example
flowA unidirectional stream of packets between a given source and destinationeach of which is
defined by a network-layer IP address and transport-layer source and destination port numbers. A unique
flow is defined as the combination of the following key fields: source IP address, destination IP address,
source port number, destination port number, Layer 3 protocol type, type of service (ToS), and input
logical interface.
flowsetA collection of flow records that follow the packet header in an export packet. A flowset
contains information that must be parsed and interpreted by the NetFlow Collection Engine. There are
two different types of flowsets: template flowsets and data flowsets. An export packet contains one or
more flowsets, and both template and data flowsets can be mixed in the same export packet.
IPv6IP Version 6. Replacement for IP Version 4 (IPv4). IPv6 includes support for flow ID in the
packet header, which can be used to identify flows. Formerly called IPng (next generation).
labelA short, fixed-length identifier that tells switching nodes how the data (packets or cells) should
be forwarded.
LDPLabel Distribution Protocol. A standard protocol that operates between Multiprotocol Label
Switching (MPLS)-enabled routers to negotiate the labels (addresses) used to forward packets. The
Cisco proprietary version of this protocol is the Tag Distribution Protocol (TDP).
LFIBLabel Forwarding Information Base. A data structure and way of managing forwarding in which
destinations and incoming labels are associated with outgoing interfaces and labels.
LSRlabel switch router. A router that forwards packets in a Multiprotocol Label Switching (MPLS)
network by looking only at the fixed-length label.
MPLSMultiprotocol Label Switching. A switching method in which IP traffic is forwarded through
use of 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.
NetFlowA Cisco IOS application that provides statistics on packets flowing through the router. It is
emerging as a primary network accounting and security technology.
NetFlow Collection Engine (formerly NetFlow FlowCollector)A Cisco application that is used with
NetFlow on Cisco routers and Catalyst series switches. The NetFlow Collection Engine collects packets
from the router that is running NetFlow and decodes, aggregates, and stores them. You can generate
reports on various aggregations that can be set up on the NetFlow Collection Engine.
NetFlow v9NetFlow export format Version 9. A flexible and extensible means of carrying NetFlow
records from a network node to a collector. NetFlow Version 9 has definable record types and is
self-describing for easier NetFlow Collection Engine configuration.
network byte orderInternet-standard ordering of the bytes corresponding to numeric values.
17
Glossary
options data recordSpecial type of data record that is used in the NetFlow process. It is based on an
options template and has a reserved template ID that provides information about the NetFlow process
itself.
options templateA type of template record that the router uses to communicate the format of
NetFlow-related data to the NetFlow collector.
P routerprovider core or backbone router. A router that is part of a service providers core or
backbone network and is connected to the provider edge (PE) routers.
packet headerFirst part of an export packet. It provides basic information about the packet (such as
the NetFlow version, number of records contained in the packet, and sequence numbering) so that lost
packets can be detected.
PAL tablePrefix/Application/Label table. A data structure that collects and exports the prefix,
application, and time stamp for a specific label.
PE routerprovider edge router. A router that is part of a service providers network connected to a
customer edge (CE) router. All Virtual Private Network (VPN) processing occurs in the PE router.
RDroute distinguisher. An 8-byte value that is concatenated with an IPv4 prefix to create a unique
VPN IPv4 prefix.
There are two formats for configuring the route distinguisher argument. It can be configured in the
as-number:network number (ASN:nn) format or it can be configured in the IP address:network number
format (IP-address:nn).
RPRoute Processor. A processor module in the Cisco 7000 series routers that contains the CPU,
system software, and most of the memory components that are used in the router. Sometimes called a
Supervisory Processor.
TEtraffic engineering. Techniques and processes that cause routed traffic to travel through the
TE tunneltraffic 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.
template flowsetA collection of template records that are grouped in an export packet.
template IDA unique number that distinguishes a template record produced by an export device from
other template records produced by the same export device. A NetFlow Collection Engine application
can receive export packets from several devices. You should be aware that uniqueness is not guaranteed
across export devices. Thus, you should configure the NetFlow Collection Engine to cache the address
of the export device that produced the template ID in order to enforce uniqueness.
VPNVirtual 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.
VPNv4 prefixIPv4 prefix preceded by an 8-byte route distinguisher. The VPN addresses are made
unique by adding a route distinguisher to the front of the address.
18
Glossary
coincidental.
19
Glossary
20
ATM PVC Bundle EnhancementMPLS
EXP-Based PVC Selection
First Published: January 01, 2006

This feature allows you to configure multiple VCs that have different quality of service (QoS)
characteristics between any pair of ATM-connected routers that support this feature. VC bundle
management allows multiple VCs with various QoS settings to be directed to the same destination and
to map traffic to the VCs based on protocol criteria associated with the traffic. Three experimental (EXP)
bits in the Multiprotocol Label Switching (MPLS) packets determine which VC in the bundle to use to
forward the packets.
Finding Feature Information

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 ATM PVC Bundle EnhancementMPLS EXP-Based PVC
Selection section on page 27.
Contents
Prerequisites for ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection, page 2
Restrictions for ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection, page 2
Information About ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection, page 2
How to Configure ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection, page 6
ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection
Prerequisites for ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection
Configuration Examples for ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection,
page 22
Feature Information for ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection,
page 27
Prerequisites for ATM PVC Bundle EnhancementMPLS

This feature requires ATM VC management, Cisco Express Forwarding, and Forwarding Information
Base (FIB) and Label Forwarding Information Base (LFIB) switching functionality.
Restrictions for ATM PVC Bundle EnhancementMPLS

The router at the remote end must be running a version of Cisco IOS software that supports MPLS
and ATM VC management.
This feature is not supported on either the ATM interface processor (AIP) or the ATM Lite port
adapter (PA-A1).
Information About ATM PVC Bundle EnhancementMPLS

You need to understand the concepts in the following sections to configure the MPLS EXP Bits Based
ATM PVC Bundles VC Selection feature:
ATM VC Bundle Management, page 2
ATM VC Bundle Configuration, page 3
Benefits of ATM VC Bundle Management, page 4
VC Bundle Management Supported Features, page 5
ATM VC Bundle Management

The MPLS EXP Bits Based ATM PVC Bundles VC Selection feature is an extension to the IP to ATM
Class of Service feature suite. The IP to ATM Class of Service feature suite, using VC support and
bundle management, maps QoS characteristics between IP and ATM. It provides customers that have
multiple VCs (with varying qualities of service to the same destination) the ability to build a QoS
differentiated network.
The IP to ATM Class of Service feature suite allows customers to use IP precedence level as the selection
criterion for packet forwarding. This feature provides customers with the option of using the MPLS
experimental level as an additional selection criterion for packet forwarding.
2
Information About ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection
Note If a selection criterion for packet forwarding is not selected (that is, if the packet is unlabeled), this
feature uses the IP precedence level as the default selection criterion.
For more information about the IP to ATM Class of Service feature suite, see the Related Documents
section on page 25.
ATM VC Bundle Configuration

ATM VC bundle management allows you to configure multiple VCs that have different QoS
characteristics between any pair of ATM-connected routers. As shown in Figure 1, these VCs are
grouped in a bundle and are referred to as bundle members.
Figure 1 ATM VC Bundle
VC 1
VC 2
VC 3
62398
IP precedence or
MPLS EXP value
ATM VC bundle management allows you to define an ATM VC bundle and add VCs to it. Each VC of
a bundle has its own ATM traffic class and ATM traffic parameters. You can apply attributes and
characteristics to discrete VC bundle members, or you can apply them collectively at the bundle level.
Using VC bundles, you can create differentiated service by flexibly distributing MPLS EXP levels over
the different VC bundle members. You can map a single MPLS EXP level, or a range of these levels, to
each discrete VC in the bundle, thereby enabling individual VCs in the bundle to carry packets marked
with different MPLS EXP levels. You can use Weighted Random Early Detection (WRED) or distributed
WRED (dWRED) to further differentiate service across traffic that has different MPLS EXP levels.
To determine which VC in the bundle to use to forward a packet to its destination, the ATM VC bundle
management software matches MPLS EXP levels between packets and VCs (see Figure 2). IP traffic is
sent to the next hop address for the bundle because all VCs in a bundle share the same destination, but
the VC used to carry a packet depends on the value set for that packet in the MPLS EXP level of the type
of service (ToS) byte of its header. The ATM VC bundle management software matches the MPLS EXP
level of the packet to the MPLS EXP levels assigned to a VC, sending the packet out on the appropriate
VC.
3
Moreover, the ATM VC bundle management software allows you to configure how traffic will be
redirected when the VC to which the packet was initially directed goes down. Figure 2 illustrates how
the ATM VC bundle management software determines which permanent virtual circuit (PVC) bundle
member to use to carry a packet and how WRED (or dWRED) is used to differentiate traffic on the same
VC.
Figure 2 ATM VC Bundle PVC Selection for Packet Transfer
VC1
VC2
VC3
VC4
WRED in
62397
VC selection per-VC queue
based on precedence
or EXP value
The support of multiple parallel ATM VCs allows you to create stronger service differentiation at the IP
layer. For example, you might want to configure the network to provide IP traffic belonging to real-time
class of service (CoS) such as Voice over IP traffic on an ATM VC with strict constraints on constant bit
rate (CBR) or variable bit rate real-time (VBR-rt), while also allowing the network to transport
nonreal-time traffic over a more elastic ATM unspecified bit rate (UBR) PVC. UBR is effectively the
ATM version of best-effort service. Using a multiple parallel ATM VC configuration allows you to make
full use of your network capacity.
Benefits of ATM VC Bundle Management

ATM VC bundle management was designed to provide a true working solution to class-based services,
without the investment of new ATM network infrastructures. It allows networks to offer different service
classes (sometimes termed differential service classes) across the entire WAN, not just the routed
portion. Mission-critical applications can be given exceptional service during periods of high network
usage and congestion. In addition, noncritical traffic can be restricted in its network usage, ensuring
greater QoS for more important traffic and user types.
ATM VC bundle management gives customers the option of using the MPLS EXP level, in addition to
IP precedence, as a selection criterion for packet forwarding.
4
VC Bundle Management Supported Features

The following features are supported on an MPLS over VC bundle:
PVC support only (no switched virtual circuits or SVCs):
Support for multipoint and point-to-point subinterfaces.
Support for AAL5SNAP (RFC1483 bridging) and multiplex (MUX) type VCs encapsulation.
Use of static mapping and Inverse Address Resolution Protocol (Inverse ARP) for the next hop
protocol address (supported on multipoint subinterfaces only).
PVCs associated with VC bundles through explicit configuration.
Use of Interim Local Management Interface (ILMI) and Operation, Administration, and
Maintenance (OAM) functionality in the PVC management feature for PVC failure detection.
VC selection within the bundle:
Uses three EXP bits in the MPLS header to define the precedence levels, with level 7 being the
highest for MPLS traffic.
No automapping of VCs to precedence levels can be done. The user must use the mpls
experimental command under each member VC to explicitly specify the mapping.
Multiple precedence levels can be mapped to one VC.
Packets with the PAK_PRIORITY_CRUCIAL flag set go on a high precedence (level 6) VC.
These packets include IP routing packets such as Intermediate System-Intermediate System
(IS-IS) packets for integrated IP routing. Label Distribution Protocol (LDP) and Tag
Distribution Protocol (TDP) messages, and Inverse ARP packets also use a precedence level 6
VC. However, OAM cells still flow in the individual VC to detect PVC failures, although the
PAK_PRIORITY_CRUCIAL flag is set for them.
Regular ping commands use the lowest precedence (level 0) VC. If other protocols such as
Internetwork Packet Exchange (IPX) are configured in the bundle, they will also use the lowest
precedence level VC for their traffic.
ATM Inverse ARP:
Inverse ARP is viewed as a parameter at the bundle level and can be enabled or disabled only
for the bundle, not for individual VCs in the bundle.
The PAK_PRIORITY_CRUCIAL flag is set in each ATM Inverse ARP packet and the packets
use the precedence level 6 VC.
Inverse ARP for other protocols such as IPX is off by default unless it is configured in the
bundle.
Broadcast and multicast:
Broadcasting can be turned on or off at the bundle level, not at the individual VC level in the
bundle.
Pseudobroadcasting is used for forwarding the broadcast traffic.
VC selection for the broadcast traffic is based on the precedence levels of the broadcast packets.
Bundle management:
According to the protected group rule, when all members in the protected group fail, the bundle
is declared down.
According to the protected VC rule, when a protected VC goes down, the bundle goes down.
A VC can be a standalone VC or belong to only one bundle.
5
How to Configure ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection
When a bundle goes down, no traffic should be forwarded out the bundle, even if some of the
VCs in the bundle are still up.
In VC bumping, each bundle member can specify if bumping is allowed. If bumping is allowed,
the next lower precedence level VC is selected when a VC goes down. This is the implicit
bumping rule. Traffic is restored to the original VC when it comes back.
In explicit VC bumping, a VC can specify to which precedence level it wants to bump its traffic
when it goes down. Only one precedence level can be specified for bumping. If the VC that
carries the bumped traffic also fails, the traffic will follow the bumping rules specified for that
VC.
In reject bumping, a VC may also be configured not to accept the bumped traffic.
When no alternate VC can be found for some bumped traffic, the bundle has to be declared
down.
To avoid bringing down a bundle because of a failure of the lowest precedence VC, configure
explicit bumping on the lowest precedence VC.
Bundle status attributes and their current status for each VC in the bundle can be displayed in a
tabular form using EXEC commands.
Bundle statistics are the same statistics provided for VC that have been aggregated for a VC
bundle.
Bundle debugging commands, when enabled, print bundle events and bundle errors.
Packet forwarding:
There are four possible paths for MPLS packet forwarding over the VC bundle: IP to MPLS,
MPLS to MPLS, MPLS to IP, and locally generated packets.
Process switching is used for locally generated packets.
Cisco Express Forwarding FIB switching is used for the IP to MPLS path.
Cisco Express Forwarding LFIB switching is used for the MPLS to MPLS and MPLS to IP
paths.
No fast switching is supported for transit IP packets. The fast switching path does not classify
IP packets based on their precedence levels.
VC bundle configuration is already added to handle the IP VC bundle feature and may be used
without any modification.
How to Configure ATM PVC Bundle EnhancementMPLS

This section contains the following procedures:
Configuring MPLS and Creating a VC Bundle, page 7 (required)
Configuring the Bundle-Level Protocol, page 9 (required)
Configuring Parameters on a VC Bundle Member Directly, page 9 (optional)
Configuring a VC Class and Applying Parameters to a Bundle, page 11 (optional)
Attaching a Class to a Bundle, page 14 (optional)
Configuring a VC Bundle at the Subinterface Level, page 15 (optional)
6
Assigning VC and Bundle Attributes, page 18 (optional)

Verifying ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection Configuration,
page 21 (optional)
Configuring MPLS and Creating a VC Bundle

Perform this task to enable MPLS and create a VC bundle. When you create a VC bundle, you enter
bundle configuration mode, in which you can assign attributes and parameters to the bundle and to all of
its member VCs.
SUMMARY STEPS
1. enable
3. ip cef [distributed]
4. mpls ldp advertise-labels
5. interface atm interface-number[.subinterface-number {mpls | multipoint | point-to-point}]
6. ip address ip-address mask
7. mpls ip
8. bundle bundle-name
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef [distributed] Enables Cisco Express Forwarding, which is needed for
MPLS.
Example: Note This command without the optional keyword
Router(config)# ip cef enables Cisco Express Forwarding on the Route
Processor (RP) card. The optional distributed
keyword is used to enable distributed Cisco Express
Forwarding for the Versatile Interface Processor
(VIP)-based platforms.
Step 4 mpls ldp advertise-labels Controls the distribution of locally assigned, incoming
labels by means of the LDP, and allows TDP neighbors to
exchange messages between them.
Example:
Router(config)# mpls ldp advertise-labels
7

Step 5 interface atm Configures an ATM interface and enters interface
interface-number[.subinterface-number {mpls | configuration mode.
multipoint | point-to-point}]
Example:
Router(config)# interface atm 0/0/3
Step 6 ip address ip-address mask Sets the IP address for an interface.
Example:
Router(config-if)# ip address 10.13.11.3
255.255.0.0
Step 7 mpls ip Enables MPLS forwarding of IP packets along normally
routed paths for the platform.
Example:
Router(config-if)# mpls ip
Step 8 bundle bundle-name Creates or modifies a bundle and enters bundle
configuration mode. The prompt changes to the following:
Example: Router(config-if-atm-bundle)#
Router(config-if)# bundle new-york
What to Do Next
Decide whether you want to configure the VC bundle member directly or use a VC class attached to a
bundle.
You can apply parameters (or attributes) to bundles either by applying the parameters directly to the
bundle or by applying the parameters to a VC class assigned to the bundle.
Applying parameters by using VC classes assigned to the bundle allows you to apply multiple parameters
at once because you apply the VC class to the bundle and to all of its VC members. This method allows
you to apply a parameter across all VCs for the bundle, after which (for some parameters) you can later
modify that parameter for individual VCs. After configuring the parameters for the VC class, you need
to attach the VC class to the bundle.
To configure the VC bundle member directly, complete the procedure in the Configuring Parameters on
a VC Bundle Member Directly section on page 9. To use a VC class attached to a bundle, instead
complete the procedures in both the Configuring a VC Class and Applying Parameters to a Bundle
section and the Attaching a Class to a Bundle section on page 14.
Parameters applied directly to a bundle take priority over those applied to VC classes assigned to the
bundle, and the steps for this task are in the Configuring the Bundle-Level Protocol section on page 9.
Parameters applied to VC classes assigned to the bundle take priority over those applied to individual
VCs.
Note Some parameters applied through a VC class or directly to the bundle can be superseded by commands
that you apply directly to individual VCs in bundle-VC configuration mode.
8
Configuring the Bundle-Level Protocol

Perform this task to configure a protocol that applies to the bundle and to all of its members. The
commands in these steps are entered in bundle configuration mode.
SUMMARY STEPS
1. protocol protocol {protocol-address | inarp} [[no] broadcast]

2. encapsulation [aal5mux | aal5snap]
DETAILED STEPS

Step 1 protocol protocol {protocol-address | inarp} Configures a static map (the map statement for the bundle)
[[no] broadcast] for an ATM PVC, SVC, or VC class.
protocolNetworking protocol.
Example:
Router(config-if-atm-bundle)# protocol clns
protocol-addressDestination address that is being
10.0000.0000.0000.3333.00 broadcast mapped to a PVC.
inarp(Valid only for IP and IPX protocols on PVCs)
Enables Inverse ARP on an ATM PVC. If you specify a
protocol address instead of the inarp keyword, Inverse
ARP is automatically disabled for that protocol.
[no] broadcastIndicates that this map entry is used
when the corresponding protocol sends broadcast
packets to the interface.
Note Pseudobroadcasting is supported. The broadcast
keyword of the protocol command takes
precedence if you previously configured the
broadcast command on the ATM PVC or SVC.
Step 2 encapsulation [aal5mux | aal5snap] Configures the ATM adaptation layer (AAL) and
encapsulation type for every VC in the bundle.
Example: aal5muxAAL and encapsulation type for multiplex
Router(config-if-atm-bundle)# encapsulation (MUX) type VCs. A protocol must be specified when
aal5snap using this encapsulation type.
aal5snapAAL and encapsulation type that supports
Inverse ARP.
Configuring Parameters on a VC Bundle Member Directly

Perform this task to configure parameters on an individual VC bundle member directly. The commands
in these steps are entered in bundle-VC configuration mode.
SUMMARY STEPS
1. pvc-bundle pvc-name [vpi/][vci]

2. ubr pcr
9
3. vbr-nrt pcr scr [mbs]

4. mpls experimental [other | range]
5. bump {implicit | explicit precedence-level | traffic}
6. protect {group | vc}
7. exit
DETAILED STEPS

Step 1 pvc-bundle pvc-name [vpi/][vci] Adds a VC to a bundle as a member and enters bundle-VC
configuration mode to configure VC specific parameters.
Example: The VC is created upon exiting the mode.
Router(config-if-atm-bundle)# pvc-bundle
ny-control 207
vpiATM network virtual path identifier (VPI) for this
PVC. The absence of the slash mark (/) and a VPI value
defaults the value to 0. The vpi and vci keywords
cannot both be set to 0.
vciATM network virtual channel identifier (VCI) for
this PVC. The value range is from 0 to 1 less than the
maximum value set for this interface by the atm
vc-per-vp command.
Note The pvc-bundle command is used instead of the
pvc command to avoid the ambiguity between this
command and the interface pvc command.
Step 2 ubr pcr Configures UBR QoS and specifies the output peak cell rate
(PCR) for the VC bundle member.
Example:
Router(config-if-atm-member)# ubr 10000
Step 3 vbr-nrt pcr scr [mbs] Configures variable bit rate non-real-time (VBR-nrt) QoS
with a PCR, a sustaining cell rate (SCR), and maximum
burst size (MBS).
Example:
Router(config-if-atm-member)# vbr-nrt 20000
10000 32
Step 4 mpls experimental [other | range] Configures MPLS EXP levels for a VC class that can be
assigned to a VC bundle and thus applied to all VC
members of that bundle.
Example:
Router(config-if-atm-member)# mpls This command is ignored if the class that contains it is
experimental 7 not attached to a bundle member.
otherAny precedence level from 0 to 7 not explicitly
configured.
rangeAn MPLS EXP level specified as a number or
a range of numbers. Ranges can be expressed with a
hyphen (2-5, for example), and numbers and ranges can
be expressed in groups separated by commas; 1, 3, 5-7,
for example.
10

Step 5 bump {implicit | explicit precedence-level | Configures the bumping rules and applies only to bundle
traffic} members.
implicitApplies the implicit bumping rule, which is
Example: the default, to a single VC or PVC bundle member or to
Router(config-if-atm-member)# bump explicit 7 all VCs in the bundle (VC-class mode). The implicit
bumping rule stipulates that bumped traffic is to be
carried by a VC or PVC with a lower precedence level.
explicit precedence-levelSpecifies a precedence
level from 0 to 7 for the traffic to be bumped to.
trafficSpecifies that the VC or PVC accepts bumped
traffic (the default condition). The no form of this
command stipulates that the VC or PVC does not accept
any bumped traffic.
Step 6 protect {group | vc} Configures a VC class with protected group or protected VC
status for application to a VC bundle member.
Example: This command makes a bundle member part of the
Router(config-if-atm-member)# protect vc protected group of a bundle or a protected VC in a
bundle.
groupConfigures the VC or PVC bundle member as
part of the protected group of the bundle.
vcConfigures the VC or PVC member as individually
protected.
Step 7 exit Exits the current configuration mode.
Continue entering exit at the prompt to exit each
Example: configuration mode.
Router(config-if-atm-member)# exit
Configuring a VC Class and Applying Parameters to a Bundle

Perform this task to configure a VC class to contain commands that configure all VC members of a
bundle when the class is applied to that bundle. The parameters are applied in VC-class configuration
mode. Use the vc-class atm command in global configuration mode to enter the VC-class configuration
mode.
Commands Ignored in a VC Class Bundle

When a VC is part of a bundle, some of the VC configuration in the VC class will no longer be applicable
to the VC and will be ignored. The inheritance rule for VCs in VC bundles follows this order: VC
configuration, bundle configuration, subinterface configuration. In VC mode and bundle mode, the
configuration with the individual command takes precedence over the configuration with the class
command.
11
SUMMARY STEPS
1. enable
3. vc-class atm name
4. oam-bundle [manage] [frequency]
8. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 vc-class atm name Creates a VC class for an ATM interface and enters
VC-class configuration mode.
Example:
Router(config)# vc-class atm bundle-class
Step 4 oam-bundle [manage] [frequency] Enables end-to-end F5 OAM loopback cell generation and
determines whether the bundle is OAM managed, that is,
whether every VC in the bundle is OAM managed. There is
Example:
Router(config-vc-class)# oam-bundle manage 3
no effect if the VC class that contains this command is not
attached to a bundle.
manageEnables OAM management. If this keyword
is omitted, loopback cells are sent, but the bundle is not
managed.
frequencySeconds between transmitted OAM
loopback cells. Default is 10 seconds.
12

Step 5 mpls experimental [other | range] Configures MPLS EXP levels for a VC class that can be
assigned to a VC bundle and thus applied to all VC
members of that bundle.
Example:
Router(config-vc-class)# mpls experimental 7 This command is ignored if the class that contains it is
not attached to a bundle member.
otherAny precedence level from 0 to 7 not explicitly
configured.
for example.
Step 6 bump {implicit | explicit precedence-level | Configures the bumping rules and applies only to bundle
traffic} members.
Example: the default, to a single VC or PVC bundle member or to
Router(config-vc-class)# no bump traffic all VCs in the bundle (VC-class mode). The implicit
bumping rule stipulates that bumped traffic is to be
any bumped traffic.
Router(config-vc-class)# protect vc protected group of a bundle or a protected VC in a
bundle.
protected.
Router(config-vc-class)# exit
13
Attaching a Class to a Bundle

Perform this task to attach a VC class containing bundle-level configuration commands to a bundle.
Enter the bundle command in global configuration mode to enter bundle configuration mode.
SUMMARY STEPS
1. enable
5. class-bundle vc-class-name
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
configuration mode.
Example: bundle-nameSpecifies the name of the bundle to be
Router(config-if)# bundle new-york created. Name is limited is 16 characters.
Step 5 class-bundle vc-class-name Configures a bundle with the bundle-level commands
contained in the specified VC class.
Example:
Router(config-if-atm-bundle)# class-bundle
class1
Router(config-if-atm-bundle)# exit
14
Configuring a VC Bundle at the Subinterface Level

Perform this task to configure a bundle at the subinterface configuration level. The bundle submode is
activated by entering the bundle command. This mode is similar to the VC mode.
SUMMARY STEPS
1. enable
5. encapsulation [aal5mux | aal5snap]
6. protocol protocol {protocol-address | inarp} [[no] broadcast]
7. class class-name
9. ubr pcr
11. exit
12. oam-bundle [manage] [frequency]
13. oam retry [up-count] [down-count] [retry-frequency]
14. inarp [minutes]
15. broadcast
16. exit
DETAILED STEPS

Example:
Router> enable
Example:
Example:
15

configuration mode.
Example: bundle-nameSpecifies the name of the bundle to be
Router(config-if)# bundle new-york created. Name is limited is 16 characters.
Step 5 encapsulation [aal5mux | aal5snap] Configures the AAL and encapsulation type for every VC in
the bundle.
Example: aal5muxAAL and encapsulation type for multiplex
Router(config-atm-bundle)# encapsulation (MUX) type VCs. A protocol must be specified when
aal5snap using this encapsulation type.
aal5snapAAL and encapsulation type that supports
Inverse ARP.
Step 6 protocol protocol {protocol-address | inarp} Configures a static map (the map statement for the bundle)
[[no] broadcast] for an ATM PVC, SVC, or VC class.
protocolNetworking protocol.
Example:
Router(config-atm-bundle)# protocol clns
protocol-addressDestination address that is being
10.0000.0000.0000.3333.00 broadcast mapped to a PVC.
inarp(Valid only for IP and IPX protocols on PVCs)
Enables Inverse ARP on an ATM PVC. If you specify a
protocol address instead of the inarp keyword, Inverse
ARP is automatically disabled for that protocol.
[no] broadcastIndicates that this map entry is used
when the corresponding protocol sends broadcast
packets to the interface.
Note Pseudobroadcasting is supported. The broadcast
keyword of the protocol command takes
precedence if you previously configured the
broadcast command on the ATM PVC or SVC.
Step 7 class class-name Attaches a named VC class to this bundle.
Example:
Router(config-atm-bundle)# class control-class
16

ny-control 207
vc-per-vp command.
Step 9 ubr pcr Configures UBR QoS and specifies the output PCR for the
VC bundle member.
Example:
Step 10 vbr-nrt pcr scr [mbs] Configures VBR-nrt QoS with a PCR, an SCR, and MBS.
Example:
10000 32
Step 11 exit Exits bundle-VC configuration mode and returns to bundle
configuration mode.
Example:
Step 12 oam-bundle [manage] [frequency] Enables OAM for every VC in the bundle.
manageEnables OAM management. If this keyword
Example: is omitted, loopback cells are sent, but the bundle is not
Router(config-if-atm-member)# oam-bundle manage managed.
6
frequencySeconds between transmitted OAM
loopback cells. Default is 10 seconds.
Step 13 oam retry [up-count] [down-count] Configures OAM parameters for every VC in the bundle.
[retry-frequency]
up-countConsecutive end-to-end F5 OAM loopback
cell responses that must be received to change a
Example: connection state to up. Default is 3.
Router(config-if-atm-member)# oam retry 5 3 10
down-countConsecutive end-to-end F5 OAM
loopback cell responses that are not received to change
a PVC state to down. Default is 5.
retry-frequencyFrequency (in seconds) that
end-to-end F5 OAM loopback cells are transmitted
when a change in the up/down state is being verified.
Default is 1 second.
17

Step 14 inarp [minutes] Configures the Inverse ARP time period.
Default is 15 minutes.
Example:
Router(config-if-atm-member)# inarp 1
Step 15 broadcast Enables broadcast forwarding on this bundle.
Example:
Router(config-if-atm-member)# broadcast
Assigning VC and Bundle Attributes

The pvc-bundle command activates the bundle-VC configuration mode, in which specific VC and
bundle member attributes can be assigned.
SUMMARY STEPS
1. enable
6. class class-name
7. ubr pcr
12. exit
18
DETAILED STEPS

Example:
Router> enable
Example:
Example:
configuration mode.
Example:
Router(config-if)# bundle new-york
ny-control 207
vc-per-vp command.
Step 6 class class-name Attaches a VC class to this VC.
Example:
Router(config-if-atm-member)# class
control-class
Step 7 ubr pcr Configures UBR QoS and specifies the output PCR for the
VC bundle member.
Example:
19

Step 8 vbr-nrt pcr scr [mbs] Configures VBR-nrt QoS with a PCR, an SCR, and MBS.
Example:
10000 32
Step 9 mpls experimental [other | range] Defines the experimental levels for packets to be forwarded
on this PVC.
Example: otherAny precedence level from 0 to 7 not explicitly
Router(config-if-atm-member)# mpls configured.
experimental 7
for example.
Step 10 bump {implicit | explicit precedence-level | Specifies the bumping rule for the VC.
traffic}
the default, to a single VC or PVC bundle member or to
Example: all VCs in the bundle (VC class mode). The implicit
Router(config-if-atm-member)# bump explicit 7 bumping rule stipulates that bumped traffic is to be
any bumped traffic.
Router(config-if-atm-member)# protect vc protected group of a bundle or a protected VC in a
bundle.
protected.
20
Verifying ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection

Configuration
Use the commands in the following steps as needed, to verify configurations for the ATM PVC Bundle
EnhancementMPLS EXP-Based PVC Selection feature.
SUMMARY STEPS
1. enable
2. debug atm bundle adjacency events
3. debug atm bundle error
4. debug atm bundle events
5. debug atm bundle inarp
6. show atm bundle [bundle-name]
7. show mpls forwarding-table [{network {mask | length} | labels label [- label] | interface interface
| next-hop address | lsp-tunnel [tunnel-id]}] [detail]
DETAILED STEPS

Example:
Router> enable
Step 2 debug atm bundle adjacency events Displays information about adjacency events such as
addition, removal, and update of adjacencies for the bundle.
Example:
Router# debug atm bundle adjacency
Step 3 debug atm bundle error Displays debug messages for PVC bundle errors.
Example:
Router# debug atm bundle error
Step 4 debug atm bundle events Displays bundle events such as when VC bumping occurs,
when the bundle goes up or down, and so on.
Example:
Router# debug atm bundle event
Step 5 debug atm bundle inarp Displays information about Inverse ARP events and errors
on the bundle.
Example:
Router# debug atm bundle inarp
21
Configuration Examples for ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection

Step 6 show atm bundle [bundle-name] Displays the bundle attributes assigned to each VC member
and the current working status of the VC members.
Example:
Router# show atm bundle new-york
Step 7 show mpls forwarding-table [{network {mask | Displays the contents of the MPLS FIB.
length} | labels label [- label] | interface
interface | next-hop address | lsp-tunnel
[tunnel-id]}] [detail]
Example:
Router# show mpls forwarding-table detail
Configuration Examples for ATM PVC Bundle

EnhancementMPLS EXP-Based PVC Selection
This section provides the following configuration examples:
Configuring MPLS: Example, page 22
Defining ATM VC Classes and Parameters: Example, page 22
Associating an ATM VC Bundle with the Interface: Example, page 23
Creating a VC Class: Example, page 24
Configuring MPLS: Example

The following example shows how to configure MPLS:
ip cef
mpls ldp advertise-labels
!
interface atm 0/0/3
ip address 10.13.11.3 255.255.0.0
mpls ip
bundle bundle1
Defining ATM VC Classes and Parameters: Example

In the following example, VC classes are defined with parameters applicable to individual VCs in the
bundle. Each VC class is preceded by a description of how it will be used.
! The following commands define the bundle class. Any bundle that uses this class will
! have AAL5snap encapsulation, broadcast on, use of Inverse ARP to resolve IP addresses,
! and OAM enabled at the bundle class level in the inheritance chain.
! This router uses IS-IS as an IP routing protocol.
!
router isis
net 10.0000.0000.0000.1111.00
!
vc-class atm bundle-class
encapsulation aal5snap
22
broadcast
protocol ip inarp
oam-bundle manage 3
oam 4 3 10
!
! The following VC class defines the parameters applicable to an individual VC
! in a bundle. The control-class carries precedence 7 traffic and it takes the
! bundle down when it is down. It uses the implicit bumping rule.
! The QoS is set to VBR-nrt.
!
vc-class atm control-class
mpls experimental 7
protect vc
vbr-nrt 10000 5000 32
!
! The following VC class defines a premium class that carries precedence level 6 and 5
! traffic. It does not allow other traffic to be bumped onto it. The VC will choose
! precedence 7 VC as the alternate VC for its traffic when it goes down, and it belongs
! to the protected group of the bundle. The QoS type is VBR-nrt.
!
vc-class atm premium-class
mpls experimental 6-5
no bump traffic
protect group
bump explicit 7
vbr-nrt 20000 10000 32
!
! The following VC class defines a priority class that carries precedence levels
! 4 through 2 traffic, uses the implicit bumping rule, allows bumped traffic,
! and belongs to the protected group of the bundle. The QoS type is UBR+.
!
vc-class atm priority-class
mpls experimental 4-2
protect group
ubr+ 10000 3000
! The following VC class defines a basic-class that carries the traffic of the precedence
! levels not specified in the profile; it is part of a protected group.
! The QoS type is UBR.
!
vc-class atm basic-class
mpls experimental other
protect group
ubr 10000
Associating an ATM VC Bundle with the Interface: Example

The following interface has one bundle, new-york, for connecting to three neighbors: new-york,
san-francisco, and los-angeles. The new-york and san-francisco bundles have four members and
los-angeles has three members.
interface atm 1/0.1 multipoint
ip address 10.0.0.1 255.255.255.0
ip router isis
bundle new-york
!
! The following commands enable IP and OSI traffic flows in the bundle. The protocol ip
! command takes precedence over the protocol ip inarp command in the bundle class,
! according to the inheritance rule. The protocol clns command is configured so IP routing
! can be integrated. The OSI routing packets will go on the highest precedence VC in the
! bundle, while the OSI data packets, if any, will use the lowest precedence VC in the
23
! bundle. Other protocols such as IPX or AppleTalk, if configured, would always use the
! lowest precedence VC in the bundle.
protocol ip 10.10.1.2 broadcast
protocol clns 49.0000.0000.0000.2222.00 broadcast
class bundle-class
!
! The following commands show how to configure the PVC bundles, including adding a VC
! to a bundle as a member.
pvc-bundle ny-control 207
class control-class
pvc-bundle ny-premium 206
class premium-class
pvc-bundle ny-priority 204
class priority-class
pvc-bundle ny-basic 201
class basic-class
bundle san-francisco
inarp 1
class bundle-class
pvc-bundle sf-control 307
class control-class
pvc-bundle sf-premium 306
class premium-class
pvc-bundle sf-priority 304
pvc-bundle sf-basic 301
class basic-class
bundle los-angeles
protocol ip 1.1.1.4 broadcast
inarp 1
class bundle-class
pvc-bundle la-high 407
precedence 7-5
protect vc
class premium-class
pvc-bundle la-mid 404
precedence 4-2
protect group
pvc-bundle la-low 401
precedence other
protect group
class basic-class
!
The following commands configure PVC la-other as a standalone VC that does not belong to
any of the bundles.
!
pvc la-other 400
no protocol ip inarp
broadcast
Creating a VC Class: Example

In the following example, a class called class1 is created and then applied to the bundle called bundle1:
! The following commands create the class class1:
vc-class atm class1
encapsulation aal5snap
broadcast
protocol ip inarp
24
oam-bundle manage 3
oam 4 3 10
!
! The following commands apply class1 to the bundle called bundle1:
bundle bundle1
class-bundle class1
With hierarchy precedence rules taken into account, VCs belonging to the bundle named bundle1 will
be characterized by these parameters: AAL5SNAP (RFC1483 bridging) encapsulation, broadcast on, use
of Inverse ARP to resolve IP addresses, and OAM enabled.
The following sections provide references related to the ATM PVC Bundle EnhancementMPLS
EXP-Based PVC Selection feature.
Related Documents
QoS Overview Cisco IOS Quality of Service Overview
QoS Commands Cisco IOS Quality of Service Solutions Command Reference
Configuring ATM Configuring ATM
SVC bundles IP to ATM SVC Bundles for Class of Service (CoS) Mapping
ATM VC bundle management on Cisco 12000 ATM VC Bundle Management on Cisco 12000 Series 8-Port OC-3 STM-1
Series Internet Routers ATM Line Cards
Standards
Standards Title
None
MIBs
MIBs MIBs Link
None To locate and download MIBs for selected platforms, Cisco IOS releases, and
feature sets, use Cisco MIB Locator found at the following URL:
RFCs
RFCs Title
None
25
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.
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.
26
Feature Information for ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection
Feature Information for ATM PVC Bundle EnhancementMPLS

Cisco IOS software release train. Unless noted otherwise, subsequent releases of that Cisco IOS
software release train also support that feature.
Table 1 Feature Information for ATM PVC Bundle Enhancement MPLS EXP-Based PVC Selection

ATM PVC Bundle Enhancement MPLS 12.2(8)T In Cisco IOS Release 12.2(8)T, this feature was introduced.
EXP-Based PVC Selection 12.0(23)S
In Cisco IOS Release 12.0(23)S, this feature was made
12.0(29)S
available on the 8-port OC-3 STM-1 ATM line card for
12.2(33)SRC
Cisco 12000 series Internet routers.
This feature was integrated into Cisco IOS Release
12.0(29)S.
In Cisco IOS Release 12.2(33)SRC, support was added for
the Cisco 7200 series router.
feature:
Information About ATM PVC Bundle
EnhancementMPLS EXP-Based PVC Selection,
page 2
How to Configure ATM PVC Bundle
EnhancementMPLS EXP-Based PVC Selection,
page 6
The following commands were introduced or modified:
mpls experimental, show mpls forwarding-table.
27
Feature Information for ATM PVC Bundle EnhancementMPLS EXP-Based PVC Selection
CCDE, CCENT, CCSI, Cisco Eos, Cisco HealthPresence, Cisco IronPort, the Cisco logo, Cisco Lumin, Cisco Nexus, Cisco Nurse Connect,
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,
coincidental.
2006-2009 Cisco Systems, Inc. All rights reserved.
28
MPLS Label Distribution Protocol
MPLS Label Distribution Protocol (LDP)

Last Updated: May 1, 2008
Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) enables peer label switch
routers (LSRs) in an 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.

Your Cisco IOS software release may not support all of the features documented in this module. For the
latest feature information and caveats, see the release notes for your platform and software release. To
reach links to specific feature documentation in this module and to see a list of the releases in which each
feature is supported, use the Feature Information for MPLS Label Distribution Protocol section on page 27.
Contents
Prerequisites for MPLS LDP, page 2
Information About MPLS LDP, page 2
Information About MPLS LDP, page 2
How to Configure MPLS LDP, page 5
MPLS LDP Configuration Examples, page 20

Prerequisites for MPLS LDP
Prerequisites for MPLS LDP

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

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

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 LDP 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.
LDP and TDP Support

LDP supercedes Tag Distribution Protocol (TDP). See Table 1 for information about LDP and TDP
support in Cisco IOS releases.
Book Title
2
Use caution when upgrading the image on a router that uses TDP. Ensure that the TDP sessions are
established when the new image is loaded. You can accomplish this by issuing the global configuration
command mpls label protocol tdp. Issue this command and save it to the startup configuration before
loading the new image. Alternatively, you can enter the command and save the running configuration
immediately after loading the new image.
Table 1 LDP and TDP Support
Train and Release LDP/TDP Support

12.0S Train TDP is enabled by default.
Cisco IOS Release 12.0(29)S and earlier releases: TDP is supported for LDP features.
Cisco IOS Release 12.0(30)S and later releases: TDP is not support for LDP features.
12.2S, SB, and SR Trains LDP is enabled by default.
Cisco IOS Release 12.2(25)S and earlier releases: TDP is supported for LDP features.
Cisco IOS Releases 12.2(27)SBA, 12.2(27)SRA, 12.2(27)SRB and later releases: TDP is
not supported for LDP features.
12.T/Mainline Trains Cisco IOS Release 12.3(14)T and earlier releases: TDP is enabled by default.
Cisco IOS Releases 12.4 and 12.4T and later releases: LDP is enabled by default.
Cisco IOS Release 12.3(11)T and earlier releases: TDP is supported for LDP features.
Cisco IOS Release 12.3(14)T and later releases: TDP is not support ed for LDP features.
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.
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 6.
Book Title
3
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 link(s) 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, the targeted Hellos 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.
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-specificAn 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.
Book Title
4
How to Configure MPLS LDP
Platform-wideAn 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.
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 interface 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.

Enabling Directly Connected LDP Sessions, page 6 (required)
Book Title
5
Establishing Nondirectly Connected MPLS LDP Sessions, page 8 (optional)

Saving Configurations: MPLS/Tag Switching Commands, page 11 (optional)
Specifying the LDP Router ID, page 11 (optional)
Preserving QoS Settings with MPLS LDP Explicit Null, page 13 (optional)
Protecting Data Between LDP Peers with MD5 Authentication, page 17 (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 | tdp | both}
5. interface type number
6. mpls ip
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.
Book Title
6

Step 4 mpls label protocol {ldp | tdp | both} Configures the use of LDP on all interfaces. LDP is the
default.
Example: If you set all interfaces globally to LDP, you can
Router(config)# mpls label protocol ldp override specific interfaces with either the tdp or both
keyword by specifying the command in interface
configuration mode.
Step 5 Router(config)# interface type number Specifies the interface to be configured and enters interface
configuration mode.
Example:
Router(config)# interface ethernet3/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.
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:
Router(config)# exit
Step 9 show mpls interfaces [interface] [detail] Verifies that the interfaces have been configured to use LDP,
TDP, or both.
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
Book Title
7
Examples
The following show mpls interfaces command verifies that interfaces Ethernet 1/0 and 1/1 have been
configured to use LDP:
Interface IP Tunnel BGP Static Operational

Ethernet3/0 Yes (ldp) No No No Yes
Ethernet3/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:
Ethernet3/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:
FastEthernet1/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 20.
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 CEF.
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
Book Title
8
5. interface tunnelnumber
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:
default.
configuration mode.
Step 5 interface tunnelnumber 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
Book Title
9

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:
Example
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:
POS2/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 (tdp): passive, xmit/recv
TDP Id: 192.168.0.0:0
This command output indicates that:

The local LSR (172.16.0.0) sent LDP link Hello messages on interface POS2/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.
Book Title
10
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 22.
Saving Configurations: MPLS/Tag Switching Commands

In releases of Cisco IOS software prior to 12.4(2)T, some MPLS commands had both a tag-switching
version and an MPLS version. For example, the two commands tag-switching ip and mpls ip were the
same. To support backward compatibility, the tag-switching form of the command was written to the
saved configuration.
Starting in Cisco IOS Release 12.4(2)T, the MPLS form of the command is written to the saved
configuration.
For example, if an ATM interface is configured using the following commands, which have both a
tag-switching form and an MPLS form:
Router(config)# interface ATM3/0
Router(config-if)# ip unnumbered Loopback0
router(config-if)# tag-switching ip
Router(config-if)# mpls label protocol ldp
After you enter these commands and save this configuration or display the running configuration with
the show running command, the commands saved or displayed appear as follows:
interface ATM3/0
ip unnumbered Loopback0
mpls ip
mpls label protocol ldp
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.
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.
Book Title
11
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
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:
Book Title
12

default.
configuration mode.
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 label protocol ldp
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:
Ethernet4 (ldp): xmit/recv
LDP Id: 10.14.14.14:0
Preserving QoS Settings with MPLS LDP Explicit Null
Book Title
13
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
(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:
Book Title
14

default.
configuration mode.
Step 5 interface type number Specifies the interface to be configured and enters interface
configuration mode.
Example:
Router(config)# interface atm2/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).
[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.
Book Title
15
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
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:
Ethernet4 (ldp): xmit/recv
TDP Id: 10.14.14.14:0
Book Title
16

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.

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 on the router called 47K-60-4, the output shows
that it receives explicit null labels for 10.24.24.24/32.

17 0 <--- 10.24.24.24/32 0 Et4 172.16.0.1
20 Pop tag 172.16.0.0/8 0 Et4 172.16.0.1
21 20 10.12.12.12/32 0 Et4 172.16.0.1
22 16 10.0.0.0/8 0 Et4 172.16.0.1
23 21 10.13.13.13/32 0 Et4 172.16.0.1
25 Pop tag 10.14.14.14/32 0 Et4 172.16.0.1
27 Pop tag 192.168.0.0/8 0 Et4 172.16.0.1
28 25 10.16.16.16/32 0 Et4 172.16.0.1
29 Pop tag 192.168.34.34/32 0 Et4 172.16.0.1
Protecting Data Between LDP Peers with MD5 Authentication
Book Title
17
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.
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:
Book Title
18

default.
configuration mode.
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, Src IP addr: 10.20.10.2
10.1.1.2 10.20.20.1 10.20.10.2
Book Title
19
MPLS LDP Configuration Examples
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; 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

This section includes the following configuration examples:
Configuring Directly Connected MPLS LDP Sessions: Example, page 20
Establishing Nondirectly Connected MPLS LDP Sessions: Example, page 22
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.
Book Title
20
Figure 1 Configuration of MPLS LDP
Router 2
POS2/0/0
10.0.0.33
POS3/0/0
10.0.0.44
Router 1
POS3/0/1
192.168.0.44
Router 3
39405
POS1/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 POS3/0/0
ip address 10.0.0.44 255.0.0.0
mpls ip !Enable hop-by-hop MPLS forwarding
mpls label protocol ldp !Use LDP for this interface
!
interface POS3/0/1
ip address 192.168.0.44 255.0.0.0
mpls label protocol tdp !Use TDP for this interface
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
mpls label protocol ldp !Use LDP for this interface
ip cef !Assumes R3 does not support dCEF
!
ip address 172.16.0.33 255.255.255.255
!
Book Title
21
interface POS1/0
ip address 192.168.0.55 255.0.0.0
mpls label protocol tdp !Use tDP for this interface
The LDP configuration for Router 1 uses the mpls label protocol ldp command in interface
configuration mode, because some of its interfaces use LDP and some use TDP. Another way to
configure Router 1 is to use the mpls label protocol ldp command in global configuration mode to
configure LDP as the default protocol for interfaces and use the mpls label protocol tdp command in
interface configuration mode to configure TDP for the POS3/0/1 link to Router 3. This alternative way
to configure Router 1 is shown below:
ip cef distributed !Assumes R1 supports dCEF
mpls label protocol ldp !Use LDP for the default protocol
!
ip address 172.16.0.11 255.255.255.255
interface POS3/0/0
ip address 10.0.0.44 255.0.0.0
!Use LDP (configured i/f default)
interface POS3/0/1
ip address 192.168.0.44 255.0.0.0
mpls label protocol tdp !Use TDP for this interface
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.
Book Title
22
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 TDP. 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 as default 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 tdp !Use TDP for session with Router 5

Book Title
23
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
mpls label protocol ldp !Use LDP as default for all interfaces

ip address 10.25.0.44 255.255.255.255

Router 5 must use TDP for all targeted sessions. Therefore, its configuration includes the mpls label
protocol tdp command.
ip cef !Router 5 supports CEF
mpls label protocol tdp !Use TDP as default for all interfaces

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.
The following sections provide references related to MPLS LDP.
Book Title
24
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.
Standards
Standard Title
None
MIBs
MIB MIBs Link
MPLS Label Distribution Protocol MIB To locate and download MIBs for selected platforms, Cisco IOS
(draft-ietf-mpls-ldp-mib-08.txt) releases, and feature sets, use Cisco MIB Locator found at the
SNMP-VACM-MIB following URL:
The View-based Access Control Model (ACM) http://www.cisco.com/go/mibs
MIB for SNMP
RFCs
RFC Title
RFC 3036 LDP Specification
Description Link
The Cisco Technical Support website contains http://www.cisco.com/techsupport
thousands of pages of searchable technical content,
including links to products, technologies, solutions,
technical tips, and tools. Registered Cisco.com users
can log in from this page to access even more content.
Book Title
25
Command Reference
Command Reference
Command Reference at http://www.cisco.com/en/US/docs/ios/mo/command/reference/mp_book.html.
For information about all Cisco IOS commands, use the Command Lookup Tool at
http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.:
mpls label protocol (global configuration)
mpls ldp router-id
Book Title
26
Feature Information for MPLS Label Distribution Protocol

Table 2 Feature Information for MPLS Label Distribution Protocol Overview

MPLS Label Distribution 12.0(10)ST This feature was introduced in Cisco IOS Release 12.0(10)ST, incorporating a
Protocol 12.0(14)ST new set of Multiprotocol Label Switching (MPLS) CLI commands implemented
12.1(2)T for use with Cisco routers and switches. The CLI commands in this release
12.1(8a)E reflected MPLS command syntax and terminology, thus facilitating the orderly
12.2(2)T transition from a network using the Tag Distribution Protocol (TDP) to one using
12.2(4)T the Label Distribution Protocol (LDP).
12.2(8)T
In Cisco IOS Release 12.0(14)ST, several new MPLS CLI commands were
12.0(21)ST
introduced, support for MPLS VPNs was added by means of a new vrf vpn-name
12.0(22)S
parameter in certain existing commands, and other commands were modified to
12.0(23)S
ensure consistent interpretation of associated prefix-access-list arguments by
12.2(13)T
Cisco IOS software.
12.4(3)
12.4(5) In Cisco IOS 12.1(2)T, this feature was integrated into this release. Also, the
debug mpls atm-ldp api, debug mpls atm-ldp routes, and debug mpls atm-ldp
states commands were modified.
This feature was integrated into Cisco IOS Release 12.1(8a)E.
This feature was integrated into Cisco IOS Release 12.2(2)T.
Book Title
27
Table 2 Feature Information for MPLS Label Distribution Protocol Overview (continued)

In Cisco IOS Release 12.2(4)T, support was added for Cisco MGX 8850 and
MGX 8950 switches equipped with a Cisco MGX RPM-PR card, and the VPI
range in the show mpls atm-ldp bindings and show mpls ip binding commands
was changed to 4095.
In Cisco IOS Release 12.2(8)T, the debug mpls atm-ldp failure command was
introduced.
In Cisco IOS Release 12.0(21)ST, the mpls ldp neighbor implicit-withdraw
command was introduced.
This feature was integrated into Cisco IOS Release 12.0(22)S. The mpls ldp
neighbor targeted-session command and the interface keyword for the mpls ldp
advertise-labels command were added.
This feature was integrated into Cisco IOS Release 12.0(23)S. Default values for
the mpls ldp discovery command holdtime and interval keywords were
changed.
In Cisco IOS Release 12.4(3), the default MPLS label distribution protocol
changed from TDP to LDP. See LDP and TDP Support section on page 2 for
more information. If no protocol is explicitly configured by the mpls label
protocol command, LDP is the default label distribution protocol. See the mpls
label protocol (global configuration) command for more information.
Also in Cisco IOS Release 12.4(3), LDP configuration commands are saved by
using the MPLS form of the command rather than the tag-switching form.
Previously, commands were saved by using the tag-switching form of the
command, for backward compatibility. See the Saving Configurations:
MPLS/Tag Switching Commands section on page 11 for more information.
In Cisco IOS Release 12.4(5), the vrf vrf-name keyword/argument pair was added
for the mpls ldp router-id command to allow you to associate the LDP router ID
with a nondefault VRF.
CCDE, CCVP, Cisco Eos, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We
Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE,
CCIP, CCNA, CCNP, CCSP, 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, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Event Center, Fast
Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness
Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, 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.
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
coincidental.
Book Title
28
MPLS LDP Session Protection
First Published: November 8, 2004

The MPLS LDP Session Protection feature provides faster 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.

supported, use the Feature Information for MPLS LDP Session Protection section on page 23.
Contents
Information About MPLS LDP Session Protection, page 2
How to Configure MPLS LDP Session Protection, page 2
Configuration Examples for MPLS LDP Session Protection, page 7
Feature Information for MPLS LDP Session Protection, page 23

Information About MPLS LDP Session Protection
Information About MPLS LDP Session Protection

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 label switched
routers (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 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. Take, for example,
two directly connected routers that 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.
How to Configure MPLS LDP Session Protection

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

You use the mpls ldp session protection command to enable MPLS LDP Session Protection. This
command enables LDP sessions to be protected during a link failure. By default, the command protects
all LDP sessions. The command has several options that enable you to specify which LDP sessions to
protect. The vrf keyword lets you protect LDP sessions for a specified VRF. The for keyword lets you
specify a standard IP access control list (ACL) of prefixes that should be protected. The duration
keyword enables you to specify how long the router should retain the LDP Targeted Hello Adjacency
following the loss of the LDP Link Hello Adjacency.
2
Prerequisites
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
This feature is not supported under the following circumstances:
With TDP sessions
With extended access lists
With LC-ATM routers
SUMMARY STEPS
1. enable
4. interface loopbacknumber
5. ip address {prefix mask}
6. interface interface
7. mpls ip
9. exit
10. mpls ldp session protection [vrf vpn-name] [for acl] [duration seconds]
3
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef [distributed] Configures Cisco Express Forwarding.
Example:
Router(config)# ip cef
Step 4 interface loopbacknumber 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:
255.255.255.255
Step 6 interface interface Specifies the interface to configure.
Example:
Router(config-if)# interface POS3/0
Step 7 mpls ip Configures MPLS hop-by-hop forwarding for a specified
interface.
Example:
Step 8 mpls label protocol {ldp | tdp | both} 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 default label distribution protocol for the interface to be
LDP, overriding any default set by the global mpls label
protocol command.
In global configuration mode, the command sets all the
interfaces to LDP.
4

Step 9 exit Exits from interface configuration mode.
Example:
Step 10 mpls ldp session protection [vrf vpn-name] [for Enables MPLS LDP Session Protection.
acl] [duration seconds]
Example:
Router(config)# mpls ldp session protection
Customizing MPLS LDP Session Protection

You can modify MPLS LDP Session Protection by using the keywords in the mpls ldp session
protection command. The following sections explain how to customize the feature.
Specifying 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.
Specifying 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.
Enabling MPLS LDP Session Protection on Specified VPN Routing and Forwarding Instances
If the router is configured with at least one VPN routing and forwarding (VRF) instance, you can use the
vrf keyword to select which VRF is to be protected. You cannot specify more than one VRF with the
mpls ldp session protection command. To specify multiple VRFs, issue the command multiple times.
Enabling MPLS LDP Session Protection on Specified Peer Routers
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.
5
Verifying MPLS LDP Session Protection

To verify that LDP Session Protection has been correctly configured, perform the following steps.
SUMMARY STEPS
1. show mpls ldp discovery

2. show mpls ldp neighbor
3. show mpls ldp neighbor detail
DETAILED STEPS
Step 1 show mpls ldp discovery

Issue this command and check that the output contains xmit/recv to the peer router.

10.0.0.5:0
Discovery Sources:
Interfaces:
ATM5/1/0.5 (ldp): xmit/recv
LDP Id: 10.0.0.1:0
Targeted Hellos:
10.0.0.5 -> 10.0.0.3 (ldp): active, xmit/recv
LDP Id: 10.0.0.3:0
Step 2 show mpls ldp neighbor

Issue this command to check that the targeted hellos are active.

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 3 show mpls ldp neighbor detail

Issue this command to check 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.

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
6
Configuration Examples for MPLS LDP Session Protection
LDP Session Protection enabled, state: Protecting

duration: infinite
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.

Figure 1 shows a sample configuration for MPLS LDP Session Protection.
Figure 1 MPLS LDP Session Protection Example
R1 R2 R3
e4/0/6 e5/0/6 e5/0/2 e1/2
e4/0/4 e1/4
117994
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
tag-switching tdp router-id Loopback0 force
!
interface Loopback0
ip address 10.0.0.1 255.255.255.255
no ip directed-broadcast
no ip mroute-cache
!
interface Multilink4
no ip address
no ip mroute-cache
load-interval 30
ppp multilink
multilink-group 4
!
interface Ethernet1/0/0
ip address 10.3.123.1 255.255.0.0
7
!
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
tag-switching ip
!
ip address 10.0.0.1 255.0.0.0
tag-switching ip
!
ip address 10.0.0.1 255.0.0.0
tag-switching ip
!
router ospf 100
log-adjacency-changes
redistribute connected
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
ip cef distributed
!
interface Loopback0
ip address 10.0.0.3 255.255.255.255
!
no ip address
shutdown
full-duplex
8
!
ip address 10.0.0.1 255.0.0.0
full-duplex
tag-switching ip
!
ip address 10.0.0.2 255.0.0.0
ip load-sharing per-packet
full-duplex
tag-switching ip
!
interface FastEthernet5/1/0
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
no ip domain-lookup
mpls label range 200 100000 static 16 199
!
interface Loopback0
ip address 10.0.0.5 255.255.255.255
!
interface Ethernet1/0
no ip address
shutdown
half-duplex
!
ip address 10.0.0.2 255.0.0.0
full-duplex
tag-switching ip
!
ip address 10.0.0.2 255.0.0.0
full-duplex
tag-switching ip
!
router ospf 100
9
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.
10
Command Reference
Related Documents
MPLS LDP MPLS Label Distribution Protocol
MPLS LDP-IGP synchronization MPLS LDP-IGP Synchronization
LDP autoconfiguration LDP Autoconfiguration
Standards
Standards Title
None
MIBs
MIBs MIBs Link
MPLS LDP MIB To locate and download MIBs for selected platforms, Cisco IOS
following URL:
RFCs
RFCs Title
RFC 3037 LDP Applicability
Description Link
Cisco products and technologies. Access to most tools
on the Cisco Support website requires a Cisco.com user
ID and password. If you have a valid service contract
but do not have a user ID or password, you can register
on Cisco.com.
Command Reference
11
Command Reference
debug mpls ldp session protection
show mpls ldp neighbor
Feature Information for MPLS LDP Session Protection
coincidental.
12
MPLS LDP-IGP Synchronization

Last Updated: September 2, 2009
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.

supported, see the Feature History for MPLS LDP-IGP Synchronization section on page 17.
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 14
Feature History for MPLS LDP-IGP Synchronization, page 17
Prerequisites for MPLS LDP-IGP Synchronization
Prerequisites for MPLS LDP-IGP Synchronization

This feature is supported only on interfaces that are 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 command or the mpls
ldp autoconfig command.
Restrictions for MPLS LDP-IGP Synchronization

In Cisco IOS Release 12.2(33)SB, and Cisco IOS Release 12.2(33)SRB, the MPLS LDP-IGP
Synchronization feature is not supported with IS-IS. Only OSPF is supported.
The Tag Distribution Protocol (TDP) is not supported. You must specify that the default label
distribution protocol is LDP for a router or for an interface.
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 MPLS 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 that is 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 that is associated with
an IGP OSPF or IS-IS process.
2
Information About MPLS LDP-IGP Synchronization
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.
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 peers transport address.
When the routing table has an inaccurate route for the peers 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

Cisco IOS Release 12.0(32)SY and later releases of 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. Normally, when LDP-IGP synchronization is configured, LDP notifies IGP
as soon as LDP is converged. When the delay timer is configured, this notification is delayed. 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.
3
How to Configure MPLS LDP-IGP Synchronization
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.
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 on 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 8 (required)
Disabling MPLS LDP-IGP Synchronization on Some IS-IS Interfaces, page 12 (optional)
Verifying MPLS LDP-IGP Synchronization with IS-IS, page 12 (optional)
Configuring MPLS LDP-IGP Synchronization with OSPF Interfaces

To configure MPLS LDP-IGP synchronization with OSPF interfaces, perform the following steps.
SUMMARY STEPS
1. enable
3. mpls ip
4. mpls label protocol ldp
6. ip address prefix mask
4
7. mpls ip
8. exit
9. router ospf process-id
10. network ip-address wildcard-mask area area-id
11. mpls ldp sync
12. end
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:
Step 5 interface type number Specifies the interface to configure and enters interface
configuration mode.
Example:
Router(config)# interface POS3/0
Step 6 ip address prefix mask Assigns an IP address to the interface.
Example:
255.255.255.255
Step 7 mpls ip Enables hop-by-hop forwarding on the interface.
Example:
Step 8 exit Exits interface configuration mode.
Example:
5

Step 9 router ospf process-id Enables OSPF routing and enters router configuration
mode.
Example:
Router(config)# router ospf 1
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:
Router(config-router)# network 10.0.0.0
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
Step 12 end Exits router configuration mode and returns to privileged
EXEC mode.
Example:
Router(config-router)# end
Disabling MPLS LDP-IGP Synchronization on 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. The following configuration steps
show how to disable LDP-IGP synchronization from some OSPF interfaces after they have been
configured with LDP-IGP synchronization through the mpls ldp sync command.
SUMMARY STEPS
1. enable
4. no mpls ldp igp sync
5. end
6
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
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
Step 5 end Exits interface configuration mode and returns to privileged
EXEC mode.
Example:
Router(config-if)# end
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
DETAILED STEPS
Step 1 enable
Enables privileged EXEC mode. Enter your password if prompted.
Step 2 show mpls ldp igp sync
The output of this command (as shown in the following example) shows 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
7
Ethernet0/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:
Ethernet5/1:
LDP configured; LDP-IGP Synchronization not enabled.
Step 3 show ip ospf mpls ldp interface

The output of the show ip ospf mpls ldp interface command in the following example shows that the
interfaces are properly configured:
Router# show ip ospf mpls ldp interface
Ethernet3/0/0
Process ID 1, Area 0
LDP is configured through LDP autoconfig
LDP-IGP Synchronization: Yes
Holddown timer is not configured
Timer is not running
Ethernet3/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
Configuring MPLS LDP-IGP Synchronization with IS-IS Interfaces
Note In Cisco IOS Releases 12.2(33)SRB and 12.2(33)SB, the MPLS LDP-IGP Synchronization feature is not
supported with IS-IS. Only OSPF is supported.
The following sections contain the steps and examples for configuring MPLS LDP-IGP synchronization
for interfaces that are running IS-IS processes:
Configuring MPLS LDP-IGP Synchronization on All IS-IS Interfaces, page 8
Configuring MPLS LDP-IGP Synchronization on an IS-IS Interface, page 10
Configuring MPLS LDP-IGP Synchronization on All IS-IS Interfaces

This section contains the steps for configuring the MPLS LDP-IGP Synchronization feature on all
interfaces that are running IS-IS processes.
SUMMARY STEPS
1. enable
3. mpls ip
8

5. router isis process-name
6. mpls ldp sync
7. mpls ldp autoconfig
8. exit
11. ip router isis process-name
12. mpls ip
13. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
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:
Step 7 mpls ldp autoconfig Configures auto-configuration to quickly configure the auto
synchronization. When auto-configure is configured,
auto-sync configuration is not required on any interfaces
Example:
Router(config-router)# mpls ldp autoconfig
with MPLS enabled.
9

Step 8 exit Exits router configuration mode and returns to global
configuration mode.
Example:
Router(config-router)# exit
configuration mode.
Example:
Example:
255.255.255.0
Step 11 ip router isis process-name Enables IS-IS.
Example:
Router(config-if)# ip router isis ISIS
Step 12 mpls ip Enables MPLS IP.
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
5. mpls ldp igp sync
6. ip router isis
7. exit
8. router isis
9. mpls ldp sync
10. end
10
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Example:
255.0.0.0
Step 5 mpls ldp igp sync Enables MPLS LDP-IGP synchronization.
Example:
Router(config-if)# mpls ldp igp sync
Step 6 ip router isis Enables the IS-IS protocol for IP on the interface.
Example:
Router(config-if)# ip router isis
Step 7 exit Exits interface configuration mode and returns to global
configuration mode.
Example:
Step 8 router isis Enables IS-IS process on the router.
Example:
Router(config)# router isis
Step 9 mpls ldp sync Enables LDP-IGP synchronization for interfaces that
belongs to an IS-IS process.
Example:
EXEC mode.
Example:
11
Disabling MPLS LDP-IGP Synchronization on 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. The following configuration steps
show how to disable LDP-IGP synchronization from some IS-IS interfaces after they have been
configured with LDP-IGP synchronization through the mpls ldp sync command.
SUMMARY STEPS
1. enable
4. no mpls ldp igp sync
5. end
DETAILED STEPS

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

After you configure the interfaces for LDP-IGP synchronization with IS-IS, you can verify that the
configuration is working correctly with the show isis mpls ldp command.
12
SUMMARY STEPS
1. enable
2. show isis mpls ldp
DETAILED STEPS
Step 1 enable
Step 2 show isis mpls ldp
The output of the following command shows that IS-IS is configured on the interface (ISIS is UP) and
that MPLS LDP-IGP synchronization with IS-IS is configured properly (SYNC achieved).
Router# show isis mpls ldp
Interface: POS0/2; ISIS tag null enabled

ISIS is UP on interface
AUTOCONFIG Information :
LDP enabled: NO
SYNC Information :
Required: YES
Achieved: YES
IGP Delay: NO
Holddown time: Infinite
State: SYNC achieved
If MPLS LDP-IGP synchronization with IS-IS is not enabled on an interface, the output looks like the
following:
Interface: Ethernet0; ISIS tag null enabled
LDP enabled: NO
SYNC Information :
Required: NO
If MPLS LDP-IGP synchronization with IS-IS is configured but is not enabled, the output looks like the
following:
Interface: Ethernet0/0; ISIS tag ISIS-1 enabled
LDP enabled: YES
SYNC Information :
Required: YES
Achieved: NO
IGP Delay: YES
Holddown time: Infinite
State: Holding down until SYNC
The IS-IS process holds down the adjacency of the interface until synchronization is enabled.
13
Configuration Examples for MPLS LDP-IGP Synchronization
Use the debug mpls ldp igp sync command to display events related to MPLS LDP-IGP
synchronization.
Configuration Examples for 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: Example, page 14
MPLS LDP-IGP Synchronization with IS-IS: Example, page 14
MPLS LDP-IGP Synchronization with OSPF: Example

The following configuration commands enable LDP for OSPF process 1. The mpls ldp sync command
and the OSPF network commands enable LDP on interfaces POS0/0, POS0/1, and POS1/1, respectively.
The no mpls ldp igp sync command on interface POS1/0 prevents LDP from being enabled on interface
POS1/0, even though OSPF is enabled for that interface.
!
!
!
!
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: Example
Note In Cisco IOS Release 12.2(33)SRB and 12.2(33)SB, the MPLS LDP-IGP Synchronization feature is not
supported with IS-IS. Only OSPF is supported.
The following commands configure MPLS LDP-IGP synchronization on interfaces POS0/2 and POS0/3,
which are running IS-IS processes:
14

!
!
The following sections provide references related to the MPLS LDP-IGP Synchronization feature.
Related Documents
MPLS LDP Autoconfiguration MPLS LDP Autoconfiguration
MPLS LDP Session Protection MPLS LDP Session Protection
Standards
Standards Title
MIBs
MIBs MIBs Link
following URL:
15
RFCs
RFCs Title
Description Link
16
Feature History for MPLS LDP-IGP Synchronization

Table 1 Feature Information for MPLS LDP-IGP Synchronization

MPLS LDP-IGP Synchronization 12.0(30)S The MPLS LDP-IGP Synchronization feature
12.0(32)SY ensures that LDP is fully established before the IGP
12.2(33)SB path is used for switching.
12.2(33)SRB
In 12.0(30)S, this feature was introduced.
15.0(1)M
12.3(14)T In 12.0(32)SY, support for enabling
Cisco IOS XE synchronization on interfaces running Intermediate
Release 2.1 System-to-System (IS-IS) processes was added.
In 12.2(33)SB, the feature was integrated. MPLS
LDP-IGP synchronization for IS-IS is not
supported in this release.
In 12.2(33)SRB, the feature was integrated. MPLS
In 12.3(14)T, this feature was integrated. MPLS
In 15.0(1)M, support for enabling synchronization
on interfaces running IS-IS processes was added.
In XE 2.1, this feature was implemented on
Cisco ASR 1000 Series Routers.
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
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.
18
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.

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

The MPLS LDP Autoconfiguration feature has the following restrictions:
In Cisco IOS Release 12.0(32)SY, the mpls ldp autoconfig command is supported only with the
IS-IS interface. Other IGPs are not supported.
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

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 following section provides information about
autoconfiguration feature on OSPF and IS-IS interfaces:
MPLS LDP Autoconfiguration on OSPF and IS-IS Interfaces
MPLS LDP Autoconfiguration on OSPF and IS-IS Interfaces

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. 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 5 (optional)
Configuring MPLS LDP Autoconfiguration with IS-IS Interfaces, page 6 (required)
Disabling MPLS LDP Autoconfiguration from Selected IS-IS Interfaces, page 8 (optional)
2
Verifying MPLS LDP Autoconfiguration with IS-IS, page 9 (optional)
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
10. mpls ldp autoconfig [area area-id]
11. end
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Example:
configuration mode.
Example:
Router(config)# interface POS 3/0
3

Example:
255.255.255.255
Example:
Step 8 router ospf process-id Enables OSPF routing and enters router configuration
mode.
Example:
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:
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.
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 the MPLS LDP Autoconfiguration feature with the mpls ldp
autoconfig command.
SUMMARY STEPS
1. enable
4. no mpls ldp igp autoconfig
5. end
4
DETAILED STEPS

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

The following steps explain how to verify the MPLS LDP Autoconfiguration feature.
SUMMARY STEPS
1. enable
2. show mpls interfaces [type number | vrf vpn-name] [all] [detail] [internal]
3. show mpls ldp discovery [vrf vpn-name | all] [detail]
DETAILED STEPS
Step 1 enable
Step 2 show mpls interfaces [type number | vrf vpn-name] [all] [detail] [internal]
The show mpls interfaces command displays the method 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
5
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 Serial 2/0 detail
Interface Serial2/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 [vrf vpn-name | all] [detail]

The show mpls ldp discovery detail command also shows 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 (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
Configuring MPLS LDP Autoconfiguration with IS-IS Interfaces

The following steps explain how to configure the MPLS LDP Autoconfiguration feature for interfaces
that are running IS-IS processes.
SUMMARY STEPS
1. enable
6
5. ip router isis
6. exit
7. mpls ip
9. router isis
10. mpls ldp autoconfig [level-1 | level-2]
11. end
DETAILED STEPS
Example:
Router> enable
Example:
configuration mode.
Example:
Example:
255.0.0.0
Step 5 ip router isis Enables IS-IS for IP on the interface.
Example:
Example:
Example:
Example:
7

Step 9 router isis Enables an IS-IS process on the router and enters router
configuration mode.
Example:
Step 10 mpls ldp autoconfig [level-1 | level-2] Enables the LDP for interfaces that belong to an IS-IS
process.
Example:
Router(config-router)# mpls ldp autoconfig
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, 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 the MPLS LDP Autoconfiguration feature with the mpls ldp
autoconfig command.
SUMMARY STEPS
1. enable
4. no mpls ldp igp autoconfig
5. end
DETAILED STEPS

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

Step 4 no mpls ldp igp autoconfig Disables LDP for that interface.
Example:
Router(config-if)# no mpls ldp igp autoconfig
EXEC mode.
Example:
Verifying MPLS LDP Autoconfiguration with IS-IS

You can verify that the MPLS LDP Autoconfiguration feature is working correctly with the show isis
mpls ldp command.
SUMMARY STEPS
1. enable
2. show isis mpls ldp
DETAILED STEPS
Step 1 enable
Enables privileged EXEC mode.
Step 2 show isis mpls ldp
The output of the following show isis mpls ldp command shows that IS-IS is configured on the interface
and that LDP is enabled:
Router# show isis mpls ldp
Interface: POS0/2; ISIS tag null enabled

LDP enabled: YES
SYNC Information :
Required: NO
The output shows :

IS-IS is up.
LDP is enabled.
If the MPLS LDP Autoconfiguration feature is not enabled on an interface, the output looks like the
following:
Interface: Ethernet0; ISIS tag null enabled
LDP enabled: NO
SYNC Information :
Required: NO
9
Configuration Examples for MPLS LDP Autoconfiguration
You can use the debug mpls ldp autoconfig command to display events that are related to the MPLS
LDP Autoconfiguration feature.
Configuration Examples for MPLS LDP Autoconfiguration

The following sections show examples for the MPLS LDP Autoconfiguration feature with OSPF and
IS-IS processes.
MPLS LDP Autoconfiguration with OSPF: Example, page 10
MPLS LDP Autoconfiguration with IS-IS: Examples, page 10
MPLS LDP Autoconfiguration with OSPF: Example

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 POS interfaces 0/0, 0/1,
and 1/1. The no mpls ldp igp autoconfig command on POS interface 1/0 prevents LDP from being
enabled on POS interface 1/0, even though OSPF is enabled for that interface.
configure terminal
interface POS 0/0
ip address 10.0.0.1 255.0.0.0
!
interface POS 0/1
ip address 10.0.1.1 255.0.0.1
!
interface POS 1/1
ip address 10.1.1.1 255.255.0.0
!
interface POS 1/0
ip address 10.1.0.1 0.1.0.255
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
end
interface POS 1/0
no mpls ldp igp autoconfig
MPLS LDP Autoconfiguration with IS-IS: Examples

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

http://tools.cisco.com/ITDIT/CFN/jsp/index.jsp. An account on Cisco.com is not required.
Table 1 Feature Information for MPLS LDP Autoconfiguration

MPLS LDP Autoconfiguration 12.0(30)S This feature enables you to globally configure LDP on every
12.0(32)SY interface associated with a specified Interior Gateway
12.2(28)SB Protocol (IGP) instance.
12.2(33)SRB
12.3(14)T
feature:
15.0(1)M
12.2(33)XNE Information About MPLS LDP Autoconfiguration,
page 2
How to Configure MPLS LDP Autoconfiguration,
page 2
In Cisco IOS Release 12.0(30)S, this feature was introduced
with support for OSPF.
In Cisco IOS Release 12.0(32)SY, support for IS-IS was
added.
This feature was integrated into Cisco IOS
Release 12.2(28)SB with support for OSPF.
Release 12.2(33)SRB.
Release 12.3(14)T with support for OSPF.
In Release 15.0(1)M, support for IS-IS was added.
12.2(33)XNE with support for IS-IS on the Cisco 10000
series router.
The following commands were modified: mpls ldp
autoconfig, mpls ldp igp autoconfig, show isis mpls ldp,
and show mpls ldp discovery.
13
coincidental.
14
MPLSLDP MD5 Global Configuration

The MPLSLDP MD5 Global Configuration feature provides enhancements to the Label Distribution
Protocol (LDP) implementation of the Message Digest 5 (MD5) password. This feature allows you to
enable LDP MD5 globally instead of on a per-peer basis. Using this feature you can set up password
requirements for a set of LDP neighbors to help prevent unauthorized peers from establishing LDP
sessions and to block spoofed TCP messages.
This document provides information about and configuration information for the global configuration of
LDP MD5 protection.

feature is supported, use the Feature Information for MPLSLDP MD5 Global Configuration section on
page 20.
Contents
Prerequisites for MPLSLDP MD5 Global Configuration, page 2
Restrictions for MPLSLDP MD5 Global Configuration, page 2
Information About MPLSLDP MD5 Global Configuration, page 2
How to Configure the MPLSLDP MD5 Global Configuration Feature, page 5
Configuration Examples for Configuring the MPLSLDP MD5 Global Configuration Feature,
page 16

Prerequisites for MPLSLDP MD5 Global Configuration

Glossary, page 22
Feature Information for MPLSLDP MD5 Global Configuration, page 20
Prerequisites for MPLSLDP MD5 Global Configuration

Cisco Express Forwarding or distributed Cisco Express Forwarding must be enabled on the label
switch router (LSR).
Routing (static or dynamic) must be configured for the LSR.
Multiprotocol Label Switching (MPLS) LDP must be configured on the LSR. However, you can
configure LDP MD5 protection before you configure MPLS LDP. You can then use LDP MD5
protection after you configure MPLS LDP.
A Virtual Private Network (VPN) routing and forwarding instance (VRF) must be configured if you
want to configure MPLS LDP MD5 global configuration for a VRF. If you delete a VRF, the LDP
MD5 global configuration for that VRF is automatically removed.
Restrictions for MPLSLDP MD5 Global Configuration

MD5 protection described in this document applies only to the LDP sessions. All enhancements
described in this document do not affect Tag Distribution Protocol (TDP) sessions.
Information About MPLSLDP MD5 Global Configuration

Before you configure the MPLSLDP MD5 Global Configuration feature, you must understand the
following:
Enhancements to LDP MD5 Protection for LDP Messages Between Peers, page 2
LDP MD5 Password Configuration Information, page 3
LDP MD5 Password Configuration for Routing Tables, page 4
Enhancements to LDP MD5 Protection for LDP Messages Between Peers

The MPLSLDP MD5 Global Configuration feature provides the following enhancements to the LDP
support of MD5 passwords:
You can specify peers for which MD5 protection is required. This can prevent the establishment of
LDP sessions with unexpected peers.
You can configure passwords for groups of peers. This increases the scalability of LDP password
configuration management.
The established LDP session with a peer is not automatically torn down when the password for that
peer is changed. The new password is used the next time an LDP session is established with the peer.
2
You can control when the new password is used. You can configure the new password on the peer
before forcing the use of the new password.
If the neighboring nodes support graceful restart, then LDP sessions are gracefully restarted. The
LDP MD5 password configuration is checkpointed to the standby Route Processors (RPs). The LDP
MD5 password is used by the router when the new active RP attempts to establish LDP sessions with
neighbors after the switchover.
LDP session, advertisement, and notification messages are exchanged between two LDP peers over a
TCP connection. You can configure the TCP MD5 option to protect LDP messages that are exchanged
over a TCP connection. You can configure this protection for each potential LDP peer. As a result, an
LDP ignores any LDP hello messages sent from an LSR for which you have not configured a password.
(LDP tries to establish an LDP session with each neighbor from which a hello message is received.)
Before the introduction of the MPLSLDP MD5 Global Configuration feature, you needed to configure
a separate password for each LDP peer for which you wanted MD5 protection. This was the case even
when the same password was used for multiple LDP peers. Before this feature, LDP would tear down
LDP sessions with a peer immediately if a password for that peer had changed.
LDP MD5 Password Configuration Information

Before the introduction of the MPLSLDP MD5 Global Configuration feature, the command used for
configuring a password for an LDP neighbor was mpls ldp neighbor [vrf vrf-name] ip-address
password [0 | 7] password. This command configures a password for one neighbor whose router ID is
the IP address in the specified VRF. An LSR can have zero or one such configuration for each LDP
neighbor.
You can use the commands provided by the MPLSLDP MD5 Global Configuration feature to
configure passwords for LDP neighbors.
You must understand how LDP determines the password for an LDP session between peers before you
configure MD5 password protection for your network. LDP determines the passwords for its sessions
based on the commands that you enter.
You can enter an mpls ldp password vrf vrf-name required [for acl] command, either with an optional
acl argument that permits the LDP router ID of the neighbor or without an acl argument. Make sure that
you enter a command that configures a password. Otherwise, LDP might not establish a session with the
neighbor in question.
For the commands in the following password-determining process, A.B.C.D:N represents the
LDP neighbor in VRF vpn1 and the neighbor LDP ID:
A.B.C.D is the neighbor router ID.
N is the neighbor label space ID.
To determine the password for an LDP session for the neighbor label space A.B.C.D:N, LDP looks at the
password commands in the order indicated by the following statements:
If you configured this command:
mpls ldp neighbor vrf vpn1 A.B.C.D password pwd-nbr
The LDP session password is pwd-nbr. LDP looks no further and uses the password you specify.
Otherwise, LDP looks to see if you configured one or more mpls ldp vrf vpn1 password option
commands. LDP considers the commands in order of the ascending number arguments (number-1st
to number-n). For example:
mpls ldp vrf vpn1 password option number-1st for acl-1st pwd-1st
3
LDP compares the peer router ID of the neighbor (A.B.C.D) with this command. If A.B.C.D is
permitted by the command access list acl-1st, the session password is the command password, that
is, pwd-1st.
If A.B.C.D is not permitted by acl-1st, LDP looks at the command with the next ascending number
argument (number-2nd):
mpls ldp vrf vpn1 password option number-2nd for acl-2nd pwd-2nd
If A.B.C.D is permitted by the command access list acl-2nd, the session password is pwd-2nd.
If A.B.C.D is not permitted by the access list acl-2nd, LDP continues checking A.B.C.D against
access lists until LDP:
Finds A.B.C.D permitted by an access list. Then the command password is the session password.
Has processed the number-nth argument of this command (n being the highest number argument
you configured for this command).
If the mpls ldp vrf vpn1 password option number-nth for acl-nth pwd-nth command produces no
match and, therefore no password, LDP looks to see if you configured the following command:
mpls ldp password vrf vpn1 fallback pwd-fback
If you configured this command, the session password is pwd-fback.
Otherwise, if LDP has not found a password, you did not configure a password for the session. LDP
does not use MD5 protection for the session TCP connection.
LDP MD5 Password Configuration for Routing Tables

The MPLSLDP MD5 Global Configuration feature introduces commands that can establish password
protection for LDP sessions between LDP neighbors or peers. These commands can apply to routes in
the global routing table or in a VRF.
By default, if the vrf keyword is not specified in the command, the command applies to the global
routing table. The following sample commands would apply to routes in the global routing table:
Router# mpls ldp password required
Router# mpls ldp password option 15 for 99 pwd-acl
Router# mpls ldp password fallback pwd-fbck
You can configure LDP MD5 password protection for routes in a VRF only when the VRF is configured
on the LSR. If you specify a VRF name and a VRF with that name is not configured on the LSR, LDP
prints out a warning and discards the command. If you remove a VRF, LDP deletes the password
configuration for that VRF. The following sample commands would apply to routes in a VRF, for
example, VRF vpn1:
Router# mpls ldp vrf vpn1 password required
Router# mpls ldp vrf vpn1 password option 15 for 99 pwd-acl
Router# mpls ldp vrf vpn1 password fallback pwd-flbk
4
How to Configure the MPLSLDP MD5 Global Configuration Feature
How to Configure the MPLSLDP MD5 Global Configuration

Feature
Perform the following tasks to configure the MPLSLDP MD5 Global Configuration feature:
Identifying LDP Neighbors for LDP MD5 Password Protection, page 5 (required)
Configuring an LDP MD5 Password for LDP Sessions, page 7 (required)
Verifying the LDP MD5 Configuration, page 14 (optional)
Password Requirements for LDP Sessions

You might require password protection for a certain set of neighbors for security reasons (for example,
to prevent LDP sessions being established with unauthorized peers, or to block spoofed TCP messages).
To enforce this security, you can configure a password requirement for LDP sessions with those
neighbors that must have MD5 protection (TCP session uses a password).
If you configure a password requirement for a neighbor and you did not configure a password for the
neighbor, LDP tears down the LDP sessions with the neighbor. LDP also tears down the LDP sessions
with the neighbor if you configured a password requirement and a password and the password is not used
in the LDP sessions.
If a password is required for a neighbor and the LDP sessions with the neighbor are established to use a
password, any configuration that removes the password for the neighbor causes the LDP sessions to be
torn down.
To avoid unnecessary LDP session flapping, you should perform the task as described in this section and
use caution when you change LDP passwords.
Identifying LDP Neighbors for LDP MD5 Password Protection

Perform the following task to identify LDP neighbors for LDP MD5 password protection.
Prerequisites
Before you start to configure passwords for LDP sessions, you must identify neighbors or groups of
peers for which you want to provide MD5 protection. For example:
You might have several customers that all use the same core routers. To ensure security you might
want to provide each customer with a different password.
You could have defined several departmental VRFs in your network. You could provide password
protection for each VRF.
Certain groups of peers might require password protection for security reasons. Password protection
prevents unwanted LDP sessions.
Before you start to configure passwords for LDP sessions, you must identify neighbors or groups of
peers for which you want to provide LDP MD5 password protection. This task uses the network in
Figure 1 to show how you might identify LDP neighbors for LDP MD5 protection.
After you identify LDP neighbors or a group of peers for LDP MD5 protection, you must decide if
password protection is mandatory and what password commands to use for each peer.
5
SUMMARY STEPS
1. Identify LDP neighbors or groups of peers for LDP MD5 password protection.
2. Decide what LDP MD5 protection is required for each neighbor or group of peers.
DETAILED STEPS
Step 1 Identify LDP neighbors or groups of peers for LDP MD5 password protection.
This task uses the network in Figure 1 to show how you might identify LDP neighbors for LDP MD5
protection.
Figure 1 shows a sample network that has the following topology:
Carrier Supporting Carrier (CSC) is configured between provider edge (PE) router PE1 and
customer edge (CE) router CE1 and between PE1 and CE2.
Internal Border Gateway Protocol (IBGP) Virtual Private Network (VPN) IPv4 (VPNv4) to support
Layer 3 VPNs is configured between PE1 and PE2.
CE1 and CE3 are in VRF VPN1. CE2 and CE4 are in a different VRF, VPN2.
Figure 1 Sample Network: Identifying LDP Neighbors for LDP MD5 Protection
VPN1 VPN1
CE1 CE3
IBGP VPNv4
PE1 PE2
PE1 P1 P2 PE2
135061
CE2 CE4
VPN2 VPN2
For the sample network in Figure 1, you could configure separate passwords on PE1 for the following:
VRF VPN1
VRF VPN2
You could also configure a password requirement on PE1 for P1, P2, CE1 and CE2.
Step 2 Decide what LDP MD5 protection is required for each neighbor or group of peers.
If you need to set up a password for an LDP session with one peer or neighbor, for example, from
PE1 to CE1, you could use the mpls ldp neighbor [vrf vrf-name] ip-address password [0 | 7]
password-string command, where ip-address is the router ID of the neighbor. See the Configuring
an LDP MD5 Password for LDP Sessions section on page 7 for instructions.
If you need to set up an LDP session password for a set of peers, for example for P1 and P2, you
could set up an access list that permits access to these routers and denies access to all others. See
the Configuring an LDP MD5 Password for LDP Sessions with a Selected Group of Peers section
on page 12 for instructions.
6
If you want to require a password for communication among VRF vpn1 members, you can configure
a password requirement and password for VRF vpn1. If your network contains several VRFs, you
can configure a password for each VRF. See the Configuring an LDP MD5 Password for LDP
Sessions with Peers from a Specified VRF section on page 10 for instructions.
Configuring an LDP MD5 Password for LDP Sessions

This section contains information about and instructions for configuring an LDP MD5 password for LDP
sessions. You configure an LDP MD5 password to protect your routers from unwanted LDP sessions and
provide LDP session security. You can provide LDP session security for a specific neighbor, or for LDP
peers from a specific VRF or from the global routing table, or for a specific set of LDP neighbors.
After you have identified the LDP neighbor, LDP neighbors, or LDP peers in your network for which
you want LDP MD5 password protection, perform the following procedures, as you require, to configure
an LDP MD5 password for LDP sessions:
Configuring an LDP MD5 Password for a Specified Neighbor, page 7
Configuring an LDP MD5 Password for LDP Sessions with Peers from a Specified VRF, page 10
Configuring an LDP MD5 Password for LDP Sessions with a Selected Group of Peers, page 12
Configuring an LDP MD5 Password for a Specified Neighbor

Perform the following task to configure an LDP MD5 password for a specified neighbor.
LDP looks first for a password between the router and neighbor that is configured with the mpls ldp
neighbor [vrf vrf-name] ip-address password pwd-string command. If a password is configured with
this command, LDP uses that password before checking passwords configured by other commands.
You must add a configuration command for each neighbor or peer for which you want password
protection.
Prerequisites
Identify the LDP neighbor or peer for which you want MD5 password protection.
SUMMARY STEPS
1. enable
3. mpls ldp neighbor [vrf vrf-name] ip-address password [0 | 7] password-string
4. end
5. show mpls ldp neighbor [vrf vrf-name | all] [ip-address | interface] [detail] [graceful-restart]
6. show mpls ldp neighbor [vrf vrf-name] [ip-address | interface] password [pending | current]
7. show mpls ldp discovery [vrf vrf-name | all] [detail]
7
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls ldp neighbor [vrf vrf-name] ip-address Configures a password key for computing MD5 checksums
password [0 | 7] password-string for the session TCP connection with the specified neighbor.
The vrf vrf-name keyword-argument pair specifies the
Example: VPN routing and forwarding instance for the specified
Router(config)# mpls ldp neighbor vrf vpn1 neighbor.
10.1.1.1 password nbrce1pwd
The ip-address argument specifies the router ID (IP
address) that identifies a neighbor.
The [0 | 7] keywords specify whether the password that
follows is encrypted:
0 specifies a clear-text (nonencrypted) password.
7 specifies a Cisco proprietary encrypted
password.
The password-string argument defines the password
key to be used for computing MD5 checksums for the
session TCP connection with the specified neighbor.
Example:
Router(config)# end
8

Step 5 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 VRF instance
(vrf-name).
Example:
Router# show mpls ldp neighbor vrf vpn1 detail The all keyword displays LDP neighbor information
for all VPNs, including those in the default routing
domain.
The ip-address argument identifies the neighbor with
the IP address for which you configured password
protection.
The interface argument defines 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 or not
required)
The password source (neighbor, fallback or
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.
9

Step 6 show mpls ldp neighbor [vrf vrf-name] Displays password information used in established LDP
[ip-address | interface] password [pending | sessions.
current]
The vrf vrf-name keyword-argument pair displays the
LDP neighbors for the specified VRF instance
Example: (vrf-name).
Router# show mpls ldp neighbor vrf vpn1
password The ip-address argument identifies the neighbor with
the IP address for which you configured password
protection.
The interface argument defines the LDP neighbors
accessible over this interface.
The pending keyword displays LDP sessions whose
passwords are different from that in the current
configuration.
The current keyword displays LDP sessions whose
password is the same as that in current configuration.
If you do not specify an optional keyword for this
command, password information for all established LDP
sessions is displayed.
Step 7 show mpls ldp discovery [vrf vrf-name | all] Displays the status of the LDP discovery process.
[detail]
neighbor discovery information for the specified VRF
Example: instance (vrf-name).
Router# show mpls ldp discovery vrf vpn1 detail
The all keyword displays LDP discovery information
domain.
The detail keyword displays detailed information about
all LDP discovery sources on an LSR.
Configuring an LDP MD5 Password for LDP Sessions with Peers from a Specified VRF
Perform the following task to configure an LDP MD5 password for LDP sessions with peers from a
specified VRF. You can also use this task to configure an LDP MD5 password for LDP sessions with
peers from the global routing table.
This task provides you with LDP session protection with peers from a particular VRF or the global
routing table. If you want a password requirement, you can use the mpls ldp password required
command.
If only LDP sessions with a set of LDP neighbors need MD5 protection, configure a standard IP access
list that10 permits the desired set of LDP neighbors and denies the rest. See the Configuring an LDP
MD5 Password for LDP Sessions with a Selected Group of Peers section on page 12.
Prerequisites
Identify LDP peers for which you want MD5 password protection.
10
SUMMARY STEPS
1. enable
3. mpls ldp [vrf vrf-name] password fallback [0 | 7] password
4. mpls ldp [vrf vrf-name] password required [for acl]
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls ldp [vrf vrf-name] password fallback [0 | Configures an MD5 password for LDP sessions with peers.
7] password
The vrf vrf-name keyword-argument pair specifies a
VRF configured on the LSR.
Example:
Router(config)# mpls ldp vrf vpn1 password
The [0 | 7] keywords specify whether the password that
fallback 0 vrfpwdvppn1 follows is encrypted:
password.
The password argument specifies the MD5 password to
be used for the LDP sessions with peers whose
connections are established through a named VRF or
the global routing table.
The example sets up an MD5 password for a VRF.
Step 4 mpls ldp [vrf vrf-name] password required [for Specifies that LDP must use a password when establishing
acl] a session between LDP peers.
Example: VRF configured on the LSR.
Router(config)# mpls ldp vrf vpn1 password
required The for acl keyword-argument pair names an access list
that specifies that a password is mandatory only for
LDP sessions with neighbors whose LDP router IDs are
permitted by the list. Only standard IP access lists can
be used for the acl argument.
11

Example:
Router(config)# end
[detail]
neighbor discovery information for the specified VPN
Example: routing and forwarding instance (vrf-name).
domain.
Use this command to verify that password configuration is
correct for all LDP neighbors.
Configuring an LDP MD5 Password for LDP Sessions with a Selected Group of Peers
Perform the following task to configure an LDP MD5 password for LDP sessions with a selected group
of peers.
If only LDP sessions with a selected group of peers need MD5 protection, configure a standard IP access
list that permits sessions with the desired group of peers (identified by LDP router IDs) and denies
session with the rest. Configuring a password and password requirement for these neighbors or peers
provides security by preventing LDP sessions from being established with unauthorized peers.
Prerequisites
Identify the groups of peers for which you want MD5 password protection and define an access list that
permits LDP sessions with the group of peers you require.
SUMMARY STEPS
1. enable
3. mpls ldp [vrf vrf-name] password option number for acl [0 | 7] password
4. mpls ldp [vrf vrf-name] password required [for acl]
5. end
12
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls ldp [vrf vrf-name] password option number Configures an MD5 password for LDP sessions with
for acl [0 | 7] password neighbors whose LDP router IDs are permitted by a
specified access list.
Example: The vrf vrf-name keyword-argument pair specifies a
Router(config)# mpls ldp password option 25 for VRF configured on the LSR.
10 aclpwdfor10
The number argument defines the order in which the
access lists are evaluated in the determination of a
neighbor password. The valid range is 132767.
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 (199) can be used for the
acl argument.
The [0 | 7] keywords specifies whether the password
that follows is encrypted:
password.
The password argument specifies the MD5 password to
be used for the specified LDP sessions.
Step 4 mpls ldp [vrf vrf-name] password required [for Specifies that LDP must use a password when establishing
acl] a session between LDP peers.
Example: VRF configured on the LSR.
Router(config)# mpls ldp password required for
10 The for acl keyword-argument pair names an access
list. The access list specifies a password is mandatory
only for LDP sessions with neighbors whose LDP
router IDs are permitted by the list. Only standard IP
access lists can be used for the acl argument.
13

Example:
Router(config)# end
[detail]
neighbor discovery information for the specified VPN
Example: routing and forwarding instance (vrf-name).
domain.
Use this command to verify password configuration is
correct for all LDP neighbors.
Verifying the LDP MD5 Configuration

Perform the following task to verify that the LDP MD5 secure sessions are as you configured for all LDP
neighbors.
SUMMARY STEPS
1. enable
2. show mpls ldp discovery detail
3. show mpls ldp neighbor detail
4. show mpls ldp neighbor password [pending | current]
5. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls ldp discovery detail

Use this command to verify that the LDP MD5 password information is as you configured for each
neighbor. For example:

10.1.1.1:0
Discovery Sources:
Interfaces:
14
Ethernet1/0 (ldp): xmit/recv

LDP Id: 10.4.4.4:0
Password: not required, none, stale
Targeted Hellos:
10.1.1.1 -> 10.3.3.3 (ldp): passive, xmit/recv
LDP Id: 10.3.3.3:0
Password: required, neighbor, in use
The Password field might display any of the following for the status of the password:
Required or not requiredIndicates whether password configuration is required.
Neighbor, none, option #, or fallbackIndicates the password source when the password was
configured.
In use (current) or stale (previous)Indicates the current LDP session password usage status.
Look at the output of the command to verify your configuration.
Step 3 show mpls ldp neighbor detail

Use this command to verify that the password information for a neighbor is as you configured. For
example:

TCP connection: 10.3.3.3.11018 - 10.1.1.1.646
Targeted Hello 10.1.1.1 -> 10.3.3.3, passive;
10.3.3.3 10.0.30.3
TCP connection: 10.4.4.4.11017 - 10.1.1.1.646
Ethernet1/0; Src IP addr: 10.0.20.4
10.0.40.4 10.4.4.4 10.0.20.4
Step 4 show mpls ldp neighbor password [pending | current]

Use this command to verify that LDP sessions are using the password configuration that you expect,
either the same as or different from that in the current configuration. The pending keyword displays
information for LDP sessions whose password is different from that in the current configuration. The
current keyword displays information for LDP sessions whose password is the same as that in the
current configuration.
15
Configuration Examples for Configuring the MPLSLDP MD5 Global Configuration Feature
For example:
Router# show mpls ldp neighbor password

TCP connection: 10.4.4.4.11017 - 10.1.1.1.646
State: Oper; Msgs sent/rcvd: 57/57
TCP connection: 10.3.3.3.11018 - 10.1.1.1.646
Router# show mpls ldp neighbor password pending

TCP connection: 10.4.4.4.11017 - 10.1.1.1.646
Router# show mpls ldp neighbor password current

TCP connection: 10.3.3.3.11018 - 10.1.1.1.646
This command displays password information used in established LDP sessions. If you do not enter an
optional pending or current keyword for the command, password information for all established LDP
sessions is displayed.
Step 5 exit
Router# exit
Router>
Configuration Examples for Configuring the MPLSLDP MD5

Global Configuration Feature
This section contains the following example for configuring the MPLSLDP MD5 Global
Configuration feature:
Configuring an LDP MD5 Password for LDP Sessions: Examples, page 16
Configuring an LDP MD5 Password for LDP Sessions: Examples

The section contains the following examples for configuring an LDP MD5 password for LDP sessions:
Configuring an LDP MD5 Password for LDP Sessions for a Specified Neighbor: Example, page 17
Configuring an LDP MD5 Password for LDP Sessions with Peers from a Specified VRF: Example,
page 17
16
Configuration Examples for Configuring the MPLSLDP MD5 Global Configuration Feature
Configuring an LDP MD5 Password for LDP Sessions with a Selected Group of Peers: Example,
page 17
Configuring an LDP MD5 Password for LDP Sessions for a Specified Neighbor: Example
The following example shows how to configure an LDP MD5 password for LDP sessions for a specified
neighbor:
enable
configure terminal
mpls ldp vrf vpn1 10.1.1.1 password nbrscrtpwd
end
This sets up nbrscrtpwd as the password to use for LDP sessions for the neighbor whose LDP router ID
is 10.1.1.1. Communication with this neighbor is through VRF vpn1.
Configuring an LDP MD5 Password for LDP Sessions with Peers from a Specified VRF: Example
The following example shows how to configure an LDP MD5 password for LDP sessions with peers
from a specified VRF. The password vrfpwdvpn1 is configured for use with LDP peers that communicate
using VRF vpn1. A password is required; otherwise, LDP tears down the session.
enable
configure terminal
mpls ldp vrf vpn1 password fallback vrfpwdvpn1
mpls ldp vrf vpn1 password required
end
The following example shows how to configure a password that is used for sessions for peers that
communicate using the global routing table:
enable
configure terminal
mpls ldp password fallback vrfpwdvppn1
end
Configuring an LDP MD5 Password for LDP Sessions with a Selected Group of Peers: Example
The following example shows how to configure an LDP MD5 password for LDP sessions with a selected
group of peers. The required password aclpwdfor10 is configured for access list 10. Only those LDP
router IDs permitted in access list 10 are required to use the password.
enable
configure terminal
mpls ldp password option 25 for 10 aclpwdfor10
mpls ldp password required for 10
end
Access list 10 might look something like this:

enable
configure terminal
access-list 10 permit 10.1.1.1
end
17
The following sections provide references related to the MPLSLDP MD5 Global Configuration
feature.
Related Documents
Configuration tasks for LDP MPLS LDP MD5 Global Configuration
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
No new or modified RFCs are supported by this
feature, and support for existing RFCs has not been
18
Command Reference
Description Link
Command Reference
mpls ldp password fallback
mpls ldp password option
mpls ldp password required
show mpls ldp discovery
show mpls ldp neighbor password
19
Feature Information for MPLSLDP MD5 Global Configuration

20
Table 1 Feature Information for MPLSLDP MD5 Global Configuration

MPLSLDP MD5 Global Configuration 12.2(28)SB The MPLSLDP MD5 Global Configuration feature
12.0(32)SY provides enhancements to the Label Distribution Protocol
12.2(33)SRB (LDP) implementation of the Message Digest 5 (MD5)
12.4(20)T password. This feature allows you to enable LDP MD5
globally instead of on a per-peer basis. Using this feature
you can set up password requirements for a set of LDP
neighbors to help prevent unauthorized peers from
establishing LDP sessions and to block spoofed TCP
messages.
In 12.0(32)SY, this feature was integrated into Cisco IOS
Release 12.0(32)SY.
12.2(33)SRB.
12.4(20)T.
feature:
Enhancements to LDP MD5 Protection for LDP
Messages Between Peers, page 2
LDP MD5 Password Configuration Information, page 3
LDP MD5 Password Configuration for Routing Tables,
page 4
Password Requirements for LDP Sessions, page 5
Identifying LDP Neighbors for LDP MD5 Password
Protection, page 5
Identifying LDP Neighbors for LDP MD5 Password
Protection, page 5
Configuring an LDP MD5 Password for LDP Sessions,
page 7
Verifying the LDP MD5 Configuration, page 14
The following commands were modified by this feature:
mpls ldp password fallback, mpls ldp password option,
mpls ldp password required, show mpls ldp discovery,
show mpls ldp neighbor, show mpls ldp neighbor
password.
21
Glossary
Glossary
BGPBorder Gateway Protocol. An interdomain routing protocol that replaces External Gateway
Protocol (EGP). BGP systems exchange reachability information with other BGP systems. BGP is
EGPExterior Gateway Protocol. An internet protocol for exchanging routing information between
autonomous systems. EGP is documented in RFC 904. EGP is not to be confused with the general term
exterior gateway protocol. EGP is an obsolete protocol that was replaced by Border Gateway Protocol
(BGP).
CE routercustomer edge router. A router that is part of a customer network and that interfaces to a
provider edge (PE) router.
CSCCarrier Supporting Carrier. A situation where one service provider allows another service
provider to use a segment of its backbone network. The service provider that provides the segment of the
backbone network to the other provider is called the backbone carrier. The service provider that uses the
segment of the backbone network is called the customer carrier.
LDPLabel Distribution Protocol. A standard protocol between Multiprotocol Label Switching
(MPLS)-enabled routers that is uses in the negotiation of the labels used to forward packets. The Cisco
proprietary version of this protocol is the Tag Distribution Protocol (TDP).
LDP peerA label switch router (LSR) that is the receiver of label space information from another
LSR. If an LSR has a label space to advertise to another LSR, or to multiple LSRs, one Label
Distribution Protocol (LDP) session exists for each LSR (LDP peer) receiving the label space
information.
MD5Message Digest 5. A one-way hashing algorithm that produces a 128-bit hash. Both MD5 and
Secure Hash Algorithm (SHA) are variations on MD4 and are designed to strengthen the security of the
MD4 hashing algorithm. Cisco uses hashes for authentication within the IPSec framework. SNMP v.2
uses MD5 for message authentication, to verify the integrity of the communication, to authenticate the
message origin, and to check its timeliness.
MPLSMultiprotocol Label Switching. A switching method that forwards IP traffic through use of
labels. Each label instructs the routers and the switches in the network where to forward a packet based
on preestablished IP routing information.
customer edge (CE) router. All Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN)
processing occurs in the PE router.
VPNVirtual Private Network. Enables IP traffic to travel securely over a public TCP/IP network by
encrypting all traffic forwarded from one network to another. A VPN uses tunneling to encrypt all
information at the IP level.
VRFA 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. In general, a VRF includes the routing information
that defines a customer VPN site that is attached to a PE router.
22
Glossary
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, the Cisco logo, 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, iQ
Expertise, the iQ logo, iQ Net Readiness Scorecard, 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.
23
Glossary
24
MPLS LDPLossless MD5 Session
Authentication

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

feature is supported, use the Feature Information for MPLS LDPLossless MD5 Session Authentication
section on page 31.
Contents
Prerequisites for MPLS LDPLossless MD5 Session Authentication, page 2
Restrictions for MPLS LDPLossless MD5 Session Authentication, page 2
Information About MPLS LDPLossless MD5 Session Authentication, page 2
How to Configure MPLS LDPLossless MD5 Session Authentication, page 6
Configuration Examples for MPLS LDPLossless MD5 Session Authentication, page 16
Feature Information for MPLS LDPLossless MD5 Session Authentication, page 31

MPLS LDPLossless MD5 Session Authentication
Prerequisites for MPLS LDPLossless MD5 Session Authentication
Prerequisites for MPLS LDPLossless MD5 Session

Authentication
The MPLS LDPLossless MD5 Session Authentication feature is an enhancement to the MPLS LDP
MD5 Global Configuration feature. Before configuring the MPLS LDPLossless MD5 Session
Authentication feature, refer to the MPLSLDP 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 LDPLossless 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
LDPLossless MD5 Session Authentication feature:
Cisco Express Forwarding or distributed Cisco Express Forwarding
Static or dynamic routing
MPLS Virtual Private Network (VPN) routing and forwarding (VRFs) instances for MPLS VPNs
MPLS LDPLossless 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 LDPLossless MD5 Session

Authentication
MD5 protection applies to LDP sessions between peers. Tag Distribution Protocol (TDP) sessions
between peers are not protected.
Information About MPLS LDPLossless MD5 Session

Authentication
You should understand the following concepts before configuring the MPLS LDPLossless MD5
Session Authentication feature:
How MPLS LDP Messages in MPLS LDPLossless MD5 Session Authentication are Exchanged,
page 3
The Evolution of MPLS LDP MD5 Password Features, page 3
Keychains Use with MPLS LDPLossless 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 LDPLossless MD5 Session Authentication
How MPLS LDP Messages in MPLS LDPLossless 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 LDPLossless 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 MPLSLDP 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 LDPLossless MD5 Session Authentication feature is based on the MPLS LDP MD5
Global Configuration feature. However, the MPLS LDPLossless 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 LDPLossless MD5 Session Authentication

The MPLS LDPLossless 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 1 specifies the lab password. The send-lifetime command enables the lab password to
authenticate the outgoing TCP segments from November 2, 2007, at 10:00:00 a.m. until
December 2, 2007, 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, 2007, at 10:00:00 a.m.
until November 17, 2007, at 10:00:00 a.m. and from November 17, 2007, at 10:00:00 a.m. until
December 2, 2007, at 10:00:00 a.m., respectively.
key chain ldp-pwd
key 1
key-string lab
send-lifetime 10:00:00 Nov 2 2007 10:00:00 Dec 2 2007
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 2007 10:00:00 Nov 17 2007
key 3
key-string lab3
accept-lifetime 10:00:00 Nov 17 2007 10:00:00 Dec 2 2007
!
mpls ldp password option 1 for nbr-acl key-chain ldp-pwd
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 LDPLossless 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 LDPLossless MD5 Session

Authentication
Configuring MPLS LDPLossless MD5 Session Authentication Using a Keychain, page 7
(Optional)
Enabling the Display of MPLS LDP Password Rollover Changes and Events, page 12 (Optional)
Changing MPLS LDPLossless MD5 Session Authentication Passwords, page 13 (Optional)

6
Configuring MPLS LDPLossless MD5 Session Authentication Using a

Keychain
Perform this task to configure the MPLS LDPLossless 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]

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

8

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.

9

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

10

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.

11

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:
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
this task.
SUMMARY STEPS
1. enable
3. mpls ldp logging password configuration [rate-limit number]
4. mpls ldp logging password rollover [rate-limit number]

12
5. exit
6. debug mpls ldp transport events
or
debug mpls ldp transport connections
DETAILED STEPS
Step 1 enable
This command enables privileged EXEC mode. Enter the password if prompted.
Step 2 configure terminal
This command enables global configuration mode.
Step 3 mpls ldp logging password configuration [rate-limit number]
This command is used to enable the display of events related to configuration changes. The output
displays events when a new password is configured or an existing password has been changed or deleted.
A rate limit of 1 to 60 messages a minute can be specified.
Step 4 mpls ldp logging password rollover [rate-limit number]
This command is used to enable the display of events related to password rollover events. Events are
displayed when a new password is used for authentication or when authentication is disabled. A rate
limit of 1 to 60 messages a minute can be specified.
Step 5 exit
This command exits global configuration mode.
Step 6 debug mpls ldp transport events
or
debug mpls ldp transport connections
Either command displays notifications when a session TCP MD5 option is changed.
For example:
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]
Changing MPLS LDPLossless MD5 Session Authentication Passwords

The MPLS LDPLossless 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 vpn-name] ip-address password password

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

14

Step 5 no mpls ldp neighbor [vrf vpn-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 vpn-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.
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:
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 LDPLossless MD5 Session Authentication
Configuration Examples for MPLS LDPLossless MD5 Session

Authentication
Configuring MPLS LDPLossless MD5 Session Authentication Using a Keychain (Symmetrical):
Example, page 16
Configuring MPLS LDPLossless MD5 Session Authentication Using a Keychain
(Asymmetrical): Example, page 17
Changing MPLS LDPLossless MD5 Session Authentication Password: Example, page 18
Changing MPLS LDPLossless MD5 Session Authentication Password Using a Rollover Without
Keychain: Example, page 19
Changing MPLS LDPLossless MD5 Session Authentication Password Using a Rollover with a
Keychain: Example, page 20
Changing MPLS LDPLossless MD5 Session Authentication Password Using a Fallback Password
With a Keychain: Example, page 22
Changing MPLS LDPLossless MD5 Session Authentication: Common Misconfiguration
Examples, page 24
Changing MPLS LDPLossless 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
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 2007 10:00:00 Feb 1 2007
accept-lifetime 09:00:00 Jan 1 2007 11:00:00 Feb 1 2007
!
interface loopback0
ip address 10.1.1.1 255.255.255.255
!
ip address 10.0.1.1 255.255.255.254
tag-switching 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
tag-switching 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
tag-switching 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
tag-switching ip
Changing MPLS LDPLossless 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 LDPLossless MD5 Session Authentication Password Using

a Rollover Without Keychain: Example
The MPLS LDPLossless 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
!
ip address 10.2.0.1 255.255.0.0
mpls ip

19

!
interface loopback0
ip address 10.11.11.11 255.255.255.255
!
ip address 10.2.0.2 255.255.0.0
mpls ip
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 MPLS LDPLossless MD5 Session Authentication 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

20
send-lifetime 10:00:00 Jan 1 2007 10:30:00 Jan 1 2007

accept-lifetime 10:00:00 Jan 1 2007 10:45:00 Jan 1 2007
key 11
key-string lab2
key 12
key-string lab3
send-lifetime 10:30:00 Feb 1 2007 10:30:00 Mar 1 2007
accept-lifetime 10:15:00 Feb 1 2007 10:45:00 Mar 1 2007
!
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 MPLS LDPLossless MD5 Session Authentication 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 LDPLossless MD5 Session Authentication: Common

Misconfiguration Examples
The following sections describe common misconfiguration examples that can occur when the MPLS
LDPLossless MD5 Session Authentication 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 2007 10:30:00 Mar 1 2007 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 2007 10:30:00 Mar 1 2007 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 LDPLossless MD5 Session Authentication Using a Second

Key to Avoid LDP Session Failure: Examples
The MPLS LDPLossless MD5 Session Authentication 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 MPLS LDPLossless MD5
Session Authentication 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 27
Reconfigure a Keychain to Prevent TCP Authentication and LDP Session Failures: Example,
page 27

26
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 2007 01:10:00 Sep 10 2007
send-lifetime 01:05:00 Sep 10 2007 01:08:00 Sep 10 2007
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

27
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 2007 infinite
send-lifetime 01:08:00 Sep 10 2007 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
key 2
key 3
accept-lifetime 01:13:00 Sep 10 2007 infinite
send-lifetime 01:15:00 Sep 10 2007 infinite

28
The following sections provide references related to the MPLS LDPLossless 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.

29
Command Reference
Description Link
Command Reference
Command Reference at http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_book.html
http://tools.cisco.com/Support/CLILookup.
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 password

30
Feature Information for MPLS LDPLossless MD5 Session Authentication
Feature Information for MPLS LDPLossless MD5 Session

Authentication
Table 1 Feature Information for MPLS LDPLossless MD5 Session Authentication

MPLS LDPLossless MD5 Session 12.0(33)S This feature allows an LDP session to be
Authentication 12.2(33)SRC password-protected without tearing down and
12.2(33)SB reestablishing the LDP session.
12.4(20)T
This feature was introduced in
Cisco IOS Release12.0(33)S.
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.
This feature was integrated into
Cisco IOS Release 12.2(33)SRC.
This feature was integrated into
Cisco IOS Release12.2(33)SB.
This feature was integrated ino
Cisco IOS Release12.4(20)T.

31
Feature Information for MPLS LDPLossless MD5 Session Authentication
coincidental.

32
MPLS LDP Inbound Label Binding Filtering
Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) supports inbound label
binding filtering. You can use the MPLS LDP feature to configure access control lists (ACLs) for
controlling the label bindings a label switch router (LSR) accepts from its peer LSRs.
History for the MPLS LDP Inbound Label Binding Filtering Feature
12.2(25)S This feature was integrated into Cisco IOS Release 12.2(25)S for the Cisco
7500 series router.
12.3(14)T This feature was integrated into Cisco IOS Release 12.3(14)T.
12.2(18)SXE This feature was integrated into Cisco IOS Release 12.2(18)SXE for the
Cisco 7600 series router.
support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on
Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at
the login dialog box and follow the instructions that appear.
Contents
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
Glossary, page 8

Information about MPLS LDP Inbound Label Binding Filtering
Information about MPLS LDP Inbound Label Binding Filtering

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 4 (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 25.0.0.2 from LDP neighbor router 10.12.12.12.
Restrictions
Inbound label binding filtering does not support extended ACLs; it only supports standard ACLs.
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 labels accept acl Specifies the ACL to be used to filter label
bindings for the 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
3
Verifying that MPLS LDP Inbound Label Bindings are Filtered

If inbound filtering is enabled, perform the following steps to verify that inbound label bindings are
filtered:
Step 1 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.
show mpls ldp neighbor [vrf vpn-name][address | interface] [detail]
Note To display information about inbound label binding filtering, you must enter the detail keyword.
Following is sample output from the show mpls ldp neighbor command.
Router# show mpls ldp neighbor 10.12.12.12 detail

TCP connection: 10.12.12.12.646 - 10.13.13.13.12592
Serial1/0; Src IP addr: 25.0.0.2
10.0.0.129 10.12.12.12 10.0.0.2
LDP inbound filtering accept acl: 1
Step 2 Enter the show ip access-list command to display the contents of all current IP access lists or of a
specified access list.
show ip access-list [access-list-number | access-list-name]
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 3 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
tib entry: 10.13.13.13/32, rev 14
4
Configuration Examples for MPLS LDP Inbound Label Binding Filtering
tib entry: 10.10.0.0/16, rev 711

tib entry: 10.0.0.0/8, rev 1135
remote binding: tsr: 12.12.12.12:0, tag: imp-null
tib entry: 10.0.0.0/8, rev 8
Router#
Configuration Examples for MPLS LDP Inbound Label Binding

Filtering
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
The following sections provide additional references related to MPLS LDP inbound label binding filters.
5
Command Reference
Related Documents
MPLS Label Distribution Protocol (LDP) MPLS Label Distribution Protocol
Standards
Standard Title
None
MIBs
MIB MIBs Link
LDP Specification, draft-ietf-mpls-ldp-08.txt To locate and download MIBs for selected platforms, Cisco IOS
following URL:
RFCs
RFC Title
Description Link
Command Reference
clear mpls ldp neighbor
6
Command Reference
mpls ldp neighbor labels accept

7
Glossary
Glossary
carrier supporting carrierA situation where one service provider allows another service provider to
use a segment of its backbone network. The service provider that provides the segment of the backbone
network to the other provider is called the backbone carrier. The service provider that uses the segment
of the backbone network is called the customer carrier.
inbound label binding filteringAllows 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.
labelA short fixed-length identifier that tells switching nodes how to forward data (packets or cells).
label bindingAn association between a destination prefix and a label.
coincidental.
8
MPLS LDPLocal Label Allocation Filtering

Last Updated: April 11, 2008
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 LDPLocal
Label Allocation Filtering feature.

feature is supported, use the Feature Information for MPLS LDPLocal Label Allocation Filtering section
on page 19.
Contents
Prerequisites for MPLS LDPLocal Label Allocation Filtering, page 2
Restrictions for MPLS LDPLocal Label Allocation Filtering, page 2
Information About MPLS LDPLocal Label Allocation Filtering, page 2
How to Configure MPLS LDPLocal Label Allocation Filtering, page 5
Configuration Examples for MPLS LDPLocal Label Allocation Filtering, page 10

Prerequisites for MPLS LDPLocal Label Allocation Filtering
Feature Information for MPLS LDPLocal Label Allocation Filtering, page 19

Glossary, page 21
Prerequisites for MPLS LDPLocal Label Allocation Filtering

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

The MPLS LDPLocal Label Allocation Filtering feature does not support access lists. This feature
supports prefix lists.
Restrictions for the MPLS LDPLocal Label Allocation Filtering feature in Cisco IOS
Releases 12.2(33)SRC and 12.2(33)SB:
LDP local label allocation configuration for prefix list or host routes is supported only in the global
routing table.
LDP and RIB restart handling supported in Cisco IOX software 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 LDPLocal Label Allocation Filtering

Before you configure the MPLS LDPLocal 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 Introduced in Cisco IOS Release 12.2(33)SRC 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 (19972007), 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 LDPLocal 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 LDPLocal 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
Local bindings
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 LDPLocal 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 LDPLocal 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 Introduced in Cisco IOS Release 12.2(33)SRC

and LDP Actions
The MPLS LDPLocal Label Allocation Filtering enhancement modifies the LDPs 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.

4
How to Configure MPLS LDPLocal Label Allocation Filtering
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.
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 LDPLocal 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 LDPLocal 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 LDPLocal 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]

5
4. end
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
Step 9 exit Exits to privileged EXEC mode.
Example:

8
Verifying MPLS LDPLocal Label Allocation Filtering Configuration

Perform the following task to verify the MPLS LDPLocal 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 LDPLocal Label Allocation Filtering
Step 4 exit
Router# exit
Router>
Configuration Examples for MPLS LDPLocal Label Allocation

Filtering
This section contains the following configuration examples for the MPLS LDPLocal 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, Ethernet1/0
O 10.3.3.3 [110/11] via 10.10.9.1, 00:00:36, Ethernet3/0
C 10.10.7.0 is directly connected, Ethernet1/0
O 10.10.8.0 [110/20] via 10.10.9.1, 00:00:36, Ethernet3/0
[110/20] via 10.10.7.1, 00:00:36, Ethernet1/0
C 10.10.9.0 is directly connected, Ethernet3/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 FilterHost 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 FilterPrefix 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 LDPLocal Label Allocation Filtering
feature.
Related Documents
Configuration tasks for MPLS LDP MPLS Label Distribution Protocol Overview
MPLS LDP commands Cisco IOS Multiprotocol Label Switching Command Reference
Configuration tasks for inbound label binding filtering MPLS LDP Inbound Label Binding Filtering
for MPLS LDP
Standards
Standard Title
MIBs
MIB MIBs Link

17
Command Reference
RFCs
RFC Title
RFC 3815 Definitions of Managed Objects for the Multiprotocol Label
Switching (MPLS), Label Distribution Protocol (LDP)
Description Link
Command Reference
allocate
debug mpls ldp bindings
mpls ldp label
show mpls ldp bindings

18
Feature Information for MPLS LDPLocal Label Allocation Filtering
Feature Information for MPLS LDPLocal Label Allocation

Filtering
Table 1 Feature Information for MPLS LDPLocal Label Allocation Filtering

MPLS LDPLocal Label Allocation Filtering 12.2(33)SRC This feature introduces command-line interface (CLI)
12.2(33)SB 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 LDPLocal Label Allocation
Filtering feature.
In 12.2(33)SRC, the feature was introduced on a Cisco IOS
12.2SR release.
In 12.2(33)SB, the feature was integrated into a Cisco IOS
12.2SB release.
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 Introduced in
Cisco IOS Release 12.2(33)SRC 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 LDPLocal Label Allocation Filtering
Table 1 Feature Information for MPLS LDPLocal Label Allocation Filtering (continued)

Configuring MPLS LDP Local Label Allocation
Filtering, page 7
Verifying MPLS LDPLocal Label Allocation
Filtering Configuration, page 9
allocate, debug mpls ldp bindings, mpls ldp label, show
mpls ldp bindings.

20
Glossary
Glossary
BGPBorder Gateway Protocol. An interdomain routing protocol that replaces Exterior Gateway
Protocol (EGP). A BGP system exchanges reachability information with other BGP systems. It is
provider edge (PE) router. CE routers do not have routes to associated Virtual Private Networks (VPNs)
in their routing tables.
FECForwarding 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.
IGPInterior 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).
labelA short fixed-length label that tells switching nodes how to forward data (packets or cells).
LDPLabel 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.
LIBLabel 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.
LSPlabel 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.
LSRlabel switch router. A device that forwards Multiprotocol Label Switching (MPLS) packets based
on the value of a fixed-length label encapsulated in each packet.
MPLSMultiprotocol 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
customer edge (CE) router. All Virtual Private Network (VPN) processing occurs in the PE router.
VPNVirtual 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
CCDE, CCVP, Cisco Eos, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We
Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE,
CCIP, CCNA, CCNP, CCSP, 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, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Event Center, Fast
Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness
Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, 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.

22
MPLS Traffic Engineering: Path
Calculation and Setup
MPLS Traffic EngineeringLSP Attributes
First Published: August 26, 2003

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

supported, see the Feature Information for MPLS Traffic EngineeringLSP Attributes section on page 42.
Contents
Prerequisites for MPLS Traffic EngineeringLSP Attributes, page 2
Restrictions for MPLS Traffic EngineeringLSP Attributes, page 2
Information About MPLS Traffic EngineeringLSP Attributes, page 2
How to Configure MPLS Traffic EngineeringLSP Attributes, page 6
Configuration Examples for MPLS Traffic EngineeringLSP Attributes, page 34
2003 2009 Cisco Systems, Inc. All rights reserved.

Prerequisites for MPLS Traffic EngineeringLSP Attributes

Feature Information for MPLS Traffic EngineeringLSP Attributes, page 42
Glossary, page 44
Prerequisites for MPLS Traffic EngineeringLSP Attributes

TheMPLS Traffic EngineeringLSP 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 EngineeringLSP 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 EngineeringLSP Attributes

To configure the MPLS Traffic EngineeringLSP Attributes feature, you need the following
information:
MPLS Traffic EngineeringLSP 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 EngineeringLSP Attributes Benefits

The MPLS Traffic EngineeringLSP 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 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 bandwidthglobal 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 EngineeringLSP 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.
For more information on automatic bandwidth adjustment for TE tunnels, see the MPLS Traffic
Engineering (TE)Automatic Bandwidth Adjustment for TE Tunnels feature documentation.
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 EngineeringLSP 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 bandwidth 1000
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 EngineeringLSP
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

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}
5. tunnel mode mpls traffic-eng
6. tunnel mpls traffic-eng autoroute announce
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

Step 3 interface type number Configures an interface type and enters interface
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:
Router(config-if)# tunnel mode mpls traffic-eng
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:
Router(config-if)# tunnel mpls traffic-eng
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-10-c_t1 (Tunnel1) Destination: 10.10.10.12

Status:
Admin: up Oper: up Path: valid Signalling: connected
path option 2, type explicit path2 (Basis for Setup, path weight 65834)
Config Parameters:
Bandwidth: 1000 kbps (Global) Priority: 1 1 Affinity: 0x0/0xFFFF
Metric Type: IGP (global)
AutoRoute: enabled LockDown: disabled Loadshare: 1 bw-based
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
Use this command to return to user EXEC mode. For example:
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:
configuration mode.
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-15-c_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 EngineeringLSP 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 EngineeringLSP

Attributes
This section contains the following configuration examples for the MPLS Traffic EngineeringLSP
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 Ethernet4/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 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
tunnel destination 10.10.10.12
tunnel mode mpls traffic-eng
tunnel mpls traffic-eng autoroute announce
tunnel mpls traffic-eng priority 1 1
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 EngineeringLSP Attributes
feature.
Related Documents
MPLS TE automatic bandwidth adjustment for TE MPLS Traffic Engineering (TE)Automatic Bandwidth Adjustment
tunnels configuration tasks for TE Tunnels
MPLS TE command descriptions Cisco IOS Multiprotocol Label Switching Command Reference
Standards
Standards Title
MIBs
MIBs MIBs Link
39
Command Reference
RFCs
RFCs Title
Description Link
Command Reference
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
show mpls traffic-eng tunnels
40
Feature Information for MPLS Traffic EngineeringLSP Attributes
Feature Information for MPLS Traffic EngineeringLSP

Attributes
Table 1 Feature Information for MPLS Traffic EngineeringLSP Attributes

MPLS Traffic EngineeringLSP Attributes 12.0(26)S This document describes how to configure label switched
12.2(33)SRA path (LSP) attributes for path options associated with
12.2(33)SXH Multiprotocol Label Switching (MPLS) traffic engineering
12.4(20)T (TE) tunnels.
The MPLS Traffic EngineeringLSP 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.
In 12.2(33)SRA, this feature was integrated into a
Cisco IOS 12.2SRA release.
In 12.2(33)SXH, this feature was integrated into a
Cisco IOS 12.2SXH release.
In 12.4(20)T, this feature was integrated into a Cisco IOS
12.4T release.
feature:
MPLS Traffic EngineeringLSP Attributes Benefits,
page 2
Traffic Engineering Bandwidth and Bandwidth Pools,
page 3
41
Feature Information for MPLS Traffic EngineeringLSP Attributes
Table 1 Feature Information for MPLS Traffic EngineeringLSP Attributes (continued)

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
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
bandwidthThe 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 reservationThe 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 poolThe total bandwidth allocated to an MPLS traffic engineering link.
label switched path (LSP) tunnelA configured connection between two routers, using label
switching to carry the packets.
LSRlabel 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 TEMPLS 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.
subpoolThe more restrictive bandwidth in an MPLS traffic engineering link. The subpool is a portion
of the link's overall global pool bandwidth.
TEtraffic engineering. The 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 had been
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 tunnelA 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.
tunnelA secure communication path between two peers, such as two routers.
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,
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.
43
Glossary
44
MPLS Traffic EngineeringAutotunnel Primary
and Backup

The MPLS Traffic EngineeringAutotunnel Primary and Backup feature enables a router to
dynamically build backup tunnels and to dynamically create one-hop primary tunnels on all interfaces
that have been configured with Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnels.
A router with primary one-hop autotunnels and backup autotunnels can be configured with stateful
switchover (SSO) redundancy.

supported, see the Feature Information for MPLS Traffic EngineeringAutotunnel Primary and Backup
section on page 17.
Contents
Prerequisites for MPLS Traffic EngineeringAutotunnel Primary and Backup, page 2
Restrictions for MPLS Traffic EngineeringAutotunnel Primary and Backup, page 2
Information About MPLS Traffic EngineeringAutotunnel Primary and Backup, page 2
How to Configure MPLS Traffic EngineeringAutotunnel Primary and Backup, page 8
Configuration Examples for MPLS Traffic EngineeringAutotunnel Primary and Backup, page 11
MPLS Traffic EngineeringAutotunnel Primary and Backup
Prerequisites for MPLS Traffic EngineeringAutotunnel Primary and Backup

Feature Information for MPLS Traffic EngineeringAutotunnel Primary and Backup, page 17
Glossary, page 18
Prerequisites for MPLS Traffic EngineeringAutotunnel

Primary and Backup
Configure TE on the routers.
Restrictions for MPLS Traffic EngineeringAutotunnel Primary

and Backup
You cannot configure a static route to route traffic over TE autotunnels. For autotunnels, you should
use only the autoroute for tunnel selection.
Information About MPLS Traffic EngineeringAutotunnel

Primary and Backup
To configure autotunnels, you need to understand the following concepts:
Overview of MPLS Traffic EngineeringAutotunnel Primary and Backup, page 2
Benefits of MPLS Traffic EngineeringAutotunnel Primary and Backup Feature, page 3
MPLS Traffic Engineering, page 3
MPLS Traffic Engineering Backup Autotunnels, page 3
MPLS Traffic Engineering Primary Autotunnels, page 5
MPLS Traffic Engineering Label-Based Forwarding, page 6
Benefits of MPLS Traffic Engineering Protection, page 6
SSO Redundancy Overview, page 7
Overview of MPLS Traffic EngineeringAutotunnel Primary and Backup

The MPLS Traffic EngineeringAutotunnel Primary and Backup feature has the following features:
Backup autotunnelEnables a router to dynamically build backup tunnels.
Primary one-hop autotunnelEnables a router to dynamically create one-hop primary tunnels on all
interfaces that have been configured with MPLS TE tunnels.
If no backup tunnels exist, the following types of backup tunnels are created:
Next hop (NHOP)
Next-next hop (NNHOP)
2
Information About MPLS Traffic EngineeringAutotunnel Primary and Backup
Benefits of MPLS Traffic EngineeringAutotunnel Primary and Backup

Feature
Backup tunnels are built automatically, eliminating the need for users to preconfigure each backup
tunnel and then assign the backup tunnel to the protected interface.
The dynamic creation of one-hop primary tunnels eliminates the need to configure an MPLS TE
tunnel with the Fast Reroute (FRR) option for the tunnel to be protected.
Protection is expanded; FRR does not protect IP traffic that is not using the TE tunnel or Label
Distribution Protocol (LDP) labels that are not using the TE tunnel.
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.
TE is the process of adjusting bandwidth allocations to ensure that enough bandwidth is left for
high-priority traffic.
In MPLS TE, the upstream router creates a network tunnel for a particular traffic stream, then sets the
bandwidth available for that tunnel.
MPLS Traffic Engineering Backup Autotunnels

MPLS backup autotunnels protect fast reroutable TE label switched paths (LSPs). Without MPLS
backup autotunnels to protect a LSP you had to do the following:
Preconfigure each backup tunnel.
Assign the backup tunnels to the protected interfaces.
An LSP requests backup protection from Resource Reservation Protocol (RSVP) FRR in the following
situations:
Receipt of the first RSVP Resv message
Receipt of an RSVP path message with the protection attribute after the LSP has been established
without the protection attribute
Detection that a Record Route Object (RRO) changed
If there was no backup tunnel protecting the interface used by the LSP, the LSP remained unprotected.
Backup autotunnels enable a router to dynamically build backup tunnels when they are needed. This
prevents you from having to build MPLS TE tunnels statically.
Backup tunnels may not be available for the following reasons:
Static backup tunnels are not configured.
Static backup tunnels are configured, but cannot protect the LSP. The backup tunnel may not have
enough available bandwidth, the tunnel may protect a different pool, or the tunnel may be down.
If a backup tunnel is not available, the following two backup tunnels are created dynamically:
NHOPProtects against link failure
NNHOPProtects against node failure
3
Note At the penultimate hop, only an NHOP backup tunnel is created.
Note If two LSPs share the same output interface and NHOP, three (not four) backup tunnels are created. They
share an NHOP backup tunnel.
Link Protection
Backup tunnels that bypass only a single link of the LSPs path provide link protection. They protect
LSPs if a link along their path fails by rerouting the LSPs traffic to the next hop (bypassing the failed
link). These are referred to as NHOP backup tunnels because they terminate at the LSPs next hop
beyond the point of failure. Figure 1 illustrates an NHOP backup tunnel.
Figure 1 Next-Hop Backup Tunnel
Next-hop
backup tunnel
R1 R2 R3 R4
Next hop
59556
Primary Protected
LSP's path link
Node Protection
Backup tunnels that bypass next-hop nodes along LSP paths are called NNHOP backup tunnels because
they terminate at the node following the next-hop node of the LSPs, thereby bypassing the next-hop
node. They protect LSPs by enabling the node upstream of a link or node failure to reroute the LSPs and
their traffic around the failure to the next-hop node. 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.
4
Figure 2 Next-Next Hop 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
59557
link or node failures
Explicit Paths
Explicit paths are used to create backup autotunnels as follows:
NHOP excludes the protected links IP address.
NNHOP excludes the NHOP router ID.
The explicit-path name is _auto-tunnel_tunnelxxx, where xxx matches the dynamically created
backup tunnel ID.
The interface used for the ip unnumbered command defaults to Loopback0. You can configure this
to use a different interface.
Range for Backup Autotunnels

The tunnel range for backup autotunnels is configurable. By default, the last 100 TE tunnel IDs are used;
that is 65,436 to 65,535. Autotunnels detect tunnel IDs that are being used. IDs are allocated starting
with the lowest number.
Foe example, if you configure a tunnel range 1000 to 1100 and statically configured TE tunnels are in
that range, routers do not use those IDs. If those static tunnels are removed, the MPLS TE dynamic
tunnel software can use those IDs.
MPLS Traffic Engineering Primary Autotunnels

The MPLS Traffic EngineeringAutotunnel Primary and Backup feature enables a router to
dynamically create one-hop primary tunnels on all interfaces that have been configured with MPLS
traffic. The tunnels are created with zero bandwidth. The constraint-based shortest path first (CSPF) is
the same as the shortest path first (SPF) when there is zero bandwidth, so the routers choice of the
autorouted one-hop primary tunnel is the same as if there were no tunnel. Because it is a one-hop tunnel,
the encapsulation is tag-implicit (that is, there is no tag header).
5
Explicit Paths
Explicit paths are used to create autotunnels as follows:
The explicit path is dynamically created.
The explicit path includes the IP address for the interface connected to the next hop.
The explicit-path name is _auto-tunnel_tunnelxxx, where xxx matches the dynamically created
one-hop tunnel ID.
Interfaces used for the ip unnumbered command default to Loopback0. You can configure this to
use a different interface.
Range for Autotunnels

The tunnel range is configurable. By default, the last 100 TE tunnel IDs are used; that is 65,436 to
65,535. Autotunnels detect tunnel IDs that are being used. IDs are allocated starting with the lowest
number.
For example, if you configure a tunnel range 100 to 200 and statically configured TE tunnels are in that
range, routers do not use those IDs. If those static tunnels are removed, the IDs become available for use
by the MPLS TE dynamic tunnel software.
MPLS Traffic Engineering Label-Based Forwarding

Routers receive a packet, determine where it needs to go by examining some fields in the packet, and
send it to the appropriate output device. A label is a short, fixed-length identifier that is used to forward
packets. A label switching device normally replaces the label in a packet with a new value before
forwarding the packet to the next hop. For this reason, the forwarding algorithm is called label swapping.
A label switching device, referred to as an LSR, runs standard IP control protocols (that is, routing
protocols, RSVP, and so forth) to determine where to forward packets.
Benefits of MPLS Traffic Engineering Protection

The following sections describe the benefits of MPLS traffic engineering protection:
Delivery of Packets During a Failure, page 6
Multiple Backup Tunnels Protecting the Same Interface, page 6
Scalability, page 7
RSVP Hello, page 7
Delivery of Packets During a Failure

Backup tunnels that terminate at the NNHOP protect both the downstream link and node. This provides
protection for link and node failures.
Multiple Backup Tunnels Protecting the Same Interface

In addition to being required for node protection, the autotunnel primary and backup feature provides
the following benefits:
6
RedundancyIf one backup tunnel is down, other backup tunnels protect LSPs.
Increased backup capacityIf 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).
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. N:1 protection has significant scalability
advantages over one-to-one (1:1) protection, where a separate backup tunnel must be used for each LSP
needing protection.
An example of N:1 protection is that when one backup tunnel protects 5000 LSPs, each router along the
backup path maintains one additional tunnel.
An example of 1:1 protection is that when 5000 backup tunnels protect 5000 LSPs, each router along the
backup path must maintain state for an additional 5000 tunnels.
RSVP Hello
RSVP Hello allows a router to detect when its neighbor has gone down but its interface to that neighbor
is still operational. When Layer 2 link protocols are unable to detect that the neighbor is unreachable,
Hellos provide the detection mechanism; this allows the router to switch LSPs onto its backup tunnels
and avoid packet loss.
SSO Redundancy Overview

The SSO feature is an incremental step within an overall program to improve the availability of networks
constructed with Cisco IOS routers.
SSO is particularly useful at the network edge. It provides protection for network edge devices with dual
route processors (RPs) that represent a single point of failure in the network design, and where an outage
might result in loss of service for customers.
In specific Cisco networking devices that support dual RPs, SSO takes advantage of RP redundancy to
increase network availability. The feature establishes one of the RPs as the active processor while the
other RP is designated as the standby processor, and then synchronizes 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 standby processor occurs when the active RP fails, is removed from the
networking device, or is manually taken down for maintenance.
7
How to Configure MPLS Traffic EngineeringAutotunnel Primary and Backup
How to Configure MPLS Traffic EngineeringAutotunnel

Primary and Backup
This sections contains the following procedures:
Establishing MPLS Backup Autotunnels to Protect Fast Reroutable TE LSPs, page 8 (required)
Establishing MPLS One-Hop Tunnels to All Neighbors, page 9 (required)
Establishing MPLS Backup Autotunnels to Protect Fast Reroutable TE LSPs

To establish an MPLS backup autotunnel to protect fast reroutable TE LSPs, perform the following task.
Note Only Steps 1 through 3 are required. If you perform additional steps, you can perform them in any order
after Step 3.
SUMMARY STEPS
1. enable
3. mpls traffic-eng auto-tunnel backup
4. mpls traffic-eng auto-tunnel backup nhop-only
5. mpls traffic-eng auto-tunnel backup tunnel-num [min num] [max num]
6. mpls traffic-eng auto-tunnel backup timers removal unused sec
7. mpls traffic-eng auto-tunnel backup config unnumbered-interface interface
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng auto-tunnel backup Automatically builds NHOP and NNHOP backup
tunnels.
Example:
Router(config)# mpls traffic-eng auto-tunnel
backup
8

Step 4 mpls traffic-eng auto-tunnel backup nhop-only Enables the creation of dynamic NHOP backup tunnels.
Example:
backup nhop-only
Step 5 mpls traffic-eng auto-tunnel backup tunnel-num Configures the range of tunnel interface numbers for
[min num] [max num] backup autotunnels.
Example:
backup tunnel-num min 1000 max 1100
Step 6 mpls traffic-eng auto-tunnel backup timers removal Configures how frequently a timer will scan backup
unused sec autotunnels and remove tunnels that are not being used.
Example:
backup timers removal unused 50
Step 7 mpls traffic-eng auto-tunnel backup config Enables IP processing on the specified interface without
unnumbered-interface interface an explicit address.
Example:
backup config unnumbered-interface ethernet1/0
Establishing MPLS One-Hop Tunnels to All Neighbors

To establish MPLS one-hop tunnels to all neighbors, perform the following task.
Note Only Steps 1 through 3 are required. If you perform additional steps, you can perform them in any order
after Step 3.
SUMMARY STEPS
1. enable
3. mpls traffic-eng auto-tunnel primary onehop
4. mpls traffic-eng auto-tunnel primary tunnel-num [min num] [max num]
5. mpls traffic-eng auto-tunnel primary timers removal rerouted sec
6. mpls traffic-eng auto-tunnel primary config unnumbered interface
7. mpls traffic-eng auto-tunnel primary config mpls ip
8. clear mpls traffic-eng auto-tunnel primary
9
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng auto-tunnel primary onehop Automatically creates primary tunnels to all
next hops.
Example:
Router(config)# mpls traffic-eng auto-tunnel primary
onehop
Step 4 mpls traffic-eng auto-tunnel primary tunnel-num [min num] Configures the range of tunnel interface
[max num] numbers for primary autotunnels.
Example:
tunnel-num min 2000 max 2100
Step 5 mpls traffic-eng auto-tunnel primary timers removal Configures how many seconds after a failure
rerouted sec primary autotunnels will be removed.
Example:
timers removal rerouted 400
Step 6 mpls traffic-eng auto-tunnel primary config unnumbered Enables IP processing on the specified interface
interface without an explicit address.
Example:
config unnumbered ethernet1/0
Step 7 mpls traffic-eng auto-tunnel primary config mpls ip Enables LDP on primary autotunnels.
Example:
config mpls ip
Step 8 clear mpls traffic-eng auto-tunnel primary Removes all primary autotunnels and re-creates
them.
Example:
Router(config)# clear mpls traffic-eng auto-tunnel
primary
10
Configuration Examples for MPLS Traffic EngineeringAutotunnel Primary and Backup
Configuration Examples for MPLS Traffic

EngineeringAutotunnel Primary and Backup
This section contains the following configuration examples:
Establishing MPLS Backup Autotunnels to Protect Fast Reroutable TE LSPs: Example, page 11
Establishing MPLS One-Hop Tunnels to Neighbors: Example, page 13
Establishing MPLS Backup Autotunnels to Protect Fast Reroutable TE LSPs:

Example
Note This example does not include the mpls traffic-eng auto-tunnel backup nhop-only command because
autotunneling would not be able to create any backup tunnels.
To determine if there are any backup tunnels, enter the show ip rsvp fast-reroute command. This
example shows that there is a static configured primary tunnel and no backup tunnels.
Router(config)# show ip rsvp fast-reroute
Primary Protect BW Backup

Tunnel I/F BPS:Type Tunnel:Label State Level Type
------ ------- ------- ------------ ------ ----- ----
R3-PRP_t0 PO3/1 0:G None None None
The following command causes autotunnels to automatically configure NHOP and NNHOP backup
tunnels:
Router(config)# mpls traffic-eng auto-tunnel backup
As illustrated in the show ip interface brief command output, autotunneling created two backup tunnels
that have tunnel IDs 65436 and 65437:
Router# show ip interface brief
Interface IP-Address OK? Method Status Protocol

POS2/0 10.0.0.14 YES NVRAM down down
POS2/1 10.0.0.49 YES NVRAM up up
POS2/3 10.0.0.57 YES NVRAM administratively down down
POS3/2 unassigned YES NVRAM administratively down down
GigabitEthernet4/0 10.0.0.37 YES NVRAM up up
GigabitEthernet4/1 unassigned YES NVRAM administratively down down
Loopback0 10.0.3.1 YES NVRAM up up
Tunnel0 10.0.3.1 YES unset up up
Ethernet0 10.3.38.3 YES NVRAM up up
Ethernet1 unassigned YES NVRAM administratively down down
R3-PRP#
The following command prevents autotunneling from creating NNHOP backup tunnels:
11
Router# mpls traffic-eng auto-tunnel backup nhop-only
The Type field in the following show ip rsvp fast-reroute command shows that there is only an NHOP
tunnel:
Router# show ip rsvp fast-reroute

------ ------- -------- ------------- ------ ------- ----
R3-PRP_t0 PO3/1 0:G Tu65436:24 Ready any-unl Nhop
The following command changes the minimum and maximum tunnel interface numbers to 1000 and
1100, respectively:
Router# mpls traffic-eng auto-tunnel backup tunnel-num min 1000 max 1100
You can verify the ID numbers and autotunnel backup range ID by entering the show ip rsvp
fast-reroute and show ip interface brief commands. In this example, only one backup tunnel is
protecting the primary tunnel:

------ ------- -------- ------------- ------ ----- ------
R3-PRP_t0 PO3/1 0:G Tu1000:24 Ready any-unl Nhop

The default tunnel range for autotunnel backup tunnels is 65,436 through 65,535. The following show
ip rsvp fast-reroute command changes the tunnel range IDs:

------ ------- -------- ------------- ------ ----- ------
R3-PRP_t0 PO3/1 0:G Tu1001:0 Ready any-unl N-Nhop
The results are shown in the show ip interface brief command:

Router# show ip interface
Interface UP-Address OK? Method Status Protocol
12

The following mpls traffic-eng auto-tunnel backup timers removal unused command specifies that a
timer will scan backup autotunnels every 50 seconds and the timer will remove tunnels that are not being
used:
Router(config)# mpls traffic-eng auto-tunnel backup timers removal unused 50
The following mpls traffic-eng auto-tunnel backup config unnumbered-interface command enables
IP processing on POS interface 3/1:
Router(config)# mpls traffic-eng auto-tunnel backup config unnumbered-interface POS3/1
To verify that IP processing is enabled on POS3/1, enter the show interfaces tunnel command:
Router# show interfaces tunnel 1001
Tunnel1001 is up, line protocol is up

Hardware is Tunnel
Interface is unnumbered. Using address of POS3/1 (10.0.0.33)
MTU 1514 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255
Encapsulation TUNNEL, loopback not set
Keepalive not set
Tunnel source 10.0.0.0, destination 10.0.5.1
Tunnel protocol/transport Label Switching, sequencing disabled
Key disabled
Checksumming of packets disabled
Last input never, output never, output hang never
Last clearing of "show interface" counters never
Queueing strategy: fifo
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 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
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 output buffer failures, 0 output buffers swapped out
Establishing MPLS One-Hop Tunnels to Neighbors: Example

For autotunneling to automatically create primary tunnels to all next hops, you must enter the following
command:
Router(config)# mpls traffic-eng auto-tunnel primary onehop
In this example there are four primary tunnels and no backup tunnels. To verify that configuration, enter
the show ip rsvp fast-reroute command and the show ip interface brief command:
13

------ ------- -------- ------------- ------ ----- ------
R3-PRP_t65339 Gi4/0 0:G None None None

Tunnel0 10.0.3.1 YES unset administratively down down
R3-PRP#
The default tunnel range for primary autotunnels is 65,336 through 65,435. The following
mpls traffic-eng auto-tunnel primary tunnel-num command changes the range to 2000 through 2100:
Router(config)# mpls traffic-eng auto-tunnel primary tunnel-num min 2000 max 2100
The following sample output from the show ip rsvp fast-reroute command and the show ip interface
brief command shows that the tunnel IDs are 2000, 2001, 2002, and 2003:

------ ------- -------- ------------- ------ ----- ------
R3-PRP_t2003 Gi4/0 0:G None None None

14

Tunnel0 10.0.3.1 YES unset administratively down down
Ethernet0 10.3.38.3 ' YES NVRAM up up
The following mpls traffic-eng auto-tunnel primary timers command specifies that a timer will scan
backup autotunnels every 50 seconds and remove tunnels that are not being used:
Router(config)# mpls traffic-eng auto-tunnel primary timers removal rerouted 50
The following mpls traffic-eng auto-tunnel primary config unnumbered command enables IP
processing on POS interface 3/1:
Router(config)# mpls traffic-eng auto-tunnel primary config unnumbered POS3/1
To specify that autotunneling remove all primary autotunnels and re-create them, enter the following
command:
Router(config)# clear mpls traffic-eng auto-tunnel primary
The following sections provide references related to the MPLS Traffic EngineeringAutotunnel
Primary and Backup feature.
Backup tunnels MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast
Tunnel Interface Down Detection)
Link protection MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast
Tunnel Interface Down Detection)
MPLS traffic engineering commands Cisco IOS Multiprotocol Label Switching Command Reference
SSO Cisco IOS High Availability Configuration Guide
Standards
Standard Title
15
MIBs
MIB MIBs Link
RFCs
RFC Title
Description Link
16
Feature Information for MPLS Traffic EngineeringAutotunnel Primary and Backup
Feature Information for MPLS Traffic EngineeringAutotunnel

Primary and Backup
Table 1 Feature Information for MPLS Traffic EngineeringAutotunnel Primary and Backup
Feature Name Releases Feature Configuration Information

MPLS Traffic EngineeringAutotunnel 12.0(27)S The MPLS Traffic EngineeringAutotunnel Primary and
Primary and Backup 12.2(33)SRA Backup feature enables a router to dynamically build
12.2(33)SXH backup tunnels and to dynamically create one-hop primary
12.4(20)T tunnels on all interfaces that have been configured with
12.2(33)SRE MPLS TE tunnels.
In Cisco IOS Release 12.0(27)S, this feature was
introduced.
In Cisco IOS Release 12.2(33)SRA, this feature was
integrated.
In Cisco IOS Release 12.2(33)SXH, support was added.
In Cisco IOS Release 12.4(20)T, this feature was
integrated.
In Cisco IOS Release 12.2(33)SRE. this feature was
integrated. A router with primary one-hop autotunnels and
backup autotunnels can be configured with SSO
redundancy.
17
Glossary
Glossary
backup tunnelAn MPLS traffic engineering tunnel used to protect other (primary) tunnels traffic
when a link or node failure occurs.
egress routerA router at the edge of the network where packets are leaving.
Fast RerouteFast Reroute (FRR) is a mechanism for protecting MPLS traffic engineering (TE) 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.
hopPassage of a data packet between two network nodes (for example, between two routers).
interfaceA network connection.
IP addressA 32-bit address assigned to hosts using TCP/IP. An IP address belongs to one of five
classes (A, B, C, D, or E) and is written as four octets separated by periods (dotted decimal format). Each
address consists of a network number, an optional subnetwork number, and a host number. The network
and subnetwork numbers together are used for routing, and the host number is used to address an
individual host within the network or subnetwork. A subnet mask is used to extract network and
subnetwork information from the IP address.
IP explicit pathA list of IP addresses, each representing a node or link in the explicit path.
LDPLabel Distribution Protocol. A standard protocol between MPLS-enabled routers to negotiate the
labels (addresses) used to forward packets.
linkPoint-to-point connection between adjacent nodes.
LSPlabel switched path. A path that is followed by a labeled packet over several hops, starting at an
ingress LSR and ending at an egress LSR.
LSRlabel switch router. A Layer 3 router that forwards a packet based on the value of a label
MPLSMultiprotocol 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. ATM switches or existing routers
in the network core can switch packets according to the labels with minimal lookup overhead.
nodeEndpoint 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.
penultimate routerThe second-to-last router; that is, the router that is immediately before the egress
router.
primary tunnelAn MPLS tunnel whose LSP can be fast rerouted if there is a failure.
routerA 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.
router IDSomething by which a router originating a packet can be uniquely distinguished from all
other routers. For example, an IP address from one of the routers interfaces.
scalabilityAn indicator showing how quickly some measure of resource usage increases as a network
gets larger.
traffic engineeringThe techniques and processes used to cause routed traffic to travel through the
used.
18
Glossary
tunnelA secure communication path between two peers, such as two routers. A traffic engineering
tunnel is 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.
coincidental.
19
Glossary
20
MPLS Traffic EngineeringAutoTunnel Mesh
Groups

The MPLS Traffic EngineeringAutoTunnel Mesh Groups feature allows a network administrator to
configure traffic engineering (TE) label switched paths (LSPs) by using a few command-line interface
(CLI) commands.
In a network topology where edge TE label switch routers (LSRs) are connected by core LSRs, the
MPLS Traffic EngineeringAutoTunnel Mesh Groups feature automatically constructs a mesh of TE
LSPs among the provider edge (PE) routers.

supported, see the Feature Information for MPLS Traffic EngineeringAutoTunnel Mesh Groups section
on page 18.
Contents
Prerequisites for MPLS Traffic EngineeringAutoTunnel Mesh Groups, page 2
Restrictions for MPLS Traffic EngineeringAutoTunnel Mesh Groups, page 2
Information About MPLS Traffic EngineeringAutoTunnel Mesh Groups, page 2
How to Configure MPLS Traffic EngineeringAutoTunnel Mesh Groups, page 4
Configuration Examples for MPLS Traffic EngineeringAutotunnel Mesh Groups, page 14
MPLS Traffic EngineeringAutoTunnel Mesh Groups
Prerequisites for MPLS Traffic EngineeringAutoTunnel Mesh Groups

Feature Information for MPLS Traffic EngineeringAutoTunnel Mesh Groups, page 18
Glossary, page 19
Prerequisites for MPLS Traffic EngineeringAutoTunnel Mesh

Groups
Be knowledgeable about MPLS TE. See the Additional References section on page 16.
Decide how you will set up autotunnels (that is, identify the tunnel commands that you will include
in the template interface).
Identify a block of addresses that you will reserve for mesh tunnel interfaces.
Restrictions for MPLS Traffic EngineeringAutoTunnel Mesh

Groups
Mesh groups do not support interarea tunnels because the destinations of those tunnels do not exist
in the local area TE database.
You cannot configure a static route to route traffic over autotunnel mesh group TE tunnels. You
should use only the autoroute for tunnel selection.
Intermediate System-to-System (IS-IS) does not support Interior Gateway Protocol (IGP)
distribution of mesh group information. For IS-IS, only Access Control Lists (ACLs) can be used.
Information About MPLS Traffic EngineeringAutoTunnel

Mesh Groups
To configure autotunnel mesh groups, you need to understand the following concepts:
AutoTunnel Mesh Groups Description and Benefits, page 2
Access Lists for Mesh Tunnel Interfaces, page 3
AutoTunnel Template Interfaces, page 3
OSPF Flooding of Mesh Group Information, page 4
AutoTunnel Mesh Groups Description and Benefits

An autotunnel mesh group (referred to as a mesh group) is a set of connections between edge LSRs in a
network. There are two types of mesh groups:
FullAll the edge LSRs are connected. Each PE router has a tunnel to each of the other PE routers.
PartialSome of the edge LSRs are not connected to each other by tunnels.
2
Information About MPLS Traffic EngineeringAutoTunnel Mesh Groups
In a network topology where edge TE LSRs are connected by core LSRs, the MPLS Traffic
EngineeringAutoTunnel Mesh Groups feature automatically constructs a mesh of TE LSPs among the
PE routers.
Initially, you must configure each existing TE LSR to be a member of the mesh by using a minimal set
of configuration commands. When the network grows (that is, when one or more TE LSRs are added to
the network as PE routers), you do not need to reconfigure the existing TE LSR members of that mesh.
Mesh groups have the following benefits:
Minimize the initial configuration of the network. You configure one template interface per mesh,
and it propagates to all mesh tunnel interfaces, as needed.
Minimize future configurations resulting from network growth. The feature eliminates the need to
reconfigure each existing TE LSR to establish a full mesh of TE LSPs whenever a new PE router is
added to the network.
Enable existing routers to configure TE LSPs to new PE routers.
Enable the construction of a mesh of TE LSPs among the PE routers automatically.
Access Lists for Mesh Tunnel Interfaces

The access list determines the destination addresses for the mesh tunnel interfaces. It is useful if you
preallocate a block of related IP addresses. You can use that block of addresses to control the PE routers
to which a full or partial mesh of TE tunnel LSPs is established. The access list allows matches for only
the addresses that are learned and stored in the TE topology database.
For example, you can create an access list that matches all 10.1.1.1 IP addresses. You configure a
template with the access list, then the template creates mesh tunnel interfaces to destinations within the
TE topology database that match destinations in that access list.
Whenever the TE topology database is updated (for example, when a new TE LSR is inserted into the
Interior Gateway Protocol (IGP), the destination address is stored in the TE topology database of each
router in the IGP. At each update, the Mesh Group feature compares the destination address contained
in the database to IP addresses in the access list associated with all template interfaces. If there is a
match, the Mesh Group feature establishes a mesh tunnel interface to the tunnel destination IP address.
AutoTunnel Template Interfaces

An autotunnel template interface is a logical entity; that is, it is a configuration for a tunnel interface that
is not tied to specific tunnel interfaces. It can be applied dynamically, when needed.
Mesh tunnel interfaces are tunnel interfaces that are created, configured dynamically (for example, by
the applying [or cloning] of a template interface), used, and then freed when they are no longer needed.
A mesh tunnel interface obtains its configuration information from a template, except for the tunnels
destination address, which it obtains from the TE topology database that matches an access list or from
the IGP mesh group advertisement.
The template interface allows you to enter commands once per mesh group. These commands specify
how mesh tunnel interfaces are created. Each time a new router is added to the network, a new mesh
tunnel interface is created. The configuration of the interface is duplicated from the template. Each mesh
tunnel interface has the same path constraints and other parameters configured on the template interface.
Only the tunnel destination address is different.
3
How to Configure MPLS Traffic EngineeringAutoTunnel Mesh Groups
OSPF Flooding of Mesh Group Information

For OSPF to advertise or flood mesh group information, you need to configure a mesh group in OSPF
and add that mesh group to an autotemplate interface. When the configuration is complete, OSPF
advertises the mesh group IDs to all LSRs. MPLS TE LSPs automatically connect the edge LSRs in each
mesh group. For configuration information, see the Configuring IGP Flooding for Autotunnel Mesh
Groups section on page 13.
OSPF can advertise mesh group IDs for an OSPF area. OSPF is the only IGP supported in the Cisco IOS
12.0(29)S, 12.2(33)SRA, 12.2(33)SXH, and 12.4(20)T releases of the MPLS Traffic
EngineeringAutoTunnel Mesh Groups feature.
How to Configure MPLS Traffic EngineeringAutoTunnel Mesh

Groups
Configuring a Mesh of TE Tunnel LSPs, page 4 (required)
Specifying the Range of Mesh Tunnel Interface Numbers, page 9 (optional)
Displaying Configuration Information About Tunnels, page 10 (optional)
Monitoring the Autotunnel Mesh Network, page 11 (required)
Configuring IGP Flooding for Autotunnel Mesh Groups, page 13 (optional)
Configuring a Mesh of TE Tunnel LSPs

Perform the following tasks on each PE router in your network to configure a mesh of TE tunnel LSPs:
Enabling Autotunnel Mesh Groups Globally, page 4
Creating an Access List Using a Name, page 5
Creating an Autotunnel Template Interface, page 7
Note You can perform these tasks in any order.
Enabling Autotunnel Mesh Groups Globally

Perform the following task to enable autotunnel mesh groups globally. Perform this task on all PE routers
in your network that you want to be part of an autotunnel mesh group.
SUMMARY STEPS
1. enable
3. mpls traffic-eng auto-tunnel mesh
4. end
4
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng auto-tunnel mesh Enables autotunnel mesh groups globally.
Example:
mesh
Example:
Router(config)# end
Creating an Access List Using a Name

Perform the following task to create an access list using a name.
The access list determines the destination addresses for the mesh tunnel interfaces. You can use an access
list to control the PE routers to which a full or partial mesh of TE tunnel LSPs is established. The access
list allows matches for only the addresses that are learned and stored in the TE topology database.
SUMMARY STEPS
1. enable
3. ip access-list {standard | extended} access-list-name
4. permit source [source-wildcard]
5. end
DETAILED STEPS

Example:
Router> enable
5

Example:
Step 3 ip access-list {standard | extended} Defines an IP access list using a name and enters standard
access-list-name named access list configuration mode.
The standard keyword specifies a standard IP access
Example: list.
Router(config)# ip access-list standard a1
The extended keyword specifies an extended IP access
list.
The access-list-name argument is the name of the
access list. A name cannot contain a space or quotation
mark and must begin with an alphabetic character. This
prevents confusion with numbered access lists.
Step 4 permit source [source-wildcard] Sets conditions to allow a packet to pass a named IP access
list.
Example: The source argument is the number of the network or
Router(config-std-nacl)# permit 10.0.0.0 host from which the packet is being sent. There are
0.255.255.255 three alternative ways to specify the source:
Use a 32-bit quantity in four-part dotted decimal
format.
Use the any keyword as an abbreviation for a
source and source-wildcard of 0.0.0.0
255.255.255.255.
Use host source as an abbreviation for a source and
source-wildcard of source 0.0.0.0.
The source-wildcard argument is the wildcard bits to
be applied to source. There are three alternative ways
to specify the source wildcard:
Use a 32-bit quantity in four-part dotted decimal
format. Place 1s in the bit positions you want to
ignore.
Use the any keyword as an abbreviation for a
source and source-wildcard of 0.0.0.0
255.255.255.255.
Use host source as an abbreviation for a source and
source-wildcard of source 0.0.0.0.
Example:
Router(config-std-nacl)# end
6
Creating an Autotunnel Template Interface

Perform the following task to create an autotunnel template interface. This helps minimize the initial
configuration of the network. You configure one template interface per mesh, and it propagates to all
mesh tunnel interfaces, as needed.
Note You can use the following commands to create a minimal configuration.
SUMMARY STEPS
1. enable
3. interface auto-template interface-num
4. ip unnumbered interface-type interface-number
5. tunnel mode {aurp | cayman | dvmrp | eon | gre | ipip | iptalk | mpls | nos}
8. tunnel mpls traffic-eng auto-bw [collect-bw] [frequency seconds] [max-bw kbps] [min-bw kbps]
path-number}} [lockdown]
10. tunnel destination access-list num
11. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface auto-template interface-num Creates a template interface and enters interface
configuration mode.
Example: The interface-num argument is the interface number.
Router(config)# interface auto-template 1 Valid values are from 1 to 25.
Step 4 ip unnumbered interface-type interface-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 Loopback 0 number of another interface on which the router has an
assigned IP address. It cannot be another unnumbered
interface.
7

Step 5 tunnel mode {aurp | cayman | dvmrp | eon | gre Sets the encapsulation mode for the tunnel interface.
| ipip | iptalk | mpls | nos}
Example:
Router(config-if)# tunnel mode mpls
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 algorithm (SPF)
calculation.
Example:
autoroute announce
Step 7 tunnel mpls traffic-eng priority setup-priority Configures the setup and reservation priority for an MPLS
[hold-priority] TE tunnel.
Example: an LSP is signaled for this tunnel and determines which
Router(config-if)# tunnel mpls traffic-eng existing tunnels can be preempted. Valid values are
priority 1 1
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.
with an LSP for this tunnel and determines if it should
be preempted by other LSPs that are being signaled.
Step 8 tunnel mpls traffic-eng auto-bw [collect-bw] Configures a tunnel for automatic bandwidth adjustment
[frequency seconds] [max-bw kbps] [min-bw kbps] and for control of the manner in which the bandwidth for a
tunnel is adjusted.
Example: The collect-bw keyword collects output rate
Router(config-if)# tunnel mpls traffic-eng information for the tunnel, but does not adjust the
auto-bw
tunnels bandwidth.
The frequency seconds keyword-argument pair is the
interval between bandwidth adjustments. The specified
interval can be from 300 to 604800 seconds. Do not
specify a value lower than the output rate sampling
interval specified in the mpls traffic-eng auto-bw
command in global configuration mode.
The max-bw kbps keyword-argument pair is the
maximum automatic bandwidth, in kbps, for this
tunnel. The value can be from 0 to 4294967295.
The min-bw kbps keyword-argument pair is the
minimum automatic bandwidth, in kbps, for this
tunnel. The value can be from 0 to 4294967295.
8

Step 9 tunnel mpls traffic-eng path-option number Configures a path option for an MPLS TE tunnel.
{dynamic | explicit {name path-name |
path-number}} [lockdown] The number argument is the number of the path option.
When multiple path options are configured, lower
numbered options are preferred.
Example:
Router(config-if)# tunnel mpls traffic-eng The dynamic keyword specifies that the path of the
path-option 1 dynamic LSP is dynamically calculated.
The explicit keyword specifies that the path of the LSP
is an IP explicit path.
The name path-name keyword-argument pair is the
path name of the IP explicit path that the tunnel uses
with this option.
The path-number argument is the path number of the IP
explicit path that the tunnel uses with this option.
The lockdown keyword specifies that the LSP cannot
be reoptimized.
Step 10 tunnel destination access-list num Specifies the access list that the template interface uses for
obtaining the mesh tunnel interface destination address.
Example: The num argument is the number of the access list.
access-list 1
Example:
Router(config)# end
Specifying the Range of Mesh Tunnel Interface Numbers

Perform the following task to specify the range of mesh tunnel interface numbers.
SUMMARY STEPS
1. enable
3. mpls traffic-eng auto-tunnel mesh tunnel-num min num max num
4. end
9
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng auto-tunnel mesh tunnel-num Specifies the range of mesh tunnel interface numbers.
min num max num
The min num keyword-argument pair specifies the
beginning number of the range of mesh tunnel interface
Example: numbers. Valid values are from 1 to 65535.
mesh tunnel-num min 1000 max 2000 The max num keyword-argument pair specifies the
ending number of the range of mesh tunnel interface
numbers. Valid values are from 1 to 65535.
Example:
Router(config)# end
Displaying Configuration Information About Tunnels

Perform the following task to display tunnel configuration information, such as tunnel interface and
mesh tunnel configuration.
SUMMARY STEPS
1. enable
2. show running interface auto-template num
3. show interface tunnel num configuration
4. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show running interface auto-template num

Use this command to display interface configuration information for a tunnel interface. For example:
Router# show running interface auto-template 1
10
interface auto-template1
no keepalive
tunnel destination access-list 1
tunnel mpls traffic-eng path-option 1 dynamic
This output shows that autotunnel template interface auto-template1 uses an access list (access-list 1) to
determine the destination addresses for the mesh tunnel interfaces.
Step 3 show interface tunnel num configuration
Use this command to display the configuration of the mesh tunnel interface. For example:
Router# show interface tunnel 5 configuration
interface tunnel 5
no keepalive
tunnel destination access-list 1
Step 4 exit
Router# exit
Router>
Monitoring the Autotunnel Mesh Network

Perform the following task to monitor the autotunnel mesh network.
SUMMARY STEPS
1. enable
2. show mpls traffic-eng tunnels property auto-tunnel mesh [brief]
3. show mpls traffic-eng auto-tunnel mesh
4. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show mpls traffic-eng tunnels property auto-tunnel mesh [brief]
11
Use this command to monitor mesh tunnel interfaces. This command restricts the output of the show
mpls traffic-eng tunnels command to display only mesh tunnel interfaces. For example:
Router# show mpls traffic-eng tunnels property auto-tunnel mesh brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
Periodic reoptimization: every 3600 seconds, next in 491 seconds
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: disabled
TUNNEL NAME DESTINATION UP IF DOWN IF
STATE/PROT
router_t64336 10.2.2.2 - Se2/0
up/up
router_t64337 10.3.3.3 - Se2/0
up/up
Displayed 2 (of 2) heads, 0 (of 0) midpoints, 0 (of 0) tails
Step 3 show mpls traffic-eng auto-tunnel mesh

Use this command to display the cloned mesh tunnel interfaces of each autotemplate interface and the
current range of mesh tunnel interface numbers. For example:
Router# show mpls traffic-eng auto-tunnel mesh
Auto-Template1:
Using access-list 1 to clone the following tunnel interfaces:
Destination Interface
----------- ---------
10.2.2.2 Tunnel64336
10.3.3.3 Tunnel64337
Mesh tunnel interface numbers: min 64336 max 65337
Step 4 exit
Router# exit
Router>
You can configure mesh tunnel interfaces directly. However, you cannot delete them manually, and
manual configuration is not permanent. The configuration is overwritten when the template changes or
the mesh tunnel interface is deleted and re-created. If you attempt to manually delete a mesh tunnel
interface, an error message appears.
You can enter the show mpls traffic-eng tunnels destination address command to display information
about tunnels that are destined for a specified IP address.
Enter the show mpls traffic-eng tunnels property auto-tunnel mesh command to display information
about mesh tunnel interfaces.
12
Configuring IGP Flooding for Autotunnel Mesh Groups

Perform the following task to configure IGP flooding for autotunnel mesh groups. Use this task to
configure an OSPF-based discovery for identifying mesh group members and advertising the mesh group
IDs to all LSRs.
SUMMARY STEPS
1. enable
3. mpls traffic-eng auto-tunnel mesh
5. mpls traffic-eng mesh-group mesh-group-id interface-type interface-number area area-id
6. exit
7. Repeat steps 4 and 5 at other LSRs to advertise the mesh group numbers to which they belong.
8. interface auto-template interface-num
9. tunnel destination mesh-group mesh-group-id
10. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng auto-tunnel mesh Enables autotunnel mesh groups globally.
Example:
mesh
13
Configuration Examples for MPLS Traffic EngineeringAutotunnel Mesh Groups

Step 4 router ospf process-id Enters router configuration mode and configures an OSPF
routing process.
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. A
unique value is assigned for each OSPF routing
process.
Step 5 mpls traffic-eng mesh-group mesh-group-id Advertises the autotunnel mesh group number of an LSR.
interface-type interface-number area area-id
The mesh-group-id is a number that identifies a specific
mesh group.
Example:
Router(config-router)# mpls traffic-eng
The interface-type and interface-number arguments
mesh-group 10 loopback 0 area 100 specify a type of interface and an interface number.
The area area-id keyword-argument pair identifies the
area.
Step 6 exit Exits to global configuration mode.
Example:
Step 7 Repeat steps 4 and 5 at other LSRs to advertise the
mesh group numbers to which they belong.
Step 8 interface auto-template interface-num Creates a template interface and enters interface
configuration mode.
Example: The interface-num argument identifies the interface
Router(config)# interface auto-template 1 number. Valid values are from 1 to 25.
Step 9 tunnel destination mesh-group mesh-group-id Specifies a mesh group that a template interface uses to
signal tunnels for all mesh group members.
Example: The mesh-group-id is a number that identifies a specific
Router(config-if)# tunnel destination mesh group.
mesh-group 10
Example:
Configuration Examples for MPLS Traffic

EngineeringAutotunnel Mesh Groups
Configuring a Mesh of TE Tunnel LSPs: Examples, page 15
Specifying the Range of Mesh Tunnel Interface Numbers: Example, page 16
Configuring IGP Flooding for Autotunnel Mesh Groups: Example, page 16
14
Configuration Examples for MPLS Traffic EngineeringAutotunnel Mesh Groups
Configuring a Mesh of TE Tunnel LSPs: Examples

This section contains the following configuration examples for configuring a mesh of TE tunnel LSP:
Enabling Autotunnel Mesh Groups Globally: Example, page 15
Creating an Access List Using a Name: Example, page 15
Creating an AutoTunnel Template Interface: Example, page 15
Enabling Autotunnel Mesh Groups Globally: Example

The following example shows how to enable autotunnel mesh groups globally:
configure terminal
!
mpls traffic-eng auto-tunnel mesh

end
Creating an Access List Using a Name: Example

The following examples shows how to create an access list using a name to determine the destination
addresses for the mesh tunnel interfaces:
configure terminal
!
ip access-list standard a1
permit 10.0.0.0 0.255.255.255
end
In this example, any IP address in the TE topology database that matches access list a1 causes the
creation of a mesh tunnel interface with that destination address.
Creating an AutoTunnel Template Interface: Example

This example shows how to create an AutoTunnel template template interface. In the following example,
an AutoTunnel template is created and configured with a typical set of TE commands. The mesh group
created from the template consists of mesh tunnel interfaces with destination addresses that match access
list a1.
Note The following example shows a typical configuration.
15
configure terminal
!
interface auto-template 1
tunnel mode mpls
tunnel mpls traffic-eng auto-bw
tunnel destination access-list a1
end
Specifying the Range of Mesh Tunnel Interface Numbers: Example

In the following example, the lowest mesh tunnel interface number can be 1000, and the highest mesh
tunnel interface number can be 2000:
configure terminal
!
mpls traffic-eng auto-tunnel mesh tunnel-num min 1000 max 2000
end
Configuring IGP Flooding for Autotunnel Mesh Groups: Example

In the following example, OSPF is configured to advertise the router membership in mesh group 10:
configure terminal
!
mpls traffic-eng auto-tunnel mesh
router ospf 100
mpls traffic-eng mesh-group 10 loopback 0 area 100
exit
!
interface auto-template 1
tunnel destination mesh-group 10
end
The following sections provide references related to the MPLS Traffic EngineeringAutoTunnel Mesh
Groups feature.
Related Documents
MPLS traffic engineering command descriptions Cisco IOS Multiprotocol Label Switching Command Reference
16
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
Description Link
17
Feature Information for MPLS Traffic EngineeringAutoTunnel Mesh Groups
Feature Information for MPLS Traffic EngineeringAutoTunnel

Mesh Groups
Table 1 Feature Information for MPLS Traffic EngineeringAutoTunnel Mesh Groups

MPLS Traffic EngineeringAutoTunnel Mesh 12.0(27)S The MPLS Traffic EngineeringAutoTunnel Mesh Groups
Groups 12.0(29)S feature allows a network administrator to configure TE
12.2(33)SRA LSPs.
12.2(33)SXH
12.4(20)T
introduced.
12.2(33)SRE
In Cisco IOS Release 12.0(29)S, this feature was updated to
include Interior Gateway Protocol (IGP) flooding of
autotunnel mesh groups.
In Cisco IOS Release 12.2(33)SRA, this feature was
integrated.
In Cisco IOS Release 12.2(33)SXH, support was added.
In Cisco IOS Release 12.4(20)T, this feature was integrated.
In Cisco IOS Release 12.2(33)SRE, this feature was
integrated. A router with autotunnel mesh groups can be
configured with stateful switchover (SSO) redundancy.
18
Glossary
Glossary
CE routercustomer edge router. A router that is part of a customers network and interfaces to a
customer networkA network that is under the control of an end customer. Private addresses can be
used in a customer network. Customer networks are logically isolated from each other and from the
service providers network.
edge routerA router at the edge of the network that receives and transmits packets. It can define the
boundaries of the Multiprotocol Label Switching (MPLS) network.
headendThe label switch router (LSR) where a tunnel originates. The tunnel's head or tunnel
interface resides at this LSR as well.
labelA short, fixed-length data construct that tells switching nodes how to forward data (packets).
label switched path (LSP) tunnelA configured connection between two routers in which label
switching is used to carry the packets.
LSPlabel switched path. A path that a labeled packet follows over several hops, starting at an ingress
LSR and ending at an egress LSR.
mesh groupA set of label switch routers (LSRs) that are members of a full or partial network of traffic
engineering (TE) label switched paths (LSPs).
P routerprovider core router.
PE routerprovider edge router. A router at the edge of the service providers network that interfaces
to customer edge (CE) routers.
tailendThe downstream, receive end of a tunnel.
used.
tunnel is a label switched tunnel that is used for traffic engineering. Such a tunnel is set up through means
other than normal Layer 3 routing.
19
Glossary
coincidental.
20
MPLS Traffic EngineeringVerbatim Path
Support

The MPLS Traffic EngineeringVerbatim 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.

supported, see the Feature Information for MPLS Traffic EngineeringVerbatim Path Support section on
page 9.
Contents
Prerequisites for MPLS Traffic EngineeringVerbatim Path Support, page 2
Restrictions for MPLS Traffic EngineeringVerbatim Path Support, page 2
Information About MPLS Traffic EngineeringVerbatim Path Support, page 2
How to Configure and Verify MPLS Traffic EngineeringVerbatim Path Support, page 2
Configuration Example for MPLS Traffic EngineeringVerbatim Path Support, page 7
MPLS Traffic EngineeringVerbatim Path Support
Prerequisites for MPLS Traffic EngineeringVerbatim Path Support

Glossary, page 10
Prerequisites for MPLS Traffic EngineeringVerbatim Path

Support
An MPLS TE tunnel must be configured globally.
MPLS TE must be enabled on all links.
Restrictions for MPLS Traffic EngineeringVerbatim 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.
You cannot configure MPLS Traffic Engineering over the logical GRE tunnel interface.
Information About MPLS Traffic EngineeringVerbatim Path

Support
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

EngineeringVerbatim Path Support
Configuring MPLS Traffic EngineeringVerbatim Path Support, page 3 (required)
Verifying Verbatim LSPs for MPLS TE Tunnels, page 6 (optional)

2
How to Configure and Verify MPLS Traffic EngineeringVerbatim Path Support
Configuring MPLS Traffic EngineeringVerbatim Path Support

Perform this task to configure MPLS traffic engineeringverbatim path support.
SUMMARY STEPS
1. enable
3. interface tunnel number
4. ip unnumbered loopback number
5. tunnel destination {host-name | ip-address}
7. tunnel mpls traffic-eng bandwidth {sub-pool kbps | kbps}
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}}
- or -
tunnel mpls traffic-eng path-option protect preference-number {dynamic [attributes string |
bandwidth {sub-pool kbps | kbps}] | explicit {name path-name | identifier path-number} [
attributes string | bandwidth {sub-pool kbps | kbps} | verbatim]}
11. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel number Enters interface configuration mode.
The number argument identifies the tunnel number to
Example: be configured.
Router(config)# interface tunnel 1
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.
Step 6 tunnel mode mpls traffic-eng Sets the tunnel encapsulation mode to MPLS traffic
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]
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.
with an LSP for this tunnel to determine if it should be
preempted by other LSPs that are being signaled.

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
- or -
option.
tunnel mpls traffic-eng path-option protect
preference-number {dynamic [attributes string | The protect keyword and preference-number argument
bandwidth {sub-pool kbps | kbps}] | explicit identify the path option with protection.
{name path-name | identifier path-number}
[attributes string | bandwidth {sub-pool kbps | The dynamic keyword indicates that the path option is
kbps} | verbatim]} dynamically calculated. (The router figures out the best
path.)
Example: The explicit keyword indicates that the path option is
Router(config-if)# tunnel mpls traffic-eng specified. The IP addresses are specified for the path.
path-option 1 explicit name test verbatim
Router(config-if)# tunnel mpls traffic-eng identifies the name of the explicit path option.
path-option protect 2 dynamic name test 2
bandwidth sub-pool 34 The path-number argument identifies the number of the
verification.

LSP.
The bandwidth keyword specifies the LSP bandwidth.
4294967295.
LSP.
Example:
Router(config)# end

5
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
Examples
In the following example, the show mpls traffic-eng tunnels command displays tunnel information,
including whether the explicit path option is using verbatim and the Active Path Options Parameters that
show the status of verbatim.
Name: GSR-2_t100 (Tunnel100) Destination: 192.168.30.1

Status:
path option 1, type explicit (verbatim) BACKUP (Basis for Setup, path weight 0)
Config Parameters:
Metric Type: TE (default)
AutoRoute: disabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
BandwidthOverride: disabled LockDown: disabled Verbatim: enabled

6
Configuration Example for MPLS Traffic EngineeringVerbatim Path Support
Configuration Example for MPLS Traffic EngineeringVerbatim

Path Support
This section provides the following configuration example:
Configuring MPLS Traffic EngineeringVerbatim Path Support, page 7
Configuring MPLS Traffic EngineeringVerbatim Path Support

The following example shows a tunnel that has been configured with an explicit path option using
verbatim:
interface tunnel 1
ip unnumbered loopback 1
tunnel mpls traffic-eng path-option 1 explicit name path1 verbatim
The following sections provide references related to the MPLS Traffic EngineeringVerbatim Path
feature.
Related Documents
MPLS Label Distribution Protocol MPLS Label Distribution Protocol (LDP) feature module
Standards
Standard Title
MIBs
MIB MIBs Link

7
Command Reference
RFCs
RFC Title
release.
Description Link
Command Reference
tunnel mpls traffic-eng path option

8
Feature Information for MPLS Traffic EngineeringVerbatim Path Support
Feature Information for MPLS Traffic EngineeringVerbatim

Path Support
Table 1 Feature Information for MPLS Traffic EngineeringVerbatim Path Support

MPLS Traffic EngineeringVerbatim Path 12.0(26)S The MPLS Traffic EngineeringVerbatim Path Support
Support 12.2(33)SRA feature allows network nodes to support Resource
12.2(33)SXH Reservation Protocol (RSVP) extensions without
12.4(20)T supporting Interior Gateway Protocol (IGP) extensions for
traffic engineering (TE), thereby bypassing the topology
database verification process.
Release 12.2(33)SRA.
Release 12.2(33)SXH.
Release 12.4(20)T.
show mpls traffic-eng tunnels, tunnel mpls traffic-eng
path option.

9
Glossary
Glossary
Fast RerouteProcedures that enable temporary routing around a failed link or node while a new LSP
is being established at the head end.
headendThe router that originates and maintains a given LSP. This is the first router in the LSPs path.
IGPInterior Gateway Protocol. Internet protocol used to exchange routing information within an
autonomous system. Examples of common Internet IGPs include IGRP, OSPF, and RIP.
LSPlabel-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.
LSRlabel switching router. A device that forwards MPLS packets based on the value of a fixed-length
label encapsulated in each packet.
merge pointThe backup tunnels tail.
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.
PLRpoint of local repair. The head-end of the backup tunnel.
RSVPResource 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
(bandwidth, jitter, maximum burst, and so on) of the packet streams they want to receive.
SPFshortest 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 Dijkstras algorithm.
tailendThe router upon which an LSP is terminated. This is the last router in the LSPs path.
used.
tunnelA secure communications path between two peers, such as routers.
countries.
coincidental.
2003, 2006, 2008 Cisco Systems, Inc. All rights reserved.

10
MPLS Traffic EngineeringRSVP Hello State
Timer

The MPLS Traffic EngineeringRSVP 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).
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.

supported, see the Feature Information for MPLS Traffic EngineeringRSVP Hello State Timer section
on page 13.
Contents
Prerequisites for MPLS Traffic EngineeringRSVP Hello State Timer, page 2
Restrictions for MPLS Traffic EngineeringRSVP Hello State Timer, page 2
Information About MPLS Traffic EngineeringRSVP Hello State Timer, page 2
How to Configure MPLS Traffic EngineeringRSVP Hello State Timer, page 5
Configuration Examples for MPLS Traffic EngineeringRSVP Hello State Timer, page 10
MPLS Traffic EngineeringRSVP Hello State Timer
Prerequisites for MPLS Traffic EngineeringRSVP Hello State Timer

Prerequisites for MPLS Traffic EngineeringRSVP Hello State

Timer
Perform the following tasks on routers before configuring the MPLS Traffic EngineeringRSVP 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 EngineeringRSVP 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 EngineeringRSVP Hello State

Timer
You should understand the following concepts before configuring the MPLS TERSVP Hello State
Timer feature:
Hellos for State Timeout, page 2
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.
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
nodes resources to be reused by other LSPs.
Hellos must be configured both globally on the router and on the specific interface to be operational.

2
Information About MPLS Traffic EngineeringRSVP Hello State Timer
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.
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.
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.

3
Information About MPLS Traffic EngineeringRSVP Hello State Timer
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.
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.
Figure 3 Fast Reroutable TE LSP Without Backup Tunnel

117936
Router 1 Router 2 Router 3

PLR Merge Point

4
How to Configure MPLS Traffic EngineeringRSVP Hello State Timer
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 EngineeringRSVP 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 number Enters interface configuration mode.
The type number arguments identify the interface to be
Example: configured.
Router(config)# interface Ethernet 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:

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:
The type number argument identifies the interface to be

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:

9
Configuration Examples for MPLS Traffic EngineeringRSVP 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 EngineeringRSVP

Hello State Timer
This section provides a configuration example for the MPLS TERSVP Hello State Timer feature:
MPLS Traffic EngineeringRSVP Hello State Timer: Example, page 10
MPLS Traffic EngineeringRSVP 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)# ip rsvp signalling hello
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 EngineeringRSVP 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
examples
QoS features including signaling, classification, and Cisco IOS Quality of Service Solutions Configuration Guide
congestion management
Stateful Switchover Cisco IOS High Availability Configuration Guide
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
Command Reference
MIBs
MIB MIBs Link
No new or modified MIBS are supported by this To locate and download MIBs for selected platforms, Cisco IOS
RFCs
RFC Title
RFC 3209 RSVP-TE: Extensions to RSVP for LSP Tunnels
Description Link
Command Reference
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

12
Feature Information for MPLS Traffic EngineeringRSVP Hello State Timer
show ip rsvp hello
Feature Information for MPLS Traffic EngineeringRSVP Hello

State Timer
Table 1 Feature Information for MPLS Traffic EngineeringRSVP Hello State Timer

MPLS Traffic EngineeringRSVP Hello 12.0(29)S The MPLS Traffic EngineeringRSVP Hello State Timer
State Timer 12.2(33)SRA feature detects when a neighbor is down and quickly
12.2(33)SXH triggers a state timeout, which frees resources such as
12.4(20)T bandwidth that can be reused by other label switched paths
(LSPs).
Release 12.4(20)T.

13
Glossary
Glossary
autonomous systemA collection of networks that share the same routing protocol and that are under
the same system administration.
ASBRautonomous system boundary router. A router that connects and exchanges information
between two or more autonomous systems.
backup tunnelAn MPLS traffic engineering tunnel used to protect other (primary) tunnel traffic when
a link or node failure occurs.
DSCPdifferentiated services code point. Six bits in the IP header, as defined by the IETF. These bits
determine the class of service provided to the IP packet.
Fast RerouteA mechanism for protecting MPLS traffic engineering (TE) 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 restartA process for helping a neighboring Route Processor restart after a node failure has
occurred.
autonomous system. Examples of common Internet IGPs include IGRP, OSPF, and RIP.
IS-ISIntermediate System-to-Intermediate System. OSI link-state hierarchical routing protocol
whereby Intermediate System (IS) routers exchange routing information based on a single metric to
determine network topology.
instanceA 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.
labelA short, fixed-length data identifier that tells switching nodes how to forward data (packets or
cells).
LDPLabel Distribution Protocol. The protocol that supports 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).
LSPlabel switched path is a configured connection between two routers, in which 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.
OSPFOpen Shortest Path First. A link-state routing protocol used for routing.
PLRpoint of local repair. The headend of the backup tunnel.
RSVPResource 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
(bandwidth, jitter, maximum burst, and so on) of the packet streams they want to receive.

14
Glossary
stateInformation that a router must maintain about each LSP. The information is used for rerouting
tunnels.
used.
topologyThe physical arrangement of network nodes and media within an enterprise networking
structure.
tunnelSecure communications path between two peers, such as two routers.
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.

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 6
Prerequisites for MPLS Traffic Engineering Forwarding Adjacency
Feature Information for MPLS Traffic Engineering Forwarding Adjacency, page 11

Glossary, page 12
Prerequisites for MPLS Traffic Engineering Forwarding

Adjacency
Your network must support the following Cisco IOS 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.
You cannot configure MPLS Traffic Engineering over the logical GRE tunnel interface.
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 links 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
This section contains the following tasks:
Configuring a Tunnel Interface for MPLS TE Forwarding Adjacency, page 3 (required)
Configuring MPLS TE Forwarding Adjacency on Tunnels, page 4 (required)
Verifying MPLS TE Forwarding Adjacency, page 5 (optional)
Configuring a Tunnel Interface for MPLS TE Forwarding Adjacency

To configure a tunnel interface for an MPLS TE forwarding adjacency, perform the following steps.
3
SUMMARY STEPS
1. enable
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:
Configuring MPLS TE Forwarding Adjacency on Tunnels

To configure an MPLS TE forwarding adjacency, perform the following steps.
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.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng forwarding-adjacency [holdtime value]
5. isis metric {metric-value | maximum} {level-1 | level-2}
4
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel number Designates a tunnel interface for the forwarding adjacency, and
Example:
Step 4 tunnel mpls traffic-eng Advertises a TE tunnel as a link in an IGP network.
forwarding-adjacency [holdtime value]
Example:
Router(config-if)# tunnel mpls
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.
Verifying MPLS TE Forwarding Adjacency

To verify MPLS TE forwarding adjacency on tunnels, perform the following steps.
SUMMARY STEPS
1. show mpls traffic-eng forwarding-adjacency [ip-address]

2. show isis [process-tag] database [level-1] [level-2] [l1] [l2] [detail] [lspid]
DETAILED STEPS
Step 1 show mpls traffic-eng forwarding-adjacency [ip-address]

Use this command to see the current tunnels.
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)
5
Configuration Examples for MPLS Traffic Engineering Forwarding Adjacency
Router# show mpls traffic-eng forwarding-adjacency 192.168.1.7

(flags:Announce Forward-Adjacency, holdtime 0)
Step 2 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.
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
Configuration Examples for MPLS Traffic Engineering

Forwarding Adjacency
This section provides the following configuration example for the MPLS Traffic Engineering
Forwarding Adjacency feature using an IS-IS metric: MPLS Traffic Engineering Forwarding Adjacency
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
6
Configuration Examples for MPLS Traffic Engineering Forwarding Adjacency
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:
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.)
7
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
Switching services commands Cisco IOS IP Switching Command Reference
IS-IS TLVs Intermediate System-to-Intermediate System (IS-IS) TLVs (white
paper)
8
Standards
Standard Title
MIBs
MIB MIBs Link
feature, and support for existing standards has not been releases, and feature sets, use Cisco MIB Locator found at the
RFCs
RFC Title
Description Link
9
Command Reference
Command Reference
debug mpls traffic-eng forwarding-adjacency
show mpls traffic-eng forwarding-adjacency
tunnel mpls traffic-eng forwarding-adjacency
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 12.0(15)S The MPLS Traffic Engineering Forwarding Adjacency
Adjacency 12.0(16)ST feature allows a network administrator to handle a TE LSP
12.2(18)S tunnel as a link in an IGP network based on the SPF
12.2(18)SXD algorithm.
12.2(27)SBC
12.2(28)SB
12.4(20)T In 12.0(16)ST, this feature was integrated.
In 12.2(18)S, this feature was integrated.
In 12.2(18)SXD, this feature was integrated.
In 12.2(27)SBC, this feature was integrated.
In 12.2(28)SB, this feature was integrated.
In 12.4(20)T, this feature was integrated. 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 ForwardingA scalable, distributed, Layer 3 switching solution designed to meet the
future performance requirements of the Internet and enterprise networks.
forwarding adjacencyA 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-ISIntermediate 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
routing mechanisms, or through configuration.
label instructs the routers and the switches in the network where to forward the packets based on
preestablished IP routing information.
OSPFOpen 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.
SPFShortest 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.
TLVtype, length, value. A block of information embedded in Cisco Discovery Protocol
advertisements.
applied.
traffic engineering tunnelA 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 would cause the tunnel to take.
countries.
12
Glossary
coincidental.
13
Glossary
14
MPLS Traffic Engineering : Class-based Tunnel
Selection

The MPLS Traffic Engineering (TE): Class-based Tunnel Selection feature enables you to dynamically
route and forward traffic with different class of service (CoS) values onto different TE tunnels between
the same tunnel headend and the same tailend. The TE tunnels can be regular TE or DiffServ-aware TE
(DS-TE) tunnels.
The set of TE (or DS-TE) tunnels from the same headend to the same tailend that you configure to carry
different CoS values is referred to as a tunnel bundle. After configuration, Class-Based Tunnel
Selection (CBTS) dynamically routes and forwards each packet into the tunnel that:
Is configured to carry the CoS of the packet
Has the right headend for the destination of the packet
Because CBTS offers dynamic routing over DS-TE tunnels and requires minimum configuration, it
greatly eases deployment of DS-TE in large-scale networks.
CBTS can distribute all CoS values on eight different tunnels.
CBTS also allows the TE tunnels of a tunnel bundle to exit headend routers through different interfaces.

feature is supported, use the Feature Information for MPLS Traffic Engineering : Class-based Tunnel
Selection section on page 30.

MPLS Traffic Engineering : Class-based Tunnel Selection
Contents
Contents
Prerequisites for MPLS Traffic Engineering : Class-based Tunnel Selection, page 2
Restrictions for MPLS Traffic Engineering : Class-based Tunnel Selection, page 2
Information About MPLS Traffic Engineering : Class-based Tunnel Selection, page 2
How to Configure MPLS Traffic Engineering : Class-based Tunnel Selection, page 10
Configuration Examples for MPLS Traffic Engineering : Class-based Tunnel Selection, page 19
Feature Information for MPLS Traffic Engineering : Class-based Tunnel Selection, page 30
Glossary, page 31
Prerequisites for MPLS Traffic Engineering : Class-based

Tunnel Selection
Multiprotocol Label Switching (MPLS) must be enabled on all tunnel interfaces.
Cisco Express Forwarding or distributed Cisco Express Forwarding must be enabled in global
configuration mode.
Restrictions for MPLS Traffic Engineering : Class-based Tunnel

Selection
For a given destination, all CoS values are carried in tunnels terminating at the same tailend. Either
all CoS values are carried in tunnels or no values are carried in tunnels. In other words, for a given
destination, you cannot map some CoS values in a DS-TE tunnel and other CoS values in a Shortest
Path First (SPF) Label Distribution Protocol (LDP) or SPF IP path.
CBTS does not allow load-balancing of a given experimental (EXP) value in multiple tunnels. If two
or more tunnels are configured to carry a given EXP value, CBTS picks one of those tunnels to carry
this EXP value.
The operation of CBTS is not supported with Any Transport over MPLS (AToM), MPLS TE
Automesh, or label-controlled (LC)-ATM.
Information About MPLS Traffic Engineering : Class-based

Tunnel Selection
To configure the MPLS Traffic Engineering (TE): Class-based Tunnel Selection feature, you should
understand the following concepts:
Incoming Traffic Supported by MPLS TE Class-based Tunnel Selection, page 3
CoS Attributes for MPLS TE Class-based Tunnel Selection, page 3
2
Information About MPLS Traffic Engineering : Class-based Tunnel Selection
Routing Protocols and MPLS TE Class-based Tunnel Selection, page 3

Tunnel Selection with MPLS TE Class-based Tunnel Selection, page 4
DS-TE Tunnels and MPLS TE Class-based Tunnel Selection, page 10
Reoptimization and MPLS TE Class-based Tunnel Selection, page 10
Interarea and Inter-AS and MPLS TE Class-based Tunnel Selection, page 10
ATM PVCs and MPLS TE Class-based Tunnel Selection, page 10
Incoming Traffic Supported by MPLS TE Class-based Tunnel Selection

The CBTS feature supports the following kinds of incoming packets:
At a provider edge (PE) routerUnlabeled packets that enter a Virtual Private Network (VPN)
routing and forwarding (VRF) instance interface
At a provider core (P) routerUnlabeled and MPLS-labeled packets that enter a non-VRF interface
At a PE router in a Carrier Supporting Carrier (CSC) or interautonomous system
(Inter-AS)MPLS-labeled packets that enter a VRF interface
CoS Attributes for MPLS TE Class-based Tunnel Selection

CBTS supports tunnel selection based on the value of the EXP field that the headend router imposes on
the packet. Before imposing this value, the router considers the input modular quality of service (QoS)
command-line interface (CLI) (MQC). If the input MQC modifies the EXP field value, CBTS uses the
modified value for its tunnel selection.
Packets may enter the headend from multiple incoming interfaces. These interfaces can come from
different customers that have different DiffServ policies. In such cases, service providers generally use
input MQC to apply their own DiffServ policies and mark imposed EXP values accordingly. Thus, CBTS
can operate consistently for all customers by considering the EXP values marked by the service provider.
Note If the output MQC modifies the EXP field, CBTS ignores the change in the EXP value.
CBTS allows up to eight different tunnels on which it can distribute all classes of service.
Routing Protocols and MPLS TE Class-based Tunnel Selection

CBTS routes and forwards packets to MPLS TE tunnels for specified destinations through use of the
following routing protocols:
Intermediate System-to-Intermediate System (IS-IS) with Autoroute configured
Open Shortest Path First (OSPF) with Autoroute configured
Static routing
Border Gateway Protocol (BGP) with recursion configured on the BGP next hop with packets
forwarded on the tunnel through the use of IS-IS, OSPF, or static routing
3
Tunnel Selection with MPLS TE Class-based Tunnel Selection

This section contains the following topics related to tunnel selection:
EXP Mapping Configuration, page 4
Tunnel Selection for EXP Values, page 4
Tunnel Failure Handling, page 7
Misordering of Packets, page 9
EXP Mapping Configuration

With CBTS, you can configure each tunnel with any of the following:
The same EXP information configured as it was before the CBTS feature was introduced, that is,
with no EXP-related information
One or more EXP values for the tunnel to carry
A property that allows the carrying of all EXP values not currently allocated to any up-tunnel
(default)
One or more EXP values for the tunnel to carry, and the default property that allows the carrying of
all EXP values not currently allocated to any up-tunnel
The default property (the carrying of all EXP values not currently allocated to any up-tunnel) effectively
provides a way for the operator to avoid explicitly listing all possible EXP values. Even more important,
the default property allows the operator to indicate tunnel preferences onto which to bump certain EXP
values, should the tunnel carrying those EXP values go down. (See the tunnel mpls traffic-eng exp
command for the command syntax.)
The configuration of each tunnel is independent of the configuration of any other tunnel. CBTS does not
attempt to perform any consistency check for EXP configuration.
This feature allows configurations where:
Not all EXP values are explicitly allocated to tunnels.
Multiple tunnels have the default property.
Some tunnels have EXP values configured and others do not have any values configured.
A given EXP value is configured on multiple tunnels.
Tunnel Selection for EXP Values

This section contains information about the following topics:
Tunnel Selection Process, page 5
Tunnel Selection Examples, page 5
Multipath with Non-TE Paths and MPLS TE Class-Based Tunnel Selection, page 7
MPLS TE Class-Based Tunnel Selection and Policy-Based Routing, page 7
4
Tunnel Selection Process
Tunnel selection with this feature is a two-step process:

1. For a given prefix, routing (autoroute, static routes) occurs exactly as it did without the CBTS
feature. The router selects the set of operating tunnels that have the best metrics, regardless of the
EXP-related information configured on the tunnel.
2. CBTS maps all of the EXP values to the selected set of tunnels:
If a given EXP value is configured:
On only one of the tunnels in the selected set, CBTS maps the EXP value onto that tunnel.
On two or more of the tunnels in the selected set, CBTS arbitrarily maps the EXP value onto
one of these tunnels. First CBTS selects the tunnel on which the lowest EXP value is explicitly
configured. Then CBTS picks the tunnel that has the lowest tunnel ID.
If a given EXP value is not configured on any of the tunnels in the selected set:
And only one of the tunnels in the selected set is configured as a default, CBTS maps the EXP
value onto that tunnel.
And two or more of the tunnels in the selected set are configured as defaults, CBTS arbitrarily
maps the EXP value onto one of these tunnels.
And no tunnel in the selected set of tunnels is configured as a default, CBTS does not map this
EXP value onto any specific tunnel. Instead, CBTS performs CoS-unaware load balancing of
that EXP information across all tunnels in the selected set.
CBTS relies on autoroute to select the tunnel bundle. Autoroute selects only tunnels that are on the SPF
to the destination. Therefore, similar to Autoroute, CBTS does not introduce any risk of routing loops.
Tunnel Selection Examples
The following examples show various tunnel configurations that are set up by an operator and indicate
how CBTS maps packets carrying EXP values onto these tunnels. Each example describes a different
configuration: a default tunnel configured, more than one tunnel configured with the same EXP value,
and so on.
Example 1Default Tunnel Configured

An operator configures the following parameters on tunnels T1 and T2:
T1: exp = 5, autoroute
T2: exp = default, autoroute
If T1 and T2 are next-hop interfaces for prefix P, CBTS maps the packets onto the tunnels in this way:
Packets with <Dest = P, exp = 5> onto T1
Packets with <Dest = P, exp = anything-other-than-5> onto T2
Example 2 EXP Values Configured on Two Tunnels; One Default Tunnel

An operator configures the following parameters on tunnels T1, T2, and T3:
T2: exp = 3 and 4, autoroute
If T1, T2, and T3 are next-hop interfaces for prefix P, CBTS maps the packets onto the tunnels in this
way:
5

Packets with <Dest = P, exp = 3 or 4> onto T2
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T3
Example 3More than One Tunnel with the Same EXP

If T1, T2, and T3 are next-hop interfaces for prefix P, CBTS maps the packets onto the tunnels in this
way:
Packets with <Dest = P, exp = 5> onto T1 (arbitrary selection)
Packets with <Dest = P, exp = anything-other-than-5> onto T3
No packets onto T2
Example 4Static Route Configured

T2: exp = 3
Static route to P on T2
If prefix P is behind the T1 and T2 tailend router, CBTS maps the packets onto the tunnels in this way:
Packets with <Dest = P, exp = anything> onto T2
No packets onto T1
Static routes are preferred over dynamic routes; therefore, the router chooses only T2 as the selected
set of tunnels.
Example 5Metrics Configured on Tunnels

T1: exp = 5, autoroute, relative metric 2
T2: exp = 3, autoroute, relative metric 3
CBTS maps the packets onto the tunnels in this way:
Packets with <Dest = P, exp = anything> onto T2
No packets onto T1
The autoroute tunnel selection algorithm selects the tunnel with the best metric. Therefore, the router
selects only T2 as the selected set of tunnels.
Example 6No Default or Metric Configuration

If T1 and T2 are the next-hop interfaces for prefix P, CBTS maps the packets onto the tunnels in this way:
6

Packets with <Dest = P, exp = anything-other-than-3-or-5> onto T2
If a packet arrives with an EXP value that is different from any value configured for a tunnel, the packet
goes in to the default tunnel. If no default tunnel is configured, the packet goes in to the tunnel that is
configured with the lowest EXP value.
Multipath with Non-TE Paths and MPLS TE Class-Based Tunnel Selection
For a given prefix in the routing process, the router might select a set of paths that includes both
TE tunnels and non-TE-tunnel paths (SPF paths). For example, internal Border Gateway Protocol
(iBGP) Multipath might be activated and result in multiple BGP next hops for that prefix, where one
BGP next hop is reachable through TE tunnels and other BGP next hops are reachable through
non-TE-tunnel paths.
An equal cost IGP path might also exist over TE tunnels and over a non-TE tunnel path. For example, a
TE tunnel metric might be modified to be equal to the SPF path.
In these situations, CBTS maps traffic in the following manner:
If a given EXP value is configured on one or more of the tunnels in the selected set, CBTS maps the
EXP value onto that tunnel or one of those tunnels.
If a given EXP value is not configured on any of the tunnels in the selected set but one or more of
the tunnels is configured as a default in the selected set, then CBTS maps the EXP value onto that
tunnel or one of those tunnels.
If a given EXP value is not configured on any of the tunnels from the selected set and no tunnel in
the selected set is configured as a default, CBTS performs CoS-unaware load-balancing of that EXP
value across all the possible paths, including all of the TE tunnels of the selected set and the non-TE
paths.
If the routing process allocates all EXP values to tunnels or if a default is used, then routing does
not use the non-TE paths unless all TE tunnels are down.
MPLS TE Class-Based Tunnel Selection and Policy-Based Routing
If you configure both policy-based routing (PBR) over TE tunnels (in non-VRF environments) and
CBTS, the PBR decision overrides the CBTS decision. PBR is an input process that the router performs
ahead of regular forwarding.
Tunnel Failure Handling

This section contains the following sections:
Tunnel Up or Down, page 7
Behavior When a Tunnel Goes Down, page 8
Tunnel Up or Down
For CBTS operation, the important question is whether the tunnel interface is up or down, not whether
the current TE label switched path (LSP) is up or down. For example, a TE LSP might go down but is
reestablished by the headend because another path option exists. The tunnel interface does not go down
during the transient period while the TE LSP is reestablished. Because the tunnel interface does not go
down, the corresponding EXP does not get rerouted onto another tunnel during the transient period.
7
Behavior When a Tunnel Goes Down
When a tunnel used by CBTS for forwarding goes down, the feature adjusts its tunnel selection for the
affected EXP values. It reapplies the tunnel selection algorithm to define the behavior of packets for all
EXP values, as shown in the examples that follow.
Example 1Tunnel Other than the Default Tunnel Goes Down

If T1, T2, and T3 are next-hop interfaces for prefix P and Tunnel T1 goes down, CBTS maps the packets
onto the tunnels in this way:
Packets with <Dest = P, exp = 3, 4> onto T2 (as before)
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T3 (as before)
Example 2Default Tunnel Goes Down

Packets with <Dest = P, exp = 5> onto T1 (as before)
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T1 and T2, following existing CoS-unaware load
balancing
Example 3Two Default Tunnels Are Configured

T2: exp = 3, 4, and default, autoroute
T3: exp = 0, 1, 2, 6, 7, and default, autoroute
Packets with <Dest = P, exp = 0, 1, 2, 6, or 7> onto T2
If tunnel T2 goes down, CBTS maps the packets onto the tunnels in this way:
8
Packets with <Dest = P, exp = 3, or 4> onto T3

If tunnel T1 goes down, CBTS maps the packets onto the tunnels in this way:
Packets with <Dest = P, exp = 3, or 4> onto T2 (as before)
Packets with <Dest = P, exp = 5> onto either T2 or T3, but not both
In Example 3, the operator configures the EXP default option on two tunnels to ensure that nonvoice
traffic is never redirected onto the voice tunnel (T1).
Misordering of Packets
In DiffServ, packets from a given flow might get marked with EXP values that are different from each
other but belong to the same CoS value because of in-contract and out-of-contract marking of packets.
We can refer to these values of EXP bits as EXP-in and EXP-out.
If packets for EXP-in are sent on a different tunnel than packets for EXP-out, then misordering of
packets within the same flows could occur. For that reason, CBTS allows operators to ensure that EXP-in
and EXP-out never get mapped onto different tunnels.
The CBTS feature allows the operator to configure EXP-in and EXP-out to be transported on the same
tunnel when that tunnel is up. This ensures that the feature does not introduce misordering of packets.
In case of tunnel failure, the tunnel selection algorithm ensures that if EXP-in and EXP-out were carried
on the same tunnel before the failure, they are still carried on a single tunnel after the failure. Thus,
CBTS protects against nontransient misordering even in the event of tunnel failure.
Note CBTS does not attempt to force EXP-in and EXP-out to be carried on the same tunnel. The operator must
configure CBTS so that EXP-in and EXP-out are carried on the same tunnel. This is comparable to the
regular DiffServ situation, where the operator must ensure that EXP-in and EXP-out are configured to
go in the same queue.
Fast Reroute and MPLS TE Class-based Tunnel Selection

CBTS allows Fast Reroute (FRR) protection on tunnels for which you configure CoS-based selection.
CBTS operation with FRR does not change the number of or the way in which FRR backup tunnels might
be used. The operation of FFR is the same as when CBTS is not activated. After you configure primary
tunnels from a given headend to a given tailend, you can use FRR in the same way whether you activate
CoS-based tunnel selection or not. This includes the following possibilities:
None of the tunnels use FRR.
All of the x tunnels are FRR-protected and share the same backup tunnel, if the traffic goes out the
same interface.
Some of the x tunnels are not FRR-protected; the remaining tunnels are FRR-protected and share
the same backup tunnel, if the traffic goes out the same interface.
Some of the x tunnels are not FRR-protected; the remaining tunnels are FRR-protected and are
protected by different backup tunnels (for example, if the traffic goes out different interfaces, or if
the traffic goes out the same interface). Bandwidth guarantees exist on the backup tunnels.
The important question for CBTS operation is only whether a tunnel interface goes down or stays up.
FRR protects a given tunnel in exactly the same way as if CBTS were not configured on the tunnel.
9
How to Configure MPLS Traffic Engineering : Class-based Tunnel Selection
DS-TE Tunnels and MPLS TE Class-based Tunnel Selection

CBTS operates over tunnels using DS-TE. Therefore, the tunnels on which CoS-based selection is
performed can each arbitrarily and independently use a bandwidth from the global pool or the subpool.
Reoptimization and MPLS TE Class-based Tunnel Selection

CBTS allows tunnels on which CoS-based selection is performed to be reoptimized. Reoptimization
does not affect CBTS operation.
Interarea and Inter-AS and MPLS TE Class-based Tunnel Selection

The CBTS operates over tunnels that are interarea when the interarea tunnels use static routes on
destination prefixes or on the BGP next hops.
ATM PVCs and MPLS TE Class-based Tunnel Selection

CBTS operates over ATM permanent virtual circuits (PVCs). This means that TE or DS-TE tunnels
handled by CBTS can span links that are ATM PVCs. ATM PVCs might be used on the headend router
that is running CBTS and on transit label switch routers (LSRs).
How to Configure MPLS Traffic Engineering : Class-based

Tunnel Selection
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend,
page 10
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel, page 13
Making the MPLS TE or DS-TE Tunnels Visible for Routing, page 14
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP, page 15
Configuring a Master Tunnel, page 17
You need to configure the CBTS feature only on the tunnel headend. No CBTS configuration is required
on the tailend or transit LSR.
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the
Same Tailend
Figure 1 shows an example of two tunnels, Tunnel 65 and Tunnel 66, transporting different classes of
traffic between the same headend and the same tailend.
10
Figure 1 Tunnels Transporting Different Classes of Service Between the Same Headend and
Tailend
POP 1-to-POP 4
Tunnel 65: EXP = 5 (voice)
Tunnel 66: EXP = 0, 1, 2, 3, 4, 6, 7, (data)
POP 1 Tunnel 65 POP 4
Tunnel 66
121203
To create multiple MPLS TE or DS-TE tunnels with the same headend and same tailend, perform the
following steps.
SUMMARY STEPS
1. enable
4. ip unnumbered type number
7. tunnel mpls traffic-eng bandwidth [sub-pool | global] bandwidth
8. exit
9. Repeat steps 3 through 8 on the same headend router to create additional tunnels from this headend
to the same tailend.
10. end
DETAILED STEPS
11

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 Enables IP processing on an interface without assigning an
Example:
Router(config-if)# ip unnumbered loopback 0
Example:
10.10.10.12
Step 6 tunnel mode mpls traffic-eng Sets the mode of a tunnel to MPLS for TE.
Example:
Step 7 tunnel mpls traffic-eng bandwidth [sub-pool | Configures the bandwidth for the MPLS TE tunnel. If
global] bandwidth automatic bandwidth is configured for the tunnel, use the
tunnel mpls traffic-eng bandwidth command to configure
Example: the initial tunnel bandwidth, which is adjusted by the
Router(config-if)# tunnel mpls traffic-eng autobandwidth mechanism.
bandwidth sub-pool 3000
Note You can configure any existing MPLS TE command
on these TE or DS-TE tunnels.
Step 8 exit Returns to global configuration mode.
Example:
Step 9 Repeat steps 3 through 8 on the same headend router to
create additional tunnels from this headend to the same
tailend.
Step 10 end Returns to privileged EXEC mode.
Example:
Router(config)# end
12
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel

To configure EXP values to be carried by each MPLS TE or DS-TE tunnel, perform the following steps.
For each tunnel that you create, you must indicate which EXP values the tunnel carries.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng exp [list-of-exp-values] [default]
5. exit
6. Repeat steps 3 through 5 for all MPLS TE tunnels that you created in the Creating Multiple MPLS
TE or DS-TE Tunnels from the Same Headend to the Same Tailend section on page 10.
7. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 tunnel mpls traffic-eng exp Specifies the EXP bits that will be forwarded over a member
[list-of-exp-values] [default] tunnel that is part of the CBTS bundle.
Example:
Router(config-if)# tunnel mpls traffic-eng exp
5
Example:
13

Step 6 Repeat steps 3 through 5 for all MPLS TE tunnels that
you created in the Creating Multiple MPLS TE or
DS-TE Tunnels from the Same Headend to the Same
Tailend section on page 10.
Example:
Making the MPLS TE or DS-TE Tunnels Visible for Routing

Perform the following task to make the MPLS TE or DS-TE tunnels visible for routing.
Note Alternatively, static routing could be used instead of autoroute to make the TE or DS-TE tunnels visible
for routing.
SUMMARY STEPS
1. enable
5. tunnel mpls traffic-eng autoroute metric {absolute | relative} value
6. end
DETAILED STEPS

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

Step 4 tunnel mpls traffic-eng autoroute announce Specifies that the Interior Gateway Protocol (IGP) should
use the tunnel (if the tunnel is up) in its enhanced SPF
calculation.
Example:
autoroute announce
Step 5 tunnel mpls traffic-eng autoroute metric Specifies the MPLS TE tunnel metric that the IGP enhanced
{absolute | relative} value SPF calculation uses.
Note Even though the value for a relative metric can be
Example: from 10 to +10, configuring a tunnel metric with a
Router(config-if)# tunnel mpls traffic-eng negative value is considered a misconfiguration. If
autoroute metric relative 2
the metric to the tunnel tailend appears to be 4 from
the routing table, then the cost to the tunnel tailend
router is actually 3 because 1 is added to the cost for
getting to the loopback address. In this instance, the
lowest value that you can configure for the relative
metric is 3.
Example:
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to
the IGP
To verify that the MPLS TE or DS-TE tunnels are operating and announced to the IGP, perform the
following steps.
SUMMARY STEPS
1. show mpls traffic-eng topology {ip-address | igp-id {isis nsap-address | ospf ip-address} [brief]
2. show mpls traffic-eng tunnels number [brief] protect
3. show ip cef [vrf vrf-name] [unresolved [detail] | [detail | summary]]
| next-hop address | lsp-tunnel [tunnel-id]] [vrf vrf-name] [detail]
5. show mpls traffic-eng autoroute
DETAILED STEPS
Step 1 show mpls traffic-eng topology {ip-address | igp-id {isis nsap-address | ospf ip-address} [brief]
Use this command to display the MPLS TE global topology currently known at this node:
Router# show mpls traffic-eng topology
My_System_id: 0000.0025.0003.00
15
IGP Id: 0000.0024.0004.00, MPLS TE Id:172.16.4.4 Router Node

link[0 ]:Intf Address: 10.1.1.4
Nbr IGP Id: 0000.0024.0004.02,
admin_weight:10, affinity_bits:0x0
max_link_bw:10000 max_link_reservable: 10000
globalpoolsubpool
total allocatedreservable reservable
--------------- ---------- ----------
bw[0]: 0 1000500
bw[1]:10 990490
bw[2]: 600 390390
bw[3]: 0 390390
bw[4]: 0 390390
bw[5]: 0 390390
Step 2 show mpls traffic-eng tunnels number [brief] [protection]

Use this command to display information for a specified tunneling interface:
Router# show mpls traffic-eng tunnels 500 brief protection
Router#_t500
LSP Head, Tunnel500, Admin: up, Oper: up
Src 172.16.0.5, Dest 172.16.0.8, Instance 17
Fast Reroute Protection: None
Path Protection: 1 Common Link(s) , 1 Common Node(s)
Primary lsp path:192.168.6.6 192.168.7.7
192.168.8.8 192.168.0.8
Protect lsp path:172.16.7.7 192.168.8.8

10.0.0.8
Path Protect Parameters:
InLabel : -
OutLabel : Serial5/3, 46
RSVP Signalling Info:
Src 172.16.0.5, Dst 172.16.0.8, Tun_Id 500, Tun_Instance 18
RSVP Path Info:
My Address: 172.16.0.5
Explicit Route: 192.168.7.7 192.168.8.8
Record Route: NONE
Tspec: ave rate=50 kbits, burst=1000 bytes, peak rate=50 kbits
RSVP Resv Info:
Record Route: NONE
Fspec: ave rate=50 kbits, burst=1000 bytes, peak rate=50 kbits
Step 3 show ip cef summary

Use this command to display a summary of the IP CEF table:
Router# show ip cef summary
IP Distributed CEF with switching (Table Version 25), flags=0x0

21 routes, 0 reresolve, 0 unresolved (0 old, 0 new), peak 1
21 leaves, 16 nodes, 19496 bytes, 36 inserts, 15 invalidations
0 load sharing elements, 0 bytes, 0 references
universal per-destination load sharing algorithm, id 5163EC15
3(0) CEF resets, 0 revisions of existing leaves
Resolution Timer: Exponential (currently 1s, peak 1s)
0 in-place/0 aborted modifications
refcounts: 4377 leaf, 4352 node
Table epoch: 0 (21 entries at this epoch)
16
Adjacency Table has 9 adjacencies
Step 4 show mpls forwarding-table [network {mask | length} | labels label [- label] | interface interface |
next-hop address | lsp-tunnel [tunnel-id]] [vrf vrf-name] [detail]
Use this command to display the contents of the MPLS Label Forwarding Information Base (LFIB):

Label Label or VC or Tunnel Id switched interface
26 No Label 10.253.0.0/16 0 Et4/0/0 10.27.32.4
28 1/33 10.15.0.0/16 0 AT0/0.1 point2point
29 Pop Label 10.91.0.0/16 0 Hs5/0 point2point
1/36 10.91.0.0/16 0 AT0/0.1 point2point
30 32 10.250.0.97/32 0 Et4/0/2 10.92.0.7
32 10.250.0.97/32 0 Hs5/0 point2point
34 26 10.77.0.0/24 0 Et4/0/2 10.92.0.7
26 10.77.0.0/24 0 Hs5/0 point2point
35 No Label[T] 10.100.100.101/32 0 Tu301 point2point
36 Pop Label 10.1.0.0/16 0 Hs5/0 point2point
1/37 10.1.0.0/16 0 AT0/0.1 point2point
[T] Forwarding through a TSP tunnel.

View additional tagging info with the 'detail' option
Step 5 show mpls traffic-eng autoroute

Use this command to display tunnels that are announced to the IGP, including interface, destination, and
bandwidth:
Router# show mpls traffic-eng autoroute
MPLS TE autorouting enabled

Tunnel1021 (traffic share 10000, nexthop 10.2.2.2, absolute metric 11)
Tunnel1022 (traffic share 3333, nexthop 10.2.2.2, relative metric -3)
Tunnel1031 (traffic share 10000, nexthop 172.16.3.3, relative metric -1)
Configuring a Master Tunnel

To configure a master tunnel to which other tunnels can be members, perform the following steps.
SUMMARY STEPS
1. enable
7. tunnel mpls traffic-eng exp-bundle master
17
8. tunnel mpls traffic-eng exp-bundle member tunnel-number

9. exit
DETAILED STEPS

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 Enables IP processing on an interface without assigning an
Example:
Example:
10.10.10.12
Step 6 tunnel mode mpls traffic-eng Sets the mode of a tunnel to MPLS for TE.
Example:
Step 7 tunnel mpls traffic-eng exp-bundle master Configures a master tunnel.
Example:
exp-bundle master
Step 8 tunnel mpls traffic-eng exp-bundle member Identifies which tunnel is a member of a master tunnel.
tunnel-number
Example:
exp-bundle member tunnel1
Example:
18
Configuration Examples for MPLS Traffic Engineering : Class-based Tunnel Selection
Configuration Examples for MPLS Traffic Engineering :

Class-based Tunnel Selection
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the Same Tailend:
Example, page 19
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel: Example, page 19
Making the MPLS TE or DS-TE Tunnels Visible for Routing: Example, page 20
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to the IGP: Example,
page 20
Configuring a Master Tunnel: Example, page 27
Creating Multiple MPLS TE or DS-TE Tunnels from the Same Headend to the
Same Tailend: Example
The following example shows how to create multiple MPLS TE or DS-TE tunnels from the same
headend to the same tailend:
Router(config-if)# ip numbered loopback 0
Router(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000
Router(config-if)# ^Z
Router(config-if)# ip numbered loopback 0
Router#
Configuring EXP Values to Be Carried by Each MPLS TE or DS-TE Tunnel:

Example
The following example shows how to configure EXP values to be carried by each MPLS TE or DS-TE
tunnel that you created:
Router(config-if)# tunnel mpls traffic-eng exp 5
Router(config)#
Router(config-if)# tunnel mpls traffic-eng exp 0 1 2 3 4 6 7
Router#
19
Making the MPLS TE or DS-TE Tunnels Visible for Routing: Example

The following example shows how to make the MPLS TE or DS-TE tunnels visible for routing:
Router(config-if)# tunnel mpls traffic-eng autoroute announce
Router(config-if)# tunnel mpls traffic-eng autoroute metric relative -2
Router(config)#
Router(config-if)# tunnel mpls traffic-eng autoroute announce
Router(config-if)# tunnel mpls traffic-eng autoroute metric relative -2
Router#
Packets destined beyond 10.1.1.1 are sent on:

Tunnel 65 if their EXP value after input MQC is 5.
Tunnel 66 if their EXP value after input MQC is 0, 1, 2, 3, 4, 6, or 7.
Verifying That the MPLS TE or DS-TE Tunnels Are Operating and Announced to
the IGP: Example
The output for each of the following examples helps verify that the MPLS TE or DS-TE tunnels are
operating and visible.
The show mpls traffic-eng topology command output displays the MPLS TE global topology:
Router# show mpls traffic-eng topology 10.0.0.1
IGP Id: 10.0.0.1, MPLS TE Id:10.0.0.1 Router Node (ospf 10 area 0) id 1

link[0]: Broadcast, DR: 10.0.1.2, nbr_node_id:6, gen:18
frag_id 0, Intf Address:10.1.1.1
TE metric:1, IGP metric:1, attribute_flags:0x0
SRLGs: None
physical_bw: 100000 (kbps), max_reservable_bw_global: 1000 (kbps)
max_reservable_bw_sub: 0 (kbps)
Global Pool Sub Pool

Total Allocated Reservable Reservable
BW (kbps) BW (kbps) BW (kbps)
--------------- ----------- ----------
bw[0]: 0 1000 0
bw[1]: 0 1000 0
bw[2]: 0 1000 0
bw[3]: 0 1000 0
bw[4]: 0 1000 0
bw[5]: 0 1000 0
bw[6]: 0 1000 0
bw[7]: 100 900 0
link[1]: Broadcast, DR: 10.0.2.2, nbr_node_id:7, gen:19

frag_id 1, Intf Address:10.0.2.1
SRLGs: None

20

--------------- ----------- ----------
bw[0]: 0 1000 0
bw[1]: 0 1000 0
bw[2]: 0 1000 0
bw[3]: 0 1000 0
bw[4]: 0 1000 0
bw[5]: 0 1000 0
bw[6]: 0 1000 0
bw[7]: 300 700 0
Router#
Router# show mpls traffic-eng topology 10.0.0.9
IGP Id: 10.0.0.9, MPLS TE Id:10.0.0.9 Router Node (ospf 10 area 0) id 3

link[0]: Point-to-Point, Nbr IGP Id: 10.0.0.5, nbr_node_id:5, gen:9
frag_id 1, Intf Address:10.0.5.2, Nbr Intf Address:10.0.5.1
SRLGs: None

--------------- ----------- ----------
bw[0]: 0 1000 0
bw[1]: 0 1000 0
bw[2]: 0 1000 0
bw[3]: 0 1000 0
bw[4]: 0 1000 0
bw[5]: 0 1000 0
bw[6]: 0 1000 0
bw[7]: 0 1000 0
link[1]: Point-to-Point, Nbr IGP Id: 10.0.0.7, nbr_node_id:4, gen:9

SRLGs: None

--------------- ----------- ----------
bw[0]: 0 1000 0
bw[1]: 0 1000 0
bw[2]: 0 1000 0
bw[3]: 0 1000 0
bw[4]: 0 1000 0
bw[5]: 0 1000 0
bw[6]: 0 1000 0
bw[7]: 0 1000 0
Router#
The show mpls traffic-eng tunnels command output displays information about a tunnel:
Name: Router_t1 (Tunnel1) Destination: 10.0.0.9

Status:
21
Config Parameters:
auto-bw: disabled
BandwidthOverride: disabled LockDown: disabled Verbatim: disabled
InLabel : -
OutLabel : FastEthernet6/0, 12304
RSVP Path Info:
Explicit Route: 10.0.1.2 10.0.3.2 10.0.5.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Shortest Unconstrained Path Info:
Path Weight: 3 (TE)
Explicit Route: 10.0.2.1 180.0.2.2 10.0.3.2 180.0.5.2
10.0.0.9
History:
Tunnel:
Time since created: 15 minutes, 18 seconds
Time since path change: 15 minutes, 5 seconds
Current LSP:
Uptime: 15 minutes, 5 seconds
Router# show mpls traffic-eng tunnel tunnel2

Status:
Config Parameters:
auto-bw: disabled
InLabel : -
RSVP Path Info:
Explicit Route: 10.0.2.2 10.0.4.2 10.0.6.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
22
Path Weight: 3 (TE)

Explicit Route: 10.0.2.1 10.0.2.2 10.0.3.2 10.0.5.2
10.0.0.9
History:
Tunnel:
Current LSP:

Status:
Config Parameters:
auto-bw: disabled
InLabel : -
RSVP Path Info:
' Explicit Route: 10.0.2.2 10.0.4.2 10.0.6.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Path Weight: 3 (TE)
Explicit Route: 10.0.2.1 10.0.2.2 10.0.3.2 10.0.5.2
10.0.0.9
History:
Tunnel:
Current LSP:

Status:
Config Parameters:
auto-bw: disabled
23

InLabel : -
RSVP Path Info:
Explicit Route: 10.0.2.2 10.0.4.2 10.0.6.2 10.0.0.9
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Path Weight: 3 (TE)
Explicit Route: 10.0.2.1 10.0.2.2 10.0.3.2 10.0.5.2
10.0.0.9
History:
Tunnel:
Current LSP:
The show ip cef detail command output displays detailed FIB entry information for a tunnel:
Router# show ip cef tunnel1 detail
IP CEF with switching (Table Version 46), flags=0x0

2 instant recursive resolutions, 0 used background process
8 load sharing elements, 8 references
34696 bytes allocated to the FIB table data structures
universal per-destination load sharing algorithm, id 9EDD49E1
1(0) CEF resets
Tree summary:
8-8-8-8 stride pattern
short mask protection disabled
31 leaves, 23 nodes using 26428 bytes

10.0.0.9/32, version 45, epoch 0, per-destination sharing
0 packets, 0 bytes
tag information set, all rewrites inherited
local tag: tunnel head
via 0.0.0.0, Tunnel1, 0 dependencies
traffic share 1
next hop 0.0.0.0, Tunnel1
valid adjacency
tag rewrite with Tu1, point2point, tags imposed {12304}
0 packets, 0 bytes switched through the prefix
tmstats: external 0 packets, 0 bytes
internal 0 packets, 0 bytes
24

1(0) CEF resets
Tree summary:

0 packets, 0 bytes
traffic share 1
valid adjacency

1(0) CEF resets
Tree summary:

0 packets, 0 bytes
traffic share 1
valid adjacency
25

1(0) CEF resets
Tree summary:

0 packets, 0 bytes
traffic share 1
valid adjacency
The show mpls forwarding-table detail command output displays detailed information from the MPLS
LFIB:

Router#
Router# show mpls forwarding-table 10.0.0.9 detail

Tun hd Untagged 10.0.0.9/32 0 Tu1 point2point
MAC/Encaps=14/18, MRU=1500, Tag Stack{12304}, via Fa6/0
00027D884000000ED70178A88847 03010000
No output feature configured
Per-exp selection: 1
Untagged 10.0.0.9/32 0 Tu2 point2point
00027D884001000ED70178A98847 03011000
Per-exp selection: 2 3
00027D884001000ED70178A98847 03012000
Per-exp selection: 4 5
00027D884001000ED70178A98847 03013000
26

Per-exp selection: 0 6 7
Router#
The show mpls traffic-eng autoroute command output displays tunnels that are announced to the IGP:
Router# show mpls traffic-eng autoroute
MPLS TE autorouting enabled

destination 10.0.0.9, area ospf 10 area 0, has 4 tunnels
(flags: Announce)
(flags: Announce)
(flags: Announce)
(flags: Announce)
Router#
Configuring a Master Tunnel: Example

The following example specifies that there is a master tunnel that includes tunnels Tunnel20000 through
Tunnel20005:
interface Tunnel 200
ip unnumbered Loopback 0
tunnel mpls traffic-eng exp-bundle master
tunnel mpls traffic-eng exp-bundle member Tunnel20000
27
The following sections provide references related to the MPLS Traffic Engineering (TE): Class-based
Tunnel Selection feature.
Related Documents
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
28
Command Reference
Description Link
Command Reference
show ip cef
show mpls forwarding-table
tunnel mpls traffic-eng exp
tunnel mpls traffic-eng exp-bundle member
29
Feature Information for MPLS Traffic Engineering : Class-based Tunnel Selection
Feature Information for MPLS Traffic Engineering : Class-based

Tunnel Selection
Table 1 Feature Information for MPLS Traffic Engineering : Class-based Tunnel Selection

MPLS Traffic Engineering : Class-based 12.0(29)S The MPLS Traffic Engineering (TE): Class-based Tunnel
Tunnel Selection 12.2(33)SRA Selection feature enables you to dynamically route and
12.2(32)SY forward traffic with different class of service (CoS) values
12.2(33)SXH onto different TE tunnels between the same tunnel headend
12.4(20)T and the same tailend. The TE tunnels can be regular TE or
DiffServ-aware TE (DS-TE) tunnels.
In 12.2(33)SRA, this feature was integrated and the
following commands were added:
tunnel mpls traffic-eng exp-bundle member
12.0(32)SY, support for this feature was added on the
Cisco 12000 family of routers.
In 12.2(33)SXH, this feature was integrated.
In 12.4(20)T, this feature was integrated.
30
Glossary
Glossary
BGPBorder Gateway Protocol. Interdomain routing protocol that replaces External Gateway Protocol
(EGP). BGP exchanges reachability information with other BGP systems. It is defined by RFC 116.3
bundled tunnelsMembers of a master tunnel. You define the EXP bits that will be forwarded over
each bundled tunnel.
Cisco Express ForwardingAn advanced Layer 3 IP switching technology. Cisco Express Forwarding
optimizes network performance and scalability for networks with large and dynamic traffic patterns,
such as the Internet and networks characterized by intensive web-based applications or interactive
sessions.
CoSclass of service. An indication of how an upper-layer protocol requires a lower-layer protocol to
treat its messages. In Systems Network Architecture (SNA) subarea routing, CoS definitions are used by
subarea nodes to determine the optimal route for establishing a given session. A CoS definition
comprises a virtual route number and a transmission priority field. Also called type of service (ToS).
DS-TEDiffServ-aware traffic engineering. The configuring of two bandwidth pools on each link, a
global pool and a subpool. Multiprotocol Label Switching (MPLS) traffic engineering tunnels using the
subpool bandwidth can be configured with quality of service (QoS) mechanisms to deliver guaranteed
bandwidth services end-to-end across the network. Simultaneously, tunnels using the global pool can
convey DiffServ traffic.
EXPexperimental field or bits. A 3-bit field in the Multiprotocol Label Switching (MPLS) header
widely known as the EXP field or EXP bits because, according to RFC 3032, that field is reserved for
experimental use. However, the most common use of those bits is for quality of service (QoS) purposes.
headendThe upstream, transmitting end of a tunnel. This is the first router in the label switched path
(LSP).
LSPlabel 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
master tunnelA set of tunnels that have the same destination.
MPLS traffic engineeringMultiprotocol Label Switching traffic engineering. A constraint-based
routing algorithm for routing label switched path (LSP) tunnels.
MQCmodular quality of service (QoS) command-line interface (CLI). A CLI structure that allows
users to create traffic polices and attach those polices to interfaces.
PBRpolicy-based routing. A routing scheme in which packets are forwarded to specific interfaces
based on user-configured policies. A policy might specify, for example, that traffic sent from a particular
network should be forwarded out one interface, and all other traffic should be forwarded out another
interface.
tailendThe downstream, receiving end of a tunnel. The router that terminates the traffic engineering
label switched path (LSP).
used.
ToStype of service. See CoS.
31
Glossary
VCDvirtual circuit descriptor. A unique number for each ATM interface processor (AIP) that tells the
AIP which virtual path identifier (VPI)/virtual channel identifier (VCI) to use for a particular packet.
Valid values range from 1 to the value set with the atm maxvc command.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are
trademarks; Changing the Way We Work, Live, Play, and Learn is a service mark; 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, iQ Expertise, the iQ logo,
iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, 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.
32
MPLS Traffic Engineering: Interarea Tunnels

The MPLS Traffic Engineering: Interarea Tunnels feature allows you to establish Multiprotocol Label
Switching (MPLS) traffic engineering (TE) tunnels that span multiple Interior Gateway Protocol (IGP)
areas and levels, removing the restriction that had required the tunnel headend and tailend routers both
be in the same area. The IGP can be either Intermediate System-to-Intermediate System (IS-IS) or Open
Shortest Path First (OSPF).
Note Cisco IOS Release 12.2(33)SRE and later releases support the autoroute destination feature, which
automatically routes traffic through TE tunnels instead of through manually configured static routes.

supported, see the Feature Information for MPLS Traffic Engineering: Interarea Tunnels section on
page 25.
Contents
Prerequisites for MPLS Traffic Engineering: Interarea Tunnels, page 2
Restrictions for MPLS Traffic Engineering: Interarea Tunnels, page 2
Information About MPLS Traffic Engineering: Interarea Tunnels, page 2
How to Configure MPLS Traffic Engineering: Interarea Tunnels, page 5
Prerequisites for MPLS Traffic Engineering: Interarea Tunnels
Configuration Examples for MPLS Traffic Engineering: Interarea Tunnels, page 18

Feature Information for MPLS Traffic Engineering: Interarea Tunnels, page 25
Glossary, page 26
Prerequisites for MPLS Traffic Engineering: Interarea Tunnels

MPLS
IS-IS or OSPF
TE tunnels
Restrictions for MPLS Traffic Engineering: Interarea Tunnels

The dynamic path option feature for TE tunnels (which is specified in the tunnel mpls traffic-eng
path-option number dynamic command) is not supported for interarea tunnels. An explicit path
identifying the Area Border Routers (ABRs) is required. When there are choices for the ABRs to be
used, multiple explicit paths are recommended, each of which identifies a different sequence of
ABRs.
The MPLS TE AutoRoute feature (which is specified in the tunnel mpls traffic-eng autoroute
announce command) is not supported for interarea tunnels because you would need to know the
network topology behind the tailend router.
Tunnel affinity (the tunnel mpls traffic-eng affinity command) is not supported for interarea
tunnels.
The reoptimization of tunnel paths is not supported for interarea tunnels.
Cisco IOS Release 12.4(20)T does not support stateful switchover (SSO) recovery of label-switched
paths (LSPs) that include loose hops.
Information About MPLS Traffic Engineering: Interarea Tunnels

Before using the MPLS Traffic Engineering: Interarea Tunnels feature, you need to understand the
following concepts:
Interarea Tunnels Functionality, page 3
Autoroute Destination Functionality, page 4
MPLS Traffic Engineering Interarea Tunnels Benefits, page 5
2
Interarea Tunnels Functionality

To configure an interarea tunnel, you specify on the headend router a loosely routed explicit path for the
tunnel label switched path (LSP) that identifies each ABR the LSP should traverse using the
next-address loose command. The headend router and the ABRs along the specified explicit path
expand the loose hops, each computing the path segment to the next ABR or tunnel destination.
For example, to configure a TE tunnel from router R1 to router R3 in the simple multiarea network
shown in Figure 1, you would specify ABR1 and ABR2 as loose hops in the explicit path for the tunnel.
Note Rx can be configured as a loose hop as well. In that case, the headend router R1 computes the path to
Rx and router Rx computes the path to ABR1.
To signal the tunnel LSP, the headend router (R1) computes the path to ABR1 and sends a Resource
Reservation Protocol (RSVP) Path message specifying the path from itself to ABR1 as a sequence of
strict hops followed by the path from ABR1 to the tailend as a sequence of loose hops (ABR2, R3). When
ABR1 receives the Path message, it expands the path across the backbone area to ABR2 and forwards
the Path message specifying the path from itself to ABR2 as a sequence of strict hops followed by the
path from ABR2 to the tunnel tailend (R3) as a loose hop. When ABR2 receives the Path message, it
expands the path across the tailend area to R3 and propagates the Path message specifying the path from
itself to R2 as a sequence of strict hops.
Figure 1 Multiarea Network
Area A Backbone Area Area B
59166
R1 Rx ABR1 Ry ABR2 Rz R3
(headend) (tailend)
Note Cisco IOS Release 12.2(33)SRB supports SSO recovery of LSPs that include loose hops.
Cisco IOS Release 12.4(20)T does not support SSO recovery of LSPs that include loose hops.
Note Strictly speaking, IS-IS does not have the notion of an ABR. For the purpose of discussing the MPLS
Traffic Engineering: Interarea Tunnels feature, an IS-IS level-1-2 router is considered to be an ABR.
Note The explicit path for a TE interarea tunnel may contain any number of non-ABR LSPs. Within an area,
a combination of loose and strict next IP addresses is allowed. To specify the next IP address in the
explicit path, use the next-address command.
3
Note With OSPF, if an area is connected to the backbone through a virtual link, there may be more than two
ABRs in the path.
The following MPLS TE features are supported on interarea traffic engineering LSPs:
Automatic bandwidth adjustment
Diff-Serve-aware traffic engineering
Fast reroute link protection
Policy-based routing
Static routing
Autoroute Destination Functionality

The autoroute destination feature allows you to automatically route traffic through a TE tunnel instead
of manually configuring static routes.
You enable this feature on a per-tunnel basis by using the tunnel mpls traffic-eng autoroute
destination command.
The following sections describe how the autoroute destination feature interacts with other features:
CBTS Interaction with Autoroute Destination, page 4
Manually Configured Static Routes Interaction with Autoroute Destination, page 4
Autoroute Announce Interaction with Autoroute Destination, page 5
Forwarding Adjacency Interaction with Autoroute Destination, page 5
CBTS Interaction with Autoroute Destination

TE tunnels that have the autoroute destination feature enabled can also be configured as class-based
traffic shaping (CBTS) tunnel bundle masters or members. Within a CBTS bundle, only the master
tunnel with autoroute destination enabled is installed into the Routing Information Base (RIB); that is,
the member tunnels are not installed into the RIB.
If member tunnels that have autoroute destination enabled are unconfigured from the bundle, they
become regular TE tunnels and TE requests that the static process installs static routes over those tunnels
in the RIB. Conversely, when regular TE tunnels with autoroute destination enabled are added to a CBTS
bundle as members, TE requests that the static process removes the automatic static routes over those
tunnels from the RIB.
Manually Configured Static Routes Interaction with Autoroute Destination

If there is a manually configured static route to the same destination as a tunnel with autoroute
destination enabled via the tunnel mpls traffic-eng autoroute destination command, traffic for that
destination is load-shared between the static route and the tunnel with autoroute destination enabled.
4
How to Configure MPLS Traffic Engineering: Interarea Tunnels
Autoroute Announce Interaction with Autoroute Destination

For intra-area tunnels, if a tunnel is configured with both autoroute announce and autoroute destination,
the tunnel is announced to the RIB by both the IGP and the static process. RIBs prefer static routes, not
IGP routes, so the autoroute destination features takes precedence over autoroute announce.
Forwarding Adjacency Interaction with Autoroute Destination

If a tunnel is configured with both forwarding adjacency and autoroute destination, the tunnel is
announced to the RIB by both the IGP and the static process. The RIB prefers the static route. However,
because the IGP was notified about the tunnel via the forwarding adjacency command and the tunnel
information was flooded, forwarding adjacency continues to function.
MPLS Traffic Engineering Interarea Tunnels Benefits

When it is desirable for the traffic from one router to another router in a different IGP area to travel
over TE LSPs, the MPLS Traffic Engineering: Interarea Tunnels feature allows you to configure a
tunnel that runs from the source router to the destination router. The alternative would be to
configure a sequence of tunnels, each crossing one of the areas between source and destination
routers such that the traffic arriving on one such tunnel is forwarded into the next such tunnel.
The autoroute destination feature prevents you from having to manually configure static routes to
route traffic over certain interarea tunnels such as ASBRs.

Configuring OSPF for Interarea Tunnels, page 5 (optional)
Configuring IS-IS for Interarea Tunnels, page 8 (optional)
Configuring MPLS and RSVP to Support Traffic Engineering, page 12 (required)
Configuring an MPLS Traffic Engineering Interarea Tunnel, page 14 (required)
Note You must configure either OSPF or IS-IS.
Configuring OSPF for Interarea Tunnels

This section describes the following tasks:
Configuring OSPF for ABR Routers, page 6
Configuring OSPF for Non-ABR Routers, page 7
5
Configuring OSPF for ABR Routers

For each ABR that is running OSPF, perform the following steps to configure traffic engineering on each
area you want tunnels in or across. By having multiple areas and configuring traffic engineering in and
across each area, the router can contain changes within the network within an area.
SUMMARY STEPS
1. enable
5. mpls traffic-eng router-id interface-name
6. mpls traffic-eng area 0
7. mpls traffic-eng area number
8. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router ospf process-id Enables OSPF and enters router configuration mode.
The process-id argument is an internally used identification
Example: parameter for the OSPF routing process. It is logically
Router(config)# router ospf 1 assigned and can be any positive integer. Assign a unique
value for each OSPF routing process.
Step 4 network ip-address wildcard-mask area area-id Specifies the interfaces on which OSPF is to run and
specifies the area to which the interface is connected.
Example:
0.0.255.255 area 1
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 a given interface.
Example: The router identifier is displayed in the show mpls
Router(config-router)# mpls traffic-eng traffic-eng topology path command output.
router-id Loopback0
Note The interface-name value must be Loopback0.
6

Step 6 mpls traffic-eng area 0 Turns on MPLS traffic engineering for OSPF in area 0.
Note To display the MPLS TE global topology currently
Example: known at this node, use the show mpls traffic-eng
Router(config-router)# mpls traffic-eng area 0 topology command.
Step 7 mpls traffic-eng area number Configures a router running OSPF MPLS to flood traffic
engineering for the indicated OSPF area.
Example:
Router(config-router)# mpls traffic-eng area 2
Example:
Configuring OSPF for Non-ABR Routers

For each non-ABR that is running OSPF, perform the following steps to configure OSPF.
SUMMARY STEPS
1. enable
7. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router ospf process-id Enables OSPF and enters router configuration mode.
The process-id argument is an internally used identification
Example: parameter for the OSPF routing process. It is locally
Router(config)# router ospf 1 assigned and can be any positive integer. Assign a unique
value for each OSPF routing process.
7

Step 4 network ip-address wildcard-mask area area-id Specifies the interfaces on which OSPF is to run and
specifies the area to which the interface is connected.
Example:
255.255.255.0 area 1
node is the IP address associated with a given interface.
Example: The router identifier is displayed in the show mpls
Router(config-router)# mpls traffic-eng traffic-eng topology path command output.
router-id Loopback0
Note The interface-name value must be Loopback0.
Step 6 mpls traffic-eng area number Specifies the area that the router is in.
Router(config-router)# mpls traffic-eng area 1 topology command.
Example:
Configuring IS-IS for Interarea Tunnels

This section describes the following tasks:
Configuring IS-IS for Backbone Routers, page 8
Configuring IS-IS for Nonbackbone Routers, page 10
Configuring IS-IS for Interfaces, page 11
Configuring IS-IS for Backbone Routers

To configure IS-IS for background (level-1-2) routers, perform the following steps.
SUMMARY STEPS
1. enable
3. router isis
4. metric-style wide
5. net nn.nnnn.nnnn.nnnn.nnnn
7. mpls traffic-eng level-1
9. interface typeslot/port
10. ip router isis
8
11. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router isis Enables IS-IS routing and specifies an IS-IS process for IP,
and places the router in router configuration mode.
Example:
Step 4 metric-style wide Configures a router to generate and accept only new-style
type, length, value objects (TLVs).
Example:
Router(config-router)# metric-style wide
Step 5 net nn.nnnn.nnnn.nnnn.nnnn Configures the area ID (area address) and the system ID.
Example:
Router(config-router)# net
10.0000.0100.0000.0010
node is the IP address associated with interface Loopback0.
Example:
router-id Loopback0
Step 7 mpls traffic-eng level-1 Turns on MPLS traffic engineering for IS-IS at level 1.
Router(config-router)# mpls traffic-eng level-1 topology command.
Step 8 mpls traffic-eng level-2 Turns on MPLS traffic engineering for IS-IS at level 2.
Step 9 interface typeslot/port Configures an interface type and enters interface
configuration mode.
Example:
Router(config-router)# interface POS1/0
9

Step 10 ip router isis Enables IS-IS routing.
Specify this command on each interface on which you want
Example: to run IS-IS.
Example:
Configuring IS-IS for Nonbackbone Routers

To configure IS-IS for nonbackbone routers, perform the following steps.
SUMMARY STEPS
1. enable
3. router isis
7. mpls traffic-eng {level-1 | level-2}
8. end
DETAILED STEPS

Example:
Router> enable
Example:
and places the router in router configuration mode.
Example:
TLVs.
Example:
10

Example:
10.0000.2000.0100.0001
Example:
router-id Loopback0
Step 7 mpls traffic-eng {level-1 | level-2} Turns on MPLS traffic engineering for IS-IS at level 1.
Example:
Configuring IS-IS for Interfaces

To configure IS-IS for interfaces, perform the following steps.
SUMMARY STEPS
1. enable
3. router isis
8. ip router isis
9. end
11
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 the router in router configuration
Example: mode.
TLVs.
Example:
Example:
10.0000.0100.0000.0010
Example:
router-id Loopback0
Step 7 interface typeslot/port Specifies the interface and enters interface configuration
mode.
Example:
Router(config-router)# interface POS1/0
Step 8 ip router isis Enables IS-IS routing.
Specify this command on each interface on which you want
Example: to run IS-IS.
Example:
Configuring MPLS and RSVP to Support Traffic Engineering

To configure MPLS and RSVP to support traffic engineering on the routers, perform the following steps.
12
SUMMARY STEPS
1. enable
3. ip cef
4. mpls traffic-eng tunnels
6. ip address ip-address mask [secondary [vrf vrf-name]]
7. ip rsvp bandwidth
8. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef Enables Cisco Express Forwarding on the Route Processor
card.
Example:
Step 4 mpls traffic-eng tunnels Enables MPLS traffic engineering tunnel signaling on a
device.
Example:
Router(config)# mpls traffic-eng tunnels
mode.
Example:
Router(config)# interface Loopback0
Step 6 ip address ip-address mask [secondary [vrf Assigns an IP network address and network mask to the
vrf-name]] interface.
Example:
Router(config-if)# ip address
192.168.10.10 255.255.255.255
13

Step 7 ip rsvp bandwidth Enables RSVP for IP on an interface.
Example:
Router(config-if)# ip rsvp bandwidth
Example:
Configuring an MPLS Traffic Engineering Interarea Tunnel

Configuring an MPLS Traffic Engineering Interarea Tunnel to Use Explicit Paths, page 14
Configuring Explicit Paths, page 16
Configuring an MPLS Traffic Engineering Interarea Tunnel to Use Explicit Paths

To configure an MPLS traffic engineering interarea tunnel to use explicit paths, perform the following
steps.
SUMMARY STEPS
1. enable
3. interface tunnel-interface
7. tunnel mpls traffic-eng bandwidth bandwidth
8. tunnel mpls traffic-eng path-option number explicit {name path-name | identifier path-number}
[lockdown]
9. end
14
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel-interface Configures an interface type and enters interface
configuration mode.
Example:
Router(config)# interface Tunel1
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.
You must enter the MPLS traffic engineering router ID of
Example: the destination device.
192.168.20.20
engineering.
Example:
Step 7 tunnel mpls traffic-eng bandwidth bandwidth Configures the bandwidth required for the MPLS traffic
engineering tunnel.
Example:
bandwidth 300
Step 8 tunnel mpls traffic-eng path-option number Configures the tunnel to use a named IP explicit path or a
explicit {name path-name | identifier path dynamically calculated from the traffic engineering
path-number} [lockdown]
topology database.
The name keyword must specify the ABRs the tunnel LSP
Example: must traverse as loose hops via the next-address loose
command.
path-option 1 explicit name path-Tunnel1
Example:
15
Configuring Explicit Paths

To configure explicit paths, perform the following steps.
SUMMARY STEPS
1. enable
3. ip explicit-path name pathname
4. next-address [loose | strict] ip-address
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip explicit-path name pathname Enters IP explicit path configuration mode and creates or
modifies the specified path.
Example:
Router(config)# ip explicit-path name
path-tunnel1
Step 4 next-address [loose | strict] ip-address Specifies the next IP address in the explicit path.
In a next-address loose command you must specify each
Example: ABR the path must traverse.
Router(config-ip-expl-path)# next-address loose
192.168.40.40
Example:
Router(config-ip-expl-path)# end
Configuring an MPLS Traffic Engineering Tunnel with Autoroute Destination

To configure an MPLS traffic engineering tunnel with autoroute destination, perform the following steps.
UMMARY STEPS
1. enable
16
3. interface tunnel-interface
8. tunnel mpls traffic-eng path-option number explicit {name path-name | identifier path-number}
[lockdown]
9. tunnel mpls traffic-eng autoroute destination
10. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel-interface Configures an interface type and enters interface
configuration mode.
Example:
Router(config)# interface Tunnel1
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
You must enter the MPLS traffic engineering router ID of
Example: the destination device.
192.168.20.20
engineering.
Example:
Step 7 tunnel mpls traffic-eng bandwidth bandwidth Configures the bandwidth required for the MPLS traffic
engineering tunnel.
Example:
bandwidth 300
17
Configuration Examples for MPLS Traffic Engineering: Interarea Tunnels

Step 8 tunnel mpls traffic-eng path-option number Configures the tunnel to use a named IP explicit path or a
explicit {name path-name | identifier path dynamically calculated from the traffic engineering
path-number} [lockdown]
topology database.
The name keyword must specify the ABRs the tunnel LSP
Example: must traverse as loose hops via the next-address loose
command.
path-option 1 explicit name path-Tunnel1
Step 9 tunnel mpls traffic-eng autoroute destination Automatically routes traffic through a TE tunnel.
Example:
autoroute destination
Example:
Configuration Examples for MPLS Traffic Engineering: Interarea

Tunnels
This section shows how to configure MPLS traffic engineering interarea tunnels for the simple router
topology illustrated in Figure 2. It includes configuration fragments that illustrate the configurations
shown in the following sections:
Configuring OSPF for Interarea Tunnels: Example, page 19
Configuring IS-IS for Interarea Tunnels: Example, page 20
Configuring MPLS and RSVP to Support Traffic Engineering: Example, page 22
Configuring an MPLS Traffic Engineering Interarea Tunnel: Example, page 22
Configuring an MPLS Traffic Engineering Tunnel with Autoroute Destination: Example, page 23
18
Figure 2 Router Topology
loopback0 loopback0 loopback0

192.168.10.10 /255.255.255.0 192.168.30.30 /255.255.255.0 192.168.40.40 /255.255.255.0
pos2/0
192.168.45.2 /255.255.255.0
R1 Ra
pos1/0 Rx
192.168.35.1 /255.255.255.0 pos1/0
192.168.35.2 /255.255.255.0
pos3/0
192.168.55.1 /255.255.255.0
loopback0
192.168.50.50 /255.255.255.0
pos3/0
192.168.55.2 /255.255.255.0 pos2/0
192.168.45.1 /255.255.255.0
Ry
pos4/0
192.168.65.1 /255.255.255.0
pos4/0
192.168.65.2 /255.255.255.0
Rb Rz R2
pos5/0 pos6/0
146902
192.168.75.1 /255.255.255.0 pos5/0 192.168.85.1 /255.255.255.0 pos6/0
192.168.75.2 /255.255.255.0 192.168.85.2 /255.255.255.0
loopback0 loopback0 loopback0
192.168.60.60 /255.255.255.0 192.168.70.70 /255.255.255.0 192.168.20.20 /255.255.255.0
Configuring OSPF for Interarea Tunnels: Example

The following configuration fragments show how to configure OSPF for interarea tunnels assuming that:
Routers R1, Rx, and Ra are in OSPF Area 1
Routers Ra, Ry, and Rb are in OSPF Area 0
Routers Rb, Rz, and R2 are in OSPF Area 2
Router Ra is an ABR for Area 0 and Area 1
Router Rb is an ABR for Area 0 and Area 2
Router R1 OSPF Configuration

router ospf 1
network 192.168.10.10 0.0.0.0 area 1
network 192.168.35.0 0.0.0.255 area 1
mpls traffic-eng router-id Loopback0
mpls traffic-eng area 1
Router Rx OSPF Configuration

router ospf 1
network 192.168.30.30 0.0.0.0 area 1
network 192.168.35.0 0.0.0.255 area 1
network 192.168.45.0 0.0.0.255 area 1
19
Router Ra OSPF Configuration

Ra is an ABR for Area 0 and Area 1. Interface POS2/0 is in Area 1 and interface POS3/0 is in Area 0.
The mpls traffic-eng area commands configure Ra for IGP TE updates for both areas.
router ospf 1
network 192.168.40.40 0.0.0.0 area 0
network 192.168.45.0 0.0.0.255 area 1
network 192.168.55.0 0.0.0.255 area 0
Router Rb OSPF Configuration

Rb is an ABR for Area 0 and Area 2. Interface POS4/0 is in Area 0 and interface POS5/0 is in Area 2.
The mpls traffic-eng area commands configure Rb for IGP TE updates for both areas.
router ospf 1
network 192.168.60.60 0.0.0.0 area 0
network 192.168.65.0 0.0.0.255 area 0
network 192.168.75.0 0.0.0.255 area 2
Router Rz OSPF Configuration

router ospf 1
network 192.168.70.70 0.0.0.0 area 2
network 192.168.75.0 0.0.0.255 area 2
network 192.168.85.0 0.0.0.255 area 2
Router R2 OSPF Configuration

router ospf 1
network 192.168.20.20 0.0.0.0 area 2
network 192.168.85.0 0.0.0.255 area 2
Configuring IS-IS for Interarea Tunnels: Example

The following configuration fragments illustrate how to configure IS-IS for interarea tunnels assuming
that:
R1 and Rx are level-1 routers
Ra, Ry, and Rb are level-1-2 routers
Rz and R2 are level-1 routers
Router R1 IS-IS Configuration

interface POS1/0
ip router isis
router isis
metric-style wide
net 10.0000.0100.0000.0010
mpls traffic-eng level-1
20
Router Rx IS-IS Configuration

clns routing
interface POS1/0
ip router isis
interface POS2/0
ip router isis
router isis
metric-style wide
net 10.0000.2000.0100.0001
Router Ra IS-IS Configuration

clns routing
interface POS2/0
ip router isis
interface POS3/0
ip router isis
router isis
metric-style wide
net 10.0000.2000.0200.0002
Router Ry IS-IS Configuration

clns routing
interface POS3/0
ip router isis
interface POS4/0
ip router isis
router isis
metric-style wide
net 10.0000.2000.0300.0003
Router Rb IS-IS Configuration

clns routing
interface POS4/0
ip router isis
interface POS5/0
ip router isis
router isis
metric-style wide
net 10.0000.2000.0400.0004
Router Rz IS-IS Configuration

clns routing
interface POS5/0
ip router isis
interface POS6/0
ip router isis
router isis
metric-style wide
net 10.0000.2000.0500.0005
21
Router R2 IS-IS Configuration

clns routing
interface POS6/0
ip router isis
router isis
metric-style wide
net 10.0000.0200.0000.0020
Configuring MPLS and RSVP to Support Traffic Engineering: Example

The following configuration fragments show how to configure MPLS and RSVP to support traffic
engineering on the routers.
Router R1 Traffic Engineering Configuration

ip cef
mpls traffic-eng tunnels
interface Loopback0
ip address 192.168.10.10 255.255.255.255
interface POS1/0
!Each interface supporting MPLS TE must include the following:
ip rsvp bandwidth
The configuration of routers Rx, Ra, Ry, Rb, Rz, and R2 for traffic engineering operation
is similar to that for R1.
Configuring an MPLS Traffic Engineering Interarea Tunnel: Example

The following configuration fragments show how to configure an MPLS traffic engineering interarea
tunnel. Tunnel1 is configured with a path option that is loosely routed through Ra and Rb.
R1 Interarea Tunnel Configuration

The following commands configure an MPLS TE tunnel to use explicit paths:
interface Tunnel1
tunnel mpls traffic-eng path-option 1 explicit name path-tunnel1
The following commands configure an explicit path:

ip explicit-path name path-tunnel1
next-address loose 192.168.40.40
next-address loose 192.168.60.60
next-address loose 192.168.20.20 !Specifying the tunnel tailend in the loosely routed
!path is optional.
22
Note Generally for an interarea tunnel you should configure multiple loosely routed path options that specify
different combinations of ABRs (for OSPF) or level-1-2 boundary routers (for IS-IS) to increase the
likelihood that the tunnel will be successfully signaled. In this simple topology there are no other loosely
routed paths.
Configuring an MPLS Traffic Engineering Tunnel with Autoroute Destination:

Example
The following example shows how to configure an MPLS TE tunnel with autoroute destination:
interface Tunnel103
tunnel mpls traffic-end path-option 1 explicit name 111-103
tunnel mpls traffic-eng autoroute destination
The following sections provide references related to the MPLS Traffic Engineering: Interarea Tunnels
feature.
Related Documents
IS-IS Integrated IS-IS Routing Protocol Overview
Cisco IOS IP Routing Protocols Command Reference
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
Standards
Standard Title
23
MIBs
MIB MIBs Link
modified by this feature following URL:
RFCs
RFC Title
Description Link
24
Feature Information for MPLS Traffic Engineering: Interarea Tunnels
Feature Information for MPLS Traffic Engineering: Interarea

Tunnels
http://www.cisco.com/go/cfn. An account on Cisco.com is not required
Table 1 Feature Information for MPLS Traffic Engineering: Interarea Tunnels

MPLS Traffic Engineering: Interarea 12.0(19)ST1 The MPLS Traffic Engineering: Interarea Tunnels feature
Tunnels 12.0(21)ST allows you to establish MPLS TE tunnels that span multiple
12.2(18)S IGP areas and levels, removing the restriction that had
12.2(18)SXD required the tunnel headend and tailend routers both to be in
12.2(27)SBC the same area.
12.2(28)SB
In 12.0(19)ST1, this feature was introduced.
12.2(33)SRB
12.4(20)T In 12.0(21)ST, support was added for the Cisco 10000 series
12.2(33)SRE routers.
In 12.2(18)SXD, this feature was integrated.
In 12.2(27)SBC, this feature was integrated.
In 12.2(33)SRB, support was added for stateful switchover
(SSO) recovery of LSPs that include loose hops.
In 12.4(20)T, support was eliminated for SSO recovery of
LSPs that include loose hops.
In 12.2(33)SRE, the autoroute destination feature was added.
The following commands were added or modified: show ip
static route, show mpls traffic-eng autoroute, show mpls
traffic-eng tunnels, and tunnel mpls traffic-eng autoroute
destination.
25
Glossary
Glossary
ABRArea Border Router. A router connecting two areas. In OSPF, ABRs belong to both areas and
must maintain separate topological databases for each. When an OSPF router has interfaces in more than
one area, it is an Area Border Router.
areaA logical set of network segments (for example, one that is OSPF-based) and their attached
devices. Areas usually are connected to other areas by routers, making up a single autonomous system.
OSPF and IS-IS define their areas differently. OSPF area borders are marked by routers. Some interfaces
are in one area, and other interfaces are in another area. With IS-IS, all the routers are completely within
an area, and the area borders are on links, not on routers. The routers that connect the areas are level-2
routers, and routers that have no direct connectivity to another area are level-1 routers.
area IDIn an IS-IS router, this area address is associated with the entire router rather than an interface.
A router can have up to three area addresses. Both the area ID and the system ID are defined on an IS-IS
router by a single address, the Network Entry Title (NET).
autonomous systemA collection of networks under a common administration sharing a common
routing strategy. Autonomous systems are subdivided by areas.
optimizes network performance and scalability for networks that have large and dynamic traffic patterns,
such as the Internet, and for networks characterized by intensive Web-based applications or interactive
sessions. Cisco Express Forwarding uses a Forwarding Information Base (FIB) to make IP destination
prefix-based switching decisions. The FIB is conceptually similar to a routing table or information base.
When routing or topology changes occur in the network, the IP routing table is updated, and those
changes are reflected in the FIB. The FIB maintains next-hop address information based on the
information in the IP routing table.
headendThe upstream, transmit end of a tunnel. The router that originates and maintains the traffic
engineering LSP.
autonomous system. Examples of common IGPs include OSPF and Routing Information Protocol (RIP).
interarea TEAbility for a traffic engineering LSP to span multiple areas.
IS-ISIntermediate 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 the network topology.
label switched path (LSP) tunnelA configured connection between two routers in which label
switching is used to carry the packets.
level-1 routersRouters that are directly connected to other areas. The routers are not in the backbone.
MPLS does not run in the background. These routers are also called internal routers.
level-2 routersRouters that connect two areas. These routers let you run MPLS in the background.
load balancingThe distribution of traffic among multiple paths to the same destination so that the
router uses bandwidth efficiently. Load balancing increases the use of network segments, thus increasing
effective network bandwidth.
LSPlabel switched path. A sequence of hops such as 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
maskA bit combination used to describe which part of an address refers to the network or the subnet
and which part refers to the host.
26
Glossary
OSPFOpen Shortest Path First. Link-state, hierarchical 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.
process IDDistinguishes one process from another within the device. An OSPF process ID can be any
positive integer, and it has no significance outside the router on which it is configured.
other routers. For example, an IP address from one of the routers interfaces.
static routingA static route is a fixed path preprogrammed by a network administrator. Static routes
cannot make use of routing protocols and dont self-update after receipt of routing update messages; they
must be updated by hand.
tailendThe downstream, receive end of a tunnel. The router that terminates the traffic engineering
LSP.
traffic engineeringThe techniques and processes that cause routed traffic to travel through the
tunnel is 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.
virtual linkOrdinarily, each area is directly connected to area 0. A virtual link is used for a connection
when an area is connected to an area that is one area away from area 0.
coincidental.
27
Glossary
28
MPLS TE: Bundled Interface Support

Last Updated: December 27, 2007
The MPLS TE: Bundled Interface Support feature enables Multiprotocol Label Switching (MPLS)
traffic engineering (TE) tunnels over the bundled interfaces EtherChannel and Multilink PPP (MLP).
The Resource Reservation Protocol (RSVP) notifies TE about bandwidth changes that occur when
member links are added or deleted, or when links become active or inactive. TE notifies other nodes in
the network via IGP flooding. By default, the bandwidth available to TE LSPs is 75% of the interface
bandwidth. You can change the percentage of the global bandwidth available for TE LSPs by using an
RSVP command on the bundled interface. Bandwidth reservation and preemption are supported.
The Fast Reroute (FRR) feature is supported on the bundled interfaces. FRR is activated when a bundled
interface goes down: for example, if you enter the shut command to shut down the interface, or fewer
than the required minimum number of links are operational.

latest feature information and caveats, see the release notes for your Cisco IOS software release. To
feature is supported, use the Feature Information for MPLS TE: Bundled Interface Support section on
page 10.
Contents
Prerequisites for MPLS TE: Bundled Interface Support, page 2
Restrictions for MPLS TE: Bundled Interface Support, page 2

Prerequisites for MPLS TE: Bundled Interface Support
Information About MPLS TE: Bundled Interface Support, page 2

How to Configure MPLS TE: Bundled Interface Support, page 4
Configuration Examples for MPLS TE: Bundled Interface Support, page 7
Feature Information for MPLS TE: Bundled Interface Support, page 10
Glossary, page 11
Prerequisites for MPLS TE: Bundled Interface Support

Configure MPLS TE tunnels.
Enable Cisco Express Forwarding in global configuration mode.
Enable RSVP.
Configure EtherChannel.
Configure MLP.
Restrictions for MPLS TE: Bundled Interface Support

Traffic engineering over Service Virtual Interfaces (SVIs) is not supported unless the SVI consists
of a bundle of links that represent a single point-to-point interface.
There must be a valid IP address configuration on the bundled interface and there must not be an IP
address configuration on the member links.
To ensure that the Fast Reroute feature functions correctly in MLP, enter the multilink min-links
command (to specify the preferred minimum number of links) along with the mandatory keyword
(to deactivate the MLP bundle if the minimum number of links is not present).
Information About MPLS TE: Bundled Interface Support

To configure the MPLS TE: Bundled Interface Support feature, you should understand the following
concepts:
MLP Overview, page 2
Cisco EtherChannel Overview, page 3
Load Balancing and Min-Links in MLP and EtherChannel, page 4
MLP Overview
MLP provides the capability of splitting and recombining packets to a single end system across a logical
pipe (also called a bundle) formed by multiple links. MLP provides bandwidth on demand and reduces
transmission latency across WAN links.
2
Information About MPLS TE: Bundled Interface Support
MLP allows packets to be fragmented and the fragments to be sent at the same time over multiple
point-to-point links to the same remote address. The multiple links come up in response to a dialer load
threshold that you define. The load can be calculated on inbound traffic, outbound traffic, or on either,
as needed for the traffic between the specific sites. MLP provides bandwidth on demand and reduces
transmission latency across WAN links.
MLP is designed to work over single or multiple interfaces of the following types that are configured to
support both dial-on-demand rotary groups and PPP encapsulation:
Asynchronous serial interfaces
Basic Rate Interfaces
Primary Rate Interfaces
Cisco EtherChannel Overview

Cisco EtherChannel technology builds upon standards-based 802.3 full-duplex Fast Ethernet to provide
network managers with a reliable, high-speed solution for the campus network backbone. EtherChannel
technology provides bandwidth scalability within the campus by providing up to 800 Mbps, 8 Gbps, or
80 Gbps of aggregate bandwidth for a Fast EtherChannel, Gigabit EtherChannel, or 10 Gigabit
EtherChannel connection, respectively. Each of these connection speeds can vary in amounts equal to
the speed of the links used (100 Mbps, 1 Gbps, or 10 Gbps). Even in the most bandwidth-demanding
situations, EtherChannel technology helps aggregate traffic and keep oversubscription to a minimum,
while providing effective link-resiliency mechanisms.
Cisco EtherChannel Benefits

Cisco EtherChannel technology allows network managers to provide higher bandwidth among servers,
routers, and switches than single-link Ethernet technology can provide.
Cisco EtherChannel technology provides incremental scalable bandwidth and the following benefits:
Standards-basedCisco EtherChannel technology builds upon IEEE 802.3-compliant Ethernet by
grouping multiple, full-duplex point-to-point links. EtherChannel technology uses IEEE 802.3
mechanisms for full-duplex autonegotiation and autosensing, when applicable.
Flexible incremental bandwidthCisco EtherChannel technology provides bandwidth aggregation
in multiples of 100 Mbps, 1 Gbps, or 10 Gbps, depending on the speed of the aggregated links. For
example, network managers can deploy EtherChannel technology that consists of pairs of
full-duplex Fast Ethernet links to provide more than 400 Mbps between the wiring closet and the
data center. In the data center, bandwidths of up to 800 Mbps can be provided between servers and
the network backbone to provide large amounts of scalable incremental bandwidth.
Load balancingCisco EtherChannel technology comprises several Fast Ethernet links and is
capable of load balancing traffic across those links. Unicast, broadcast, and multicast traffic is
evenly distributed across the links, providing improved performance and redundant parallel paths.
When a link fails, traffic is redirected to the remaining links within the channel without user
intervention and with minimal packet loss.
Resiliency and fast convergenceWhen a link fails, Cisco EtherChannel technology provides
automatic recovery by redistributing the load across the remaining links. When a link fails,
Cisco EtherChannel technology redirects traffic from the failed link to the remaining links in less
than one second. This convergence is transparent to the end userno host protocol timers expire,
so no sessions are dropped.
3
How to Configure MPLS TE: Bundled Interface Support
Load Balancing and Min-Links in MLP and EtherChannel

Load balancing affects the actual and practical bandwidth that can be used for TE. Multilink load
balancing uses a per-packet load balancing method. All of the bundle interface bandwidth is available.
EtherChannel load balancing has various load balancing methods, depending on the traffic pattern and
the load balancing configuration. The total bandwidth available for TE may be limited to the bandwidth
of a single member link.
Min-links affects how FRR works. Multilink PPP Minimum Links (min-links) allows you to configure
the minimum number of links in an MLP bundle required to keep that bundle active. To configure
min-links for MLP, use the multilink min-links command. It is recommended that you specify the
mandatory keyword. To use FRR, you must specify the mandatory keyword. On EtherChannel,
min-link is supported only in the Link Aggregation Control Protocol (LACP). For other EtherChannel
protocols, the minimum is one link, by default, and it is not configurable. To configure min-link for
EtherChannel, use the port-channel min-links command.

Configuring MPLS TE on an MLP Interface, page 4 (required)
Configuring MPLS TE on an EtherChannel Interface, page 6 (required)
Configuring MPLS TE on an MLP Interface

To configure MPLS TE on an MLP interface, perform the following steps.
SUMMARY STEPS
1. enable
3. interface type number [name-tag]
4. ip address ip-address mask [secondary]
6. mpls traffic-eng backup-path tunnel
7. ppp multilink [ppp]
8. multilink min-links links [mandatory]
9. multilink-group group-number
10. ip rsvp bandwidth [interface-kbps] [single-flow-kbps]
11. keepalive [period [retries]]
12. end
4
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number [name-tag] Creates a multilink bundle, assigns a group number to the
bundle, and enters interface configuration mode.
Example:
Router(config)# interface multilink 1
Step 4 ip address ip-address mask [secondary] Specifies an IP address for the multilink group.
Example:
255.255.255.0
Step 5 mpls traffic-eng tunnels Enables MPLS traffic engineering tunnel signaling on an
interface (assuming that it is enabled on the device).
Example:
Router(config-if)# mpls traffic-eng tunnels
Step 6 mpls traffic-eng backup-path tunnel (Optional) Enables FRR.
Example:
Router(config-if)# mpls traffic-eng backup-path
Tunnel50
Step 7 ppp multilink [ppp] Enables MLP on an interface and, optionally, enables
Bandwidth Allocation Control Protocol (BACP) and its
Bandwidth Allocation Protocol (BAP) subset for dynamic
Example:
Router(config-if)# ppp multilink
bandwidth allocation.
Step 8 multilink min-links links [mandatory] Specifies the preferred minimum number of links in an
MLP bundle.
Example: Note To use FRR, you must enter the mandatory
Router(config-if)# multilink min-links 2 keyword.
mandatory
Step 9 multilink-group group-number Restricts a physical link to joining only a designated
multilink-group interface.
Example:
Router(config-if)# multilink-group 1
Step 10 ip rsvp bandwidth [interface-kbps] Enables RSVP for IP on an interface and specifies a
[single-flow-kbps] percentage of the total interface bandwidth as available in
the RSVP bandwidth pool.
Example:
Router(config-if)# ip rsvp bandwidth 100
5

Step 11 keepalive [period [retries]] Enables keepalive packets and specifies the number of times
that the Cisco IOS software tries to send keepalive packets
without a response before bringing down the interface or
Example:
Router(config-if)# keepalive 3
before bringing the tunnel protocol down for a specific
interface.
Step 12 end Returns to global configuration mode.
Example:
Configuring MPLS TE on an EtherChannel Interface

To configure MPLS TE on an EtherChannel interface, perform the following steps.
SUMMARY STEPS
1. enable
3. interface type number [name-tag]
6. mpls traffic-eng backup-path tunnel
7. port-channel min-links min-num
8. ip rsvp bandwidth [interface-kbps] [single-flow-kbps]
9. end
6
Configuration Examples for MPLS TE: Bundled Interface Support
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type number [name-tag] Creates an EtherChannel bundle, assigns a group number to
the bundle, and enters interface configuration mode.
Example:
Router(config)# interface port-channel 1
Step 4 ip address ip-address mask [secondary] Specifies an IP address for the EtherChannel group.
Example:
255.255.255.0
Step 5 mpls traffic-eng tunnels Enables MPLS TE tunnel signaling on an interface
(assuming that it is enabled on the device).
Example:
Step 6 mpls traffic-eng backup-path tunnel (Optional) Enables FRR.
Example:
Tunnel120
Step 7 port-channel min-links min-num Specifies that a minimum number of bundled ports in an
EtherChannel is required before the channel can be active.
Example:
Router(config-if)# port-channel min-links 2
Step 8 ip rsvp bandwidth [interface-kbps] Enables RSVP for IP on an interface and specifies a
[single-flow-kbps] percentage of the total interface bandwidth as available in
the RSVP bandwidth pool.
Example:
Router(config-if)# ip rsvp bandwidth 100
Step 9 end Returns to global configuration mode.
Example:
Configuration Examples for MPLS TE: Bundled Interface Support

7
Configuring MPLS TE on an MLP Interface: Example, page 8

Configuring MPLS TE on an EtherChannel Interface: Example, page 8
Configuring MPLS TE on an MLP Interface: Example

The following example shows how to configure MPLS TE on an MLP interface:
interface multilink 1
ip address 10.0.0.7 255.255.255.0
mpls traffic-eng backup-path Tunnel50
ppp multilink
multilink min-links 2 mandatory
multilink-group 1
ip rsvp bandwidth 100
keepalive 3
Configuring MPLS TE on an EtherChannel Interface: Example

The following example shows how to configure MPLS TE on an EtherChannel interface:
interface port-channel 1
ip address 10.0.0.4 255.255.255.0
port-channel min-links 2
The following sections provide references related to the MPLS TE: Bundled Interface Support feature.
Related Documents
Configuring EtherChannel Configuring EtherChannels
EtherChannel Load Balancing Configuring EtherChannels
8
Command Reference
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
Description Link
Command Reference
This feature uses no new or modified commands.
9
Feature Information for MPLS TE: Bundled Interface Support
Feature Information for MPLS TE: Bundled Interface Support

Table 1 Feature Information for MPLS TE: Bundled Interface Support

MPLS TE: Bundled Interface Support 12.2(33)SRC The MPLS TE: Bundled Interface Support feature enables
MPLS traffic engineering (TE) tunnels over the bundled
interfaces EtherChannel and Multilink MLP.
In 12.2(33)SRC, this feature was introduced.
10
Glossary
Glossary
bundleA group of interfaces that comprise an aggregate interface; for example, MLP and
EtherChannel.
Cisco Express ForwardingA 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.
EtherChannelEtherChannel is a trunking technology that groups multiple full-duplex 802.3 Ethernet
interfaces to provide fault-tolerant high-speed links between switches, routers, and servers.
EtherChannel is a logical aggregation of multiple Ethernet interfaces. EtherChannel forms a single
higher bandwidth routing or bridging endpoint.
Fast EtherChannelFast EtherChannel is a technology-leveraging, standards-based Fast Ethernet that
provides the additional bandwidth network backbones require today. It provides flexible, scalable
bandwidth with resiliency and load sharing across links for switches, router interfaces, and servers. It
supports up to eight links per channel.
Gigabit EtherChannelGigabit EtherChannel is high-performance Ethernet technology that provides
gigabit per second transmission rates. It provides flexible, scalable bandwidth with resiliency and load
sharing across links for switches, router interfaces, and servers. It supports up to eight links per channel.
member linkAn interface that is part of a bundle.
min-linksMinimum number of links in an MLP bundle.
MLPMultilink PPP provides load balancing functionality over multiple WAN links, while providing
multivendor interoperability, packet fragmentation, proper sequencing, and load calculation on both
inbound and outbound traffic.
MPLSMultiprotocol Label Switching. Switching method that forwards IP traffic using a label. This
PPPPoint-to-Point Protocol. A successor to SLIP that provides router-to-router and host-to-network
connections over synchronous and asynchronous circuits. PPP was designed to work with several
network layer protocols (such as IP, IPX, and ARA). PPP also has built-in security mechanisms (such as
CHAP and PAP). PPP relies on two protocols: LCP and NCP.
RSVPResource Reservation Protocol. 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
(bandwidth, jitter, maximum burst, and so on) of the packet streams they want to receive. RSVP depends
on IPv6. Also known as Resource Reservation Setup Protocol.
traffic engineeringTechniques 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.
CCVP, the Cisco logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn
is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco,
the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient,
IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX, Networking
Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Your Internet Quotient, and
TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
11
Glossary
coincidental.
12
MPLS Traffic Engineering (TE)Automatic
Bandwidth Adjustment for TE Tunnels

The MPLS Traffic Engineering (TE)Automatic 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.

supported, see the Feature Information for MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels
section on page 19.
Contents
Prerequisites for MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels, page 2
Restrictions for MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels, page 2
Information About MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels, page 2
How to Configure MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels, page 3
Configuration Examples for MPLS TEAutomatic Bandwidth Adjustments for TE Tunnels,
page 15
MPLS Traffic Engineering (TE)Automatic Bandwidth Adjustment for TE Tunnels
Prerequisites for MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels

Feature Information for MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels, page 19
Prerequisites for MPLS TEAutomatic Bandwidth Adjustment

for TE Tunnels
Your network must support the following:
Multiprotocol Label Switching (MPLS) traffic engineering (TE) tunnels
Cisco Express Forwarding
Intermediate System-to-Intermediate System (IS-IS) or Open Shortest Path First (OSPF)
MPLS TE must be configured on the interface and on the tunnels.
Restrictions for MPLS TEAutomatic 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 TEAutomatic Bandwidth Adjustment

for TE Tunnels
Before you configure the MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels feature, you
should understand the following:
MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels Overview, page 2
MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels Benefits, page 3
MPLS TEAutomatic 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 tunnels allocated bandwidth to be the largest sample for the tunnel since the last adjustment.
2
How to Configure MPLS TEAutomatic 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 TEAutomatic Bandwidth Adjustment for TE Tunnels Benefits

The automatic bandwidth feature allows you to configure and monitor the bandwidth for MPLS TE
tunnels. If automatic bandwidth is configured for a tunnel, TE automatically adjusts the tunnels
bandwidth.
How to Configure MPLS TEAutomatic Bandwidth Adjustment

for TE Tunnels
This section contains the following tasks to configure MPLS TE automatic bandwidth adjustment for TE
tunnels:
Configuring a Device 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 a Tunnel Crosses, page 6 (required)
Configuring Bandwidth on Each Link That a Tunnel Crosses, page 6 (required)
Enabling Automatic Bandwidth Adjustment on a Platform, page 10 (required)
Enabling Automatic Bandwidth Adjustment for a Tunnel, page 11 (required)
Configuring the Interval for Computing the Tunnel Average Output Rate, page 12 (optional)
Verifying Automatic Bandwidth Configuration, page 13 (optional)
Configuring a Device to Support Traffic Engineering Tunnels

To configure a device to support TE tunnels, perform the following task.
SUMMARY STEPS
1. enable
3. ip cef distributed
5. exit
3
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef distributed Enables distributed Cisco Express Forwarding operation.
Example:
Router(config)# ip cef distributed
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 IS-IS or OSPF for MPLS TE:
Configuring IS-IS for MPLS Traffic Engineering, page 4 (optional)
Configuring OSPF for MPLS Traffic Engineering, page 5 (optional)
Configuring IS-IS for MPLS Traffic Engineering

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

Example:
Router> enable
Example:
and enters router configuration mode.
Example:
Step 4 mpls traffic-eng level-1 Turns on MPLS TE 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 TE router identifier for the node is the IP
address associated with interface loopback0.
Example:
router-id loopback0
type, length, value objects (TLVs).
Example:
Example:
Example:
Configuring OSPF for MPLS Traffic Engineering

To configure OSPF for MPLS TE, perform the following task.
SUMMARY STEPS
1. enable
5

5. mpls traffic-eng router-id loopback0
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 value for the process-id argument is an internally
Router(config)# router ospf 200 used 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 Turns on MPLS TE for the indicated OSPF area.
Example:
Router(config-router)# mpls traffic-eng area 0
Step 5 mpls traffic-eng router-id loopback0 Specifies that the TE router identifier for the node is the IP
address associated with interface loopback0.
Example:
router-id loopback0
Example:
Example:
Configuring Bandwidth on Each Link That a Tunnel Crosses

To configure bandwidth on each link that a tunnel crosses, perform the following task.
6
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:
configuration mode.
Example:
Router(config)# interface FastEthernet 0/0/0
Step 4 mpls traffic-eng tunnels Enables MPLS TE tunnels on an interface.
Example:
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 10000000.
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 10000000.
Example:
Example:
7
Configuring an MPLS Traffic Engineering Tunnel

To configure an MPLS TE tunnel, perform the following task. The MPLS TE tunnel has two path setup
options: a preferred explicit path and a backup dynamic path.
Note The configuration applies only to the TE head-end node. The configuration applies to all nodes
and interfaces in the network.
SUMMARY STEPS
1. enable
8. tunnel mpls traffic-eng path-option [protect] preference-number {dynamic | explicit | {name
path-name | path-number}} [lockdown]
9. exit
10. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel number Configures a 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: An MPLS TE tunnel interface should be unnumbered
Router(config-if)# ip unnumbered loopback 0 because it represents a unidirectional link.
Note This command is not effective until Lookback0 has
been configured with an IP address.
8

The destination must be the MPLS TE router ID of the
Example: destination device.
Step 6 tunnel mode mpls traffic-eng Sets the encapsulation mode of the tunnel to MPLS TE.
Example:
Step 7 tunnel mpls traffic-eng bandwidth bandwidth Configures the bandwidth for the MPLS TE tunnel.
The bandwidth argument is the bandwidth, in kilobits
Example: per second, set for the MPLS TE tunnel. The range is
Router(config-if)# tunnel mpls traffic-eng from 1 to 4294967295. The default is 0.
bandwidth 250
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 tunnels 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
preference-number {dynamic | explicit | {name path dynamically calculated from the TE topology database.
path-name | path-number}} [lockdown]
A dynamic path is used if an explicit path is currently
unavailable.
Example:
path-option 10 explicit avoid-protected-link
Example:
Example:
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.
9
Enabling Automatic Bandwidth Adjustment on a Platform

To enable automatic bandwidth adjustment on a platform and initiate sampling the output rate for tunnels
configured for bandwidth adjustment, perform the following task.
Note This task is applicable only to the TE head-end router. The configuration applies to all
locally-configured TE head-end interfaces.
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:
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 trafficeng autobw 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.
10

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 trafficeng autobw output rate sampling and bandwidth adjustment for
timers tunnels. In addition, the no form of the command
restores the configured bandwidth for each tunnel
where the 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 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:
Enabling 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 [collect-bw] [frequency seconds] [adjustment-threshold
percent] [overflow-limit number overflow-threshold percent] [max-bw kbps] [min-bw kbps]
5. exit
6. exit
11
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 tunnel mpls traffic-eng auto-bw [collect-bw] Enables automatic bandwidth adjustment for the tunnel and
[frequency seconds] [adjustment-threshold controls the manner in which the bandwidth for a tunnel is
percent] [overflow-limit number
overflow-threshold percent] [max-bw kbps]
adjusted.
[min-bw kbps]
Example:
auto-bw max-bw 2000 min-bw 1000
Example:
Example:
Configuring the Interval for Computing the Tunnel Average Output Rate
To specify the interval for computing the average output rate for an MPLS TE 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.
Example:
Example:
Verifying Automatic Bandwidth Configuration

To verify the automatic bandwidth configuration, perform the following task.
SUMMARY STEPS
1. show mpls traffic-eng tunnels

2. show running-config
DETAILED STEPS
Step 1 show mpls traffic-eng tunnels

Use this command to display 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.4
13
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:13 kbps (Global) Priority:7 7 Affinity:0x0/0xFFFF
AutoRoute: disabled LockDown:disabled Loadshare:13 bw-based
auto-bw:(300/265) 53 Bandwidth Requested: 13
Adjustment threshold: 5%
Overflow Limit: 4 Overflow Threshold: 25%
Overflow Threshold Crossed: 1
Sample Missed: 1 Samples Collected: 1
State: dynamic path option 1 is active
InLabel : -
RSVP Path Info:
Explicit Route: 10.105.0.2 104.105.0.1 10.0.0.4
Record Route: NONE
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Path Weight: 128 (TE)
Explicit Route: 10.105.0.2 104.105.0.1 10.0.0.4
History:
Tunnel:
Number of LSP IDs (Tun_Instances) used: 2
Number of Auto-bw Adjustment resize requests: 1
Time since last Auto-bw Adjustment resize request: 1 minutes, 7 seconds
Number of Auto-bw Overflow resize requests: 1
Time since last Auto-bw Overflow resize request: 52 seconds
Current LSP:
Uptime: 52 seconds
Selection: reoptimization
Prior LSP:
ID: path option 1 [1]
Removal Trigger: configuration changed
In the command output:

The auto-bw line indicates that automatic bandwidth adjustment is enabled for the tunnel.
300 is the time, in seconds, between bandwidth adjustments.
265 is the time, in seconds, remaining until the next bandwidth adjustment.
53 is the largest bandwidth sample since the last bandwidth adjustment.
13 is the last bandwidth adjustment and the bandwidth currently requested for the tunnel.
The adjustment threshold is 5 percent.
The overflow limit is 4.
The overflow threshold is 25 percent.
14
Configuration Examples for MPLS TEAutomatic Bandwidth Adjustments for TE Tunnels
The overflow crossed is 1.
Step 2 show running-config

Use this command to verify that the tunnel mpls traffic-eng auto bw command is as you expected. For
example:
.
.
.
interface tunnel1
tunnel destination 192.168.17.17 255.255.255.0
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.
Configuration Examples for MPLS TEAutomatic 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 TE tunnels originating on Router 1
and to enable automatic bandwidth adjustment for Tunnel 1.
15
Configuration Examples for MPLS TEAutomatic Bandwidth Adjustments for TE Tunnels
Figure 1 Sample MPLS Traffic Engineering Tunnel Configuration
Router 3
192.168.12.12 /255.255.255.0
192
0
55.
.16
2
55.
S1/1
8.3
S1/0
.1
5.2
.2
6.0
/25
/25
Tun
2
5.0
5.2
nel
nel
8.3
55.
Tun
2
.16
255
192
.0
S1/3 S1/1 192.168.33.0 /255.255.255.0
.1 .2
Tunnel 2 S1/2 .1 Tunnel 2 .2
146900
S1/0
S1/0 S1/0 S1/3 S1/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
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 16
Tunnel Configuration for Automatic Bandwidth: Example, page 16
The examples omit some configuration required for MPLS TE, 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
!
ip cef distributed
mpls traffic-eng auto-bw timers frequency 600 !Enable automatic bandwidth adjustment
interface loopback 0
ip address 192.168.11.11 255.255.255.0
Tunnel Configuration for Automatic Bandwidth: Example

The following example shows how to use the tunnel mpls traffic-eng auto-bw command to enable
automatic bandwidth adjustment for Tunnel 1. 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
16

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 EngineeringAutomatic
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
MIBs
MIB MIBs Link
MPLS Traffic Engineering MIB To locate and download MIBs for selected platforms, Cisco IOS
following URL:
RFCs
RFC Title
modified.
17
Description Link
18
Feature Information for MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels
Feature Information for MPLS TEAutomatic Bandwidth

Adjustment for TE Tunnels
Table 1 Feature Information for MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels

MPLS Traffic Engineering (TE)Automatic Release 12.2(33)SRE The MPLS Traffic Engineering
Bandwidth Adjustment for TE Tunnels (TE)Automatic 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.
The following commands were introduced or
modified to support automatic bandwidth
adjustment threshold and overflow threshold:
mpls traffic-eng lsp attributes, show mpls
traffic-eng tunnels, and tunnel mpls
traffic-eng auto-bw.
19
Feature Information for MPLS TEAutomatic Bandwidth Adjustment for TE Tunnels
countries.
20
MPLS Point-to-Multipoint Traffic Engineering

The MPLS Point-to-Multipoint Traffic Engineering feature enables you to forward Multiprotocol Label
Switching (MPLS) traffic from one source to multiple destinations.

supported, see the Feature Information for MPLS Point-to-Multipoint Traffic Engineering section on
page 34.
Contents
Prerequisites for MPLS Point-to-Multipoint Traffic Engineering, page 2
Restrictions for MPLS Point-to-Multipoint Traffic Engineering, page 2
Information About MPLS Point-to-Multipoint Traffic Engineering, page 3
How to Configure MPLS Point-to-Multipoint Traffic Engineering, page 13
Configuration Examples for MPLS Point-to-Multipoint Traffic Engineering, page 24
Glossary, page 31
Feature Information for MPLS Point-to-Multipoint Traffic Engineering, page 34
Prerequisites for MPLS Point-to-Multipoint Traffic Engineering
Prerequisites for MPLS Point-to-Multipoint Traffic Engineering

Before configuring the MPLS Point-to-Multipoint Traffic Engineering (P2MP TE) feature, configure
Resource Reservation Protocol (RSVP) and traffic engineering features on the headend, midpoint, and
tailend routers in the MPLS network.
Restrictions for MPLS Point-to-Multipoint Traffic Engineering

The following functionality is not supported:
Interior Gateway Protocol (IGP) extensions for P2MP TE signaling, as defined in RFC 5073, are not
supported.
Multiple path options per destination are not supported. The P2MP TE feature allows one path
option for each destination.
P2MP TE is not supported in inter-area and autonomous system networks. All P2MP TE sub-label
switched paths (LSPs) must originate and terminate in the same IGP and autonomous system
domain.
Path and node protection for P2MP sub-LSPs is not supported.
The P2MP TE feature does not support nonstop forwarding/stateful switchover (NSF/SSO).
However, NSF/SSO coexistence is supported.
The P2MP TE feature does not support Protocol Independent Multicast (PIM) sparse mode. Only
PIM source-specific multicast (SSM) is supported.
The P2MP TE feature does not support dynamic adding and removal of destinations. You must
manually add and remove destinations at the headend router.
RFC 4090 describes two FRR methods: Facility and Detour backup. Both point-to-point (P2P) TE
and P2MP TE support only the Facility FRR method.
P2MP TE does not support the MIBs for P2MP tunnels as described in
draft-ietf-mpls-p2mp-te-mib-09.txt. The P2MP TE headend interfaces are represented in the
mplsTunnelTable of the MPLS-TE-STD-MIB. However, sub-LSP-related information is not
supported by the MPLS-TE-STD-MIB.
The MPLS LSP Ping and MPLS Operations, Administration, and Maintenance (OAM) features are
not supported.
P2MP TE does not support signaling of multiple sub-LSPs in the same Path/Resv message. If
multiple sub-LSPs occur in the same message, the router sends a PathErr Unknown Objects
message, and the Path/Resv message with multiple sub-LSPs is not forwarded.
P2MP TE does not support RSVP local policies, which control the resources that RSVP reservations
are allowed to use.
P2MP TE does not support policy-based routing.
P2MP TE cannot be configured with static IP routes.
P2MP TE does not support penultimate-hop popping. Therefore, the egress router must allocate an
explicit null or non-null label.
The tunnel mpls traffic-eng autoroute announce command is not supported with this feature; it is
supported only with IP unicast traffic.
MPLS P2MP TE tunnels and IP Multicast (MFIB) do not support fragmentation. Configure MTU
values on the ingress interface of the headend router.
2
Information About MPLS Point-to-Multipoint Traffic Engineering
The following restrictions apply when port-channels are coupled with MPLS TE Fast Reroute:
Active and backup ports must be port-channel interfaces.
All members of the primary port-channel interfaces must be on the same slot.
All members of the backup port-channel must be on the same slot but different from the primary
port-channel.

Before configuring the P2MP TE features, you should understand the following concepts:
MPLS Point-to-Multipoint Traffic Engineering Overview, page 3
How P2MP TE Sub-LSPs Are Signaled, page 5
How P2MP TE Traffic Is Forwarded, page 6
Computing the IGP Path Using Dynamic Paths or Explicit Paths, page 7
Benefits of MPLS Point-to-Multipoint Traffic Engineering, page 8
MPLS Point-to-Multipoint Traffic EngineeringRe-optimizing Traffic, page 9
P2P TE Tunnels Coexist with P2MP TE Tunnels, page 9
MPLS Point-to-Multipoint Traffic Engineering Overview

A P2MP TE network contains the following elements, which are shown in Figure 1:
The headend router, also called the source or ingress router, is where the label switched path (LSP)
is initiated. The headend router can also be a branch point, which means the router performs packet
replication and the sub-LSPs split into different directions.
The midpoint router is where the sub-LSP signaling is processed. The midpoint router can be a
branch point.
The tailend router, also called the destination, egress, or leaf-node router, is where sub-LSP
signaling ends.
A bud router is a midpoint and tailend router at the same time.
A P2MP tunnel consists of one or more sub-LSPs.All sub-LSPs belonging to the same P2MP tunnel
employ the same constraints, protection policies, and so on, which are configured at the headend
router.
3
Figure 1 Basic P2MP TE Tunnels
Tailend
IP/MPLS
Headend
Midpiont and
branch point
IP/MPLS
Sub-LSP
Sub-LSP
195423
P2MP TE tunnels build on the features that exist in basic point-to-point TE tunnels. The P2MP TE
tunnels have the following characteristics:
There is one source (headend) but more than one destination (tailend).
They are unidirectional.
They are explicitly routed.
Multiple sub-LSPs connect the headend router to various tailend routers.
Figure 2 shows a P2MP TE tunnel that has three destinations.
PE1 is the headend router.
P01 is a branch point router, where packet replication occurs.
PE2, PE3, and PE4 are tailend routers, where the sub-LSP ends.
Between the PE and CE routers, PIM is enabled to exchange multicast routing information with the
directly connected customer edge (CE) routers. PIM is not enabled across the P2MP TE tunnel.
4
Figure 2 Network Topology with P2MP TE Tunnel
CE2 (Emulated)
Multicast Receiver
10.20.20.20
PE2 PIM
(Emulated)
Multicast Source
10.10.10.10 P02
PIM PIM
CE1 PE1 P01 P04 PE4 CE4
(Emulated)
Multicast Receiver
P03 10.40.40.40
PE3
PIM
(Emulated)
P2MP TE Headend Multicast Receiver
10.30.30.30
CE3
Sub-LSP Tailend
Sub-LSP
195424
Backup LSP
How P2MP TE Sub-LSPs Are Signaled

RSVP TE extensions defined in RFC 4875 allow multiple sub-LSPs to be signaled from the headend
router. A P2MP TE tunnel consists of multiple sub-LSPs that connect the headend router to various
tailend routers.
The headend router sends one RSVP path message to each destination. The tailend router replies with a
RESV message. The Label Forwarding Information Base (LFIB) is populated using the RSVP labels
allocated by the RESV messages.
The tailend routers allocate unreserved labels, which are greater than 15 and do not include implicit or
explicit null labels. Using unreserved labels allows IP Multicast to perform a Reverse Path Forwarding
(RPF) check on the tailend router. Because a sub-LSP tailend router cannot be represented as a regular
interface, a special LSP virtual interface (VIF) is automatically created. The LSP VIF represents the
originating interface for all IP multicast traffic originating from the P2MP TE tailend router.
Figure 3 shows the LSP signaling process.
5
Figure 3 How LSPs Are Signaled
IP/MPLS
PATH
PATH
PATH
PATH
IP/MPLS L=17
RESV
L=16
RESV
RESV
L=16
RESV
195425
L=18
Input Out Label,

Label Interface
16 17,0
18,1
How P2MP TE Traffic Is Forwarded

At the headend of the traffic engineering tunnel, through a static Internet Group Management Protocol
(IGMP) group-to-tunnel mapping, IP multicast traffic is encapsulated with a unique MPLS label, which
is associated with the P2MP TE tunnel. The multicast traffic is label switched in the P2MP tree and
replicated at branch and bud nodes along the P2MP tree. When the labeled packet reaches the tailend (a
PE router), the MPLS label is removed and forwarded to the IP multicast tree towards the end point.This
process is shown in Figure 4.
6
Figure 4 How Packets Traverse the P2MP Tree
R6
(Branch
(Head end) Point) (Bud node) (Tail end)
R1 R2 R3 R4 R5
Push Replicate Swap Replicate pop

swap pop
swap swap
Label
Label Label Label Label
Label
Payload
Payload Payload Payload Payload Payload Payload
195426
Payload
When sub-LSPs share a common router (branch point) and use the same ingress interface of the router,
the same MPLS label is used for forwarding. The multicast state is built by reusing the MPLS labels at
the branch points, as shown in Figure 5, where MPLS label 17 is shared by two sub-LSPs that both use
router C.
Figure 5 Reusing MPLS Labels in Branch Points
In Out
Et0/0, 17 Et2/0, 17
Et3/0, 17
B D F
10.0.1.14
F10.0
A label G
17
Et2/0
label Et0/0 Et3/0
C 10.0.1.18
17
Et0/0 H
label
17
E
Sub-LSP from Headend A to leaf node F
195427
Sub-LSP from Headend A to leaf node H
Computing the IGP Path Using Dynamic Paths or Explicit Paths
7
You can either specify explicit paths or allow paths to be created dynamically. You can also specify
bandwidth parameters, which are flooded throughout the MPLS network through existing RSVP-TE
extensions to Open Shortest Path First (OSPF) and Integrated Intermediate System-to-Intermediate
System (IS-IS).
The MPLS core network uses RSVP to enable end-to-end IP multicast connectivity. The tailend router
and the end point router use PIM to exchange multicast routing information with directly connected CE
routers. PIM is not configured in the MPLS core.
P2MP TE tunnels can co-exist with regular P2P TE tunnels. Existing path calculation and bandwidth
preemption rules apply in this case.
You create IGP paths by enabling dynamic path computation, configuring explicit paths through CLI
commands, or using both methods in your P2MP TE network.
Dynamic paths are created using Constrained Shortest Path First (CSPF) to determine the best path
to a destination. CSPF uses path constraints, such as bandwidth, affinities, priorities, and so on, as
part of the computation.
Explicit paths allows you to manually specify the path a sub-LSP uses from the headend router to
the tailend router. You configure static paths on the headend router.
Remerge Events
When explicit paths are configured with a limited number of equal cost links or paths, two sub-LSPs
might connect at a midpoint router through different ingress interfaces, but use the same egress interface.
This is called a remerge event, which can cause duplicate MPLS packets. If a router detects a remerge
event, it sends a PathErr Routing Problem: Remerge Detected message toward the headend router and
the sub-LSPs are not established. With dynamic paths, the router signals a path that avoids a remerge
situation.
Crossover Events
With a P2MP tunnel, two sibling sub-LSPs (sub-LSPs that share the same link and label) are said to
cross over when they have different incoming interfaces and different outgoing interfaces on the same
intersecting node. The sibling sub-LSPs neither share input label nor output bandwidth. Avoid
configuring crossover LSPs, because they waste bandwidth. However, the duplication of sub-LSPs does
not result in an error.
Benefits of MPLS Point-to-Multipoint Traffic Engineering

The P2MP TE feature provides the following benefits:
You can configure signaling attributes, such as affinities, administrative metrics, fast reroute
protection, and bandwidth constraints, when you set up P2MP TE sub-LSPs.
P2MP TE provides a single point of traffic control. You specify all the signaling and path parameters
at the headend router.
You can configure explicit paths to optimize traffic distribution.
You can enable Fast Reroute link protection and bandwidth protection for P2MP TE sub-LSPs.
Protocol Independent Multicast (PIM) is not needed in the MPLS core. Only the nonMPLS
interfaces on the tailend routers need to be configured with PIM.
8
MPLS Point-to-Multipoint Traffic EngineeringRe-optimizing Traffic

A P2MP TE tunnel is operational (up) when the first sub-LSP has been successfully signaled. The P2MP
TE tunnel is not operational (down) when all sub-LSPs are down. Certain events can trigger a tunnel
re-optimization:
One of the sub-LSPs is fast-rerouted to a backup tunnel (for dynamic LSPs).
A link is operational. (if the command mpls traffic-eng reoptimize events link-up is configured).
A periodic, schedule optimization occurs through the mpls traffic-eng reoptimize timers
frequency command.
The network administrator forces a tunnel optimization through the mpls traffic-eng reoptimize
command.
A fast reroute protected interface becomes operational.
A nonfast reroute LSP detects a remerge situation.
When a P2MP tunnel is reoptimized, a new LSP is signaled and traffic is moved to the new LSP.
To determine if a tunnel should be reoptimized, the router considers the following criteria:
The router compares the number of reachable destinations between the new tree and current tree. If
the new tree contains more reachable destinations than the current tree, the router performs a
reoptimization. If the new tree contains fewer reachable destinations than the current tree, then the
router keeps the current tree.
The router verifies that the same set of reachable destinations in the current tree are also in the new
tree. If the new tree does not contain the same destinations, the router keeps the current tree.
The router compares the number of destinations in the new tree with the number of destinations in
the old tree. If the number of destinations in the new tree is greater than the number of destinations
in the current tree, the router switches to the new tree. This guarantees that the new tree will contain
all of the existing destinations and more.
The router compares the metric between the current and new tree to ensure the new tree and current
tree contain the same set of reachable destinations.
The router compares the administrative weights of the old tree and the new tree. The router switches
to the new tree if the cumulative administrative weight is lower. This step applies as a tie breaker if
all the other conditions are the same.
P2MP TE uses make-before-break reoptimization, which uses the following reoptimization process:
The new LSP is signaled.
The headend router initiates a timer to ensure sufficient time elapses before traffic moves from the
current LSP to the new LSP.
Traffic is redirected from the current LSP to the new LSP.
The timer is started for the purpose of tearing down the old sub-LSPs.
P2P TE Tunnels Coexist with P2MP TE Tunnels

Both P2P and P2MP TE tunnels share the following characteristics:
9
Tunnel bandwidth is configured the same way in both P2P and P2MP tunnels. In P2MP TE tunnels,
any bandwidth parameters you configure are applied to all the destination routers. That is, the
bandwidth parameters apply to all sub-LSPs. Both P2P and P2MP TE tunnels use the same IGP
extension to flood link bandwidth information throughout the network.
Tunnel setup and hold priorities, attributes flags, affinity and mask, and administrative weight
parameters are configured the same way for P2P and P2MP TE tunnels. P2MP TE tunnel parameters
apply to all sub-LSPs.
Fast Reroute-enabled P2MP sub-LSPs coexist with Fast Reroute-enabled P2P LSPs in a network.
For P2P TE, node, link, and bandwidth protection is supported. For P2MP TE, only link and
bandwidth protection are supported.
The method of computing the path dynamically through CSPF is the same for P2P and P2MP TE.
Auto-tunnel backup behaves slightly different with P2P and P2MP tunnels. With P2P tunnels,
auto-tunnel backup creates two backup tunnels: one for the node protection and one for the link
protection. The node protection backup is preferred for P2P LSP protection. With P2MP tunnels,
auto-tunnel backup creates one backup tunnel, which is the link protection. Only the link protection
backup can be used for P2MP sub-LSPs. The P2P and P2MP tunnels can coexist and be protected.
Note If P2MP sub-LSPs are signaled from R1->R2->R3 and a P2P tunnel is signaled from R3->R2->R1, then
issue the mpls traffic-eng multicast-intact command on R3 in IGP configuration mode under router
OSPF or IS-IS to ensure to accommodate multicast traffic for R3's sub-LSPs.
Using Fast Reroute to Protect P2MP TE Links

Fast Reroute applies to P2P LSPs and P2MP sub-LSPs in the same manner. No new protocol extensions
are needed to support P2MP.
Note For P2MP TE fast reroute protection, issue the ip routing protocol purge interface command on every
penultimate hop router. Otherwise, the router can lose up to 6 seconds worth of traffic during a fast
reroute cutover event.
Fast Reroute minimizes interruptions in traffic delivery as a result of link or node failure. FRR
temporarily fast switches LSP traffic to a backup path around a network failure until the headend router
signals a new end-to-end LSP.
Fast Reroute-enabled P2MP sub-LSPs coexist with Fast Reroute-enabled P2P LSPs in a network. For
P2MP TE, only link and bandwidth protection is supported. Node, link, and bandwidth protection are
supported for P2P TE.
You can configure P2P explicit backup tunnels on point of local repair (PLR) nodes for link protection
of P2MP sub-LSPs, similar to LSPs for P2P TE tunnels. You can also enable automatic creation of
backup tunnels using the Auto-tunnel Backup feature for P2P TE tunnels. All sibling sub-LSPs that share
the same outgoing link are protected by the same backup tunnel. All cousin sub-LSPs that share the same
outgoing link can be protected by multiple P2P backup tunnels.
Link protection for a P2MP TE tunnel is illustrated in Figure 6, which shows PE1 as the tunnel headend
router and PE2, PE3, and PE4 as tunnel tailend routers. The following sub-LSPs are signaled from PE1
in the network:
From PE1 to PE2, the sub-LSP travels the following path: PE1 -> P01 -> P02 -> PE2
10
Node P01 is a branch node that does packet replication in the MPLS forwarding plane; ingress traffic
originating from PE1 will be replicated towards routers P02, P03, and P04.
Figure 6 P2MP TE Link Protection Example
CE2 (Emulated)
Multicast Receiver
10.20.20.20
PE2 PIM
(Emulated)
Multicast Source
10.10.10.10 P02
PIM PIM
(Emulated)
Multicast Receiver
P03 10.40.40.40
PE3
PIM
(Emulated)
P2MP TE Headend Multicast Receiver
10.30.30.30
CE3
Sub-LSP Tailend
Sub-LSP
195424
Backup LSP
To protect the three sub-LSPs, separate point-to-point backup tunnels are signaled. Note that backup
tunnels can be created only for links that have an alternative network path. In this example, router P01
is the Point of Local Repair (PLR) and routers P02, P03, and P04 are Merge Points (MPs).
If a link failure occurs between routers P01 and P04, the following events are triggered:
1. Router P01 switches traffic destined to PE4 to the backup tunnel associated with P04.
2. Router P01 sends RSVP path error messages upstream to the P2MP TE headend router PE1. At the
same time, P01 and P04 send IGP updates (link state advertisements (LSAs)) to all adjacent IGP
neighbors, indicating that the interfaces associated with links P01 through P04 are down.
3. Upon receiving RSVP path error messages and IGP LSA updates, the headend router triggers a
P2MP TE tunnel reoptimization and signals a new sub-LSP. (This occurs if you have specified
dynamic path creation.)
Note If only one sub-LSP becomes active, it remains down until all the sub-LSPs become active.
11
FRR Failure Detection Mechanisms

To detect link failures in a P2MP TE network, you can use native link and interface failure detection
mechanisms, such as bidirectional forwarding detection (BFD), loss of signal (LoS) failure events, and
RSVP hellos.
Bidirectional Forwarding Detection

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. For more information, see MPLS Traffic Engineering: BFD-triggered Fast
Reroute (FRR).
Loss of Signal Failure Events
Fast Reroute can be triggered by loss of signal events. It is alarm based and dependent upon platform
and line card support. For more information, see MPLS TE: Link and Node Protection, with RSVP Hellos
Support (with Fast Tunnel Interface Down Detection)
RSVP Hellos
You can configure RSVP hellos on interfaces that do not provide FRR cutover notification during a link
failure. The behavior for RSVP hellos is similar for both P2MP TE and P2P TE. For every sub-LSP that
has a backup tunnel and has RSVP hellos enabled on its output interface, an RSVP hello instance is
created to the neighbor, and the sub-LSP is added to the neighbor's FRR tree in the hello database.
Hello instances between an output interface and neighbor address are shared by fast reroutable P2MP
sub-LSPs and P2P LSPs. When a hello session to a neighbor is declared down, all P2P LSPs and P2MP
sub-LSPs that are protected by a backup LSP or sub-LSP are switched to their respective backups in the
control and data planes.
RSVP hello sessions can also be used to inform the P2MP headend router of failures along a sub-LSPs
path before the RSVP state for the sub-LSP times out, which leads to faster reoptimization. If a sub-LSP
cannot select a backup tunnel but has RSVP hellos enabled on its output interface, it looks for a hello
instance to its neighbor. If none exists, a hello state time (HST) hello instance is created. If the neighbor
goes down, that sub-LSP is torn down. For more information, see MPLS Traffic Engineering (TE) - Fast
Reroute (FRR) Link and Node Protection.
Bandwidth Preemption for P2MP TE

Bandwidth Admission Control and preemption mechanisms for P2MP TE sub-LSPs are the same as for
LSPs associated with P2P TE tunnels. Any link affinities or constraints defined for the P2MP TE tunnel
will be taken into account. The bandwidth signaled for the sub-LSP is removed from the appropriate pool
at the appropriate priority, and if needed, lower priority sub-LSPs are preempted with a higher priority
sub-LSP.
A P2MP tunnel can be configured to use sub-pool or global-pool bandwidth. When bandwidth is
configured, all sub-LSPs of the P2MP tunnel are signaled with the same bandwidth amount and type. If
the bandwidth amount or type of a P2MP tunnel is changed, the P2MP tunnel ingress always signals a
new set of sub-LSPs (a new P2MP LSP) with the new bandwidth amount and type.
Preemption procedures do not take into account the tunnel type. The same priority rules apply to P2P
LSPs and P2MP sub-LSPs. A sub-LSP with a higher setup priority preempts a (sub-)LSP with a lower
hold priority, regardless of tunnel type. Thus, a P2MP sub-LSP may preempt a P2P LSP, and vice versa.
The determination of which LSPs get preempted is based on hold priority.
12
How to Configure MPLS Point-to-Multipoint Traffic Engineering
You can configure a P2MP TE tunnel to use subpool or global-pool bandwidth. All sub-LSPs associated
with the P2MP TE tunnel are signaled with the same bandwidth amount and type. If the bandwidth
amount or type is changed, the P2MP tunnel headend router signals a new set of sub-LSPs with the new
bandwidth parameters.
Bandwidth sharing is similar for P2MP TE sub-LSPs and P2P TE LSPs. When adding a new sub-LSP,
the P2MP-TE headend router determines whether it should share bandwidth with the other sub-LSPs.
Two sub-LSPs can share bandwidth as long as they are a Transit Pair, meaning the sub-LSPs share the
output interface, next-hop and output label.
LSPs and sub-LSPs cannot share bandwidth if they use different bandwidth pools. A change in
bandwidth requires reoptimizing P2P or P2MP TE tunnels, which may result in double-counting
bandwidth on common links.
Using FRR with Bandwidth Protection has the following requirements:
A backup tunnel is required to maintain the service level agreement while the new sub-LSP is
created.
The PLR router selects the backup tunnel only if the tunnel has enough bandwidth capacity.
The backup tunnel might not signal bandwidth.
The PLR router decides the best backup path to protect the primary path, based on backup bandwidth
and class type.
NSF/SSO Support for MPLS P2MP TE

NSF/SSO coexistence is supported with P2MP TE. State information associated with active P2MP
tunnels and associated sub-LSPs is not checkpointed and cannot be recovered after a route processor
(RP) failover. When a RP switchover is triggered through NSF/SSO, traffic going to P2MP TE tunnels
is lost. P2MP TE sends RSVP path error messages upstream and RSVP RESV error messages
downstream to tear down the affected P2MP sub-LSPs. The RSVP error message can also trigger a FRR
switchover to backup paths, and the TE headend router can recalculate and resignal a new P2MP TE
tunnel.

Use the following procedures to configure the P2MP TE feature:
Configuring the Headend Routers, page 13 (required)
Configuring the Midpoint Routers, page 16 (required)
Configuring the Tailend Routers, page 17 (required)
Configuring Fast Reroute with P2MP TE Tunnels, page 19 (optional)
Enabling MPLS Traffic Engineering System Logging of Events, page 19 (optional)
Verifying the Configuration of MPLS Traffic Engineering Point-to-Multipoint Tunnels, page 19
(optional)
Configuring the Headend Routers
13
The following steps explain how to configure the headend routers for Multicast and MPLS
point-to-multipoint traffic engineering. As part of the configuration, you specify the tailend routers. You
can also specify explicit paths that the tunnel should use or request that the paths be dynamically created
or have a combination of dynamic and explicit paths.
Because the configuration of the P2MP TE tunnels is done at the headend router, this feature works best
in situations where the destinations do not change often. The P2MP feature does not support dynamic
grafting and pruning of sub-LSPs.
Restrictions
The tunnel destination command is not supported with point-to-multipoint traffic engineering
tunnels. Instead, use the mpls traffic-eng destination list command.
Multiple path options per sub-LSP (destination) are not supported. The P2MP TE feature allows one
path option for each sub-LSP.
The tunnel mpls traffic-eng autoroute announce command is not supported with this feature; it is
supported only with IP unicast traffic.
If P2MP sub-LSPs are signaled from R1->R2->R3 and a P2P tunnel is signaled from R3->R2->R1,
then issue the mpls traffic-eng multicast-intact command on R3 in IGP configuration mode under
router OSPF or IS-IS to ensure accommodate multicast traffic for R3's sub-LSPs.
SUMMARY STEPS
1. enable
4. ip multicast-routing [vrf vrf-name] [distributed]
6. tunnel mode mpls traffic-eng point-to-multipoint
7. tunnel destination list mpls traffic-eng {identifier dest-list-id | name dest-list-name}
8. ip igmp static-group {* | group-address [source {source-address | ssm-map}] | class-map
class-map-name}
9. ip pim {dense-mode [proxy-register {list access-list | route-map map-name}] | passive |
sparse-mode | sparse-dense-mode}
10. exit
11. mpls traffic-eng destination list {name dest-list-name | identifier dest-list-id}
12. ip ip-address path-option id {dynamic | explicit {name name | identifier id} [verbatim]}
13. exit
14. ip explicit-path {name word | identifier number} [enable | disable]
15. next-address [loose | strict] ip-address
16. end
14
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng tunnels Globally enables MPLS Traffic Engineering.
Also issue this command on each network interface that
Example: supports a traffic engineering tunnel.
Step 4 ip multicast-routing [vrf vrf-name] Globally enables IP multicast routing.
[distributed]
Example:
Router(config)# ip multicast-routing
Step 5 interface tunnel number Configures a tunnel and enters interface configuration
mode.
Example:
Step 6 tunnel mode mpls traffic-eng Enables MPLS point-to-multipoint traffic engineering on
point-to-multipoint the tunnel.
Example:
point-to-multipoint
Step 7 tunnel destination list mpls traffic-eng Specifies a destination list to specify the IP addresses of
{identifier dest-list-id |name dest-list-name} point-to-multipoint destinations.
Example:
Router(config-if)# tunnel destination list mpls
traffic-eng name in-list-01
Step 8 ip igmp static-group {* | group-address [source Configures static group membership entries on an interface.
{source-address | ssm-map}] | class-map
class-map-name} Configure this on the TE tunnel interface if the source
address (S, G) cannot be resolved.
Example:
Router(config-if)# ip igmp static-group
239.100.100.101 source 10.11.11.11
15

Step 9 ip pim {dense-mode [proxy-register {list Enable Protocol Independent Multicast (PIM) on an
access-list | route-map map-name}] | passive | interface.
An interface configured with passive mode does not
pass or forward PIM control plane traffic; it passes or
Example: forwards only IGMP traffic.
Router(config-if)# ip pim passive
Example:
Step 11 mpls traffic-eng destination list {name Creates a destination list and enters traffic engineering
dest-list-name | identifier dest-list-id} destination list configuration mode.
Example:
Router(config)# mpls traffic-eng destination
list name in-list-01
Step 12 ip ip-address path-option id {dynamic | Specifies the IP addresses of MPLS point-to-multipoint
explicit {name name | identifier id} traffic engineering tunnel destinations.
[verbatim]}
If you use the explicit keyword, you must configure
explicit paths, using the ip explicit-path command.
Example:
Router (cfg-te-dest-list)# ip 10.10.10.10 Repeat this step for each destination.
path-option 1 dynamic
Step 13 exit Exits traffic engineering destination list configuration
mode.
Example:
Router (cfg-te-dest-list)# exit
Step 14 ip explicit-path {name word | identifier Specifies the name of an IP explicit path and enters ip
number} [enable | disable] explicit path command mode command mode.
Example:
Router(config)# ip explicit-path name path1
enable
Step 15 next-address [loose | strict] ip-address Specifies an explicit path that includes only the addresses
specified or loose explicit paths.
Example:
Router(cfg-ip-expl-path)# next-address 10.0.0.2
Step 16 end Exits the current configuration mode and returns to
privileged EXEC mode.
Example:
Router(cfg-ip-expl-path)# end
Configuring the Midpoint Routers
16
No special configuration is needed to support P2MP TE on the midpoint routers. The midpoint routers
must have Cisco IOS Release 12.2(33)SRE or later release installed. They must be able to support and
implement the P2MP signaling extensions. The MPLS TE configuration of the midpoint routers supports
both P2P and P2MP TE. All multicast traffic is label switched. The midpoint routers do not require IPv4
multicast routing or PIM. For information on configuring MPLS TE, see MPLS Traffic Engineering and
Enhancements.
Configuring the Tailend Routers

The tailend routers remove the MPLS labels from the IP multicast packets and send the packets to the
MFIB for regular multicast forwarding processing. You must issue the ip mroute command to configure
a static route back to the headend router, thus enabling RPF checks.
The following task explains how to configure PIM on the egress interface of the PE router. PIM is needed
when the egress PE router is connected to a CE router, which is connected to a LAN where one or more
multicast receivers are connected.
If the egress PE router is directly connected to a decoder device/system (e.g., DCM), you must configure
Internet Group Management Protocol (IGMP) on the egress interface of the PE router. For more
information on configuring IGMP, see Customizing IGMP.
SUMMARY STEPS
1. enable
3. ip multicast-routing [vrf vrf-name] [distributed]
4. ip multicast mpls traffic-eng [range access-list-number | access-list-name]
5. interface type slot/port
or
interface type slot/port-adapter/port
6. ip pim {dense-mode [proxy-register {list access-list | route-map map-name}] | passive |
7. exit
8. ip mroute [vrf vrf-name] source-address mask {fallback-lookup {global | vrf vrf-name} |
rpf-address | interface-type interface-number} [distance]
9. end
17
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip multicast-routing [vrf vrf-name] Enables IP multicast routing globally.
[distributed]
Example:
Router(config)# ip multicast-routing
Step 4 ip multicast mpls traffic-eng [range Enables IP multicast routing for MPLS traffic engineering
access-list-number | access-list-name] point-to-multipoint tunnels.
Example:
Router(config)# ip multicast mpls traffic-eng
Step 5 interface type slot/port Configures an interface type and enters interface
configuration mode.
or
The type argument specifies the type of interface to be
interface type slot/port-adapter/port
configured.
The slot/ argument specifies the slot number. Refer to
the appropriate hardware manual for slot and port
Example: information.
Router(config)# interface ethernet 1/1 The port argument specifies the port number. Refer to
or the appropriate hardware manual for slot and port
Router(config)# interface fastethernet 1/0/0 information.
The port-adapter/ argument specifies the port adapter
number. Refer to the appropriate hardware manual for
information about port adapter compatibility.
Step 6 ip pim {dense-mode [proxy-register {list Enables Protocol Independent Multicast (PIM) on an
access-list | route-map map-name}] | passive | interface.
Example:
Router(config-if)# ip pim ssm default
Example:
18

Step 8 ip mroute [vrf vrf-name] source-address mask Configures a static multicast route (mroute) to the headend
{fallback-lookup {global | vrf vrf-name} | router, thus enabling RPF checks.
rpf-address | interface-type interface-number}
[distance]
Example:
Router(config)# ip mroute 10.10.10.10
255.255.255.255 10.11.11.11
Step 9 end (Required) Exits the current configuration mode and returns
to privileged EXEC mode.
Example:
Router(config)# end
Configuring Fast Reroute with P2MP TE Tunnels

To enable link protection for sub-LSPs associated with a P2MP TE tunnel, perform the following
configuration tasks:
Enable Fast Reroute on the headend router for each P2MP TE Tunnel.
Configure P2P backup tunnels for network interfaces that require protection.
See MPLS Traffic EngineeringFast Reroute Link and Node Protection for information and
configuration instructions.
Enabling MPLS Traffic Engineering System Logging of Events

MPLS Traffic Engineering system logging allows you to view the following events:
Setting up and tearing down of LSPs
RSVP Path and RESV requests
Sub-LSP status (through path-change messages)
Commands to enable system logging include:
mpls traffic-eng logging lsp path-errors
mpls traffic-eng logging lsp preemption
mpls traffic-eng logging lsp reservation-errors
mpls traffic-eng logging lsp setups
mpls traffic-eng logging lsp teardowns
mpls traffic-eng logging tunnel path change
Verifying the Configuration of MPLS Traffic Engineering Point-to-Multipoint

Tunnels
Verifying the Configuration of the Headend Router, page 20
19
Verifying the Configuration of the Midpoint Routers, page 22

Verifying the Configuration of the Tailend Routers, page 23
Verifying the Configuration of the Headend Router

At the headend router, use the following steps to verify that:
All sub-LSPs are enabled.
IP multicast traffic is being forwarded onto the P2MP TE tunnel.
The following commands may also be helpful in the verification of the headend router:
show cef path set and show cef path set detail (when the headend router is also a branch point)
show ip mfib and show ip mfib verbose
show ip rsvp fast-reroute
show mpls traffic-eng destination list
show mpls traffic-eng fast-reroute database
show mpls traffic-eng tunnels with the dest-mode p2mp, detail, and summary keywords
SUMMARY STEPS
1. enable
2. show mpls traffic-eng tunnels brief
3. show mpls traffic-eng forwarding path-set brief
4. show mpls traffic-eng forwarding path-set detail
5. show ip mroute
DETAILED STEPs
Step 1 enable
Issue the enable command to enter privileged EXEC mode.
Step 2 show mpls traffic-eng tunnels brief
Use the show mpls traffic-eng tunnels brief command to display the P2MP TE tunnels originating from
the headend router. For example:
Router# show mpls traffic-eng tunnels brief
signaling Summary:
Passive LSP Listener: running
Forwarding: enabled
Periodic FRR Promotion: Not Running
Periodic auto-bw collection: disabled
P2P TUNNELS:
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
p2p-LSP 10.2.0.1 - Se2/0 up/up
20
P2MP TUNNELS:
DEST CURRENT
INTERFACE STATE/PROT UP/CFG TUNID LSPID
Tunnel2 up/up 3/10 2 1
Tunnel5 up/down 1/10 5 2
Displayed 2 (of 2) P2MP heads
P2MP SUB-LSPS:
SOURCE TUNID LSPID DESTINATION SUBID ST UP IF DOWN IF
10.1.0.1 2 1 10.2.0.1 1 up head Se2/0
10.1.0.1 2 1 10.3.0.199 2 up head Et2/0
10.1.0.1 2 1 19.4.0.1 2 up head s2/0
10.1.0.1 2 2 1 9.4.0.1 2 up head s2/0
10.1.0.1 5 2 10.5.0.1 7 up head e2/0
100.100.100.100 1 3 200.200.200.200 1 up ge2/0 s2/0
100.100.100.100 1 3 10.1.0.1 1 up e2/0 tail
Displayed 7 P2MP sub-LSPs:
5 (of 5) heads, 1 (of 1) midpoints, 1 (of 1) tails
Step 3 show mpls traffic-eng forwarding path-set brief

Use the show mpls traffic-eng forwarding path-set brief command to show the sub-LSPs that
originate from the headend router. The following example shows three sub-LSPs originating at the
headend router and going to different destinations. All the sub-LSPs belong to the same path set, which
is a collection of paths. The path set is given a unique ID, which is shown in the PSID column of the
example:
Router# show mpls traffic-eng forwarding path-set brief
Sub-LSP Identifier
src_lspid[subid]->dst_tunid InLabel Next Hop I/F PSID
--------------------------- ------- ------------- ------ ----
10.0.0.1_19[16]->10.0.0.8_1 none 10.0.1.2 Et0/0 C5000002
10.0.0.1_19[27]->10.0.0.6_1 none 10.0.1.2 Et0/0 C5000002
10.0.0.1_19[31]->10.0.0.7_1 none 10.0.1.2 Et0/0 C5000002
Step 4 show mpls traffic-eng forwarding path-set detail

Use the show mpls traffic-eng forwarding path-set detail command to show more information about
the sub-LSPs that originate from the headend router. For example:
Router# show mpls traffic-eng forwarding path-set detail
LSP: Source: 10.1.0.1, TunID: 100, LSPID: 7

Destination: 10.2.0.1, P2MP Subgroup ID: 1
Path Set ID: 0x30000001
Next Hop : 10.1.3.2
FRR OutLabel : Tunnel666, 16
LSP: Source: 10.1.0.1, TunID: 100, LSPID: 7

Destination: 10.3.0.1, P2MP Subgroup ID: 2
Path Set ID: 0x30000001
Next Hop : 10.1.3.2
FRR OutLabel : Tunnel666, 16
Step 5 show ip mroute

Use the show ip mroute command to verify that IP multicast traffic is being forwarded to the P2MP TE
tunnel. In the following example, the output shown in bold shows that Tunnel 1 is part of the outgoing
interface list for multicast group 232.0.1.4 with a source address of 10.10.10.10:
21
Router# show ip mroute
IP Multicast Routing Table

Flags: D - Dense, S - Sparse, B - Bidir Group, s - SSM Group, C - Connected,
L - Local, P - Pruned, R - RP-bit set, F - Register flag,
T - SPT-bit set, J - Join SPT, M - MSDP created entry, E - Extranet,
X - Proxy Join Timer Running, A - Candidate for MSDP Advertisement,
U - URD, I - Received Source Specific Host Report,
Z - Multicast Tunnel, z - MDT-data group sender,
Y - Joined MDT-data group, y - Sending to MDT-data group,
V - RD & Vector, v - Vector
Outgoing interface flags: H - Hardware switched, A - Assert winner
Timers: Uptime/Expires
Interface state: Interface, Next-Hop or VCD, State/Mode
(10.10.10.10, 232.0.1.4), 1d00h/stopped, flags: sTI

Incoming interface: Ethernet2/0, RPF nbr 10.10.1.1
Outgoing interface list:
Tunnel1, Forward/Sparse-Dense, 1d00h/00:01:17
(*, 224.0.1.40), 1d00h/00:02:48, RP 0.0.0.0, flags: DCL

Incoming interface: Null, RPF nbr 0.0.0.0
Ethernet2/0, Forward/Sparse, 1d00h/00:02:48
Verifying the Configuration of the Midpoint Routers

At the midpoint router, use the following commands to verify that MPLS forwarding occurs. If the
midpoint router is branch router, you can also use show mpls forwarding-table labels command to
display show specific labels.
SUMMARY STEP
1. enable
2. show mpls forwarding-table
DETAILED STEP
Step 1 enable
Step 2 show mpls forwarding-table
Use the show mpls forwarding-table command to show that MPLS packets are switched at the midpoint
routers. For example:
Local Outgoing Prefix Bytes Label Outgoing Next Hop

Label Label or Tunnel Id Switched interface
16 16 10.0.0.1 1 [19] 0 Et1/0 10.0.1.30

16 16 10.0.0.1 1 [19] 0 Et1/0 10.0.1.30
MAC/Encaps=14/18, MRU=1500, Label Stack{16}
AABBCC032800AABBCC0325018847 00010000
22

Broadcast
Verifying the Configuration of the Tailend Routers

At the tailend router, use the following steps to verify that:
MPLS forwarding occurs.
IP Multicast forwarding occurs.
You can also use the show ip mfib, show mpls traffic-eng destination list, and show mpls traffic-eng
tunnels dest-mode p2mp commands for verification.
SUMMARY STEPS
1. enable
2. show mpls forwarding-table
3. show ip mroute
DETAILED STEPs
Step 1 enable
Step 2 show mpls forwarding-table
Use the show mpls forwarding-table command to show that MPLS labeled packets are forwarded from
the tailend router without any label.

17 [T] No Label 10.0.0.1 1 [19] 342 aggregate
[T] Forwarding through a LSP tunnel.

17 No Label 10.0.0.1 1 [19] 342 aggregate
MAC/Encaps=0/0, MRU=0, Label Stack{}, via Ls0
Step 3 show ip mroute

Use the show ip mroute command to display IP multicast traffic. In the following example, the output
in bold shows the incoming interface is Lspvif0 and the outgoing interface is Ethernet1/0 is for multicast
group 232.0.1.4 with source address 10.10.10.10:
Router# show ip mroute
IP Multicast Routing Table

(*, 232.0.1.4), 1d02h/stopped, RP 0.0.0.0, flags: SP

23
Configuration Examples for MPLS Point-to-Multipoint Traffic Engineering
Outgoing interface list: Null
(10.10.10.10, 232.0.1.4), 00:01:51/00:01:38, flags:

Incoming interface: Lspvif0, RPF nbr 10.0.0.1, Mroute
Ethernet1/0, Forward/Sparse, 00:01:51/00:02:37
(*, 224.0.1.40), 1d02h/00:02:57, RP 0.0.0.0, flags: DCL

Ethernet1/0, Forward/Sparse, 1d02h/00:02:57
Configuration Examples for MPLS Point-to-Multipoint Traffic

Engineering
The following examples show point-to-multipoint traffic engineering configurations on the headend
router (PE5), a midpoint router (P1), and a tailend router (PE1):
Configuration of the Headend Router (PE5): Example, page 25
Configuration of the Midpoint Router (P1): Example, page 28
Configuration of the Tailend Router (PE1): Example, page 29
24
Figure 7 Sample MPLS TE P2MP TE Topology
Sender
CE5
PE5
P1 P2
P3 P4
PE1 PE4
PE2 PE3
CE1 CE2 CE3 CE4

195429
Receiver 1 Receiver 2 Receiver 3 Receiver 4
Configuration of the Headend Router (PE5): Example

In the following example configuration of the headend router, note the following:
IPv4 multicast routing is enabled with the ip multicast-routing command.
Two destination lists are specified, one for dynamic paths and one for explicit paths. The destination
list specifies one path-option per destination.
The tunnel mode mpls traffic-eng point-to-multipoint command enables the P2MP tunnel.
On the tunnel interfaces, the ip pim passive command is used.
On the non-MPLS interfaces, the ip pim sparse-mode command is used.
The ip igmp static-group commands map the multicast groups to the P2MP tunnel.
Fast Reroute is enabled on the router, with tunnel 3 as the backup path. An explicit path called
PE5->P1-BKUP provides the alternative path.
25
hostname [PE5]
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
clock timezone PST -8
ip subnet-zero
ip source-route
ip cef
no ip domain lookup
!
ip multicast-routing
!
no ipv6 cef
!
mpls traffic-eng destination list name P2MP-DYN-DST-LIST
ip 172.16.255.1 path-option 10 dynamic
!
mpls traffic-eng destination list name P2MP-EXCIT-DST-LIST
ip 172.16.255.1 path-option 10 explicit identifier 101
!
multilink bundle-name authenticated
!
interface Tunnel1
description PE5->PE1,PE2,PE3,PE4-DYN
ip pim passive
ip igmp static-group 232.0.1.4 source 192.168.5.255
tunnel mode mpls traffic-eng point-to-multipoint
tunnel destination list mpls traffic-eng name P2MP-DYN-DST-LIST
!
interface Tunnel2
description PE5->PE1,PE2,PE3,PE4-EXCIT
ip pim passive
tunnel destination list mpls traffic-eng name P2MP-EXCIT-DST-LIST
tunnel mpls traffic-eng fast-reroute
!
interface Tunnel3
description PE5->P1
26
tunnel mpls traffic-eng path-option 10 explicit name PE5->P1-BKUP

!
interface Loopback0
ip address 172.16.255.5 255.255.255.255
!
description CONNECTS to CE5
ip address 192.168.5.1 255.255.255.252
ip pim sparse-mode
!
description CONNECTS TO P1
bandwidth 1000000
ip address 172.16.0.13 255.255.255.254
ip router isis
isis network point-to-point
ip rsvp bandwidth percent 100
!
bandwidth 1000000
ip address 172.16.0.14 255.255.255.254
ip router isis
!
router isis
net 49.0001.1720.1625.5005.00
is-type level-2-only
metric-style wide
passive-interface Loopback0
!
!
ip classless
!
no ip http server
!
ip pim ssm default
!
ip explicit-path identifier 101 enable
next-address 172.16.0.12
!
!
!
27
!
ip explicit-path name PE5->P1-BKUP enable
Configuration of the Midpoint Router (P1): Example

In the following example configuration of the midpoint router, note the following:
MPLS Traffic Engineering is enabled both globally and on the interface connecting to other core
routers.
MPLE TE extensions are enabled through the mpls traffic-eng router-id and mpls traffic-eng level
commands.
hostname [P1]
!
no aaa new-model
ip subnet-zero
ip source-route
ip cef
no ip domain lookup
!
no ipv6 cef
!
interface Loopback0
ip address 172.16.255.201 255.255.255.255
!
bandwidth 1000000
ip address 172.16.192.2 255.255.255.254
ip router isis
!
no ip address
shutdown
!
no ip address
shutdown
!
no ip address
shutdown
!
bandwidth 1000000
ip address 172.16.192.1 255.255.255.254
ip router isis
!
28
description CONNECTS TO PE5
bandwidth 1000000
ip address 172.16.0.12 255.255.255.254
ip router isis
!
router isis
net 49.0001.1720.1625.5201.00
metric-style wide
!
ip classless
!
no ip http server
Configuration of the Tailend Router (PE1): Example

In the following example configuration of the tailend router, note the following:
IPv4 multicast routing is enabled with the ip multicast-routing command.
On the non-MPLS interfaces, the ip pim sparse-mode command is used.
The ip multicast mpls commands enable multicast routing of traffic.
hostname [PE1]
!
no aaa new-model
ip subnet-zero
ip source-route
ip cef
no ip domain lookup
!
ip multicast-routing
!
no ipv6 cef
!
interface Loopback0
ip address 172.16.255.1 255.255.255.255
!
description CONNECTS TO CE1
ip address 192.168.1.1 255.255.255.252
ip pim sparse-mode
!
bandwidth 155000
no ip address
shutdown
!
29
description CONNECTS TO PE2

bandwidth 1000000
ip address 172.16.0.5 255.255.255.254
ip router isis
!
bandwidth 1000000
ip address 172.16.0.0 255.255.255.254
ip router isis
!
router isis
net 49.0001.1720.1625.5001.00
metric-style wide
!
!
ip classless
!
no ip http server
!
ip multicast mpls traffic-eng
ip pim ssm default
ip mroute 192.168.5.0 255.255.255.0 172.16.255.5
The following sections provide references related to the P2MP TE feature.
Related Documents
MPLS Traffic Engineering Fast Reroute MPLS Traffic EngineeringFast Reroute Link and Node Protection
MPLS Traffic Engineering LSP Attributes MPLS Traffic EngineeringLSP Attributes
Standards
Standard Title
draft-leroux-mpls-p2mp-te-bypass-xx.txt P2MP MPLS-TE Fast Reroute with P2MP Bypass Tunnels
draft-ietf-mpls-p2mp-te-mib-09.txt Point-to-Multipoint Multiprotocol Label Switching (MPLS) Traffic
Engineering (TE) Management Information Base (MIB) module
30
Glossary
MIBs
MIB MIBs Link
MPLS Traffic Engineering MIB To locate and download MIBs for selected platforms, Cisco IOS
following URL:
RFCs
RFC Title
RFC 4875 Extensions to RSVP-TE for Point-to-Multipoint TE Label Switched Paths
RFC 4461 Signaling Requirements for Point-to-Multipoint TE MPLS LSPs
RFC 5332 MPLS Multicast Encapsulations
Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/techsupport
documentation and tools for troubleshooting and resolving technical issues with
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.
Glossary
Branch routerAn router that has more than one directly connected downstream routers. A router
where packet replication occurs.
Bud router An egress router that has one or more directly connected downstream routers. A bud node
can be a branch node and a destination.
CrossoverA condition that occurs at an intersecting node when two or more incoming sub-LSPs that
belong to the same LSP have different input interfaces and different output interfaces.
Egress router One of potentially many destinations of the P2MP TE sub-LSP. Egress routers may
also be referred to as tailend routers, leaf nodes, or leaves.
Data DuplicationA condition that occurs when an egress router receives duplicate packets. The
condition can happen as a result of re-optimization of LSPs, remerge, or crossover. It causes network
bandwidth to be wasted and should be minimized.
Grafting The process of adding a new sub-LSP to a P2MP TE tunnel.
Headend router An Ingress PE router that is at the headend of a P2MP tunnel.
31
Glossary
Ingress router The router that initiates the signaling messages that set up the P2MP TE LSP. Also
known as the headend router.
MDT A Multicast Domain/Distribution tree in the core which carries traffic and/or control messages
for a given VPN. An MDT implicitly implies that we are discussing the Domain-Model. And MDT can
have multiple types of encapsulation in the core, e.g. GRE, IP-in-IP or MPLS.
MFI MPLS Forwarding Infrastructure
P2MP ID (P2ID) A unique identifier of a P2MP TE LSP, which is constant for the whole LSP
regardless of the number of branches and/or leaves.
P2MP LSPone or more source to leaf sub-LSPs. It is identified by 5-tuple key:
Session
P2MP ID
Tunnel ID
Extended Tunnel ID
Sender Template
Tunnel sender address
LSP ID
P2MP Sub-LSPA segment of a P2MP TE LSP that runs from the headend router to one destination.
A sub-LSP is identified by the following 7-tuple key:
P2MP session
P2MP ID
Tunnel ID
Extended Tunnel ID
Sender Template
Tunnel sender address
LSP ID
Sub Group ID originator
Sub Group ID
P2MP-TEPoint to Multipoint Traffic Engineering
P2MP tree The ordered set of routers and TE links that comprise the paths of P2MP TE sub-LSPs
from the ingress router to all of the egress routers.
P2MP tunnelA group of one of more P2MP LSPs. A tunnel has the following 3-tuple key:
P2MP ID
Tunnel ID
Extended Tunnel ID.
PIMProtocol Independent Multicast
PIM-SMPIM Sparse Mode, see RFC 4601
PIM-SSMPIM Source Specific Multicast, a subset of PIM-SM. See RFC 4601.
PruningThe process of removing a sub-LSP from a a P2MP LSP.
32
Glossary
Receiver A recipient of traffic carried on a P2MP service supported by a P2MP sub-LSP. A receiver
is not necessarily an egress router of the P2MP LSP. Zero, one, or more receivers may receive data
through a given egress router.
RemergeA condition that occurs at an intersecting node when two data streams belonging to the same
P2MP LSP merge into onto one data stream as they exit the intersecting node.
Sibling LSPTwo LSPs that belong to the same P2MP tunnel, meaning that the session objects are the
same for both LSPs.
Sibling sub-LSPTwo sub-LSPs that belong to the same P2MP LSP, meaning that the session and
sender template objects are the same for both sub-LSPs.
SourceThe sender of traffic that is carried on a P2MP service supported by a P2MP LSP. The sender
is not necessarily the ingress router of the P2MP LSP.
Tailend router An Egress PE router that is at the tailend of a P2MP tunnel.
33
Feature Information for MPLS Point-to-Multipoint Traffic Engineering
Feature Information for MPLS Point-to-Multipoint Traffic

Engineering
Table 1 Feature Information for MPLS Point-to-Multipoint Traffic Engineering

MPLS Point-to-Multipoint Traffic Engineering 12.2(33)SRE The MPLS Point-to-Multipoint Traffic Engineering feature
enables you to forward MPLS traffic from one source to
multiple destinations.
introduced.
debug ip rsvp p2mp,
debug mpls traffic-eng filter
debug mpls traffic-eng path
ip multicast mpls traffic-eng
ip path-option
ip pim
show cef
show ip multicast mpls vif
show ip rsvp fast-reroute
show ip rsvp fast-reroute bw-protect
show ip rsvp fast-reroute detail
show ip rsvp request
show ip rsvp reservation
show ip rsvp sender
show mpls traffic-eng destination list
show mpls traffic-eng forwarding path-set
show mpls traffic-eng forwarding statistics
tunnel destination list mpls traffic-eng
34
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, 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.
35
36
MPLS Traffic Engineering: DiffServ
MPLS Traffic Engineering - DiffServ Aware
(DS-TE)
This guide presents extensions made to Multiprotocol Label Switching Traffic Engineering (MPLS TE)
that make it DiffServ aware. Specifically, the bandwidth reservable on each link for constraint-based
routing (CBR) purposes can now be managed through at least two bandwidth pools: a global pool (also
called BC0) and a sub-pool (also called BC1). The sub-pool can be limited to a smaller portion of the
link bandwidth. Tunnels using the sub-pool bandwidth can then be used in conjunction with MPLS
Quality of Service (QoS) mechanisms to deliver guaranteed bandwidth services end-to-end across the
network.
Beginning with Cisco IOS Release 12.2(33)SRB, DS-TE has been augmented to conform to IETF
standards that were developed after the initial creation of Cisco DS-TE. Now both the traditional and the
IETF versions of DS-TE can be run on your network; the new releases are backwards compatible.

MPLS Traffic Engineering - DiffServ Aware (DS-TE)
Background and Overview
Feature History
12.0(11) ST DS-TE feature introduced.
12.0(14) ST Support was added for Cisco Series 7500(VIP) platform.
Support was added for IS-IS Interior Gateway Protocol.
12.0(14) ST-1 Support was added for guaranteed bandwidth service directed to many destination
prefixes (for example, guaranteed bandwidth service destined to an autonomous
system or to a BGP community).
12.0(22)S Feature was implemented in Cisco IOS Release 12.0(22)S.
12.2(14)S Feature was integrated into Cisco IOS Release 12.2(14)S.
12.2(18)S Feature was implemented in Cisco IOS Release 12.2(18)S.
12.2(18)SXD Feature was implemented in Cisco IOS Release 12.2(18)SXD.
12.2(28)SB Feature was implemented in Cisco IOS Release 12.2(28)SB.
12.2(33)SRB Feature was augmented to include the new IETF-Standard functionality of DS-TE, as
described in RFCs 3270, 4124, 4125, and 4127.
The guide contains the following sections:

Background and Overview, page 2
Supported Standards, page 5
Prerequisites, page 6
Configuration Tasks, page 6
Configuration Examples, page 13
Glossary, page 41

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. DiffServ-aware Traffic
Engineering extends MPLS traffic engineering to enable you to perform constraint-based routing of
guaranteed traffic, which satisfies a more restrictive bandwidth constraint than that satisfied by CBR
for regular traffic. The more restrictive bandwidth is termed a sub-pool, while the regular TE tunnel
bandwidth is called the global pool. (The sub-pool is a portion of the global pool. In the new
IETF-Standard, the global pool is called BC0 and the sub-pool is called BC1. These are two of an
2
eventually available eight Class Types). This ability to satisfy a more restrictive bandwidth constraint
translates into an ability to achieve higher Quality of Service performance in terms of delay, jitter, or
loss for the guaranteed traffic.
For example, DS-TE can be used to ensure that traffic is routed over the network so that, on every link,
there is never more than 40 per cent (or any assigned percentage) of the link capacity of guaranteed
traffic (for example, voice), while there can be up to 100 per cent of the link capacity of regular traffic.
Assuming that QoS mechanisms are also used on every link to queue guaranteed traffic separately from
regular traffic, it then becomes possible to enforce separate overbooking ratios for guaranteed and
regular traffic. In fact, for the guaranteed traffic it becomes possible to enforce no overbooking at allor
even an underbookingso that very high QoS can be achieved end-to-end for that traffic, even while for
the regular traffic a significant overbooking continues to be enforced.
Also, through the ability to enforce a maximum percentage of guaranteed traffic on any link, the network
administrator can directly control the end-to-end QoS performance parameters without having to rely on
over-engineering or on expected shortest path routing behavior. This is essential for transport of
applications that have very high QoS requirements such as real-time voice, virtual IP leased line, and
bandwidth trading, where over-engineering cannot be assumed everywhere in the network.
The new IETF-Standard functionality of DS-TE expands the means for allocating constrained bandwidth
into two distinct models, called the Russian Dolls Model and the Maximum Allocation Model. They
differ from each other as follows:
Table 1 Bandwidth Constraint Model Capabilities
Achieves
Bandwidth Ensures Isolation across Class Protects against QoS
MODEL Efficiency Types Degradation...
When When ...of the Premi- ...of all other

Preemption is Preemption is um Class Type Class Types
Not Used Used
Maximum Yes Yes Yes Yes No

Allocation
Russian Yes No Yes Yes Yes

Dolls
Therefore in practice, a Network Administrator might prefer to use:

the Maximum Allocation Model when s/he needs to ensure isolation across all Class Types without
having to use pre-emption, and s/he can afford to risk some QoS degradation of Class Types other
than the Premium Class.
the Russian Dolls Model when s/he needs to prevent QoS degradation of all Class Types and can
impose pre-emption.
DS-TE involves extending OSPF (Open Shortest Path First routing protocol), so that the available
sub-pool or class-type bandwidth at each preemption level is advertised in addition to the available
global pool bandwidth at each preemption level. And DS-TE modifies constraint-based routing to take
this more complex advertised information into account during path computation.
3
With the addition of IETF-Standard functionality (beginning with Cisco IOS Release 12.2(33)SRB),
networks may accomplish DS-TE in three different combinations or modes, so that they may transition
to the IETF-Standard formats in a manner that will not degrade their ongoing traffic service. These three
situations or modes are summarized as follows:
1. The original, or Traditional (pre-IETF-Standard) mode. This describes networks that
already operate the form of DS-TE that was introduced by Cisco a few years ago. Such networks
can continue to operate is this traditional mode, even when they use the new Release
12.2(33)SRB and subsequent releases.
2. The Migration or combination mode. Networks already running traditional DS-TE that
would like to upgrade to the IETF-Standard should first configure their routers into the
Migration mode. This will allow them to continue to operate DS-TE without tunnels being torn
down. In Migration mode, routers will continue to generate IGP and tunnel signalling as in the
Traditional form, but now these routers will add TE-class mapping and will accept
advertisement in both the Traditional and the new IETF-Standard formats.
3. The Liberal IETF mode. Networks already running in the Migration mode can then move
into IETF formats by reconfiguring their routers into this flexible (hence Liberal)
combination: their routers will henceforth generate IGP advertisement and tunnel signalling
according to the new IETF Standard, but they will remain capable of accepting advertisement
in the Traditional format, as well as in the new IETF format.
Table 2 summarizes these distinctions among the three modes.
Table 2 Summary of DS-TE Mode behaviors
Uses
TE-class
mapping Generates Processes
IGP RSVP-TE IGP RSVP-TE

MODE Advertisement Signalling Advertisement Signalling
Traditional No traditional traditional traditional1 traditional
traditional & traditional &

Yes traditional traditional
Migration IETF IETF
traditional & traditional & traditional &

Yes IETF
Liberal IETF IETF IETF IETF
1Note that it is not possible for the Traditional mode to be liberal in what it accepts in terms of IGP, since it does not use TE-Class
mapping and therefore cannot interpret the Unreserved Bandwidth in the IETF-compliant way when the Subpool Sub-TLV
is absent.
Benefits
DiffServ-aware Traffic Engineering enables service providers to perform separate admission control and
separate route computation for discrete subsets of traffic (for example, voice and data traffic).
Therefore, by combining DS-TE with other IOS features such as QoS, the service provider can:
Develop QoS services for end customers based on signaled rather than provisioned QoS
Build the higher-revenue generating strict-commitment QoS services, without over-provisioning
4
Supported Standards
Offer virtual IP leased-line, Layer 2 service emulation, and point-to-point guaranteed bandwidth
services including voice-trunking
Enjoy the scalability properties offered by MPLS.
Related Features and Technologies

The DS-TE feature is related to OSPF, IS-IS, RSVP (Resource reSerVation Protocol), QoS, and MPLS
traffic engineering. Cisco documentation for all of these features is listed in the next section.
Related Documents
The following sections provide references related to the MPLS Traffic EngineeringDiffServ Aware
(DS-TE) feature:

IS-IS Cisco IOS IP Routing Protocols Command Reference
Configuring a Basic IS-IS Network
MPLS Traffic Engineering Cisco IOS Multiprotocol Label Switching Command Reference
OSPF Configuration Task List
QoS Cisco IOS Quality of Service Solutions Command Reference
Quality of Service Overview
RSVP Cisco IOS Quality of Service Solutions Command Reference
Configuring RSVP
Supported Standards
The traditional (pre-IETF Standard) version of DiffServ-aware MPLS Traffic Engineering conforms to
the descriptions given in the following two documents:
Requirements for Support of Diff-Serv-aware MPLS Traffic Engineering by F. Le Faucheur, T.
Nadeau, A. Chiu, W. Townsend, D. Skalecki & M. Tatham
Protocol Extensions for Support of Diff-Serv-aware MPLS Traffic Engineering by F. Le Faucheur,
T. Nadeau, J. Boyle, K. Kompella, W. Townsend & D. Skalecki.
The IETF Standard for DiffServ-aware MPLS Traffic Engineering is described in the following four
documents:
Multi-Protocol Label Switching (MPLS) Support of Differentiated Services by F. Le Faucheur, L.
Wu, B. Davie, P. Vaananen, R. Krishnan, P. Cheval, & J. Heinanen (RFC 3270)
Protocol Extensions for Support of Diffserv-aware MPLS Traffic Engineering ed. by F. Le Faucheur
(RFC 4124)
Russian Dolls Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering ed. by F.
Le Faucheur (RFC 4127)
5
Prerequisites
Maximum Allocation Bandwidth Constraints Model for Diffserv-aware MPLS Traffic Engineering
by F. Le Faucheur & W. Lai (RFC 4125).
The new concept of "Class-Type" defined in the IETF Standard corresponds to the prior concept of
bandwidth pool that was implemented in the original version of DS-TE. Likewise, the two bandwidth
pools implemented in the original version of DS-TE (global pool and sub-pool) correspond to two of the
IETF Standards new Class-Types (Class-Type 0 and Class-Type 1, respectively).
Prerequisites
Your network must support the following Cisco IOS features in order to support guaranteed bandwidth
services based on DiffServ-aware Traffic Engineering:
MPLS
IP Cisco Express Forwarding (CEF)
OSPF or ISIS
RSVP-TE
QoS
Configuration Tasks
This section presents the minimum set of commands you need to implement the DiffServ-aware Traffic
Engineering featurein other words, to establish a tunnel that reserves bandwidth to a sub-pool
(renamed BC1 by the IETF-Standard).
The subsequent Configuration Examples section (page 13), presents these same commands in context
and shows how, by combining them with QoS commands, you can build guaranteed bandwidth services.
From Traditional to IETF-Standard Commands

DS-TE commands originally were developed from the then-existing command set that had been used to
configure MPLS traffic engineering. The only difference introduced at that time to create DS-TE was
the expansion of two commands:
ip rsvp bandwidth was expanded to configure the size of the sub-pool on every link.
tunnel mpls traffic-eng bandwidth was expanded to enable a TE tunnel to reserve bandwidth from
the sub-pool.
The ip rsvp bandwidth command

The early MPLS command had been
ip rsvp bandwidth x y
where x = the size of the only possible pool, and y = the size of a single traffic flow (ignored by traffic
engineering).
Then, to create the original implementation of DS-TE, the command was made into
ip rsvp bandwidth x y sub-pool z
where x = the size of the global pool, and z = the size of the sub-pool.
6
Configuration Tasks
With the addition of the IETF-Standard version of DS-TE, the command has been further extended to
become:
ip rsvp bandwidth x y [ [rdm x {subpool z | bc1 z}] | [mam bc0 x bc1 z]]
where x = the size of the global pool (now called bc0), and z = the size of the sub-pool (now called also
bc1).
Two bandwidth constraint models also have become available, Russian Dolls (indicated by the
keyword rdm) and Maximum Allocation (mam). The former model allows greater sharing of
bandwidth across all Class Types (bandwidth pools), while the latter protects especially the premium
Class Type. (The IETF Standard makes possible the future implementation of as many as seven
sub-pools within one LSP, instead of just one sub-pool per LSP).
The tunnel mpls traffic-eng bandwidth command

The pre-DS-TE traffic engineering command was
tunnel mpls traffic-eng bandwidth b
where b = the amount of bandwidth this tunnel requires.
So for the original DS-TE, you specified from which pool (global or sub) the tunnel's bandwidth would
come. You could enter
tunnel mpls traffic-eng bandwidth sub-pool b
to indicate that the tunnel should use bandwidth from the sub-pool. Alternatively, you could enter
tunnel mpls traffic-eng bandwidth b
to indicate that the tunnel should use bandwidth from the global pool (which was the default).
With the addition of the IETF-Standard version of DS-TE, the command has been extended to become:
tunnel mpls traffic-eng bandwidth [sub-pool|class-type 1] b
where both sub-pool and class-type 1 indicate the same, smaller bandwidth pool (now called class-type
1). The two keywords can be used interchangeably.
The mpls traffic-eng ds-te commands

The IETF Standard introduces two new commands, one to indicate the Bandwidth Constraints model
mpls traffic-eng ds-te bc-model [rdm | mam]
and one to select the DS-TE mode:

mpls traffic-eng ds-te mode [migration|ietf]
(The concepts of bc-model and DS-TE mode were explained on page 3).
The first command allows you to select between the Russian Dolls Model (rdm) and the Maximum
Allocation Model (mam) of bandwidth constraints.
The second command allows you to transition a network from traditional DS-TE tunnels to the IETF
Standard without disrupting any of the tunnels operation. To accomplish this, you first put the routers
into Migration mode (using the migration keyword) and subsequently into the Liberal-IETF mode
(using the ietf keyword).
7
Configuration Tasks
Transitioning a Network to the IETF Standard

Networks already operating DS-TE tunnels by means of the traditional, pre-IETF-Standard software can
switch to the IETF-Standard without interrupting their DS-TE service by following this sequence:
1. Install Cisco IOS Release 12.2(33)SRB (or a subsequent release) on each router in the network,
gradually, one router at a time, using Ciscos In Service Software Upgrade (ISSU) procedure which
protects ongoing network traffic from interruption. (After that installation, DS-TE tunnels in the
network will continue to operate by using the pre-IETF-Standard formats.)
2. Enter the global configuration command mpls traffic-eng ds-te mode migration on each router in
the network, one router at a time. This will enable the routers to receive IETF-format IGP
advertisement and RSVP-TE signaling, while the routers will continue to generate and receive the
pre-Standard formats for those two functions.
3. After all the routers in the network have begun to operate in Migration mode, enter the global
configuration command mpls traffic-eng ds-te mode ietf on each router, one at a time. This will
cause the router to refresh its TE tunnels with IETF-compliant Path signaling, without disrupting the
tunnels operation. This mode also causes the router to generate IGP advertisement in the
IETF-Standard format.
Configuring DS-TE Tunnels

To establish a sub-pool (BC1) traffic engineering tunnel, you must enter configurations at three levels:
the device level (router or switch router)
the physical interface
the tunnel interface
On the first two levels, you activate traffic engineering; on the third levelthe tunnel interfaceyou
establish the sub-pool tunnel. Therefore, it is only at the tunnel headend device that you need to
configure all three levels. At the tunnel midpoints and tail, it is sufficient to configure the first two levels.
In the tables below, each command is explained in brief. For a more complete explanation of any
command, type it into the Command Lookup Tool at
http://www.cisco.com/cgi-bin/Support/Cmdlookup/home.pl. (If prompted to log in there, use your
Cisco.com account username and password).
Level 1: Configuring the Device

At this level, you tell the device (router or switch router) to use accelerated packet-forwarding (known
as Cisco Express Forwarding or CEF), MultiProtocol Label Switching (MPLS), traffic-engineering
tunneling, a bandwidth constraints model, and either the OSPF or IS-IS routing algorithm (Open
Shortest Path First or Intermediate System to Intermediate System). This level is called the global
configuration mode, because the configuration is applied globally, to the entire device, rather than to a
specific interface or routing instance.
8
Configuration Tasks
You enter the following commands:
Command Purpose
Step 1 Router(config)# ip cef distributed Enables CEFwhich accelerates the flow of packets through the
device.
Step 2 Router(config)# mpls traffic-eng tunnels Enables MPLS, and specifically its traffic engineering tunnel
capability.
Step 3 Router(config)# mpls traffic-eng ds-te Specifies the bandwidth constraints model (see page 3).
bc-model [rdm | mam ]
Step 4 Router(config)# router ospf Invokes the OSPF routing process for IP and puts the device into
router configuration mode. Proceed now to Steps 10 and 11.
[or]
Router(config)# router isis Alternatively, you may invoke the IS-IS routing process with this
command, and continue with Step 5.
Step 5 Router (config-router)# net Specifies the IS-IS network entity title (NET) for the routing
network-entity-title process.
Step 6 Router (config-router)# metric-style wide Enables the router to generate and accept IS-IS new-style TLVs
(type, length, and value objects).
Step 7 Router (config-router)# is-type level-n Configures the router to learn about destinations inside its own
area or IS-IS level.
Step 8 Router (config-router)# mpls traffic-eng Specifies the IS-IS level (which must be same level as in the
level-n preceding step) to which the router will flood MPLS traffic-
engineering link information.
Step 9 Router (config-router)# passive-interface Instructs IS-IS to advertise the IP address of the loopback
loopback0 interface without actually running IS-IS on that interface.
Continue with Step 10 but dont do Step 11because Step 11
refers to OSPF.
Step 10 Router(config-router)# mpls traffic-eng Specifies that the traffic engineering router identifier is the IP
router-id loopback0 address associated with the loopback0 interface.
Step 11 Router(config-router)# mpls traffic-eng Turns on MPLS traffic engineering for a particular OSPF area.
area num
Level 2: Configuring the Physical Interface

Having configured the device, you now must configure the interface on that device through which the
tunnel will run. To do that, you first put the router into interface-configuration mode.
You then enable Resource Reservation Protocol (RSVP). This protocol is used to signal (set up) a traffic
engineering tunnel, and to tell devices along the tunnel path to reserve a specific amount of bandwidth
for the traffic that will flow through that tunnel. It is with this command that you establish the maximum
size of the sub-pool (BC1).
Finally, you enable the MPLS traffic engineering tunnel feature on this physical interfaceand if you
will be relying on the IS-IS routing protocol, you enable that as well.
9
Configuration Tasks
To accomplish these tasks, you enter the following commands:
Command Purpose
Step 1 Router(config)# interface interface-id Moves configuration to the interface level, directing subsequent
configuration commands to the specific interface identified by
the interface-id.
Step 2 Router(config-if)# ip rsvp bandwidth Enables RSVP on this interface, indicates the Bandwidth
[interface-kbps] [single-flow-kbps][[rdm Constraints Model to be used (explained on page 3), and limits
kbps{[subpool kbps]|[bc1 subpool]}]|[mam
max-reservable-bw kbps bc0 kbps bc1 kbps]]
the amount of bandwidth RSVP can reserve on this interface.
The sum of bandwidth used by all tunnels on this interface
cannot exceed interface-kbps.
Step 3 Router(config-if)# mpls traffic-eng tunnels Enables the MPLS traffic engineering tunnel feature on this
interface.
Step 4 Router(config-if)# ip router isis Enables the IS-IS routing protocol on this interface. Do not
enter this command if you are configuring for OSPF.
Level 3: Configuring the Tunnel Interface

Now you create a set of attributes for the tunnel itself; those attributes are configured on the tunnel
interface (not to be confused with the physical interface just configured above).
You enter the following commands:
Command Purpose
Step 1 Router(config)# interface tunnel1 Creates a tunnel interface (named in this example tunnel1)
and enters interface configuration mode.
Step 2 Router(config-if)# tunnel destination A.B.C.D Specifies the IP address of the tunnel tail device.
Step 3 Router(config-if)# tunnel mode mpls traffic-eng Sets the tunnels encapsulation mode to MPLS traffic
engineering.
Step 4 Router(config-if)# tunnel mpls traffic-eng Configures the tunnels bandwidth, and assigns it either to
bandwidth {sub-pool|class-type1} bandwidth the sub-pool (when you use that keyword or the
IETF-Standard keyword class-type1) or to the global pool
(when you leave out both keywords).
Step 5 Router(config-if)# tunnel mpls traffic-eng Sets the priority to be used when the system determines
priority which existing tunnels are eligible to be preempted.
Step 6 Router(config-if)# tunnel mpls traffic-eng Configures the paths (hops) a tunnel should use. The user
path-option can enter an explicit path (can specify the IP addresses of
the hops) or can specify a dynamic path (the router figures
out the best set of hops).
Verifying the Configuration

To view the complete configuration you have entered, use the EXEC command show running-config
and check its output display for correctness.
To check just one tunnels configuration, enter show interfaces tunnel followed by the tunnel interface
number. And to see that tunnels RSVP bandwidth and flow, enter show ip rsvp interface followed by
the name or number of the physical interface.
10
Configuration Tasks
Here is an example of the information displayed by these latter two commands. (To see an explanation
of each field used in the following displays, enter show interfaces tunnel or show ip rsvp interface into
the Command Lookup Tool at http://www.cisco.com/cgi-bin/Support/Cmdlookup/home.pl. If prompted
to log in there, use your Cisco.com account username and password.)
Router#show interfaces tunnel 4
Tunnel4 is up, line protocol is down
Hardware is Routing Tunnel
MTU 1500 bytes, BW 9 Kbit, DLY 500000 usec, rely 255/255, load 1/255
Encapsulation TUNNEL, loopback not set, keepalive set (10 sec)
Tunnel source 0.0.0.0, destination 0.0.0.0
Tunnel protocol/transport GRE/IP, key disabled, sequencing disabled
Last input never, output never, output hang never
Last clearing of show interface counters never
Output queue 0/0, 0 drops; input queue 0/75, 0 drops
Five minute input rate 0 bits/sec, 0 packets/sec
Five minute output rate 0 bits/sec, 0 packets/sec
0 packets input, 0 bytes, 0 no buffer
Received 0 broadcasts, 0 runts, 0 giants
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
0 packets output, 0 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets, 0 restarts
Router#show ip rsvp interface pos4/0

interface allocated i/f max flow max sub max
PO4/0 300K 466500K 466500K 0M
To view all tunnels at once on the router you have configured, enter show mpls traffic-eng tunnels
brief. The information displayed when tunnels are functioning properly looks like this:
Router#show mpls traffic-eng tunnels brief
Signalling Summary:
Forwarding: enabled
GSR1_t0 192.168.1.13 - SR3/0 up/up
GSR1_t1 192.168.1.13 - SR3/0 up/up
GSR1_t2 192.168.1.13 - PO4/0 up/up
When one or more tunnels is not functioning properly, the display could instead look like this. (In the
following example, tunnels t0 and t1 are down, as indicated in the far right column).
Router#show mpls traffic-eng tunnels brief
Signalling Summary:
Forwarding: enabled
GSR1_t0 192.168.1.13 - SR3/0 up/down
GSR1_t1 192.168.1.13 - SR3/0 up/down
GSR1_t2 192.168.1.13 - PO4/0 up/up
To find out why a tunnel is down, insert its name into this same command, after adding the keyword
name and omitting the keyword brief. For example:
Router#show mpls traffic-eng tunnels name GSR1_t0
Name:GSR1_t0 (Tunnel0) Destination:192.168.1.13
11
Configuration Tasks
Status:
Admin:up Oper:down Path: not valid Signalling:connected
If, as in this example, the Path is displayed as not valid, use the show mpls traffic-eng topology
command to make sure the router has received the needed updates.
Additionally, you can use any of the following show commands to inspect particular aspects of the
network, router, or interface concerned:
To see information about...

this level and this item... Use this command
Network Advertised bandwidth show mpls traffic-eng link-management advertisements
allocation information
Preemptions along the debug mpls traffic-eng link-management preemption
tunnel path
Available TE link band- show mpls traffic-eng topology (described on page 41)
width on all head routers
Router Status of all tunnels cur- show mpls traffic-eng link-management
rently signalled by this admission-control
router
Tunnels configured on show mpls traffic-eng link-management summary
midpoint routers
Physical Detailed information on show mpls traffic-eng link-management
interface current bandwidth pools bandwidth-allocation [interface-name]
TE RSVP bookkeeping show mpls traffic-eng link-management interfaces
Entire configuration of show run interface
one interface
12
Note The following 25 pages of examples illustrate DS-TE in the traditional, pre-IETF-Standard mode. You
may update these examples simply by inserting the new Device Level command mpls traffic-eng ds-te
bc-model as its proper use is shown in Step 3 on page 9, and by applying the updated syntax within the
two modified commands as each is shown respectively at the Physical Interface Level in Step 2 on page
10 (ip rsvp bandwidth), and at the Tunnel Interface Level in Step 4 on page 10 (tunnel mpls traffic-eng
bandwidth).
First this section presents the DS-TE configurations needed to create the sub-pool tunnel. Then it
presents the more comprehensive design for building end-to-end guaranteed bandwidth service, which
involves configuring Quality of Service as well.
As shown in Figure 1, the tunnel configuration involves at least three devicestunnel head, midpoint,
and tail. On each of those devices one or two network interfaces must be configured, for traffic ingress
and egress.
Figure 1 Sample Tunnel Topology
Lo0: 22.1.1.1 Lo0: 25.1.1.1 Lo0: 24.1.1.1

Head Mid Tail
(router-1) (router-2) (router-3)
10.1.1.0 12.1.1.0
POS2/0/0 POS4/0 POS4/1 POS2/0
= Data flow
53559
= Sub-pool tunnel
Tunnel Head
At the device level:
router-1# configure terminal
router-1(config)# ip cef distributed

router-1(config)# mpls traffic-eng tunnels
[now one uses either the IS-IS commands on the left or the OSPF commands on the right]:
router-1(config)# router isis router ospf 100
router-1(config-router)# net redistribute connected
49.0000.1000.0000.0010.00
router-1(config-router)# metric-style wide network 10.1.1.0 0.0.0.255 area 0
router-1(config-router)# is-type level-1 network 22.1.1.1 0.0.0.0 area
0
13
router-1(config-router)# mpls traffic-eng mpls traffic-eng area 0

level-1
router-1(config-router)# passive-interface
Loopback0
[now one resumes the common command set]:
router-1(config-router)# mpls traffic-eng router-id Loopback0
router-1(config-router)# exit
router-1(config)# interface Loopback0
At the virtual interface level:

router-1(config-if)# ip address 22.1.1.1 255.255.255.255
router-1(config-if)# no ip directed-broadcast
router-1(config-if)# exit

router-1(config)# interface POS2/0/0
At the physical interface level (egress):

router-1(config-if)# mpls traffic-eng tunnels
router-1(config-if)# ip rsvp bandwidth 130000 130000 sub-pool 80000
[and if using IS-IS instead of OSPF]:
router-1(config-if)# ip router isis
[and in all cases]:

router-1(config)# interface Tunnel1
At the tunnel interface level:

router-1(config-if)# bandwidth 110000
router-1(config-if)# ip unnumbered Loopback0
router-1(config-if)# tunnel destination 24.1.1.1
router-1(config-if)# tunnel mode mpls traffic-eng
router-1(config-if)# tunnel mpls traffic-eng priority 0 0
router-1(config-if)# tunnel mpls traffic-eng bandwidth sub-pool 30000
router-1(config-if)# tunnel mpls traffic-eng path-option 1 dynamic
router-1(config)#
Midpoint Devices
14
49.0000.1000.0000.0012.00
router-2(config-router)# metric-style wide network 11.1.1.0 0.0.0.255
area 0
router-2(config-router)# is-type level-1 network 12.1.1.0 0.0.0.255
area 0
router-2(config-router)# mpls traffic-eng network 25.1.1.1 0.0.0.0 area 0
level-1
router-2(config-router)# passive-interface mpls traffic-eng area 0
Loopback0


router-1(config)# interface POS4/0
[If using IS-IS instead of OSPF]:

[and in all cases]:


[and in all cases]:
Note that there is no configuring of tunnel interfaces at the mid-point devices, only network interfaces
and the device globally.
Tail-End Device
15

49.0000.1000.0000.0013.00
0
router-3(config-router)# mpls traffic-eng level-1 mpls traffic-eng area 0
Loopback0

[and in all cases]:


[and in all cases]:
Guaranteed Bandwidth Service Configuration

Having configured two bandwidth pools, you now can
Use one pool, the sub-pool, for tunnels that carry traffic requiring strict bandwidth guarantees or
delay guarantees
Use the other pool, the global pool, for tunnels that carry traffic requiring only Differentiated
Service.
Having a separate pool for traffic requiring strict guarantees allows you to limit the amount of such
traffic admitted on any given link. Often, it is possible to achieve strict QoS guarantees only if the
amount of guaranteed traffic is limited to a portion of the total link bandwidth.
Having a separate pool for other traffic (best-effort or diffserv traffic) allows you to have a separate limit
for the amount of such traffic admitted on any given link. This is useful because it allows you to fill up
links with best-effort/diffserv traffic, thereby achieving a greater utilization of those links.
16
Providing Strict QoS Guarantees Using DS-TE Sub-pool Tunnels
A tunnel using sub-pool bandwidth can satisfy the stricter requirements if you do all of the following:
1. Select a queueor in diffserv terminology, select a PHB (per-hop behavior)to be used exclusively
by the strict guarantee traffic. This shall be called the GB queue.
If delay/jitter guarantees are sought, the diffserv Expedited Forwarding queue (EF PHB) is used. On
the Cisco 7500(VIP) it is the "priority" queue.You must configure the bandwidth of the queue to be
at least equal to the bandwidth of the sub-pool.
If only bandwidth guarantees are sought, the diffserv Assured Forwarding PHB (AF PHB) is used.
On the Cisco 7500 (VIP) you use one of the existing Class-Based Weighted Fair Queuing (CBWFQ)
queues.
2. Ensure that the guaranteed traffic sent through the sub-pool tunnel is placed in the GB queue at the
outbound interface of every tunnel hop, and that no other traffic is placed in this queue.
You do this by marking the traffic that enters the tunnel with a unique value in the mpls exp bits
field, and steering only traffic with that marking into the GB queue.
3. Ensure that this GB queue is never oversubscribed; that is, see that no more traffic is sent into the
sub-pool tunnel than the GB queue can handle.
You do this by rate-limiting the guaranteed traffic before it enters the sub-pool tunnel. The aggregate
rate of all traffic entering the sub-pool tunnel should be less than or equal to the bandwidth capacity
of the sub-pool tunnel. Excess traffic can be dropped (in the case of delay/jitter guarantees) or can
be marked differently for preferential discard (in the case of bandwidth guarantees).
4. Ensure that the amount of traffic entering the GB queue is limited to an appropriate percentage of
the total bandwidth of the corresponding outbound link. The exact percentage to use depends on
several factors that can contribute to accumulated delay in your network: your QoS performance
objective, the total number of tunnel hops, the amount of link fan-in along the tunnel path, burstiness
of the input traffic, and so on.
You do this by setting the sub-pool bandwidth of each outbound link to the appropriate percentage
of the total link bandwidth (that is, by adjusting the z parameter of the ip rsvp bandwidth
command).
Providing Differentiated Service Using DS-TE Global Pool Tunnels
You can configure a tunnel using global pool bandwidth to carry best-effort as well as several other
classes of traffic. Traffic from each class can receive differentiated service if you do all of the following:
1. Select a separate queue (a distinct diffserv PHB) for each traffic class. For example, if there are three
classes (gold, silver, and bronze) there must be three queues (diffserv AF2, AF3, and AF4).
2. Mark each class of traffic using a unique value in the MPLS experimental bits field (for example
gold = 4, silver = 5, bronze = 6).
3. Ensure that packets marked as Gold are placed in the gold queue, Silver in the silver queue, and so
on. The tunnel bandwidth is set based on the expected aggregate traffic across all classes of service.
To control the amount of diffserv tunnel traffic you intend to support on a given link, adjust the size of
the global pool on that link.
Providing Strict Guarantees and Differentiated Service in the Same Network
Because DS-TE allows simultaneous constraint-based routing of sub-pool and global pool tunnels, strict
guarantees and diffserv can be supported simultaneously in a given network.
17
Guaranteed Bandwidth Service Examples

Given the many topologies in which Guaranteed Bandwidth Services can be applied, there is space here
only to present two examples. They illustrate opposite ends of the spectrum of possibilities.
In the first example, the guaranteed bandwidth tunnel can be easily specified by its destination. So the
forwarding criteria refer to a single destination prefix.
In the second example, there can be many final destinations for the guaranteed bandwidth traffic,
including a dynamically changing number of destination prefixes. So the forwarding criteria are
specified by Border Gateway Protocol (BGP) policies.
Example with Single Destination Prefix

Figure 2 illustrates a topology for guaranteed bandwidth services whose destination is specified by a
single prefix, either Site D (like a voice gateway, here bearing prefix 26.1.1.1) or a subnet (like the
location of a web farm, here called Province and bearing prefix 26.1.1.0). Three services are offered:
From Site A (defined as all traffic arriving at interface FE4/1/0): to host 26.1.1.1, 8 Mbps of
guaranteed bandwidth with low loss, low delay and low jitter
From Site B (defined as all traffic arriving at interface FE4/1/1): towards subnet 26.1.1.0, 32 Mbps
of guaranteed bandwidth with low loss
From Site C (defined as all traffic arriving at interface FE2/1/0): 30 Mbps of guaranteed bandwidth
with low loss
Figure 2 Sample Topology for Guaranteed Bandwidth Services to a Single Destination Prefix
23.1.1.1
Head-1
140/60
8 40
FE4/1/0 POS4/0
FE4/1/1
Site A
32 26.1.1.1
Mid-1 Tail
26.1.1.0
140/60 Province
Site B 40
POS2/1 POS3/1 POS2/1 Site D
POS
POS1/1 POS4/1 2/2
22.1.1.1
Head-2 30 140/60 30 140/60
Mid-2
140/60
30 30
FE2/1/0 POS0/0
Site C POS1/1 POS2/1
8
= Data flow (service bandwidth indicated in Mbps [megabits per second])
49947
140/60
= Sub-pool tunnel (global and sub-pool bandwidth indicated in Mbps for this link)
18
These three services run through two sub-pool tunnels:

From the Head-1 router, 23.1.1.1, to the router-4 tail
From the Head-2 router, 22.1.1.1, to the router-4 tail
Both tunnels use the same tail router, though they have different heads. (In Figure 2 one midpoint router
is shared by both tunnels. In the real world there could of course be many more midpoints.)
All POS interfaces in this example are OC3, whose capacity is 155 Mbps.
Configuring Tunnel Head-1

First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented
earlier in this Configuration Examples section). Then we present the QoS commands that guarantee
end-to-end service on the subpool tunnel. (With the 7500 router, Modular QoS CLI is used.)
Configuring the Pools and Tunnel

49.0000.1000.0000.0010.00
0
level-1
Loopback0
Create a virtual interface:

At the outgoing physical interface:

router-1(config)# interface pos4/0
[and in all cases}:
At the tunnel interface:

19
router-1(config-if)# bandwidth 110000

To ensure that packets destined to host 26.1.1.1 and subnet 26.1.1.0 are sent into the sub-pool tunnel, we
create a static route. At the device level:
router-1(config)# ip route 26.1.1.0 255.255.255.0 Tunnel1
router-1(config)# exit
And in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic down
this tunnel, we disable autoroute announce:
router-1(config)# no tunnel mpls traffic-eng autoroute announce
For Service from Site A to Site D
At the inbound physical interface (FE4/1/0):

1. In global configuration mode, create a class of traffic matching ACL 100, called "sla-1-class":
class-map match-all sla-1-class
match access-group 100
2. Create an ACL 100 to refer to all packets destined to 26.1.1.1:

access-list 100 permit ip any host 26.1.1.1
3. Create a policy named sla-1-input-policy, and according to that policy:

a. Packets in the class called sla-1-class are rate-limited to:
a rate of 8 million bits per second
a normal burst of 1 million bytes
a maximum burst of 2 million bytes
b. Packets which conform to this rate are marked with MPLS experimental bit 5 and are forwarded.
c. Packets which exceed this rate are dropped.
d. All other packets are marked with experimental bit 0 and are forwarded.
policy-map sla-1-input-policy
class sla-1-class
police 8000000 1000000 2000000 conform-action set-mpls-exp-transmit 5 \
exceed-action drop
class class-default
set-mpls-exp-transmit 0
4. The policy is applied to packets entering interface FE4/1/0.

service-policy input sla-1-input-policy
20
For Service from Site B to Subnet Province

2. Create an ACL, 120, to refer to all packets destined to subnet 26.1.1.0:

access-list 120 permit ip any 26.1.1.0 0.0.0.255

class sla-2-class
exceed-action drop
class class-default

For Both Services
The outbound interface (POS4/0) is configured as follows:

1. In global configuration mode, create a class of traffic matching experimental bit 5, called
"exp-5-traffic".
class-map match-all exp-5-traffic
match mpls experimental 5
2. Create a policy named output-interface-policy. According to that policy, packets in the class
exp-5-traffic are put in the priority queue (which is rate-limited to 62 kbits/sec).
policy-map output-interface-policy
class exp-5-traffic
priority 32
3. The policy is applied to packets exiting interface POS4/0.

interface POS4/0
service-policy output output-interface-policy
The result of the above configuration lines is that packets entering the Head-1 router via interface
FE4/1/0 destined to host 26.1.1.1, or entering the router via interface FE4/1/1 destined to subnet
26.1.1.0, will have their MPLS experimental bit set to 5. We assume that no other packets entering the
21
router (on any interface) are using this value. (If this cannot be assumed, an additional configuration
must be added to mark all such packets to another experimental value.) Packets marked with
experimental bit 5, when exiting the router via interface POS4/0, will be placed into the priority queue.
Note Packets entering the router via FE4/1/0 or FE4/1/1 and exiting POS4/0 enter as IP packets and exit as
MPLS packets.
Configuring Tunnel Head-2

First we recapitulate commands that establish two bandwidth pools and a sub-pool tunnel (as presented
earlier in this Configuration Examples section). Then we present the QoS commands that guarantee
end-to-end service on the sub-pool tunnel.
.Configuring the Pools and Tunnel

49.0000.1000.0000.0011.00
0
level-1
Loopback0

router-2(config-if)# no ip directed broadcast

[and in all cases]:
At the tunnel interface:

22

And to ensure that packets destined to subnet 26.1.1.0 are sent into the sub-pool tunnel, we create a static
route, at the device level:
router-2(config)# exit
Finally, in order to make sure that the Interior Gateway Protocol (IGP) will not send any other traffic
down this tunnel, we disable autoroute announce:
router-2(config)# no tunnel mpls traffic-eng autoroute announce
For Service from Site C to Subnet Province

2. Create an ACL, 130, to refer to all packets destined to subnet 26.1.1.0:

access-list 130 permit ip any 26.1.1.0 0.0.0.255

class sla-3-class
exceed-action drop
class class-default

The outbound interface POS0/0 is configured as follows:

1. In global configuration mode, create a class of traffic matching experimental bit 5, called
"exp-5-traffic".
class-map match-all exp-5-traffic
23
match mpls experimental 5
2. Create a policy named output-interface-policy. According to that policy, packets in the class
exp-5-traffic are put in the priority queue (which is rate-limited to 32 kbits/sec).
policy-map output-interface-policy
class exp-5-traffic
priority 32
3. The policy is applied to packets exiting interface POS0/0:

interface POS0/0
service-policy output output-interface-policy
As a result of all the above configuration lines, packets entering the Head-2 router via interface FE2/1/0
and destined for subnet 26.1.1.0 have their IP precedence field set to 5. It is assumed that no other
packets entering this router (on any interface) are using this precedence. (If this cannot be assumed, an
additional configuration must be added to mark all such packets with another precedence value.) When
exiting this router via interface POS0/0, packets marked with precedence 5 are placed in the priority
queue.
Note Packets entering the router via FE2/1/0 and exiting through POS0/0 enter as IP packets and exit as MPLS
packets.
Tunnel Midpoint Configuration [Mid-1]

All four interfaces on the midpoint router are configured identically to the outbound interface of the head
router (except, of course, for the IDs of the individual interfaces):
Configuring the Pools and Tunnels

49.0000.2400.0000.0011.00
area 0
router-3(config-router)# mpls traffic-eng network 24.1.1.1 0.0.0.0 area
level-1 0
router-3(config-router)# passive-interface network 12.1.1.0 0.0.0.255 area 0
Loopback0
router-3(config-router)# network 13.1.1.0 0.0.0.255 area 0
router-3(config-router)# mpls traffic-eng area 0
24

At the physical interface level (ingress):

[and in all cases]:

[and in all cases]:

[and in all cases]:

[and in all cases]:

Both interfaces on the midpoint router are configured identically to the outbound interface of the head
router (except, of course, for the IDs of the individual interfaces):
Configuring the Pools and Tunnel

49.2500.1000.0000.0012.00
25

area 0
level-1 0
Loopback0


[and in all cases]:

[and in all cases]:
Tunnel Tail Configuration

The inbound interfaces on the tail router are configured identically to the inbound interfaces of the
midpoint routers (except, of course, for the ID of each particular interface):

49.0000.2700.0000.0000.00
26

area 0
level-1 0
Loopback0

At the physical interface (ingress):

[and in all cases]:

[and in all cases]:
Because the tunnel ends on the tail (does not include any outbound interfaces of the tail router), no
outbound QoS configuration is used.
Example with Many Destination Prefixes

Figure 3 illustrates a topology for guaranteed bandwidth services whose destinations are a set of
prefixes. Those prefixes usually share some common properties such as belonging to the same
Autonomous System (AS) or transiting through the same AS. Although the individual prefixes may
change dynamically because of route flaps in the downstream autonomous systems, the properties the
prefixes share will not change. Policies addressing the destination prefix set are enforced through Border
Gateway Protocol (BGP), which is described in the following documents:
Configuring QoS Policy Propagation via Border Gateway Protocol in the Cisco IOS Quality of
Service Solutions Configuration Guide, Release 12.1
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_c/qcprt1/qcdprop.htm)
Configuring BGP in the Cisco IOS IP and IP Routing Configuration Guide, Release 12.1
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_c/ipcprt2/1cdbgp.h
tm)
27
BGP Commands in the Cisco IOS IP and IP Routing Command Reference, Release 12.1
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/ip_r/iprprt2/1rdbgp.ht
m)
BGP-Policy Command in the Cisco IOS Quality of Service Solutions Command Reference,
Release 12.1
(http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121cgcr/qos_r/qrdcmd1.htm
#xtocid89313)
In this example, three guaranteed bandwidth services are offered, each coming through a 7500 or a 12000
edge device:
Traffic coming from Site A (defined as all traffic arriving at interface FE4/1/0) and from Site C
(defined as all traffic arriving at interface FE2/1) destined to AS5
Traffic coming from Sites A and C that transits AS5 but is not destined to AS5. (In the figure, the
transiting traffic will go to AS6 and AS7)
Traffic coming from Sites A and C destined to prefixes advertised with a particular BGP community
attribute (100:1). In this example, Autonomous Systems #3, #5, and #8 are the BGP community
assigned the attribute 100:1.
Figure 3 Sample Topology for Guaranteed Bandwidth Service to Many Destination Prefixes
AS2
23.1.1.1
Head-1
AS3* AS7
FE4/1/0 POS4/0
Site A 24.1.1.1 27.1.1.1

Mid-1 Tail
AS5* AS6
POS2/1 POS3/1 POS2/1
POS
POS1/1 POS4/1 2/2
22.1.1.1
Head-2
25.1.1.1
Mid-2
AS4 AS8*
FE2/1 POS0/0
Site C POS1/1 POS2/1
*BGP Community 100:1
= Data flow
= Sub-pool tunnel; guaranteed bandwidth service
59025
= Global pool tunnel; best-effort service
The applicability of guaranteed bandwidth service is not limited to the three types of multiple destination
scenarios described above. There is not room in this document to present all possible scenarios. These
three were chosen as representative of the wide range of possible deployments.
The guaranteed bandwidth services run through two sub-pool tunnels:
From the Head-1 router, 23.1.1.1, to the tail
28
From the Head-2 router, 22.1.1.1, to that same tail

In addition, a global pool tunnel has been configured from each head end, to carry best-effort traffic to
the same destinations. All four tunnels use the same tail router, even though they have different heads
and differ in their passage through the midpoints. (Of course in the real world there would be many more
midpoints than just the two shown here.)
All POS interfaces in this example are OC3, whose capacity is 155 Mbps.
Configuring a multi-destination guaranteed bandwidth service involves:
a. Building a sub-pool MPLS-TE tunnel
b. Configuring DiffServ QoS
c. Configuring QoS Policy Propagation via BGP (QPPB)
d. Mapping traffic onto the tunnels
All of these tasks are included in the following example.
Configuration of Tunnel Head-1

First we recapitulate commands that establish a sub-pool tunnel (commands presented earlier on page
13) and now we also configure a global pool tunnel. Additionally, we present QoS and BGP commands
that guarantee end-to-end service on the sub-pool tunnel. (With the 7500(VIP) router, Modular QoS CLI
is used).

49.0000.1000.0000.0010.00
0
level-1


29

[and in all cases]:
At one tunnel interface, create a sub-pool tunnel:

router-1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name gbs-path1
and at a second tunnel interface, create a global pool tunnel:

router-1(config-if)# tunnel mpls traffic-eng bandwidth 80000
router-1(config-if)# tunnel mpls traffic-eng path-option 1 explicit name \
best-effort-path1
In this example explicit paths are used instead of dynamic, to ensure that best-effort traffic and
guaranteed bandwidth traffic will travel along different paths.
router-1(config)# ip explicit-path name gbs-path1
router-1(config-ip-expl-path)# next-address 24.1.1.1
router-1(config-ip-expl-path)# exit
router-1(config)# ip explicit-path name best-effort-path1
Note that autoroute is not used, as that could cause the Interior Gateway Protocol (IGP) to send other
traffic down these tunnels.
Configuring DiffServ QoS
At the inbound physical interface (in Figure 3 this is FE4/1/0), packets received are rate-limited to:
a. a rate of 30 Mbps
b. a normal burst of 1 MB
c. a maximum burst of 2 MB
Packets that are mapped to qos-group 6 and that conform to the rate-limit are marked with experimental
value 5 and the BGP destination community string, and are forwarded; packets that do not conform
(exceed action) are dropped:
router-1(config)# interface FastEthernet4/1/0
router-1(config-if)# rate-limit input qos-group 6 30000000 1000000 2000000 \
conform-action set-mpls-exp-transmit 5 exceed-action drop
router-1(config-if)# bgp-policy destination ip-qos-map
30
At the device level create a class of traffic called exp5-class that has MPLS experimental bit set to 5:
router-1(config)# class-map match-all exp5-class
router-1(config-cmap)# match mpls experimental 5
router-1(config-cmap)# exit
Create a policy that creates a priority queue for exp5-class:

router-1(config)# policy-map core-out-policy
router-1(config-pmap)# class exp5-class
router-1(config-pmap-c)# priority 100000
router-1(config-pmap-c)# exit
router-1(config-pmap)# class class-default
router-1(config-pmap-c)# bandwidth 55000
router-1(config-pmap)# exit
The policy is applied to packets exiting the outbound interface POS4/0.

router-1(config-if)# service-policy output core-out-policy
Configuring QoS Policy Propagation via BGP
For All GB Services
Create a table map under BGP to map (tie) the prefixes to a qos-group. At the device level:
router-1(config)# ip bgp-community new-format
router-1(config)# router bgp 2
router-1(config-router)# no synchronization
router-1(config-router)# table-map set-qos-group
router-1(config-router)# bgp log-neighbor-changes
router-1(config-router)# neighbor 27.1.1.1 remote-as 2
router-1(config-router)# neighbor 27.1.1.1 update-source Loopback0
router-1(config-router)# no auto-summary
For GB Service Destined to AS5
Create a distinct route map for this service. This includes setting the next-hop of packets matching
29.1.1.1 so they will be mapped onto Tunnel #1 (the guaranteed bandwidth service tunnel). At the device
level:
router-1(config)# route-map set-qos-group permit 10
router-1(config-route-map)# match as-path 100
router-1(config-route-map)# set ip qos-group 6
router-1(config-route-map)# set ip next-hop 29.1.1.1
router-1(config-route-map)# exit
router-1(config)# ip as-path access-list 100 permit ^5$
For GB Service Transiting through AS5
Create a distinct route map for this service. (Its traffic will go to AS6 and AS7).
31
router-1(config)# ip as-path access-list 101 permit _5_
For GB Service Destined to Community 100:1
Create a distinct route map for all traffic destined to prefixes that have community value 100:1. This
traffic will go to AS3, AS5, and AS8.
router-1(config-route-map)# match community 20
router-1(config)# ip community-list 20 permit 100:1
Mapping Traffic onto the Tunnels
Map all guaranteed bandwidth traffic onto Tunnel #1:

Map all best-effort traffic onto Tunnel #2:

Configuration of Tunnel Head-2

As with the Head-1 device and interfaces, the following Head-2 configuration first presents commands
that establish a sub-pool tunnel (commands presented earlier on page 13) and then also configures a
global pool tunnel. After that it presents QoS and BGP commands that guarantee end-to-end service on
the sub-pool tunnel. (Because this is a 7500 (VIP) router, Modular QoS CLI is used).

49.0000.1000.0000.0011.00
0
level-1

32

[and in all cases]:
At one tunnel interface, create a sub-pool tunnel:

router-2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name gbs-path2
and at a second tunnel interface, create a global pool tunnel:

router-2(config-if)# tunnel mpls traffic-eng bandwidth 70000
router-2(config-if)# tunnel mpls traffic-eng path-option 1 explicit name \
best-effort-path2
In this example explicit paths are used instead of dynamic, to ensure that best-effort traffic and
guaranteed bandwidth traffic will travel along different paths.
router-2(config)# ip explicit-path name gbs-path2
router-2(config)# ip explicit-path name best-effort-path2
Note that autoroute is not used, as that could cause the Interior Gateway Protocol (IGP) to send other
traffic down these tunnels.
Configuring DiffServ QoS
At the inbound physical interface (in Figure 3 this is FE2/1), packets received are rate-limited to:
a. a rate of 30 Mbps
b. a normal burst of 1 MB
c. a maximum burst of 2 MB
33
Packets that are mapped to qos-group 6 and that conform to the rate-limit are marked with experimental
value 5 and the BGP destination community string, and are forwarded; packets that do not conform
(exceed action) are dropped:
router-2(config)# interface FastEthernet2/1
router-2(config-if)# rate-limit input qos-group 6 30000000 1000000 2000000 \
conform-action set-mpls-exp-transmit 5 exceed-action drop
router-2(config-if)# bgp-policy destination ip-qos-map
At the device level create a class of traffic called exp5-class that has MPLS experimental bit set to 5:
router-2(config)# class-map match-all exp5-class
router-2(config-cmap)# match mpls experimental 5
router-2(config-cmap)# exit
Create a policy that creates a priority queue for exp5-class:

router-2(config)# policy-map core-out-policy
router-2(config-pmap)# class exp5-class
router-2(config-pmap-c)# priority 100000
router-2(config-pmap)# class class-default
router-2(config-pmap-c)# bandwidth 55000
router-2(config-pmap)# exit
The policy is applied to packets exiting interface POS0/0:

interface POS0/0
service-policy output core-out-policy
As a result of all the above configuration lines, packets entering the Head-2 router via interface FE2/1
and destined for AS5, BGP community 100:1, or transiting AS5 will have their experimental field set to
5. It is assumed that no other packets entering this router (on any interface) are using this exp bit value.
(If this cannot be assumed, an additional configuration must be added to mark all such packets with
another experimental value.) When exiting this router via interface POS0/0, packets marked with
experimental value 5 are placed into the priority queue.
Note Packets entering the router via FE2/1 and exiting through POS0/0 enter as IP packets and exit as MPLS
packets.
Configuring QoS Policy Propagation via BGP
For All GB Services
Create a table map under BGP to map (tie) the prefixes to a qos-group. At the device level:
router-2(config-router)# no synchronization
router-2(config-router)# table-map set-qos-group
router-2(config-router)# bgp log-neighbor-changes
router-2(config-router)# neighbor 27.1.1.1 remote-as 2
router-2(config-router)# neighbor 27.1.1.1 update-source Loopback0
router-2(config-router)# no auto-summary
34
For GB Service Destined to AS5
Create a distinct route map for this service. This includes setting the next-hop of packets matching
29.1.1.1 so they will be mapped onto Tunnel #3 (the guaranteed bandwidth service tunnel). At the device
level:
router-2(config)# ip as-path access-list 100 permit ^5$
For GB Service Transiting through AS5
Create a distinct route map for this service. (Its traffic will go to AS6 and AS7).
router-2(config)# ip as-path access-list 101 permit _5_
For GB Service Destined to Community 100:1
Create a distinct route map for all traffic destined to prefixes that have community value 100:1. This
traffic will go to AS3, AS5, and AS8.
router-2(config-route-map)# match community 20
router-2(config)# ip community-list 20 permit 100:1
Mapping the Traffic onto the Tunnels
Map all guaranteed bandwidth traffic onto Tunnel #3:

Map all best-effort traffic onto Tunnel #4:


All four interfaces on the midpoint router are configured very much like the outbound interface of the
head router. The strategy is to have all mid-point routers in this Autonomous System ready to carry future
as well as presently configured sub-pool and global pool tunnels.

35

49.0000.2400.0000.0011.00
area 0
level-1 0


[and in all cases]:

[and in all cases]:
At the physical interface level (egress), through which two sub-pool tunnels currently exit:
[and in all cases]:
At the physical interface level (egress), through which two global pool tunnels currently exit:
36

[and in all cases]:

Both interfaces on this midpoint router are configured like the outbound interfaces of the Mid-1 router.

49.2500.1000.0000.0012.00
area 0
level-1 0


[and in all cases]:

[and in all cases]:
37
Tunnel Tail Configuration

The inbound interfaces on the tail router are configured much like the outbound interfaces of the
midpoint routers:

[now one uses either the IS-IS commands on the left or the OSPF commands on the right. In the case of
OSPF, one must advertise two new loopback interfaces29.1.1.1 and 30.1.1.1 in our examplewhich
are defined in the QoS Policy Propagation section, further along on this page]:
49.0000.2700.0000.0000.00
area 0
router-4(config-router)# mpls traffic-eng level-1 network 27.1.1.1 0.0.0.0 area
0
router-4(config-router)# network 29.1.1.1 0.0.0.0 area
0
router-4(config-router)# network 30.1.1.1 0.0.0.0 area
0
[now one resumes the common command set, taking care to include the two additional loopback
interfaces]:

At the physical interface (ingress):

[and in all cases]:

38
[and in all cases]:

Configuring QoS Policy Propagation
On the tail device, one must configure a separate virtual loopback IP address for each class-of-service
terminating here. The headend routers need these addresses to map traffic into the proper tunnels. In the
current example, four tunnels terminate on the same tail device but they represent only two service
classes, so only two additional loopback addresses are needed:
Create two virtual interfaces:
[and in all cases]:
[and in all cases]:
At the device level, configure BGP to send the community to each tunnel head:
router-4(config-router)# neighbor 23.1.1.1 send-community
router-4(config-router)# neighbor 22.1.1.1 send-community
39
Command Reference
Command Reference
ip rsvp bandwidth
mpls traffic-eng ds-te bc-model
mpls traffic-eng ds-te mode
show mpls traffic-eng topology
tunnel mpls traffic-eng bandwidth
40
Glossary
Glossary
This section defines acronyms and words that may not be readily understood.
ASAutonomous System. A collection of networks under a common administration, sharing a common
routing strategy and identified by a unique 16-bit number (assigned by the Internet Assigned Numbers
Authority).
BGPBorder Gateway Protocol. The predominant interdomain routing protocol. It is defined by RFC 1163.
Version 4 uses route aggregation mechanisms to reduce the size of routing tables.
CBRConstraint Based Routing. The computation of traffic paths that simultaneously satisfy
label-switched path attributes and current network resource limitations.
CEFCisco Express Forwarding. A means for accelerating the forwarding of packets within a router, by
CLICommand Line Interface. Ciscos interface for configuring and managing its routers.
DS-TEDiff Serv-aware Traffic Engineering. The capability to configure two bandwidth pools on each
link, a global pool and a sub-pool. MPLS traffic engineering tunnels using the sub-pool bandwidth can
be configured with Quality of Service mechanisms to deliver guaranteed bandwidth services end-to-end
across the network. Simultaneously, tunnels using the global pool can convey DiffServ traffic.
floodingA traffic passing technique used by switches and bridges in which traffic received on an
interface is sent out through all of the interfaces of that device except the interface on which the
information was originally received.
GB queueGuaranteed Bandwidth queue. A per-hop behavior (PHB) used exclusively by the strict
guarantee traffic. If delay/jitter guarantees are sought, the diffserv Expedited Forwarding queue
(EF PHB) is used. If only bandwidth guarantees are sought, the diffserv Assured Forwarding PHB
(AF PHB) is used.
Global PoolThe total bandwidth allocated to an MPLS traffic engineering link.
IGPInterior Gateway Protocol. An internet protocol used to exchange routing information within an
autonomous system. Examples of common internet IGPs include IGRP, OSPF, and RIP.
label-switched path (LSP) tunnelA configured connection between two routers, using label
IS-ISIntermediate System-to-Intermediate System. A link-state hierarchical routing protocol, based on
DECnet Phase V routing, whereby nodes exchange routing information based on a single metric, to determine
network topology.
LCACLink-level (per-hop) call admission control.
LSPLabel-switched path (see above).
Also Link-state packetA broadcast packet used by link-state protocols that contains information about
neighbors and path costs. LSPs are used by the receiving routers to maintain their routing tables. Also called
link-state advertisement (LSA).
MPLSMulti-Protocol Label Switching (formerly known as Tag Switching). A method for directing
packets primarily through Layer 2 switching rather than Layer 3 routing, by assigning the packets short
fixed-length labels at the ingress to an MPLS cloud, 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.
MPLS TEMPLS 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.
41
Glossary
OSPFOpen Shortest Path First. A link-state, hierarchical IGP routing algorithm, derived from the IS-IS
protocol. OSPF features include least-cost routing, multipath routing, and load balancing.
RSVPResource reSerVation Protocol. An IETF protocol used for signaling requests (to set aside
internet services) by a customer before that customer is permitted to transmit data over that portion of
the network.
Sub-poolThe more restrictive bandwidth in an MPLS traffic engineering link. The sub-pool is a
portion of the links overall global pool bandwidth.
TETraffic engineering. 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.
Note See Internetworking Terms and Acronyms for terms not included in this glossary.
coincidental.
42
MPLS Traffic Engineering: Path, Link, and
Node Protection
MPLS Traffic Engineering: Inter-AS TE

The MPLS Traffic Engineering: Inter-AS TE feature provides Autonomous System Boundary Router
(ASBR) node protection, loose path reoptimization, stateful switchover (SSO) recovery of
label-switched paths (LSPs) that include loose hops, ASBR forced link flooding, Cisco IOS Resource
Reservation Protocol (RSVP) local policy extensions for interautonomous system (Inter-AS), and
per-neighbor keys:
ASBR node protectionProtects interarea and Inter-AS TE label-switched paths (LSPs) from the
failure of an Area Border Router (ABR) or ASBR.
Loose path reoptimizationAllows a Multiprotocol Label Switching (MPLS) traffic engineering
(TE) tunnels LSPs to traverse hops that are not in the tunnel headend routers topology database
(that is, they are not in the same Open Shortest Path First (OSPF) area, Intermediate
System-to-Intermediate System (IS-IS) level, or autonomous system as the tunnels headend router).
Loose hop recoverySupports SSO recovery of LSPs that include loose hops.
ASBR forced link floodingHelps an LSP cross a boundary into another domain when information
in the other domain is not available to the headend router.
Cisco IOS RSVP local policy extensions for Inter-ASAllows network administrators to create
controlled policies for TE tunnels that function across multiple autonomous systems.
Per-neighbor keysAllows cryptographic authentication to be accomplished on a per-neighbor
basis.

feature is supported, use the Feature Information for MPLS Traffic Engineering: Inter-AS TE section on
page 27.
Contents
Contents
Prerequisites for MPLS Traffic Engineering: Inter-AS TE, page 2
Restrictions for MPLS Traffic Engineering: Inter-AS TE, page 2
Information About MPLS Traffic Engineering: Inter-AS TE, page 3
How to Configure MPLS Traffic Engineering: Inter-AS TE, page 11
Configuration Examples for MPLS Traffic Engineering: Inter-AS TE, page 21
Feature Information for MPLS Traffic Engineering: Inter-AS TE, page 27
Glossary, page 28
Prerequisites for MPLS Traffic Engineering: Inter-AS TE

Enable MPLS.
Configure TE on routers.
Ensure that your network supports the following Cisco IOS features:
MPLS
IS-IS or OSPF
For loose path reoptimization, know how to configure the following:
IP explicit paths for MPLS TE tunnels
Loose hops
Interarea and Inter-AS tunnels
Restrictions for MPLS Traffic Engineering: Inter-AS TE

Loose Path Reoptimization
Midpoint reoptimization is not supported.
ASBR Forced Link Flooding

The TE metric and affinity attributes that are known at a headend router (and used as constraints
when an LSPs path is computed) are not currently signaled. Consequently, explicit router (ERO)
expansions do not consider these constraints.
Each node in an autonomous system must have a unique router ID.
The router ID configured on a link must not conflict with the router ID within the autonomous
system.
2
Information About MPLS Traffic Engineering: Inter-AS TE
If a link is configured for forced link flooding, the links neighbors are not learned by regular Interior
Gateway Protocol (IGP) updates. If a link is already learned about neighbors by IGP on a link, you
cannot configure the link as passive. Therefore, to configure a link for forced flooding, be sure that
the node does not already have a neighbor on that link.

To configure the MPLS Traffic Engineering: Inter-AS TE feature, you need to understand the following
concepts:
MPLS Traffic Engineering Tunnels, page 3
Multiarea Network Design, page 3
Fast Reroute, page 4
ASBR Node Protection, page 4
Loose Path Reoptimization, page 7
ASBR Forced Link Flooding, page 9
Link Flooding, page 11
MPLS Traffic Engineering Tunnels

MPLS TE lets you build LSPs across your network that you then forward traffic down.
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.
Interarea tunnels allow you to do the following:
Build TE tunnels between areas (interarea tunnels)
Build TE tunnels that start and end in the same area, on multiple areas on a router (intra-area tunnels)
Some tunnels are more important than others. For example, you may have tunnels carrying Voice over
IP (VoIP) traffic and tunnels carrying data traffic that are competing for the same resources. Or you may
simply have some data tunnels that are more important than others. 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.
Multiarea Network Design

You can establish MPLS TE tunnels that span multiple IGP areas and levels. The tunnel headend routers
and tailend routers do not have to be in the same area. The IGP can be either IS-IS or OSPF.
To configure an interarea tunnel, use the next-address loose command to specify on the headend router
a loosely routed explicit path of the LSP that identifies each ABR the LSP should traverse. The headend
router and the ABRs along the specified explicit path expand the loose hops, each computing the path
segment to the next ABR or tunnel destination.
3
Fast Reroute
MPLS Fast Reroute (FRR) is a fast recovery local protection technique that protects TE LSPs from link,
shared risk link group (SRLG), and node failure. One or more TE LSPs (called backup LSPs) are
preestablished to protect against the failure of a link, node, or SRLG. If there is a failure, each protected
TE LSP traversing the failed resource is rerouted onto the appropriate backup tunnels.
The backup tunnel must meet the following requirements:
It should not pass through the element it protects.
It should intersect with a primary tunnel at a minimum of two nodes: point of local repair (PLR) and
merge point (MP). The PLR should be the headend LSR of the backup tunnel, and the MP should
be the tailend LSR of the backup tunnel. The PLR is where FRR is triggered when a link, node, or
SRLG failure occurs.
FRR protection can be performed for an Inter-AS tunnel only if the backup tunnels merge point can
route packets to the PLRs backup tunnels egress interface. You can configure a static route or you
can configure Border Gateway Protocol (BGP) to export the backup tunnels egress interface to
other autonomous systems.
If the preferred link is a passive link, you must assign an administrative-weight for it. To assign an
administrative weight, use the mpls traffic-eng administrative-weight command in interface
configuration mode.
Each router must be configured with the mpls traffic-eng reoptimize events link-up command in
global configuration mode.
ASBR Node Protection

A TE LSP that traverses an ASBR needs a special protection mechanism (ASBR node protection)
because the MP and PLR will be in different autonomous systems that have different IGPs.
A PLR ensures that the backup tunnel intersects with the primary tunnel at the MP by examining the
Record Route Object (RRO) of the primary tunnel to see if any addresses specified in the RRO match
the destination of the backup tunnel.
Addresses specified in RRO IPv4 and IPv6 subobjects can be node-IDs and interface addresses. The
traffic engineering RFC 3209 specifies that you can use a router address or interface address, but
recommends using the interface address of outgoing path messages. Therefore, in Figure 1 router R2 is
more likely to specify interface addresses in the RRO objects carried in the resv messages of the primary
tunnel (T1) and the backup tunnel.
Node IDs allow the PLR to select a suitable backup tunnel by comparing node IDs in the resv RRO to
the backup tunnels destination.
RSVP messages that must be routed and forwarded to the appropriate peer (for example, an
resv message) require a route from the MP back to the PLR for the RSVP messages to be delivered. The
MP needs a route to the PLR backup tunnels outgoing interface for the resv message to be delivered.
Therefore, you must configure a static route from the MP to the PLR. For the configuration procedure,
see the Configuring a Static Route from the MP to the PLR section on page 14.
Figure 1 illustrates ASBR node protection. Router R4 is node-protected with a backup tunnel from
R2-R3-R5-R6.
4
Figure 1 ASBR Node Protection
PLR backup tunnel outgoing

Protected interface interface 10.10.3.1
10.10.4.1
AS100 Link that is being AS200
link-flooded
R2 R4
1 2
0 0
R1 1 R6
2
103550
R3 R5
= Primary tunnel (tunnel 100)

= Ethernet connection
= Serial line connection
= Backup tunnel (tunnel 102)
Notes:
There are two autonomous systems.
The numbers within the Ethernet serial
connection indicate the OSPF area number.
There is no IGP between R2 and R4,
and R3 and R5.
In this configuration, IP addresses are as follows:

R1Loopback0 10.10.0.1
Ethernet 0IP address of 10.10.1.1 is connected to R2 Ethernet 0
Serial 2IP address of 10.10.4.1 is connected to R4 serial 2
5

In Figure 1, the following situations exist:
Routers R1, R2, and R3 are in AS 100. The R1-R2 and R1-R3 links are in OSPF area 1.
Routers R4, R5, and R6 are in AS200. The R4-R6 and R5-R6 links are in OSPF area 2.
The link R2-R3 is in AS100, and link R4-R5 is in AS200. The links R2-R3 and R4-R5 are in OSPF
area 0.
The links R2-R4 and R3-R5 are not running an IGP because they cross the Inter-AS boundary
between AS100 and AS200. Because they are not running IGP, you must configure an administrative
weight for each passive interface for FRR to work. Use the mpls traffic-eng administrative-weight
command in interface configuration mode.
There is a primary tunnel, tunnel 100, from R1-R2-R4-R6.
There is a backup tunnel, tunnel 102, from R2-R3-R5-R6.
There is a TE tunnel, tunnel 101, from R6-R5-R3-R1 for returning data traffic for tunnel 100.
There is a TE tunnel, tunnel 103, from R6-R5-R3-R2 for returning data traffic for tunnel 102.
The explicit paths of all the tunnels use loose hops.
The R2-R4 link is configured to be link flooded in both R2s and R4s IGP. The R3-R5 link is
configured to be link flooded in both R3s and R5s IGP.
Router R2 needs to ensure the following:
Backup tunnel intersects with the primary tunnel at the MP, and therefore has a valid MP address.
In Figure 1, R2 needs to determine that tunnel 100 and backup tunnel 102 share MP node R6.
Backup tunnel satisfies the request of the primary LSP for bandwidth protection. For example, the
amount of bandwidth guaranteed for the primary tunnel during a failure, and the type of protection
(preferably protecting against a node failure rather than a link failure).
Node-IDs Signaling in RROs

ASBR node protection includes a node-ID flag (0x20), which is also called a node-ID subobject. When
it is set, the flag indicates that the address specified in the RRO object in the resv message is the node-ID
address. The node-ID address refers to the traffic engineering router ID.
A node must always use the same address in the RRO (that is, it must use IPv4 or IPv6, but not both).
To display all the hops, enter the following command on the headend router. Sample command output is
as follows:
Router(config)# show ip rsvp reservations detail
Reservation:
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
Next Hop: 10.10.1.2 on Ethernet0/0
Label: 17 (outgoing)
Reservation Style is Shared-Explicit, QoS Service is Controlled-Load
Average Bitrate is 10K bits/sec, Maximum Burst is 1K bytes
6
Min Policed Unit: 0 bytes, Max Pkt Size: 0 bytes

RRO:
10.10.0.2/32, Flags:0x29 (Local Prot Avail/to NNHOP, Is Node-id)
10.10.4.1/32, Flags:0x9 (Local Prot Avail/to NNHOP)
Label subobject: Flags 0x1, C-Type 1, Label 17
10.10.0.4/32, Flags:0x20 (No Local Protection, Is Node-id)
10.10.7.1/32, Flags:0x0 (No Local Protection)
10.10.0.6/32, Flags:0x20 (No Local Protection, Is Node-id)
Resv ID handle: 0100040E.
Status:
Policy: Accepted. Policy source(s): MPLS/TE
For a description of the fields, see the Cisco IOS Quality of Service Solutions Command Reference.
Addition of the Node-ID Subobject

When a fast reroutable LSP is signaled, the following actions occur:
An LSR adds a node-ID subobject and an incoming label subobject in the resv message.
If there is an RRO object in the path message, an LSR adds a node-ID subobject, an RRO IPv4
subobject that records the interface address, and an incoming label subobject in the resv message.
If you enable record-route on the headend LSR, the interface addresses for the LSP are included in the
RRO object of the resv message.
To enable record-route, enter the following command with the record-route keyword:
tunnel mpls traffic-eng record-route
Processing of an RRO with Node-ID Subobjects

The node-ID subobject is added to the RECORD_ROUTE object before the label route subobject. If
RECORD_ROUTE is turned on, the RRO object consists of the following in this order: node-ID,
interface address, and label.
Merge Point Location

The destination of the backup tunnel is the node-ID of the MP. A PLR can find the MP and appropriate
backup tunnel by comparing the destination address of the backup tunnel with the node-ID subobjects
included in the resv RRO for the primary tunnel.
When both the IPv4 node-ID and IPv6 node-ID subobjects are present, a PLR can use either or both of
them to find the MP address.
Determination of Backward Compatibility

To remain compatible with nodes that do not support RRO IPv4 or IPv6 node-ID subobjects, a node can
ignore those objects. Those nodes cannot be the MP in a network with interarea or Inter-AS traffic
engineering.
Loose Path Reoptimization

Interarea and Inter-AS LSPs
If the LSP of an MPLS TE tunnel traverses hops that are not in the headend routers topology database
(that is, the hops are in a different OSPF area or IS-IS level), the LSP is called an interarea TE LSP.
7
If the LSP of the tunnel traverses hops that are in a different autonomous system (AS) from the tunnels
headend router, the LSP is called an Inter-AS TE LSP.
Interarea LSPs and Inter-AS TE LSPs can be signaled using loose hop subobjects in their EROs. The
headend does not have strict knowledge of hops beyond its area, so the LSPs path is loosely
specified at the headend. Downstream routers processing these loose hop subobjects (which do have the
knowledge) are relied upon to expand them into strict hops.
Loose Hop Configuration

Beyond the headend area, configure hops as loose hops. Typically you specify only the ABRs and the
tailend router of a tunnel, but any other combination is allowed.
Loose Hop Expansion

Loose hop expansion is the conversion of a single ERO loose hop subobject into one or more strict hop
subobjects.
Interarea and Inter-AS TE LSPs can be signaled using loose hop subobjects in their EROs. When a router
receives a path message containing an ERO that has a loose hop as the next address, the router typically
expands the ERO by converting the single loose hop subobject into one or more strict hop subobjects.
The router typically has the knowledge, in its topology database, of the best way to reach the loose hop
and computes this path by using constraint-based shortest path first (CSPF). So the router substitutes this
more specific information for the loose hop subobject found in the ERO. This process is called loose hop
expansion or ERO expansion.
Loose hop expansions can occur at one or more hops along an LSPs path. This process is referred to as
loose path reoptimization.
Tunnel Reoptimization Procedure

Tunnel reoptimization is the signaling of an LSP that is more optimal than the LSP a TE tunnel is
currently using (for example, it may be shorter or may have a lower cost), and the switching over of the
tunnels data to use this new LSP.
The new more optimal TE LSP is always established and the data moved onto it before the original LSP
is torn down (so it is called the make before break procedure). This ensures that no data packets are
lost during the transition to the new LSP.
For tunnel reoptimization to function:
Each router must be configured with the mpls traffic-eng reoptimize events link-up command.
Each passive link must have an assigned administrative weight. To configure an administrative
weight, use the mpls traffic-eng administrative-weight command in interface configuration mode.
The TE LSPs reoptimization process is triggered under the following circumstances:
Periodically (based on a timer)
User entered a command (mpls traffic-eng reoptimize) requesting reoptimization
Network event, such as a link-up
Regardless of how reoptimization is triggered, the headend router reoptimizes a tunnel only if it can find
a better path than the one the tunnel currently uses. If there is not a better path in the local topology
database, no new LSP is signaled and reoptimization does not occur.
Prior to the addition of loose path reoptimization, interarea TE LSPs were not reoptimized if a better
path became available in any area beyond the headend area. This is because the headend router was not
capable of finding a better path when the better path existed in an area beyond its view (that is, it was
not in its local topology database).
8
With the addition of loose path reoptimization, a tunnels headend can reoptimize LSPs even if they span
multiple areas, levels, or autonomous systems. This is done via the implementation of a query and
response protocol defined in draft-vasseur-mpls-loose-path-reopt-02.txt. This draft defines a protocol
whereby a tunnels headend may query downstream routers to perform ERO expansion for this tunnels
LSP. These downstream routers respond in the affirmative if they can find a more optimal path than the
one in use. (This is done via a new ERO expansion.) Having received an affirmative answer to its query,
a headend signals a new LSP for the tunnel, and the new LSP benefits from a new ERO expansion along
the better path.
Loose path reoptimization is on by default, and cannot be disabled. Whenever an LSP reoptimization is
attempted but the headend fails to find a better path, if the LSP contains loose ERO subobjects, a query
is sent downstream to determine whether downstream routers can find a better path. If an affirmative
answer comes back, the LSP is reoptimized. That is, a new LSP is signaled (which will follow the better
path), the tunnels data packets are switched over to use this new LSP, and the original LSP is torn down.
For details on this query and response protocol, see draft-vasseur-mpls-loose-path-reopt-02.txt.
ASBR Forced Link Flooding

When you configure forced link flooding on an interface, the MPLS TE link management module
advertises the link to all nodes. As a result of this advertisement, the TE topology database on all the
nodes within the Inter-AS is updated with this information.
ASBR forced link flooding allows the links to be advertised even if IGP adjacencies are not running over
these links. TE LSPs can traverse these links at the edge of a network between two nodes running BGP
(or static routes) even if the exit ASBR is not listed in the IP explicit path. Therefore, a headend LSR
can consider that link when it computes its TE LSP path.
Configuration of ASBR Forced Link Flooding

To activate ASBR forced link flooding, configure a link as passive and provide neighbor information
(that is, the neighbor IGP ID and the neighbor TE ID). The required configuration tasks are described in
the Configuring a Static Route from the MP to the PLR section on page 14.
Link Flooding
A passive link is configured on an interface of an ASBR. The link is flooded in the ASBRs IGP. All the
links are flooded as point-to-point links.
Flooding notifications are also sent when there is a change to a links property.
OSPF Flooding
OSPF floods opaque link-state advertisement (LSA) Type 10 link information.
If a multiaccess link has more than one neighbor, a Type 10 LSA is advertised for each neighbor. In the
topology database, neighbors are represented by point-to-point neighbor relationships.
Link TLV
A link TLV describes a single link and contains multiple sub-TLVs.
An opaque LSA contains a single link TLV.
For each ASBR-to-ASBR link, an ASBR must flood an opaque LSA containing one link TLV that has
the links attributes.
A link TLV comprises the following sub-TLVs:
9
Link type (1 octet)(Required) Defines the type of the link. The link type of a passive interface
always is 1 (point-to-point), even for a multiaccess subnetwork.
Link ID (4 octets)(Required) Identifies the other end of the link for a point-to-point link. Includes
the system ID of the neighbor, requires static configuration for a multiaccess ASBR-to-ASBR link,
and includes the system ID of the neighbor.
Local interface IP address (4 octets)Specifies the IP addresses of the neighbors interface
corresponding to this link.
Remote interface IP address (4 octets)Specifies the IP addresses of the neighbors interface
corresponding to this link. The remote interface IP address is set to the router ID of the next hop.
There must be a static configuration for the ASBR-to-ASBR link.
Traffic engineering metric (4 octets)
Maximum bandwidth (4 octets)
Maximum reservable bandwidth (4 octets)
Unreserved bandwidth (32 octets)
Administrative group (4 octets)
IS-IS TLV
In IS-IS, when autonomous system A1 floods its LSP, it includes the system ID and a pseudonode
number.
If three autonomous systems are connected to a multiaccess network LAN, each link is considered to be
a point-to-point link. The links are marked with the maximum metric value so that the inter-ASBR links
are considered by CSPF and not by shortest path first (SPF).
TE uses the protocol TLV type 22, which has the following data structure:
System ID and pseudonode number node (7 octets)
Default metric (3 octets)
Length of sub-TLVs (1 octet)
Sub-TLVs (0 to 244 octets), where each sub-TLV consists of a sequence of the following: 1 octet for
subtype, 1 octet for the length of the value field of the sub-TLV, and 0 to 242 octets for the value
Table 1 defines the sub-TLVs.
Table 1 Sub-TLVs
Sub-TLV Length (Octets) Name

3 4 Administrative group (color).
6 4 IPv4 address for the interface described by the
main TLV.
8 4 IPv4 address for a neighboring router on this link.
This will be set to the router ID of the next hop.
9 4 Maximum link bandwidth.
10 4 Reservable link bandwidth.
11 32 Unreserved bandwidth.
18 3 TE default metric.
10
How to Configure MPLS Traffic Engineering: Inter-AS TE
Table 1 Sub-TLVs (continued)
Sub-TLV Length (Octets) Name

250 to 254 Reserved for Cisco-specific extensions.
255 Reserved for future expansion.
Note The TE router ID is TLV type 134.
Topology Database
When the topology database module receives a link-state advertisement (LSA), the module scans the
LSA to find the neighbors of the links. The ASBR link is part of the same LSA and is installed in the TE
topology database like any other link.
During the CSPF operation, the TE headend module uses the TE topology database to find a path to the
destination. Because the Inter-AS links are part of the TE topology database, the CSPF operation uses
these links to compute the LSP path.
Link Flooding
The IGP floods information about a link in the following situations:
When a link goes down
When a links configuration is changed (for example, when the link cost is modified)
When it is time to periodically reflood the routers IGP information
When link bandwidth changes significantly
Flooding is a little different in IS-IS and OSPF. In OSPF, only information about the link that has
changed is flooded, because a Type 10 LSA contains a single link advertisement. In IS-IS, information
about all links on a node is flooded even if only one has changed, because the Type 22 TLV contains a
list of all links on the router.

This section contains the following procedures for configuring MPLS Traffic Engineering: Inter-AS TE:
Configuring Loose Hops, page 12
Configuring a Static Route from the MP to the PLR, page 14
Configuring ASBR Forced Link Flooding, page 15
Note There is no configuration procedure for loose path reoptimization.
11
Configuring Loose Hops

The section describes how to do the following so that there can be loose hops:
Configuring an Explicit Path on the Tunnel That Will Cross the Inter-AS Link, page 12 (required)
Configuring a Route to Reach the Remote ASBR, page 14 (required)
Configuring an Explicit Path on the Tunnel That Will Cross the Inter-AS Link
If you want a tunnel to span multiple networks, configure an explicit path on the tunnel that will cross
the Inter-AS link by performing the following steps.
SUMMARY STEPS
1. enable
3. ip explicit-path {name path-name | identifier number} [enable | disable]
4. next-address loose A.B.C.D
6. tunnel mpls traffic-eng fast-reroute
7. mpls traffic-eng reoptimize events link-up
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip explicit-path {name path-name | identifier Enters the subcommand mode for IP explicit paths and
number} [enable | disable] creates or modifies the explicit path. This command
places the router in IP explicit path configuration
Example: mode.
Router(config)# ip explicit-path identifier 2 enable
Step 4 next-address loose A.B.C.D Specifies the next loose IP address in the explicit path.
Each area border router (ABR) the path must traverse
should be specified in a next-address loose command.
Example:
Router(cfg-ip-expl-path)# next-address loose
This command places the router in global
10.10.0.2 configuration mode.
12

Step 5 interface tunnel number Configures a tunnel interface. This command places
the router in interface configuration mode.
Example:
Step 6 tunnel mpls traffic-eng fast-reroute Enables an MPLS traffic engineering tunnel to use an
established backup tunnel in the event of a link failure.
Example:
fast-reroute
Step 7 mpls traffic-eng reoptimize events link-up Enables automatic reoptimization of MPLS traffic
engineering when an interface becomes operational.
Example:
Router(config)# mpls traffic-eng reoptimize events
link-up
13
Configuring a Route to Reach the Remote ASBR

To configure a route to reach the remote ASBR, perform the following steps.
SUMMARY STEPS
1. enable
3. ip route prefix mask {ip-address | interface-type interface-number}
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip route prefix mask {ip-address | Establishes static routes.
interface-type interface-number}
Example:
Router(config)# ip route 10.10.0.1
255.255.255.255 tunnel 101
Configuring a Static Route from the MP to the PLR

To enable Fast Reroute protection that spans across different autonomous systems, configure a static
route from the MP to the PLR by performing the following steps.
SUMMARY STEPS
1. enable
3. ip route prefix mask ip-address outgoing-interface
14
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip route prefix mask ip-address Establishes static routes.
outgoing-interface
Note Enter this command on the MP. The destination is
the PLR.
Example:
Router(config)# ip route 10.10.3.1
255.255.255.255 10.0.0.0 FastEthernet0/0
Configuring ASBR Forced Link Flooding

This section describes how to do the following so that you can configure ASBR forced link flooding:
Configuring the Inter-AS Link as a Passive Interface Between Two ASBRs, page 15 (required)
Creating LSPs Traversing the ASBRs, page 16(required)
Configuring Multiple Neighbors on a Link, page 18 (optional)
Configuring the Inter-AS Link as a Passive Interface Between Two ASBRs

To configure the Inter-AS link as a passive interface between two ASBRs, perform the following steps.
SUMMARY STEPS
1. enable
5. mpls traffic-eng passive-interface nbr-te-id te-router-id [nbr-if-addr if-addr] [nbr-igp-id {isis
sysid | ospf sysid}]
6. mpls traffic-eng administrative-weight weight
15
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/port Specifies an interface and enters interface
configuration mode.
Example:
Router(config)# interface serial 2/0
Step 4 ip address ip-address mask [secondary] Sets a primary or secondary IP address for an
interface.
Example:
Router(config-if)# ip address 10.10.4.1 255.255.255.0
Step 5 mpls traffic-eng passive-interface nbr-te-id te-router-id Configures a link as a passive interface
[nbr-if-addr if-addr] [nbr-igp-id {isis sysid | ospf between two ASBRs.
sysid}]
Note For an RSVP Hello configuration on
the Inter-AS link, all fields are
Example: required.
Router(config-if)# mpls traffic-eng passive-interface
nbr-te-id 10.10.11.12 nbr-igp-id ospf 10.10.15.18
Step 6 mpls traffic-eng administrative-weight weight Overrides the Interior Gateway Protocol (IGP)
administrative weight (cost) of the link and
assigns a specific weight for the link.
Example:
Router(config-if)# mpls traffic-eng administrative-weight
20
Creating LSPs Traversing the ASBRs

To create LSPs traversing the ASBRs, perform the following steps.
Note Perform Steps 3 through 7 for the primary LSP and then for the backup LSP.
SUMMARY STEPS
1. enable
3. ip explicit path name enable
4. next-address loose A.B.C.D
16

7. tunnel mpls traffic-eng path-option number {dynamic | explicit | {name path-name |
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip explicit path name enable Specifies the name of the explicit path and enables the path.
Example:
Router(config)# ip explicit path route1 enable
Step 4 next-address loose A.B.C.D Configures a loose hop.
Example:
Router(config)# next-address loose 10.10.10.2
configuration mode.
Example:
Step 6 tunnel mpls traffic-eng fast-reroute Enables an MPLS traffic engineering tunnel to use an
established backup tunnel in the event of a link failure.
Example:
fast-reroute
Step 7 tunnel mpls traffic-eng path-option number Configures a path option for an MPLS traffic engineering
{dynamic | explicit | {name path-name | tunnel.
Example:
path-option 1 route1
17
Configuring Multiple Neighbors on a Link

To configure multiple neighbors on a link, perform the following steps.
SUMMARY STEPS
1. enable
4. mpls traffic-eng passive-interface [nbr-te-id] [router-id | te-id] [nbr-igp-id] [isis sysid | ospf
sysid]
5. mpls traffic-eng administrative-weight weight
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/port Specifies an interface and enters interface configuration
mode.
Example:
Step 4 mpls traffic-eng passive-interface [nbr-te-id] Configures a link as a passive link.
[router-id | te-id] [nbr-igp-id] [isis sysid |
ospf sysid]
Example:
Router(config-if)# mpls traffic-eng
passive-interface nbr-te-id 10.10.0.4
nbr-igp-id ospf 10.10.0.4
Step 5 mpls traffic-eng administrative-weight weight Overrides the Interior Gateway Protocol (IGP)
administrative weight (cost) of the link and assigns a
specific weight for the link.
Example:
Router(config-if)# mpls traffic-eng
administrative-weight 20
The following debug commands are useful for troubleshooting issues with MPLS Traffic Engineering:
Inter-AS TE.
18
Note The debug commands are described in detail in the Cisco IOS Debug Command Reference,
Release 12.4.
Debugging Headend of TE LSPs

debug mpls traffic-eng path lookup
debug mpls traffic-eng path verify
debug mpls traffic-eng path spf
Debugging Head and Midpoint (Link-Related Debugs)

debug mpls traffic-eng link-management igp-neighbors
debug mpls traffic-eng link-management advertisements
debug mpls traffic-eng link-management bandwidth-allocation
debug mpls traffic-eng link-management routing
Verifying the Inter-AS TE Configuration

To verify the Inter-AS TE configuration, perform the following steps.
Note Perform Step 1 for Fast Reroute ready, and Step 2 for Fast Reroute active.
SUMMARY STEPS
1. show ip rsvp sender detail

3. show mpls traffic-eng link-management advertisements
DETAILED STEPS
Step 1 show ip rsvp sender detail

Use this command to display the MP sender display for the primary tunnel when Fast Reroute is ready.
Router# show ip rsvp sender detail
PATH:
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.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
19
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

Use this command to display the MP sender display when the primary tunnel is Fast Reroute active:
PATH:
Path refreshes:
Session Attr:
Session Name: R1_t100
ERO: (incoming)
10.10.0.6 (Loose IPv4 Prefix, 8 bytes, /32)
RRO:
10.10.3.1/32, Flags:0xB (Local Prot Avail/In Use/to NNHOP) !Ready
Inbound FRR: Active
Orig Input I/F: Et0/0
Orig PHOP: 10.10.7.1
Now using Bkup Filterspec w/ sender: 10.10.3.1 LSP ID: 31
Step 3 show mpls traffic-eng link-management advertisements

Use this command to display the influence of a passive link. On R2, the passive link to R4 is in the Link
ID:: 1 section.
Router# show mpls traffic-eng link-management advertisements
Flooding Status: ready

Configured Areas: 2
IGP Area[1] ID:: ospf 1 area 0
System Information::
Flooding Protocol: OSPF
Header Information::
IGP System ID: 10.10.0.2
MPLS TE Router ID: 10.10.0.2
Flooded Links: 2
Link ID:: 1
Link Subnet Type: Point-to-Point
Link IP Address: 10.10.4.1
IGP Neighbor: ID 0-0-0-0-0-0-0, IP 10.10.0.4
Physical Bandwidth: 1544 kbits/sec
Res. Global BW: 1158 kbits/sec
Res. Sub BW: 0 kbits/sec
Downstream::
20
Configuration Examples for MPLS Traffic Engineering: Inter-AS TE

----------- ---------
Reservable Bandwidth[0]: 1158 0 kbits/sec
Attribute Flags: 0x00000000
IGP Area[1] ID:: ospf 1 area 1
Flooding Protocol: OSPF
IGP System ID: 10.10.0.2
Flooded Links: 2
Link ID:: 1
IGP Neighbor: ID 0-0-0-0-0-0-0, IP 10.10.0.4
Downstream::
----------- -----------
Configuration Examples for MPLS Traffic Engineering: Inter-AS

TE
This section provides the following configuration examples for MPLS Traffic Engineering: Inter-AS TE:
Configuring Loose Hops: Examples, page 21
Configuring a Static Route from the MP to the PLR: Example, page 22
Configuring ASBR Forced Link Flooding: Examples, page 22
Configuring Loose Hops: Examples

This section includes the following:
Configuring an Explicit Path on the Tunnel That Will Cross the Inter-AS Link: Example, page 22
Configuring a Route to Reach the Remote ASBR in the IP Routing Table: Example, page 22
21
Configuring an Explicit Path on the Tunnel That Will Cross the Inter-AS Link: Example
The following commands configure a loose IP explicit path named route1 suitable for use as a path
option with Inter-AS TE with the destination 10.10.10.6 that is to traverse ABRs 10.10.0.2 and
10.10.0.4. The tunnel headend and the specified ABRs will find a path from the source AS100 to the
destination 10.10.0.6 in AS200. See Figure 1.
Router(config)# ip explicit-path name route1 enable
Router(cfg-ip-expl-path)# next-address loose 10.10.0.2
Note that the explicit path for an interarea TE tunnel need not specify the destination router because the
tunnel configuration specifies it in the tunnel destination command. The following commands configure
an explicit path named path-without-tailend that would work equally well for the interarea tunnel created
in the previous example:
Router(config)# ip explicit-path name path-without-tailend

Configuring a Route to Reach the Remote ASBR in the IP Routing Table: Example
In the following example, packets for the ASBR whose router ID is 10.10.0.1 will be forwarded via
tunnel 101:
Router> enable
Router(config)# ip route 10.10.0.1 255.255.255.255 tunnel 101
Configuring a Static Route from the MP to the PLR: Example

In the following example, a static route is configured from the MP to the PLR. The outgoing interface is
tunnel 103.
Router> enable
Router(config)# ip route 10.10.3.1 255.255.255.255 tunnel 103
Configuring ASBR Forced Link Flooding: Examples

This section includes the following ASBR forced link flooding examples:
Configuring the Inter-AS Link as a Passive Interface: Example, page 23
Creating LSPs Traversing the ASBRs: Example, page 24
Configuring Multiple Neighbors on a Link: Example, page 24
22
Configuring the Inter-AS Link as a Passive Interface: Example

For this example, see Figure 1.
Routers R2 and R4 have the following router IDs:
Router R210.10.0.2
Router R410.10.0.4
Router> enable
Configures OSPF on Router R2 When Its Neighbor Is Running OSPF Too

Router(config-if)# mpls traffic-end passive-interface nbr-te-id 10.10.0.4
Note Because both routers are running OSPF, the nbr-igp-id keyword is not specified.
Specifies That Both Router R2 and Its Neighbor Are Running OSPF (the nbr-igp-id Keyword Is Specified)
Router(config-if)# mpls traffic-eng passive-interface nbr-te-id 10.10.0.4 nbr-igp-id ospf
10.10.0.4
Configures IS-IS on Router R1

Router(config-if)# mpls traffic-eng passive-interface nbr-te-id 10.10.0.4 nbr-igp-id isis
40.0000.0002.0001.00
Configures the Neighbor IGP ID (nbr-igp-id) When There Is More than One Neighbor Specified on a Link
Router(config-if)# mpls traffic-end passive-interface nbr-te-id 10.10.0.4 nbr-igp-id ospf
10.10.0.4

10.10.0.7
Overrides the Interior Gateway Protocol (IGP) Administrative Weight of the Link and Assigns a Specific Weight
Router(config-if)# mpls traffic-eng administrative-weight 20
Note The ID is unique for each neighbor.
Configures a Link as a Passive Interface (Includes Global TE Commands)

interface serial 2/0
ip address 10.10.4.1.255.255.255.0
mpls traffic-eng administrative-weight 10
mpls traffic-eng passive-interface nbr-te-id 10.10.0.4 nbr-igp-id ospf 10.10.0.4
mpls traffic-eng administrative-weight 20
23
Creating LSPs Traversing the ASBRs: Example

In the following example, a primary LSP is created:
Router> enable
Router(config)# ip explicit path route1 enable
Router(config-if)# tunnel mpls traffic-eng fast reroute
Router(config-if)# tunnel mpls traffic-eng path-option 1 route1
In the following example, a backup LSP is created:

Router> enable
Router(config)# ip explicit path backpath1 enable
Router(config)# mpls traffic-eng backup path tunnel 102
Router(config-if)# tunnel mpls traffic-eng path-option 1 backpath1
Configuring Multiple Neighbors on a Link: Example

In the following example, there is more than one neighbor on a link:
Router> enable
10.10.0.4
Router(config-if)# mpls traffic-eng administrative-weight 20
24
The following sections provide references related to the MPLS Traffic Engineering: Inter-AS TE feature.
Related Documents
MPLS traffic engineering commands: complete Cisco IOS Multiprotocol Label Switching Command Reference
command syntax, command mode, command history,
defaults, usage guidelines, and examples
Fast Reroute MPLS TE: Link and Node Protection, with RSVP Hellos Support
Link flooding and node protection MPLS Traffic Engineering: Interarea Tunnels
IS-IS configuration tasks Configuring a Basic IS-IS Network
OSPF configuration tasks Configuring OSPF
IS-IS and OSPF commands: complete command Cisco IOS IP Routing Protocols Command Reference
syntax, command mode, command history, defaults,
usage guidelines, and examples
RSVP RSVP Message Authentication
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title
RFC 3209 Extensions to RSVP for LSP Tunnels
draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt Fast Reroute Extensions to RSVP-TE for LSP Tunnels
draft-vasseur-mpls-loose-path-reopt-02.txt Reoptimization of an Explicitly Loosely Routed MPLS TE Path
25
Command Reference
RFCs Title
draft-vasseur-mpls-inter-as-te-00.txt MPLS Inter-AS Traffic Engineering
draft-ietf-mpls-soft-preemption-00.txt MPLS Traffic Engineering Soft Preemption
Description Link
Command Reference
mpls traffic-eng passive-interface
26
Feature Information for MPLS Traffic Engineering: Inter-AS TE
Feature Information for MPLS Traffic Engineering: Inter-AS TE

support. Access Cisco Feature Navigator at http://www.cisco.com/go/cfn. You must have an account on
Cisco IOS software release. Unless noted otherwise, subsequent releases of that Cisco IOS software
release also support that feature.
Table 2 Feature Information for MPLS Traffic Engineering: Inter-AS TE

MPLS Traffic Engineering: Inter-AS TE 12.0(29)S The MPLS Traffic Engineering: Inter-AS TE feature
12.2(33)SRA provides ASBR node protection, loose path reoptimization,
12.2(33)SRB SSO recovery of LSPs that include loose hops, ASBR
12.2(33)SXH forced link flooding, Cisco IOS RSVP local policy
12.4(20)T extensions for Inter-AS, and per-neighbor key capabilities.
In 12.2(33)SRA, the nbr-if-addr keyword was added to the
mpls traffic-eng passive-interface command.
In 12.2(33)SRB, support was added for SSO recovery of
LSPs that include loose hops.
In 12.2(33)SXH, this feature was integrated into Cisco IOS
In 12.4(20)T, this feature was integrated into Cisco IOS
Release 12.4(20)T.
27
Glossary
Glossary
ABRArea Border Router. A routers connecting two areas.
adjacencyThe MPLS TE Forwarding Adjacency feature allows a network administrator to handle a
traffic engineering, label-switched path (LSP) tunnel as a link in an Interior Gateway Protocol (IGP)
network based on the Shortest Path First (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.
areaA logical set of network segments (for example, one that is OSPF-based) and their attached
devices. Areas usually are connected to other areas by routers, making up a single autonomous system.
OSPF and IS-IS define their areas differently. OSPF area borders are marked by routers. Some interfaces
are in one area, and other interfaces are in another area. With IS-IS, all the routers are completely within
an area, and the area borders are on links, not on routers. The routers that connect the areas are level-2
routers, and routers that have no direct connectivity to another area are level-1 routers.
ASBRAutonomous System Boundary Router. The router is located between an OSPF autonomous
system and a non-OSPF network. ASBRs run both OSPF and another routing protocol, such as RIP.
ASBRs must reside in a nonstub OSPF area.
routing strategy. Autonomous systems are subdivided by areas.
backup tunnelAn MPLS traffic engineering tunnel used to protect other (primary) tunnels traffic
when a link or node failure occurs.
BGPBorder Gateway Protocol. Interdomain routing protocol that replaces EGP. BGP exchanges
reachability information with other BGP systems.
border routerA router at the edge of a provider network that interfaces to another providers border
router using extended BGP procedures.
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.
floodingA traffic-passing technique used by switches and bridges in which traffic received on an
interface is sent out all the interfaces of that device except the interface on which the information was
received originally.
forwarding adjacencyA traffic engineering link (or LSP) into an IS-IS or OSPF network.
autonomous system. Examples of common IGPs include Interior Gateway Routing Protocol (IGRP),
Open Shortest Path First (OSPF), and Routing Information Protocol (RIP).
Inter-AS LSPAn MPLS traffic engineering label-switched path (LSP) that traverses hops that are not
in the headends topology database (that is, it is not in the same OSPF area, IS-IS area, or autonomous
system as the headend).
28
Glossary
IS-ISIntermediate System-to-Intermediate System. OSI link-state hierarchal routing protocol based

on DECnet Phase V routing, where intermediate system (IS) routers exchange routing information based
on a single metric to determine the network topology.
linkA point-to-point connection between adjacent nodes.
LSAlink-state advertisement. A broadcast packet used by link-state protocols that contains
information about neighbors and path costs. LSAs are used by the receiving routers to maintain their
routing tables.
LSPlabel-switched path. A configured connection between two routers, in which MPLS is used to
carry packets. An LSP is 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.
midpointA transit router for a given LSP.
midpoint reoptimizationAbility of a midpoint to trigger a headend reoptimization.
MPmerge point. The LSR where one or more backup tunnels rejoin the path of the protected LSP,
downstream of the potential failure. An LSR can be both an MP and a PLR simultaneously.
MPLSMultiprotocol 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.
multicastSingle packets are copied by the network and sent to a specific subset of network addresses.
These addresses are specified in the Destination address field. (Multicast is an efficient paradigm for
transmitting the same data to multiple receivers, because of its concept of a Group address. This allows
a group of receivers to listen to the single address.)
can be interconnected by links, and serve as control points in the network.
OSPFOpen 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.
opaque LSAIf a router understands LSA Type 10 link information, the router continues flooding the
link throughout the network.
passive linkWhen IGP is not running on the link between two ASBRs, traffic engineering informs the
IGP to flood link information on behalf of that link (that is, it advertises that link).
PLRpoint of local repair. The headend LSR of a backup tunnel.
RSVPResource 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.
SPFshortest 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.
SRLGShared Risk Link Group. Sets of links that are likely to go down together (for example, because
they have the same underlying fiber).
29
Glossary
used.
TLVtype, length, values. A block of information embedded in Cisco Discovery Protocol
advertisements.
coincidental.
30
MPLS Traffic Engineering: Shared Risk Link
Groups
First Published: May 6, 2004

The MPLS Traffic Engineering: Shared Risk Link Groups feature enhances backup tunnel path selection
so that a backup tunnel avoids using links that are in the same Shared Risk Link Group (SRLG) as
interfaces the backup tunnel is protecting.
SRLGs refer to situations where links in a network share a common fiber (or a common physical
attribute). If one link fails, other links in the group may fail too. Links in the group have a shared risk.
This document contains information about and instructions for configuring the MPLS Traffic
Engineering: Shared Risk Link Groups feature.

feature is supported, use the Feature Information for MPLS Traffic Engineering: Shared Risk Link Groups
section on page 20.
Contents
Prerequisites for MPLS Traffic Engineering: Shared Risk Link Groups, page 2
Restrictions for MPLS Traffic Engineering: Shared Risk Link Groups, page 2
Information About MPLS Traffic Engineering: Shared Risk Link Groups, page 2
How to Configure MPLS Traffic Engineering: Shared Risk Link Groups, page 7
MPLS Traffic Engineering: Shared Risk Link Groups
Prerequisites for MPLS Traffic Engineering: Shared Risk Link Groups
Configuration Examples for MPLS Traffic Engineering: Shared Risk Link Groups, page 15
Feature Information for MPLS Traffic Engineering: Shared Risk Link Groups, page 20
Glossary, page 22
Prerequisites for MPLS Traffic Engineering: Shared Risk Link

Groups
You must configure Fast Reroutable tunnels.
You must enable the autotunnel backup.
Restrictions for MPLS Traffic Engineering: Shared Risk Link

Groups
The backup tunnel must be within a single area.
Manually created backup tunnels do not automatically avoid SRLGs of protected interfaces.
A primary tunnel cannot be specified to avoid links belonging to specified SRLGS.
Information About MPLS Traffic Engineering: Shared Risk Link

Groups
To configure MPLS traffic engineering (MPLS TE) SRLGs, you need to understand the following
concepts:
MPLS Traffic Engineering Brief Overview, page 2
MPLS Traffic Engineering Shared Risk Link Groups, page 3
Fast Reroute Protection for MPLS TE SRLGs, page 4
Autotunnel Backup for MPLS TE SRLGs, page 5
MPLS Traffic Engineering Brief Overview

Multiprotocol Label Switching (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.
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.
2
Information About MPLS Traffic Engineering: Shared Risk Link Groups
MPLS Traffic Engineering Shared Risk Link Groups

SRLGs refer to situations where links in a network share a common fiber (or a common physical
attribute). If one link fails, other links in the group may fail too. Links in the group have a shared risk.
Backup tunnels should avoid using links in the same SRLG as interfaces they are protecting. Otherwise,
when the protected link fails the backup tunnel fails too.
Figure 1 shows a primary label-switched path (LSP) from router R1 to router R5. The LSP protects
against the failure of the R2-R3 link at R2 via a backup tunnel to R4. If the R2-R3 link fails, link
protection reroutes the LSP along the backup tunnel. However, the R2-R3 link and one of the backup
tunnel links are in the same SRLG. So if the R2-R3 link fails, the backup tunnel may fail too.
Figure 1 Backup Tunnel in the Same SRLG as the Interface It Is Protecting
Backup tunnel
117165
R1 LSP R2 R3 R4 R5
The MPLS TE SRLG feature enhances backup tunnel path selection so a backup tunnel can avoid using
links that are in the same SRLG as the interfaces it is protecting.
There are two ways for a backup tunnel to avoid the SRLGs of its protected interface:
The router does not create the backup tunnel unless it avoids SRLGs of the protected interface.
The router tries to avoid SRLGs of the protected interface, but if that is not possible the router
creates the backup tunnel anyway. In this case there are two explicit paths. The first explicit path
tries to avoid the SRLGs of the protected interface. If that does not work, the backup tunnel uses the
second path (which ignores SRLGs).
Note Only backup tunnels that routers create automatically (called autotunnel backup) can avoid SRLGs of
protected interfaces. For more information about these backup tunnels, see the Autotunnel Backup for
MPLS TE SRLGs section on page 5.
To activate the MPLS TE SRLG feature, you must do the following:

Configure the SRLG membership of each link that has a shared risk with another link.
Configure the routers to automatically create backup tunnels that avoid SRLGs of the protected
interfaces.
For a detailed explanation of the configuration steps, see the How to Configure MPLS Traffic
Engineering: Shared Risk Link Groups section on page 7.
3
Open Shortest Path First (OSPF) and Intermediate System-to-Intermediate System (IS-IS) flood the
SRLG membership information (including other TE link attributes such as bandwidth availability and
affinity) so that all routers in the network have the SRLG information for each link. With this topology
information, routers can compute backup tunnel paths that exclude links having SRLGs in common with
their protected interfaces. As shown in Figure 2, the backup tunnel avoids the link between R2 and R3,
which shares an SRLG with the protected interface.
Figure 2 Backup Tunnel That Avoids SRLG of Protected Interface
R1 LSP R2 R3 R4 R5
117168
Backup tunnel
Fast Reroute Protection for MPLS TE SRLGs

Fast Reroute (FRR) protects MPLS TE LSPs from link and node failures by locally repairing the LSPs
at the point of failure. This protection allows data to continue to flow on LSPs 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.
LSPs if a link along their path fails by rerouting the LSPs traffic to the next hop (bypassing the
failed link). These are referred to as next-hop (NHOP) backup tunnels because they terminate at the
LSPs next hop beyond the point of failure. Figure 3 illustrates an NHOP backup tunnel.
4
Figure 3 NHOP Backup Tunnel
10.1.1.1
R1 LSP R2 R3 R4 R5
117171
NHOP backup tunnel
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 Resource Reservation Protocol (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 4 NNHOP Backup Tunnel
NNHOP backup tunnel
192.168.1.1
10.1.1.1
R1 LSP R2 R3 R4 R5
117172
NHOP backup tunnel
Autotunnel Backup for MPLS TE SRLGs

Autotunnel backup is the ability of routers to create backup tunnels automatically. Therefore, you do not
need to preconfigure each backup tunnel and then assign the backup tunnel to the protected interface.
Only automatically created backup tunnels can avoid SRLGs or their protected interfaces.
5
For information about backup tunnels, see the Fast Reroute Protection for MPLS TE SRLGs section
on page 4.
For detailed information about autotunnel backup and how you can change the default command values,
see MPLS Traffic Engineering (TE)--AutoTunnel Primary and Backup.
To globally activate the autotunnel backup feature, enter the mpls traffic-eng auto-tunnel backup
command.
Figure 5 illustrates an NNHOP automatically generated backup tunnel that excludes the router
192.168.1.1 and terminates at router R4. The backup tunnel must avoid touching any links of
192.168.1.1.
Figure 5 Autotunnel Backup for NNHOP
192.168.1.1
R1 LSP R2 R3 R4 R5
117169
Backup tunnel
Figure 6 illustrates an NHOP automatically generated backup tunnel that terminates at router R3 and
avoids the link 10.1.1.1, not the entire node.
Figure 6 Autotunnel Backup for NHOP
10.1.1.1
R1 LSP R2 R3 R4 R5
117171
NHOP backup tunnel
6
How to Configure MPLS Traffic Engineering: Shared Risk Link Groups
Note NNHOP excludes the router ID (the entire router must be excluded; that is, no link of the router can be
included in the backup tunnels path). NHOP excludes only the link when the backup tunnels path is
computed.
How to Configure MPLS Traffic Engineering: Shared Risk Link

Groups
This section contains the following procedures for configuring the MPLS Traffic Engineering: Shared
Risk Link Groups feature:
Configuring MPLS TE SRLG Membership of Each Link That Has a Shared Risk with Another Link,
page 7 (required)
Configuring the Routers That Automatically Create Backup Tunnels to Avoid MPLS TE SRLGs of
Their Protected Interfaces, page 8 (required)
Verifying the MPLS Traffic Engineering: Shared Risk Link Groups Configuration, page 9 (optional)
Configuring MPLS TE SRLG Membership of Each Link That Has a Shared Risk
with Another Link
Perform the following task to configure MPLS TE SRLG membership of each link that has a shared risk
with another link. Configuring SRLG membership enhances backup tunnel path selection so that a
backup tunnel avoids using links that are in the same SRLG as interfaces the backup tunnel is protecting.
Enter the commands on the physical interface.
SUMMARY STEPS
1. enable
4. mpls traffic-eng srlg [number]
5. end
DETAILED STEPS

Example:
Router> enable
Example:
7

Step 3 interface type slot/port Specifies an interface and enters interface configuration
mode.
Example: The type argument is the type of interface to be
Router(config)# interface pos 1/1 configured.
The slot argument is the slot number. Refer to the
appropriate hardware manual for slot and port
information.
The /port argument is the port number. Refer to the
information. The slash (/) is required.
Step 4 mpls traffic-eng srlg [number] Configures the SRLG membership of a link (interface).
The number argument is an SRLG identifier. Valid
Example: values are 0 to 4,294,967,295.
Router(config-if)# mpls traffic-eng srlg 5
Note To make the link a member of multiple SRLGs,
enter the mpls traffic-eng srlg command multiple
times.
Example:
Configuring the Routers That Automatically Create Backup Tunnels to Avoid

MPLS TE SRLGs of Their Protected Interfaces
Perform the following task to configure routers that automatically create backup tunnels to avoid
MPLS TE SRLGs of their protected interfaces. Backup tunnels provide link protection by rerouting
traffic to the next hop bypassing failed links or in this instance by avoiding SRLGs.
SUMMARY STEPS
1. enable
3. mpls traffic-eng auto-tunnel backup srlg exclude [force | preferred]
4. end
8
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng auto-tunnel backup srlg Specifies that autocreated backup tunnels should avoid
exclude [force | preferred] SRLGs of its protected interface.
The force keyword forces the backup tunnel to avoid
Example: SRLGs of its protected interface or interfaces.
backup srlg exclude force The preferred keyword causes the backup tunnel to try
to avoid SRLGs of its protected interface or interfaces,
but the backup tunnel can be created if SRLGs cannot
be avoided.
Example:
Router(config)# end
Verifying the MPLS Traffic Engineering: Shared Risk Link Groups Configuration
Perform the following task to verify the MPLS traffic engineering SRLG configurations.
SUMMARY STEPS
1. enable
3. show mpls traffic-eng link-management interfaces interface slot/port
4. show mpls traffic-eng topology
5. show mpls traffic-eng topology srlg
6. show mpls traffic-eng topology brief
7. show mpls traffic-eng link-management advertisements
8. show ip rsvp fast-reroute
9. mpls traffic-eng auto-tunnel backup srlg exclude force
10. show ip explicit-paths
11. show mpls traffic-eng tunnels tunnel num
12. mpls traffic-eng auto-tunnel backup srlg exclude preferred
13. show ip explicit-paths
9
14. show ip rsvp fast-reroute

15. 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 running config

Use the following commands to configure the SRLG membership of the interface pos 3/1 and to verify
that the configuration is as expected. For example:
Router(config)# interface pos 3/1
interface POS 3/1

ip address 10.0.0.33 255.255.255.255
ip router isis
encapsulation ppp
no ip mroute-cache
mpls traffic-eng srlg 1
mpls traffic-eng srlg 2
tag-switching ip
crc 32
clock source internal
pos ais-shut
pos report rdool
pos report lais
pos report lrdi
pos report pais
pos report prdi
pos report sd-ber
isis circuit-type level-2-only
ip rsvp bandwidth 20000 20000 sub-pool 5000
This verifies that the Packet over SONET (POS) interface pos 3/1 is associated that SRLG 1 and SRLG 2.
Step 3 show mpls traffic-eng link-management interfaces interface slot/port
Use this command to show the SRLG membership configured on interface pos 3/1. For example:
Router# show mpls traffic-eng link-management interfaces pos 3/1
Links Count: 11
Link ID:: PO3/1 (10.0.0.33)
Link Status:
SRLGs: 1 2
Max Res Global BW: 20000 kbits/sec (reserved:0% in, 0% out)
10
Max Res Sub BW: 5000 kbits/sec (reserved:0% in, 0% out)

MPLS TE Link State: MPLS TE on, RSVP on, admin-up, flooded
Inbound Admission: allow-all
Outbound Admission: allow-if-room
Admin. Weight: 10 (IGP)
IGP Neighbor Count: 1
IGP Neighbor: ID 0000.0000.0004.00, IP 10.0.0.34 (Up)
Flooding Status for each configured area [1]:
IGP Area[1]: isis level-2: flooded
Step 4 show mpls traffic-eng topology

Use this command to show the SRLG link membership flooded via the Interior Gateway Protocol (IGP).
For example:
Router# show mpls traffic-eng topology
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
SRLGs:1 2
physical_bw:2488000 (kbps), max_reservable_bw_global:20000
(kbps)
max_reservable_bw_sub:5000 (kbps)

--------------- ----------- ----------
bw[0]: 0 20000 5000
bw[1]: 0 20000 5000
bw[2]: 0 20000 5000
bw[3]: 0 20000 5000
bw[4]: 0 20000 5000
bw[5]: 0 20000 5000
Step 5 show mpls traffic-eng topology srlg

Use this command to display all the links in the network that are members of a given SRLG. For
example:
Router# show mpls traffic-eng topology srlg
MPLS TE Id:0000.0000.0003.00 (isis level-2)

SRLG:1
10.0.0.33
SRLG:2
10.0.0.33
The following command shows that there are two links in SRLG 1:
Router# show mpls traffic-eng topology srlg
MPLS TE Id:0000.0000.0003.00 (isis level-2)

SRLG:1
10.0.0.33
10.0.0.49
11
Step 6 show mpls traffic-eng topology brief

Use this command to display brief topology information:
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
SRLGs:1 2
Step 7 show mpls traffic-eng link-management advertisements

Use this command to show local link information that MPLS TE link management is currently flooding
into the global TE topology. For example:
Router# show mpls traffic-eng link-management advertisements
Flooding Status: ready

Configured Areas: 1
IGP Area[1] ID:: isis level-2
Flooding Protocol: ISIS
IGP System ID: 0000.0000.0003.00
Flooded Links: 2
Link ID:: 0
IGP Neighbor: ID 0000.0000.0007.00, IP 10.0.0.50
TE metric: 80000
IGP metric: 80000
SRLGs: None
Downstream::
----------- --------------
Link ID:: 1
IGP Neighbor: ID 0000.0000.0004.00, IP 10.0.0.34
TE metric: 10
IGP metric: 10
SRLGs: 1
12

Downstream::
----------- --------------
Step 8 show ip rsvp fast-reroute

Use this command to show that the primary tunnel is going over Pos3/1 on R3, on which SLRG 1 is
configured. For example:

------- ------- -------- ------------ ----- ----- ----
R3-PRP_t0 PO3/1 0:G None None None None None
Step 9 mpls traffic-eng auto-tunnel backup srlg exclude force

Use the following commands to configure autotunnel backup with the force keyword. For example:
Router(config)# mpls traffic-eng auto-tunnel backup srlg exclude force
Step 10 show ip explicit-paths

Use the following command to verify that the force keyword is configured with the pos3/1 link excluded
from the IP explicit path. For example:
Router# show ip explicit-paths
PATH __dynamic_tunnel65436 (loose source route, path complete,

generation 24, status non-configured)
1:exclude-address 10.0.0.33
2:exclude-srlg 10.0.0.33
Step 11 show mpls traffic-eng tunnels tunnel num

Use the following command to show that autotunnel backup is configured but is down because the
headend router does not have any other path to signal and it cannot use pos2/1 because it belongs in the
same SRLG; that is, SRLG 1. For example:
Router# show mpls traffic-eng tunnels tunnel 65436
Name:R3-PRP_t65436 (Tunnel65436) Destination:

10.0.4.1
Status:
Admin:up Oper:down Path:not valid Signalling:Down
path option 1, type explicit __dynamic_tunnel65436
Config Parameters:
Bandwidth:0 kbps (Global) Priority:7 7 Affinity:
0x0/0xFFFF
Metric Type:TE (default)
13
AutoRoute: disabled LockDown:disabled Loadshare:0

bw-based
auto-bw:disabled

Path Weight:10 (TE)
Explicit Route:10.0.0.34 10.0.4.1
History:
Tunnel:
Time since created:5 minutes, 29 seconds
Path Option 1:
Last Error:PCALC::No path to destination, 0000.0000.0004.00
Step 12 mpls traffic-eng auto-tunnel backup srlg exclude preferred

The following commands configure autotunnel backup with the preferred keyword. For example:
Router(config)# mpls traffic-eng auto-tunnel backup srlg exclude preferred
Step 13 show ip explicit-paths

The following command shows two explicit paths. The first path avoids the SRLGs of the protected
interface. The second path does not avoid the SRLGs. For example:
Router# show ip explicit-paths
PATH __dynamic_tunnel65436 (loose source route, path complete,

2:exclude-srlg 10.0.0.33
PATH __dynamic_tunnel65436_pathopt2 (loose source route, path complete,
Step 14 show ip rsvp fast-reroute

The following command shows that the primary tunnel is protected with autotunnel backup using the
second path option (see Step 10) that does not avoid the SRLGs. For example:

------- ------- -------- ------------ ----- ----- ----
R3-PRP_t0 PO3/1 0:G 0:G Tu65436:0 Ready any-unl nhop
The following command shows the path options for the tunnel Tu65436:
Name:R3-PRP_t65436 (Tunnel65436) Destination:

10.0.4.1
Status:
Admin:up Oper:up Path:valid Signalling:connected
path option 2, type explicit __dynamic_tunnel65436_pathopt2 (Basis

for Setup, path weight 80020)
path option 1, type explicit __dynamic_tunnel65436
Config Parameters:
Bandwidth:0 kbps (Global) Priority:7 7 Affinity:
0x0/0xFFFF
Metric Type:TE (default)
14
Configuration Examples for MPLS Traffic Engineering: Shared Risk Link Groups
AutoRoute: disabled LockDown:disabled Loadshare:0

bw-based
auto-bw:disabled
State:explicit path option 2 is active
BandwidthOverride:disabled LockDown:disabled Verbatim:disabled
InLabel : -
OutLabel :POS2/1, 23
RSVP Path Info:
My Address:10.0.3.1
Explicit Route:10.0.0.50 10.0.0.66 10.0.0.113 10.0.4.1
Record Route: NONE
Tspec:ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
RSVP Resv Info:
Record Route: NONE
Fspec:ave rate=0 kbits, burst=1000 bytes, peak rate=0 kbits
Path Weight:10 (TE)
Explicit Route:10.0.0.34 10.0.4.1
Step 15 exit
Router# exit
Router>
Configuration Examples for MPLS Traffic Engineering: Shared

Risk Link Groups
Configuring the SRLG Membership of Each Link That Has a Shared Risk with Another Link:
Example, page 15
Configuring the Routers That Automatically Create Backup Tunnels to Avoid SRLGs of Their
Protected Interfaces: Example, page 16
Configuring the SRLG Membership of Each Link That Has a Shared Risk with
Another Link: Example
The following example shows how to specify that the SRLG membership of each link has a shared risk
with another link.
As shown in Figure 7 and in the following commands:
link R2-R3 = SRLG5
link R2-R3 = SRLG6
link R7-R4 = SRLG5
link R1-R2 = SRLG6
15
Router1# configure terminal

Router1# interface pos 1/0
Router1(config-if)# mpls traffic-eng srlg 6


Figure 7 SRLG Membership
R6 R7
pos 3/0
5
pos 1/0 pos 1/1
117167
6 56
R1 R2 R3 R4 R5
Configuring the Routers That Automatically Create Backup Tunnels to Avoid

SRLGs of Their Protected Interfaces: Example
The following example shows how to specify that automatically created backup tunnels are forced to
avoid SRLGs of their protected interfaces:
Router(config)# mpls traffic-eng auto-tunnel backup srlg exclude force
Figure 8 illustrates the automatically created NNHOP backup tunnel that would be created to avoid
SRLGs of the protected interface if the following conditions exist:
The exclude address is 192.168.1.1.
The link at R2 has an IP address of 10.1.1.1.
The backup tunnels explicit path avoids links that have a membership in the same SRLG as the link
whose IP address is 10.1.1.1.
16
Figure 8 srlg exclude forceNNHOP Autobackup Tunnel
NNHOP backup tunnel
192.168.1.1
10.1.1.1
R1 LSP R2 R3 R4 R5
117170
Figure 9 illustrates the automatically created NHOP backup tunnel that would be created.
Figure 9 srlg exclude forceNHOP Autobackup Tunnel
10.1.1.1
R1 LSP R2 R3 R4 R5
117171
NHOP backup tunnel
17
The following sections provide references related to the MPLS Traffic Engineering: Shared Risk Link
Groups feature.
Related Documents
Fast Reroute MPLS TE: Link and Node Protection, with RSVP Hellos Support
IS-IS Integrated IS-IS Routing Protocol Overview
OSPF Configuring OSPF
Autotunnel backups MPLS Traffic Engineering AutoTunnel Primary and Backup
Standards
Standard Title
None
MIBs
MIB MIBs Link
following URL:
RFCs
RFC Title
draft-ietf-isis-gmpls-extensions-16.txt IS-IS Extensions in Support of Generalized MPLS
18
Command Reference
Description Link
Command Reference
mpls traffic-eng auto-tunnel backup srlg exclude
mpls traffic-eng srlg
show ip explicit-paths
show mpls traffic-eng link-management advertisements
show mpls traffic-eng link-management interfaces
show mpls traffic-eng topology
19
Feature Information for MPLS Traffic Engineering: Shared Risk Link Groups
Feature Information for MPLS Traffic Engineering: Shared Risk

Link Groups
Table 1 Feature Information for MPLS Traffic Engineering: Shared Risk Link Groups

MPLS Traffic Engineering: Shared Risk Link 12.0(28)S The MPLS Traffic Engineering: Shared Risk Link Groups
Groups 12.0(29)S feature enhances backup tunnel path selection so that a
12.2(33)SRA backup tunnel avoids using links that are in the same Shared
12.2(33)SXH Risk Link Group (SRLG) as interfaces the backup tunnel is
12.4(20)T protecting.
SRLGs refer to situations where links in a network share a
common fiber (or a common physical attribute). If one link
fails, other links in the group may fail too. Links in the
group have a shared risk.
This document contains information about and instructions
for configuring the MPLS Traffic Engineering: Shared Risk
Link Groups feature
In 12.0(29)S, support was added for Open Shortest Path
First (OSPF).
In 12.2(33)SRA, this feature was integrated into a
Cisco IOS 12.2SRA release
In 12.2(33)SXH, this feature was integrated into a
Cisco IOS 12.2SXH release.
12.4T release.
feature:
MPLS Traffic Engineering Brief Overview, page 2
20
Feature Information for MPLS Traffic Engineering: Shared Risk Link Groups
Table 1 Feature Information for MPLS Traffic Engineering: Shared Risk Link Groups (continued)

MPLS Traffic Engineering Shared Risk Link Groups,
page 3
Fast Reroute Protection for MPLS TE SRLGs, page 4
Autotunnel Backup for MPLS TE SRLGs, page 5
Configuring MPLS TE SRLG Membership of Each
Link That Has a Shared Risk with Another Link, page 7
Configuring the Routers That Automatically Create
Backup Tunnels to Avoid MPLS TE SRLGs of Their
Protected Interfaces, page 8
Verifying the MPLS Traffic Engineering: Shared Risk
Link Groups Configuration, page 9
mpls traffic-eng auto-tunnel backup srlg exclude, mpls
traffic-eng srlg, show ip explicit-paths, show mpls
traffic-eng link-management advertisements, show mpls
traffic-eng link-management interfaces, and show mpls
traffic-eng topology.
21
Glossary
Glossary
failure by locally repairing the LSPs at the point of failure. This protection allows 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.
IGPInterior Gateway Protocol. An Internet protocol used to exchange routing information within an
autonomous system.
IP addressA 32-bit address assigned to hosts using TCP/IP. An IP address belongs to one of five
classes (A, B, C, D, or E) and is written as four octets separated by periods (dotted decimal format). Each
address consists of a network number, an optional subnetwork number, and a host number. The network
and subnetwork numbers together are used for routing, and the host number is used to address an
individual host within the network or subnetwork. A subnet mask is used to extract network and
subnetwork information from the IP address.
IS-ISIntermediate System-to-Intermediate System. OSI link-state hierarchal routing protocol based
on DECnet Phase V routing, where intermediate system (IS) routers exchange routing information based
on a single metric to determine the network topology.
linkA point-to-point connection between adjacent nodes.
LSPlabel-switched path. A path that is followed by a labeled packet over several hops, starting at an
LSRlabel switching router. A Layer 3 router that forwards a packet based on the value of a label
nodeAn 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.
OSPFOpen Shortest Path First. A link-state hierarchical Interior Gateway Protocol (IGP) routing
algorithm, derived from the IS-IS protocol. OSPF features include least-cost routing, multipath routing,
and load balancing.
other routers; for example, an IP address from one of the routers interfaces.
used.
22
Glossary
coincidental.
23
Glossary
24
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.
Note Cisco IOS Release 12.3(33)SRE and later releases support enhanced path protection, which is the ability
to configure up to eight secondary path options for a given primary path option.

supported, see the Feature Information for MPLS Traffic Engineering (TE): Path Protection section on
page 31.
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): Regular Path Protection, page 17
Prerequisites for MPLS Traffic Engineering (TE): Path Protection
Configuration Examples for MPLS Traffic Engineering (TE): Enhanced Path Protection, page 23
Feature Information for MPLS Traffic Engineering (TE): Path Protection, page 31
Glossary, page 32
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 stateful switchover (SSO), configure Resource Reservation Protocol (RSVP)
Graceful Restart in full mode on the routers.
If your router supports SSO, for Cisco nonstop forwarding (NSF) operation you must have
configured SSO on the device.
Restrictions for MPLS Traffic Engineering (TE): Path Protection

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 3
Path Protection, page 3
Enhanced Path Protection, page 3
ISSU, page 4
NSF/SSO, page 4
2
Information About MPLS Traffic Engineering (TE): Path Protection
Traffic Engineering Tunnels

MPLS TE lets you build label switched paths (LSPs) across your network for forwarding traffic.
MPLS TE LSPs 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.
Interarea tunnels allow you to do the following:
Build TE tunnels between areas (interarea tunnels)
Build TE tunnels that start and end in the same area, on multiple areas on a router (intra-area tunnels)
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.
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 tunnels TE traffic. When there is a failure on the protected LSP, the
headend router immediately enables the secondary LSP to temporarily carry the tunnels 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), interarea
(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 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 tunnels 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 tunnels 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.
Enhanced Path Protection

Enhanced path protection provides support of multiple backup path options per primary path option. You
can configure up to eight backup path options for a given primary path option. Only one of the configured
backup path options is actively signaled at any time.
3
How to Configure MPLS Traffic Engineering (TE): Path Protection
After you enter the mpls traffic-eng path-option list command, you can enter the backup path priority
in the number argument of the path-option command. A lower identifier represents a higher priority.
Priorities are configurable for each backup path option. Multiple backup path options and a single
backup path option cannot coexist to protect a primary path option.
ISSU
Cisco In Service Software Upgrade (ISSU) allows you to perform a Cisco IOS software upgrade or
downgrade while the system continues to forward packets. ISSU takes advantage of the Cisco IOS high
availability infrastructureCisco nonstop forwarding (NSF) with stateful switchover (SSO) and
hardware redundancyand eliminates downtime associated with software upgrades or version changes
by allowing changes while the system remains in service. Cisco ISSU 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 that of 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.
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 configuration procedures:
Regular Path Protection Configuration Tasks, page 5
4
Enhanced Path Protection Configuration Tasks, page 10

In enhanced path protection you create and assign a path option list.
Regular Path Protection Configuration Tasks

This section contains the following tasks which are shown in Figure 1.
Configuring Explicit Paths for Secondary Paths, page 5 (required)
Assigning a Secondary Path Option to Protect a Primary Path Option, page 6 (required)
Verifying the Configuration of MPLS Traffic Engineering Regular Path Protection, page 7
(optional)
Figure 1 Network TopologyPath Protection
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
3. ip explicit-path {name path-name | identifier number} [enable | disable]
4. index index command ip-address
5. exit
5
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 configuration 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 configuration mode and enters global
configuration mode.
Example:
Router(cfg-ip-exp1-path)# exit
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
4. tunnel mpls traffic-eng path-option protect number [attributes lsp-attributes | bandwidth {kbps
| subpool kbps} | explicit {identifier path-number | name path-name} | list {name pathlist-name |
identifier pathlist-identifier}]
6
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 [attributes lsp-attributes | bandwidth
{kbps | subpool kbps} | explicit {identifier
path-number | name path-name} | list {name
pathlist-name | identifier
pathlist-identifier}]
Example:
path-option protect 10 explicit name path344
Verifying the Configuration of MPLS Traffic Engineering Regular Path Protection

To verify the configuration of regular path protection, perform the following steps. In Steps 1 and 2, refer
to Figure 2.
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
7
SUMMARY STEPS
1. show running interface tunneltunnel-number

2. show mpls traffic-eng tunnels tunnel tunnel-interface
3. show mpls traffic-eng tunnels tunnel number [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 tunneltunnel-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
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:
8
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
auto-bw: disabled
InLabel : -
OutLabel : Ethernet1/0, 16
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.2.0.1 10.2.0.2 10.10.0.1 10.10.0.2 10.0.0.9
History:
Tunnel:
Current LSP:
Step 3 show mpls traffic-eng tunnels tunnel number [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).
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
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
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
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 [fixed | variable] |
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
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
Enhanced Path Protection Configuration Tasks

This section contains the following tasks which are shown in Figure 3.
Creating a Path Option List, page 11 (required)
10
Assigning a Path Option List to Protect a Primary Path Option, page 12 (required)
Verifying the Configuration of MPLS TE Enhanced Path Protection, page 13 (optional)
Figure 3 Network Topology - Enhanced Path Protection in Cisco IOS Release 12.2(33)SRE
Creating a Path Option List

In Cisco IOS Release 12.2(33)SRE, perform the following task to create a path option list of backup
paths for a primary path option.
Note To use a secondary path instead, perform the steps in the Configuring Explicit Paths for Secondary
Paths section on page 5.
SUMMARY STEPS
1. enable
3. mpls traffic-eng path-option list [name pathlist-name | identifier pathlist-number]
4. path-option number explicit [name pathoption-name | identifier pathoption-number]
5. list
6. no [pathoption-name | pathoption-number]
7. exit
11
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls traffic-eng path-option list [name Configures a path option list, and enters path-option list
pathlist-name | identifier pathlist-number] configuration mode.
You can enter the following commands: path-option,
Example: list, no, and exit.
Router(config)# mpls traffic-eng path-option
list name pathlist-01
Step 4 path-option number explicit [name (Optional) Specifies the name or identification number of
pathoption-name | identifier pathoption-number] the path option to add, edit, or delete. The
pathoption-number value can be from 1 through 65535.
Example:
Router(cfg-pathoption-list)# path-option 10
explicit identifier 200
Step 5 list (Optional) Lists all of the path options.
Example:
Router(cfg-pathoption-list)# list
Step 6 no [pathoption-name | pathoption-number] (Optional) Deletes a specified path option.
Example:
Router(cfg-pathoption-list)# no 10
Step 7 exit (Optional) Exits path-option list configuration mode and
enters global configuration mode.
Example:
Router(cfg-pathoption-list)# exit
Assigning a Path Option List to Protect a Primary Path Option

Assign a path option list in case there is a link or node failure along a path and all interfaces in your
network are not protected. See Figure 3.
SUMMARY STEPS
1. enable
12
4. tunnel mpls traffic-eng path-option protect number [attributes lsp-attributes | bandwidth {kbps
| subpool kbps} | explicit {identifier path-number | name path-name} | list {name pathlist-name |
identifier pathlist-identifier}]
5. exit
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Step 4 tunnel mpls traffic-eng path-option protect Configures a path option list to protect primary path option
number [attributes lsp-attributes | bandwidth 10.
{kbps | subpool kbps} | explicit {identifier
path-number | name path-name} | list {name
pathlist-name | identifier
pathlist-identifier}]
Example:
path-option protect 10 list name pathlist-01
Step 5 exit (Optional) Exits interface configuration mode and enters
global configuration mode.
Example:
Verifying the Configuration of MPLS TE Enhanced Path Protection

To verify the configuration of MPLS TE enhanced path protection, refer to Figure 4 and perform the
following steps.
13
Figure 4 Network Topology Verification for Enhanced Path Protection
R4
10.2.0.2 10.10.0.1
10.2.0.1 10.10.0.2
10.1.0.1 10.1.0.2
R1 R3
10.0.0.1 10.0.1.2
10.0.0.2 10.0.1.1
R2
193993
Primary path
Secondary path
SUMMARY STEPS
1. show running interface tunneltunnel-number

2. show mpls traffic-eng tunnels tunnel-number
3. show mpls traffic-eng tunnels tunnel number [brief] [protection]
4. show ip rsvp high-availability database {hello | link-management {interfaces [fixed | variable]
| system} | lsp [filter destination ip-address | filter lsp-id lsp-id | filter source ip-address | filter
DETAILED STEPS
Step 1 show running interface tunneltunnel-number

This command shows the configuration of the path option and backup path option.
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.
Building configuration..

!
interface Tunnel2
tunnel mpls traffic-eng path-option 10 explicit name primary1
14
tunnel mpls traffic-eng path-option protect 10 list name pathlist-01

end
Step 2 show mpls traffic-eng tunnels tunnel number

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: iou-100_t2 (Tunnel2) Destination: 10.10.0.2

Status:
path option 10, type explicit primary1 (Basis for Setup, path weight 10)
path protect option 10, type list name secondary-list
Inuse path-option 10, type explicit secondary1 (Basis for Protect, path weight 20)
Config Parameters:
AutoRoute announce: enabled LockDown: disabled Loadshare: 0 bw-based
auto-bw: disabled
InLabel : -
OutLabel : Ethernet7/0, implicit-null
RSVP Path Info:
Explicit Route: 10.1.0.2 10.10.0.2
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Explicit Route: 10.1.0.1 10.1.0.2 10.10.0.2
History:
Tunnel:
Time since created: 1 hours, 34 minutes
Current LSP:
Prior LSP:
Removal Trigger: label reservation removed
Step 3 show mpls traffic-eng tunnels tunnel number [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).
15
The following command output shows that the primary LSP is up, and the secondary LSP is up and
providing protection:
iou-100_t2
10.10.0.2
10.0.1.1 10.0.1.2
10.10.0.2
InLabel : -
RSVP Path Info:
Explicit Route: 10.0.0.2 10.0.1.1 10.0.1.2 10.10.0.2
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
Step 4 show ip rsvp high-availability database {hello | link-management {interfaces [fixed | variable}] |
system} | lsp [filter destination ip-address | filter lsp-id lsp-id | filter source ip-address | filter
The show ip rsvp high-availability database command displays the contents of the RSVP HA read and
write databases used in TE. If you specify the lsp-head keyword, the command output includes path
protection information.
LSP_HEAD WRITE DB
Tun ID: 2
Header:
State: Checkpointed Action: Add
Seq #: 2 Flags: 0x0
Data:
feature flags: none
RRR path setup info
Destination: 10.10.0.2, Id: .10.10.0.2 Router Node (ospf) flag:0x0
16
Configuration Examples for MPLS Traffic Engineering (TE): Regular Path Protection

Configuration Examples for MPLS Traffic Engineering (TE):

Regular Path Protection
This section provides the following configuration examples for MPLS TE regular path protection:
Creating a Path Option List: Example, page 23
Assigning a Path Option List to Protect a Primary Path Option: Example, page 24
Configuring Tunnels Before and After Path Protection: Example, page 24
Configuring Explicit Paths for Secondary Paths: Example

Figure 5 illustrates a primary path and a secondary path. If there is a failure, the secondary path is used.
Figure 5 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
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

17


Router(cfg-ip-expl-path)# exit
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# interface tunnel 500

!
interface Tunnel500
end
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.
18

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
Prior LSP:
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
10.10.0.1 10.10.0.2
10.0.0.9
10.0.1.1 10.0.1.2
10.0.0.9
19

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 e1/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:
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
20
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:
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 ethernet1/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:
auto-bw: disabled
InLabel : -
21

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
Prior LSP:
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:
Record Route: NONE
R1#
22
Configuration Examples for MPLS Traffic Engineering (TE): Enhanced Path Protection
Configuration Examples for MPLS Traffic Engineering (TE):

Enhanced Path Protection
This section provides the following configuration examples for MPLS TE path protection:
Creating a Path Option List: Example, page 23
Assigning a Path Option List to Protect a Primary Path Option: Example, page 24
Configuring Tunnels Before and After Path Protection: Example, page 24
Creating a Path Option List: Example

Figure 6 shows the network topology for enhanced path protection.
Figure 6 Network Topology for Enhanced Path Protection
R4
10.2.0.2 10.10.0.1
10.2.0.1 10.10.0.2
10.1.0.1 10.1.0.2
R1 R3
10.0.0.1 10.0.1.2
10.0.0.2 10.0.1.1
R2
193993
Primary path
Secondary path
The following example configures two explicit paths named secondary1 and secondary2.
Router(config)# ip explicit-path name secondary1
Explicit Path name secondary1:

Router(cfg-ip-expl-path)# ip explicit-path name secondary2

23

Router(cfg-ip-expl-path)# exit
In the following example a path option list of backup paths is created. You define the path option list by
using the explicit paths.
Router(config)# mpls traffic-eng path-option list name pathlist-01
Router(cfg-pathoption-list)# path-option 10 explicit name secondary1
path-option 10 explicit name secondary1
Router(cfg-pathoption-list)# path-option 20 explicit name secondary2

Router(cfg-pathoption-list)# exit
Assigning a Path Option List to Protect a Primary Path Option: Example

In the following example, a traffic engineering tunnel is configured:
Router(config-if)# tunnel mpls traffic-eng path-option protect 10 list name secondary-list
The following show running interface command output shows that path protection has been configured.
Tunnel 2 has path option 10 using path primary1 and protected by secondary-list.
Router# show running-config interface tunnel 2

!
interface Tunnel2
tunnel mpls traffic-eng path-option 10 explicit name primary1
tunnel mpls traffic-eng path-option protect 10 list name secondary-list
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:
24
Config Parameters:
auto-bw: disabled
InLabel : -
RSVP Path Info:
Explicit Route: 10.1.0.2 103.103.103.103
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Explicit Route: 10.1.0.1 10.1.0.2 103.103.103.103
History:
Tunnel:
Current LSP:
The following show mpls traffic-eng tunnels command output shows information about the secondary
path. Tunnel 2 is protected.
Router# show mpls traffic-eng tunnels tunnel 2 protection
Router_t2
103.103.103.103
10.0.1.1 10.0.1.2
103.103.103.103
InLabel : -
RSVP Path Info:
Explicit Route: 10.0.0.2 10.0.1.1 10.0.1.2 103.103.103.103
Record Route: NONE
25
RSVP Resv Info:

Record Route: NONE
The following shutdown command shuts down the interface to use path protection:
Router(config)# interface e7/0
The following show mpls traffic-eng tunnels command shows that the protection path is used, and the
primary path is down:

Status:
path option 10, type explicit primary1
Config Parameters:
auto-bw: disabled
State: list path option 10 is active
InLabel : -
RSVP Path Info:
Explicit Route: 10.0.0.2 10.0.1.1 10.0.1.2 103.103.103.103
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 103.103.103.103
History:
Tunnel:
Current LSP:
Selection:
Prior LSP:
26
Removal Trigger: path error

Last Error: PCALC:: No addresses to connect 100.100.100.100 to 10.1.0.2
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.
Router_t2
The no shutdown command in the following command sequence causes the interface to be up again and
activates the primary path:

Router(config-if)# interface ethernet7/0
The following command output shows that path protection has been reestablished and the primary path
is being used:

Status:
Config Parameters:
auto-bw: disabled
InLabel : -
RSVP Path Info:
Explicit Route: 10.1.0.2 103.103.103.103
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
Explicit Route: 10.1.0.1 10.1.0.2 103.103.103.103
History:
Tunnel:
27

Current LSP:
Prior LSP:
Router_t2
103.103.103.103
10.0.1.1 10.0.1.2
103.103.103.103
InLabel : -
RSVP Path Info:
Explicit Route: 10.0.0.2 10.0.1.1 10.0.1.2 103.103.103.103
Record Route: NONE
RSVP Resv Info:
Record Route: NONE
The following command displays the contents of the RSVP high availability read and write databases
used in TE.
LSP_HEAD WRITE DB
Tun ID: 2
Header:
State: Checkpointed Action: Modify
Seq #: 17 Flags: 0x0
Data:
feature flags: none
RRR path setup info
Destination: 103.103.103.103, Id: 103.103.103.103 Router Node (ospf) flag:0x0
LSP_HEAD READ DB
28
The following sections provide references related to the MPLS Traffic Engineering (TE): Path Protection
feature.
Related Documents
Configuring OSPF
ISSU ISSU MPLS Clients
ISSU and eFSU on Cisco 7600 Series Routers
NSF/SSO ISSU and eFSU on Cisco 7600 Series Routers
Standards
Standard Title
MIBs
MIB MIBs Link

29
RFCs
RFC Title
Description Link
30
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 12.0(30)S The MPLS Traffic Engineering (TE): Path
Protection 12.2(18)SXD1 Protection feature provides an end-to-end failure
12.2(33)SRC recovery mechanism (that is, full path protection)
12.4(20)T for MPLS TE tunnels.
12.2(33)SRE
introduced.
In Cisco IOS Release 12.2(18)SXD, this feature
was integrated.
In Cisco IOS Release 12.2(33)SRC, support was
added for In Service Software Upgrade (ISSU) and
Cisco nonstop forwarding with stateful switchover
(NSF/SSO). The following command was modified
by this feature: show ip rsvp high-availability
database. The following command was added:
tunnel mpls traffic-eng path-option protect.
In Cisco IOS Release 12.4(20)T, this feature was
integrated. ISSU was not supported, and NSF with
SSO was not supported. The following commands
were modified: show ip rsvp high-availability
database, tunnel mpls traffic-eng path-option,
and tunnel mpls traffic-eng path-option protect.
In Cisco IOS Release 12.2(33)SRE, support was
added for enhanced path protection. The following
commands were added or modified: mpls
traffic-eng path option list, show mpls
traffic-eng path-option list, show mpls
traffic-eng tunnels, and tunnel mpls traffic-eng
path-option protect.
31
Glossary
Glossary
autotunnel mesh groupAn autotunnel mesh group (referred to as a mesh group) is a set of connections
between edge LSRs in a network.
backup LSPThe LSP that is signaled to provide path protection. A backup LSP carries traffic only after
failure of the primary LSP.
backup tunnelAn MPLS TE tunnel used to protect other (primary) tunnels traffic when a link or node
failure occurs.
BGPBorder Gateway Protocol. An interdomain routing protocol designed to provide loop-free routing
between separate routing domains that contain independent routing policies (autonomous systems).
storing route lookup.
is being established at the headend.
graceful restartA process for helping an RP restart after a node failure has occurred.
IS-ISIntermediate 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
ISSUIn Service Software Upgrade. The ISSU process allows Cisco IOS software at the router level to
be updated or otherwise modified while packet forwarding continues. At the line-card level, an enhanced
Fast Software Upgrade (eFSU) process minimizes line-card downtime during such upgrades to between
30 and 90 seconds by preloading the new line-card image before the ISSU switchover occurs from the
active to the standby Route Processor.
linkA 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.
LSPlabel switched path. A configured connection between two routers, in which label switching is
NHOPnext hop. The next downstream node along an LSPs path.
NHOP backup tunnelnext-hop backup tunnel. The backup tunnel terminating at the LSPs 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.
NNHOPnext-next hop. The node after the next downstream node along an LSPs path.
NNHOP backup tunnelnext-next-hop backup tunnel. The backup tunnel terminating at the LSPs
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.
32
Glossary
nodeThe 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.
NSFCisco 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.
OSPFOpen 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.
path optionA path that a TE tunnel uses to reach a destination.
path option listA list of backup paths as a secondary path option to protect a primary path option.
primary LSPThe last LSP originally signaled over the protected interface before the failure. A
primary LSP is signaled by configuring a primary path option.
primary path optionA path that a TE tunnel uses originally to transport packets.
primary tunnelA tunnel whose LSP may be fast rerouted if there is a failure. Backup tunnels cannot
be primary tunnels.
protected interfaceAn interface that has one or more backup tunnels associated with it.
RPRoute Processor. A generic term for the centralized control unit in a chassis.
secondary LSPThe LSP signaled over the protected interface before the failure. A secondary LSP is
signaled by configuring a secondary path option or a path option list.
secondary pathA path that a TE tunnel uses to protect a primary path.
secondary path optionConfiguration of the path option that provides protection.
SRLGShared 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.
used.
33
Glossary
VoIPVoice over IP. The capability of a router to carry voice traffic (for example, telephone calls and faxes)
over an IP network. Ciscos voice support is implemented by using voice packet technology.
coincidental.
34
MPLS Traffic EngineeringFast Reroute Link
and Node Protection

The MPLS Traffic EngineeringFast Reroute Link and Node Protectionfeature 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

supported, see the Feature Information for MPLS Traffic EngineeringFast Reroute Link and Node
Protection section on page 37.
Contents
Prerequisites for MPLS Traffic EngineeringFast Reroute Link and Node Protection, page 2
Restrictions for MPLS Traffic EngineeringFast Reroute Link and Node Protection, page 2
Information About MPLS Traffic EngineeringFast Reroute Link and Node Protection, page 3
MPLS Traffic EngineeringFast Reroute Link and Node Protection
Prerequisites for MPLS Traffic EngineeringFast Reroute Link and Node Protection
How to Configure MPLS Traffic EngineeringFast Reroute (FRR) Link and Node Protection,
page 17
Configuration Examples for MPLS Traffic EngineeringFast Reroute (FRR) Link and Node
Protection, page 31
Feature Information for MPLS Traffic EngineeringFast Reroute Link and Node Protection,
page 37
Glossary, page 39
Prerequisites for MPLS Traffic EngineeringFast Reroute Link

and Node Protection
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 EngineeringFast 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.

2
Information About MPLS Traffic EngineeringFast Reroute Link and Node Protection
(Applicable only to Release 12.2.) You cannot enable primary one-hop autotunnels, backup
autotunnels, or autotunnel mesh groups on a router that is also configured with stateful switchover
(SSO) redundancy. This restriction does not prevent an MPLS TE tunnel that is automatically
configured by TE autotunnel from being successfully recovered by any midpoint router along the
LSPs path if the router experiences an SSO switchover.
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.
Information About MPLS Traffic EngineeringFast Reroute Link

and Node Protection
To configure MPLS Traffic EngineeringFast Reroute Link and Node Protection, you need to
Link Protection, page 3
Node Protection, page 4
Bandwidth Protection, page 5
RSVP Hello, page 5
Features of MPLS Traffic EngineeringFast 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
LSPs by rerouting them over backup tunnels that bypass failed links or node.
Link Protection
link). These are referred to as next-hop (NHOP) backup tunnels because they terminate at the LSPs next
hop beyond the point of failure. Figure 1 illustrates an NHOP backup tunnel.

3
Next-hop
backup tunnel
R1 R2 R3 R4
Next hop
59556
Primary Protected
LSP's path link
Node Protection
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.
Next-next hop
backup tunnel
R1 R2 R3 R4
Next-next hop

Backup tunnel
can protect against
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.

4
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
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
RSVP Hello
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 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 intervalUse the ip rsvp signalling hello refresh interval command.
Number of acknowledgment messages that are missed before the sending node declares that the
neighbor is downUse 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

5
Passive 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 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 EngineeringFast Reroute Link and Node Protection

MPLS Traffic EngineeringFast Reroute Link and Node Protection has the following features:
Backup Tunnel Support, page 6
Backup Bandwidth Protection, page 7
RSVP Hello, page 8
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.

6
In addition to being required for node protection, the protection of an interface by multiple backup
tunnels provides the following benefits:
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:

8
Interface down notification

RSVP Hello neighbor down notification
When a routers 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.
RedundancyIf 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 balancingIf 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 LSPs outgoing interface; that is, the interface is
configured with the mpls traffic-eng backup-path command.
The backup tunnel does not traverse the LSPs protected interface.
The backup tunnel terminates at the LSPs NHOP or NNHOP. If it is an NNHOP tunnel, it does not
traverse the LSPs 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 bandwidthA backup tunnel provides bandwidth protection. The sum of the
bandwidth of all LSPs using this backup tunnel cannot exceed the backup tunnels backup
bandwidth. When you assign LSPs to this type of backup tunnel, sufficient backup bandwidth must
exist.
Unlimited backup bandwidthThe 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 LSPs 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 LSPs
NNHOP, and the other terminates at the LSPs 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
Preemption Algorithms section on page 14.
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 tunnels 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 LSPs 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 bandwidthMakes available more bandwidth than needed, but
results in lots of waste
Ten LSPs, each using one unit of bandwidthResults 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.
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

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

16
How to Configure MPLS Traffic EngineeringFast Reroute (FRR) Link and Node Protection
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 EngineeringFast 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, enter the
following commands at the headend of each LSP.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng fast-reroute [bw-protect]

17
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
backup tunnel if there is a link or node failure.
Example:
fast-reroute bw-protect
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
7. tunnel mpls traffic-eng path-option [protect] number {dynamic | explicit | {name path-name |
8. ip explicit-path name word
9. exclude-address ip-address

18
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
Router(config-if)# ip unnumbered loopback 0 Lookback0 has 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
Example:
NNHOP of LSPs to be protected.
Step 6 tunnel mode mpls traffic-eng Sets the encapsulation mode of the tunnel to
MPLS TE.
Example:
Step 7 tunnel mpls traffic-eng path-option [protect] Configures a path option for an MPLS TE tunnel.
preference-number {dynamic | explicit | {name Enters router configuration mode.
path-name | path-number}}[lockdown]
Example:
Router(config-if)# tunnel mpls traffic-eng path-option
10 explicit avoid-protected-link

19
Command Purpose
Step 8 ip explicit-path name word Enters the command mode for IP explicit paths
and creates the specified path. Enters explicit path
command mode.
Example:
Router(config-router)# ip explicit-path name
avoid-protected-link
Step 9 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.
Note Backup tunnel paths can be dynamic or
explicit and they do not have to use
exclude-address. Because backup tunnels
Example: must avoid the protected link or node, it is
Router(config-ip-expl-path)# exclude-address 3.3.3.3 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).
Assigning Backup Tunnels to a Protected Interface

To assign one or more backup tunnels to a protected interface, 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.
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

20
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Step 3 interface type slot/port Moves configuration to the physical interface
level, directing subsequent configuration
commands to the specific physical interface
identified by the type value. The slot and port
identify the slot and port being configured. The
interface must be a supported interface. See the
Example: Finding Feature Information section on page 1.
Router(config)# interface POS 5/0 Enters interface configuration mode.
Step 4 mpls traffic-eng backup-path tunnel interface Allows LSPs going out this interface to use this
Example: Note You can enter this command multiple
Router(config-if)# mpls traffic-eng backup-path tunnel times to associate multiple backup tunnels
2 with the same protected interface.
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, enter the following commands.
SUMMARY STEPS
1. enable
4. tunnel mpls traffic-eng backup-bw {bandwidth | [sub-pool {bandwidth | Unlimited}]
[global-pool {bandwidth | Unlimited}]

21
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
specified tunnel.
Example:
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}]
from the specified pool can use the tunnel.
Example:
Router(config-if)# tunnel mpls traffic-eng backup-bw
sub-pool 1000
Configuring Backup Bandwidth Protection

To configure backup bandwidth protection, enter the following commands.
SUMMARY STEPS
1. enable
3. tunnel mpls traffic-eng-fast-reroute [bw-protect]
4. mpls traffic-eng fast-reroute backup-prot-preemption [optimize-bw]
DETAILED STEPS

Example:
Router> enable
Step 2 configure terminal Enters interface configuration mode.
Example:

22
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. Enters global
configuration mode.
Step 4 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.
Router(config)# mpls traffic-eng fast-reroute
backup-prot-preemption optimize-bw
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}
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Router(config)# interface pos0/0

23
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
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:
Router(config-if)# pos report lrdi
Verifying That Fast Reroute Is Operational

To verify that FRR can function, perform the following steps.
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.

3. show mpls traffic-eng fast-reroute database
4. show mpls traffic-eng tunnels backup
6. show ip rsvp reservation
DETAILED STEPS

Use this command to verify that backup tunnels are up:
Following is sample output from the show mpls traffic-eng tunnels brief command:
Signalling Summary:
Forwarding: enabled
Router_t1 10.112.0.12 - PO4/0/1 up/up

24
Router_t2 10.112.0.12 - unknown up/down

Router_t3 10.112.0.12 - unknown admin-down
Router_t2000 10.110.0.10 - PO4/0/1 up/up

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.
PATH:
Path refreshes:
Session Attr:
ERO: (incoming)
RRO:
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 pos5/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 pos5/0:Untagged Tu0:12304 ready
LSP midpoint frr information:

LSP identifier In-label Out intf/label FRR intf/label Status
10.0.0.12 1 [459] 16 pos0/1:17 Tu2000:19 ready

25
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:

Tun hd Untagged 10.0.0.11/32 48 pos5/0 point2point
MAC/Encaps=4/8, MTU=1520, Tag Stack{22}
48D18847 00016000
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
Fast Reroute Backup Provided:
Protected i/fs: PO1/0, PO1/1, PO3/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: PO1/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 existsVerify that there is a backup tunnel that terminates at this LSPs NHOP or
NNHOP. Look for the LSPs NHOP or NNHOP in the Dest field.
Backup tunnel is upTo verify that the backup tunnel is up, look for Up in the State field.
Backup tunnel is associated with LSPs interfaceVerify that the interface for the LSP is allowed
to use this backup tunnel. Look for the LSPs output interface in the protects field list.
Backup tunnel has sufficient bandwidthIf 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
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

26
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 typeIf 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:17 Tu2000:19 ready
Note 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:

48D18847 00016000

27
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
Average Bitrate is 0 bits/sec, Maximum Burst is 1K bytes
RRO:
172.18.1.1/32, Flags:0x1 (Local Prot Avail/to NHOP)
172.19.1.1/32, Flags:0x0 (Local Prot Avail/In Use/Has BW/to NHOP)
Resv ID handle: CD000404.
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
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

28
Couldnt get rsbs (error may self-correct when Resv arrives) Error Message Is Printed at the
Point of Local Repair

At a PLR, LSPs transition from Ready to Active if one of the following events occurs:
Primary interface goes downIf the primary interface (LSPs 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 downIf Hellos are enabled on the primary interface (LSPs outbound
interface), and the LSPs 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).

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 requestDisplays upstream reservation state (that is, information related to the Resv
messages that this node will send upstream).
show ip rsvp reservationDisplays information about Resv messages received.
show ip rsvp senderDisplays 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.

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

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

30
Configuration Examples for MPLS Traffic EngineeringFast Reroute (FRR) Link and Node Protection
Configuration Examples for MPLS Traffic EngineeringFast

Reroute (FRR) Link and Node Protection
Enabling Fast Reroute for all Tunnels: Example, page 31
Creating an NHOP Backup Tunnel: Example, page 32
Creating an NNHOP Backup Tunnel: Example, page 32
Assigning Backup Tunnels to a Protected Interface: Example, page 32
Associating Backup Bandwidth and Pool Type with Backup Tunnels: Example, page 33
Configuring Backup Bandwidth Protection: Example, page 33
Configuring an Interface for Fast Link and Node Failure Detection: Example, page 33
Configuring RSVP Hello and POS Signals: Example, page 33
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
POS5/0
R1 R2 R3 R4
Tunnel 172.16.1.2
1000
Tunnel 172.16.1.3
2000
= Primary tunnels
59561
= 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.

31
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 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 5/0:
Router(config-if)# mpls traffic-eng backup-path tunnel 1

32
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:
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 dscpSets the differentiated services code point (DSCP) value that is in
the IP header of the Hello message.
ip rsvp signalling hello refresh missesSpecifies 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 intervalConfigures the Hello request interval.
ip rsvp signalling hello statisticsEnables Hello statistics on the router.

33
For configuration examples, see the Hello command descriptions in the Command Reference section
of MPLS Traffic Engineering (TE): Link and Node Protection, with RSVP Hellos Support,
Release 12.0(24)S.
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 EngineeringFast Reroute Link
and Node Protection feature.
Related Documents

Link protection MPLS TE: Link and Node Protection, with RSVP Hellos Support
Shared risk link groups MPLS Traffic Engineering: Shared Risk Link Groups
FRR protection of TE LSPs from SRLG failure MPLS Traffic Engineering: Shared Risk Link Groups
Configuration of MPLS TE tunnels MPLS Traffic Engineering: Interarea Tunnels
Configuring OSPF

34
Standards
Standards Title
draft-ietf-mpls-rsvp-lsp-fastreroute-04.txt Fast ReRoute Extensions to RSVP-TE for LSP Tunnels
MIBs
MIBs MIBs Link
RFCs
RFCs Title
draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Description Link

35
Command Reference
Command Reference
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 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 sender
show mpls traffic tunnel backup
show mpls traffic-eng tunnels summary
tunnel mpls traffic-eng backup-bw

36
Feature Information for MPLS Traffic EngineeringFast Reroute Link and Node Protection
Feature Information for MPLS Traffic EngineeringFast Reroute

Link and Node Protection
Table 3 Feature Information for MPLS Traffic EngineeringFast Reroute Link and Node Protection

MPLS Traffic EngineeringFast Reroute 12.0(10)ST The MPLS Traffic EngineeringFast Reroute Link and
Link and Node Protection 12.0(16)ST Node Protection feature supports link protection
12.0(22)S (backup tunnels that bypass only a single link of the
12.0(23)S label-switched path (LSP), node protection (backup
12.0(24)S tunnels that bypass next-hop nodes along LSPs), and the
12.0(29)S following FRR features: backup tunnel support, backup
12.2(33)SRA bandwidth protection, and RSVP Hellos.
12.4(20)T
In 12.0(10)ST, the Fast Reroute Link Protection feature
was introduced.
In 12.0(16)ST, Link Protection for Cisco series 7200
and 7500 platforms was added.
In 12.0(22)S, Fast Reroute enhancements were added.
In 12.0(23)S, the show mpls traffic-eng fast-reroute
database command was revised.
In 12.0(24)S, support for the Cisco 10720 Internet
router and the Cisco 12000 series router engine 3 was
added.
In 12.0(29)S, backup bandwidth protection was added.
In 12.2(33)SRA, the commands were integrated into
this release.
Release 12.4(20)T.

37
Feature Information for MPLS Traffic EngineeringFast Reroute Link and Node Protection
Table 3 Feature Information for MPLS Traffic EngineeringFast Reroute Link and Node Protection

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 bandwidthThe usage of NHOP and NNHOP backup tunnels to provide bandwidth protection
for rerouted LSPs.
failure occurs.
bandwidthThe available traffic capacity of a link.
storing route lookup.
enterprise networkA large and diverse network connecting most major points in a company or other
organization.
global poolThe total bandwidth allocated to an MPLS traffic engineering link or node.
instanceA 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 SystemIS-IS. Link-state hierarchical routing protocol that
calls for intermediate system (IS) routers to exchange routing information based on a single metric to
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 bandwidthBackup tunnels that provide bandwidth protection.
load balancingA 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.
LSPlabel-switched path. A connection between two routers in which MPLS forwards the packets.
MPLS global label allocationThere 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.

39
Glossary
NHOP backup tunnelnext-hop backup tunnel. Backup tunnel terminating at the LSPs next hop
NNHOP backup tunnelnext-next-hop backup tunnel. Backup tunnel terminating at the LSPs
can be interconnected by links, and serve as control points in the network. Nodes can be processors,
controllers, or workstations.
OSPFOpen 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 LSPThe last LSP originally signaled over the protected interface before the failure. The
primary LSP is the LSP before the failure.
primary tunnelTunnel whose LSP may be fast rerouted if there is a failure. Backup tunnels cannot
be primary tunnels.
promotionConditions, 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.
redundancyThe 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.
RSVPResource 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.
scalabilityAn indicator showing how quickly some measure of resource usage increases as a network
gets larger.
SRLGshared risk link group. Sets of links that are likely to go down together.
tunnels.
sub-poolThe more restrictive bandwidth in an MPLS traffic engineering link or node. The subpool is
a portion of the link or nodes overall global pool bandwidth.
structure.
unlimited backup bandwidthBackup tunnels that provide no bandwidth (best-effort) protection (that
is, they provide best-effort protection).

40
Glossary
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 in order 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.
Note If the Multiprotocol Label Switching (MPLS) TE FRR Link Protection feature is planned to be used in
releases earlier than Cisco IOS Release 12.0(24)S, contact the Cisco Technical Assistance Center for
important deployment and upgrade information.
For information about shared risk link groups (SRLGs), which are sets of links that are likely to go down
together, refer to MPLS Traffic Engineering: Shared Risk Link Groups.
MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down Detection)

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 39.
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 33
Feature Information for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast
Glossary, page 41
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 features in order to support features described in
this document:
MPLS
Your network must support at least one of the following protocols:
Intermediate System-to-Intermediate System (IS-IS)
Open Shortest Path First (OSPF)
2
Restrictions for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down
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.
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
RSVP Hello, page 5
Features of MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Fast Reroute Operation, page 9
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
LSPs by rerouting them over backup tunnels that bypass failed links or nodes.
For information about how FRR protects TE LSPs from shared risk link group (SRLG) failure, refer to
MPLS Traffic Engineering: Shared Risk Link Groups.
3
Information About MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down
Link Protection
Backup tunnels that bypass only a single link of the LSPs path provide Link Protection. They protect
hop beyond the point of failure. Figure 1 illustrates an NHOP backup tunnel.
Next-hop
backup tunnel
R1 R2 R3 R4
Next hop
59556
Primary Protected
LSP's path link
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.
Next-next hop
backup tunnel
R1 R2 R3 R4
Next-next hop

Backup tunnel
can protect against
59557
4
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.)
protected. For information about mapping tunnels and assigning backup bandwidth, see the Backup
Tunnel Selection Procedure section on page 11.
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
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 6
Hello Instance, page 6
Hello Commands, page 7
5
RSVP Hello Operation

Note
Hello Instance
6
Hello Commands
Traffic EngineeringRSVP Hello State Timer
Features of MPLS TE: Link and Node Protection, with RSVP Hellos Support
Backup Tunnel Support
Backup Tunnels Can Terminate at the Next-Next Hop to Support FRR
Multiple Backup Tunnels Can Protect the Same Interface
7
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 10
and the Backup Tunnels Terminating at the Same Destination section on page 11.
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
Semidynamic Backup Tunnel Paths, page 8
Prioritizing Which LSPs Obtain Backup Tunnels with Bandwidth Protection, page 9
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.
8
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
receive chance
Fast Reroute Operation
9
Fast Reroute Activation
Backup Tunnels Terminating at Different Destinations
Figure 3 Backup Tunnels that Terminate at Different Destinations
R1 R2 R3
R4
= Primary tunnels
59558
= Backup tunnels
10
Backup Tunnels Terminating at the Same Destination
Figure 4 Backup Tunnels that Terminate at the Same Destination
Backup tunnel
T2
T1
R1 R2 R3
59559
Primary
LSP's path
Backup Tunnel Selection Procedure
tunnel mpls traffic-eng

fast-reroute

mpls traffic-eng backup-path

Load Balancing on Limited-bandwidth Backup Tunnels
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
Figure 6 Overloaded Link
R2
R3
Primary tunnel 2
82032
Load Balancing on Unlimited-bandwidth Backup Tunnels
Pool Type and Backup Tunnels
Tunnel Selection Priorities
NHOP Versus NNHOP Backup Tunnels

Table 1 Tunnel Selection Priorities
Backup Tunnel
Preference Destination Bandwidth Pool Bandwidth Amount
Note
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
1.
2.
3.
4.
5.
Promotion
1.
2.
3.
4.
mpls traffic-eng fast-reroute timers
Backup Protection Preemption Algorithms
mpls traffic-eng fast-reroute

Bandwidth Protection Considerations
Bandwidth Protection Methods
Method Advantages Disadvantages

Using Backup Tunnels Signaled with Zero Bandwidth, page 17
Using Backup Tunnels with Explicitly Signaled Bandwidth

Protected Bandwidth Pools and the Bandwidth Pool from Which the Backup Tunnel Reserves Its Bandwidth

Note
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 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 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
How to Configure MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface Down
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.
How to Configure MPLS TE: Link and Node Protection, with

Detection)
configured.
Make sure that the following tasks have been performed before you perfom 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
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 19 (required)
Creating a Backup Tunnel to the Next Hop or to the Next-Next Hop, page 20 (required)
Assigning Backup Tunnels to a Protected Interface, page 21 (required)
Associating Backup Bandwidth and Pool Type with a Backup Tunnel, page 22 (optional)
Configuring Backup Bandwidth Protection, page 23 (optional)
Configuring an Interface for Fast Link and Node Failure Detection, page 24 (optional)
Configuring an Interface for Fast Tunnel Interface Down, page 25 (optional)

Verifying That Fast Reroute Is Operational, page 25 (optional)
Note You can perform the configuration tasks in any order.
Note An NNHOP backup tunnel must go via the NHOP.

LSPs can use backup tunnels only if they have been configured as fast reroutable. To do this, 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]
DETAILED STEPS
Command Purpose
Example:
Router> enable
configure terminal Enters global configuration mode.

interface tunnel number Enters interface configuration mode for the
specified tunnel.

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.

fast-reroute bw-protect node-protect
Note exclude-address
SUMMARY STEPS
1. enable
3. interface tunnel
tunnel destination A.B.C.D
7. tunnel mpls traffic-eng path-option number {dynamic | explicit {name path-name
8. ip explicit-path name
9. exclude-address
DETAILED STEPS
Command Purpose
Step 1 Enables privileged EXEC mode.
Example:
Step 2 Enters global configuration mode.
Example:
Step 3 Creates a new tunnel interface and enters interface

configuration mode.
Example:
Step 4 type number Gives the tunnel interface an IP address that is the
same as that of interface Loopback0.
Example: This command is not effective until
Router(config-if)# ip unnumbered loopback0 Lookback0 has been configured with an IP
address.
A.B.C.D Specifies the IP address of the device where the
tunnel will terminate.
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.
Sets encapsulation mode of the tunnel to MPLS
TE.

tunnel mpls traffic-eng path-option number {dynamic |
explicit {name path-name | path-number}} [lockdown]

300 explicit name avoid-protected-link
ip explicit-path name name

exclude-address address

Command Purpose
Step 1 enable

Example:
Router> enable
Example:
Step 3 interface slot/port
Example:
type
slot port
Step 4 tunnel-id
Example: Note
tunnel2
SUMMARY STEPS
1.
2.
3.
4. bandwidth bandwidth
bandwidth bandwidth
DETAILED STEPS
Command Purpose
Step 1

Example:
Router> enable
Step 2
Example:
Step 3 number
Example:
Step 4 {bandwidth |
[ {bandwidth | }][
{bandwidth | }]} [ {bandwidth |
}]
Example:
sub-pool 1000
SUMMARY STEPS
1.
2.
3. number
4.
5.
DETAILED STEPS
Step 1

Example:
Router> enable
Step 2
Example:
number

[ ]
bw-protect
[optimize-bw]

Configuring an Interface for Fast Link and Node Failure Detection
SUMMARY STEPS
1.
2.
3. type slot port
4.
5. b2-tca b3-tca lais lrdi pais plop prdi rdool sd-ber sf-ber slof
slos
enable
Router> enable
configure terminal

interface /
Router(config)# interface pos0/0

pos ais-shut

pos report {b1-tca | b2-tca | b3-tca | lais | lrdi |
pais | plop | prdi | rdool | sd-ber | sf-ber | slof |
slos}
enable
configure terminal
interface type slot/port
tunnel mpls traffic-eng interface down delay time
enable
Router> enable
configure terminal

interface /

tunnel mpls traffic-eng interface down delay
Router(config-if)# tunnel mpls traffic-eng interface

down delay 0
show mpls traffic-eng tunnels brief
show ip rsvp sender detail
show mpls traffic-eng tunnels backup
show mpls traffic-eng tunnels brief
Signalling Summary:
Forwarding: enabled
Router_t1 10.112.0.12 - PO4/0/1 up/up
Router_t2000 10.110.0.10 - PO4/0/1 up/up
PATH:
Path refreshes:
Session Attr:
ERO: (incoming)
RRO:


Protected tunnel In-label Out intf/label FRR intf/label Status
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
LSP midpoint item frr information:

show mpls forwarding-table ip-address detail
Router# show mpls forwarding-table 10.0.0.11 32 detail

48D18847 00016000
primary
Figure 8 Protected LSPs
Primary tunnel 500
ATM 4/0.100
R1 R2 R3 R4
POS 2/0
121955
Backup tunnel 501




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


LSP is reroutable show run int tunnel
Router_t578
Protected lsps: 1
Router_t5710
Protected lsps: 0
Router_t5711
Protected lsps: 2
tunnel mpls
traffic-eng bandwidth
tunnel
mpls traffic-eng bandwidth

debug ip rsvp fast-reroute
debug mpls traffic-eng fast-reroute
shutdown
no shutdown




10.0.0.12 1 [459] 16 pos0/1:17 Tu2000:19 ready
show mpls forwarding-table detail

48D18847 00016000

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
Reservation:
Next Hop: 10.1.1.2 on POS1/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 31
Primary Tunnel Does Not Select Backup Tunnel That Is Up, page 32
Enhanced RSVP Commands, page 32
RSVP Hello, page 32
Hello Instances Have Not Been Created, page 32
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 33
Couldnt get rsbs (error may self-correct when Resv arrives) Error Message Is Printed at the Point
of Local Repair, page 33

shutdown
no shutdown
Note
Enhanced RSVP Commands

show ip rsvp sender
show mpls forwarding
RSVP Hello
ip rsvp signalling hello

(configuration)
ip rsvp
signalling hello (interface)
show ip rsvp sender
Configuration Examples for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
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
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.
Couldnt 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.
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 34
Creating an NNHOP Backup Tunnel: Example, page 35
Configuring an Interface for Fast Link and Node Failure Detection: Example, page 36
Configuring an Interface for Fast Tunnel Interface Down: Example, page 36
Configuring RSVP Hello and POS Signals: Example, page 36
Configuration Examples for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface

10.3.3.3 10.4.4.4
POS5/0
R1 R2 R3 R4
Tunnel 172.16.1.2
1000
Tunnel 172.16.1.3
2000
= Primary tunnels
59561
= Backup tunnels
Enabling Fast Reroute for All Tunnels: Example
bw-prot node-prot
interface Tunnel2000
tunnel mpls traffic-eng fast-reroute bw-prot node-prot
Creating an NHOP Backup Tunnel: Example
ip explicit-path name avoid-protected-link

exclude-address 10.1.1.2
end
interface Tunnel1
ip unnumbered loopback0
Configuration Examples for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel

tunnel mode mpls traffic-eng0
unnel mpls traffic-eng path-option explicit avoid-protected-link
ip explicit-path name avoid-protected-node

exclude-address 10.3.3.3
end
interface Tunnel2
ip unnumbered loopback0
tunnel mode mpls traffic-eng0
tunnel mpls traffic-eng path-option explicit avoid-protected-node
interface POS5/0
mpls traffic-eng backup-path tunnel1
interface Tunnel1
tunnel mpls traffic-eng backup-bw global-pool Unlimited
interface Tunnel2
Note
tunnel mpls traffic-eng fast-reroute bw-protect

mpls traffic-eng fast-reroute backup-prot-preemption optimize-bw
Configuration Examples for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel Interface
Configuring an Interface for Fast Link and Node Failure Detection: Example
interface pos0/0
pos ais-shut
interface pos0/0
pos report lrdi
Configuring an Interface for Fast Tunnel Interface Down: Example
interface tunnel 1000

tunnel mpls traffic-eng interface down delay 0
Configuring RSVP Hello and POS Signals: Example



ip rsvp signalling hello statistics
MPLS Traffic Engineering (TE): Link and Node Protection, with RSVP Hellos Support
pos ais-shut
pos report rdool
pos report lais
pos report lrdi
pos report pais
pos report prdi
pos report sd-ber
Related Documents
MPLS TE: Link and Node Protection, with RSVP Hellos Support
Cisco IOS Multiprotocol Label Switching Command Reference
Cisco IOS Quality of Service Solutions Command Reference
Standards
Standards Title
MIBs
MIBs MIBs Link
RFCs
RFCs Title
Fast Reroute Extensions to RSVP-TE for LSP Tunnels
Command Reference
Description Link
Command Reference
Cisco IOS Multiprotocol Label Switching
Command Reference

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)
Note
Table 3 Feature Information for MPLS TE: Link and Node Protection, with RSVP Hellos Support (with Fast Tunnel
Interface Down Detection)

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)

Link protection for GE interfaces on 10x1G engine 4+ GE,
1x10G engine 4+ GE, and 4x1G engine 3 GE routers with the
Loss of Signal Fast Reroute trigger
The command
was added.
This feature was integrated into Cisco IOS Release 12.2(33)SRB.
Glossary
Glossary
The usage of NHOP and NNHOP backup tunnels to provide bandwidth protection
for rerouted LSPs.
An MPLS TE tunnel used to protect other (primary) tunnels traffic when a link or node
failure occurs.
The available traffic capacity of a link.
enterprise network
Fast Reroute
Gigabit Ethernet
global pool
headend
hop
instance
interface
Intermediate System-to-Intermediate System
link
limited backup bandwidth

load balancing
LSP
merge point
MPLS
MPLS global label allocation
NHOP
Glossary
NHOP backup tunnel
NNHOP
NNHOP backup tunnel
node
OSPF
primary LSP
primary tunnel
promotion
protected interface
redundancy
RSVP
scalability
state
subpool
tailend
topology
tunnel
unlimited backup bandwidth
coincidental.

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.

supported, see the Feature Information for MPLS Traffic Engineering: BFD-triggered Fast Reroute section
on page 25.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS, Catalyst OS,
and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to
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 19
Feature Information for MPLS Traffic Engineering: BFD-triggered Fast Reroute, page 25
Glossary, page 26
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
BFD, page 3
2
Information About MPLS Traffic Engineering: BFD-triggered Fast Reroute
BFD
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
hop beyond the point of failure.
Node Protection
the failed link as well as the node.
protected.
3
How to Configure MPLS Traffic Engineering: BFD-triggered Fast Reroute
How to Configure MPLS Traffic Engineering: BFD-triggered Fast

Reroute
configured.
To review how to configure MPLS TE tunnels, see the MPLS Traffic Engineering: Interarea Tunnels
process module.
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 8 (required)
Enabling BFD on the Protected Interface, page 10 (required)
Associating Backup Bandwidth and Pool Type with a Backup Tunnel, page 10 (optional)
Configuring Backup Bandwidth Protection, page 11 (optional)
Verifying That Fast Reroute Is Operational, page 12 (optional)
Enabling BFD Support on the Router

To enable support for Bidirectional Fowarding on the router, enter the following commands.
SUMMARY STEPS
1. enable
3. ip rsvp signalling hello bfd
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

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]
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
5
Command Purpose
specified tunnel.
Example:
[node-protect] backup tunnel if there is a link or node failure.
Example:
fast-reroute bw-protect node-protect

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.
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
5. tunnel destination A.B.C.D
path-number}}[lockdown]
8. exit
9. ip explicit-path name name
10. exclude-address address
6
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 type number Gives the tunnel interface an IP address that is the
same as that of interface loopback 0.
Example: Note This command is not effective until
Router(config-if)# ip unnumbered loopback 0 lookback 0 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. That address should be the
router ID of the device that is the NHOP or
Example:
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:
10 explicit name avoid-protected-link
Example:
7
Command Purpose
Step 9 ip explicit-path name name Enters IP explicit path mode for IP explicit paths
to create the named path.
Example:
Step 10 exclude-address address For link protection, specifies the IP address of the
link to be protected. For node protection, specifies
the router ID of the node to be protected.
Example:
Router(cfg-ip-expl-path)# exclude-address 10.3.3.3 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.

SUMMARY STEPS
1. enable
4. mpls traffic-eng backup-path tunnel tunnel-id
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
8
Command Purpose
Step 3 interface type slot/port Moves configuration to the physical interface
level, directing subsequent configuration
commands to the specific physical interface
Example:
Router(config)# interface Gi 9/1
identified by the type value, and enters interface
configuration mode. The slot and port values
identify the slot and port being configured. The
interface must be a supported interface. See the
Finding Feature Information section on page 1.
Step 4 mpls traffic-eng backup-path tunnel tunnel-id Allows LSPs going out this interface to use this
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.
9
Enabling BFD on the Protected Interface

SUMMARY STEPS
1. enable
4. ip rsvp signalling hello bfd
5. bfd interval milliseconds min_rx milliseconds multiplier interval-multiplier
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
Example:
Router(config)# interface Gi9/1
Step 4 ip rsvp signalling hello bfd Enables the BFD protocol on the interface for
MPLS TE link and node protection.
Example:
Router(config-if)# ip rsvp signalling hello bfd
Step 5 bfd interval milliseconds min_rx milliseconds Sets the BFD interval.
multiplier interval-multiplier
Example:
Router(config-if)# bfd interval 100 min_rx 100
multiplier 4

To associate backup bandwidth with a backup tunnel and designate the type of LSP that can use a backup
tunnel, enter the following commands.
SUMMARY STEPS
1. enable
10
4. tunnel mpls traffic-eng backup-bw {bandwidth | [sub-pool {bandwidth |
Unlimited}][global-pool {bandwidth | Unlimited}]}[any {bandwidth | Unlimited}]
DETAILED STEPS
Command Purpose
Example:
Router> enable
Example:
specified tunnel.
Example:
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:
sub-pool 1000

To configure the backup bandwidth protection, perform the following steps.
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
11
DETAILED STEPS

Example:
Router> enable
Example:
specified tunnel.
Example:
backup 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.
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.
Verifying That Fast Reroute Is Operational

To verify that FRR can function, perform the following steps.
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.
12
Note To determine the status of BFD, perform Steps 9 through 11.

4. show mpls traffic-eng tunnels backup
6. show ip rsvp reservation
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

Use this command to verify that backup tunnels are up:
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

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 router acting as the point of local repair (PLR) before a failure:
PATH:
Path refreshes:
Session Attr:
ERO: (incoming)
13

RRO:

MPLS TE FRR Node Protection has been enabled.



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
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 9/1 is protected by backup tunnel 501.
14
Figure 1 Protected LSPs
Primary tunnel 500
Gi9/1
R1 R2 R3 R4
Gi7/1
186133
Backup tunnel 501
Figure 1 shows the following:

Primary tunnel 500Path is R1 via Gigabit Ethernet9/1 to R2 to R3 to R4.
FRR backup tunnel 501Path is R1 via Gigabit Ethernet7/1to R2.
Interface Gigabit Ethernet9/1Protected by backup tunnel 501.



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

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 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.
15
On the router where the backup tunnels originate, enter the show mpls traffic-eng tunnels backup
command. Following is sample command output:
Router_t578
Protected lsps: 1
Router_t5710
Protected lsps: 0
Router_t5711
Protected lsps: 2
The command output will allow you to verify the following:

Backup tunnel existsVerify that there is a backup tunnel that terminates at this LSPs NHOP or
NNHOP. Look for the LSPs NHOP or NNHOP in the Dest field.
Backup tunnel is upTo verify that the backup tunnel is up, look for Up in the Oper field.
Backup tunnel is associated with the LSPs interfaceVerify that the interface for the LSP is
allowed to use this backup tunnel. Look for the LSPs output interface in the protected i/fs field list.
Backup tunnel has sufficient bandwidthIf 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
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 In order to determine how much bandwidth is sufficient, offline capacity planning may be required.
Backup tunnel has appropriate bandwidth typeIf 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.
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:
1. Enter the shutdown command for the primary tunnel.
16
2. Enter the no shutdown command for the primary tunnel.

3. View the debug output.


Tunne1l0 Tun Gi5/0:Untagged Tu0:12304 ready

10.0.0.11/32 Tu110 Tun hd Gi5/0:Untagged Tu0:12304 ready

10.0.0.12 1 [459] 16 Gi0/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 Gi5/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
RRO:
17


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 rsv interface detail
Gi9/47:
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
Window size: 1
Challenge: disabled
FRR Extension:
Backup Path: Configured (or "Not Configured")
BFD Extension:
State: Disabled
18
Configuration Examples for MPLS Traffic Engineering: BFD-triggered Fast Reroute
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 Gi9/47 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: Gi9/47
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 Gi9/47 Up 0 1
Configuration Examples for MPLS Traffic Engineering:

BFD-triggered Fast Reroute
Enabling BFD Support on the Router: Example, page 20
Enabling Fast Reroute on LSPs: Example, page 20
Creating a Backup Tunnel to the Next Hop: Example, page 21
19
Enabling BFD on the Protected Interface: Example, page 21


10.3.3.3 10.4.4.4
Gi7/1
R1 R2 R3 R4
Tunnel 172.16.1.2
1000
Tunnel 172.16.1.3
2000
= Primary tunnels
186134
= Backup tunnels
Enabling BFD Support on the Router: Example

The following example enables the BFD protocol on the router:
Router(config)# ip rsvp signalling hello bfd
Enabling Fast Reroute on LSPs: 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 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
20
Creating a Backup Tunnel to the Next Hop: 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)# ip explicit-path name avoid-protected-link
Explicit Path name avoid-protected-link:

Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit avoid-protected-link

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 mode mpls traffic-eng0
Router(config-if)# tunnel mpls traffic-eng path-option 1 explicit avoid-protected-node

On router R2, associate both backup tunnels with interface Gigabit Ethernet 5/0:
Enabling BFD on the Protected Interface: Example

BFD is enabled on interface Gigabit Ethernet 9/47:
Router(config-if)# ip rsvp signalling hello bfd
Router(config-if)# bfd interval 100 min_rx 100 multiplier 4
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.
21

Router(config-if)# tunnel mpls traffic-eng backup-bw global-pool Unlimited

Router(config-if)# tunnel mpls traffic-eng backup-bw sub-pool 1000

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
The following sections provide references related to the MPLS Traffic Engineering: BFD-triggered Fast
Reroute feature.
22
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 Bidirectional Forwarding Detection
Direction configuration
information
MPLS Traffic Engineering MPLS Traffic Engineering: Interarea Tunnels
Interarea Tunnels configuration
information
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
23
Command Reference
Description Link
Command Reference
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
show ip rsvp interface detail
24
Feature Information for MPLS Traffic Engineering: BFD-triggered Fast Reroute
Feature Information for MPLS Traffic Engineering:

BFD-triggered Fast Reroute
Cisco Feature Navigator enables you to determine which Cisco IOS, Catalyst OS, and 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.
Table 1 Feature Information for MPLS Traffic Engineering: BFD-triggered Fast Reroute

MPLS Traffic Engineering: BFD-triggered Fast 12.2(33)SRC MPLS Traffic Engineering: BFD-triggered Fast
Reroute Cisco IOS XE Reroute allows you to obtain link and node protection
Release 2.3 by using the BFD protocol.
In Cisco IOS XE Release 2.3, this feature was
introduced on the Cisco ASR 1000 series 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.
25
Glossary
Glossary
backup bandwidthThe usage of NHOP and NNHOP backup tunnels to provide bandwidth protection
for rerouted LSPs.
failure occurs.
bandwidthThe available traffic capacity of a link.
fast rerouteProcedures that enable temporary routing around a failed link or node while a new LSP
global poolThe total bandwidth allocated to an MPLS traffic engineering link or node.
instanceA 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
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.
LSPlabel-switched path. A configured connection between two routers, in which label switching is
NHOP backup tunnelnext-hop backup tunnel. Backup tunnel terminating at the LSPs next hop
NNHOP backup tunnelnext-next-hop backup tunnel. Backup tunnel terminating at the LSPs
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,
controllers, or workstations.
primary LSPThe last LSP originally signaled over the protected interface before the failure. The LSP
before the failure.
primary tunnelTunnel whose LSP may be fast rerouted if there is a failure. Backup tunnels cannot
be primary tunnels.
26
Glossary
tunnels.
subpoolThe more restrictive bandwidth in an MPLS traffic engineering link or node. The subpool is
a portion of the link or nodes overall global pool bandwidth.
unlimited backup bandwidthBackup tunnels that provide no bandwidth (best-effort) protection (that
is, they provide best-effort protection).
coincidental.
27
Glossary
28
MPLS Layer 2 VPNs
Any Transport over MPLS

This document describes the Any Transport over MPLS (AToM) feature, which provides the following
capabilities:
Transport data link layer (Layer2) packets over a Multiprotocol Label Switiching (MPLS) backbone.
Enable service providers to connect customer sites with existing Layer 2 networks by using a single,
integrated, packet-based network infrastructurea Cisco MPLS network. Instead of using separate
networks with network management environments, service providers can deliver Layer 2
connections over an MPLS backbone.
Provide 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

supported, see the Feature Information for Any Transport over MPLS section on page 88.
Contents
Contents
Prerequisites for Any Transport over MPLS, page 2
Restrictions for Any Transport over MPLS, page 3
Information About Any Transport over MPLS, page 5
How to Configure Any Transport over MPLS, page 14
Configuration Examples for Any Transport over MPLS, page 67
Feature Information for Any Transport over MPLS, page 88
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 or distributed 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 routers 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.
AToM is supported on the Cisco 7200 and 7500 series routers. For details on supported hardware,
see the following documents:
Cross-Platform Release Notes for Cisco IOS Release 12.0S
Cross-Platform Release Notes for Cisco IOS Release 12.4T, Part 2: Platform-Specific
Information
AToM is supported on the Cisco 7600 routers. For details on supported shared port adapters and line
cards, see the following documents:
Guide to Supported Hardware for Cisco 7600 Series Routers with Release 12.2SR
Cross-Platform Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600 Series Routers
The Cisco 7600 router has platform-specific instructions for configuring some AToM features.
Platform-specific configuration information is included in the following documents:
The Configuring PFC3BXL and PFC3B Mode Multiprotocol Label Switching module of the
Cisco 7600 Series Cisco IOS Software Configuration Guide, Release 12.2SR
The Configuring Multiprotocol Label Switching on the Optical Services Modules module of
the OSM Configuration Note, Release 12.2SR
The Configuring Multiprotocol Label Switching on FlexWAN and Enhanced FlexWAN
Modules module of the FlexWAN and Enhanced FlexWAN Modules Installation and
Configuration Guides of Cisco 7600 Series Routers.
The Configuring Any Transport over MPLS on a SIP section of the Cisco 7600 Series Router
SIP, SSC, and SPA Software Configuration Guide
2
Restrictions for Any Transport over MPLS
The Configuring AToM VP Cell Mode Relay Support section of the Cisco 7600 Series Router
SIP, SSC, and SPA Software Configuration Guide
The Cross-Platform Release Notes for Cisco IOS Release 12.2SR
AToM is supported on the Cisco 10000 series routers. For details on supported hardware, see the
Configuring Any Transport over MPLS section of the Cisco 10000 Series Router Software
Configuration Guide.
The Cisco 10000 series router has platform-specific instructions for configuring some AToM
features. Platform-specific configuration information is contained in the Configuring Any
Transport over MPLS section of the Cisco 10000 Series Router Broadband Aggregation,
Leased-Line, and MPLS Configuration Guide.
AToM is supported on the Cisco12000 series routers. For information about hardware requirements,
see the Cross-Platform Release Notes for Cisco IOS Release 12.0S.

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.
Distributed Cisco Express Forwarding is the only forwarding model supported on the Cisco 12000
series routers and is enabled by default. Disabling distributed Cisco Express Forwarding on the
Cisco 12000 series routers disables forwarding.
Distributed Cisco Express Forwarding mode is supported on the Cisco 7500 series routers for Frame
Relay, HDLC, and PPP. In distributed Cisco Express Forwarding mode, the switching process occurs
on the Versatile Interface Processors (VIPs) that support switching. When distributed Cisco Express
Forwarding is enabled, VIP port adapters maintain identical copies of the Forwarding Information
Base (FIB) and adjacency tables. The port adapters perform the express forwarding between port
adapters, relieving the Route Switch Processor (RSP) from performing the switching. Distributed
Cisco Express Forwarding uses an interprocess communications (IPC) mechanism to ensure
synchronization of FIBs and adjacency tables between the RSP and port adapters.
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.
Configuring ATM Relay over MPLS with the Cisco 12000 Series Router engine 2 8-port OC-3
STM-1 ATM line card: In Cisco IOS Release 12.0(25)S, there were special instructions for
configuring ATM cell relay on the Cisco 12000 series router with an engine 2 8-port OC-3 STM-1
ATM line card. The special configuration instructions do not apply in releases later than Cisco IOS
Release 12.0(25)S and you do not need to use the atm mode cell-relay command.
In Cisco IOS Release 12.0(25)S, when you configured the Cisco 12000 series 8-port OC-3 STM-1
ATM line card for ATM Cell Relay over MPLS, two ports were reserved. In releases later than
Cisco IOS Release 12.0(25)S, only one port is reserved.
In addition, in Cisco IOS Release 12.0(25)S, if you configured an 8-port OC-3 STM-1 ATM port for
ATM AAL5 over MPLS and then configured ATM single cell relay over MPLS on that port, the VCs
and VPs for AAL5 on the port and its corresponding port were removed. Starting in Cisco IOS
Release 12.0(26)S, this behavior no longer occurs. ATM AAL5 over MPLS and ATM single cell
3
relay over MPLS are supported on the same port. The Cisco 12000 series 8-port OC-3 STM-1 ATM
line cards now support, by default, the ATM single cell relay over MPLS feature in both VP and VC
modes and ATM AAL5 over MPLS on the same port.
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.
The following restrictions pertain to the Ethernet over MPLS feature:
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.
In Cisco IOS Release 12.2(25)S, the behavior of the mpls mtu command changed. If the interface
MTU is less 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.
If you upgrade to Cisco IOS Release 12.2(25)S from an earlier release and you have an MPLS MTU
setting that does not conform to these guidelines, the command is rejected. See the Maximum
Transmission Unit Guidelines for Estimating Packet Size section on page 7 for more information.
The following restrictions pertain to the Frame Relay over MPLS feature:
Frame Relay traffic shaping is not supported with AToM switched VCs.
If you configure Frame Relay over MPLS on the Cisco 12000 series router and the core-facing
interface is an engine 4 or 4+ line card and the edge-facing interface is an engine 0 or 2 line card,
then the BECN, FECN, control word (CW), and DE bit information is stripped from the PVC.
4
Information About Any Transport over MPLS

To configure AToM, you must understand the following concepts:
How AToM Transports Layer 2 Packets, page 5
AToM Configuration Commands Prior to Cisco IOS Release 12.0(25)S, page 6
Benefits of AToM, page 6
MPLS Traffic Engineering Fast Reroute, page 6
Maximum Transmission Unit Guidelines for Estimating Packet Size, page 7
Frame Relay over MPLS and DTE, DCE, and NNI Connections, page 9
QoS Features Supported with AToM, 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
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. See the Configuring the Pseudowire Class section on page 15 for more information.
5
AToM Configuration Commands Prior to Cisco IOS Release 12.0(25)S

In releases of AToM previous to Cisco IOS 12.0(25)S, the command used to configure AToM circuits
was mpls l2 transport route. This command has been replaced with the xconnect command.
No enhancements will be made to the mpls l2transport route command. Enhancements will be made
to either the xconnect command or pseudowire-class command. Therefore, Cisco recommends that you
use the xconnect command to configure AToM circuits.
Configurations from releases previous to Cisco IOS 12.0(25)S that use the mpls l2transport route
command are still supported.
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, such as the Cisco 7200 and 7500 series routers. 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 86 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 providers ability to expand the
network and can force the service provider to use only one vendors 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.
For more information on configuring MPLS TE fast reroute, see the following document:
MPLS Traffic Engineering (TE)Link and Node Protection, with RSVP Hellos Support
Note The AToM VC independence feature was introduced in Cisco IOS Release 12.0(31)S and enables the
Cisco 12000 series router to perform fast reroute in fewer than 50 milliseconds, regardless of the number
of VCs configured. In previous releases, the fast reroute time depended on the number of VCs inside the
protected TE tunnel.
For the Cisco 12000 series routers, fast reroute uses three or more labels, depending on where the TE
tunnel ends:
If the TE tunnel is from a PE router to a PE router, three labels are used.
6
If the TE tunnel is from a PE router to the core router, four labels are used.
Engine 0 ATM line cards support three or more labels, although performance degrades. Engine 2 Gigabit
Ethernet line cards and engine 3 line cards support three or more labels and can work with the fast reroute
feature.
You can issue the debug mpls l2transport fast-reroute command to debug fast reroute with AToM.
Note This command does not display output on platforms where AToM fast reroute is implemented in the
forwarding code. The command does display output on Cisco 10720 Internet router line cards and
Cisco 12000 series line cards. This command does not display output for the Cisco 7500 (both Route
Processor (RP) and VIP) series routers, Cisco 7200 series routers, and Cisco 12000 series RP.
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 shows 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, 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, 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 032 bytes
Ethernet VLAN 18 bytes
Ethernet Port 14 bytes
7
Table 1 Header Size of Packets (continued)
Transport Type Packet Size

Frame Relay DLCI 2 bytes for Cisco encapsulation, 8 bytes for Internet
Engineering Task Force (IETF) encapsulation
HDLC 4 bytes
PPP 4 bytes
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.
8
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
mpls mtu Command Changes

Some interfaces (such as FastEthernet) require the mpls mtu command to change the MTU size.
In Cisco IOS Release 12.2(25)S, the behavior of the mpls mtu command changed.
If the interface MTU is fewer 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.
If you upgrade to Cisco IOS Release 12.2(25)S and you have an MPLS MTU setting that does not
conform to these guidelines, the command is rejected.
For Cisco IOS Release 12.2(27)SBC, 12.2(33)SRA, 12.4(11)T, 12.2(33)SXH, and later releases, you
cannot set the MPLS MTU greater than the interface MTU. This eliminates problems, such as dropped
packets, data corruption, and high CPU rates. See the MPLS MTU Command Changes document for
more information.
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.
9
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.
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.
10
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.
For information about LMI, including configuration instructions, see the Configuring the LMI section
of the Configuring Frame Relay document.
QoS Features Supported with AToM

For information about configuring QoS features on the Cisco 12000 series routers, see the following
feature module:
Any Transport over MPLS (AToM): Layer 2 QoS for the Cisco 12000 Series Router (Quality of Service)
The following tables list the QoS features supported by AToM on the Cisco 7200 and 7500 series routers:
Table 3, QoS Features Supported with Ethernet over MPLS on the Cisco 7200 and 7500 Series
Routers
Table 4, QoS Features Supported with Frame Relay over MPLS on the Cisco 7200 and 7500 Series
Routers
Table 5, QoS Features Supported with ATM Cell Relay and AAL5 over MPLS on the Cisco 7200
and 7500 Series Routers
Table 3 QoS Features Supported with Ethernet over MPLS on the Cisco 7200 and 7500 Series
Routers
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)
11
Table 3 QoS Features Supported with Ethernet over MPLS on the Cisco 7200 and 7500 Series
Routers (continued)
QoS Feature Ethernet over MPLS

Policing Supports the following:
Single-rate policing
Two-rate policing
Color-aware policing
Multiple-action policing
Queueing and Supports the following:
shaping Distributed Low Latency Queueing (dLLQ)
Distributed Weighted Random Early Detection (dWRED)
Byte-based WRED
Table 4 QoS Features Supported with Frame Relay over MPLS on the Cisco 7200 and 7500
Series Routers
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)
12
Table 4 QoS Features Supported with Frame Relay over MPLS on the Cisco 7200 and 7500
Series Routers (continued)
QoS Feature Frame Relay over MPLS

Two-rate policing
Queueing and Supports the following:
shaping dLLQ
dWRED
Distributed traffic shaping
Distributed class-based weighted fair queueing (dCBWFQ)
Byte-based WRED
random-detect discard-class-based command
Table 5 QoS Features Supported with ATM Cell Relay and AAL5 over MPLS on the Cisco 7200
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)
13
How to Configure Any Transport over MPLS
Table 5 QoS Features Supported with ATM Cell Relay and AAL5 over MPLS on the Cisco 7200
QoS Feature ATM Cell Relay and AAL5 over MPLS

Two-rate policing
Queueing and shaping Supports the following:
dLLQ
dWRED
dCBWFQ
Byte-based WRED
random-detect discard-class-based command
Class-based shaping support on ATM PVCs

This section explains how to perform a basic AToM configuration and includes the following procedures:
Configuring the Pseudowire Class, page 15 (required)
Changing the Encapsulation Type and Removing a Pseudowire, page 16 (optional)
Configuring ATM AAL5 over MPLS on PVCs, page 16 (optional)
Configuring ATM AAL5 over MPLS in VC Class Configuration Mode, page 18 (optional)
Configuring OAM Cell Emulation for ATM AAL5 over MPLS, page 20 (optional)
Configuring OAM Cell Emulation for ATM AAL5 over MPLS on PVCs, page 21 (optional)
Configuring OAM Cell Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode,
page 23 (optional)
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 27 (optional)
Configuring ATM Cell Relay over MPLS in PVP Mode, page 28 (optional)
Configuring ATM Cell Relay over MPLS in Port Mode, page 30 (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 45 (optional)
Configuring Ethernet over MPLS in Port Mode, page 46 (optional)
Configuring Ethernet over MPLS with VLAN ID Rewrite, page 48 (optional)
Configuring per-Subinterface MTU for Ethernet over MPLS, page 52 (optional)
14
Configuring Frame Relay over MPLS with DLCI-to-DLCI Connections, page 54 (optional)
Configuring Frame Relay over MPLS with Port-to-Port Connections, page 55 (optional)
Configuring HDLC and PPP over MPLS, page 56 (optional)
Configuring Tunnel Selection, page 58 (optional)
Setting Experimental Bits with AToM, page 61 (optional)
Setting the Frame Relay Discard Eligibility Bit on the Cisco 7200 and 7500 Series Routers, page 65
(optional)
Matching the Frame Relay DE Bit on the Cisco 7200 and 7500 Series Routers, page 66 (optional)
Enabling the Control Word, page 66
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
For more information about the pseudowire-class command, see the following feature module: Layer 2
Tunnel Protocol Version 3.
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.
SUMMARY STEPS
1. enable
3. pseudowire-class name
4. encapsulation mpls
15
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-class)#
encapsulation mpls
Changing the Encapsulation Type and Removing a Pseudowire

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.
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 a pseudowire, use the clear xconnect command in privileged EXEC command. You can
remove all pseudowires or specific pseudowires on an interface or peer router.
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
16
a. interface typeslot/port
3. pvc [name] vpi/vci l2transport
4. encapsulation aal5
5. xconnect peer-router-id vcid encapsulation mpls
6. exit
7. exit
8. exit
9. show mpls l2transport vc
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface typeslot/port Specifies the interface by type, slot, and port number, and
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 that you specify the same encapsulation
Example: type on the PE and customer edge (CE) routers.
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
17
Example:
Step 9 exit Exits global configuration mode.
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 is sample output from the show mpls l2transport vc command, 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.
Restrictions
AAL5 over MPLS is supported only in SDU mode.
SUMMARY STEPS
1. enable
3. vc-class atm vc-class-name
4. encapsulation layer-type
5. exit
7. class-int vc-class-name
10. exit
18
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:
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
L2transport VC configuration mode.
Example:
19
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
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, 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)
20
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 21
Configuring OAM Cell Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode,
page 23
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.
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
21
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Step 5 encapsulation aal5 Specifies ATM AAL5 encapsulation for the PVC.
Make sure you specify the same encapsulation type
Example: on the PE and CE routers.
aal5
Example:
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
Example: which AIS cells are sent. The default is one cell
Router(config-if-atm-l2trans-pvc)# oam-ac every second. The 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
Router(config-if-atm-l2trans-pvc)# oam-pvc between transmission of loopback cells and ranges
manage from 0 to 600 seconds. The default value is
10 seconds.
Example:
22
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 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
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.
23
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
5. oam-ac emulation-enable [ais-rate]
6. oam-pvc manage [frequency]
7. exit
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
Example: which AIS cells are sent. The default is one cell
Router(config-vc-class)# oam-ac emulation-enable every second. The range is 0 to 60 seconds.
30
24
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
Router(config-vc-class)# oam-pvc manage between transmission of loopback cells and ranges
from 0 to 600 seconds. The default value is 10
seconds.
Example:
Example:
subinterface.
Router(config-if)# class-int oamclass
Example:
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 atmslot/port
4. pvc vpi/vci l2transport
7. exit
8. exit
9. exit
10. show atm vc
25
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface atmslot/port 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.
Example: Make sure you specify the same encapsulation type on
Router(config-if-atm-l2trans-pvc)# the PE and CE routers.
encapsulation aal0
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
26
Examples
The output of the 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.
SUMMARY STEPS
1. enable
5. exit
DETAILED STEPS

Example:
Router> enable
Example:
27
mode.
Example:
Router(config)# vc-class atm cellrelay
Example:
Example:
Example:
subinterface.
Router(config-if)# class-int cellrelay
Example:
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 ATM cell relay over MPLS 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. On the Cisco 12000 series
router, this is true only on the engine 0 ATM line cards.
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 atmslot/port Defines the interface and enters interface configuration mode.
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
Router(config-if)# atm pvp 1 l2transport relay. 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.
encapsulation mpls
The syntax for this command is the same as for all other
Layer 2 transports.
Example:
Router(config-if-atm-l2trans-pvp)#
xconnect 10.0.0.1 123 encapsulation mpls
Step 6 exit Exits L2 transport configuration mode.
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 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
Configuring ATM Cell Relay over MPLS 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 ATM cell relay over MPLS in port mode, use the following guidelines:
30
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.
Note The AToM control word is not supported for port mode cell relay on Cisco 7600 series routers.
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.
For the Cisco 7600 series routers, you must specify the interface ATM slot, bay, and port for the
SIP400 or SIP200.
SUMMARY STEPS
1. enable
or
interface atmslot/bay/port
5. exit
6. exit
7. show atm route
DETAILED STEPS

Example:
Router> enable
Example:
or configuration mode.
interface atmslot/bay/port For the Cisco 7600 series routers, you must specify
the interface ATM slot, bay, and port for the SIP400
Example: or SIP200. In the example the slot is 4, the bay is 3,
Router(config)# interface atm1/0 and the port is 0.
or
Router(config)# interface atm4/3/0
31
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 show atm route command in the following example displays port mode cell relay state. The
following example shows that atm interface 1/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 ATOM Tunnel 123 DOWN
The show mpls l2transport vc command in the following example also shows configuration
information:

------------- -------------------- --------------- ---------- ----------
AT1/0 ATM CELL ATM1/0 10.1.1.121 1121 UP
The debug atm l2transport and debug mpls l2transport vc display troubleshooting information.
32
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:
Step 4 pvc vpi/vci l2transport Assigns a VPI and VCI and enters L2transport VC
configuration mode.
Step 5 encapsulation aal0 Specifies raw cell encapsulation for the interface.
Make sure you specify the same encapsulation type
Example: on the PE and CE routers.
aal0
Example:
33
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.
See the following sections for configuration information:
Configuring ATM Packed Cell Relay over MPLS in VC Mode, page 34
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 40
Configuring ATM Packed Cell Relay over MPLS in Port Mode, page 42
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
34
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:
Step 3 interface atmslot/port Defines the interface and enters interface 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
Router(config-if)# atm mcpt-timers 100 200 250 specify 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 timeouts 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:
Step 7 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 8 encapsulation aal0 Specifies raw cell encapsulation for the interface.
Make sure you specify the same encapsulation type on
Example: the PE routers.
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
10 mcpt-timer 1 from 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.
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.
SUMMARY STEPS
1. enable
6. exit
8. shutdown
37
10. no shutdown
DETAILED STEPS

Example:
Router> enable
Example:
mode.
Example:
Router(config)# vc-class atm cellpacking
Example:
parameters.
Example: The cells argument represents the maximum number
Router(config-vc-class)# cell-packing 10 of cells to be packed into an MPLS packet. The
mcpt-timer 1 range is from 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.
information.
Example:
Example:
38
Example:
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.
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 timeouts default and range of
acceptable values depends on the ATM link speed.
adapters are:
You can specify either the number of microseconds
or use the default.
adapters are:
Example:
subinterface.
Router(config-if)# class-int cellpacking
Example:
39
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
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface atmslot/port Defines the interface and enters interface configuration mode.
Example:
Example:
40

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 timeouts default and range of
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:
enters L2transport PVP configuration submode.
Router(config-if)# atm pvp 1 l2transport relay. This submode is for Layer 2 transport only; it is not for
regular PVPs.
encapsulation mpls
Layer 2 transports.
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
Example: to be packed into an MPLS packet. The range is from 2 to the
Router(cfg-if-atm-l2trans-pvp)# MTU of the interface divided by 52. The default is MTU/52.
cell-packing 10 mcpt-timer 1
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.
41
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
10. exit
11. show atm cell-packing
12. show atm vp
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example:
Example:
42
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.
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 timeouts default and range of
adapters are:
You can specify either the number of microseconds
or use the default.
adapters are:
Example:
parameters.
Example: The cells argument represents the maximum number
Router(config-if)# cell-packing 10 mcpt-timer 1 of 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.
The timer argument allows you to specify which
timer to use. The default is timer 1.
information.
Step 8 xconnect peer-router-id vcid encapsulation mpls Binds the attachment circuit to the interface.
Example:
encapsulation mpls
Example:
43
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 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 vc 1/200 20 15 30 20 60
atm 1/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 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.
44
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/interface.subinterface
4. encapsulation dot1q vlan-id
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface gigabitethernet Specifies the Gigabit Ethernet subinterface and enters
slot/interface.subinterface subinterface configuration mode.
Make sure the subinterface on the adjoining CE
Example: router is on the same VLAN as this PE router.
Router(config)# interface gigabitethernet4/0.1
45
Step 4 encapsulation dot1q vlan-id Enables the subinterface to accept 802.1Q VLAN
packets.
Example: The subinterfaces between the CE and PE routers
Router(config-subif)# encapsulation dot1q 100 that are running Ethernet over MPLS must be in the
same subnet. All other subinterfaces and backbone
routers do not.
The syntax for this command is the same as for all
Example: other Layer 2 transports.
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.
SUMMARY STEPS
1. enable
3. interface gigabitethernetslot/interface
5. exit
6. exit
46
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface gigabitethernetslot/interface Specifies the Gigabit Ethernet interface and enters interface
configuration mode.
Example: Make sure the interface on the adjoining CE router is on the
Router(config)# interface same VLAN as this PE router.
gigabitethernet4/0
encapsulation mpls
Layer 2 transports.
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:
Examples
In the following example, the output of the show mpls l2transport vc detail command is displayed:
Router# show mpls l2transport vc detail
Local interface: Gi4/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
47
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.
The Cisco 12000 series router requires you to configure VLAN ID rewrite manually, as described in the
following sections.
The following routers automatically perform VLAN ID rewrite on the disposition PE router. No
configuration is required:
Cisco 7200 series routers.
Routers supported on Cisco IOS Release 12.4(11)T. (Use Cisco Feature Navigator to find
information about platform support and Cisco IOS and Catalyst OS software image support.)
The following sections explain how to configure the VLAN ID rewrite feature:
Guidelines for Configuring Ethernet over MPLS with VLAN ID Rewrite for the Cisco 12000 Series
Routers for Cisco IOS Releases 12.0(29)S and Earlier Releases, page 48
Configuring Ethernet over MPLS with VLAN ID Rewrite for the Cisco 12000 Series Routers for
Cisco IOS Releases 12.0(30)S and Later Releases, page 49
Guidelines for Configuring Ethernet over MPLS with VLAN ID Rewrite for the Cisco 12000 Series
Routers for Cisco IOS Releases 12.0(29)S and Earlier Releases
Use the following guidelines for the VLAN ID rewrite feature for the Cisco 12000 series routers in
Cisco IOS releases earlier than 12.0(29)S:
The IP Service Engine (ISE) 4-port Gigabit Ethernet line card performs the VLAN ID rewrite on the
disposition side at the edge-facing line card.
The engine 2 3-port Gigabit Ethernet line card performs the VLAN ID rewrite on the imposition side
at the edge-facing line card.
The VLAN ID rewrite functionality requires that both ends of the Ethernet over MPLS connections be
provisioned with the same line cards. Make sure that both edge-facing ends of the virtual circuit use
either the engine 2 or ISE Ethernet line card. The following example shows the system flow with the
VLAN ID rewrite feature:
The ISE 4-port Gigabit Ethernet line card:
Traffic flows from VLAN1 on CE1 to VLAN2 on CE2. As the frame reaches the edge-facing line
card of the disposition router PE2, the VLAN ID in the dot1Q header changes to the VLAN ID
assigned to VLAN2.
The engine 2 3-port Gigabit Ethernet line card:
Traffic flows from VLAN1 on CE1 to VLAN2 on CE2. As the frame reaches the edge-facing line
card of the imposition router PE1, the VLAN ID in the dot1Q header changes to the VLAN ID
assigned to VLAN2.
For the Cisco 12000 series router engine 2 3-port Gigabit Ethernet line card, you must issue the remote
circuit id command as part of the Ethernet over MPLS VLAN ID rewrite configuration.
48
Configuring Ethernet over MPLS with VLAN ID Rewrite for the Cisco 12000 Series Routers for
Cisco IOS Releases 12.0(30)S and Later Releases
In Cisco IOS Release 12.0(30)S, the following changes to VLAN ID rewrite were implemented:
The ISE 4-port Gigabit Ethernet line card can perform VLAN ID rewrite at both the imposition and
disposition sides of the edge-facing router.
The remote circuit id command is not required as part of the Ethernet over MPLS VLAN ID rewrite
configuration, as long as both PE routers are running Cisco IOS Release 12.0(30)S. The VLAN ID
rewrite feature is implemented automatically when you configure Ethernet over MPLS.
The VLAN ID rewrite feature in Cisco IOS Release 12.0(30)S can interoperate with routers that are
running earlier releases. If you have a PE router at one end of the circuit that is using an earlier
Cisco IOS release and the remote circuit id command, the other PE can run Cisco IOS
Release 12.0(30)S and still perform VLAN ID rewrite.
You can mix the line cards on the PE routers, as shown in the following table
Table 6 Supported Line Cards for VLAN ID Rewrite Feature:
If PE1 Has These Line Cards Then PE2 Can Use These Line Cards
Engine 2 3-port Gigabit Ethernet line card Engine 2 3-port Gigabit Ethernet line card
or or
ISE 4-port Gigabit Ethernet line card ISE 4-port Gigabit Ethernet line card
ISE 4-port Gigabit Ethernet line card Any Cisco 12000 series router line card
SUMMARY STEPS
1. enable
3. interface gigabitethernet slot/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:
Step 3 interface Specifies the Gigabit Ethernet subinterface and enters
gigabitethernetslot/interface.subinterface subinterface configuration mode.
Make sure the subinterfaces between the CE and PE
Example: routers that are running Ethernet over MPLS are in
Router(config)# interface gigabitethernet4/0.1 the 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(config-subif)# encapsulation dot1q 100 router is 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.
Example: The syntax for this command is the same as for all
Router(config-subif)# xconnect 10.0.0.1 123 other Layer 2 transports.
encapsulation mpls
Step 6 remote circuit id remote-vlan-id Enables you to use VLAN interfaces with different
VLAN IDs at both ends of the tunnel.
Example: This command is required only for the Cisco 12000
Router(config-subif-xconn)# remote circuit id series router engine 2 3-port Gigabit Ethernet line
101 card.
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 command output of the show controllers eompls forwarding-table command in the following
example shows VLAN ID rewrite configured on the Cisco 12000 series routers 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
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
51
Configuring per-Subinterface MTU for Ethernet over MPLS

Cisco IOS Release 12.2(33)SRC introduces 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.
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
The MTU value can be configured in xconnect subinterface configuration mode only on the
following interfaces and subinterfaces:
Ethernet
FastEthernet
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
3. interface gigabitethernet slot/interface
4. mtu mtu-value
5. interface gigabitethernet slot/interface.subinterface
52
8. mtu mtu-value
9. end
10. show mpls l2transport binding
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface gigabitethernet slot/interface Specifies the Gigabit Ethernet interface and enters interface
configuration mode.
Example:
Router(config)# interface gigabitethernet4/0
Step 4 mtu mtu-value Specifies the MTU value for the interface.
The MTU value specified at the interface level can be
Example: inherited by a subinterface.
Step 5 interface gigabitethernet slot Specifies the Gigabit Ethernet subinterface and enters
/interface.subinterface subinterface configuration mode.
Make sure the subinterface on the adjoining CE router
Example: is on the same VLAN as this PE router.
Router(config-if)# interface
gigabitethernet4/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
Example: are running Ethernet over MPLS must be in the same
Router(config-subif)# encapsulation dot1q 100 subnet. All other subinterfaces and backbone routers
need not be.
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
53

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.
SUMMARY STEPS
1. enable
3. frame-relay switching
4. interface serialslot/port
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:
54

Step 3 frame-relay switching Enables PVC switching on a Frame Relay device.
Example:
Router(config)# frame-relay switching
Step 4 interface serialslot/port Specifies a serial interface and enters interface configuration
mode.
Example:
Router(config)# interface serial3/1
Step 5 encapsulation frame-relay [cisco | ietf] Specifies Frame Relay encapsulation for the interface.
You can specify different types of encapsulations. You can set
Example: one interface to Cisco encapsulation and the other interface to
Router(config-if)# encapsulation IETF 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
Example: Network-to-Network Interface (NNI) and DTE connections.
Router(config-if)# frame-relay intf-type
dce
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
Example: not be a locally switched PVC, but will be tunneled over the
Router(config)# connect fr1 serial5/0 backbone network.
1000 l2transport
The connection-name argument is a text string that you
provide.
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.
encapsulation mpls
In a DLCI-to DLCI connection type, Frame Relay over MPLS
uses the xconnect command in connect configuration
Example: submode.
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
55
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
DETAILED STEPS

Example:
Router> enable
Example:
mode.
Example:
Router(config)# interface serial5/0
Step 4 encapsulation hdlc Specifies that Frame Relay PDUs will be encapsulated in HDLC
packets.
Example:
Router(config-if)# encapsulation hdlc
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.
56
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.
You must configure PPP on router interfaces only. You cannot configure PPP on subinterfaces.
SUMMARY STEPS
1. enable
4. encapsulation encapsulation-type
DETAILED STEPS

Example:
Router> enable
Example:
mode.
Example: You must configure HDLC and PPP over MPLS on router
Router(config)# interface serial5/0 interfaces only. You cannot configure HDLC over MPLS on
subinterfaces.
57

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
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
58
5. preferred-path {interface tunnel tunnel-number | peer {ip-address | host-name}}

[disable-fallback]
6. exit
7. interface slot/port
8. encapsulation encapsulation-type
9. xconnect peer-router-id vcid pw-class name
DETAILED STEPS

Example:
Router> enable
Example:
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
For AToM, the encapsulation type is mpls.
Example:
encapsulation mpls
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-class)# preferred
path peer 10.18.18.18
Step 6 exit Exits from pseudowire configuration mode.
Example:
Router(config-pw-class)# exit
Step 7 interface slot/port Specifies an interface and enters interface configuration mode.
Example:
59

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
Examples
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.
Local interface: Gi0/0/0.1 up, line protocol up, Eth VLAN 222 up
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: AT1/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:
60

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: Et3/2
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.
Note For information about setting EXP bits on the Cisco 12000 series router for Cisco IOS
Release 12.0(30)S, see the AToM: L2 QoS feature module.
For configuration steps and examples, see the Setting Experimental Bits with AToM section on
page 61.
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 headers tag control
information field are set to zero.
On the Cisco 7500 series routers, distributed Cisco Express Forwarding must be enabled before you
set the experimental bits.
The following restrictions apply to ATM Cell Relay over MPLS with EXP bits:
ATM Cell Relay over MPLS 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 headers tag control
The following restrictions apply to Ethernet over MPLS with EXP bits:
On the Cisco 7200 and 7500 Series Routers

Ethernet over MPLS allows you to set the EXP bits by using either of the following methods:
61
Writing the priority bits into the experimental bit field, which is the default.
Using the match any command with the set mpls exp command.
If you do not assign values to the experimental bits, the priority bits in the 802.1Q headers tag
control information field are written into the experimental bit fields.
On the Cisco 10720 Internet Router

Table 7 lists the commands that are supported on the Cisco 10720 Internet router for Ethernet over
MPLS. The letter Y means that the command is supported on that interface. A dash () means that
command is not supported on that interface.
Note The match cos command is supported only on subinterfaces, not main interfaces.
Table 7 Commands Supported on the Cisco 10720 Router for Ethernet over MPLS
Commands Imposition Disposition

Traffic Matching Commands In Out In Out
match any Y Y Y Y
match cos Y
match input-interface Y Y
match mpls exp Y Y
match qos-group Y Y
Traffic Action Commands In Out In Out
set cos Y
set mpls exp Y
set qos-group Y Y
set srp-priority Y
The following restrictions apply to 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
The following restrictions apply to 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.
On the Cisco 7500 series routers, enable distributed Cisco Express Forwarding before setting the
experimental bits.
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.
62
SUMMARY STEPS
1. enable
3. class-map class-name
4. match any
5. exit
6. policy-map policy-name
7. class class-name
8. set mpls experimental value
9. exit
10. exit
11. interface slot/port
12. service-policy input policy-name
13. exit
14. exit
15. show policy-map interface interface-name [vc [vpi/] vci] [dlci dlci] [input | output]
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
Example: unexpected results.
Router(config-cmap)# match any
Step 5 exit Exits class map configuration mode.
Example:
Router(config-cmap)# exit
63

Step 6 policy-map policy-name Specifies the name of the traffic policy to configure and
enters policy-map configuration mode.
Example:
Router(config)# policy-map policy1
Step 7 class class-name Specifies the name of the predefined traffic that was
configured with the class-map command and was used to
classify traffic to the traffic policy specified, and enters
Example:
Router(config-pmap)# class class1
policy-map class configuration mode.
Step 8 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 9 exit Exits policy-map class configuration mode.
Example:
Router(config-pmap-c)# exit
Step 10 exit Exits policy-map configuration mode.
Example:
Router(config-pmap)# exit
Step 11 interface slot/port Specifies the interface and enters interface configuration
mode.
Example:
Step 12 service-policy input policy-name Attaches a traffic policy to an interface.
Example:
Router(config-if)# service-policy input
policy1
Example:
Example:
Step 15 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
64
Setting the Frame Relay Discard Eligibility Bit on the Cisco 7200 and 7500 Series
Routers
You can use the DE bit in the address field of a Frame Relay frame to prioritize frames in congested
Frame Relay networks. The Frame Relay DE bit has only one bit and can therefore only have two
settings, 0 or 1. If congestion occurs in a Frame Relay network, frames with the DE bit set to 1 are
discarded before frames with the DE bit set to 0. Therefore, important traffic should have the DE bit set
to 0, and less important traffic should be forwarded with the DE bit set at 1. The default DE bit setting
is 0. You can change the DE bit setting to 1 with the set fr-de command.
Note The set fr-de command can be used only in an output service policy.
Perform this task to set the Frame Relay DE bit on the Cisco 7200 and 7500 series routers.
SUMMARY STEPS
1. enable
3. policy-map policy-name
4. class class-name
5. set fr-de
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 policy-map policy-name Specifies the name of the traffic policy to configure and enters
policy-map configuration mode.
Example: Names can be a maximum of 40 alphanumeric characters.
Router(config)# policy-map policy1
Step 4 class class-name Specifies the name of a predefined traffic class and enters
policy-map class configuration mode.
Example:
Router(config-pmap)# class class1
Step 5 set fr-de Sets the Frame Relay DE bit setting for all packets that match the
specified traffic class from 0 to 1.
Example:
Router(config-pmap-c)# set fr-de
65
Matching the Frame Relay DE Bit on the Cisco 7200 and 7500 Series Routers
You can use the match fr-de command to enable frames with a DE bit setting of 1 to be considered a
member of a defined class and forwarded according to the specifications set in the service policy.
Perform this task to match frames with the FR DE bit set to 1.
SUMMARY STEPS
1. enable
3. class-map class-map-name
4. match fr-de
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 class-map class-map-name Specifies the name of a predefined traffic class and enters
class-map configuration mode.
Example:
Router(config)# class-map de-bits
Step 4 match fr-de Classifies all frames with the DE bit set to 1.
Example:
Router(config-cmap)# match fr-de
Enabling the Control Word

You can enable the control word for dynamic and static pseudowires under a pseudowire class. Use the
control-word command to enable, disable, or set a control word to autosense mode. If you do not enable
a control word, autosense is the default mode for the control word.
Perform this task to enable a control word.
SUMMARY STEPS
1. enable
3. pseudowire-class cw_enable
66
Configuration Examples for Any Transport over MPLS
5. control-word
6. exit
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class cw_enable Enters pseudowire class configuration mode.
Example:
Router(config)# pseudowire-class
cw_enable
Example:
encapsulation mpls
Step 5 control-word Enables the control word.
Example:
Router(config-pw-class)# control-word
Step 6 exit Exits pseudowire class configuration mode and returns to global
configuration mode.
Example:
Example:

ATM AAL5 over MPLS: Examples, page 68
OAM Cell Emulation for ATM AAL5 over MPLS: Examples, page 69
67
ATM Cell Relay over MPLS: Examples, page 70

ATM Single Cell Relay over MPLS: Examples, page 71e
Ethernet over MPLS: Examples, page 72
Configuring per-Subinterface MTU for Ethernet over MPLS: Example, page 79
Tunnel Selection: Examples, page 72
Setting Frame Relay Discard Eligibility Bit on the Cisco 7200 and 7500 Series Routers: Examples,
page 74
Matching Frame Relay DE Bit on the Cisco 7200 and 7500 Series Routers: Examples, page 75
ATM over MPLS: Examples, page 75
Ethernet over MPLS with MPLS Traffic Engineering Fast Reroute: Examples, page 76
Configuring per-Subinterface MTU for Ethernet over MPLS: Example, page 79
Configuring MTU Values in xconnect Configuration Mode for L2VPN Interworking: Example,
page 81
Removing a Pseudowire: Examples, page 84
ATM AAL5 over MPLS: Examples

ATM AAL5 over MPLS on PVCs
The following example enables ATM AAL5 over MPLS on an ATM PVC:
enable
configure terminal
interface atm1/0
pvc 1/200 l2transport
encapsulation aal5
ATM AAL5 over MPLS in VC Class Configuration Mode

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
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
class-vc aal5class
68
OAM Cell Emulation for ATM AAL5 over MPLS: Examples

OAM Cell Emulation for ATM AAL5 over MPLS on PVCs
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
OAM Cell Emulation for ATM AAL5 over MPLS in VC Class Configuration Mode
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
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
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
class-int oamclass
69

ATM Cell Relay over MPLS: Examples

ATM Cell Relay over MPLS in VC Mode Using VC Class Configuration Mode
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
class-int cellrelay
enable
configure terminal
vc-class atm cellrelay
encapsulation aal0
interface atm1/0
class-vc cellrelay
ATM Cell Relay over MPLS in PVP Mode

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
ATM Cell Relay over MPLS in Port Mode

The following example shows interface ATM 5/0 configured to transport ATM cell relay packets:
pseudowire-class atm-cell-relay
encapsulation mpls
interface atm 5/0
xconnect 10.0.0.1 123 pw-class atm-cell-relay
The following example shows interface ATM 9/0/0 configured to transport ATM cell relay packets on a
Cisco 7600 series router, where you must specify the interface ATM slot, bay, and port:
pseudowire-class atm-cell-relay
encapsulation mpls
interface atm 9/0/0
xconnect 10.0.0.1 500 pw-class atm-cell-relay
70
ATM Single Cell Relay over MPLS: Examples

ATM Packed Cell Relay over MPLS in VC Mode
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
shutdown
atm mcpt-timer 1000 800 500
no shutdown
encapsulation aal0
ATM Packed Cell Relay over MPLS in VC Mode Using VC Class Configuration Mode
The following example configures ATM cell relay over MPLS 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
shutdown
atm mcpt-timers 100 200 250
no shutdown
class-int cellpacking
enable
configure terminal
vc-class atm cellpacking
encapsulation aal0
interface atm1/0
shutdown
atm mcpt-timers 100 200 250
no shutdown
class-vc cellpacking
ATM Packed Cell Relay over MPLS in VP Mode

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
71

ATM Packed Cell Relay over MPLS in Port Mode

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
shutdown
no shutdown
Ethernet over MPLS: Examples

Ethernet over MPLS in Port Mode
The following example configures VC 123 in Ethernet port mode:
pseudowire-class ethernet-port
encapsulation mpls
int gigabitethernet1/0
xconnect 10.0.0.1 123 pw-class ethernet-port
Ethernet over MPLS with VLAN ID Rewrite

The following example configures VLAN ID rewrite on peer PE routers with Cisco 12000 series router
engine 2 3-port Gigabit Ethernet line cards.
PE1 PE2
interface GigabitEthernet0/0.2 interface GigabitEthernet3/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
Tunnel Selection: 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
72
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
tag-switching ip
ip rsvp bandwidth 15000 15000
!
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
73
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 Ethernet3/3.1
no cdp enable
mpls l2transport route 10.2.2.2 101
!
interface ATM5/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
Setting Frame Relay Discard Eligibility Bit on the Cisco 7200 and 7500 Series
Routers: Examples
The following example shows how to configure the service policy called set-de and attach it to an
interface. In this example, the class map called data evaluates all packets exiting the interface for an IP
precedence value of 1. If the exiting packet has been marked with the IP precedence value of 1, the
packets DE bit is set to 1.
class-map data
match ip precedence 1
policy-map set-de
74
class data
set fr-de
interface Serial0/0/0
encapsulation frame-relay
interface Serial0/0/0.1 point-to-point
ip address 192.168.249.194 255.255.255.252
frame-relay interface-dlci 100
service output set-de
Matching Frame Relay DE Bit on the Cisco 7200 and 7500 Series Routers:
Examples
The following example shows how to configure the service policy called match-de and attach it to an
interface. In this example, the class map called data evaluates all packets entering the interface for a DE
bit setting of 1. If the entering packet has been a DE bit value of 1, the packets EXP bit setting is set to 3.
class-map data
match fr-de
policy-map match-de
class data
set mpls exp 3
ip routing
ip cef distributed
interface Loopback0
ip address 10.20.20.20 255.255.255.255
ip address 10.0.0.2 255.255.255.0
mpls ip
service input match-de
connect 100 Serial4/0/0 100 l2transport
ATM over MPLS: Examples

Example 1 shows the configuration of ATM over MPLS on two PE routers.
75
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 interface ATM4/0
pvc 0/100 l2transport pvc 0/100 l2transport
encapsulation aal0 encapsulation aal0
! !
interface ATM4/0.300 point-to-point interface ATM4/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
Ethernet over MPLS with MPLS Traffic Engineering Fast Reroute: Examples
The following configuration example and Figure 2 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 2 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
mpls ldp router-id Loopback1 force
!
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
76
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
!
interface POS0/0
description pe1name POS8/0/0
ip address 10.1.0.2 255.255.255.252
crc 16
pos ais-shut
pos report lrdi
!
interface POS0/3
description pe1name POS10/1/0
ip address 10.1.0.14 255.255.255.252
crc 16
!
interface gigabitethernet3/0.1
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
77
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
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
!
interface FastEthernet0/0.2
!
!
interface FastEthernet1/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
78

!
ip explicit-path name xxxx-1 enable
Configuring per-Subinterface MTU for Ethernet over MPLS: Example

Figure 3 shows a configuration that enables matching MTU values between VC endpoints.
As shown in Figure 3, 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.
Figure 3 Configuring MTU Values in xconnect Subinterface Configuration Mode
CE1 PE1 PE2 CE2

MPLS Core
MTU 2000 Bytes
231561
subinterface g0/0.1 subinterface g0/0.2 interface g1/0 subinterface f0/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 3:
CE1 Configuration
interface gigabitethernet0/0
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
79
PE2 Configuration
mtu 2000
no ip address
!
ip address 10.100.152.2 255.255.255.0
mpls ip
!
interface fastethernet0/0
no ip address
!
interface fastethernet0/0.1
description default MTU of 1500 for FastEthernet
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: Ethernet, 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]
Local interface: Gi0/0.1 up, line protocol up, Eth VLAN 100 up
Output interface: Gi0/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:
80
In the following example, you are specifying 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)# interface gigabitethernet0/2.1
router(config-subif)# xconnect 10.10.10.1 100 encapsulation mpls
router(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)# interface gigabitethernet0/2.1
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
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
!
interface Loopback0
ip address 10.1.1.151 255.255.255.255
!
interface Serial2/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
!
interface Serial4/0
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
81
!
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
!
interface Serial4/0
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 Configuration

Local Label: 105
Cbit: 1, VC Type: PPP, GroupID: 0
CV Type: LSPV [2]
Remote Label: 205
CV Type: LSPV [2]
Local interface: Se2/0 up, line protocol up, PPP up

MPLS VC type is PPP, interworking type is IP
Output interface: Se4/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
82
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 Configuration

Local Label: 205
CV Type: LSPV [2]
Remote Label: 105
CV Type: LSPV [2]
Local interface: Et0/0 up, line protocol up, Ethernet up

MPLS VC type is Ethernet, interworking type is IP
Output interface: Se4/0, imposed label stack {1002 105}
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:
83
Removing a Pseudowire: Examples

The following example removes all xconnects:
Router# clear xconnect all
02:13:56: Xconnect[ac:Et1/0.1(Eth VLAN)]: provisioning fwder with fwd_type=1, sss_role=1

02:13:56: Xconnect[mpls:10.1.1.2:1234000]: provisioning fwder with fwd_type=2, sss_role=2
02:13:56: MPLS peer 10.1.1.2 vcid 1234000, VC DOWN, VC state DOWN
02:13:56: XC AUTH [Et1/0.1, 1001]: Event: start xconnect authorization, state changed from
IDLE to AUTHORIZING
02:13:56: XC AUTH [Et1/0.1, 1001]: Event: found xconnect authorization, state changed from
AUTHORIZING to DONE
IDLE to AUTHORIZING
AUTHORIZING to DONE
02:13:56: XC AUTH [10.1.1.2, 1234001]: Event: start xconnect authorization, state changed
from IDLE to AUTHORIZING
02:13:56: XC AUTH [10.1.1.2, 1234001]: Event: found xconnect authorization, state changed
from AUTHORIZING to DONE
02:13:56: XC AUTH [Et1/0.1, 1001]: Event: free xconnect authorization request, state
changed from DONE to END
02:13:56: XC AUTH [10.1.1.2, 1234001]: Event: free xconnect authorization request, state
02:13:56: MPLS peer 10.1.1.2 vcid 1234001, VC UP, VC state UP
The following example removes all the xconnects associated with peer router 10.1.1.2:
Router# clear xconnect peer 10.1.1.2 all

IDLE to AUTHORIZING
AUTHORIZING to DONE
84
The following example removes the xconnects associated with peer router 10.1.1.2 and VC ID 1234001:
Router# clear xconnect peer 10.1.1.2 vcid 1234001

IDLE to AUTHORIZING
AUTHORIZING to DONE
The following example removes the xconnects associated with interface Ethernet 1/0.1:
Router# clear xconnect interface eth1/0.1

The following sections provide references related to the Any Transport over MPLS feature.
Related Documents
Cisco IOS commands Cisco IOS Master Commands List, All Releases
MPLS commands Cisco IOS Multiprotocol Label Switching Command
Reference
Any Transport over MPLS Overview section of Cisco Any Transport over MPLS
Any Transport over MPLS for the Cisco 10000 series router Cisco 10000 Series Router Broadband Aggregation,
Leased-Line, and MPLS Configuration Guide
Layer 2 Tunnel Protocol Version 3 (L2TPv3) Layer 2 Tunnel Protocol Version 3 (L2TPv3)
L2VPN interworking L2VPN Interworking
85
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
MIBs
MIB MIBs Link
ATM AAL5 over MPLS and ATM Cell Relay over To locate and download MIBs for selected platforms, Cisco IOS
MPLS: releases, and feature sets, use Cisco MIB Locator found at the
MPLS LDP MIB (MPLS-LDP-MIB.my) following URL:
ATM MIB (ATM-MIB.my) http://tools.cisco.com/go/mibs
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
86
Description Link
The Cisco Support website provides extensive online http://www.cisco.com/cisco/web/support/index.html
87
Feature Information for Any Transport over MPLS

88
Table 8 Feature Information for Any Transport over MPLS

Any 12.0(10)ST In Cisco IOS Release 12.0(10)ST, Any Transport over MPLS: ATM AAL5 over MPLS
Transport 12.1(8a)E was introduced on the Cisco 12000 series routers.
over MPLS 12.0(21)ST
In Cisco IOS Release 12.1(8a)E, Ethernet over MPLS was introduced on the Cisco 7600
12.0(22)S
series Internet router.
12.0(23)S
12.2(14)S In Cisco IOS Release 12.0(21)ST, Any Transport over MPLS: Ethernet over MPLS was
12.2(15)T introduced on the Cisco 12000 series routers. ATM AAL5 over MPLS was updated.
12.0(25)S In Cisco IOS Release 12.0(22)S, Ethernet over MPLS was integrated into this release.
12.0(26)S Support for the Cisco 10720 Internet router was added. ATM AAL5 over MPLS was
12.0(27)S integrated into this release for the Cisco 12000 series routers.
12.2(25)S
12.0(29)S In Cisco IOS Release 12.0(23)S, the following new features were introduced and support
12.0(30)S was added for them on the Cisco 7200 and 7500 series routers:
12.0(31)S ATM Cell Relay over MPLS (single cell relay, VC mode)
12.0(32)S
12.2(28)SB
12.4(11)T HDLC over MPLS
12.2(33)SRB PPP over MPLS
12.2(33)SXH
12.2(33)SRC Cisco IOS Release 12.0(23)S also added support on the Cisco 12000, 7200, and 7500
12.2(33)SRD series routers for the following features:
12.2(1)SRE ATM AAL5 over MPLS
Ethernet over MPLS (VLAN mode)
The AToM features were integrated into Cisco IOS Release 12.2(14)S.
The AToM features were integrated into Cisco IOS Release 12.2(15)T.
In Cisco IOS Release 12.0(25)S, the following new features were introduced:
New commands for configuring AToM
Ethernet over MPLS: port mode
ATM Cell Relay over MPLS: packed cell relay
ATM Cell Relay over MPLS: VP mode
ATM Cell Relay over MPLS: port mode
Distributed Cisco Express Forwarding mode for Frame Relay, PPP, and HDLC over
MPLS
Fast reroute with AToM
Tunnel selection
Traffic policing
QoS support
89
Table 8 Feature Information for Any Transport over MPLS (continued)

Support for connecting disparate attachment circuits. See L2VPN Interworking for
more information.
QoS functionality with AToM for the Cisco 7200 series routers.
Support for FECN and BECN marking with Frame Relay over MPLS. (See BECN and
FECN Marking for Frame Relay over MPLS for more information.)
ATM Cell Relay over MPLS: Packed Cell Relay for VC, PVP, and port mode for the
Support for ATM over MPLS on the Cisco 12000 series 4-port OC-12X/STM-4 ATM
ISE line card.
This feature was integrated into Cisco IOS Release 12.2(25)S for the Cisco 7200 and
7500 series routers.
In Cisco IOS Release 12.0(29)S, the Any Transport over MPLS Sequencing Support
feature was added for the Cisco 7200 and 7500 series routers. See the Any Transport over
MPLS (AToM) Sequencing Support document for more information.
ATM VC Class SupportYou can specify AAL5 and AAL0 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. See the How
to Configure Any Transport over MPLS section on page 14 for links to the sections
that explain the ATM VC Class Support feature.
VLAN ID RewriteThis feature was enhanced to enable the IP Service Engine
(ISE) 4-port Gigabit Ethernet line card to perform VLAN ID rewrite at both the
imposition and disposition sides of the edge-facing router. See the Configuring
Ethernet over MPLS with VLAN ID Rewrite section on page 48 for more
information.
In Cisco IOS Release 12.0(31)S, the Cisco 12000 series router introduced the following
enhancements:
AToM VC IndependenceWith this enhancement, fast reroute is accomplished in
less than 50 milliseconds, regardless of the number of VCs configured. See the
MPLS Traffic Engineering Fast Reroute section on page 6 for more information.
Support for ISE line cards on the 2.5G ISE SPA Interface Processor (SIP).
In Cisco IOS Release 12.0(32)S, the Cisco 12000 series router added engine 5 line card
support for the following transport types:
Ethernet over MPLS
HDLC over MPLS
PPP over MPLS
90

This feature was integrated into Cisco IOS Release 12.2(28)SB on the Cisco 10000 series
routers. Platform-specific configuration information is contained in the Configuring
Any Transport over MPLS section of the Cisco 10000 Series Router Broadband
Aggregation, Leased-Line, and MPLS Configuration Guide.
Any Transport over MPLS was integrated into Cisco IOS Release 12.4(11)T with support
for the following features:
Any Transport over MPLS: Ethernet over MPLS: Port Mode
Any Transport over MPLS: Ethernet over MPLS: VLAN Mode
Any Transport over MPLS: Ethernet over MPLS: VLAN ID Rewrite
Any Transport over MPLS: Frame Relay over MPLS
Any Transport over MPLS: AAL5 over MPLS
Any Transport over MPLS: ATM OAM Emulation
AToM Tunnel Selection was introduced into this release on the Cisco 7600 router.
This feature was integrated into Cisco IOS Release 12.2(33)SRB to support the following
features on the Cisco 7600 router:
Any Transport over MPLS: Frame Relay over MPLS
Any Transport over MPLS: ATM Cell Relay over MPLS: Packed Cell Relay
Any Transport over MPLS: Ethernet over MPLS
AToM Static Pseudowire Provisioning
Platform-specific configuration information is contained in the following documents:
The Configuring PFC3BXL and PFC3B Mode Multiprotocol Label Switching
module of the Cisco 7600 Series Cisco IOS Software Configuration Guide, Release
12.2SR
The Configuring Multiprotocol Label Switching on the Optical Services Modules
module of the OSM Configuration Note, Release 12.2SR
The Configuring Multiprotocol Label Switching on FlexWAN and Enhanced
FlexWAN Modules module of the FlexWAN and Enhanced FlexWAN Modules
Configuration Guide
The Configuring Any Transport over MPLS on a SIP section of the Cisco 7600
Series Router SIP, SSC, and SPA Software Configuration Guide
The Configuring AToM VP Cell Mode Relay Support section of the Cisco 7600
Series Router SIP, SSC, and SPA Software Configuration Guide
The Cross-Platform Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600
Series Routers
91

This feature was integrated into Cisco IOS Release 12.2(33)SXH and supports the
following features:
Any Transport over MPLS: Ethernet over MPLS: Port Mode
Any Transport over MPLS: ATM OAM Emulation
Any Transport over MPLS: Single Cell RelayVC Mode
Any Transport over MPLS: ATM Cell Relay over MPLSVP Mode
Any Transport over MPLS: Packed Cell RelayVC/VP Mode
Any Transport over MPLS: Ethernet over MPLS
ATM Port Mode Packed Cell Relay over AToM
AToM Tunnel Selection
The following features were integrated into Cisco IOS Release 12.2(33)SRC:
AToM Tunnel Selection for the Cisco 7200 and Cisco 7300 routers
Per-Subinterface MTU for Ethernet over MPLS (EoMPLS)
In Cisco IOS Release 12.2(33)SRD, support for ATM Cell Relay over MPLS in port
mode on Cisco 7600 series routers was added.
In Cisco IOS Release 12.2(1)SRE, support for control word on dynamic pseudowires
was added. The clear xconnect command was introduced.
The following commands were introduced or modified by this feature: cell-packing,
control-word, encapsulation (Any Transport over MPLS), oam-ac
emulation-enable.
coincidental.
92
MPLS MTU Command Changes

This document explains the change in behavior of the mpls mtu command for the following Cisco IOS
releases:
12.2(27)SBC and later
12.2(33)SRA and later
12.4(11)T and later
12.2(33)SXH and later
You cannot set the MPLS MTU value larger than the interface MTU value. This eliminates problems,
such as dropped packets, data corruption, and high CPU rates from occurring when MPLS MTU value
settings are larger than interface MTU values. Cisco IOS software allows the MPLS MTU value to be
higher than the interface MTU value only for interfaces that have a default interface MTU value of 1580
or less.
Note In Cisco IOS Release 15.0(1)M1, you can configure the interface MTU on PA-1FE and PA-2FE port
adapters (PAs). The range of values is 1500 -1530. Before this enhancement, the MTU of those interfaces
was not configurable. When you attempted to configure the interface MTU, the following message was
displayed:
% Interface {Interface Name} does not support user settable mtu.

supported, use the Feature Information for MPLS MTU Command Changes section on page 8.

Contents
Contents
Information About MPLS MTU Command Changes, page 2
How to Configure MPLS MTU Values, page 3
Configuration Examples for Setting the MPLS MTU Values, page 5
Feature Information for MPLS MTU Command Changes, page 8
Information About MPLS MTU Command Changes

Before configuring the interface or MPLS MTU values, you should understand the following concepts:
MPLS MTU Values During Upgrade, page 2
Guidelines for Setting MPLS MTU and Interface MTU Values, page 2
MPLS MTU Values for Ethernet Interfaces, page 3
MPLS MTU Values During Upgrade

If you have configuration files with MPLS MTU values that are larger than the interface MTU values
and you upgrade to Cisco IOS Release 12.2(27)SBC, 12.2(33)SRA, 12.4(11)T, 12.2(33)SXH or later
releases, the software does not change the MPLS MTU value. When you reboot the router, the software
accepts the values that are set for the MPLS MTU and the interface MTU. The following error message
is displayed during system initialization:
Setting the mpls mtu to xxxx on interface x/x, which is higher than the interface MTU
xxxx. This could lead to packet forwarding problems including packet drops.
You must set the MPLS MTU values equal to or lower than the interface MTU values.
Caution If you do not set the MPLS MTU less than or equal to the interface MTU, data corruption, dropped
packets, and high CPU conditions can occur.
Guidelines for Setting MPLS MTU and Interface MTU Values

When configuring the network to use MPLS, set the core-facing interface MTU values greater than the
edge-facing interface MTU values, using one of the following methods:
Set the interface MTU values on the core-facing interfaces to a higher value than the interface MTU
values on the customer-facing interfaces to accommodate any packet labels, such as MPLS labels,
that an interface might encounter. Make sure that the interface MTUs on the remote end interfaces
have the same interface MTU values. The interface MTU values on both ends of the link must match.
Set the interface MTU values on the customer-facing interfaces to a lower value than the interface
MTU on the core-facing interfaces to accommodate any packet labels, such as MPLS labels, than an
interface might encounter. When you set the interface MTU on the edge interfaces, ensure that the
interface MTUs on the remote end interfaces have the same values. The interface MTU values on
both ends of the link must match.
2
How to Configure MPLS MTU Values
Changing the interface MTU can also modify the IP MTU, Connectionless Network Service (CLNS)
MTU, and other MTU values, because they depend on the value of the interface MTU. The Open Shortest
Path First (OSPF) routing protocol requires that the IP MTU values match on both ends of the link.
Similarly, the Intermediate System-to-Intermediate System (IS-IS) routing protocol requires that the
CLNS MTU values match on both ends of the link. If the values on both ends of the link do not match,
IS-IS or OSPF cannot complete its initialization.
If the configuration of the adjacent router does not include the mpls mtu and mtu commands, add these
commands to the router.
Note The MPLS MTU setting is displayed only in the show running-config output if the MPLS MTU value is
different from the interface MTU value. If the values match, only the interface MTU value is displayed.
If you attempt to set the MPLS MTU value higher than the interface MTU value, the software displays
the following error, which reminds you to set the interface MTU to a higher value before you set the
MPLS MTU value:
% Please increase interface mtu to xxxx and then set mpls mtu
adapters. The range of values is 1500 -1530. Before this enhancement, the MTU of those interfaces was
not configurable.
MPLS MTU Values for Ethernet Interfaces

If you have an interface with a default interface MTU value of 1580 or less (such as an Ethernet
interface), the mpls mtu command provides an override keyword, which allows you to set the MPLS
MTU value higher than the interface MTU value. The override keyword is not available for interface
types that do not have a default interface MTU value of 1580 or less. For configuration details, see the
Setting the MPLS MTU Value on an Ethernet Interface section on page 5.
Setting the MPLS MTU value higher than the Ethernet interface MTU value can lead to dropped packets,
data corruption, or high CPU rates. When you set the MPLS MTU value higher than the Ethernet
interface MTU value, the software displays the following message:
%MFI-30-MPLS_MTU_SET: Setting the mpls mtu to xxxx on Ethernet x/x, which is higher than
the interface MTU xxxx. This could lead to packet forwarding problems including packet
drops.
Most drivers will be able to support baby giants and will gracefully drop packets that are
too large. Certain drivers will have packet forwarding problems including data corruption.
Setting the mpls mtu higher than the interface mtu can lead to packet forwarding problems
and may be blocked in a future release.
Note The override keyword is supported in Cisco IOS Release 12.2(27)SBC, 12.2(33)SRA, 12.4(11)T,
12.2(33)SXH, and later releases, but may not be supported in a future release.

The following sections explain how to configure MPLS MTU and interface MTU values:
Setting the Interface MTU and MPLS MTU Values, page 4
3
Setting the MPLS MTU Value on an Ethernet Interface, page 5
Setting the Interface MTU and MPLS MTU Values

Use the following steps to set the interface MTU and the MPLS MTU.
adapters. The range of values is 1500 -1530.Before this enhancement, the MTU of those interfaces was
not configurable.
SUMMARY STEPS
1. enable
4. mtu bytes
5. mpls mtu bytes
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/port Enters interface configuration mode to configure the
interface.
Example:
Router(config)# interface Serial 1/0
Step 4 mtu bytes Sets the interface MTU size.
Example:
Router(config-if) mtu 1520
Step 5 mpls mtu bytes Sets the MPLS MTU to match the interface MTU.
Example:
Router(config-if) mpls mtu 1520
4
Configuration Examples for Setting the MPLS MTU Values
Setting the MPLS MTU Value on an Ethernet Interface

Use the following steps to set the MPLS MTU value on an Ethernet interface.
SUMMARY STEPS
1. enable
4. mpls mtu override bytes
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface type slot/port Enters interface configuration mode to configure the
Ethernet interface.
Example:
Step 4 mpls mtu override bytes Sets the MPLS MTU to a value higher than the interface
MTU value.
Example:
Router(config-if) mpls mtu override 1510
Caution Setting the MPLS MTU value higher than the
Ethernet interface MTU value can lead to
dropped packets, data corruption, or high CPU
rates.

This section includes the following examples:
Setting the Interface MTU and MPLS MTU: Example, page 6
Setting the MPLS MTU Value on an Ethernet Interface: Example, page 7
5
Setting the Interface MTU and MPLS MTU: Example

The following example shows how to set the interface and MPLS MTU values. The serial interface in
the following configuration examples is at the default interface MTU value. The MPLS MTU value is
not set. The interface settings are as follows:
interface Serial 4/0
mpls ip
end
The following example attempts to set the MPLS MTU value to 1520. This returns an error, because the
MPLS MTU value cannot be set to a greater value than the interface MTU.

Router(config-if)# mpls mtu 1520
% Please increase interface mtu to 1520 and then set mpls mtu
The following example first sets the interface MTU to 1520 and then sets the MPLS MTU to 1520:
The following example shows the new interface MTU value. The MPLS MTU value is not displayed,
because it is equal to the interface value.
Router# show running-config interface serial 4/0
interface Serial4/0
mtu 1520
mpls ip
end
The following example sets the MPLS MTU value to 1510:

The following example shows the new interface MTU value. The MPLS MTU value is displayed,
because it is different than the interface MTU value.
Router# show running-config interface serial 4/0
interface Serial4/0
mtu 1520
mpls mtu 1510
mpls ip
6
end
Setting the MPLS MTU Value on an Ethernet Interface: Example
Caution Setting the MPLS MTU value higher than the Ethernet interface MTU value can lead to dropped packets,
data corruption, or high CPU rates.
The following example shows how to set the MPLS MTU values on an Ethernet interface. The Ethernet
interface in the following configuration examples is at the default interface MTU value. The MPLS MTU
value is not set. The interface settings are as follows:
interface Ethernet 2/0
mpls ip
end
The following example uses the override keyword to set the MPLS MTU to 1520, which is higher than
the Ethernet interfaces MTU value:
Router(config-if)# mpls mtu override 1520
%MFI-30-MPLS_MTU_SET: Setting the mpls mtu to 1520 on Ethernet2/0, which is higher than
the interface MTU 1500. This could lead to packet forwarding problems including packet
drops.
The following example shows the new MPLS MTU value:

Router# show running-config interface ethernet 2/0
mtu 1500
mpls mtu 1520
mpls ip
end
7
Feature Information for MPLS MTU Command Changes

Table 1 Feature Information for MPLS MTU Command Changes

MPLS MTU Command Changes 12.2(27)SBC This document explains the changes to the mpls mtu
12.2(28)SB command. You cannot set the MPLS MTU value larger than
12.2(33)SRA the interface MTU value, except for Ethernet interfaces.
12.4(11)T
In 12.2(28)SB, support was added for the Cisco 10000
12.2(33)SXH
router.
15.0(1)M1
In 12.2(33)SRA, support was added for the Cisco 7600
series router.
12.4(11)T.
12.2(33)SXH.
In 15.0(1)M1, you can configure the interface MTU on
PA-1FE and PA-2FE port adapters.
feature:
Information About MPLS MTU Command Changes,
page 2
How to Configure MPLS MTU Values, page 3
Configuration Examples for Setting the MPLS MTU
Values, page 5
8
coincidental.
9
10

The AToM Static Pseudowire Provisioning feature allows provisioning an Any Transport over
Multiprotocol Label Switching (MPLS) (AToM) static pseudowire without the use of a directed control
connection. In environments that do not or cannot use directed control protocols, this feature provides a
means for provisioning the pseudowire parameters statically at the Cisco IOS command-line interface
(CLI).

supported, see the Feature Information for AToM Static Pseudowire Provisioning section on page 9.
Contents
Restrictions for AToM Static Pseudowire Provisioning, page 2
Information About AToM Static Pseudowire Provisioning, page 2
How to Provision an AToM Static Pseudowire, page 3
Configuration Examples for AToM Static Pseudowire Provisioning, page 6
Feature Information for AToM Static Pseudowire Provisioning, page 9

Restrictions for AToM Static Pseudowire Provisioning
Restrictions for AToM Static Pseudowire Provisioning

The following parameters are exchanged using directed control protocol messages on pseudowires, but
cannot be changed using the AToM Static Pseudowire Provisioning feature introduced in Cisco IOS
Release 12.33(SRB). Instead, the software has preconfigured defaults.
The Virtual Circuit Connectivity Verification (VCCV) options used for fault detection, isolation,
and verification at both ends of the connection are set as follows:
Control channel type 1 sets the control word.
Control channel type 2 sets the MPLS router alert label.
Connectivity verification type 2 sets the label switched path (LSP) ping command.
In order to support cell packing for static pseudowires, both provider-edge routers (PEs) must run
Cisco IOS Release 12.2(1)SRE, and the maximum number of cells that can be packed must be set to the
same value on each.
Autosensing of the virtual circuit type for Ethernet over MPLS is not supported.
Additionally, the following functionality is not supported for static pseudowires:
Sequence number resynchronizationconfigured by the sequencing function in the Cisco IOS
pseudowire-class commandis not supported because the sequence number resynchronization is
done when the Label Distribution Protocol (LDP) software sends an LDP Label Release or
Withdraw message followed by a Label Request or Mapping message, and static pseudowires do not
use LDP.
Tunnel stitching is not supported because it requires an extension of the Cisco IOS neighbor
command to start the mode that allows configuring static pseudowire parameters such as remote and
local labels, which is not supported in Cisco IOS Release 12.33(SRB). Note that a tunnel switch
point can be configured using a different static label command. The tunnel switch point will not
process control words, but label swapping will occur.
Pseudowire redundancy is not supported because it requires using a directed control protocol
between the peer provider edge routers.
Information About AToM Static Pseudowire Provisioning

To provision an AToM static pseudowire, you should understand the following concepts:
Pseudowire Provisioning, page 2
Benefits of Statically Provisioned Pseudowires, page 3
Pseudowire Provisioning
In software prior to Cisco IOS Release 12.33(SRB), pseudowires were dynamically provisioned using
LDP, or another directed control protocol such as Resource Reservation Protocol over traffic-engineered
tunnels (RSVP-TE), to exchange the various parameters required for these connections. In environments
that do not or cannot use directed control protocols, a means for provisioning the pseudowire parameters
statically at the Cisco IOS CLI is provided by the AToM Static Pseudowire Provisioning feature.
The AToM Static Pseudowire Provisioning feature is platform-independent, but has been tested on only
the Cisco 7600 series routers for Cisco IOS Release 12.33(SRB).
2
How to Provision an AToM Static Pseudowire
Benefits of Statically Provisioned Pseudowires

Cisco IOS Release 12.33(SRB) allows provisioning an AToM label switching static pseudowire without
the use of a directed control connection. This feature also includes static provisioning of the tunnel label
and the pseudowire label.

Provisioning an AToM Static Pseudowire, page 3
Verifying the AToM Static Pseudowire Configuration, page 5
Provisioning an AToM Static Pseudowire

In this configuration task, you use options in the xconnect Ethernet interface configuration command to
specify a static connection, and mpls commands in xconnect mode to statically set the following
pseudowire parameters:
Set the local and remote pseudowire labels
Enable or disable sending the MPLS control word
SUMMARY STEPS
1. enable
3. interface ethernet-type interface-number
4. xconnect peer-ip-address vcid encapsulation mpls manual pw-class class-name
5. mpls label local-pseudowire-label remote-pseudowire-label
6. [no] mpls control-word
7. exit
DETAILED STEPS

Example:
Router> enable
Example:
3

Step 3 interface ethernet-type interface-number Enters interface configuration mode for the specified interface.
Example:
Step 4 xconnect peer-ip-address vcid encapsulation Configures a static AToM pseudowire and enters xconnect
mpls manual pw-class class-name configuration mode where the local and remote pseudowire
labels are set.
Example:
Router(config-if)# xconnect 10.131.191.252
100 encapsulation mpls manual pw-class mpls
Step 5 mpls label local-pseudowire-label Sets the local and remote pseudowire labels.
remote-pseudowire-label
The label must be an unused static label within the static
label range configured using the mpls label range
Example: command.
Router(config-if-xconn)# mpls label 100 150
The mpls label command checks the validity of the label
entered and displays an error message if it is not valid. The
label supplied for the remote-pseudowire-label argument
must be the value of the peer PEs local pseudowire label.
Step 6 [no] mpls control-word Sets whether the MPLS control word is sent.
This command must be set for Frame Relay data-link
Example: connection identifier (DLCI) and ATM adaptation layer 5
Router(config-if-xconn)# no mpls (AAL5) attachment circuits. For other attachment circuits,
control-word the control word is included by default.
If you enable inclusion of the control word, it must be
enabled on both ends of the connection for the circuit to
work properly.
Inclusion of the control word can be explicitly disabled
using the no mpls control-word command.
Step 7 exit Exits the configuration mode.
Continue entering the exit command at the router prompt
Example: until you reach the desired configuration mode.
Router(config-if-xconn)# exit
4
Verifying the AToM Static Pseudowire Configuration

To verify the AToM static pseudowire configuration, use the show running-config EXEC command. To
verify that the AToM static pseudowire was provisioned correctly, use the show mpls l2transport vc
detail and ping mpls pseudowire EXEC commands as described in the following steps.
SUMMARY STEPS
1. show mpls l2transport vc detail

2. ping mpls pseudowire ipv4-address vc-id vc-id
DETAILED STEPS
Step 1 show mpls l2transport vc detail

For nonstatic pseudowire configurations, this command lists the type of protocol used to send the MPLS
labels (such as LDP). For static pseudowire configuration, the value of the signaling protocol field
should be Manual. Following is sample output:

Output interface: Et3/0, imposed label stack {17}
Default path:
Next hop: 10.0.0.2
Signaling protocol: Manual
VC statistics:
Step 2 ping mpls pseudowire ipv4-address vc-id vc-id

Because there is no directed control protocol exchange of parameters on a static pseudowire, both ends
of the connection must be correctly configured. One way to detect mismatch of labels or control word
options is to send an MPLS pseudowire LSP ping command as part of configuration task, and then
reconfigure the connection if problems are detected. An exclamation point (!) is displayed when the ping
command is successfully sent to its destination. An example of command use and output follows:
Router# ping mpls pseudowire 10.7.1.2 vc-id 1001
Sending 5, 100-byte MPLS Echos to 10.7.1.2,

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
Type escape sequence to abort.
5
Configuration Examples for AToM Static Pseudowire Provisioning
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/2/4 ms
Configuration Examples for AToM Static Pseudowire

Provisioning
This section contains the following example:
Provisioning an AToM Pseudowire: Example, page 6
Provisioning an AToM Pseudowire: Example

The following examples show the configuration commands for an AToM static pseudowire connection
between two PEs, PE1 and PE2.
The mpls label range static command must be used to configure the static label range prior to
provisioning the AToM static pseudowire.
Router(config)# mpls label range 200 16000 static 16 199
% Label range changes will take effect at the next reload.
The mpls ip command must also be configured on the core-facing interface of both PE1 and PE2 (which
is also done for directed control protocol signaled pseudowires). Following is a configuration example:
Router(config-if)# description Backbone interface
Following is an example AToM static pseudowire configuration for PE1:

Router(config-if)# no ip address
Router(config-if)# xconnect 10.131.191.251 100 encapsulation mpls manual pw-class mpls
Following is an example AToM static pseudowire configuration for PE2:

Router(config-if)# no ip address
Router(config-if)# xconnect 10.132.192.252 100 encapsulation mpls manual pw-class mpls
This feature also allows tunnel labels to be statically configured using the mpls static binding ipv4 vrf
command. This means that there is no need to use a directed control protocol to provision tunnels and
pseudowires. Refer to the MPLS Static Labels feature module and the Cisco IOS Multiprotocol Label
Switching Command Reference for information about static labels and the mpls static binding ipv4 vrf
command.
6
The following sections provide references related to the AToM Static Pseudowire Provisioning feature.
Related Documents
Configuring the pseudowire class Any Transport over MPLS
MPLS and xconnect commands Cisco IOS Multiprotocol Label Switching Command Reference
Static labels and the mpls static binding ipv4 vrf MPLS Static Labels section of the Cisco IOS Multiprotocol Label
command Switching Configuration Guide
Standards
Standard Title
IETF draft-ietf-pwe3-vccv-12.txt Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)
MIBs
MIB MIBs Link
following URL:
RFCs
RFC Title
7
Description Link
8
Feature Information for AToM Static Pseudowire Provisioning

Table 1 lists the features in this module and provides links to specific configuration information. Only
features that were introduced or modified in Cisco IOS Release 12.2(1) or a later release appear in the
table.
Table 1 Feature Information for AToM Static Pseudowire Provisioning

AToM Static Pseudowire Provisioning 12.2(33)SRB This feature allows provisioning an AToM static pseudowire
12.2(1)SRE without the use of a directed control protocol connection.
The AToM Static Pseudowire feature is
platform-independent, but has been tested on only the
Cisco 7500 series routers for Cisco IOS
Release 12.33(SRB).
The following commands were introduced or modified by
this feature: cell-packing, mpls control-word, mpls label,
show mpls l2transport vc, xconnect.
coincidental.
9
10
MPLS Pseudowire Status Signaling
First Published: December 31, 2007

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. In releases prior to Cisco
IOS 12.2(33)SRC, if the attachment circuit was down, the pseudowire status messages were not sent to
the peer.

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 5
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. Specifically, both routers should be running Cisco IOS
Release 12.2(33)SRC and have the supported hardware installed.
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.
For a list of supported hardware for this feature, see the release notes for your platform.
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

In releases prior to Cisco IOS Release 12.2(33)SRC, the control plane for AToM does not have the ability
to provide pseudowire status. Therefore, when an attachment circuit (AC) associated with a pseudowire
is down (or is forced down as part of the Pseudowire Redundancy functionality), labels advertised to
peers are withdrawn. In Cisco IOS Release 12.2(33)SRC, the MPLS Pseudowire Status Signaling feature
enables the AC status to be sent to the peer through the Label Distribution Protocol.
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
2
Information About MPLS Pseudowire Status Signaling
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.
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 [110.1.1.2]: Sending label withdraw msg

*Feb 26 13:41:40.707: AToM LDP [110.1.1.2]: VC Type 5, mtu 1500
*Feb 26 13:41:40.707: AToM LDP [110.1.1.2]: VC ID 100, label 18
*Feb 26 13:41:40.707: AToM LDP [110.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.
3
How to Configure MPLS Pseudowire Status Signaling
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
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:
Llocal router
Rremote router
r or nready (r) or not ready (n)
u or dup (u) or down (d) status
The output also includes other values:
DDataplane
SLocal shutdown
How to Configure MPLS Pseudowire Status Signaling

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
Configuration Examples for MPLS Pseudowire Status Signaling
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:
Router(config-pw)# encapsulation mpls
Step 6 exit Exits pseudowire class configuration mode.
Example:
Router(config-pw)# exit
Example:
Step 8 show mpls l2transport vc detail Validates that pseudowire messages can be sent and
received.
Example:

This section contains the following examples:
5
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
!
interface GigabitEthernet10/5
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
Any Transport over MPLS Any Transport over MPLS
Virtual Private LAN Services Virtual Private LAN Services on the Optical Services Modules
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
Ethernet, Frame Relay, and ATM Services releases, and feature sets, use Cisco MIB Locator found at the
following URL:
RFCs
RFC Title
None
7
Command Reference
Description Link
Command Reference
debug mpls l2transport vc
show mpls l2transport vc
status (pseudowire class)
8
Feature Information for MPLS Pseudowire Status Signaling

Table 1 Feature Information for MPLS Pseudowire Status Signaling
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,
coincidental.
9
10
L2VPN Interworking

Last Updated:November 20, 2009
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/VLAN to ATM AAL5 Interworking
Ethernet/VLAN to Frame Relay Interworking
Ethernet/VLAN to PPP Interworking
Ethernet to VLAN Interworking
Frame Relay to ATM AAL5 Interworking
Frame Relay to PPP Interworking
Ethernet/VLAN to ATM virtual channel identifier (VPI) and virtual channel identifier (VCI)
Interworking
L2VPN Interworking: VLAN Enable/Disable Option for AToM

supported, see the Feature Information for L2VPN Interworking section on page 31.
Contents
Prerequisites for L2VPN Interworking, page 2
L2VPN Interworking
Prerequisites for L2VPN Interworking
Restrictions for L2VPN Interworking, page 2

Information About L2VPN Interworking, page 11
How to Configure L2VPN Interworking, page 15
Configuration Examples for L2VPN Interworking, page 21
Feature Information for L2VPN Interworking, page 31
Prerequisites for L2VPN Interworking

Before you configure L2VPN Interworking on a router:
You must enable Cisco Express Forwarding.
On the Cisco 12000 series Internet router, before you configure Layer 2 Tunnel Protocol version 3
(L2TPv3) for L2VPN Interworking on an IP Services Engine (ISE/Engine 3) or Engine 5 interface,
you must also enable the L2VPN feature bundle on the line card.
To enable the feature bundle, enter the hw-module slot np mode feature command in global
configuration mode as follows:
Router(config)# hw-module slot slot-number np mode feature
Restrictions for L2VPN Interworking

The following sections list the L2VPN Interworking restrictions:
General Restrictions, page 2
Cisco 7600 Series Routers Restrictions, page 3
Cisco 12000 Series Router Restrictions, page 5
ATM AAL5 Interworking Restrictions, page 7
Ethernet/VLAN Interworking Restrictions, page 8
L2VPN Interworking: VLAN Enable/Disable Option for AToM Restrictions, page 9
Frame Relay Interworking Restrictions, page 10
PPP Interworking Restrictions, page 11
General Restrictions
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.
The following quality of service (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
Book Title
2
L2VPN Interworking
IP ToS reflection in tunnel header (Layer 2 Tunnel Protocol Version 3 (L2TPv3) only)
Frame Relay policing
Frame Relay data-link connection identifier (DLCI)-based congestion management
(Cisco 7500/Versatile Interface Processor (VIP))
One-to-one mapping of VLAN priority bits to MPLS EXP bits
Only ATM AAL5 VC mode is supported; ATM VP and port mode are not supported.
Cisco 7600 Series Routers Restrictions

The following line cards are supported on the Cisco 7600 series router. Table 1 shows the line cards that
are supported on the WAN (ATM, Frame Relay, or PPP) side of the interworking link. Table 2 shows the
line cards that are supported on the Ethernet side of the interworking link. For more details on the Cisco
7600 routers supported shared port adapters and line cards, see the following documents:
Cisco 7600 Series Routers Documentation Roadmap
Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600 Series Routers
Table 1 Cisco 7600 Series Routers: Supported Line Cards for the WAN Side
Interworking Type Core-Facing Line Cards Customer-Edge Line Cards

Ethernet (bridged) Any EflexWAN
(ATM and Frame Relay) SIP-200
SIP-400
IP (routed) Any EflexWAN
(ATM, Frame Relay, and PPP) SIP-200
Table 2 Cisco 7600 Series Routers: Supported Line Cards for the Ethernet Side
Interworking Ethernet over MPLS

Type Mode Core-Facing Line Cards Customer-Edge Line Cards
Ethernet Policy feature card Any, except optical Catalyst LAN
(bridged) (PFC) based service module (OSM) SIP-600
and ES40
Ethernet Switched virtual EflexWAN Catalyst LAN
(bridged) interface (SVI) ES20 EflexWAN (with MPB)
based ES+40 ES20
SIP-200 ES+40
SIP-400 SIP-200 (with MPB)
SIP-600 SIP-400 (with MPB)
SIP-600
Ethernet Scalable (with Any, except OSM ES20
(bridged) E-MPB) SIP-600 and SIP-400 with Gigabit
Ethernet (GE) SPA
Book Title
3
L2VPN Interworking
Table 2 Cisco 7600 Series Routers: Supported Line Cards for the Ethernet Side (continued)
Interworking Ethernet over MPLS

Type Mode Core-Facing Line Cards Customer-Edge Line Cards
IP (routed) PFC-based Catalyst LAN Catalyst LAN
SIP-600 SIP-600
Note: PFC-based mode Note: PFC-based mode is not
is not supported with supported with routed interworking
routed interworking in in Cisco IOS Release 12.2(33)SRD.
Cisco IOS Release Use SVI, Scalable, or EVC-based
12.2(33)SRD. Use EoMPLS instead.
SVI, Scalable, or
Ethernet virtual
connection (EVC)
based Ethernet over
MPLS (EoMPLS)
instead.
IP (routed) SVI-based Any, except Catalyst Catalyst LAN
LAN and OSM. EflexWAN (with MPB)
ES20
SIP-200 (with MPB)
SIP-400 (with MPB)
SIP-600
The following restrictions apply to the Cisco 7600 series routers and L2VPN Interworking:
OAM Emulation is not supported with L2VPN Interworking on the SIP-200, SIP-400, and Flexwan2
line cards.
Cisco 7600 series routers support the L2VPN Interworking: VLAN Enable/Disable Option for
AToM feature starting in Cisco IOS Release 12.2(33)SRE. This feature has the following
restrictions:
PFC-based EoMPLS is not supported.
Scalable and SVI-based EoMPLS are supported with the SIP-400 line card.
The Cisco 7600 series routers do not support L2VPN Interworking over L2TPv3.
Cisco 7600 series routers support only the following interworking types:
Ethernet/VLAN to Frame Relay (IP and Ethernet modes)
Ethernet/VLAN to ATM AAL5SNAP (IP and Ethernet modes)
Ethernet/VLAN to PPP (IP only)
Cisco 7600 series routers do not support the following interworking types:
Ethernet/VLAN to ATM AAL5MUX
Frame Relay to PPP Interworking
Both ends of the interworking link must be configured with the same encapsulation and interworking
type:
Book Title
4
L2VPN Interworking
If you use Ethernet encapsulation, you must use the Ethernet (bridged) interworking type. If you
are not using Ethernet encapsulation, you can use a bridging mechanism, such as routed bridge
encapsulation (RBE).
If you use an IP encapsulation (such as ATM or Frame Relay), you must use the IP (routed)
interworking type. The PE routers negotiate the process for learning and resolving addresses.
You must use the same MTU size on the attachment circuits at each end of the pseudowire.
PFC-based EoMPLS is not supported on ES40 line cards. SVI and EVC/scalable EoMPLS are the
alternative options.
PFC-based EoMPLS is not supported for Routed/IP interworking in Cisco IOS
Release 12.2(33)SRD and later releases. The alternative Routed/IP interworking options are SVI
and EVC or scalable EoMPLS. However, PFC-based EoMPLS is supported for Ethernet/Bridged
interworking and for like-to-like over AToM.
Cisco 12000 Series Router Restrictions

For more information about hardware requirements on the Cisco12000 series routers, see the
Cross-Platform Release Notes for Cisco IOS Release 12.0S.
For QOS support on the Cisco 12000 series routers, see Any Transport over MPLS (AToM): Layer 2 QoS
(Quality of Service) for the Cisco 12000 Series Router
Frame Relay to PPP and High-Level Data Link Control Interworking

The Cisco 12000 series Internet router does not support L2VPN Interworking with PPP and high-level
data link control (HDLC) transport types in Cisco IOS releases earlier than Cisco IOS
Release 12.0(32)S.
In Cisco IOS Release 12.0(32)S and later releases, the Cisco 12000 series Internet router supports
L2VPN interworking for Frame Relay over MPLS and PPP and HDLC over MPLS only on the following
shared port adapters (SPAs):
ISE/Engine 3 SPAs:
SPA-2XCT3/DS0 (2-port channelized T3 to DS0)
SPA-4XCT3/DS0 (4-port channelized T3 to DS0)
Engine 5 SPAs:
SPA-1XCHSTM1/OC-3 (1-port channelized STM-1c/OC-3c to DS0)
SPA-8XCHT1/E1 (8-port channelized T1/E1)
SPA-2XOC-48-POS/RPR (2-port OC-48/STM16 POS/RPR)
SPA-OC-192POS-LR (1-port OC-192/STM64 POS/RPR)
SPA-OC-192POS-XFP (1-port OC-192/STM64 POS/RPR)
L2VPN Interworking over L2TPv3

On the Cisco 12000 series Internet router, Ethernet (bridged) interworking is not supported for L2TPv3.
Only IP (routed) interworking is supported.
IP (routed) interworking is not supported in an L2TPv3 pseudowire that is configured for data
sequencing (using the sequencing command).
In Cisco IOS Release 12.0(32)SY and later releases, the Cisco 12000 series Internet router supports
L2VPN Interworking over L2TPv3 tunnels in IP mode on ISE and Engine 5 line cards as follows:
Book Title
5
L2VPN Interworking
On an ISE interface configured for L2TPv3 tunneling, the following Layer 2 encapsulations are
supported:
ATM adaptation layer type-5 (AAL5)
Ethernet
802.1q (VLAN)
Frame Relay DLCI
On an Engine 5 interface configured for L2TPv3 tunneling, the following Layer 2 encapsulations
are supported:
Ethernet
802.1q (VLAN)
Frame Relay DLCI
For more information, refer to Layer 2 Tunnel Protocol Version 3.
The only frame format supported for L2TPv3 interworking on Engine 5 Ethernet SPAs is Ethernet
Version 2 (also known as Ethernet II) with the Ether type 0x0800 value set as Internet Protocol Payload
and (optionally) 802.1q VLAN. Ethernet packets with other Ethernet frame formats are dropped.
Remote Ethernet Port Shutdown Support

The Cisco Remote Ethernet Port Shutdown feature (which minimizes potential data loss after a remote
link failure) is supported only on the following Engine 5 Ethernet SPAs:
SPA-8XFE (8-port Fast Ethernet)
SPA-2X1GE (2-port Gigabit Ethernet)
SPA-1X10GE (1-port 10-Gigabit Ethernet)
For more information about this feature, refer to Any Transport over MPLS (AToM): Remote Ethernet
Port Shutdown.
L2VPN Any-to-Any Interworking on Engine 5 Line Cards

Table 3 shows the different combinations of transport types supported for L2VPN interworking on
Engine 3 and Engine 5 SPA interfaces connected through an attachment circuit over MPLS or L2TPv3.
Table 3 Engine 3 and Engine 5 Line Cards/SPAs Supported for L2VPN Interworking
Attachment Attachment Interworking AC1 Engine Type and AC2 Engine Type and
Circuit 1 (AC1) Circuit 2 (AC2) Mode Line Card/SPA Line Card/SPA
Frame Relay Frame Relay IP Engine 5 Engine 3
POS and channelized ATM line cards
Frame Relay ATM Ethernet Engine 5 Engine 3
Frame Relay ATM IP Engine 5 Engine 3
Frame Relay Ethernet Ethernet Engine 5 Engine 5
POS and channelized Gigabit Ethernet
Book Title
6
L2VPN Interworking
Table 3 Engine 3 and Engine 5 Line Cards/SPAs Supported for L2VPN Interworking
Attachment Attachment Interworking AC1 Engine Type and AC2 Engine Type and
Circuit 1 (AC1) Circuit 2 (AC2) Mode Line Card/SPA Line Card/SPA
Frame Relay Ethernet IP Engine 5 Engine 5
Frame Relay VLAN Ethernet Engine 5 Engine 5
Frame Relay VLAN IP Engine 5 Engine 5
Ethernet Ethernet Ethernet Engine 5 Engine 5
Gigabit Ethernet Gigabit Ethernet
Ethernet Ethernet IP Engine 5 Engine 5
Ethernet VLAN Ethernet Engine 5 Engine 5
Ethernet VLAN IP Engine 5 Engine 5
ATM Ethernet Ethernet Engine 3 Engine 5
ATM line cards Gigabit Ethernet
ATM Ethernet IP Engine 3 Engine 5
ATM line cards Gigabit Ethernet
On the Cisco 12000 series Engine 3 line card, Network Layer Protocol ID (NLPID) encapsulation is not
supported in routed mode; and neither NLPID nor AAL5MUX is supported in bridged mode.
On the Cisco 12000 series Internet router, Ethernet (bridged) interworking is not supported for
L2TPv3.
In an L2VPN Interworking configuration, after you configure L2TPv3 tunnel encapsulation for a
pseudowire using the encapsulation l2tpv3 command, you cannot enter the interworking ethernet
command.
On Ethernet SPAs on the Cisco 12000 series Internet router, the only frame format supported for
L2TPv3 interworking is Ethernet Version 2 (also known as Ethernet II) with the Ether type 0x0800
value set as Internet Protocol Payload and [optionally] 802.1q VLAN.
Ethernet packets with other Ethernet frame formats are dropped.
ATM AAL5 Interworking Restrictions

The following restrictions apply to ATM AAL5 Interworking:
Switched virtual circuits (SVCs) are not supported.
Inverse Address Resolution Protocol (ARP) is not supported with IP interworking.
Customer edge (CE) routers must use point-to-point subinterfaces or static maps.
Both AAL5MUX and AAL5SNAP encapsulation are supported. In the case of AAL5MUX, no
translation is needed.
In the Ethernet end-to-end over ATM scenario, the following translations are supported:
Book Title
7
L2VPN Interworking
Ethernet without LAN frame check sequence (FCS) (AAAA030080C200070000)

Spanning tree (AAAA030080c2000E)
Everything else is dropped.
In the IP over ATM scenario, the IPv4 (AAAA030000000800) translation is supported. Everything
else is dropped.
Operation, Administration, and Management (OAM) emulation for L2VPN Interworking is the
same as like-to-like. The end-to-end F5 loopback cells are looped back on the PE router. When the
pseudowire is down, an F5 end-to-end segment Alarm Indication Signal (AIS)/Remote Defect
Identification (RDI) is sent from the PE router to the CE router.
Interim Local Management Interface (ILMI) can manage virtual circuits (VCs) and permanent
virtual circuits (PVCs).
To enable ILMI management, configure ILMI PVC 0/16 on the PE routers ATM interface. If a PVC
is provisioned or deleted, an ilmiVCCChange trap is sent to the CE router.
Only the user side of the User-Network Interface (UNI) is supported; the network side of the UNI
is not supported.
Ethernet/VLAN Interworking Restrictions

The following restrictions apply to Ethernet/VLAN interworking:
When you configure VLAN to Ethernet interworking, VLAN to Frame Relay (routed), or ATM
using Ethernet (bridged) interworking, the PE router on the Ethernet side that receives a VLAN
tagged frame from the CE router removes the VLAN tag. In the reverse direction, the PE router adds
the VLAN tag to the frame before sending the frame to the CE router.
(If you enable the L2VPN Interworking: VLAN Enable/Disable Option for AToM feature with the
interworking vlan command, VLAN ID is included as part of the Ethernet frame. See the VLAN
Interworking section on page 13 for more information. )
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.
The Cisco 10720 Internet router supports Ethernet to VLAN Interworking Ethernet only over
L2TPv3.
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:
Book Title
8
L2VPN Interworking
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 routers Ethernet or VLAN
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.
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.
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.
L2VPN Interworking: VLAN Enable/Disable Option for AToM Restrictions

The following restrictions apply to the L2VPN Interworking: VLAN Enable/Disable Option for AToM
feature, which allows the VLAN ID to be included as part of the Ethernet frame:
The L2VPN Interworking: VLAN Enable/Disable Option for AToM feature is supported on the
following releases:
Cisco IOS release 12.2(52)SE for the Cisco Catalyst 3750 Metro switches
Cisco IOS Release 12.2(33)SRE for the Cisco 7600 series routers
L2VPN Interworking: VLAN Enable/Disable Option for AToM is not supported with L2TPv3. You
can configure the featue only with AToM.
If the interface on the PE router is a VLAN interface, it is not necessary to specify the interworking
vlan command on that PE router.
The L2VPN Interworking: VLAN Enable/Disable Option for AToM feature works only with the
following attachment circuit combinations:
Ethernet to Ethernet
Ethernet to VLAN
VLAN to VLAN
If you specify an interworking type on a PE router, that interworking type must be enforced. The
interworking type must match on both PE routers. Otherwise, the VC may be in an incompatible
state and remain in the down state. If the attachment circuit (AC) is VLAN, the PE router can
negotiate (autosense) the VC type using Label Distribution Protocol (LDP).
For example, both PE1 and PE2 use Ethernet interfaces, and VLAN interworking is specified on PE1
only. PE2 is not configured with an interworking type and cannot autosense the interworking type.
The result is an incompatible state where the VC remains in the down state.
On the other hand, if PE1 uses an Ethernet interface and VLAN interworking is enabled (which will
enforce VLAN as the VC type), and PE2 uses a VLAN interface and interworking is not enabled
(which causes PE2 to use Ethernet as its default VC type), PE2 can autosense and negotiate the
interworking type and select VLAN as the VC type.
Book Title
9
L2VPN Interworking
Table 4 summarizes shows the AC types, interworking options, and VC types after negotiation.
Table 4 Negotiating Ethernet and VLAN Interworking Types
PE1 AC Interworking PE2 AC Interworking

Type Option Type Option VC Type after Negotiation
Ethernet none Ethernet none Ethernet
Vlan none Ethernet none Ethernet
Ethernet none Vlan none Ethernet
Vlan none Vlan none Ethernet
Ethernet Vlan Ethernet none Incompatible
Vlan Vlan Ethernet none Incompatible
Ethernet Vlan Vlan none Vlan
Vlan Vlan Vlan none Vlan
Ethernet none Ethernet Vlan Incompatible
Vlan none Ethernet Vlan Vlan
Ethernet none Vlan Vlan Incompatible
Vlan none Vlan Vlan Vlan
Ethernet Vlan Ethernet Vlan Vlan
Vlan Vlan Ethernet Vlan Vlan
Ethernet Vlan Vlan Vlan Vlan
Vlan Vlan Vlan Vlan Vlan
Frame Relay Interworking Restrictions

The following restrictions apply to Frame Relay interworking:
The attachment circuit maximum transmission unit (MTU) sizes must match when you connect them
over MPLS. By default, the MTU size associated with a Frame Relay DLCI is the interface MTU.
This may cause problems, for example, when connecting some DLCIs on a PoS interface (with a
default MTU of 4470 bytes) to Ethernet or VLAN (with a default MTU of 1500 bytes) and other
DLCIs on the same PoS interface to ATM (with a default MTU of 4470 bytes). To avoid reducing
all the interface MTUs to the lowest common denominator (1500 bytes in this case), you can specify
the MTU for individual DLCIs using the mtu command.
Only DLCI mode is supported. Port mode is not supported.
Configure Frame Relay switching to use DCE or Network-to-Network Interface (NNI). DTE mode
does not report status in the Local Management Interface (LMI) process. If a Frame Relay over
MPLS circuit goes down and the PE router is in DTE mode, the CE router is never informed of the
disabled circuit. You must configure the frame-relay switching command in global configuration
mode in order to configure DCE or NNI.
Frame Relay policing is non-distributed on the Cisco 7500 series routers. If you enable Frame Relay
policing, traffic is sent to the route switch processor for processing.
Inverse ARP is not supported with IP interworking. CE routers must use point-to-point subinterfaces
or static maps.
Book Title
10
L2VPN Interworking
Information About L2VPN Interworking
The PE router automatically supports translation of both the Cisco encapsulations and the
Internet Engineering Task Force (IETF) encapsulations that come from the CE, but translates only
to IETF when sending to the CE router. This is not a problem for the Cisco CE router, because it can
handle IETF encapsulation on receipt even if it is configured to send Cisco encapsulation.
With Ethernet interworking, the following translations are supported:
Ethernet without LAN FCS (0300800080C20007 or 6558)
Spanning tree (0300800080C2000E or 4242)
All other translations are dropped.
With IP interworking, the IPv4 (03CC or 0800) translation is supported. All other translations are
dropped.
PVC status signaling works the same way as in like-to-like case. The PE router reports the PVC
status to the CE router, based on the availability of the pseudowire. PVC status detected by the PE
router will also be reflected into the pseudowire. LMI to OAM interworking is supported when you
connect Frame Relay to ATM.
PPP Interworking Restrictions

The following restrictions apply to PPP interworking:
There must be a one-to-one relationship between a PPP session and the pseudowire. Multiplexing
of multiple PPP sessions over the pseudowire is not supported.
There must be a one-to-one relationship between a PPP session and a Frame Relay DLCI. Each
Frame Relay PVC must have only one PPP session.
Only IP (IPv4 (0021) interworking is supported. Link Control Protocol (LCP) packets and Internet
Protocol Control Protocol (IPCP) packets are terminated at the PE router. Everything else is
dropped.
Proxy IPCP is automatically enabled on the PE router when IP interworking is configured on the
pseudowire.
By default, the PE router assumes that the CE router knows the remote CE routers IP address.
Password Authentication Protocol (PAP) and Challenge-Handshake Authentication Protocol
(CHAP) authentication are supported.

The following sections provide an introduction to L2VPN interworking.
Overview of L2VPN Interworking, page 12
L2VPN Interworking Modes, page 12
L2VPN Interworking: Support Matrix, page 14
Static IP Addresses for L2VPN Interworking for PPP, page 14
Book Title
11
L2VPN Interworking
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. Figure 1 is an example of Layer 2 interworking, where
ATM and Frame Relay packets travel over the MPLS cloud.
Figure 1 ATM to Frame Relay Interworking Example
Frames or Frames or
IP packets Pseudowire IP packets
Tunnel LSP
ATM ATM PE P router P router PE FR FR

CE Link Link CE
95574
P router
MPLS Network
The L2VPN Interworking feature supports Ethernet, 802.1Q (VLAN), Frame Relay, ATM AAL5, and
PPP attachment circuits over MPLS and L2TPv3. 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, IP (routed), or Ethernet VLAN
mode. You specify the mode by issuing the interworking {ethernet | ip |vlan} command in
pseudowire-class configuration mode.
Ethernet (Bridged) Interworking

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.
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:
Book Title
12
L2VPN Interworking
LAN servicesAn 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 servicesAn 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 (Routed) Interworking
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.
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 and L2TPv3.
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
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.
VLAN Interworking
The vlan keyword allows the VLAN ID to be included as part of the Ethernet frame. In Cisco IOS
Release 12.2(52)SE, you can configure Catalyst 3750 Metro switches to use Ethernet VLAN for Ethernet
(bridged) interworking. You can specify the Ethernet VLAN (type 4) by issuing the interworking vlan
command in pseudowire-class configuration mode. This allows the VLAN ID to be included as part of
the Ethernet frame. In releases previous to Cisco IOS Release 12.2(52)SE, the only way to achieve
VLAN encapsulation is to ensure the CE router is connected to the PE router through an Ethernet VLAN
interface/subinterface.
Book Title
13
L2VPN Interworking
L2VPN Interworking: Support Matrix

The supported L2VPN Interworking features are listed in Table 5.
Table 5 L2VPN Interworking Supported Features
Feature MPLS or L2TPv3 Support IP or Ethernet Support

Ethernet/VLAN to ATM AAL5 MPLS IP
L2TPv3 (12000 series only) Ethernet
Ethernet/VLAN to Frame Relay MPLS IP
L2TPv3 Ethernet
Ethernet/VLAN to PPP MPLS IP
Ethernet to VLAN MPLS IP
L2TPv3 Ethernet1
L2VPN Interworking: VLAN MPLS Ethernet VLAN
Enable/Disable Option for AToM
Frame Relay to ATM AAL5 MPLS IP
L2TPv3 (12000 series only)
Frame Relay to Ethernet or VLAN MPLS IP
L2TPv3 Ethernet
Frame Relay to PPP MPLS IP
L2TPv3
Note: On the Cisco 12000 series Internet router:
Ethernet (bridged) interworking is not supported for L2TPv3.
IP (routed) interworking is not supported in an L2TPv3 pseudowire configured for data
sequencing (using the sequencing command).
1. With the L2VPN Interworking: VLAN Enable/Disable Option for AToM feature, VLAN interworking can also be supported.
For more information, see the VLAN Interworking section on page 13.
Static IP Addresses for L2VPN Interworking for PPP

If the PE router needs to perform address resolution with the local CE router for PPP, you can configure
the remote CE routers IP address on the PE router. Issue the ppp ipcp address proxy command with
the remote CE routers IP address on the PE routers xconnect PPP interface. The following example
shows a sample configuration:
pseudowire-class ip-interworking
encapsulation mpls
interworking ip
interface Serial2/0
encapsulation ppp
xconnect 10.0.0.2 200 pw-class ip-interworking
ppp ipcp address proxy 10.65.32.14
You can also configure the remote CE routers IP address on the local CE router with the peer default
ip address command if the local CE router performs address resolution.
Book Title
14
L2VPN Interworking
How to Configure L2VPN Interworking

The following sections explain the tasks you can perform to configure L2VPN Interworking:
Configuring L2VPN Interworking, page 15 (required)
Verifying the L2VPN Interworking Configuration, page 16 (optional)
Configuring L2VPN Interworking: VLAN Enable/Disable Option for AToM, page 19 (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 or L2TPv3 configuration.
For specific instructions on configuring AToM or L2TPv3, see the following documents:
Layer 2 Tunnel Protocol Version 3
SUMMARY STEPS
1. enable
3. hw-module slot slot-number np mode feature
5. encapsulation {mpls | l2tpv3}
6. interworking {ethernet | ip | vlan}
DETAILED STEPS

Example:
Router> enable
Example:
Book Title
15
L2VPN Interworking

Step 3 hw-module slot slot-number np mode feature (Optional) Enables L2VPN Interworking functionality on
the Cisco 12000 series router.
Example: Note Enter this command only on a Cisco 12000 series
Router(config)# hw-module slot 3 np mode Internet router if you use L2TPv3 for L2VPN
feature Interworking on an ISE (Engine 3) or Engine 5
interface.
In this case, you must first enable the L2VPN
feature bundle on the line card by entering the
hw-module slot slot-number np mode feature
command.
Example:
Router(config)# pseudowire-class class1
Step 5 encapsulation {mpls | l2tpv3} Specifies the tunneling encapsulation, which is either mpls
or l2tpv3.
Example:
Step 6 interworking {ethernet | ip} | vlan} Specifies the type of pseudowire and the type of traffic that
can flow across it.
Example: Note On the Cisco 12000 series Internet router, Ethernet
Router(config-pw)# interworking ip (bridged) interworking is not supported for
L2TPv3.
After you configure the L2TPv3 tunnel
encapsulation for the pseudowire using the
encapsulation l2tpv3 command, you cannot enter
the interworking ethernet command.
Verifying the L2VPN Interworking Configuration

To verify the L2VPN Interworking configuration, you can use the following commands.
SUMMARY STEPS
1. enable
1. show l2tun session all
2. show arp
3. ping
4. show l2tun session interworking
DETAILED STEPS
Step 1 enable
Book Title
16
L2VPN Interworking

Step 2 show l2tun session all (L2TPv3 only)
For L2TPv3, you can verify the L2VPN Interworking configuration using the show l2tun session all
command on the PE routers.
In the following example, the interworking type is shown in bold.
PE1 PE2
Router# show l2tun session all Router# show l2tun session all
Session Information Total tunnels 1 sessions 1 Session Information Total tunnels 1 sessions 1
Session id 15736 is up, tunnel id 35411 Session id 26570 is up, tunnel id 46882
Call serial number is 4035100045 Call serial number is 4035100045
Remote tunnel name is PE2 Remote tunnel name is PE1
Internet address is 10.9.9.9 Internet address is 10.8.8.8
Session is L2TP signalled Session is L2TP signalled
Session state is established, time since Session state is established, time since change 1d22h
change 1d22h 16 Packets sent, 16 received
16 Packets sent, 16 received 1230 Bytes sent, 1230 received
1518 Bytes sent, 1230 received Receive packets dropped:
Receive packets dropped: out-of-order: 0
out-of-order: 0 total: 0
total: 0 Send packets dropped:
Send packets dropped: exceeded session MTU: 0
exceeded session MTU: 0 total: 0
total: 0 Session vcid is 123
Session vcid is 123 Session Layer 2 circuit, type is Ethernet Vlan, name is
Session Layer 2 circuit, type is Ethernet, FastEthernet2/0.1:10
name is FastEthernet1/1/0 Circuit state is UP, interworking type is Ethernet
Circuit state is UP Remote session id is 15736, remote tunnel id 35411
Remote session id is 26570, remote tunnel DF bit off, ToS reflect disabled, ToS value 0, TTL
id 46882 value 255
DF bit off, ToS reflect disabled, ToS value No session cookie information available
0, TTL value 255 FS cached header information:
No session cookie information available encap size = 24 bytes
FS cached header information: 00000000 00000000 00000000 00000000
encap size = 24 bytes 00000000 00000000
00000000 00000000 00000000 00000000 Sequencing is off
00000000 00000000
Sequencing is off
Step 3 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
Internet 10.1.1.7 - 0005.0032.0000 ARPA FastEthernet0/0
Step 4 ping
You can issue the ping command between the CE routers to ensure that data is being sent:
Router# ping 10.1.1.5

Sending 5, 100-byte ICMP Echos to 10.1.1.5, timeout is 2 seconds:
!!!!!
Book Title
17
L2VPN Interworking
Step 5 show l2tun session interworking (L2TPv3 only)

For L2TPv3, you can verify that the interworking type is correctly set using the show l2tun session
interworking command. Enter the command on the PE routers that are performing the interworking
translation.
In Example 1, the PE router performs the raw Ethernet translation. The command output displays
the interworking type with a dash (-).
In Example 2, the PE router performs the Ethernet VLAN translation. The command output displays
the interworking type as ETH.
Example 1 Command Output for Raw Ethernet Translation
Router# show l2tun session interworking
Session Information Total tunnels 1 sessions 1
LocID TunID Peer-address Type IWrk Username, Intf/Vcid, Circuit

15736 35411 10.9.9.9 ETH - 123, Fa1/1/0
Example 2 Command Output for Ethernet VLAN Translation
Router# show l2tun session interworking
Session Information Total tunnels 1 sessions 1
LocID TunID Peer-address Type IWrk Username, Intf/Vcid, Circuit

26570 46882 10.8.8.8 VLAN ETH 123, Fa2/0.1:10
Step 6 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.
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.3 up, line protocol up, Eth VLAN
Ethernet up 10 up
Destination address: 10.9.9.9, VC ID: 123, VC MPLS VC type is Ethernet, interworking type is
status: up Ethernet
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, imposed label stack {16 16}
01:43:33 Create time: 00:00:26, last status change time:
Signaling protocol: LDP, peer 10.9.9.9:0 up 00:00:06
MPLS VC labels: local 16, remote 20 Signaling protocol: LDP, peer 10.8.8.8:0 up
Group ID: local 0, remote 0 MPLS VC labels: local 20, remote 16
MTU: local 1500, remote 1500 Group ID: local 0, remote 0
Remote interface description: MTU: local 1500, remote 1500
Sequencing: receive disabled, send disabled Remote interface description:
VC statistics: Sequencing: receive disabled, send disabled
packet totals: receive 15, send 4184 VC statistics:
byte totals: receive 1830, send 309248 packet totals: receive 5, send 0
packet drops: receive 0, send 0 byte totals: receive 340, send 0
Book Title
18
L2VPN Interworking
Configuring L2VPN Interworking: VLAN Enable/Disable Option for AToM

You can specify the Ethernet VLAN (type 4) by issuing the interworking vlan command in
pseudowire-class configuration mode. This allows the VLAN ID to be included as part of the Ethernet
frame. In releases previous to Cisco IOS Release 12.2(52)SE and Cisco IOS Release 12.2(33)SRE, the
only way to achieve VLAN encapsulation is to ensure the CE router is connected to the PE router through
an Ethernet link.
Restrictions
In Cisco IOS Release 12.2(52)SE and Cisco IOS Release 12.2(33)SRE, the encapsulation command
supports only the mpls keyword. The l2tpv3 keyword is not supported. The interworking command
supports only the ethernet and vlan keywords. The ip keyword is not supported.
Prerequisites
For complete instructions on configuring AToM, see Any Transport over MPLS.
SUMMARY STEPS
1. enable
4. encapsulation {mpls | l2tpv3}
5. interworking {ethernet | ip | vlan}
6. end
7. show mpls l2transport vc [vcid vc-id | vcid vc-id-min vc-id-max] [interface type number
[local-circuit-id]] [destination ip-address | name] [detail]
DETAILED STEPS

Example:
Router> enable
Example:
Example:
Router(config)# pseudowire-class class1
Book Title
19
L2VPN Interworking

Step 4 encapsulation {mpls | l2tpv3} Specifies the tunneling encapsulation, which is either mpls
or l2tpv3.
Example: For the L2VPN Interworking: VLAN Enable/Disable
Router(config-pw)# encapsulation mpls Option for AToM feature, only MPLS encapsulation is
supported.
Step 5 interworking {ethernet | ip | vlan} Specifies the type of pseudowire and the type of traffic that
can flow across it.
Example: For the L2VPN Interworking: VLAN Enable/Disable
Router(config-pw)# interworking vlan Option for AToM feature, specify the vlan keyword.
Step 6 end Exits pseudowire class configuration mode and enters
Example:
Router(config-pw)# end
Step 7 show mpls l2transport vc [vcid vc-id | vcid Displays information about AToM VCs.
vc-id-min vc-id-max] [interface type number
[local-circuit-id]] [destination ip-address |
name] [detail]
Example:
Examples
When the pseudowire on an interface is different from the VC type, the interworking type is displayed
in the show mpls l2transport vc detail command output. In the following example, the pseudowire is
configured on an Ethernet port and VLAN interworking is configured in the pseudowire class. The
relevant output is shown in bold:
PE1# show mpls l2 vc 34 detail

MPLS VC type is Ethernet, interworking type is Eth VLAN
Destination address: 10.1.1.2, VC ID: 34, VC status: down
Output interface: if-?(0), imposed label stack {}
Default path: no route
No adjacency
Signaling protocol: LDP, peer unknown
Status TLV support (local/remote) : enabled/None (no remote binding)
LDP route watch : enabled
Label/status state machine : local standby, AC-ready, LnuRnd
Last local dataplane status rcvd: No fault
Last local SSS circuit status rcvd: No fault
Last local SSS circuit status sent: Not sent
Last local LDP TLV status sent: None
Last remote LDP TLV status rcvd: None (no remote binding)
Last remote LDP ADJ status rcvd: None (no remote binding)
MPLS VC labels: local 2003, remote unassigned
Group ID: local 0, remote unknown
MTU: local 1500, remote unknown
Book Title
20
L2VPN Interworking
Configuration Examples for L2VPN Interworking
VC statistics:
packet drops: receive 0, seq error 0, send 0

The following sections show examples of L2VPN Interworking:
Ethernet to VLAN over L2TPV3 (Bridged): Example, page 21
Ethernet to VLAN over AToM (Bridged): Example, page 22
Frame Relay to VLAN over L2TPV3 (Routed): Example, page 22
Frame Relay to VLAN over AToM (Routed): Example, page 23
Frame Relay to ATM AAL5 over AToM (Routed): Example, page 24
VLAN to ATM AAL5 over AToM (Bridged): Example, page 25
Frame Relay to PPP over L2TPv3 (Routed): Example, page 26
Frame Relay to PPP over AToM (Routed): Example, page 27
Ethernet/VLAN to PPP over AToM (Routed): Example, page 28
Ethernet to VLAN over L2TPV3 (Bridged): Example

The following example shows the configuration of Ethernet to VLAN over L2TPv3:
PE1 PE2
ip cef ip cef
! !
l2tp-class interworking-class l2tp-class interworking-class
authentication authentication
hostname PE1 hostname PE2
password 0 lab password 0 lab
! !
pseudowire-class inter-ether-vlan pseudowire-class inter-ether-vlan
encapsulation l2tpv3 encapsulation l2tpv3
interworking ethernet interworking ethernet
protocol l2tpv3 interworking-class protocol l2tpv3 interworking-class
ip local interface Loopback0 ip local interface Loopback0
! !
! !
interface FastEthernet1/0 interface FastEthernet0/0
xconnect 10.9.9.9 1 pw-class inter-ether-vlan no ip address
!
xconnect 10.8.8.8 1 pw-class inter-ether-vlan
Book Title
21
L2VPN Interworking
Ethernet to VLAN over AToM (Bridged): Example

The following example shows the configuration of Ethernet to VLAN over AToM:
PE1 PE2
ip cef ip cef
! !
mpls ldp router-id Loopback0 force mpls ldp router-id Loopback0 force
! !
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
interface FastEthernet1/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
Frame Relay to VLAN over L2TPV3 (Routed): Example

The following example shows the configuration of Frame Relay to VLAN over L2TPv3:
PE1 PE2
configure terminal configure terminal
ip cef ip routing
frame-relay switching ip cef
! frame-relay switching
! !
interface loopback 0 interface loopback 0
no shutdown no shutdown
! !
pseudowire-class ip pseudowire-class ip
interworking ip interworking ip
ip local interface loopback0 ip local interface loopback0
! !
interface POS1/0 interface FastEthernet1/0/1
encapsulation frame-relay speed 10
clock source internal no shutdown
logging event dlci-status-change !
no shutdown interface FastEthernet1/0/1.6
no fair-queue encapsulation dot1Q 6
! xconnect 10.8.8.8 6 pw-class ip
connect fr-vlan POS1/0 206 l2transport no shutdown
xconnect 10.9.9.9 6 pw-class ip !
! router ospf 10
router ospf 10 network 10.0.0.2 0.0.0.0 area 0
network 10.0.0.2 0.0.0.0 area 0 network 10.9.9.9 0.0.0.0 area 0
network 10.8.8.8 0.0.0.0 area 0
Book Title
22
L2VPN Interworking
Frame Relay to VLAN over AToM (Routed): Example

The following example shows the configuration of Frame Relay to VLAN over AToM:
PE1 PE2
ip cef ip routing
frame-relay switching ip cef
mpls label protocol ldp !
mpls ldp router-id loopback0 mpls label protocol ldp
mpls ip mpls ldp router-id loopback0
! mpls ip
pseudowire-class atom !
encapsulation mpls pseudowire-class atom
interworking ip encapsulation mpls
! interworking ip
interface loopback 0 !
ip address 10.8.8.8 255.255.255.255 interface loopback 0
no shutdown ip address 10.9.9.9 255.255.255.255
! no shutdown
connect fr-vlan POS1/0 206 l2transport !
xconnect 10.9.9.9 6 pw-class atom interface FastEthernet1/0/1.6
xconnect 10.8.8.8 6 pw-class atom
no shutdown
Book Title
23
L2VPN Interworking
Frame Relay to ATM AAL5 over AToM (Routed): Example
Note Frame Relay to ATM AAL5 is available only with AToM in IP mode.
The following example shows the configuration of Frame Relay to ATM AAL5 over AToM:
PE1 PE2
ip cef ip cef
frame-relay switching mpls ip
mpls ip mpls label protocol ldp
mpls label protocol ldp mpls ldp router-id loopback0 force
mpls ldp router-id loopback0 force pseudowire-class fratmip
pseudowire-class fratmip encapsulation mpls
encapsulation mpls interworking ip
interworking ip interface Loopback0
interface Loopback0 ip address 10.22.22.22 255.255.255.255
ip address 10.33.33.33 255.255.255.255 interface ATM 2/0
interface serial 2/0 pvc 0/203 l2transport
encapsulation frame-relay ietf encapsulation aa5snap
frame-relay intf-type dce xconnect 10.33.33.33 333 pw-class fratmip
connect fr-eth serial 2/0 100 l2transport interface POS1/0
xconnect 10.22.22.22 333 pw-class fratmip ip address 10.1.1.2 255.255.255.0
interface POS1/0 crc 32
ip address 10.1.7.3 255.255.255.0 clock source internal
crc 32 mpls ip
clock source internal mpls label protocol ldp
mpls ip router ospf 10
mpls label protocol ldp passive-interface Loopback0
router ospf 10 network 10.22.22.22 0.0.0.0 area 10
passive-interface Loopback0 network 10.1.1.0 0.0.0.255 area 10
network 10.33.33.33 0.0.0.0 area 10
network 10.1.7.0 0.0.0.255 area 10
Book Title
24
L2VPN Interworking
VLAN to ATM AAL5 over AToM (Bridged): Example

The following example shows the configuration of VLAN to ATM AAL5 over AToM:
PE1 PE2
ip cef ip cef
! !
mpls ip mpls ip
mpls ldp router-id Loopback0 mpls ldp router-id Loopback0
! !
pseudowire-class inter-ether pseudowire-class inter-ether
interworking ethernet interworking ethernet
! !
! !
interface ATM1/0.1 point-to-point interface FastEthernet0/0
pvc 0/100 l2transport no ip address
encapsulation aal5snap !
xconnect 10.9.9.9 123 pw-class inter-ether interface FastEthernet0/0.1
! encapsulation dot1Q 10
interface FastEthernet1/0 xconnect 10.8.8.8 123 pw-class inter-ether
xconnect 10.9.9.9 1 pw-class inter-ether !
! router ospf 10
router ospf 10 log-adjacency-changes
log-adjacency-changes network 10.9.9.9 0.0.0.0 area 0
network 10.1.1.1 0.0.0.0 area 0
Book Title
25
L2VPN Interworking
Frame Relay to PPP over L2TPv3 (Routed): Example

The following example shows the configuration of Frame Relay to PPP over L2TPv3:
PE1 PE2
ip cef ip cef
ip routing ip routing
! !
! !
pseudowire-class ppp-fr pseudowire-class ppp-fr
! !
! !
interface FastEthernet1/0/0 interface FastEthernet1/0/0
! !
interface Serial3/0/0 interface Serial3/0/0
no ip address no ip address
encapsulation ppp encapsulation frame-relay
ppp authentication chap frame-relay intf-type dce
! !
ip route 10.0.0.0 255.0.0.0 10.16.1.2 ip route 10.0.0.0 255.0.0.0 10.16.2.2
! !
xconnect 10.2.2.2 1 pw-class ppp-fr connect ppp-fr Serial3/0/0 100 l2transport
ppp ipcp address proxy 10.65.32.14 xconnect 10.1.1.1 100 pw-class ppp-fr
Book Title
26
L2VPN Interworking
Frame Relay to PPP over AToM (Routed): Example

The following example shows the configuration of Frame Relay to PPP over AToM:
PE1 PE2
ip cef ip cef
ip routing ip routing
mpls ldp router-id loopback0 force mpls ldp router-id loopback0 force
! !
! !
pseudowire-class ppp-fr pseudowire-class ppp-fr
! !
! !
interface FastEthernet1/0/0 interface FastEthernet1/0/0
mpls ip mpls ip
label protocol ldp mpls label protocol ldp
! !
interface Serial3/0/0 interface Serial3/0/0
encapsulation ppp encapsulation frame-relay
ppp authentication chap frame-relay intf-type dce
xconnect 10.2.2.2 1 pw-class ppp-fr !
ppp ipcp address proxy 10.65.32.14 ip route 10.0.0.0 255.0.0.0 10.16.2.2
! !
ip route 10.0.0.0 255.0.0.0 10.16.1.2 connect ppp-fr Serial3/0/0 100 l2transport
xconnect 10.1.1.1 100 pw-class ppp-fr
Book Title
27
L2VPN Interworking
Ethernet/VLAN to PPP over AToM (Routed): Example

The following example shows the configuration of Ethernet VLAN to PPP over AToM:
PE1 PE2
mpls ldp router-id Loopback0 mpls ldp router-id Loopback0
mpls ip mpls ip
! !
pseudowire-class ppp-ether pseudowire-class ppp-ether
! !
no shutdown no shutdown
! !
interface POS2/0/1 interface vlan300
no ip address mtu 4470
encapsulation ppp no ip address
no peer default ip address xconnect 10.8.8.8 300 pw-class ppp-ether
ppp ipcp address proxy 10.10.10.1 no shutdown
xconnect 10.9.9.9 300 pw-class ppp-ether !
no shutdown interface GigabitEthernet6/2
switchport
switchport trunk encapsulation dot1q
switchport trunk allowed vlan 300
switchport mode trunk
no shutdown
The following sections provide references related to the L2VPN Interworking feature.
Related Documents
Layer 2 Tunnel Protocol Version 3 Layer 2 Tunnel Protocol Version 3
Cisco 12000 series routers hardware support Cross-Platform Release Notes for Cisco IOS Release 12.0S.
Cisco 7600 series routers hardware support Cisco 7600 Series Routers Documentation Roadmap
Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600
Series Routers
Cisco 3270 series routers hardware support Cisco IOS Software Releases 12.2SE Release Notes
Book Title
28
L2VPN Interworking
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
MIBs
MIBs MIBs Link
RFCs
RFCs Title
Book Title
29
L2VPN Interworking
Description Link
Book Title
30
L2VPN Interworking
Feature Information for L2VPN Interworking

Book Title
31
L2VPN Interworking
Table 6 Feature Information for L2VPN Interworking

L2VPN 12.0(26)S This feature allows disparate attachment circuits to be connected. An interworking
Interworking 12.0(30)S function facilitates the translation between the different Layer 2 encapsulations.
12.0(32)S
This feature was introduced in Cisco IOS Release 12.0(26)S.
12.0(32)SY
12.2(33)SRA In Cisco IOS Release 12.0(30)S, support was added for Cisco 12000 series Internet
12.4(11)T routers.
12.2(33)SXH In Cisco IOS Release 12.0(32)S, support was added on Engine 5 line cards (SIP-401,
12.2(33)SRD SIP-501, SIP-600, and SIP-601) in Cisco 12000 series routers for the following four
12.2(52)SE transport types:
12.2(33)SRE
Ethernet/VLAN to ATM AAL5 Interworking
On the Cisco 12000 series Internet router, support was added for IP Services Engine
(ISE) and Engine 5 line cards that are configured for L2TPv3 tunneling (see Layer 2
Tunnel Protocol Version 3).
In Cisco IOS Release 12.2(33)SRA, support was added for the Cisco 7600 series
routers.
In Cisco IOS Release 12.4(11)T, support was added for the following transport types:
This feature was integrated into Cisco IOS Release 12.2(33)SXH.
In Cisco IOS Release 12.2(33)SRD, support for routed and bridged interworking on
SIP-400 was added for the Cisco 7600 series routers.
In Cisco IOS Release 12.2(52)SE, the L2VPN Interworking: VLAN Enable/Disable
Option for AToM feature was added for the Cisco 3750 Metro switch.
In Cisco IOS Release 12.2(33)SRE, the L2VPN Interworking: VLAN Enable/Disable
Option for AToM feature was added for the Cisco 7600 series router.
The following commands were introduced or modified: interworking
Book Title
32
L2VPN Interworking
coincidental.
Book Title
33
L2VPN Interworking
Book Title
34
L2VPN Pseudowire Redundancy
First Published: April 20, 2005

The L2VPN Pseudowire Redundancy feature lets you 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.

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 5
Configuration Examples for L2VPN Pseudowire Redundancy, page 10
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). You can find that information in the following documents:
L2 VPN Interworking
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

General Restrictions
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.
If you use L2VPN Pseudowire Redundancy with L2VPN Interworking, the interworking method
must be the same for the primary and backup pseudowires.
Setting the experimental (EXP) bit on the Multiprotocol Label Switching (MPLS) pseudowire is
supported.
Different pseudowire encapsulation types on the MPLS pseudowire are not supported.
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.
More than one backup pseudowire is not supported.
Restrictions for Layer 2 Tunnel Protocol Version 3 (L2TPv3) Xconnect Configurations

Interworking is not supported.
Local switching backup by pseudowire redundancy is not supported.
PPP, HDLC, and Frame-Relay attachment circuit (AC) types of L2TPv3 pseudowire redundancy are
not supported.
For the edge interface, only the Cisco 7600 series SPA Interface Processor-400 (SIP-400) linecard
with the following shared port adapters (SPAs) is supported:
Cisco 2-Port Gigabit Ethernet Shared Port Adapter (SPA-2X1GE)
Cisco 2-Port Gigabit Ethernet Shared Port Adapter, Version 2 (SPA-2X1GE-V2)
2
Information About L2VPN Pseudowire Redundancy
Cisco 2-Port OC3c/STM1c ATM Shared Port Adapter (SPA-2XOC3-ATM)

Cisco 1-Port OC-48c/STM-16 ATM Shared Port Adapter (SPA-1XOC48-ATM)

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
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.
3
Figure 2 shows a network with redundant pseudowires and redundant attachment circuits.
Figure 2 L2VPN 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.
Figure 3 L2VPN 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 L2VPN 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
4
How to Configure L2VPN Pseudowire Redundancy

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.
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.
The following sections explain how to configure the L2VPN Pseudowire Redundancy feature:
Configuring the Pseudowire, page 5 (required)
Configuring L2VPN Pseudowire Redundancy, page 6 (required)
Forcing a Manual Switchover to the Backup Pseudowire VC, page 8 (optional)
Verifying the L2VPN Pseudowire Redundancy Configuration, page 8 (optional)
Configuring the Pseudowire

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:
Encapsulation type
Control protocol
Payload-specific options
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
5. interworking {ethernet | ip}
5
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 pseudowire-class name Establishes a pseudowire class with a name that you specify. Enters
Example:
Step 4 encapsulation mpls Specifies the tunneling encapsulation. For AToM, the encapsulation
type is mpls.
Example:
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 L2VPN Pseudowire Redundancy

Use the following steps to configure the L2VPN Pseudowire Redundancy feature.
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 gigabitethernetslot/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}
6
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface Specifies the Gigabit Ethernet subinterface and enters
gigabitethernetslot/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.
Router(config)# interface gigabitethernet0/0/0.1
packets.
Example: The subinterfaces between the CE and PE routers that
Router(config-subif)# encapsulation dot1q 100 are 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:
Router(config-subif)# xconnect 10.0.0.1 123
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.
7
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 {interface-info | peer ip-address vcid}
DETAILED STEPS

Example:
Router> enable
Step 2 xconnect backup force-switchover {interface Specifies that the router should switch to the backup or
interface-info | peer ip-address vcid} to the primary pseudowire.
Example:
Router# xconnect backup force-switchover peer
10.10.10.1 123
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:

------------- ----------------------- --------------- ---------- ----------
Et0/0.1 Eth VLAN 101 10.0.0.2 101 UP
8
Et0/0.1 Eth VLAN 101 10.0.0.3 201 DOWN
Local interface: Et0/0.1 up, line protocol up, Eth VLAN 101 up
Destination address 10.0.0.2 VC ID: 101, VC status UP
.
.
.
Local interface: Et0/0.1 down, line protocol down, Eth 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 Et0/0(Ethernet) UP mpls 10.55.55.2:1000 UP
IA sec ac Et0/0(Ethernet) 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
------+---------------------------------+--+---------------------------------+--
UP pri ac Se6/0:150(FR DLCI) UP ac Se8/0:150(FR DLCI) UP
IA sec ac Se6/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
9
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), L2VPN Interworking, and Layer 2 Local Switching features.
L2VPN Pseudowire Redundancy and AToM (Like to Like): Examples, page 10
L2VPN Pseudowire Redundancy and L2VPN Interworking: Examples, page 10
L2VPN Pseudowire Redundancy with Layer 2 Local Switching: Examples, page 11
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:
interface Serial4/0
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 225 l2transport
xconnect 10.55.55.2 5225 pw-class mpls
L2VPN Pseudowire Redundancy and L2VPN Interworking: Examples

The following example shows an 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 Ethernet VLAN attachment circuit xconnect with L2VPN IP
interworking and a backup pseudowire:
interface Ethernet1/0.1
The following example shows a Frame Relay attachment circuit xconnect with L2VPN IP interworking
and a backup pseudowire:
10
connect fr-ppp-pw Serial6/0 250 l2transport

The following example shows a PPP attachment circuit xconnect with L2VPN IP interworking and a
backup pseudowire:
interface Serial7/0
encapsulation ppp
L2VPN Pseudowire Redundancy with Layer 2 Local Switching: Examples

The following example shows an Ethernet VLAN-VLAN local switching xconnect with a pseudowire
backup for Ethernet segment E2/0.2. If the subinterface associated with E2/0.2 goes down, the backup
pseudowire is activated.
connect vlan-vlan Ethernet1/0.2 Ethernet2/0.2
The following example shows a Frame Relay-to-Frame Relay local switching connect with a pseudowire
backup for Frame Relay segment S8/0 150. If data-link connection identifier (DLCI) 150 on S8/0 goes
down, the backup pseudowire is activated.
connect fr-fr-ls Serial6/0 150 Serial8/0 150
11
The following sections provide references related to the L2VPN Pseudowire Redundancy feature.
Related Documents
High Availability for AToM AToM Graceful Restart
L2VPN Interworking L2VPN Interworking
Layer 2 local switching Layer 2 Local Switching
PWE3 MIB Pseudowire Emulation Edge-to-Edge MIBs for Ethernet and Frame
Relay Services
Packet sequencing Any Transport over MPLS (AToM) Sequencing Support
Standards
Standards Title
None
MIBs
MIBs MIBs Link
following URL:
RFCs
RFCs Title
None
12
Command Reference
Description Link
Command Reference
backup delay (L2VPN local switching)
backup peer
show xconnect
xconnect backup force-switchover
xconnect logging redundancy
13
Feature Information for L2VPN Pseudowire Redundancy

14
Table 1 Feature Information for L2VPN Pseudowire Redundancy

L2VPN Pseudowire Redundancy 12.0(31)S This feature enables you to set up your network to detect
12.2(28)SB a failure in the network and reroute the Layer 2 service to
12.4(11)T another endpoint that can continue to provide service.
12.2(33)SRB
In Cisco IOS Release 12.0(31)S, the L2VPN Pseudowire
12.2(22)SXI
Redundancy feature was introduced for Any Transport
Cisco IOS XE
over MPLS (AToM) on the Cisco 12000 series routers.
Release 2.3
Release 12.2(28)SB.
Release 12.4(11)T.
Release 12.2(33)SRB.
Release 12.2(33)SXI.
In Cisco IOS XE Release 2.3, this feature was implemented
on the Cisco ASR 1000 series routers.
feature:
Introduction to L2VPN Pseudowire Redundancy,
page 3
Configuring the Pseudowire, page 5
Configuring L2VPN Pseudowire Redundancy, page 6
Forcing a Manual Switchover to the Backup
Pseudowire VC, page 8
Verifying the L2VPN Pseudowire Redundancy
Configuration, page 8
backup delay (L2VPN local switching), backup peer,
show xconnect, xconnect backup force-switchover,
xconnect logging redundancy.
L2VPN Pseudowire Redundancy for 12.2(33)SRE This feature provides L2VPN pseudowire redundancy for
L2TPv3 L2TPv3 xconnect configurations.
implemented on the Cisco 7600 series routers.
15
coincidental.
16
First Published: April 20, 2005

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. The feature supports ATM and
time-division multiplexing (TDM) attachment circuits (ACs) and Ethernet ACs.

supported, see the Feature Information for L2VPN Pseudowire Switching section on page 15.
Contents
Prerequisites for L2VPN Pseudowire Switching, page 2
Restrictions for L2VPN Pseudowire Switching, page 2
Information About L2VPN Pseudowire Switching, page 2
How to Configure L2VPN Pseudowire Switching, page 4
Configuration Examples for L2VPN Pseudowire Switching, page 7
Feature Information for L2VPN Pseudowire Switching, page 15
Prerequisites for L2VPN Pseudowire Switching
Prerequisites for L2VPN Pseudowire Switching

For the Cisco 12000 series routers, the L2VPN Pseudowire Switching feature for Any Transport over
MPLS (AToM) is supported on the following engines:
E2
E3
E4+
E5
E6
For engines that do not support this feature, the packets are sent to the software and forwarded through
the slow path.
Note Engines E1 and E4 do not support L2VPN Pseudowire Switching, even in the slow path.
Restrictions for L2VPN Pseudowire Switching

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 provider-edge (PE) to customer-edge (CE) connections
enforce the sequencing.
You can ping the adjacent next-hop PE router. End-to-end label switched path (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 label distribution protocol (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 3
How Packets Are Manipulated at the L2VPN Pseudowire Switching Aggregation Point, page 3
2
Information About L2VPN Pseudowire Switching
How L2VPN Pseudowire Switching Works

L2VPN Pseudowire Switching allows the user to extend L2VPN pseudowires across two separate MPLS
networks or across an inter-AS boundary, 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.
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.
3
How to Configure L2VPN Pseudowire Switching
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 to 1.
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.

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 interautonomous 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]
4
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
Step 4 neighbor ip-address vcid [encapsulation mpls | Configures an emulated VC.
pw-class pw-class-name]
Specify the IP address and the VC ID of the remote
router.
Example:
Router(config-vfi)# neighbor 10.0.0.1 100
Also specify the pseudowire class to use for the
pw-class mpls emulated VC.
Note Only two neighbor commands are allowed for each
l2 vfi point-to-point command.
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:
5

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, verifies end-to-end
system-address} connectivity.
Example:
Examples
The following example displays output from 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 output from 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
6
Configuration Examples for L2VPN Pseudowire Switching

This section provides the following configuration example:
L2VPN Pseudowire Switching in an Inter-AS Configuration: Example, page 7
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.
7
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 S0/0
S0/0 S0/0 S1/0 S1/0 .2 .1
.2 S1/0 PE-agg1 PE-agg2 S1/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 S1/0 .1
PE1 PE2
e0/0 e0/0
e0/0 .1 .2 e0/0
135250
CE1 10.0.0.0/30 10.0.0.0/30 CE2
8
PE-agg-1 PE-agg-2
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 [pe-agg1] hostname [pe-agg2]
! !
boot-start-marker boot-start-marker
boot-end-marker boot-end-marker
! !
enable secret 5 $1$Q0Bb$32sIU82pHRgyddWaeB4zs/ enable secret 5 $1$32jd$zQRfxXzjstr4llV9DcWf7/
! !
ip subnet-zero ip subnet-zero
ip cef ip cef
no ip domain-lookup no ip domain-lookup
pseudowire-class SW-PW pseudowire-class SW-PW
! !
l2 vfi PW-SWITCH-1 point-to-point l2 vfi PW-SWITCH-1 point-to-point
neighbor 172.17.255.3 100 pw-class SW-PW neighbor 172.16.255.3 100 pw-class SW-PW
neighbor 172.16.255.1 16 pw-class SW-PW neighbor 172.17.255.1 17 pw-class SW-PW
! !
! !
interface Serial0/0 interface Serial0/0
mpls ip mpls ip
! !
mpls bgp forwarding mpls bgp forwarding
! !
router ospf 16 router ospf 17
log-adjacency-changes log-adjacency-changes
! !
router bgp 65016 router bgp 65017
no synchronization no synchronization
bgp log-neighbor-changes bgp log-neighbor-changes
network 172.16.255.3 mask 255.255.255.255 network 172.17.255.3 mask 255.255.255.255
neighbor 192.168.0.2 remote-as 65017 neighbor 192.168.0.1 remote-as 65016
neighbor 192.168.0.2 send-label neighbor 192.168.0.1 send-label
no auto-summary no auto-summary
! !
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
9
A-P1 B-P1
! !
hostname [a-p1] hostname [b-p1]
! !
! !
enable secret 5 $1$eiUn$rTMnZiYnJxtMTpO0NKpQQ/ enable secret 5 $1$svU/$2JmJZ/5gxlW4nVXVniIJe1
! !
ip cef ip cef
! !
! !
mpls ip mpls ip
! !
mpls ip mpls ip
! !
! !
! !
! !
login login
! !
end end
10
PE1 PE2
! !
hostname [pe1] hostname [pe2]
! !
! !
enable secret 5 $1$9z8F$2A1/YLc6NB6d.WLQXF0Bz1 enable secret 5 $1$rT.V$8Z6Dy/r8/eaRdx2TR/O5r/
! !
ip cef ip cef
pseudowire-class ETH-PW pseudowire-class ETH-PW
! !
! !
interface Ethernet0/0 interface Ethernet0/0
no cdp enable no cdp enable
xconnect 172.16.255.3 16 pw-class ETH-PW xconnect 172.17.255.3 17 pw-class ETH-PW
! !
mpls ip mpls ip
! !
! !
! !
! !
login login
! !
end end
11
CE1 CE2
! !
hostname [ce1] hostname [ce2]
! !
! !
enable secret 5 $1$o9N6$LSrxHufTn0vjCY0nW8hQX. enable secret 5 $1$YHo6$LQ4z5PdrF5B9dnL75Xvvm1
! !
ip cef ip cef
! !
interface Ethernet0/0 interface Ethernet0/0
! !
! !
! !
login login
! !
end end
The following sections provide references related to L2VPN Pseudowire Switching.
12
Related Documents
Pseudowire redundancy L2VPN Pseudowire Redundancy
High availability for AToM AToM Graceful Restart
L2VPN interworking L2VPN Interworking
Layer 2 local switching Layer 2 Local Switching
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
CISCO-IETF-PW-MPLS-MIB releases, and feature sets, use Cisco MIB Locator found at the
following URL:
CISCO-IETF-PW-ENET-MIB
CISCO-IETF-PW-FR-MIB
RFCs
RFCs Title
None
13
Description Link
14
Feature Information for L2VPN Pseudowire Switching

features that were introduced or modified in Cisco IOS Releases 12.2(28)SB or 12.2(33)SRB or a later
release appear in the table
Table 1 Feature Information for L2VPN Pseudowire Switching

L2VPN Pseudowire Switching 12.0(31)S This feature configures L2VPN Pseudowire Switching, which
12.2(28)SB extends L2VPN pseudowires across an interautonomous
12.2(33)SRB system (inter-AS) boundary or across two separate MPLS
12.2(33)SRD2 networks.
12.2(33)SRE
In Cisco IOS Release 12.2(28)SB, support was added for
the Cisco 7200 and 7301 series routers.
In 12.2(33)SRD2, support was added for ATM and TDM
ACs.
The following commands were introduced or modified: l2
vfi point-to-point, neighbor (L2VPN Pseudowire
Switching), show vfi.
15
coincidental.
16
VPLS Autodiscovery: BGP Based

VPLS Autodiscovery enables each Virtual Private LAN Service (VPLS) provider edge (PE) router to
discover which other PE routers are part of the same VPLS domain. VPLS Autodiscovery also
automatically detects when PE routers are added to or removed from the VPLS domain. You no longer
need to manually configure the VPLS and maintain the configuration when a PE router is added or
deleted. VPLS Autodiscovery uses the Border Gateway Protocol (BGP) to discover the VPLS members
and to set up and tear down pseudowires in the VPLS.

supported, see the Feature Information for VPLS Autodiscovery: BGP Based section on page 16.
Contents
Prerequisites for VPLS Autodiscovery: BGP Based, page 2
Restrictions for VPLS Autodiscovery: BGP Based, page 2
Information About VPLS Autodiscovery: BGP Based, page 3
How to Configure VPLS Autodiscovery: BGP Based, page 5
Configuration Examples for VPLS Autodiscovery: BGP Based, page 11
Feature Information for VPLS Autodiscovery: BGP Based, page 16

Prerequisites for VPLS Autodiscovery: BGP Based
Prerequisites for VPLS Autodiscovery: BGP Based

Before configuring VPLS Autodiscovery, if you are using a Cisco 7600 series router, perform the
Cisco 7600 router-specific tasks listed in the section called Virtual Private LAN Services on the Optical
Service Modules in the Cisco 7600 Series Router IOS Software Configuration Guide, 12.2SR.
Restrictions for VPLS Autodiscovery: BGP Based

VPLS Autodiscovery supports only IPV4 addresses.
VPLS Autodiscovery uses Forwarding Equivalence Class (FEC) 129 to convey endpoint
information. Manually configured pseudowires use FEC 128.
VPLS Autodiscovery is not supported with Layer 2 Tunnel Protocol Version 3 (L2TPv3).
VPLS Autodisocovery is not supported with interautonomous system configurations.
You can configure both autodiscovered and manually configured pseudowires in a single virtual
forwarding instance (VFI). However, the pseudowires cannot go to the same peer PE router.
If you manually configure a neighbor using the neighbor (VPLS) command after you have enabled
VPLS Autodiscovery and both peers are in autodiscovery mode, manually configure the route target
(RT) values to prevent each peer from receiving discovery data for that VPLS.
If you manually configure multiple pseudowires and target different IP addresses on the same PE
router for each pseudowire, do not use the same virtual circuit identifier (VC ID) to identify the
pseudowires terminated at the same PE router.
You cannot configure a pseudowire by manually configuring a neighbor on one PE router and using
autodiscovery on the other PE router to configure the same pseudowire in the other direction.
Tunnel selection is not supported with autodiscovered neighbors.
You can have up to 16 route targets only per VFI.
The same RT is not allowed in multiple VFIs in the same PE router.
The BGP autodiscovery process does not support dynamic hierarchical VPLS. User-facing PE
(U-PE) routers cannot discover the network-facing PE (N-PE) routers, and N-PE routers cannot
discover U-PE routers.
Pseudowires for autodiscovered neighbors are provisioned with split horizon enabled. Therefore,
manually configure the pseudowires for hierarchical VPLS. Make sure the U-PE routers do not
participate in BGP autodiscovery for those pseudowires.
Do not disable split horizon on autodiscovered neighbors. Split horizon is required with VPLS
Autodiscovery.
The provisioned peer address must be a /32 address bound to the peers Label Distribution Protocol
(LDP) router ID.
The peer PE router must be able to access the IP address that is used as the local LDP router ID.
Even though the IP address need not be used in the xconnect command on the peer PE router, that
IP address must be reachable.
VPLS Autodiscovery is supported on the Cisco 7600 router hardware. For details on supported
shared port adapters and line cards, see the following documents:
Cisco 7600 Series Router Cisco IOS Software Configuration Guide
Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600 Series Routers
2
Information About VPLS Autodiscovery: BGP Based

To understand VPLS Autodiscovery, you should understand the following concepts:
How the VPLS Feature Works, page 3
How the VPLS Autodiscovery: BGP Based Feature Works, page 3
How Enabling VPLS Autodiscovery Differs from Manually Configuring VPLS, page 3
Show Commands Affected by VPLS Autodiscovery: BGP Based, page 4
BGP VPLS Autodiscovery Support on a Route Reflector, page 4
How the VPLS Feature Works

VPLS allows Multiprotocol Label Switching (MPLS) networks to provide multipoint Ethernet LAN
services, also known as Transparent LAN Services (TLS). All customer sites in a VPLS appear to be on
the same LAN, even though those sites might be in different geographic locations.
How the VPLS Autodiscovery: BGP Based Feature Works

VPLS Autodiscovery enables each VPLS PE router to discover the other PE routers that are part of the
same VPLS domain. VPLS Autodiscovery also tracks when PE routers are added to or removed from the
VPLS domain. The autodiscovery and signaling functions use BGP to find and track the PE routers.
BGP uses the L2VPN Routing Information Base (RIB) to store endpoint provisioning information,
which is updated each time any Layer 2 VFI is configured. Prefix and path information is stored in the
L2VPN database, allowing BGP to make decisions on the best path. When BGP distributes the endpoint
provisioning information in an update message to all its BGP neighbors, the endpoint information is used
to configure a pseudowire mesh to support L2VPN-based services.
The BGP autodiscovery mechanism facilitates the configuration of L2VPN services, which are an
integral part of the Cisco IOS Virtual Private LAN Service (VPLS) feature. VPLS enables flexibility in
deploying services by connecting geographically dispersed sites as a large LAN over high-speed
Ethernet in a robust and scalable IP MPLS network. For more information about BGP and the L2VPN
address family in relation to VPLS Autodiscovery, see the following documents:
The section called L2VPN Address Family in the Cisco BGP Overview.
The document called BGP Support for the L2VPN Address Family
How Enabling VPLS Autodiscovery Differs from Manually Configuring VPLS

With VPLS Autodiscovery, you no longer need to manually set up the VPLS. The commands you use to
set up VPLS Autodiscovery are similar to those you use to manually configure a VPLS, as shown in
Table 1. VPLS Autodiscovery uses neighbor commands in L2VPN address family mode to distribute
endpoint information to configure a pseudowire.
3
Table 1 VPLS Autodiscovery Configuration versus Manual VPLS Configuration
Manual Configuration of VPLS VPLS Autodiscovery: BGP Based
l2 vfi vpls1 manual l2 vfi vpls1 autodiscovery

vpn id 100 vpn id 100
neighbor 10.10.10.1 encapsulation mpls exit
neighbor 10.10.10.0 encapsulation mpls
exit router bgp 1
no bgp default ipv4-unicast
bgp log-neighbor-changes
bgp update-delay 1
neighbor 10.1.1.2 remote-as 1
neighbor 10.1.1.2 update-source Loopback1
.
.
.
address-family l2vpn vpls
neighbor 10.1.1.2 activate
neighbor 10.1.1.2 send-community extended
exit-address-family
When you configure VPLS Autodiscovery, you enter the l2vfi autodiscovery command. This command
allows the VFI to learn and advertise the pseudowire endpoints. As a result, you no longer need to enter
the neighbor (VPLS) command in L2 VFI configuration mode.
However, the neighbor (VPLS) command is still supported with VPLS Autodiscovery in L2 VFI
command mode. You can use the neighbor (VPLS) command to allow PE routers that do not participate
in the autodiscovery process to join the VPLS. You can also use the neighbor (VPLS) command with
PE routers that have been configured using the Tunnel Selection feature. You can also use the neighbor
(VPLS) command in hierarchical VPLS configurations that have U-PE routers that do not participate in
the autodiscovery process and have split-horizon forwarding disabled.
Show Commands Affected by VPLS Autodiscovery: BGP Based

VPLS Autodiscovery changes the following show commands:
The show mpls l2transport vc command with the detail keyword has been updated to include FEC
129 signaling information for the autodiscovered VPLS pseudowires.
The show vfi command now displays information related to autodiscovered VFIs. The new
information includes the VPLS ID, the route distinguisher (RD), the RT, and the router IDs of the
discovered peers.
The show xconnect command has been updated with the rib keyword to provide RIB information
about the pseudowires.
BGP VPLS Autodiscovery Support on a Route Reflector

VPLS Autodiscovery is normally run on PE routers to support endpoint discovery and the setup of
pseudowires between the PEs (typically a full mesh). VPLS does not normally run on a BGP route
reflector. In Cisco IOS Release 12.2(33)SRE, VPLS Autodiscovery support was added to route
reflectors. The BGP route reflector can be used to reflect the BGP VPLS prefixes without having VPLS
explicitly configured on the route reflector.
4
How to Configure VPLS Autodiscovery: BGP Based
The route reflector does not participate in the autodiscovery, meaning that no pseudowires are set up
between the route reflector and the PEs. The route reflector reflects the VPLS prefixes to other PEs, so
that the PEs do not need to have a full mesh of BGP sessions. The network administrator configures only
the BGP VPLS address family on the route reflector. For an example configuration of VPLS
autodiscovery support on a route reflector, see the BGP VPLS Autodiscovery Support on Route
Reflector: Example section on page 13.

To configure VPLS Autodiscovery, perform the following tasks:
Enabling VPLS Autodiscovery: BGP Based, page 5 (required)
Configuring BGP to Enable VPLS Autodiscovery, page 6 (required)
Customizing the VPLS Autodiscovery Settings, page 9 (optional)
Enabling VPLS Autodiscovery: BGP Based

Perform the following task to enable each VPLS PE router to discover the other PE routers that are part
of the same VPLS domain.
Prerequisites
Before configuring VPLS Autodiscovery, perform the Cisco 7600 router-specific tasks listed in the
Virtual Private LAN Services on the Optical Services Modules chapter in the Cisco 7600 Series Router
Cisco IOS Software Configuration Guide, Release 12.2SR.
SUMMARY STEPS
1. enable
3. l2 vfi vfi-name autodiscovery
4. vpn id vpn-id
5. exit
DETAILED STEPS

Example:
Router> enable
Example:
5

Step 3 l2 vfi vfi-name autodiscovery Enables VPLS Autodiscovery on the PE router and enters
L2 VFI configuration mode.
Example:
Router(config)# l2 vfi vpls1 autodiscovery
Step 4 vpn id vpn-id Configures a VPN ID for the VPLS domain.
Example:
Router(config-vfi)# vpn id 10
Step 5 exit Exits L2 VFI configuration mode. Commands take effect
after the router exits L2 VFI configuration mode.
Example:
Configuring BGP to Enable VPLS Autodiscovery

In Cisco IOS Release 12.2(33)SRB, the BGP L2VPN address family was introduced with a separate
L2VPN RIB that contains endpoint provisioning information for VPLS Autodiscovery. BGP learns the
endpoint provisioning information from the L2VPN database which is updated each time a Layer 2
virtual forwarding instance (VFI) is configured. When BGP distributes the endpoint provisioning
information in an update message to all its BGP neighbors, the endpoint information is used to configure
a pseudowire mesh to support aL2VPN-based services.
SUMMARY STEPS
1. enable
3. router bgp autonomous-system-number
4. no bgp default ipv4-unicast
5. bgp log-neighbor-changes
6. neighbor {ip-address | peer-group-name} remote-as autonomous-system-number
7. neighbor {ip-address | peer-group-name} update-source interface
8. Repeat Step 6 and Step 7 to configure other BGP neighbors.
9. address-family l2vpn [vpls]
10. neighbor {ip-address | peer-group-name} activate
11. neighbor {ip-address | peer-group-name} send-community [both | standard | extended]
12. Repeat Step 10 and Step 11 to activate other BGP neighbors under L2VPN address family.
13. exit-address-family
14. exit
15. exit
16. show vfi
17. show ip bgp l2vpn vpls {all | rd vpn-rd}
6
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp autonomous-system-number Enters router configuration mode for the specified routing
process.
Example:
Router(config)# router bgp 65000
Step 4 no bgp default ipv4-unicast Disables the IPv4 unicast address family for the BGP
routing process.
Example: Note Routing information for the IPv4 unicast address
Router(config-router)# no bgp default family is advertised by default for each BGP routing
ipv4-unicast session configured with the neighbor remote-as
router configuration command unless you configure
the no bgp default ipv4-unicast router
configuration command before configuring the
neighbor remote-as command. Existing neighbor
configurations are not affected.
Step 5 bgp log-neighbor-changes Enables logging of BGP neighbor resets.
Example:
Router(config-router)# bgp log-neighbor-changes
Step 6 neighbor {ip-address | peer-group-name} Adds the IP address or peer group name of the neighbor in
remote-as autonomous-system-number the specified autonomous system to the IPv4 multiprotocol
BGP neighbor table of the local router.
Example: If the autonomous-system-number argument matches
Router(config-router)# neighbor 10.10.10.1 the autonomous system number specified in the router
remote-as 65000
bgp command, the neighbor is an internal neighbor.
If the autonomous-system-number argument does not
match the autonomous system number specified in the
router bgp command, the neighbor is an external
neighbor.
In this example, the neighbor at 10.10.10.1 is an
internal BGP neighbor.
7

Step 7 neighbor {ip-address | peer-group-name} (Optional) Configures a router to select a specific source or
update-source interface-type interface-number interface to receive routing table updates.
This example uses a loopback interface. The advantage
Example: to this configuration is that the loopback interface is not
Router(config-router)# neighbor 10.10.10.1 affected by the effects of a flapping interface.
update-source loopback1
Step 8 Repeat Step 6 and Step 7 to configure other BGP
neighbors
Step 9 address-family l2vpn [vpls] Specifies the L2VPN address family and enters address
family configuration mode.
Example: The optional vpls keyword specifies that VPLS
Router(config-router)# address-family l2vpn endpoint provisioning information is to be distributed
vpls to BGP peers.
In this example, an L2VPN VPLS address family
session is created.
Step 10 neighbor {ip-address | peer-group-name} Enables the neighbor to exchange information for the
activate L2VPN VPLS address family with the local router.
Example:
Router(config-router-af)# neighbor 10.10.10.1
activate
Step 11 neighbor {ip-address | peer-group-name} Specifies that a communities attribute should be sent to a
send-community {both | standard | extended} BGP neighbor.
In this example, an extended communities attribute is
Example: sent to the neighbor at 10.10.10.1.
send-community extended
Step 12 Repeat Step 10 and Step 11 to activate other BGP
neighbors under an L2VPN address family.
Step 13 exit-address-family Exits address family configuration mode and returns to
Example:
Router(config-router-af)# exit-address-family
Step 14 exit Exits router configuration mode.
Example:
Step 15 exit Exits privileged EXEC mode.
Example:
8

Step 16 show vfi (Optional) Displays information about the configured VFI
instances.
Example:
Router# show vfi
Step 17 show ip bgp l2vpn vpls {all | rd vpn-rd} (Optional) Displays information about the Layer2 VPN
VPLS address family.
Example:
Router# show ip bgp l2vpn vpls all
Customizing the VPLS Autodiscovery Settings

Several commands allow you to customize the VPLS environment. You can specify identifiers for the
VPLS domain, the route distinguisher, the route target, and the PE router. Perform the following steps
to customize these settings.
SUMMARY STEPS
1. enable
3. l2 vfi vfi-name autodiscovery
4. vpn id vpn-id
5. vpls-id {autonomous-system-number:nn | ip-address:nn}
6. rd {autonomous-system-number:nn | ip-address:nn}
7. route-target [import | export | both] {autonomous-system-number:nn| ip-address:nn}
8. l2 router-id ip-address
9. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 l2 vfi vfi-name autodiscovery Enables VPLS Autodiscovery on the PE router and enters
L2 VFI configuration mode.
Example:
Router(config)# l2 vfi vpls1 autodiscovery
9

Step 4 vpn id vpn-id Configures a VPN ID for the VPLS domain.
Example:
Step 5 vpls-id {autonomous-system-number:nn | (Optional) Specifies the VPLS domain. This command is
ip-address:nn} optional, because VPLS Autodiscovery automatically
generates a VPLS ID using the BGP autonomous system
Example: number and the configured VFI VPN ID. You can use this
Router(config-vfi)# vpls-id 5:300 command to change the automatically generated VPLS ID.
There are two formats for configuring the VPLS ID
argument. It can be configured in the
autonomous-system-number:network number (ASN:nn)
format, as shown in the example, or it can be configured in
the IP-address:network number format (IP-address:nn).
Step 6 rd {autonomous-system-number:nn | (Optional) Specifies the RD to distribute endpoint
ip-address:nn} information. This command is optional, because VPLS
Autodiscovery automatically generates an RD using the
Example: BGP autonomous system number and the configured VFI
Router(config-vfi)# rd 2:3 VPN ID. You can use this command to change the
automatically generated route distinguisher.
There are two formats for configuring the route
distinguisher argument.It can be configured in the
Step 7 route-target [import | export | both] (Optional) Specifies the route target (RT). This command is
{autonomous-system-number:nn | ip-address:nn} optional, because VPLS Autodiscovery automatically
generates a route target using the lower 6 bytes of the RD
Example: and VPLS ID. You can use this command to change the
Router(config-vfi)# route-target 600:2222 automatically generated route target.
There are two formats for configuring the route target
argument. It can be configured in the
Step 8 l2 router-id ip-address (Optional) Specifies a unique identifier for the PE router.
This command is optional, because VPLS Autodiscovery
automatically generates a Layer 2 router ID using the MPLS
Example:
Router(config-vfi)# l2 router-id 10.10.10.10
global router ID. You can use this command to change the
automatically generated ID.
Step 9 exit Exits L2 VFI configuration mode. Commands take effect
after the router exits L2 VFI configuration mode.
Example:
10
Configuration Examples for VPLS Autodiscovery: BGP Based

The following examples shows the configuration of a network using VPLS Autodiscovery and VPLS
Autodiscovery supported on a route reflector:
VPLS Autodiscovery: BGP Based: Basic Example, page 11
BGP VPLS Autodiscovery Support on Route Reflector: Example, page 13
VPLS Autodiscovery: BGP Based: Basic Example

Figure 1 show a basic configuration of VPLS Autodiscovery.
Figure 1 Basic VPLS Autodiscovery Configuration
Service Provider
Backbone
PE1 PE3
10.1.1.1 10.1.1.3
230428
PE2
10.1.1.2
PE1
l2 router-id 10.1.1.1
l2 vfi auto autodiscovery
vpn id 100
!
encapsulation mpls
!
interface Loopback1
ip address 10.1.1.1 255.255.255.255
!
description Backbone interface
ip address 192.168.0.1 255.255.255.0
mpls ip
!
router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 172.16.0.0 0.0.0.255 area 0
!
router bgp 1
bgp update-delay 1
11

!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
exit-address-family
PE2
vpn id 100
!
encapsulation mpls
!
interface Loopback1
ip address 10.1.1.2 255.255.255.255
!
ip address 192.168.0.2 255.255.255.0
mpls ip
!
router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 172.16.0.0 0.0.0.255 area 0
!
router bgp 1
bgp update-delay 1
!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
exit-address-family
12
PE3
vpn id 100
!
encapsulation mpls
!
interface Loopback1
ip address 10.1.1.3 255.255.255.255
!
ip address 192.168.0.3 255.255.255.0
mpls ip
!
router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 172.16.0.0 0.0.0.255 area 0
!
router bgp 1
bgp update-delay 1
!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
exit-address-family
BGP VPLS Autodiscovery Support on Route Reflector: Example

In the following example, a host named PE-RR (indicating Provider Edge-Route Reflector) is configured
as a route reflector capable of reflecting VPLS prefixes. The VPLS address family is configured by
address-family l2vpn vpls below.
hostname PE-RR
!
router bgp 1
bgp router-id 1.1.1.3
no bgp default route-target filter
neighbor iBGP_PEERS peer-group
neighbor iBGP_PEERS remote-as 1
neighbor iBGP_PEERS update-source Loopback1
neighbor 1.1.1.1 peer-group iBGP_PEERS
!
13

neighbor iBGP_PEERS send-community extended
neighbor iBGP_PEERS route-reflector-client
exit-address-family
The following sections provide references related to the VPLS Autodiscovery: BGP Based feature.
Related Documents
Virtual Private LAN Services on the Virtual Private LAN Services on the Optical Services Modules chapter in the
Cisco 7600 series router Cisco 7600 Series Router Cisco IOS Software Configuration Guide, Release
12.2SR
L2 VPNs on the Cisco 7600 router Configuration information for Layer 2 VPNs on the Cisco 7600 router is included
in the following documents:
The Configuring PFC3BXL and PFC3B Mode Multiprotocol Label
Switching module of the Cisco 7600 Series Cisco IOS Software
Configuration Guide, Release 12.2SR
The Configuring Multiprotocol Label Switching on the Optical Services
Modules module of the OSM Configuration Note, Release 12.2SR
The Configuring Multiprotocol Label Switching on FlexWAN and
Enhanced FlexWAN Modules module of the FlexWAN and Enhanced
FlexWAN Modules Configuration Guide
The Configuring Any Transport over MPLS on a SIP section of the
Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide
The Configuring AToM VP Cell Mode Relay Support section of the
Cisco 7600 Series Router SIP, SSC, and SPA Software Configuration Guide
The Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600 Series
Routers
MPLS Commands Cisco IOS Multiprotocol Label Switching Command Reference
http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_book.html
Standards
Standard Title
draft-ietf-l2vpn-signaling-08.txt Provisioning, Autodiscovery, and Signaling in L2VPNs
draft-ietf-l2vpn-vpls-bgp-08.8 Virtual Private LAN Service (VPLS) Using BGP for Autodiscovery and
Signaling
draft-ietf-mpls-lsp-ping-03.txt Detecting MPLS Data Plane Failures
draft-ietf-pwe3-vccv-01.txt Pseudo-Wire (PW) Virtual Circuit Connection Verification (VCCV)
14
MIBs
MIB MIBs Link
CISCO-IETF-PW-MIB (PW-MIB) To locate and download MIBs for selected platforms, Cisco IOS
CISCO-IETF-PW-MPLS-MIB (PW-MPLS-MIB) releases, and feature sets, use Cisco MIB Locator found at the
following URL:
CISCO-IETF-PW-ENET-MIB (PW-ENET-MIB)
CISCO-IETF-PW-FR-MIB (PW-FR-MIB)
CISCO-IETF-PW-ATM-MIB (PW-ATM-MIB)
RFCs
RFC Title
RFC 3916 Requirements for Pseudo-wire Emulation Edge-to-Edge (PWE3)
RFC 3981 Pseudo Wire Emulation Edge-to-Edge Architecture
Description Link
Cisco products and technologies. Access to most tools
on the Cisco Support website requires a Cisco.com user
ID and password. If you have a valid service contract
but do not have a user ID or password, you can register
on Cisco.com.
15
Feature Information for VPLS Autodiscovery: BGP Based

Table 2 Feature Information for VPLS Autodiscovery: BGP Based

VPLS Autodiscovery: BGP Based 12.2(33)SRB VPLS Autodiscovery enables each Virtual Private LAN
Service (VPLS) provider edge (PE) router to discover which
other PE routers are part of the same VPLS domain.
In 12.2(33)SRB, this feature was introduced on the
Cisco 7600 router.
The following commands were introduced or modified for
this feature:
auto-route-target
l2 router-id
l2 vfi autodiscovery
neighbor (VPLS)
rd (VPLS)
route-target (VPLS)
show vfi
show xconnect
vpls-id
xconnect
BGP VPLS Autodiscovery Support on Route 12.2(33)SRE This feature was introduced on the Cisco 7600 series
Reflector routers. This feature is documented in the following
sections:
BGP VPLS Autodiscovery Support on a Route
Reflector, page 4
BGP VPLS Autodiscovery Support on Route Reflector:
Example, page 13
16
coincidental.
17
18
H-VPLS N-PE Redundancy for QinQ and MPLS
Access

The H-VPLS N-PE Redundancy for QinQ and MPLS Access feature enables two network provider edge
(N-PE) routers to provide failover services to a user provider edge (U-PE) router in a hierarchical virtual
private LAN service (H-VPLS). Having redundant N-PE routers provides improved stability and
reliability against link and node failures. This document explains how to implement this feature.

latest feature information and caveats, see the release notes for your Cisco IOS software release. To reach
supported, use the Feature Information for H-VPLS N-PE Redundancy for QinQ and MPLS Access section
on page 13.
Contents
Prerequisites for H-VPLS N-PE Redundancy for QinQ and MPLS Access, page 2
Restrictions for H-VPLS N-PE Redundancy for QinQ and MPLS Access, page 2
Information About H-VPLS N-PE Redundancy for QinQ and MPLS Access, page 3
How to Configure H-VPLS N-PE Redundancy for QinQ and MPLS Access, page 6
Configuration Examples for H-VPLS N-PE Redundancy for QinQ and MPLS Access, page 9

H-VPLS N-PE Redundancy for QinQ and MPLS Access
Prerequisites for H-VPLS N-PE Redundancy for QinQ and MPLS Access
Feature Information for H-VPLS N-PE Redundancy for QinQ and MPLS Access, page 13
Glossary, page 14
Prerequisites for H-VPLS N-PE Redundancy for QinQ and MPLS

Access
Before configuring the H-VPLS N-PE Redundancy for QinQ and MPLS Access feature, configure
your H-VPLS network and make sure it is operating correctly. For more information about
configuring the H-VPLS network, see the Configuring VPLS chapter of the Configuring
Multiprotocol Label Switching on the Optical Services Modules.
Make sure that the PE-to-CE interface is configured the switchport trunk with a list of allowed
VLANs. For more information, see the Configuring VPLS chapter of the Configuring VPLS
chapter of the Configuring Multiprotocol Label Switching on the Optical Services Modules.
To provide faster convergence, you can optionally enable the MPLS Traffic Engineering: Fast
Reroute feature in the Multiprotocol Label Swithing (MPLS) core. See the MPLS Traffic
Engineering (TE)Fast Reroute (FRR) Link and Node Protection documentation.
Enable the L2VPN Pseudowire Redundancy feature on the U-PE routers for MPLS access. For
information about configuring the L2VPN Pseudowire Redundancy feature, see the L2VPN
Pseudowire Redundancy documentation.
When configuring MSTP, specify that one of N-PEs routers is the root by assigning it the lowest
priority, using the following command:
spanning-tree mst instance-id priority priority
For information about configuring MSTP, see the Configuring MST Instance Parameters chapter
of the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.1E.
When configuring MSTP, make sure each of the routers participating in the spanning-tree are in the
same region and are the same revision by issuing the revision, name, and instance commands in
MST configuration mode. For more information on configuring these MSTP parameters, see the
Configuring IEEE 802.1s MST chapter of the Cisco 7600 Series Cisco IOS Software
Configuration Guide, 12.1E.
Restrictions for H-VPLS N-PE Redundancy for QinQ and MPLS

Access
H-VPLS N-PE Redundancy for QinQ and MPLS Access cannot be used with the VPLS
Autodiscovery feature on the pseudowires that attach to the U-PE routers. When you create the
VPLS, manually create the virtual forwarding interface (VFI).
You cannot configure more than one pseudowire (PW) to carry the bridge protocol data unit (BPDU)
information between the N-PE routers. If you attempt to enter the forward permit l2protocol all
command for multiple VFIs, you receive an error message.
You cannot configure a local loopback address as a neighbor when you configure the H-VPLS N-PE
Redundancy for QinQ and MPLS Access featureon the N-PE routers. If you do, the following error
is displayed:
VPLS local switching to peer address not supported
2
Information About H-VPLS N-PE Redundancy for QinQ and MPLS Access
Only two N-PE routers can be connected to each U-PE router.

For a list of supported hardware for this feature, see the Release Notes for Cisco IOS Release 12.2SR
for the Cisco 7600 Series Routers.
The spanning tree mode must be MSTP for the H-VPLS N-PE Redundancy for QinQ and MPLS
Access feature. If the spanning tree mode changes, the H-VPLS N-PE Redundancy for QinQ and
MPLS Access feature may not work correctly, even though the the pseudowire that carries the BPDU
information still exists and the H-VPLS N-PE Redundancy is still configured.
Information About H-VPLS N-PE Redundancy for QinQ and MPLS

Access
Before configuring the H-VPLS N-PE Redundancy for QinQ and MPLS Access feature, you should
How H-VPLS N-PE Redundancy for QinQ and MPLS Access Works, page 3
MAC Address Withdrawal, page 5
How H-VPLS N-PE Redundancy for QinQ and MPLS Access Works
In a network configured with the H-VPLS N-PE Redundancy for QinQ and MPLS Access feature, the
U-PE router is connected to two N-PE routers, which provides a level of redundancy that can tolerate
both link or device faults. If a failure occurs in the network that disables one N-PE router from
transmitting data, the other N-PE router will take over. This feature works with both QinQ access based
on Multiple Spanning Tree Protocol (MSTP) and MPLS access based on pseudowire redundancy.
H-VPLS N-PE Redundancy with QinQ Access Based on MSTP

H-VPLS N-PE redundancy with QinQ access uses MSTP running on the N-PE routers and U-PE routers
in an H-VPLS network. A pseudowire running between N-PE routers carries only MSTP BPDUs. The
pseudowire running between the N-PE routers is always up and is used to create a loop path between
N-PE routers so that MSTP will block one of the redundant paths between the U-PE router and the N-PE
routers. If the primary N-PE router or the path to it fails, MSTP will enable the path to the backup N-PE
router.
Figure 1 shows an H-VPLS network with redundant access. Each U-PE router has two trunk
connections, one to each N-PE router. Between the two N-PE routers is a pseudowire to provide a loop
path for MSTP BPDUs. The network topology shown in Figure 1 allows for the backup N-PE router to
take over if the primary N-PE router or the path to it fails.
3
Figure 1 H-VPLS N-PE Redundancy with QinQ access Based on MSTP
CE U-PE N-PE
pseudowire between
N-PE routers
CE U-PE N-PE
186183
VLAN A
VLAN B
H-VPLS N-PE Redundancy with MPLS Access Based on Pseudowire Redundancy

For H-VPLS redundancy with MPLS access based on pseudowire redundancy, the MPLS network has
pseudowires to the VPLS core N-PE routers.
As shown in Figure 2, one pseudowire transports data between the U-PE router and its peer N-PE
routers. When a failure occurs along the path of the U-PE router, the backup pseudowire and the
redundant N-PE router become active and start transporting data.
Figure 2 H-VPLS N-PE Redundancy for QinQ and MPLS Access with MPLS Access Based On
Pseudowire Redundancy
CE-1 N-PE1 N-PE2
PW1
U-PE
PW2
186184
CE-2 N-PE4 N-PE3
4
MAC Address Withdrawal

PE routers learn the remote MAC addresses and directly attached MAC addresses on customer-facing
ports by deriving topology and forwarding information from packets originating at customer sites. To
display the number of MAC address withdrawal messages, enter the show mpls l2transport vc detail
command, as shown in the following example. The MAC address withdrawal message is shown in bold.
Local interface: VFI TEST VFI up

MPLS VC type is VFI, interworking type is Ethernet
Output interface: Se2/0, imposed label stack {17}
MAC Withdraw: sent 5, received 3
VC statistics:
How MAC Address Withdrawal Works with H-VPLS N-PE Redundancy with QinQ Access
If a failure occurs in the customer switched network, a spanning tree Topology Change Notification
(TCN) is issued to the U-PE router, which issues an LDP-based MAC address withdrawal message to
the peer N-PE routers and flushes its MAC address table.
How MAC Address Withdrawal Works with H-VPLS N-PE Redundancy with MPLS Access
If the pseudowire between the U-PE router and N-PE router fails, then the L2VPN Pseudowire
Redundancy feature on the U-PE router activates the standby pseudowire. In addition, the U-PE router
sends a Label Distribution Protocol (LDP) MAC address withdrawal request to the new N-PE router,
which forwards the message to all pseudowires in the VPLS core and flushes its MAC address table.
If a switched virtual interface (SVI) on the N-PE router fails, the L2VPN Pseudowire Redundancy
feature activates the standby pseudowire and the U-PE router sends a MAC withdrawal message to the
newly active N-PE router.
For information about the L2VPN Pseudowire Redundancy feature, see the L2VPN Pseudowire
Redundancy feature.
5
How to Configure H-VPLS N-PE Redundancy for QinQ and MPLS Access
How to Configure H-VPLS N-PE Redundancy for QinQ and MPLS

Access
Configuring the VPLS Pseudowire Between the N-PE Routers, page 6 (required)
Configuring the SVI for the Native VLAN, page 7 (required)
Verifying the H-VPLS N-PE Redundancy for QinQ and MPLS Access Configuration, page 8
(optional)
Configuring the VPLS Pseudowire Between the N-PE Routers

Configuring N-PE redundancy in an H-VPLS network requires two steps. First you define the VPLS
pseudowire for transporting BPDU data. Then, you connect that pseudowire to the native VLAN. This
provides a redundancy that provides improved reliability against link and node failures.
Prerequisites
Before configuring the H-VPLS N-PE Redundancy for QinQ and MPLS Access feature, configure
your H-VPLS network and make sure it is operating correctly. For more information about
configuring the H-VPLS network, see the Configuring VPLS chapter of the Configuring
Multiprotocol Label Switching on the Optical Services Modules.
Make sure that the PE-to-CE interface is configured the switchport trunk with a list of allowed
VLANs. For more information, see the Configuring VPLS chapter of the Configuring VPLS
chapter of the Configuring Multiprotocol Label Switching on the Optical Services Modules.
To provide faster convergence, you can optionally enable the MPLS Traffic Engineering: Fast
Reroute feature in the Multiprotocol Label Swithing (MPLS) core. See the MPLS Traffic
Engineering (TE)Fast Reroute (FRR) Link and Node Protection documentation.
Enable the L2VPN Pseudowire Redundancy feature on the U-PE routers for MPLS access. For
information about configuring the L2VPN Pseudowire Redundancy feature, see the L2VPN
Pseudowire Redundancy documentation.
When configuring MSTP, specify that one of N-PEs routers is the root by assigning it the lowest
priority, using the following command:
spanning-tree mst instance-id priority priority
For information about configuring MSTP, see the Configuring MST Instance Parameters chapter
of the Cisco 7600 Series Cisco IOS Software Configuration Guide, 12.1E.
When configuring MSTP, make sure each of the routers participating in the spanning-tree are in the
same region and are the same revision by issuing the revision, name, and instance commands in
MST configuration mode. For more information on configuring these MSTP parameters, see the
Configuring IEEE 802.1s MST chapter of the Cisco 7600 Series Cisco IOS Software
Configuration Guide, 12.1E.
SUMMARY STEPS
1. enable
6
3. l2 vfi name manual

4. vpn id id-number
5. forward permit l2protocol all
6. neighbor remote-router-id vc-id {encapsulation encapsulation-type | pw-class pw-name}
[no-split-horizon]
7. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 l2 vfi name manual Creates a Layer 2 VFI and enters Layer 2 VFI manual
configuration mode.
Example:
Router(config)# l2 vfi vfitest1 manual
Step 4 vpn id id-number Specifies the VPN ID.
Example:
Step 5 forward permit l2protocol all Creates a pseudowire that is to be used to transport BPDU
data between the two N-PE routers.
Example:
Router(config-vfi)# forward permit l2protocol
all
Step 6 neighbor remote-router-id vc-id {encapsulation Specifies the peer IP address of the redundant N-PE router
encapsulation-type | pw-class pw-name} and the type of tunnel signaling and encapsulation
[no-split-horizon]
mechanism.
Example:
Router(config-vfi)# neighbor 10.2.2.2 3
encapsulation mpls
Step 7 end Ends the current configuration session and returns to
Example:
Router(config-vfi)# end
Configuring the SVI for the Native VLAN

Perform the following task to configure the switch virtual interface for the native VLAN.
7
SUMMARY STEPS
1. enable
3. interface vlan vlanid
4. xconnect vfi vfi-name
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface vlan vlanid Creates a dynamic SVI.
Example:
Router(config)# interface vlan 23
Step 4 xconnect vfi vfi-name Specifies the Layer 2 VFI that you are binding to the VLAN
port.
Example:
Router(config)# xconnect vfi vfitest1
Verifying the H-VPLS N-PE Redundancy for QinQ and MPLS Access
Configuration
To ensure that the H-VPLS N-PE Redundancy for QinQ and MPLS Access feature is correctly
configured, perform the following task.
SUMMARY STEPS
1. show vfi vfi-name
DETAILED STEPS
Step 1 show vfi vfi-name

Use this command on the pseudowire between the two N-PE routers to displays information about the
pseudowire, as shown in the following example:
Router# show vfi VPLS-2
VFI name: VPLS-2, state: up

VPN ID: 100
8
Configuration Examples for H-VPLS N-PE Redundancy for QinQ and MPLS Access
Local attachment circuits:

Vlan2
Neighbors connected via pseudowires:
Peer Address VC ID Split-horizon
10.1.1.1 2 Y
10.1.1.2 2 Y
10.2.2.3 2 N
Configuration Examples for H-VPLS N-PE Redundancy for QinQ

and MPLS Access
This section provides the following example for configuring H-VPLS redundancy:
H-VPLS N-PE Redundancy for QinQ Access: Example
H-VPLS N-PE Redundancy for QinQ Access: Example

Figure 3 shows a configuration that is set up for H-VPLS N-PE redundancy with QinQ access.
Figure 3 H-VPLS N-PE Redundancy with QinQ Access Topology
gi5/2
U-PE1 N-PE1
10.2.2.2
QinQ
w/MSTP L2 trunk
MPLS
or BPDU
MPLS PW
N-PE2
10.4.4.4
U-PE2
186220
gi2/0/5
MST root
Table 1 shows the configuration of two N-PE routers for H-VPLS N-PE redundancy with QinQ access.
9
Configuration Examples for H-VPLS N-PE Redundancy for QinQ and MPLS Access
Table 1 H-VPLS N-PE Redundancy for QinQ Access: Example
N-PE1 N-PE2
l2 vfi l2trunk manual l2 vfi l2trunk manual
vpn id 10 vpn id 10
forward permit l2protocol all forward permit l2protocol all
neighbor 10.4.4.4 encapsulation mpls neighbor 10.2.2.2 encapsulation mpls
! !
interface Vlan1 interface Vlan1
xconnect vfi l2trunk xconnect vfi l2trunk
! !
spanning-tree mode mst spanning-tree mode mst
spanning-tree extend system-id spanning-tree extend system-id
! !
spanning-tree mst configuration spanning-tree mst configuration
revision 10 revision 10
instance 1 vlan 20 instance 1 vlan 20
! !
interface GigabitEthernet5/2 spanning-tree mst 1 priority 0
switchport !
switchport trunk encapsulation dot1q interface GigabitEthernet2/0/5
switchport trunk allowed vlan 20 switchport
switchport mode trunk switchport trunk allowed vlan 20
switchport mode trunk
mls qos trust dscp
10
The following sections provide references related to the H-VPLS N-PE Redundancy feature.
Related Documents
L2VPN pseudowire redundancy L2VPN Pseudowire Redundancy
H-VPLS Configuring VPLS chapter of the Configuring Multiprotocol
Label Switching on the Optical Services Modules
Multiple spanning tree configuration Configuring MST Instance Parameters chapter of the Cisco 7600
Series Cisco IOS Software Configuration Guide, 12.1E
MPLS traffic engineering MPLS Traffic Engineering (TE)Fast Reroute (FRR) Link and Node
Protection
Supported hardware on the Cisco 7600 series routers Release Notes for Cisco IOS Release 12.2SR for the Cisco 7600
Series Routers
Standards
Standard Title
http://www.ietf.org/rfc/rfc4447.txt Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)
http://www3.ietf.org/proceedings/06mar/IDs/draft-ietf Virtual Private LAN Services over MPLS
-l2vpn-vpls-ldp-08.txt
http://www.ietf.org/internet-drafts/draft-ietf-pwe3-seg Segmented Pseudo Wire
mented-pw-02.txt
draft-ietf-pwe3-vccv-10.txt Pseudo Wire Virtual Circuit Connectivity Verification (VCCV)

draft-ietf-pwe3-oam-msg-map-03.txt Pseudo Wire (PW) OAM Message Mapping
MIBs
MIB MIBs Link
Pseudowire Emulation Edge-to-Edge MIBs for To locate and download MIBs for selected platforms, Cisco IOS
Ethernet, Frame Relay, and ATM Services releases, and feature sets, use Cisco MIB Locator found at the
following URL:
RFCs
RFC Title
None
11
Command Reference
Description Link
Command Reference
module.
forward permit l2protocol
For information about these commands, see the Cisco IOS Multiprotocol Label Switching Command
Reference at http://www.cisco.com/en/US/docs/ios/mpls/command/reference/mp_book.html.
12
Feature Information for H-VPLS N-PE Redundancy for QinQ and MPLS Access
Feature Information for H-VPLS N-PE Redundancy for QinQ and

MPLS Access
Table 2 Feature Information for H-VPLS N-PE Redundancy for QinQ and MPLS Access

H-VPLS N-PE Redundancy for QinQ and 12.2(33)SRC The H-VPLS N-PE Redundancy for QinQ and MPLS
MPLS Access Access feature enables two network provider edge (N-PE)
routers to provide redundancy to a user provider edge
(U-PE) router in a hierarchical virtual private LAN service
(VPLS). Having redundant N-PE routers provides improved
stability and reliability against link and node failures.
In Release 12.2(33)SRC, this feature was introduced on the
Cisco Series 7600 router.
this feature: forward permit l2protocol and show mpls
l2transport vc.
13
Glossary
Glossary
CE routerCustomer edge router. A router that belongs to a customer network, which connects to a PE
router to utilize MPLS VPN network services.
LANLocal area network. High-speed, low-error data network covering a relatively small geographic
area. LANs connect workstations, peripherals, terminals, and other devices in a single building or other
geographically limited area.
MSTPMultiple Spanning Tree Protocol. The MSTP enables multiple VLANs to be mapped to the
same spanning-tree instance, reducing the number of spanning-tree instances needed to support a large
number of VLANs.
PE routerProvider edge router. The PE router is the entry point into the Service Provider network.
The PE router is typically deployed on the edge of the network and is administered by the Service
Provider.
PWPseudowire.
N-PENetwork-facing PE router. This router acts as a gateway between the MPLS core and edge
domains.
pseudowireA pseudowire is a virtual connection that, in the context of VPLS, connects two VSIs. A
pseudowire is bidirectional and consists of a pair of uni-directional MPLS Virtual Circuits (VCs). A
pseudowire can be used to connect a point-to-point circuit.
PWPseudowire. A mechanism that carries the elements of an emulated service from one PE router to
one or more PEs over a packet switched network (PSN).
QinQAn IEEE 802.1Q VLAN tunnel.
U-PECustomer-facing PE router. This router connects Customer Edge (CE) routers to the service.
QinQA mechanism for constructing multipoint Layer 2 VPN using Ethernet switches.
spanning treeLoop-free subset of a network topology.
VFIVirtual forwarding instance. A VFI is a collection of data structures used by the data plane,
software-based or hardware-based, to forward packets to one or more VCs.
VLANVirtual LAN. Group of devices on one or more LANs that are configured (using management
software) so that they can communicate as if they were attached to the same wire, when in fact they are
located on a number of different LAN segments.
VPLSVirtual Private LAN Service. VPLS describes an architecture that delivers Layer 2 service that
emulates an Ethernet LAN across a Wide Area Network (WAN) and inherits the scaling characteristics
of a LAN.
VPLS redundancyAlso called N-PE redundancy. Allows U-PEs to be dual-honed (to their N-PEs) in
a loop-free topology with MPLS or QinQ as the access or aggregation domain.
14
Glossary
VPNVirtual Private Network. Allows IP traffic to travel securely over public TCP/IP networks and the
Internet by encapsulating and encrypting all IP packets. VPN uses a tunnel to encrypt all information at
the IP level.
coincidental.
15
Glossary
16
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 feature spans multiple cores or
autonomous systems of the same or different carrier networks.

supported, see the Feature Information for L2VPN Multisegment Pseudowires section on page 12.
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 12

Prerequisites for L2VPN Multisegment Pseudowires

Before configuring this feature, see the following documents:
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 Multiprotocol Label Switching (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. See the Restrictions section on page 8 for specific restrictions on ping
mpls and trace mpls operations.
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 2, 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.
8
How to Configure 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. An L2VPN MS-PW can include up to 254 PW segments.
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.
Figure 2 A Multisegment Pseudowire
PW segment PW segment PW segment
CE1 CE1
T-PE1 T-PE2
S-PE1 S-PE2
CE2 CE2 243511
9

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 L2VPN Multisegment Pseudowires, page 7
(optional)
Configuring L2VPN Multisegment Pseudowires

Perform the following steps on the S-PE routers to create L2VPN multisegment pseudowires.
Cisco 7600 Router-Specific Instructions
If the Cisco 7600 router is the penultimate hop router connected to the S-PE or T-PE router, issue the
following commands on the S-PE or T-PE routers:
mpls ldp explicit-null
no mls mpls explicit-null propagate-ttl
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}
8
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
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:
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:
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
9

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
Displaying Information About the L2VPN Multisegment Pseudowires

Perform the following task to display the status of L2VPN multisegment pseudowires.
SUMMARY STEPS
1. show mpls l2transport binding

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:
8
Local interface: Se3/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
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 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
9
Restrictions
Some ping mpls and trace mpls keywords that are available with IPv4 LDP or traffic engineering (TE),
are not available with pseudowire.
The following keywords are not available with the ping mpls pseudowire command:
dsmap
flags
force-explicit-null
output
revision
ttl
The following keywords are not available with the trace mpls pseudowire command:
flags
force-explicit-null
output
revision
ttl
SUMMARY STEPS
1. ping mpls pseudowire destination-address vc-id [segment segment-number]

2. trace mpls pseudowire destination-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.
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.
destination-address is S-PE1 and vc-id is the VC between T-PE1 and S-PE1.
ping mpls pseudowiredestination-address vc-id
To perform a ping operation from T-PE1 to segment 2, enter the following command.
destination-address is S-PE1 and vc-id is the VC between T-PE1 and S-PE1.
ping mpls pseudowire destination-address vc-id 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 origin of the trace.
8
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. destination-address is S-PE1 and vc-id is the VC between T-PE1 and S-PE1.
trace mpls pseudowire destination-address vc-id 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. destination-address is S-PE1 and vc-id is the VC between
T-PE1 and S-PE1.
trace mpls pseudowire destination-address vc-id segment 2 4
The following commands perform trace operations on S-PE router 10.10.10.9, first on segment 1, then
on segment 2.
Segment 1 trace:
Router# trace mpls pseudowire 10.10.10.9 220 segment 1
Tracing MS-PW segments within range [1-1] peer address 10.10.10.9 and timeout 2 seconds


L 1 10.10.9.9 0 ms [Labels: 18 Exp: 0]
local 10.10.10.22 remote 10.10.10.9 vc id 220
Segment 2 trace:
Router# trace mpls pseudowire 10.10.10.9 220 segment 2


L 1 10.10.9.9 4 ms [Labels: 18 Exp: 0]
! 2 10.10.3.3 4 ms [Labels: 16 Exp: 0]

9
The following sections provide references related to the L2VPN multisegment pseudowires feature.
Related Documents
Layer 2 VPNS Any Transport over MPLS
MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for
VCCV
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 4447 Pseudowire Setup and Maintenance Using the Label Distribution
Protocol (LDP)
RFC5085 Pseudowire Virtual Circuit Connectivity Verification (VCCV)
RFC4379 Detecting Multi-Protocol Label Switched (MPLS) Data Plane
Failures
8
Description Link
9
Feature Information for L2VPN Multisegment Pseudowires

Table 1 Feature Information for L2VPN Multisegment Pseudowires

L2VPN Multisegment Pseudowires 12.2(33)SRE This feature enables you to configure two or more Layer 2
pseudowire segments that function as a single pseudowire.
The feature spans multiple cores or autonomous systems of
the same or different carrier networks.
coincidental.
8
QoS Policy Support for L2VPN ATM PVPs

This document explains how to configure Quality of Service (QoS) Policy Support for Layer 2 Virtual
Private Network (L2VPN) ATM permanent virtual paths (PVPs). That is, it explains how to configure
QoS policies in ATM PVP mode for L2VPNs.

supported, see the Feature Information for QoS Policy Support for L2VPN ATM PVPs section on page 10.
Contents
Prerequisites for QoS Policy Support for L2VPN ATM PVPs, page 2
Restrictions for QoS Policy Support for L2VPN ATM PVPs, page 2
Information About QoS Policy Support for L2VPN ATM PVPs, page 2
How to Configure QoS Policy Support for L2VPN ATM PVPs, page 3
Configuration Examples for QoS Policy Support for L2VPN ATM PVPs, page 7
Feature Information for QoS Policy Support for L2VPN ATM PVPs, page 10

Prerequisites for QoS Policy Support for L2VPN ATM PVPs
Prerequisites for QoS Policy Support for L2VPN ATM PVPs

Before configuring QoS policies on L2VPN ATM PVPs, you should understand the concepts and
configuration instructions in the following document:
Restrictions for QoS Policy Support for L2VPN ATM PVPs

The following restrictions apply to the QoS Policy Support for L2VPN ATM PVPs feature:
The Cisco 7600 series router does not support any queueing features in ATM PVP mode.
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.
Cisco IOS Release 12.2(33)SRE does not support cell-based ATM shaping per PVP.
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 for L2VPN ATM PVPs

Before configuring the QoS Policy Support for L2VPN ATM PVPs feature, you should understand the
following concepts:
MQC Structure, page 2
Elements of a Traffic Class, page 3
Elements of a Traffic Policy, page 3
MQC Structure
The modular QoS command-line interface (CLI) (MQC) structure allows you to define a traffic class,
create a traffic policy, and attach the traffic policy to an interface.
The MQC structure is the result of the following these three high-level steps.
1. Define a traffic class by using the class-map command. A traffic class is used to classify traffic.
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.
3. Attach the traffic policy (policy map) to the interface by using the service-policy command.
2
How to Configure QoS Policy Support for 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 5 (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 Cisco 7600 series router does not support a service policy that uses the match atm-vci
command in the egress direction.
The show policy-map interface command does not display service policy information for ATM
interfaces.
SUMMARY STEPS
1. enable
3
3. interface atm slot/port
5. service-policy [input | output] policy-map-name
7. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface atm slot/port Defines the interface and enters interface configuration mode.
Example:
Router(config)# interface atm 1/0
enters l2transport PVP configuration mode.
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
encapsulation mpls
Layer 2 transports.
Example:
Step 7 end Exits l2transport PVP configuration mode and returns to
Example:
Router(config-if-atm-l2trans-pvp)# end
4
Enabling Traffic Shaping in ATM PVP Mode

Traffic shaping commands are supported in ATM 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).
Restrictions
The Cisco 7600 series router does not support traffic shaping.
SUMMARY STEPS
1. enable
3. interface atm slot/port
5. ubr pcr
or
cbr pcr
or
vbr-nrt pcr scr mbs
or
vbr-rt pcr scr mbs
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface atm slot/port Defines the interface and enters interface configuration mode.
Example:
Router(config)# interface atm 1/0
Step 4 atm pvp vpi l2transport Specifies that the PVP is dedicated to transporting ATM cells, and
enters l2transport PVP configuration mode.
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
or
cbr 56
or
vbr-nrt 11760 11760 1
or
vbr-rt 640 320 80
encapsulation mpls
Layer 2 transports.
Example:
Enabling Matching of ATM VCIs

You can enable packet matching 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.
On the Cisco 7600 series router, the match atm-vci command is supported only in the ingress
direction on 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
6
Configuration Examples for QoS Policy Support for L2VPN ATM PVPs
DETAILED STEPS

Example:
Router> enable
Example:
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 match any VC
Router(config-cmap)# match atm-vci 50
except those you specify in the command.
Step 5 end (Optional) Returns to privileged EXEC mode.
Example:
Router(config-cmap)# end
Configuration Examples for QoS Policy Support for L2VPN ATM

PVPs
The following section shows an example of the QoS Policy Support for 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.
interface atm 1/0
ubr 1000
cbr 1000
vbr-nrt 1200 800 128
7
The following sections provide references related to the QoS Policy Support for L2VPN ATM PVPs
feature.
Related Documents
Standards
Standard Title
None
MIBs
MIB MIBs Link
following URL:
RFCs
RFC Title
None
8
Description Link
9
Feature Information for QoS Policy Support for L2VPN ATM PVPs
Feature Information for QoS Policy Support for L2VPN ATM PVPs
Table 1 Feature Information for QoS Policy Support for L2VPN ATM PVPs

QoS Policy Support for L2VPN ATM 12.2(33)SRE This feature enables you to configure QoS policies in ATM
PVPs PVP mode for L2VPNs.
this feature: cbr, match atm-vci, service-policy, ubr,
vbr-nrt, vbr-rt.
coincidental.
10
L2VPN: Pseudowire Preferential Forwarding

The L2VPN: Pseudowire Preferential Forwarding feature allows you to configure pseudowires so that
you can use ping, show, and traceroute commands to find status information of the pseudowires before,
during, and after a switchover.

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)
NSF/SSOAny Transport over MPLS and AToM Graceful Restart
MPLS LSP Ping/Traceroute for LDP/TE, and LSP Ping for VCCV
The provider edge (PE) routers must be configured with the following features:
NSF/SSOAToM 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:
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
VC cell packing
OAM emulation
Integrated LMI/permanent virtual circuit (PVC)-D
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, show, and traceroute 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, page 3 (required)
Configuring the Pseudowire

You configure 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 Any
Transport over MPLS (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/SSOAny
Transport over MPLS and AToM Graceful Restart features. See the following documents for
configuration instructions:
3
NSF/SSOAny Transport over MPLS and AToM Graceful Restart
SUMMARY STEPS
1. enable
5. status redundancy {master | slave}
6. 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
Example:
Example:
Step 5 status redundancy {master | slave} Specifies the pseudowire as the master or slave.
This enables the L2VPN: Pseudowire Preferential Forwarding
Example: feature to display the status of the active and backup pseudowires.
Router(config-pw)# status redundancy
master
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.
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
!
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.1 ATM VPC CELL 50 10.1.1.2 100 UP
AT0/2/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.
Router-standby# show mpls l2transport vc

------------- -------------------------- --------------- ---------- ----------
AT0/2/0.1 ATM VPC CELL 50 10.1.1.2 100 HOTSTANDBY
AT0/2/0.1 ATM VPC CELL 50 10.1.1.3 100 DOWN
During a switchover, the status of the active and backup pseudowires changes:
5
Configuration Examples for L2VPN: Pseudowire Preferential Forwarding

------------- -------------------------- --------------- ---------- ----------
AT0/2/0.1 ATM VPC CELL 50 10.1.1.2 100 RECOVERING
AT0/2/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.1 ATM VPC CELL 50 10.1.1.2 100 UP
AT0/2/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.1/1/1:220/220(ATM V UP mpls 10.193.193.3:330 UP
IA sec ac AT1/1/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:


!!!!!
Router# traceroute mpls pseudowire 10.193.193.22 331 segment 1

6

! 1 10.193.33.22 4 ms [Labels: 23 Exp: 0]
The following sections provide references related to the L2VPN: Pseudowire Preferential Forwarding
feature.
Related Documents
L2VPN pseudowires MPLS Pseudowire Status Signaling
NSF/SSO for L2VPNs NSF/SSOAny 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
N/A To locate and download MIBs for selected platforms, Cisco IOS
following URL:
RFCs
RFC Title
None
7
Description Link
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
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 12.2(33)SRE This feature allows you to configure pseudowires so that
you can use ping, show, and traceroute commands to find
status information of the pseudowires before, during, and
after a switchover.
this feature: show mpls l2transport vc, show xconnect,
status redundancy.
coincidental.
9
MPLS Layer 3 VPNs
Configuring MPLS Layer 3 VPNs

Last Updated: August 26, 2008
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.

supported, see the Feature Information for MPLS Layer 3 VPNs section on page 37.
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 29
Feature Information for MPLS Layer 3 VPNs, page 37
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 (CEF) installed in your network. All routers in the core, including the PE
routers, must be able to support CEF and MPLS forwarding. See 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 releases that support the Tag Forwarding Information Base (TFIB), specifically Cisco IOS
Releases 12.xT, 12.xM, and 12.0S. 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 releases that support the MPLS Forwarding Infrastructure (MFI), specifically Cisco IOS
Release 12.2(25)S and later. 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:
environment and enable load sharing where the destination can be reached through two next hops:
ip route destination-prefix mask next-hop1
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
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
(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
sharing where the destination can be reached through two next hops:
ip route vrf destination-prefix mask next-hop1 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
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 routers loopback address, as in EBGP multihop cases.
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
3

Before configuring MPLS Layer 3 VPNs, you should undertand 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 providers 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) routerRouter 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 routerRouter 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) routerRouter in the ISP or enterprise network.
Customer edge routerEdge 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/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 CEF 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 sites 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 CEF table for each VRF.
A separate set of routing and CEF 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 communitiesA, B, or Cis 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 (refer to 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 CEF 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 communitiesA 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 routersMP-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 forwardingMPLS 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, including:
Connectionless ServiceA 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 ServiceBuilding 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.
ScalabilityIf 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.
SecurityMPLS 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 CreateTo 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 AddressingTo 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.
Integrated Quality of Service (QoS) SupportQoS 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.
8
Straightforward MigrationFor 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 13 (required)
Verifying Connectivity Between MPLS VPN Sites, page 27 (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 CEF Is Enabled in the Core, page 10 (required)
Configuring Multiprotocol BGP on the PE Routers and Route Reflectors, page 11 (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.
4. Determine if you need BGP load sharing and redundant paths.
9
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 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 protocolBGP, OSPF, IS-IS, EIGRP, staticsee 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 configuration information, see the Configuring MPLS
Label Distribution Protocol (LDP).
MPLS Traffic Engineering Resource Reservation Protocol (RSVP). For configuration information,
see Configuring MPLS Traffic Engineering.
Determining if CEF Is Enabled in the Core

Cisco Express Forwarding (CEF) must be enabled all routers in the core, including the PE routers. For
information about how to determine if CEF is enabled, see Configuring Basic Cisco Express
ForwardingImproving Performance, Scalability, and Resiliency in Dynamic Network.
10
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.
SUMMARY STEPS
1. enable
3. router bgp as-number
5. neighbor {ip-address | peer-group-name} remote-as as-number
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.
11

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 pp.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.
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 pp.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.
send-community extended BGP neighbor.
Example: BGP-speaking neighbor.
Router(config-router-af)# neighbor pp.0.0.1
send-community extended The peer-group-name argument specifies the name of a
BGP peer group.
Example: neighbor.
Router(config-router-af)# neighbor pp.0.0.1
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.
12
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)
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
13

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,
192.168.122.15:1
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:
configuration mode.
Example: The type argument specifies the type of interface to be
Router(config)# interface Ethernet 5/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.
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 21
Configuring EIGRP as the Routing Protocol Between the PE and CE Routers, page 23
Configuring EIGRP Redistribution in the MPLS VPN, page 25
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]

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

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 pp.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.
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 pp.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:
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
17
DETAILED STEPS

Example:
Router> enable
Example:
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.
See the redistribute command for information
Example: about other arguments and keywords.
Router(config-router-af)# redistribute bgp 200
18

Example:
Example:
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
19
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.
| 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: See the redistribute command for information
Router(config-router-af)# redistribute connected about other arguments and keywords.
20

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
DETAILED STEPS

Example:
Router> enable
Example:
21

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 192.168.129.16 0.0.0.3 address.
area 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.
| 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: See the redistribute command for information
Router(config-router-af)# redistribute rip metric 1 about other arguments and keywords.
subnets
22

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]
15. end
23
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Enters router configuration mode, and creates a BGP
routing process.
Example:
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
24

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.
SUMMARY STEPS
1. enable
25
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.
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.
26

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 28
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
27
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
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]
28
Configuration Examples for MPLS VPNs
Use this command to display the CEF forwarding table associated with a VRF. Check that the prefix of
the remote CE router is in the CEF table.
Step 4 exit

Configuring an MPLS VPN Using BGP: Example, page 30
Configuring an MPLS VPN Using RIP: Example, page 31
Configuring an MPLS VPN Using Static Routes: Example, page 32
Configuring an MPLS VPN Using OSPF: Example, page 33
Configuring an MPLS VPN Using EIGRP: Example, page 34
29
Configuring an MPLS VPN Using BGP: Example

This example shows an MPLS VPN that is configured using BGP.
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 Ethernet0/0
! ip address 34.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 Ethernet0/0 bgp log-neighbor-changes
ip vrf forwarding vpn1 neighbor 34.0.0.2 remote-as 100
ip address 34.0.0.2 255.0.0.0 !
no cdp enable address-family ipv4
! redistribute connected
interface Ethernet 1/1 neighbor 34.0.0.2 activate
ip address 30.0.0.1 255.0.0.0 neighbor 34.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 30.0.0.0 0.255.255.255 area 100
!
router bgp 100
no synchronization
bgp log-neighbor changes
no auto-summary
!
address-family vpnv4
bgp scan-time import 5
exit-address-family
!
address-family ipv4 vrf vpn1
neighbor 34.0.0.1 as-override
neighbor 34.0.0.1 advertisement-interval 5
no auto-summary
no synchronization
exit-address-family
30
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
! ip address 34.0.0.1 255.0.0.0
ip address 10.0.0.1 255.255.255.255
! router rip
interface Ethernet0/0 version 2
ip vrf forwarding vpn1 timers basic 30 60 60 120
ip address 34.0.0.2 255.0.0.0 redistribute connected
no cdp enable network 10.0.0.0
interface Ethernet 1/1 network 34.0.0.0
ip address 30.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 34.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
31
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 Ethernet0/0
mpls ldp router-id Loopback0 force ip address 34.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 34.0.0.2 3
ip address 10.0.0.1 255.255.255.255 ip route 31.0.0.0 255.0.0.0 34.0.0.2 3
!
ip vrf forwarding vpn1
ip address 34.0.0.2 255.0.0.0
no cdp enable
!
ip address 30.0.0.1 255.0.0.0
mpls ip
!
router ospf 100
network 10.0.0. 0.0.0.0 area 100
network 30.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
34.0.0.1
ip route vrf vpn1 34.0.0.0 255.0.0.0 34.0.0.1
32
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 34.0.0.1 255.0.0.0
ip address 10.0.0.1 255.255.255.255 !
! router ospf 1000
interface Ethernet0/0 log-adjacency-changes
ip vrf forwarding vpn1 auto-cost reference-bandwidth 1000
ip address 34.0.0.2 255.0.0.0 redistribute connected subnets
no cdp enable network 34.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 34.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
33
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 34.0.0.1 255.0.0.0
ip address 10.0.0.1 255.255.255.255 !
interface Ethernet0/0 router eigrp 1000
ip vrf forwarding vpn1 network 34.0.0.0
ip address 34.0.0.2 255.0.0.0 auto-summary
no cdp enable
ip address 30.0.0.1 255.0.0.0
mpls ip
router eigrp 1000
auto-summary
!
redistribute bgp 100 metric 10000 100 255
1 1500
network 34.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
34
The following sections provide references related to MPLS VPNs.
Related Documents
MPLS VPN Carrier Supporting Carrier MPLS VPN Carrier Supporting Carrier Using LDP and an IGP
MPLS VPN Carrier Supporting Carrier with BGP
MPLS VPN InterAutonomous Systems MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and
MPLS Labels
MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4
Addresses
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
35
Description Link
36
Feature Information for MPLS Layer 3 VPNs

Table 1 Feature Information for MPLS Layer 3 VPNs

MPLS Virtual Private Networks 12.0(5)T This feature allows a set of sites that to be interconnected by
means of an MPLS provider core network. At each
12.0(21)ST
customer site, one or more customer edge (CE) routers
12.0(22)S attach to one or more provider edge (PE) routers.
12.0(23)S The following sections provide information about this
12.2(13)T feature:
12.2(14)S MPLS VPN Definition, page 4
12.0(26)S How an MPLS VPN Works, page 5

Major Components of MPLS VPNs, page 7
Benefits of an MPLS VPN, page 7
How to Configure MPLS Layer 3 VPNs, page 9
MPLS VPN Support for EIGRP Between 12.0(22)S This feature allows you to connect customers running
Provider Edge and Customer Edge EIGRP to an MPLS VPN.
12.2(15)T
12.2(18)S The following sections provide information about this
feature:
12.0(27)S
Configuring EIGRP as the Routing Protocol Between
the PE and CE Routers, page 23
Configuring EIGRP Redistribution in the MPLS VPN,
page 25
37
coincidental.
2005-2008 Cisco Systems, Inc. All rights reserved
38
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 previously imposed on hub-and-spoke topologies by removing the requirement
of one Virtual Routing and Forwarding (VRF) 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.

feature is supported, use 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
Feature Information for MPLS VPN Half-Duplex VRF, page 18

Prerequisites for Configuring MPLS VPN Half-Duplex VRF
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
For information about this feature on the Cisco 10000 series routers, see the Half-Duplex VRF section
of the Configuring Multiprotocol Label Switching chapter in the Cisco 10000 Series Router
Broadband Aggregation, Leased-Line, and MPLS Configuration Guide.
MPLS VPN Half-Duplex VRF Overview

The MPLS VPN Half-Duplex VRF feature provides the following benefits:
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. When 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 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)
To configure this feature on the Cisco 10000 series routers, see the Half-Duplex VRF section of the
Configuring Multiprotocol Label Switching chapter in the Cisco 10000 Series Router Broadband
Aggregation, Leased-Line, and MPLS Configuration Guide.
Configuring the Upstream and Downstream VRFs on the Spoke PE Router

To configure the upstream and downstream VRFs on the PE router or 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
4
DETAILED STEPS

Example:
Router> enable
Example:
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 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.
VRFs list of import, export, or both (import and
export) route-target extended communities.
5

Step 7 exit-address-family Exits from VRF address family configuration mode.
Example:
Router(config-vrf-af)# exit-address-family
Example:
Router(config-vrf-af)# end
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
6. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example: The type argument identifies the type of interface to be
The number argument identifies the port, connector, or
Step 4 vrf forwarding vrf-name [downstream vrf2] Associates a VRF with an interface or subinterface.
The vrf-name argument is the name of the VRF.
Example: The downstream vrf2 is the name of the downstream
Router(config-if)# vrf forwarding vrf1
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 the Downstream VRF for an AAA Server configuration, perform the following steps.
SUMMARY STEPS
1. show vrf [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 [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 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
show vrf detail vrf-name

Use this 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]
Connected addresses are not in global routing table
Export VPN route-target communities
RT:2:0
Import VPN route-target communities
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
No Export VPN route-target communities
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
No Export VPN route-target communities
RT:100:1
No import route-map
No export route-map
8
Step 2 show ip route vrf vrf-name

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

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 interfaceyou specify, including information about
the associated upstream and downstream VRFs.
The following example shows how to display information about the subinterface named POS3/0/1:
Router# show running-config interface POS3/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)# rd 1:0
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-af)# route-target import 1:8
Associating a VRF with an Interface: Example

The following example associates the VRF named Up with the POS3/0/1 subinterface and specifies the
downstream VRF named Down:
Router> enable
Router(config)# interface POS 3/0/1
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
route-target export 1:100
exit-address-family
!
vrf definition U
rd 1:0
address-family ipv4
route-target import 1:0
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
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
14
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 PEs Core-Facing Interfaces and Processes

interface Loopback0
ip address 10.11.11.11 255.255.255.255
!
interface POS3/0/2
ip address 10.0.1.1 255.0.0.0
mpls ip
!
router ospf 100
auto-cost reference-bandwidth 1000
nsf enforce global
redistribute connected subnets
network 10.11.11.11 0.0.0.0 area 100
network 10.0.1.0 0.255.255.255 area 100
Spoke PEs Edge-Facing Interfaces and Processes

interface Loopback100
vrf forwarding Down
ip address 10.22.22.22 255.255.255.255
!
interface POS3/0/1
vrf forwarding Up downstream Down
ip address 10.0.0.1 255.0.0.0
!
interface POS3/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

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
Configuring IPv4 and IPv6 VRFs MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
Unicast Reverse Path Forwarding Configuring Unicast Reverse Path Forwarding
Standards
Standard Title
MIBs
MIB MIBs Link
16
RFCs
RFCs
RFC Title
Description Link
17
Feature Information for MPLS VPN Half-Duplex VRF

Table 1 Feature Information for MPLS VPN Half-Duplex VRF

MPLS VPN - Half Duplex VRF (HDVRF) 12.3(6) This feature ensures that VPN clients that connect to the
Support with Static Routing 12.3(11)T same PE router at the edge of the MPLS VPN use the hub
12.2(28)SB site to communicate.
In 12.3(6), this feature was introduced.
In 12.2(28)SB, this feature was integrated
MPLS VPN Half-Duplex VRF 12.2(28)SB2 In 12.2(28)SB2, support for dynamic routing protocols was
12.4(20)T added.
12.2(33)SRC For the Cisco 10000 series routers, see the Half-Duplex
VRF section of the Configuring Multiprotocol Label
Switching chapter in the Cisco 10000 Series Router
Broadband Aggregation, Leased-Line, and MPLS
Configuration Guide at the following URL:
http://www.cisco.com/univercd/cc/td/doc/product/aggr/100
00/swconfig/cfggdes/bba/dffsrv.htm#wp1065648
In 12.4(20)T, this feature, with support for dynamic routing
protocols, was integrated.
In Cisco IOS Release 12.2(33)SRC this feature, with
support for dynamic routing protocols, was integrated into
the SR train.
show ip interface, show vrf
18
coincidental.
19
20
MPLS VPNShow Running VRF
First Published: March 16, 2006

The MPLS VPNShow Running VRF feature provides a Cisco IOS command-line interface (CLI)
option to display a subset of the running configuration on a router that is linked to a Virtual Private
Network (VPN) routing and forwarding (VRF) instance. You can display the configuration of a specific
VRF or of all VRFs configured on a router.
On heavily loaded routers, the display of the configuration file might require several pages or screens.
As the configuration increases in size and complexity, the possibility of misconfiguration also increases.
You might find it difficult to trace a problem on a router where you have several VRFs configured. A
command that displays all the elements of the configuration linked to a VRF allows for easier
troubleshooting on a per-VRF basis and facilitates comparisons among configurations of different VRFs
on the same router.

feature is supported, use the Feature Information for MPLS VPNShow Running VRF section on page 6.
Contents
Prerequisites for MPLS VPNShow Running VRF, page 2
Restrictions for MPLS VPNShow Running VRF, page 2
Information About MPLS VPNShow Running VRF, page 2
How to Configure MPLS VPNShow Running VRF, page 4
Prerequisites for MPLS VPNShow Running VRF
Configuration Examples for MPLS VPNShow Running VRF, page 4

Feature Information for MPLS VPNShow Running VRF, page 6
Glossary, page 8
Prerequisites for MPLS VPNShow Running VRF

A Cisco IOS image that supports VRFs installed on the router
At least one VRF configured on the router
Cisco Express Forwarding for MPLS VPN routing and forwarding
Restrictions for MPLS VPNShow Running VRF

Any element of the running configuration of the router that is not linked directly to a VRF is not
displayed. For example, a route map associated with a Border Gateway Protocol (BGP) neighbor in a
VRF address-family configuration is not displayed. The VRF address-family configuration under BGP
is displayed, but the route-map configuration is not. An exception to this general rule is the display of a
controller configuration (for more information, see the Display of Configuration Not Directly Linked
to a VRF section on page 4).
Information About MPLS VPNShow Running VRF

Before using the MPLS VPNShow Running VRF feature, you should understand the following
information:
Configuration Elements Displayed for the MPLS VPNShow Running VRF Feature, page 2
Display of VRF Routing Protocol Configuration, page 3
Display of Configuration Not Directly Linked to a VRF, page 4
Configuration Elements Displayed for the MPLS VPNShow Running VRF

Feature
You can display the running configuration associated with a specific VRF or all VRFs on the router by
entering the show running-config vrf command. To display the running configuration of a specific VRF,
enter the name of the VRF as an argument to the show running-config vrf command. For example, for
a VRF named vpn3, you enter:
Router# show running-config vrf vpn3
2
Information About MPLS VPNShow Running VRF
The show running-config vrf command displays the following elements of the running configuration
on a router:
The VRF configuration
This includes any configuration that is applied in the VRF submode.
The configuration of each interface in the VRF
Entering a show run vrf vpn-name command is the same as executing a show running-config
interface type number for each interface that you display by use of the show ip vrf vpn-name
command. The interfaces display in the same sorted order that you would expect from the show ip
interface command.
For a channelized interface, the configuration of the controller is displayed (as shown by the show
run controller controller-name command).
For a subinterface, the configuration of the main interface is displayed.
The configuration of routing-protocol address families or processes that are linked with the VRF,
including static routing configuration (see the Display of VRF Routing Protocol Configuration
section on page 3)
Display of VRF Routing Protocol Configuration

Open Shortest Path First (OSPF), Routing Information Protocol (RIP), Border Gateway Protocol (BGP),
Enhanced Interior Gateway Routing Protocol (EIGRP), and static routing are routing protocols that
support VRF configuration.
OSPF has one process per VRF. The show running-config vrf command display includes the complete
configuration of any OSPF process associated with the VRF. For example, the following shows the
sample display for OSPF process 101, which is associated with the VRF named vpn3:
area 1 sham-link 10.43.43.43 10.23.23.23 cost 10
network 172.17.0.0 0.255.255.255 area 1
RIP, BGP, and EIGRP support VRF address-family configuration. If a VRF address family for the VRF
exists for any of these routing protocols, a configuration in the following format is displayed:
router protocol {AS | PID}
!
address-family ipv4 vrf vrf-name
.
.
.
Where the protocol argument is one of the following: rip, bgp or eigrp; the AS argument is an
autonomous system number; the PID argument is a process identifier; and the vrf-name argument is the
name of the associated VRF.
The following shows a sample display for a BGP with autonomous system number 100 associated with
a VRF named vpn3:
!
router bgp 100
!
redistribute ospf 101 match external 1 external 2
no auto-summary
3
How to Configure MPLS VPNShow Running VRF
no synchronization
exit-address-family
!
The show running-config vrf command also includes the configuration of any static routes configured
in the VRF. For example:
ip route vrf vpn1 10.1.1.0 255.255.255.0 10.30.1.1 global
ip route vrf vpn1 10.1.2.0 255.255.255.0 10.125.1.2
Display of Configuration Not Directly Linked to a VRF

Any element of a configuration that is not linked directly to a VRF is not displayed. In some instances,
the display of the configuration of an element that is not directly linked to a VRF is required.
For example, the show running-config vrf command displays the configuration of an E1 controller
whose serial subinterfaces are in a VRF. The command displays the controller configuration and the
subinterface configuration.
How to Configure MPLS VPNShow Running VRF

There are no tasks for the MPLS VPNShow Running VRF feature.
Configuration Examples for MPLS VPNShow Running VRF

There are no configuration examples for the MPLS VPNShow Running VRF feature.
The following sections provide references related to the MPLS VPNShow Running VRF feature.
Related Documents
MPLS command descriptions Cisco IOS Multiprotocol Label Switching Command Reference
Standards
Standards Title
4
Command Reference
MIBs
MIBs MIBs Link
RFCs
RFCs Title
Description Link
Command Reference
show policy-map interface brief
show running-config vrf
5
Feature Information for MPLS VPNShow Running VRF

Table 1 Feature Information for MPLS VPNShow Running VRF

MPLS VPNShow Running VRF 12.2(28)SB The MPLS VPNShow Running VRF feature provides a
12.0(32)SY CLI option to display a subset of the running configuration
12.2(33)SRB on a router that is linked to a VRF. You can display the
12.2(33)SXH configuration of a specific VRF or of all VRFs configured
12.4(20)T on a router. A command that displays all the elements of the
configuration linked to a VRF allows for easier
troubleshooting on a per-VRF basis and facilitates
comparisons among configurations of different VRFs on the
same router.
In 12.0(32)SY, support was added for a Cisco IOS
12.0SY release.
In 12.2(33)SRB, support was added for a Cisco IOS
12.2SR release.
In 122(33)SXH, support was added for a Cisco IOS
12.2SX release.
In 12.4(20)T, support was added for a Cisco IOS
12.4T release.
feature:
Configuration Elements Displayed for the MPLS
VPNShow Running VRF Feature, page 2
Display of VRF Routing Protocol Configuration,
page 3
Display of Configuration Not Directly Linked to a VRF,
page 4
6
Table 1 Feature Information for MPLS VPNShow Running VRF (continued)

show policy-map interface brief, show running-config
vrf.
7
Glossary
Glossary
BGPBorder Gateway Protocol. An interdomain routing protocol that replaces External Gateway
Protocol (EGP). BGP systems exchange reachability information with other BGP systems. BGP is
EGPExternal Gateway Protocol. An internet protocol for exchanging routing information between
autonomous systems. EGP is documented in RFC 904. Not to be confused with the general term exterior
gateway protocol. EGP is an obsolete protocol that was replaced by Border Gateway Protocol (BGP).
EIGRPEnhanced Interior Gateway Routing Protocol. Advanced version of Interior Gateway Routing
Protocol (IGRP) developed by Cisco. Provides superior convergence properties and operating efficiency,
and combines the advantages of link state protocols with those of distance vector protocols.
IGPInterior 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).
IGRPInterior Gateway Routing Protocol. An Interior Gateway Protocol (IGP) developed by Cisco to
address the issues associated with routing in large, heterogeneous networks.
MPLSMultiprotocol Label Switching. A switching method that forwards IP traffic through the use of
a label. This label instructs the routers and the switches in the network where to forward each packet
based on preestablished IP routing information.
OSPFOpen Shortest Path First. A link-state, hierarchical, Interior Gateway Protocol (IGP) routing
algorithm and routing protocol 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 Intermediate System-to-Intermediate System (IS-IS)
protocol.
RIPRouting Information Protocol. Internal Gateway Protocol (IGP) supplied with UNIX Berkeley
Software Distribution (BSD) systems. RIP is the most common IGP in the Internet. It uses hop count as
a routing metric.
VPNVirtual Private Network. The result of a router configuration that enables IP traffic to use
tunneling to travel securely over a public TCP/IP network.
VRFA Virtual Private Network (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. In general, a VRF
includes the routing information that defines a customer VPN site that is attached to a provider edge (PE)
router.
coincidental.
8
MPLS VPNVRF CLI for IPv4 and IPv6 VPNs

This document describes how to configure a Virtual Private Network (VPN) routing and forwarding
(VRF) instance for IPv4 and IPv6 VPNs and describes how to upgrade your existing single-protocol
IPv4-only VRF to a multiprotocol VRF configuration.
The MPLS VPNVRF CLI for IPv4 and IPv6 VPNs feature introduces Cisco IOS command-line
interface (CLI) commands that allow you to enable an IPv4 and IPv6 VPN in the same VRF instance and
to simplify the migration from a single-protocol VRF configuration to a multiprotocol VRF
configuration.

supported, see the Feature Information for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs section on
page 19.
Contents
Prerequisites for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs, page 2
Restrictions for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs, page 2
Information About MPLS VPNVRF CLI for IPv4 and IPv6 VPNs, page 2
How to Configure MPLS VPNVRF CLI for IPv4 and IPv6 VPNs, page 6
Configuration Examples for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs, page 14
Prerequisites for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs

Feature Information for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs, page 19
Glossary, page 21
Prerequisites for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
The MPLS VPNVRF CLI for IPv4 and IPv6 VPNs feature has the following prerequisites:
For migrationAn IPv4 Multiprotocol Label Switching (MPLS) VPN VRF must exist.
For a new VRF configurationCisco Express Forwarding and an MPLS label distribution method,
either Label Distribution Protocol (LDP) or MPLS traffic engineering (TE), must be enabled on all
routers in the core, including the provider edge (PE) routers.
Restrictions for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
The MPLS VPNVRF CLI for IPv4 and IPv6 VPNs feature has the following restrictions:
Once you have converted to a multiprotocol VRF, you cannot convert the VRF back to an IPv4-only
single-protocol VRF.
You can associate an interface with only one VRF. You cannot configure a VRF for IPv4 and a
different VRF for IPv6 on the same interface.
You can configure only IPv4 and IPv6 address families in a multiprotocol VRF. Other protocols
(IPX, AppleTalk, and the like) are not supported.
Information About MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
Before you use the MPLS VPNVRF CLI for IPv4 and IPv6 VPNs feature to migrate from a
single-protocol VRF to a multiprotocol VRF, you should understand the following concepts:
VRF Concepts Similar for IPv4 and IPv6 MPLS VPNs, page 2
Single-Protocol VRF to Multiprotocol VRF Migration, page 3
Multiprotocol VRF Configurations Characteristics and Examples, page 4
VRF Concepts Similar for IPv4 and IPv6 MPLS VPNs

VPNs for IPv6 use the same VRF concepts that IPv4 MPLS VPNs use, such as address families, route
distinguishers, route targets, and VRF identifiers. Customers that use both IPv4 and IPv6 VPNs might
want to share VRF policies between address families. They might want a way to define applicable VRF
policies for all address families, instead of defining VRF policies for an address family individually as
they do for or a single-protocol IPv4-only VRF.
Prior to Cisco IOS Release 12.2(33)SRB, a VRF applied only to an IPv4 address family. A one-to-one
relationship existed between the VRF name and a routing and forwarding table identifier, between a VRF
name and a route distinguisher (RD), and between a VRF name and a VPN ID. This configuration is
called a single-protocol VRF.
Book Title
2
Cisco IOS Release 12.2(33)SRB introduces support for a multiple address-family (multi-AF) VRF
structure. The multi-AF VRF allows you to define multiple address families under the same VRF. A
given VRF, identified by its name and a set of policies, can apply to both an IPv4 VPN and an IPv6 VPN
at the same time. This VRF can be activated on a given interface, even though the routing and forwarding
tables are different for the IPv4 and IPv6 protocols. This configuration is called a multiprotocol VRF.
Single-Protocol VRF to Multiprotocol VRF Migration

Prior to Cisco IOS Release 12.2(33)SRB, you could create a single-protocol IPv4-only VRF. You
created a single-protocol VRF by entering the ip vrf command. To activate the single-protocol VRF on
an interface, you entered the ip vrf forwarding (interface configuration) command.
After the introduction of the MPLS VPNVRF CLI for IPv4 and IPv6 VPNs feature in Cisco IOS
Release 12.2(33)SRB, you create a multiprotocol VRF by entering the vrf definition command. To
activate the multiprotocol VRF on an interface, you enter the vrf forwarding command.
The MPLS VPNVRF CLI for IPv4 and IPv6 VPNs feature introduces the vrf upgrade-cli
multi-af-mode {common-policies | non-common-policies} [vrf vrf-name] command that forces VRF
configuration migration from a single-protocol VRF model to a multiprotocol VRF model:
If the route-target policies apply to all address families configured in the multi-AF VRF, select the
common-policies keyword.
If the route-target policies apply only to the IPv4 address family that you are migrating, select the
non-common-policies keyword.
After you enter the vrf upgrade-cli command and save the configuration to NVRAM, the
single-protocol VRF configuration is saved as a multiprotocol VRF configuration. In the upgrade
process, the ip vrf command is converted to the vrf definition command (global configuration
commands) and the ip vrf forwarding command is converted to the vrf forwarding command (interface
configuration command). The vrf upgrade-cli command has a one-time immediate effect.
You might have both IPv4-only VRFs and multiprotocol VRFs on your router. Once you create a VRF,
you can edit it using only the commands in the mode in which it was created. For example, you created
a VRF named vrf2 with the following multiprotocol VRF commands:
Enter configuration command, one per line. End with CNTL/Z
Router(config-vrf)# route-target export 2:2
Router(config-vrf)# end
If you try to edit VRF vrf2 with IPv4-only VRF commands, you receive the following message:
Enter configuration command, one per line. End with CNTL/Z
Router(config)# ip vrf vrf2
% Use vrf definition vrf2 command
If you try to edit an IPv4-only VRF with the multiprotocol VRF commands, you would receive this
message, where <vrf-name> is the name of the IPv4-only VRF:
% Use ip vrf <vrf-name> command
Book Title
3
The ip vrf name and ip vrf forwarding (interface configuration) name commands will be available for
a period of time before they are removed. Use the vrf upgrade command to migrate your older IPv4-only
VRFs to the new multiprotocol VRF configuration. When you need to create a new VRFwhether the
VRF is for an IPv4 VPN, or IPv6 VPN, or bothuse the multiprotocol VRF vrf definition and vrf
forwarding commands that support a multi-AF configuration.
Multiprotocol VRF Configurations Characteristics and Examples

In a multiprotocol VRF, you can configure both IPv4 VRFs and IPv6 VRFs under the same address
family or configure separate VRFs for each IPv4 or IPv6 address family. The multiprotocol VRF
configuration has the following characteristics:
The VRF name identifies a VRF, which might have both IPv4 and IPv6 address families. On the
same interface, you cannot have IPv4 and IPv6 address families using different VRF names.
The RD, VPN ID, and Simple Network Management Protocol (SNMP) context are shared by both
IPv4 and IPv6 address families for a given VRF.
The policies (route target, for example) specified in multi-AF VRF mode, outside the address-family
configuration, are defaults to be applied to each address family. Route targets are the only VRF
characteristics that can be defined inside and outside an address family.
The following is also true when you associate a multiprotocol VRF with an interface:
Binding an interface to a VRF (vrf forwarding vrf-name command) removes all IPv4 and IPv6
addresses configured on that interface.
Once you associate a VRF with a given interface, all active address families belong to that VRF. The
exception is when no address of the address-family type is configured, in which case the protocol is
disabled.
Configuring an address on an interface that is bound to a VRF requires that the address family
corresponding to the address type is active for that VRF. Otherwise, an error message is issued
stating that the address family must be activated first in the VRF.
Backward compatibility with the single-protocol VRF CLI is supported in Cisco IOS
Release 12.2(33)SRB. This means that you might have single-protocol and multiprotocol CLI on the
same router, but not in the same VRF configuration.
The single-protocol CLI continues to allow you to define an IPv4 address within a VRF and an IPv6
address in the global routing table on the same interface.
The following sections have multiprotocol VRF configuration examples:
Multiprotocol VRF Configuration: Single Protocol with Noncommon Policies Example, page 4
Multiprotocol VRF Configuration: Multiprotocol with Noncommon Policies Example, page 5
Multiprotocol VRF Configuration: Multiprotocol with Common Policies Example, page 5
Multiprotocol VRF Configuration: Multiprotocol with Common and Noncommon Policies, page 5
Multiprotocol VRF Configuration: Single Protocol with Noncommon Policies Example

The following is an example of a multiprotocol VRF configuration for a single protocol (IPv4) with
route-target policies in the address-family configuration:
vrf definition vrf2
rd 2:2
!
address-family ipv4
Book Title
4

exit-address-family
The RD (2:2) applies to all address families defined for VRF vrf2.
Multiprotocol VRF Configuration: Multiprotocol with Noncommon Policies Example

The following is an example of a multiprotocol VRF configuration for IPv4 and IPv6 VPNs in which the
route-target policies are defined in the separate address-family configurations:
vrf definition vrf2
rd 2:2
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
Multiprotocol VRF Configuration: Multiprotocol with Common Policies Example

The following is an example of a multiprotocol VRF configuration for IPv4 and IPv6 VPNs with
route-target policies defined in the global part of the VRF:
vrf definition vrf2
rd 2:2
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
The route-target policies are defined outside the address-family configurations. Therefore, the policies
apply to all address families defined in VRF vrf2.
Multiprotocol VRF Configuration: Multiprotocol with Common and Noncommon Policies

The following is an example of a multiprotocol VRF with route-target policies defined in both global
and address-family areas:
For IPv6, the route-target definitions are defined under the address family. These definitions are
used and the route-target definitions in the global area are ignored. Therefore, the IPv6 VPN ignores
import 100:2.
For IPv4, no route-target policies are defined under the address family, therefore, the global
definitions are used.
vrf definition vfr1
!
Book Title
5
How to Configure MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
This feature provides Cisco IOS CLI commands that allow you to configure a multiprotocol VRF (IPv4
and IPv6 VPNs in the same VRF) and to migrate a single-protocol VRF configuration (IPv4-only VRF)
to a multiprotocol VRF configuration.
A multiprotocol VRF allows you to share route targets policies (import and export) between IPv4 and
IPv6 or to configure separate route-target policies for IPv4 and IPv6 VPNs.
Perform the tasks in the following sections to configure or migrate to the MPLS VPNVRF CLI for
IPv4 and IPv6 VPNs feature:
Configuring a VRF for IPv4 and IPv6 MPLS VPNs, page 6 (required)
Associating a Multiprotocol VRF with an Interface, page 9 (required)
Verifying the MPLS VPNVRF CLI for IPv4 and IPv6 VPNs Configuration, page 10 (optional)
Perform the following task to migrate from a single-protocol VRF to a multiprotocol VRF configuration:
Migrating from a Single-Protocol IPv4-Only VRF to a Multiprotocol VRF Configuration, page 13
Configuring a VRF for IPv4 and IPv6 MPLS VPNs

Perform the following task to configure a VRF for IPv4 and IPv6 MPLS VPNs. When you configure a
VRF for both IPv4 and IPv6 VPNs (a multiprotocol VRF), you can choose to configure route-target
policies that apply to all address families in the VRF or you can configure route-target policies that apply
to individual address families in the VRF.
The following task shows how to configure a VRF that has that has route-target policies defined for IPv4
and IPv6 VPNs in separate VRF address families.
SUMMARY STEPS
1. enable
Book Title
6

10. end
DETAILED STEPS

Example:
Router> enable
Example:
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.
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.
a VRF.
Book Title
7

Example:
community.
Step 7 exit-address-family Exits from VRF address family configuration mode.
Example:
a VRF.
Example:
community.
Enter the route-target command one time for each target
community.
Example:
Router(config-vrf-af)# end
Book Title
8
Associating a Multiprotocol VRF with an Interface

Perform the following task to associate a multiprotocol VRF with an interface. Associating the VRF with
an interface activates the VRF.
SUMMARY STEPS
1. enable
4. vrf forwarding vrf-name
6. ipv6 address {ipv6-address/prefix-length | prefix-name sub-bits/prefix-length}
7. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example: The type argument identifies the type of interface to be
The number argument identifies the port, connector, or
Step 4 vrf forwarding vrf-name Associates a VRF with an interface or subinterface.
The vrf-name argument is the name of the VRF.
Example:
Router(config-if)# vrf forwarding vrf1
Example: The mask argument is the mask of the associated IP
255.255.255.255
subnet.
address.
Book Title
9

Step 6 ipv6 address {ipv6-address/prefix-length | Configures an IPv6 address based on an IPv6 general prefix
prefix-name sub-bits/prefix-length} and enables IPv6 processing on an interface.
The ipv6-address argument is the IPv6 address to be
Example: used.
Router(config-if)# ipv6 address
2001:0DB8:0300:0201::/64 The prefix-length argument is the length of the IPv6
prefix, which is a decimal value that indicates how
many of the high-order contiguous bits of the address
comprise the prefix (the network portion of the
address). A slash mark must precede the decimal value.
The prefix-name argument is a general prefix that
specifies the leading bits of the network to be
configured on the interface.
The sub-bits argument is the subprefix bits and host bits
of the address to be concatenated with the prefixes
provided by the general prefix specified with the
prefix-name argument.
The sub-bits argument must be in the form documented
in RFC 2373 where the address is specified in
hexadecimal using 16-bit values between colons.
Example:
Router(config-if) end
Verifying the MPLS VPNVRF CLI for IPv4 and IPv6 VPNs Configuration
Perform the following task to verify the MPLS VPNVRF CLI for IPv4 and IPv6 VPNs feature
configuration, that is, to show that the VRF configuration is upgraded to a multi-AF multiprotocol VRF.
SUMMARY STEPS
1. enable
2. show running-config vrf [vrf-name]
3. show vrf
4. show vrf detail [vrf-name]
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#
Book Title
10
Step 2 show running-config vrf [vrf-name]

Use this command to verify that the upgrade to a multi-AF multiprotocol VRF configuration was
successful. The following is sample command output before the upgrade to a multi-AF multiprotocol
VRF:

ip vrf vpn2
rd 1:1
route-target both 1:1
!
!
interface Loopback1
ip address 10.43.43.43 255.255.255.255
!
The following is sample command output after you upgrade to a multi-AF multiprotocol VRF with
common policies for all address families:

vrf definition vpn1
rd 1:1
!
address-family 1pv4
exit-address-family
!
!
interface Loopback1
ip address 10.43.43.43 255.255.255.255
!
This configuration contains the vrf definition command. The vrf definition command replaces the
ip vrf command in the multi-AF multiprotocol VRF configuration.
Step 3 show vrf
Use this command to verify that the upgrade to a multi-AF multiprotocol VRF configuration was
successful. The show vrf command replaces the show ip vrf command when a VRF configuration is
updated to a multi-AF multiprotocol VRF configuration. The show vrf command displays the protocols
defined for a VRF. The following command shows sample output after you upgrade a single-protocol
VRF configuration to a multi-AF multiprotocol VRF configuration:
Router# show vrf vpn1
Name Default RD Protocols Interfaces

vpn1 1:1 ipv4 Lo1/0
Book Title
11
The following is sample output from the show ip vrf vp1 command. Compare this to the output of the
show vrf vpn1 command. The protocols under the VRF are not displayed.
Router# show ip vrf vrf1
Name Default RD Interface

vpn1 1:1 Loopback1
The following is sample output from the show vrf command for multiprotocol VRFs, one of which
contains both IPv4 and IPv6 protocols:
Router# show vrf
Name Default RD Protocols Interfaces

vpn1 1:1 ipv4 Lo1/0
vpn2 100:3 ipv4 Lo23 AT3/0/0.1
vpn4 100:2 ipv4,ipv6
Step 4 show vrf detail [vrf-name]

Use this command to display all characteristics of the defined VRF to verify that the configuration is as
you expected. For example, if your VRF configuration for VRF vpn1 is as follows:
vrf definition vpn1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
This command would display the following:

Router# show vrf detail vpn1
VRF vpn1 (VRF Id = 3); default RD <not set>; default VPNID <not set>
No interfaces
Address family ipv4 (Table ID = 3 (0x3)):
RT:100:1

RT:100:1 RT:100:2
No import route-map
No export route-map
VRF label allocation mode: per-prefix
Address family ipv6 (Table ID = 503316483 (0x1E000003)):
RT:100:1

RT:100:1 RT:100:3
No import route-map
No export route-map
Book Title
12
Step 5 exit
Router# exit
Router>
Migrating from a Single-Protocol IPv4-Only VRF to a Multiprotocol VRF

Configuration
Perform the following task to force migration from a single-protocol IPv4-only VRF to a multiprotocol
VRF configuration.
The multiprotocol VRF configuration allows you to define multiple address families under the same
VRF. A given VRF, identified by its name and a set of policies, can apply to both an IPv4 VPN and an
IPv6 VPN at the same time. This VRF can be activated on a given interface, even though the routing and
forwarding tables are different for the IPv4 and IPv6 protocols.
SUMMARY STEPS
1. enable
3. vrf upgrade-cli multi-af-mode {common-policies | non-common-policies} [vrf vrf-name]
4. exit
5. show running-config vrf vrf-name
DETAILED STEPS

Example:
Router> enable
Example:
Book Title
13
Configuration Examples for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs

Step 3 vrf upgrade-cli multi-af-mode {common-policies Upgrades a VRF instance or all VRFs configured on the
| non-common-policies} [vrf vrf-name] router to support multiple address families under the same
VRF.
Example: The multi-af-mode keyword specifies an upgrade of a
Router(config)# vrf upgrade-cli multi-af-mode single-protocol VRF or all VRFs to a multiprotocol
common-policies vrf vpn4
VRF that supports multi-AFs configuration.
The common-policies keyword specifies to copy the
route-target policies to the common part of the VRF
configuration so that the policies apply to all address
families configured in the multi-AF VRF.
The non-common-policies keyword specifies to copy
the route-target policies to the IPv4 address family part
of the VRF configuration so that the policies apply only
to IPv4.
The vrf keyword specifies a VRF for the upgrade to a
multi-AF VRF configuration.
The vrf-name argument is the name of the
single-protocol VRF to upgrade to a multi-AF VRF
configuration.
Example:
Step 5 show running-config vrf [vrf-name] Displays the subset of the running configuration of a router
that is linked to a specific VRF instance or to all VRFs
configured on the router.
Example:
Router# show running-config vrf vpn4 The vrf-name argument is the name of the VRF of
which you want to display the configuration.
Note The Cisco IOS image that supports the
multiprotocol VRF commands might not support
the show running-config vrf command. You can
use the show running-config command instead.
Configuration Examples for MPLS VPNVRF CLI for IPv4 and

IPv6 VPNs
The following examples show how to use the VRF CLI provided by the MPLS VPNVRF CLI for IPv4
and IPv6 VPNs feature to migrate from a single-protocol VRF to a multiprotocol VRF configuration:
Configuring a VRF for IPv4 and IPv6 VPNs: Example, page 15
Associating a Multiprotocol VRF with an Interface: Example, page 15
Migrating from a Single-Protocol IPv4-Only VRF Configuration to a Multiprotocol VRF
Configuration: Example, page 16
Book Title
14
Configuring a VRF for IPv4 and IPv6 VPNs: Example

The following example shows how to configure a VRF for IPv4 and IPv6 VPNs:
configure terminal
!
vrf definition vrf1
rd 100:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
In this example, noncommon policies are defined in the address-family configuration.

The following is an example of a VRF for IPv4 and IPv6 that has common policies defined in the global
part of the VRF configuration:
configure terminal
!
vrf definition vrf2
rd 200:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
end
Associating a Multiprotocol VRF with an Interface: Example

The following example shows how to associate a multiprotocol VRF with an interface:
configure terminal
!
vrf forwarding vrf1
ip address 10.24.24.24 255.255.255.255
ipv6 address 2001:0DB8:0300:0201::/64
end
Book Title
15
Migrating from a Single-Protocol IPv4-Only VRF Configuration to a

Multiprotocol VRF Configuration: Example
This section contains examples that show how to migrate from a single-protocol IPv4-only VRF to a
multiprotocol VRF configuration.
This example shows a single-protocol IPv4-only VRF before the Cisco IOS VRF CLI for IPv4 and IPv6
is entered on the router:
ip vrf vrf1
rd 1:1
interface Loopback1
ip vrf forwarding V1
ip address 10.3.3.3 255.255.255.255
This example shows how to force the migration of the single-protocol VRF vrf1 to a multiprotocol VRF
configuration:
!
Router(config)# vrf upgrade-cli multi-af-mode common-policies vrf vrf1
You are about to upgrade to the multi-AF VRF syntax commands.

You will loose any IPv6 address configured on interfaces
belonging to upgraded VRFs.
Are you sure ? [yes]: yes
Number of VRFs upgraded: 1
This example shows the multiprotocol VRF configuration after the forced migration:
vrf definition vrf1
rd 1:1
!
address-family ipv4
exit-address-family
!
interface Loopback1
vrf forwarding V1
ip address 10.3.3.3 255.255.255.255
The following is another example of a multi-AF multiprotocol VRF configuration:

vrf definition vrf2
rd 100:1
address family ipv6
exit-address-family
!
ip vrf vrf1
rd 200:1
!
vrf forwarding vrf2
Book Title
16
ip address 10.50.1.2 255.255.255.0

ipv6 address 2001:0DB8:0:1::/64
!
ip vrf forwarding vrf1
ip address 10.60.1.2 255.255.255.0
ipv6 address 2001:0DB8:1 :1::/64
In this example, all addresses (IPv4 and IPv6) defined for interface Ethernet0/0 are in VRF vrf2. For the
interface Ethernet0/1, the IPv4 address is defined in VRF vrf1 but the IPv6 address is in the global
IPv6 routing table.
The following sections provide references related to the MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
feature.
Related Documents
MPLS MPLS Product Literature
Commands for configuring MPLS and MPLS VPNs Cisco IOS Multiprotocol Label Switching Command Reference
Configuration tasks for MPLS and MPLS VPNs Cisco IOS Multiprotocol Label Switching Configuration Guide
Standards
Standard Title
MIBs
MIB MIBs Link
Book Title
17
Command Reference
RFCs
RFC Title
RFC 1771 A Border Gateway Protocol 4 (BGP-4)
RFC 4364 BGP MPLS/IP Virtual Private Networks (VPNs)
Description Link
Command Reference
show vrf
vrf definition
vrf forwarding
vrf upgrade-cli
Book Title
18
Feature Information for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
Feature Information for MPLS VPNVRF CLI for IPv4 and IPv6
VPNs
Table 1 Feature Information for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs

MPLS VPNVRF CLI for IPv4 and IPv6 12.2(33)SRB This document describes how to configure a multiprotocol
VPNs 12.2(33)SXI Virtual Private Network (VPN) routing and forwarding (VRF)
instance for IPv4 and IPv6 VPNs and describes how to upgrade
your existing single-protocol IPv4-only VRF to a multiprotocol
VRF configuration.
The MPLS VPNVRF CLI for IPv4 and IPv6 VPNs feature
introduces Cisco IOS command-line interface (CLI) commands
that allow you to enable an IPv4 and IPv6 VPN in the same
Multiprotocol Label Switching (MPLS) VRF instance and to
simplify the migration from a single-protocol VRF configuration
to a multiprotocol VRF configuration.
In 12.2(33)SRB, this feature was introduced on the Cisco 7600
router.
In 12.2(33)SXI, this feature was integrated into a Cisco IOS
12.2SXI release.
The following sections provide information about this feature:
VRF Concepts Similar for IPv4 and IPv6 MPLS VPNs,
page 2
Single-Protocol VRF to Multiprotocol VRF Migration,
page 3
Multiprotocol VRF Configurations Characteristics and
Examples, page 4
Configuring a VRF for IPv4 and IPv6 MPLS VPNs, page 6
Associating a Multiprotocol VRF with an Interface, page 9
Book Title
19
Feature Information for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
Table 1 Feature Information for MPLS VPNVRF CLI for IPv4 and IPv6 VPNs (continued)

Verifying the MPLS VPNVRF CLI for IPv4 and IPv6
VPNs Configuration, page 10
Migrating from a Single-Protocol IPv4-Only VRF to a
Multiprotocol VRF Configuration, page 13
The following commands were introduced or modified: show
vrf, vrf definition, vrf forwarding, vrf upgrade-cli.
Book Title
20
Glossary
Glossary
6PEIPv6 provider edge router or a Multiprotocol Label Switching (MPLS) label switch router (LSR)
edge router using IPv6.
6VPEIPv6 Virtual Private Network (VPN) provider edge router.
AFaddress family. Set of related communication protocols in which all members use a common
addressing mechanism to identify endpoints. Also called protocol family.
AFIAddress Family Identifier. Carries the identity of the network-layer protocol that is associated
with the network address.
BGPBorder Gateway Protocol. A routing protocol used between autonomous systems. It is the routing
protocol that makes the internet work. BGP is a distance-vector routing protocol that carries connectivity
information and an additional set of BGP attributes. These attributes allow for a set of policies for
deciding the best route to use to reach a given destination. BGP is defined by RFC 1771.
CEcustomer edge router. A service provider router that connects to Virtual Private Network (VPN)
customer sites.
FIBForwarding Information Base. Database that stores information about switching of data packets.
A FIB is based on information in the Routing Information Base (RIB). It is the optimal set of selected
routes that are installed in the line cards for forwarding.
HAhigh availability. High availability is defined as the continuous operation of systems. For a system
to be available, all componentsincluding application and database servers, storage devices, and the
end-to-end networkneed to provide continuous service.
IPInternet 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.
IPv4IP Version 4. Network layer for the TCP/IP protocol suite. IPv4 is a connectionless, best-effort
packet switching protocol.
IPv6IP Version 6. Replacement for IPv4. IPv6 is a next-generation IP protocol. IPv6 is backward
compatible with and designed to fix the shortcomings of IPv4, such as data security and maximum
number of user addresses. IPv6 increases the address space from 32 to 128 bits, providing for an
unlimited number of networks and systems. It also supports quality of service (QoS) parameters for
real-time audio and video.
MFIMPLS Forwarding Infrastructure. In the Cisco MPLS subsystem, the data structure for storing
information about incoming and outgoing labels and associated equivalent packets suitable for labeling.
MPLSMultiprotocol Label Switching. MPLS is 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.
PEprovider edge router. A router that is part of a service providers network and that is connected to
a customer edge (CE) router. The PE router function is a combination of an MLS edge label switch router
(LSR) function with some additional functions to support Virtual Private Networks (VPNs).
RD (IPv4)route distinguisher. An 8-byte value that is concatenated with an IPv4 prefix to create a
unique VPN IPv4 (VPNv4) prefix.
RD (IPv6)route distinguisher. A 64-bit value that is prepended to an IPv6 prefix to create a globally
unique VPN-IPv6 address.
Book Title
21
Glossary
RIBRouting Information Base. The set of all available routes from which to choose the Forwarding
Information Base (FIB). The RIB essentially contains all routes available for selection. It is the sum of
all routes learned by dynamic routing protocols, all directly attached networks (that is-networks to which
a given router has interfaces connected), and any additional configured routes, such as static routes.
RTroute target. Extended community attribute used to identify the Virtual Private Network (VPN)
routing and forwarding (VRF) routing table into which a prefix is to be imported.
VPNVirtual Private Network. Enables IP traffic to travel securely over a public TCP/IP network by
encrypting all traffic from one network to another. A VPN uses tunneling to encrypt all information at
the IP level.
VRFVirtual Private Network (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. In general, a VRF includes the
routing information that defines a customer VPN site that is attached to a PE router.
VRF tableA routing and a forwarding table associated to a Virtual Private Network (VPN) routing
and forwarding (VRF) instance. This is a customer-specific table, enabling the provider edge (PE) router
to maintain independent routing states for each customer.
CCDE, CCENT, Cisco Eos, Cisco Lumin, Cisco Nexus, Cisco StadiumVision, Cisco TelePresence, Cisco WebEx, the Cisco logo, 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.
Book Title
22
MPLS VPNBGP Local Convergence

The MPLS VPNBGP Local Convergence feature reduces the downtime of a provider edge (PE) to
customer edge (CE) link failure. It does so by rerouting PE-egress traffic onto a backup path to the CE
before BGP has re-converged.
The MPLS VPNBGP Local Convergence feature is also referred to as local protection.
Note that the MPLS VPNBGP Local Convergence feature only affects traffic exiting the VPN.
Therefore, it cannot fully protect traffic end-to-end by itself.

supported, see the Feature Information for MPLS VPNBGP Local Convergence section on page 13.
Contents
Prerequisites for MPLS VPNBGP Local Convergence, page 2
Restrictions for MPLS VPNBGP Local Convergence, page 2
Information About MPLS VPNBGP Local Convergence, page 3
How to Enable MPLS VPNBGP Local Convergence, page 5
Configuration Examples for MPLS VPNBGP Local Convergence, page 8
Feature Information for MPLS VPNBGP Local Convergence, page 13
Prerequisites for MPLS VPNBGP Local Convergence
Prerequisites for MPLS VPNBGP Local Convergence

Before this form of link protection can be enabled, the customer site must be connected to the
provider site by more than one path.
Both the main forwarding path and the redundant backup path must have been installed within BGP,
and BGP must support lossless switchover between operational paths.
Note Any routing protocol can be used between the PE and CE as long as the path is redistributed
into BGP. That includes: eBGP, RIP, EIGRP, IS-IS, OSPF, and static routing. Any next-hop
core tunneling technology that is supported by BGP is also supported for protection,
including MPLS, IP/L2TPv3, and IP/GRE. Enabling a Carrier's Carrier (CsC) protocol
between the PE and CE is also supported. Inter-AS option A (back-to-back VRF) is
supported because it is essentially the same as performing the PE-CE link protection in both
AS's. However, inter-AS options B and C protection are not supported at this time.
All Provider Edge routers that are serving as backup to the link must have assigned a unique Route
Distinguisher to each Virtual Routing and Forwarding table involved with the link to ensure that the
route reflectors advertise all available paths.
Although not required, it is recommended that the backup PE (shown as PE2 in Figure 2) also be
running the IOS version that is running on the PE (PE1) whose link with the CE will be protected;
that is, Cisco IOS Release 12.2(33) SRC, Cisco IOS Release 12.2(33)SB, Cisco IOS
Release 15.0(1)M or a more recent version of those products.
Restrictions for MPLS VPNBGP Local Convergence

This feature only affects traffic exiting the VPN. Therefore, it cannot fully protect traffic end-to-end
by itself.
Configuration of this feature is not allowed in IPv6.
Local protection is not applicable with VRF-lite. Although configuration of both features together
is not blocked, protection does not occur.
This link protection cannot be initiated during an HA stateful switchover (SSO). But links already
configured with this protection before the switchover begins will remain protected after the
switchover.
When performing an ISSU downgrade from an image that does include this link protection to an
image that does not support this feature, active protection will be halted when BGP routes are
refreshed.
2
Information About MPLS VPNBGP Local Convergence

To configure the MPLS VPNBGP Local Convergence feature, you should understand the following
concepts:
How Link Failures Are Handled with BGP, page 3
How Links Are Handled with the MPLS VPNBGP Local Convergence Feature, page 3
How Link Failures Are Detected, page 4
How Link Failures Are Handled with BGP

Within a Layer 3 VPN network, the failure of a PE-CE link can cause a loss of connectivity (LoC) to a
customer site, which is detrimental to time-sensitive applications. Several factors contribute to the
duration of such an outage:
The time to detect the failure
The programming of the forwarding
The convergence of BGP (In large networks, the restored traffic arrival time at its destination varies
according to the prefix.)
When BGP detects a PE-CE link failure, it removes all of the BGP paths through the failing link. BGP
runs the bestpath algorithm on the affected prefixes and selects alternate paths for each prefix. These
new paths (which typically include a remote PE) are installed into forwarding. The local labels are
removed and BGP withdrawals are sent to all BGP neighbors. As each BGP neighbor receives the
withdrawal messages (typically indirectly using route-reflectors), the bestpath algorithm is called and
the prefixes are switched to an alternate path. Only then is connectivity restored.
How Links Are Handled with the MPLS VPNBGP Local Convergence Feature
The MPLS VPNBGP Local Convergence feature requires that the prefixes to be protected on a PE-CE
link have at least one backup path that does not include that link. (See Figure 1.) The customer site must
have backup paths to the provider site.
Figure 1 Figure 1 Network Configured with Primary and Backup Paths
172.16.0.22 [VRF]
172.16.1.2
Primary Path
PE 1 172.16.0.44 [VRF]
172.16.0.2
172.16.1.1
P 172.16.5.2
172.16.0.3 172.16.5.1
172.16.8.2
CE 1 PE 3 CE 2
172.16.0.1 172.16.0.4 172.16.0.5
172.16.8.1
270788
PE 2
172.16.0.6
172.16.0.66 [VRF]
3
The MPLS VPNBGP Local Convergence feature reduces LoC time by sending the broken links traffic
over a backup path (as shown in Figure 2) instead of waiting for total network convergence. The local
label is maintained for 5 minutes while prefixes switch from the failing local path to the backup path.
Because the label is not freed as had been the usual practice, forwarding continues to take place.
The bestpath algorithm selects the backup path. Thus, the local label has been applied in place of the
failed BGP bestpath label (which is sometimes called "label swapping"). Traffic is restored locally while
the network propagation of the BGP withdrawal messages takes place. Eventually, the egress PE router
converges and bypasses the local repair.
Figure 2 Figure 2 Network Using the Backup Path After a PE-CE Link Failure on the Primary
Path
Primary PE with
Higher Local Preference
Best Path
Link Failure PE 1
P
Backup Path
CE 1 PE 3 CE 2
172.16.8.1
270789
PE 2
Backup PE
Note After the 5-minute label preservation, the local labels are freed. Any BGP prefix that is remote and is
not part of a Carrier Supporting Carrier network does not have a local label and is removed. The delay
in local label deletion does not modify normal BGP addition and deletion of BGP paths. Rather, BGP
re-programs the new backup bestpath into forwarding as usual.
How Link Failures Are Detected

Local protection relies on BGP being notified of the interface failure. Detection can occur using either
the interface drivers or the routing tables. If an interface or route goes down, the corresponding path in
the routing table is removed and BGP will be notified using the routing APIs.
However, when the routing table cannot detect the failure (as when a Layer 2 switch goes down), BGP
determines that a neighbor is down through use of its hold-down timer. However, that determination can
be extremely slow because of the 3-minute default for BGP session time-out.
You can reduce the detection delay by either reducing the BGP session time-out interval (as described
in the Configuring Internal BGP Features document) or by enabling the Bidirectional Forwarding
Detection protocol within eBGP between the PE and CE. For complete instructions to enable BFD, see
the Bidirectional Forwarding Detection document.
4
How to Enable MPLS VPNBGP Local Convergence

This section contains the following information:
Configuring MPLS VPNBGP Local Convergence with IPv4, page 5
Configuring MPLS VPNBGP Local Convergence with IPv6, page 6
Troubleshooting Tips, page 8
Configuring MPLS VPNBGP Local Convergence with IPv4

Perform the following steps to configure MPLS VPNBGP Local Convergence for IPv4 MPLS VPNs.
Prerequisite
Ensure that the CE is already connected to the PE by a minimum of two paths.
SUMMARY STEPS
1. enable
3. ip vrf vrf-name
4. rd (conditional)
5. protection local-prefixes
6. show ip vrf detail
DETAILED STEPS

Step 1 enable Enables privileged EXEC mode. Enter your password if
prompted.
Example:
Router> enable
Example:
Step 3 ip vrf vrf-name Enters VRF configuration mode. If no VRF routing table
and Cisco Express Forwarding (CEF) table had been
previously created for this named VRF, then this command
Example: also creates them, giving both tables the specified vrf-name
Router(config)# ip vrf vpn1 (in this example, the name is vpn1).
5

Step 4 rd route-distinguisher (Optional). If no route distinguisher had been previously
established for the named VRF, then it is necessary to enter
this command.
The route-distinguisher value can be either an:
autonomous system number followed by a colon and an
arbitrary number (for example, 100:3)
or
Example: IP address followed by a colon and an arbitrary number
(for example, 192.168.122.15:1).
Step 5 protection local-prefixes Allows a pre-configured backup path to carry traffic if the
PE-CE link breaks by preserving the local prefixes while
BGP reconverges.
Example:
Router(config-vrf)# protection local-prefixes
Step 6 show ip vrf detail (Optional) Verifies that MPLS VPNBGP Local
Convergence has been configured. (See Examples.)
Example:
Router(config-vrf)# show ip vrf detail
Configuring MPLS VPNBGP Local Convergence with IPv6

Perform the following steps to configure MPLS VPNBGP Local Convergence for IPv6 MPLS VPNs.
Prerequisite
Ensure that the CE is already connected to the PE by a minimum of two paths.
SUMMARY STEPS
1. enable
4. rd (optional)
5. address-family [ipv4 | ipv6]
6. protection local-prefixes
6
DETAILED STEPS

Step 1 enable Enables privileged EXEC mode. Enter your password if
prompted.
Example:
Router> enable
Example:
Step 3 vrf definition vrf-name Enters VRF definition configuration mode. If no VRF
routing table and Cisco Express Forwarding (CEF) table
had been previously created for this named VRF, then this
Example:
command also creates them, giving both tables the specified
vrf-name (in this example, the name is vrf2).
Step 4 rd route-distinguisher (Optional) If no route distinguisher had been previously
established for the named VRF, it is necessary to enter this
command.
The route-distinguisher value can be either an:
autonomous system number followed by a colon and an
arbitrary number (for example, 100:3)
or
IP address followed by a colon and an arbitrary number
Example:
(for example, 192.168.122.15:1).
Step 5 address-family [ ipv4 | ipv6 ] Enters address family configuration mode and specifies the
IPv4 or IPv6 protocol.
Example:
Step 6 protection local-prefixes Allows a pre-configured backup path to carry traffic if the
PE-CE link breaks by preserving the local prefixes while
BGP reconverges.
Example:
Router(config-vrf-af)# protection
local-prefixes
Step 7 show ip vrf detail (Optional) Verifies that MPLS VPNBGP Local
Convergence has been configured. (See Examples.)
Example:
Router(config-vrf)# show ip vrf detail
7
Configuration Examples for MPLS VPNBGP Local Convergence
Examples
To verify that local link protection has been enabled, enter the VRF detail command show ip vrf detail.
If the protection is enabled, the status message Local prefix protection enabled will be shown in
the display:
Router# show ip vrf detail
VRF vpn1 (VRF Id = 1); default RD 100:1; default VPNID <not set>
Interfaces:
AT1/0/1.1
VRF Table ID = 1
RT:100:1
RT:100:1 RT:100:2
No import route-map
No export route-map
Local prefix protection enabled
Ensure that a minimum of two paths are present for the protected prefix w.x.y.z in BGP in steady
state condition on the PE. The path using the protected PE should be the BGP best-path before
failover occurs. To view the configuration, enter the command show ip bgp vpnv4 vrf vpn w.x.y.z
Ensure that local protection has been enabled in the protected PE by entering the show ip vrf detail
command as shown in the Examples section on page 8.
When route reflectors exist in the topology, ensure that each VRF has a unique route distinguisher.
Configuration Examples for MPLS VPNBGP Local

Convergence
The following examples show how MPLS VPNBGP Local Convergence can prevent traffic loss after
a link failure. You can display a detailed view of local link protection before, during, and after BGP
convergence by using the show bgp vpnv4 and show mpls forwarding-table vrf commands as shown
in the following 3-stage example.
Note The show bgp vpnv4 unicast command is equivalent to the show ip bgp vpnv4 command that existed
in prior releases of Cisco IOS.
Example 1: Before the Link Failure

Both a primary path and a backup path have been configured:
PE1# show bgp vpnv4 unicast all 172.16.0.1
BGP routing table entry for 100:1:172.16.0.1/32, version 2
Paths: (2 available, best #2, table v1)
Flag: 0x820
Advertised to update-groups:
1
100, imported path from 100:2:172.16.0.1/32
8
172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)

Origin incomplete, metric 0, localpref 100, valid, internal
Extended Community: RT:100:0
Originator: 172.16.0.6, Cluster list: 172.16.0.7
mpls labels in/out 16/17
100
172.16.1.1 from 172.16.1.1 (172.16.0.1)
Origin incomplete, metric 0, localpref 100, valid, external, best
mpls labels in/out 16/nolabel
Paths: (1 available, best #1, no table)
Flag: 0x820
Not advertised to any peer
100
172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)
Origin incomplete, metric 0, localpref 100, valid, internal, best
mpls labels in/out nolabel/17
Label information for both paths can be displayed:

PE1# show bgp vpnv4 unicast all labels
Network Next Hop In label/Out label
Route Distinguisher: 100:1 (v1)
172.16.0.1/32 172.16.0.6 16/17
172.16.1.1 16/nolabel
172.16.0.5/32 172.16.0.4 nolabel/23
172.16.0.22/32 0.0.0.0 17/nolabel(v1)
172.16.0.44/32 172.16.0.4 nolabel/24
172.16.0.66/32 172.16.0.6 nolabel/21
172.16.1.0/24 172.16.1.1 18/nolabel
0.0.0.0 18/nolabel(v1)
172.16.5.0/24 172.16.0.4 nolabel/25
172.16.8.0/24 172.16.0.6 19/23
172.16.1.1 19/nolabel
Route Distinguisher: 100:2
172.16.0.1/32 172.16.0.6 nolabel/17
172.16.0.66/32 172.16.0.6 nolabel/21
172.16.8.0/24 172.16.0.6 nolabel/23
The PE1 (see Figure 1 on page 3) forwarding table contains BGP bestpath information:
PE1# show mpls forwarding-table vrf v1 172.16.0.1 detail
16 No Label 172.16.0.1/32[V] 570 Et0/0 172.16.1.1
MAC/Encaps=14/14, MRU=1504, Label Stack{}
AABBCC000B00AABBCC000C000800
VPN route: v1
PE1#
9
Example 2: After the Link Failure and Before BGP Convergence

After the link failure on only one path, the backup path remains available (see Figure 2 on page 4):
172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)
100
172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)
The label information for the backup path label can be displayed:
172.16.0.1/32 172.16.0.6 16/17
172.16.0.5/32 172.16.0.4 nolabel/23
172.16.0.22/32 0.0.0.0 17/nolabel(v1)
172.16.0.44/32 172.16.0.4 nolabel/24
172.16.0.66/32 172.16.0.6 nolabel/21
172.16.1.0/24 172.16.0.6 nolabel/22
172.16.5.0/24 172.16.0.4 nolabel/25
172.16.8.0/24 172.16.0.6 19/23
172.16.0.1/32 172.16.0.6 nolabel/17
172.16.0.66/32 172.16.0.6 nolabel/21
172.16.1.0/24 172.16.0.6 nolabel/22
172.16.8.0/24 172.16.0.6 nolabel/23
The PE1 (see Figure 1 on page 3) forwarding table contains new label and next-hop information to direct
traffic onto the backup path:
16 17 172.16.0.1/32[V] 0 Et1/0 172.16.3.2
MAC/Encaps=14/22, MRU=1496, Label Stack{21 17}
AABBCC000D00AABBCC000C018847 0001500000011000
VPN route: v1
PE1#
10
Example 3: After Local Label Expiration and BGP Re-convergence

Because the local label preservation window has expired, the replacement local label is now gone from
the PE1 forwarding table information:
None 17 172.16.0.1/32[V] 0 Et1/0 172.16.3.2
MAC/Encaps=14/22, MRU=1496, Label Stack{21 17}
AABBCC000D00AABBCC000C018847 0001500000011000
VPN route: v1
The new BGP information reverts to the configuration shown in Figure 1 on page 3:
172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)
100
172.16.0.6 (metric 21) from 172.16.0.7 (172.16.0.7)

172.16.0.1/32 172.16.0.6 nolabel/17
172.16.0.5/32 172.16.0.4 nolabel/23
172.16.0.22/32 0.0.0.0 17/nolabel(v1)
172.16.0.44/32 172.16.0.4 nolabel/24
172.16.0.66/32 172.16.0.6 nolabel/21
172.16.1.0/24 172.16.0.6 nolabel/22
172.16.5.0/24 172.16.0.4 nolabel/25
172.16.8.0/24 172.16.0.6 nolabel/23
172.16.0.1/32 172.16.0.6 nolabel/17
172.16.0.66/32 172.16.0.6 nolabel/21
172.16.1.0/24 172.16.0.6 nolabel/22
172.16.8.0/24 172.16.0.6 nolabel/23
PE1#
11
The following sections provide references related to the MPLS VPNBGP Local Convergence feature.
Related Documents, page 12
Standards, page 12
MIBs, page 12
RFCs, page 12
Technical Assistance, page 13
Related Documents
Configuration of VRF under the specific cases of IPv4 MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
and IPv6 situations.
Protocol for quickly detecting failed forwarding paths. Bidirectional Forwarding Detection
BGP Configuration Configuring a Basic BGP Network
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
12
Feature Information for MPLS VPNBGP Local Convergence
Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/techsupport
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.
password.

Table 1 Feature Information for MPLS VPNBGP Local Convergence

MPLS VPNBGP Local 12.2(33)SRC This feature reduces the downtime of a PE-CE link failure by
Convergence rerouting PE-egress traffic onto a backup path to the CE before BGP
has re-converged.
In 12.2(33)SRC, this feature was introduced on the Cisco 7200 and
the Cisco 7600.
The following command was introduced: protection local-prefixes.
MPLS VPNBGP Local 12.2(33)SB This feature became available on the Cisco 7300 series and the Cisco
Convergence 10000 series routers.
MPLS VPNBGP Local 15.0(1)M This feature was integrated in this release. The following command
Convergence was introduced: protection local-prefixes.
13
14
MPLS VPNRoute Target Rewrite

The MPLS VPNRoute Target Rewrite feature allows the replacement of route targets on incoming and
outgoing Border Gateway Protocol (BGP) updates. Typically, Autonomous System Border Routers
(ASBRs) perform the replacement of route targets at autonomous system boundaries. Route Reflectors
(RRs) and provider edge (PE) routers can also perform route target replacement.
The main advantage of the MPLS VPNRoute Target Rewrite feature is that it keeps the administration
of routing policy local to the autonomous system.

feature is supported, use the Feature Information for MPLS VPNRoute Target Rewrite section on
page 19.
Contents
Prerequisites for MPLS VPNRoute Target Rewrite, page 2
Restrictions for MPLS VPNRoute Target Rewrite, page 2
Information About MPLS VPNRoute Target Rewrite, page 2
How to Configure MPLS VPNRoute Target Rewrite, page 4
Configuration Examples for MPLS VPNRoute Target Rewrite, page 15
Prerequisites for MPLS VPNRoute Target Rewrite

Feature Information for MPLS VPNRoute Target Rewrite, page 19
Glossary, page 20
Prerequisites for MPLS VPNRoute Target Rewrite

The MPLS VPNRoute Target Rewrite feature requires the following:
You should know how to configure Multiprotocol Virtual Private Networks (MPLS VPNs).
You need to configure your network to support interautonomous systems with different route target
(RT) values in each autonomous system.
You need to identify the RT replacement policy and target router for each autonomous system.
Restrictions for MPLS VPNRoute Target Rewrite

You can apply multiple replacement rules using the route-map continue clause. The MPLS VPNRoute
Target Rewrite feature does not support the continue clause on outbound route maps.
Information About MPLS VPNRoute Target Rewrite

To configure the MPLS VPNRoute Target Rewrite feature, you need to understand the following
concepts:
Route Target Replacement Policy, page 2
Route Maps and Route Target Replacement, page 4
Route Target Replacement Policy

Routing policies for a peer include all configurations that may impact inbound or outbound routing table
updates. The MPLS VPNRoute Target Rewrite feature can influence routing table updates by allowing
the replacement of route targets on inbound and outbound BGP updates. Route targets are carried as
extended community attributes in BGP Virtual Private Network IP Version 4 (VPNv4) updates. Route
target extended community attributes are used to identify a set of sites and VPN routing and forwarding
(VRF) instances that can receive routes with a configured route target.
In general, ASBRs perform route target replacement at autonomous system borders when the ASBRs
exchange VPNv4 prefixes. You can also configure the MPLS VPNRoute Target Rewrite feature on
PE routers and RR routers.
Figure 1 shows an example of route target replacement on ASBRs in an MPLS VPN interautonomous
system topology. This example includes the following configurations:
PE1 is configured to import and export RT 100:1 for VRF VPN1.
ASBR1 is configured to rewrite all inbound VPNv4 prefixes with RT 200:1 to RT 100:1.
ASBR2 is configured to rewrite all inbound VPNv4 prefixes with RT 100:1 to RT 200:1.
2
Information About MPLS VPNRoute Target Rewrite
Figure 1 Route Target Replacement on ASBRs in an MPLS VPN Interautonomous System

Topology
AS 100 P1 P2 AS 200
RT Rewrite RT Rewrite
200:1 to 100:1 100:1 to 200:1
PE1 ASBR1 ASBR2 PE2
VPNv4 iBGP
VPNv4 iBGP VPNv4 eBGP
88324
CE1 CE2
VPN1 VPN2
RT export 100:1 RT export 200:1
RT import 100:1 RT import 200:1
Figure 2 shows an example of route target replacement on route reflectors in an MPLS VPN
interautonomous system topology. This example includes the following configurations:
EBGP is configured on the route reflectors.
EBGP and IBGP IPv4 label exchange is configured between all BGP routers.
Peer groups are configured on the routers reflectors.
RR1 is configured to rewrite all inbound VPNv4 prefixes with RT 200:1 or RT 200:2 to RT 100:1.
RR2 is configured to rewrite all inbound prefixes with RT 100:1 to RT 200:1 and RT 200:2.
3
How to Configure MPLS VPNRoute Target Rewrite
Figure 2 Route Target Rewrite on Route Reflectors in an MPLS VPN Interautonomous System
Topology
VPNv4 iBGP VPNv4 multihop-eBGP VPNv4 iBGP
AS 100 AS 200
RT Rewrite RT Rewrite
200:1 to 100:1 100:1 to 200:1
RR1 200:2 to 100:1 100:1 to 200:2 RR2
PE1 ASBR1 ASBR2 PE2
88325
P1 P2
CE1 CE2 CE3

VPN1 VPN2 VPN2
RT export 100:1 RT export 200:1 RT export 200:2
RT import 100:1 RT import 200:1 RT import 200:2
Route Maps and Route Target Replacement

The MPLS VPNRoute Target Rewrite feature extends the BGP inbound/outbound route map
functionality to enable route target replacement. The set extcomm-list delete command entered in
route-map configuration mode allows the deletion of a route target extended community attribute based
on an extended community list.

This section contains the following procedures to configure MPLS VPNRoute Target Rewrite:
Configuring a Route Target Replacement Policy, page 4 (required)
Applying the Route Target Replacement Policy, page 8 (required)
Verifying the Route Target Replacement Policy, page 12 (optional)
Troubleshooting Your Route Target Replacement Policy, page 13 (optional)
Configuring a Route Target Replacement Policy

Perform this task to configure an RT replacement policy for your internetwork.
If you configure a PE to rewrite RT x to RT y and the PE has a VRF that imports RT x, you need to
configure the VRF to import RT y in addition to RT x.
4
SUMMARY STEPS
1. enable
3. ip extcommunity-list {standard-list-number | expanded-list-number} {permit | deny}
[regular-expression] [rt | soo extended-community-value]
4. route-map map-name [permit | deny] [sequence-number]
5. match extcommunity {standard-list-number | expanded-list-number}
6. set extcomm-list extended-community-list-number delete
7. set extcommunity {rt extended-community-value [additive] | soo extended-community-value}
8. end
9. show route-map map-name
DETAILED STEPS

Example:
Router> enable
Example:
5

Step 3 ip extcommunity-list {standard-list-number | Creates an extended community access list and controls
expanded-list-number} {permit | deny} access to it.
[regular-expression] [rt | soo
extended-community-value] The standard-list-number argument is an integer from
1 to 99 that identifies one or more permit or deny
groups of extended communities.
Example:
Router(config)# ip extcommunity-list 1 permit The expanded-list-number argument is an integer from
rt 100:3 100 to 500 that identifies one or more permit or deny
groups of extended communities. Regular expressions
can be configured with expanded lists but not standard
lists.
The permit keyword permits access for a matching
condition.
The deny keyword denies access for a matching
condition.
The regular-expression argument specifies an input
string pattern to match against. When you use an
expanded extended community list to match route
targets, include the pattern RT: in the regular
expression.
The rt keyword specifies the route target extended
community attribute. The rt keyword can be configured
only with standard extended community lists and not
expanded community lists.
The soo keyword specifies the site of origin (SOO)
extended community attribute. The soo keyword can be
configured only with standard extended community
lists and not expanded community lists.
The extended-community-value argument specifies the
route target or site of origin. The value can be one of the
following combinations:
autonomous-system-number:network-number
ip-address:network-number
The colon is used to separate the autonomous system
number and network number or IP address and network
number.
6

Step 4 route-map map-name [permit | deny] Defines the conditions for redistributing routes from one
[sequence-number] routing protocol into another or enables policy routing and
enables route-map configuration mode.
Example: The map-name argument defines a meaningful name
Router(config)# route-map extmap permit 10 for the route map. The redistribute router
configuration command uses this name to reference
this route map. Multiple route maps may share the
same map name.
If the match criteria are met for this route map, and the
permit keyword is specified, the route is redistributed
as controlled by the set actions. In the case of policy
routing, the packet is policy routed.
If the match criteria are not met, and the permit
keyword is specified, the next route map with the same
map tag is tested. If a route passes none of the match
criteria for the set of route maps sharing the same
name, it is not redistributed by that set.
The permit keyword is the default.
If the match criteria are met for the route map and the
deny keyword is specified, the route is not
redistributed. In the case of policy routing, the packet
is not policy routed, and no further route maps sharing
the same map tag name will be examined. If the packet
is not policy routed, the normal forwarding algorithm is
used.
The sequence-number argument is a number that
indicates the position a new route map will have in the
list of route maps already configured with the same
name. If given with the no form of this command, the
position of the route map should be deleted.
Step 5 match extcommunity {standard-list-number Matches BGP extended community list attributes.
|expanded-list-number}
The standard-list-number argument is a number from 1
to 99 that identifies one or more permit or deny groups
Example: of extended community attributes.
Router(config-route-map)# match extcommunity 1
The expanded-list-number argument is a number from
100 to 500 that identifies one or more permit or deny
Example: groups of extended community attributes.
Router(config-route-map)# match extcommunity
101
Step 6 set extcomm-list extended-community-list-number Removes a route target from an extended community
delete attribute of an inbound or outbound BGP VPNv4 update.
The extended-community-list-number argument
Example: specifies the extended community list number.
Router(config-route-map)# set extcomm-list 1
delete
7

Step 7 set extcommunity {rt extended-community-value Sets BGP extended community attributes.
[additive] | soo extended-community-value}
The rt keyword specifies the route target extended
community attribute.
Example:
Router(config-route-map)# set extcommunity rt
The soo keyword specifies the site of origin extended
100:4 additive community attribute.
The extended-community-value argument specifies the
value to be set. The value can be one of the following
combinations:
autonomous-system-number : network-number
ip-address : network-number
The colon is used to separate the autonomous system
number and network number or IP address and network
number.
The additive keyword adds a route target to the
existing route target list without replacing any existing
route targets.
Example:
Router(config-route-map)# end
Step 9 show route-map map-name (Optional) Use this command to verify that the match and
set entries are correct.
Example: The map-name argument is the name of a specific route
Router# show route-map extmap map.
Applying the Route Target Replacement Policy

Perform the following tasks to apply the route target replacement policy to your internetwork:
Associating Route Maps with Specific BGP Neighbors, page 8
Refreshing BGP Session to Apply Route Target Replacement Policy, page 10
Associating Route Maps with Specific BGP Neighbors

Perform this task to associate route maps with specific BGP neighbors.
SUMMARY STEPS
1. enable
8

7. neighbor {ip-address | peer-group-name} send-community [both | extended | standard]
8. neighbor {ip-address | peer-group-name} route-map map-name {in | out}
9. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Configures a BGP routing process and places the router in
along.
Valid numbers are from 0 to 65535. Private autonomous
system numbers that can be used in internal networks
range from 64512 to 65535.
Example: neighbor.
Router(config-router)# neighbor 172.10.0.2
BGP peer group.
address prefixes.
Example:
address prefixes.
Example: neighbor.
BGP peer group.
9

send-community [both | extended | standard] BGP neighbor.
BGP peer group.
The both keyword sends standard and extended
community attributes.
The extended keyword sends an extended community
attribute.
The standard keyword sends a standard community
attribute.
Step 8 neighbor {ip-address | peer-group-name} Apply a route map to incoming or outgoing routes
route-map map-name {in | out}
neighbor.
Example:
The peer-group-name argument specifies the name of a
route-map extmap in BGP or multiprotocol peer group.
The map-name argument specifies the name of a route
map.
The in keyword applies route map to incoming routes.
The out keyword applies route map to outgoing routes.
Example:
Refreshing BGP Session to Apply Route Target Replacement Policy

Perform this task to refresh the BGP session to apply the RT replacement policy.
After you have defined two routers to be BGP neighbors, the routers form a BGP connection and
exchange routing information. If you subsequently change a routing policy, you must reset BGP
connections for the configuration change to take effect. After configuring the RT replacement policy and
applying it to the target routers in your system, you must refresh the BGP session to put the policy into
operation.
SUMMARY STEPS
1. enable
2. clear ip bgp {* | neighbor-address | peer-group-name [soft [in | out]} [ipv4 {multicast | unicast}
| vpnv4 unicast {soft | in | out}]
3. disable
10
DETAILED STEPS

Example:
Router> enable
Step 2 clear ip bgp {* | neighbor-address | Resets a BGP connection using BGP soft reconfiguration.
peer-group-name [soft [in | out]} [ipv4
{multicast | unicast} | vpnv4 unicast {soft | The * keyword resets all current BGP sessions.
in | out}]
The neighbor-address argument resets only the
identified BGP neighbor.
Example: The peer-group-name argument resets the specified
Router# clear ip bgp vpnv4 unicast 172.16.0.2
BGP peer group.
in
The ipv4 keyword resets the specified IPv4 address
family neighbor or peer group. The multicast or
unicast keyword must be specified.
The vpnv4 keyword resets the specified VPNv4
address family neighbor or peer group. The unicast
keyword must be specified.
The soft keyword indicates a soft reset. Does not reset
the session. The in or out keywords do not follow the
soft keyword when a connection is cleared under the
VPNv4 or IPv4 address family because the soft
keyword specifies both.
The in and out keywords trigger inbound or outbound
soft reconfiguration, respectively. If the in or out
keyword is not specified, both inbound and outbound
soft reset are triggered.
Example:
Router# disable
To determine whether a BGP router supports the route refresh capability, use the show ip bgp neighbors
command. If a router supports the route refresh capability, the following message is displayed:
Received route refresh capability from peer.
You can issue the debug ip bgp updates command on the router where you entered the clear ip bgp
command to verify that the updates are occurring.
Note Issuing the debug ip bgp updates command could impair performance if the router sends or receives a
large number of BGP updates.
11
Verifying the Route Target Replacement Policy

Perform this task to verify the operation of your RT replacement policy.
SUMMARY STEPS
1. enable
2. show ip bgp vpnv4 all network-address
3. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 show ip bgp vpnv4 all network-address

Use this command to verify that all VPNv4 prefixes with a specified RT extended community attribute
are replaced with the proper RT extended community attribute at the ASBRs or route reflectors and to
verify that the PE routers receive the rewritten RT extended community attributes from the ASBRs or
route reflectors. The following examples verify route target replacement on ABSR1 and ABSR2.
Verify route target replacement on ABSR1:
Router# show ip bgp vpnv4 all 172.16.17.17

1
300
172.16.11.11 (metric 589) from 172.16.11.11 (172.16.11.11)
Verify route target replacement on ABSR2:


1
100 300
192.168.1.1 from 192.168.1.1 (172.16.13.13)
Origin incomplete, localpref 100, valid, external, best
The following examples verify route target replacement on PE1 and PE2.
Verify route target on PE1:

Paths: (1 available, best #1, table vpn1)
12
1
300
192.168.2.1 (via vpn1) from 192.168.2.1 (172.16.19.19)
Origin incomplete, metric 0, localpref 100, valid, external, best
Verify route target on PE2:


3
100 300
192.168.1.1 (metric 20) from 172.16.16.16 (172.16.16.16)
Origin incomplete, localpref 100, valid, internal, best
Step 3 exit
Use this command to exit to user EXEC mode:
Router# exit
Router>
Troubleshooting Your Route Target Replacement Policy

Perform this task to troubleshoot your RT replacement policy.
SUMMARY STEPS
1. enable
2. debug ip bgp updates
3. show ip bgp vpnv4 all network-address
4. exit
DETAILED STEPS
Step 1 enable
Router> enable
Router#
Step 2 debug ip bgp updates

Use the following command to verify that BGP updates are occurring on the ASBR. The ASBR in this
example has the IP address 172.16.16.16.
Router# debug ip bgp updates
BGP(2): no valid path for 100:1:172.16.20.20/32

BGP(2): no valid path for 100:1:10.0.0.0/8
%BGP-5-ADJCHANGE: neighbor 172.16.16.16 Down User reset
13
BGP(2): nettable_walker 100:1:172.16.20.20/32 no RIB

BGP(2): 172.16.11.11 computing updates, afi 2, neighbor version 13,
table version 15, starting at 0.0.0.0
BGP(2): 172.16.11.11 send unreachable 100:1:172.16.20.20/32
BGP(2): 172.16.11.11 send UPDATE 100:1:172.16.20.20/32 -- unreachable
BGP(2): 172.16.11.11 send UPDATE 100:1:192.168.3.0/8 -- unreachable
BGP(2): 1 updates (average = 58, maximum = 58)
BGP(2): 172.16.11.11 updates replicated for neighbors: 172.16.11.11
BGP(2): 172.16.11.11 update run completed, afi 2, ran for 0ms,
neighbor version 15, start version 15, throttled to 15
BGP: Import walker start version 13, end version 15
BGP: ... start import cfg version = 30
%BGP-5-ADJCHANGE: neighbor 172.16.16.16 Up
BGP(2): 172.16.16.16 computing updates, afi 2, neighbor version 0,
table version 15, starting at 0.0.0.0
BGP(2): 172.16.16.16 send UPDATE (format) 100:1:172.16.0.0/16,
next 172.16.11.11, metric 0, path 300, extended community RT:2:2
RT:7777:222222222 RT:20000:111 RT:65535:999999999
BGP(2): 172.16.16.16 send UPDATE (prepend, chgflags: 0x0)
100:1:172.16.19.19/32, next 172.16.11.11, metric 0, path 300,
extended community RT:2:2 RT:7777:222222222 RT:20000:111
RT:65535:999999999
next 172.16.11.11, metric 0, path , extended community
RT:2:2 RT:7777:222222222 RT:20000:111 RT:65535:999999999
BGP(2): 172.16.16.16 rcvd UPDATE w/ attr: nexthop 172.16.15.15,
origin ?, path 200, extended community RT:100:1
BGP(2): 172.16.16.16 rcvd 100:1:192.168.3.0/8
BGP(2): 172.16.16.16 rcvd UPDATE w/ attr: nexthop 172.16.15.15,
origin ?, path 200 400, extended community RT:100:1
BGP(2): 172.16.16.16 rcvd 100:1:172.16.0.0/16
BGP(2): 172.16.16.16 rcvd 100:1:172.16.20.20/32
BGP: Import walker start version 15, end version 17
BGP: ... start import cfg version = 30
BGP(2): 172.16.11.11 computing updates, afi 2,
neighbor version 15, table version 17,
starting at 0.0.0.0
BGP(2): 172.16.11.11 NEXT_HOP part 1 net 100:1:172.16.20.20/32,
next 172.16.15.15
next 172.16.15.15,metric 0, path 200 400, extended community
RT:1:1 RT:10000:111 RT:33333:888888888
RT:65535:999999999
BGP(2): 172.16.11.11 NEXT_HOP part 1 net 100:1:10.0.0.0/8,
next 172.16.15.15
next 172.16.15.15, metric 0, path 200, extended community
RT:1:1 RT:10000:111 RT:33333:888888888 RT:65535:999999999
You can also reset the BGP connection using the clear ip bgp * command and enter the debug ip bgp
updates command again to verify that BGP updates are occurring as shown in the output after the clear
ip bgp command is entered.
14
Configuration Examples for MPLS VPNRoute Target Rewrite
Step 3 show ip bgp vpnv4 all network-address

Use this command to verify that RT extended community attributes are replaced correctly. For example:

1
100 300
192.168.1.1 from 192.168.1.1 (172.16.13.13)
Origin incomplete, localpref 100, valid, external, best
This example shows VPN address information from the BGP table and verifies that RT extended
community attributes are replaced correctly.
Step 4 exit
Use this command to exit to user EXEC mode:
Router# exit
Router>

This section contains the following configuration examples for the MPLS VPNRoute Target Rewrite
feature:
Configuring Route Target Replacement Policies: Examples, page 15
Applying Route Target Replacement Policies: Examples, page 16
Configuring Route Target Replacement Policies: Examples

This example shows the RT replacement configuration of an ASBR (ASBR1) that exchanges VPNv4
prefixes with another ASBR (ASBR2). The route map extmap is configured to replace RTs on inbound
updates. Any incoming update with RT 100:3 is replaced with RT 200:3. Any other prefixes with an RT
whose autonomous system number is 100 is rewritten to RT 200:4.
!
ip extcommunity-list 1 permit rt 100:3
ip extcommunity-list 101 permit RT:100:*
!
route-map extmap permit 10
match extcommunity 1
set extcomm-list 1 delete
set extcommunity rt 200:3 additive
!
route-map regexp permit 10
!
route-map regexp permit 20
15
This example shows the use of the route-map configuration continue command when you need to apply
more than one replacement rule on an update. In this example, an incoming update with RT 100:3 is
replaced with RT 200:3. Without the continue 20 command, route-map evaluation would stop when a
match on sequence 10 is made. With the continue 20 command, route-map evaluation continues into
sequence 20 even if a match occurs in sequence 10. If the incoming update has an RT 100:4, the router
replaces it with RT 200:4.
!
!
continue 20
!
!
Note The route-map configuration continue command is not supported on outbound route maps.
Applying Route Target Replacement Policies: Examples

Associating Route Maps with Specific BGP Neighbor: Example, page 16
Refreshing the BGP Session to Apply the Route Target Replacement Policy: Example, page 17
Associating Route Maps with Specific BGP Neighbor: Example

This example shows the association of route map extmap with a BGP neighbor. The BGP inbound route
map is configured to replace RTs on incoming updates.
router bgp 100
.
.
.
.
.
.
!
address family vpnv4
neighbor 172.16.0.2 route-map extmap in
This example shows the association of the same route map with the outbound BGP neighbor. The route
map is configured to replace RTs on outgoing updates.
router bgp 100
16
.
.
.
.
.
.
!
address family vpnv4
neighbor 172.16.0.2 route-map extmap out
Refreshing the BGP Session to Apply the Route Target Replacement Policy: Example
The following example shows the clear ip bgp command used to initiate a dynamic reconfiguration in
the BGP peer 172.16.0.2. This command requires that the peer supports the route refresh capability.
Router# clear ip bgp 172.16.0.2 vpnv4 unicast in
The following sections provide references related to the MPLS VPNRoute Target Rewrite feature.
Related Documents
MPLS, MPLS VPN, and MPLS VPN interautonomous Cisco IOS Multiprotocol Label Switching Configuration Guide
systems configuration tasks
Commands to configure MPLS and MPLS VPNs Cisco IOS Multiprotocol Label Switching Command Reference
BGP configuration tasks Cisco IOS IP Routing Protocols Configuration Guide
Commands to configure and monitor BGP Cisco IOS IP Routing Protocols Command Reference
Standards
Standards Title
17
Command Reference
MIBs
MIBs MIBs Link
RFCs
RFCs Title
Description Link
Command Reference
set extcomm-list delete
18
Feature Information for MPLS VPNRoute Target Rewrite
Feature Information for MPLS VPNRoute Target Rewrite

Table 1 Feature Information for MPLS VPNRoute Target Rewrite

MPLS VPNRoute Target Rewrite 12.0(26)S The MPLS VPNRoute Target Rewrite feature allows the
12.2(25)S replacement of route targets on incoming and outgoing Border
12.2(33)SRA Gateway Protocol (BGP) updates. Typically, Autonomous System
12.2(33)SXH Border Routers (ASBRs) perform the replacement of route targets at
12.4(20)T autonomous system boundaries. Route Reflectors (RRs) and provider
edge (PE) routers can also perform route target replacement.
The main advantage of the MPLS VPNRoute Target Rewrite
feature is that it keeps the administration of routing policy local to the
autonomous system.
In 12.0(26)S, this feature was introduced for the Cisco 7200, 7500,
and 12000 series routers.
In 12.2(25)S, this feature was integrated into a Cisco IOS 12.2S
release to support the Cisco 7500 series router.
In 12.2(33)SRA, this feature was integrated into a Cisco IOS
12.2SRA release.
In 12.2(33)SXH, this feature was integrated into a Cisco IOS
12.2SXH release.
12.4T release.
Route Target Replacement Policy, page 2
Route Maps and Route Target Replacement, page 4
Configuring a Route Target Replacement Policy, page 4
Verifying the Route Target Replacement Policy, page 12
Troubleshooting Your Route Target Replacement Policy, page 13
The following command was modified: set extcomm-list delete.
19
Glossary
Glossary
ASBRautonomous system border router. A router that connects and exchanges information between
two or more autonomous systems.
BGPBorder Gateway Protocol. The exterior border gateway protocol used to exchange routing
information between routers in separate autonomous systems. BGP uses Transmission Control Protocol
(TCP). Because TCP is a reliable protocol, BGP does not experience problems with dropped or
fragmented data packets.
CE routercustomer edge router. The customer router that connects to the provider edge (PE) router.
EBGPExternal Border Gateway Protocol. A BGP session between routers in different autonomous
systems. When a pair of routers in different autonomous systems are more than one IP hop away from
each other, an EBGP session between those two routers is called multihop EBGP.
IBGPInternal Border Gateway Protocol. A BGP session between routers within the same autonomous
system.
autonomous system. Examples of common Internet IGPs include Internal Gateway Routing Protocol
(IGRP), Open Shortest Path First (OSPF), and Routing Information Protocol (RIP).
labels (addresses) used to forward packets. The Cisco proprietary version of this protocol is the Tag
Distribution Protocol (TDP).
LERlabel edge router. The edge router that performs label imposition and disposition.
LSRlabel switch router. The role of an LSR is to forward packets in an MPLS network by looking
only at the fixed-length label.
NLRINetwork Layer Reachability Information. BGP sends routing update messages containing
NLRI, which describes the route. In this context, an NLRI is a prefix. A BGP update message carries
one or more NLRI prefixes and the attributes of a route for the NLRI prefixes. The route attributes
include a BGP next-hop gateway address, community values, and other information.
P routerprovider router. The core router in the service provider network that connects to provider
edge (PE) routers. In a packet-switched star topology, a router that is part of the backbone and that serves
as the single pipe through which all traffic from peripheral networks must pass on its way to other
peripheral networks.
PE routerprovider edge router. The label edge router (LER) in the service provider network that
connects to the customer edge (CE) router.
VPN IPv4 (VPNv4) prefix.
RRroute reflector. A router that advertises, or reflects, IBGP learned routes to other IBGP peers
without requiring a full network mesh.
RTroute target. Extended community attribute used to identify the VRF routing table into which a
prefix is to be imported.
20
Glossary
VPNVirtual Private Network. A group of sites that, as a result of a set of administrative policies, can
communicate with each other over a shared backbone.
VPNv4 prefixIPv4 prefix preceded by an 8-byte route distinguisher. The VPN addresses are made
unique by adding a route distinguisher to the front of the address.
VRFVPN routing and forwarding instance. A VRF consists of an IP routing table, a derived
that defines a customer VPN site that is attached to a provider edge (PE) router.
coincidental.
21
Glossary
22
MPLS VPNPer VRF Label
First Published: June 29, 2007

The MPLS VPNPer VRF Label feature (hereafter, in this document, referred to as the Per VRF Label
feature or the Per VRF feature) allows you to configure a single Virtual Private Network (VPN) label for
all local routes in the entire VPN routing and forwarding (VRF) domain on Cisco 6500 routers. This
MPLS VPNPer VRF Label feature incorporates a single (per VRF) VPN label that for all local routes
in the VRF table.
You can enable (or disable) the MPLS VPNPer VRF Label feature in global configuration mode. This
feature is available for the Cisco 6500 router only.

supported, see the Feature Information for MPLS VPNPer VRF Label section on page 12.
Contents
This document includes the following topics:
Prerequisites for the Per VRF Label Feature, page 2
Restrictions for the Per VRF Label Feature, page 2
Information About the Per VRF Label Feature, page 2
How to Configure the Per VRF Label Feature, page 3
Configuration Examples for the Per VRF Label feature, page 5
.
Prerequisites for the Per VRF Label Feature

Feature Information for MPLS VPNPer VRF Label, page 12
Prerequisites for the Per VRF Label Feature

If your VRF domain has the external/internal Border Gateway Protocol (EIBGP) multipath feature
or the Carrier Supporting Carrier (CSC) feature enabled, disable those features before you configure
the Per VRF Label feature.
Before configuring Multiprotocol Label Switching (MPLS) Layer 3 VPNs, you must have MPLS,
Label Distribution Protocol (LDP), and Cisco Express Forwarding (CEF) installed in your network.
All routers in the core, including the Provider Edge (PE) routers, must be able to support CEF and
MPLS forwarding.
Restrictions for the Per VRF Label Feature

Enabling the Per VRF Label feature causes BGP reconvergence, which can result in data loss for
traffic coming from the MPLS VPN core.
Note You can minimize network disruption by enabling this feature during a scheduled MPLS
maintenance window. Also, if possible, avoid enabling this feature on a live router.
There is no performance degradation when you configure up to 511 VRFs; however, when you add
more than 511 VRFs, your network might experience some minor performance degradation (similar
to the normal degradation experienced by any of the directly connected VRF prefixes present in the
router).
Per-prefix MPLS counters for VPN prefixes are lost when you enable the Per VRF Label feature.
You cannot use this feature with CSC and EIBGP multipath features.
Information About the Per VRF Label Feature

To configure the MPLS VPNPer VRF Label feature, you should understand the following concept:
MPLS VPNPer VRF Label Functionality, page 2
MPLS VPNPer VRF Label Functionality

The PE stores both local and remote routes and includes a label entry for each route. For distributed
platforms, the per-prefix labels consume memory. When there are many VRFs and routes, the amount of
memory that the per-prefix labels consume can become an issue.
This new Per VRF Label feature allows the advertisement of a single VPN label for local routes
throughout the entire VRF. The router uses a new VPN label for the VRF decoding and IP-based lookup
to learn where to forward packets for the PE or customer edge (CE) interfaces.
2
How to Configure the Per VRF Label Feature
The following conditions apply when you configure the Per VRF Label feature:
The VRF uses one label for all local routes.
When you enable the Per VRF Label feature, any existing Per VRF Aggregate label is used. If no
Per VRF Aggregate label is present, the software creates a new Per VRF label.
When you enable the Per VRF Label feature, the CE routers learned local routes will experience
some data loss.
The CE does not lose data when you disable the Per VRF Label feature because when you disable
the feature, the configuration reverts to the default labeling configuration of the Cisco 6500
platform, which uses the Per VRF Aggregate label from the local nonCE-sourced routes.
When you disable the Per VRF Label feature, the configuration reverts to the default configuration
of the Cisco 6500 routers.
A Per VRF label forwarding entry is deleted only if the VRF or the BGP configuration is removed.
Summarization of Label Allocation Modes

Table 1 defines the label allocations used with various route types.
Table 1 Label Allocation Modes
Label Mode: Label Mode:

Route Types Cisco 6500 Default Per VRF Label Feature
Local to the PE (connected, static route to Per VRF Aggregate Per VRF label
NULL0, BGP aggregates), redistributed to label
BGP
Locally learned from CE (through EBGP or Per Prefix label Per VRF label
other PE or CE protocols)

This section describes the following required task:
Configuring the Per VRF Label Feature, page 3
Configuring the Per VRF Label Feature

To configure the Per VRF Label feature, perform the following task.
SUMMARY STEPS
1. enable
3. mpls label mode {vrf vrf-name | all-vrfs} protocol bgp-vpnv4 {per-prefix | per-vrf}
4. end
3
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls label mode {vrf vrf-name | all-vrfs} protocol bgp-vpnv4 Configures the Per VRF Label feature.
{per-prefix | per-vrf}
Example:
Router(config)# mpls label mode all-vrfs protocol bgp-vpnv4
per-vrf
Example:
Router(config)# end
Step 5 show ip vrf detail Displays the VRF label mode.
Example:
Examples
The following command example shows how to verify the Per VRF Label configuration:
In this example output, the bold text indicates the label modes:
VRF vpn1; default RD 1:1; default VPNID <not set>

VRF Table ID = 1
Interfaces:
Ethernet0/0 Serial5/0 Loopback1
RT:1:1
RT:1:1
No import route-map
No export route-map
CSC is not configured.
VRF label allocation mode: per-vrf (Label 19)
VRF Table ID = 2
Interfaces:
Ethernet2/0 Loopback2
4
Configuration Examples for the Per VRF Label feature
RT:2:1
RT:2:1
No import route-map
No export route-map
VRF Table ID = 3
Interfaces:
RT:3:1
RT:3:1
No import route-map
No export route-map
Router# show ip bgp vpnv4 all labels

Route Distinguisher: 1:1 (vpn1)
127.0.0.1/32 192.168.1.1 IPv4 VRF Aggr:19/nolabel
127.0.0.5/32 127.0.0.4 nolabel/19
0.0.0.0 IPv4 VRF Aggr:19/aggregate(vpn1)
192.168.4.0/24 127.0.0.4 nolabel/20
172.16.0.0/16 0.0.0.0 IPv4 VRF Aggr:19/aggregate(vpn1)

16 Pop tag 192.168.3.0/24 0 Et1/0 192.168.2.3
17 Pop tag 127.0.0.3/32 0 Et1/0 192.168.2.3
18 17 127.0.0.4/32 0 Et1/0 192.168.2.3
19 Pop Label IPv4 VRF[V] 0 aggregate/vpn1
PE1#

This section shows examples for three different configurations:
No Label Mode (Cisco 6500 Router Default): Example, page 6
5
Mixed Mode (with Global Per-Prefix): Example, page 7

Mixed Mode (with Global Per-VRF): Example, page 9
No Label Mode (Cisco 6500 Router Default): Example

The following example shows the default label mode configuration (no label mode) for the Cisco 6500
router.

VRF Table ID = 1
Interfaces:
RT:1:1
RT:1:1
No import route-map
No export route-map
per-vrf-aggr for connected and BGP aggregates (Label 19)
VRF Table ID = 2
Interfaces:
RT:2:1
RT:2:1
No import route-map
No export route-map
VRF Table ID = 3
Interfaces:
RT:3:1
RT:3:1
No import route-map
No export route-map

127.0.0.1/32 192.168.1.1 27/nolabel
127.0.0.5/32 127.0.0.4 nolabel/19
6
0.0.0.0 IPv4 VRF Aggr:19/aggregate(vpn1)

192.168.4.0/24 127.0.0.4 nolabel/20
172.16.128.0/32 192.168.1.1 28/nolabel
127.0.0.6/32 192.168.5.1 21/nolabel
172.17.128.0/32 192.168.5.1 22/nolabel
127.0.0.8/32 192.168.7.1 24/nolabel
172.16.128.0/32 192.168.7.1 25/nolabel

16 Pop tag 192.168.3.0/24 0 Et1/0 192.168.2.3
17 Pop tag 127.0.0.3/32 0 Et1/0 192.168.2.3
18 17 127.0.0.4/32 0 Et1/0 192.168.2.3
21 Untagged 127.0.0.6/32[V] 0 Et2/0 192.168.5.1
22 Untagged 172.17.128.0/32[V]0 Et2/0 192.168.5.1
24 Untagged 127.0.0.8/32[V] 0 Et3/0 192.168.7.1
25 Untagged 172.16.128.0/32[V]0 Et3/0 192.168.7.1
27 Untagged 127.0.0.1/32[V] 0 Et0/0 192.168.1.1
28 Untagged 172.16.128.0/32[V]0 Et0/0 192.168.1.1
Mixed Mode (with Global Per-Prefix): Example

For this example, the following commands set VPN 1 for per-vrf label mode, VPN 2 for per-prefix label
mode, and all remaining VPNs for per-prefix (globally).
Router# mpls label mode vrf vpn1 protocol bgp-vpnv4 per-vrf
Router# mpls label mode vrf vpn2 protocol bgp-vpnv4 per-prefix
Use the following show commands to display the label mode settings:

VRF Table ID = 1
Interfaces:
RT:1:1
RT:1:1
No import route-map
No export route-map
VRF Table ID = 2
Interfaces:
7
RT:2:1
RT:2:1
No import route-map
No export route-map
VRF Table ID = 3
Interfaces:
RT:3:1
RT:3:1
No import route-map
No export route-map
Router# show ip bgp vpnv4 all label

127.0.0.5/32 127.0.0.4 nolabel/19
192.168.1.1 IPv4 VRF Aggr:26/nolabel
192.168.4.0/24 127.0.0.4 nolabel/20
127.0.0.6/32 192.168.5.1 20/nolabel
172.17.128.0/32 192.168.5.1 21/nolabel
127.0.0.8/32 192.168.7.1 22/nolabel
172.16.128.0/32 192.168.7.1 23/nolabel

16 Pop tag 192.168.3.0/24 0 Et1/0 192.168.2.3
17 Pop tag 127.0.0.3/32 0 Et1/0 192.168.2.3
18 17 127.0.0.4/32 0 Et1/0 192.168.2.3
20 Untagged 127.0.0.6/32[V] 0 Et2/0 192.168.5.1
21 Untagged 172.17.128.0/32[V]0 Et2/0 192.168.5.1
22 Untagged 127.0.0.8/32[V] 0 Et3/0 192.168.7.1
23 Untagged 172.16.128.0/32[V]0 Et3/0 192.168.7.1
8
Mixed Mode (with Global Per-VRF): Example

For this example, the following commands set VPN 1 for per-vrf label mode, VPN 2 for per-prefix label
mode, and all remaining VPNs for per-vrf (globally).
Router# mpls label mode vrf vpn1 protocol bgp-vpnv4 per-vrf
Router# mpls label mode vrf vpn2 protocol bgp-vpnv4 per-prefix
Router# mpls label mode all-vrfs protocol bgp-vpnv4 per-vrf

VRF Table ID = 1
Interfaces:
RT:1:1
RT:1:1
No import route-map
No export route-map
VRF Table ID = 2
Interfaces:
RT:2:1
RT:2:1
No import route-map
No export route-map
VRF Table ID = 3
Interfaces:
RT:3:1
RT:3:1
No import route-map
No export route-map
Router# show ip bgp vpnv4 all label

127.0.0.5/32 127.0.0.4 nolabel/19
192.168.1.1 IPv4 VRF Aggr:26/nolabel
192.168.4.0/24 127.0.0.4 nolabel/20
9

127.0.0.6/32 192.168.5.1 20/nolabel
172.17.128.0/32 192.168.5.1 21/nolabel

16 Pop tag 192.168.3.0/24 0 Et1/0 192.168.2.3
17 Pop tag 127.0.0.3/32 0 Et1/0 192.168.2.3
18 17 127.0.0.4/32 0 Et1/0 192.168.2.3
20 Untagged 127.0.0.6/32[V] 0 Et2/0 192.168.5.1
21 Untagged 172.17.128.0/32[V]0 Et2/0 192.168.5.1
The following sections provide references related to the Per VRF Label feature.
Related Documents
MPLS VPNs Cisco IOS Multiprotocol Label Switching Configuration Guide,
Release 12.4
Part 4: MPLS Virtual Private Networks
Standards
Standard Title
10
Command Reference
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 2547 BGP/MPLS
Description Link
Command Reference
debug ip bgp vpnv4 unicast
mpls label mode
11
Feature Information for MPLS VPNPer VRF Label
Feature Information for MPLS VPNPer VRF Label

Table 2 Feature Information for MPLS VPNPer VRF Label

MPLS VPNPer VRF Label 12.2(33)SRD This feature allows a user to configure a single VPN label
for all local routes in the entire VPN routing and
forwarding (VRF) domain on Cisco 6500 routers. The
feature incorporates a single (per VRF) VPN label for all
local routes in the VRF table.
You can enable (or disable) the MPLS VPNPer VRF
Label feature in global configuration mode using a new,
hidden, command. This feature is available for the
Cisco 6500 router only
In 12.2(33)SRD, this feature was integrated.
countries.
coincidental.
12
MPLS VPN 6VPE per VRF Label

The MPLS VPN 6VPE per VRF Label feature allows you to configure a single Virtual Private Network
(VPN) label for all local routes in the entire IPv6 VPN routing and forwarding (VRF) domain on
Cisco 7600 routers. This MPLS VPN 6VPE per VRF Label feature incorporates a single (per VRF) VPN
label for all local IPv6 routes in the VRF table.
You can enable (or disable) the MPLS VPN 6VPE per VRF Label feature in global configuration mode.
This feature is available for the Cisco 7600 router only.

supported, see the Feature Information for MPLS VPN 6VPE per VRF Label section on page 9.
Contents
This document includes the following topics:
Prerequisites for the MPLS VPN 6VPE per VRF Label feature, page 2
Restrictions for the MPLS VPN 6VPE per VRF Label feature, page 2
Information About the MPLS VPN 6VPE per VRF Label feature, page 2
How to Configure the MPLS VPN 6VPE per VRF Label Feature, page 3
Configuration Examples for MPLS VPN 6VPE per VRF Label, page 5
Prerequisites for the MPLS VPN 6VPE per VRF Label feature

Feature Information for MPLS VPN 6VPE per VRF Label, page 9
Prerequisites for the MPLS VPN 6VPE per VRF Label feature
If your VRF domain has the external/internal Border Gateway Protocol (EIBGP) multipath feature
or the Carrier Supporting Carrier (CSC) feature enabled, disable those features before you configure
the MPLS VPN 6VPE per VRF Label feature.
Before configuring Multiprotocol Label Switching (MPLS) Layer 3 VPNs, you must have MPLS,
Label Distribution Protocol (LDP), and Cisco Express Forwarding installed in your network. All
routers in the core, including the provider edge (PE) routers, must be able to support Cisco Express
Forwarding and MPLS forwarding.
Before configuring a 6VPE per VRF label, be sure that the IPv6 address family is configured on that
VRF.
Restrictions for the MPLS VPN 6VPE per VRF Label feature
Enabling the MPLS VPN 6VPE per VRF Label feature causes BGP reconvergence, which can result
in data loss for traffic coming from the MPLS VPN core.
Note You can minimize network disruption by enabling this feature during a scheduled MPLS
maintenance window. Also, if possible, avoid enabling this feature on a live router.
Per-prefix MPLS counters for VPN prefixes are lost when you enable the MPLS VPN 6VPE per
VRF Label feature.
You cannot use this feature with CSC and EIBGP multipath features.
Information About the MPLS VPN 6VPE per VRF Label feature
To configure the MPLS VPN 6VPE per VRF Label feature, you should understand the following
concept:
MPLS VPN 6VPE per VRF Label Functionality, page 2
MPLS VPN 6VPE per VRF Label Functionality

The PE router stores both local and remote routes and includes a label entry for each route. For
distributed platforms, the multiplicity of per-prefix labels consume memory. When there are many VRFs
and routes, the amount of memory that the per-prefix labels consume can cause performance degradation
on some platform devices. To avoid this issue, the MPLS VPN 6VPE per VRF Label feature allows the
advertisement of a single VPN label for local routes throughout the entire VRF. The router uses a new
VPN label for the VRF decoding and IP-based lookup to learn where to forward packets for the PE or
customer edge (CE) interfaces.
The following conditions apply when you configure the MPLS VPN 6VPE per VRF Label feature:
2
How to Configure the MPLS VPN 6VPE per VRF Label Feature
The VRF uses one label for all local routes.

When you enable the MPLS VPN 6VPE per VRF Label feature, any existing per VRF aggregate
label is used. If no per VRF aggregate label is present, the software creates a new 6VPE per VRF
label.
When you enable the MPLS VPN 6VPE per VRF Label feature, the CE routers learned local routes
will experience some data loss.
The CE does not lose data when you disable the MPLS VPN 6VPE per VRF Label feature because
the configuration reverts to the default labeling configuration of the Cisco 7600 platform, which
uses the Per VRF Aggregate label from the local nonCE-sourced routes.
When you disable the MPLS VPN 6VPE per VRF Label feature, the configuration reverts to the
default configuration of the Cisco 7600 routers.
A 6VPE Per VRF Label forwarding entry is deleted only if the VRF, the IPv6 VRF address family,
or the BGP configuration is removed.
See the Implementing IPv6 VPN over MPLS (6VPE) configuration guide for detailed information about
IPv6 VPN services and 6VPE.
Summarization of Label Allocation Modes

Table 1 defines the label allocations used with various route types.
Table 1 Label Allocation Modes
Label Mode: Label Mode:

Route Types Cisco 7600 Default MPLS VPN 6VPE per VRF Label feature
Local to the PE (connected, static Per VRF Aggregate 6VPE Per VRF Label
route to NULL0, BGP aggregates), label
redistributed to BGP
Locally learned from CE (through Per Prefix label 6VPE Per VRF Label
external BGP or other PE or CE
protocols)
This section describes the following required task:
Configuring the MPLS VPN 6VPE per VRF Label Feature, page 3
Configuring the MPLS VPN 6VPE per VRF Label Feature

To configure a single (per VRF) VPN label for all local IPv6 routes in the VRF table, perform the
following task.
SUMMARY STEPS
1. enable
3
3. mpls label mode {vrf vrf-name | all-vrfs} protocol {bgp-vpnv6 | all-afs}

{per-prefix | per-vrf}
4. end
5. show vrf detail vrf-name
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls label mode {vrf vrf-name | all-vrfs} protocol {bgp-vpnv6 | Configures a single (per VRF) VPN
all-afs} {per-prefix | per-vrf} label for all local IPv6 routes in the
VRF table.
Example:
Router(config)# mpls label mode all-vrfs protocol bgp-vpnv6
per-vrf
Example:
Router(config)# end
Step 5 show vrf detail vrf-name Displays the VRF label mode for the
specified VRF.
Example:
Examples
The following example shows how to verify the 6VPE per VRF label configuration.
In this example output, the bold text indicates the 6VPE per VRF label mode for VPN1.
Interfaces:
GE4/1 Lo1
RT:1:1
RT:1:1 RT:2:2
No import route-map
No export route-map
4
Configuration Examples for MPLS VPN 6VPE per VRF Label

vrf-conn-aggr for connected and BGP aggregates (Label 17)
RT:1:1
RT:1:1
No import route-map
No export route-map
Router# show bgp vpnv6 unicast vrf vpn1 label

2001:DB8:1:2::/96
2001:DB8:1:2::1 IPv6 VRF Aggr:18/nolabel
:: IPv6 VRF Aggr:18/nolabel(vpn1)
2001:DB8:4:5::/96
::FFFF:127.0.0.4
nolabel/17
2001:DB8:2::1/128
2001:DB8:4::1/128
::FFFF:127.0.0.4
nolabel/18
2001:DB8:CE2::1/128
::FFFF:127.0.0.4
nolabel/19
2001:DB8:CE1::1/128
Router# show mpls forwarding

Label Label or VC or Tunnel Id Switched interface
16 Pop Label 127.0.0.4/32 0 AT3/0/0.1 point2point
The debug ip bgp vpnv6 unicast command can help troubleshoot the 6VPE per VRF label
configuration.

This section shows the default label mode configuration example (no label mode) for the Cisco 7600
router:
6VPE No Label Mode (Cisco 7600 Router Default): Example, page 5
6VPE No Label Mode (Cisco 7600 Router Default): Example
5
The following example shows the 6VPE default label mode configuration (no label mode) for the
Cisco 7600 router.
In this example output, the bold text indicates the default label mode for VPN1.
Interfaces:
GE4/1 Lo1
RT:1:1
RT:1:1 RT:2:2
No import route-map
No export route-map
RT:1:1
RT:1:1
No import route-map
No export route-map
Router# show bgp vpnv6 unicast vrf vpn1 label

2001:DB8:1:2::/96
2001:DB8:4:5::/96
::FFFF:127.0.0.4
nolabel/17
2001:DB8:2::1/128
2001:DB8:4::1/128
::FFFF:127.0.0.4
nolabel/18
2001:DB8:CE2::1/128
::FFFF:127.0.0.4
nolabel/19
2001:DB8:CE1::1/128
2001:DB8:1:2::1 19/nolabel
Router# show mpls forwarding

Label Label or VC or Tunnel Id Switched interface
16 Pop Label 127.0.0.4/32 0 AT3/0/0.1 point2point
19 No Label 2001:DB8:CE1::1/128[V]
0 GE4/1 FE80::20C:CFFF:FEAD:A00A
6
The following sections provide references related to the MPLS VPN 6VPE per VRF Label feature.
Related Documents
MPLS VPNs Configuring MPLS Virtual Private Networks
Implementing IPv6 VPN over MPLS (6VPE)
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 2547 BGP/MPLS
7
Command Reference
Description Link
Command Reference
debug ip bgp vpnv6 unicast
mpls label mode (6VPE)
8
Feature Information for MPLS VPN 6VPE per VRF Label

Table 2 Feature Information for MPLS VPN 6VPE per VRF Label

MPLS VPN 6VPE per VRF Label 12.2(33)SRD This feature allows a user to configure a single VPN label
for all local routes in the entire IPv6 VPN routing and
forwarding (VRF) domain on Cisco 7600 routers. The
feature incorporates a single (per VRF) VPN label for all
local IPv6 routes in the VRF table.
You can enable (or disable) the MPLS VPN 6VPE per VRF
Label feature in global configuration mode. This feature is
available for the Cisco 7600 only.
In Release 12.2(33)SRD, this feature was introduced on the
Cisco 7600 router. The following commands were
introduced: debug ip bgp vpnv6 unicast and mpls label
mode (6VPE).
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.

feature is supported, use the Feature Information for MPLS Multi-VRF section on page 18.
Contents
Prerequisites for MPLS Multi-VRF, page 1
Restrictions with 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 13
Prerequisites for MPLS Multi-VRF

The networks core and provider edge routers must be configured for MPLS Virtual Private Network
(VPN) operation.

Restrictions with MPLS Multi-VRF
Restrictions with 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 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
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 Ethernet 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 sites 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.
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 providers 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 customers 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.
2
Information About MPLS Multi-VRF
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 reasons that will be detailed in the section, How to Configure MPLS Multi-VRF, page 4.
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.
3
How to Configure MPLS Multi-VRF

Configuring VRFs, page 4 (Required)
Configuring BGP as the Routing Protocol (Recommended), page 6 (Required)
Configuring PE-to-CE MPLS Forwarding and Signalling with BGP (Recommended), 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)
When BGP is used as the routing protocol, it can also be used for 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 the MPLS Multi-VRF feature, you create a VRF table and then specify the Layer 3 interface
associated with that VRF. Then you configure the routing protocols within the VPN and between the CE
and the PE routers.
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.
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. In Figure 2, for example, four virtual Layer 3 interfaces are connected to the MPLS
Multi-VRF CE router.
The MPLS Multi-VRF feature does not affect the packet switching rate.
Configuring VRFs
Configure VRFs on both the PE and the CE routers.
4
Restrictions
Multicast cannot be configured at the same time on the same Layer 3 interface as the MPLS Multi-VRF
feature.
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
8. exit
9. interface interface-id
11. show ip vrf
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip routing Enables IP routing.
Example:
Router(config)# ip routing
5

Step 4 ip vrf vrf-name Names the VRF, and enters VRF configuration mode.
Example:
Router(config)# ip vrf v1
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
Example:
Step 9 interface interface-id 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.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 (Recommended)

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.
6
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.
PSUMMARY STEPS
1. enable
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:
Router(config-router)# network
10.0.0.0 mask 255.255.255.0
Step 5 redistribute ospf process-id match Sets the router to redistribute OSPF internal routes.
internal
Example:
Router(config-router)# redistribute
ospf 2 match internal
7
Command Purpose
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:
Router(config-router)# network
10.0.0.0 255.255.255.0 area 0
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 routers BGP neighbor table of the
remote-as as-number neighbors address (or peer group name) and the
neighbors autonomous system number.
Example:
Router(config-router-af)# neighbor
10.0.0.3 remote-as 100
Step 9 neighbor address activate Activates the advertisement of the IPv4 address-family
neighbors.
Example:
10.0.0.3 activate
Configuring PE-to-CE MPLS Forwarding and Signalling with BGP

(Recommended)
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
5. neighbor address send-label
6. neighbor address activate
7. end
8
10. mpls bgp forwarding
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
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
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,
Router(config-router-af)# neighbor the command does not take effect until the BGP session is
10.0.0.3 remote-as 100 restarted.
Step 6 neighbor address activate Activates the advertisement of the IPv4 address-family
neighbors.
Example:
10.0.0.3 activate
Example:
Example:
9
Command Purpose
Step 9 interface interface-id Enters interface configuration mode for the interface to be
used for the BGP session.
Example: The interface can be a routed port or an SVI.
Router(config)# interface
fastethernet3/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

If OSPF, EIGRP, RIP, or static routing is used, LDP must be used to signal labels.
SUMMARY STEPS
1. enable
4. mpls ip
11
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface interface-id 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.10
Step 4 mpls ip Enables MPLS forwarding of IPv4 packets along normally
routed paths for this interface.
Example:
12
Configuration Examples for MPLS Multi-VRF

Configuring MPLS Multi-VRF on the PE Router: Example, page 13
Configuring MPLS Multi-VRF on the CE Router, page 14
Figure 2 MPLS Multi-VRF Configuration Example
VPN 1 10.0.0.0
fe3/8 PE
10.1.1.1 CE
fe3/7 fe3/0
Core
fe3/11 fe3/0
192.168.1.1
fe3/3
135235
VPN 2
192.168.10.10
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
neighbor 10.0.0.8 send-label
exit
address-family ipv4 vrf vl
end
13
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
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
14

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
exit
Configuring PE-to-CE Connections Using BGP for Both Routing and Label Exchange
router bgp 800
exit
address-family ipv4 vrf vl1
end
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
15
The following sections provide references related to the MPLS Multi-VRF feature.
Related Documents
OSPF with Multi-VRF OSPF Support for Multi-VRF in CE Routers
Standards
Standard Title
N/A
MIBs
MIB MIBs Link
following URL:
RFCs
RFC Title
N/A
Description Link
16
Command Reference
Command Reference
17
Feature Information for MPLS Multi-VRF
Feature Information for MPLS Multi-VRF

Table 1 Feature Information for MPLS Multi-VRF

MPLS Multi-VRF 12.1(11)EA1 The MPLS Multi-VRF feature allows you to configure and
12.1(20)EW maintain more than one instance of a routing and
12.2(4)T forwarding table within the same CE router.
12.2(8)YN
In Cisco IOS Release 12.1(11)EA1, the Multi-VRF feature
12.2(18)SXD
was introduced.
12.2(25)EWA
12.2(28)SB The feature was integrated into the 12.1(20)EW release.
The feature was integrated into the 12.2(4)T release.
The feature was integrated into the 12.2(8)YN release.
The feature was integrated into the 12.2(18)SXD release.
The feature was integrated into the 12.2(25)EWA release.
Multiprotocol Label Switching support was added in Cisco
IOS Release 12.2(28)SB.
coincidental.
18
BGP Best External

The BGP Best External feature provides the network with a backup external route to avoid loss of
connectivity of the primary external route. The BGP Best External feature advertises as a backup route
the most preferred route among those received from external neighbors. This feature is beneficial in
active-backup topologies, where service providers use routing policies that cause a border router to
choose a path received over an internal BGP (iBGP) session (that of another border router) as the best
path for a prefix even if it has an external BGP (eBGP) learned path. This active-backup topology defines
one exit or egress point for the prefix in the autonomous system and uses the other points as backups if
the primary link or eBGP peering is unavailable. The policy causes the border router to hide from the
autonomous system the paths that it learned over its eBGP sessions, because it does not advertise any
path for such prefixes. To cope with this situation, some routers advertise one externally learned path
called the best-external path.

supported, see the Feature Information for BGP Best External section on page 12.
Contents
Prerequisites for BGP Best External, page 2
Restrictions for BGP Best External, page 2
Information About BGP Best External, page 2
How to Configure BGP Best External, page 5
BGP Best External
Prerequisites for BGP Best External
Configuration Examples for BGP Best External, page 9

Feature Information for BGP Best External, page 12
Prerequisites for BGP Best External

The Bidirectional Forwarding Detection (BFD) protocol must be enabled to quickly detect link
failures.
Ensure that the BGP and theMultiprotocol Label Switching (MPLS) network is up and running with
the customer site connected to the provider site by more than one path (multihomed).
The backup path must have a unique next hop that is not the same as the next hop of the best path.
BGP must support lossless switchover between operational paths.
Restrictions for BGP Best External

The BGP Best External feature will not install a backup path if BGP Multipath is installed and a
multipath exists in the BGP table. One of the multipaths automatically acts as a backup for the other
paths.
The BGP Best External feature is not supported with the following features:
MPLS VPN Carrier Supporting Carrier
MPLS VPN Inter-Autonomous Systems, option B
MPLS VPN Per VRF Label
The BGP Best External feature cannot be configured with Multicast, L2VPNs, or IPv6 VPNs.
The BGP Best External feature cannot be configured on route reflectors.
The BGP Best External feature does not support NSF/SSO. However, ISSU is supported if both
route processors have the BGP Best External feature configured.
The BGP Best External feature can only be configured on VPNv4 and IPv4 VRF address families.
When you configure the BGP Best External feature using the bgp advertise-best-external
command, you do not need to also enable the BGP PIC feature with the bgp additional-paths
install command. The BGP PIC feature is automatically enabled by the BGP Best External feature.
When you configure the BGP Best External feature, it will override the functionality of the MPLS
VPNBGP Local Convergence feature. However, you do not have to remove the protection
local-prefixes command from the configuration.
Information About BGP Best External

Before configuring the BGP Best External feature, you should understand the following concepts:
BGP Best External Overview, page 3
What the Best External Route Means, page 3
How the BGP Best External Feature Works, page 3
2
BGP Best External
Configuration Modes for Enabling BGP Best External, page 4
BGP Best External Overview

Service providers use routing policies that cause a border router to choose a path received over an
internal BGP (iBGP) session (that of another border router) as the best path for a prefix even if it has an
external BGP (eBGP) learned path. This practice is known popularly as active-backup topology and is
done to define one exit or egress point for the prefix in the autonomous system and to use the other points
as backups if the primary link or eBGP peering is unavailable.
The policy, though beneficial, causes the border router to hide from the autonomous system the paths
that it learned over its eBGP sessions, because it does not advertise any path for such prefixes. To cope
with this situation, some routers advertise one externally learned path called the best-external path. The
best-external behavior causes the BGP selection process to select two paths to every destination:
The best path is selected from the complete set of routes known to that destination.
The best external path is selected from the set of routes received from its external peers.
BGP advertises to external peers the best path. Instead of withdrawing the best path from its internal
peers when it selects an iBGP path as the best path, BGP advertises the best external path to the internal
peers.
The BGP Best External feature is an essential component of the prefix independent (PIC) edge for both
Internet access and MPLS VPN scenarios makes alternate paths available in the network in the
active-backup topology.
What the Best External Route Means

The BGP Best External feature uses a best external route as a backup path, which, according to
draft-marques-idr-best-external, is the most preferred route among those received from external
neighbors. The most preferred route from external neighbors can be the following:
Two routers in different clusters that have an iBGP session between them.
Two routers in different autonomous systems of a confederation that have an eBGP session between
them.
The best external route might be different from the best route installed in the RIB. The best route could
be an internal route. By allowing the best external route to be advertised and stored in addition to the
best route, networks gain faster restoration of connectivity by providing additional paths that may be
used if the primary path fails.
How the BGP Best External Feature Works

The BGP Best External feature is based on Internet Engineering Task Force (IETF)
draft-marques-idr-best-external.txt. The BGP Best External feature advertises a best external route to its
internal peers as a backup route. The backup route is stored in the routing information base (RIB) and
Cisco Express Forwarding. If the primary path fails, the BGP PIC functionality enables the best external
path to take over, enabling faster restoration of connectivity.
3
BGP Best External
Figure 1 MPLS VPN: Best External at the Edge of MPLS VPN
Primary PE with
Higher Local Preference
Best Path
Link Failure PE 1
P
Backup Path
CE 1 PE 3 CE 2
172.16.8.1
270789
PE 2
Backup PE
Figure 1 shows an MPLS VPN using the BGP Best External feature. The network includes the following
components:
eBGP sessions exist between the provider edge (PE) and customer edge (CE) routers.
PE1 is the primary router and has a higher local preference setting.
Traffic from CE2 uses PE1 to reach router CE1.
PE1 has two paths to reach CE1.
CE1 is dual-homed with PE1 and PE2.
PE1 is the primary path and PE2 is the backup path.
In Figure 1, traffic in the MPLS cloud flows through PE1 to reach CE1. Therefore, PE2 uses PE1 as the
best path and PE2 as the backup path.
PE1 and PE2 are configured with the BGP Best External feature. BGP computes both the best path (the
PE1CE1 link) and an backup path (PE2) and installs both paths into the RIB and Cisco Express
Forwarding. The best external path (PE2) is advertised to the peer routers in addition to the best path.
When Cisco Express Forwarding detects a link failure on PE1CE1 link, Cisco Express Forwarding
immediately switches to the backup path PE2. Traffic is quickly re-routed very due to local Fast
Convergence in Cisco Express Forwarding using the backup path. Thus traffic loss is minimized and fast
convergence achieved.
Configuration Modes for Enabling BGP Best External

You can enable the BGP Best External feature in different modes, each of which protects VRFs in its
own way:
If you issue the bgp advertise-best-external command in VPNv4 address family configuration
mode, it applies to all IPv4 VRFs. If you issue the command in this mode, you need not also issue
it for specific VRFs.
If you issue the bgp advertise-best-external command in IPv4 address-family configuration mode,
it applies only that VRF.
4
BGP Best External
How to Configure BGP Best External

Perform the following tasks to enable the BGP Best External feature.
Enabling the BGP Best External Feature, page 5
Verifying the BGP Best External Feature, page 7
Enabling the BGP Best External Feature

Perform the following task to enable the BGP Best External feature. In this task the configuration shown
allows the BGP Best External feature to be configured in either IPv4 or VPNv4 address family. In
VPNv4 address family configuration mode, the BGP Best External feature applies to all IPv4 VRFs and
you do not have to configure it for specific VRFs as well. If you issue the bgp advertise-best-external
command in IPv4 VRF address family configuration mode, the BGP Best External feature applies only
that VRF.
Prerequisites
Configure the MPLS VPN and verify that it is working properly before configuring the BGP Best
External feature. See Configuring MPLS Layer 3 VPNs for more information.
Configure multiprotocol VRFs, which allows you to share route targets policies (import and export)
between IPv4 and IPv6 or to configure separate route-target policies for IPv4 and IPv6 VPNs. For
information on configuring multiprotocol VRFs, see MPLS VPNVRF CLI for IPv4 and IPv6
VPNs.
Ensure that the CE router is connected to the network by at least two paths.
SUMMARY STEPS
1. enable
4. address-family ipv4 [unicast | vrf vrf-name]
or
address-family vpnv4 [unicast]
5. bgp advertise-best-external
6. neighbor ip-address remote-as autonomous-system-number
8. neighbor ip-address fall-over [bfd |route-map map-name]
9. end
5
BGP Best External
DETAILED STEPS

Example:
Router> enable
Example:
process.
Example:
Step 4 address-family ipv4 [unicast | vrf vrf-name] Specifies the IPv4 or VPNv4 address family and enters
or address family configuration mode.
address-family vpnv4 [unicast] The unicast keyword specifies the IPv4 or VPNv4
unicast address family.
Example: The vrf keyword and vrf-name argument specify the
Router(config-router)# address-family ipv4 name of the virtual routing and forwarding (VRF)
unicast
instance to associate with subsequent IPv4 address
or
family configuration mode commands.
Step 5 bgp advertise-best-external Calculates and uses an external backup path and installs it
into the RIB and Cisco Express Forwarding.
Example:
Router(config-router-af)# bgp
advertise-best-external
Step 6 neighbor ip-address remote-as Adds the IP address of the neighbor in the specified
autonomous-system-number autonomous system to the IPv4 multiprotocol BGP
neighbor table of the local router.
Example: By default, neighbors that are defined using the
Router(config-router-af)# neighbor 192.168.1.1 neighbor remote-as command in router configuration
remote-as 45000
mode exchange only IPv4 unicast address prefixes. To
exchange other address prefix types, neighbors must
also be activated using the neighbor activate command
in address family configuration mode for the other
prefix types.
Step 7 neighbor ip-address activate Enables the neighbor to exchange prefixes for the IPv4
unicast address family with the local router.
Example:
activate
6
BGP Best External

Step 8 neighbor ip-address fall-over [bfd |route-map Configures the BGP peering to use fast session deactivation
map-name] and enables BFD protocol support for failover.
BGP will remove all routes learned through this peer if
Example: the session is deactivated.
fall-over bfd
Example:
Verifying the BGP Best External Feature

Perform the following task to verify that the BGP Best External feature is configured correctly.
SUMMARY STEPS
1. enable
2. show vrf detail
3. show ip bgp ipv4 {mdt {all | rd | vrf} | multicast | tunnel | unicast}
or
show ip bgp vpnv4 {all | rd route-distinguisher | vrf vrf-name} [rib-failure] [ip-prefix/length
[longer-prefixes]] [network-address [mask] [longer-prefixes]] [cidr-only] [community]
[community-list] [dampened-paths] [filter-list] [flap-statistics] [inconsistent-as] [neighbors]
[paths [line]] [peer-group] [quote-regexp] [regexp] [summary] [labels]
4. show bgp vpnv4 unicast vrf vrf-name ip-address
5. show ip route vrf vrf-name repair-paths ip-address
6. show ip cef vrf vrf-name ip-address detail
DETAILED STEPS
Step 1 enable
Use this command to enabled privileged EXEC mode. Enter your password, if prompted. For example:
Router> enable
Router#
Step 2 show vrf detail

Use this command to verify that the BGP Best External feature is enabled. The following show vrf detail
command output shows that the BGP Best External feature is enabled. (Relevant output is shown in
bold).
VRF test1 (VRF Id = 1); default RD 400:1; default VPNID <not set>
Interfaces:
Se4/0
7
BGP Best External

RT:100:1 RT:200:1 RT:300:1
RT:400:1
RT:100:1 RT:200:1 RT:300:1
RT:400:1
No import route-map
No export route-map
Prefix protection with additional path enabled
Address family ipv6 not active.
Step 3 show ip bgp ipv4 {mdt {all | rd | vrf} | multicast | tunnel | unicast}
or
show ip bgp vpnv4 {all | rd route-distinguisher | vrf vrf-name} [rib-failure] [ip-prefix/length
[community-list] [dampened-paths] [filter-list] [flap-statistics] [inconsistent-as] [neighbors] [paths
[line]] [peer-group] [quote-regexp] [regexp] [summary] [labels]
Use this command to verify that the best external route is advertised. In the command output, the code
b indicates a backup path and the code x designates the best external path. In the following example, the
relevant output is shown in bold.
Router# show ip bgp vpnv4 all
BGP table version is 1104964, local router ID is 10.2.2.2

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale, multipath, b backup-path, x best-external
Origin codes: i - IGP, e - EGP, ? - incomplete
Network Next Hop Metric LocPrf Weight Path

Route Distinguisher: 11:12 (default for vrf blue)
*>i1.0.0.1/32 10.10.3.3 0 200 0 1 ?
* i 10.10.3.3 0 200 0 1 ?
* 10.0.0.1 0 1 ?
*bx 10.0.0.1 0 0 1 ?
* 10.0.0.1 0 1 ?
Step 4 show bgp vpnv4 unicast vrf vrf-name ip-address

Use this command to verify that the best external route is advertised. In the following example, the
relevant output is shown in bold.
Router# show bgp vpnv4 unicast vrf vpn1 10.10.10.10

Advertise-best-external
1 2
200
10.6.6.6 (metric 21) from 10.6.6.6 (10.6.6.6)
200
10.1.2.1 from 10.1.2.1 (10.1.1.1)
Origin incomplete, metric 0, localpref 100, valid, external, backup/repair,
advertise-best-external
Extended Community: RT:1:1 , recursive-via-connected
mpls labels in/out 23/nolabel
8
BGP Best External
Configuration Examples for BGP Best External
Step 5 show ip route vrf vrf-name repair-paths ip-address

Use this command to display the repair route, which is shown in bold.
Router# show ip route vrf vpn1 repair-paths
Routing Table: vpn1

Codes: L - local, C - connected, S - static, R - RIP, M - mobile, B - BGP
o - ODR, P - periodic downloaded static route, H - NHRP
+ - replicated route, % - next hop override

B 10.1.1.0/24 [200/0] via 10.6.6.6, 00:38:33
[RPR][200/0] via 10.1.2.1, 00:38:33
B 10.1.1.1/32 [200/0] via 10.6.6.6, 00:38:33
[RPR][200/0] via 10.1.2.1, 00:38:33
C 10.1.2.0/24 is directly connected, Ethernet0/0
L 10.1.2.2/32 is directly connected, Ethernet0/0
B 10.1.6.0/24 [200/0] via 10.6.6.6, 00:38:33
[RPR][200/0] via 10.1.2.1, 00:38:33
Step 6 show ip cef vrf vrf-name ip-address detail

Use this command to display the best external route. In the following example, the relevant output is
shown in bold.
Router# show ip cef vrf test 10.71.8.164 detail
10.71.8.164/30, epoch 0, flags rib defined all labels

recursive via 10.249.0.102 label 35
nexthop 10.249.246.101 Ethernet0/0 label 25
recursive via 10.249.0.104 label 28, repair
nexthop 10.249.246.101 Ethernet0/0 label 24
Configuration Examples for BGP Best External

The following examples configure and then verify the BGP Best External feature:
Configuring the BGP Best External Feature: Example, page 9
Configuring the BGP Best External Feature: Example

The following example configures the BGP Best External feature in VPNv4 mode:
vrf definition test1
rd 400:1
9
BGP Best External

address-family ipv4
exit-address-family
exit
!
vrf forwarding test1
ip address 10.0.0.1 255.0.0.0
exit
!
router bgp 64500
no synchronization
no auto-summary
!
bgp advertise-best-external
exit-address-family
!
address-family ipv4 vrf test1
no synchronization
bgp recursion host
neighbor 192.168.13.2 fall-over bfd
exit-address-family
The following sections provide references related to the BGP Best External feature.
Related Documents
Basic MPLS VPNs Configuring MPLS Layer 3 VPNs
Multiprotocol VRFs MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
A failover feature that creates a new path after a link or MPLS VPNBGP Local Convergence
node failure
BGP routing BGP Feature Roadmap
10
BGP Best External
Standards
Standard Title
draft-marques-idr-best-external BGP Best-external, Advertisement of the best-external route to
iBGP
MIBs
MIB MIBs Link
following URL:
RFCs
RFC Title
Description Link
11
BGP Best External
Feature Information for BGP Best External
Feature Information for BGP Best External

Table 1 Feature Information for BGP Best External

BGP Best External 12.2(33)SRE The BGP Best External feature creates and stores a backup path in the routing
12.2(33)XNE information base and in Cisco Express Forwarding, so that in case of a failure, the
backup path can immediately take over, thus enabling subsecond failover.
In Cisco IOS Release12.2(33)SRE, this feature was introduced.
In 12.2(33)XNE, support was added for the Cisco 10000 router.
Information About BGP Best External, page 2
How to Configure BGP Best External, page 5
Configuration Examples for BGP Best External, page 9
The following commands were introduced or modified: bgp
advertise-best-external, bgp recursion host, show ip bgp, show ip bgp vpnv4,
show ip cef, show ip cef vrf, show ip route, show ip route vrf.
coincidental.
12
BGP PIC Edge for IP and MPLS-VPN

The BGP PIC Edge for IP and MPLS-VPN feature improves convergence after a network failure. This
convergence is applicable to both core and edge failures and can be used in both IP and MPLS networks.
BGP PIC Edge for IP and MPLS-VPN feature creates and stores a backup/alternate path in the routing
information base (RIB), forwarding information base (FIB) and in Cisco Express Forwarding, so that
when a failure is detected, the backup/alternate path can immediately take over, thus enabling fast
failover.
Benefits of this feature include the following:
An additional path for failover allows faster restoration of connectivity if a primary path is invalid
or is withdrawn.
Reduction of traffic loss.
Constant convergence time so that the switching time is the same for all prefixes.
Note In this document, the BGP PIC Edge for IP and MPLS-VPN feature is called BGP PIC.

supported, see the Feature Information for BGP PIC section on page 18.
Contents
Contents
Prerequisites for BGP PIC, page 2
Restrictions for BGP PIC, page 2
Information About BGP PIC, page 3
How to Configure BGP PIC, page 11
Configuration Examples for BGP PIC, page 13
Feature Information for BGP PIC, page 18
Prerequisites for BGP PIC

Ensure that the BGP and the IP or Multiprotocol Label Switching (MPLS) network is up and running
with the customer site connected to the provider site by more than one path (multihomed).
Ensure that the backup/alternate path has a unique next hop that is not the same as the nexthop of
the best path.
Enable Bidirectional Forwarding Detection (BFD) protocol to quickly detect link failures of directly
connected neighbors.
Restrictions for BGP PIC

The following restrictions apply to the BGP PIC feature:
With BGP Multipath, the BGP PIC feature is already supported.
In MPLS VPNs, the BGP PIC feature is not supported with MPLS VPN Inter-Autonomous Systems
Option B.
The BGP PIC feature supports prefixes only the IPv4 and VPNv4 address families.
The BGP PIC feature cannot be configured with Multicast, L2VPNs, or IPv6 VPNs.
If the route reflector is only in the control plane, then you do not need BGP PIC, because BGP PIC
addresses data plane convergence.
When two PE routers become each others backup/alternate path to a CE router, traffic might loop
if the CE router fails. Neither router will reach the CE router, and traffic will continue to be
forwarded between the PE router until the time-to-live (TTL) timer expires.
The BGP PIC feature does not support NSF/SSO. However, ISSU is supported if both route
processors have the BGP PIC feature configured.
The BGP PIC feature solves the traffic forwarding only for a single network failure at both edge and
core.
The BGP PIC feature does not work with the he BGP Best External feature. If you try to configure
the BGP PIC feature after configuring the BGP Best External feature, you receive an error.
2
Information About BGP PIC

Before configuring the BGP PIC feature, you should understand the following concepts:
How BGP Converges Under Normal Circumstances, page 3
How BGP PIC Improves Convergence, page 3
How a Failure Is Detected, page 5
How BGP PIC Can Achieve Subsecond Convergence, page 5
How BGP PIC Improves Upon the Functionality of MPLS VPNBGP Local Convergence, page 6
Configuration Modes for Enabling BGP PIC, page 6
BGP PIC Scenarios, page 6
How BGP Converges Under Normal Circumstances

Under normal circumstances, BGP can take several seconds to a few minutes to converge after a network
change. At a high level, BGP goes through the following process:
1. BGP learns of failures through either IGP or BFD events or interface events.
2. BGP withdraws the routes from the routing information base (RIB), and the RIB withdraws the
routes from the forwarding information base (FIB) and distributed FIB (dFIB). This process clears
the data path for the affected prefixes.
3. BGP sends withdraw messages to its neighbors.
4. BGP calculates the next best path to the affected prefixes.
5. BGP inserts the next best path for affected prefixes into the RIB, and the RIB installs them in the
FIB and dFIB.
This process take from a few seconds to a few minutes to complete depending on the latency of the
network, the convergence time across the network, and the local load on the devices. The data plane
converges only after the control plane converges.
How BGP PIC Improves Convergence

BGP PIC functionality is achieved by additional functionality in the BGP, RIB, Cisco Express
Forwarding, and MPLS.
BGP Functionality
BGP PIC affects prefixes under the IPv4 and VPVN4 address families. For those prefixes, BGP
calculates an additional second best path in addition to the primary best path. (The second best path
is called the backup/alternate path.) BGP installs the best and backup/alternate paths for the affected
prefixes into the BGP RIB. The backup/alternate path provides a fast reroute mechanism to counter
a singular network failure. BGP also includes the alternate/backup path in its application
programming interface (API) to the IP RIB.
RIB Functionality
For BGP PIC, RIB installs an alternate path per route if one is available. With BGP PIC
functionality, if the RIB selects a BGP route containing a backup/alternate path, it installs the
backup/alternate path with the best path. The RIB also includes the alternate path in its API with the
FIB.
3
Cisco Express Forwarding (FIB) Functionality

With BGP PIC, Cisco Express Forwarding stores an alternate path per prefix. When the primary path
goes down, Cisco Express Forwarding searches for the backup/alternate path when in a prefix
independent manner. Cisco Express Forwarding also listens to BFD events to rapidly detect local
failures.
MPLS Functionality
MPLS Forwarding is similar to Cisco Express Forwarding in that it stores alternate paths and
switches to an the alternate path if the primary path goes away.
When the BGP PIC feature is enabled, BGP calculates a backup/alternate path per prefix and installs
them into BGP RIB, IP RIB, and FIB. This improves convergence after a network failure. There are two
types of network failures that the BGP PIC feature detects:
Core node/link failure (iBGP node failure): If a PE node/link fails, then the failure is detected
through IGP convergence. IGP conveys the failure through the RIB to the FIB.
Local link/immediate neighbor node failure (eBGP node/link failure): To detect a local link failure
or eBGP single-hop peer node failure in less than a second, you must enable BFD. Cisco Express
Forwarding looks for BFD events to detect a failure of an eBGO single-hop peer.
Convergence in the Data Plane

Upon detection of a failure, Cisco Express Forwarding detects the alternate nexthop for all prefixes
affected by the failure. The data plane convergence is achieved in subseconds depending on whether the
BGP PIC implementation exists software or hardware.
Convergence in the Control Plane Convergence

Upon detection of failure, BGP learns about the failure through IGP convergence or BFD events and
sends withdraw messages for the prefixes, recalculating the best and backup/alternate paths, and
advertising the next best path across the network.
BGP Fast Reroutes Role in the BGP PIC Feature

BGP Fast Reroute (FRR) provides a best path and a backup/alternate path in BGP, RIB, and Cisco
Express Forwarding. BGP FRR provides a very fast reroute mechanism into the RIB and Cisco Express
Forwarding on the backup BGP next hop to reach a destination when the current best path is not
available.
BGP FRR precomputes a second best path in BGP and gives it to the RIB and Cisco Express Forwarding
as a backup/alternate path, and Cisco Express Forwarding programs it into line cards.
Therefore BGP FRR is responsible for the setup of the best path and backup/alternate path. The BGP
PIC feature provides the ability for Cisco Express Forwarding to quickly switch the traffic to the other
egress ports if the current next hop or the link to this next hop goes down. This is illustrated in Figure 1.
4
Figure 1 BGP PIC Edge and BGP FRR
BGP IPv4 NLRI BGP VPNv4 NLRI

(IPv4 unicast and global address family) (VPNv4 and VRF address family)
BGP FRR
Selects and stores best path and
backup/alternate path per prefix. BGP RIB
IP RIB
PIC Software
Reacts to next hop failure and
switches to alternate path.
FIB
Convergence not dependent
on number of prefixes.
PIC Hardware CEF/FIB H/W API
DFIB DFIB ...
196159
How a Failure Is Detected
If the failure is detected in the IBGP (remote) peer, it is detected by IGP and can take a few seconds for
the detection to occur. Convergence can occur in subseconds or seconds, depending on whether PIC is
enabled on the line cards.
If the failure is with directly connected neighbors (EBGP), if you use BFD to detect when a neighbor
has gone away, the detection is within a subsecond and the convergence can occur in subseconds or
seconds, depending on whether PIC is enabled on the line cards.
How BGP PIC Can Achieve Subsecond Convergence

The BGP PIC feature works at the Cisco Express Forwarding level, and Cisco Express Forwarding can
be processed in hardware line cards and in software.
For platforms that support Cisco Express Forwarding processing in the line cards, the BGP PIC
feature can converge in subseconds. The 7600 router supports Cisco Express Forwarding processing
in the line cards and thus can attain subsecond convergence.
5
For platforms that do not use Cisco Express Forwarding in hardware line cards, Cisco Express
Forwarding is achieved in the software. The BGP PIC feature will work with the Cisco Express
Forwarding through the software and achieve convergence within seconds. The Cisco 10000 router
and the Cisco ASR 1000 series router supports Cisco Express Forwarding in the software and thus
can achieve convergence in seconds rather than milliseconds.
How BGP PIC Improves Upon the Functionality of MPLS VPNBGP Local
Convergence
The BGP PIC feature is an enhancement to the MPLS VPNBGP Local Convergence feature, which
provides a failover mechanism that recalculates the best path and installs the new path in forwarding
after a link failure. The feature maintains the local label for 5 minutes to ensure that the traffic uses the
backup/alternate path, thus minimizing traffic loss.
The BGP PIC feature improves the LoC time to under a second by calculating a backup/alternate path
in advance. When a link failure occurs, the traffic is sent to the backup/alternate path.
When you configure the BGP PIC feature, it will override the functionality of the MPLS VPNBGP
Local Convergence feature. You do not have to remove the protection local-prefixes command from the
configuration.
Configuration Modes for Enabling BGP PIC

Because many service provider networks contain many VRFs, the BGP PIC feature allows you to
configure BGP PIC feature for all VRFs at once.
VPNv4 address family configuration mode protects all the VRFs.
VRF-IPv4 address family configuration mode protects only IPv4 VRFs.
Global router configuration mode protects prefixes in the global routing table.
BGP PIC Scenarios

The following scenarios explain how you can configure BGP PIC functionality to achieve fast
convergence:
IP PECE Link and Node Protection on the CE Side (Dual PEs), page 6
IP PECE Link and Node Protection on the CE Side (Dual CEs and Dual PE Primary and Backup
Nodes), page 7
IP MPLS PECE Link Protection for the Primary or Backup/Alternate Path, page 8
IP MPLS PECE Node Protection for Primary or Backup/Alternate Path, page 9
IP PECE Link and Node Protection on the CE Side (Dual PEs)

Figure 2 shows a network that uses the BGP PIC feature. The network includes the following
components:
eBGP sessions exist between the PE and CE routers.
Traffic from CE1 uses PE1 to reach network 192.168.9.0/24 through router CE3.
6
CE1 has two paths:

PE1 as the primary path.
PE2 as the backup/alternate path.
CE1 is configured with theBGP PIC feature. BGP computes PE1 as the best path and PE2 as the
backup/alternate path and installs both the routes into the RIB and Cisco Express Forwarding forwarding
plane. When the CE1PE1 link goes down, Cisco Express Forwarding detects the link failure and points
the forwarding object to the backup/alternate path. Traffic is quickly rerouted due to local fast
convergence in Cisco Express Forwarding.
Figure 2 Using BGP PIC To Protect PE-CE Link
AS64500
AS64499
PE1 RR1 PE3 AS64511
S2/0 S3/0 S2/0 S3/0 S2/0 S3/0
R3 R5 R7
CE1 S2/0 S4/0 S4/0 S5/0 S4/0 S2/0 CE3
PIC
R1 R9
S4/0 S2/0 S4/0 S3/0
S3/0 S3/0
S3/0 R8 S4/0
R4 S5/0 S3/0 R6 S5/0 S2/0
PE2 RR2 PE4
247897
IP PECE Link and Node Protection on the CE Side (Dual CEs and Dual PE Primary and Backup
Nodes)
Figure 3 shows a network that uses the BGP PIC feature on CE1. The network includes the following
components:
CE1 has two paths:
PE1 as the primary path.
PE2 as the backup/alternate path.
An iBGP session exists between the CE1 and CE2 routers.
In this example, CE1 and CE2 are configured with the BGP PIC feature. BGP computes PE1 as the best
path and PE2 as the backup/alternate path and installs both the routes into the RIB and Cisco Express
Forwarding plane.
There should not be any policies set on CE1 and CE2 for the eBGP peers PE1 and PE2. Both CE routers
must point to the external eBGP route as next hop. On CE1, the next hop to reach CE3 is through PE1,
so PE1 is the best path to reach CE3. On CE2, the best path to reach CE3 is PE2. CE2 advertises to CE1
with itself as the next hop and CE1 does the same to CE2. As a result, CE1 has two paths for the specific
7
prefix and it usually selects the directly connected eBGP path over the iBGP path through the best path
selection rules. Similarly, CE2 has two pathsan eBGP path through PE2 and an iBGP path through
CE1PE1.
When the CE1PE1 link goes down, Cisco Express Forwarding detects the link failure and points the
forwarding object to the backup/alternate node CE2. Traffic is quickly rerouted due to local fast
convergence in Cisco Express Forwarding.
If the CE1PE1 link or PE1 goes down and BGP PIC is enabled on CE1, BGP recomputes the best path,
removing the next hop PE1 from RIB and reinstalling CE2 as the nexthop into the RIB and Cisco Express
Forwarding. CE1 automatically gets a backup/alternate repair path into Cisco Express Forwarding and
the traffic loss during forwarding is now in subseconds, thereby achieving fast convergence.
Figure 3 Using BGP PIC in a Dual CE, Dual PE Network
AS64500
AS64499
CE1 PE1 RR1 PE3 AS64511
S2/0 S2/0 S3/0 S2/0 S3/0 S2/0 S3/0
R1 R3 R5 R7
FE 0/0 S4/0 S4/0 S5/0 S4/0 S2/0 CE3
PIC
FE 0/0 S3/0 R9
S4/0 S2/0 S4/0
S3/0
R2 S2/0 S3/0 R8 S4/0

R4 S5/0 S3/0 R6 S5/0 S2/0
CE2 PE2 RR2 PE4
252634
IP MPLS PECE Link Protection for the Primary or Backup/Alternate Path
Figure 3 shows a network that uses that uses the BGP PIC feature on CE1 and CE2. The network includes
the following components:
The PE routers are VPNv4 iBGP peers with reflect routers in the MPLS network.
PE1 has two paths to reach CE3 from the reflect routers:
PE3 is the primary path with the next hop as a PE3 address.
PE4 is the backup/alternate path with the next hop as a PE4 address.
In this example, all the PE routers can be configured with the BGP PIC feature under IPv4 or VPNv4
address families.
8
For BGP PIC to work in BGP for PECE link protection, set the policies on PE3 and PE4 for the prefixes
received from CE3 so that one of the PE routers acts as primary and the other as backup/alternate.
Usually this is done using local preference and giving better local preference to PE3. In the MPLS cloud,
traffic internally flows through PE3 to reach CE3. PE1 thus has PE3 as the best path and PE4 as the
second path.
When the PE3CE3 link goes down, Cisco Express Forwarding detects the link failure, PE3 recomputes
the best path and selects PE4 as the best path and sends a withdraw for the PE3 prefix to the reflect
routers. Some of the traffic goes through PE3PE4 until BGP installs PE4 as the best path route into the
RIB and Cisco Express Forwarding. PE1 receives the withdraw and recomputes the best path and selects
PE4 as the best path and installs the routes into the RIB and Cisco Express Forwarding plane.
Thus, with BGP PIC enabled on PE3 and PE4, Cisco Express Forwarding detects the link failure and
does in-place modification of the forwarding object to the backup/alternate node PE4 that already exists
in Cisco Express Forwarding. PE4 knows that the backup/alternate path is locally generated and routes
the traffic to the egress port connected to CE3. This way, traffic loss is minimized and fast convergence
is achieved.
IP MPLS PECE Node Protection for Primary or Backup/Alternate Path

Figure 4 shows a network that uses theBGP PIC feature on all the PE routers in an MPLS network.
Figure 4 Enabling BGP PIC on All PEs Routers in the MPLS Network
AS64500
AS64499 PIC
CE1 PE1 RR1 PE3 AS64511

S2/0 S2/0 S3/0 S2/0 S3/0 S2/0 S3/0
R1 R3 R5 R7
FE 0/0 S4/0 S4/0 S5/0 S4/0 S2/0 CE3
FE 0/0 S3/0 R9
S4/0 S2/0 S4/0
S3/0
R2 S2/0 S3/0 R8 S4/0

R4 S5/0 S3/0 R6 S5/0 S2/0
CE2 PE2 RR2 PE4
PIC
206552
The network includes the following components:

The PE routers are VPNv4 iBGP peers with reflect routers in the MPLS network.
PE1 has two paths to reach CE3 from the reflect routers:
PE3 is the primary path with the with the next hop as a PE3 address.
PE4 is the backup/alternate path with the next hop as a PE4 address.
9
In this example, all the PE routers are configured with the BGP PIC feature under IPv4 and VPNv4
address families.
For BGP PIC to work in BGP for the PECE node protection, set the policies on PE3 and PE4 for the
prefixes received from CE3 such that one of the PE routers acts as primary and the other as
backup/alternate. Usually this is done using local preference and giving better local preference to PE3.
In the MPLS cloud, traffic internally flows through PE3 to reach CE3. So PE1 has PE3 as the best path
and PE4 as the second path.
When PE3 goes down, PE1 knows about the removal of the host prefix by IGPs in subseconds and
recomputes the best path and selects PE4 as the best path and installs the routes into the RIB and Cisco
Express Forwarding forwarding plane. Normal BGP convergence will happen, while BGP PIC is
redirecting the traffic through PE4. Thus, packets are not lost.
Thus, with BGP PIC enabled on PE3 Cisco Express Forwarding detects the node failure on PE3 and
points the forwarding object to the backup/alternate node PE4. PE4 knows that the backup/alternate path
is locally generated and routes the traffic to the egress port using the backup/alternate path. This way,
traffic loss is minimized.
No local policies set on the PE routers

PE1 and PE2 point to the eBGP CE paths as the next hop with no local policy. Each of the PE routers
receives the others path and BGP calculates the backup/alternate path and installs it into Cisco Express
Forwarding along with its own eBGP path towards CE as the best path. The limitation of the MPLS
PECE link and node protection solutions is that you cannot change BGP policies. They should work
without the need of a best-external path.
Local policies set on the PE routers

Whenever there is a local policy on the PE routers to select one of the PE routers as the primary path to
reach the egress CE, the bgp advertise-best-external command is needed on the backup/alternate node
PE3 to propagate the external CE routes with a backup/alternate label into the route reflectors and the
far-end PE routers.
Cisco Express Forwarding Recursion

Recursion is the ability to find the next longest matching path when the primary path goes away.
When the BGP PIC feature is not installed, if the next hop to a prefix fails, Cisco Express forwarding
finds the next path to reach the prefix by recursing through the FIB to find the next longest matching
path to the prefix. This is useful if the next hop is multiple hops away and there is more than one way of
reaching the next hop.
However with the of BGP PIC feature, you want to disable Cisco Express Forwarding recursion, for the
following reasons:
Recursion slows down convergence when Cisco Express Forwarding searches all the FIB entries.
BGP PIC Edge already precomputes an alternate path, thus eliminating the need for CEF recursion.
When BGP PIC functionality is enabled, Cisco Express Forwarding recursion is disabled by default for
two conditions :
For next hops learned with a /32 network mask (host routes)
For next hops that are directly connected
For all other cases, Cisco Express Forwarding recursion is enabled.
10
How to Configure BGP PIC
As part of BGP PIC functionality, you can issue the bgp recursion host command to disable or enable
Cisco Express Forwarding recursion for BGP host routes.
To disable or enable Cisco Express Forwarding recursion for BGP directly connected next hops, you can
issue the disable-connected-check command.

Configuring the BGP PIC feature consists of the following task:
Enabling BGP PIC, page 11
Enabling BGP PIC

Because many service provider networks contain many VRFs, the BGP PIC feature allows you to
configure BGP PIC feature for all VRFs at once.
VPNv4 address family configuration mode protects all the VRFs.
VRF-IPv4 address family configuration mode protects only IPv4 VRFs.
Global router configuration mode protects prefixes in the global routing table.
For a full configuration example that includes configuring multiprotocol VRFs and show output to verify
that the feature is enabled, see the Configuring BGP PIC: Example section on page 13.
Prerequisites
If you are implementing the BGP PIC feature in an MPLS VPN, ensure the network is working
properly before configuring the BGP PIC feature. See Configuring MPLS Layer 3 VPNs for more
information.
If you are implementing the BGP PIC feature in an MPLS VPN, configure multiprotocol VRFs,
which allows you to share route-targets policies (import and export) between IPv4 and IPv6 or to
configure separate route-target policies for IPv4 and IPv6 VPNs. For information on configuring
multiprotocol VRFs, see MPLS VPNVRF CLI for IPv4 and IPv6 VPNs.
Ensure that the CE router is connected to the network by at least two paths.
SUMMARY STEPS
1. enable
4. address-family ipv4 [unicast | vrf vrf-name]
or
5. bgp additional-paths install
6. neighbor ip-address remote-as autonomous-system-number
8. bgp recursion host
11
9. neighbor ip-address fall-over [bfd | route-map map-name]

10. end
DETAILED STEPS

Example:
Router> enable
Example:
process.
Example:
Step 4 address-family ipv4 [unicast | vrf vrf-name] Specifies the IPv4 or VPNv4 address family and enters
or address family configuration mode.
The unicast keyword specifies the IPv4 or VPNv4
unicast address family.
Example:
Router(config-router)# address-family ipv4 The vrf keyword and vrf-name argument specify the
unicast name of the virtual routing and forwarding (VRF)
or instance to associate with subsequent IPv4 address
Router(config-router)# address-family vpnv4 family configuration mode commands.
Step 5 bgp additional-paths install Calculates a backup/alternate path and installs it into the
RIB and Cisco Express Forwarding.
Example:
Router(config-router-af)# bgp additional-paths
install
Step 6 neighbor ip-address remote-as Adds the IP address of the neighbor in the specified
autonomous-system-number autonomous system to the IPv4 multiprotocol BGP
neighbor table of the local router.
Example: By default, neighbors that are defined using the
Router(config-router-af)# neighbor 192.168.1.1 neighbor remote-as command in router configuration
remote-as 45000
mode exchange only IPv4 unicast address prefixes. To
exchange other address prefix types, neighbors must
also be activated using the neighbor activate command
in address family configuration mode for the other
prefix types.
Step 7 neighbor ip-address activate Enables the neighbor to exchange prefixes for the IPv4
unicast address family with the local router.
Example:
activate
12
Configuration Examples for BGP PIC

Step 8 bgp recursion host (Optional) Enables the recursive-via-host flag for IPv4,
VPNv4, and VRF address families.
Example: When the BGP PIC feature is enabled, Cisco Express
Router(config-router-af)# bgp recursion host Forwarding recursion is disabled. Under most
circumstances, you do not want to enable recursion
when BGP PIC is enabled.
Step 9 neighbor ip-address fall-over [bfd |route-map Enables BFD protocol support to detect when a neighbor
map-name] has gone away, which can occur within a subsecond.
Example:
fall-over bfd
Step 10 end Exits address family configuration mode and enters
Example:

The following examples configure and then verify the BGP PIC feature:
Configuring BGP PIC: Example, page 13
Displaying Backup/Alternate Paths for BGP PIC: Example, page 14
Configuring BGP PIC: Example

The following example configures the BGP PIC feature in VPNv4 address-family configuration mode,
which enables the feature on all VRFs. (The bgp additional-paths install command is shown in bold.)
In the following example there are two VRFs defined: blue and green. All the VRFs, including those in
VRFs blue and green are protected by backup/alternate paths.
vrf definition test1
rd 400:1
address-family ipv4
exit-address-family
exit
!
vrf forwarding test1
ip address 10.0.0.1 255.0.0.0
exit
router bgp 3
no synchronization
13
redistribute static
no auto-summary
!
bgp additional-paths install
neighbor 10.6.6.6 send-community both
exit-address-family
!
address-family ipv4 vrf blue
import path selection all
import path limit 10
no synchronization
exit-address-family
!
address-family ipv4 vrf green
import path selection all
import path limit 10
no synchronization
exit-address-family
The following show vrf detail command output shows that the BGP PIC feature is enabled. (Relevant
output is shown in bold)
VRF test1 (VRF Id = 1); default RD 400:1; default VPNID <not set>
Interfaces:
Se4/0
RT:100:1 RT:200:1 RT:300:1
RT:400:1
RT:100:1 RT:200:1 RT:300:1
RT:400:1
No import route-map
No export route-map
Prefix protection with additional path enabled
Address family ipv6 not active.
Displaying Backup/Alternate Paths for BGP PIC: Example

The command output in the following example shows that the VRFs in VRF blue have backup/alternate
paths. The relevant command output is shown in bold.
Router# show ip bgp vpnv4 vrf blue 10.0.0.0
14

Paths: (4 available, best #1, table blue)
Additional-path
6
10.3.3.3 (metric 21) from 10.6.6.6 (10.6.6.6)
Originator: 10.3.3.3, Cluster list: 10.0.0.1 , recursive-via-host
10.13.13.13 (via green) from 10.13.13.13 (10.0.0.2)
Origin incomplete, metric 0, localpref 100, valid, external
10.3.3.3 (metric 21) from 10.7.7.7 (10.7.7.7)
1
10.11.11.11 from 10.11.11.11 (1.0.0.1)
Origin incomplete, metric 0, localpref 100, valid, external, backup/repair
The command output in the following example shows that the VRFs in VRF green have backup/alternate
paths. The relevant command output is shown in bold.
Router# show ip bgp vpnv4 vrf green 12.0.0.0

Paths: (4 available, best #4, table green)
Additional-path
5
10.11.11.11 (via blue) from 10.11.11.11 (1.0.0.1)
Origin incomplete, metric 0, localpref 100, valid, external
1
10.3.3.3 (metric 21) from 10.7.7.7 (10.7.7.7)
1
10.13.13.13 from 10.13.13.13 (10.0.0.2)
Origin incomplete, metric 0, localpref 100, valid, external, backup/repair
1
10.3.3.3 (metric 21) from 10.6.6.6 (10.6.6.6)
The command output in the following example shows the BGP routing table entries for the backup and
alternate paths. The relevant command output is shown in bold.
Router# show ip bgp 10.0.0.0 255.255.0.0
BGP routing table entry for 10.0.0.0/16, version 123
15
Paths: (4 available, best #3, table default)

Additional-path
2 3
Local
10.0.101.4 from 10.0.101.4 (10.3.3.3)
Origin IGP, localpref 100, weight 500, valid, internal
Local
10.0.101.3 from 10.0.101.3 (10.4.4.4)
Origin IGP, localpref 100, weight 200, valid, internal
Local
10.0.101.2 from 10.0.101.2 (10.1.1.1)
Origin IGP, localpref 100, weight 900, valid, internal, best
Local
10.0.101.1 from 10.0.101.1 (10.5.5.5)
Origin IGP, localpref 100, weight 700, valid, internal, backup/repair
The command output in the following example shows the routing information base entries for the
backup and alternate paths. The relevant command output is shown in bold.
Router# show ip route repair-paths 10.0.0.0 255.255.0.0
Routing entry for 10.0.0.0/16

Known via "bgp 10", distance 200, metric 0, type internal
Last update from 10.0.101.2 00:00:56 ago
Routing Descriptor Blocks:
* 10.0.101.2, from 10.0.101.2, 00:00:56 ago
Route metric is 0, traffic share count is 1
AS Hops 0
MPLS label: none
[RPR]10.0.101.1, from 10.0.101.1, 00:00:56 ago
AS Hops 0
MPLS label: none
The command output in the following example shows the Cisco Express Forwarding/forwarding
information base entries for the backup and alternate paths. The relevant command output is shown in
bold.
Router# show ip cef 40.0.0.0 255.255.0.0 detail
10.0.0.0/16, epoch 0, flags rib only nolabel, rib defined all labels
recursive via 10.0.101.2
attached to GigabitEthernet0/2
recursive via 10.0.101.1, repair
attached to GigabitEthernet0/2
16
The following sections provide references related to the BGP PIC feature.
Related Documents
Basic MPLS VPNs Configuring MPLS Layer 3 VPNs
A failover feature that creates a new path after a link or MPLS VPNBGP Local Convergence
node failure
Configuring multiprotocol VRFs MPLS VPNVRF CLI for IPv4 and IPv6 VPNs
BGP routing BGP Feature Roadmap
Standards
Standard Title
draft-walton-bgp-add-paths-04.txt Advertisement of Multiple Paths in BGP
MIBs
MIB MIBs Link
following URL:
RFCs
RFC Title
17
Feature Information for BGP PIC
Description Link
The Cisco Support website provides extensive online resources, including http://www.cisco.com/cisco/web/sup
documentation and tools for troubleshooting and resolving technical issues with port/index.html
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.
password.

18
Table 1 Feature Information for BGP PIC

BGP PIC Edge for IP and MPLS-VPN 12.2(33)SRE The BGP PIC feature creates and stores a backup/alternate path in
12.2(33)XNE the routing information base (RIB) and in Cisco Express
Forwarding, so that in case of a failure, the backup/alternate path
can immediately take over, thus enabling subsecond failover.
In 12.2(33)SRC, this feature was introduced on the Cisco 7200
router.
In 12.2(33)SRB, this feature was introduced on the Cisco 7600
router.
In 12.2(33)XNE, support was added for the Cisco 10000 router.
Prerequisites for BGP PIC, page 2
Restrictions for BGP PIC, page 2
Information About BGP PIC, page 3
How to Configure BGP PIC, page 11
The following commands were introduced or modified: bgp
additional-paths install, bgp recursion host, show ip bgp, show
ip route, show ip cef, show vrf.
coincidental.
19
20
MPLS VPNL3VPN over GRE
First Published: September 29, 2008

The MPLS VPNL3VPN over GRE feature provides a mechanism for tunneling Multiprotocol Label
Switching (MPLS) packets over a non-MPLS network.
The MPLS VPNL3VPN 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.

supported, see the Feature Information for MPLS VPNL3VPN over GRE section on page 11.
Contents
Prerequisites for MPLS VPNL3VPN over GRE, page 2
Restrictions for MPLS VPNL3VPN over GRE, page 2
Information About MPLS VPNL3VPN over GRE, page 2
How to Configure MPLS VPNL3VPN over GRE, page 4
Configuration Examples for MPLS VPNL3VPN over GRE, page 6
Feature Information for MPLS VPNL3VPN over GRE, page 11
Prerequisites for MPLS VPNL3VPN over GRE
Prerequisites for MPLS VPNL3VPN over GRE

Before you configure the MPLS VPNL3VPN 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 VPNL3VPN over GRE

The MPLS VPNL3VPN 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 VPNL3VPN over GRE

The MPLS VPNL3VPN over GRE feature provides a mechanism for tunneling MPLS packets over
non-MPLS networks.
MPLS VPNL3VPN 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 VPNL3VPN 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 VPNL3VPN 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 routers 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 VPNL3VPN 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 VPNL3VPN over GRE Tunnel Interface, page 4 (required)
Configuring the MPLS VPNL3VPN over GRE Tunnel Interface

To configure the MPLS VPNL3VPN 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 VPNL3VPN over GRE feature, ensure that your MPLS VPN and the
appropriate routing protocols are configured and working properly. See the Prerequisites for MPLS
VPNL3VPN over GRE section on page 2.
SUMMARY STEPS
1. enable
3. interface tunnel tunnel-number
4. ip route prefix mask {ip-address | interface-type interface-number [ip-address]} [dhcp] [distance]
[name next-hop-name] [permanent | track number] [tag tag]
5. tunnel source source-address
6. tunnel destination destination-address
4
7. mpls ip
8. exit
9. show ip route
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 route prefix mask {ip-address | Configures a static route to the BGP neighbor on the SIP 2
interface-type interface-number [ip-address]} interface or tunnel interface.
[dhcp] [distance] [name next-hop-name]
[permanent | track number] [tag tag]
Example:
Router(config-if)# ip route 209.165.200.253
255.255.255.224 FastEthernet 0/0
Step 5 tunnel source source-address Specifies the tunnels source IP address.
Example:
Router(config-if)# tunnel source
209.165.200.254
Step 6 tunnel destination destination-address Specifies the tunnels destination IP address.
Example:
209.165.200.255
Step 7 mpls ip Enables MPLS on the tunnels physical interface.
Example:
5
Configuration Examples for MPLS VPNL3VPN over GRE

Step 8 exit Exits the interface configuration mode.
Example:
Step 9 show ip route Displays the unicast routes and configures a static route
globally or on the tunnel.
Example:
Router(config)# show ip route
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)# tunnel source 209.165.200.254
PE2 Configuration
Router(config-if)# tunnel source 209.165.200.240

This section provides the following configuration example for the MPLS VPNL3VPN over GRE
feature:
MPLS Configuration with MPLS VPNL3VPN over GRE: Example, page 6
Display of Unicast Routes: Example, page 8
MPLS Configuration with MPLS VPNL3VPN 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
6
rd 100:1
!
ip address 209.165.200.225 255.255.255.224
!
interface GigabitEthernet 0/1/2
ip address 209.165.200.226 255.255.255.224
!
interface Tunnel 1
ip address 209.165.200.227 255.255.255.224
tunnel source 209.165.200.228
mpls ip
!
ip address 209.165.200.230 255.255.255.224
!
router bgp 100
neighbor 209.165.200.231 update-source loopback0
!
neighbor 209.165.200.232 send community-extended
!
!
PE2 Configuration
!
mpls ip
!
ip vrf vpn1
rd 100:1
!
ip address 209.165.200.240 255.255.255.224
!
ip address 209.165.200.241 255.255.255.224
!
interface Tunnel 1
ip address 209.165.200.244 255.255.255.224
tunnel source 209.165.200.245
mpls ip
!
ip address 209.165.200.249 255.255.255.224
!
router bgp 100
neighbor 209.165.200.252 update-source loopback0
!
7

neighbor 209.165.200.254 send community-extended
!
Display of Unicast Routes: Example

The following example shows the display of unicast routes. This display shows the next hop for the BGP
neighbor depending on the selected interface.
Router# show ip route
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

O 209.165.200.226 [110/3] via 209.165.200.250, 00:09:55, POS2/0/0
O 209.165.200.231 [110/2] via 209.165.200.232, 00:09:55, POS2/0/0
S 209.165.200.240/8 [1/0] via 209.165.200.252
S 209.165.200.247 is directly connected, POS2/0/0
O 209.165.200.248 [110/3] via 209.165.200.249, 00:09:55, POS2/0/0
C 209.165.200.254/8 is directly connected, POS2/0/0
8
The following sections provide references related to the MPLS VPNL3VPN over GRE feature.
Related Documents
Setting up MPLS VPN networks Configuring MPLS Layer 3 VPNs
Multiprotocol Border Gateway Protocol (MP-BGP)
Label Distribution Protocol MPLS Label Distribution Protocol Overview
Configuring L3 VPN over mGRE Tunnels Dynamic Layer-3 VPNs with Multipoint GRE Tunnels
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
None
9
Description Link
10
Feature Information for MPLS VPNL3VPN over GRE

Table 1 Feature Information for MPLS VPNL3VPN over GRE

MPLS VPNL3VPN over GRE feature 12.0(22)S The MPLS VPNL3VPN over GRE feature
12.2(13)T provides a mechanism for tunneling Multiprotocol
12.0(26)S Label Switching (MPLS) packets over a non-MPLS
12.2(33)SRE network.
coincidental.
11
12
Dynamic Layer 3 VPNs with Multipoint GRE
Tunnels

The Dynamic Layer 3 VPNs with Multipoint GRE Tunnels feature provides a Layer-3 (L3) transport
mechanism based on an enhanced multipoint generic routing encapsulation (mGRE) tunneling
technology for use in IP networks. The dynamic Layer-3 tunneling transport can also be used within IP
networks to transport Virtual Private Network (VPN) traffic across service provider and enterprise
networks, and to provide interoperability for packet transport between IP and Multiprotocol Label
Switching (MPLS) VPNs. This feature provides support for RFC 2547, which defines the outsourcing
of IP backbone services for enterprise networks.

supported, see the Feature Information for Dynamic L3 VPNs with mGRE Tunnels section on page 24.
Contents
Prerequisites for Dynamic L3 VPNs with mGRE Tunnels, page 2
Restrictions for Dynamic L3 VPNs with mGRE Tunnels, page 2
Information About Dynamic L3 VPNs with mGRE Tunnels, page 2
How to Configure L3 VPN mGRE Tunnels, page 7
Configuration Examples for Dynamic L3 VPNs Support Using mGRE Tunnels, page 20
Dynamic Layer 3 VPNs with Multipoint GRE Tunnels
Prerequisites for Dynamic L3 VPNs with mGRE Tunnels

Feature Information for Dynamic L3 VPNs with mGRE Tunnels, page 24
Prerequisites for Dynamic L3 VPNs with mGRE Tunnels

Before you configure the Dynamic Layer 3 VPNs with Multipoint GRE Tunnels feature, ensure that your
MPLS VPN is configured and working properly. See the Configuring MPLS Layer 3 VPNs module
for information about setting up MPLS VPNs.
Restrictions for Dynamic L3 VPNs with mGRE Tunnels

MPLS VPN over mGRE is supported on the Cisco 7600 series routers using the ES-40 line card and
the SIP 400 line card as core facing cards.
Tunnelled tag traffic must enter the router through a line card, which supports MPLS VPN over
mGRE. The supported line cards are the ES-40 and the SIP-400.
The deployment of MPLS VPN using both IP/GRE and MPLS encapsulation within a single network
is not supported.
Each provider edge (PE) router supports one tunnel configuration only.
MPLS VPN of mGRE does not support the transportation of multicase traffic between VPNs.
MPLS VPN over mGRE supports a maximum of 4,000 tunnel endpoints per tunnel instance.
However, hardware limitations may reduce the number of tunnel endpoints.
Information About Dynamic L3 VPNs with mGRE Tunnels

You can configure mGRE tunnels to create a multipoint tunnel network that overlays an IP backbone.
This overlay connects PE routers to transport VPN traffic.
In addition, when MPLS VPNs are configured over mGRE you can deploy L3 PE-based VPN services
using a standards based IP core. This allows you to provision the VPN services without using the overlay
method. When MPLS VPN over mGRE is configured, the system uses IPv4-based mGRE tunnels to
encapsulate VPN-labeled IPv4 and IPv6 packets between PEs.
This section contains information on the following:
Layer 3 mGRE Tunnels, page 2
MPLS VPN over mGRE, page 4
Layer 3 mGRE Tunnels

By configuring mGRE tunnels, you create a multipoint tunnel network as an overlay to the IP backbone.
This overlay interconnects the PE routers to transport VPN traffic through the backbone. This multipoint
tunnel network uses Border Gateway Protocol (BGP) to distribute VPNv4 routing information between
PE routers maintaining the peer relationship between the service provider or enterprise network and
customer sites. The advertised next hop in BGP VPNv4 triggers tunnel endpoint discovery. This feature
2
provides the ability for multiple service providers to cooperate and offer a joint VPN service with traffic
tunneled directly from the ingress PE router at one service provider directly to the egress PE router at a
different service provider site.
In addition to providing the VPN transport capability, the mGRE tunnels create a full-mesh topology and
reduce the administrative and operational overhead previously associated with a full mesh of
point-to-point tunnels used to interconnect multiple customer sites. The configuration requirements are
greatly reduced and enables the network to grow with minimal additional configuration.
Dynamic L3 tunnels provide for better scaling when creating partial-mesh or full-mesh VPNs. Adding
new remote VPN peers is simplified because only the new router needs to be configured. The new
address is learned dynamically and propagated to the nodes in the network. The dynamic routing
capability dramatically reduces the size of configuration needed on all routers in the VPN, such that with
the use of multipoint tunnels, only one tunnel interfaced needs to be configured on a PE that services
many VPNs. The L3 mGRE tunnels need to be configured only on the PE router. Features available with
GRE are still available with mGRE, including dynamic IP routing and IP multicast and Cisco Express
Forwarding (CEF) switching of mGRE/Next Hop Routing Protocol (NHRP) tunnel traffic.
The following sections describe how the mGRE tunnels are used:
Interconnecting Provider Edge Routers Within an IP Network, page 3
Packet Transport Between IP and MPLS Networks, page 4
BGP Next Hop Verification, page 4
Interconnecting Provider Edge Routers Within an IP Network

The Dynamic Layer 3 VPNs with Multipoint GRE Tunnels feature allows you to create a multi access
tunnel network to interconnect the PE routers servicing your IP network. This tunnel network transports
IP VPN traffic to all of the PE routers. Figure 1 illustrates the tunnel overlay network used in an IP
network to transport VPN traffic between the PE routers.
Figure 1 mGRE Tunnel Overlay Connecting PE Routers within an IP Network
PE A PE B
IP mGRE
Tunnel Overlay
PE C PE D
IP Transport Network
82872
3
The multi access tunnel overlay network provides full connectivity between PE routers. The PE routers
exchange VPN routes using BGP as defined in RFC 2547. IP traffic is redirected through the multipoint
tunnel overlay network using distinct IP address spaces for the overlay and transport networks and by
changing the address space instead of changing the numerical value of the address.
Packet Transport Between IP and MPLS Networks

Layer 3 mGRE tunnels can be used as a packet transport mechanism between IP and MPLS networks.
To enable the packet transport between the two different protocols, one PE router on one side of the
connection between the two networks must run MPLS. Figure 2 shows how mGRE tunnels can be used
to transport VPN traffic between PE routers.
Figure 2 mGRE Used to Transport VPN Traffic Between IP and MPLS Network
Customer
mGRE key for Customer A's VPN MPLS label for Customer A's VPN A's VPN
Only mGRE is configured Both mGRE and MPLS are configured
CE
mGRE or MPLS VPN
CE
Customer
A's VPN PE G M PE
IP Network MPLS Network

CE PE
Customer
B's VPN
PE PE
CE PE
82873
Customer
A's VPN
Customer
CE B's VPN
CE Customer
Customer C's VPN
B's VPN
For the packet transport to occur between the IP and MPLS network, the MPLS VPN label is mapped to
the GRE key. The mapping takes place on the router where both mGRE and MPLS are configured. In
Figure 2 the mapping of the label to the key occurs on Router M, which sits on the MPLS network.
BGP Next Hop Verification

BGP performs the BGP path selection, or next hop verification, at the PE. For a BGP path to a network
to be considered in the path selection process, the next hop for the path must be reachable in the Interior
Gateway Protocol (IGP). When an IP prefix is received and advertised as the next hop IP address, the IP
traffic is tunneled from the source to the destination by switching the address space of the next hop.
MPLS VPN over mGRE

GRE is a point-to-point tunneling protocol where two peers form the endpoints of the tunnel. It is
designed to encapsulate network-layer packets inside IP tunneling packets. mGRE is a similar protocol
with a single endpoint at one side of the tunnel connected to multiple endpoints at the other side of the
4
tunnel. The mGRE tunnel provides a common link between branch offices that connect to the same VPN.
As GRE requires a full mesh topology, mGRE uses a point-to-multipoint topology and therefore requires
fewer tunnels.
MPLS is a widely deployed VPN internet architecture. MPLS requires that all core routers in the network
support MPLS. This feature is useful in networks where the service provider uses a backbone carrier to
provide connectivity.
MPLS VPN over mGRE is a feature that overcomes the requirement of the carrier supporting MPLS, by
allowing you to provide MPLS connectivity between networks that are connected by IP-only networks.
This allows MPLS label switch paths (LSPs) to use GRE tunnels to cross routing areas, autonomous
systems and Internet service providers (ISPs).
When MPLS VPNs are configured over mGRE you can deploy L3 Provider Edge (PE) based VPN
services using a standards-based IP core. This allows you to provision the VPN services without using
LSP or a Label Distribution Protocol (LDP). The system uses IPv4-based mGRE tunnels to encapsulate
VPN-labeled IPv4 and IPv6 packets between PEs.
The MPLS VPN over mGRE feature also allows you to deploy existing MPLS VPN LSP-encapsulated
technology concurrently with MPLS VPN over mGRE and enables the system to determine which
encapsulation method is used to route specific traffic. The ingress PE router determines which
encapsulation technology to use when transmitting a packet to the remote PE router.
This section includes information on the following topics:
Route Maps, page 6
Tunnel Endpoint Discovery and Forwarding, page 6
Tunnel Decapsulation, page 6
Tunnel Source, page 6
IPv6 VPN, page 7
5
Route Maps
By default, VPN traffic is sent using an LSP. The MPLS VPN over mGRE feature uses user-defined
route-maps to determine which VPN prefixes are reachable over an mGRE tunnel and which VPN
prefixes are reachable using an LSP. The route map is applied to advertisements for VPNv4 and VPNv6
address families. The route map uses a NextHOP Tunnel Table to determine the encapsulation method
for the VPN traffic.
To route traffic over the mGRE tunnel, the system creates an alternative address space that shows that
all next hops are reached by encapsulating the traffic in an mGRE tunnel. To configure a specific route
to use an mGRE tunnel, the user adds an entry for that route to the route map. The new entry remaps the
Network Layer Reachability Information (NLRI) of the route to the alternative address space. If there is
no remap entry in the route map for a route, then traffic on that route is forwarded over an LSP.
When the user configures MPLS VPN over mGRE, the system automatically provisions the alternative
address space, normally held in the tunnel-encapsulated virtual routing and forwarding (VRF) instance.
To ensure that all traffic reachable through the address space is encapsulated in an mGRE tunnel, the
system installs a single default route out of a tunnel. The system also creates a default tunnel on the route
map. The user can attach this default route map to the appropriate BGP updates.
Tunnel Endpoint Discovery and Forwarding

In order for MPLS VPN over mGRE to function correctly, the system must be able to discover the remote
PEs in the system and construct tunnel forwarding information for these remote PEs. In addition the
system must be able to detect when a remote PE is no longer valid and remove the tunnel forwarding
information for that PE.
If an ingress PE receives a VPN advertisement over BGP, it uses the route target attributes (which it
inserts into the VRF) and the MPLS VPN label from the advertisement, to associate the prefixes with
the appropriate customer. The next hop of the inserted route is set to the NLRI of the advertisement.
The advertised prefixes contain information about remote PEs in the system (in the form of NLRIs), and
the PE uses this information to notify the system when an NLRI becomes active or inactive. The system
uses this notification to update the PE forwarding information.
When the system receives notification of a new remote PE, it adds the information to the Tunnel
Endpoint Database, which causes the system to create an adjacency associated with the tunnel interface.
The adjacency description includes information on the encapsulation and other processing that the
system must perform to send encapsulated packets to the new remote PE.
The adjacency information is placed into the tunnel encapsulated VRF. When a user remaps a VPN NLRI
to a route in the VRF (using the route map) the system links the NLRI to the adjacency, therefore the
VPN is linked to a tunnel.
Tunnel Decapsulation
When the egress PE receives a packet from a tunnel interface that uses MPLS VPN over mGRE, the PE
decapsulates the packet to create a VPN label tagged packet, and sends the packet to the MPLS
forwarding (MFI) code.
Tunnel Source
MPLS VPN over mGRE uses a single tunnel configured as a multi point GRE tunnel to configure a
system with a large number of endpoints (remote PEs). To identify the origin of tunnel-encapsulated
packets, the system uses the tunnel source information.
6
How to Configure L3 VPN mGRE Tunnels
At the transmitting (ingress) PE, when a VPN packet is sent to a tunnel, the tunnel destination is the
NLRI. At a receiving (egress) PE, the tunnel source is the address that the packets encapsulated in the
mGRE tunnel are received on. Therefore, at the egress PE the packet destination must match the NLRI
from the local PE.
IPv6 VPN
If the advertising PE router has an IPv6 address then the NLRI must also be an IPv6 address (regardless
of the network between the PEs). If the network between the PEs is IPv4 based, the system creates the
IPv6 address of the advertising PE using an IPv4 mapped address in the following form:
::FFFF:IPv4-PE-address. The receiving PE sets the next hop for the VPN tag IPv6 prefixes to the IPv4
address embedded in the IPv6 NLRI. This enables the PE to link VPNv6 traffic to an LSP or an mGRE
tunnel in the same way it maps VPNv4 traffic.
When a PE receives VPNv6 updates it applies the IPv6 route map. MPLS VPN over mGRE uses the IPv6
route map to set the next hop information in the Tunnel_Encap VRF.

To deploy L3 VPN mGRE tunnels you create a VRF instance, create the mGRE tunnel, redirect the VPN
IP traffic to the tunnel, and set up the BGP VPNv4 exchange so that updates are filtered through a route
map and interesting prefixes are resolved in the VRF table.
To deploy MPLS VPN over mGRE tunnels, you create a VRF instance, enable and configure L3 VPN
encapsulation, link the route map to the application template, and set up the BGP VPNv4 and VPNv6
exchange so that updates are filtered through the route map.
The configuration steps to deploy MPLS VPN over mGRE are described in the following sections:
Creating the VRF and mGRE Tunnel, page 7 (Required)
Setting Up BGP VPN Exchange, page 9 (Required)
Enabling the MPLS VPN over mGRE Tunnels and Configuring L3VPN Encapsulation Profile,
page 11 (Required)
Defining the Address Space and Specifying Address Resolution for MPLS VPNs over mGRE,
page 14 (Required)
Creating the VRF and mGRE Tunnel

The tunnel that transports the VPN traffic across the service provider network resides in its own address
space. A special VRF instance must be created called Resolve in VRF (RiV). This section describes how
to create the VRF and GRE tunnel.
Prerequisites
The IP address on the interface should be the same as that of the source interface specified in the
configuration. The source interface specified should match that used by BGP as a source for the VPNv4
update.
7
SUMMARY STEPS
1. enable
3. ip vrf vrf-name
4. rd 1:1
5. interface tunnel tunnel name
6. ip address ip-address subnet-id
7. tunnel source loopback n
8. tunnel mode gre multipoint l3vpn
9. tunnel key gre-key
10. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip vrf vrf-name Creates the special Resolve in VRF (RiV) VRF instance and
table that will be used for the tunnel and redirection of the
IP address.
Example:
Router(config)# ip vrf customer a riv
Step 4 rd 1:1 Enters the VRF configuration mode and specifies a route
distinguisher (RD) for a VPN VRF instance.
Example:
Step 5 interface tunnel tunnel name Enters interface configuration mode to create the tunnel.
Example:
Router(config-vrf)# interface tunnel 1
Step 6 ip address ip-address subnet-id Specifies the IP address for the tunnel.
Example:
Router(config-if)# ipaddress 209.165.200.225
255.255.255.224
8

Step 7 tunnel source loopback n Creates the loopback interface.
Example:
Router(config-if)# tunnel source loopback test1
Step 8 tunnel mode gre multipoint l3vpn Sets the mode for the tunnel as gre multipoint l3vpn.
Example:
Router(config-if)# tunnel mode gre multipoint
l3vpn
Step 9 tunnel key gre-key Specifies the GRE key for the tunnel.
Example:
Router(config-if)# tunnel key 18
Example:
Setting Up BGP VPN Exchange

The configuration task described in this section sets up the BGP VPNv4 exchange so that the updates
are filtered through a route map and interesting prefixes are resolved in the VRF table.
SUMMARY STEPS
1. enable
3. interface tunnel tunnel name
4. ip route vrf riv-vrf-name IP address subnet mask tunnel n
6. network network id
8. neighbor {ip-address | peer-group-name} update-source interface-type
11. neighbor {ip-address | peer-group-name} route-map map-name {in | out}
12. set ip next-hop resolve-in-vrf vrf name
13. end
9
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface tunnel tunnel name Enters interface configuration mode for the tunnel.
Example:
Step 4 ip route vrf riv-vrf-name ip address subnet Sets the packet forwarding to the special RiV VRF.
mask tunnel n
Example:
Router(config-if)# ip route vrf 209.165.200.226
255.255.255.224 tunnel 1
Step 5 router bgp as-number Specifies the number of an autonomous system that
identifies the router to other BGP routers and tags the
routing information passed along.
Example:
Step 6 network network id Specifies the network ID for the networks to be advertised
by the BGP and multiprotocol BGP routing processes.
Example:
Router(config)# network 209.165.200.255
Example:
Router(config)# neighbor 209.165.200.227
remote-as 100
Step 8 neighbor {ip-address | peer-group-name} Specifies a specific operational interface that BGP sessions
update-source interface-type use for TCP connections.
Example:
update-source FastEthernet0/1
Step 9 address-family vpnv4 [unicast] Specifies address family configuration mode for
configuring routing sessions, such as BGP, that use standard
VPN4 address prefixes.
Example:
Router(config)# address-family vpnv4
10

activate router.
Example:
activate
Step 11 neighbor {ip-address | peer-group-name} Applies a route map to incoming or outgoing routes.
route-map map-name {in | out}
Use once for each inbound route.
Example:
route-map mpt in
Step 12 set ip next-hop resolve-in-vrf vrf name Specifies that the next hop is to be resolved in the VRF table
for the specified VRF.
Example:
Router(config)# set ip next-hop resolve-in-vrf
vrft
Example:
Router(config)# end
Enabling the MPLS VPN over mGRE Tunnels and Configuring L3VPN
Encapsulation Profile
This section describes how to define the VRF, enable MPLS VPN over mGRE, and configure an L3VPN
encapsulation profile.
Note Transport protocols such as IPv6, MPLS, IP, and Layer 2 Tunneling Protocol version 3 (L2TPv3) can
also be used in this configuration.
Prerequisites
To enable and configure MPLS VPN over mGRE you must first define the VRF for tunnel encapsulation
and enable L3VPN encapsulation in the system.
SUMMARY STEPS
1. enable
4. rd 1:1
11
5. exit
6. ip cef
7. ipv6 unicast-routing
8. ipv6 cef
9. l3vpn encapsulation ip profile name
10. transport ipv4 [source interface n]
11. protocol gre [key gre-key]
12. exit
14. ip address ip-address mask
15. ip router isis
16. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 vrf definition vrf-name Configures a VPN VRF routing table instance and enters
VRF configuration mode.
Example:
Router(config)# vrf definition tunnel encap
Step 4 rd 1:1 Specifies an RD for a VPN VRF instance.
Example:
Step 5 exit Exits VRF configuration mode.
Example:
Step 6 ip cef Enables Cisco Express Forwarding on the router.
Example:
12

Step 7 ipv6 unicast-routing Enables the forwarding of IPv6 unicast datagrams.
Example:
Router(config)# ipv6 unicast-routing
Step 8 ipv6 cef Enables Cisco Express Forwarding for IPv6 on the router.
Example:
Router(config)# ipv6 cef
Step 9 l3vpn encapsulation ip profile name Enters L3 VPN encapsulation configuration mode to create
the tunnel.
Example:
Router(config)# l3vpn encapsulation ip tunnel
encap
Step 10 transport ipv4 source interface n Specifies IPv4 transport source mode and defines the
transport source interface.
Example:
Router(config-l3vpn-encap-ip)# transport ipv4
source loopback 0
Step 11 protocol gre [key gre-key] Specifies GRE as the tunnel mode and sets the GRE key.
Example:
Router(config-l3vpn-encap-ip)# protocol gre key
1234
Step 12 exit Exits L3 VPN encapsulation configuration mode.
Example:
Router(config-l3vpn-encap-ip)# exit
Step 13 interface type number Enters interface configuration mode to configure the
interface type.
Example:
Router(config)# interface loopback 0
Step 14 ip address ip-address mask Specifies the primary IP address and mask for the interface.
Example:
255.255.255.255
Step 15 ip router isis Configures an Intermediate System-to-Intermediate System
(IS-IS) routing process for IP on the interface and attaches
a null area designator to the routing process.
Example:
Example:
Router(config-if)#end
13
Defining the Address Space and Specifying Address Resolution for MPLS VPNs
over mGRE
This section describes how to define the address space and specify the address resolution for MPLS
VPNs over mGRE. The following steps also enables you to link the route map to the application template
and sets up the BGP VPNv4 and VPNv6 exchange so that updates are filtered through the route map.
SUMMARY STEPS
1. enable
5. neighbor ip-address remote-as as-number
6. neighbor ip-address update-source interface name
7. address-family ipv4
9. redistribute connected
11. no auto-summary
12. exit
15. neighbor ip-address send-community both
16. neighbor ip-address route-map map-name in
17. exit
20. neighbor ip-address send-community both
21. neighbor ip-address route-map map-name in
22. exit
23. route-map map-tag permit position
24. set ip next-hop encapsulate l3vpn profile name
25. set ipv6 next-hop encapsulate l3vpn profile name
26. exit
27. exit
14
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Specifies the number of an autonomous system that
identifies the router to other BGP routers and tags the
routing information passed along and enters router
Example:
Router (config)# router bgp 100
configuration mode.
Example:
Router (config-router)# bgp
log-neighbor-changes
Step 5 neighbor ip-address remote-as as-number Adds an entry to the BGP or multiprotocol BGP neighbor
table.
Example:
Router (config-router)# neighbor 10.10.10.6
remote-as 100
Step 6 neighbor ip-address update-source interface Allows BGP sessions to use any operational interface for
name TCP connections.
Example:
Router (config-router)# neighbor 10.10.10.6
update-source loopback 0
Step 7 address-family ipv4 Enters address family configuration mode to configure
routing sessions, that use IPv4 address prefixes.
Example:
Router (config-router)# address-family vpnv4
Step 8 no synchronization Enables the Cisco IOS software to advertise a network route
without waiting for an IGP.
Example:
Router (config-router-af)# no synchronization
Step 9 redistribute connected Redistributes routes from one routing domain into another
routing domain and allows the target protocol to redistribute
routes learned by the source protocol and connected
Example:
Router (config-router-af)# redistribute
prefixes on those interfaces over which the source protocol
connected is running.
15

Step 10 neighbor ip-address activate Enables the exchange of information with a BGP neighbor.
Example:
Router (config-router-af)# neighbor 10.10.10.6
activate
Step 11 no auto-summary Disables automatic summarization and sends subprefix
routing information across classful network boundaries
Example:
Router (config-router-af)# no auto-summary
Step 12 exit Exits address family configuration mode.
Example:
Router (config-router-af)# exit
Step 13 address-family vpnv4 Enters address family configuration mode to configure
address prefixes.
Example:
Example:
activate
Step 15 neighbor ip-address send-community both Specifies that a communities attribute, for both standard and
extended communities, should be sent to a BGP neighbor.
Example:
send-community both
Step 16 neighbor ip-address route-map map-name in Applies the named route map to the incoming route.
Example:
route-map SELECT UPDATE FOR L3VPN in
Example:
Step 18 address-family vpnv6 Enters address family configuration mode to configure
routing sessions, such as BGP, that use VPNv6 address
prefixes.
Example:
Example:
Router (config-router-af)# neighbor
209.165.200.252 activate
16

Step 20 neighbor ip-address send-community both Specifies that a communities attribute, for both standard and
extended communities, should be sent to a BGP neighbor.
Example:
209.165.200.252 send-community both
Step 21 neighbor ip-address route-map ip-address in Applies the named route map to the incoming route.
Example:
209.165.200.252 route-map SELECT UPDATE FOR
L3VPN in
Example:
Step 23 route-map map-tag permit position Enters route-map configuration mode and defines the
conditions for redistributing routes from one routing
protocol into another.
Example:
Router (config-router)# route-map SELECT UPDATE The redistribute router configuration command uses
FOR L3VPN permit 10 the specified map tag to reference this route map.
Multiple route maps may share the same map tag name.
If the match criteria are met for this route map, the route
is redistributed as controlled by the set actions.
If the match criteria are not met, the next route map
with the same map tag is tested. If a route passes none
of the match criteria for the set of route maps sharing
the same name, it is not redistributed by that set.
The position argument indicates the position a new
route map will have in the list of route maps already
configured with the same name.
Step 24 set ip next-hop encapsulate l3vpn tunnel encap Indicates that output IPv4 packets that pass a match clause
of the route map are sent to the VRF for tunnel
encapsulation.
Example:
Router (config-route-map)# set ip next-hop
encapsulate l3vpn my profile
Step 25 set ipv6 next-hop encapsulate l3vpn profile Indicates that output IPv6 packets that pass a match clause
name of the route map are sent to the VRF for tunnel
encapsulation.
Example:
Router (config-route-map)# set ip next-hop
encapsulate l3vpn tunnel encap
17

Step 26 exit Exits route-map configuration mode and enters global
configuration mode.
Example:
Router (config-route-map)# exit
Example:
Router (config)# exit
What to Do Next
You can perform the following to make sure that the configuration is working properly.
Check the VRF Prefix

Verify that the specified VRF prefix has been received by BGP. The BGP table entry should show that
the route map has worked and that the next hop is showing in the RiV. Use the show ip bgp vpnv4
command as shown in this example:
Router# show ip bgp vpnv4 vrf customer 209.165.200.250
Paths: (1 available, best #1)
Local
209.165.200.251 in "my riv" from 209.165.200.251 (209.165.200.251)
Confirm that the same information has been propagated to the routing table:
Router# show ip route vrf customer 209.165.200.250
Known via "bgp 100", distance 200, metric 0, type internal
* 209.165.200.251 (my riv), from 209.165.200.251, 00:23:07 ago
AS Hops 0
CEF Switching
You can also verify that CEF switching is working as expected:
Router# show ip cef vrf customer 209.165.200.250
209.165.200.250/24, version 6, epoch 0
0 packets, 0 bytes
tag information set
local tag: VPN-route-head
fast tag rewrite with Tu1, 123.1.1.2, tags imposed: {17}
via 209.165.200.251, 0 dependencies, recursive
next hop 209.165.200.251, Tunnel1 via 209.165.200.251/32 (my riv)
valid adjacency
tag rewrite with Tu1, 209.165.200.251, tags imposed: {17}
18
Endpoint Creation
Note that in this example display the tunnel endpoint has been created correctly:
Router# show tunnel endpoint tunnel 1
Tunnel1 running in multi-GRE/IP mode
RFC2547/L3VPN Tunnel endpoint discovery is active on Tu1
Transporting l3vpn traffic to all routes recursing through "my riv"
Endpoint 209.165.200.251 via destination 209.165.200.251

Endpoint 209.165.200.254 via destination 209.165.200.254
Adjacency
Confirm that the corresponding adjacency has been created.
Router# show adjacency Tunnel 1 interface

Protocol Interface Address
TAG Tunnel1 209.165.200.251(4)
15 packets, 1980 bytes
4500000000000000FF2FC3C77B010103
7B01010200008847
Epoch: 0
Fast adjacency disabled
IP redirect disabled
IP mtu 1472 (0x0)
Fixup enabled (0x2)
GRE tunnel
Adjacency pointer 0x624A1580, refCount 4
Connection Id 0x0
Bucket 121
Note that because MPLS is being transported over mGRE, the LINK_TAG adjacency is the relevant
adjacency. The MTU reported in the adjacency is the payload length (including the MPLS label) that the
packet will accept.The mac string shown in the adjacency display can be interpreted as follows:
45000000 -> Beginning of IP Header (Partially populated, tl & chksum
00000000 are fixed up per packet)
FF2FC3C7
7B010103 -> Source IP Address in transport network 209.165.200.253
7B010102 -> Destination IP address in transport network 209.165.200.252
00008847 -> GRE Header
Refer to the Cisco IOS Multiprotocol Label Switching Configuration Guide for information about
configuring MPLS Layer 3 VPNs.
You can use show l3vpn encapsulation profile name command to get information on the basic state of
the application. The output of this command provides you details on the references to the tunnel and
VRF.
19
Configuration Examples for Dynamic L3 VPNs Support Using mGRE Tunnels
Configuration Examples for Dynamic L3 VPNs Support Using

mGRE Tunnels
This section provides an example to configure the layer 3 VPN over mGRE.
Configuring Layer 3 VPN mGRE Tunnels: Example, page 20
Configuring Layer 3 VPN mGRE Tunnels: Example

This example shows the configuration sequence for creating mGRE tunnels. It includes the definition of
the special VRF instance.
ip vrf my riv
rd 1:1
interface Tunnel1
ip vrf forwarding my_riv
ip address 209.165.200.250 255.255.255.224
tunnel source Loopback0
tunnel mode gre multipoint l3vpn
tunnel key 123
end
ip route vrf my riv ip address subnet mask Tunnel1
router bgp 100

network 209.165.200.251
!
neighbor 209.165.200.250 route-map SELECT_UPDATES_FOR_L3VPN_OVER_MGRE in
!
route-map SELECT UPDATES FOR L3VPN OVER MGRE permit 10
set ip next-hop in-vrf my riv
This example shows the configuration to link a route map to the application:
vrf definition Customer A
rd 100:110
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
vrf definition tunnel encap
rd 1:1
!
address-family ipv4
exit-address-family
!
address-family ipv6
exit-address-family
!
!
ip cef
20
Configuration Examples for Dynamic L3 VPNs Support Using mGRE Tunnels
!
ipv6 unicast-routing
ipv6 cef
!
!
l3vpn encapsulation ip profile name
transport source loopback 0
protocol gre key 1234
!
!
interface Loopback0
ip address 209.165.200.252 255.255.255.224
ip router isis
!
interface Serial2/0
vrf forwarding Customer A
ip address 209.165.200.253 255.255.255.224
ipv6 address 3FFE:1001::/64 eui-64
no fair-queue
!
router bgp 100
!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
neighbor 209.165.200.254 route-map SELECT UPDATE FOR L3VPN in
exit-address-family
!
neighbor 209.165.200.254 route-map SELECT UPDATE FOR L3VPN in
exit-address-family
!
address-family ipv4 vrf Customer A
no synchronization
exit-address-family
!
address-family ipv6 vrf Customer A
no synchronization
exit-address-family
!
!
route-map SELECT UPDATE FOR L3VPN permit 10
set ip next-hop encapulate <profile_name>
set ipv6 next-hop encapsulate <profile_name>
21
For additional information related to dynamic L3 VPN mGRE tunnels, refer to the following references:
Related Documents
Configuring MPLS Layer 3 VPNs Cisco IOS Multiprotocol Label Switching Configuration Guide
Cisco Express Forwarding Cisco IOS IP Switching Configuration Guide
Generic Routing Encapsulation Cisco IOS Interface and Hardware Component Configuration Guide
Standards
Standard Title
None
MIBs
MIB MIBs Link
IETF-PPVPN-MPLS-VPN-MIB To locate and download MIBs for selected platforms, Cisco IOS
following URL:
RFCs
RFC Title
RFC 2784 Generic Routing Encapsulation (GRE)
RFC 2890 Key Sequence Number Extensions to GRE
RFC 4023 Encapsulating MPLS in IP or Generic Routing Encapsulation
RFC 4364 BGP/MPLS IP Virtual Private Networks (VPNs)
22
Description Link
23
Feature Information for Dynamic L3 VPNs with mGRE Tunnels

features that were introduced or modified in Cisco IOS Release 12.0(23)S or a later release appear in the
table.
Table 1 Feature Information for Dynamic L3 VPNs with mGRE Tunnels

Dynamic Layer-3 VPNs (L3 VPNs) (RFC 2547 12.0(23)S This feature provides an L3 transport mechanism based on
based) with Multipoint GRE (mGRE) Tunnels an enhanced mGRE tunneling technology for use in IP
networks.
MPLS VPN over mGRE 12.2(33)SRE This feature provides support to carry MPLS Layer 3 VPN
traffic over mGRE. This feature also supports SIP400 and
ES40 on Cisco 7600 series routers.
feature:
Layer 3 mGRE Tunnels, page 2
MPLS VPN over mGRE, page 4
Creating the VRF and mGRE Tunnel, page 7
Setting Up BGP VPN Exchange, page 9
Enabling the MPLS VPN over mGRE Tunnels and
Configuring L3VPN Encapsulation Profile, page 11
Defining the Address Space and Specifying Address
Resolution for MPLS VPNs over mGRE, page 14
this feature: set ip next-hop, show tunnel endpoints,
tunnel mode, l3vpn encapsulation ip profile-name,
protocol gre key, transport ipv4 source interface.
24
25
26
MPLS Layer 3 VPNs: InterAutonomous
Systems and Carrier Supporting Carrier
MPLS VPN Inter-AS with ASBRs Exchanging
VPN-IPv4 Addresses

The MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses feature allows a Multiprotocol
Label Switching (MPLS) Virtual Private Network (VPN) to span service providers and autonomous
systems. This module explains how to enable Autonomous System Boundary Routers (ASBRs) to use
Exterior Border Gateway Protocol (EBGP) to exchange IPv4 Network Layer Reachability Information
(NLRI) in the form of VPN-IPv4 addresses.

supported, see the Feature Information for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4
Addresses section on page 33.
Contents
Prerequisites for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses, page 2
Restrictions for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses, page 3
Information About MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses, page 3
How to Configure MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses, page 11
Configuration Examples for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses,
page 16
MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
Prerequisites for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses

Feature Information for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses,
page 33
Prerequisites for MPLS VPN Inter-AS with ASBRs Exchanging

VPN-IPv4 Addresses
Before you configure EBGP routing between autonomous systems or subautonomous systems in an
MPLS VPN, ensure that you have properly configured all MPLS VPN routing instances and
sessions. The configuration tasks outlined in this section build from those configuration tasks.
Perform the following tasks as described in the Configuring MPLS Layer 3 VPNs module:
Define VPN routing instances
Configure BGP routing sessions in the MPLS core
Configure PE-to-PE routing sessions in the MPLS core
Configure BGP PE-to-CE routing sessions
Configure a VPN-IPv4 EBGP session between directly connected ASBRs
This feature is supported on the Cisco 12000 series router line cards listed in Table 1.
Table 1 Cisco 12000 Series Line Card Support Added for Cisco IOS Releases
Type Line Cards Cisco IOS Release Added

Packet over SONET (POS) 4-Port OC-3 POS 12.0(16)ST
1-Port OC-12 POS
8-Port OC-3 POS 12.0(17)ST
16-Port OC-3 POS
4-Port OC-12 POS
1-Port OC-48 POS
4-Port OC-3 POS ISE 12.0(22)S
8-Port OC-3 POS ISE
16 x OC-3 POS ISE
4-Port OC-12 POS ISE
Electrical interface 6-Port DS3 12.0(21)ST
12-Port DS3
6-Port E3 12.0(22)S
12-Port E3
Ethernet 3-Port GbE 12.0(23)S
1-Port 10-GbE 12.0(24)S
Modular GbE/FE
ATM 4-Port OC-3 ATM 12.0(16)ST
1-Port OC-12 ATM
4-Port OC-12 ATM 12.0(17)ST
8-Port OC-3 ATM 12.0(23)S
2
Restrictions for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
Table 1 Cisco 12000 Series Line Card Support Added for Cisco IOS Releases

Channelized interface 2-Port CHOC-3 12.0(22)S
6-Port Ch T3 (DS1)
1-Port CHOC-12 (DS3)
1-Port CHOC-12 (OC-3)
4-Port CHOC-12 ISE
1-Port CHOC-48 ISE
Restrictions for MPLS VPN Inter-AS with ASBRs Exchanging

VPN-IPv4 Addresses
Multihop VPN-IPv4 EBGP is not supported.
Information About MPLS VPN Inter-AS with ASBRs Exchanging

VPN-IPv4 Addresses
Before configuring this feature, you should understand the following concepts:
MPLS VPN Inter-AS Introduction, page 3
Benefits of MPLS VPN Inter-AS, page 3
Use of Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses, page 4
Information Exchange in an MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses,
page 4
MPLS VPN Inter-AS Introduction

An autonomous system is a single network or group of networks that is controlled by a common system
administration group and that uses a single, clearly defined routing protocol.
As VPNs grow, their requirements expand. In some cases, VPNs need to reside on different autonomous
systems in different geographic areas. Also, some VPNs need to extend across multiple service providers
(overlapping VPNs). Regardless of the complexity and location of the VPNs, the connection between
autonomous systems must be seamless to the customer.
Benefits of MPLS VPN Inter-AS

An MPLS VPN Inter-AS provides the following benefits:
Allows a VPN to cross more than one service provider backbone
Service providers running separate autonomous systems can jointly offer MPLS VPN services to the
same customer. A VPN can begin at one customer site and traverse different VPN service provider
backbones before arriving at another site of the same customer. Previously, MPLS VPN could
3
Information About MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
travers only e a single BGP autonomous system service provider backbone. This feature allows
multiple autonomous systems to form a continuous (and seamless) network between customer sites
of a service provider.
Allows a VPN to exist in different areas
A service provider can create a VPN in different geographic areas. Having all VPN traffic flow
through one point (between the areas) allows for better rate control of network traffic between the
areas.
Allows confederations to optimize IBGP meshing
Internal Border Gateway Protocol (IBGP) meshing in an autonomous system is more organized and
manageable. An autonomous system can be divided into multiple, separate subautonomous systems
and then classify them into a single confederation (even though the entire VPN backbone appears
as a single autonomous system). This capability allows a service provider to offer MPLS VPNs
across the confederation because it supports the exchange of labeled VPN-IPv4 NLRI between the
subautonomous systems that form the confederation.
Use of Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses

Separate autonomous systems from different service providers can communicate by exchanging IPv4
NLRI in the form of VPN-IPv4 addresses. The ASBRs use EBGP to exchange that information. Then an
Interior Gateway Protocol (IGP) distributes the network layer information for VPN-IPv4 prefixes
throughout each VPN and each autonomous system. Routing information uses the following protocols:
Within an autonomous system, routing information is shared using an IGP.
Between autonomous systems, routing information is shared using an EBGP. An EBGP allows a
service provider to set up an interdomain routing system that guarantees the loop-free exchange of
routing information between separate autonomous systems.
The primary function of an EBGP is to exchange network reachability information between autonomous
systems, including information about the list of autonomous system routes. The autonomous systems use
EGBP border edge routers to distribute the routes, which include label switching information. Each
border edge router rewrites the next hop and labels. See the Information Exchange in an MPLS VPN
Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses section for more information.
Interautonomous system configurations supported in an MPLS VPN are as follows:
Interprovider VPNMPLS VPNs that include two or more autonomous systems, connected by
separate border edge routers. The autonomous systems exchange routes using EBGP. No IGP or
routing information is exchanged between the autonomous systems.
BGP confederationsMPLS VPNs that divide a single autonomous system into multiple
subautonomous systems, and classify them as a single, designated confederation. The network
recognizes the confederation as a single autonomous system. The peers in the different autonomous
systems communicate over EBGP sessions; however, they can exchange route information as if they
were IBGP peers.
Information Exchange in an MPLS VPN Inter-AS with ASBRs Exchanging

VPN-IPv4 Addresses
4
Transmission of Information in an MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4

Addresses, page 5
Exchange of VPN Routing Information in an MPLS VPN Inter-AS with ASBRs Exchanging
VPN-IPv4 Addresses, page 6
Packet Forwarding Between MPLS VPN Inter-AS Systems with ASBRs Exchanging VPN-IPv4
Addresses, page 8
Use of a Confederation for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses,
page 9
Transmission of Information in an MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
Figure 1 illustrates one MPLS VPN consisting of two separate autonomous systems. Each autonomous
system operates under different administrative control and runs a different IGP. Service providers
exchange routing information through EBGP border edge routers (ASBR1, ASBR2).
Figure 1 EBGP Connection Between Two MPLS VPN Inter-AS Systems with ASBRs Exchanging
VPN-IPv4 Addresses
Service Provider 1 Service Provider 2

RR-1 RR-2
Core of P Core of P
routers routers
EBGP VPNv4
routes with label
distribution
PE-1 ASBR1 ASBR2 PE-2 PE-3
CE-1 CE-2 CE-5

VPN1
CE-3 CE-4
43877
VPN1
This configuration uses the following process to transmit information:
Step 1 The provider edge router (PE-1) assigns a label for a route before distributing that route. The PE router
uses the multiprotocol extensions of BGP to transmit label mapping information. The PE router
distributes the route as a VPN-IPv4 address. The address label and the VPN identifier are encoded as
part of the NLRI.
Step 2 The two route reflectors (RR-1 and RR-2) reflect VPN-IPv4 internal routes within the autonomous
system. The autonomous systems border edge routers (ASBR1 and ASBR2) advertise the VPN-IPv4
external routes.
5
Step 3 The EBGP border edge router (ASBR1) redistributes the route to the next autonomous system (ASBR2).
ASBR1 specifies its own address as the value of the EBGP next-hop attribute and assigns a new label.
The address ensures the following:
That the next-hop router is always reachable in the service provider (P) backbone network.
That the label assigned by the distributing router is properly interpreted. (The label associated with
a route must be assigned by the corresponding next-hop router.)
Step 4 The EBGP border edge router (ASBR2) redistributes the route in one of the following ways, depending
on its configuration:
If the IBGP neighbors are configured with the neighbor next-hop-self command, ASBR2 changes
the next-hop address of updates received from the EBGP peer, then forwards it.
If the IBGP neighbors are not configured with the neighbor next-hop-self command, the next-hop
address does not get changed. ASBR2 must propagate a host route for the EBGP peer through the
IGP. To propagate the EBGP VPN-IPv4 neighbor host route, use the redistribute connected
subnets command. The EBGP VPN-IPv4 neighbor host route is automatically installed in the
routing table when the neighbor comes up. This is essential to establish the label switched path
between PE routers in different autonomous systems.
Exchange of VPN Routing Information in an MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4
Addresses
Autonomous systems exchange VPN routing information (routes and labels) to establish connections.
To control connections between autonomous systems, the PE routers and EBGP border edge routers
maintain a Label Forwarding Information Base (LFIB). The LFIB manages the labels and routes that the
PE routers and EBGP border edge routers receive during the exchange of VPN information.
Figure 2 illustrates the exchange of VPN route and label information between autonomous systems. The
autonomous systems use the following conditions to exchange VPN routing information:
Routing information includes:
The destination network (N)
The next-hop field associated with the distributing router
A local MPLS label (L)
An RD1: route distinguisher is part of a destination network address. It makes the VPN-IPv4 route
globally unique in the VPN service provider environment.
The ASBRs are configured to change the next-hop (next hop-self) when sending VPN-IPv4 NLRIs
to the IBGP neighbors. Therefore, the ASBRs must allocate a new label when they forward the NLRI
to the IBGP neighbors.
6
Figure 2 Exchanging Routes and Labels Between MPLS VPN Inter-AS Systems with ASBRs
Exchanging VPN-IPv4 Addresses

RR-1 RR-2
Network = RD1:N Network = RD1:N
Next hop = PE-1 Next hop = ASBR2
Label = L1 Label = L3
Network = RD1:N
Core of P Next hop = ASBR2 Core of P
routers Label = L3 routers
Network = RD1:N
Next hop = PE-1
Label = L1
PE-1 PE-2 PE-3
ASBR1 ASBR2
Network = RD1:N
Next hop = ASBR1
Label = L2
Network = N
Next hop = CE-2 Network = N
Next hop = PE-3
43878
CE-1 CE-2 CE-3 CE-4 CE-5
VPN1 VPN1
Figure 3 illustrates the exchange of VPN route and label information between autonomous systems. The
only difference is that ASBR2 is configured with the redistribute connected command, which
propagates the host routes to all PEs. The redistribute connected command is necessary because
ASBR2 is not configured to change the next-hop address.
Figure 3 Exchanging Routes and Labels with the redistribute connected Command in an MPLS
VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses

RR-1 RR-2
Network = RD1:N Network = RD1:N
Next hop = PE-1 Next hop = ASBR1
Label = L1 Label = L2
Network = RD1:N
Core of P Next hop = ASBR1 Core of P
routers Label = L2 routers
Network = RD1:N
Next hop = PE-1
Label = L1
PE-1 PE-2 PE-3
ASBR1 ASBR2
Network = RD1:N
Next hop = ASBR1
Label = L2
Network = N
Next hop = CE-2 Network = N
Next hop = PE-3
CE-1 CE-2 CE-5

VPN1
48299
CE-3 CE-4
VPN1
7
Packet Forwarding Between MPLS VPN Inter-AS Systems with ASBRs Exchanging VPN-IPv4
Addresses
Figure 4 illustrates how packets are forwarded between autonomous systems in an interprovider network
using the following packet forwarding method.
Packets are forwarded to their destination by means of MPLS. Packets use the routing information stored
in the LFIB of each PE router and EBGP border edge router.
The service provider VPN backbone uses dynamic label switching to forward labels.
Each autonomous system uses standard multilevel labeling to forward packets between the edges of the
autonomous system routers (for example, from CE-5 to PE-3). Between autonomous systems, only a
single level of labeling is used, corresponding to the advertised route.
A data packet carries two levels of labels when traversing the VPN backbone:
The first label (IGP route label) directs the packet to the correct PE router or EBGP border edge
router. (For example, the IGP label of ASBR2 points to the ASBR2 border edge router.)
The second label (VPN route label) directs the packet to the appropriate PE router or EBGP border
edge router.
Figure 4 Forwarding Packets Between MPLS VPN Inter-AS Systems with ASBRs Exchanging
VPN-IPv4 Addresses
Service Provider 2
RR-1 RR-2 Network = N
Service Provider 1 IGP label = ASBR2
VPN label = L3
Core of P Core of P
Network = N Network = N
routers routers
IGP label = PE1 VPN label = L3
Network = N VPN label = L1
VPN label = L1 Network = RD1:N
PE-1 VPN label = L2 PE-2
ASBR1 ASBR2
PE-3
Network = RD1:N
Network = RD1:N
CE-1 CE-2 CE-5

VPN 1
43879
CE-3 CE-4
VPN 1
Figure 5 shows the same packet forwarding method as described in Figure 4, except the EBGP router
(ASBR1) forwards the packet without reassigning it a new label.
8
Figure 5 Forwarding Packets Without a New Label Assignment Between MPLS VPN Inter-AS
Systems with ASBRs Exchanging VPN-IPv4 Addresses
Service Provider 2
RR-1 RR-2 Network = N
Service Provider 1 IGP label = ASBR1
VPN label = L2
Core of P Core of P
routers Network = RD1:N Network = RD1:N
routers
IGP label = PE1 IGP label = ASBR1
Network = N VPN label = L1 VPN label = L2
VPN label = L1 Network = RD1:N
PE-1 VPN label = L2 PE-2
ASBR1 ASBR2
PE-3
Network = N
Network = N
CE-1 CE-2 CE-5

VPN 1
48300
CE-3 CE-4
VPN 1
Use of a Confederation for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
A confederation is multiple subautonomous systems grouped together. A confederation reduces the total
number of peer devices in an autonomous system. A confederation divides an autonomous system into
subautonomous systems and assigns a confederation identifier to the autonomous systems. A VPN can
span service providers running in separate autonomous systems or in multiple subautonomous systems
that form a confederation.
In a confederation, each subautonomous system is fully meshed with other subautonomous systems. The
subautonomous systems communicate using an IGP, such as Open Shortest Path First (OSPF) or
Intermediate System-to-Intermediate System (IS-IS). Each subautonomous system also has an EBGP
connection to the other subautonomous systems. The confederation EBGP (CEBGP) border edge routers
forward next-hop-self addresses between the specified subautonomous systems. The next-hop-self
address forces the BGP to use a specified address as the next hop rather than letting the protocol choose
the next hop.
You can configure a confederation with separate subautonomous systems in either of two ways:
You can configure a router to forward next-hop-self addresses between only the CEBGP border edge
routers (both directions). The subautonomous systems (IBGP peers) at the subautonomous system
border do not forward the next-hop-self address. Each subautonomous system runs as a single IGP
domain. However, the CEBGP border edge router addresses are known in the IGP domains.
You can configure a router to forward next-hop-self addresses between the CEBGP border edge
routers (both directions) and within the IBGP peers at the subautonomous system border. Each
subautonomous system runs as a single IGP domain but also forwards next-hop-self addresses
between the PE routers in the domain. The CEBGP border edge router addresses are known in the
IGP domains.
9
Note Figure 2 and Figure 3 illustrate how two autonomous systems exchange routes and forward packets.
Subautonomous systems in a confederation use a similar method of exchanging routes and forwarding
packets.
Figure 6 illustrates a typical MPLS VPN confederation configuration. In this confederation

configuration:
The two CEBGP border edge routers exchange VPN-IPv4 addresses with labels between the two
subautonomous systems.
The distributing router changes the next-hop addresses and labels and uses a next-hop-self address.
IGP-1 and IGP-2 know the addresses of CEBGP-1 and CEBGP-2.
Figure 6 EBGP Connection Between Two Subautonomous Systems in a Confederation

Sub-AS1 with Sub-AS2 with
IGP-1 IGP-2
Core of P Core of P
routers routers
eBGP intraconfederation
for VPNv4 routes with label
distribution
PE-1 PE-2 PE-3
CEGBP-1 CEBGP-2
CE-1 CE-2
CE-5
VPN 1 43880
CE-3 CE-4
VPN 1
In this confederation configuration:
CEBGP border edge routers function as neighboring peers between the subautonomous systems.
The subautonomous systems use EBGP to exchange route information.
Each CEBGP border edge router (CEBGP-1, CEBGP-2) assigns a label for the route before
distributing the route to the next subautonomous system. The CEBGP border edge router distributes
the route as a VPN-IPv4 address by using the multiprotocol extensions of BGP. The label and the
VPN identifier are encoded as part of the NLRI.
Each PE and CEBGP border edge router assigns its own label to each VPN-IPv4 address prefix
before redistributing the routes. The CEBGP border edge routers exchange VPN-IPv4 addresses
with the labels. The next-hop-self address is included in the label (as the value of the EBGP next-hop
attribute). Within the subautonomous systems, the CEBGP border edge router address is distributed
throughout the IBGP neighbors, and the two CEBGP border edge routers are known to both
confederations.
10
How to Configure MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
How to Configure MPLS VPN Inter-AS with ASBRs Exchanging

VPN-IPv4 Addresses
To configure MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses, perform the tasks in
the following sections:
Configuring the ASBRs to Exchange VPN-IPv4 Addresses, page 11 (required)
Configuring EBGP Routing to Exchange VPN Routes Between Subautonomous Systems in a
Confederation, page 12 (required)
Verifying Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses, page 15 (optional)
Configuring the ASBRs to Exchange VPN-IPv4 Addresses

To configure an EBGP ASBR to exchange VPN-IPv4 routes with another autonomous system, perform
this task.
Note Issue the redistribute connected subnets command in the IGP configuration portion of the router to
propagate host routes for VPN-IPv4 EBGP neighbors to other routers and provider edge routers.
Alternatively, you can specify the next-hop-self address when you configure IBGP neighbors.
SUMMARY STEPS
1. enable
4. no bgp default route-target filter
6. neighbor peer-group-name remote-as as-number
7. neighbor peer-group-name activate
9. end
DETAILED STEPS

Example:
Router> enable
Example:
11

Step 3 router bgp as-number Creates an EBGP routing process and assigns it an
autonomous system number.
Example: The autonomous system number is passed along and
Router(config)# router bgp 1 identifies the router to EBGP routers in another
autonomous system.
Step 4 no bgp default route-target filter Disables BGP route-target filtering and places the router in
configuration mode.
Example: All received BGP VPN-IPv4 routes are accepted by the
Router(config)# no bgp default route-target router.
filter
Step 5 address-family vpnv4 [unicast] Configures a routing session to carry VPNv4 addresses
across the VPN backbone and places the router in address
Example:
Router(config-router)# address-family vpnv4 Each address has been made globally unique by the
addition of an 8-byte route distinguisher (RD).
The unicast keyword specifies a unicast prefix.
Step 6 neighbor peer-group-name remote-as as-number Enters the address family configuration mode and specifies
a neighboring EBGP peer group.
Example: This EBGP peer group is identified to the specified
Router(config-router-af)# neighbor 1 remote-as autonomous system.
2
Step 7 neighbor peer-group-name activate Activates the advertisement of the VPNv4 address family to
a neighboring EBGP router.
Example:
Router(config-router-af)# neighbor 1 activate
Step 8 exit-address-family Exits from the address family submode of the router
configuration mode.
Example:
Example:
Router(config)# end
Configuring EBGP Routing to Exchange VPN Routes Between Subautonomous

Systems in a Confederation
Perform this task to configure EBGP routing to exchange VPN routes between subautonomous systems
in a confederation.
12
Note To ensure that the host routes for VPN-IPv4 EBGP neighbors are propagated (by means of the IGP) to
the other routers and provider edge routers, specify the redistribute connected command in the IGP
configuration portion of the CEBGP router. If you are using OSPF, make sure that the OSPF process is
not enabled on the CEBGP interface where the redistribute connected subnet exists.
Note In this confederation, subautonomous system IGP domains must know the addresses of CEBGP-1 and
CEBGP-2. If you do not specify a next-hop-self address as part of the router configuration, ensure that
the addresses of all PE routers in the subautonomous system are distributed throughout the network, not
just the addresses of CEBGP-1 and CEBGP-2.
SUMMARY STEPS
1. enable
3. router bgp sub-autonomous-system
4. bgp confederation identifier as-number
5. bgp confederation peers sub-autonomous-system
8. neighbor peer-group-name remote-as as-number
9. neighbor peer-group-name next-hop-self
10. neighbor peer-group-name activate
12. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp sub-autonomous-system Creates an EBGP routing process and assigns it an autonomous
system number and enters the router in configuration mode.
Example: The subautonomous system number is passed along to
Router(config)# router bgp 2 identify the router to EBGP routers in other subautonomous
systems.
13

Step 4 bgp confederation identifier as-number Defines an EBGP confederation by specifying a confederation
identifier associated with each subautonomous system.
Example: The subautonomous systems appear as a single autonomous
Router(config-router)# bgp confederation system.
identifier 100
Step 5 bgp confederation peers Specifies the subautonomous systems that belong to the
sub-autonomous-system confederation (identifies neighbors of other subautonomous
systems within the confederation as special EBGP peers).
Example:
Router(config-router)# bgp confederation
peers 1
Step 6 no bgp default route-target filter Disables BGP route-target community filtering. All received BGP
VPN-IPv4 routes are accepted by the router.
Example:
Router(config-router)# no bgp default
route-target filter
Step 7 address-family vpnv4 [unicast] Configures a routing session to carry VPNv4 addresses across the
VPN backbone. Each address is made globally unique by the
addition of an 8-byte RD. Enters address family configuration
Example:
Router(config-router)# address-family
mode.
vpnv4 The unicast keyword specifies a unicast prefix.
Step 8 neighbor peer-group-name remote-as Enters the address family configuration mode and specifies a
as-number neighboring EBGP peer group.
This EBGP peer group is identified to the specified
Example: subautonomous system.
Router(config-router-af)# neighbor 1
remote-as 1
Step 9 neighbor peer-group-name next-hop-self Advertises the router as the next hop for the specified neighbor.
If a next-hop-self address is specified as part of the router
Example: configuration, the redistribute connected command need
Router(config-router-af)# neighbor 1 not be used.
next-hop-self
Step 10 neighbor peer-group-name activate Activates the advertisement of the VPNv4 address family to a
neighboring PE router in the specified subautonomous system.
Example:
Router(config-router-af)# neighbor R
activate
Step 11 exit-address-family Exits from the address family submode of the router configuration
mode.
Example:
Router(config-router-af)#
exit-address-family
Example:
Router(config)# end
14
Verifying Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses

Perform this task to display the VPN-IPv4 LFIB entries.
SUMMARY STEPS
1. enable
2. show ip bgp vpnv4 {all | rd route-distinguisher | vrf vrf-name} [summary] [labels]
3. show mpls forwarding-table [network {mask | length} | labels label [-label] | interface interface |
4. disable
DETAILED STEPS

Example:
Router> enable
Step 2 show ip bgp vpnv4 {all | rd route-distinguisher Displays VPN address information from the BGP table.
| vrf vrf-name} [summary] [labels]
Use the all and labels keywords to display information
about all VPNv4 labels.
Example:
Step 3 show mpls forwarding-table [network { mask | Displays the contents of the MPLS LFIB (such as VPNv4
length} | labels label [-label] | interface prefix/length and BGP next-hop destination for the route).
[tunnel-id]] [vrf vrf-name] [detail]
Example:
Step 4 disable Exits to user EXEC mode.
Example:
Router# disable
Examples
The sample output from the show mpls forwarding-table command shows how the VPN-IPv4 LFIB
entries appear:
33 33 10.120.4.0/24 0 Hs0/0 point2point
35 27 100:12:10.200.0.1/32 \
0 Hs0/0 point2point
15
Configuration Examples for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
In this example, the Prefix field appears as a VPN-IPv4 RD, plus the prefix. If the value is longer than
the width of the Prefix column (as illustrated in the last line of the example), the output automatically
wraps onto the next line in the forwarding table, preserving column alignment.
Configuration Examples for MPLS VPN Inter-AS with ASBRs

This section provides the following configuration examples for MPLS VPN Inter-AS:
Configuring MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses: Example,
page 16
Configuring MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses in a
Confederation: Example, page 23
Configuring MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses:

Example
The network topology in Figure 7 shows two autonomous systems, which are configured as follows:
Autonomous system 1 (AS1) includes PE1, P1, and EBGP1. The IGP is OSPF.
Autonomous system 2 (AS2) includes PE2, P2, and EBGP2. The IGP is IS-IS.
CE1 and CE2 belong to the same VPN, which is called VPN1.
The P routers are route reflectors.
EBGP1 is configured with the redistribute connected subnets command.
EBGP2 is configured with the neighbor next-hop-self command.
Figure 7 Configuring Two Autonomous Systems
VPN1 VPN1
PE1 P1 P2 PE2
CE1 AS1 AS2 CE2

47866
EBGP1 EBGP2
Configuration for Autonomous System 1, CE1: Example

The following example shows how to configure CE1 in VPN1 in a topology with two autonomous
systems (see Figure 7):
CE1: Burlington
!
interface Loopback1
16
ip address aa.0.0.6 255.255.255.255

!
interface Serial1/3
description wychmere
no ip address
frame-relay intf-type dce
!
interface Serial1/3.1 point-to-point
ip address aa.6.2.1 255.255.255.252
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
Configuration for Autonomous System 1, PE1: Example

The following example shows how to configure PE1 in AS1 in a topology with two autonomous systems
(see Figure 7):
PE1: wychmere
!
ip cef
!
ip vrf V1
rd 1:105
!
interface Serial0/0
description Burlington
no ip address
no fair-queue
clockrate 2000000
!
ip address aa.6.2.2 255.255.255.252
!
description Vermont
ip address aa.2.2.5 255.255.255.0
tag-switching ip
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
!
router ospf 10 vrf V1
redistribute bgp 1 metric 100 subnets
network aa.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
neighbor 1 peer-group
neighbor 1 remote-as 1
neighbor 1 update-source Loopback0
17
neighbor aa.0.0.2 peer-group R

no auto-summary
!
address-family ipv4 vrf V1
redistribute ospf 10
no auto-summary
no synchronization
exit-address-family
!
neighbor R activate
neighbor R send-community extended
no auto-summary
exit-address-family
Configuration for Autonomous System 1, P1: Example

The following example shows how to configure P1 in AS1 in a topology with two autonomous systems
(see Figure 7):
P1: Vermont
!
ip cef
!
interface Loopback0
ip address aa.0.0.2 255.255.255.255
!
description Ogunquit
ip address aa.2.1.1 255.255.255.0
tag-switching ip
!
ip address aa.2.2.1 255.255.255.0
duplex auto
speed auto
tag-switching ip
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
neighbor R peer-group
neighbor R remote-as 1
neighbor R update-source Loopback0
neighbor R route-reflector-client
!
neighbor R activate
exit-address-family
18
Configuration for Autonomous System 1, EBGP1: Example

The following example shows how to configure EBGP1 in AS1 in a topology with two autonomous
EBGP1: Ogunquit
!
ip cef
!
interface Loopback0
ip address aa.0.0.4 255.255.255.255
!
EBGP1: Ogunquit
!
ip cef
!
interface Loopback0
ip address aa.0.0.4 255.255.255.255
!
description Vermont
ip address aa.2.1.40 255.255.255.0
tag-switching ip
!
interface ATM1/0
description Lowell
no ip address
no atm scrambling cell-payload
!
interface ATM1/0.1 point-to-point
description Lowell
ip address aa.0.0.1 255.255.255.252
pvc 1/100
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
neighbor aa.0.0.2 remote-as 2
no auto-summary
!
neighbor R activate
neighbor aa.0.0.2 activate
neighbor aa.0.0.2 send-community extended
no auto-summary
exit-address-family
19
Configuration for Autonomous System 2, EBGP2: Example

The following example shows how to configure EBGP2 in AS2 in a topology with two autonomous
EBGP2: Lowell
!
ip cef
!
ip vrf V1
rd 2:103
!
interface Loopback0
ip address aa.0.0.3 255.255.255.255
ip router isis
!
interface Loopback1
ip address aa.0.0.3 255.255.255.255
!
interface Serial0/0
description Littleton
no ip address
load-interval 30
no fair-queue
clockrate 2000000
!
ip router isis
tag-switching ip
!
interface ATM1/0
no ip address
atm clock INTERNAL
!
ip address aa.0.0.2 255.255.255.252
pvc 1/100
!
router isis
net 49.0002.0000.0000.0003.00
!
router bgp 2
no synchronization
neighbor aa.0.0.8 update-source Loopback0
neighbor aa.0.0.8 next-hop-self
!
20
no auto-summary
no synchronization
exit-address-family
!
exit-address-family

The following example shows how to configure P2 in AS2 in a topology with two autonomous systems
(see Figure 7):
P2: Littleton
!
ip cef
!
ip vrf V1
rd 2:108
!
interface Loopback0
ip address aa.0.0.8 255.255.255.255
ip router isis
!
interface Loopback1
ip address aa.0.0.8 255.255.255.255
!
description Pax
ip address aa.9.1.2 255.255.255.0
ip router isis
tag-switching ip
!
interface Serial5/0
description Lowell
no ip address
!
description Lowell
ip router isis
tag-switching ip
!
router isis
net aa.0002.0000.0000.0008.00
!
router bgp 2
no synchronization
21
!
no auto-summary
no synchronization
exit-address-family
!
neighbor R activate
exit-address-family

The following example shows how to configure PE2 in AS2 in a topology with two autonomous systems
(see Figure 7):
PE2: Pax
!
ip cef
!
ip vrf V1
rd 2:109
!
interface Loopback0
ip address aa.0.0.9 255.255.255.255
ip router isis
!
interface Loopback1
ip address aa.0.0.9 255.255.255.255
!
interface Serial0/0
description Bethel
no ip address
no fair-queue
clockrate 2000000
!
description Bethel
!
ip address aa.9.1.1 255.255.255.0
ip router isis
tag-switching ip
!
22

network aa.0.0.0 0.255.255.255 area 0
!
router isis
net 49.0002.0000.0000.0009.00
!
router bgp 2
no synchronization
!
no auto-summary
no synchronization
exit-address-family
!
exit-address-family v

The following example shows how to configure CE2 in VPN1 in a topology with two autonomous
CE2: Bethel
!
interface Loopback0
ip address 1.0.0.11 255.255.255.255
!
interface Serial0
description Pax
no ip address
no fair-queue
clockrate 2000000
!
interface Serial0.1 point-to-point
description Pax
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
Configuring MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses

in a Confederation: Example
The network topology in Figure 8 shows a single internet service provider, which is partitioning the
backbone with confederations. The autonomous system number of the provider is 100. The two
autonomous systems run their own IGPs and are configured as follows:
Autonomous system 1 (AS1) includes PE1, P1, CEBGP1. The IGP is OSPF.
Autonomous system 2 (AS2) includes PE2, P2, CEBGP2. The IGP is IS-IS.
23
CE1 and CE2 belong to the same VPN, which is called VPN1.
The P routers are route reflectors.
CEBGP1 is configured with the redistribute connected subnets command.
CEBGP2 is configured with the neighbor next-hop-self command.
Figure 8 Configuring Two Autonomous Systems in a Confederation
VPN1 VPN1
PE1 P1 P2 PE2
CE1 AS1 AS2 CE2
47867
ASBR1 ASBR2

The following example shows how to configure CE1 in VPN1 in a confederation topology (see Figure 8):
CE1: Burlington
!
interface Loopback1
ip address aa.0.0.6 255.255.255.255
!
interface Serial1/3
no ip address
!
ip address aa.6.2.1 255.255.255.252
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0

The following example shows how to configure PE1 in AS1 in a confederation topology (see Figure 8):
PE1: wychmere
!
ip cef
!
ip vrf V1
rd 1:105
24

!
interface Serial0/0
no ip address
no fair-queue
clockrate 2000000
!
ip address aa.6.2.2 255.255.255.252
!
description Vermont
ip address aa.2.2.5 255.255.255.0
tag-switching ip
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
!
network aa.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
bgp confederation identifier 100
neighbor 1 peer-group
neighbor 1 remote-as 1
neighbor 1 update-source Loopback0
no auto-summary
!
no auto-summary
no synchronization
exit-address-family
!
neighbor R activate
no auto-summary
exit-address-family
Configuration for Autonomous System 1, P1 Example

The following example shows how to configure P1 in AS1 in a confederation topology (see Figure 8):
P1: Vermont
!
ip cef
!
interface Loopback0
ip address aa.0.0.2 255.255.255.255
25
!
ip address 100.2.1.1 255.255.255.0
tag-switching ip
!
ip address aa.2.2.1 255.255.255.0
duplex auto
speed auto
tag-switching ip
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
neighbor 100.0.0.4 peer-group R
neighbor 100.0.0.5 peer-group R
!
neighbor R activate
exit-address-family
Configuration for Autonomous System 1, CEBGP1: Example

The following example shows how to configure CEBGP1 in AS1 in a confederation topology (see
Figure 8):
EBGP1: Ogunquit
!
ip cef
!
interface Loopback0
ip address aa.0.0.4 255.255.255.255
!
description Vermont
ip address aa.2.1.40 255.255.255.0
tag-switching ip
!
interface ATM1/0
description Lowell
no ip address
!
description Lowell
26
ip address aa.0.0.1 255.255.255.252

pvc 1/100
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
!
router bgp 1
no synchronization
bgp confederation peers 1
no auto-summary
!
neighbor R activate
no auto-summary
exit-address-family
Configuration for Autonomous System 2, CEBGP2: Example

The following example shows how to configure CEBGP2 in AS2 in a confederation topology (see
Figure 8):
EBGP2: Lowell
!
ip cef
!
ip vrf V1
rd 2:103
!
interface Loopback0
ip address aa.0.0.3 255.255.255.255
ip router isis
!
interface Loopback1
ip address aa.0.0.3 255.255.255.255
!
interface Serial0/0
no ip address
load-interval 30
no fair-queue
clockrate 2000000
27
!
ip router isis
tag-switching ip
!
interface ATM1/0
no ip address
atm clock INTERNAL
!
ip address aa.0.0.2 255.255.255.252
pvc 1/100
!
router isis
net aa.0002.0000.0000.0003.00
!
router bgp 2
no synchronization
bgp confederation peers 1
!
no auto-summary
no synchronization
exit-address-family
!
exit-address-family

The following example shows how to configure P2 in AS2 in a confederation topology (see Figure 8):
P2: Littleton
!
ip cef
!
ip vrf V1
rd 2:108
28
!
interface Loopback0
ip address aa.0.0.8 255.255.255.255
ip router isis
!
interface Loopback1
ip address aa.0.0.8 255.255.255.255
!
description Pax
ip address aa.9.1.2 255.255.255.0
ip router isis
tag-switching ip
!
interface Serial5/0
description Lowell
no ip address
!
description Lowell
ip router isis
tag-switching ip
!
router isis
net aa.0002.0000.0000.0008.00
!
router bgp 2
no synchronization
!
no auto-summary
no synchronization
exit-address-family
!
neighbor R activate
exit-address-family

The following example shows how to configure PE2 in AS2 in a confederation topology (see Figure 8):
PE2: Pax
!
29
ip cef
!
ip vrf V1
rd 2:109
!
interface Loopback0
ip address aa.0.0.9 255.255.255.255
ip router isis
!
interface Loopback1
ip address 1.0.0.9 255.255.255.255
!
interface Serial0/0
description Bethel
no ip address
no fair-queue
clockrate 2000000
!
description Bethel
!
ip address 200.9.1.1 255.255.255.0
ip router isis
tag-switching ip
!
network aa.0.0.0 0.255.255.255 area 0
!
router isis
net aa.0002.0000.0000.0009.00
!
router bgp 2
no synchronization
!
no auto-summary
no synchronization
exit-address-family
!
exit-address-family
30
Command Reference

The following example shows how to configure CE2 in VPN1 in a confederation topology (see
Figure 8):
CE2: Bethel
!
interface Loopback0
ip address aa.0.0.11 255.255.255.255
!
interface Serial0
description Pax
no ip address
no fair-queue
clockrate 2000000
!
interface Serial0.1 point-to-point
description Pax
!
router ospf 1
network aa.0.0.0 0.255.255.255 area 0
Command Reference
31
Related Documents
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 1700 Assigned Numbers
RFC 1966 BGP Route Reflection: An Alternative to Full Mesh IBGP
RFC 2842 Capabilities Advertisement with BGP-4
RFC 2858 Multiprotocol Extensions for BGP-4
RFC 3107 Carrying Label Information in BGP-4
32
Feature Information for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses
Description Link
Feature Information for MPLS VPN Inter-AS with ASBRs

Not all commands may be available in your Cisco IOS software release. For details on when support for
specific commands was introduced, see the command reference documents.
Table 2 Feature Information for MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4 Addresses

MPLS VPNInterautonomous System Support 12.1(5)T This feature enables an MPLS VPN to span service
12.0(16)ST providers and autonomous systems. This feature explains
12.0(17)ST how to configuring the Inter-AS using the ASBRs to
12.0(22)S exchange VPN-IPv4 Addresses.
33
countries.
coincidental.
34
MPLS VPN Inter-AS with ASBRs Exchanging
IPv4 Routes and MPLS Labels

The MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels feature allows a
Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) to span service providers and
autonomous systems. This module explains how to configure an MPLS VPN Inter-AS network so that
the Autonomous System Boundary Routers (ASBRs) exchange IPv4 routes with MPLS labels of the
provider edge (PE) routers. Route reflectors (RRs) exchange VPN-IPv4 routes by using multihop,
multiprotocol, external Border Gateway Protocol (eBGP).

supported, see the Feature Information for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and
MPLS Labels section on page 37.
Contents
Prerequisites for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels,
page 2
Restrictions for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels,
page 3
MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
Prerequisites for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
Information About MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels,
page 3
How to Configure MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels,
page 6
Configuration Examples for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS
Labels, page 20
Feature Information for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS
Labels, page 37
Prerequisites for MPLS VPN Inter-AS with ASBRs Exchanging

The network must be properly configured for MPLS VPN operation before you configure MPLS VPN
Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels.
Table 1 lists the Cisco 12000 series line card support in Cisco IOS S releases.
Table 1 Cisco 12000 Series Line Card Support in Cisco IOS S Releases
Type Line Cards Cisco IOS Release Supported

ATM 4-Port OC-3 ATM 12.0(22)S, 12.0(23)S,
1-Port OC-12 ATM 12.0(27)S
4-Port OC-12 ATM
8-Port OC-3 ATM
Channelized interface 2-Port CHOC-3 12.0(22)S, 12.0(23)S,
6-Port Ch T3 (DS1) 12.0(27)S
4-Port CHOC-12 ISE
1-Port CHOC-48 ISE
Electrical interface 6-Port DS3 12.0(22)S, 12.0(23)S,
12-Port DS3 12.0(27)S
6-Port E3
12-Port E3
Ethernet 3-Port GbE 12.0(23)S, 12.0(27)S
2
Restrictions for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
Table 1 Cisco 12000 Series Line Card Support in Cisco IOS S Releases (continued)
Type Line Cards Cisco IOS Release Supported

Packet over SONET (POS) 4-Port OC-3 POS 12.0(22)S, 12.0(23)S,
8-Port OC-3 POS 12.0(27)S
16-Port OC-3 POS
1-Port OC-12 POS
4-Port OC-12 POS
1-Port OC-48 POS
4-Port OC-3 POS ISE
8-Port OC-3 POS ISE
Restrictions for MPLS VPN Inter-AS with ASBRs Exchanging

This feature includes the following restrictions:
For networks configured with eBGP multihop, you must configure a label switched path (LSP)
between nonadjacent routers.
The physical interfaces that connect the BGP speakers must support Cisco Express Forwarding or
distributed Cisco Express Forwarding and MPLS.
Information About MPLS VPN Inter-AS with ASBRs Exchanging

Before configuring MPLS VPN Inter-AS, you should understand the following concepts:
MPLS VPN Inter-AS Introduction, page 3
Benefits of MPLS VPN Inter-AS, page 4
Information About Using MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS
Labels, page 4
Benefits of MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels, page 4
How the Inter-AS Works When ASBRs Exchange IPv4 Routes with MPLS Labels, page 5
MPLS VPN Inter-AS Introduction

An autonomous system is a single network or group of networks that is controlled by a common system
administration group and that uses a single, clearly defined routing protocol.
As VPNs grow, their requirements expand. In some cases, VPNs need to reside on different autonomous
systems in different geographic areas. Also, some VPNs need to extend across multiple service providers
(overlapping VPNs). Regardless of the complexity and location of the VPNs, the connection between
autonomous systems must be seamless to the customer.
3
Information About MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
Benefits of MPLS VPN Inter-AS

MPLS VPN Inter-AS provides the following benefits:
Allows a VPN to cross more than one service provider backbone
Service providers running separate autonomous systems, can jointly offer MPLS VPN services to
the same customer. A VPN can begin at one site and traverse different VPN service provider
backbones before arriving at another site of the same customer. Previously, MPLS VPNs could
traverse only a single BGP autonomous system service provider backbone. This feature allows
multiple autonomous systems to form a continuous (and seamless) network between customer sites
of a service provider.
Allows a VPN to exist in different areas
A service provider can create a VPN in different geographic areas. Having all VPN traffic flow
through one point (between the areas) allows for better rate control of network traffic between the
areas.
Allows confederations to optimize iBGP meshing
Internal Border Gateway Protocol (iBGP) meshing in an autonomous system is more organized and
manageable. This feature can divide an autonomous system into multiple, separate subautonomous
systems and then classify them into a single confederation (even though the entire VPN backbone
appears as a single autonomous system). This capability allows a service provider to offer MPLS
VPNs across the confederation because it supports the exchange of labeled VPN-IPv4 Network
Layer Reachability Information (NLRI) between the subautonomous systems that form the
confederation.
Information About Using MPLS VPN Inter-AS with ASBRs Exchanging IPv4
Routes and MPLS Labels
This feature can configure a MPLS VPN Inter-AS network so that the ASBRs exchange IPv4 routes with
MPLS labels of the PE routers. RRs exchange VPN-IPv4 routes by using multihop, multiprotocol,
External Border Gateway Protocol (eBGP). This method of configuring the Inter-AS system is often
called MPLS VPN Inter-ASIPv4 BGP Label Distribution.
Benefits of MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS
Labels
An Inter-AS system can be configured so that the ASBRs exchange the IPv4 routes and MPLS labels has
the following benefits:
Saves the ASBRs from having to store all the VPN-IPv4 routes. Using the route reflectors to store
the VPN-IPv4 routes and forward them to the PE routers results in improved scalability compared
wtih configurations where the ASBR holds all of the VPN-IPv4 routes and forwards the routes based
on VPN-IPv4 labels.
Simplifies the configuration at the border of the network by having the route reflectors hold the
VPN-IPv4 routes.
Enables a non-VPN core network to act as a transit network for VPN traffic. You can transport IPv4
routes with MPLS labels over a non-MPLS VPN service provider.
4
Information About MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
Eliminates the need for any other label distribution protocol between adjacent LSRs. If two adjacent
label switch routers (LSRs) are also BGP peers, BGP can handle the distribution of the MPLS labels.
No other label distribution protocol is needed between the two LSRs.
How the Inter-AS Works When ASBRs Exchange IPv4 Routes with MPLS
Labels
A VPN service provider network to exchange IPv4 routes with MPLS labels can be configured. The VPN
service provider network can be configured as follows:
Route reflectors exchange VPN-IPv4 routes by using multihop, multiprotocol eBGP. This
configuration also preserves the next-hop information and the VPN labels across the autonomous
systems.
A local PE router (for example, PE1 in Figure 1) needs to know the routes and label information for
the remote PE router (PE2). This information can be exchanged between the PE routers and ASBRs
in one of two ways:
Internal Gateway Protocol (IGP) and Label Distribution Protocol (LDP): The ASBR can
redistribute the IPv4 routes and MPLS labels it learned from eBGP into IGP and LDP and vice
versa.
Internal Border Gateway Protocol (iBGP) IPv4 label distribution: The ASBR and PE router can
use direct iBGP sessions to exchange VPN-IPv4 and IPv4 routes and MPLS labels.
Alternatively, the route reflector can reflect the IPv4 routes and MPLS labels learned from the
ASBR to the PE routers in the VPN. This is accomplished by the ASBR exchanging IPv4 routes
and MPLS labels with the route reflector. The route reflector also reflects the VPN-IPv4 routes
to the PE routers in the VPN. For example, in VPN1 of Figure 1, RR1 reflects to PE1 the
VPN-IPv4 routes it learned and IPv4 routes and MPLS labels learned from ASBR1. Using the
route reflectors to store the VPN-IPv4 routes and forward them through the PE routers and
ASBRs allows for a scalable configuration.
Figure 1 VPNs Using eBGP and iBGP to Distribute Routes and MPLS Labels
Multihop
RR1 Multiprotocol RR2
VPNv4
BGP IPv4 routes

and label with
multipath support
PE1 ASBR1 ASBR2 PE2

59251
CE1 CE2
VPN1 VPN2
BGP Routing Information

BGP routing information includes the following items:
5
How to Configure MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
A network number (prefix), which is the IP address of the destination.

Autonomous system path, which is a list of the other autonomous systems through which a route
passes on its way to the local router. The first autonomous system in the list is closest to the local
router; the last autonomous system in the list is farthest from the local router and usually the
autonomous system where the route began.
Path attributes, which provide other information about the autonomous system path, for example,
the next hop.
Types of BGP Messages and MPLS Labels

MPLS labels are included in the update messages that a router sends. Routers exchange the following
types of BGP messages:
Keepalive messagesRouters exchange keepalive messages to determine if a neighboring router is
still available to exchange routing information. The router sends these messages at regular intervals.
(Sixty seconds is the default for Cisco routers.) The keepalive message does not contain routing
data; it contains only a message header.
Notification messagesWhen a router detects an error, it sends a notification message.
Open messagesAfter a router establishes a TCP connection with a neighboring router, the routers
exchange open messages. This message contains the number of the autonomous system to which the
router belongs and the IP address of the router that sent the message.
Update messagesWhen a router has a new, changed, or broken route, it sends an update message
to the neighboring router. This message contains the NLRI, which lists the IP addresses of the usable
routes. The update message includes any routes that are no longer usable. The update message also
includes path attributes and the lengths of both the usable and unusable paths. Labels for VPN-IPv4
routes are encoded in the update message as specified in RFC 2858. The labels for the IPv4 routes
are encoded in the update message as specified in RFC 3107.
How BGP Sends MPLS Labels with Routes

When BGP (eBGP and iBGP) distributes a route, it can also distribute an MPLS label that is mapped to
that route. The MPLS label mapping information for the route is carried in the BGP update message that
contains the information about the route. If the next hop is not changed, the label is preserved.
When you issue the neighbor send-label command on both BPG routers, the routers advertise to each
other that they can then send MPLS labels with the routes. If the routers successfully negotiate their
ability to send MPLS labels, the routers add MPLS labels to all outgoing BGP updates.
How to Configure MPLS VPN Inter-AS with ASBRs Exchanging

To configure MPLS VPN Inter-AS with ASBRs exchanging IPv4 routes and MPLS labels, perform the
tasks in the following sections:
Configuring the ASBRs to Exchange IPv4 Routes and MPLS Labels, page 7
Configuring the Route Reflectors to Exchange VPN-IPv4 Routes, page 9
Configuring the Route Reflector to Reflect Remote Routes in Its Autonomous System, page 11
6
Verifying the MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
Configuration, page 13
Figure 2 shows the following sample configuration:
The configuration consists of two VPNs.
The ASBRs exchange the IPv4 routes with MPLS labels.
The route reflectors exchange the VPN-IPv4 routes using multihop MPLS eBGP.
The route reflectors reflect the IPv4 and VPN-IPv4 routes to the other routers in their autonomous
system.
Figure 2 Configuring Two VPN Service Providers to Exchange IPv4 Routes and MPLS Labels
Multihop
aa.aa Multiprotocol bb.bb
RR1 EBGP RR2
exchange
AS 100 AS 200
IPv4 BGP +
labels exchange
with multipath
P1 support
PE1 ASBR1 ASBR2 PE2

ee.ee ww.ww xx.xx ff.ff
59252
CE1 CE2
oo.oo nn.nn
Configuring the ASBRs to Exchange IPv4 Routes and MPLS Labels

Perform this task to configure the ASBRs to exchange IPv4 routes and MPLS labels. This configuration
procedure uses ASBR1 as an example.
SUMMARY STEPS
1. enable
7. neighbor ip-address send-label
9. end
7
DETAILED STEPS

Example:
Router> enable
Example:
Example: neighbor.
Router(config-router)# neighbor hh.0.0.1
BGP peer group.
Step 5 address-family ipv4 [multicast | unicast | mdt| Enters address family configuration mode for configuring
vrf vrf-name] routing sessions such as BGP that use standard IPv4 address
prefixes.
Example: The multicast keyword specifies IPv4 multicast
Router(config-router)# address-family ipv4 address prefixes.
The unicast keyword specifies IPv4 unicast address
prefixes.
The mdt keyword specifies an IPv4 multicast
distribution tree (MDT) address family session.
The vrf vrf-name keyword and argument specify the
name of the VPN routing and forwarding (VRF)
instance to associate with subsequent IPv4 address
family configuration mode commands.
8

activate router.
Example: neighbor.
Router(config-router-af)# neighbor hh.0.0.1
BGP peer group.
Step 7 neighbor ip-address send-label Enables a BGP router to send MPLS labels with BGP routes
to a neighboring BGP router.
Example: The ip-address argument specifies the IP address of the
Router(config-router-af)# neighbor hh.0.0.1 neighboring router.
send-label
Example:
Example:
Configuring the Route Reflectors to Exchange VPN-IPv4 Routes

Perform this task to enable the route reflectors to exchange VPN-IPv4 routes by using multihop,
multiprotocol eBGP.
This procedure also specifies that the next hop information and the VPN label are to be preserved across
the autonomous systems. This procedure uses RR1 as an example of the route reflector.
SUMMARY STEPS
1. enable
6. neighbor {ip-address | peer-group-name} ebgp-multihop [ttl]
8. neighbor {ip-address | peer-group-name} next-hop unchanged
10. end
9
DETAILED STEPS

Example:
Router> enable
Example:
The autonomous system number identifies RR1 to routers in
other autonomous systems.
Example: neighbor.
Router(config-router)# neighbor bb.bb.bb.bb
BGP peer group.
Step 5 neighbor {ip-address | peer-group-name} Accepts and attempts BGP connections to external peers
ebgp-multihop [ttl] residing on networks that are not directly connected.
Router(config-router)# neighbor bb.bb.bb.bb
ebgp-multihop 255 The peer-group-name argument specifies the name of a
BGP peer group.
The ttl argument specifies the time-to-live in the range
from 1 to 255 hops.
routing sessions, such as BGP sessions, that use standard
VPNv4 address prefixes.
Example:
address prefixes.
10

activate router.
Example: neighbor.
Router(config-router-af)# neighbor bb.bb.bb.bb
BGP peer group.
Step 8 neighbor {ip-address | peer-group-name} Enables an eBGP multihop peer to propagate the next hop
next-hop unchanged unchanged.
Example: next hop.
Router(config-router-af)# neighbor ip-address
next-hop unchanged The peer-group-name argument specifies the name of a
BGP peer group that is the next hop.
Example:
Example:
Configuring the Route Reflector to Reflect Remote Routes in Its Autonomous

System
Perform this task to enable the RR to reflect the IPv4 routes and labels learned by the ASBR to the PE
routers in the autonomous system.
This is accomplished by making the ASBR and PE router route reflector clients of the RR. This
procedure also explains how to enable the RR to reflect the VPN-IPv4 routes.
SUMMARY STEPS
1. enable
6. neighbor ip-address route-reflector-client
11

13. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 4 address-family ipv4 [multicast | unicast | vrf Enters address family configuration mode for configuring
vrf-name] routing sessions, such as BGP sessions, that use standard
IPv4 address prefixes.
prefixes.
name of the VRF instance to associate with subsequent
IPv4 address family configuration mode commands.
activate router.
Example: neighbor.
Router(config-router-af)# neighbor ee.ee.ee.ee
BGP peer group.
Step 6 neighbor ip-address route-reflector-client Configures the router as a BGP route reflector and
configures the specified neighbor as its client.
Router(config-router-af)# neighbor ee.ee.ee.ees BGP neighbor being configured as a client.
route-reflector-client
12

Router(config-router-af)# neighbor ee.ee.ee.ee neighboring router.
send-label
Example:
routing sessions, such as BGP sessions, that use standard
VPNv4 address prefixes.
Example:
address prefixes.
activate router.
Example: neighbor.
BGP peer group.
Step 11 neighbor ip-address route-reflector-client Enables the RR to pass iBGP routes to the neighboring
router.
Example:
Example:
Example:
Verifying the MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and
MPLS Labels Configuration
If you use ASBRs to distribute the IPv4 labels and route reflectors to distribute the VPN-IPv4 routes,
use the following procedures to help verify the configuration:
Verifying the Route Reflector Configuration, page 14
Verifying that CE1 Can Communicate with CE2, page 15
Verifying that PE1 Can Communicate with CE2, page 16
Verifying that PE2 Can Communicate with CE2, page 18
13
Verifying the ASBR Configuration, page 19

Figure 3 shows the configuration that is referred to in the next several sections.
Figure 3 Configuring Two VPN Service Providers to Exchange IPv4 Routes and MPLS Labels
Multihop
RR1 EBGP RR2
exchange
AS 100 AS 200
IPv4 BGP +
labels exchange
with multipath
P1 support
PE1 ASBR1 ASBR2 PE2

59252
CE1 CE2
oo.oo nn.nn
Verifying the Route Reflector Configuration

Perform this task to verify the route reflector configuration.
SUMMARY STEPS
1. enable
3. disable
14
DETAILED STEPS

Example:
Router> enable
Step 2 show ip bgp vpnv4 {all | rd route-distinguisher (Optional) Displays VPN address information from the
| vrf vrf-name} [summary] [labels] BGP table.
Use the all and summary keywords to verify that a
Example: multihop, multiprotocol eBGP session exists between
Router# show ip bgp vpnv4 all summary the route reflectors and that the VPNv4 routes are being
exchanged between the route reflectors.
The last two lines of the command output show the
following information:
Prefixes are being learned from PE1 and then
passed to RR2.
Prefixes are being learned from RR2 and then
passed to PE1.
Use the all and labels keywords to verify that the route
reflectors exchange VPNv4 label information.
Example:
Router# disable
Verifying that CE1 Can Communicate with CE2

Perform this task to verify that router CE1 has NLRI for router CE2.
SUMMARY STEPS
1. enable
2. show ip route [ip-address [mask] [longer-prefixes]] | [protocol [process-id]] | [list
access-list-number | access-list-name]
3. disable
15
DETAILED STEPS

Example:
Router> enable
Step 2 show ip route [ip-address [mask] Displays the current state of the routing table.
[longer-prefixes]] | [protocol [process-id]] |
[list access-list-number | access-list-name] Use the ip-address argument to verify that CE1 has a
route to CE2.
Example: Use this command to verify the routes learned by CE1.

Router# show ip route nn.nn.nn.nn Make sure that the route for CE2 is listed.
Step 3 disable (Optional) Exits to privileged EXEC mode.
Example:
Router# disable
Verifying that PE1 Can Communicate with CE2

Perform this task to verify that router PE1 has NLRI for router CE2.
SUMMARY STEPS
1. enable
2. show ip route vrf vrf-name [connected] [protocol [as-number] [tag] [output-modifiers]] [list
number [output-modifiers]] [profile] [static [output-modifiers]] [summary [output-modifiers]]
[supernets-only [output-modifiers]] [traffic-engineering [output-modifiers]]
3. show ip bgp vpnv4 {all | rd route-distinguisher | vrf vrf-name} [ip-prefix | length [longer-prefixes]
[output-modifiers]] [network-address [mask] [longer-prefixes] [output-modifiers]] [cidr-only]
[community] [community-list] [dampened-paths] [filter-list] [flap-statistics] [inconsistent-as]
[neighbors] [paths [line]] [peer-group] [quote-regexp] [regexp] [summary] [tags]
4. show ip cef [vrf vrf-name] [network [mask]] [longer-prefixes] [detail]
5. show mpls forwarding-table [{network {mask | length} | labels label [-label] | interface interface
| next-hop address | lsp-tunnel [tunnel-id]}] [detail]
6. show ip bgp [network] [network-mask] [longer-prefixes]
8. disable
16
DETAILED STEPS

Example:
Router> enable
Step 2 show ip route vrf vrf-name [connected] (Optional) Displays the IP routing table associated with a
[protocol [as-number] [tag] [output-modifiers]] VRF.
[list number [output-modifiers]] [profile]
[static [output-modifiers]] [summary Use this command to verify that router PE1 learns
[output-modifiers]] [supernets-only routes from router CE2 (nn.nn.nn.nn).
[output-modifiers]] [traffic-engineering
[output-modifiers]]
Example:
Router# show ip route vrf vpn1 nn.nn.nn.nn
| vrf vrf-name} [ip-prefix|length BGP table.
[longer-prefixes] [output-modifiers]]
[network-address [mask] [longer-prefixes] Use the vrf or all keyword to verify that router PE2 is
[output-modifiers]] [cidr-only] [community] the BGP next-hop to router CE2.
[community-list] [dampened-paths] [filter-list]
[flap-statistics] [inconsistent-as] [neighbors]
[paths [line]] [peer-group] [quote-regexp]
[regexp] [summary] [tags]
Example:
Router# show ip bgp vpnv4 vrf vpn1 nn.nn.nn.nn
Example:
Router# show ip bgp vpnv4 all nn.nn.nn.nn
Step 4 show ip cef [vrf vrf-name] [network [mask]] (Optional) Displays entries in the Forwarding Information
[longer-prefixes] [detail] Base (FIB) or displays a summary of the FIB.
Use this command to verify that the Cisco Express
Example: Forwarding entries are correct.
Router# show ip cef vrf vpn1 nn.nn.nn.nn
Step 5 show mpls forwarding-table [{network {mask | (Optional) Displays the contents of the MPLS LFIB.
length} | labels label [-label] | interface
interface | next-hop address | lsp-tunnel Use this command to verify the IGP label for the BGP
[tunnel-id]}] [detail] next hop router (autonomous system boundary).
Example:
Step 6 show ip bgp [network] [network-mask] (Optional) Displays entries in the BGP routing table.
[longer-prefixes]
Use the show ip bgp command to verify the label for
the remote egress PE router (PE2).
Example:
Router# show ip bgp ff.ff.ff.ff
17

Use the all and summary keywords to verify the VPN
Example: label of CE2, as advertised by PE2.
Example:
Router# disable
Verifying that PE2 Can Communicate with CE2

Perform this task to ensure that PE2 can access CE2.
SUMMARY STEPS
1. enable
2. show ip route vrf vrf-name [connected] [protocol [as-number] [tag] [output-modifiers]] [list
number [output-modifiers]] [profile] [static [output-modifiers]] [summary [output-modifiers]]
[supernets-only [output-modifiers]] [traffic-engineering [output-modifiers]]
3. show mpls forwarding-table [vrf vrf-name] [{network {mask | length} | labels label [-label] |
interface interface | next-hop address | lsp-tunnel [tunnel-id]}] [detail]
6. disable
DETAILED STEPS

Example:
Router> enable
Step 2 show ip route vrf vrf-name [connected] (Optional) Displays the IP routing table associated with a
[protocol [as-number] [tag] [output-modifiers]] VRF.
[list number [output-modifiers]] [profile]
[static [output-modifiers]] [summary Use this command to check the VPN routing and
[output-modifiers]] [supernets-only forwarding table for CE2. The output provides
[output-modifiers]] [traffic-engineering
next-hop information.
[output-modifiers]]
Example:
Router# show ip route vrf vpn1 nn.nn.nn.nn
18

Step 3 show mpls forwarding-table [vrf vrf-name] (Optional) Displays the contents of the LFIB.
[{network {mask | length} | labels label
[-label] | interface interface | next-hop Use the vrf keyword to check the VPN routing and
address | lsp-tunnel [tunnel-id]}] [detail] forwarding table for CE2. The output provides the label
for CE2 and the outgoing interface.
Example:
Router# show mpls forwarding-table vrf vpn1
nn.nn.nn.nn
Use the all and labels keywords to check the VPN label
Example: for CE2 in the multiprotocol BGP table.
Step 5 show ip cef [vrf vrf-name] [network [mask]] (Optional) Displays entries in the FIB or displays a
[longer-prefixes] [detail] summary of the FIB.
Use this command to check the Cisco Express
Example: Forwarding entry for CE2. The command output shows
Router# show ip cef vpn1 nn.nn.nn.nn the local label for CE2 and the outgoing interface.
Example:
Router# disable
Verifying the ASBR Configuration

Perform this task to verify that the ASBRs exchange IPv4 routes with MPLS labels or IPv4 routes
without labels as prescribed by a route map.
SUMMARY STEPS
1. enable
2. show ip bgp [network] [network-mask] [longer-prefixes]
4. disable
DETAILED STEPS
19

Example:
Router> enable
Step 2 show ip bgp [network] [network-mask] (Optional) Displays entries in the BGP routing table.
[longer-prefixes]
Use this command to check that:
ASBR1 receives an MPLS label for PE2 from
Example:
Router# show ip bgp ff.ff.ff.ff
ASBR2.
ASBR1 receives IPv4 routes for RR2 without
labels from ASBR2.
ASBR2 distributes an MPLS label for PE2 to
ASBR1.
ASBR2 does not distribute a label for RR2 to
ASBR1.
Step 3 show ip cef [vrf vrf-name] [network [mask]] (Optional) Displays entries in the FIB or displays a
[longer-prefixes] [detail] summary of the FIB.
Use this command from ASBR1 and ASBR2 to check
Example: that:
Router# show ip cef ff.ff.ff.ff
The Cisco Express Forwarding entry for PE2 is
correct.
Example:
The Cisco Express Forwarding entry for RR2 is
Router# show ip cef bb.bb.bb.bb
correct.
Example:
Router# disable
Configuration Examples for MPLS VPN Inter-AS with ASBRs

Exchanging IPv4 Routes and MPLS Labels
Configuration examples for MPLS VPN Inter-AS are as follows:
Configuring MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels over an
MPLS VPN Service Provider: Examples, page 20
Configuring MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels over a
Non-MPLS VPN Service Provider: Examples, page 26
Configuring MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and
MPLS Labels over an MPLS VPN Service Provider: Examples
20
Configuration Examples for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
Configuration examples for Inter-AS using BGP to distribute routes and MPLS labels over an MPLS
VPN service provider included in this section are as follows:
Route Reflector 1 Configuration Example (MPLS VPN Service Provider), page 22
ASBR1 Configuration Example (MPLS VPN Service Provider), page 23
Route Reflector 2 Configuration Example (MPLS VPN Service Provider), page 24
ASBR2 Configuration Example (MPLS VPN Service Provider), page 25
Figure 4 shows two MPLS VPN service providers. The service provider distributes the VPN-IPv4 routes
between the route reflectors. The MPLS VPN service providers distribute the IPv4 routes with MPLS
labels between the ASBRs.
The configuration example shows the following two techniques you can use to distribute the VPN-IPv4
routes and the IPv4 routes with MPLS labels of the remote RRs and PEs to the local RRs and PEs:
Autonomous system 100 uses the RRs to distribute the VPN-IPv4 routes learned from the remote
RRs. The RRs also distribute the remote PE address and label learned from ASBR1 using IPv4
labels.
In Autonomous system 200, the IPv4 routes that ASBR2 learned are redistributed into IGP.
Figure 4 Distributing IPv4 Routes and MPLS Labels Between MPLS VPN Service Providers
Multihop
RR1 EBGP RR2
exchange
AS 100 AS 200
IPv4 BGP +
labels exchange
with multipath
P1 support
PE1 ASBR1 ASBR2 PE2

59252
CE1 CE2
oo.oo nn.nn
21
Route Reflector 1 Configuration Example (MPLS VPN Service Provider)

The configuration example for RR1 specifies the following:
RR1 exchanges VPN-IPv4 routes with RR2 using multiprotocol, multihop eBGP.
The VPN-IPv4 next-hop information and the VPN label are preserved across the autonomous
systems.
RR1 reflects to PE1:
The VPN-IPv4 routes learned from RR2
The IPv4 routes and MPLS labels learned from ASBR1
ip subnet-zero
ip cef
!
interface Loopback0
ip address aa.aa.aa.aa 255.255.255.255
!
ip address dd.0.0.2 255.0.0.0
!
router ospf 10
network aa.aa.aa.aa 0.0.0.0 area 100
network dd.0.0.0 0.255.255.255 area 100
!
router bgp 100
bgp cluster-id 1
timers bgp 10 30
neighbor ee.ee.ee.ee remote-as 100
neighbor ee.ee.ee.ee update-source Loopback0
neighbor ww.ww.ww.ww remote-as 100
neighbor ww.ww.ww.ww update-source Loopback0
neighbor bb.bb.bb.bb remote-as 200
neighbor bb.bb.bb.bb ebgp-multihop 255
neighbor bb.bb.bb.bb update-source Loopback0
no auto-summary
!
address-family ipv4
neighbor ee.ee.ee.ee activate
neighbor ee.ee.ee.ee route-reflector-client !IPv4+labels session to PE1
neighbor ee.ee.ee.ee send-label
neighbor ww.ww.ww.ww activate
neighbor ww.ww.ww.ww route-reflector-client !IPv4+labels session to ASBR1
neighbor ww.ww.ww.ww send-label
no neighbor bb.bb.bb.bb activate
no auto-summary
no synchronization
exit-address-family
!
neighbor ee.ee.ee.ee route-reflector-client !VPNv4 session with PE1
neighbor ee.ee.ee.ee send-community extended
neighbor bb.bb.bb.bb activate
neighbor bb.bb.bb.bb next-hop-unchanged !MH-VPNv4 session with RR2
neighbor bb.bb.bb.bb send-community extended !with next hop unchanged
exit-address-family
!
ip default-gateway 3.3.0.1
22
no ip classless
!
snmp-server engineID local 00000009020000D0584B25C0
snmp-server community public RO
snmp-server community write RW
no snmp-server ifindex persist
snmp-server packetsize 2048
!
end
ASBR1 Configuration Example (MPLS VPN Service Provider)

ASBR1 exchanges IPv4 routes and MPLS labels with ASBR2.
In this example, ASBR1 uses route maps to filter routes:
A route map called OUT specifies that ASBR1 should distribute the PE1 route (ee.ee) with labels
and the RR1 route (aa.aa) without labels.
A route map called IN specifies that ASBR1 should accept the PE2 route (ff.ff) with labels and the
RR2 route (bb.bb) without labels.
ip subnet-zero
!
interface Loopback0
ip address ww.ww.ww.ww 255.255.255.255
!
ip address hh.0.0.2 255.0.0.0
!
ip address dd.0.0.1 255.0.0.0
mpls ip
!
router ospf 10
passive-interface Ethernet0/2
network ww.ww.ww.ww 0.0.0.0 area 100
network dd.0.0.0 0.255.255.255 area 100
router bgp 100

timers bgp 10 30
neighbor aa.aa.aa.aa remote-as 100
neighbor aa.aa.aa.aa update-source Loopback0
neighbor hh.0.0.1 remote-as 200
no auto-summary
!
!
address-family ipv4 ! Redistributing IGP into BGP
redistribute ospf 10 ! so that PE1 & RR1 loopbacks
neighbor aa.aa.aa.aa activate ! get into the BGP table
neighbor aa.aa.aa.aa send-label
neighbor hh.0.0.1 activate
neighbor hh.0.0.1 advertisement-interval 5
neighbor hh.0.0.1 send-label
neighbor hh.0.0.1 route-map IN in ! accepting routes in route map IN.
neighbor hh.0.0.1 route-map OUT out ! distributing routes in route map OUT.
23
neighbor kk.0.0.1 activate

neighbor kk.0.0.1 advertisement-interval 5
neighbor kk.0.0.1 send-label
neighbor kk.0.0.1 route-map IN in ! accepting routes in route map IN.
neighbor kk.0.0.1 route-map OUT out ! distributing routes in route map OUT.
no auto-summary
no synchronization
exit-address-family
!
ip classless
!
access-list 1 permit ee.ee.ee.ee log !Setting up the access lists
access-list 2 permit ff.ff.ff.ff log
access-list 3 permit aa.aa.aa.aa log
access-list 4 permit bb.bb.bb.bb log
route-map IN permit 10 !Setting up the route maps

match ip address 2
match mpls-label
!
route-map IN permit 11
match ip address 4
!
route-map OUT permit 12
match ip address 3
!
match ip address 1
set mpls-label
!
end
Route Reflector 2 Configuration Example (MPLS VPN Service Provider)

RR2 exchanges VPN-IPv4 routes with RR1 through multihop, multiprotocol eBGP. This configuration
also specifies that the next-hop information and the VPN label are preserved across the autonomous
systems:
ip subnet-zero
ip cef
!
interface Loopback0
ip address bb.bb.bb.bb 255.255.255.255
!
interface Serial1/1
ip address ii.0.0.2 255.0.0.0
!
router ospf 20
network bb.bb.bb.bb 0.0.0.0 area 200
network ii.0.0.0 0.255.255.255 area 200
!
router bgp 200
bgp cluster-id 1
timers bgp 10 30
neighbor aa.aa.aa.aa ebgp-multihop 255
neighbor ff.ff.ff.ff remote-as 200
neighbor ff.ff.ff.ff update-source Loopback0
24
no auto-summary
!
neighbor aa.aa.aa.aa activate
neighbor aa.aa.aa.aa next-hop-unchanged !Multihop VPNv4 session with RR1
neighbor aa.aa.aa.aa send-community extended !with next-hop-unchanged
neighbor ff.ff.ff.ff activate
neighbor ff.ff.ff.ff route-reflector-client !VPNv4 session with PE2
neighbor ff.ff.ff.ff send-community extended
exit-address-family
!
no ip classless
!
end
ASBR2 Configuration Example (MPLS VPN Service Provider)

ASBR2 exchanges IPv4 routes and MPLS labels with ASBR1. However, in contrast to ASBR1, ASBR2
does not use the RR to reflect IPv4 routes and MPLS labels to PE2. ASBR2 redistributes the IPv4 routes
and MPLS labels learned from ASBR1 into IGP. PE2 can now reach these prefixes.
ip subnet-zero
ip cef
!
!
interface Loopback0
ip address xx.xx.xx.xx 255.255.255.255
!
ip address hh.0.0.1 255.0.0.0
!
ip address jj.0.0.1 255.0.0.0
mpls ip
!
router ospf 20
redistribute bgp 200 subnets ! Redistributing the routes learned from
passive-interface Ethernet1/0 ! ASBR1(eBGP+labels session) into IGP
network xx.xx.xx.xx 0.0.0.0 area 200 ! so that PE2 will learn them
network jj..0.0 0.255.255.255 area 200
!
router bgp 200
timers bgp 10 30
neighbor hh.0.0.2 remote-as 100
no auto-summary
!
address-family ipv4
redistribute ospf 20 ! Redistributing IGP into BGP
neighbor hh.0.0.2 activate ! so that PE2 & RR2 loopbacks
neighbor hh.0.0.2 advertisement-interval 5 ! will get into the BGP-4 table.
neighbor hh.0.0.2 route-map IN in
neighbor hh.0.0.2 route-map OUT out
neighbor hh.0.0.2 send-label
25

neighbor kk.0.0.2 route-map IN in
neighbor kk.0.0.2 route-map OUT out
no auto-summary
no synchronization
exit-address-family
!
neighbor bb.bb.bb.bb send-community extended
exit-address-family
!
ip classless
!
access-list 1 permit ff.ff.ff.ff log !Setting up the access lists
access-list 2 permit ee.ee.ee.ee log
route-map IN permit 11 !Setting up the route maps

match ip address 2
match mpls-label
!
match ip address 4
!
match ip address 1
set mpls-label
!
match ip address 3
end
Configuring MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and
MPLS Labels over a Non-MPLS VPN Service Provider: Examples
Configuration examples for Inter-AS using BGP to distribute routes and MPLS labels over a non MPLS
VPN service provider included in this section are as follows:
Route Reflector 1 Configuration Example (Non-MPLS VPN Service Provider), page 27
ASBR1 Configuration Example (Non-MPLS VPN Service Provider), page 28
26
Figure 5 shows two MPLS VPN service providers that are connected through a non MPLS VPN service
provider. The autonomous system in the middle of the network is configured as a backbone autonomous
system that uses LDP or Tag Distribution Protocol (TDP) to distribute MPLS labels. Traffic engineering
tunnels can also be used instead of TDP or LDP to build the LSP across the non MPLS VPN service
provider.
Figure 5 Distributing Routes and MPLS Labels over a Non-MPLS VPN Service Provider
Multihop
RR1 EBGP RR2
exchange
AS 100 AS 200
P1
PE1 ASBR1 ASBR2 PE2

ee.ee IPv4 ww.ww xx.xx IPv4 ff.ff
BGP BGP
CE1 with with CE2
oo.oo labels labels nn.nn
Non MPLS VPN

cc.cc
RR3
ASBR3 ASBR4
59253
zz.zz yy.yy
Route Reflector 1 Configuration Example (Non-MPLS VPN Service Provider)

The configuration example for RR1 specifies the following:
RR1 exchanges VPN-IPv4 routes with RR2 using multiprotocol, multihop eBGP.
The VPN-IPv4 next-hop information and the VPN label are preserved across the autonomous
systems.
RR1 reflects to PE1:
The VPN-IPv4 routes learned from RR2
The IPv4 routes and MPLS labels learned from ASBR1
ip subnet-zero
ip cef
!
interface Loopback0
ip address aa.aa.aa.aa 255.255.255.255
!
interface Serial1/2
ip address dd.0.0.2 255.0.0.0
clockrate 124061
!
router ospf 10
network aa.aa.aa.aa 0.0.0.0 area 100
network dd.0.0.0 0.255.255.255 area 100
27
!
router bgp 100
bgp cluster-id 1
timers bgp 10 30
neighbor ww.ww.ww.ww remote-as 100
neighbor ww.ww.ww.ww update-source Loopback0
neighbor bb.bb.bb.bb ebgp-multihop 255
no auto-summary
!
address-family ipv4
neighbor ee.ee.ee.ee route-reflector-client !IPv4+labels session to PE1
neighbor ee.ee.ee.ee send-label
neighbor ww.ww.ww.ww activate
neighbor ww.ww.ww.ww route-reflector-client !IPv4+labels session to ASBR1
neighbor ww.ww.ww.ww send-label
no neighbor bb.bb.bb.bb activate
no auto-summary
no synchronization
exit-address-family
!
neighbor ee.ee.ee.ee route-reflector-client !VPNv4 session with PE1
neighbor bb.bb.bb.bb next-hop-unchanged !MH-VPNv4 session with RR2
neighbor bb.bb.bb.bb send-community extended with next-hop-unchanged
exit-address-family
!
no ip classless
!
snmp-server engineID local 00000009020000D0584B25C0
snmp-server community write RW
no snmp-server ifindex persist
snmp-server packetsize 2048
!
end
ASBR1 Configuration Example (Non-MPLS VPN Service Provider)

ASBR1 exchanges IPv4 routes and MPLS labels with ASBR2.
In this example, ASBR1 uses route maps to filter routes:
A route map called OUT specifies that ASBR1 should distribute the PE1 route (ee.ee) with labels
and the RR1 route (aa.aa) without labels.
A route map called IN specifies that ASBR1 should accept the PE2 route (ff.ff) with labels and the
RR2 route (bb.bb) without labels.
ip subnet-zero
ip cef distributed
!
interface Loopback0
28
ip address ww.ww.ww.ww 255.255.255.255

!
ip address kk.0.0.2 255.0.0.0
ip route-cache distributed
!
ip address dd.0.0.1 255.0.0.0
mpls ip
!
router ospf 10
passive-interface Serial3/0/0
network ww.ww.ww.ww 0.0.0.0 area 100
network dd.0.0.0 0.255.255.255 area 100
router bgp 100

timers bgp 10 30
neighbor kk.0.0.1 remote-as 200
no auto-summary
!
address-family ipv4
redistribute ospf 10 ! Redistributing IGP into BGP
neighbor aa.aa.aa.aa activate ! so that PE1 & RR1 loopbacks
neighbor aa.aa.aa.aa send-label ! get into BGP table
neighbor kk.0.0.1 route-map IN in ! Accepting routes specified in route map IN
neighbor kk.0.0.1 route-map OUT out ! Distributing routes specified in route map OUT
no auto-summary
no synchronization
exit-address-family
!
ip classless
!
!
match ip address 2
match mpls-label
!
match ip address 4
!
match ip address 3
!
match ip address 1
set mpls-label
!
end
29

RR2 exchanges VPN-IPv4 routes with RR1 using multihop, multiprotocol eBGP. This configuration also
specifies that the next-hop information and the VPN label are preserved across the autonomous systems:
ip subnet-zero
ip cef
!
interface Loopback0
!
interface Serial1/1
ip address ii.0.0.2 255.0.0.0
!
router ospf 20
network ii.0.0.0 0.255.255.255 area 200
!
router bgp 200
bgp cluster-id 1
timers bgp 10 30
neighbor aa.aa.aa.aa ebgp-multihop 255
neighbor ff.ff.ff.ff remote-as 200
neighbor ff.ff.ff.ff update-source Loopback0
no auto-summary
!
neighbor aa.aa.aa.aa activate
neighbor aa.aa.aa.aa next-hop-unchanged !MH vpnv4 session with RR1
neighbor aa.aa.aa.aa send-community extended !with next-hop-unchanged
neighbor ff.ff.ff.ff activate
neighbor ff.ff.ff.ff route-reflector-client !vpnv4 session with PE2
neighbor ff.ff.ff.ff send-community extended
exit-address-family
!
no ip classless
!
end

ASBR2 exchanges IPv4 routes and MPLS labels with ASBR1. However, in contrast to ASBR1, ASBR2
does not use the RR to reflect IPv4 routes and MPLS labels to PE2. ASBR2 redistributes the IPv4 routes
and MPLS labels learned from ASBR1 into IGP. PE2 can now reach these prefixes.
ip subnet-zero
ip cef
!
!
interface Loopback0
ip address xx.xx.xx.xx 255.255.255.255
!
ip address qq.0.0.2 255.0.0.0
!
30
ip address jj.0.0.1 255.0.0.0

mpls ip
!
router ospf 20
redistribute bgp 200 subnets !redistributing the routes learned from
passive-interface Ethernet0/1 !ASBR2 (eBGP+labels session) into IGP
network xx.xx.xx.xx 0.0.0.0 area 200 !so that PE2 will learn them
network jj.0.0.0 0.255.255.255 area 200
!
router bgp 200
timers bgp 10 30
neighbor qq.0.0.1 remote-as 100
no auto-summary
!
address-family ipv4 ! Redistributing IGP into BGP
redistribute ospf 20 ! so that PE2 & RR2 loopbacks
neighbor qq.0.0.1 activate ! will get into the BGP-4 table
neighbor qq.0.0.1 advertisement-interval 5
neighbor qq.0.0.1 route-map IN in
neighbor qq.0.0.1 route-map OUT out
neighbor qq.0.0.1 send-label
no auto-summary
no synchronization
exit-address-family
!
neighbor bb.bb.bb.bb send-community extended
exit-address-family
!
ip classless
!
!
match ip address 2
match mpls-label
!
match ip address 4
!
match ip address 1
set mpls-label
!
match ip address 3
!
end
31

ASBR3 belongs to a non MPLS VPN service provider. ASBR3 exchanges IPv4 routes and MPLS labels
with ASBR1. ASBR3 also passes the routes learned from ASBR1 to ASBR3 through RR3.
Note Do not redistribute eBGP routes learned into iBGP if you are using iBGP to distribute the routes and
labels. This is not a supported configuration.
ip subnet-zero
ip cef
!
interface Loopback0
ip address yy.yy.yy.yy 255.255.255.255
interface Hssi4/0
ip address mm.0.0.0.1 255.0.0.0
mpls ip
hssi internal-clock
!
interface Serial5/0
ip address kk.0.0.1 255.0.0.0
load-interval 30
clockrate 124061
!
router ospf 30
network yy.yy.yy.yy 0.0.0.0 area 300
network mm.0.0.0 0.255.255.255 area 300
!
router bgp 300
timers bgp 10 30
neighbor cc.cc.cc.cc remote-as 300
neighbor cc.cc.cc.cc update-source Loopback0
neighbor kk.0.0.2 remote-as 100
no auto-summary
!
address-family ipv4
neighbor cc.cc.cc.cc activate ! iBGP+labels session with RR3
neighbor cc.cc.cc.cc send-label
neighbor kk.0.0.2 activate ! eBGP+labels session with ASBR1
neighbor kk.0.0.2 route-map IN in
neighbor kk.0.0.2 route-map OUT out
no auto-summary
no synchronization
exit-address-family
!
ip classless
!
!
match ip address 1
match mpls-label
!
32
match ip address 3
!
match ip address 2
set mpls-label
!
match ip address 4
!
ip classless
!
end

RR3 is a non MPLS VPN RR that reflects IPv4 routes with MPLS labels to ASBR3 and ASBR4.
ip subnet-zero
mpls traffic-eng auto-bw timers
no mpls ip
!
interface Loopback0
ip address cc.cc.cc.cc 255.255.255.255
!
interface POS0/2
ip address pp.0.0.1 255.0.0.0
crc 16
!
router ospf 30
network cc.cc.cc.cc 0.0.0.0 area 300
network pp.0.0.0 0.255.255.255 area 300
!
router bgp 300
neighbor zz.zz.zz.zz remote-as 300
neighbor zz.zz.zz.zz update-source Loopback0
neighbor yy.yy.yy.yy remote-as 300
neighbor yy.yy.yy.yy update-source Loopback0
no auto-summary
!
address-family ipv4
neighbor zz.zz.zz.zz activate
neighbor zz.zz.zz.zz route-reflector-client
neighbor zz.zz.zz.zz send-label ! iBGP+labels session with ASBR3
neighbor yy.yy.yy.yy activate
neighbor yy.yy.yy.yy route-reflector-client
neighbor yy.yy.yy.yy send-label ! iBGP+labels session with ASBR4
no auto-summary
no synchronization
exit-address-family
!
ip classless
!
end
33

ASBR4 belongs to a non MPLS VPN service provider. ASBR4 and ASBR3 exchange IPv4 routes and
MPLS labels by means of RR3.
Note Do not redistribute eBGP routes learned into iBGP if you are using iBGP to distribute the routes and
labels. This is not a supported configuration.
ip subnet-zero
ip cef distributed
!
interface Loopback0
ip address zz.zz.zz.zz 255.255.255.255
!
ip address qq.0.0.1 255.0.0.0
!
interface POS1/1/0
ip address pp.0.0.2 255.0.0.0
!
interface Hssi2/1/1
ip address mm.0.0.2 255.0.0.0
mpls ip
hssi internal-clock
!
router ospf 30
network zz.zz.zz.zz 0.0.0.0 area 300
network pp.0.0.0 0.255.255.255 area 300
network mm.0.0.0 0.255.255.255 area 300
!
router bgp 300
timers bgp 10 30
neighbor cc.cc.cc.cc remote-as 300
neighbor cc.cc.cc.cc update-source Loopback0
neighbor qq.0.0.2 remote-as 200
no auto-summary
!
address-family ipv4
neighbor cc.cc.cc.cc activate
neighbor cc.cc.cc.cc send-label
neighbor qq.0.0.2 activate
neighbor qq.0.0.2 advertisement-interval 5
neighbor qq.0.0.2 send-label
neighbor qq.0.0.2 route-map IN in
neighbor qq.0.0.2 route-map OUT out
no auto-summary
no synchronization
exit-address-family
!
ip classless
!
34
Command Reference

!
match ip address 1
match mpls-label
!
match ip address 3
!
match ip address 2
set mpls-label
!
match ip address 4
!
ip classless
!
end
Command Reference
35
Related Documents
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
36
Feature Information for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels
Description Link
Feature Information for MPLS VPN Inter-AS with ASBRs

Exchanging IPv4 Routes and MPLS Labels
Table 2 lists the features in this module and provides links to specific configuration information.
Not all commands may be available in your Cisco IOS software release. For details on when support for
specific commands was introduced, see the command reference documents.
Table 2 Feature Information for MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and MPLS Labels

MPLS VPN Inter-AS with ASBRs Exchanging 12.0(21)ST This module explains how to configure an MPLS VPN
IPv4 Routes and MPLS Labels 12.0(22)S Inter-AS network so that the ASBRs exchange IPv4 routes
12.0(23)S with MPLS labels of the provider edge (PE) routers. Route
12.2(13)T reflectors (RRs) exchange VPN-IPv4 routes by using
12.0(24)S multihop, multiprotocol, external Border Gateway
12.2(14)S Protocol (eBGP).
12.0(27)S
12.0(29)S
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,
37
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,
38
39
40
MPLS VPN Carrier Supporting Carrier Using LDP
and an IGP

Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) Carrier Supporting Carrier
(CSC) enables one MPLS VPN-based service provider to allow other service providers to use a segment
of its backbone network. This module explains how to configure the MPLS VPN CSC network using
MPLS Label Distribution Protocol (LDP) to distribute MPLS labels and an Interior Gateway Protocol
(IGP) to distribute routes.

supported, see the Feature Information for MPLS VPN CSC with LDP and IGP section on page 66.
Contents
Prerequisites for MPLS VPN CSC with LDP and IGP, page 2
Restrictions for MPLS VPN CSC with LDP and IGP, page 2
Information About MPLS VPN CSC with LDP and IGP, page 3
How to Configure MPLS VPN CSC with LDP and IGP, page 9
Configuration Examples for MPLS VPN CSC with LDP and IGP, page 18
MPLS VPN Carrier Supporting Carrier Using LDP and an IGP
Prerequisites for MPLS VPN CSC with LDP and IGP

Feature Information for MPLS VPN CSC with LDP and IGP, page 66
Glossary, page 66
Prerequisites for MPLS VPN CSC with LDP and IGP

This feature includes the following requirements:
The provider edge (PE) routers of the backbone carrier require 128 MB of memory.
The backbone carrier must enable the PE router to check that the packets it receives from the
customer edge (CE) router contain only the labels that the PE router advertised to the CE router. This
prevents data spoofing, which occurs when a packet from an unrecognized IP address is sent to a
router.
Restrictions for MPLS VPN CSC with LDP and IGP

The following features are not supported with this feature:
ATM MPLS
Carrier supporting carrier traffic engineering
Carrier supporting carrier quality of service (QoS)
RSVP aggregation
VPN Multicast between the customer carrier and the backbone carrier network
The following router platforms are supported on the edge of the MPLS VPN:
Cisco 7200 series
Cisco 7500 series
Cisco 12000 series
See Table 1 for Cisco 12000 series line card support added for Cisco IOS releases.
Table 1 Cisco12000 Series Line Card Support Added for Cisco IOS Releases

Packet over SONET (POS) 4-Port OC-3 POS 12.0(16)ST
1-Port OC-12 POS
8-Port OC-3 POS 12.0(21)ST
16-Port OC-3 POS
4-Port OC-12 POS
1-Port OC-48 POS
4-Port OC-3 POS ISE 12.0(22)S
8-Port OC-3 POS ISE
16 x OC-3 POS ISE
4 Port OC-12 POS ISE
2
Information About MPLS VPN CSC with LDP and IGP
Table 1 Cisco12000 Series Line Card Support Added for Cisco IOS Releases

Electrical Interface 6- Port DS3 12.0(16)ST
12- Port DS3
6-Port E3 12.0(21)ST
ATM 4-Port OC-3 ATM 12.0(22)S
1-Port OC12 ATM
4-Port OC-12 ATM
Channelized Interface 2-Port CHOC-3 12.0(22)S
6-Port Ch T3 (DS1)
4-Port CHOC-12 ISE
1-Port CHOC-48 ISE

Before configuring MPLS VPN CSC, you should understand the following concepts:
MPLS VPN CSC Introduction, page 3
Benefits of Implementing MPLS VPN CSC, page 3
Configuration Options for MPLS VPN CSC with LDP and IGP, page 4
MPLS VPN CSC Introduction

Carrier supporting carrier is where one service provider allows another service provider to use a segment
of its backbone network. The service provider that provides the segment of the backbone network to the
other provider is called the backbone carrier. The service provider that uses the segment of the backbone
network is called the customer carrier.
A backbone carrier offers Border Gateway Protocol and Multiprotocol Label Switching (BGP/MPLS)
VPN services. The customer carrier can be either:
An Internet service provider (ISP)
A BGP/MPLS VPN service provider
Benefits of Implementing MPLS VPN CSC

The MPLS VPN CSC provides the following benefits to service providers who are backbone carriers and
to customer carriers.
Benefits to the Backbone Carrier

The backbone carrier can accommodate many customer carriers and give them access to its
backbone. The backbone carrier does not need to create and maintain separate backbones for its
customer carriers. Using one backbone network to support multiple customer carriers simplifies the
3
backbone carriers VPN operations. The backbone carrier uses a consistent method for managing
and maintaining the backbone network. This is also cheaper and more efficient than maintaining
separate backbones.
The MPLS VPN carrier supporting carrier feature is scalable. Carrier supporting carrier can change
the VPN to meet changing bandwidth and connectivity needs. The feature can accommodate
unplanned growth and changes. The carrier supporting carrier feature enables tens of thousands of
VPNs to be configured over the same network, and it allows a service provider to offer both VPN
and Internet services.
The MPLS VPN carrier supporting carrier feature is a flexible solution. The backbone carrier can
accommodate many types of customer carriers. The backbone carrier can accept customer carriers
who are ISPs or VPN service providers or both. The backbone carrier can accommodate customer
carriers that require security and various bandwidths.
Benefits to the Customer Carriers

The MPLS VPN carrier supporting carrier feature removes from the customer carrier the burden of
configuring, operating, and maintaining its own backbone. The customer carrier uses the backbone
network of a backbone carrier, but the backbone carrier is responsible for network maintenance and
operation.
Customer carriers who use the VPN services provided by the backbone carrier receive the same level
of security that Frame Relay or ATM-based VPNs provide. Customer carriers can also use IPSec in
their VPNs for a higher level of security; it is completely transparent to the backbone carrier.
Customer carriers can use any link layer technology (SONET, Digital Subscriber Line, Frame Relay,
and so on) to connect the CE routers to the PE routers and the PE routers to the P routers. The MPLS
VPN carrier supporting carrier feature is link layer independent. The CE routers and PE routers use
IP to communicate, and the backbone carrier uses MPLS.
The customer carrier can use any addressing scheme and still be supported by a backbone carrier.
The customer address space and routing information are independent of the address space and
routing information of other customer carriers or the backbone provider.
Configuration Options for MPLS VPN CSC with LDP and IGP
The backbone carrier offers BGP and MPLS VPN services. The customer carrier can be one of the two
types of service providers described in the following sections, which explain how the backbone and
customer carriers distribute IPv4 routes and MPLS labels.
Customer Carrier Is an ISP, page 4
Customer Carrier Is a BGP/MPLS VPN Service Provider, page 7
Customer Carrier Is an ISP

This section explains how a BGP/MPLS VPN service provider (backbone carrier) can provide a segment
of its backbone network to a customer who is an ISP.
Consider the following example:
An ISP has two sites: one in California, the other in Maine. Each site is a point of presence (POP). The
ISP wants to connect these sites using a VPN service provided by a backbone carrier. Figure 1 illustrates
this situation.
4
Figure 1 Sample BGP/MPLS Backbone Carrier Supporting an ISP
ISP site 1 Backbone ISP site 2

(California) carrier (Maine)
CSC-CE1 CSC-PE1 CSC-PE2 CSC-CE2

ASBR1 ASBR2
P1 P2
50276
C1 C2
Note The CE routers in the figures are CE routers to the backbone carrier. However, they are PE routers to the
customer carrier.
In this example, only the backbone carrier uses MPLS. The customer carrier (ISP) uses only IP. As a
result, the backbone carrier must carry all the Internet routes of the customer carrier, which could be as
many as 100,000 routes. This poses a scalability problem for the backbone carrier. To solve the
scalability problem, the backbone carrier is configured as follows:
The backbone carrier allows only internal routes of the customer carrier (IGP routes) to be
exchanged between the CE routers of the customer carrier and the PE routers of the backbone carrier.
MPLS is enabled on the interface between the CE router of the customer carrier and the PE router
of the backbone carrier.
Internal and external routes are differentiated this way:
Internal routes go to any of the routers within the ISP.
External routes go to the Internet.
The number of internal routes is much lower than the number of external routes. Restricting the routes
between the CE routers of the customer carrier and the PE routers of the backbone carrier significantly
reduces the number of routes that the PE router needs to maintain.
Because the PE routers do not have to carry external routes in the VRF routing table, they can use the
incoming label in the packet to forward the customer carrier Internet traffic. Adding MPLS to the routers
provides a consistent method of transporting packets from the customer carrier to the backbone carrier.
MPLS allows the exchange of an MPLS label between the PE and the CE routers for every internal
customer carrier route. The routers in the customer carrier have all the external routes either through
internal Border Gateway Protocol (iBGP) or route redistribution to provide Internet connectivity.
Figure 2 shows how information is exchanged when the network is configured in this manner.
5
Figure 2 Backbone Carrier Exchanging Routing Information with a Customer Carrier Who Is an
ISP
Exterior Router Information (IPv4 NLRIs)

IBGP
Backbone
ISP site 1 carrier ISP site 2
IBGP
VPN routes with labels for
ISP sites 1 and 2
50277
IGP routes for ISP sites 1 and 2
Labels for routes
In Figure 3, routes are created between the backbone carrier and the customer carrier sites. ASBR2
receives an Internet route that originated outside the network. All routers in the ISP sites have all the
external routes through IBGP connections among them.
Figure 3 Establishing a Route Between a Backbone Carrier and a Customer Carrier Who Is an
ISP
ISP site 1 Backbone ISP site 2

(California) carrier (Maine)

ASBR1 ASBR2
P1 P2
50278
C1 C2
Table 2 describes the process of establishing the route, which can be divided into two distinct steps:
The backbone carrier propagates the IGP information of the customer carrier, which enables the
customer carrier routers to reach all the customer carrier routers in the remote sites.
Once the routers of the customer carriers in different sites are reachable, external routes can be
propagated in the customer carrier sites, using IBGP without using the backbone carrier routers.
6
Table 2 Establishing a Route Between the Backbone Carrier and the Customer Carrier ISP
Step Description
1 CSC-CE2 sends the internal routes within site 2 to CSC-PE2. The routes include the route
to ASBR2.
2 CSC-PE2 sends the routing information for site 2 to CSC-PE1, using MPLS VPN processes.
CSC-PE1 gets one label (called L3), which is associated with the route to the VPN-IP
address for ASBR2. CSC-PE1 gets another label (called L2), which is associated with the
route to CSC-PE2.
3 CSC-PE1 sends the routing information associated with internal routes from site 2 to
CSC-CE1. CSC-PE1 also sends the label binding information. As a result, CSC-CE1 gets the
route to ASBR2 with CSC-PE1 as the next hop. The label associated with that route is called
L1.
4 CSC-CE1 distributes the routing information through site 1. Every router in site 1 gets a
route for every internal destination in site 2. Therefore, every router in site 1 can reach
routers in site 2 and learn external routes through IBGP.
5 ASBR2 receives an Internet route.
6 The IBGP sessions exchange the external routing information of the ISP, including a route
to the Internet. Every router in site 1 knows a route to the Internet, with ASBR2 as the next
hop of that route.
Customer Carrier Is a BGP/MPLS VPN Service Provider

When a backbone carrier and the customer carrier both provide BGP/MPLS VPN services, the method
of transporting data is different from when a customer carrier provides only ISP services. The following
list highlights those differences:
When a customer carrier provides BGP/MPLS VPN services, its external routes are VPN-IPv4
routes. When a customer carrier is an ISP, its external routes are IP routes.
When a customer carrier provides BGP/MPLS VPN services, every site within the customer carrier
must use MPLS. When a customer carrier is an ISP, the sites do not need to use MPLS.
Figure 4 shows how information is exchanged when MPLS VPN services reside on all customer carrier
sites and on the backbone carrier.
7
Figure 4 Backbone Carrier Exchanging Information with a Customer Carrier Who Is an MPLS
VPN Service Provider
Exterior Router Information (VPN-IPv4 NLRI)

IBGP
MPLS VPN Backbone MPLS VPN

site 1 carrier site 2
CSC-PE CSC-PE
IBGP
VPN-IPv4 routes for
MPLS VPN sites 1 and 2
50279
IGP routes for MPLS VPN sites 1 and 2
Labels for routes
In the example shown in Figure 5, routes are created between the backbone carrier and the customer
carrier sites.
Figure 5 Establishing a Route Between a Backbone Carrier and a Customer Carrier Who Is an
MPLS VPN Service Provider
MPLS VPN ISP site 1 Backbone ISP site 2 MPLS VPN

site 1 (California) carrier (Maine) site 2

CE1 PE1 PE2 CE2
51423
P1 P2
C1 C2
Table 3 describes the process of establishing the route.
Table 3 Establishing a Route Between the Backbone Carrier and Customer Carrier Site
Step Description
1 CE2 sends all the internal routes within site 2 to CSC-PE2.
2 CSC-PE2 sends the routing information for site 2 to CSC-PE1, using MPLS VPN processes.
CSC-PE1 gets one label (called L3), which is associated with the route to the VPN-IP address
for PE2. CSC-PE1 gets another label (called L2), which is associated with the route to
CSC-PE2.
8
How to Configure MPLS VPN CSC with LDP and IGP
Table 3 Establishing a Route Between the Backbone Carrier and Customer Carrier Site
Step Description
3 CSC-PE1 sends the routing information associated with internal routes from site 2 to
CSC-CE1. CSC-PE1 also sends the label binding information. As a result, CSC-CE1 gets the
route to PE2 with CSC-PE1 as the next hop. The label associated with that route is called L1.
4 CE1 distributes the routing and labeling information through site 1. Every router in site 1 gets
a route for every internal destination in site 2. Therefore, PE1 can establish an MP-IBGP
session with PE2.
5 CE2 advertises the internal routes of MPLS VPN site 2 to PE2.
6 PE2 allocates labels for all the VPN routes (regular MPLS VPN functionality) and advertises
the labels to PE1, using MP-IBGP.
7 PE1 can forward traffic from VPN site 1 that is destined for VPN site 2.

Configuring the Backbone Carrier Core, page 9 (required)
Configuring the CSC-PE and CSC-CE Routers, page 15 (required)
Verifying the Carrier Supporting Carrier Configuration, page 17 (optional)
Configuring the Backbone Carrier Core

Configuring the backbone carrier core requires configuring connectivity and routing functions for the
CSC core and the CSC-PE routers.
Configuring and verifying the CSC core (backbone carrier) involves the following tasks:
Verifying IP Connectivity and LDP Configuration in the CSC Core, page 9 (optional)
Configuring VRFs for CSC-PE Routers, page 11 (required)
Configuring Multiprotocol BGP for VPN Connectivity in the Backbone Carrier, page 13 (required)
Prerequisites
Before you configure a backbone carrier core, configure the following on the CSC core routers:
An IGP routing protocolBGP, OSPF, IS-IS, EIGRP, static, and so on. For information, see
Configuring a Basic BGP Network, Configuring OSPF, Configuring a Basic IS-IS Network, and
Configuring EIGRP.
Label Distribution Protocol (LDP). For information, see MPLS Label Distribution Protocol.
Verifying IP Connectivity and LDP Configuration in the CSC Core

Perform this task to verify IP connectivity and LDP configuration in the CSC core. For a configuration
example for this task, see the Verifying IP Connectivity and LDP Configuration in the CSC Core
section on page 9.
9
SUMMARY STEPS
1. enable
5. show mpls ldp discovery [vrf vrf-name | all]
6. show mpls ldp neighbor [[vrf vrf-name] [address | interface] [detail] | all]
8. show mpls interfaces [[vrf vrf-name] [interface] [detail] | all]
9. show ip route
10. disable
DETAILED STEPS

Example:
Router> enable
Step 2 ping [protocol] {host-name | system-address} (Optional) Diagnoses basic network connectivity on
AppleTalk, Connectionless Network Service (CLNS), IP,
Novell, Apollo, VINES, DECnet, or Xerox Network System
Example:
Router# ping ip 10.0.0.1
(XNS) networks.
Use the ping ip command to verify the connectivity
from one CSC core router to another.
Step 3 trace [protocol] [destination] (Optional) Discovers the routes that packets will actually
take when traveling to their destination.
Example: Use the trace command to verify the path that a packet
Router# trace ip 10.0.0.1 goes through before reaching the final destination. The
trace command can help isolate a trouble spot if two
routers cannot communicate.
Step 4 show mpls forwarding-table [network {mask | (Optional) Displays the contents of the MPLS label
length} | labels label [- label] | interface forwarding information base (LFIB).
[tunnel-id]] [vrf vrf-name] [detail] Use the show mpls forwarding-table command to
verify that MPLS packets are being forwarded.
Example:
Step 5 show mpls ldp discovery [vrf vrf-name | all] (Optional) Displays the status of the LDP discovery
process.
Example: Use the show mpls ldp discovery command to verify
Router# show mpls ldp discovery that LDP is operational in the CSC core.
10

Step 6 show mpls ldp neighbor [[vrf vrf-name] [address (Optional) Displays the status of LDP sessions.
| interface] [detail] |all]
Use the show mpls ldp neighbor command to verify
LDP configuration in the CSC core.
Example:
Step 7 show ip cef [vrf vrf-name] [network [mask]] (Optional) Displays entries in the forwarding Information
[longer-prefixes] [detail] Base (FIB).
Use the show ip cef command to check the forwarding
Example: table (prefixes, next hops, and interfaces).
Router# show ip cef
Step 8 show mpls interfaces [[vrf vrf-name] (Optional) Displays information about one or more or all
[interface] [detail] | all] interfaces that are configured for label switching.
Use the show mpls interfaces command to verify that
Example: the interfaces are configured to use LDP.
Step 9 show ip route (Optional) Displays IP routing table entries.
Use the show ip route command to display the entire
Example: routing table, including host IP address, next hop, and
Router# show ip route interface.
Step 10 disable (Optional) Returns to privileged EXEC mode.
Example:
Router# disable
You can use the ping and trace commands to verify complete MPLS connectivity in the core. You also
get useful troubleshooting information from the additional show commands.
Configuring VRFs for CSC-PE Routers

Perform this task to configure VPN routing and forwarding (VRF) instances for the backbone carrier
edge (CSC-PE) routers.
SUMMARY STEPS
1. enable
3. ip vrf vrf-name
7. exit
11
10. end
DETAILED STEPS

Example:
Router> enable
Example:
Example: to an IPv4 prefix to create a VPN-IPv4 prefix. You can
example, 101:3
192.168.122.15:1
Step 5 route-target {import |export | both} Creates a route-target extended community for a VRF.
Example:
extended community.
12

Example:
configuration mode.
Router(config)# interface Ethernet5/0 configured.
subinterface.
Example:
Enter a show ip vrf detail command and make sure the MPLS VPN is up and associated with the right
interfaces.
Configuring Multiprotocol BGP for VPN Connectivity in the Backbone Carrier

Perform this task to configure multiprotocol BGP (MP-BGP) for VPN connectivity in the backbone
carrier.
SUMMARY STEPS
1. enable
10. end
13
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
neighbors.
Example: Use the no form of the bgp default-unicast command
Router(config-router)# no bgp default if you are using this neighbor for MPLS routes only.
ipv4-unicast
Example: neighbor.
BGP peer group.
Step 6 neighbor {ip-address | peer-group-name} Allows BGP sessions to use a specific operational interface
update-source interface-type for TCP connections.
update-source loopback0 The peer-group-name argument specifies the name of a
BGP peer group.
The interface-type argument specifies the interface to
be used as the source.
address prefixes.
Example:
address prefixes.
14

BGP peer group.
Example: neighbor.
BGP peer group.
Example:
command generates an error message, enter a debug ip bgp x.x.x.x events command, where x.x.x.x is
the IP address of the neighbor.
Configuring the CSC-PE and CSC-CE Routers

To enable the CSC-PE and CSC-CE routers to distribute routes and MPLS labels, perform the following
tasks:
Configuring LDP on the CSC-PE and CSC-CE Routers, page 15 (required)
Enabling MPLS Encapsulation on the CSC-PE and CSC-CE Routers, page 16 (required)
Prerequisites
Before you configure the CSC-PE and CSC-CE routers, you must configure an IGP on the CSC-PE and
CSC-CE routers. A routing protocol is required between the PE and CE routers that connect the
backbone carrier to the customer carrier. The routing protocol enables the customer carrier to exchange
IGP routing information with the backbone carrier. Use the same routing protocol that the customer
carrier uses. You can choose RIP, OSPF, or static routing as the routing protocol. BGP is not supported.
For the configuration steps, see Configuring MPLS Layer 3 VPNs.
Configuring LDP on the CSC-PE and CSC-CE Routers

MPLS LDP is required between the PE and CE routers that connect the backbone carrier to the customer
carrier. You can configure LDP as the default label distribution protocol for the entire router or just for
the PE-to-CE interface for VRF.
15
SUMMARY STEPS
1. enable
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls label protocol ldp Specifies MPLS LDP as the default label distribution
protocol for the router.
Example:
Step 4 interface type number (Optional) Specifies the interface to configure and enters
Step 5 mpls label protocol ldp (Optional) Specifies MPLS LDP as the default label
distribution protocol for the interface.
Example:
Step 6 exit (Optional) Exits to privileged EXEC mode.
Example:
Enabling MPLS Encapsulation on the CSC-PE and CSC-CE Routers

Every packet that crosses the backbone carrier must be encapsulated, so that the packet includes MPLS
labels. You can enable MPLS encapsulation for the entire router or just on the interface of the PE or CE
router. To enable the encapsulation of packets, perform the following task.
16
SUMMARY STEPS
1. enable
3. mpls ip
5. mpls ip
6. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls ip Enables MPLS encapsulation for the router.
Example:
Step 4 interface type number (Optional) Specifies the interface to configure and enters
Step 5 mpls ip (Optional) Enables MPLS encapsulation for the specified
interface.
Example:
Step 6 exit (Optional) Exits to privileged EXEC mode.
Example:
Verifying the Carrier Supporting Carrier Configuration

The following commands verify the status of LDP sessions that were configured between the backbone
carrier and customer carrier. Now the customer carrier ISP sites appear as a VPN customer to the
backbone carrier.
17
Configuration Examples for MPLS VPN CSC with LDP and IGP
SUMMARY STEPS
1. show mpls ldp discovery vrf vrf-name

2. show mpls ldp discovery all
DETAILED STEPS
Step 1 show mpls ldp discovery vrf vrf-name

Use this command to show that the LDP sessions are in VRF VPN1 of the PE router of the backbone
carrier, for example:
Router# show mpls ldp discovery vrf vpn1

10.0.0.0:0
Discovery Sources:
Interfaces:
LDP Id: 10.0.0.1:0
POS6/0 (ldp): xmit
Step 2 show mpls ldp discovery all

Use this command to list all LDP sessions in a router, for example:
Router# show mpls ldp discovery all

10.10.10.10:0
Discovery Sources:
Interfaces:
LDP Id: 10.5.5.5:0
VRF vpn1: Local LDP Identifier:
10.0.0.1:0
Discovery Sources:
Interfaces:
LDP Id: 10.0.0.1:0
POS6/0 (ldp): xmit
The Local LDP Identifier field shows the LDP identifier for the local label switching router for this
session. The Interfaces field displays the interfaces engaging in LDP discovery activity:
xmit indicates that the interface is transmitting LDP discovery hello packets.
recv indicates that the interface is receiving LDP discovery hello packets.
MPLS VPN CSC Network with a Customer Who Is an ISP: Example
MPLS VPN CSC Network with a Customer Who Is an MPLS VPN Provider: Example
MPLS VPN CSC Network That Contains Route Reflectors: Example
18
MPLS VPN CSC Network with a Customer Who Has VPNs at the Network Edge: Example
MPLS VPN CSC Network with a Customer Who Is an ISP: Example

Figure 6 shows a carrier supporting carrier network configuration where the customer carrier is an ISP.
The customer carrier has two sites, each of which is a POP. The customer carrier connects these sites
using a VPN service provided by the backbone carrier. The backbone carrier uses MPLS. The ISP sites
use IP. To enable packet transfer between the ISP sites and the backbone carrier, the CE routers that
connect the ISPs to the backbone carrier run MPLS.
Figure 6 Carrier Supporting Carrier Network with a Customer Carrier Who Is an ISP
ISP site 1 Backbone carrier ISP site 2
50846
IP MPLS IP
The following examples show the configuration of each router in the carrier supporting carrier network.
OSPF is used to connect the customer carrier to the backbone carrier.
CSC-CE1 Configuration
!
interface Loopback0
ip address 10.14.14.14 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
atm pvc 101 0 51 aal5snap
mpls ip
!
interface ATM2/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
19
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
router ospf 200
network 10.14.14.14 0.0.0.0 area 200
network 10.15.0.0 0.255.255.255 area 200
network 10.16.0.0 0.255.255.255 area 200
CSC-PE1 Configuration
ip cef distributed
!
ip vrf vpn1
rd 100:0
no mpls aggregate-statistics
!
interface Loopback0
ip address 10.11.11.11 255.255.255.255
no ip route-cache
no ip mroute-cache
!
ip address 10.19.19.19 255.255.255.255
!
interface ATM1/1/0
no ip address
no ip route-cache distributed
atm clock INTERNAL
!
interface ATM1/1/0.1
ip address 10.0.0.1 255.0.0.0
mpls ip
!
interface ATM3/0/0
no ip address
atm clock INTERNAL
atm sonet stm-1
20
!
interface ATM3/0/0.1 point-to-point
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 100
passive-interface ATM3/0/0.1
network 10.11.11.11 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
!
network 10.19.19.19 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
!
router bgp 100
timers bgp 10 30
!
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
redistribute ospf 200 match internal external 1 external 2
no auto-summary
no synchronization
exit-address-family
ip cef distributed
!
ip vrf vpn1
rd 100:0
!
interface Loopback0
ip address 10.12.12.12 255.255.255.255
21
no ip route-cache
no ip mroute-cache
!
ip address 10.20.20.20 255.255.255.255
!
interface ATM0/1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM3/0/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 100
network 10.12.12.12 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
!
network 10.20.20.20 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
!
router bgp 100
timers bgp 10 30
!
22
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
ip cef
!
!
interface Loopback0
ip address 10.16.16.16 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM5/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls ip
23
!
router ospf 200
network 10.16.16.16 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
network 10.0.0.0 0.255.255.255 area 200
MPLS VPN CSC Network with a Customer Who Is an MPLS VPN Provider:
Example
Figure 7 shows a carrier supporting carrier network configuration where the customer carrier is an MPLS
VPN provider. The customer carrier has two sites. The backbone carrier and the customer carrier use
MPLS. The IBGP sessions exchange the external routing information of the ISP.
Figure 7 Carrier Supporting Carrier Network with a Customer Carrier Who Is an MPLS VPN
Provider
IBGP
50847
MPLS MPLS MPLS
CE1 CE2
PE1 CSC-CE1 CSC-PE1 CSC-PE2 CSC-CE2 PE2
IBGP
The following configuration examples show the configuration of each router in the carrier supporting
carrier network. OSPF is the protocol used to connect the customer carrier to the backbone carrier.
CE1 Configuration
ip cef
!
interface Loopback0
ip address 10.17.17.17 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
!
router ospf 300
network 10.17.17.17 0.0.0.0 area 300
!
router bgp 300
no synchronization
timers bgp 10 30
24
no auto-summary
PE1 Configuration
ip cef
!
ip vrf vpn2
rd 200:1
!
interface Loopback0
ip address 10.13.13.13 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
ip address 10.0.0.1 255.0.0.0
no ip mroute-cache
!
router ospf 200
network 10.13.13.13 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
!
router bgp 200
timers bgp 10 30
!
address-family ipv4
25
no synchronization
exit-address-family
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
interface Loopback0
ip address 10.14.14.14 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM2/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
router ospf 200
26
network 10.14.14.14 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
network 10.0.0.0 0.255.255.255 area 200
ip cef distributed
!
ip vrf vpn1
rd 100:0
!
interface Loopback0
ip address 11.11.11.11 255.255.255.255
no ip route-cache
no ip mroute-cache
!
ip address 10.19.19.19 255.255.255.255
!
interface ATM1/1/0
no ip address
atm clock INTERNAL
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
interface ATM3/0/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
27
router ospf 100

network 10.11.11.11 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
!
network 10.19.19.19 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
!
router bgp 100
timers bgp 10 30
!
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
ip cef distributed
!
ip vrf vpn1
rd 100:0
!
interface Loopback0
ip address 10.12.12.12 255.255.255.255
no ip route-cache
no ip mroute-cache
!
ip address 10.20.20.20 255.255.255.255
!
interface ATM0/1/0
no ip address
28
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM3/0/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 100
network 10.12.12.12 0.0.0.0 area 100
network 10.0.0.0 0.255.255.255 area 100
!
network 10.20.20.20 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
!
router bgp 100
timers bgp 10 30
!
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
29

no auto-summary
no synchronization
exit-address-family
ip cef
!
!
interface Loopback0
ip address 10.16.16.16 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM5/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
router ospf 200
network 10.16.16.16 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
network 10.0.0.0 0.255.255.255 area 200
PE2 Configuration
ip cef
30
ip cef accounting non-recursive

!
ip vrf vpn2
rd 200:1
!
interface Loopback0
ip address 10.15.15.15 255.255.255.255
!
ip address 10.0.0.1 255.0.0.0
!
interface ATM5/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 200
network 10.15.15.15 0.0.0.0 area 200
network 10.0.0.0 0.255.255.255 area 200
!
router bgp 200
timers bgp 10 30
!
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
no auto-summary
31
no synchronization
exit-address-family
CE2 Configuration
ip cef
!
interface Loopback0
ip address 10.18.18.18 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
!
router ospf 300
network 10.18.18.18 0.0.0.0 area 300
!
router bgp 300
no synchronization
timers bgp 10 30
no auto-summary
MPLS VPN CSC Network That Contains Route Reflectors: Example

Figure 8 shows a carrier supporting carrier network configuration that contains route reflectors. The
customer carrier has two sites.
32
Figure 8 Carrier Supporting Carrier Network that Contains Route Reflectors
Backbone Carrier
AS 100
Site 1 Site 2
RR 1 RR 2
Customer Carrier 72K-37-1 72K-38-1 Customer Carrier
AS 200 AS 200
PE1 PE3
72K-36-8 CSC-CE1 CSC-CE3 72K-36-4
ASBR-1 72K-36-9 72K-36-6 ASBR-3
CSC-PE1 CSC-PE2
75K-37-3 75K-38-3
PE2 RR 3 CSC-CE4
72K-36-7 36K-38-4 72K-36-5
ASBR-2
Physical connection
RR 4
CE1 36K-38-5
36K-36-1
CE2 CE3
36K-36-2 36K-36-3
VPN 1
AS 300
51323
VPN 1
AS 300
Note A connection between route reflectors (RRs) is not necessary.
The following configuration examples show the configuration of each router in the carrier supporting
carrier network. Note the following:
The router IP addresses are abbreviated for ease of reading. For example, the loopback address for
PE 1 is 25, which is equivalent to 10.25.25.25.
The following list shows the loopback addresses for the CSC-PE routers:
CSC-PE1 (75K-37-3): loopback 0 = 10.15.15.15, loopback 1 = 10.18.18.18
CSC-PE2 (75K-38-3): loopback 0 = 10.16.16.16, loopback 1 = 10.20.20.20
Backbone Carrier Configuration
Route Reflector 1 (72K-37-1) Configuration

interface Loopback0
ip address 10.13.13.13 255.255.255.255
no ip route-cache
no ip mroute-cache
33
!
interface ATM1/0
no ip address
atm clock INTERNAL
!
interface ATM1/0.1 mpls
ip address 10.0.0.2 255.0.0.0
mpls atm vpi 2-5
mpls ip
!
interface ATM1/1
no ip address
atm clock INTERNAL
!
ip address 10.0.0.1 255.0.0.0
mpls atm vpi 2-5
mpls ip
!
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.2.0.0 0.255.255.255 area 100
!
router bgp 100
no synchronization
bgp cluster-id 1
redistribute static
!
no auto-summary
no synchronization
exit-address-family
!
neighbor 10.15.15.15 route-reflector-client
exit-address-family
34

interface Loopback0
ip address 10.14.14.14 255.255.255.255
no ip mroute-cache
!
interface ATM1/0
no ip address
atm clock INTERNAL
!
ip address 10.0.0.1 255.0.0.0
mpls atm vpi 2-5
mpls ip
!
interface ATM1/1
no ip address
atm clock INTERNAL
!
ip address 10.0.0.2 255.0.0.0
mpls atm vpi 2-5
mpls ip
!
router ospf 100
network 10.0.0.0 0.255.255.255 area 100
network 10.1.0 0.255.255.255 area 100
network 10.2.0.0 0.255.255.255 area 100
!
router bgp 100
no synchronization
bgp cluster-id 1
redistribute static
!
35

no auto-summary
no synchronization
exit-address-family
!
exit-address-family
CSC-PE1 (75K-37-3) Configuration

ip cef distributed
!
ip vrf vpn1
rd 100:1
!
interface Loopback0
ip address 10.15.15.15 255.255.255.255
!
interface Loopback1
ip address 10.18.18.18 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM1/1/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
interface ATM1/1/0.1 mpls
ip address 10.0.0.1 255.0.0.0
mpls atm vpi 2-5
mpls ip
!
interface ATM3/0/0
no ip address
atm clock INTERNAL
36
atm sonet stm-1

!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM3/1/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.1 255.0.0.0
mpls atm vpi 2-5
mpls ip
!
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.2.0.0 0.255.255.255 area 100
network 10.3.0.0 0.255.255.255 area 100
network 10.4.0.0 0.255.255.255 area 100
!
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
!
router bgp 100
!
address-family ipv4
redistribute static
no synchronization
exit-address-family
!
exit-address-family
37
!
no auto-summary
no synchronization
exit-address-family

ip cef distributed
!
ip vrf vpn1
rd 100:1
!
interface Loopback0
ip address 10.16.16.16 255.255.255.255
!
interface Loopback1
ip address 10.20.20.20 255.255.255.255
!
interface ATM0/1/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls atm vpi 2-5
mpls ip
!
interface ATM2/1/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.2 255.0.0.0
mpls atm vpi 2-5
mpls ip
!
interface ATM3/0/0
no ip address
38
atm clock INTERNAL

atm sonet stm-1
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
interface ATM3/1/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 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
network 10.0.0.0 0.255.255.255 area 100
!
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
!
router bgp 100
!
address-family ipv4
redistribute static
no synchronization
exit-address-family
!
39

exit-address-family
!
no auto-summary
no synchronization
exit-address-family
Customer Carrier Site 1 Configuration
PE1 (72K-36-8) Configuration

ip cef
!
ip vrf vpn2
rd 200:1
no mpls ip propagate-ttl
!
interface Loopback0
ip address 10.25.25.25 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
ip address 10.0.0.1 255.0.0.0
no ip mroute-cache
!
ip address 10.0.0.1 255.0.0.0
no ip mroute-cache
mpls ip
!
ip address 10.0.0.2 255.0.0.0
no ip mroute-cache
mpls ip
!
40
router ospf 1
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
!
router bgp 200
!
no auto-summary
no synchronization
exit-address-family
!
exit-address-family
CSC-CE1 (72K-36-9) Configuration

ip cef
no ip domain-lookup
!
interface Loopback0
ip address 10.11.11.11 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
interface ATM2/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.0.0.1 255.0.0.0
41

mpls ip
!
ip address 10.0.0.2 255.0.0.0
no ip mroute-cache
mpls ip
!
ip address 10.0.0.1 255.0.0.0
no ip mroute-cache
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101

ip cef
!
ip vrf vpn2
rd 200:1
no mpls ip propagate-ttl
!
interface Loopback0
ip address 10.24.24.24 255.255.255.255
no ip route-cache
no ip mroute-cache
!
ip address 10.0.0.1 255.0.0.0
no ip mroute-cache
mpls ip
!
ip address 10.0.0.1 255.0.0.0
no ip mroute-cache
!
ip address 10.0.0.2 255.0.0.0
no ip mroute-cache
mpls ip
!
42
ip address 10.0.0.2 255.0.0.0
no ip mroute-cache
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
network 10.0.0.0 0.255.255.255 area 101
!
router bgp 200
!
no auto-summary
no synchronization
exit-address-family
!
exit-address-family

ip cef
!
interface Loopback0
ip address 10.23.23.23 255.255.255.255
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
interface ATM3/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.0.0.2 255.0.0.0
mpls ip
43
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 101
network 10.1.0.0 0.255.255.255 area 101
network 10.2.0.0 0.255.255.255 area 101
network 10.3.0.0 0.255.255.255 area 101
!
router bgp 200
no synchronization
bgp cluster-id 2
redistribute static
!
no auto-summary
no synchronization
exit-address-family
!
exit-address-family
CE1 (36K-36-1) Configuration

ip cef
!
interface Loopback0
ip address 10.28.28.28 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
!
ip address 10.0.0.2 255.0.0.0
!
router bgp 300
network 10.0.0.0
network 10.0.0.0
network 10.0.0.0
44

ip cef
!
interface Loopback0
ip address 10.12.12.12 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface POS2/0
ip address 10.0.0.2 255.0.0.0
encapsulation ppp
mpls ip
!
interface ATM5/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 101
network 10.1.0.0 0.255.255.255 area 101
network 10.2.0.0 0.255.255.255 area 101
network 10.3.0.0 0.255.255.255 area 101

ip cef
!
ip vrf vpn2
rd 200:1
!
45
!
interface Loopback0
ip address 10.21.21.21 255.255.255.255
!
ip address 10.0.0.1 255.0.0.0
!
ip address 10.0.0.1 255.0.0.0
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
interface ATM5/0
no ip address
atm clock INTERNAL
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM6/0
no ip address
atm clock INTERNAL
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 101
network 10.1.0.0 0.255.255.255 area 101
network 10.2.0.0 0.255.255.255 area 101
network 10.3.0.0 0.255.255.255 area 101
!
router bgp 200
!
46

no auto-summary
no synchronization
exit-address-family
!
exit-address-family

ip cef
!
interface Loopback0
ip address 10.10.10.10 255.255.255.255
!
interface POS4/0
ip address 10.0.0.1 255.0.0.0
encapsulation ppp
mpls ip
!
interface ATM5/0
no ip address
atm clock INTERNAL
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
interface ATM6/0
no ip address
atm clock INTERNAL
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 101
network 10.1.0.0 0.255.255.255 area 101
network 10.2.0.0 0.255.255.255 area 101
network 10.3.0.0 0.255.255.255 area 101
47

ip cef
!
interface Loopback0
ip address 10.22.22.22 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
mpls ip
!
interface ATM2/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.0.0.1 255.0.0.0
mpls ip
!
router ospf 1
network 10.0.0.0 0.255.255.255 area 101
network 10.1.0.0 0.255.255.255 area 101
network 10.2.0.0 0.255.255.255 area 101
!
router bgp 200
no synchronization
bgp cluster-id 2
redistribute static
!
no auto-summary
no synchronization
exit-address-family
!
exit-address-family
48

ip cef
!
interface Loopback0
ip address 10.26.26.26 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
!
ip address 10.0.0.1 255.0.0.0
!
router ospf 300
redistribute bgp 300
network 10.0.0.0 0.255.255.255 area 300
network 10.0.0.0 0.255.255.255 area 300
!
router bgp 300
network 10.0.0.0
network 10.1.0.0
network 10.2.0.0

ip cef
!
interface Loopback0
ip address 10.27.27.27 255.255.255.255
!
ip address 10.0.0.2 255.0.0.0
!
ip address 10.0.0.2 255.0.0.0
!
router ospf 300
redistribute bgp 300
network 10.0.0.0 0.255.255.255 area 300
network 10.0.0.0 0.255.255.255 area 300
!
router bgp 300
network 10.0.0.0
network 10.1.0.0
network 10.2.0.0
MPLS VPN CSC Network with a Customer Who Has VPNs at the Network Edge:
Example
Figure 9 shows a carrier supporting carrier network configuration where the customer carrier has VPNs
at the network edge.
49
Figure 9 Carrier Supporting Carrier Network
10.7.0.0
10.8.0.0
10.9.0.0
10.1.0.0 10.4.0.0
10.2.0.0 10.5.0.0
10.3.0.0 10.6.0.0
CSC-PE1 CSC-PE2
72K-36-9 72K-36-5
P1 P2
75K-37-3 75K-38-3
10.15.0.0 10.18.0.0
10.16.0.0 10.19.0.0
10.17.0.0 Backbone carrier 10.20.0.0
CSC-CE1 CSC-CE2
72K-36-8 Customer Customer 72K-36-4
carrier carrier
10.10.0.0 10.11.0.0
10.12.0.0
10.13.0.0
PE1 PE2
72K-36-7 72K-36-6
10.35.0.0 CE1 CE2

36K-36-1 36K-38-4
51562
10.29.0.0
10.14.0.0
CE3
36K-38-5
Backbone Carrier Configuration

ip cef
!
ip vrf vpn1
rd 100:0
!
!
interface Loopback0
ip address 10.14.14.14 255.255.255.255
no ip route-cache
no ip mroute-cache
!
50
ip address 10.22.22.22 255.255.255.255

!
interface ATM1/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.1.0.1 255.255.0.0
tag-switching ip
!
ip address 10.2.0.1 255.255.0.0
tag-switching ip
!
ip address 10.3.0.1 255.255.0.0
tag-switching ip
!
interface ATM2/0
no ip address
no ip mroute-cache
atm clock INTERNAL
!
ip address 10.15.0.2 255.255.0.0
tag-switching ip
!
ip address 10.16.0.2 255.255.0.0
tag-switching ip
!
ip address 10.17.0.2 255.255.0.0
51
tag-switching ip
!
router ospf 100
passive-interface ATM2/0.1
network 10.14.14.14 0.0.0.0 area 100
network 10.1.0.0 0.0.255.255 area 100
network 10.2.0.0 0.0.255.255 area 100
network 10.3.0.0 0.0.255.255 area 100
!
network 10.22.22.22 0.0.0.0 area 200
network 10.15.0.0 0.0.255.255 area 200
network 10.16.0.0 0.0.255.255 area 200
network 10.17.0.0 0.0.255.255 area 200
!
router bgp 100
timers bgp 10 30
!
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
P1 (75K-37-3) Configuration
ip cef distributed
!
!
interface Loopback0
ip address 10.12.12.12 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/1/0
52
no ip address
atm clock INTERNAL
!
ip address 10.7.0.1 255.255.0.0
tag-switching ip
!
ip address 10.8.0.1 255.255.0.0
tag-switching ip
!
ip address 10.9.0.1 255.255.0.0
tag-switching ip
!
interface ATM3/0/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.1.0.2 255.255.0.0
mpls accounting experimental input
tag-switching ip
!
ip address 10.2.0.2 255.255.0.0
tag-switching ip
!
ip address 10.3.0.2 255.255.0.0
tag-switching ip
53
!
router ospf 100
network 10.12.12.12 0.0.0.0 area 100
network 10.1.0.0 0.0.255.255 area 100
network 10.2.0.0 0.0.255.255 area 100
network 10.3.0.0 0.0.255.255 area 100
network 10.7.0.0 0.0.255.255 area 100
network 10.8.0.0 0.0.255.255 area 100
network 10.9.0.0 0.0.255.255 area 100
P2 (75K-38-3) Configuration
ip cef distributed
!
!
interface Loopback0
ip address 10.13.13.13 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM0/1/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.7.0.2 255.255.0.0
tag-switching ip
!
ip address 10.8.0.2 255.255.0.0
tag-switching ip
!
ip address 10.9.0.2 255.255.0.0
tag-switching ip
!
interface ATM3/1/0
no ip address
atm clock INTERNAL
atm sonet stm-1
54
!
ip address 10.4.0.2 255.255.0.0
tag-switching ip
!
ip address 10.5.0.2 255.255.0.0
tag-switching ip
!
ip address 10.6.0.2 255.255.0.0
tag-switching ip
!
router ospf 100
network 10.13.13.13 0.0.0.0 area 100
network 10.4.0.0 0.0.255.255 area 100
network 10.5.0.0 0.0.255.255 area 100
network 10.6.0.0 0.0.255.255 area 100
network 10.7.0.0 0.0.255.255 area 100
network 10.8.0.0 0.0.255.255 area 100
network 10.9.0.0 0.0.255.255 area 100
!

ip cef
!
ip vrf vpn1
rd 100:0
!
interface Loopback0
ip address 10.11.11.11 255.255.255.255
no ip route-cache
no ip mroute-cache
!
ip address 10.23.23.23 255.255.255.255
!
interface ATM5/0
no ip address
55
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.18.0.2 255.255.0.0
tag-switching ip
!
ip address 10.19.0.2 255.255.0.0
tag-switching ip
!
ip address 10.20.0.2 255.255.0.0
tag-switching ip
!
interface ATM6/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.4.0.1 255.255.0.0
tag-switching ip
!
ip address 10.5.0.1 255.255.0.0
tag-switching ip
!
ip address 10.6.0.1 255.255.0.0
56
tag-switching ip
!
router ospf 100
network 10.11.11.11 0.0.0.0 area 100
network 10.4.0.0 0.0.255.255 area 100
network 10.5.0.0 0.0.255.255 area 100
network 10.6.0.0 0.0.255.255 area 100
!
network 10.23.23.23 0.0.0.0 area 200
network 10.18.0.0 0.0.255.255 area 200
network 10.19.0.0 0.0.255.255 area 200
network 10.20.0.0 0.0.255.255 area 200
!
router bgp 100
timers bgp 10 30
!
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family

ip cef
!
!
interface Loopback0
ip address 10.15.15.15 255.255.255.255
no ip route-cache
no ip mroute-cache
!
interface ATM1/0
no ip address
57
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.15.0.1 255.255.0.0
tag-switching ip
!
ip address 10.16.0.1 255.255.0.0
tag-switching ip
!
ip address 10.17.0.1 255.255.0.0
tag-switching ip
!
ip address 10.10.0.2 255.255.0.0
no ip mroute-cache
tag-switching ip
!
router ospf 200
network 10.15.15.15 0.0.0.0 area 200
network 10.10.0.0 0.0.255.255 area 200
network 10.15.0.0 0.0.255.255 area 200
network 10.16.0.0 0.0.255.255 area 200
network 10.17.0.0 0.0.255.255 area 200

ip cef
!
ip vrf customersite
rd 200:1
!
interface Loopback0
ip address 10.16.16.16 255.255.255.255
no ip route-cache
no ip mroute-cache
!
58
ip vrf forwarding customersite
ip address 10.35.0.2 255.255.0.0
no ip mroute-cache
!
ip address 30.10.0.1 255.255.0.0
no ip mroute-cache
tag-switching ip
!
router ospf 200
network 10.16.16.16 0.0.0.0 area 200
network 10.10.0.0 0.0.255.255 area 200
!
router bgp 200
timers bgp 10 30
!
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
address-family ipv4 vrf customersite
no auto-summary
no synchronization
exit-address-family

ip cef
!
interface Loopback0
ip address 10.19.19.19 255.255.255.255
!
ip address 30.35.0.1 255.255.0.0
!
router ospf 300
59
network 10.19.19.19 0.0.0.0 area 300
!
router bgp 300
no synchronization
timers bgp 10 30
no auto-summary

ip cef
!
!
interface Loopback0
ip address 10.17.17.17 255.255.255.255
!
interface ATM5/0
no ip address
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.11.0.2 255.255.0.0
tag-switching ip
!
ip address 10.12.0.2 255.255.0.0
tag-switching ip
!
ip address 10.13.0.2 255.255.0.0
tag-switching ip
!
interface ATM6/0
no ip address
atm clock INTERNAL
atm sonet stm-1
60
!
ip address 10.18.0.1 255.255.0.0
tag-switching ip
!
ip address 10.19.0.1 255.255.0.0
tag-switching ip
!
ip address 10.20.0.1 255.255.0.0
tag-switching ip
!
router ospf 200
network 10.17.17.17 0.0.0.0 area 200
network 10.11.0.0 0.0.255.255 area 200
network 10.12.0.0 0.0.255.255 area 200
network 10.13.0.0 0.0.255.255 area 200
network 10.18.0.0 0.0.255.255 area 200
network 10.19.0.0 0.0.255.255 area 200
network 10.20.0.0 0.0.255.255 area 200

ip cef
!
ip vrf customersite
rd 200:1
!
interface Loopback0
ip address 10.18.18.18 255.255.255.255
no ip route-cache
no ip mroute-cache
!
ip address 10.29.0.2 255.255.0.0
!
ip address 10.30.0.2 255.255.0.0
61
!
interface ATM5/0
no ip address
no ip mroute-cache
atm clock INTERNAL
atm sonet stm-1
!
ip address 10.11.0.1 255.255.0.0
tag-switching ip
!
ip address 10.12.0.1 255.255.0.0
tag-switching ip
!
ip address 10.13.0.1 255.255.0.0
tag-switching ip
!
router ospf 200
network 10.18.18.18 0.0.0.0 area 200
network 10.11.0.0 0.0.255.255 area 200
network 10.12.0.0 0.0.255.255 area 200
network 10.13.0.0 0.0.255.255 area 200
!
router bgp 200
timers bgp 10 30
!
address-family ipv4
no synchronization
exit-address-family
!
exit-address-family
!
address-family ipv4 vrf customersite
62

no auto-summary
no synchronization
exit-address-family

ip cef
!
interface Loopback0
ip address 10.21.21.21 255.255.255.255
!
ip address 10.29.0.1 255.255.0.0
!
ip address 10.14.0.1 255.255.0.0
!
router ospf 300
network 10.21.21.21 0.0.0.0 area 300
network 10.14.0.0 0.0.255.255 area 300
!
router bgp 300
no synchronization
timers bgp 10 30
no auto-summary

ip cef
!
interface Loopback0
ip address 10.20.20.20 255.255.255.255
!
ip address 10.30.0.1 255.255.0.0
!
ip address 10.14.0.2 255.255.0.0
!
router ospf 300
network 10.20.20.20 0.0.0.0 area 300
63
network 10.14.0.0 0.0.255.255 area 300

!
router bgp 300
no synchronization
timers bgp 10 30
no auto-summary
Related Documents
Standards
Standard Title
64
Command Reference
MIBs
MIB MIBs Link
RFCs
RFC Title
Description Link
Command Reference
65
Feature Information for MPLS VPN CSC with LDP and IGP
Feature Information for MPLS VPN CSC with LDP and IGP
Table 4 Feature Information for MPLS VPN CSC with LDP and IGP

MPLS VPN Carrier Supporting Carrier 12.0(14)ST This feature enables you to set up and create an
12.0(16)ST MPLS VPN CSC network that uses LDP to
12.2(8)T transport MPLS labels and an IGP to transport
12.0(21)ST routes.
12.0(22)S
In 12.0(14)ST, this feature was introduced.
12.0(23)S
In 12.0(16)ST, this feature was integrated.
In 12.0(21)ST, this feature was integrated.
Glossary
ASBR autonomous system boundary router. A router that connects one autonomous system to another.
carrier suporting carrierA situation where one service provider allows another service provider to
use a segment of its backbone network.
provider edge (PE) router. In this document, the CE roter sits on the edge of the customer carrier
network.
edge routerA router that is at the edge of the network. It defines the boundary of the MPLS network.
It receives and transmits packets. Also referred to as edge label switch router and label edge router.
66
Glossary
autonomous system.
MPLSMultiprotocol Label Switching. 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.
PE routerprovider edge router. A router, at the edge of a service providers network, that interfaces
to CE routers.
coincidental.
67
Glossary
68

Multiprotocol Label Switching (MPLS) Virtual Private Network (VPN) Carrier Supporting Carrier
(CSC) enables one MPLS VPN-based service provider to allow other service providers to use a segment
of its backbone network. This module explains how to configure an MPLS VPN CSC network that uses
Border Gateway Protocol (BGP) to distribute routes and MPLS labels.

supported, see the Feature Information for MPLS VPN CSC with BGP section on page 50.
Contents
Prerequisites for MPLS VPN CSC with BGP, page 2
Restrictions for MPLS VPN CSC with BGP, page 2
Information About MPLS VPN CSC with BGP, page 2
How to Configure MPLS VPN CSC with BGP, page 5
Configuration Examples for MPLS VPN CSC with BGP, page 32
Feature Information for MPLS VPN CSC with BGP, page 50
Glossary, page 51
Prerequisites for MPLS VPN CSC with BGP
Prerequisites for MPLS VPN CSC with BGP

You should be able to configure MPLS VPNs with end-to-end (CE-to-CE router) pings working. To
accomplish this, you need to know how to configure Interior Gateway Protocols (IGPs), MPLS
Label Distribution Protocol (LDP), and Multiprotocol Border Gateway Protocol (MP-BGP).
Make sure that the CSC-PE routers and the CSC-CE routers run images that support BGP label
distribution. Otherwise, you cannot run external BGP (EBGP) between them. Ensure that
connectivity between the customer carrier and the backbone carrier. EBGP-based label distribution
is configured on these links to enable MPLS between the customer and backbone carriers.
Restrictions for MPLS VPN CSC with BGP

On a provider edge (PE) router, you can configure an interface for either BGP with labels or LDP. You
cannot enable both types of label distribution on the same interface. If you switch from one protocol to
the other, then you must disable the existing protocol on all interfaces before enabling the other protocol.
This feature does not support the following:
EBGP multihop between CSC-PE and CSC-CE routers
EIBGP multipath load sharing
The physical interfaces that connect the BGP speakers must support Cisco Express Forwarding or
distributed Cisco Express Forwarding and MPLS.
Information About MPLS VPN CSC with BGP

Before configuring MPLS VPN CSC, you should understand the following concepts:
MPLS VPN CSC Introduction, page 2
Benefits of Implementing MPLS VPN CSC, page 3
Benefits of Implementing MPLS VPN CSC with BGP, page 3
Configuration Options for MPLS VPN CSC with BGP, page 4
MPLS VPN CSC Introduction

Carrier supporting carrier is where one service provider allows another service provider to use a segment
of its backbone network. The service provider that provides the segment of the backbone network to the
other provider is called the backbone carrier. The service provider that uses the segment of the backbone
network is called the customer carrier.
A backbone carrier offers Border Gateway Protocol and Multiprotocol Label Switching (BGP/MPLS)
VPN services. The customer carrier can be either:
An Internet service provider (ISP)
A BGP/MPLS VPN service provider
2
Benefits of Implementing MPLS VPN CSC

The MPLS VPN CSC network provides the following benefits to service providers who are backbone
carriers and to customer carriers.
Benefits to the Backbone Carrier

The backbone carrier can accommodate many customer carriers and give them access to its
backbone. The backbone carrier does not need to create and maintain separate backbones for its
customer carriers. Using one backbone network to support multiple customer carriers simplifies the
backbone carriers VPN operations. The backbone carrier uses a consistent method for managing
and maintaining the backbone network. This is also cheaper and more efficient than maintaining
separate backbones.
The MPLS VPN carrier supporting carrier feature is scalable. Carrier supporting carrier can change
the VPN to meet changing bandwidth and connectivity needs. The feature can accommodate
unplanned growth and changes. The carrier supporting carrier feature enables tens of thousands of
VPNs to be set up over the same network, and it allows a service provider to offer both VPN and
Internet services.
The MPLS VPN carrier supporting carrier feature is a flexible solution. The backbone carrier can
accommodate many types of customer carriers. The backbone carrier can accept customer carriers
who are ISPs or VPN service providers or both. The backbone carrier can accommodate customer
carriers that require security and various bandwidths.
Benefits to the Customer Carriers

The MPLS VPN carrier supporting carrier feature removes from the customer carrier the burden of
configuring, operating, and maintaining its own backbone. The customer carrier uses the backbone
network of a backbone carrier, but the backbone carrier is responsible for network maintenance and
operation.
Customer carriers who use the VPN services provided by the backbone carrier receive the same level
of security that Frame Relay or ATM-based VPNs provide. Customer carriers can also use IPSec in
their VPNs for a higher level of security; it is completely transparent to the backbone carrier.
Customer carriers can use any link layer technology (SONET, DSL, Frame Relay, and so on) to
connect the CE routers to the PE routers and the PE routers to the P routers. The MPLS VPN carrier
supporting carrier feature is link layer independent. The CE routers and PE routers use IP to
communicate, and the backbone carrier uses MPLS.
The customer carrier can use any addressing scheme and still be supported by a backbone carrier.
The customer address space and routing information are independent of the address space and
routing information of other customer carriers or the backbone provider.
Benefits of Implementing MPLS VPN CSC with BGP

You can configure your CSC network to enable BGP to transport routes and MPLS labels between the
backbone carrier PE routers and the customer carrier CE routers using multiple paths. The benefits of
using BGP to distribute IPv4 routes and MPLS label routes are:
BGP takes the place of an IGP and LDP in a VPN forwarding/routing instance (VRF) table. You can
use BGP to distribute routes and MPLS labels. Using a single protocol instead of two simplifies the
configuration and troubleshooting.
3
BGP is the preferred routing protocol for connecting two ISPs, mainly because of its routing policies
and ability to scale. ISPs commonly use BGP between two providers. This feature enables those
ISPs to use BGP.
Configuration Options for MPLS VPN CSC with BGP

The backbone carrier offers BGP and MPLS VPN services. The customer carrier can be either of the
following:
Customer Carrier Is an ISP with an IP Core, page 4
Customer Carrier Is an MPLS Service Provider With or Without VPN Services, page 4
The following sections explain how the backbone and customer carriers distribute IPv4 routes and MPLS
labels.
Customer Carrier Is an ISP with an IP Core

Figure 1 shows a network configuration where the customer carrier is an ISP. The customer carrier has
two sites, each of which is a point of presence (POP). The customer carrier connects these sites using a
VPN service provided by the backbone carrier. The backbone carrier uses MPLS. The ISP sites use IP.
Figure 1 Network Where the Customer Carrier Is an ISP
50846
IP MPLS IP
The links between the CE and PE routers use EBGP to distribute IPv4 routes and MPLS labels. Between
the links, the PE routers use multiprotocol IBGP to distribute VPNv4 routes.
Note If a router other than a Cisco router is used as a CSC-PE or CSC-CE, that router must support IPv4 BGP
label distribution (RFC 3107). Otherwise, you cannot run EBGP with labels between the routers.
Customer Carrier Is an MPLS Service Provider With or Without VPN Services

Figure 2 shows a network configuration where the backbone carrier and the customer carrier are
BGP/MPLS VPN service providers. This is known as hierarchical VPNs. The customer carrier has two
sites. Both the backbone carrier and the customer carrier use MPLS in their networks.
4
How to Configure MPLS VPN CSC with BGP
Figure 2 Network Where the Customer Carrier Is an MPLS VPN Service Provider
MP-IBGP exchanging VPNv4 prefixes
IPv4 + IPv4 +
labels labels
CE1 PE1 CSC-CE1 CSC-PE1 CSC-PE2 CSC-CE2 PE2 CE2
Customer carrier Backbone carrier Customer carrier
65682
MPLS VPN SP MPLS VPN SP MPLS VPN SP
In this configuration, the customer carrier can configure its network in one of the following ways:
The customer carrier can run IGP and LDP in its core network. In this case, the CSC-CE1 router in
the customer carrier redistributes the EBGP routes it learns from the CSC-PE1 router of the
backbone carrier to IGP.
The CSC-CE1 router of the customer carrier system can run an IPv4 and labels IBGP session with
the PE1 router.

Identifying the Carrier Supporting Carrier Topology, page 5 (required)
Configuring the Backbone Carrier Core, page 6 (required)
Configuring the CSC-PE and CSC-CE Routers, page 12 (required)
Configuring the Customer Carrier Network, page 21 (required)
Configuring the Customer Site for Hierarchical VPNs, page 24 (required)
Identifying the Carrier Supporting Carrier Topology

Before you configure the MPLS VPN CSC with BGP, you need to identify both the backbone and
customer carrier topology.
For hierarchical VPNs, the customer carrier of the MPLS VPN network provides MPLS VPN services
to its own customers. In this instance, you need to identify the type of customer carrier as well as the
topology of the customer carriers. Hierarchical VPNs require extra configuration steps, which are noted
in the configuration sections.
Note You can connect multiple CSC-CE routers to the same PE, or you can connect a single CSC-CE router
to CSC-PEs using more than one interface to provide redundancy and multiple path support in CSC
topology.
Perform this task to identify the carrier supporting carrier topology.
5
SUMMARY STEPS
1. Identify the type of customer carrier, ISP or MPLS VPN service provider.
2. (For hierarchical VPNs only) Identify the CE routers.
3. (For hierarchical VPNs only) Identify the customer carrier core router configuration.
4. Identify the customer carrier edge (CSC-CE) routers.
5. Identify backbone carrier router configuration.
DETAILED STEPS

Step 1 Identify the type of customer carrier, ISP or MPLS Sets up requirements for configuration of carrier supporting
VPN service provider. carrier network.
For an ISP, customer site configuration is not required.
For an MPLS VPN service provider, the customer site
needs to be configured, as well as any task or step
designated for hierarchical VPNs only.
Step 2 (For hierarchical VPNs only) Identify the CE routers. Sets up requirements for configuration of CE to PE
connections.
Step 3 (For hierarchical VPNs only) Identify the customer Sets up requirements for connection configuration between
carrier core router configuration. core (P) routers and between P routers and edge routers (PE
and CSC-CE routers).
Step 4 Identify the customer carrier edge (CSC-CE) routers. Sets up requirements for configuration of CSC-CE to
CSC-PE connections.
Step 5 Identify the backbone carrier router configuration. Sets up requirements for connection configuration between
CSC core routers and between CSC core routers and edge
routers (CSC-CE and CSC-PE routers).
What to Do Next
Set up your carrier supporting carrier networks with the Configuring the Backbone Carrier Core
section on page 6.
Configuring the Backbone Carrier Core

Configuring the backbone carrier core requires setting up connectivity and routing functions for the CSC
core and the CSC-PE routers.
Configuring and verifying the CSC core (backbone carrier) involves the following tasks:
Verifying IP Connectivity and LDP Configuration in the CSC Core, page 7 (optional)
Configuring VRFs for CSC-PE Routers, page 8 (required)
Configuring Multiprotocol BGP for VPN Connectivity in the Backbone Carrier, page 10 (required)
6
Prerequisites
Before you configure a backbone carrier core, configure the following on the CSC core routers:
An IGP routing protocolBGP, OSPF, IS-IS, EIGRP, static, and so on.
Label Distribution Protocol (LDP). For information, see How to Configure MPLS LDP.
Verifying IP Connectivity and LDP Configuration in the CSC Core

Perform this task to verify IP connectivity and LDP configuration in the CSC core.
SUMMARY STEPS
1. enable
4. show mpls forwarding-table [vrf vrf-name] [{network {mask | length} | labels label [- label] |
5. show mpls ldp discovery [vrf vrf-name | all]
6. show mpls ldp neighbor [[vrf vrf-name] [address | interface] [detail] | all]
8. show mpls interfaces [[vrf vrf-name] [interface] [detail] | all]
9. show ip route
10. disable
DETAILED STEPS

Example:
Router> enable
Step 2 ping [protocol] {host-name | system-address} (Optional) Diagnoses basic network connectivity on
AppleTalk, CLNS, IP, Novell, Apollo, VINES, DECnet, or
XNS networks.
Example:
Router# ping ip 10.1.0.0 Use the ping ip command to verify the connectivity
from one CSC core router to another.
Step 3 trace [protocol] [destination] (Optional) Discovers the routes that packets will actually
take when traveling to their destination.
7

Step 4 show mpls forwarding-table [vrf vrf-name] (Optional) Displays the contents of the MPLS label
[{network {mask | length} | labels label forwarding information base (LFIB).
[- label] | interface interface | next-hop
address | lsp-tunnel [tunnel-id]}] [detail] Use the show mpls forwarding-table command to
verify that MPLS packets are being forwarded.
Example:
Step 5 show mpls ldp discovery [vrf vrf-name | all] (Optional) Displays the status of the LDP discovery
process.
Example: Use the show mpls ldp discovery command to verify
Router# show mpls ldp discovery that LDP is operational in the CSC core.
Step 6 show mpls ldp neighbor [[vrf vrf-name] [address (Optional) Displays the status of LDP sessions.
| interface] [detail] | all]
Use the show mpls ldp neighbor command to verify
LDP configuration in the CSC core.
Example:
Step 7 show ip cef [vrf vrf-name] [network [mask]] (Optional) Displays entries in the forwarding information
[longer-prefixes] [detail] base (FIB).
Use the show ip cef command to check the forwarding
Example: table (prefixes, next hops, and interfaces).
Router# show ip cef
Step 8 show mpls interfaces [[vrf vrf-name] (Optional) Displays information about one or more or all
[interface] [detail] | all] interfaces that are configured for label switching.
Use the show mpls interfaces command to verify that
Example: the interfaces are configured to use LDP.
Step 9 show ip route (Optional) Displays IP routing table entries.
Example: routing table, including host IP address, next hop,
Router# show ip route interface, and so forth.
Step 10 disable (Optional) Returns to privileged EXEC mode.
Example:
Router# disable
You can use the ping and trace commands to verify complete MPLS connectivity in the core. You also
get useful troubleshooting information from the additional show commands.
Configuring VRFs for CSC-PE Routers

Perform this task to configure VPN forwarding/routing instances (VRFs) for the backbone carrier edge
(CSC-PE) routers.
8
SUMMARY STEPS
1. enable
3. ip vrf vrf-name
7. exit
10. end
DETAILED STEPS

Example:
Router> enable
Example:
example, 101:3
192.168.122.15:1
9

Example:
extended community.
Example:
Step 8 interface type number Specifies the interface to configure.
The type argument specifies the type of interface to be
Router(config)# interface Ethernet5/0
subinterface.
Enter a show ip vrf detail command and make sure the MPLS VPN is up and associated with the right
interfaces.
Configuring Multiprotocol BGP for VPN Connectivity in the Backbone Carrier

Perform this task to configure Multiprotocol BGP (MP-BGP) connectivity in the backbone carrier.
SUMMARY STEPS
1. enable
10
10. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
neighbors.
Example: Use the no form of the bgp default-unicast command
Router(config-router)# no bgp default if you are using this neighbor for MPLS routes only.
ipv4-unicast
Example: neighbor.
BGP peer group.
11

Step 6 neighbor {ip-address | peer-group-name} Allows BGP sessions to use a specific operational interface
update-source interface-type for TCP connections.
update-source loopback0 The peer-group-name argument specifies the name of a
BGP peer group.
The interface-type argument specifies the interface to
be used as the source.
address prefixes.
Example:
address prefixes.
BGP peer group.
Example: neighbor.
BGP peer group.
Example:
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.
Configuring the CSC-PE and CSC-CE Routers

Perform the following tasks to configure and verify links between a CSC-PE router and the carrier
CSC-CE router for an MPLS VPN CSC network that uses BGP to distribute routes and MPLS labels.
Configuring CSC-PE Routers, page 13 (required)
Configuring CSC-CE Routers, page 15 (required)
Verifying Labels in the CSC-PE Routers, page 17 (optional)
12
Verifying Labels in the CSC-CE Routers, page 19 (optional)

Figure 3 shows the configuration for the peering with directly connected interfaces between CSC-PE and
CSC-CE routers. This configuration is used as the example in the tasks that follow.
Figure 3 Configuration for Peering with Directly Connected Interfaces Between CSC-PE and
CSC-CE Routers
e1/0 e1/0
121190
10.0.0.1 10.0.0.2
CSC-CE CSC-PE
Configuring CSC-PE Routers

Perform this task to configure the CSC-PE routers.
SUMMARY STEPS
1. enable
7. neighbor ip-address as-override
10. end
DETAILED STEPS

Example:
Router> enable
Example:
13

configuration mode.
Step 4 address-family ipv4 [multicast | unicast | vrf Specifies the IPv4 address family type and enters address
vrf-name] family configuration mode.
The multicast keyword specifies IPv4 multicast
Example: address prefixes.
vpn1 The unicast keyword specifies IPv4 unicast address
prefixes.
name of the VRF to associate with subsequent IPv4
address family configuration mode commands.
Example: neighbor.
BGP peer group.
Example: neighbor.
BGP peer group.
Step 7 neighbor ip-address as-override Configures a PE router to override the autonomous system
number (ASN) of a site with the ASN of a provider.
Router(config-router-af)# neighbor 10.0.0.2 router that is to be overridden with the ASN provided.
as-override
Router(config-router-af)# neighbor 10.0.0.2 neighboring router.
send-label
14

Example:
Example:
Enter a show ip bgp neighbor command to verify that the neighbors are up and running. Make sure you
see the following line in the command output under Neighbor capabilities:
IPv4 MPLS Label capability:advertised and received
Configuring CSC-CE Routers

Perform this task to configure the CSC-CE routers.
SUMMARY STEPS
1. enable
5. redistribute protocol
10. end
15
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Router(config-router)# address-family ipv4
prefixes.
Step 5 redistribute protocol Redistributes routes from one routing domain into another
routing domain.
Example: The protocol argument specifies the source protocol
Router(config-router-af)# redistribute static from which routes are being redistributed. It can be one
of the following keywords: bgp, egp, igrp, isis, ospf,
mobile, static [ip], connected, and rip.
The static [ip] keyword redistributes IP static
routes. The optional ip keyword is used when you
redistribute static routes into IS-IS.
The connected keyword refers to routes which are
established automatically when IP is enabled on an
interface. For routing protocols such as OSPF and
IS-IS, these routes are redistributed as external to
the autonomous system.
16

Example: neighbor.
BGP peer group.
Example: neighbor.
BGP peer group.
send-label
Step 9 exit-address-family Exits from the address family configuration mode.
Example:
Example:
Verifying Labels in the CSC-PE Routers

Perform this task to verify the labels in the CSC-PE routers.
SUMMARY STEPS
1. enable
3. show mpls interfaces [all]
8. traceroute vrf [vrf-name] ip-address
17
9. disable
DETAILED STEPS

Example:
Router> enable
Use the show ip bgp vpnv4 all summary command to
Example: check that the BGP session is up and running between
Router# show ip bgp vpnv4 all summary the CSC-PE routers and the CSC-CE routers. Check the
data in the State/PfxRcd column to verify that prefixes
are learned during each session.
Step 3 show mpls interfaces [all] (Optional) Displays information about one or more
interfaces that have been configured for label switching.
Example: Use the show mpls interfaces all command to check
Router# show mpls interfaces all that MPLS interfaces are up and running, and that
LDP-enabled interfaces show that LDP is up and
running. Check that LDP is turned off on the VRF
because EBGP distributes the labels.
Step 4 show ip route vrf vrf-name [prefix] (Optional) Displays the IP routing table associated with a
VRF.
Example: Use the show ip route vrf command to check that the
Router# show ip route vrf vpn1 10.5.5.5 prefixes for the PE routers are in the routing table of the
CSC-PE routers.
Note If you have multiple paths configured between
CSC-PE and CSC-CE, verify that the multiple
routes for the same destination learned from the
CSC-CE are installed in the corresponding VRF
routing table.
Use the show ip bgp vpnv4 vrf vrf-name labels
Example: command to check that the prefixes for the customer
Router# show ip bgp vpnv4 vrf vpn1 labels carrier MPLS service provider networks are in the BGP
table and have the appropriate labels.
CSC-PE and CSC-CE, verify that the labels for the
same destination learned from the CSC-CE are
installed in the corresponding VRF routing table.
18

Step 6 show ip cef [vrf vrf-name] [network [mask]] (Optional) Displays entries in the forwarding information
[longer-prefixes] [detail] base (FIB) or displays a summary of the FIB.
Use the show ip cef vrf and the show ip cef vrf detail
Example: commands to check that the prefixes of the PE routers
Router# show ip cef vrf vpn1 10.1.0.0 detail are in the CEF table.
Step 7 show mpls forwarding-table [vrf vrf-name] (Optional) Displays the contents of the MPLS forwarding
[{network {mask | length} | labels label information base (LFIB).
address | lsp-tunnel [tunnel-id]}] [detail] Use the show mpls forwarding-table command with
the vrf keyword and both the vrf and detail keywords
to check that the prefixes for the PE routers in the local
Example:
customer MPLS VPN service provider are in the LFIB.
Router# show mpls forwarding-table vrf vpn1
10.1.0.0 detail Note If you have multiple paths configured between
CSC-PE and CSC-CE, verify that the labels for the
same destination learned from the CSC-CE are
installed in the corresponding VRF table.
Step 8 traceroute vrf [vrf-name] ip-address Shows the routes that packets follow traveling through a
network to their destination.
Example: Use the traceroute vrf command to check the data path
Router# traceroute vrf vpn2 10.2.0.0 and transport labels from a PE to a destination CE
router.
Note This command works with MPLS-aware traceroute
only if the backbone routers are configured to
propagate and generate IP Time to Live (TTL)
information. For more information, see the
documentation on the mpls ip propagate-ttl
command.

table.
Example:
Router# disable
Verifying Labels in the CSC-CE Routers

Perform this task to verify the labels in the CSC-CE routers.
SUMMARY STEPS
1. enable
2. show ip bgp summary
3. show ip route [address]
19
4. show mpls ldp bindings [network {mask | length}]

5. show ip cef [network [mask]] [longer-prefixes] [detail]
7. show ip bgp labels
DETAILED STEPS

Example:
Router> enable
Step 2 show ip bgp summary (Optional) Displays the status of all BGP connections.
Use the show ip bgp summary command to check that
Example: the BGP session is up and running on the CSC-CE
Router# show ip bgp summary routers.
Step 3 show ip route [address] (Optional) Displays IP routing table entries.
Use the show ip route command to check that the
Example: loopback address of the local and remote PE routers are
Router# show ip route 10.1.0.0 in the routing table.
table.
Step 4 show mpls ldp bindings [network {mask | (Optional) Displays the contents of the label information
length}] base (LIB).
Use the show mpls ldp bindings command to check
Example: that the prefix of the local PE router is in the MPLS
Router# show mpls ldp bindings 10.2.0.0 LDP bindings.
255.255.255.255
Step 5 show ip cef [network [mask]] [longer-prefixes] (Optional) Displays entries in the forwarding information
[detail] base (FIB) or a summary of the FIB.
Use the show ip cef and the show ip cef detail
Example: commands to check that the prefixes of the local and
Router# show ip cef 10.5.0.0 detail remote PE routers are in the Cisco Express Forwarding
table.
routes and the labels for the same destination
learned from the CSC-CE are installed in the
corresponding VRF table.
20

Step 6 show mpls forwarding-table [vrf vrf-name] (Optional) Displays the contents of the MPLS LFIB.
[- label] | interface interface | next-hop Use the show mpls forwarding-table and show mpls
address | lsp-tunnel [tunnel-id]}] [detail] forwarding-table detail commands to check that the
prefixes of the local and remote PE routers are in the
MPLS forwarding table.
Example:
Router# show mpls forwarding-table 10.2.0.0 Note If you have multiple paths configured between
detail CSC-PE and CSC-CE, verify that the multiple
routes and labels for the same destination learned
from the CSC-CE are installed in the corresponding
VRF routing table.
Step 7 show ip bgp labels (Optional) Displays information about MPLS labels from
the EBGP route table.
Example: Use the show ip bgp labels command to check that the
Router# show ip bgp labels BGP routing table contains labels for prefixes in the
customer carrier MPLS VPN service provider
networks.
Configuring the Customer Carrier Network

Perform the following tasks to configure and verify the customer carrier network. This requires setting
up connectivity and routing functions for the customer carrier core (P) routers and the customer carrier
edge (PE) routers.
Verifying IP Connectivity in the Customer Carrier, page 21 (optional)
Configuring a Customer Carrier Core Router as a Route Reflector, page 22 (optional)
Prerequisites
Before you configure an MPLS VPN CSC network that uses BGP to distribute routes and MPLS labels,
you must configure the following on your customer carrier routers:
An IGP routing protocolBGP, OSPF, IS-IS, EIGRP, static, and so on. For information, see
Configuring a Basic BGP Network, Configuring OSPF, Configuring a Basic IS-IS Network, and
Configuring EIGRP.
MPLS VPN functionality on the PE routers (for hierarchical VPNs only).
Label Distribution Protocol (LDP) on P and PE routers (for hierarchical VPNs only). For
information, see How to Configure MPLS LDP.
Note You must configure the items in the preceding list before performing the tasks in this section.
Verifying IP Connectivity in the Customer Carrier

Perform this task to verify IP connectivity in the customer carrier.
21
SUMMARY STEPS
1. enable
4. show ip route
5. disable
DETAILED STEPS

Example:
Router> enable
Step 2 ping [protocol] {host-name | system-address} Diagnoses basic network connectivity on AppleTalk,
CLNS, IP, Novell, Apollo, VINES, DECnet, or XNS
networks.
Example:
Router# ping ip 10.2.0.0 Use the ping command to verify the connectivity from
one customer carrier core router to another.
Step 3 trace [protocol] [destination] Discovers the routes that packets will actually take when
traveling to their destination.
Step 4 show ip route Displays IP routing table entries.
Example: routing table, including host IP address, next hop,
Router# show ip route interface, and so forth.
Step 5 disable Returns to user mode.
Example:
Router# disable
Configuring a Customer Carrier Core Router as a Route Reflector

Perform this task to configure a customer carrier core (P) router as a route reflector of multiprotocol BGP
prefixes.
SUMMARY STEPS
1. enable
22

9. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
BGP routers and labels the routing information passed
Example: neighbor.
BGP peer group.
address prefixes.
Example:
address prefixes.
23

Example: neighbor.
BGP peer group.
Step 7 neighbor ip-address route-reflector-client Configures the router as a BGP route reflector and
configures the specified neighbor as its client.
Router(config-router-af)# neighbor 10.1.1.1 BGP neighbor being identified as a client.
Example:
Example:
By default, neighbors that are defined using the neighbor remote-as command in router configuration
mode exchange only unicast address prefixes. For neighbors to exchange other address prefix types, such
as multicast and VPNv4, you must also activate neighbors using the neighbor activate command in
address family configuration mode, as shown.
Route reflectors and clients (neighbors or internal BGP peer groups) that are defined in router
configuration mode using the neighbor route-reflector-client command reflect unicast address prefixes
to and from those clients by default. To cause them to reflect prefixes for other address families, such as
multicast, define the reflectors and clients in address family configuration mode, using the neighbor
route-reflector-client command, as shown.
Configuring the Customer Site for Hierarchical VPNs
Note This section applies only to customer carrier networks that use BGP to distribute routes and MPLS
labels.
Perform the following tasks to configure and verify the customer site for hierarchical VPNs:
Defining VPNs on PE Routers for Hierarchical VPNs, page 25 (required)
Configuring BGP Routing Sessions on the PE Routers for Hierarchical VPNs, page 26 (required)
Verifying Labels in Each PE Router for Hierarchical VPNs, page 28 (optional)
Configuring CE Routers for Hierarchical VPNs, page 29 (required)
Verifying IP Connectivity in the Customer Site, page 31 (optional)
24
Note This section applies to hierarchical VPNs only.
Defining VPNs on PE Routers for Hierarchical VPNs

Perform this task to define VPNs on PE routers.
SUMMARY STEPS
1. enable
3. ip vrf vrf-name
8. exit
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip vrf vrf-name Creates a VRF routing table and a Cisco Express
Forwarding table and enters VRF configuration mode.
Example: The vrf-name argument is a name you assign to a VRF.
Example: to an IPv4 prefix to create a VPN IPv4 prefix.
25

Example:
Router(config-vrf)# route-target export 200:1
and export routing information to the target VPN
extended community.
Step 6 import map route-map Configures an import route map for a VRF.
Router(config-vrf)# import map map23
Step 7 ip vrf forwarding vrf-name Associates a VPN VRF instance with an interface or
subinterface.
Router(config-vrf)# ip vrf forwarding vpn2
Example:
Configuring BGP Routing Sessions on the PE Routers for Hierarchical VPNs

Perform this task to configure BGP routing sessions on the PE routers for PE-to-CE router
communication.
SUMMARY STEPS
1. enable
5. neighbor {ip address | peer-group-name} remote-as as-number
7. end
26
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Configures the router to run a BGP process and enters router
configuration mode.
multicast The unicast keyword specifies IPv4 unicast address
prefixes.
Example: neighbor.
BGP peer group.
27

activate router.
Example: neighbor.
BGP peer group.
Example:
Verifying Labels in Each PE Router for Hierarchical VPNs

Perform this task to verify labels in each PE router for hierarchical VPNs.
SUMMARY STEPS
1. enable
3. show mpls forwarding-table [vrf vrf-name] [prefix] [detail]
4. show ip cef [network [mask [longer-prefix]]] [detail]
5. show ip cef vrf vrf-name [ip-prefix]
6. exit
DETAILED STEPS

Example:
Router> enable
Step 2 show ip route vrf vrf-name [prefix] (Optional) Displays the IP routing table associated with a
VRF.
Example: Use the show ip route vrf command to check that the
Router# show ip route vrf vpn2 10.5.5.5 loopback addresses of the local and remote CE routers
are in the routing table of the PE routers.
Step 3 show mpls forwarding-table [vrf vrf-name] (Optional) Displays the contents of the LFIB.
[prefix] [detail]
Use the show mpls forwarding-table command to
check that the prefixes for the local and remote CE
Example: routers are in the MPLS forwarding table, and that the
Router# show mpls forwarding-table vrf vpn2 specified prefix is untagged.
10.1.0.0
28

Step 4 show ip cef [network [mask [longer-prefix]]] (Optional) Displays specific entries in the FIB based on IP
[detail] address information.
Use the show ip cef command to check that the prefixes
Example: of the local and remote PE routers are in the Cisco
Router# show ip cef 10.2.0.0 Express Forwarding table.
Step 5 show ip cef vrf vrf-name [ip-prefix] (Optional) Displays the Cisco Express Forwarding table
associated with a VRF.
Example: Use the show ip cef vrf command to check that the
Router# show ip cef vrf vpn2 10.3.0.0 prefix of the remote CE router is in the Cisco Express
Forwarding table.
Step 6 exit (Optional) Exits to user EXEC mode.
Example:
Router# exit
Configuring CE Routers for Hierarchical VPNs

Perform this task to configure CE routers for hierarchical VPNs. This configuration is the same as that
for an MPLS VPN that is not in a hierarchical topology.
SUMMARY STEPS
1. enable
6. exit
10. end
29
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef [distributed] Enables Cisco Express Forwarding on the route processor
card.
Example: The distributed keyword enables distributed Cisco
Router(config)# ip cef distributed Express Forwarding operation. Cisco Express
Forwarding information is distributed to the line cards.
Line cards perform express forwarding.
Note For the Cisco ASR 1000 Series Aggregation
Services Router, the distributed keyword is
required.
configuration mode.
Router(config)# interface loopback 0 configured.
A loopback interface indicates a software-only
interface that emulates an interface that is always
up. It is a virtual interface supported on all
platforms.
The number argument is the number of the loopback
interface that you want to create or configure. There is
no limit on the number of loopback interfaces you can
create.
Example: The mask argument is the mask for the associated IP
255.255.255.255
subnet.
address.
Example:
30

configuration mode.
routing domain.
Router(config-router)# redistribute connected from which routes are being redistributed. It can be one
of the following keywords: bgp, connected, egp, igrp,
isis, mobile, ospf, static [ip], or rip.
The connected keyword refers to routes that are
interface. For routing protocols such as Open Shortest
Path First (OSPF) and IS-IS, these routes are
redistributed as external to the autonomous system.
Step 9 neighbor {ip-address | peer-group-name} Adds the IP address of the neighbor in the remote
remote-as as-number autonomous system to the multiprotocol BGP neighbor
table of the local router.
Router(config-router)# neighbor 10.8.0.0 neighbor.
remote-as 100
BGP peer group.
Example:
Verifying IP Connectivity in the Customer Site

Perform this task to verify IP connectivity in the customer site.
SUMMARY STEPS
1. enable
2. show ip route [ip-address [mask] [longer-prefixes] | protocol [process-id] | list [access-list-number
| access-list-name] | static download]
5. disable
31
Configuration Examples for MPLS VPN CSC with BGP
DETAILED STEPS

Example:
Router> enable
Step 2 show ip route [ip-address [mask] (Optional) Displays the current state of the routing table.
[longer-prefixes] | protocol [process-id] |
list [access-list-number | access-list-name] | Use the show ip route ip-address command to check
static download] that the loopback addresses of the remote CE routers
learned through the PE router are in the routing table of
the local CE routers.
Example:
Router# show ip route 10.5.5.5
Step 3 ping [protocol] {host-name | system-address} Diagnoses basic network connectivity on Apollo,
AppleTalk, Connectionless Network Service (CLNS),
DECnet, IP, Novell IPX, VINES, or XNS networks.
Example:
Router# ping 10.5.5.5 Use the ping command to check connectivity between
customer site routers.
Step 4 trace [protocol] [destination] Discovers the routes that packets will actually take when
traveling to their destination.
Example: Use the trace command to follow the path of the
Router# trace ip 10.5.5.5 packets in the customer site.
To use nondefault parameters and invoke an extended
trace test, enter the trace command without a
destination argument. You will be stepped through a
dialog to select the desired parameters.
Example:
Router# disable

Configuration examples for the MPLS VPN CSC with BGP include the following:
Configuring the Backbone Carrier Core: Examples, page 33
Configuring the Links Between CSC-PE and CSC-CE Routers: Examples, page 36
Configuring the Customer Carrier Network: Examples, page 43
Configuring the Customer Site for Hierarchical VPNs: Examples, page 44
Figure 4 shows a sample CSC topology for exchanging IPv4 routes and MPLS labels. Use this figure as
a reference for configuring and verifying carrier supporting carrier routers to exchange IPv4 routes and
MPLS labels.
32
Figure 4 Sample CSC Topology for Exchanging IPv4 Routes and MPLS Labels

IPv4 + labels
with multipath
support
aa.aa bb.bb cc.cc dd.dd ee.ee gg.gg hh.hh jj.jj
IPv4 +
labels
CE1 PE1 CSC-CE1 CSC-PE1 CSC-PE2 CSC-CE2 PE2 CE2
Customer carrier Backbone carrier Customer carrier
62893
MPLS VPN SP MPLS VPN SP MPLS VPN SP
Table 1 describes the sample configuration shown in Figure 4.
Table 1 Description of Sample Configuration Shown in Figure 4
Routers Description
CE1 and CE2 Belong to an end customer. CE1 and CE2 routers exchange routes learned
from PE routers.
The end customer is purchasing VPN services from a customer carrier.
PE1 and PE2 Part of a customer carrier network that is configured to provide MPLS VPN
services. PE1 and PE2 are peering with a VPNv4 IBGP session to form an
MPLS VPN network.
CSC-CE1 and Part of a customer carrier network. CSC-CE1 and CSC-CE2 routers
CSC-CE2 exchange IPv4 BGP updates with MPLS labels and redistribute PE loopback
addressees to and from the IGP (OSPF in this example).
The customer carrier is purchasing carrier supporting carrier VPN services
from a backbone carrier.
CSC-PE1 and Part of the backbone carriers network configured to provide carrier
CSC-PE2 supporting carrier VPN services. CSC-PE1 and CSC-PE2 are peering with a
VPNv4 IP BGP session to form the MPLS VPN network. In the VRF,
CSC-PE1 and CSC-PE2 are peering with the CSC-CE routers, which are
configured for carrying MPLS labels with the routes, with an IPv4 EBGP
session.
Configuring the Backbone Carrier Core: Examples

Configuration and verification examples for the backbone carrier core included in this section are as
follows:
Verifying IP Connectivity and LDP Configuration in the CSC Core: Example, page 34
Configuring VRFs for CSC-PE Routers: Example, page 35
Configuring Multiprotocol BGP for VPN Connectivity in the Backbone Carrier: Example, page 35
33
Verifying IP Connectivity and LDP Configuration in the CSC Core: Example

Check that CSC-PE2 is reachable from CSC-PE1 by entering the following command on CSC-CE1:

Sending 5, 100-byte ICMP Echos to 10.5.5.5, timeout is 2 seconds:
!!!!!
Verify the path from CSC-PE1 to CSC-PE2 by entering the following command on CSC-CE1:
Router# trace 10.5.5.5

Tracing the route to 10.5.5.5
1 10.5.5.5 0 msec 0 msec *
Check that CSC-PE router prefixes are in the MPLS forwarding table:
Local Outgoing Prefix or Bytes tag Outgoing Next Hop

tag tag or VC Tunnel Id switched interface
16 2/nn dd.dd.dd.dd/32 0 AT2/1/0.1 point2point
17 16 bb.bb.bb.bb/32[V] 30204 Et1/0 pp.0.0.1
21 Pop tag cc.cc.cc.cc/32[V] 0 Et1/0 pp.0.0.1
22 Pop tag nn.0.0.0/8[V] 570 Et1/0 pp.0.0.1
23 Aggregate pp.0.0.0/8[V] 0
2 2/nn gg.gg.gg.gg/32[V] 0 AT3/0.1 point2point
8 2/nn hh.hh.hh.hh/32[V] 15452 AT3/0.1 point2point
29 2/nn qq.0.0.0/8[V] 0 AT3/0.1 point2point
30 2/nn ss.0.0.0/8[V] 0 AT3/0.1 point2point
Check the status of LDP discovery processes in the core:


ee.ee.ee.ee:0
Discovery Sources:
Interfaces:
ATM2/1/0.1 (ldp): xmit/recv
TDP Id: dd.dd.dd.dd:1
Check the status of LDP sessions in the core:

Peer LDP Ident: dd.dd.dd.dd:1; Local LDP Ident ee.ee.ee.ee:1

TCP connection: dd.dd.dd.dd.646 - ee.ee.ee.ee.11007
State: Oper; Msgs sent/rcvd: 20/21; Downstream on demand
Up time: 00:14:56
ATM2/1/0.1, Src IP addr: dd.dd.dd.dd
Check the forwarding table (prefixes, next-hops, and interfaces):

Router# show ip cef
Prefix Next Hop Interface

0.0.0.0/0 drop Null0 (default route handler entry)
34
0.0.0.0/32 receive
dd.dd.dd.dd/32 dd.dd.dd.dd ATM2/1/0.1
ee.ee.ee.ee/32 receive
224.0.0.0/4 drop
224.0.0.0/24 receive
255.255.255.255/32 receive
Note Also see the Verifying Labels in the CSC-CE Routers: Examples section on page 41.
Verify that interfaces are configured to use LDP:

Interface IP Tunnel Operational

Ethernet0/1 Yes (ldp) No Yes
Display the entire routing table, including host IP address, next hop, interface, and so forth:
Router# show ip route

i - IS-IS, L1 - IS-IS level-1, L2 - IS-IS level-2, ia - IS-IS inter area
dd.0.0.0/32 is subnetted, 1 subnets

O dd.dd.dd.dd [110/7] via dd.dd.dd.dd, 00:16:42, ATM2/1/0.1
ee.0.0.0/32 is subnetted, 1 subnets
C ee.ee.ee.ee is directly connected, Loopback0
Configuring VRFs for CSC-PE Routers: Example

The following example shows how to configure a VPN routing and forwarding (VRF) instance for a
CSC-PE router:
ip cef distributed
ip vrf vpn1
rd 100:1
route target both 100:1
!
Configuring Multiprotocol BGP for VPN Connectivity in the Backbone Carrier: Example
The following example shows how to configure Multiprotocol BGP (MP-BGP) for VPN connectivity in
the backbone carrier:
ip cef distributed
ip vrf vpn1
rd 100:1
route target both 100:1
hostname csc-pe1
35
!
router bgp 100
timers bgp 10 30
no auto-summary
!
bgp dampening 30
exit-address-family
!
router bgp 100
. . .
! (BGP IPv4 to CSC-CE router from CSC-PE router)
!
neighbor ss.0.0.2 remote-as 200
neighbor ss.0.0.2 activate
neighbor ss.0.0.2 as-override
neighbor ss.0.0.2 advertisement-interval 5
neighbor ss.0.0.2 send-label
no auto-summary
no synchronization
bgp dampening 30
exit-address-family
!
Configuring the Links Between CSC-PE and CSC-CE Routers: Examples

Configuring the CSC-PE Routers: Examples, page 36
Configuring the CSC-CE Routers: Examples, page 37
Verifying Labels in the CSC-PE Routers: Examples, page 38
Verifying Labels in the CSC-CE Routers: Examples, page 41
Configuring the CSC-PE Routers: Examples

The following example shows how to configure a CSC-PE router:
ip cef
!
ip vrf vpn1
rd 100:1
!
interface Loopback0
ip address dd.dd.dd.dd 255.255.255.255
!
ip address pp.0.0.2 255.0.0.0
!
36
interface ATM0/1/0
no ip address
atm clock INTERNAL
!
mpls atm vpi 2-5
mpls ip
!
router ospf 100
network dd.dd.dd.dd 0.0.0.0 area 100
!
router bgp 100
timers bgp 10 30
!
address-family vpnv4 !VPNv4 session with CSC-PE2
bgp dampening 30
exit-address-family
!
neighbor pp.0.0.1 remote-as 200
neighbor pp.0.0.1 activate
neighbor pp.0.0.1 as-override
neighbor pp.0.0.1 advertisement-interval 5
neighbor pp.0.0.1 send-label
no auto-summary
no synchronization
bgp dampening 30
exit-address-family
Configuring the CSC-CE Routers: Examples

The following example shows how to configure a CSC-CE router:
ip cef
!
!
interface Loopback0
ip address cc.cc.cc.cc 255.255.255.255
!
ip address pp.0.0.1 255.0.0.0
!
ip address nn.0.0.2 255.0.0.0
37
no ip mroute-cache
mpls ip
!
router ospf 200
redistribute connected subnets !Exchange routes
redistribute bgp 200 metric 3 subnets !learned from PE1
passive-interface ATM1/0
network cc.cc.cc.cc 0.0.0.0 area 200
network nn.0.0.0 0.255.255.255 area 200
!
router bgp 200
timers bgp 10 30
neighbor pp.0.0.2 remote-as 100
neighbor pp.0.0.2 update-source Ethernet3/0
no auto-summary
!
address-family ipv4
redistribute ospf 200 metric 4 match internal
neighbor pp.0.0.2 activate
neighbor pp.0.0.2 send-label
no auto-summary
no synchronization
bgp dampening 30
exit-address-family
Verifying Labels in the CSC-PE Routers: Examples

The following examples show how to verify the configurations of the CSC-PE routers.
Verify that the BGP session is up and running between the CSC-PE router and the CSC-CE router. Check
the data in the State/PfxRcd column to verify that prefixes are learned during each session.
Router# show ip bgp vpnv4 all summary
BBGP router identifier 10.5.5.5, local AS number 100

BGP table version is 52, main routing table version 52
12 network entries and 13 paths using 2232 bytes of memory
6 BGP path attribute entries using 336 bytes of memory
1 BGP AS-PATH entries using 24 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
Dampening enabled. 0 history paths, 0 dampened paths
BGP activity 16/4 prefixes, 27/14 paths, scan interval 5 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

10.5.5.5 4 100 7685 7686 52 0 0 21:17:04 6
10.0.0.2 4 200 7676 7678 52 0 0 21:16:43 7
Verify that the MPLS interfaces are up and running, and that LDP-enabled interfaces show that LDP is
up and running. LDP is turned off on the VRF because EBGP distributes the labels.
Router# show mpls interfaces all
38
Interface IP Tunnel Operational

GigabitEthernet6/0 Yes (ldp) No Yes
VRF vpn1:
Ethernet3/1 No No Yes
Verify that the prefix for the local PE router is in the routing table of the CSC-PE router:
Router# show ip route vrf vpn2 10.5.5.5

Known via "bgp 100", distance 20, metric 4
Tag 200, type external
Last update from pp.0.0.2 21:28:39 ago
* pp.0.0.2, from pp.0.0.2, 21:28:39 ago
AS Hops 1, BGP network version 0
Verify that the prefix for the remote PE router is in the routing table of the CSC-PE router:

Tag 200, type internal
* 10.1.0.0 (Default-IP-Routing-Table), from 10.1.0.0, 21:27:39 ago
Verify that the prefixes for the customer carrier MPLS VPN service provider networks are in the BGP
table, and have appropriate labels:
Router# show ip bgp vpnv4 vrf vpn2 labels

cc.cc.cc.cc/32 pp.0.0.2 22/imp-null
bb.bb.bb.bb/32 pp.0.0.2 27/20
hh.hh.hh.hh/32 ee.ee.ee.ee 34/35
gg.gg.gg.gg/32 ee.ee.ee.ee 30/30
nn.0.0.0 pp.0.0.2 23/imp-null
ss.0.0.0 ee.ee.ee.ee 33/34
pp.0.0.0 pp.0.0.2 25/aggregate(vpn1)
Verify that the prefix of the PE router in the local customer carrier MPLS VPN service provider is in the
Cisco Express Forwarding table:
Router# show ip cef vrf vpn2 10.1.0.0
10.1.0.0/32, version 19, cached adjacency pp.0.0.2

0 packets, 0 bytes
tag information set
local tag: 27
fast tag rewrite with Et3/1, pp.0.0.2, tags imposed {20}
via pp.0.0.2, 0 dependencies, recursive
next hop pp.0.0.2, Ethernet3/1 via pp.0.0.2/32
valid cached adjacency
tag rewrite with Et3/1, pp.0.0.2, tags imposed {20}
Router# show ip cef vrf vpn2 10.1.0.0 detail
39

0 packets, 0 bytes
tag information set
local tag: 27
Verify that the prefix of the PE router in the local customer carrier MPLS VPN service provider is in the
MPLS forwarding table:
Router# show mpls forwarding-table vrf vpn2 10.1.0.0

27 20 10.1.0.0/32[V] 958048 Et3/1 pp.0.0.2
Router# show mpls forwarding-table vrf vpn2 10.1.0.0 detail

27 20 10.1.0.0/32[V] 958125 Et3/1 pp.0.0.2
00B04A74A05400B0C26E10558847 00014000
VPN route: vpn1
Per-packet load-sharing, slots: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Verify that the prefix of the PE router in the remote customer carrier MPLS VPN service provider is in
the Cisco Express Forwarding table:
10.3.0.0/32, version 25, cached adjacency rr.0.0.2

0 packets, 0 bytes
tag information set
local tag: 34
fast tag rewrite with Gi6/0, rr.0.0.2, tags imposed {35}
via ee.ee.ee.ee, 0 dependencies, recursive
next hop rr.0.0.2, GigabitEthernet6/0 via ee.ee.ee.ee/32
tag rewrite with Gi6/0, rr.0.0.2, tags imposed {35}
Router# show ip cef vrf vpn2 10.3.0.0 detail
hh.hh.hh.hh/32, version 25, cached adjacency rr.0.0.2

0 packets, 0 bytes
tag information set
local tag: 34
fast tag rewrite with Gi6/0, rr.0.0.2, tags imposed {35}
via ee.ee.ee.ee, 0 dependencies, recursive
next hop rr.0.0.2, GigabitEthernet6/0 via ee.ee.ee.ee/32
tag rewrite with Gi6/0, rr.0.0.2, tags imposed {35}
Verify that the prefix of the PE router in the remote customer carrier MPLS VPN service provider is in
the MPLS forwarding table:
40

34 35 hh.hh.hh.hh/32[V] 139034 Gi6/0 rr.0.0.2
Router# show mpls forwarding-table vrf vpn2 10.3.0.0 detail

34 35 hh.hh.hh.hh/32[V] 139034 Gi6/0 rr.0.0.2
00B0C26E447000B0C26E10A88847 00023000
VPN route: vpn1
Verifying Labels in the CSC-CE Routers: Examples

The following examples show how to verify the configurations of the CSC-CE routers.
Verify that the BGP session is up and running:
Router# show ip bgp summary
BGP router identifier cc.cc.cc.cc, local AS number 200

BGP table version is 35, main routing table version 35
14 network entries and 14 paths using 2030 bytes of memory
3 BGP path attribute entries using 168 bytes of memory
1 BGP AS-PATH 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
Dampening enabled. 1 history paths, 0 dampened paths
BGP activity 17/67 prefixes, 29/15 paths, scan interval 60 secs
Neighbor V AS MsgRcvd MsgSent TblVer InQ OutQ Up/Down State/PfxRcd

pp.0.0.1 4 100 7615 7613 35 0 0 21:06:19 5
Verify that the loopback address of the local PE router is in the routing table:

Known via "ospf 200", distance 110, metric 101, type intra area
Redistributing via bgp 200
Advertised by bgp 200 metric 4 match internal
Last update from nn.0.0.1 on Ethernet4/0, 00:34:08 ago
* nn.0.0.1, from bb.bb.bb.bb, 00:34:08 ago, via Ethernet4/0
Verify that the loopback address of the remote PE router is in the routing table:

Redistributing via ospf 200
Advertised by ospf 200 metric 3 subnets
Last update from pp.0.0.1 00:45:16 ago
* pp.0.0.1, from pp.0.0.1, 00:45:16 ago
41
Verify that the prefix of the local PE router is in the MPLS LDP bindings:
Router# show mpls ldp bindings 10.1.0.0 255.255.255.255
tib entry: 10.1.0.0/32, rev 20

Verify that the prefix of the local PE router is in the Cisco Express Forwarding table:
Router# show ip cef 10.1.0.0
10.1.0.0/32, version 46, cached adjacency nn.0.0.1

0 packets, 0 bytes
tag information set
local tag: 20
via nn.0.0.1, Ethernet4/0, 0 dependencies
next hop nn.0.0.1, Ethernet4/0
unresolved
tag rewrite with Et4/0, nn.0.0.1, tags imposed {}
Verify that the prefix of the local PE router is in the MPLS forwarding table:
Router# show mpls forwarding-table 10.1.0.0

20 Pop tag bb.bb.bb.bb/32 893397 Et4/0 nn.0.0.1

20 Pop tag bb.bb.bb.bb/32 893524 Et4/0 nn.0.0.1
MAC/Encaps=14/14, MTU=1504, Tag Stack{}
00074F83685400B04A74A0708847
Verify that the BGP routing table contains labels for prefixes in the customer carrier MPLS VPN service
provider networks:
Router# show ip bgp labels
Network Next Hop In Label/Out Label

cc.cc.cc.cc/32 0.0.0.0 imp-null/exp-null
bb.bb.bb.bb/32 nn.0.0.1 20/exp-null
hh.hh.hh.hh/32 pp.0.0.1 26/34
gg.gg.gg.gg/32 pp.0.0.1 23/30
nn.0.0.0 0.0.0.0 imp-null/exp-null
ss.0.0.0 pp.0.0.1 25/33
pp.0.0.0 0.0.0.0 imp-null/exp-null
pp.0.0.1/32 0.0.0.0 16/exp-null
Verify that the prefix of the remote PE router is in the Cisco Express Forwarding table:

0 packets, 0 bytes
tag information set
local tag: 26
42

Verify that the prefix of the remote PE router is in the MPLS forwarding table:
Router# show mpls forwarding-table 10.5.5.5

26 34 hh.hh.hh.hh/32 81786 Et3/0 pp.0.0.1

26 34 hh.hh.hh.hh/32 81863 Et3/0 pp.0.0.1
00B0C26E105500B04A74A0548847 00022000
Configuring the Customer Carrier Network: Examples

Customer carrier configuration and verification examples in this section include:
Verifying IP Connectivity in the Customer Carrier: Example, page 43
Configuring a Customer Carrier Core Router as a Route Reflector: Example, page 44
Verifying IP Connectivity in the Customer Carrier: Example

Verify the connectivity from one customer carrier core router to another (from CE1 to CE2) by entering
the following command:

Sending 5, 100-byte ICMP Echos to jj.jj.jj.jj, timeout is 2 seconds:
!!!!!
Verify the path that a packet goes through on its way to its final destination from CE1 to CE2:

1 mm.0.0.2 0 msec 0 msec 4 msec

2 nn.0.0.2 [MPLS: Labels 20/21 Exp 0] 8 msec 8 msec 12 msec
3 pp.0.0.2 [MPLS: Labels 28/21 Exp 0] 8 msec 8 msec 12 msec
4 ss.0.0.1 [MPLS: Labels 17/21 Exp 0] 8 msec 8 msec 12 msec
6 tt.0.0.1 [AS 200] [MPLS: Label 21 Exp 0] 8 msec 8 msec 8 msec
7 tt.0.0.2 [AS 200] 8 msec 4 msec *
Verify the path that a packet goes through on its way to its final destination from CE2 to CE1:
43

1 tt.0.0.1 0 msec 0 msec 0 msec

2 qq.0.0.2 [MPLS: Labels 18/21 Exp 0] 8 msec 12 msec 12 msec
6 mm.0.0.2 [AS 200] [MPLS: Label 21 Exp 0] 12 msec 8 msec 12 msec
7 mm.0.0.1 [AS 200] 4 msec 4 msec *
Configuring a Customer Carrier Core Router as a Route Reflector: Example

The following example shows how to use an address family to configure internal BGP peer 10.1.1.1 as
a route-reflector client for both unicast and multicast prefixes:
router bgp 200
router bgp 100

neighbor xx.xx.xx.xx activate
neighbor xx.xx.xx.xx route-reflector-client
! xx.xx.xx,xx is a PE router
neighbor xx.xx.xx.xx send-community extended
exit address-family
! You need to configure your peer BGP neighbor.
Configuring the Customer Site for Hierarchical VPNs: Examples

This section contains the following configuration and verification examples for the customer site:
Configuring PE Routers for Hierarchical VPNs: Examples, page 44
Verifying Labels in Each PE Router for Hierarchical VPNs: Examples, page 45
Configuring CE Routers for Hierarchical VPNs: Examples, page 47
Verifying IP Connectivity in the Customer Site: Examples, page 47
Configuring PE Routers for Hierarchical VPNs: Examples

This example shows how to configure a PE router:
ip cef
!
ip vrf vpn2
rd 200:1
!
interface Loopback0
!
ip address nn.0.0.1 255.0.0.0
44
no ip mroute-cache
mpls ip
!
ip address mm.0.0.2 255.0.0.0
no ip mroute-cache
!
router ospf 200
network nn.0.0.0 0.255.255.255 area 200
!
router bgp 200
timers bgp 10 30
neighbor hh.hh.hh.hh remote-as 200
neighbor hh.hh.hh.hh update-source Loopback0
!
address-family vpnv4 !VPNv4 session with PE2
neighbor hh.hh.hh.hh activate
neighbor hh.hh.hh.hh send-community extended
bgp dampening 30
exit-address-family
!
neighbor mm.0.0.1 remote-as 300
neighbor mm.0.0.1 activate
neighbor mm.0.0.1 as-override
neighbor mm.0.0.1 advertisement-interval 5
no auto-summary
no synchronization
bgp dampening 30
exit-address-family
Verifying Labels in Each PE Router for Hierarchical VPNs: Examples

The following examples show how to verify the configuration of PE router in hierarchical VPNs.
Verify that the loopback address of the local CE router is in the routing table of the PE1 router:

Last update from mm.0.0.2 20:36:59 ago
* mm.0.0.2, from mm.0.0.2, 20:36:59 ago
Verify that the prefix for the local CE router is in the MPLS forwarding table, and that the prefix is
untagged:
45

23 Untagged aa.aa.aa.aa/32[V] 0 Et3/3 mm.0.0.2
Verify that the prefix of the remote PE router is in the Cisco Express Forwarding table:

0 packets, 0 bytes
tag information set
local tag: 31
fast tag rewrite with Et3/0, nn.0.0.2, tags imposed {26}
via nn.0.0.2, Ethernet3/0, 2 dependencies
next hop nn.0.0.2, Ethernet3/0
unresolved
tag rewrite with Et3/0, nn.0.0.2, tags imposed {26}
Verify that the loopback address of the remote CE router is in the routing table:

Tag 300, type internal
Last update from hh.hh.hh.hh 20:38:49 ago
* hh.hh.hh.hh (Default-IP-Routing-Table), from hh.hh.hh.hh, 20:38:49 ago
Verify that the prefix of the remote CE router is in the MPLS forwarding table, and that an outgoing
interface exists:

None 26 jj.jj.jj.jj/32 0 Et3/0 nn.0.0.2
Verify that the prefix of the remote CE router is in the Cisco Express Forwarding table:

0 packets, 0 bytes
tag information set
local tag: VPN route head
fast tag rewrite with Et3/0, nn.0.0.2, tags imposed {26 32}
via hh.hh.hh.hh, 0 dependencies, recursive
next hop nn.0.0.2, Ethernet3/0 via hh.hh.hh.hh/32
tag rewrite with Et3/0, nn.0.0.2, tags imposed {26 32}
Verify that the prefix of the local PE router is in the Cisco Express Forwarding table:
10.1.0.0/32, version 9, connected, receive

tag information set
local tag: implicit-null
46
Configuring CE Routers for Hierarchical VPNs: Examples

The following example shows how to configure a CE router:
ip cef distributed
interface Loopback0
ip address 10.3.0.0 255.255.255.255
!
ip address mm.0.0.1 255.0.0.0
!
router bgp 300
no synchronization
timers bgp 10 30
redistribute connected !Redistributing routes into BGP
neighbor mm.0.0.2 remote-as 200 !to send to PE1
neighbor mm.0.0.2 advertisement-interval 5
no auto-summary
Verifying IP Connectivity in the Customer Site: Examples

The following examples show how to verify IP connectivity at the customer site.
Verify that the loopback address of the remote CE router, learned from the PE router, is in the routing
table of the local router:

Redistributing via ospf 300
Advertised by ospf 300 subnets
Last update from mm.0.0.1 20:29:35 ago
* mm.0.0.1, from mm.0.0.1, 20:29:35 ago
AS Hops 2
The following sections provide information related to MPLS VPNs.
Related Documents
LDP MPLS Label Distribution Protocol
47
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 1164 Application of the Border Gateway Protocol in the Internet
RFC 1171 A Border Gateway Protocol 4
Description Link
48
Command Reference
Command Reference
49
Feature Information for MPLS VPN CSC with BGP
Feature Information for MPLS VPN CSC with BGP

Table 2 Feature Information for MPLS VPN CSC with BGP

MPLS VPNCarrier Supporting 12.0(21)ST This feature enables you to create an MPLS
CarrierIPv4 BGP Label 12.0(22)S VPN CSC network that uses BGP to transport
Distribution 12.0(23)S routes and MPLS labels.
12.2(13)T
In 12.0(21)ST, this feature was introduced.
12.0(24)S
12.2(14)S In 12.0(22)S, this feature was integrated.
12.0(27)S In 12.0(23)S, this feature was integrated.
12.0(29)S
12.0(24)S, this feature was integrated.
50
Glossary
Glossary
ASBR Autonomous System Boundary router. A router that connects one autonomous system to
another.
provider edge (PE) router. In this document, the CE roter sits on the edge of the customer carrier
network.
edge routerA router that is at the edge of the network. It defines the boundary of the MPLS network.
It receives and transmits packets. Also referred to as edge label switch router and label edge router.
MPLSMultiprotocol Label Switching. 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.
PE routerprovider edge router. A router, at the edge of a service providers network, that interfaces
to CE routers.
countries.
coincidental.
51
Glossary
52
Load Sharing MPLS VPN Traffic

Load sharing distributes traffic so that no individual router is overburdened. In a Multiprotocol Label
Switching (MPLS) Virtual Private Network (VPN) network, you can achieve load sharing through the
following methods:
BGP multipath options
Directly connected loopback peering

supported, see the Feature Information for Load Sharing MPLS VPN Traffic section on page 50.
Contents
Prerequisites for Load Sharing MPLS VPN Traffic, page 2
Restrictions for Load Sharing MPLS VPN Traffic, page 2
Information About Load Sharing MPLS VPN Traffic, page 4
How to Configure Load Sharing, page 7
Configuration Examples for Load Sharing MPLS VPN Traffic, page 46
Prerequisites for Load Sharing MPLS VPN Traffic

Feature Information for Load Sharing MPLS VPN Traffic, page 50
Prerequisites for Load Sharing MPLS VPN Traffic

Before configuring load sharing, ensure that your MPLS VPN network (including MPLS VPN carrier
supporting carrier or interautonomous system) is configured and working properly. See the Related
Documents section on page 48 for references related to MPLS VPNs.
Restrictions for Load Sharing MPLS VPN Traffic

When you configure 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 releases that support the Tag Forwarding Information Base (TFIB), specifically Cisco IOS
Releases 12.nT, 12.nM, and 12.0S. 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 releases that support the MPLS Forwarding Infrastructure (MFI), specifically Cisco IOS
Release 12.2(25)S and later releases. 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 an 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:
Unsupported Static Routes in an MPLS Environment That Uses the TFIB

environment:
The following ip route command is not supported when you configure static routes in an MPLS VPN
environment and enable load sharing where the next hop can be reached through two paths:
environment and enable load sharing where the destination can be reached through two next hops:
Use the interface and next-hop arguments when specifying static routes.
2
Restrictions for Load Sharing MPLS VPN Traffic
Supported Static Routes in an MPLS VPN Environment

The following ip route vrf commands are supported when you configure static routes in an MPLS VPN
environment, and the next hop and interface are associated with the same virtual routing and forwarding
(VRF) instance:
ip route vrf vrf-name destination-prefix mask next-hop-address
The following ip route vrf commands are supported when you configure static routes in an 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
(This command is supported when the next hop and the interface are in the core.)
The following ip route commands are supported when you configure static routes in an 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
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 an MPLS VPN
sharing where the destination can be reached through two next hops:
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:
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 an MPLS VPN
environment, and the next hop is in the global table on the customer edge (CE) side. For example, the
following command is supported when the destination-prefix is the CE routers loopback address, as in
EBGP multihop cases.
The following ip route commands are supported when you configure static routes in an MPLS VPN
environment, the next hop is in the global table on the CE side, and you enable load sharing with static
nonrecursive routes and a specific outbound interfaces:
3
Information About Load Sharing MPLS VPN Traffic

Before configuring load sharing features, you should understand the following concepts:
Load Sharing Using BGP Multipath Options, page 4
Load Sharing Using Directly Connected Loopback Peering, page 6
Load Sharing Using BGP Multipath Options

A variety of Border Gateway Protocol (BGP) multipath options exist that enable you to configure load
sharing on your MPLS VPN that uses BGP. The following sections describe some BGP multipath
options:
Internal BGP Multipath Load Sharing, page 4
BGP Multipath for eBGP and iBGP, page 4
eBGP Multipath Load Sharing, page 6
Internal BGP Multipath Load Sharing

When a BGP-speaking router with no local policy configured receives multiple network layer
reachability information (NLRI) from the internal BGP (iBGP) for the same destination, the router
chooses one iBGP path as the best path. The best path is then installed in the IP routing table of the
router. The iBGP multipath feature enables the BGP-speaking router to select multiple iBGP paths as
the best paths to a destination. The best paths are then installed in the IP routing table of the router. To
enable iBGP multipath load sharing, you issue the maximum-paths ibgp command in router
configuration mode. For more information about iBGP multipath load sharing, see Configuring BGP.
BGP Multipath for eBGP and iBGP

The BGP multipath load sharing for both eBGP and iBGP in an MPLS VPN feature allows multihomed
autonomous systems and provider edge (PE) routers to be configured to distribute traffic across both
external BGP (eBGP) and iBGP paths.
BGP installs up to the maximum number of paths allowed (configured using the maximum-paths
command). BGP uses the best path algorithm to select one multipath as the best path, inserts the best
path into the routing information base (RIB), and advertises the best path to BGP peers. Other multipaths
can be inserted into the RIB, but only one path is selected as the best path.
Cisco Express Forwarding uses mutlipaths to perform load balancing on a per-packet or per-source or
destination pair basis. To enable the load sharing feature, configure the router with MPLS VPNs that
contain VPN routing and forwarding instances (VRFs) that import both eBGP and iBGP paths. You can
configure the number of multipaths separately for each VRF.
Note This feature operates within the configuration parameters of the existing outbound routing policy.
4
eBGP and iBGP Multipath Load Sharing in an MPLS Network Using BGP
Figure 1 shows an MPLS service provider network using BGP that connects two remote networks to PE1
and PE2, which are both configured for VPNv4 unicast iBGP peering. Network 2 is a multihomed
network that is connected to PE1 and PE2. Network 2 also has extranet VPN services configured with
Network 1. Both Network 1 and Network 2 are configured for eBGP peering with the PE routers.
Figure 1 A Service Provider MPLS Network Using BGP
Provider edge Provider edge

router 1 router 2
iBGP peering
RD1 RD21 RD22

VRF1 VRF21 VRF22
eBGP peering eBGP peering eBGP peering
Network 1 Network 2
60938
You can configure PE1 so that both iBGP and eBGP paths can be selected as multipaths and imported
into the VRF of Network 1. Cisco Express Forwarding uses the mutlipaths to perform load balancing.
Traffic is distributed as follows:
IP traffic that is sent from Network 2 to PE1 and PE2 is sent across the eBGP paths as IP traffic.
IP traffic that is sent from PE1 to PE2 is sent across the iBGP path as MPLS traffic.
MPLS traffic that is sent across an eBGP path is sent as IP traffic.
Any prefix that is advertised from Network 2 will be received by PE1 through route distinguisher (RD)
21 and RD22.
The advertisement through RD21 is carried in IP packets.
The advertisement through RD22 is carried in MPLS packets.
Both paths can be selected as multipaths for VRF1 and inserted into the VRF1 RIB.
eBGP and iBGP Multipath Load Sharing with Route Reflectors
Figure 2 shows a topology that contains three PE routers and a route reflector, all configured for iBGP
peering. PE2 and PE3 each advertise an equal preference eBGP path to PE1. By default, the route
reflector chooses only one path and advertises PE1.
5
Figure 2 Topology with a Route Reflector
Provider edge
router 2
eBGP advertisement for PE1
iBGP
Provider edge
router 1
iBGP Route reflector
iBGP
eBGP advertisement for PE1
60937
Provider edge
router 3
For all equal preference paths to PE1 to be advertised through the route reflector, you must configure
each VRF with a different RD. The prefixes received by the route reflector are recognized differently
and advertised to PE1.
eBGP Multipath Load Sharing

When a router learns two identical eBGP paths for a prefix from a neighboring autonomous system, it
chooses the path with the lower route ID as the best path. This best path is installed in the IP routing
table. You can enable eBGP multipath, which installs multiple paths in the IP routing table when the
eBGP paths are learned from a neighboring autonomous system, instead of picking one best path.
During packet switching, depending on the switching mode, either per-packet or per-destination load
sharing is performed among the multiple paths. The maximum-paths router configuration command
controls the number of paths allowed. By default, BGP installs only one path to the IP routing table.
Load Sharing Using Directly Connected Loopback Peering

You use this feature with MPLS VPN Inter-AS and MPLS VPN carrier supporting carrier (CSC)
networks to load share traffic between adjacent label switched routers (LSRs) that are connected by
multiple links. The LSRs could be a pair of autonomous system boundary routers (ASBRs) or a CSC-PE
and a CSC-CE.
Using directly connected loopback peering allows load sharing at the IGP level, so more than one BGP
session is not needed between the LSRs. No other label distribution mechanism is needed between the
adjacent LSRs than BGP.
Directly connected loopback peering enables load sharing of traffic as follows:
A BGP session is established, using the loopback addresses of the LSRs.
MPLS is enabled on the connecting links.
Multiple static routes to the loopback address of the adjacent LSR allow IGP load sharing.
The outgoing label to the loopback address of the adjacent LSR is an implicit null label and is
inferred by the LSR.
6
How to Configure Load Sharing
Because IGP load sharing is enabled on the loopback address of the adjacent LSR, any traffic
destined to a prefix that is learned over the BGP session (and recurses over the loopback) is load
shared.

Configuring BGP Multipath Load Sharing for eBGP and iBGP, page 7 (required)
Verifying BGP Multipath Load Sharing for eBGP and iBGP, page 8 (optional)
Configuring eBGP Multipath Load Sharing with MPLS VPN Inter-AS, page 9 (required)
Configuring eBGP Multipath Load Sharing with MPLS VPN Carrier Supporting Carrier, page 11
(required)
Configuring Directly Connected Loopback Peering for MPLS VPN Inter-AS using ASBRs to
Exchange VPN-IPv4 Addresses, page 16 (required)
Configuring Directly Connected Loopback Peering for MPLS VPN Inter-AS Using ASBRs to
Exchange IPv4 Routes and Labels, page 23 (required)
Configuring Directly Connected Loopback Peering on MPLS VPN Carrier Supporting Carrier,
page 31 (required)
Configuring BGP Multipath Load Sharing for eBGP and iBGP

This section lists restrictions for load sharing.
Restrictions
Configuring BGP multipath for eBGP and iBGP is only for basic MPLS Layer 3 VPNs. MPLS VPN
Inter-AS and MPLS VPN carrier supporting carrier do not support this multipath configuration.
With multiple iBGP paths installed in a routing table, a route reflector advertises only one of the
paths (one next hop). If a router is behind a route reflector, all routers that are connected to
multihomed sites are not advertised unless separate VRFs with different RDs are configured for each
VRF.
Each IP routing table entry for a BGP prefix that has multiple iBGP paths uses additional memory.
We recommend not using this feature on a router with a low amount of available memory and
especially when the router is carrying a full Internet routing table.
To configure iBGP and eBGP routes for multipath load sharing, perform the following task.
SUMMARY STEPS
1. enable
5. maximum-paths eibgp number-of-paths
7
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Enters router configuration mode and configures the router
to run a BGP routing process.
Example:
vrf-name] routing sessions such as BGP that use standard IPv4 address
prefixes.
Example: Note For this task you must create the VRF and specify
Router(config-router)# address-family ipv4 vrf the vrf keyword.
vrf1
address prefixes.
prefixes.
Step 5 maximum-paths eibgp number-of-paths Configures the number of parallel iBGP and eBGP routes
that can be installed into a routing table.
Example:
Router(config-router-af)# maximum-paths eibgp 6
Verifying BGP Multipath Load Sharing for eBGP and iBGP

To verify the configuration of iBGP and eBGP routes for multipath load sharing, perform this task.
SUMMARY STEPS
1. enable
2. show ip bgp vpnv4 {all | rd route-distinguisher | vrf vrf-name} [rib-failure] [ip-prefix/length
[community-list] [dampened-paths] [filter-list] [flap-statistics] [inconsistent-as] [neighbors]
[paths [line]] [peer-group] [quote-regexp] [regexp] [summary] [labels]
8
DETAILED STEPS

Example:
Router> enable
Step 2 show ip bgp vpnv4 {all | rd route-distinguisher Displays attributes and multipaths for a specific network in
| vrf vrf-name} [rib-failure] [ip-prefix/length an MPLS VPN.
[longer-prefixes]] [network-address [mask]
[longer-prefixes]] [cidr-only] [community] Enter one or more keywords or arguments.
[community-list] [dampened-paths] [filter-list]
[flap-statistics] [inconsistent-as] [neighbors]
[paths [line]] [peer-group] [quote-regexp]
[regexp] [summary] [labels]
Example:
Router# show ip bgp vpnv4 all
Configuring eBGP Multipath Load Sharing with MPLS VPN Inter-AS

Perform this task on the ASBRs to configure eBGP Multipath for MPLS VPN interautonomous systems
with ASBRs exchanging IPv4 routes and MPLS labels.
Restrictions
eBGP Multipath is not supported on MPLS VPN Inter-AS with ASBRs that exchange VPNv4 routes.
SUMMARY STEPS
1. enable
6. maximum paths number-paths
10. end
9
DETAILED STEPS

Example:
Router> enable
Example:
Example: neighbor.
BGP peer group.
vrf-name] routing sessions such as BGP that use standard IPv4 address
prefixes.
prefixes.
Step 6 maximum-paths number-paths (Optional) Controls the maximum number of parallel routes
an IP routing protocol can support.
Example: The number-paths argument specifies the maximum
Router(config-router-af)# maximum-paths 2 number of parallel routes an IP routing protocol installs
in a routing table.
10

activate router.
Example: neighbor.
BGP peer group.
send-label
Example:
Example:
Configuring eBGP Multipath Load Sharing with MPLS VPN Carrier Supporting
Carrier
Configuring eBGP Multipath Load Sharing on the CSC-PE Routers, page 11
Configuring eBGP Multipath Load Sharing on the CSC-CE Routers, page 13
Configuring eBGP Multipath Load Sharing on the CSC-PE Routers

Perform this task to configure eBGP Multipath load sharing on the CSC-PE routers that distribute BGP
routes with MPLS labels.
SUMMARY STEPS
1. enable
8. neighbor ip-address as-override
11

11. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
vpn1 The unicast keyword specifies IPv4 unicast address
prefixes.
Example: On the CSC-PE router, this command is enabled in
Router(config-router-af)# maximum-paths 2 address family configuration mode.
The number-paths argument specifies the maximum
number of parallel routes an IP routing protocol installs
in a routing table.
12

Example: neighbor.
BGP peer group.
Example: neighbor.
BGP peer group.
Step 8 neighbor ip-address as-override Configures a PE router to override the autonomous system
number (ASN) of a site with the ASN of a provider.
Router(config-router-af)# neighbor 10.0.0.1 router that is to be overridden with the ASN provided.
as-override
send-label
Example:
Example:
Configuring eBGP Multipath Load Sharing on the CSC-CE Routers

Perform this task to configure eBGP Multipath load sharing on the CSC-CE routers.
SUMMARY STEPS
1. enable
13
11. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Example: On the CSC-CE routers, this command is issued in
Router(config-router)# maximum-paths 2 router configuration mode.
The number-paths argument specifies the maximum
number of parallel routes an IP routing protocol installs
in a routing table.
prefixes.
14

routing domain.
Router(config-router-af)# redistribute static from which routes are being redistributed. It can be one
of the following keywords: bgp, connected, egp, igrp,
isis, mobile, ospf, rip, and static [ip].
The static [ip] keyword redistributes IP static
routes.
Note The optional ip keyword is used when you
redistribute static routes into Intermediate System-
to-Intermediate System (IS-IS).
The connected keyword refers to routes that are

interface.
For routing protocols such as Open Shortest Path
First (OSPF) and IS-IS, these routes are
redistributed as external to the autonomous system.
Example: neighbor.
BGP peer group.
Example: neighbor.
BGP peer group.
send-label
Example:
Example:
15
Configuring Directly Connected Loopback Peering for MPLS VPN Inter-AS

using ASBRs to Exchange VPN-IPv4 Addresses
This section describes the following tasks you need to do to configure peering of loopback interfaces of
directly connected ASBRs:
Configuring Loopback Interface Addresses for Directly Connected ASBRs, page 16 (required)
Configuring /32 Static Routes to the eBGP Neighbor Loopback, page 17 (required)
Configuring Forwarding on Connecting Loopback Interfaces, page 18 (required)
Configuring an eBGP Session Between the Loopbacks, page 19 (required)
Verifying That Load Sharing Occurs Between Loopbacks, page 22 (optional)
Figure 3 shows the loopback configuration for directly connected ASBR1 and ASBR2. This
configuration is used as the example in the tasks that follow.
Figure 3 Loopback Interface Configuration for Directly Connected ASBR1 and ASBR2
L0 L0
10.10.10.10 e1/0 e1/0 10.20.20.20

192.168.0.2 192.168.0.1
121193
e0/0 e0/0
ASBR1 192.168.2.2 192.168.2.1 ASBR2
Configuring Loopback Interface Addresses for Directly Connected ASBRs

Perform this task to configure loopback interface addresses for directly connected ASBRs.
Note Loopback addresses need to be configured for each directly connected ASBR. That is, configure a
loopback address for ASBR1 and for ASBR2 in the example shown in Figure 3.
SUMMARY STEPS
1. enable
3. interface loopback interface-number
5. end
16
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface loopback interface-number Configures a software-only virtual interface that emulates
an interface that is always up and enters interface
configuration mode.
Example:
Router(config)# interface loopback 0 The interface-number argument is the number of the
loopback interface that you want to create or configure.
There is no limit on the number of loopback interfaces
that you can create.
255.255.255.255
subnet.
address.
Example:
Configuring /32 Static Routes to the eBGP Neighbor Loopback

Perform this task to configure /32 static routes to the eBGP neighbor loopback.
Note You need to configure /32 static routes on each of the directly connected ASBRs.
SUMMARY STEPS
1. enable
3. ip route prefix mask {ip-address | interface-type interface-number [ip-address]}
[distance] [name] [permanent] [tag tag]
4. end
17
DETAILED STEPS

Example:
Router> enable
Example:
interface-type interface-number [ip-address]}
[distance] [name] [permanent] [tag tag] The prefix argument is the IP route prefix for the
destination.
Example: The mask argument is the prefix mask for the

Router(config)# ip route 10.20.20.20 destination.
255.255.255.255 Ethernet 1/0 172.16.0.1
The ip-address argument is the IP address of the next
hop that you can use to reach the specified network.
The interface-type and interface-number arguments are
the network interface type and interface number.
The distance argument is an administrative distance.
The name argument applies a name to the specified
route.
The permanent keyword specifies that the route is not
to be removed, even if the interface shuts down.
The tag tag keyword and argument name a tag value
that can be used as a match value for controlling
redistribution through the use of route maps.
Example:
Router(config)# end
Configuring Forwarding on Connecting Loopback Interfaces

Perform this task to configure forwarding on the connecting loopback interfaces.
This task is required for sessions between loopbacks. In the Configuring /32 Static Routes to the eBGP
Neighbor Loopback task, Ethernet 1/0 and Ethernet 0/0 are the connecting interfaces.
SUMMARY STEPS
1. enable
18

5. exit
6. Repeat Steps 3 and 4 for another connecting interface (Ethernet 0/0).
7. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
Router(config)# interface ethernet 1/0 configured.
information.
information.
Step 4 mpls bgp forwarding Configures BGP to enable MPLS forwarding on connecting
interfaces.
Example:
Router(config-if)# mpls bgp forwarding
Example:
Step 6 Repeat Steps 3 and 4 for another connecting interface
(Ethernet 0/0).
Example:
Router(config)# end
Configuring an eBGP Session Between the Loopbacks

Perform this task to configure an eBGP session between the loopbacks.
19
Note You need to configure an eBGP session between loopbacks on each directly connected ASBR.
SUMMARY STEPS
1. enable
6. neighbor {ip-address | peer-group-name} disable-connected-check
7. neighbor {ip-address | ipv6-address | peer-group-name} update-source
interface-type interface-number
9. neighbor {ip-address | peer-group-name | ipv6-address} activate
11. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Configures the BGP routing process.
The as-number indicates the number of an autonomous
Example: system that identifies the router to other BGP routers
Router(config)# router bgp 200 and tags the routing information passed along.
Step 4 no bgp default route-target filter Disables BGP route-target filtering, and enters router
configuration mode.
Example: All received BGP VPN-IPv4 routes are accepted by the
Router(config)# no bgp default route-target router.
filter
20

The ip-address argument is the IP address of the
Example: neighbor.
remote-as 100 The peer-group-name argument is the name of a BGP
peer group.
The as-number argument is the autonomous system to
which the neighbor belongs.
Step 6 neighbor {ip-address | peer-group-name} Allows peering between loopbacks.
disable-connected-check
neighbor.
Example:
The peer-group-name argument is the name of a BGP
disable-connected-check peer group.
Step 7 neighbor {ip-address | ipv6-address | Allows BGP sessions to use any operational interface for
peer-group-name} update-source interface-type TCP connections.
interface-number
The ip-address argument is the IPv4 address of the
BGP-speaking neighbor.
Example:
Router(config-router)# neighbor 10.20.20.20 The ipv6-address argument is the IPv6 address of the
update-source Loopback 0 BGP-speaking neighbor.
This argument must be in the form documented in
RFC 2373, where the address is specified in
peer group.
The interface-type argument is the interface type.
The interface-number argument is the interface
number.
routing protocols such as BGP, Routing Information
Protocol (RIP), and static routing.
Example:
Router(config-router)# address-family vpnv4 The unicast keyword specifies unicast prefixes.
Step 9 neighbor {ip-address | peer-group-name | Enables the exchange of information with a BGP neighbor.
ipv6-address} activate
neighboring router.
Example:
activate peer group.
The ipv6-address argument is the IPv6 address of the
Note This argument must be in the form documented in
21

send-community [both | standard | extended] BGP neighbor.
Example: neighboring router.
send-community extended The peer-group-name argument is the name of a BGP
peer group.
The both keyword specifies that both standard and
extended communities will be sent.
The standard keyword specifies that only standard
communities will be sent.
The extended keyword specifies that only extended
Example:
Router(config)# end
Verifying That Load Sharing Occurs Between Loopbacks

Perform this task to verify that load sharing occurs between loopbacks. You need to ensure that the
MPLS Label Forwarding Information Base (LFIB) entry for the neighbor route lists the available paths
and interfaces.
SUMMARY STEPS
1. enable
3. disable
22
DETAILED STEPS

Example:
Router> enable
Step 2 show mpls forwarding-table [network {mask | Displays the contents of the MPLS LFIB.
interface | next-hop address | lsp-tunnel Enter an optional keyword or argument if desired.
Example:
Example:
Router# disable
Configuring Directly Connected Loopback Peering for MPLS VPN Inter-AS

Using ASBRs to Exchange IPv4 Routes and Labels
The following sections describe how to configure peering of loopback interfaces of directly connected
ASBRs to achieve load sharing in an interautonomous system network:
Configuring Loopback Interface Addresses for Directly Connected ASBRs, page 24 (required)
Configuring /32 Static Routes to the eBGP Neighbor Loopback, page 25 (required)
Configuring Forwarding on Connecting Loopback Interfaces, page 26 (required)
Configuring an eBGP Session Between the Loopbacks, page 27 (required)
Figure 4 shows the loopback configuration for directly connected ASBR1 and ASBR2. This
Figure 4 Loopback Interface Configuration for Directly Connected ASBR1 and ASBR2
L0 L0
10.10.10.10 e1/0 e1/0 10.20.20.20

192.168.0.2 192.168.0.1
121193
e0/0 e0/0
ASBR1 192.168.2.2 192.168.2.1 ASBR2
23
Configuring Loopback Interface Addresses for Directly Connected ASBRs

Perform this task to configure loopback interface addresses.
Note Loopback addresses need to be configured for each directly connected ASBR. That is, configure a
loopback address for ASBR1 and for ASBR2 in the example shown in Figure 4.
SUMMARY STEPS
1. enable
5. end
DETAILED STEPS

Example:
Router> enable
Example:
an interface that is always up and enters interface
configuration mode.
Example:
24

255.255.255.255
subnet.
address.
Example:
Configuring /32 Static Routes to the eBGP Neighbor Loopback

Perform this task to configure /32 static routes to the eBGP neighbor loopback.
Note You need to configure /32 static routes on each of the directly connected ASBRs.
SUMMARY STEPS
1. enable
4. end
DETAILED STEPS

Example:
Router> enable
Example:
25

destination.

255.255.255.255 Ethernet 1/0 172.16.0.1
hop that you can use to reach the specified network.
route.
redistribution through the use of route maps.
Example:
Router(config)# end
Configuring Forwarding on Connecting Loopback Interfaces

Perform this task to configure forwarding on the connecting loopback interfaces.
This task is required for sessions between loopbacks. In the Configuring /32 Static Routes to the eBGP
Neighbor Loopback task, Ethernet1/0 and Ethernet0/0 are the connecting interfaces.
SUMMARY STEPS
1. enable
5. exit
6. Repeat Steps 3 and 4 for another connecting interface (Ethernet 0/0)
7. end
26
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
information.
information.
interfaces.
Example:
Example:
(Ethernet 0/0).
Example:
Router(config)# end
Configuring an eBGP Session Between the Loopbacks

Perform the following tasks to configure an eBGP session between the loopbacks.
Note You need to configure an eBGP session between loopbacks on each directly connected ASBR.
SUMMARY STEPS
1. enable
27
8. address-family ipv4 [unicast] vrf vrf-name
11. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 router bgp as-number Configures the BGP routing process, and enters router
configuration mode.
along.
Example:
Example: neighbor.
peer group.
The as-number argument is the number of the
autonomous system to which the neighbor belongs.
28

neighbor.
Example:
interface-number
Example:

peer group.
number.
Step 8 address-family ipv4 [unicast] vrf vrf-name Enters address family configuration mode for configuring
Example:
Router(config-router)# address-family ipv4 The unicast keyword specifies unicast prefixes.
name of a VPN routing/forwarding instance (VRF) to
associate with submode commands.
neighboring router.
Example:
The peer-group-name argument is the name of the BGP
29

send-community [both | standard | extended] BGP neighbor.
Example: neighboring router.
send-community extended The peer-group-name argument is the name of the BGP
peer group.
The both keyword specifies that both standard and
extended communities will be sent.
The standard keyword specifies that only standard
The extended keyword specifies that only extended
Example:
Router(config)# end

To verify that load sharing can occur between loopbacks, ensure that the MPLS LFIB entry for the
neighbor route lists the available paths and interfaces.
SUMMARY STEPS
1. enable
2. show mpls forwarding-table [network {mask | length} | labels label [-label] | interface interface |
3. disable
30
DETAILED STEPS

Example:
Router> enable
Step 2 show mpls forwarding-table [network {mask | Displays the contents of the MPLS LFIB.
interface | next-hop address | lsp-tunnel Enter a keyword or argument, if desired.
Example:
Example:
Router# disable
Configuring Directly Connected Loopback Peering on MPLS VPN Carrier

Supporting Carrier
The following sections explain how to load balance CSC traffic by peering loopback interfaces of
directly connected CSC-PE and CSC-CE routers:
Configuring Loopback Interface Addresses on CSC-PE Routers, page 32 (required)
Configuring Loopback Interface Addresses for CSC-CE Routers, page 33 (required)
Configuring /32 Static Routes to the eBGP Neighbor Loopback on the CSC-PE Router, page 34
(required)
Configuring /32 Static Routes to the eBGP Neighbor Loopback on the CSC-CE Router, page 36
(required)
Configuring Forwarding on CSC-PE Interfaces That Connect to the CSC-CE Loopback, page 37
(required)
Configuring Forwarding on CSC-CE Interfaces That Connect to the CSC-PE Loopback, page 39
(required)
Configuring an eBGP Session Between the CSC-PE Router and the CSC-CE Loopback, page 40
(required)
Configuring an eBGP Session Between the CSC-CE Router and the CSC-PE Loopback, page 43
(required)
Figure 5 shows the loopback configuration for directly connected CSC-PE and CSC-CE routers. This
31
Figure 5 Loopback Interface Configuration for Directly Connected CSC-PE and CSC-CE Routers
L0 L0
10.10.10.10 e1/0 e1/0 10.20.20.20

192.168.0.2 192.168.0.1
121191
e0/0 e0/0
CSC-CE 192.168.2.2 192.168.2.1 CSC-PE
Restrictions
Load sharing using directly connected loopback peering does not apply to CSC networks that use LDP
and an IGP to distribute routes and MPLS labels.
Configuring Loopback Interface Addresses on CSC-PE Routers

Perform this task to configure loopback interface addresses on the CSC-PE router.
Note Configuration of a loopback interface address on the CSC-PE router requires the enabling of a VRF. The
CSC-CE router loopback interface does not require the enabling a of VRF.
SUMMARY STEPS
1. enable
6. end
DETAILED STEPS

Example:
Router> enable
Example:
32

an interface that is always up, and enters interface
configuration mode.
Example:
subinterface.
255.255.255.255
subnet.
address.
Example:
Router(config)# end
Configuring Loopback Interface Addresses for CSC-CE Routers

Perform this task to configure loopback interface addresses for CSC-CE routers.
SUMMARY STEPS
1. enable
5. end
33
DETAILED STEPS

Example:
Router> enable
Example:
an interface that is always up.
Example: The interface-number argument is the number of the
Router(config)# interface loopback 0 loopback interface that you want to create or configure.
255.255.255.255
subnet.
address.
Example:
Configuring /32 Static Routes to the eBGP Neighbor Loopback on the CSC-PE Router
Perform the following task to configure /32 static routes to the eBGP neighbor loopback on the CSC-PE
router.
SUMMARY STEPS
1. enable
3. ip route vrf vrf-name prefix mask {ip-address | interface-type interface-number [ip-address]}
[global] [distance] [name] [permanent] [tag tag]
4. end
34
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip route vrf vrf-name prefix mask {ip-address | Establishes static routes for a VRF.
[global] [distance] [name] [permanent] [tag The vrf-name argument is the name of the VRF for the
tag] static route.
The prefix argument is the IP route prefix for the
Router(config)# ip route vrf vpn1 10.10.10.10
The mask argument is the prefix mask for the
255.255.255.255 Ethernet 1/0 172.16.0.2
destination.
hop that you can use to reach the destination network.
The global keyword specifies that the given next hop
address is in the nonVRF routing table.
route.
redistribution via route maps.
Example:
Router(config)# end
35
Configuring /32 Static Routes to the eBGP Neighbor Loopback on the CSC-CE Router
Perform the following task to configure /32 static routes to the eBGP neighbor loopback for the CSC-CE
router.
SUMMARY STEPS
1. enable
4. end
DETAILED STEPS

Example:
Router> enable
Example:
36

destination.

255.255.255.255 Ethernet 1/0 172.16.0.1
hop that you can use to reach the destination network.
route.
redistribution via route maps.
Example:
Router(config)# end
Configuring Forwarding on CSC-PE Interfaces That Connect to the CSC-CE Loopback

Perform this task to configure forwarding on CSC-PE interfaces that connect to the CSC-CE loopback.
SUMMARY STEPS
1. enable
7. exit
8. Repeat Steps 3 through 6 for another connecting interface (Ethernet 0/0).
9. end
37
DETAILED STEPSCSC-PE

Example:
Router> enable
Example:
configuration mode.
information.
information.
Step 4 ip vrf forwarding vrf-name Associates a VRF with an interface or subinterface.
The vrf-name argument is the name assigned to a VRF.
Example:
255.255.255.255
subnet.
address.
interfaces.
Example:
Example:
38

Step 8 Repeat Steps 3 through 6 for another connecting
interface (Ethernet 0/0).
Example:
Router(config)# end
Configuring Forwarding on CSC-CE Interfaces That Connect to the CSC-PE Loopback

Perform this task to configure forwarding on CSC-CE interfaces that connect to the CSC-PE loopback.
SUMMARY STEPS
1. enable
5. exit
6. Repeat Steps 3 and 4 for another connecting interface (Ethernet 0/0).
7. end
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
information.
information.
39

interfaces.
Example:
Example:
(Ethernet 0/0).
Example:
Router(config)# end
Configuring an eBGP Session Between the CSC-PE Router and the CSC-CE Loopback
Perform this task to configure an eBGP session between the CSC-PE router and the CSC-CE loopback.
SUMMARY STEPS
1. enable
8. address-family ipv4 [unicast] vrf vrf-name
12. end
40
DETAILED STEPS

Example:
Router> enable
Example:
The as-number argument indicates the number of an
Example: autonomous system that identifies the router to other
Router(config)# router bgp 200 BGP routers and tags the routing information passed
along.
Example:
Example: neighbor.
peer group.
neighbor.
Example:
41

interface-number
Example:
peer group.
number.
Step 8 address-family ipv4 [unicast] vrf vrf-name Enters address family configuration mode for configuring
Example:
Router(config-router)# address-family ipv4 vrf The ipv4 keyword configures sessions that carry
vpn1 standard IPv4 address prefixes.
The unicast keyword specifies unicast prefixes.
name of a VRF to associate with submode commands.
Step 9 ip vrf forwarding vrf-name Associates a VRF with an interface or subinterface.
The vrf-name argument is the name assigned to a VRF.
Example:
Router(config-router-af)# ip vrf forwarding
vpn1
neighboring router.
Example:
42

Example: The ip-address argument is the IP address of the
send-label
Example:
Router(config)# end
Configuring an eBGP Session Between the CSC-CE Router and the CSC-PE Loopback
Perform this task to configure an eBGP session between the CSC-CE router and the CSC-PE loopback.
SUMMARY STEPS
1. enable
8. address-family ipv4 [unicast] [vrf vrf-name]
11. end
DETAILED STEPS

Example:
Router> enable
Example:
43

The as-number argument indicates the number of an
Example: autonomous system that identifies the router to other
Router(config)# router bgp 200 BGP routers and tags the routing information passed
along.
Example:
Example: neighbor.
peer group.
neighbor.
Example:
interface-number
Example:
peer group.
number.
44

Step 8 address-family ipv4 [unicast] [vrf vrf-name] Enters address family configuration mode for configuring
routing protocols such as BGP, RIP, and static routing.
Example: The ipv4 keyword configures sessions that carry
Router(config-router)# address-family ipv4 standard IPv4 address prefixes.
The unicast keyword specifies unicast prefixes.
name of a VRF to associate with submode commands.
neighboring router.
Example:
Example: The ip-address argument is the IP address of the
send-label
Example:
Router(config)# end

To verify that load sharing occurs between loopbacks, ensure that the MPLS LFIB entry for the neighbor
route lists the available paths and interfaces.
SUMMARY STEPS
1. enable
3. disable
45
Configuration Examples for Load Sharing MPLS VPN Traffic
DETAILED STEPS

Example:
Router> enable
Step 2 show mpls forwarding-table [vrf vrf-name] Displays the contents of the MPLS LFIB.
address | lsp-tunnel [tunnel-id]}] [detail]
Example:
Example:
Router# disable

This section contains the following configuration examples for Load Sharing MPLS VPN Traffic:
Configuring a Router to Select eBGP or iBGP Paths as Multipaths: Example, page 46
Configuring a /32 Static Route from an ASBR to the Loopback Address of Another ASBR:
Examples, page 46
Configuring BGP/MPLS Forwarding on the Interfaces Connecting ASBRs: Example, page 47
Configuring VPNv4 Sessions on an ASBR: Example, page 47
Verifying VPN NLRI for a Specified Network: Example, page 47
Configuring a Router to Select eBGP or iBGP Paths as Multipaths: Example

The following example configures a router in address family configuration mode to select six eBGP or
iBGP paths as multipaths:
Router(config-router)# address-family ipv4 vrf try
Router(config-router-af)# maximum-paths eibgp 6
Configuring a /32 Static Route from an ASBR to the Loopback Address of

Another ASBR: Examples
The following example configures a /32 static route from ASBR1 to the loopback address of ASBR2:
Router(config)# ip route 10.20.20.20 255.255.255 e1/0 168.192.0.1
46
Router(config)# ip route 10.20.20.20 255.255.255 e0/0 168.192.2.1
The following example configures a /32 static route from ASBR2 to the loopback address of ASBR1:
Router(config)# ip route vrf vpn1 10.10.10.10 255.255.255 e1/0 168.192.0.2
Router(config)# ip route vrf vpn1 10.10.10.10 255.255.255 e0/0 168.192.2.2
Configuring BGP/MPLS Forwarding on the Interfaces Connecting ASBRs:

Example
The following example configures BGP/MPLS forwarding on the interfaces connecting ASBR2 with
ASBR1:
Configuring VPNv4 Sessions on an ASBR: Example

The following example configures VPNv4 sessions on ASBR2:
Router(config-router)# neighbor 10.10.10.10 remote-as 100
Router(config-router)# neighbor 10.10.10.10 disable-connected-check
Router(config-router)# neighbor 10.10.10.10 update-source Loopback0
!
Router(config-router-af)# neighbor 10.10.10.10 activate
Router(config-router-af)# neighbor 10.10.10.10 send-community extended
Verifying VPN NLRI for a Specified Network: Example

If you enter the all keyword with the show ip bgp vpnv4 command, the output displays information
about all VPN network layer reachability information (NLRI) for a specified network:

Paths:(5 available, best #5)
Multipath: eiBGP
Advertised to non peer-group peers:
10.0.0.2 10.0.0.3 10.0.0.4 10.0.0.5
22
10.0.0.2 (metric 20) from 10.0.0.4 (10.0.0.4)
Origin IGP, metric 0, localpref 100, valid, internal, multipath
47
Extended Community:0x0:0:0 RT:100:1 0x0:0:0

Originator:10.0.0.2, Cluster list:10.0.0.4
22
10.0.0.2 (metric 20) from 10.0.0.5 (10.0.0.5)
22
10.0.0.2 (metric 20) from 10.0.0.2 (10.0.0.2)
Extended Community:RT:100:1 0x0:0:0
22
10.0.0.2 (metric 20) from 10.0.0.3 (10.0.0.3)
22
10.1.1.12 from 10.1.1.12 (10.22.22.12)
Origin IGP, metric 0, localpref 100, valid, external, multipath, best
Extended Community:RT:100:1
Related Documents
MPLS Cisco IOS Multiprotocol Label Switching Configuration Guide,
Release 15.0, MPLS VPN Carrier Supporting Carrier with BGP
BGP Cisco IOS IP Routing: BGP Configuration Guide, Release 15.0,
Configuring BGP
Standards
Standard Title
MIBs
MIB MIBs Link
48
Command Reference
RFCs
RFC Title
RFC 1164 Application of the Border Gateway Protocol in the Internet
RFC 1171 A Border Gateway Protocol 4
RFC 2373 IP Version 6 Addressing Architecture
Description Link
Command Reference
49
Feature Information for Load Sharing MPLS VPN Traffic

Table 1 Feature Information for Load Sharing MPLS VPN Traffic

MPLS VPNLoad Balancing Support 12.0(29)S This feature allows MPLS VPN Inter-AS and MPLS VPN
for Inter-AS and CSC VPNs 12.4(20)T CSC networks to load share traffic between adjacent LSRs
that are connected by multiple links. The LSRs can be a pair
of ASBRs or a CSC-PE and a CSC-CE. Using directly
connected loopback peering allows load sharing at the IGP
level, so more than one BGP session is not needed between the
LSRs. No other label distribution mechanism is needed
between the adjacent LSRs than BGP.
Load Sharing Using Directly Connected Loopback
Peering, page 6
Configuring Directly Connected Loopback Peering for
MPLS VPN Inter-AS using ASBRs to Exchange
VPN-IPv4 Addresses, page 16
BGP Multipath Load Sharing for Both 12.2(4)T This feature allows multihomed autonomous systems and PE
eBGP and iBGP in an MPLS VPN 12.2(14)S routers to be configured to distribute traffic across both
12.0(24)S external BGP (eBGP) and internal BGP (iBGP) paths.
BGP Multipath for eBGP and iBGP, page 4
Configuring BGP Multipath Load Sharing for eBGP and
iBGP, page 7
50
Table 1 Feature Information for Load Sharing MPLS VPN Traffic (continued)

iBGP Multipath Load Sharing 12.2(2)T This feature enables the BGP speaking router to select
12.2(14)S multiple iBGP paths as the best paths to a destination.
The following section provides information about this feature:
Internal BGP Multipath Load Sharing, page 4
eBGP Multipath 12.0(27)S This feature installs multiple paths in the IP routing table
when the eBGP paths are learned from a neighboring
Autonomous System (AS), instead of picking one best path.
eBGP Multipath Load Sharing, page 6
Configuring eBGP Multipath Load Sharing with MPLS
VPN Inter-AS, page 9
Configuring eBGP Multipath Load Sharing with MPLS
VPN Carrier Supporting Carrier, page 11
coincidental.
51
52
MPLS VPNInter-AS Option AB

The MPLS VPNInter-AS Option AB feature combines the best functionality of an Inter-AS Option
(10) A and Inter-AS Option (10) B network to allow a Multiprotocol Label Switching (MPLS) Virtual
Private Network (VPN) service provider to interconnect different autonomous systems to provide VPN
services. These networks are defined in RFC 4364 section 10 Multi-AS Backbones, option a and
option b respectively.
When different autonomous systems are interconnected in an MPLS VPNInter-AS Option AB
configuration, the entire network configuration is scaled and simplified, and maintains IP Quality of
Service (QoS) functions between Autonomous System Boundary Router (ASBR) peers.
In an Inter-AS Option A network, ASBR peers are connected by multiple sub-interfaces with at least one
interface VPN that spans the two autonomous systems. These ASBRs associate each sub-interface with
a VRF and a BGP session to signal unlabeled IP prefixes. As a result, traffic between the back-to-back
VRFs is IP. In this scenario, the VPNs are isolated from each other and because the traffic is IP, QoS
mechanisms that operate on IP traffic can be applied to achieve customer Service Level Agreements
(SLAs). The downside of this configuration is that there needs to be one BGP session for each
sub-interface (and at least one subinterface for each VPN), which causes scalability concerns as this
network grows.
In an Inter-AS Option B network, ASBR peers are connected by one or more sub-interfaces that are
enabled to receive MPLS traffic. A Multi-protocol Border Gateway Protocol (MP-BGP) session is used
to distribute labeled VPN prefixes between the ASBR. As a result, the traffic that flows between them is
labeled. The downside of this configuration is that because the traffic is MPLS, QoS mechanisms that
can only be applied to IP traffic cannot be applied and the VRFs cannot be isolated.

latest feature information and caveats, see the release notes for your Cisco IOS software release. To reach
links to specific feature documentation in this module and to see a list of the releases in which each
feature is supported, use the Feature Information for MPLS VPNInter-AS Option AB section on
page 45.
Contents
Contents
Prerequisites for MPLS VPNInter-AS Option AB, page 2
Restrictions for MPLS VPNInter-AS Option AB, page 2
Information About MPLS VPNInter-AS Option AB, page 3
How to Configure Inter-AS Option AB, page 9
Configuration Examples for MPLS VPNInter-AS Option AB, page 18
Feature Information for MPLS VPNInter-AS Option AB, page 45
Glossary, page 46
Prerequisites for MPLS VPNInter-AS Option AB

Follow the appropriate configuration tasks outlined in the following documents:
Perform the following requirements before configuring the MPLS VPNInter-AS Option AB feature.
Enable Cisco Express Forwarding, which is required for MPLS VPN routing and forwarding
operation.
Identify the VPNs for the MPLS VPNInter-AS Option AB network and configure the VRFs to
which these VPNs belong. These VRFs are used for Inter-AS Option AB connections on the ASBR
interface.
Restrictions for MPLS VPNInter-AS Option AB

This feature has the following restrictions:
The In Service Software Upgrade (ISSU) feature can only be configured on the active Route
Processor (RP) if the standby RP supports this feature. The ISSU feature can be configured if both
the active and standby RP support this feature.
Carrier Supporting Carrier (CSC) MPLS load-balancing on ASBR Option AB VRF interfaces is not
supported.
VPNv6 is not supported.

2
Information About MPLS VPNInter-AS Option AB

This section provides an introduction to the MPLS VPNInter-AS Option AB feature and describes its
benefits:
MPLS VPNInter-AS Option AB Introduction, page 2
Benefits of MPLS VPNInter-AS Option AB, page 2
MPLS VPNInter-AS Option AB Route Distribution and Packet Forwarding in Non-CSC
Networks, page 4
MPLS VPNInter-AS Option AB Route Distribution and Packet Forwarding for CSC, page 7
MPLS VPNInter-AS Option AB Introduction

MPLS VPN service providers need to interconnect different autonomous systems to provide service for
multiple VPN customers. The MPLS VPNInter-AS Option AB feature allows the different
autonomous systems to interconnect by using a single MP-BGP session in the global routing table to
carry control plane traffic. This MP-BGP session signals VPN prefixes between two ASBRs for each
virtual routing and forwarding (VRF) instance. The data plane traffic is on a VRF interface. This traffic
can either be IP or MPLS.
Note Inter-AS connections can be configured between ASBRs that either have or do not have connections
between different providers.
Benefits of MPLS VPNInter-AS Option AB

The MPLS VPNInter-AS Option AB feature provides the following benefits for service providers:
Network configuration can be simplified because only one BGP session is configured for each VRF
on the ASBR.
One BGP session reduces CPU utilization.
Networks can be scaled because a single MP-BGP session, which is enabled globally on the router,
reduces the number of sessions required by multiple VPNs, while continuing to keep VPNs isolated
and secured from each other.
IP QoS functions between ASBR peers are maintained for customer SLAs.
Dataplane traffic is isolated on a per-VRF basis for security purposes.
3
MPLS VPNInter-AS Option AB Route Distribution and Packet Forwarding in

Non-CSC Networks
The following sections describe MPLS VPNInter-AS Option AB operation:
Route Distribution for VPN 1, page 5
Packet Forwarding for VPN 1, page 5
Note All imported routes are accomplished by configuring the appropriate route targets (RTs).
The following attributes describe the topology of the sample MPLS VPNInter-AS Option AB network
shown in Figure 1 on page 4:
Customer edge 1 (CE1) and CE3 belong to VPN 1.
CE2 and CE 4 belong to VPN 2.
Provider edge 1 (PE1) uses route distinguisher 1 (RD 1) for VPN 1 (VRF 1) and RD 2 for VPN 2
(VRF 2).
PE2 uses RD 3 for VPN 1 (VRF 1) and RD 4 for VPN 2 (VRF 2).
ASBR1 has VRF 1 provisioned with RD 5 and VRF 2 provisioned with RD 6.
ASBR2 has VRF 1 provisioned with RD 7 and VRF 2 provisioned and RD 8.
ASBR1 and ASBR2 have three links between them:
VRF 1
VRF 2
MP-BGP session
Note The VRFs configured on the ASBRs are called Option AB VRFs. The eBGP peers on the ASBRs are
called Option AB Peers.
Figure 1 MPLS VPN Inter-AS Option AB Topology
RD 1 = VPN 1 RD 3 = VPN 1
RD 2 = VPN 2 RD 4 = VPN 2
(VPN 1) (VPN 1)
CE1 CE3
MP-BGP session
AS1 AS2
VPN 1
VPN 2
PE1 ASBR1 ASBR2 PE2
186003
(VPN 2) (VPN 2)
CE2 CE4

4
Route Distribution for VPN 1

A route distinguisher (RD) is an identifier attached to a route that identifies which VPN belongs to each
route. Each routing instance must have a unique RD autonomous system associated with it. The RD is
used to place a boundary around a VPN so that the same IP address prefixes can be used in different
VPNs without having these IP address prefixes overlap.
Note An RD statement is required if the instance type is a VRF.
The following process describes the route distribution process for VPN 1 in Figure 1. Prefix N is used
in this process to indicate the IP address of a VPN.
1. CE1 advertises the prefix N to PE1.
2. PE1 advertises a VPN prefix RD 1:N to ASBR1 through MP internal BGP (iBGP).
3. ASBR1 imports the prefix into VPN 1 and creates a prefix RD 5:N.
4. ASBR1 advertises the imported prefix RD 5:N to ASBR2. ASBR1 sets itself as the next hop for
prefix RD 5:N and allocates a local label that is signaled with this prefix.
5. ASBR1 advertises the route with the export RT configured on the VRF rather than the originally
received RTs. By default, ASBR1 does not advertise the source prefix RD 1:N to ASBR2. This
advertisement is suppressed because the prefix is being imported into an Option AB VRF.
Note In an Option 10B connection, the source prefix can be advertised to another ASBR on which
ASBR1 has an Option 10B connection. An ASBR with an Option 10B connection maintains all
VPNv4 routes in its BGP table.
6. ASBR2 receives the prefix RD 5:N and imports it into VPN 1 as RD 7:N.
received RTs.
8. While importing the prefix, ASBR2 sets the next hop of RD 7:N to the ASBR1 interface IP address
in VRF 1. The next hop table ID is also set to VRF 1. When installing the MPLS forwarding entry
for RD 7:N, the outgoing label is not installed in forwarding by default. This enables the traffic
between the ASBRs to be IP.
9. ASBR2 advertises the imported prefix RD 7:N to PE2. It sets itself as the next hop for this prefix
and also allocates a local label that is signaled with the prefix. By default, ASBR2 does not advertise
the source prefix RD 5:N to PE2. This advertisement is suppressed because the prefix is being
imported into an Option AB VRF.
10. PE2 imports the RD 7:N into VRF 1 as RD 3:N.
Packet Forwarding for VPN 1

The following packet forwarding process works the same as it does in an Option A scenario. The ASBR
acts like the PE by terminating the VPN and then forwards its traffic as standard IP packets with no VPN
label to the next PE, which in turn repeats the VPN process. Each PE router, therefore, treats the adjacent
PE router as a CE router, and the standard Layer 3 MPLS VPN mechanisms are used for route
redistribution with each autonomous system; that is, the PEs use external BGP (eBGP) to distribute
unlabeled IPv4 addresses to each other.
5
Note Prefix N is used in this process to indicate the IP address of a VPN.
1. CE3 sends a packet destined for N to PE2.

2. PE2 encapsulates the packet with the VPN label allocated by ASBR2 and the IGP label needed to
tunnel the packet to ASBR2.
3. The packet arrives on ASBR2 with the VPN label. ASBR2 removes the VPN label and sends the
packet as IP to ASBR1 on the VRF 1 interface.
4. The IP packet arrives at ASBR1 on the VRF 1 interface. ASBR1 then encapsulates the packet with
the VPN label allocated by PE1 and the IGP label needed to tunnel the packet to PE1.
5. The packet arrives on PE1 with the VPN label. PE1 disposes the VPN label and forwards the IP
packet to CE1.

The following information describes the route distribution process for VPN 2 in Figure 1:
1. CE2 advertises prefix N to PE1, where N is the VPN IP address.
2. PE1 advertises a VPN prefix RD 2:N to ASBR1 through MP-iBGP.
4. ASBR1 advertises the imported prefix RD 6:N to ASBR2. It sets itself as the next hop for this prefix
the source prefix RD 2:N to ASBR2. This advertisement is suppressed as the prefix is being
Note In the case of an Option 10B connection, the source prefix can be advertised to another ASBR
on which ASBR1 has an Option 10B connection. An ASBR with an Option 10B connection
maintains all VPNv4 routes in its BGP table.
6. While importing the prefix, ASBR2 sets the next hop of RD 8:N to ASBR1s interface address in
VRF 2. The next hop table ID is also set to that of VRF 2. While installing the MPLS forwarding
entry for RD 8:N, by default the outgoing label is not installed in forwarding. This enables traffic
between the ASBRs to be IP.
the source prefix RD 6:N to PE2. This advertisement is suppressed because the prefix is being

6
MPLS VPNInter-AS Option AB Route Distribution and Packet Forwarding for

CSC
The following sections describe MPLS VPNInter-AS Option AB operation for a CSC scenario for
VPN 1. These sections are similar to those found in MPLS VPNInter-AS Option AB Route
Distribution and Packet Forwarding in Non-CSC Networks section on page 4 for VPN 1, except for the
method in which MPLS labels are handled between the two ASBRs.
Packet Forwarding for VPN 1, page 5
Note VPN 2 is not shown or discussed in this section.
Figure 2 shows how VPN 1 provides VPN service to a small customer carrier that in turn provides a VPN
service to its customer. This configuration implies that VPN 1 is used to provide a Label Switched Path
(LSP) between the PE (PE 3 and PE 4) loopback interfaces of the small customer carrier.
Figure 2 MPLS VPN Inter-AS Option AB CSC Topology
AS1 AS2
(CSC) ASBR1 ASBR2 (CSC)

PE1 PE2
(CSC)
(CSC) CE2
CE1
PE3 PE4
186004
Note The RD, RT, VRF, and Link provisioning in this section is the same as in the MPLS VPNInter-AS
Option AB Route Distribution and Packet Forwarding in Non-CSC Networks section on page 4
example for VPN 1.

The following information describe the route distribution process for VPN 1 in Figure 1. Prefix N is
used in these steps to indicate the IP address of a VPN.
1. CE1 advertises PE 3 loopback N to PE1.
2. PE1 advertises a VPN prefix RD 1:N to ASBR1 through MP-iBGP.
4. ASBR1 advertises the imported prefix RD 5:N to ASBR2. It sets itself as the next hop for this prefix
and also allocates a local label that is signaled with the prefix.
received RTs. By default, ASBR1 does not advertise the source prefix RD 1:N to ASBR2. This
advertisement is suppressed as the prefix is being imported into an Option AB VRF.
7
Note In an Option 10B connection, the source prefix can be advertised to another ASBR on which ASBR1 has
an Option 10B connection. An ASBR with an Option 10B connection maintains all VPNv4 routes in its
BGP table.
received RTs.
8. While importing the prefix, ASBR2 sets the next hop of RD 7:N to ASBR1 interface address in VRF
1. The next hop table ID is also set to that of VRF 1.
Note In a CSC scenario, an outgoing MPLS label can be installed in forwarding by making a
configuration change. See How to Configure Inter-AS Option AB section on page 9.
9. While installing the MPLS forwarding entry for RD 7:N, the outgoing label is installed during the
forwarding process, which enables the traffic between the ASBRs to be MPLS traffic.
the source prefix RD 5:N to PE2. This advertisement is suppressed as the prefix is being imported
into an Option AB VRF.
Packet Forwarding for VPN 1

The packet forwarding process shown below works the same as it does in an Option A scenario. See
MPLS VPNInter-AS Option AB Route Distribution and Packet Forwarding in Non-CSC Networks
section on page 4 for more information about Option A.
1. PE 4 sends an MPLS packet destined for N to CE2.
2. CE2 swaps the MPLS label and sends a packet destined for N to PE2.
3. PE2 encapsulates the packet with the VPN label allocated by ASBR2 and the IGP label needed to
tunnel the packet to ASBR2.
4. The packet arrives on ASBR2 with the VPN label. ASBR2 swaps the received VPN label with the
outgoing label received from ASBR1 and sends the MPLS packet on to the VRF 1 interface.
5. The MPLS packet arrives at ASBR1 on the VRF 1 interface. ASBR1 then swaps the received MPLS
label with a label stack consisting of the VPN label allocated by PE1 and the IGP label needed to
tunnel the packet to PE1.
6. The packet arrives on PE1 with the VPN label. PE1 disposes the VPN label and forwards the MPLS
packet to CE1. CE1 in turn swaps the label and forwards the labeled packet to PE 3.

8
How to Configure Inter-AS Option AB

The following sections describe how to configure the Inter-AS Option AB feature on an ASBR for either
an MPLS VPN or an MPLS VPN that supports CSC:
Configuring an Inter-AS Option AB Connection, page 9
Changing an Inter-AS Option A Deployment to an Option AB Deployment, page 15
Configuring an Inter-AS Option AB Connection

The following sections are required and describe how to configure an Inter-AS Option AB connection
on an ASBR:
Configuring the VRFs on the ASBR Interface for Each VPN Customer, page 9
Configuring the MP-BGP Session Between ASBR Peers, page 11
Configuring the Routing Policy for VPNs that Need Inter-AS Connections, page 13
Note See the Configuring MPLS Layer 3 VPNs feature module for more information on configuring PE and
CE routers in an MPLS VPN.
Configuring the VRFs on the ASBR Interface for Each VPN Customer
Use the following steps to configure the VRFs on the ASBR interface for each VPN customer so that
these VPNs have connectivity over the MPLS VPNInter-AS Option AB network.
SUMMARY STEPS
1. enable
5. mpls bgp forwarding (Optional)
6. end
Note The mpls bgp forwarding command is used only on the ASBR interface for VRFs that support CSC.
Use all of the steps in the following procedure to configure additional VRFs that need to be configured
on the ASBR interface and the VRFs that need to be configured on the peer ASBR interface.
9
DETAILED STEPS

Example:
Router> enable
Example:
configuration mode.
subinterface.
Step 5 mpls bgp forwarding (Optional) This step applies to a CSC network only.
Configures BGP to enable MPLS forwarding on connecting
interfaces for VRFs that must support MPLS traffic.
Example:
Example:

10
Configuring the MP-BGP Session Between ASBR Peers

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.
Follow the steps in this section to configure the MP-BGP session on the ASBR.
SUMMARY STEPS
1. enable
7. neighbor {ip-address | peer-group-name} inter-as-hybrid
9. end
Use all of the steps in the following procedure to configure the MP BGP session on the peer ASBR.
11
DETAILED STEPS

Example:
Router> enable
Example:
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.
Example: neighbor.
BGP peer group.
Step 5 address-family vpn4 [unicast] Enters address family configuration mode for configuring
address prefixes.
Example:
Router(config-router)# address-family vpn4 The unicast keyword specifies IPv4 unicast address
prefixes.
activate router.
Example: neighbor.
BGP peer group.

12

Step 7 neighbor {ip-address | peer-group-name} Configures eBGP peer router (ASBR) as an Inter-AS
inter-as-hybrid Option AB peer.
Example: neighbor.
inter-as-hybrid The peer-group-name argument specifies the name of a
BGP peer group.
If any prefixes are imported into Option AB VRFs, then
the imported paths are advertised to this peer.
If any prefixes are received from this peer and are
imported into Option AB VRFs, then the imported
paths are advertised to iBGP peers.
Note Advertised routes have RTs that are configured on
the VRF. Advertised routes do not have their
original RTs.
Step 8 exit-address-family Exits from the address family configuration submode.
Example:
Example:
Configuring the Routing Policy for VPNs that Need Inter-AS Connections
Use the steps in this section to configure VRFs for the VPNs that need Inter-AS connections between
ASBR peers, by configuring the appropriate routing policy and Option AB configuration.
SUMMARY STEPS
1. enable
5. address-family ipv4
7. inter-as-hybrid [csc]
8. inter-as-hybrid [csc] next-hop ip-address
9. exit
Use all of the steps in the following procedure to configure additional VPNs that need Inter-AS Option
AB connectivity on this ASBR and the peer ASBR.
13
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 vrf definition vrf-name Defines the VPN routing instance by assigning a VRF name
Router(config)# vrf definition vpn1
16-bit autonomous system number: your 32-bit
number, for example, 101:3
192.168.122.15:1
Step 5 address-family ipv4 Enters VRF address family configuration mode to specify
Router(config-vrf)# address-family ipv4 a VRF.
Example:
Router(config-vrf-af)# route-target import
100:1 target VPN extended community.
extended community.
route-target extended community attributes to the VRF
list of import, export, or both (import and export)

14

Step 7 inter-as-hybrid [csc] Specifies the VRF as an Option AB VRF, which has the
following effects:
Example: Routes imported to this VRF can be advertised to
Router(config-vrf-af)# inter-as-hybrid Option AB peers and VPNv4 iBGP peers.
When routes received from Option AB peers and are
imported into the VRF, the next hop table ID of the
route is set to the table ID of the VRF.
If the csc keyword is not used, a per-VRF label is
allocated for imported routes.
When routes are received from Option AB peers and are
imported next into the VRF, the learned out label can
only be installed in forwarding when the csc keyword is
used.
The csc keyword implies the following:
A per-prefix label is allocated for imported routes.
For routes received from Option AB peers that are
imported into the VRF, the learned out label is installed
in forwarding.
Step 8 inter-as-hybrid [csc] next-hop ip-address (Optional) Specifies the next hop IP address to be set on
paths that are imported into the VRF and that are received
from an Option AB peer. The next hop context is also set to
Example:
Router(config-vrf-af)# inter-as-hybrid next-hop
the VRF, which imports these paths.
192.168.1.0 The csc keyword implies the following:
A per-prefix label is allocated for imported routes.
For routes received from Option AB peers that are
imported into the VRF, the learned outlabel is installed
in forwarding.
Example:
Router(config-vrf-af)# exit
Changing an Inter-AS Option A Deployment to an Option AB Deployment

In an Option A deployment, the VRF instances are back-to-back between the ASBR routers and there is
direct connectivity between PE routers of different autonomous systems. The PE routers are attached by
multiple physical or logical interfaces, each of which is associated with a given VPN (through a VRF
instance).
In the Option AB deployment, the different autonomous systems interconnect by using a single MP-BGP
session in the global routing table to carry control plane traffic.
15
Use the following steps to change an MPLS VPN Inter-AS Option A deployment to an Option AB
deployment.
1. Configure the MP-BGP session on the ASBR. BGP multiprotocol extensions are used to define
support for address families other than IPv4 so 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. See
Configuring the MP-BGP Session Between ASBR Peers section on page 11 for detailed
configuration information.
2. Identify the VRFs that need an upgrade from Option A and configure them for Option AB by using
the inter-as-hybrid command. See Configuring the Routing Policy for VPNs that Need Inter-AS
Connections section on page 13 for detailed configuration information.
3. Use the following steps in this section to remove the configuration for the eBGP (peer ASBR)
neighbor.
SUMMARY STEPS
1. enable
5. no neighbor {ip-address | peer-group-name}
7. end
Repeat all the steps in the following procedure to remove the configuration for additional eBGP (peer
ASBR) neighbors.
DETAILED STEPS

Example:
Router> enable
Example:

16

Step 4 address-family ipv4 vrf vrf-name Configures each VRF that is identified in the MP-BGP
session on the ASBR so that the routes for a given VPN are
learned only by other members of that VPN, enabling
Example:
members of the VPN to communicate with each other.
vpn4 Enters address family configuration mode to specify an
address family for a VRF.
Step 5 no neighbor {ip-address | peer-group-name} Removes the configuration for the exchange of information
with the neighboring eBGP (ASBR) router.
Router(config-router-af)# no neighbor neighbor.
192.168.0.1
BGP peer group.
Step 6 exit-address-family Exits from address family configuration mode.
Example:
Example:
17
Configuration Examples for MPLS VPNInter-AS Option AB

The following sections describe standard and CSC MPLS VPN configurations between two ASBR peers
that use the Inter-AS AB feature:
Inter-AS AB Network Configuration: Examples, page 18
Inter-AS AB CSC Configuration: Examples, page 27
Inter-AS AB Network Configuration: Examples

The following examples show the configuration of an inter-AS option AB network that uses non
overlapping IP addresses:
CE1: Example, page 18
PE1: Example, page 19
Route Reflector 1: Example, page 20
ASBR1: Example, page 21
ASBR 3: Example, page 23
CE 4: Example, page 26
CE1: Example
!
ip cef distributed
!
interface lo0
ip address 192.168.13.13 255.255.255.255
no shutdown
!
interface et4/0
ip address 192.168.36.1 255.255.255.0
no shutdown
!
router ospf 300
nsf enforce global
passive-interface et4/0
network 192.168.13.13 0.0.0.0 area 300
!
router bgp 300
no synchronization
address-family ipv4 no auto-summary

18
CE2: Example
!
ip cef distributed
!
interface lo0
ip address 192.168.14.14 255.255.255.255
no shutdown
!
interface et1/6
ip address 192.168.37.1 255.255.255.0
no ipv6 address
no shutdown
!
router ospf 400
nsf enforce global
network 192.168.14.14 0.0.0.0 area 400
!
router bgp 400
no synchronization
!
PE1: Example
!
ip cef distributed
!
ip vrf vpn1
rd 100:1
!
ip vrf vpn2
rd 100:2
!
mpls ldp router-id lo0 force
mpls ip
mpls ip propagate-ttl
!
interface lo0
ip address 192.168.17.17 255.255.255.255
no shutdown
!
interface gi3/1
19

ip address 192.168.36.2 255.255.255.0
no shutdown
!
interface gi3/8
mpls ip
ip address 192.168.31.2 255.255.255.0
!
interface gi3/10
mpls ip
ip address 192.168.40.1 255.255.255.0
no shutdown
!
interface gi3/13
ip address 192.168.0.2 255.0.0.0
no shutdown
!
router ospf 100
nsf enforce global
passive-interface gi3/1
network 192.168.0.0 0.0.255.255 area 10
network 192.168.17.17 0.0.0.0 area 100
network 192.168.0.0 0.0.255.255 area 100
!
router bgp 100
no synchronization
no auto-summary
address-family ipv4 vrf vpn2 no auto-summary
!
Route Reflector 1: Example

!
ip cef distributed


20
mpls ip
mpls ip
!
interface lo0
ip address 192.168.19.19 255.255.255.255
no shutdown
!
interface gi3/3
mpls ip
ip address 192.168.40.2 255.255.255.0
no shutdown
!
router ospf 100
nsf enforce global
network 192.168.19.19 0.0.0.0 area 100
network 192.168.0.0 0.0.255.255 area 100 !
router bgp 100
address-family ipv4
no neighbor 192.168.17.17 activate
!
ASBR1: Example
!
ip cef distributed
!
ip vrf vpn1
rd 100:1
inter-as-hybrid next-hop 192.168.32.2
exit
ip vrf vpn2
rd 100:2
21

exit
mpls ip
mpls ip
interface lo0
ip address 192.168.11.11 255.255.255.255
no ipv6 address
ip route-cache cef distributed
no shutdown
interface gi3/8
mpls ip
ip address 192.168.13.1 255.255.255.0
no ipv6 address
no shutdown
interface gi3/10
ip address 192.168.32.1 255.255.255.0
no ipv6 address
no shutdown
interface gi3/11
ip address 192.168.33.1 255.255.255.0
no ipv6 address
no shutdown
interface gi3/46
ip address 192.168.34.1 255.255.255.0
no ipv6 address
no shutdown
router ospf 100

nsf enforce global
network 192.168.0.0 0.0.255.255 area 100
network 192.168.11.11 0.0.0.0 area 100
router bgp 100

no synchronization

22

address-family ipv4
no auto-summary
no auto-summary
no auto-summary
neighbor 192.168.34.2 inter-as-hybrid
neighbor 192.168.19.19 send-community extended !
ip route vrf vpn1 192.168.12.12 255.255.255.255 gi3/10 192.168.32.2
!
ASBR 3: Example
!
ip cef distributed
!
ip vrf vpn1
rd 200:1
!
ip vrf vpn2
rd 200:2
!
mpls ip
!
interface lo0
ip address 192.168.12.12 255.255.255.255
no shutdown
!
interface po2/1/0
mpls ip
ip address 192.168.35.1 255.255.255.0
crc 16
no shutdown
!
interface gi3/10
23

ip address 192.168.32.2 255.255.255.0
no shutdown
!
interface gi3/11
ip address 192.168.33.2 255.255.255.0
no shutdown
!
interface gi3/45
ip address 192.168.34.2 255.255.255.0
no shutdown
!
router ospf 200
nsf enforce global
router bgp 200

no synchronization
address-family ipv4
no auto-summary
no auto-summary
no auto-summary
neighbor 192.168.20.20 send-community extended !
!
PE2: Example
!
ip cef distributed
!
ip vrf vpn1
rd 200:1
!
ip vrf vpn2

24
rd 200:2
!
mpls ip
!
interface lo0
ip address 192.168.18.18 255.255.255.255
no shutdown
!
interface po1/0/0
mpls ip
ip address 192.168.35.2 255.255.255.0
crc 16
no shutdown
!
interface gi3/2
ip address 192.168.38.2 255.255.255.0
no shutdown
!
interface gi3/8
mpls ip
ip address 192.168.4.1 255.255.255.0
no shutdown
!
interface gi3/10
ip address 192.168.39.2 255.255.255.0
no shutdown
!
router ospf 200
nsf enforce global
network 192.168.0.0 0.0.255.255 area 200
network 192.168.18.18 0.0.0.0 area 200
network 192.168.0.0 0.0.255.255 area 200 !
router bgp 200
no synchronization
no auto-summary
25
no auto-summary
!
CE3: Example
!
ip cef distributed
!
interface lo0
ip address 192.168.15.15 255.255.255.255
no shutdown
!
interface gi0/2
ip address 192.168.38.1 255.255.255.0
no shutdown
!
router ospf 500
nsf enforce global
network 192.168.15.15 0.0.0.0 area 500
!
router bgp 500
no synchronization
address-family ipv4
no auto-summary
!
CE 4: Example
!
ip cef distributed
!
interface lo0
ip address 192.168.16.16 255.255.255.255
no shutdown
!
interface et6/2
ip address 192.168.9.1 255.255.255.0
no shutdown
!
router ospf 600
nsf enforce global

26
network 192.168.16.16 0.0.0.0 area 600
!
router bgp 600
no synchronization
!
Inter-AS AB CSC Configuration: Examples

The following examples show the configuration of an inter-AS option AB network with CSC:
CE 4: Example, page 29
CSC-CE1: Example, page 30
CSC-PE1: Example, page 31
PE 2: Example, page 32
ASBR1: Example, page 34
CSC-PE 3: Example, page 37
CSC-CE 4: Example, page 39
CE1: Example
!
ip cef distributed
!
interface Loopback0
ip address 192.168.20.20 255.255.255.255
!
ip address 192.168.41.2 255.255.255.0
!
!
router bgp 500
27

!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
CE2: Example
!
ip cef distributed
!
interface Loopback0
ip address 192.168.21.21 255.255.255.255
!
ip address 192.168.42.2 255.255.255.0
!
router bgp 600
bgp graceful-restart neighbor 192.168.42.1 remote-as 400
!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
CE3: Example
!
ip cef distributed
!
interface Loopback0
ip address 192.168.22.22 255.255.255.255
!
ip address 192.168.43.2 255.255.255.0
!
router bgp 500
bgp graceful-restart neighbor 192.168.43.1 remote-as 300
!
address-family ipv4
no auto-summary

28
no synchronization
exit-address-family
!
CE 4: Example
!
ip cef distributed
!
interface Loopback0
ip address 192.168.23.23 255.255.255.255
!
!
ip address 192.168.44.2 255.255.255.0
!
router bgp 600
!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
PE1: Example
!
ip cef distributed
!
ip vrf vpn3
rd 300:3
!
!
!
mpls ip
!
interface Loopback0
ip address 192.168.192.10 255.255.255.255
!
ip address 192.168.4.1 255.255.255.0
!
ip address 192.168.3.1 255.255.255.0
mpls ip
!
29
!
router ospf 300
network 192.168.192.10 0.0.0.0 area 300
network 192.168.0.0 0.0.255.255 area 300
!
router bgp 300
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
CSC-CE1: Example
!
ip cef distributed
!
!
mpls ip
!
interface Loopback0
ip address 192.168.11.11 255.255.255.255
!
!
ip address 192.168.30.2 255.255.255.0
mpls ip
!
router ospf 300
passive-interface FastEthernet1/0
network 192.168.11.11 0.0.0.0 area 300
network 192.168.0.0 0.0.255.255 area 300
distance ospf intra-area 19 inter-area 19

30
!
router bgp 300
!
address-family ipv4
redistribute ospf 300 metric 4 match internal external 1 external 2
no auto-summary
no synchronization
exit-address-family
!
CSC-PE1: Example
!
ip vrf vpn1
rd 100:1
!
ip vrf vpn2
rd 100:2
!
!
mpls ip
!
interface Loopback0
ip address 192.168.12.12 255.255.255.255
!
!
ip address 192.168.34.1 255.255.255.0
mpls ip
!
ip address 192.168.13.1 255.255.255.0
mpls bgp forwarding
!
!
ip address 192.168.33.1 255.255.255.0
mpls bgp forwarding
!
router ospf 100
31
nsf enforce global
network 192.168.12.12 0.0.0.0 area 100
network 192.168.0.0 0.0.255.255 area 100
!
router bgp 100
!
exit-address-family
!
neighbor 192.168.33.2 update-source FastEthernet4/1/0
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
PE 2: Example
ip cef distributed
!
ip vrf vpn4
rd 400:4
!
!
!
mpls ip
!
interface Loopback0

32
ip address 192.168.13.13 255.255.255.255

!
!
ip address 192.168.42.1 255.255.255.0
!
!
ip address 192.168.32.1 255.255.255.0
mpls ip
!
!
router ospf 400
nsf enforce global
network 192.168.13.13 0.0.0.0 area 400
network 192.168.0.0 0.0.255.255 area 400
!
router bgp 400
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
CSC-CE2: Example
!
ip cef distributed
!
!
mpls ip
interface Loopback0
ip address 192.168.14.14 255.255.255.255
!
!
33
ip address 192.168.33.2 255.255.255.0
mpls bgp forwarding
!
!
ip address 192.168.32.2 255.255.255.0
mpls ip
!
!
router ospf 400
nsf enforce global
passive-interface GigabitEthernet8/16
network 192.168.14.14 0.0.0.0 area 400
network 192.168.0.0 0.0.255.255 area 400
!
router bgp 400
!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
ASBR1: Example
!
ip vrf vpn5
rd 100:5
inter-as-hybrid csc next-hop 192.168.35.2
!
ip vrf vpn6
rd 100:6
!

34

!
!
interface Loopback0
ip address 192.168.15.15 255.255.255.255
!
ip address 192.168.35.1 255.255.255.0
mpls bgp forwarding
!
ip address 192.168.36.1 255.255.255.0
mpls bgp forwarding
!
!
ip address 192.168.34.2 255.255.255.0
mpls ip
!
!
ip address 192.168.37.1 255.255.255.0
mpls bgp forwarding
!
!
router ospf 100
nsf enforce global
network 192.168.15.15 0.0.0.0 area 100
network 192.168.0.0 0.0.255.255 area 100
!
router bgp 100
neighbor 192.168.0.2 disable-connected-check
!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
exit-address-family
!
no synchronization
35
exit-address-family
!
no synchronization
exit-address-family
!
ip route 192.168.16.16 255.255.255.255 GigabitEthernet2/16 192.168.0.2
ip route vrf vpn5 192.168.16.16 255.255.255.255 GigabitEthernet2/3 192.168.35.2
!
ip vrf vpn5
rd 200:5
!
ip vrf vpn6
rd 200:6
!
!
!
interface Loopback0
ip address 192.168.16.16 255.255.255.255
!
!
ip address 192.168.35.2 255.255.255.0
mpls bgp forwarding
!
ip address 192.168.36.2 255.255.255.0
mpls bgp forwarding
! !
ip address 192.168.0.2 255.0.0.0
mpls bgp forwarding
!
ip address 192.168.38.2 255.255.255.0
mpls ip
!
router ospf 200
nsf enforce global
network 192.168.16.16 0.0.0.0 area 200
network 192.168.0.0 0.0.255.255 area 200
!
router bgp 200

36

neighbor 192.168.37.1 disable-connected-check
!
address-family ipv4
no synchronization
no auto-summary
exit-address-family
!
exit-address-family
!
no synchronization
exit-address-family
!
no synchronization
exit-address-family
!
ip route 192.168.15.15 255.255.255.255 GigabitEthernet3/14 192.168.37.1
!
CSC-PE 3: Example
ip vrf vpn1
rd 200:1
!
ip vrf vpn2
rd 200:2
!
!
mpls ip
!
interface Loopback0
ip address 192.168.17.17 255.255.255.255
!
37
ip address 192.168.5.1 255.255.255.0
mpls bgp forwarding
!
!
ip address 192.168.9.1 255.255.255.0
mpls bgp forwarding
!
!
ip address 192.168.38.1 255.255.255.0
mpls ip
!
router ospf 200
nsf enforce global
network 192.168.17.17 0.0.0.0 area 200
network 192.168.0.0 0.0.255.255 area 200
!
router bgp 200
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!

38
CSC-CE3: Example
!
interface Loopback0
ip address 192.168.18.18 255.255.255.255
!
!
ip address 192.168.40.2 255.255.255.0
mpls ip
!
!
ip address 192.168.39.2 255.255.255.0
mpls bgp forwarding
!
!
router ospf 300
network 192.168.18.18 0.0.0.0 area 300
network 192.168.0.0 0.0.255.255 area 300
!
router bgp 300
!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
CSC-CE 4: Example
!
ip cef distributed
!
!
mpls ip
!
interface Loopback0
ip address 192.168.24.24 255.255.255.255
!
!
ip address 192.168.55.0 255.255.255.0
mpls bgp forwarding
39
!
!
ip address 192.168.56.2 255.255.255.0
mpls ip
!
!
router ospf 400
network 192.168.24.24 0.0.0.0 area 400
network 192.168.0.0 0.0.255.255 area 400
!
router bgp 400
!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
PE 3: Example
!
ip cef distributed
!
ip vrf vpn3
rd 300:3
mpls ip
!
!
!
!
interface Loopback0
ip address 192.168.19.19 255.255.255.255
!
!
ip address 192.168.43.1 255.255.255.0
!
!
ip address 192.168.40.1 255.255.255.0
mpls ip
!
!

40
router ospf 300

nsf enforce global
network 192.168.19.19 0.0.0.0 area 300
network 192.168.0.0 0.0.255.255 area 300
network 192.168.0.0 0.0.255.255 area 300
!
router bgp 300
!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
PE 4: Example
!
ip cef distributed
!
ip vrf vpn4
rd 400:4
!
mpls ldp protocol ldp
!
mpls ip
!
interface Loopback0
ip address 192.168.25.25 255.255.255.255
!
!
ip address 192.168.56.1 255.255.255.0
mpls ip
41
!
!
ip address 192.168.44.1 255.255.255.0
!
!
router ospf 400
nsf enforce global
network 192.168.25.25 0.0.0.0 area 400
network 192.168.0.0 0.0.255.255 area 400
!
router bgp 400
neighbor 192.168.13.13 ebgp-multihop 7
!
address-family ipv4
no auto-summary
no synchronization
exit-address-family
!
exit-address-family
!
no auto-summary
no synchronization
exit-address-family
!
The following sections provide references related to the MPLS VPNInter-AS Option AB feature.
Related Documents, page 43
Standards, page 43
MIBs, page 43
RFCs, page 43
Technical Assistance, page 44

42
Related Documents
MPLS VPNs Configuring MPLS Layer 3 VPNs
MPLS VPN Interautonomous Systems MPLS VPN Inter-AS with ASBRs Exchanging VPN-IPv4
Addresses
MPLS VPN Inter-AS with ASBRs Exchanging IPv4 Routes and
MPLS Labels
Standards
Standard Title
MIBs
MIB MIBs Link
RFCs
RFC Title
RFC 4366 BGP/MPLS IP Virtual Private Networks
43
Description Link

44
Feature Information for MPLS VPNInter-AS Option AB
Feature Information for MPLS VPNInter-AS Option AB

Table 1 Feature Information for MPLS VPNInter-AS Option AB
Feature Name Release Feature Information

MPLS VPNInter-AS Option AB 12.2(33)SRC This feature combines the best functionality of an inter-AS
option (10) A and inter-AS option (10) B network to allow
an MPLS VPN service provider to interconnect different
autonomous systems to provide VPN services.
15.0(1)M This feature was introduced in 15.0(1)M. The following
commands were introduced or modified:
neighbor inter-as-hybrid
inter-as-hybrid
45
Glossary
Glossary
routing strategy.
BGPBorder Gateway Protocol. An interdomain routing protocol that exchanges network reachability
information with other BGP systems (which may be within the same autonomous system or between
multiple autonomous systems).
provider edge (PE) router. CE routers do not recognize associated MPLS VPNs.
CSCCarrier Supporting Carrier. A hierarchical VPN model that allows small Service Providers, or
customer carriers, to interconnect their IP or MPLS networks over an MPLS backbone. This eliminates
the need for customer carriers to build and maintain their own MPLS backbone.
eBGPexternal Border Gateway Protocol. A BGP between routers located within different autonomous
systems. When two routers, located in different autonomous systems, are more than one hop away from
one another, the eBGP session between the two routers is considered a multihop BGP.
iBGPinternal Border Gateway Protocol. A BGP between routers within the same autonomous system.
IGPInterior Gateway Protocol. Internet protocol used to exchange routing information within a single
autonomous system. Examples of common Internet IGP protocols include IGRP, OSPF, IS-IS, and RIP.
IPInternet 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.
LFIBLabel Forwarding Information Base. Data structure used in MPLS to hold information about
incoming and outgoing labels and associated Forwarding Equivalence Class (FEC) packets.
MP-BGPMultiprotocol BGP.
MPLSMultiprotocol Label Switching. The name of the IETF working group responsible for label
switching, and the name of the label switching approach it has standardized.
NLRINetwork Layer Reachability Information. The BGP sends routing update messages containing
NLRI to describe a route and how to get there. In this context, an NLRI is a prefix. A BGP update
message carries one or more NLRI prefixes and the attributes of a route for the NLRI prefixes; the route
attributes include a BGP next hop gateway address and extended community values.
NSFNonstop forwarding enables routers to continuously forward IP packets following a Route
Processor takeover or switchover to another Route Processor. NSF maintains and updates Layer 3
routing and forwarding information in the backup Route Processor to ensure that IP packets and routing
protocol information are forwarded continuously during the switchover and route convergence process.
PE routerprovider edge router. A router that is part of a service providers network. It is connected
to a customer edge (CE) router. All MPLS VPN processing occurs in the PE router.
QoSquality of service. Measure of performance for a transmission system that indicates its
transmission quality and service availability.
VPN-IPv4 prefix.
RTroute target. Extended community attribute used to identify the VRF routing table into which a
prefix is imported.
SLAService Level Agreement given to VPN subscribers.

46
Glossary
VPNVirtual Private Network. A secure MPLS-based network that shares resources on one or more
physical networks (typically implemented by one or more service providers). A VPN contains
geographically dispersed sites that can communicate securely over a shared backbone network.
VRFVPN routing and forwarding instance. Routing information that defines a VPN site that is
attached to a PE router. 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.
coincidental.
47
Glossary

48
MPLS Embedded Management and MIBs
MPLS EMMPLS LSP Multipath Tree Trace

Last Updated: Ferbruay 27, 2009
The MPLS EMMPLS 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 EMMPLS LSP Multipath Tree Trace feature to discover all paths for an IPv4
LSP.
This implementation of the MPLS EMMPLS 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 Embedded
ManagementLSP Ping/Traceroute and AToM VCCV feature module.
Cisco IOS 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.

supported, see the Feature Information for MPLS EMMPLS LSP Multipath Tree Trace section on
page 33.
Contents
Contents
Prerequisites for MPLS EMMPLS LSP Multipath Tree Trace, page 2
Restrictions for MPLS EMMPLS LSP Multipath Tree Trace, page 2
Information About MPLS EMMPLS LSP Multipath Tree Trace, page 3
How to Configure MPLS EMMPLS LSP Multipath Tree Trace, page 4
Configuration Examples for MPLS EMMPLS LSP Multipath Tree Trace, page 22
Feature Information for MPLS EMMPLS LSP Multipath Tree Trace, page 33
Glossary, page 35
Prerequisites for MPLS EMMPLS LSP Multipath Tree Trace

The following are prerequisites for using the MPLS EMMPLS 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 EMMPLS LSP Multipath Tree Trace

All restrictions that apply to the MPLS LSP Ping and LSP Traceroute features also apply to the
MPLS EMMPLS 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 EMMPLS LSP Multipath Tree Trace
Information About MPLS EMMPLS LSP Multipath Tree Trace

Before using the MPLS EMMPLS 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 EMMPLS 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 EMMPLS 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 EMMPLS 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 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 EMMPLS 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:
Router(config)# mpls oam
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:
Router(config-mpls)# echo revision 4
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 vendors extension TLVs that another vendors
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 FRC-4379 and another vendors implementation exists that is not
capable of properly handling Ciscos 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 vendors extension TLVs that another vendors
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,
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 Et0/0 source 10.1.111.101
destination 127.0.0.0
Tracing MPLS Label Switched Path to 10.1.1.150/32, timeout is 2 seconds


0 10.1.111.101 MRU 1500 [Labels: 33 Exp: 0]
L 1 10.1.111.111 MRU 1500 [Labels: 34 Exp: 0] 40 ms
L 4 10.4.140.240 MRU 1504 [Labels: implicit-null Exp: 0] 20 ms
! 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

For Cisco IOS Release 12.2(27)SXE, Cisco added 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 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.
Step 3 exit Returns to user EXEC mode.
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:
ipv4Reply with an IPv4 User Datagram Protocol (UDP) packet (default)
router-alertReply 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 packetRouter alert IP packetRouter 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 packetRouter 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 keywordReply with an IPv4 UDP
packet (default).
The router-alert keywordReply 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 ethernet0/0 The destination-address argument is the address prefix
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 LSPs 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
maximum-time-to-live]
3. exit
DETAILED STEPS

Example:
Router> enable
destination-mask-length [flags fec] [ttl ingress router and requests validation of the target FEC
maximum-time-to-live]
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 rertry-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 EMMPLS LSP Multipath Tree Trace
Configuration Examples for MPLS EMMPLS LSP Multipath

Tree Trace
This section includes the following configuration examples for the MPLS EMMPLS 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
no echo vendor-extension
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
no echo vendor-extension
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 ethernet0/0
Tracing MPLS Label Switched Path to 10.1.1.150/32, timeout is 2 seconds


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 Et0/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 EMMPLS LSP Multipath Tree Trace
feature.
Related Documents
Concepts and configuration tasks for MPLS LSP ping MPLS Embedded ManagementLSP Ping/Traceroute and AToM
or traceroute VCCV
Concepts and configuration for MPLS and other MPLS Cisco IOS Multiprotocol Label Switching Configuration Guide
applications
Troubleshooting procedures for MPLS CiscoMPLS Troubleshooting
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
Command Reference
Description Link
Command Reference
debug mpls lspv
echo
mpls oam
trace mpls
trace mpls multipath
32
Feature Information for MPLS EMMPLS LSP Multipath Tree Trace
Feature Information for MPLS EMMPLS LSP Multipath Tree

Trace
Table 3 Feature Information for MPLS EMMPLS LSP Multipath Tree Trace

MPLS EMMPLS LSP Multipath Tree 12.2(31)SB2 The MPLS EMMPLS LSP Multipath Tree Trace feature
Trace 12.2(33)SRB provides the means to discover all the possible paths of a
12.4(20)T label switched path (LSP) between an egress and ingress
12.2(33)SXI 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 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.
In Cisco IOS Release 12.2(31)SB2, this feature was
introduced.
In Cisco IOS Release 12.2(33)SRB, support was added for
a Cisco IOS 12.2SR release.
In Cisco IOS Release 12.(20)T, support was added for a
Cisco IOS 12.4T release.
In Cisco IOS Release 12.2(33)SXI, support was added for a
Cisco IOS 12.2SX release.
33
Feature Information for MPLS EMMPLS LSP Multipath Tree Trace
Table 3 Feature Information for MPLS EMMPLS LSP Multipath Tree Trace (continued)

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
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
ECMPequal-cost multipath. Multiple routing paths of equal cost that may be used for packet
forwarding.
FECForwarding 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.
flowA 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.
localhostA name that represents the host router (device). The localhost uses the reserved loopback IP
address 127.0.0.1.
LSPlabel switched path. A connection between two routers in which MPLS forwards the packets.
LSPVLabel 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 labelAn 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.
OAMOperation, Administration, and Management.
puntRedirect packets with a router alert from the line card or interface to Route Processor (RP) level
processing for handling.
RPRoute 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.
TTLtime-to-live. A parameter you can set that indicates the maximum number of hops a packet should
take to reach its destination.
TLVtype, length, values. A block of information included in a Cisco Discovery Protocol address.
UDPUser 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.
XDReXternal 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
coincidental.
36
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.
History for MPLS Enhancements to Interfaces MIB Feature

12.2(33)SB This feature was integrated into Cisco IOS Release 12.2(33)SB.
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

Prerequisites for MPLS Enhancements to Interfaces MIB
Glossary, page 13
Prerequisites for MPLS Enhancements to Interfaces MIB

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. Link up and link
down traps for the MPLS layer are supported in Cisco IOS Releases 12.2(33)SXH, 12.2(33)SB,
12.2(33)SRB and later releases.
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.
Starting in Cisco IOS Release 12.4, the high-capacity counters for the MPLS layer interfaces of the
Interfaces MIB contain 64 bits of counter data. In previous releases, 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
2
Information About MPLS Enhancements to Interfaces MIB
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.
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 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 interfaces or
subinterfaces, such as Ethernet (et0) or ATM (at1/1.1).
Cisco IOS 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.
3
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.
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.
4
Table 2 ifRcvAddressTable Objects and Descriptions
Object Definition
ifRcvAddressAddress An address for which the system accepts packets and frames on
this entrys 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.
Interfaces MIB Scalar Objects

The IF MIB supports the following scalar objects:
ifStackLastChangeThe 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.
ifTableLastChangeThe 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.
5
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
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 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.
6
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.
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:
7
How to Configure MPLS Enhancements to Interfaces MIB
mplsInterfaceOutPacketsCount only MPLS-encapsulated out packets

mplsInterfaceInPacketsCount only MPLS-encapsulated in packets
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)
Configuration Examples for the MPLS Enhancements to Interfaces MIB, page 10 (optional)
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
Step 7 show running-config Displays the running configuratoin of the router so that you
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.
10
Related Documents
SNMP commands Cisco IOS Network Management Command Reference,
Release 12.4T
Cisco IOS Network Management Command Reference,
Release 12.2SB
Release 12.2SR
SNMP configuration Configuring SNMP support in the Cisco IOS
Network Management Configuration Guide, Release 12.4
A description of SNMP agent support in Cisco IOS MPLS Label Switching Router MIB
software for the MPLS Label Switching Router MIB
(MPLS-LSR-MIB)
A description of SNMP agent support in Cisco IOS for MPLS Traffic Engineering (TE) MIB
the MPLS Traffic Engineering MIB (MPLS TE MIB)
Other documentation Multiprotocol Label Switching (MPLS) Label Switch Router (LSR)
Management Information Base, Internet draft, January 2002
[draft-ietf-mpls-lsr-mib-08.txt]; Srinivasan, C., Viswanathan, A.,
and Nadeau, T.D.
Note For information on using SNMP MIB features, see the
appropriate documentation for your network management
system.
Standards
Standards Title
MIBs
MIBs MIBs Link
Interfaces Group MIB (IF MIB) To locate and download MIBs for selected platforms, Cisco IOS
following URL:
11
Command Reference
RFCs
RFCs Title
RFC 1156 Management Information Base for Network Management of
TCP/IP-based internets
RFC 1157 A Simple Network Management Protocol (SNMP)
RFC 1213 Management Information Base for Network Management of
TCP/IP-based internets: MIB-II
RFC 1229 Extensions to the Generic-Interface MIB
RFC 2233 Interfaces MIB
Description Link
Command Reference
module. For information about these commands, use the Cisco IOS Multiprotocol Label Switching
http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.
snmp-server community
12
Glossary
Glossary
ATMAsynchronous 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-AAL5ATM 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.
encapsulationWrapping 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.
IETFInternet 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.
interfaceThe boundary between adjacent layers of the ISO model.
labelA short, fixed-length identifier that is used to determine the forwarding of a packet.
label switchingA 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.
MIBManagement Information Base. A database of network management information that is used and
maintained by a network management protocol such as 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 interfaceAn interface on which MPLS traffic is enabled.
MTUmaximum transmission unit. Maximum packet size, in bytes, that a particular interface can
handle.
NMSnetwork 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.
OIDobject 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 an 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 populated with the information
required for carrying out the test. The MIB can be configured so that when triggers are activated (fired)
either an SNMP Set is performed, a notification is sent out to the interested host, or both.
13
Glossary
SNMPSimple 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.
traffic engineering tunnelA 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.
trapA 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.
tunnelA secure communication path between two peers, such as routers.
coincidental.
20042008Cisco Systems, Inc. All rights reserved.
14
MPLS Label Switching Router MIB
The MPLS Label Switching Router MIB (MPLS-LSR-MIB) allows you to use the Simple Network
Management Protocol (SNMP) to remotely monitor a label switch router (LSR) that is using the
Multiprotocol Label Switching (MPLS) technology.
Scalability enhancements provided in the Cisco IOS 12.0(28)S release reduce the size of any MIB walk
and improve the usability of the MPLS-LSR-MIB.
ort the Internet Engineering Task Force (IETF) draft Version 8.
Note In Cisco IOS Release 12.2(33)SRB and Cisco IOS Release 12.2(33)SB, this MIB has been
deprecated and replaced by MPLS-LSR-STD-MIB (RFC 3813). In those two releases and in
later images, the entire MIB can be referenced by the name mplsLsrMIB for purposes of the
SNMP server excluded/included command. If other MIB object names need to be referenced on
the router, they must be referenced by MPLS-LSR-MIB::<table_entry_name>.
Feature History for MPLS Label Switching Router MIB

12.0(14)ST This feature was introduced on Cisco IOS Release 12.0(14)ST
12.0(22)S This feature was implemented on the Cisco 12000 series routers and
integrated into Cisco IOS Release 12.0(22)S.
12.2(14)S This feature was integrated into Cisco IOS Release 12.2(14)S and
implemented on Cisco 7200 and Cisco 7500 series routers.
12.2(25)S This feature was updated to work in the MPLS High Availability
environment with the Cisco 7500 series routers.
12.0(28)S This feature was updated to include scalability enhancements in Cisco IOS
Release 12.0(28)S.
12.2(33)SRB This MIB has been deprecated and replaced by MPLS-LSR-STD-MIB
(RFC 3813).
12.2(33)SB This MIB has been deprecated and replaced by MPLS-LSR-STD-MIB
(RFC 3813).

Contents
Contents
This document includes the following major sections:
Information About MPLS Label Switching Router MIB, page 2
How to Configure the MPLS LSR MIB, page 13
Configuration Examples for the MPLS LSR MIB, page 15
Glossary, page 17
Information About MPLS Label Switching Router MIB

The MPLS-LSR-MIB contains managed objects that support the retrieval of label switching information
from a router. The MIB is based on Revision 05 of the IETF MPLS-LSR-MIB. The MPLS-LSR-MIB
mirrors a portion of the Cisco MPLS subsystem; specifically, it mirrors the Label Forwarding
Information Base (LFIB). This implementation enables a network administrator to get information on
the status, character, and performance of the following:
MPLS-capable interfaces on the LSR
Incoming MPLS segments (labels) at an LSR and their associated parameters
Outgoing segments (labels) at an LSR and their associated parameters
In addition, the network administrator can retrieve the status of cross-connect table entries that associate
MPLS segments with each other.
Figure 1 shows the association of the cross-connect table with incoming and outgoing segments (labels).
Figure 1 Label Forwarding with the Cross-Connect Table
Out-segment
label, interface
20, atm2
In-segment
label
1000 Pop, eth1/5

103242
Pop, eth1/1
Cross-connect table
2
Note The out-segment table does not display no label entries. Labels that are displayed as POP are the
special MPLS label 3.
The notation used in the MPLS-LSR-MIB follows the conventions defined in Abstract System Notation
One (ASN.1). ASN.1 defines an Open System Interconnection (OSI) language used to describe data
types apart from particular computer structures and presentation techniques. Each object in the MIB
incorporates a DESCRIPTION field that includes an explanation of the objects meaning and usage,
which, together with the other characteristics of the object (SYNTAX, MAX-ACCESS, and INDEX)
provides sufficient information for management application development, as well as for documentation
and testing.
The MPLS-LSR-MIB represents an ASN.1 notation reflecting an idealized MPLS LSR.
A network administrator can access the entries (objects) in the MPLS-LSR-MIB by means of any
SNMP-based network management system (NMS). The network administrator can retrieve information
in the MPLS-LSR-MIB using standard SNMP get and getnext operations.
Typically, SNMP runs as a low-priority process. The response time for the MPLS-LSR-MIB is expected
to be similar to that for other MIBs. The size and structure of the MIB and other MIBs in the system
influence response time when you retrieve information from the management database. Traffic through
the LSR also affects SNMP performance. The busier the switch is with forwarding activities, the greater
the possibility of lower SNMP performance.
MPLS-LSR-MIB Elements
The top-level components of the MPLS-LSR-MIB consist of
Tables and scalars (mplsLsrObjects)
Traps (mplsLsrNotifications and mplsLsrNotifyPrefix)
Conformance (mplsLsrConformance)
This Cisco implementation does not support the notifications defined in the MIB, nor does it support the
labelStackTable or the trafficParamTable.
MPLS-LSR-MIB Tables
The Cisco implementation of the MPLS-LSR-MIB supports four main tables:
Interface configuration
In-segment
Out-segment
Cross-connect
The MIB contains three supplementary tables to supply performance information. This implementation
does not support the label stack and traffic parameter tables.
The following sections list the MPLS-LSR-MIB tables (main and supplementary), their functions, table
objects that are supported, and table objects that are not supported.
MPLS interface configuration table (mplsInterfaceConfTable)

Provides information for each MPLS-capable interface on an LSR.
3
Supports:
A unique interface index or zero
Minimum and maximum values for an MPLS label received on the interface
Minimum and maximum values for an MPLS label sent from the interface
A value for an MPLS label sent from the interface
Per platform (0) or per interface (1) setting
The storage type
Does not support:
The total usable bandwidth on the interface
The difference between the total usable bandwidth and the bandwidth in use
MPLS interface performance table (mplsInterfacePerfTable)

Augments the MPLS interface configuration table.
Supports:
The number of labels in the incoming direction in use
The number of top-most labels in outgoing label stacks in use
Does not support:
The number of top-most labels in outgoing label stacks in use
The number of labeled packets discarded because no cross-connect entries exist
The number of outgoing MPLS packets requiring fragmentation for transmission
MPLS in-segment table (mplsInSegmentTable)

Contains a description of incoming segments (labels) at an LSR and their associated parameters.
Administrative and operational status objects for this table control packet transmission. If administrative
and operational status objects are down, the LSR does not forward packets. If these status objects are up,
the LSR forwards packets.
Supports:
A unique index identifier
The incoming label
The number of labels to pop from the incoming segment
An address family number from the Internet Assigned Number Authority (IANA)
A segment cross-connect entry association
The segment owner
The storage type
The administrative status
The operational status
Note The administrative status and operational status are always up for inSegments in the Cisco
implementation. Otherwise, these entries do not appear in the table.
4
Does not support:

A pointer to a traffic parameter table entry (set to the default 0.0)
MPLS in-segment performance table (mplsInSegmentPerfTable)

Augments the MPLS in-segment table, providing performance information and counters for incoming
segments on an LSR.
Supports:
The number of 32-bit octets received
The number of 64-bit octets received
The time of the last system failure that corresponded to one or more incoming segment
discontinuities
Note The lastFailure parameter is set to zero because it has no meaning in the Cisco implementation.
Does not support:

The total number of packets received
The number of packets with errors
The number of labeled packets discarded with no errors
MPLS out-segment table (mplsOutSegmentTable)

Contains a description of outgoing segments from an LSR and their associated parameters.
Administrative and operational status objects for this table control packet transmission. If administrative
and operational status objects are down, the LSR does not forward packets. If these values are up, the
LSR forwards packets.
Supports:
A unique index identifier
An interface index of the outgoing interface
An indication of whether or not a top label is pushed onto the outgoing packets label stack
The label to push onto the outgoing packets label stack (if the previous value is true)
The next hop address type
The IPv4 address of the next hop
The segment cross-connect entry association
The segment owner
The storage type
The administrative status
The operational status
Note The administrative and operational status entries are always up in the Cisco implementation. Otherwise,
the administrative and operational status entries do not appear in the table.
Does not support:
5
An IPv6 address of the next hop

A pointer to a traffic parameter table entry (set to the default 0.0)
MPLS out-segment performance table (mplsOutSegmentPerfTable)

Augments the MPLS out-segment table, providing performance information and counters for outgoing
segments on an LSR.
Supports:
The number of 32-bit octets sent
The number of 64-bit octets sent
The time of the last system failure that corresponded to one or more outgoing segment
discontinuities
Does not support:
The number of packets sent
The number of packets that could not be sent because of errors
The number of packets discarded with no errors
MPLS cross-connect table (mplsXCTable)

Associates inSegments (labels) with outSegments (labels) to show the manager how the LSR is currently
swapping these labels.
A row in this table consists of one cross-connect entry that is indexed by the cross-connect index, the
interface index of the incoming segment, the incoming label, and the out-segment index.
The administrative and operational objects for this table control packet forwarding to and from a
cross-connect entry (XCEntry). The administrative status and operational status are always up in the
Cisco implementation. Otherwise, the LSR would not forward packets.
Supports:
A unique index identifier for a group of cross-connect segments
A label switched path (LSP) to which the cross-connect entry belongs
An index to the MPLS label stack table that identifies the stack of labels to be pushed under the top
label
An indication whether or not to restore the cross-connect entry after a failure (the default value is
false)
The cross-connect owner
The storage type
The administrative status (if up)
The operational status (if up)
Note The administrative status and operational status are always up in the Cisco implementation. Otherwise,
these status entries do not appear in the table.
Does not support:

Tunnel IDs as label switched path (LSP) ID objects
6
Information from Scalar Objects

The MPLS-LSR-MIB supports several scalar objects. In the Cisco implementation of the MIB, the
following scalar objects are hard-coded to the value indicated and are read-only objects:
mplsOutSegmentIndexNext (0)The value for the out-segment index when an LSR creates a new
entry in the MPLS out-segment table. The 0 indicates that this is not implemented because
modifications to this table are not allowed.
mplsXCTIndexNext (0)The value for the cross-connect index when an LSR creates an entry in the
MPLS cross-connect table. The 0 indicates that no unassigned values are available.
mplsMaxLabelDepth(2)The value for the maximum stack depth.
mplsLabelStackIndexNext (0)The value for the label stack index when an LSR creates entries in
the MPLS label stack table. The 0 indicates that no unassigned values are available.
mplsTrafficParamIndexNext (0)The value for the traffic parameter index when an LSR creates
entries in the MPLS traffic parameter table. The 0 indicates that no unassigned values are available.
The following scalar objects do not contain information for the MPLS-LSR-MIB and are coded as false:
mplsInSegmentTrapEnable (false)In-segment traps are not sent when this value is false.
mplsOutSegmentTrapEnable (false)Out-segment traps are not sent when this value is false.
mplsXCTrapEnable (false)Cross-connect traps are not sent when this value is false.
No trap information exists to support the MIB. Therefore, the following traps are not supported:
mplsInSegmentUp
mplsInSegmentDown
mplsOutSegmentUp
mplsOutSegmentDown
mplsXCUp
mplsXCDown
Linking Table Elements

In the cross-connect table, cross-connect entries associate incoming segments and interfaces with
outgoing segments and interfaces. The following objects index the cross-connect entry:
Cross-connect indexA unique identifier for a group of cross-connect entries in the cross-connect
table. In the Cisco implementation, this value is always the same as that for the outSegmentIndex,
unless there is no label or if the label has been popped.
Interface index of the in-segmentA unique index for an entry in the in-segment table that
represents an incoming MPLS interface. The value 0 means platform wide, for any entries that apply
to all interfaces.
Incoming labelAn entry in the in-segment table that represents the label on the incoming packet.
Out-segment indexA unique identifier for an entry in the out-segment table that contains a top
label for the outgoing packets label stack and an interface index of the outgoing interface.
Figure 2 shows the links between the in-segment and the out-segment in the cross-connect table.
7
Figure 2 Cross-Connect Table Links
In-segment Cross-connect table Out-segment

XCIndex Inif inL OutIndex
Inif, inL OutIndex
51276
Table 1 shows the cross-connect table links you might see in the output from SNMP get operations on
the MPLS-LSR-MIB objects that index a cross-connect entry. These objects include
In-Segment ValuesmplsInSegmentIfIndex and mplsInSegmentLabel
Cross-Connect EntrymplsXCIndex
Out-Segment ValuesmplsOutSegmentIndex
.
Table 1 MPLS LSR Output Showing Cross-Connect Table Links
In-Segment Values Cross-Connect Entry Out-Segment Values

01, 1000 5002, 0, 1000, 02
501, 0, 1000, 501 501 = Pop (topLabel), Eth 1/5
502, 0, 1000, 502 502 = Pop (topLabel), Eth, 1/1)
1. All MPLS-enabled interfaces can receive incoming labels.
2. For this implementation of the MPLS-LSR-MIB, the cross-connect index and the out-segment index are the same. If
there is no outsegment, the value will be zero.
Note The OutSegmentIndex object is not the label. The label can be retrieved from the
mplsOutSegmentTopLabel object.
Interface Configuration Table and Interface MIB Links

The MPLS interface configuration table lists interfaces that support MPLS technology. An LSR creates
an entry dynamically in this table for each MPLS-capable interface. An interface becomes
MPLS-capable when MPLS is enabled on that interface. A non-zero index for an entry in this table points
to the ifIndex for the corresponding interface entry in the MPLS-layer in the ifTable of the Interfaces
Group MIB.
The ifTable contains information on each interface in the network. Its definition of an interface includes
any sublayers of the internetwork layer of the interface. MPLS interfaces fit into this definition of an
interface. Therefore, each MPLS-enabled interface is represented by an entry in the ifTable.
The interrelation of entries in the ifTable is defined by the interfaces stack group of the Interfaces Group
MIB. Figure 3 shows how the stack table might appear for MPLS interfaces. The underlying layer refers
to any interface that is defined for MPLS internetworking, for example, ATM, Frame Relay, or Ethernet.
8
Figure 3 Interface Group MIB Stack Table for MPLS Interfaces
MPLS-interface ifType = mpls(166)
51273
Underlying Layer . . .
Note Tunnel interfaces are included in the MPLS list for the current implementation.
The incoming and outgoing packets include a reference to the interface index for the ifTable of the
Interfaces Group MIB. Figure 4 shows the links between MPLS-LSR-MIB objects and the Interfaces
Group MIB.
Figure 4 MPLS-LSR-MIB and Interfaces Group MIB Links
IF MIB
ifTable
ifIndex
x
In-segment Cross-connect table Out-segment
Inif inL XCIndex Inif inL OutIndex OutL Outif
OutIndex
51277
For the Interfaces Group MIB (IF MIB):

ifTable represents the MPLS interface table.
ifIndex represents the index to an entry in the MPLS interface table.
For the In-segment:
Inif represents the interface on the incoming segment (references an index entry in the ifTable).
inL represents the label on the incoming segment.
For the Out-segment:
OutL represents the label on the outgoing segment.
Outif represents the interface on the outgoing segment (references an index entry in the ifTable).
For the Cross-connect table:
XCIndex represents the index to an entry in the MPLS cross-connect table.
9
Inif represents the interface on the incoming segment.

inL represents the MPLS label on the incoming segment.
OutIndex represents an index to an entry in the MPLS out-segment table.
Using the MPLS-LSR-MIB

The MPLS-LSR-MIB enables you to display the contents of the MPLS Label Forwarding Information
Base (LFIB). It gives you the same information that you can obtain using the CLI command show mpls
forwarding-table.
However, the MPLS-LSR-MIB approach offers these advantages over the CLI command approach:
A more efficient use of network bandwidth
Greater interoperability among vendors
Greater security (SMNP Version 3)
The following paragraphs describe the MPLS-LSR-MIB structure and show, through the use of an
example, how the two approaches to the information display compare.
MPLS-LSR-MIB Structure
MIB structure is represented by a tree hierarchy. Branches along the tree have short text strings and
integers to identify them. Text strings describe object names, and integers allow computer software to
encode compact representations of the names.
The MPLS-LSR-MIB falls on the experimental branch of the Internet MIB hierarchy. The experimental
branch of the Internet MIB hierarchy is represented by the object identifier 1.3.6.1.3. This branch can
also be represented by its object name iso.org.dod.internet.experimental. The MPLS-LSR-MIB is
identified by the object name mplsLsrMIB, which is denoted by the number 96. Therefore, objects in the
MPLS-LSR-MIB can be identified in either of the following ways:
The object identifier1.3.6.1.3.96.[MIB-variable]
The object nameiso.org.dod.internet.experimental.mplsLsrMIB.[MIB-variable]
To display a MIB-variable, you enter an SNMP get command with an object identifier. Object identifiers
are defined by the MPLS-LSR-MIB.
10
Figure 5 shows the position of the MPLS-LSR-MIB in the Internet MIB hierarchy.
Figure 5 MPLS-LSR-MIB in the Internet MIB Hierarchy
Label from the root to

this point is 1.3.6.1.3.
MPLS-LSR-MIB
96
notification LsrObjects conformance

2 1 3
MPLS interface configuration table (1)
MPLS interface performance table (2)
MPLS in-segment table (3)
MPLS in-segment performance table (4)
MPLS out-segment index table (5)
MPLS out-segment table (6)
MPLS out-segment performance table (7)
MPLS cross-connect index next (8)
MPLS cross-connect table (9)
MPLS maximum label stack depth (10)
MPLS label stack index next (11)
MPLS label stack table (12)
MPLS traffic parameter index next (13)
MPLS traffic parameter table (14)

51272
MPLS cross-connect trap enable (15)
11
CLI Commands and the MPLS-LSR-MIB

The MPLS LFIB is the component of the Cisco MPLS subsystem that contains management information
for LSRs. You can access this management information by means of either of the following:
Using the show mpls forwarding-table CLI command
Entering SNMP get commands on a network manager
The following examples show how you can gather LSR management information using both methods.
CLI Command Output
A show mpls forwarding-table CLI command allows you to look at label forwarding information for a
packet on a specific MPLS LSR.
Local Outgoing Prefix Bytes Tag Outgoing Next Hop

Tag Tag or VC or Tunnel Id Switched interface
19 Pop Tag 10.3.4.0/24 0 Et1/4 10.22.23.23
22 23 14.14.14.14/32 0 AT2/0.1 point2point
1/36 14.14.14.14/32 0 AT2/0.2 point2point
MPLS-LSR-MIB Output
SNMP commands on MIB objects also allow you to look at the label forwarding information for a
specific MPLS LSR.
You can do a walk-through of the MIB by running a command such as getmany -v2c public
mplsLsrMIB on a network manager where getmany does repeated SNMP getnext operations to retrieve
the contents of the MPLS-LSR-MIB.
mplsXCOperStatus.9729.0.19.9729 = up(1)
You can continue to scan the output of the getmany command for the following (from the MPLS
out-segment table):
Out-segments top label objects (mplsOutSegmentTopLabel)
mplsOutSegmentTopLabel.9729 = 3
Note 65572 is 1/36 in label form (1 is the high-order 16 bits. 36 is the low-order 16 bits.)
Out-segments interface index (mplsOutSegmentIfIndex)

mplsOutSegmentIfIndex.9729 = 7
12
How to Configure the MPLS LSR MIB
Benefits
The benefits described in the following paragraphs are available to you with the MPLS-LSR-MIB.
Troubleshooting LSR Problems

By monitoring the cross-connect entries and the associated incoming and outgoing segments, you can
see which labels are installed and how they are being swapped. Use the MPLS-LSR-MIB in place of the
show mpls forwarding CLI command.
Monitoring of LSR Traffic Loads

By monitoring interface and packet operations on an MPLS LSR, you can identify high- and low-traffic
patterns, as well as traffic distributions.
Improvement of Network Performance

By identifying potentially high-traffic areas, you can set up load sharing to improve network
performance.
Verification of LSR Configuration

By comparing results from SNMP get commands and the show mpls forwarding CLI command, you
can verify your LSR configuration.
Displaying of Active Label Switched Paths

By monitoring the cross-connect entries and the associated incoming segments and outgoing segments,
you can determine the active LSPs.

See the following sections for configuration tasks for the MPLS-LSR-MIB feature. Each task in the list
is identified as either optional or required.
Enabling the SNMP Agent (required)
Verifying That the SNMP Agent Has Been Enabled (optional)
Prerequisites
The MPLS-LSR-MIB requires the following:
SNMP installed and enabled on the LSR
MPLS enabled on the LSR
60K of memory
Note Additional capacity is not required for runtime dynamic random-access memory (DRAM).
13

The SNMP agent for the MPLS-LSR-MIB is disabled by default. To enable the SNMP agent, perform
the following steps:
SUMMARY STEPS
1. enable
5. end
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 the information or change it as desired.
Example:
Step 4 snmp-server community string [view view-name] [ro] Configures read-only (ro) SNMP community strings.
[number]
This command enables the SNMP agent and permits
any SNMP manager to access all objects with
Example: read-only permission using the community string
Router(config)# snmp-server community public ro public.
14
Configuration Examples for the MPLS LSR MIB

Example:
Router(config)# end
Step 6 copy running-config startup-config Copies the modified SNMP configuration into router
NVRAM, permanently saving the SNMP settings.
Example: When you are working with Cisco IOS Release 10.3
Router# copy running-config startup-config or earlier, use the write memory command.
Verifying That the SNMP Agent Has Been Enabled

To verify that the SNMP agent has been enabled, perform the following steps:
Step 1 Access the router through a Telnet session:

Prompt# telnet xxx.xxx.xxx.xxx
where xxx.xxx.xxx.xxx represents the IP address of the target device.

Step 2 Enter privileged mode:
Router# enable
Step 3 Display the running configuration and look for SNMP information:
Router# show running-configuration
...
...
If you see any snmp-server statements, SNMP has been enabled on the router.
Configuration Examples for the MPLS LSR MIB

The following example shows how to enable an SNMP agent.
configure terminal
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.
configure terminal
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.
configure terminal
nmp-server community comaccess ro 4
15
The following sections provide references related to the MPLS LSR MIB.
Related Documents
Configuring SNMP using Cisco IOS software Cisco IOS Network Management Configuration Guide,
Release 12.4, Configuring SNMP Support
Release 12.4, SNMP Commands
Standards
Standard Title
draft-ietf-mpls-lsr-mib-05.txt MPLS Label Switch Router Management Information Base Using
SMIv2
draft-ietf-mpls-arch-07.txt Multiprocol Label Switching Architecture
MIBs
MIBs MIBs Link
MPLS Label Switching Router MIB To locate and download MIBs for selected platforms, Cisco IOS
(MPLS-LSR-MIB) releases, and feature sets, use Cisco MIB Locator found at the
following URL:
RFCs
RFCs Title
The LSR implementation supporting the The Internet Standards Process
MPLS-LSR-MIB is in full compliance with all
provisions of Section 10 of RFC 2026.
16
Command Reference
Description Link
Command Reference
Glossary
cross-connect (XC)An association of in-segments and incoming Multiprotocol Label Switching
(MPLS) interfaces to out-segments and outgoing MPLS interfaces.
IETFInternet Engineering Task Force. A task force (consisting of more that 80 working groups) that
is developing standards for the Internet and the IP suite of protocols.
inSegmentA label on an incoming packet that is used to determine the forwarding of the packet.
Internet Engineering Task ForceSee IETF.
labelA short, fixed length identifier that is used to determine the forwarding of a packet.
Label Distribution ProtocolSee LDP.
label switched pathSee LSP.
label switchingDescribes the forwarding of IP (or other network layer) packets by a label swapping
algorithm based on network layer routing algorithms. The forwarding of these packets uses the exact
match algorithm and rewrites the label.
label switch routerSee LSR.
LDPLabel Distribution Protocol. A standard protocol that operates between Multiprotocol Label
Switching (MPLS)-enabled routers to negotiate the labels (addresses) used to forward packets. The
Cisco proprietary version of this protocol is the Tag Distribution Protocol (TDP).
LSPlabel 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.
LSRlabel switch router. A device that forwards Multiprotocol Label Switching (MPLS) packets based
on the value of a fixed-length label encapsulated in each packet.
Management Information BaseSee MIB.
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.
17
Glossary
MPLSMultiprotocol Label Switching. A switching method that forwards IP traffic through use of 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.
MPLS interfaceAn interface on which Multiprotocol Label Switching (MPLS) traffic is enabled.
Multiprotocol Label SwitchingSee MPLS.
notification requestA message sent by a Simple Network Management Protocol (SNMP) agent to a
network management station, console, or terminal, indicating that a significant event occurred. SNMP
notification requests are more reliable than traps, because a notification request from an SNMP agent
requires that the SNMP manager acknowledge receipt of the notification request. The manager replies
with an SNMP response protocol data unit (PDU). If the manager does not receive a notification message
from an SNMP agent, it does not send a response. If the sender (SNMP agent) never receives a response,
the notification request can be sent again.
outSegmentA label on an outgoing packet.
Simple Network Management ProtocolSee SNMP.
SNMPSimple 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.
trapA 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.
Note Refer to the Cisco Dictionary of Internetworking Terms and Acronyms for terms not included in this
glossary.
coincidental.
18
MPLS Label Distribution Protocol MIB Version 8
Upgrade

Last Updated: March 06, 2009
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.
Note In Cisco IOS Release 12.2(33)SRB and Cisco IOS Release 12.2(33)SB, this MIB has been
deprecated and replaced by MPLS-LDP-STD-MIB (RFC 3815). In those two releases and in
later images, the entire MIB can be referenced by the name mplsLdpMIB for purposes of the
SNMP server excluded/included command. If other MIB object names need to be referenced on
the router, they must be referenced by MPLS-LDP-MIB::<table_entry_name>.
History for MLPS Label Distribution Protocol MIB Version 8 Update Feature
12.0(11)ST This feature was introduced to provide SNMP agent support for the MPLS
LDP MIB on Cisco 7200, Cisco 7500, and Cisco 12000 series routers.
12.2(2)T This feature was added to this release to provide SNMP agent support for
the MPLS LDP MIB on Cisco 7200 and Cisco 7500 series routers.
12.0(21)ST This feature was added to this release to provide SNMP agent and LDP
notification support for the MPLS LDP MIB on Cisco 7200, Cisco 7500,
and Cisco 12000 series Internet routers.
12.0(22)S This feature (Version 1) was integrated into Cisco IOS Release 12.0(22)S.
12.0(24)S This feature was upgraded to Version 8 in Cisco IOS Release 12.0(24)S.
12.0(27)S Support for the MPLS VPNVPN Aware LDP MIB feature was added.
12.2(18)S This feature was integrated into Cisco IOS Release 12.2(18)S.

MPLS Label Distribution Protocol MIB Version 8 Upgrade
Contents
12.2(33)SRB This MIB has been deprecated and replaced by MPLS-LDP-STD-MIB

(RVC 3815).
12.2(33)SB This MIB has been deprecated and replaced by MPLS-LDP-STD-MIB
(RVC 3815).
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 3
Description of MPLS LDP MIB Elements for MPLS LDP MIB Version 8 Upgrade, page 6
Events Generating MPLS LDP MIB Notifications in MPLS LDP MIB Version 8 Upgrade, page 9
MIB Tables in MPLS LDP MIB Version 8 Upgrade, page 11
VPN Contexts in MPLS LDP MIB Version 8 Upgrade, page 20
How to Configure MPLS LDP MIB Version 8 Upgrade, page 25
Configuration Examples for MPLS LDP MIB Version 8 Upgrade, page 37
Glossary, page 42
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.
2
Information About MPLS LDP MIB Version 8 Upgrade
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

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 3
Enhancements in Version 8 of the MPLS LDP MIB, page 5
Benefits of MPLS LDP MIB Version 8 Upgrade, page 5
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).
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 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.
3
The SNMP agent code has a layered structure that is compatible with Cisco IOS 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 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 functions. As a result, some minor translations between the MPLS LDP MIB objects and the
internal Cisco IOS 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 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.
Cisco IOS Release 12.0(11)ST and later releases support the following MPLS LDP MIB-related
functions:
Tag Distribution Protocol (TDP)
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 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.
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.
4
Enhancements in Version 8 of the MPLS LDP MIB

Version 8 of the MPLS LDP MIB contains the following enhancements:
TDP support
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

Supports TDP and LDP
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:
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)
5
Description of MPLS LDP MIB Elements for MPLS LDP MIB Version 8 Upgrade
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 entityRelates to an instance of LDP for purposes of exchanging label spaces; describes a
potential session.
LDP peerRefers to a remote LDP entity (that is, a nonlocal LSR).
LDP sessionRefers to an active LDP process between a local LSR and a remote LDP peer.
Hello adjacencyRefers 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.
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 peers active hello adjacency.
6
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:
Interface-specificAn 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-wideAn 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.
7
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.
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.
8
Events Generating MPLS LDP MIB Notifications in MPLS LDP MIB Version 8 Upgrade
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.
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.
9
Events Generating MPLS LDP MIB Notifications in MPLS LDP MIB Version 8 Upgrade
The MPLS LDP MIB objects involved in LDP status transitions and event notifications include the
following:
mplsLdpSessionUpThis 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).
mplsLdpSessionDownThis message is generated when an LDP session between a local LSR and
its adjacent LDP peer is terminated.
mplsLdpPathVectorLimitMismatchThis 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.
mplsLdpFailedInitSessionThresholdExceededThis 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.
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
10
MIB Tables in MPLS LDP MIB Version 8 Upgrade

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 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.
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
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 peers
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.
11
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
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.
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.
12
Table 1 mplsLdpEntityTable Objects and Descriptions (continued)
Object Description
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
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.
13
Table 1 mplsLdpEntityTable Objects and Descriptions (continued)
Object Description
mplsLdpEntityDiscontinuityTime The value of sysUpTime on the most recent occasion when one
or more of this entitys 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).
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.
14
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.
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.
15
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.
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.
16
Table 5 mplsLdpEntityStatsTable Objects and Descriptions (continued)
Object Description
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).
17
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.
18
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 sessions 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).
19
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.
Cisco IOS Release 12.0(11)ST and later releases include the VPN Aware LDP MIB feature that allows
the LDP MIB to get VPN context information. The 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 21
VPN Aware LDP MIB Sessions, page 21
VPN Aware LDP MIB Notifications, page 23
20
SNMP Contexts
SNMP contexts provide VPN users with a secure way of accessing MIB data. When a VPN is associated
with a context, that VPNs 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.
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

Prior to Cisco IOS Release 12.0(11)ST, 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.
21
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 release displayed only global session information.
With the VPN Aware LDP MIB enhancement in this Cisco IOS release, 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.
22
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

Prior to Cisco IOS Release 12.0(11)ST, 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.
23
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:
PE-Router(config)# snmp-server host host-address traps community mpls-ldp
PE-Router(config)# snmp-server enable traps mpls ldp
To enable LDP notifications for a VPN context, use the following commands:
PE-Router(config)# snmp-server host host-address vrf vrf-name version {v1|v2c|v3}
community community-string udp-port upd-port mpls-ldp
PE-Router(config)# snmp-server enable traps mpls ldp
Figure 10 shows LDP notifications with the VPN Aware LDP MIB feature.
24
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 the SNMP Agent, page 25 (required)
Enabling Cisco Express Forwarding, page 26 (required)
Enabling MPLS Globally, page 27 (required)
Enabling LDP Globally, page 28 (required)
Enabling MPLS on an Interface, page 29 (required)
Enabling LDP on an Interface, page 30 (required)
Configuring a VPN Aware LDP MIB, page 31 (required)
Verifying MPLS LDP MIB Version 8 Upgrade, page 37 (optional)

Perform this task to enable the SNMP agent.
SUMMARY STEPS
1. enable
25
5. end
6. write memory
DETAILED STEPS

Example:
Router> enable
Step 2 show running-config Displays the running configuration of the router so that you
device.
Example:
Router# show running-config If no SNMP information is displayed, continue with the
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.
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:
Enabling Cisco Express Forwarding

Perform this task to enable Cisco Express Forwarding or distributed Cisco Express Forwarding.
SUMMARY STEPS
1. enable
26
4. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 ip cef distributed Enables distributed Cisco Express Forwarding.
Example:
Example:
Router(config)# end
Enabling MPLS Globally

Perform this task to enable MPLS globally.
SUMMARY STEPS
1. enable
3. mpls ip
4. end
27
DETAILED STEPS

Example:
Router> enable
Example:
routed paths for the platform.
Example:
Example:
Router(config)# end
Enabling LDP Globally

Perform this task to enable LDP globally.
SUMMARY STEPS
1. enable
3. mpls label protocol {ldp | tdp}
4. end
28
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 mpls label protocol {ldp | tdp} 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.
SUMMARY STEPS
1. enable
3. interface [type number]
4. mpls ip
5. end
29
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface [type number] Enters interface configuration mode.
Router(config)# interface Ethernet 1
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 number]
5. end
30
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface [type number] Enters interface configuration mode.
Router(config)# interface Ethernet 1
Step 4 mpls label protocol {ldp | tdp | both} Specifies the label distribution protocol to be used on a
given interface.
Example:
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 31
Configuring an SNMP Context for a VPN, page 32
Associating an SNMP VPN Context with SNMPv1 or SNMPv2, page 34
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]}]
community-string [udp-port port] [notification-type] [vrf vrf-name]
4. snmp-server engineID remote ip-address [udp-port udp-port-number] [vrf vrf-name]
engineid-string
5. end
31
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 32.
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 VPNs 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 VPNs 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.
32
VPN Route Distinguishers
A route distinguisher (RD) creates routing and forwarding tables for a VPN. Cisco IOS adds the RD to
the beginning of the customers 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
33
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:
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 34.
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.
34
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]
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
35
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
Step 7 snmp-server host host-address [traps | informs] Specifies the recipient of an SNMP notification operation.
[version {1 | 2c | 3 [auth | noauth | priv]}]
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
36
Configuration Examples for MPLS LDP MIB Version 8 Upgrade

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 37
Configuring a VPN Aware SNMP Context for SNMPv1 or SNMPv2: Example, page 38
MPLS LDP MIB Version 8 Upgrade Examples

The following example shows how to enable an SNMP agent on the host NMS:
Router(config)# snmp-server community
37
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
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 LDP globally and then on an interface:
Router(config)# interface Ethernet1
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
description Belongs to VPN B
ip vrf forwarding CustomerB
ip address 10.0.0.1 255.255.0.0
38
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.
39
Related Documents
MPLS LDP configuration tasks MPLS Label Distribution Protocol (LDP)
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 releases, and feature sets, use Cisco MIB
SNMP-VACM-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
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.
40
Command Reference
Description Link
Command Reference
context
snmp mib community-map
snmp mib target list
snmp-server context
snmp-server enable traps (MPLS)
snmp-server group
snmp-server host
snmp-server trap authentication vrf
41
Glossary
Glossary
ATMAsynchronous 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.
downstream-on-demand distributionA label distribution method in which a downstream label
switch router (LSR) sends a binding upstream only if the upstream LSR requests it.
downstream unsolicited distributionA 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.
informsA 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.
labelA short, fixed-length data identifier that tells switching nodes how to forward data (packets or
cells).
label distributionThe 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.
LDPLabel 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).
LSPlabel-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.
LSRlabel 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
MPLSMultiprotocol 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 distributionA constraint-based routing algorithm for routing label-switched path (LSP)
tunnels.
NMSnetwork 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 SNMP, an NMS is a device that
performs SNMP queries to the SNMP agent of a managed device to retrieve or modify information.
notificationA 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.
RSVPResource 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.
42
Glossary
RTRResponse Time Reporter. A tool that allows you to monitor network performance, network
resources, and applications by measuring response times and availability.
SNMPSimple 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 communitiesAuthentication scheme that enables an intelligent network device to validate
SNMP requests.
SNMPv2cVersion 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.
SNMPv3Version 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.
TDPTag Distribution Protocol. A standard protocol used by MPLS-enabled routers to negotiate the
tags (addresses) used for forwarding packets. See also LDP.
TLVType-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.
trapA message sent by an SNMP agent to a network 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.
VCCvirtual 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.
VCIvirtual 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.
VCLvirtual channel link. The logical connection that exists between two adjacent switches in an ATM
network.
VPIvirtual 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.
43
Glossary
coincidental.
44
MPLS Traffic Engineering MIB

The MPLS Traffic Engineering MIB enables Simple Network Management Protocol (SNMP) agent
support in Cisco IOS 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 software.

supported, see the Feature Information for the MPLS Traffic Engineering MIB section on page 16.
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 10
Configuration Examples for the MPLS Traffic Engineering MIB, page 13
Feature Information for the MPLS Traffic Engineering MIB, page 16
Glossary, page 17

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 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 Generation Events, page 3
Notification Implementation, page 4
Benefits of MPLS Traffic Engineering MIB, page 4
MPLS Traffic Engineering MIB Layer Structure, page 4
Features and Technologies Related to 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 software require some minor translations between the MPLS TE MIB and the internal data
structures of Cisco IOS 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 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 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 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 traffic-eng
command), notification messages relating to specific events within Cisco IOS 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 Ethernet 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 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 software and is, in part, generated by the Cisco IOS 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 software, consists of four layers:
4
Platform independent layerThis layer is generated primarily by the Cisco IOS MIB development
tool set and incorporates platform and implementation independent functions. The Cisco IOS MIB
development tool set creates a standard set of files associated with a MIB.
Application interface layerThe functions, names, and template code for MIB objects in this layer
are also generated by the Cisco IOS MIB development tool set.
Application specific layerThis 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 software, such as searching through data structures.
API and data structures layerThis layer contains the data structures or APIs within Cisco IOS
software that are retrieved or called in order to set or retrieve SNMP management information.
Features and Technologies Related to 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
MPLS label switching router MIB (MPLS-LSR-MIB)
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 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 releases follow. Important MIB tables
(those highlighted in bold type) are described briefly in accompanying text.
mplsTunnelConfiguredTotal number of tunnel configurations that are defined on this node.
mplsTunnelActiveTotal number of label switched paths (LSPs) that are defined on this node.
mplsTunnelTEDistProtoThe IGP distribution protocol in use.
mplsTunnelMaxHopsThe maximum number of hops any given tunnel can utilize.
mplsTunnelIndexNextUnsupported; set to 0.
mplsTunnelTableEntries 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.
5
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.
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.
mplsTunnelIndexSame as tunnel ID (c).
mplsTunnelInstanceTunnel instance of the LSP; 0 for head configurations (b).
mplsTunnelIngressLSRIdSource IP address of the LSP; 0 for head configurations (b).
mplsTunnelEgressLSRIdDestination IP address of the tunnel (c).
mplsTunnelNameCommand name for the tunnel interfaces (a).
mplsTunnelDescrDescriptive name for tunnel configurations and LSPs (c).
mplsTunnelIsIfIndicator of whether the entry represents an interface (c).
mplsTunnelIfIndexIndex 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).
mplsTunnelSignallingProtoSignaling protocol used by tunnels (c).
mplsTunnelSetupPrioSetup priority of the tunnel (c).
mplsTunnelHoldingPrioHolding priority of the tunnel (c).
mplsTunnelSessionAttributesSession attributes (c).
mplsTunnelOwnerTunnel owner (c).
mplsTunnelLocalProtectInUseNot implemented (c).
mplsTunnelResourcePointerPointer into the Resource Table (b).
mplsTunnelInstancePriorityNot implemented (b).
mplsTunnelHopTableIndexIndex into the Hop Table (a).
mplsTunnelARHopTableIndexIndex into the AR Hop Table (b).
mplsTunnelCHopTableIndexIndex into the C Hop Table (b).
mplsTunnelPrimaryTimeUpAmount of time, in seconds, that the current path has been up (a).
mplsTunnelPathChangesNumber of times a tunnel has been resignalled (a).
mplsTunnelLastPathChangeAmount of time, in seconds, since the last path resignaling
occurred (a).
mplsTunnelCreationTimeTime stamp when the tunnel was created (a).
mplsTunnelStateTransitionsNumber of times the tunnel has changed state (a).
mplsTunnelIncludeAnyAffinityNot implemented (a).
6
mplsTunnelIncludeAllAffinityAttribute bits that must be set for the tunnel to traverse a

link (a).
mplsTunnelExcludeAllAffinityAttribute bits that must not be set for the tunnel to traverse a
link (a).
mplsTunnelPathInUsePath option number being used for the tunnels path. If no path option
is active, this object will be 0 (a).
mplsTunnelRoleRole of the tunnel on the router; that is, head, midpoint, or tail (c).
mplsTunneltotalUptimeAmount of time, in seconds, that the tunnel has been operationally up
(a).
mplsTunnelInstanceUptimeNot implemented (b).
mplsTunnelAdminStatusAdministrative status of a tunnel (c).
mplsTunnelOperStatusActual operating status of a tunnel (c).
mplsTunnelRowStatusThis object is used in conjunction with configuring a new tunnel. This
object will always be seen as active (a).
mplsTunnelStorageTypeStorage type of a tunnel entry (c).
mplsTunnelHopListIndexNextNext valid index to use as an index in the mplsTunnelHopTable.
mplsTunnelHopTableEntries 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.
mplsTunnelHopListIndexPrimary index into the table.
mplsTunnelHopIndexSecondary index into the table.
mplsTunnelHopAddrTypeIndicates if the address of this hop is the type IPv4 or IPv6.
mplsTunnelHopIpv4AddrThe IPv4 address of this hop.
mplsTunnelHopIpv4PrefixLenThe prefix length of the IPv4 address.
mplsTunnelHopIpv6AddrThe IPv6 address of this hop.
mplsTunnelHopIpv6PrefixLenThe prefix length of the IPv6 address.
mplsTunnelHopAsNumberThis object will contain 0 or the autonomous system number of
the hop, depending on the value of mplsTunnelHopAddrType.
mplsTunnelHopLspIdThis object will contain 0 or the LSPID of the tunnel, depending on the
value of mplsTunnelHopAddrType.
mplsTunnelHopTypeDenotes whether this tunnel hop is routed in a strict or loose fashion.
mplsTunnelHopRowStatusThis object is used in conjunction with the configuring of a new
row in the table.
mplsTunnelHopStorageTypeThe storage type of this MIB object.
mplsTunnelResourceIndexNextThis object contains the next appropriate value to be used for
mplsTunnelResourceIndex when creating entries in the mplsTunnelResourceTable
mplsTunnelResourceTableEntries 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.
7
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.
mplsTunnelResourceIndexThe primary index into this table.
mplsTunnelResourceMaxRateThe maximum rate, in bits per second, supported by this
tunnel.
mplsTunnelResourceMeanRateThe mean rate, in bits per second, supported by this tunnel.
mplsTunnelResourceMaxBurstSizeThe maximum burst size, in bytes, allowed by this tunnel.
mplsTunnelResourceRowStatusThis object is used in conjunction with the configuration of a
new row in the table.
mplsTunnelResourceStorageTypeThe storage type of this MIB object.
mplsTunnelARHopTableEntries 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:
mplsTunnelARHopListIndexThe primary index into this table.
mplsTunnelARHopIndexThe secondary index into this table.
mplsTunnelARHopIpv4AddrThe IPv4 address of this hop.
mplsTunnelARHopIpv4PrefixLenThe prefix length of the IPv4 address.
mplsTunnelARHopIpv6AddrThe IPv6 address of this hop.
mplsTunnelARHopIpv6PrefixLenThe prefix length of the IPv6 address.
mplsTunnelARHopAsNumberThis object will contain 0 or the AS number of the hop,
depending on the value of mplsTunnelARHopAddrType.
mplsTunnelARHopAddrTypeThe type of address for this MIB entry, either IPv4 or IPv6.
mplsTunnelARHopTypeDenotes whether this tunnel hop is routed in a strict or loose manner.
mplsTunnelCHopTableEntries 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:
mplsTunnelCHopListIndexThe primary index into this table.
mplsTunnelCHopIndexThe secondary index into this table.
mplsTunnelCHopAddrTypeIndicates if the address of this hop is the type IPv4 or IPv6.
8
mplsTunnelCHopIpv4AddrThe IPv4 address of this hop.

mplsTunnelCHopIpv4PrefixLenThe prefix length of the IPv4 address.
mplsTunnelCHopIpv6AddrThe IPv6 address of this hop.
mplsTunnelCHopIpv6PrefixLenThe prefix length of the IPv6 address.
mplsTunnelCHopAsNumberThis object will contain 0 or the autonomous system number of
the hop, depending on the value of mplsTunnelHopAddrType.
mplsTunnelCHopTypeDenotes whether this tunnel hop is routed in a strict or loose way.
mplsTunnelPerfTableThe tunnel performance table, which augments the mplsTunnelTable,
provides packet and byte counters for each tunnel. This table contains the following packet and byte
counters:
mplsTunnelPerfPacketsThis packet counter works only for tunnel heads.
mplsTunnelPerfHCPacketsThis packet counter works only for tunnel heads.
mplsTunnelPerfErrorsThis packet counter works only for tunnel heads.
mplsTunnelPerfBytesThis byte counter works for tunnel heads and tunnel midpoints, but not
for tunnel tails.
mplsTunnelPerfHCBytesThis byte counter works for tunnel heads and tunnel midpoints, but
not for tunnel tails.
mplsTunnelTrapEnableThe 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
How to Configure the MPLS Traffic Engineering MIB
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.

Enabling the SNMP Agent to Help Manage Various MPLS TE Tunnel Characteristics of Tunnels on
the Local Router, page 11 (required)
10
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 steps.
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
SNMP agent is already running.
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.
Example:
11

Step 5 snmp-server community string [view view-name] Enables the read-only (RO) community string.
[ro | rw] [ipv6 nacl] [access-list-number]
Example:
Router(config)# snmp-server community comaccess
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.
Step 7 exit Exits global configuration mode and returns to privileged
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:
Router# telnet 192.172.172.172
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
members of access list 4 that specify the comaccess community string. No other SNMP agents will have
access to any MPLS TE MIB objects.
The following sections provide references related to the MPLS Traffic Engineering MIB.
Related Documents
MPLS-based functionalities MPLS Label Distribution Protocol (LDP)
MPLS Scalability Enhancements for the LSC LSR
MPLS Scalability Enhancements for the ATM LSR
MPLS Traffic Engineering (TE)Automatic Bandwidth
Adjustment for MPLS TE Tunnels
MPLS Traffic Engineering (TE)Scalability Enhancements
MPLS Class of Service Enhancements
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
Interfaces MIB
following URL:
14
Command Reference
RFCs
RFC Title
RFC 2026 The Internet Standards Process
Description Link
Command Reference
snmp-server enable traps mpls traffic-eng
snmp-server host
15
Feature Information for the MPLS Traffic Engineering MIB
Feature Information for the MPLS Traffic Engineering MIB

Table 1 lists the release history for this MIB.
Table 1 Feature Information for the MPLS Traffic Engineering MIB

MPLS Traffic Engineering MIB 12.0(17)S The MPLS Traffic Engineering MIB feature enables the
12.0(17)ST SNMP agent support in Cisco IOS software for MPLS TE
12.2(8)T management, as implemented in the MPLS TE MIB.
12.2(14)S
In 12.0(17)S, this feature provided the ability to generate
12.2(28)SB
and queue SNMP notification messages that signal changes
12.2(31)SB2
in the operational status of MPLS TE tunnels when you are
using the MPLS TE MIB on Cisco 7500 series routers and
Cisco 12000 series Internet routers.
In 12.0(17)ST, support for SNMP traffic engineering
notifications was extended to include Cisco 7500 series
routers and Cisco 12000 series Internet routers.
In 12.2(8)T, support for SNMP TE notifications was
extended to include Cisco 7500 series routers. The
snmp-server host command was modified.
In 12.2(31)SB2, this feature was integrated.
snmp-server community, snmp-server enable traps mpls
traffic-eng, snmp-server host.
16
Glossary
Glossary
affinity bitsAn MPLS traffic engineering tunnels requirements on the attributes of the links it will
cross. The tunnels affinity bits and affinity mask must match with the attributes of the various links
carrying the tunnel.
call admission precedenceAn 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 routingProcedures 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.
flowA traffic load entering the backbone at one pointpoint 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.
headendThe LSR at which the tunnel originates. The tunnels head or tunnel interface will reside
at this LSR as well.
message because an informs message requires acknowledgment.
labelA short, fixed-length data construct that tells switching nodes how to forward data (packets or
cells).
LSPlabel switched path. A path that is followed by a labeled packet over several hops, starting at an
MIBManagement Information Base. A database of network management information (consisting of
MIB objects) that is used and maintained by a network management protocol such as 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.
MPLSMultiprotocol Label Switching. Switching method that forwards IP traffic using a label. This
NMSnetwork 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 an SNMP agent to a network management station, console, or terminal
to indicate that a significant event within Cisco IOS software has occurred (see traps).
OSPFOpen Shortest Path First. A link-state routing protocol used for routing IP.
RSVPResource 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.
tailendThe downstream, receive end of a tunnel.
traffic engineeringTechniques 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.
trapA message sent by an SNMP agent to a network management station, console, or terminal to
indicate that a significant event within Cisco IOS 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).
VCCvirtual 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.
VCIvirtual 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.
VCLvirtual channel link. A VCL is the logical connection that exists between two adjacent switches
in an ATM network.
VPIvirtual 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.
coincidental.
18
MPLS Traffic EngineeringFast Reroute MIB

The MPLS Traffic EngineeringFast Reroute MIB provides Simple Network Management Protocol
(SNMP)-based network management of the Multiprotocol Label Switching (MPLS) Fast Reroute (FRR)
feature in Cisco IOS 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.

supported, see theFeature Information for MPLS Traffic EngineeringFast Reroute MIB section on
page 17.
Contents
Contents
Prerequisites for the MPLS Traffic EngineeringFast Reroute MIB, page 2
Restrictions for the MPLS Traffic EngineeringFast Reroute MIB, page 2
Information About the MPLS Traffic EngineeringFast Reroute MIB, page 3
How to Configure the MPLS Traffic EngineeringFast Reroute MIB, page 8
Configuration Examples for the MPLS Traffic EngineeringFast Reroute MIB, page 14
Feature Information for MPLS Traffic EngineeringFast Reroute MIB, page 17
Glossary, page 18
Prerequisites for the MPLS Traffic EngineeringFast 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 EngineeringFast Reroute

MIB
The implementation of the FRR MIB is limited to read-only (RO) permission for MIB objects.
Configuration of the FRR MIB using the SNMP SET command is not supported in Cisco IOS
Release 12.2(33)SRA or in prior releases.
The following tables are not implemented in the specified releases:
mplsFrrOne2OnePlrTableNot implemented in Cisco IOS software.
mplsFrrDetourTableNot implemented in Cisco IOS software.
cmplsFrrLogTableImplemented only in Cisco IOS 12.0S-based releases.
2
Information About the MPLS Traffic EngineeringFast Reroute MIB
Information About the MPLS Traffic EngineeringFast Reroute

MIB
To use the MPLS Traffic EngineeringFast Reroute MIB, you need to understand the following
concepts:
Feature Design of the MPLS Traffic EngineeringFast Reroute MIB, page 3
Functional Structure of the MPLS Traffic EngineeringFast 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 EngineeringFast Reroute MIB, page 6
Feature Design of the MPLS Traffic EngineeringFast Reroute MIB

The FRR MIB enables standard, SNMP-based network management of FRR in Cisco IOS 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
software require some minor translations between the FRR MIB objects and the internal data structures
of Cisco IOS 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 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 EngineeringFast Reroute MIB

The SNMP agent code supporting the FRR MIB follows the existing model for such code in Cisco IOS
software and is, in part, generated by the Cisco IOS tool set, based on the MIB source code. The basis
for the generated code is the Cisco 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
software, consists of the following layers:
Platform-independent layerThis layer is generated primarily by the MIB development Cisco IOS
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 layerThe Cisco IOS tool set generates the function names and template code
for MIB objects.
3
Application-specific layerThis 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 layerThis 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 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 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. In Cisco IOS
12.0S-based releases, this object always returns 32.
cmplsFrrLogTableCurrEntries Current number of entries in the FRR log table. Except in Cisco IOS-based
releases, 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 supported in Cisco IOS Release 12.0(26)S and in prior
releases, Cisco IOS Release 12.2(33)SRA, Cisco IOS Release 12.2(33)SXH, and Cisco IOS
Release 12.4(20)T:
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 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 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 EngineeringFast 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
Note cmplsFrrLogTable and the show mpls traffic-eng fast-reroute log reroutes command are supported
only in Cisco IOS 12.0S-based releases.
cmplsFrrLogTable is indexed by the object cmplsFrrLogIndex. The index corresponds to a log entry in
the FRR features 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
7
How to Configure the MPLS Traffic EngineeringFast Reroute MIB
The following indexes specify the backup tunnel that provides protection to the protected tunnel:
cmplsFrrFacRouteProtectedIfIndex
cmplsFrrFacRouteProtectingTunIndex
cmplsFrrFacRouteProtectedTunIndex
cmplsFrrFacRouteProtectedTunInstance
cmplsFrrFacRouteProtectedTunIngressLSRId
cmplsFrrFacRouteProtectedTunEgressLSRId
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:
activeTunnel label has been placed in the Label Forwarding
Information Base (LFIB) and is ready to be applied to incoming
packets.
readyTunnels label entry has been created, but is not in the
LFIB.
partialTunnels 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 EngineeringFast Reroute

MIB
Enabling the SNMP Agent for FRR MIB Notifications, page 9 (required)
Enabling Cisco Express Forwarding, page 10 (required)
8
Enabling TE Tunnels, page 11 (required)

Enabling MPLS FRR on Each TE Tunnel, page 12 (required)
Enabling a Backup Tunnel on an Interface, page 13 (required)
Enabling the SNMP Agent for FRR MIB Notifications

To enable the SNMP agent for FRR MIB notifications, perform the following steps.
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
9

Step 5 snmp-server enable traps mpls fast-reroute protected Enables Fast Reroute traps.
Example:
Router(config)# snmp-server enable traps mpls
fast-reroute protected
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:
10

Step 3 ip cef distributed Enables distributed Cisco Express Forwarding.
Example:
Example:
Router(config)# end
Enabling TE Tunnels
To enable TE tunnels, perform the following steps.
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:
11

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.
SUMMARY STEPS
1. enable
6. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface typeslot/port Specifies the interface and enters interface
configuration mode.
Example:
12

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
4. mpls traffic-eng backup-path tunnel interface
5. end
DETAILED STEPS

Example:
Router> enable
Example:
Step 3 interface typeslot/port Specifies the interface and enters interface
configuration mode.
Example:
13
Configuration Examples for the MPLS Traffic EngineeringFast Reroute MIB

Step 4 mpls traffic-eng backup-path tunnel interface Enables a backup tunnel on a specified interface.
Example:
Router(config-if)# mpls traffic-eng backup-path tunnel1
Example:
Configuration Examples for the MPLS Traffic EngineeringFast

Reroute MIB
Enabling an SNMP Agent on a Host NMS: Example, page 14
Enabling Cisco Express Forwarding: Example, page 14
Enabling TE Tunnels: Example, page 14
Enabling MPLS FRR on Each TE Tunnel: Example, page 15
Enabling a Backup Tunnel on an Interface: Example, page 15
Enabling an SNMP Agent on a Host NMS: Example

The following example shows how to enable an SNMP agent on the host NMS:
enable
show running-config
configure terminal
snmp-server community public ro
snmp-server enable traps mpls fast-reroute protected
end
write memory
Enabling Cisco Express Forwarding: Example

The following example shows how to enable Cisco Express Forwarding:
enable
configure terminal
ip cef distributed
end
Enabling TE Tunnels: Example

The following example shows how to enable traffic engineering tunnels:
enable
configure terminal
14
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
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
end
The following sections provide references related to the MPLS Traffic EngineeringFast Reroute MIB
feature.
Related Documents
SNMP agent support for the MPLS Traffic Engineering MPLS Traffic Engineering MIB
MIB
Fast Reroute MPLS Traffic Engineering (TE): Fast Reroute (FRR) Link and Node
Protection
Standards
Standard Title
MPLS-FRR-MIB draft-ietf-mpls-fastreroute-mib-02.txt
15
Command Reference
MIBs
MIB MIBs Link
MPLS Traffic Engineering (TE) MIB To locate and download MIBs for selected platforms, Cisco IOS
following URL:
RFCs
RFC Title
No new or modified RFCs are supported by this MIB, and support for
existing RFCs has not been modified by this MIB.
Description Link
Command Reference
16
Feature Information for MPLS Traffic EngineeringFast Reroute MIB
Feature Information for MPLS Traffic EngineeringFast Reroute

MIB
features that were introduced or modified in Cisco IOS Release 12.0(10)ST or Cisco IOS Release
12.0(16)ST or 12.4(20)T or a later release appear in the table.
Table 5 Feature Information for MPLS Traffic EngineeringFast Reroute MIB

MPLS Traffic EngineeringFast Reroute 12.0(10)ST The MPLS Traffic EngineeringFast Reroute MIB
MIB 12.0(16)ST provides SNMP-based network management of the
12.0(22)S Multiprotocol Label Switching (MPLS) Fast Reroute (FRR)
12.0(26)S feature in Cisco IOS software.
12.2(33)SRA
In 12.0(10)ST, the Fast Reroute link protection feature was
12.2(33)SXH
introduced.
12.4(20)T
In 12.0(16)ST, link protection for Cisco series 7200 and
7500 platforms was added.
In 12.0(22)S, Fast Reroute enhancements, including node
protection, were added.
In 12.0(26)S, support for the IETF MIB
draft-ietf-mpls-fastreroute-mib-02.txt, which provides
network management for the FRR feature, was added.
In 12.2(33)SRA, support for cmplsFrrLogTableCurrEntries
and cmplsFrrNotifMaxRate was added. The
cmplsFrrLogTable is not supported.
In 12.2(33)SXH, support was added.
In 12.4(20)T, support was added.
17
Glossary
Glossary
optimizes network performance and scalability for networks with large and dynamic traffic patterns.
indexA method of uniquely identifying a tunnel.
instanceAn occurrence. An object can have one or more instances.
IS-ISIntermediate 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).
LFIBLabel Forwarding Information Base. The data structure for storing information about incoming
and outgoing tags (labels) and associated equivalent packets suitable for labeling.
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
NMSnetwork management station. A powerful, well-equipped computer (typically an engineering
network administration and configuration tasks.
notificationA message sent by a Simple Network Management Protocol (SNMP) agent to a network
management station, console, or terminal to indicate that a significant event within Cisco IOS software
has occurred.
objectA variable that has a specific instance associated with it.
OSPFOpen 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.
RSVPResource Reservation Protocol. Protocol for reserving network resources to provide quality of
service (QoS) guarantees to application flows.
scalar objectObjects 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 agentA managed node or device. The router that has the MIB implementation on it.
countries.
18
Glossary
coincidental.
19
Glossary
20
MPLS VPNMIB Support

Last Updated: August 26, 2008
This document describes the Simple Network Management Protocol (SNMP) agent support in Cisco IOS
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.

supported, see the Feature Information for MPLS VPNMIB Support section on page 30.
Contents
Prerequisites for MPLS VPNMIB Support, page 2
Restrictions for MPLS VPNMIB Support, page 2
Information About MPLS VPNMIB Support, page 2
How to Configure MPLS VPNMIB Support, page 20
Configuration Examples for MPLS VPNMIB Support, page 26
Feature Information for MPLS VPNMIB Support, page 30
MPLS VPNMIB Support
Prerequisites for MPLS VPNMIB Support
Glossary, page 32
Prerequisites for MPLS VPNMIB 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 VPNMIB 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 VPNMIB Support

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 3
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 19
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 VPNMIB Support
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 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 software require some minor translations between the PPVPN-MPLS-VPN MIB and
the internal data structures of Cisco IOS 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 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.
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.
3
MPLS VPNMIB Support
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 software and is, in part, generated by the Cisco IOS 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
software, consists of four layers:
Platform-independent layerThis layer is generated primarily by the MIB development Cisco IOS
software tool set and incorporates platform- and implementation-independent functions. The
Cisco IOS MIB development tool set creates a standard set of files associated with a MIB.
Application interface layerThe functions, names, and template code for MIB objects in this layer
are also generated by the MIB development Cisco IOS software tool set.
Application-specific layerThis 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 software, such as searching through data structures.
API and data structures layerThis layer contains the data structures or APIs within Cisco IOS
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 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 6
MIB Tables, page 6
Notifications, page 16
Objects that are not supported are listed in the Unsupported Objects in PPVPN-MPLS-VPN MIB
section on page 19.
4
MPLS VPNMIB Support
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 namesVPN1 and VPN2
Interfaces associated with VRFsEt1, Et2, and At3/0
Routing protocolsOpen Shortest Path First. Link-state (OSPF), Routing Information Protocol
(RIP), and internal Border Gateway Protocol (IBGP)
Routes associated with VPN110.1.0.0, 10.2.0.0, and 10.3.0.0
Routes associated with VPN2172.16.1.0 and 172.16.2.0
Routes associated with the provider network192.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, Et1 CE VPN1
OSPF 192.168.2.0 10.3.0.0
CE VPN1
VPN1, Et2 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, At3/0
172.16.1.0 CE VPN2
RIP
62823
VPN2
VPN2
5
MPLS VPNMIB Support
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.
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 10
mplsVpnVrfBgpNbrAddrTable, page 12
mplsVpnVrfSecTable, page 13
mplsVpnVrfPerfTable, page 13
mplsVpnVrfRouteTable, page 13
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.
6
MPLS VPNMIB Support
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

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
7
MPLS VPNMIB Support
Table 2 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfTable (continued)
MIB Object Function

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.
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 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.
8
MPLS VPNMIB Support
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

Et1
VPN1
Note: The mplsL3VpnVrfName is actually an Et2 Interfaces
VRFs
octet string that represents the string length
(4) and the ASCII codes for each character. VPN2 At3/0
62822
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.
The mplsVpnInterfaceConfTable is indexed by the following:
mplsVpnVrfNameThe VRF name
mplsVpnInterfaceConfIndexAn identifier that is the same as the ifIndex from the Interface MIB
of the interface assigned to the VRF
9
MPLS VPNMIB Support
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 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 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 communitiesA,
B, or Cis imported into the VRF.
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.
10
MPLS VPNMIB Support
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:
mplsVpnVrfRouteTargetIndexThe route target entry identifier
mplsVpnVrfRouteTargetTypeA value specifying whether the entry is an import route target, export
route target, or is defined as both
11
MPLS VPNMIB Support
Table 4 PPVPN-MPLS-VPN MIB Objects for the mplsVpnVrfRouteTargetTable
MIB Object Function

mplsVpnVrfRouteTargetIndex A value that defines each route targets 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 VRFs address-family.
The mplsVpnVrfBgpNbrAddrTable is indexed by the following:
mplsVpnInterfaceConfIndexAn identifier that is the same as the ifIndex from the Interface MIB
of the interface assigned to the VRF
mplsVpnVrfBgpNbrIndexThe 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).
12
MPLS VPNMIB Support
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

13
MPLS VPNMIB Support

!
!
B 10.3.0.0 [200/0] via 192.168.2.1, 04:36:33
C 10.1.0.0/16 is directly connected, Ethernet1
C 10.2.0.0/16 [200/0] directly connected Ethernet2, 04:36:33
With the show ip route vrf vpn2 command, you would see results like the following:
Router# show ip route vrf vpn2

!
!
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.
14
MPLS VPNMIB Support
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:
mplsVpnVrfNameThe VRF name, which provides the VRF routing context
mplsVpnVrfRouteDestThe IP destination address
mplsVpnVrfRouteMaskThe IP destination mask
mplsVpnVrfRouteTosThe IP header ToS bits
mplsVpnVrfRouteNextHopThe IP address of the next hop for each route entry
Note The ToS bits are not supported and, therefore, are always 0.
15
MPLS VPNMIB Support
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.
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 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 17
Notification Specification, page 18
Monitoring the PPVPN-MPLS-VPN MIB Notifications, page 19
16
MPLS VPNMIB Support
PPVPN-MPLS-VPN MIB Notification Events
The following notifications of the PPVPN-MPLS-VPN MIB are supported:

mplsVrfIfUpSent to an NMS when an interface comes up and is assigned a VRF instance.
mplsVrfIfDownGenerated 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.
mplsNumVrfRouteMidThreshExceededGenerated 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.
MplsNumVrfRouteMaxThreshExceededGenerated 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.
mplsNumVrfSecIllegalLabelThreshExceededGenerated 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.
17
MPLS VPNMIB Support
CISCO-IETF-PPVPN-MPLS-VPN MIB Notification Events
The following notification of the CISCO-IETF-PPVPN-MPLS-VPN MIB is supported in Cisco IOS

12.0S releases beginning with Release 12.0(30)S, and in Cisco IOS 12.2S releases beginning with
Release 12.2(28)S:
cMplsNumVrfRouteMaxThreshClearedGenerated 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
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 CLI commands for configuring PPVPN-MPLS-VPN MIB
notifications that are to be sent to an NMS, see the How to Configure MPLS VPNMIB Support
section on page 20 and the Command Reference section on page 29.
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.
18
MPLS VPNMIB Support
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
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
variablesmplsVpnInterfaceConfIndex and mplsVpnVrfNamein 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), notification messages relating to specific MPLS VPN events within Cisco IOS software are
generated and sent to a specified NMS in the network. Any utility that supports SNMPv1 or SNMPv2
notifications can receive notification messages.
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 software:
mplsVpnVrfBgpPathAttrPeer
mplsVpnVrfBgpPathAttrIpAddrPrefixLen
mplsVpnVrfBgpPathAttrIpAddrPrefix
mplsVpnVrfBgpPathAttrOrigin
mplsVpnVrfBgpPathAttrASPathSegment
mplsVpnVrfBgpPathAttrNextHop
mplsVpnVrfBgpPathAttrMultiExitDisc
mplsVpnVrfBgpPathAttrLocalPref
19
MPLS VPNMIB Support
How to Configure MPLS VPNMIB Support
mplsVpnVrfBgpPathAttrAtomicAggregate
mplsVpnVrfBgpPathAttrAggregatorAS
mplsVpnVrfBgpPathAttrAggregatorAddr
mplsVpnVrfBgpPathAttrCalcLocalPref
mplsVpnVrfBgpPathAttrBest
mplsVpnVrfBgpPathAttrUnknown

This section describes configuration tasks for the MPLS VPNMIB Support feature. Each task in the
list is identified as either required or optional.
Configuring the SNMP Community, page 20 (required)
Configuring the Router to Send SNMP Traps, page 22 (required)
Configuring Threshold Values for MPLS VPNSNMP Notifications, page 24 (required)
The MPLS VPN notifications are enabled or disabled using the extended CLI commands (see the
Command Reference section on page 29).
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]
20
MPLS VPNMIB Support
DETAILED STEPS

Example:
Router> enable
Step 2 show running-config [options] 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:
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 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
21
MPLS VPNMIB Support

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.
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:
22
MPLS VPNMIB Support

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-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.
23
MPLS VPNMIB Support

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.
Router(config)# snmp-server enable traps mpls
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 VPNSNMP Notifications

Perform this task to configure the following threshold values for MPLS VPNSNMP 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
24
MPLS VPNMIB Support
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.
25
MPLS VPNMIB Support
Configuration Examples for MPLS VPNMIB 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:
Router(config-vrf)# end

This section contains the following configuration examples for the MPLS VPNMIB Support feature:
Configuring the SNMP Community: Examples, page 26
Configuring the Router to Send SNMP Traps: Example, page 27
Configuring Threshold Values for MPLS VPNSNMP Notifications: Examples, page 27
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 VPNMIB 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.
26
MPLS VPNMIB Support
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 VPNSNMP 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
27
MPLS VPNMIB Support
The following sections provide additional references related to the MPLS VPN-MIB Support feature.
Related Documents
MPLS VPN configuration tasks Configuring MPLS Layer 3 VPNs
Basic MPLS VPN carrier supporting carrier MPLS VPN Carrier Supporting Carrier
configuration tasks
Standards
Standard Title
draft-ietf-ppvpn-mpls-vpn-mib-05 MPLS/BGP Virtual Private Network Management Information Base
Using SMIv2
MIBs
MIB MIBs Link
MPLS-VPN-MIB To locate and download MIBs for selected platforms, Cisco IOS
CISCO-IETF-PPVPN-MPLS-VPN-MIB
following URL:
RFCs
RFC Title
RFC 2233 The Interfaces Group MIB using SMIv2
RFC 2547bis BGP/MPLS VPNs
28
MPLS VPNMIB Support
Command Reference
Description Link
Command Reference
snmp-server enable traps mpls vpn
29
MPLS VPNMIB Support
Feature Information for MPLS VPNMIB Support

30
MPLS VPNMIB Support
Table 9 Feature Information for MPLS VPNMIB Support

MPLS VPNMIB Support 12.0(21)ST This feature was introduced into Cisco IOS
12.0(22)S Release 12.0(21)ST.
12.2(13)S
12.2(15)T
Release 12.0(22)S.
12.0(24)S1
12.0(25)S This feature was integrated into Cisco IOS
12.0(30)S Release 12.2(13)S.
12.2(28)SB The PPVPN-MPLS-VPN MIB notifications were supported
12.2(33)SRA in Cisco IOS Release 12.2(13)T. The PPVPN-MPLS-VPN
12.2(31)SB2 MIB tables were integrated into Cisco IOS
12.2(33)SXH Release 12.2(15)T.
12.4(20)T
The feature was implemented for ATM and Frame Relay
subinterfaces and integrated into Cisco IOS
Release 12.0(24)S1.
Release 12.0(25)S.
This feature was updated with the MPLS VPN Trap
Enhancement feature, which introduced the
cMplsNumVrfRouteMaxThreshCleared notification. (See
CISCO-IETF-PPVPN-MPLS-VPN MIB Notification
Events, page 18 for more information.) The
max-thresh-cleared keyword was added to the
snmp-server enable traps mpls vpn command.
Release 12.2(28)SB.
This feature was implemented into Cisco IOS
Release 12.2(31)SB2.
This feature was implemented into Cisco IOS
Release 12.4(20)T.
31
MPLS VPNMIB Support
Glossary
Glossary
ASN.1Abstract Syntax Notation One. The data types independent of particular computer structures
and representation techniques. Described by ISO International Standard 8824.
BGPBorder 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 prefixesA 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.
optimizes network performance and scalability for networks with large and dynamic traffic patterns.
CE routercustomer edge router. A router on the border between a VPN provider and a VPN customer
that belongs to the customer.
CIDRclassless 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.
communityIn SNMP, a logical group of managed devices and NMSs in the same administrative
domain.
community nameSee community string.
community stringA 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.
IETFInternet 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.
ISOCInternet 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).
cells).
LDPLabel Distribution Protocol. A standard protocol between MPLS-enabled routers that is used for
the negotiation of the labels (addresses) used to forward packets.
LFIBLabel 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.
LSRlabel switch router. A device that forwards MPLS packets based on the value of a fixed-length
32
MPLS VPNMIB Support
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 interfaceAn interface on which MPLS traffic is enabled.
MPLS VPNMultiprotocol 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 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).
NMSnetwork management system. A powerful, well-equipped computer (typically an engineering
network administration and configuration tasks.
notificationA message sent by an SNMP agent to a network management station, console, or terminal
to indicate that a significant event within Cisco IOS software has occurred. See also trap.
PE routerprovider edge router. A router on the border between a VPN provider and a VPN customer
that belongs to the provider.
PPVPNProvider-Provisioned VPN. The name of the IETF working group that is developing the
PPVPN-MPLS-VPN MIB.
QoSquality of service. A measure of performance for a transmission system that reflects its
transmission quality and service availability.
RSVPResource Reservation Protocol. A protocol for reserving network resources to provide quality
of service guarantees to application flows.
RTroute 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
discriminates routes for route updates in VRFs.
SNMPSimple 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.
SNMP2SNMP 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.
33
MPLS VPNMIB Support
Glossary
trapA 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.
VPNVirtual 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 IDA 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.
2002,2006 2008 Cisco Systems, Inc. All rights reserved.
34
MPLS EMMPLS LDP MIBRFC 3815

The MPLS EMMPLS LDP MIB - RFC 3815 feature document describes the MIBs that support the
Multiprotocol Label Switching (MPLS) Label Distribution Protocol (LDP) based on RFC 3815,
Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution
Protocol (LDP), and describes the differences between RFC 3815 and the MPLS-LDP-MIB based on the
Internet Engineering Task Force (IETF) draft Version 8 (draft-ieft-mpls-ldp-08.txt). RFC 3815 and IETF
draft Version 8 provide an interface for managing LDP through the use of the Simple Network
Management Protocol (SNMP).
In RFC 3815, the content of the MPLS-LDP-MIB is divided into four MIB modules: the
MPLS-LDP-STD-MIB, the MPLS-LDP-ATM-STD-MIB, the MPLS-LDP-FRAME-RELAY-STD-MIB,
and the MPLS-LDP-GENERIC-STD-MIB.
Cisco IOS 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

Mpls 12 2sr Book PDF

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Mpls 12 2sr Book PDF

Hochgeladen von

Copyright:

Verfügbare Formate

Cisco IOS Multiprotocol Label Switching

Cisco IOS Multiprotocol Label Switching Configuration Guide

Last Updated: October 14, 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 Mode Access Method Prompt Exit Method Mode Usage

Table 1 CLI Command Modes (continued)

Command Mode 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)# 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

For more system error messages, see the following document:

Saving Changes to a Configuration

20082009 Cisco Systems, Inc. All rights reserved.

Last Updated: November 20, 2009

This section contains the following topics:

Command Syntax Conventions

Reader Alert Conventions

Cisco IOS Documentation Set

Cisco IOS Documentation on Cisco.com

New Features List

Cisco IOS Supplementary Documents and Resources

Configuration Guides, Command References, and Supplementary Resources

Table 1 Cisco IOS Configuration Guides and Command References

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 1 Cisco IOS Configuration Guides and Command References (continued)

Configuration Guide and Command Reference Titles Features/Protocols/Technologies

Table 2 Cisco IOS Supplementary Documents and Resources

Document Title or Resource Description

Additional Resources and Documentation Feedback

20082009 Cisco Systems, Inc. All rights reserved.

First Published: October 2002

History for the MPLS Static Labels feature