SJ-20140731105308-012-ZXR10 M6000-S (V3.00.10) Carrier-Class Router Configuration Guide (MPLS) - 608087

ZXR10 M6000-S
Carrier-Class Router
Configuration Guide (MPLS)

Version: 3.00.10
ZTE CORPORATION
No. 55, Hi-tech Road South, ShenZhen, P.R.China
Postcode: 518057
Tel: +86-755-26771900
Fax: +86-755-26770801
URL: http://support.zte.com.cn
E-mail: support@zte.com.cn
LEGAL INFORMATION
Copyright 2014 ZTE CORPORATION.
The contents of this document are protected by copyright laws and international treaties. Any reproduction or
distribution of this document or any portion of this document, in any form by any means, without the prior written
consent of ZTE CORPORATION is prohibited.
Additionally, the contents of this document are protected by
contractual confidentiality obligations.

All company, brand and product names are trade or service marks, or registered trade or service marks, of ZTE
CORPORATION or of their respective owners.
This document is provided as is, and all express, implied, or statutory warranties, representations or conditions
are disclaimed, including without limitation any implied warranty of merchantability, fitness for a particular purpose,
title or non-infringement. ZTE CORPORATION and its licensors shall not be liable for damages resulting from the
use of or reliance on the information contained herein.
ZTE CORPORATION or its licensors may have current or pending intellectual property rights or applications
covering the subject matter of this document. Except as expressly provided in any written license between ZTE
CORPORATION and its licensee, the user of this document shall not acquire any license to the subject matter
herein.
ZTE CORPORATION reserves the right to upgrade or make technical change to this product without further notice.
Users may visit the ZTE technical support website http://support.zte.com.cn to inquire for related information.
The ultimate right to interpret this product resides in ZTE CORPORATION.
Revision History
Revision No.
Revision Date
Revision Reason
R1.0
2014-10-20
First edition.
Serial Number: SJ-20140731105308-012

Publishing Date: 2014-10-20 (R1.0)
SJ-20140731105308-012|2014-10-20 (R1.0)
ZTE Proprietary and Confidential
Contents
About This Manual ......................................................................................... I
Chapter 1 MPLS Configuration ................................................................. 1-1
1.1 MPLS Overview ................................................................................................. 1-1
1.2 MPLS Term........................................................................................................ 1-5
1.3 LSP Establishment ............................................................................................. 1-8
1.4 Label Distribution and Management................................................................... 1-12
1.5 MPLS Configuration ......................................................................................... 1-20
1.6 MPLS Configuration Instance............................................................................ 1-30
1.6.1 Establishing a Basic LDP Neighbour Session .......................................... 1-30
1.6.2 Establishing an LDP Target Session ........................................................ 1-33
1.6.3 Configuring a Label Distribution Policy..................................................... 1-36
1.6.4 Configuring an LDP Multi-Instance ......................................................... 1-39
1.6.5 Establishing an LDP FRR ....................................................................... 1-42
1.6.6 LDP Graceful Restart Configuration Instance ........................................... 1-49
1.6.7 LSP Load-Sharing Configuration Example ............................................... 1-56
1.6.8 LDP BFD Configuration Example ............................................................ 1-60
1.6.9 Peer BFD Configuration Example ............................................................ 1-64
1.6.10 GTSM Configuration Example ............................................................... 1-67
1.6.11 LDP IGP Synchronization Configuration Example (OSPF) ....................... 1-71
1.6.12 LDP IGP Synchronization Configuration Example (IS-IS) ........................ 1-75
1.6.13 Instance with LDPIGP Synchronization Integrated with FRR ................... 1-79
1.6.14 Packet Filtration Configuration Example................................................. 1-85
1.6.15 Label-Distribution Configuration Example............................................... 1-88
1.6.16 Label-Retention Configuration Example ................................................. 1-90
1.6.17 Label-Advertise Configuration Example ................................................. 1-93
1.6.18 Label-Request Configuration Example ................................................... 1-96
1.6.19 LSP-Control Configuration Example ...................................................... 1-99
1.6.20 Longest-Match Configuration Example..................................................1-103
Chapter 2 MPLS TE Configuration............................................................ 2-1

2.1 RSVP Configuration ........................................................................................... 2-1
2.1.1 RSVP Overview ....................................................................................... 2-1
2.1.2 Configuring RSVP .................................................................................... 2-5
2.1.3 RSVP Configuration Instance.................................................................... 2-8
I
SJ-20140731105308-012|2014-10-20 (R1.0)
2.2 TE Summary Refresh Introduction..................................................................... 2-24

2.2.1 TE Summary Refresh Introduction........................................................... 2-24
2.2.2 Configuring TE Summary Refresh ........................................................... 2-25
2.2.3 TE Summary Refresh Configuration Example .......................................... 2-26
2.3 TE Message Acknowledgement and Retransmission .......................................... 2-29
2.3.1 Introduction to TE Message Acknowledgement and Retransmission.......... 2-29
2.3.2 Configuring TE Message Acknowledgement and Retransmission .............. 2-30
2.3.3 TE Message Acknowledgement and Retransmission Configuration
Example ............................................................................................... 2-31
2.4 TE Authentication Configuration ........................................................................ 2-34
2.4.1 TE Authentication Overview .................................................................... 2-34
2.4.2 Configuring TE Authentication ................................................................. 2-35
2.4.3 TE Authentication Configuration Instance................................................. 2-37
2.5 Confiugration of MPLS TE Crossing Several AS Domains................................... 2-40
2.5.1 MPLS TE Crossing Several AS Domains Overview .................................. 2-40
2.5.2 Configuring the MPLS TE Crossing Several AS Domains.......................... 2-42
2.5.3 MPLS TE Crossing Several AS Domains Configuration Instance............... 2-43
2.6 TE-FRR Configuration ...................................................................................... 2-58
2.6.1 TE-FRR Overview .................................................................................. 2-58
2.6.2 Configuring TE-FRR ............................................................................... 2-61
2.6.3 TE-FRR Configuration Instance............................................................... 2-63
2.7 FRR Promotion Introduction.............................................................................2-103
2.7.1 FRR Promotion Introduction...................................................................2-103
2.7.2 Configuring FRR Promotion ...................................................................2-104
2.7.3 FRR Promotion Configuration Examples .................................................2-105
2.8 FRR-Hello Configuration.................................................................................. 2-114
2.8.1 FRR Hello Introduction .......................................................................... 2-114
2.8.2 Configuring FRR Hello........................................................................... 2-114
2.8.3 FRR Hello Configuration Example .......................................................... 2-116
2.9 MPLS TE End-to-End Protection Path Configuration..........................................2-121
2.9.1 MPLS TE End-to-End Path Protection Overview......................................2-121
2.9.2 Path Configuration for MPLS TE End-to-End Protection...........................2-121
2.9.3 Establishing an MPLS TE End-to-End Path Protection.............................2-122
2.10 Loose Node Re-optimization ..........................................................................2-128
2.10.1 Loose Node Re-optimization Introduction ..............................................2-128
2.10.2 Configuring Loose Node Re-optimization ..............................................2-128
2.10.3 Loose Node Re-optimization Configuration Instance ..............................2-129
2.11 Automatic Bandwidth Regulation on an MPLS TE ...........................................2-135
II
SJ-20140731105308-012|2014-10-20 (R1.0)
2.11.1 Introduction to Automatic Bandwidth Regulation Function of the MPLS

TE.......................................................................................................2-135
2.11.2 Configuring Automatic MPLS TE Bandwidth Regulation .........................2-135
2.11.3 Instances of Automatic Bandwidth Regulation Configuration for the
MPLS TE.............................................................................................2-137
2.12 TE GR Configuration .....................................................................................2-140
2.12.1 GR Introduction ...................................................................................2-140
2.12.2 Configuring GR ...................................................................................2-143
2.12.3 GR Configuration Example...................................................................2-144
2.13 TE Tunnel FA Configuration ...........................................................................2-148
2.13.1 TE Tunnel FA Introduction....................................................................2-148
2.13.2 Configuring TE Tunnel FA ....................................................................2-148
2.13.3 TE Tunnel FA Configuration Example ...................................................2-149
2.14 TE Tunnel AR Configuration...........................................................................2-152
2.14.1 TE Tunnel AR Introduction ...................................................................2-152
2.14.2 Configuring TE Tunnel AR ...................................................................2-153
2.14.3 TE Tunnel AR Configuration Example...................................................2-154
2.15 TE Metric Configuration .................................................................................2-157
2.15.1 TE Metric Introduction..........................................................................2-157
2.15.2 Configuring TE Metric .........................................................................2-157
2.15.3 TE Metric Configuration Example .........................................................2-158
2.16 TE SRLG Configuration .................................................................................2-162
2.16.1 TE SRLG Introduction..........................................................................2-162
2.16.2 Configuring TE SRLG ..........................................................................2-163
2.16.3 TE SRLG Configuration Example .........................................................2-163
2.17 TE Tunnel Reoptimization Configuration .........................................................2-168
2.17.1 Introduction to TE Tunnel Reoptimization ..............................................2-168
2.17.2 Configuring TE Tunnel Re-optimization .................................................2-168
2.17.3 TE Tunnel Reoptimization Configuration Example .................................2-170
2.18 TE HOTSTANDBY Configuration....................................................................2-173
2.18.1 Tunnel Establishment With Only TE HOTSTANDBY ..............................2-173
2.18.2 Configuring the TE HOTSTANDBY Function .........................................2-174
2.18.3 TE HOTSTANDBY Function Configuration Instance...............................2-174
2.19 WTR Configuration for a TE Tunnel ................................................................2-179
2.19.1 Introduction to TE Tunnel WTR ............................................................2-179
2.19.2 Configuring the WTR Function of a TE Tunnel.......................................2-179
2.19.3 TE Tunnel WTR Configuration Instance ................................................2-180
2.20 TE Tunnels Supporting Soft Preemption .........................................................2-185
III
SJ-20140731105308-012|2014-10-20 (R1.0)
2.20.1 TE Tunnels Supporting Soft-Preemption ..............................................2-185

2.20.2 Configuring a TE Tunnel Supporting Priorities and Soft Preemption ........2-187
2.20.3 Instance of TE Tunnels Supporting Soft Preemption ..............................2-188
2.21 Equal Load Sharing on the TE-ECMP .............................................................2-198
2.21.1 Equal Load Sharing on the TE-ECMP ...................................................2-198
2.21.2 Configuring Equal Load Sharing on the TE-ECMP .................................2-198
2.21.3 Instance of Equal Load Sharing Configuration on the TE-ECMP .............2-199
2.22 TE Affinity .....................................................................................................2-202
2.22.1 TE Affinity Introduction.........................................................................2-202
2.22.2 Configuring the TE Affinity....................................................................2-202
2.22.3 TE Affinity Configuration Instance .........................................................2-203
2.23 Binding Interfaces Supporting TE Bandwidth Reservation ................................2-214
2.23.1 Binding Interfaces Supporting TE Bandwidth Reservation ......................2-214
2.23.2 Configuring Binding Interfaces Supporting TE Bandwidth
Reservation .........................................................................................2-214
2.23.3 Configuration Instance for Binding Interfaces Supporting TE Bandwidth
Reservation .........................................................................................2-215
2.24 RSVP-TEs Supporting Resource Reservation .................................................2-220
2.24.1 Resource Reservation in FF Mode on the RSVP-TE ..............................2-220
2.24.2 Configuring RSVP-TE Supporting Resource Reservation .......................2-220
2.24.3 Instance for Resource Reservation in FF Mode on the RSVP-TE............2-221
Chapter 3 MPLS OAM Configuration ........................................................ 3-1

3.1 MPLS OAM Overview......................................................................................... 3-1
3.2 Configuring MPLS OAM...................................................................................... 3-1
3.3 MPLS OAM Configuration Example ..................................................................... 3-4
Chapter 4 Static Tunnel Configuration ..................................................... 4-1

4.1 Static Tunnel Overview ....................................................................................... 4-1
4.1.1 Associated Bidirectional Tunnels for a Static TE Tunnel ............................. 4-1
4.1.2 Static TE Tunnels Supporting DS-TE ......................................................... 4-2
4.1.3 Reserved Bandwidth Sharing on Static TE Tunnels .................................... 4-3
4.2 Configuring a Static Tunnel ................................................................................. 4-4
4.2.1 Configuring Bidirectional BFD for a Static Tunnel........................................ 4-5
4.2.2 Configuring the FA Function on a Static Tunnel .......................................... 4-6
4.2.3 Configuring the AR Function for a Static Tunnel ......................................... 4-7
4.2.4 Configuring an Associated Bidirectional Tunnel for a Static TE Tunnel ......... 4-7
4.2.5 Configuring a Static TE Tunnel Supporting DS-TE ...................................... 4-8
4.2.6 Configuring Reserved Bandwidth Sharing on Static TE Tunnels .................4-11
IV
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 5 Tunnel Protection Group Configuration ................................. 5-1

5.1 Tunnel Protection Group Overview ...................................................................... 5-1
5.2 Configuring a Tunnel Protection Group ................................................................ 5-6
5.3 Tunnel Protection Group Configuration Example .................................................. 5-9
Chapter 6 APS Configuration .................................................................... 6-1

6.1 APS Overview.................................................................................................... 6-1
6.2 Configuring APS ................................................................................................ 6-5
6.2.1 Configuring APS for a Tunnel Protection Group.......................................... 6-6
6.2.2 Configuring APS for a PW Protection Group .............................................. 6-8
6.3 APS Configuration Example................................................................................ 6-9
6.3.1 APS Configuration Example (Tunnel Protection Group) .............................. 6-9
6.3.2 APS Configuration Example (PW Protection Group) ................................. 6-15
Figures............................................................................................................. I
Glossary .........................................................................................................V
V
SJ-20140731105308-012|2014-10-20 (R1.0)
This page intentionally left blank.
VI
SJ-20140731105308-012|2014-10-20 (R1.0)
About This Manual

Purpose
This manual describes the principles, configuration commands and configuration
examples that are related to MPLS services of the ZXR10 M6000-S system.
Intended Audience
This manual is intended for:
l
l
l
Network planning engineers

Commissioning engineers
Maintaining engineers
What Is in This Manual

This manual contains the following chapters.
Chapter 1, MPLS
Describes the MPLS principle, configuration commands and
Configuration
configuration examples.
Chapter 2, MPLS TE
Describes the MPLS TE-related principle, configuration commands
Configuration
and configuration examples.
Chapter 3, MPLS OAM
Describes the MPLS OAM principles, configuration commands and
Configuration
Chapter 4, Static Tunnel
Describes the Static Tunnel principle, configuration commands and
Configuration
Chapter 5, Tunnel Protection
Describes the principles for tunnel protection group, configuration
Group Configuration
commands and configuration examples.
Chapter 6, APS Configuration
Describes the APS principles, configuration commands and

Conventions
This manual uses the following conventions:
Italics
Variables in commands. It may also refer to other related manuals and documents.
Bold
Menus, menu options, function names, input fields, option button names, check boxes,
drop-down lists, dialog box names, window names, parameters, and commands.
Constant
Text that you type, program codes, filenames, directory names, and function names.
width
[]
Optional parameters.
{}
Mandatory parameters.
I
SJ-20140731105308-012|2014-10-20 (R1.0)
Separates individual parameter in series of parameters.

Danger: indicates an imminently hazardous situation. Failure to comply can result in
death or serious injury, equipment damage, or site breakdown.
Warning: indicates a potentially hazardous situation. Failure to comply can result in
serious injury, equipment damage, or interruption of major services.
Caution: indicates a potentially hazardous situation. Failure to comply can result in
moderate injury, equipment damage, or interruption of minor services.
Note: provides additional information about a certain topic.
II
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 1
MPLS Configuration
Table of Contents
MPLS Overview .........................................................................................................1-1
MPLS Term ................................................................................................................1-5
LSP Establishment .....................................................................................................1-8
Label Distribution and Management .........................................................................1-12
MPLS Configuration .................................................................................................1-20
MPLS Configuration Instance ...................................................................................1-30
1.1 MPLS Overview

MPLS Introduction
With the rapid development of network scale of the Internet and user number, people pay
more and more attention to the problem that how to extend service further on the network
and how to improve the quality of services. As the Internet Protocol (IP) protocol is a
connectionless protocol and there is no quality of service in the Internet, it is difficult to
provide enough throughputs and time delay that meet the requirements. For IP protocol,
it just uses best-effort mechanism to satisfy the users. Without other measures to improve
the current network conditions, it is impossible to develop new services in large scale.
Among existing network technologies, in terms of Quality of Service (QoS), as a rapid
packet switching technology that is developed after IP, Asynchronous Transfer Mode (ATM)
has a lot of advantages. Therefore, ATM was considered as a technology that could be
used everywhere, and people would establish a pure ATM network that people could reach
through the core network. However, practice proves that the thought is wrong. The pure
ATM network is too complicated and expensive for people to establish. Corresponding
services do not catch the ATM network development, which leads to hard development
of ATM now. In addition, although ATM switches are widely used as backbone nodes in
networks, services that take ATM cells to desktop develop very slowly.
IP and ATM technologies meet difficulties in their own fields, and they need each other
to have further development. There is inevitability to combine the two technologies.
Therefore, Multi-Protocol Label Switching (MPLS) technology comes into being. It
integrates the advantages of switching technology in network core and IP routing
technology in network edge.
MPLS protocol uses label switching, so routers only need to judge the labels before
they forward packets. MPLS supports any protocol at the network layer (such as IPv6,
1-1
SJ-20140731105308-012|2014-10-20 (R1.0)
ZXR10 M6000-S Configuration Guide (MPLS)
Internetwork Packet Exchange protocol (IPX), IP and so on) and data link layer (such as
ATM, Frame Relay (FR), Point to Point Protocol (PPP) and so on).
IP Forwarding Characteristic
Routing devices collect network segment information in the network through different
routing protocols to establish routing tables. When a packet reaches a router, the router
decides the interface to forward the packet and the next hop device according to the
routing information in the routing table. Once the packet is forwarded, it is not controlled
by the router. Whether the packet can be forwarded to the destination correctly depends
on whether there is correct routing information on all routers along the path.
The procedure of traditional IP forwarding is shown in Figure 1-1.
Figure 1-1 IP Forwarding
Traditional IP forwarding has the following characteristics:

l
Routers search routing tables according to the longest matching principle, so they
cannot realize high speed forwarding. The longest matching means to use the route
with the longest subnet mask that matches the destination in the routing table.
IP network is connectionless, so QoS cannot be ensured.
ATM Forwarding Characteristic

ATM switches forward data through Virtual Path Identifier (VPI)/Virtual Channel Identifier
(VCI). VPI/VCI is valid on local devices. The switches do not judge routing information
when forwarding ATM cells.
When an ATM switch receives a message, it looks up VPI/VCI table and then forwards the
message by switching, as shown in Figure 1-2.
1-2
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 1 MPLS Configuration
Figure 1-2 ATM Forwarding
The handling of messages on ATM switches is easier than that on routers. ATM forwarding
has the following characteristics:
l
l
l
ATM chooses the path on the base of data link layer. VPI/VCI is valid on local
switch, so the fast looking-up can be implemented through hardware. While IP
communication need to comply with the longest matching principle.
ATM network is connection-oriented. It can implement QoS according to different
VPIs/VCIs. IP communication distinguishes QoS data flow through quintuple groups
(including source IP, destination IP, protocol number, source port number and
destination port number).
ATM supports traffic control mechanism.
ATM supports different kinds of services, such as real-time service.
As the implementation of ATM is complicated and expensive and the development of

services do not catch the step, ATM is developed slowly.
MPLS Forwarding Characteristic

MPLS belongs to the third generation of network architecture. It is a new switching
standard of IP high-speed backbone network. It is brought forward by the Internet
Engineering Task Force (IETF).
MPLS uses simplified ATM switching technology to implement switching at Layer 2 and
Layer 3. It provides a label for each IP packet, and encapsulates the label together with
the packet to form a new MPLS packet. The label decides the transmission path and
priority of the IP packet.
Before forwarding the IP packet, an MPLS router reads the top label in the packet instead
of the IP address in each IP packet. Therefore, the speed to forward packets is much
faster, and MPLS is called a layer 2.5 protocol, as shown in Figure 1-3.
1-3
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 1-3 Position of MPLS
MPLS can use different Layer 2 protocols. Till now, MPLS task force has implemented
standardization of identifiers used in FR, ATM, PPP link and IEEE802.3 Local Area
Networks (LANs). An advantage to run MPLS in FR and ATM is that it carries free
connectivity in IP network to these connection-orientated technologies.
The working mechanism of MPLS network is that it implements routing through IP outside
the MPLS network and implements Layer 2 switching through looking up labels within the
MPLS network.
MPLS has the following characteristics:
l
l
l
l
l
MPLS provides connection-orientated services for IP network.

By integrated technologies of data link layer (ATM and FR) and network layer, MPLS
solves the problems about Internet extension and QoS, and provides Internet services
of high quality.
MPLS uses accurate matching instead of the longest matching method to choose
paths through the short and fixed labels, which provides high speed IP forwarding.
When providing IP services, MPLS also provides high reliability and QoS assurance.
MPLS establishes Constraint-based Routing Label Switched Path (CR-LSP) through
explicit routing function and signaling protocols with QoS parameters. Therefore,
traffic engineering can be implemented effectively.
MPLS supports Virtual Private Network (VPN) through label nesting technology.
MPLS Brief Principles

MPLS uses a traditional IP forwarding mode outside the MPLS domain and uses label
switching mode in the MPLS domain without looking up the IP information, as shown in
Figure 1-4.
Figure 1-4 MPLS Working Principle
1-4
SJ-20140731105308-012|2014-10-20 (R1.0)
Within the MPLS domain, all routers run MPLS label distribution protocol, such as Label
Distribution Protocol (LDP) and resource ReSerVation Protocol (RSVP). Through these
protocol, devices in the MPLS domain will be distributed with corresponding labels.
The procedure of forwarding an IP packet in the MPLS domain is described below.
1. The ingress Label Edge Router (LER) receives the IP packet, and distributes a label
to this packet for identification.
2. When the backbone Label Switched Router (LSR) receives the identified packet, it
searches its label forwarding table and replaces the label in the packet with an new
outbound label.
3. When the egress LER receives the packet, it removes the label and implements
traditional IP forwarding on the third layer.
1.2 MPLS Term

MPLS Label
MPLS label is a fixed-length and locally valid identifier. The label usually exists between
the Layer 2 encapsulation header and Layer 3 packet. A label maps to a Forwarding
Equivalence Class (FEC) through binding.
As shown in Figure 1-5, an MPLS label is a fixed-length integer. The length is 32 bits. A
label is used to identify a specific FEC.
Figure 1-5 MPLS Label Structure
The MPLS label is encapsulated after the data link layer header and before network layer
header. It contains the following fields:
l
Label field
This field is 20-bit long, containing the actual value of a label.
EXP field
This field is 3-bit long. It is a CoS. At present, it is mpls exp, used as MPLS QoS.
S field
1-5
SJ-20140731105308-012|2014-10-20 (R1.0)
When the value of this field is 1, it means that this label is stack bottom label. When
the value of this field is 0, it means that this label is not the stack bottom label.
l
TTL Field
This field is 8-bit long, used for coding time to live.
MPLS supports different protocols at data link layer. MPLS label is encapsulated after data
link layer information and before Layer 3 data. Different protocols define different protocol
numbers for MPLS.
In Ethernet networks, MPLS packets are identified by value 0x8847 (for unicast) and value
0x8848 (for multicast). In PPP, a new Network Control Protocol (NCP), that is, MPLSCP,
is identified by value 0x8281.
The S field of a label is shown in Figure 1-6. In an MPLS domain, a message can be
nested with multiple labels. Two or more MPLS labels form a label stack.
Figure 1-6 MPLS Label Stack
When a message is encapsulated with multiple labels, LSRs handle the message
according to First In First Out principle. That is, LSRs just forward the message according
to the top label rather than the inner labels.
As MPLS providing label nesting technology, MPLS can be applied in different services.
MPLS VPN and traffic engineering are realized based on the nesting of multiple layer
labels.
FEC
FEC is a group of data performed by equivalence method during forwarding. It is created
by address, tunnel or Class of Service (CoS). The same labels are distributed to an FEC
on a device.
In fact, MPLS is a classification forwarding technology. It classifies the packets with the
same handling method (such as the same destination, same forwarding path, the same
service class and so on) into a class, that is, the FEC.
Packets belonging to the same FEC are handled completely the same in the MPLS
network. During the binding of LDP labels, different FECs correspond to different labels.
In the MPLS network, the nodes identify the FEC to which the packets belong according
to the labels.
1-6
SJ-20140731105308-012|2014-10-20 (R1.0)
When two groups of packets with the same source address but different destination
addresses enter an MPLS domain, MPLS judges the packets according to FEC. When
finding that the packets belong to two FECs, MPLS treats the groups in different ways
(including paths resource reservations). The ingress node adds different labels for the
two groups of packets and then transmit the packets to the MPLS domain. The nodes in
the MPLS domain forward the packets according to labels. When the packets leave the
MPLS domain, the egress node pops out the labels. The two groups of packets will be
forwarded according to the requirements of networks that they go to.
In traditional routing forwarding, packets are in the same FEC (such as Layer 3 searching)
on each router. In MPLS, FEC is defined for packets at the ingress of the network.
LSR, LER, LSP and LDP

Terms in MPLS network are described below.
l
Label Switched Router (LSR)

LSR is the core router in MPLS network. It provides the function of label switching
and label distribution.
Label Edge Router (LER)

LER is the router at the MPLS edge. It distributes corresponding labels for the traffic
to MPLS domain. It provides functions of traffic classification, label mapping and label
removing.
Label Switched Path (LSP)

Data flow of an FEC traffic are distributed with different labels on different nodes. Data
forwarding is implemented according to these labels. The path that data flow passes
through is the LSP. LSP is connection-oriented, and the path is established before
data transmission.
Label Distribution Protocol (LDP)

Routers in MPLS domain run LDP to distribute labels for packets.
As shown in Figure 1-7, MPLS domain is the range in which nodes run MPLS. MPLS
domain contains LSR and LER.
1-7
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 1-7 MPLS Special Terms
MPLS consists of LER and LSR.

l
l
LER is responsible for FEC classification, traffic engineering and LSP establishment
initiation, IP packet forwarding, Diff-Serv and so on.
LSR eis responsible for LSP establishment and label switching.
1.3 LSP Establishment

LSP Introduction
Label Switched Path (LSP) is a forwarding path established according to MPLS. It is
composed of LSRs and links between the source LSR and the destination LSR. An LSP
is similar with a virtual circuit of ATM. The establishment of LSP is also the process of
label distribution to each node along the path.
There are three drive modes to establish an LSP: flow-driven, topology-driven and
application-driven.
l
Flow-driven
Packet flow triggers the label distribution.
In this mode, the cost for label distribution is in direct proportion to the traffic. Time
delay exists for label distribution. To distribute specific labels to specific network
resources to support specific programs, flow-driven mode should be used.
Topology-driven
In this mode, label distribution is implemented according to normal routing protocols.
When an LSR handles route update of Open Shortest Path First (OSPF) or Border
Gateway Protocol (BGP), the LSR modifies the entries in label forwarding table,
meanwhile the LSR distributes labels for these entries. As long as there is a route,
label distribution is finished in advance. Therefore, there is no time delay when LSR
forwards packets.
1-8
SJ-20140731105308-012|2014-10-20 (R1.0)
Application-driven
In this mode, LSR distributes labels on the base of normally requested control service
traffic. The corresponding protocol is RSVP. When an LSR handles RSVP, the LSR
modifies the entries in the label forwarding table, meanwhile the LSR distributes labels
for these entries. This mode requires application programs to bring forward label
requests and flow rules in advance to obtain labels. It also distributes labels for existed
routes, so there is no time delay. However, it is difficult to implement RSVP in the
whole network, so this mode is seldom used.
Compared with flow-driven, topology-driven has the following advantages:

l
l
Label value assignment and distribution correspond to control message, so network

cost is little.
Label is assigned and distributed before traffic arrives, so there is no time delay.
Therefore, topology-driven is usually used in networks to distribute labels.

The protocol used between LSRs to distribute labels is the signaling protocol. An LSP
is established through the interactions of signaling protocol. Common signaling protocols
are described below.
l
l
l
l
Label Distribution Protocol (LDP) (the most common signaling protocol)

Constraint based Routing Label Distribution Protocol (CR-LDP)
RSVP with Traffic Engineering extensions (RSVP-TE) (usually used in traffic
engineering)
Multiprotocol BGP (MP-BGP) (usually used in BGP/MPLS VPN to distribute inner layer
labels)
LSP Establishment
The establishment of an LSP in MPLS network contains three steps:
1. Each node runs a dynamic routing protocol such as BGP, OSPF or Intermediate
System-to-Intermediate System (IS-IS) to generate a routing table.
2. According to the routing table, each node establishes a Label Information Base (LIB)
under the control of LDP.
3. An LSP is established after "out" labels and "in" labels on ingress LSR, intermediate
LSRs and egress LSR are mapped to each other.
The detailed procedure is described below.
1. Routing table generation
As shown in Figure 1-8, each router runs a dynamic routing protocol such as OSPF to
generate a routing table. RA, RB and RC learn the route 47.1.0.0/16 to the network
edge.
1-9
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 1-8 Routing Table Generation
2. LIB generation
As shown in Figure 1-9, the routers run LDP to distribute labels.
Figure 1-9 LIB Generation
As an egress LSR to 47.1.0.0/16, RC distributes a label "40" and sends it to upstream

neighbor RB. This information is recorded in LIB. When RC receives a message with
label "40", it knows that this message is to 47.1.0.0/16.
When RB receives the binding information of 47.1.0.0/16 and label "40" from RC,
it keeps the label information and the receiving interface in LIB. Meanwhile, RB
distributes a label for 47.1.0.0/16 and sends this information to neighbors except the
neighbor connecting to the receiving interface. Suppose that RB sends a label "50"
to RA. Therefore, there is such a piece of information in LIB of RB, as shown below.
IntfIn
1
LabelIn
50
Dest
47.1.0.0
IntfOut
2
LabelOut
40
This information means when RB receives a message with label "50" from interface
1, it changes the label to "40" and sends the message from interface 2. RB does not
look up routing information in its routing table.
When RA receives binding information, RA acts in the same way as RB does.
1-10
SJ-20140731105308-012|2014-10-20 (R1.0)
LIB is always synchronous with IP routing tables. Once a new non-BGP route is
generated in the routing table, LSR distributes a label for this route. LSR does not
distribute labels for BGP routes by default.
3. LSP generation
After the interaction of labels finishes, a LSP is established. When LSRs forward
messages, they forward them according to labels instead of looking up routing tables,
as shown in Figure 1-10.
Figure 1-10 LSP Generation
When RA receives a message with destination address 47.1.1.1, it looks up its routing
table first, and then it looks up label forwarding table. When it finds that the FEC
47.1.0.0/16 corresponds to the label "50", RA adds the label to the header of the
message and sends it from interface 2.
When RB receives the message with label "50" from interface 1, it looks up the label
forwarding table, and then RB changes the label to "40" and sends the message from
interface 2.
When RC receives the message with label "40" from interface 1, it looks up the label
forwarding table. RC finds that the destination of the message is a network segment
connecting to itself directly. Therefore, RC pops out the label and sends the IP
message.
Penultimate Hop Popping

In an MPLS domain, when the egress LER receives packets from its neighbor, it
implements searching twice.
The egress LER looks up label forwarding table first and removes the label, then it looks
up routing table and forwards the IP message. This decreases the performance of the
LER and increases forwarding complexity. Penultimate hop popping mechanism solves
this problem.
It is only necessary to use penultimate hop popping mechanism for direct routes and
aggregated routes. For direct routes, LER has to look up routing table to get next
hop information before it forwards messages to destinations connecting to it directly.
1-11
SJ-20140731105308-012|2014-10-20 (R1.0)
For aggregated routes, LER has to look up routing table for accurate routes. In other
situations, Layer 2 information of messages has been recorded in LFIB, so there is no
need to look up routing table. The messages are switched directly.
As shown in Figure 1-11, RC is an egress LER to 47.1.0.0/16, so RC distributes a particular
label "3" (means implicit-null) for messages to 47.1.0.0/16. When RB receives the label
"3" distributed by RC, RB knows that it is the penultimate hop popping LSR.
Figure 1-11 Penultimate Hop Popping
During forwarding procedure, when RB receives a message with a label "50" from RA,
it looks up the label forwarding table. RB finds that the "out" label is "3", so it pops out
the label in the message and sends the message to RC. When RC receives the message
without a label, it looks up routing table directly and forwards the message.
1.4 Label Distribution and Management

MPLS has different modes of label distribution and management.
Label distribution modes are as follows:
l
l
DoD
DU
There are two label control modes.

l
l
Ordered label control mode

Independent label control mode
There are two label retention modes.

l
l
Liberal mode
Conservative mode
By default, ZXR10 M6000-S use DU label distribution mode, independent label control
mode and liberal label retention mode.
1-12
SJ-20140731105308-012|2014-10-20 (R1.0)
Label Distribution Mode

There are two label distribution modes: DoD and DU. The upstream LSR and downstream
LSR having neighbor relationship should agree on the label distribution mode in order to
distribute the labels.
For a specific FEC, an LSR distributes labels after receiving label requests. This is the
DoD label distribution.
Figure 1-12 shows that RC is the egress LER to 171.68.10.0/24. RC cannot send label
binding information to upstream neighbor RB forwardly. RC has to wait for the request
messages from the upstream.
Figure 1-12 Downstream on Demand (DoD)
For a specific FEC, an LSR does not need to get request messages for labels from
upstream neighbors before distributing labels. This is the DU label distribution.
Figure 1-13 illustrates that RC does not need to wait for label request message from
upstream before sending binding information of the FEC and label to the downstream
LSR. In the same way, RB does not need to wait for label request message from RA
before sending binding information of the FEC and label to RC.
Figure 1-13 Downstream Unsolicited
Label Control Mode

There are two label control modes in an MPLS network:
independent mode.
l
the ordered mode and
Ordered mode
1-13
SJ-20140731105308-012|2014-10-20 (R1.0)
Only when an LSR receives specific label mapping messages of a particular FEC, or
when the LSR is the egress of the FEC, labels are distributed to the LSR and then
the LSR sends label mapping messages to upstream LSR. Ordered mode is a strict
mode which can be used in explicit route and multicast.
l
Independent mode
Each LSR can bind labels to messages independently and send label mapping
messages to the upstream neighbor when the LSR receives an FEC, no matter
whether the LSR receives label mapping messages from the downstream neighbor.
This process is similar to the route packet forwarding of traditional routers. Each
router forwards packets independently based on its routing table. The packets are
transmitted correctly through routing protocol.
Label Retention Mode

There are two label retention modes: liberal and conservative.
For a specific FEC, LSR1 receives label binding messages from LSR2, LSR3 and LSR4.
When LSR2 and LSR3 are not the next hop LSR1, if LSR1 saves these binding messages,
LSR1 uses liberal label retention mode. If LSR1 discards these binding messages, LSR1
uses conservative label retention mode.
In liberal label retention mode, an LSR can adapt itself to route changes quickly, but this
takes up more memory. In conservative label retention mode, an LSR can reduce the
memory, but it has weak ability to adapt itself to route changes.
Therefore, when an LSR is required to adapt itself to route changes quickly, use liberal
label retention mode. When an LSR is required to save few labels, use conservative label
retention mode.
Label Forwarding Table

A label forwarding table (that is, the label forwarding information base) is a database where
binding information of FECs and labels is stored. A LSR maintains the label forwarding
table through label distribution protocol dynamically.
A label forwarding table contains the following items:
l
l
l
l
l
l
InLabel: in label, distributed by local router for upstream LSR

OutLabel: out label, distributed by downstream LSR for local router
Dest: destination network segment or host
Pfxlen: prefix length
Interface: egress interface
NextHop: next hop
When an LSR receives a message, it looks up the label forwarding table. It searches for
the OutLabel based on the InLabel of the message, and then the LSR replaces the old
label with the Outlabel and sends the message from the exiting interface.
1-14
SJ-20140731105308-012|2014-10-20 (R1.0)
Label Distribution Protocol

There are the following types of protocols that can implement label distribution function.
l
l
l
l
LDP, most widely used label distribution protocol

CR-LDP
RSVP-TE, usually used in traffic engineering
MP-BGP, usually used in BGP/MPLS VPN for inner layer label distribution
LDP is a protocol that generates labels dynamically. It is based on UDP and TCP. The
protocol messages are routed hop by hop based on routing tables. LDP advertises FEC
(network prefix) and marks mapping relationship between LSRs, generates LSP at last.
LDP Session Establishment and Maintenance

LSR establishes and maintains an LIB based on label and binding information between
FECs. Two LSRs that use LDP to switch FEC/label binding information are called LDP
Peers. The main function of LDP is to make LSR implement binding of FEC and labels
and advertise the binding to LSR neighbor. Therefore, the LSRs can agree on the label
bindings.
The ZXR10 M6000-S supports LDP regulations defined in RFC, including neighbor
discovery, label request, label mapping, label withdraw, label release and error
management.
l
l
l
l
Neighbor discovery: LSR sends Hello messages to neighbors periodically to discover

LDP peers automatically.
Session establishment and maintenance: LSRs establish TCP connections and finish
session initialization (negotiation of different parameters).
LSP establishment and maintenance: LSRs distribute labels for FECs and establish
LSPs.
Session withdraw: When session hold-time expires, the session is interrupted.
Before switching labels, LDP peers need to establish an LDP session. Figure 1-14 shows
the LDP session establishment procedure.
1-15
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 1-14 LDP Session Establishment
1. R1 and R2 send multicast Hello messages to protocol interfaces before establishing

the session. The messages are encapsulated by UDP and port number is 646.
Meanwhile, protocol interfaces on R1 and R2 detect Hello messages in real time to
discover neighbors.
2. After R1 and R2 receive Hello messages, they judge whether a session has been
established with the peer. If a session has not been established, they prepare to
establish a session. The establishment procedure of a session is to establish a TCP
connection through port number 646. Before establishing the TCP connection, R1 and
R2 elect a master based on transmission addresses. The router with bigger IP address
will acts as the master. The master initiates the TCP connection. Here suppose that
transmission address of R2 is larger. Therefore, R2 sends TCP connection request.
3. R2 sends an initialization message to establish the session. The message contains
parameters to be negotiated.
4. When R1 receives the message from R2, it checks the parameters. If parameters
pass the check, R1 will send an initialization message and a keepalive message to
R2. Parameters to be negotiated are included in the initialization message.
5. R2 checks the message from R1. If parameters pass the check, R2 will send a
keepalive message to R1.
6. The session is established after R1 and R2 receive keepalive messages. During the
procedure, if any error messages are received, the session will be closed and the TCP
connection is disconnected.
LDP Multi-Instance
Market competition arouses the appearance of Level 2 carriers. Level 2 carriers rely on
the services provided by Level 1 carriers, and then they provide the services to users. To
1-16
SJ-20140731105308-012|2014-10-20 (R1.0)
manage and control the service, Level 1 carriers need to differentiate the paths that are
provided for a specific Level 2 carrier. This is the application of Carrier Of Carrier (COC).
ZXR10 M6000-S provides LDP multi-instance function to support the applications of COC.
In LDP multi-instance, several LDP instances can be configured on an LSR. Each instance
belongs to a VPN domain and it is bound to VRF. Each instance creates FECs for the
addresses and routes in the VPN domain on its own, and it binds and distributes labels
for the FECs. The instances are independent of each other. The resources used by all
the instances are limited by LDP performance parameters, that is, the resources used
by all the instances should not be beyond the resources provided by LDP performance
parameters.
LDP IGP Synchronization

Some services may be deployed to pass the LDP-enabled network, and these services rely
on end-to-end LSPs. For example, in the L2VPN or L3VPN service scenario, an MPLS
path is required between PE routers to carry VPN traffic. This means that, between PE
routers, all of the links that the shortest IP path passes through should have operational
LDP sessions, and the label binding information of these sessions have been exchanged
between PE routers. If one of these links is not covered by LDP sessions, a black hole is
generated, and services related to MPLS forwarding are interrupted.
Figure 1-15 shows the network topology for LDP IGP synchronization. It provides the
following functions:
l
l
l
All devices and links on the backbone network have the LDP function enabled, and
each link has the same cost. There are two LDP LSPs from PE1 to PE2 (active LSP:
PE1P3PE2, standby LSP: PE1P1P2PE2).
If the P3PE2 link is broken, VPN traffic is switched over from the active LSP to the
standby LSP.
If the P3PE2 link comes up again, the route is soon converged to the active path
(PE1P3PE2), and the VPN traffic is immediately switched back to the active
LSP. It may take a long time to establish LDP sessions and distribute label binding
information between P3 and PE2, which causes VPN traffic to be interrupted for a
long time.
Figure 1-15 Network Topology for IGP Synchronization
1-17
SJ-20140731105308-012|2014-10-20 (R1.0)
The ZXR10 M6000-S provides LDP IGP synchronization to achieve synchronization

convergence between LDP LSPs and IGP routes. Supported IGP protocols include OSPF
and IS-IS.
When a link that has LDP enabled comes up, if the associated LDP sessions are not fully
operational, the link cost advertised by IGP has the highest value, which prevents routes
converging to the link. The OSPF-advertised cost is 0xFFFF, and the IS-IS-advertised cost
is 0xFFFFFE.
To make LDP sessions fully operational, ensure that the following requirements are met:
l
l
l
LDP hello neighbors have been established.

The LDP sessions associated with the link have been established.
The LDP label binding information has been exchanged between LDP neighbors.
When a GR occurs, sessions are kept in the statuses before the GR occurs until the GR
timeout is reached.
GTSM
The GTSM-based TTL hack can effectively reduce the loss caused by attacks (such as
the DoS attack). The following illustrate the working principles of GTSM.
The GTSM mechanism prevents attacks by detecting the TTL field in IP packets. After
attackers keeps on sending packets to a network device by simulating actual LDP packets,
the forwarding plane of the device detects whether the received packets are LDP packets,
and the device takes one of the following actions based on the detection result:
l
l
For non-LDP packets, the device forwards or discards them based on the default
processing policy.
For LDP packets:
If the device has the GTSM function enabled, the GTSM policy-based matching
is performed first. If a match is found, the device then determines whether the
TTL of the received packets is within the permitted range. If not, the packets are
considered to be attack packets and are discarded. If a match is not found, the
packets are discarded or forwarded based on the default policy.
If the device has the GTSM function disabled, the packets are directly sent to the
control plane.
Implementation of Longest Matching Routes in LSP

In an MPLS Seamless network, MPLS applications are required to be extended from the
carrier's core backbone network to the subscriber side, and the AN is directly connected
to the subscriber side. This results in a great amount of AN nodes on a network, and
the advertisement of loopback addresses of AN nodes within their associated IGP-running
areas only. If the IGP operates across areas, the aggregated route mode should be used
to advertise routes to reduce the loads caused by running the IGP on the core-domain
or other access devices. This requires that the LDP can learn labels, and the longest
matching rule rather than the traditional exact matching rule is used to match routes.
1-18
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 1-16 shows that PE2 and PE3 (edge routers) advertise their loopback addresses
(10.1.1.1/32 and 10.1.1.2/32) to ABR2 (border router), and ABR2 only advertises the
aggregated route (10.1.1.0/24) to another domain. In this scenario, both ABR1 and
PE1 learn the aggregated route (10.1.1.0/24) only. The broken line refers to the route
advertisement flow. This results in that PE1 cannot obtain the exact routing information of
PE2 and PE3, and cross-domain LSPs (from PE1 to PE2 or PE3 in the remote domain)
cannot be established.
Figure 1-16 Implementation of Longest Matching Routes in LSP
This problem can be resolved by using the longest matching mode to establish LSPs. The
flow is as follows: When an LSR receives the label mapping information of an FEC from
a downstream LSR, if the longest match corresponding to the FEC is found from local
routes and the next-hop of the route is the LSR that sends the label mapping information,
the upstream LSR is then used to forward the FEC, assign a label to the FEC, and advertise
the label mapping information.
Figure 1-16 shows the flow of matching a route and establishing an LSP:
1. PE2 assigns a label (3) to an FEC (10.1.1.1/32), and advertises the label mapping
information to ABR2.
2. Upon receipt of the label mapping information, ABR2 assigns a label (16) to the FEC
(10.1.1.1/32), and advertises the label mapping information to the upstream.
3. Upon receipt of the label mapping information, ABR1 searches for the longest match
(10.1.1.0/24) in its local routing module, and finds that ABR2 is the next-hop of the
10.1.1.0/24 route. ABR1 is then used to forward the FEC (10.1.1.1/32), assign a label
(17) to an FEC (10.1.1.0/24), and advertises the label mapping information related to
the FEC (10.1.1.1/32) to the upstream.
4. The solid lines in Figure 1-16 illustrate the label distribution procedure. All the nodes
that the LSP passes through advertise the label mapping information of the 10.1.1.1/32
FEC to the upstream and the corresponding forwarding entries are generated. A
cross-domain LSP (PE1ABR1ABR2PE2) is established.
1-19
SJ-20140731105308-012|2014-10-20 (R1.0)
The above flow is also applicable to the establishment of another cross-domain LSP
(PE1ABR1ABR2PE3).
Packet Filtration
The ZXR10 M6000-S supports the filtration of LDP UDP/TCP packets that do not meet the
ACL policy requirements for security concerns.
1.5 MPLS Configuration

This procedure describes how to enable MPLS to distribute labels between network nodes
and then establish an LSP.
Steps
1. Enable MPLS LDP.
Step
Command
Function
ZXR10(config)#mpls ldp instance <instance-id>[vrf
Enables MPLS LDP. The
<vrf-name>]
instance-id parameter is in a
range of 1 to 65535.
ZXR10(config-ldp-instance-id)#interface
Adds interfaces in LDP
<interface-name>
configuration mode.
Note that, after this command
is executed, label switching is
implemented on the specified
interface.
Execute the mpls ldp instance command to enable the LDP function and enter the
LDP configuration mode. Add interfaces in LDP configuration mode. This means that
label switching should be implemented on these interfaces. Then the LDP sends Hello
messages on the interfaces periodically. When the device obtains the "out" label for
the specific destination network segment on an interface, the device adds the label to
the packets to the destination and forwards the packets on this interface.
A configuration example is shown below:
ZXR10(config)#interface loopback1
ZXR10(config-if-loopback1)#ip address 210.210.210.1 255.255.255.255
ZXR10(config-if-loopback1)#exit
ZXR10(config)#interface gei-0/1/0/1
ZXR10(config-if-gei-0/1/0/1)#no shutdown
ZXR10(config-if-gei-0/1/0/1)#ip address 190.190.190.2 255.255.255.0
ZXR10(config-if-gei-0/1/0/1)#exit
ZXR10(config)#interface gei-0/1/0/2
ZXR10(config-if-gei-0/1/0/2)#no shutdown
ZXR10(config-if-gei-0/1/0/2)#ip address 190.190.191.2 255.255.255.0
1-20
SJ-20140731105308-012|2014-10-20 (R1.0)

ZXR10(config-if-gei-0/1/0/2)#exit
ZXR10(config)#mpls ldp instance 1

ZXR10(config-ldp-1)#router-id loopback1
ZXR10(config-ldp-1)#interface gei-0/1/0/2
ZXR10(config-ldp-1-if-gei-0/1/0/2)#discovery transport-address interface
ZXR10(config-ldp-1-if-gei-0/1/0/2)#exit
ZXR10(config-ldp-1)#interface gei-0/1/0/1
ZXR10(config-ldp-1-if-gei-0/1/0/1)#discovery transport-address interface
ZXR10(config-ldp-1-if-gei-0/1/0/1)#exit
2. Configure the LDP router-ID.

Command
Function
ZXR10(config-ldp-instance-id)#mpls ldp
Configures the LDP router-ID. This
router-id <interface-name>
command can be used to configure the

address on a specific interface as the LDP
router-ID in the VPN domain.
Considering the stability of an LDP
connection, it is recommended to use
the loopback interface address as the
router-ID of an LDP instance.
3. Configure label generation and distribution.

Through the configuration, users can control label generation, label range and label
distribution.
Step
Command
Function
Enables LDP to establish
<vrf-name>]
an LSP along common

hop-by-hop routes and enters
LDP configuration mode.
ZXR10(config-ldp-instance-id)#access-fec {
Controls generation of labels
ip-prefix { for < prefix-access-list>| host-route-only}| bgp}
for the specified network

segment and creates an FEC.
ZXR10(config-ldp-instance-id)#label-advertise
Controls the labels generated
{disable | old-style | for < prefix-access-list>[to <
locally ("in" labels) to be
prefix-access-list>]}
distributed through LDP.

This command can control
the labels for the specified
destination network segments
to be advertised to the
specified neighbors. By
default, all labels are
distributed to all neighbors.
1-21
SJ-20140731105308-012|2014-10-20 (R1.0)
host-route-only means to create FECs for host addresses only.

bgp means to create FECs for route network segments obtained through BGP.
A configuration example is shown below.
ZXR10(config)#ipv4-access-list 2
ZXR10(config-ipv4-acl)#rule 10 deny 200.200.201.0 0.0.0.255
ZXR10(config-ipv4-acl)#rule 20 permit any
ZXR10(config-ipv4-acl)#exit
ZXR10(config-ldp-1)#access-fec for 2
ZXR10(config-ldp-1)#exit
Based on the configuration in the example, LDP does not distribute labels for routes
on the 200.200.201.0/24 network segment.
4. Configure an LDP neighbor.
Step
Command
Function
Enables an LDP instance
<vrf-name>]
to establish an LSP along

common hop-by-hop routes
and enters LDP configuration
mode.
ZXR10(config-ldp-instance-id)#target-session
Configures the session
{<ip-address>| ipv6 < X:X::X:X >}[dod]
address of non-directly
connected remote target to
establish a session.
ZXR10(config-ldp-instance-id)#discovery hello {
Configures the interval for
holdtime <holdtime>| interval <interval>}
sending Hello messages

and the holdtime of an LDP
neighbor.
ZXR10(config-ldp-instance-id)#discovery
Configures the interval for
targeted-hello {holdtime <holdtime>| interval <interval>}
sending Hello messages

and the time-out of LDP
neighbor discovery between
non-directly connected LSRs
in an LDP instance.
holdtime <holdtime>: This is the hold-time (in seconds) when an LDP instance finds
that a neighbor cannot receive following Hello messages, range: 165535, default: 1.
For targeted-hello packets, the default is 45.
interval <interval>: This configures an LDP instance to send Hello messages
periodically. The interval range is 165535 and the unit is second. The default value
is 5 seconds. The default value of targeted-hello is 15 seconds.
A configuration example is shown below.
1-22
SJ-20140731105308-012|2014-10-20 (R1.0)

ZXR10(config-ldp-1)#discovery hello holdtime 20
ZXR10(config-ldp-1)#show mpls ldp parameters instance 1
Protocol version: 1
Session holdtime: 180 sec; keep alive interval: 60 sec
Discovery hello: holdtime: 20 sec; interval: 5 sec
Discovery targeted hello: holdtime: 45 sec; interval: 15 sec
LDP for targeted sessions
Downstream on Demand max hop count: 255
LDP used lsp control mode: Independent
LDP configred lsp control mode: Independent
LDP used label retention mode: Liberal
LDP configred label retention mode: Liberal
LDP loop detection: off
LDP IGP sync delay: 5 sec
5. Configure other LDP functions.

Step
Command
Function
<vrf-name>]
an LSP along common

ZXR10(config-ldp-instance-id)#egress { for
Controls LDP to distribute
<prefix-access-list>| nexthop <nexthop-access-list>}
popping labels for the

specified non-directly
connected destination
network segment, that is,
the egress control policy.
ZXR10(config-ldp-instance-id)#explicit-null [for
Makes the LDP instance
<prefix-acl>][to <peer-acl>]
advertise explicit-null label

when it should advertise
implicit-null label. By default,
implicit-null label is used.
ZXR10(config-ldp-instance-id)#holdtime <seconds>
Configures the hold-time

when LDP session cannot
receive following LDP
messages. It is in a range
of 15 to 65535, in unit of
second. The default value is
180 seconds.
ZXR10(config-ldp-instance-id)#neighbor <ip-address
Configures the MD5 password
> password {sealed <sealed-password>|<password>}
for TCP establishment

between LDP peers.
1-23
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-ldp-instance-id)#label-request for
Configures the prefix and
<prefix-access-list>
downstream neighbor for

request messages sent by
LDP.
ZXR10(config-ldp-instance-id)#gtsm
Enables the checking of
target-neighbor < ip-address > hop-count <hop-num>
the TTL value of LDP
ZXR10(config-ldp-instance-id-if-ifname)#gtsm
packets from the peer end

(for directly-connected or
non-directly-connected
sessions)
ZXR10(config-ldp-instance-id)#filter packet for
Configures a packet filtration
<word>
policy.
ZXR10(config-ldp-instance-id)#igp sync delay
Configures a delay time
<para>
for MPLS LDP and IGP

synchronization.
10
ZXR10(config-ldp-instance-id)#label-retention
Sets the retention mode of
conservative
all LDP labels associated

with the LDP instance to
conservative.
11
ZXR10(config-ldp-instance-id)#longest-match {ipv4
Enables the use of the longest
for <acl-name>|ipv6 for <acl-name>}
matching rule to establish and

remove LSPs.
12
ZXR10(config-ldp-instance-id)#lsp-control ordered
Sets the control mode of all

LSPs associated with the LDP
instance to ordered.
13
ZXR10(config-ldp-instance-id-if-ifname)#label-
Enables the DoD mode on the
distribution dod
LDP interface.
<prefix-acl>: It is to use explicit-null label to advertise the prefix that is advertised by

implicit-null label. It is optional.
<peer-acl>: It is to designate the neighbors to which explicit-null label is advertised. It
is optional.
<ip-address>: address of the peer LSR.
<hop-num>: TTL value, range: 1254.
<acl-name>: ACL name, range: 131 characters.
<para>: delay time, range: 165535.
<acl-name>: ACL name, range: 131 characters.
6. Configure LDP BFD.
1-24
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
<vrf-name>]
an LSP along common

ZXR10(config-ldp-instance-id)#bfd <FEC-addres
Configures parameters of
s><mask-length> interval <interval> min_rx <min_rx>
LDP LSP BFD and triggers
multiplier <multiplier>
the establishment of LSP BFD

session.
ZXR10(config-ldp-instance-id)#peer bfd
Configures parameters
remote-routerid < ip-address >
related to LDPPeerBFD.
After an LDP session is up,
establishment of a PeerBFD
session with a specified
neighbor is immediately
triggered.
ZXR10(config-ldp-instance-id)#peer bfd
If only the delay field is
remote-routerid <ip-address>[delay [<time>]]
configured, a BFD session

establishment is delayed 60
seconds after a LDP session
is up.
If a specific duration is set
to the delay field, the BFD
session establishment is
delayed for the configured
duration after the LDP session
is up.
<interval>: minimum interval (in milliseconds) for sending messages, range: 10990.
<min_rx>: minimum interval (in milliseconds) for receiving messages, range: 10990.
<multiplier>: multiple of detection time-out, range: 350.
<ip-address>: router-id of the LDP neighbor.
delay: Delay duration after an LDP session is up.
<time>: delay duration after an LDP session gets up, range: 0-720, unit: seconds.
7. Configure LDP GR.
Step
Command
Function
ZXR10(config)#mpls ldp instance <1-65535>[vrf
Creates an LDP instance
<vrf-name>]
and enters LDP configuration

mode.
1-25
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-ldp-instance-id)#graceful-restart
Configures LDP GR.
[timer {max-recovery <interval>| neighbor-liveness

<interval>}]
max-recovery <interval>: maximum time (in seconds) that the LSR waits for label
recovery at the peer end, which needs to be negotiated, range: 15600, default: 120
neighbor-liveness <interval>: maximum time (in seconds) that the LSR waits for LDP
session recovery, which needs to be negotiated, range: 5300, default: 120
8. Configure LSP Ping/LSP trace detection.
To ensure that the routers in the network can report the errors related to the MPLS LSP
data plane or provide some exceptional information, the LSP Ping/LSP Trace function
is put forwarded.
LSP Ping/LSP Trace is a simple and efficient method used to detect the fault of the
MPLS LSP data plane. It can detect and isolate some faults, such as route black-hole
and route loss, that are not found by some control planes in a short time.
For the details about LSP Ping/LSP Trace, refer to the Network Layer Detection
section in ZXR10 M6000-S Configuration Guide (System Management).
9. Enable LDP IGP synchronization (OSPF-based):
Step
Command
Function
ZXR10(config)#router ospf <1-65535>[vrf <vrf-name>]
Creates an OSPF instance,

and enters the OSPF
configuration mode.
Configures LDP IGP
ZXR10(config-ospf-instance-id)#mpls ldp sync
synchronization. Different
ZXR10(config-ospf-instance-id)#area
configuration commands
<0-4294967295> mpls ldp sync
determine whether IGP

ZXR10(config-ospf-instance-id-if-interfacename)#mpls ldp sync
synchronization is valid for an

entire OSPF instance, an area
of the OSFP instance, or an
OSPF interface.
area<04294967295>: OSPF area ID.

10. Enable LDP IGP synchronization (IS-IS-based):
Step
Command
Function
ZXR10(config)#router isis <1-65535>[vrf <vrf-name>]
Creates an IS-IS instance, and

enters the IS-IS configuration
mode.
1-26
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-isis-instance-id)#mpls ldp sync
Configures LDP IGP
ZXR10(config-isis-instance-id-if-interface-
synchronization. Different
configuration commands
name)#mpls ldp sync
determine whether IGP

synchronization is valid for an
entire ISIS instance or an ISIS
interface.
11. Configure a delay timer for LDP IGP synchronization.

Step
Command
Function
Creates an LDP instance and
<vrf-name>]
enters the LDP configuration

mode.
ZXR10(config-ldp-instance-id)#igp sync delay
Configure a delay timer for
<1-65535>
LDP IGP synchronization.
igp sync delay <165535>: delay time (in seconds) for LDP IGP synchronization,
default: 5.
12. Configure the automatic configuration function of the LDP interface.
Step
Command
Function
Creates an LDP instance and
<vrf-name>]
enters the LDP configuration

mode.
ZXR10(config-ldp-instance-id)#auto-config interface
Enables or disables the
global { enable | disable }
automatic configuration
function on all LDP IPv4
interfaces of an LDP instance.
This is a global configuration
command. After disabling
the automatic configuration
function of the LDP interfaces,
no LDP interface can be
automatically created, and
the LDP Hello messages
can be received and sent
and LDP sessions can be
created on all interfaces
are determined by the LDP
interface configuration,
1-27
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
without being affected by the
IGP status of the interfaces.
ZXR10(config-ldp-instance-id)#auto-config interface
<interface-name>{enable | disable}
function on specific LDP IPv4
interfaces of an LDP instance.
If the automatic configuration
function is globally disabled
on an LDP instance, this
configuration has the highest
priority no matter whether
the automatic configuration
function is enabled or disabled
on the interface. If the
function is not globally
disabled, that is, is enabled
on an LDP instance, check
whether the automatic
configuration function is
disabled on singe interface. If
the function is disabled on any
single interface, this interface
cannot be automatically
created.
enable: Enables the global automatic IPv4 configuration function or the automatic
configuration function on a specific LDP IPv4 interface of an LDP instance.
disable: disables the global automatic IPv4 configuration function or the automatic
configuration function on a specific LDP IPv4 interface of an LDP instance.
<interface-name>: interface name
13. Verify that the configurations are correct.
Command
Function
ZXR10#show mpls ldp interface [<interface-name>] instance
Displays the information about
<instance id>
the interfaces on which LDP is

enabled in the VPN domain of
an LDP instance.
1-28
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#show mpls ldp backoff instance <instance-id>
Displays the configuration of

session backoff parameters and
the sessions in backoff state in
an LDP instance.
ZXR10#show mpls ldp bindings [{( X:X::X:X <0-128> ) | (<ip-
Displays label binding
address>{<net-mask>|<length>}[longer-prefixes])}][local-label
information of an LDP instance.
<label>[<label>]][remote-label <label>[<label>]][neighbor
<ip-address>][detail] instance <instance-id>
ZXR10#show mpls ldp bindings summary instance <instance-id>
Displays the brief label binding

ZXR10#show mpls ldp discovery [ detail ] instance
Displays the discovery
<instance-id>
ZXR10#show mpls ldp neighbor [<neighbor>|<interface-name
Displays the session information
>][detail] instance <instance-id>
of an LDP instance.
ZXR10#show mpls ldp parameters instance <instance-id>
Displays the current parameter

ZXR10#show debug ldp instance <instance-id>
Displays the debugging

ZXR10#show mpls ldp graceful-restart instance <1-65535>
Displays the current LDP GR

configuration of the router.
ZXR10#show mpls ldp neighbor [[<neighbor-ipaddress>][detai
Displays GR neighbor
l]|[graceful-restart]] instance <instance-id>
information.
ZXR10#show mpls ldp igp sync [interface <interface-name>]
Displays the status of LDP IGP
instance <instance-id>
synchronization.
14. Maintain MPLS.

Command
Function
ZXR10#debug ldp advertisements instance <instance-id>
Monitors the addresses and

labels advertised to LDP
neighbors. Run the no command
to cancel the monitoring.
ZXR10#debug ldp all [instance < instance-id>]
Enables all debugging functions

related to LDP.
ZXR10#debug ldp bindings instance <instanc-id>
Monitors the addresses and

labels advertised by LDP
neighbors.
1-29
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#debug ldp messages {received | sent} instance
Monitors the messages sending
<instance-id>
to LDP neighbors or received

from LDP neighbors.
ZXR10#debug ldp session {io | state-machine} instance
Monitors LSP sessions.
<instance-id>
ZXR10#debug ldp transport {connections | events} instance
Monitors information discovered
<instance-id>
by LDP.
ZXR10#debug ldp graceful-restart instance <1-65535>
Monitors LDP GR debugging

information.
End of Steps
1.6 MPLS Configuration Instance

1.6.1 Establishing a Basic LDP Neighbour Session
Configuration Descriptions
As shown in Figure 1-17, an LDP neighbor is established between the R1 router and the
R2 router to forward the MPLS label.
Figure 1-17 Establishing a Basic LDP Neighbour Session
Configuration Flow
The thought to establish a basic LDP neighbor session between the R1 router and the R2
router is described below:
1. Enable the MPLS hop-by-hop forwarding between the R1 router and the R2 router.
2. Configure the LDP label distribution between the R1 router and the R2 router
3. Set the IP address of the loopback interface as the router-ID of the LSR
Configuration Commands
The configuration of the R1 router is as follows:
R1(config)#interface loopback1
R1(config-if-loopback1)#ip address 1.1.1.34 255.255.255.255
1-30
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-if-loopback1)#exit
R1(config)#interface gei-0/2/0/7
R1(config-if-gei-0/2/0/7)#no shutdown
R1(config-if-gei-0/2/0/7)#ip address 100.100.100.1 255.255.255.0
R1(config-if-gei-0/2/0/7)#exit
R1(config)#router isis
R1(config-isis-0)#area 00.0001
R1(config-isis-0)#system-id 0001.0002.0034
R1(config-isis-0)#interface gei-0/2/0/7
R1(config-isis-0-if-gei-0/2/0/7)#ip router isis
R1(config-isis-0-if-gei-0/2/0/7)#exit
R1(config-isis-0)#interface loopback1
R1(config-isis-0-if-loopback1)#ip router isis
R1(config-isis-0-if-loopback1)#exit
R1(config-isis-0)#exit
R1(config)#mpls ldp instance 1
/*Configure the Router-ID and the interface for the LDP*/
R1(config-ldp-1)#router-id loopback1
R1(config-ldp-1)#interface gei-0/2/0/7
R1(config-ldp-1-if-gei-0/2/0/7)#exit
R1(config-ldp-1)#exit

R2(config-isis-0-if-loopbck1)#ip router isis
R2(config-isis-0-if-loopbck1)#exit

1-31
SJ-20140731105308-012|2014-10-20 (R1.0)

l
l
Note:
In the above configuration, the purpose of running the IS-IS protocol is to advertise
the Router-IDs (that is, the route of the loopback interface addresses) of each LSR.
Using the loopback interface addresses as the router-IDs of LDP instances can ensure
the stability of LDP ID on routers, because the state of loopback interface addresses
will not change (unless users shut down the interfaces manually).
Configuration Verification
Show the neighbor information on the R2 router:
R2(config)#show mpls ldp neighbor detail instance 1
Peer LDP Ident: 1.1.1.34:0; Local LDP Ident: 1.1.1.35:0
TCP connection: 1.1.1.34.646 - 1.1.1.35.26408
State: Oper; Msgs sent/rcvd: 31/31; Downstream
Up Time: 00:24:57
LDP discovery sources:
gei-0/3/0/7; Src IP addr: 100.100.100.1
holdtime: 15000 ms, hello interval: 5000 ms
Addresses bound to peer LDP Ident:
1.1.1.34 100.100.100.1
Session holdtime: 180000 ms; KA interval: 60000 ms
LDP Peer BFD not register.
LDP dynamic capability enable:
LDP send capability:
LDP dynamic capability
LDP Typed Wildcard FEC Cap
LDP Unrecognized Noti Cap
LDP received capability:
LDP dynamic capability negotiate success
LDP Typed Wildcard FEC Cap negotiate success
LDP Unrecognized Noti Cap negotiate success
If the session is in Oper status, it means that the parameters are negotiated correctly and
the neighbor relationship between R2 and 1.1.1.34 (R1) has been established.
1-32
SJ-20140731105308-012|2014-10-20 (R1.0)
1.6.2 Establishing an LDP Target Session

As shown in Figure 1-18, the R1 router, the R2 router and the R3 router support MPLS.
Direc-connected LDP sessions are established between the R1 router and the R2 router,
and between the R1 router and the R3 router. The target LDP session is established
between the R2 router and the R3 router.
Figure 1-18 Establishing an LDP Target Session
Configuration Flow
The thought to configure an LDP target session between the R2 router and the R3 router
is described below:
1. Establish the LDP neighbor relationships between the R1 router and the R2 router,
and between the R1 router and the R3 router.
2. Establish the LDP target neighbor relationship between the R2 router and the R3
router.
3. Set the IP address of the loopback interface as the router-ID of the LSR
1-33
SJ-20140731105308-012|2014-10-20 (R1.0)


/*Configure the Router ID and the interface for the LDP*/


R2(config-ldp-1)#target-session 1.1.1.39
1-34
SJ-20140731105308-012|2014-10-20 (R1.0)



Use the show mpls ldp neighbor command to show the neighbor information on the R3
router.
R3(config)#show mpls ldp neighbor instance 1
TCP connection: 1.1.1.34.26406 - 1.1.1.2.646
Up Time: 00:01:38
gei-0/3/0/7; Src IP addr: 200.200.200.1
1.1.1.34 100.100.100.1 200.200.200.1
TCP connection: 1.1.1.35.26412 - 1.1.1.2.646
1-35
SJ-20140731105308-012|2014-10-20 (R1.0)

Up Time: 00:00:39
Targeted Hello (1.1.1.6); Src IP addr: 1.1.1.6
1.1.1.35 100.100.100.2
the neighbor relationship between R3 and 1.1.1.35 (R2) has been established.
1.6.3 Configuring a Label Distribution Policy

As shown in Figure 1-19, a label distribution policy is configured on the R1 router. The R1
router will not distribute labels for FECs in network segments 5.0.0.0/8 and 110.1.0.0/16.
Figure 1-19 Configuring a Label Distribution Policy
Configuration Flow
The thought to configure a label distribution policy on the R1 router is described below.
1.
2.
3.
4.
Enable the MPLS hop-by-hop forwarding between the R1 router and the R2 router
Configure the LDP label distribution between R1 and R2
Set the IP address on loopback interface as the router-ID of an LDP instance on LSR
Configure the label distribution policy on the R1 router. No label is distributed to FECs
in network segments 5.0.0.0/8 and 110.1.0.0/16
Configuration Steps
1-36
SJ-20140731105308-012|2014-10-20 (R1.0)


R1(config-ldp-1)#access-fec ip-prefix for zte
/*Configure the label distribution policy. Do not allocate labels for FEC
in the 5.0.0.0/8 and the 110.1.0.0/16 network segment*/
R1(config)#ipv4-access-list zte
R1(config-ipv4-acl)#rule 10 deny 5.0.0.0 0.255.255.255
R1(config-ipv4-acl)#rule 20 deny 110.1.0.0 0.0.255.255
R1(config-ipv4-acl)#rule 30 permit any
R1(config-ipv4-acl)#exit


1-37
SJ-20140731105308-012|2014-10-20 (R1.0)

Show the result on the R1 router after the policy is applied.
R1(config)#show mpls ldp bindings instance 1
1.1.1.0/32
local binding:
label: 4126
remote binding: lsr: 1.1.1.35:0, label: imp-null(inuse)

remote binding: lsr: 1.1.1.39:0, label: 51
1.1.1.18/32
local binding:
label: 4128

remote binding: lsr: 1.1.1.39:0, label: UnTag
1.1.1.31/32 (no route)
1.1.1.34/32
local binding:
label: imp-null

1.1.1.35/32
local binding:
label: 4101

1.1.1.39/32
local binding:
label: 4119

remote binding: lsr: 1.1.1.39:0, label: imp-null
60.0.2.0/24
local binding:
label: 4108
remote binding: lsr: 1.1.1.35:0, label: 4143(inuse)

60.0.3.0/24
local binding:
label: 4109

The result shows that R1 does not distribute FECs for the 5.0.0.0/8 and 110.1.0.0/16
network segments.
1-38
SJ-20140731105308-012|2014-10-20 (R1.0)
1.6.4 Configuring an LDP Multi-Instance

The LDP session network is shown in Figure 1-20. The R1 router, the R2 router and the
R3 router support the MPLS. Establish a public network session between the R1 router
and the R2 router., and establish a private network session between the R1 router and the
R3 router.
Figure 1-20 LDP Multi-Instance Topology
Configuration Flow
The thought to configure an LDP multi-instance between the R2 router and the R3 router
is described below:
1. Establish an LDP public network neighbor between the R1 router and the R2 router.
2. Establish an LDP private network neighbor between the R1 router and the R3 router.
/*The following configuration is for the LDP public network*/
1-39
SJ-20140731105308-012|2014-10-20 (R1.0)

/*The following configuration is for the LDP private network*/
R1(config)#ip vrf
R1(config-vrf-a)#rd 1:1
R1(config-vrf-a)#address-family ipv4
R1(config-vrf-a-af-ipv4)#exit
R1(config-vrf-a)#exit
R1(config-if-loopback2)#ip vrf forwarding a
R1(config-if-gei-0/2/0/2)#ip vrf forwarding a
R1(config)#router isis 1 vrf a
R1(config)#mpls ldp instance 2 vrf a

1-40
SJ-20140731105308-012|2014-10-20 (R1.0)


Show the neighbor establishment result of the public network and the private network on
the R1 router:
Peer LDP Ident: 1.2.1.2:0; Local LDP Ident 1.2.1.1:0
TCP connection: 1.2.1.2.1054 - 1.2.1.1.646
1-41
SJ-20140731105308-012|2014-10-20 (R1.0)

state: Oper; Msgs sent/rcvd: 47/48; Downstream
Up Time: 00:00:30
gei-0/2/0/7; Src IP addr: 64.2.2.5
1.2.1.2 64.2.2.5
the public network neighbor relationship has been established with the R2 router.
TCP connection: 1.2.1.2.1054 - 1.2.1.1.646
Up Time: 00:00:30
gei-0/2/0/7; Src IP addr: 64.2.2.5
1.2.1.2 64.2.2.5
the private network neighbor relationship has been established with the R3. router
1.6.5 Establishing an LDP FRR

As shown in Figure 1-21, based on the L3VPN environment and the LDP FRR networking
mode for the public network, establish an MP-BGP neighbor between PEs and an MPLS
LDP neighbor between the public networks.
Figure 1-21 Establishing an LDP FRR
1-42
SJ-20140731105308-012|2014-10-20 (R1.0)
Configuration Flow
1.
2.
3.
4.
Configure an IGP route between the PE1 router and the PE2 router for communication.
Configure the MP-BGP neighbor.
Configure the LDP neighbor.
Enable the FRR on the PE1 router.
Access the CE1 router through the OSPF protocol, the CE2 router through the IS-IS
protocol and the middle IPG router through the IS-IS protocol. The configuration is as
follows:
The configuration of the CE1 router is as follows:
CE1(config)#interface gei-0/2/1/1
CE1(config-if-gei-0/2/1/1)#no shutdown
CE1(config-if-gei-0/2/1/1)#ip address 40.0.0.2 255.255.255.0
CE1(config-if-gei-0/2/1/1)#exit
CE1(config)#interface loopback1
CE1(config-if-loopback1)#ip address 12.1.2.1 255.255.255.255
CE1(config-if-loopback1)#exit
CE1(config)#router ospf 1
CE1(config-ospf-1)#router-id 12.1.2.1
CE1(config-ospf-1)#network 40.0.0.0 0.0.0.255 area 16
CE1(config-ospf-1)#network 12.1.2.1 0.0.0.0 area 16
CE1(config-ospf-1)#exit
The configuration of the CE2 router is as follows:

CE2(config)#interface gei-0/2/1/1
CE2(config-if-gei-0/2/1/1)#no shutdown
CE2(config-if-gei-0/2/1/1)#ip address 60.0.0.2 255.255.255.0
CE2(config-if-gei-0/2/1/1)#exit
CE2(config)#interface loopback1
CE2(config-if-loopback1)#ip address 12.1.2.5 255.255.255.255
CE2(config-if-loopback1)#exit
CE2(config)#router isis
CE2(config-isis-0)#area 10
CE2(config-isis-0)#system-id 0000.0000.0001
CE2(config-isis-0)#interface loopback1
CE2(config-isis-0-if-loopback1)#ip router isis
CE2(config-isis-0-if-loopback1)#exit
CE2(config-isis-0)#interface gei-0/2/1/1
CE2(config-isis-0-if-gei-0/2/1/1)#ip router isis
CE2(config-isis-0-if-gei-0/2/1/1)#exit
CE2(config-isis-0)#exit
1-43
SJ-20140731105308-012|2014-10-20 (R1.0)
The configuration of the PE1 router is as follows:

PE1(config)#ip vrf zte1
PE1(config-vrf-zte1)#rd 100:1
PE1(config-vrf-zte1)#route-target import 100:1
PE1(config-vrf-zte1)#route-target export 100:1
PE1(config-vrf-zte1)#address-family ipv4
PE1(config-vrf-zte1-af-ipv4)#exit
PE1(config-vrf-zte1)#exit
PE1(config)#interface loopback1
PE1(config-if-loopback1)#ip address 1.1.1.2 255.255.255.255
PE1(config-if-loopback1)#exit
PE1(config)#interface gei-0/2/1/1
PE1(config-if-gei-0/2/1/1)#no shutdown
PE1(config-if-gei-0/2/1/1)#ip vrf forwarding zte1
PE1(config-if-gei-0/2/1/1)#ip address 40.0.0.1 255.255.255.0
PE1(config-if-gei-0/2/1/1)#exit
PE1(config)#mpls ldp instance 1

PE1(config-ldp-1)#router-id loopback1
PE1(config-ldp-1)#interface gei-0/2/1/2
PE1(config-ldp-1-if-gei-0/2/1/2)#exit
PE1(config-ldp-1)#exit
PE1(config)#router bgp 100

PE1(config-bgp)#neighbor 1.1.1.3 remote-as 100
PE1(config-bgp)#neighbor 1.1.1.3 update-source loopback1
PE1(config-bgp)#address-family vpnv4
PE1(config-bgp-af-vpnv4)#neighbor 1.1.1.3 activate
PE1(config-bgp-af-vpnv4)#exit
PE1(config-bgp)#address-family ipv4 vrf zte1
PE1(config-bgp-af-ipv4-vrf)#redistribute ospf-int 1
PE1(config-bgp-af-ipv4-vrf)#exit
PE1(config-bgp)#exit
1-44
SJ-20140731105308-012|2014-10-20 (R1.0)
PE1(config)#router ospf 1 vrf zte1

PE1(config-ospf-1)#network 40.0.0.0 0.0.0.255 area 16
PE1(config-ospf-1)#exit
PE1(config)#router isis
PE1(config-isis-0)#area 10
PE1(config-isis-0)#system-id 0000.70d0.c200
PE1(config-isis-0)#interface gei-0/2/1/2
PE1(config-isis-0-if-gei-0/2/1/2)#ip router isis
PE1(config-isis-0-if-gei-0/2/1/2)#exit
PE1(config-isis-0-if-gei-0/2/1/3)#metric 20
PE1(config-isis-0)#fast-reroute enable
PE1(config-isis-0)#interface loopback1
PE1(config-isis-0-if-loopback1)#ip router isis
PE1(config-isis-0-if-loopback1)#exit
PE1(config-isis-0)#exit
The configuration of the PE2 router is as follows:

PE2(config)#ip vrf zte1
PE2(config-vrf-zte1)#rd 100:1
PE2(config-vrf-zte1)#route-target import 100:1
PE2(config-vrf-zte1)#route-target export 100:1
PE2(config-vrf-zte1)#address-family ipv4
PE2(config-vrf-zte1-af-ipv4)#exit
PE2(config-vrf-zte1)#exit
PE2(config-if-gei-0/2/1/1)#ip vrf forwarding zte1
1-45
SJ-20140731105308-012|2014-10-20 (R1.0)

PE2(config)#mpls ldp instance 1

PE2(config-ldp-1)#router-id loopback1
PE2(config-ldp-1)#exit
PE2(config)#router bgp 100

PE2(config-bgp)#neighbor 1.1.1.2 remote-as 100
PE2(config-bgp)#neighbor 1.1.1.2 update-source loopback1
PE2(config-bgp)#address-family ipv4 vrf zte1
PE2(config-bgp-af-ipv4-vrf)#redistribute isis-1-2
PE2(config-bgp-af-ipv4-vrf)#exit
PE2(config-bgp)#address-family vpnv4
PE2(config-bgp-af-vpnv4)#neighbor 1.1.1.2 activate
PE2(config-bgp-af-vpnv4)#exit
PE2(config-bgp)#exit
PE2(config)#router isis 1 vrf zte1

PE2(config-isis-1)#system-id 0000.0000.0002
PE2(config)#router isis
PE2(config-isis-0)#system-id 0000.dd00.0002
PE2(config-isis-0)#interface loopback1
PE2(config-isis-0-if-loopback1)#ip router isis
PE2(config-isis-0-if-loopback1)#exit
The configuration of the P1 router is as follows:

P1(config)#interface loopback1
1-46
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-if-loopback1)#ip address 1.1.1.4 255.255.255.255
P1(config-if-loopback1)#exit
P1(config)#interface gei-0/2/1/1
P1(config-if-gei-0/2/1/1)#no shutdown
P1(config-if-gei-0/2/1/1)#ip address 10.0.0.1 255.255.255.0
P1(config-if-gei-0/2/1/1)#exit
P1(config)#router isis
P1(config-isis-0)#area 10
P1(config-isis-0)#system-id 0000.dd00.1000
P1(config-isis-0)#interface gei-0/2/1/1
P1(config-isis-0-if-gei-0/2/1/1)#ip router isis
P1(config-isis-0-if-gei-0/2/1/1)#exit
P1(config-isis-0)#interface loopback1
P1(config-isis-0-if-loopback1)#ip router isis
P1(config-isis-0-if-loopback1)#exit
P1(config-isis-0)#exit
P1(config)#mpls ldp instance 1

P1(config-ldp-1)#router-id loopback1
P1(config-ldp-1)#interface gei-0/2/1/1
P1(config-ldp-1-if-gei-0/2/1/1)#exit
P1(config-ldp-1)#exit
The configuration of the P2 router is as follows:

1-47
SJ-20140731105308-012|2014-10-20 (R1.0)
P2(config)#router isis
P2(config-isis-0)#system-id 0000.dd00.3000
P2(config)#mpls ldp instance 1

P2(config-ldp-1)#router-id loopback1
P2(config-ldp-1)#exit
Show the configuration result to see whether the FRR configuration takes effect through
the show ip forwarding backup route command.
The FRR information on the PE1 through the IS-IS protocol is as follows:
PE1#show isis fast-reroute-topology
IS-IS ipfrr paths to Level-1 routers
System id Interface Ipfrr interface Ipfrr type metric
0000.dd00.0002 gei-0/2/1/2 gei-0/2/1/3 node 30
IS-IS ipfrr paths to Level-2 routers
System id Interface Ipfrr interface Ipfrr type metric
0000.dd00.0002 gei-0/2/1/2 gei-0/2/1/3 node 30
PE1#show ip forwarding backup route

IPv4 Backup Routing Table:
status codes: *valid, >best, M:Master, S:Slave
Dest
Gw
Interface
Owner
Pri
Metric M/S Status
1.1.1.3/32
10.0.0.2
gei-0/2/1/2
ISIS_LEVEL1
115
40
1.1.1.3/32
11.0.0.2
gei-0/2/1/3
ISIS_LEVEL1
115
40
Check the configuration result of the LDP FRR.

PE1(config)#show mpls ldp bindings 1.1.1.3 32 detail instance 1
1.1.1.3/32
1-48
SJ-20140731105308-012|2014-10-20 (R1.0)

local binding:
label: 16399
advertised to:
1.1.1.4:0
1.1.1.5:0

remote binding: lsr: 1.1.1.5:0, label: 16399(inuse_slv_ip)
PE1(config)#show mpls forwarding-table 1.1.1.3
Local
Outgoing
Prefix or
Outgoing
label
label
Tunnel Id
interface
Next Hop
M/S
16399
16394
1.1.1.3/32
gei-0/2/1/2
10.0.0.1
16399
16399
1.1.1.3/32
gei-0/2/1/3
11.0.0.1
Check the IBGP connection between the PE1 router and the PE2 router.
PE1#show ip bgp summary
Neighbor
Ver
1.1.1.3
As
100
MsgRcvd
195
MsgSend
201
Up/Down(s)
01:37:23
State
2
1.6.6 LDP Graceful Restart Configuration Instance

Configuration Description
As shown in Figure 1-22, three nodes R1, R2, and R3 in the network are main control
devices. These three nodes provide GR mechanism, and the communication among them
are implemented through OSPF . You need to establish a session among R1, R2, and R3.
When the main board of R2 is faulty, you need to synchronize the neighbor node thorough
the LP GR mechanism.
Figure 1-22 Network Architecture of LDP Graceful Restart Configuration Instance
Configuration Flow
1. Configure the IP address for each node, and the Loopback address for the LSR ID,
and notify the network segment and the LSR ID main route connected to each interface
and through the OSPF protocol.
2. Configure the OSPF GR function on reach node.
3. Configure MPLS LDP for each interface of the node, and then establish the LDP
neighbor.
4. Enable the LDP GR capability for each node.
1-49
SJ-20140731105308-012|2014-10-20 (R1.0)
Run the following commands on R1:
R1(config)#router ospf 2
R1(config-ospf-2)#router-id 10.10.10.1
R1(config-ospf-2)#network 106.15.15.0 0.0.0.255 area 0.0.0.0
R1(config-ospf-2)#nsf
R1(config-ospf-2)#exit

R1(config-ldp-1)#graceful-restart
R1(config-ldp-1)#end

1-50
SJ-20140731105308-012|2014-10-20 (R1.0)



Before the active/standby changeover on R2 or the LDP restart, check the transferring
table and binding information on R1, R2, and R3.
Run the following commands to check the information on R1:
R1#show mpls forwarding-table 10.10.10.2
Local
Outgoing
Prefix or
Outgoing
label
label
Tunnel Id
interface
16395
16388
10.10.10.2/32
gei-0/1/0/6
Next Hop
M/S
106.15.15.5
R1#show mpls ldp bindings 10.10.10.2 32 instance 1

10.10.10.2/32
1-51
SJ-20140731105308-012|2014-10-20 (R1.0)

local binding:
label: 16395
R1#show mpls ldp graceful-restart instance 1

LDP Graceful Restart is enabled
Neighbor Liveness Timer: 120 seconds
Max Recovery Timer: 120 seconds
Graceful Restart enabled Sessions:
Peer LDP Ident: 10.10.10.5:0,State:Oper
R1#show mpls ldp neighbor graceful-restart instance 1

TCP connection: 10.10.10.5.6739 - 10.10.10.1.646
Up Time: 00:02:21
gei-0/1/0/6; Src IP addr: 106.15.15.5
5.5.5.64
8.8.8.5
13.13.13.5
17.5.5.5
9.9.9.5
14.14.14.5
18.18.18.5
10.10.10.5
15.15.15.5
19.19.19.5
16.16.16.5
20.20.20.5
21.21.21.5
23.23.23.5
24.24.24.5
25.25.25.5
26.26.26.5
27.27.27.5
28.28.28.5
29.29.29.5
31.31.31.1
32.32.32.5
33.33.33.5
34.34.34.5
35.35.35.5
36.36.36.5
37.37.37.5
38.38.38.5
39.39.39.5
40.40.40.5
41.41.41.5
42.42.42.5
43.43.43.5
44.44.44.5
45.45.45.5
46.46.46.5
47.47.47.5
48.48.48.5
49.49.49.5
50.50.50.5
103.3.3.5
106.15.15.5
Graceful Restart enabled; Peer reconnect time (msecs): 120000


TCP connection: 10.10.10.1.646 - 10.10.10.5.6739
Up Time: 00:02:15
1-52
SJ-20140731105308-012|2014-10-20 (R1.0)

gei-0/1/0/6; Src IP addr: 106.15.15.1
1.1.1.64 10.10.10.1 106.15.15.1
TCP connection: 10.10.10.2.646 - 10.10.10.5.6738
Up Time: 00:02:15
gei-0/1/0/3; Src IP addr: 103.3.3.2
2.2.2.64
10.10.10.2
90.4.2.2
101.1.1.2
103.3.3.2


TCP connection: 10.10.10.5.6738 - 10.10.10.2.646
Up Time: 00:03:11
gei-0/1/0/3; Src IP addr: 103.3.3.5
5.5.5.64
8.8.8.5
13.13.13.5
17.5.5.5
9.9.9.5
14.14.14.5
18.18.18.5
10.10.10.5
15.15.15.5
19.19.19.5
16.16.16.5
20.20.20.5
21.21.21.5
23.23.23.5
24.24.24.5
25.25.25.5
26.26.26.5
27.27.27.5
28.28.28.5
29.29.29.5
31.31.31.1
32.32.32.5
33.33.33.5
34.34.34.5
35.35.35.5
36.36.36.5
37.37.37.5
38.38.38.5
39.39.39.5
40.40.40.5
41.41.41.5
42.42.42.5
43.43.43.5
44.44.44.5
45.45.45.5
46.46.46.5
48.48.48.5
49.49.49.5
50.50.50.5
47.47.47.5
103.3.3.5
106.15.15.5
1-53
SJ-20140731105308-012|2014-10-20 (R1.0)
When R2 acting as the Restarter party performs the active/standby changeover or restarts
the LDP protocol, and R1 acting as the Helper party perceives the operations of R2, R1
will restart the GR Reconnet timer. Before the GR Reconnect timer times out,the items of
the forwarding table related to the Restarter party will be saved.
If the LDP session between the Restarter party and the Helper party is established again
before the GR Reconnect timer of the Helper party times out, the Helper party will delete
the GR Reconnect timer, and restart the GR Recovery timer.
R1 MPU-0/20/0 2012-4-28 01:15:36 mpls_ldp_1:GR:
down nbr 10.10.10.5:0:: wait for reconnecting
R1 MPU-0/20/0 2012-4-28 01:15:36 mpls_ldp_1:GR: GR session 10.10.10.5:0: lost
R1 MPU-0/20/0 2012-4-28 01:15:36 mpls_ldp_1:GR: down neighbor 10.10.10.5:0::
reconnect timer started [120 secs]
R1 MPU-0/20/0 2012-4-28 01:15:36 mpls_ldp_1:GR: GR session 10.10.10.5:0::
bindings retained
R1 MPU-0/20/0 2012-4-28 01:15:56 mpls_ldp_1:GR: Received FT Sess TLV from
10.10.10.5:0 (rconn 120, rcov 120)
R1 MPU-0/20/0 2012-4-28 01:15:56 mpls_ldp_1:GR: Added FT Sess TLV
(Rconn 120000, Rcov 120000) to INIT msg to 10.10.10.5:0
established
R1 MPU-0/20/0 2012-4-28 01:15:59 mpls_ldp_1:GR: ptcl_adj: 10.10.10.5:0::
reconnect timer stopped
state change (Reconnect-Wait -> Recovering)
R1 MPU-0/20/0 2012-4-28 01:15:59 mpls_ldp_1:GR: ptcl_adj: 10.10.10.5:0::
recovery timer started,120 secs
R1 MPU-0/20/0 2012-4-28 01:15:59 mpls_ldp_1:GR: 10.10.10.1/-1::
refreshing stale binding from 10.10.10.5:0
R1 MPU-0/20/0 2012-4-28 01:15:59 mpls_ldp_1:GR: 10.10.10.2/-1::
R1 MPU-0/20/0 2012-4-28 01:15:59 mpls_ldp_1:GR: 10.10.10.5/-1::
Run the following commands to check the Graceful Restart instance on R1:
TCP connection: 10.10.10.5.6751 - 10.10.10.1.646
Up Time: 00:01:58
gei-0/1/0/6; Src IP addr: 106.15.15.5
5.5.5.64
8.8.8.5
13.13.13.5
9.9.9.5
14.14.14.5
10.10.10.5
15.15.15.5
16.16.16.5
1-54
SJ-20140731105308-012|2014-10-20 (R1.0)

17.5.5.5
18.18.18.5
19.19.19.5
20.20.20.5
21.21.21.5
23.23.23.5
24.24.24.5
25.25.25.5
26.26.26.5
27.27.27.5
28.28.28.5
29.29.29.5
31.31.31.1
32.32.32.5
33.33.33.5
34.34.34.5
35.35.35.5
36.36.36.5
37.37.37.5
38.38.38.5
39.39.39.5
40.40.40.5
41.41.41.5
42.42.42.5
43.43.43.5
44.44.44.5
45.45.45.5
46.46.46.5
47.47.47.5
48.48.48.5
49.49.49.5
50.50.50.5
103.3.3.5
106.15.15.5
Status: recovering (2 seconds left)
Run the following commands to check the LDP label on R1:

R1#show mpls forwarding-table 10.10.10.2
Local
Outgoing
Prefix or
Outgoing
label
label
Tunnel Id
interface
16395
16388
10.10.10.2/32
gei-0/1/0/6
Next Hop
M/S
106.15.15.5
The above output indicates that the LDP label of Graceful Restart is not changed.
Run the following commands to check the information of the LDP label on R1:
R1#show mpls ldp bindings detail instance 1
10.10.10.2/32
local binding:
label: 16395
advertised to:
10.10.10.5:0(deleting)
remote binding: lsr: 10.10.10.5:0, label: 16388(inuse)(stale)
10.10.10.5/32
local binding:
label: 16388
advertised to:
10.10.10.5:0(deleting)
remote binding: lsr: 10.10.10.5:0, label: exp-null(inuse)(stale)
The above output information indicates that the Helper party marks the forwarding table
related to GR Restarter with stale.
Before the GR Recovery timer of the Helper party times out, the Helper party associates
the Restarter party to restore the items of the forwarding table, and the Restarter party
also associates the Helper party to restore the items of the forwarding table.
TCP connection: 10.10.10.5.6751 - 10.10.10.1.646
Up Time: 00:01:59
gei-0/1/0/6; Src IP addr: 106.15.15.5
5.5.5.64
8.8.8.5
9.9.9.5
10.10.10.5
1-55
SJ-20140731105308-012|2014-10-20 (R1.0)

13.13.13.5
17.5.5.5
14.14.14.5
18.18.18.5
15.15.15.5
19.19.19.5
16.16.16.5
20.20.20.5
21.21.21.5
23.23.23.5
24.24.24.5
25.25.25.5
26.26.26.5
27.27.27.5
28.28.28.5
29.29.29.5
31.31.31.1
32.32.32.5
33.33.33.5
34.34.34.5
35.35.35.5
36.36.36.5
37.37.37.5
38.38.38.5
39.39.39.5
40.40.40.5
41.41.41.5
42.42.42.5
43.43.43.5
44.44.44.5
45.45.45.5
46.46.46.5
47.47.47.5
48.48.48.5
49.49.49.5
50.50.50.5
103.3.3.5
106.15.15.5
R1#show mpls ldp bindings 10.10.10.2 32 instance 1

10.10.10.2/32
local binding:
label: 16395
1.6.7 LSP Load-Sharing Configuration Example

Scenario Description
Figure 1-23 shows that OSPF is enabled between R1 and R2, and the load-sharing function
is enabled for OSPF routes.
Figure 1-23 LSP Load-Sharing Configuration Example
Configuration Flow
1. Enable the load-sharing function for the OSPF routes between R1 and R2.
2. Enable LDP on the interfaces between R1 and R2.
1-56
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-ospf-1)#network 1.1.1.1
0.0.0.0 area 0.0.0.0

R1(config-ospf-1)#maximum-paths 2


R2(config-if-loopback1)#ip address 1.1.1.2
255.255.255.255
0.0.0.0 area 0.0.0.0

R2(config-ospf-1)#maximum-paths 2
1-57
SJ-20140731105308-012|2014-10-20 (R1.0)


Run the show running-config ospfv2 command to check the OSPF configuration and
LDP configuration. The execution results are displayed as follows:
R1(config)#show running-config ospfv2
!<ospfv2>
router ospf 1
maximum-paths 2
network 1.1.1.1 0.0.0.0 area 0.0.0.0
network 104.110.111.0 0.0.0.255 area 0.0.0.0
network 104.115.116.0 0.0.0.255 area 0.0.0.0
router-id 1.1.1.1
$
!</ospfv2>
R1(config)#show running-config ldp

!<LDP>
mpls ldp instance 1
interface gei-0/1/1/5
$
$
router-id loopback1
$
!</LDP>
Run the following commands on R1 to check the statuses of the OSPF neighbor and LDP
neighbor. The execution results are displayed as follows:
R1(config)#show ip ospf neighbor
OSPF Router with ID (1.1.1.1) (Process ID 1)
Neighbor ID
Pri State
DeadTime
Address
Interface
1.1.1.2
00:00:36
104.110.111.2
gei-0/1/1/5
FULL/DR
R1(config)#show mpls ldp nei instance 1

1-58
SJ-20140731105308-012|2014-10-20 (R1.0)

TCP connection: 1.1.1.2.26100 - 1.1.1.1.646
Up Time: 01:04:43
gei-0/3/0/1; Src IP addr: 104.115.116.2
gei-0/1/1/5; Src IP addr: 104.110.111.2
1.1.1.2
104.115.116.2
104.110.111.2
Run the following command on R1 to check the load-sharing condition of IGP routes. The
execution results are displayed as follows:
R1(config)#show ip forwarding route 1.1.1.2
IPv4 Routing Table:
Headers: Dest: Destination,
Codes
Gw: Gateway,
Pri: Priority;
: BROADC: Broadcast, USER-I: User-ipaddr, USER-S: User-special,

MULTIC: Multicast, USER-N: User-network, DHCP-D: DHCP-DFT,
ASBR-V: ASBR-VPN, STAT-V: Static-VRF, DHCP-S: DHCP-static,
GW-FWD: PS-BUSI, NAT64: Stateless-NAT64, LDP-A: LDP-area,
GW-UE: PS-USER, P-VRF: Per-VRF-label, TE: RSVP-TE;
status codes: *valid, >best

Dest
Gw
Interface
Owner
Pri
Metric
*> 1.1.1.2/32
104.110.111.2
gei-0/1/1/5
ospf
110
*> 1.1.1.2/32
104.115.116.2
gei-0/3/0/1
ospf
110
Run the following commands on R1 to check entries in the LSP load-sharing table. The
execution results are displayed as follows:
R1(config)#show mpls forwarding-table
Local
Outgoing
Prefix or
Outgoing
label
label
Tunnel Id
interface
Next Hop
M/S
16384
Poptag
1.1.1.2/32
gei-0/1/1/5
104.110.111.2
16384
Poptag
1.1.1.2/32
gei-0/3/0/1
104.115.116.2
R1(config)#show mpls ldp binding instance 1

1.1.1.1/32
local binding:
label: imp-null

1.1.1.2/32
local binding:
label: 16384
remote binding: lsr: 1.1.1.2:0, label: imp-null(inuse:2)

12.1.1.0/24
local binding:
label: imp-null

17.1.1.0/24
local binding:
label: imp-null
104.110.111.0/24
1-59
SJ-20140731105308-012|2014-10-20 (R1.0)

local binding:
label: imp-null

104.115.116.0/24
local binding:
label: imp-null
1.6.8 LDP BFD Configuration Example

Figure 1-24 shows that a sample network topology. It is required to establish a neighbor
relationship between R1 and R2, and enable LDP BFD on the two routers.
Figure 1-24 LDP BFD Configuration Example
Configuration Flow
1. Configure an IGP route, and ensure that the loopback interfaces on R1 and R2 can
ping each other over the route.
2. Enable MPLS on the directly-connected interfaces of R1 and R2.
3. Configure the IP addresses of loopback interfaces to be LSR router-IDs.
4. Enable the LDP BFD function on R1 and R2.
R1(config)#router isis 1
1-60
SJ-20140731105308-012|2014-10-20 (R1.0)

/*Configures the LDP router-id and an LDP interface*/
R1(config-ldp-1)#bfd 1.1.1.35 32 interval 100 min-rx 20 multiplier 5


R2(config-ldp-1)#bfd 1.1.1.34 32 interval 100 min-rx 20 multiplier 5
1-61
SJ-20140731105308-012|2014-10-20 (R1.0)
Note:
In the above configuration, the goal of running the IS-IS protocol is to advertise the router-id
of each LSR (that is, the route to the loopback interface).
Because loopback interfaces are stable (unless you close interfaces manually), using
loopback interface addresses as the router-ids of LDP instances is helpful for the stability
of LDP operation.
Run the show mpls ldp neighbor detail instance 1 command on R2 to check whether
an LDP neighbor has been established. The execution results are displayed as follows:
TCP connection: 1.1.1.34.646 - 1.1.1.35.1069
Up Time: 00:00:30
gei-0/3/0/7; Src IP addr: 100.100.100.1
1.1.1.34 100.100.100.1
In the sample output, "state: Oper" indicates that the session status is Oper, which means
that the parameter negotiation is correct, and a neighbor relationship with R1 (1.1.1.34)
has been established.
Run the show bfd neighbor ldp brief command on R1 to check whether an LDP BFD
neighbor has been established. The execution results are displayed as follows:
R1(config)#show bfd neighbor ldp brief
PeerAddr
PrefixLen
1.1.1.35
32
LD
2050
RD
Hold
State
2050
60
UP
1-62
SJ-20140731105308-012|2014-10-20 (R1.0)

100.100.100.2
2049
2049
500
UP
R1(config)#show bfd neighbor ldp detail

---------------------------------------------------------------------------PeerAddr :1.1.1.35
Prefixlen:32
Local Discr:2050
Remote Discr:2050
State:UP
Holdown(ms):60
Vpnid:0
VRF Name:--
BFD Type:LDP[Active]
Instance Name:
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:0
MinTxInt:100
MinRxInt:20
Multiplier:5
Received MinTxInt:10
Received MinRxInt:10
Received Multiplier:3
Length:24
Min Echo Interval:0
Rx Count:6393
Rx Interval (ms) min/max/avg:2
/18
/10
Tx Count:1457
Tx Interval (ms) min/max/avg:79
/79
/79
Registered Protocols:LDP LSP

Uptime:0 day(s),0 hour(s),2 minute(s)
Control Plane Rcv Phy Interface Name:gei-0/2/0/7
============================================================================
---------------------------------------------------------------------------PeerAddr :100.100.100.2
Prefixlen:0
Local Discr:2049
Remote Discr:2049
State:UP
Holdown(ms):500
Vpnid:0
VRF Name:--
BFD Type:LDP[Passive]
Instance Name:
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:0
MinTxInt:10
MinRxInt:10
Multiplier:3
Length:24
Min Echo Interval:0
Rx Count:1983
/78
/39
Tx Count:8586
/18
/18
Registered Protocols:--Uptime:0 day(s),0 hour(s),2 minute(s)

1-63
SJ-20140731105308-012|2014-10-20 (R1.0)

============================================================================
1.6.9 Peer BFD Configuration Example

Figure 1-25 shows that an LDP neighbor relationship is established between R1 and R2.
It is required to enable the peer BFD function on the two routers.
Figure 1-25 PEER BFD Configuration Example
Configuration Flow
ping each other.
3. Configure the IP addresses of loopback interfaces to be LSR router-IDs.
4. Enable the PEER BFD function.
1-64
SJ-20140731105308-012|2014-10-20 (R1.0)

/*Configure the LDP router-id and an LDP interface*/
R1(config-ldp-1)#peer bfd remote-routerid 1.1.1.35
R1(config)#bfd
R1(config-bfd)#session 1 peer-bfd ipv4 1.1.1.34 1.1.1.35
R1(config-bfd)#exit


R2(config-ldp-1)#peer bfd remote-routerid 1.1.1.34
R2(config)#bfd
R2(config-bfd)#session 1 peer-bfd ipv4 1.1.1.35 1.1.1.34
R2(config-bfd)#exit
1-65
SJ-20140731105308-012|2014-10-20 (R1.0)
Note:
In the above configuration, the goal of running the IS-IS protocol is to advertise the router-id
of each LSR (that is, the route to the loopback interface).
Because loopback interfaces are stable (unless you close interfaces manually), using
loopback interface addresses as the router-ids of LDP instances is helpful for the stability
of LDP operation.
TCP connection: 1.1.1.34.646 - 1.1.1.35.1069
Up Time: 00:00:30
gei-0/3/0/7; Src IP addr: 100.100.100.1
1.1.1.34 100.100.100.1
LDP Peer BFD state up.
In the sample output, "state: Oper" indicates that the session status is Oper, which means
Run the show bfd neighbors ip brief command on R1 to check whether a PEER BFD
neighbor has been established. The execution results are displayed as follows:
R1(config-ldp-1)#show bfd neighbors ip brief
LocalAddr
PeerAddr
LD
RD
Hold
State
1.1.1.34
1.1.1.35
2087
2085
150
UP
Interface
--
1-66
SJ-20140731105308-012|2014-10-20 (R1.0)
R1(config-ldp-1)#show bfd neighbors ip detail

---------------------------------------------------------------------------LocalAddr:1.1.1.34
PeerAddr :1.1.1.35
Local Discr:2087
Remote Discr:2085
Holdown(ms):150
Interface:---
Vpnid:0
VRF Name:---
State:UP
BFD Type:MultiHop
Instance Name:1
---------------------------------------------------------------------------Version:1
Dest UDP Port:4784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:0
MinTxInt:50
MinRxInt:50
Multiplier:3
Length:24
Min Echo Interval:0
Min BFD Length:24
Max BFD Length:24
Rx Count:8746
/49
/24
Tx Count:9124
/46
/46
Registered Protocols:LDPINSTANCE
============================================================================
1.6.10 GTSM Configuration Example

Figure 1-26 shows a sample network topology for the GTSM configuration.
l
In the GTSM-based non-directly-connected session configuration, it is required to set

the hop count of the session to 1 on R2. This can prevent a target session being
established between R2 and R3.
In the GTSM-based directly-connected session configuration, it is required to
respectively configure a GTSM-based directly-connected session on R1 and R2 to
negotiate the session between the two ends.
1-67
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 1-26 GTSM Configuration Example
Configuration Flow
1.
2.
3.
4.
5.
6.
Establish a directly-connected session between R1 and R2.

Establish a directly-connected session between R1 and R3.
Establish a target session between R2 and R3.
On R2, set the hop count for the GTSM-based non-directly-connected session to 1.
On R2, configure a GTSM-based directly-connected session with R1.
On R1, configure a GTSM-based directly-connected session with R2.
1-68
SJ-20140731105308-012|2014-10-20 (R1.0)

/*Run the following command to configure a GTSM-based directly-connected session: */

R1(config-ldp-1-if-gei-0/2/0/7)#gtsm


R2(config-ldp)#interface gei-0/3/0/7
/*Run the following command to configure a GTSM-based directly-connected session: */

R2(config-ldp-1-if-gei-0/3/0/7)#gtsm
/*After the target session between R2 and R3 goes up,*/

/*set the GTSM hop count to 1, and configure the neighbor*/
/*address to the router-id of R3*/
R2(config-ldp-1)#gtsm target-neighbor 1.1.1.39 hop-count 1
1-69
SJ-20140731105308-012|2014-10-20 (R1.0)


Run the show mpls ldp neighbor command on R2 to check whether a neighbor has been
established (performed after the GTSM configuration and before the session times out):
TCP connection: 1.1.1.39.1072 - 1.1.1.39.646
Up Time: 00:00:02
Targeted Hello (1.1.1.39); Src IP addr: 1.1.1.39
1.1.1.39 100.100.100.2 200.200.200.2
LDP neighbor may be up to 1 hops away
Because the hop count for the GTSM-based non-directly-connected session is set to 1,
and the hop count between R2 and R3 is 2, R2 cannot received the packets from R3,
1-70
SJ-20140731105308-012|2014-10-20 (R1.0)
which causes the session to go down. After the GTSM configuration is deleted, the session
comes up again.
Run the show mpls ldp neighbor command on R1 to check whether a neighbor has been
established.
TCP connection: 1.1.1.35.646 - 1.1.1.34.1072
Up Time: 00:00:02
gei-0/2/0/7; Src IP addr: 100.100.100.2
1.1.1.35 100.100.100.2
LDP neighbor may be up to 1 hops away
It can be seen that the negotiation for the GTSM-based directly-connected session
between R1 and R2 is successful.
1.6.11 LDP IGP Synchronization Configuration Example (OSPF)

Figure 1-27 shows a sample network topology. It is required to enable LDP IGP
synchronization on the two OSPF interfaces of R1.
Figure 1-27 LDP IGP Synchronization Configuration Example (OSPF)
Configuration Flow
1. Establish a directly-connected session between R1 and R2.
2. Configure an OSPF instance on R1, and enable LDP IGP synchronization for the
OSPF instance.
3. On R1, set the timeout of the delay timer for LDP IGP synchronization to 10 seconds.
1-71
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-ospf-1)#mpls ldp sync

R1(config-ldp-1)#igp sync delay 10


1-72
SJ-20140731105308-012|2014-10-20 (R1.0)
Run the show mpls ldp neighbor command to check whether a neighbor has been
established. The execution results are displayed as follows:
TCP connection: 121.121.121.121.26459 - 111.111.111.111.646
Up Time: 00:29:46
gei-0/1/0/3; Src IP addr: 20.20.20.200
gei-0/1/0/4; Src IP addr: 40.40.40.200
20.20.20.200 40.40.40.200 121.121.121.121
It can be seen that the session is maintained by sending hello messages from the two
interfaces.
Run the show mpls ldp igp sync ins 1 command on R1 to check the information and status
of LDP IGP synchronization.
gei-0/1/0/3:
LDP configured; LDP-IGP Synchronization enabled.
Sync status: Ready
Peers:
121.121.121.121:0 (Fully Operational)
gei-0/1/0/4:
Sync status: Ready
Peers:
Run the show ip ospf interface command on R1 to check the information and status of LDP
IGP synchronization for OSPF interfaces.
gei-0/1/0/4 is up
Track State is unknown
Internet Address 40.40.40.100 255.255.255.0 enable
Up for 01:00:28
In the area 0.0.0.0 DR
Cost 1, Priority 1, Network Type broadcast
Transmit Delay(sec) 1, Authentication Type null
TTL security disabled
LDP sync enabled
LDP sync state achieved
Sending max metric
1-73
SJ-20140731105308-012|2014-10-20 (R1.0)

Timer intervals(sec) : Hello 10, Dead 40, Retransmit 5
Designated Router (ID) 20.20.20.100, Interface address 40.40.40.100
Backup Designated router (ID) 22.22.22.22, Interface address 40.40.40.200
Number of Neighbors 1, Number of Adjacent neighbors 1
22.22.22.22 BDR
Run the shutdown command on the gei-0/1/0/4 interface of R2, and check the status of
OSPF IGP synchronization and metric of the OSPF route.
of LDP IGP synchronization. It can be seen that the status of LDP IGP synchronization for
the gei-0/1/0/4 interface changes to Not ready.
gei-0/1/0/3:
Sync status: Ready
Peers:
gei-0/1/0/4:
Sync status: Not ready
Peers:
Run the show ip ospf interface command on R1 to check the information and status of LDP
IGP synchronization for the OSPF interfaces. It can be seen that the status of LDP IGP
synchronization for the gei-0/1/0/4 interface is not achieved.
gei-0/1/0/4 is up
Track State is unknown
Internet Address 40.40.40.100 255.255.255.0 enable
Up for 01:37:22
In the area 0.0.0.0 DR
Cost 1, Priority 1, Network Type broadcast
Transmit Delay(sec) 1, Authentication Type null
TTL security disabled
LDP sync enabled
LDP sync state unachieved
Sending max metric
Timer intervals(sec) : Hello 10, Dead 40, Retransmit 5
Designated Router (ID) 20.20.20.100, Interface address 40.40.40.100
Backup Designated router (ID) 22.22.22.22, Interface address 40.40.40.200
Number of Neighbors 1, Number of Adjacent neighbors 1
22.22.22.22 BDR
1-74
SJ-20140731105308-012|2014-10-20 (R1.0)
1.6.12 LDP IGP Synchronization Configuration Example (IS-IS)

Figure 1-28 shows a sample network topology.
synchronization on the two IS-IS interfaces of R1.
It is required to enable LDP IGP
Figure 1-28 LDP IGP Synchronization Configuration Example (IS-IS)
Configuration Flow
1. Establish a directly-connected session between R1 and R2.
2. Configure an IS-IS instance on R1, and enable LDP IGP synchronization for the IS-IS
instance.
3. On R1, set the timeout of the delay timer for LDP IGP synchronization to 10 seconds.
R1(config-if-gei-0/1/0/3)# ip address 20.20.20.100 255.255.255.0
R1(config-if-gei-0/1/0/3)# no shutdown
R1(config-isis-0)#mpls ldp sync
1-75
SJ-20140731105308-012|2014-10-20 (R1.0)


R1(config-ldp-1)#igp sync delay 10


1-76
SJ-20140731105308-012|2014-10-20 (R1.0)
Run the show mpls ldp neighbor command to check whether a neighbor has been
established. The execution results are displayed as follows:
TCP connection: 121.121.121.121.26469 - 111.111.111.111.646
Up Time: 00:14:03
gei-0/1/0/3; Src IP addr: 20.20.20.200
gei-0/1/0/4; Src IP addr: 40.40.40.200
20.20.20.200 40.40.40.200 121.121.121.121
It can be seen that the session is maintained by sending hello messages from the two
interfaces.
of LDP IGP synchronization.
gei-0/1/0/3:
Sync status: Ready
Peers:
gei-0/1/0/4:
Sync status: Ready
Peers:
Run the show isis circuits detail command to check the information and status of LDP IGP
synchronization for the IS-IS interfaces of R1. It can be seen that the status has changed
to "Achieved".
ZXR10(config-isis-0)#show isis circuits detail
Process ID: 0
Interface:gei-0/1/0/3
Status:Up
Track Status:Unknown
Encapsulation:SAP
Circuit Type:Level-1-2
MPLS LDP Sync(L1/L2): Enable/Enable, Sync Status(L1/L2): Achieved/Achieved
Level-1 Metric:10 Priority:64 LAN ID:no found
Number of active adjacencies:0
Next hello in seconds:3
Level-2 Metric:10 Priority:64 LAN ID:ZXR10.02
1-77
SJ-20140731105308-012|2014-10-20 (R1.0)

Status:Up
Encapsulation:SAP
Interface:loopback11
Status:Up
Encapsulation:SAP
MPLS LDP Sync(L1/L2): Enable/Enable, Sync Status(L1/L2): Unknown/Unknown
Level-1 Metric:10 Level-2 Metric:10 Circuit ID:ZXR10.00
Active Adj state:No adjacency
Run the shutdown command on the gei-0/1/0/4 interface of R2, and check the status of
IS-IS IGP synchronization and the metric of the IS-IS route.
of LDP IGP synchronization. It can be seen that the status of LDP IGP synchronization for
the gei-0/1/0/4 interface changes to "Not ready".
gei-0/1/0/3:
Sync status: Ready
Peers:
gei-0/1/0/4:
Sync status: Not ready
Peers:
Run the show isis circuits detail command on R1 to check the information and status of
LDP IGP synchronization for the IS-IS interfaces of R1. It can be seen that the status of
LDP IGP synchronization for the gei-0/1/0/4 interface is "unachieved".
1-78
SJ-20140731105308-012|2014-10-20 (R1.0)

Process ID: 0
Status:Up
Encapsulation:SAP
Status:Up
Encapsulation:SAP
MPLS LDP Sync(L1/L2): Enable/Enable, Sync Status(L1/L2): UnAchieved/UnAchieved
Interface:loopback11
Status:Up
Encapsulation:SAP
MPLS LDP Sync(L1/L2): Enable/Enable, Sync Status(L1/L2): Unknown/Unknown
Level-1 Metric:10 Level-2 Metric:10 Circuit ID:ZXR10.00
Active Adj state:No adjacency
1.6.13 Instance with LDPIGP Synchronization Integrated with FRR

Configure LDPIGP synchronization and the FRR on R1 and LDPIGP synchronization on
R2.You can check the LDPIGP synchronization and FRR operation result on R1 through
a serieas of operations.
1-79
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 1-29 Network Diagram for LDPIGP Synchronization Integrated with FRR
Configuration Flow
1. Configure the IS-IS routing protocol on R1 and enable the FRR and LDPIGP
synchronization function.
2. Configure the MPLS LDP protocol on R1.
3. Configure the IS-IS routing protocol on R2 and enable the LDPIGP synchronization
function.
4. Configure the MPLS LDP protocol on R2.
R1(config)#interface xgei-0/2/0/3
R1(config-if-xgei-0/2/0/3)#ip address 103.2.0.73 255.255.255.0
R1(config-if-xgei-0/2/0/3)#exit
R1(config-isis-0)#interface xgei-0/2/0/3
R1(config-isis-0-if-xgei-0/2/0/3)#ip router isis
R1(config-isis-0-if-xgei-0/2/0/3)#metric 30
R1(config-isis-0-if-xgei-0/2/0/3)#exit
R1(config-isis-0-if-xgei-0/2/0/4)#metric 20
R1(config-isis-0)#fast-reroute enable

R1(config-ldp-1)#interface xgei-0/2/0/3
1-80
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-ldp-1-if-xgei-0/2/0/3)#exit

R2(config-if-xgei-0/2/0/17)# ip address 104.2.0.72 255.255.255.0

1. Run the show ip forwarding backup route command to check the LDP FRR table items
on R1. The execution result is displayed as follows:
R1#show ip forwarding backup route
IPv4 Routing Table:
Gw: Gateway,
Pri: Priority,
M/S: Master/Slave,
Sta: Status;
Codes

1-81
SJ-20140731105308-012|2014-10-20 (R1.0)

Status codes: *valid, >best, M: Master, S: Slave, I: Inuse, U: Unuse;
Dest
Gw
Interface
Owner
*> 3.72.3.72/32
104.2.0.72
xgei-0/2/0/4
ISIS-L1 115 30
3.72.3.72/32
103.2.0.72
xgei-0/2/0/3
ISIS-L1 115 40
*> 110.1.3.0/24
104.2.0.72
xgei-0/2/0/4
ISIS-L2 115 20
103.2.0.72
xgei-0/2/0/3
ISIS-L2 115 30
*> 149.0.72.0/24
104.2.0.72
xgei-0/2/0/4
ISIS-L2 115 20
103.2.0.72
xgei-0/2/0/3
ISIS-L2 115 30
110.1.3.0/24
149.0.72.0/24
Pri Metric M/S Sta
2. After the active link interface xgei-0/2/0/4 is shutdown on R1, run the show ip forwardi
ng backup route command to check the LDP FRR table items. The execution result is
displayed as follows:
R1#show ip forwarding backup route
IPv4 Routing Table:
Gw: Gateway,
Pri: Priority,
M/S: Master/Slave,
Sta: Status;
Codes


Dest
Gw
Interface
Owner
Pri Metric M/S Sta
This item is null.

3. After the no shutdown command is performed on the active link interface xgei-0/2/0/4
on R1, the active link is restored but the LDP concentration is not completed, set the
IGP metric to the maximum number. The execution result is displayed as follows:
R1#show isis circuits detail
Process ID: 0
Interface:xgei-0/2/0/3
Status:Up
Encapsulation:SAP
ISIS MTU:1583
Level-1
Metric:30
Priority:64
LAN ID:3.73.02

Level-2
Metric:30
Priority:64
LAN ID:3.73.02
1-82
SJ-20140731105308-012|2014-10-20 (R1.0)
Status:Up
Encapsulation:SAP
ISIS MTU:1583
MPLS LDP Sync(L1/L2): Enable/Enable, Sync Status(L1/L2): UnAchieved/UnAchieved
Level-1
Metric:16777214
Priority:64
LAN ID:3.73.04

Level-2
Metric:16777214
Priority:64
LAN ID:3.73.04
4. Run the show isis topology command to check the route topology on R1. The execution
result is displayed as follows:
R1(config)#show isis topology
Process ID: 0
IS-IS paths to Level-1 routers
System id
Metric
Next-Hop
Interface
SNPA
R2
30
R2
xgei-0/2/0/3
00D0.0372.1000
R1
--
R3
60
R2
xgei-0/2/0/3
00D0.0372.1000

System id
Metric
Next-Hop
Interface
SNPA
R2
30
R2
xgei-0/2/0/3
00D0.0372.1000
R1
--
R3
60
R2
xgei-0/2/0/3
00D0.0372.1000
5. After the LDP concentration is completed, the IGP metric on R1 becomes a normal
value, when concentration of LDP and IGP is completed. The execution result is
R1#show isis circuits detail
Process ID: 0
Status:Up
Encapsulation:SAP
ISIS MTU:1583
Level-1
Metric:30
Priority:64
LAN ID:3.73.02

Level-2
Metric:30
Priority:64
LAN ID:3.73.02
1-83
SJ-20140731105308-012|2014-10-20 (R1.0)

Status:Up
Encapsulation:SAP
ISIS MTU:1583
Level-1
Metric:20
Priority:64
LAN ID:3.73.04

Level-2
Metric:20
Priority:64
LAN ID:3.73.04
6. Run the show isis topology command on R1 to check the route topology. The execution
result is displayed as follows:
R1#show isis topology
Process ID: 0
System id
Metric
Next-Hop
Interface
SNPA
R2
20
R2
xgei-0/2/0/4
00D0.0372.1000
R1
--
R3
50
R2
xgei-0/2/0/4
00D0.0372.1000

System id
Metric
Next-Hop
Interface
SNPA
R2
20
R2
xgei-0/2/0/4
00D0.0372.1000
R1
--
R3
50
R2
xgei-0/2/0/4
00D0.0372.1000
7. Run the show ip forwarding backup route command to check the route forwarding table
on R1. The execution result is displayed as follows:
R1(config)#show ip forwarding backup route
IPv4 Routing Table:
Gw: Gateway,
Pri: Priority,
M/S: Master/Slave,
Sta: Status;
Codes


Dest
Gw
Interface
Owner
Pri Metric M/S Sta
*> 3.72.3.72/32
104.2.0.72
xgei-0/2/0/4
ISIS-L1 115 30
3.72.3.72/32
103.2.0.72
xgei-0/2/0/3
ISIS-L1 115 40
*> 110.1.3.0/24
104.2.0.72
xgei-0/2/0/4
ISIS-L2 115 20
1-84
SJ-20140731105308-012|2014-10-20 (R1.0)
110.1.3.0/24
103.2.0.72
xgei-0/2/0/3
ISIS-L2 115 30
*> 149.0.72.0/24
104.2.0.72
xgei-0/2/0/4
ISIS-L2 115 20
103.2.0.72
xgei-0/2/0/3
ISIS-L2 115 30
149.0.72.0/24
1.6.14 Packet Filtration Configuration Example

Figure 1-30 shows a sample network topology. It is required to establish an LDP neighbor
between R1 and R2 and enable packet filtration on R1.
Figure 1-30 Packet Filtration Configuration Example
Configuration Flow
ping each other.
3. Set the IP addresses of loopback interfaces to LSR router-IDs.
4. Configure an ACL on R1.
5. Enable packet filtration on R1.
1-85
SJ-20140731105308-012|2014-10-20 (R1.0)


/*Run the following commands to configure the LDP router-id and an LDP interface*/
R1(config)#ipv4-access-list 1
R1(config-ipv4-acl)#rule 1 deny tcp 1.1.1.35 0.0.0.0 any
R1(config-ipv4-acl)#rule 2 deny udp 100.100.100.2 0.0.0.0 any

R1(config-ldp-1)#filter packet for 1


1-86
SJ-20140731105308-012|2014-10-20 (R1.0)

l
l
Note:
In the above configuration, the goal of running the IS-IS protocol is to advertise the
router-id of each LSR (that is, the route to the loopback interface).
Through the ACL rule, packet filtration can take effect for UDP or TCP packets only.
TCP connection: 1.1.1.34.646 - 1.1.1.35.1069
State: Sent; Msgs sent/rcvd: 1/0; Downstream
Up Time: 00:00:30
gei-0/3/0/7; Src IP addr: 100.100.100.1
LDP dynamic capability disable:
In the sample output information, state: Sent indicates that the session status is Sent.
This means that, although the local end initiates a TCP connection and the connection has
been established, the session still cannot enter the Oper status because packet filtration
is enabled on the peer end (R1).
an LDP neighbor has been established.
It can be seen that no output information is returned. This means that the local end discards
the received UDP and TCP packets that meet filtration conditions.
1-87
SJ-20140731105308-012|2014-10-20 (R1.0)
1.6.15 Label-Distribution Configuration Example

relationship between R1 and R2, and enable the label-distribution DoD function on the
directly-connected interfaces of R1 and R2.
Figure 1-31 Label-Distribution Configuration Example
Configuration Flow
1. Configure an IGP route, and ensure that the loopback interfaces of R1 and R2 can
ping each other.
3. Enable label-distribution DoD on the directly-connected interfaces of R1 and R2.
4. Reset the MPLS LDP instances operating on R1 and R2.
1-88
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-ldp-1-if-gei-0/2/0/7)#label-distribution dod
R1(config)#reset mpls ldp instance 1


TCP connection: 1.1.1.34.646 - 1.1.1.35.1069
state: Oper; Msgs sent/rcvd: 47/48; Downstream on Demand
1-89
SJ-20140731105308-012|2014-10-20 (R1.0)

Up Time: 00:00:30
gei-0/3/0/7; Src IP addr: 100.100.100.1
1.1.1.34 100.100.100.1
In the sample output, state: Oper indicates that the session status is Oper, which means
1.6.16 Label-Retention Configuration Example

relationship between R1 and R2, and enable the label-retention conservation function in
the LDP configuration mode of R2.
Figure 1-32 Label-Retention Configuration Example
Configuration Flow
ping each other.
3. Enable the label-retention conservative function on the MPLS instances operating on
R1 and R2.
4. Reset the MPLS instances.
1-90
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-ldp-1)#label-retention conservative

1-91
SJ-20140731105308-012|2014-10-20 (R1.0)


R1(config-ldp-1)#label-retention conservative
R2#debug ldp session io instance 1
R2#terminal monitor
Run the show mpls ldp bindings detail instance 1 command on R2 to check the label
status. The execution results are displayed as follows:
R2(config)#show mpls ldp bindings detail instance 1
1.1.1.34/32
local binding: label: 16384
1.1.1.35/32
local binding: label: imp-null
advertised to:
1.1.1.34:0
In the sample output, the next-hop of the route corresponding to FEC 1.1.1.34 is R1, and
therefore the label advertised by R1 should be stored. However, the IP address 1.1.1.35
is the last hop, and therefore the label advertised by R1 is not stored.
Run the debug command on R2, and the out label information corresponding to the FEC
is displayed:
mpls_ldp_1: Rcvd mapping msg from 1.1.1.34:0
baseMsg: uBit = 0; msgType = 0x400; msgLength = 24; msgId = 0x5
fecTlv:
uBit = 0; fBit = 0; type = 0x100; length = 8
with 1 FEC elements:
1: type = 2, addFam = 0x1, preLen = 32, address = 0x1010123
genLblTlv:
label = 16385
Sent release msg to 1.1.1.34:0 with socket-id(0x00002ae7cf01ad10)
baseMsg: uBit = 0; msgType = 0x403; msgLength = 24; msgId = 0x6
1-92
SJ-20140731105308-012|2014-10-20 (R1.0)

fecTlv:
with 1 FEC elements:
1: type = 2, addFam = 0x1, preLen = 32, address = 0x1010123
genLblTlv:
label = 16385
It can be seen that R2 has received the label mapping information related to FEC 1.1.1.35
from R1. Because the label-retention mode configured on R2 is "conservative", R2 returns
a label release message.
1.6.17 Label-Advertise Configuration Example

relationship between R1 and R2, and enable the label-advertise function in the LDP
configuration mode of R2.
Figure 1-33 Label-Advertise Configuration Example
Configuration Flow
ping each other.
3. Configure an ACL rule on R2 to deny all packets.
4. Configure an ACL rule on R2 to permit all packets.
5. Configure label-advertise for non for the MPLS LDP instance operating on R2.
6. Configure label-advertise for all to non for the MPLS LDP instance operating on R2.
1-93
SJ-20140731105308-012|2014-10-20 (R1.0)
Note:
Steps 5 and 6 are optional. In Step 5, the filtration of packets and whether a label
is advertised to the neighbor are based on the FEC prefix. In Step 6, the filtration of
packets and whether a label is advertised to the neighbor are based on the FEC prefix
and neighbor.
If one of the filtration conditions in the prefixed ACL is matched, only the later
configuration takes effect. For example, if label-advertise for all and label-advertise
for all to non commands are sequentially executed, only the label-advertise for all
to non command takes effect.
If none of the filtration conditions in the prefix ACL is matched, multiple label
advertisement combination policies can be configured in the system. For example,
the configurations in Steps 5 and 6 can be used as a combination policy and take
effect on R2.
The two commands should be used with the label-advertise disable command.

1-94
SJ-20140731105308-012|2014-10-20 (R1.0)

R2(config)#ipv4-access-list non
R2(config-ipv4-acl)#rule 1 deny any
R2(config)#ipv4-access-list all

/*Run the following commands to enable label-advertise for non*/

R2(config-ldp-1)#label-advertise for non
R2(config-ldp-1)#label-advertise disable
/*Run the following commands to enable label-advertise for all to non*/

R2(config-ldp-1)#label-advertise for all to non
R2(config-ldp-1)#label-advertise disable
1-95
SJ-20140731105308-012|2014-10-20 (R1.0)
1.1.1.34/32
1.1.1.35/32
100.100.100.0/24
It can be seen that, on R2, the advertised to: item is not found, meaning that all FECs
have no label advertisement information.
It can be seen that, on R1, all FECs do not receive the remote binding information from
R2, meaning that R2 does not send any label.
1.1.1.34/32
advertised to:
1.1.1.35:0
1.1.1.35/32
100.100.100.0/24
1.6.18 Label-Request Configuration Example

relationship between R1 and R2, and enable the label-request function in the LDP
configuration mode of R2.
Figure 1-34 Label-Request Configuration Example
1-96
SJ-20140731105308-012|2014-10-20 (R1.0)
Configuration Flow
ping each other.
3. Set the negotiation mode of the session between the directly-connected interfaces of
R1 and R2 to "DoD".
4. Configure an ACL rule on R2 to deny all packets.
5. Configure label-advertise for non for the MPLS LDP instance operating on R2.
Note:
When the session operates in DoD mode, if the label-request command is executed, all of
the valid next-hops of FECs send label request messages by default. One of the filtration
conditions in the ACL needs to be matched only when the label-request command is
executed. If no match is found, label request messages are not sent.

1-97
SJ-20140731105308-012|2014-10-20 (R1.0)


R2(config)#ipv4-access-list non
R2(config-ipv4-acl)#rule 1 deny any

R2(config-ldp-1)#label-request for non
1.1.1.34/32
1.1.1.35/32
1-98
SJ-20140731105308-012|2014-10-20 (R1.0)

advertised to:
1.1.1.34:0
100.100.100.0/24
It can be seen that, on R2, the valid next-hop of the IP address 1.1.1.34 is R1. Normally
in DoD mode, after R2 sends a label request message to R1, the remote binding item
is generated. But the action defined in the ACL rule for the label request messages that
meet the filtration conditions is "Deny", a label cannot be bound to FEC 1.1.1.34.
1.1.1.34/32
1.6.19 LSP-Control Configuration Example

Figure 1-35 shows a sample network topology. It is required to establish LDP neighbor
relationships between R1, R2, and R3, and enable the lsp-control ordered function in the
LDP instance configuration mode of R1.
Figure 1-35 LSP-Control Configuration Example
Configuration Flow
ping each other.
2. Enable MPLS on the directly-connected interfaces of R1, R2, and R3.
3. Enable the lsp-control ordered function on R1.
4. Run the label-advertise disable command for the MPLS LDP instance operating on
R3.
5. Run the no label-advertise disable command for the MPLS LDP instance operating on
R3.
1-99
SJ-20140731105308-012|2014-10-20 (R1.0)
Note:
The ordered mode of label advertisement cannot be easily observed. The goal of Step 4 is
to disable the downstream to assign a label temporarily. This can compare the difference
between the labels assigned to FEC 1.1.1.36 by R1 and R2 after the downstream
advertises a label in Step 5.

R1(config-ldp-1)#lsp-control ordered
1-100
SJ-20140731105308-012|2014-10-20 (R1.0)




1-101
SJ-20140731105308-012|2014-10-20 (R1.0)


/*Run the following command to disable label advertisement*/

R3(config-ldp-1)# label-advertise disable
/*Run the following command to disable label advertisementt*/

R3(config-ldp-1)# label-advertise disable
l
Check the execution result of Step 4 on R3.

Run the show mpls ldp bindings 1.1.1.36 32 detail instance 1 command on R1 to
check the label status. The execution results are displayed as follows:
R1(config)#show mpls ldp bindings 1.1.1.36 32 detail instance 1
1.1.1.36/32
On R1, it can be seen that the remote binding item is set to UnTag in the label
information advertised by the valid next-hop of FEC 1.1.1.36. This means that the
neighbor (1.1.1.36) does not advertise any label. Because the LSP generation mode
of R1 is "Ordered", the advertised to: item cannot be seen in the label advertisement
information.
1.1.1.36/32
The same output information can be seen on R2, except that R1 does not advertise
a label bound to FEC 1.1.1.36.
l
On R3, the execution results of Step 5 are as follows:

1.1.1.36/32
1-102
SJ-20140731105308-012|2014-10-20 (R1.0)

advertised to:
1.1.1.35:0 1.1.1.36:0
On R1, it can be seen that the valid hop (R3) of FEC 1.1.1.36 sends a valid label, and
R1 advertises labels to R2 and R3.
1.1.1.36/32
advertised to:
1.1.1.34:0
remote binding: lsr: 1.1.1.34:0, label: 16384 (inuse)
Upon receipt of a label from the downstream, R2 advertises a label to the upstream.
1.6.20 Longest-Match Configuration Example

Figure 1-36 shows a sample network topology. It is required to establish LDP neighbor
relationships between R1, R2, and R3, and enable the longest-match function in the LDP
instance configuration mode of R1.
Figure 1-36 Longest-Match Configuration Example
Configuration Flow
ping each other.
2. Enable MPLS on the directly-connected interfaces of R1, R2, and R3.
3. Establish a DoD-mode session between R1 and R2, and establish a DU-mode session
between R1 and R3.
4. Configure an ACL on R1 to permit the routes on the 1.2.0.0/16 network segment.
5. Configure the longest-match mode on R1.
6. On R1, set the next-hop of the static aggregated route (1.2.0.0/16) to R3.
7. On R2, set the next-hop of the static route (1.2.3.4/32) to R1.
8. On R3, set the next-hop of the static route (1.2.3.4/32) to R3.
1-103
SJ-20140731105308-012|2014-10-20 (R1.0)
9. Configure the static LDP on R1, and assign a static in label (100) to the static route
(1.2.3.4/32).
Note:
Steps 7, 8 or 9 can be used to create the longest matching LSP on R1 based on FEC
1.2.3.4/32. The matching result is the same as that based on FEC (1.2.0.0/16).
R1(config)#ip route 1.2.0.0 255.255.0.0 200.200.200.3
R1(config)#ipv4-access-list acl12
R1(config-ipv4-acl)#rule 1 permit 1.2.0.0 0.0.255.255

1-104
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-ldp-1)#longest-match ipv4 for acl12



1-105
SJ-20140731105308-012|2014-10-20 (R1.0)


/*Run the following command to set the next-hop of the static route 1.2.3.4/32 to R2*/
R2(config)#ip route 1.2.3.4 255.255.0.0 100.100.100.1
/*Run the following command to set the next-hop of the static route 1.2.3.4/32 to R3*/
R3(config)#ip route 1.2.3.4 255.255.255.255 loopback1
/*Run the following command to configure the static LDP, and assign the static in
label (100) to the static route 1.2.3.4/32*/
R1(config)#mpls static-lsp sta
R1(config-static-lsp-sta)#bind ipv4 1.2.3.4 255.255.255.255
R1(config-if-loopback2)#insegment inlabel 100
l
Check the execution results of Step 7 on R2 or Step 9 on R1.

Run the show mpls ldp bindings 12.3.4 32 detail instance 1 command on R1 to
R1(config)#show mpls ldp bindings 12.3.4 32 detail instance 1
1.2.3.4/32
It can be seen that R1 has received an out label from R3.

Run the show ip forwarding route 1.2.3.4 command on R1 to check the routing
information:
1-106
SJ-20140731105308-012|2014-10-20 (R1.0)

--------------------------------------------------------------------------
IPv4 Routing Table:

Codes
Gw: Gateway,
Pri: Priority;

Status codes: *valid, >best;

Interface
Owner
Pri Metric
*> 1.2.3.4/32 100.100.100.2
Dest
Gw
gei-0/2/0/2
LDP-A
254 65534
*> 1.2.0.0/16 100.100.100.2
gei-0/2/0/2
STAT
It can be seen that the 1.2.3.4/32 route is generated by the LDP based on the
1.2.0.0/16 route. The next-hop information of the egress interface of the 1.2.3.4/32
route is the same as that of the 1.2.0.0/16 route.
Run the show mpls forwarding-table 1.2.3.4 command on R1 to check the
forwarding table information:
R1(config)#show mpls forwarding-table 1.2.3.4
-------------------------------------------------------------------------Local Outgoing Prefix or OutgoingNext Hop M/S
label label Lspnameinterface
16386
16385
1.2.3.4/32loopback11.1.1.35 M
Check the execution result of Step 8 on R3.

Run the show mpls ldp bindings 12.3.4 32 detail instance 1 command on R1 to
R1(config)#show mpls ldp bindings 12.3.4 32 detail instance 1
1.2.3.4/32
remote binding: lsr: 1.1.1.36:0, label: 16385 (inuse)
Run the show ip forwarding route 1.2.3.4 command on R1 to check the routing
information:
-------------------------------------------------------------------------IPv4 Routing Table:
Codes
Gw: Gateway,
Pri: Priority;

Status codes: *valid, >best;
1-107
SJ-20140731105308-012|2014-10-20 (R1.0)

Dest
Gw
Interface
Owner
Pri Metric
*> 1.2.3.4/32 100.100.100.2 gei-0/2/0/2
LDP-A
254 65534
*> 1.2.0.0/16 100.100.100.2 gei-0/2/0/2
STAT
The output information is the same as the execution results of Step 7 or 9.

Run the show mpls forwarding-table 1.2.3.4 command on R1 to check the
forwarding table information:
R1(config)#show mpls forwarding-table 1.2.3.4
-------------------------------------------------------------------------Local Outgoing Prefix or Outgoing Next Hop M/S
label label Lspnameinterface
16386 16385
1.2.3.4/32loopback1 1.1.1.35 M
It can be seen that there is a valid out label in the forwarding table.
1-108
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 2
MPLS TE Configuration
Table of Contents
RSVP Configuration ...................................................................................................2-1
TE Summary Refresh Introduction............................................................................2-24
TE Message Acknowledgement and Retransmission ...............................................2-29
TE Authentication Configuration ...............................................................................2-34
Confiugration of MPLS TE Crossing Several AS Domains........................................2-40
TE-FRR Configuration ..............................................................................................2-58
FRR Promotion Introduction ...................................................................................2-103
FRR-Hello Configuration ........................................................................................ 2-114
MPLS TE End-to-End Protection Path Configuration ..............................................2-121
Loose Node Re-optimization ..................................................................................2-128
Automatic Bandwidth Regulation on an MPLS TE .................................................2-135
TE GR Configuration ..............................................................................................2-140
TE Tunnel FA Configuration ...................................................................................2-148
TE Tunnel AR Configuration ...................................................................................2-152
TE Metric Configuration..........................................................................................2-157
TE SRLG Configuration..........................................................................................2-162
TE Tunnel Reoptimization Configuration.................................................................2-168
TE HOTSTANDBY Configuration............................................................................2-173
WTR Configuration for a TE Tunnel........................................................................2-179
TE Tunnels Supporting Soft Preemption.................................................................2-185
Equal Load Sharing on the TE-ECMP ....................................................................2-198
TE Affinity...............................................................................................................2-202
Binding Interfaces Supporting TE Bandwidth Reservation ......................................2-214
RSVP-TEs Supporting Resource Reservation ........................................................2-220
2.1 RSVP Configuration

2.1.1 RSVP Overview
RSVP Introduction
RSVP is a resource reservation protocol designed for comprehensive network services.
In brief, RSVP has the following features:
1. The reservation on each router is "soft", which means that the reservation is updated
by the receiver periodically. It is necessary to update the reservation by advertising
2-1
SJ-20140731105308-012|2014-10-20 (R1.0)
the reservation repeatedly and periodically on the network. When the reservation is
removed from the network by RSVP explicitly, or when the reservation event expires,
the device will send a request.
This is different from the "hard-state" protocols. Generally, the hard-state protocols
only need to advertise requests once, and it is supposed that they hold the requests
until the requests are removed explicitly.
2. RSVP is a network (control) protocol instead of a transport protocol. It does not carry
data, but it works together with TCP data flows or UDP data flows.
3. RSVP is not a routing protocol. Any routing policy is made by Interior Gateway Protocol
(IGP), IGP Traffic Engineering (TE) extension and Constrained Shortest Path First
(CSPF). The only work of RSVP is to advertise the RSVP signaling and maintain the
reserved resources on the network.
4. RSVP is receiver-oriented. The receiver sends the request for resource reservation
and maintains the resource reservation information.
RSVP is on the base of IP. Users can apply for buffers and bandwidth that meet the quality
requirements of specific services from the network. The intermediate nodes establish and
maintain the resource reservation path on the data transmission network through RSVP,
thus to provide the corresponding quality of service.
RSVP Control Path

On the control path, there are two basic messages used to establish the resource
reservation path, PATH message and RESV message.
1. Before sending data, the sender sends a PATH message first to establish a
transmission path with the receiver. The PATH message contains a unique LSP
quintuple group and other control information. The source application programme
sends the characteristics of the user service and expected QoS to the RSVP process
through the application programme interface. The RSVP process forms a PATH
message according to the requirement and then sends the message to the next hop.
2. After the RSVP process on an intermediate route along the path receives the PATH
message, it establishes the PATH soft state, saves the parameters of the service and
the address of the previous hop. The RSVP process also collects the information
of available resources on the node and makes an preparation for the resource
reservation. At last, the RSVP process forms a new PATH message and sends it to
the next hop.
3. When the RSVP process of the receiver receives the PATH message, it sends the
message to the destination application programme through the RSVP application
programme interface. The application programme forms an RESV message according
to the service characteristics received and the parameters of the available resources.
The RESV message contains the QoS parameters and service characteristics that
meet the parameters. After this, the RSVP process returns the message according to
the saved previous hop address.
4. The RESV message is transmitted to the sender along the same path. When it passes
through each router, it makes a confirmation about the QoS parameters designated
2-2
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 2 MPLS TE Configuration
by the PATH message. When the RSVP process of an intermediate node receives
the RESV message, it establishes the RESV soft state, sets the parameters of the
packet classifier and packet forwarder, and then forwards the message according to
the saved previous hop address.
5. When the sender receives the RESV message from the receiver, the LSP tunnel is
established. The sender and the receiver use this path to transmit data flow. The
routers along the path reserve resources for the data flow and forward the data flow
according to the negotiated QoS.
6. Till Step 5, the resource reservation path has been established. To adapt to the
changes of routes and QoS, RSVP sends update messages periodically, including
PATH message and RESV message.
The RSVP message handling module is responsible for handling messages, establishing,
maintaining and deleting the resource reservation state, as well as forwarding messages
according to the routes obtained from the route handling module. The RESV message
handling module establishes and modifies the Path State Block (PSB) and Reservation
State Block (RSB) for data flows according to the PATH message, RESV message, PATH
update message and RESV update message it receives. The two states contain the
service parameters and resource reservation parameters of each data flow. In multicasting
situations, the RSVP message handling module combines the RESV messages that are
sent by different senders to the same receiver, and modifies the local PSB. As service
characteristics and reservation requirements are multidimensional, the RSVP message
handling module does not simply combine a reserved resource by using the larger value of
a parameter. Instead, it uses each parameter in the messages to calculate out a resource
reservation state that meets the requirement in each message according to a specific
algorithm, that is, the Least Upper Bound (LUB). RSVP is a complex signaling system,
including establishment, update and deletion of the resource reservation path. RSVP also
handles different types of error information. If the state of a data flow changes, RSVP
uses the application programme interface between the RSVP message handling module
and the service control module to trigger the service control module to adjust the reserved
resources at the link layer.
To maintain the path state information, RSVP has two timers, flush timer and period-update
timer. The interval of the period-update timer is several times smaller than that of the flush
timer. In this way, an occasional loss of the PATH message will not cause the deletion of
path state information. However, it is better to use the minimum bandwidth to configure
the RSVP packets to prevent data loss due to congestion.
LSP Tunnel Establishment

After the input LSR at the head of the tunnel completes the CSPF calculation for a specific
tunnel, the establishment of an LSP is started.
As shown in Figure 2-1, the input LSR sends an RSVP PATH message to the output LSR.
The output LSR responds the input LSR for the RESV PATH message by sending an RSVP
RESV message.
2-3
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-1 LSP Tunnel Establishment 1
When the input LSR receives the RSVP RESV message, the LSP is established. The
input LSR can use the LSP tunnel to forward services to the output LSR.
When the output LSR receives the PATH message that contains LABEL_REQUEST
Object, it sends an RESV that contains LABEL Object as a response.
LABEL Object contains the label binding information that is used for communication
between the output LSR and the upstream neighbors. The RESV message is sent in
the upstream direction of the input LSR. The direction is opposite to that of the PATH
message.
The LSRs receiving the RSVP RESV message that contains the LABEL Object use the
received labels for the services related to the specific LSP. When the RESV message
reaches the input LSR, the LSP establishment is completed.
Figure 2-2 LSP Tunnel Establishment 2
As shown in Figure 2-2,

1. MPLS and RSVP are enabled globally and on the interfaces of LSR1, LSR2, LSR3
and LSR4.
2. Through some mechanisms, LSR1 knows that the whole LSP needs to comply with
the explicit route (LSR1 -> LSR2 -> LSR3 -> LSR4).
2-4
SJ-20140731105308-012|2014-10-20 (R1.0)
3. The L bit of each abstract node in the Explicit Route Object (ERO) is cleared, that is,
the strict mode of specific bit in the explicit route. An ERO is a simple abstract node
(just comprises a node defined by a 32-bit IPv4 packet).
2.1.2 Configuring RSVP

This procedure describes how to establish an LSP tunnel by using the RSVP-TE mode.
Steps
1. Create a tunnel interface.
Command
Function
ZXR10(config)#interface te_tunnel <tunnel-number>
Enters a tunnel interface.
2. Enable MPLS TE.

Step
Command
Function
ZXR10(config)#mpls traffic-eng
Enables MPLS TE and enters

the TE configuration mode.
ZXR10(config-mpls-te)#interface <interface-name>
Enables TE on the interface.
ZXR10(config-mpls-te-if)#bandwidth
Configures a bandwidth for
[{static|dynamic}]<bandwidth value>
the TE interface.
bandwidth [{static|dynamic}]<bandwidth value>:

maximum bandwidth (static
reservation type or dynamic reservation type) that the TE interface supports, range
14294967295, unit: kbps.
3. Configure an explicit path for the tunnel.
Step
Command
Function
ZXR10(config-mpls-te)#explicit-path {identifier
Configures the explicit-path
<identifier>|name <name>}
name or identifier of the

tunnel.
ZXR10 (config-mpls-te-expl-path-id-
Configures a next hop of the
identifier)#index <1-64> next-address {strict |
explicit path.
loose}<A.B.C.D>
3
Configures an excluded path.
ZXR10 (config-mpls-te-expl-path-ididentifier)#index <1-64> exclude-address {interface|
router-id}<A.B.C.D>
2-5
SJ-20140731105308-012|2014-10-20 (R1.0)
strict: strict path.

loose: loose path.
4. Configure the destination address of the tunnel.
Step
Command
Function
ZXR10(config-mpls-te)#tunnel te_tunnel
Enters the tunnel configuration
<tunnel-number>
mode.
ZXR10(config-mpls-te-tunnel-te_tunnel-tunnel-
Configures the destination
number)#tunnel destination ipv4 <A.B.C.D>
address of the tunnel.
5. Configure a TE tunnel name.

Step
Command
Function
Enters the tunnel configuration
<tunnel-number>
mode.
Configures the TE tunnel
number)#tunnel mpls traffic-eng name <name>
name.
This tunnel name is carried

to all nodes along the
tunnel through the RSVP-TE
signaling protocol.
Check different tunnel
names by using the display
command. Tunnels with the
same tunnelID can be more
easily distinguished at the
intermediate node.
<name>: TE tunnel name with 1-63 characters.

6. Configure the path of the tunnel.
Command
Function
Configures the path of the tunnel
number)#tunnel mpls traffic-eng path-option <number>
(dynamic).
dynamic
Configures the path of the tunnel
number)#tunnel mpls traffic-eng path-option <number>
(explicit path).
explicit-path {identifier <identifier>|name <name>}
dynamic: uses the dynamic path calculation mode.

7. Configure other RSVP functions.
2-6
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Commands
Functions
ZXR10(config-mpls-te-if-interface-name)#bfd
Enables BFD on the real

interface in MPLS-TE
interface configuration mode.
ZXR10(config-mpls-te-tunnel-te_tunnel-number)#t
Enables tunnel LSP BFD in
unnel mpls traffic-eng bfd interval <interval> min-rx <
MPLS-TE tunnel interface
min-rx > multiplier <multiplier>
configuration mode.
ZXR10(config-mpls-te-tunnel-te_tunnel-number)#t
Sets the maximum number of
unnel mpls traffic-eng hop limit <hop-num>
hops on a tunnel. By default,

this number is not limited.
<interval>: minimum time interval (in milliseconds) for sending BFD control packets,
range: 3990.
<min-rx>: minimum time interval (in milliseconds) for receiving BFD control packets,
range: 3990.
<multiplier>: multiple of the timeout for detecting BFD control packets, range: 350.
<hop-num>: range of the maximum hops on a tunnel, which is 132.
8. Display the configuration results.
Commands
Functions
ZXR10#show mpls traffic-eng tunnels te_tunnel <Tunnel
Displays the information about a
ID>
specified local tunnel.
ZXR10#show mpls traffic-eng tunnels remote-tunnel
Displays the information about a remote
[tunnel-id <tunnel-id> lsp-id <lsp-id> ingress-id
tunnel.
<ingress-id> egress-id <egress-id>]

ZXR10#show mpls traffic-eng tunnels brief
Checks the brief information about a TE

tunnel, specifically, checks whether the
TE tunnel name is valid.
ZXR10#show mpls traffic-eng interface brief
Displays the brief information about the

interface on which the TE function is
enabled.
ZXR10#show mpls traffic-eng interface detail
Displays the detailed information about

the interface on which the TE function
is enabled.
End of Steps
2-7
SJ-20140731105308-012|2014-10-20 (R1.0)
2.1.3 RSVP Configuration Instance

2.1.3.1 Establishing a Basic OSPF TE RSVP Tunnel
As shown in Figure 2-3, there is a common RSVP tunnel from the P1 router to the P2
router. The tunnel is established through the OSPF TE protocol in dynamic routing mode.
Figure 2-3 Establishing a Basic OSPF TE RSVP Tunnel
Configuration Flow
1. Establish the OSPF neighbor relationship between the P1 router and the P2 router
through the direct-connected interfaces. Enable OSPF TE. Establish the RSVP tunnel
on the interfaces in the same OSPF area.
2. Enable TE on the direct connected interfaces of the P1 router and the P2 router.
Configure the destination and the path of tunnel1 on the P1 router.
3. Configure a static route to the destination on the P1 router. The next hop is Tunnel1.
In this case, the traffic is transmitted through the tunnel.
The dynamic routing mode is used in this instance.
The configuration of P1 is as follows:
P1(config)#interface te_tunnel1
P1(config-if-te_tunnel1)#ip unnumbered loopback1
P1(config-if-te_tunnel1)#exit
2-8
SJ-20140731105308-012|2014-10-20 (R1.0)
P1(config)#router ospf 1
P1(config-ospf-1)#router-id 1.1.1.1
P1(config-ospf-1)#network 192.168.1.0 0.0.0.255 area 0
P1(config-ospf-1)#mpls traffic-eng area 0
P1(config-ospf-1)#exit
P1(config)#mpls traffic-eng
P1(config-mpls-te)#interface loopback1
P1(config-mpls-te-if-loopback1)#exit
P1(config-mpls-te)#router-id 1.1.1.1
P1(config-mpls-te)#interface gei-0/1/0/2
P1(config-mpls-te-if-gei-0/1/0/2)#exit
P1(config-mpls-te)#tunnel te_tunnel1
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel destination ipv4 2.1.1.1
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng path-option 1 dynamic
P1(config-mpls-te-tunnel-te_tunnel1)#exit
P1(config-mpls-te)#exit
P1(config)#ip route 172.20.1.2 255.255.255.255 te_tunnel1

2-9
SJ-20140731105308-012|2014-10-20 (R1.0)
The configuration of R2 is as follows:

Note:
The loopback addresses are used as the Router-IDs in MPLS-TE. It is to prevent the
establishment of the tunnel from being affected by the Router-IDs due to down interfaces.
The loopback interfaces are always in UP state (unless the state is changed manually).
Check the tunnel information on the P1 router. The tunnel is in up state. The information
of the tunnel is shown below.
P1(config)#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process: running
RSVP Process: running
Forwarding: enabled
TUNNEL NAME
DESTINATION UP IF
DOWN IF
STATE/PROT
tunnel_1
2.1.1.1
gei-0/1/0/2
up/up
P1(config)#show mpls traffic-eng tunnels te_tunnel 1
Name: tunnel_1
(Tunnel1) Destination: 2.1.1.1
Status:
Admin: up
Oper: up
Path:
valid
Signalling: connected
Path option: 1, type dynamic (Basis for Setup)

Actual Bandwidth: 0 kbps
Hot-standby protection:
No path options protected
Config Parameters:
Resv-Style: SE
Metric Type: IGP (default)
Hop Prior: disabled
Upper Limit: 4294967295

Upper Limit: -
Record-Route: disabled
Facility Fast-reroute: disabled
Detour Fast-reroute: disabled
Bandwidth Protection: disabled
Hot-standby-lsp Fast-reroute: disabled
BFD: disabled
Policy class: default
2-10
SJ-20140731105308-012|2014-10-20 (R1.0)

Track Name:
Auto-reoptimize: disabled
Hot-standby-lsp Auto-reoptimize: disabled
Reference Hot-standby: disabled
Tunnel-Status: enabled
Bandwidth: 0 kbps (Global) Priority: 7
CBS: 0 byte
EIR: 0 kbps
Affinity: 0x0/0x0
EBS: 0 byte
AutoRoute: disabled
AUTO-BW: disabled
Forwarding-adjacency: disabled
Co-routed Bidirect: disabled
Associated Bidirect: disabled
Rate-limit: disabled
Crankback: disabled
Soft Preemption: disabled
Soft Preemption Status: not pending
Addresses of preempting links: 0.0.0.0
OutLabel: gei-0/1/0/2, 3
RSVP Signalling Info :
Src 1.1.1.1, Dst 2.1.1.1, Tun_Id 1, Tun_Instance 74
RSVP Path Info:
Explicit Route: 192.168.1.1 192.168.1.2
2.1.1.1
Exclude Route: NULL

Record Route: NULL
Tspec: ave rate= 0 kbits, burst= 1000 bytes, peak rate= 0 kbits
RSVP Resv Info:
Record Route: NULL
Fspec: ave rate= 0 kbits, burst= 1000 bytes, peak rate= 0 kbits
History:
Tunnel:
Time since created: 0 days, 6 hours, 10 minutes
Prior LSP: path option 1
Current LSP: Uptime:0 days, 0 hours, 0 minutes
Last lsp error information:
None log record.
2.1.3.2 Establishing a Strict IS-IS TE RSVP Tunnel

As shown in Figure 2-4, there is a common RSVP tunnel from the P1 router to the P2
router. The tunnel is established through the IS-IS TE protocol in strict routing mode.
2-11
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-4 Establishing a Strict IS-IS TE RSVP Tunnel
Configuration Flow
1. Establish the IS-IS neighbor relationship between the P1 router and the P2 router
through the direct-connected interfaces and enable IS-IS TE.
2. Enable TE on the direct-connected interfaces of the P1 router and the P2 router.
Configure the destination and the path of tunnel1 on the P1 router.
3. Configure a static route to the destination on the P1 router. The next hop is Tunnel1.
The strict routing mode is used in this example.
P1(config)#router isis 1
P1(config-isis-1)#system-id AAAA.BBBB.1111
2-12
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-isis-1)#metric-style wide
P1(config-isis-1)#mpls traffic-eng level-1
P1(config-mpls-te)#explicit-path identifier 1
P1(config-mpls-te-expl-path-id-1)#next-address strict 192.168.1.2
P1(config-mpls-te-expl-path-id-1)#exit
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng path-option 1
explicit-path identifier 1

P2(config-isis-1)#system-id AAAA.BBBB.2222
2-13
SJ-20140731105308-012|2014-10-20 (R1.0)

R2(config-if-gei-0/1/0/2)#ip address 172.20.1.2
255.255.255.0
Check the tunnel information on the P1 router. The tunnel is in up state. The information
of the tunnel is shown below.
Signalling Summary:
Forwarding: enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_1
2.1.1.1
gei-0/1/0/2
up/up
P1(config-mpls-te)#show mpls traffic-eng tunnels te_tunnel 1
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit identifier: 1 (Basis for Setup)

Actual Bandwidth: N/A
no path options protected
Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
Record-Route: enabled
2-14
SJ-20140731105308-012|2014-10-20 (R1.0)

BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
Affinity: 0x0/0x0
EBS: 0 byte
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
InLabel: OutLabel: gei-0/1/0/2, 3

RSVP Path Info:
Explicit Route: 192.168.1.1 192.168.1.2 2.1.1.1
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
None log record.
2-15
SJ-20140731105308-012|2014-10-20 (R1.0)
Note:
The loopback addresses are used as the Router-IDs in MPLS TE. It is to prevent the
establishment of the tunnel from being affected by the Router-IDs due to interface down.
The loopback interfaces are always in UP state (unless the state is changed manually).
2.1.3.3 Configuring BFD on RSVP Interface

As shown in Figure 2-5, it is required to establish an IS-IS TE tunnel between R1 and R2
and enable BFD for the RSVP-TE interfaces on R1 and R2.
Figure 2-5 Configuring BFD on RSVP Interface
Configuration Flow
1. Establish an IS-IS TE tunnel between R1 and R2.
2. Enable BFD on the RSVP-TE interfaces on R1 and R2.
Configuration Command
R1(config-isis-0)#metric-style wide
R1(config-isis-0)#mpls traffic-eng level-2
R1(config-isis-0-if-xgei-0/5/0/3)#end
2-16
SJ-20140731105308-012|2014-10-20 (R1.0)
R1(config)#interface te_tunnel1
R1(config-if-te_tunnel1)#ip unnumbered loopback1
R1(config-if-te_tunnel1)#exit
R1(config)#mpls traffic-eng
R1(config-mpls-te)#interface loopback1
R1(config-mpls-te-if-loopback1)#exit
R1(config-mpls-te)#router-id 172.20.96.1
R1(config-mpls-te)#tunnel te_tunnel 1
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel destination ipv4 172.20.108.1
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng
path-option 1 dynamic
R1(config-mpls-te-tunnel-te_tunnel1)#exit
R1(config-mpls-te)#interface xgei-0/5/0/3
R1(config-mpls-te-if-xgei-0/5/0/3)#bfd

R2(config-isis-0-if-xgei-0/0/0/3)#end
R2(config-mpls-te)#interface xgei-0/0/0/3
R2(config-mpls-te-if-xgei-0/0/0/3)#bfd
After the configuration, a session of RSVP interface on R1 should be established
successfully. Run the following commands to check the configuration result.
2-17
SJ-20140731105308-012|2014-10-20 (R1.0)
Run the show bfd neighbors [ip brief|ip detail] command to check whether the BFD
configuration of the RSVP interface takes effect.
Check the BFD configuration result of RSVP interface on R1:
R1(config)#show bfd neighbors ip brief
LocalAddr
PeerAddr
LD
RD
Hold
State
Interface
172.20.130.213
172.20.130.214
150
UP
xgei-0/5/0/3
R1(config)#show bfd neighbors ip detail

------------------------------------------------------------LocalAddr:172.20.130.213
PeerAddr :172.20.130.214
Local Discr:2050
Remote Discr:2049
Holdown(ms):150
Interface: xgei-0/5/0/3
Vpnid:0
VRF Name:---
State:UP
BFD Type:SingleHop
Instance Name:
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag:0
Demand Mode:0
Poll Bit:1
MinTxInt:50
MinRxInt:50
Multiplier:3
Length:24
Min Echo Interval:0
Min BFD Length:24
Max BFD Length:24
Rx Count:0
/0
/0
Tx Count:66
/0
/0
Registered Protocols:RSVP
Control Plane Rcv Phy Interface Name: xgei-0/5/0/3
============================================================================
2.1.3.4 Configuring RSVP LSP BFD

As shown in Figure 2-6, RSVP LSP BFD is to use BFD to detect the LSP of an RSVP tunnel.
When it is combined with the hot standby function and when an invalid LSP becomes an
active LSP, the tunnel traffic should be changed over to the standby LSP.
2-18
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-6 RSVP LSP BFD Configuration Instance
Configuration Flow
1. Enable OSPF-TE among R1, R2 and R3.
2. Configure a hot standby tunnel on R1 (R1-R3-R2) and configure BFD on the tunnel.

R1(config-ospf-100)#network 54.1.1.0 0.0.0.255 area 0
R1(config-ospf-100)#mpls traffic-eng area 0
2-19
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-mpls-te)#interface gei-0/5/0/4
R1(config-mpls-te-if-gei-0/5/0/4)#exit
R1(config-mpls-te)#tunnel te_tunnel1
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng path-option 1
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng record-route
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng hot-standby
protect 1 dynamic
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng bfd interval 30
min-rx 30 multiplier 5
R1(config-mpls-te)#explicit-path identifier 1
R1(config-mpls-te-expl-path-id-1)#next-address strict 54.1.1.3
R1(config-mpls-te-expl-path-id-1)#next-address strict 115.1.1.2


2-20
SJ-20140731105308-012|2014-10-20 (R1.0)



After the configuration, the tunnel1 on R1 is Up and a hot standby tunnel is generated. the
hot standby relation is ready. The RSVP LSP BFD session on R1 should be established
successfully. If the link between R3 and R2 is invalid. The traffic is changed over to the
hot standby tunnel.
Run the show bfd neighbors [rsvp-brief|rsvp-detail] command to check whether the RSVP
interface BFD configuration takes effect.
Check the tunnel on R1.
R1(config)#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process:
running
RSVP Process:
running
2-21
SJ-20140731105308-012|2014-10-20 (R1.0)

Forwarding:
enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_1
10.10.10.2
gei-0/5/0/4 up/up
tunnel_1(hot)
10.10.10.2
gei-0/5/0/7 up/up
R1#sho mpls traffic-eng fast-reroute

Tunnel head end item information
Protected Tunnel
LspID
Tunnel1
In-label Out intf/label
FRR intf/label
Status
Tun hd
Tu1:3
ready
FRR intf/label
Status
gei-0/5/0/4:14745
6
LSP midpoint frr information:

LSP identifier
R1#sho mpls traffic-eng tunnels hot-standby

Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Fast Reroute Protection: None

Hot-standby Protection: Ready

RSVP Path Info:
Explicit Route: 57.1.1.1 57.1.1.2 10.10.10.2
Exclude
Route: 10.10.10.3 115.1.1.2
Record Route: NULL

RSVP Resv Info:
Record Route: 10.10.10.2 57.1.1.2
Check the RSVP interface BFD configuration on R1.

R1#show bfd neighbors rsvp lsp brief
TunnelId
LspId
LD
RD
Hold
State
te_tunnel1
16
33053
2662
150
UP
R1#show bfd neighbors rsvp lsp detail

---------------------------------------------------------------------------TunnelId:te_tunnel1
LspId:16
LspRole:master
Local Discr:33053
Remote Discr:2662
State:UP
2-22
SJ-20140731105308-012|2014-10-20 (R1.0)

Holddown(ms):150
BFD Type:RSVP LSP[Active]
Instance Name:
---------------------------------------------------------------------------Version:1
Dest UDP Port:3784
Final Bit:1
Local Diag: 0
Demand Mode:0
Poll Bit:0
MinTxInt: 50
MinRxInt:50
Multiplier:3
Received MinTxInt: 10
Length:24
Min Echo Interval:0
Rx Count:0
/0
/0
Tx Count:0
/0
/0
Registered Protocols:RSVP LSP

Control Plane Rcv Phy Interface Name: gei-0/5/0/4
============================================================================
/*When the R3-R2 link is invalid, the tunnel hot standby relation is active.*/
R1#sho mpls traffic-eng fast-reroute
Protected Tunnel
LspID
Tunnel1
FRR intf/label
Status
Tun hd
Tu1:3
active
FRR intf/label
Status
gei-0/5/0/4:14745
6

LSP identifier
R1#sho mpls traffic-eng tunnels hot-standby
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Fast Reroute Protection: None

Hot-standby Protection: Backup lsp in use
R1(config)#show bfd neighbors rsvp lsp brief
2-23
SJ-20140731105308-012|2014-10-20 (R1.0)
2.2 TE Summary Refresh Introduction

2.2.1 TE Summary Refresh Introduction
Overview
RSVP is a typical soft status protocol, and the related LSP status information is maintained
by periodically sending refresh messages. If an RSVP node does not receive any refresh
message during the specified period, the corresponding LSP is removed.
Such feature of RSVP determines that, when there are thousands of tunnels, too much
pressure is put on system loads to maintain the refresh messages for these tunnels, and
a large amount of bandwidth is used to maintain these tunnels. Limited system resources
can be effectively utilized by reducing the traffic loads caused by refresh messages.
In the TE message acknowledgement and retransmission mechanism, a MESSAGE_ID
object is carried in a triggering message. When a neighbor receives the message, it sends
an ACK message to the message sender. This mechanism is applied only in triggering
messages, and no handlings are performed for PATH and RESV refresh messages.
The principle of summary refresh is to use a summary refresh message (carrying a
MESSAGE-ID object indicating a PATH or RESV message) to replace the standard PATH
and RESV message. The MESSAGE-ID object is the object applied in the TE message
acknowledgement and retransmission mechanism.
Implementation
To implement RSVP summary refresh, RFC extends the MESSAGE-ID object,
MESSAGE_ID_ACK object, MESSAGE_ID_LIST object, MESSAGE_ID_NACK object,
ACK message, and Srefresh message. For a description of the MESSAGE_ID object,
MESSAGE_ID_ACK object, and ACK message, refer to the "Introduction to TE Message
Acknowledgement and Retransmission" section.
l
MESSAGE_ID_LIST object: identifies a received message.

The MESSAGE_ID object plays the same role as a PATH or RESV message.
MESSAGE_ID_NACK object: After a MESSAGE_ID object is received, if the

corresponding status block is not found, a MESSAGE_ID_NACK object is generated.
This object is sent in an ACK message or carried in other messages through the TE
message acknowledgement and retransmission mechanism.
Srefresh message: carries one or more MESSAGE_ID_LIST objects to refresh
multiple PATH or RESV messages that have been advertised.
The Srefresh message itself needs not to be acknowledged, and it must carry a
MESSAGE_ID object.
2-24
SJ-20140731105308-012|2014-10-20 (R1.0)
Features
After a neighbor receives a summary refresh message, it determines the corresponding
PATH or RSB status block based on the MESSAGE_ID object. If the corresponding status
block is found, the neighbor considers that a PATH refresh message is received from
the upstream, or the RESV refresh message is received from the downstream, and then
updates the TTD time of the PSB or RSB.
If the neighbor does not find the corresponding PATH or RSB status block through the
MESSAGE_ID object, it sends a MESSAGE_ID_NACK object to the source end. After
the source end receives the MESSAGE_ID_NACK object, it constructs a standard PATH
or RESV refresh message based on the PATH or RSB status block corresponding to the
MESSAGE_ID object, and sends the message to the neighbor.
The advantage of summary refresh is that a message sender needs not to construct a
standard PATH or RESV message, and a neighboring node needs not to create a PKT
and compare objects in a message. This can reduce the traffic loads caused by refresh
messages, enhancing the utilization of limited system resources.
2.2.2 Configuring TE Summary Refresh

This procedure describes how to configure TE summary refresh.
Context
Before the TE summary refresh configuration, TE message acknowledgement and
retransmission should be enabled in the TE configuration mode of local and peer nodes.
Steps
1. To enable MPLS TE, run the following commands:
Command
Function
Enables MPLS TE, and enters

2. To configure summary refresh, perform the following steps:

Step
Command
Function
ZXR10(config-mpls-te)#signalling retransmit
Enables TE message
acknowledgement and
retransmission.
ZXR10(config-mpls-te)#signalling refresh reduction
Enables summary refresh.
3. To display the configuration result, run the following command:
2-25
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#show ip rsvp refresh reduction
Displays summary refresh

information.
End of Steps
2.2.3 TE Summary Refresh Configuration Example

Figure 2-7 shows a sample network topology. It is required to establish a common RSVP
tunnel from P1 to P2 by using the OSPF TE-based strict routing mode, and configure
summary refresh in the TE configuration mode of P1 and P2.
Figure 2-7 TE Summary Refresh Configuration Example
Configuration Flow
1. Establish an OSPF neighbor relationship between the directly-connected interfaces of
P1 and P2, and enable OSPF TE.
2. Enable TE on the directly-connected interfaces of P1 and P2.
3. Configure the tunnel destination and strict routing mode on P1.
4. Enable summary refresh in the TE configuration mode of P1 and P2.
Run the following commands on P1:
2-26
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#tunnel te_tunnel 1
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng
path-option 1 explicit-path identifier 1

2-27
SJ-20140731105308-012|2014-10-20 (R1.0)

Run the following commands to enable TE summary refresh:

P1(config-mpls-te)#signalling retransmit
P1(config-mpls-te)#signalling refresh reduction
P2(config-mpls-te)#signalling refresh reduction
Run the show mpls traffic-eng tunnels brief command on P1 to check whether the tunnel
has been established. The execution result is displayed as follows:
Signalling Summary:
Forwarding: enabled
TUNNEL NAME DESTINATION UP IF DOWN IF STATE/PROT
tunnel_1 2.1.1.1 - gei-0/1/0/2 up/up
It can be seen that the tunnel is in up status.

Run the show ip rsvp refresh reduction command on P1 to display the information of TE
summary refresh:
P1(config)#show ip rsvp refresh reduction
Retransmit:enabled
Initial retransmit delay:1000ms
Retransmit limit:3
Refresh Reduction:enabled
next_hop type tunnel_id lsp_id ingressegress
192.168.1.2 Path 1 2 1.1.1.12.1.1.1
Run the show ip rsvp refresh reduction command on P2 to display the information of TE
summary refresh:
P2(config-mpls-te)#show ip rsvp refresh reduction
Retransmit:enabled
Retransmit limit:3
Refresh Reduction:enabled
next_hop type tunnel_id lsp_id ingressegress
192.168.1.1 Resv 1 2 1.1.1.12.1.1.1
2-28
SJ-20140731105308-012|2014-10-20 (R1.0)
2.3 TE Message Acknowledgement and Retransmission

2.3.1 Introduction to TE Message Acknowledgement and
Retransmission
Overview
RSVP messages are IP-based, but the forwarding of IP messages is unreliable: messages
may be lost or failed. Moreover, in some abnormal cases (for example, messages are
lost), message senders are not informed of failures. Before the summary refresh function
is enabled, an RSVP message is periodically sent to refresh an LSP. In the worst cases,
if an LSP is removed due to no receipt of an RSVP message during the specified period,
only the services related to the LSP are affected, and the consequence is not very serious.
Even though the use of the summary refresh mode can reduce the amount of refresh
messages, a negative effect also arises: The function and significance of refresh
messages are greatly enhanced. The loss of a refresh message may cause multiple
LSPs not to receive the corresponding refresh information, even causing the removal of
LSPs and service interruptions.
To relieve and eliminate the negative effect, message acknowledgement and
retransmission is used to guarantee the summary refresh function. In this way, messages
that need to be acknowledged are retransmitted when no acknowledgements are
received, which ensures the reliability of message transmission.
Implementation
To implement RSVP message acknowledgement and retransmission, RFC adds a
MESSAGE-ID object, a MESSAGE_ID_ACK object, and an ACK message.
l
l
MESSAGE_ID object: uniquely identifies a message, and indicates whether the

message should be acknowledged by the peer end.
MESSAGE_ID_ACK object: acknowledges the corresponding MESSAGE_ID object.
If the flag in the MESSAGE_ID object of the message sender is not 1, this object
cannot be acknowledged.
ACK message:
acknowledges
MESSAGE_ID_ACK objects.
multiple
messages
by
carrying
multiple
An ACK message does not need to be acknowledged, and therefore it cannot carry
any MESSAGE_ID object.
Features
l
Explicit acknowledgement and implicit acknowledgement

In general, receiving a MESSAGE_ID_ACK object is referred to as explicit
acknowledgement.
2-29
SJ-20140731105308-012|2014-10-20 (R1.0)
In some cases, a received RSVP message does not carry a MESSAGE_ID_ACK

object, but the MESSAGE_ID object carried in the RSVP message functions as the
MESSAGE_ID_ACK object. This acknowledgement mode is referred to as implicit
acknowledgment.
l
Immediate acknowledgement and batch delayed acknowledgement

If a received message needs to be acknowledged, the message receiver has two
options:
Immediate acknowledgement: replies an ACK message for the received

message (such as the NOTIFY message) immediately.
This acknowledgement mode has a real-time feature but lower efficiency. An
ACK message can only acknowledge a received message.
Batch delayed acknowledgement: buffers the ACK objects for a received

message temporarily, and sends these ACK objects all at once.
2.3.2 Configuring TE Message Acknowledgement and

Retransmission
This procedure describes how to configure TE message acknowledgement and
retransmission.
Context
TE message acknowledgement and retransmission should be configured in the TE
configuration mode of local and peer nodes.
Steps
1. Enable the MPLS TE.
Command
Function

2. Configure TE message acknowledgement and retransmission.

Step
Command
Function
ZXR10(config-mpls-te)#signalling retransmit
Configures TE message
acknowledgement and
retransmission.
2-30
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-mpls-te)#signalling retransmit interval
Sets the message
< interval-value >
retransmission interval
(in milliseconds) in TE
message acknowledgement
and retransmission, range:
5003000.
ZXR10(config-mpls-te)#signalling retransmit limit <
Sets the number of
limit-count >
times that a message is

retransmitted in TE message
acknowledgement and
retransmission, range: 210.
3. Verify the configuration.

Command
Function
ZXR10#show ip rsvp refresh reduction
Displays information of TE
message acknowledgement and
retransmission.
End of Steps
2.3.3 TE Message Acknowledgement and Retransmission

Configuration Example
tunnel from P1 to P2 by using the OSPF TE-based strict routing mode, and configure TE
message acknowledgement and retransmission in the TE mode of P1 and P2.
Figure 2-8 TE Message Acknowledgement and Retransmission Configuration Example
2-31
SJ-20140731105308-012|2014-10-20 (R1.0)
Configuration Flow
4. Configure TE acknowledgement and retransmission in the TE configuration mode of
P1 and P2.
2-32
SJ-20140731105308-012|2014-10-20 (R1.0)

Signalling Summary:
Forwarding: enabled
TUNNEL NAME DESTINATION UP IF DOWN IF
tunnel_1
2.1.1.1
STATE/PROT
gei-0/1/0/2
up/up

Run the show ip rsvp refresh reduction command on P1 to check the information of
message acknowledgement and retransmission. The execution result is displayed as
follows:
P1(config)#show ip rsvp refresh reduction
/*TE message acknowledgement and retransmission is disabled*/
Retransmit:disabled
Retransmit limit:3
Refresh Reduction:disabled
2-33
SJ-20140731105308-012|2014-10-20 (R1.0)
Run the following commands on P1 to configure message acknowledgement and

retransmission:
P1(config-mpls-te)#signalling retransmit interval 2000
P1(config-mpls-te)#signalling retransmit limit 5
P2 has the same configuration as P1.

Run the show ip rsvp refresh reduction command on P1 to check the information of
message acknowledgement and retransmission. The execution result is displayed as
follows:
P1(config-mpls-te)#sho ip rsvp refresh reduction
/*TE message acknowledgement and retransmission is enabled*/
Retransmit:enabled
Retransmit limit:5
Refresh Reduction:disabled
2.4 TE Authentication Configuration

2.4.1 TE Authentication Overview
Authentication Introduction
RSVP authentication mechanism (cryptographic authentication) is a method for encrypting
messages on the sender's end, and authenticating messages on the receiver's end
between two neighboring nodes in a RSVP networking solution. By using this mechanism,
RSVP messages can be prevented from being modified illegally or suffering from an
attack that causes repeated messages transmission.
This authentication function has the following features:
l
Based on the existing flow of RSVP protocol, the RSVP message authentication
function is implemented through adding operations in RSVP transmission and
reception packages.
Cryptographic authentication is more reliable than message checksum. Thus
message transmission through an interface that has an authentication mechanism
can be free from RSVP message checksum.
Authentication Implementation
To implement the RSVP authentication function, the field function of INTG objects,
challenge objects, challenge messages and challenge-response messages are extended.
l
An INTG object carries the information to be checked for authentication between

neighboring nodes. For the nodes that have been configured with an authentication
mechanism, all messages except challenge messages that are sent from the node
2-34
SJ-20140731105308-012|2014-10-20 (R1.0)
must carry INTG objects. The received messages also carry INTG objects that are
required to be checked.
A challenge object carries a key ID and a timestamp-based coolie file. This object is
only used between the interactions of challenge messages and challenge-response
messages.
For challenge messages, when the receiver end receives a RSVP message in which
the challenge consultation bit is set to 1, check the consultation status. If the status
is not successful, challenge consultation will be initialized, and a challenge message
will be sent to the sender's end.
A response message is the response to a challenge message. It contains an INTG
object and a challenge object. Among which, the challenge object is the one carried
in the original challenge message.
Authentication Features
The RSVP authentication method is to generate a data abstract based on packets and
passwords using a simplex algorithm. After the packets and the abstract are sent to a
neighbor, the neighbor also generates the abstract based on the packets and passwords
using the same algorithm, and then checks the two abstracts to confirm whether the
packets are intact. Meanwhile, to avoid vicious transmission of packets repeatedly, when
packets are sent, a sequence number field is added. the value for this field increases
continuously. If the sequence number is too old, the corresponding packets will also be
deleted.
The RSVP authentication requires a password. In this way, the unauthorized routers
cannot operate as a neighbor. Even with constructed packets, without the corresponding
password, a RSVP connection to the router cannot be created. The RSVP key verification
is performed between two RSVP neighbors. The key used by the two neighbors cannot
be different. Otherwise, the authentication will fail, and the RSVP packets received by the
interface will be deleted.
A RSVP key can be encrypted in two modes: MD5 and SHA-1. The default mode is MD5.
To promote the security and reliability of RSVP authentication, the enhanced functions
of RSVP authentication are provided, including slide-window technology and handshake
mechanism. Sliding windows are used to prevent unordered packets. The handshake
mechanism (authentication negotiation) is used to prevent nodes being attacked by
repeatedly-sent packets during reboot.
2.4.2 Configuring TE Authentication

This procedure describes how to configure TE authentication.
Context
You should configure two neighboring nodes to implement the authentication function.
2-35
SJ-20140731105308-012|2014-10-20 (R1.0)
Steps
1. Enable MPLS TE.
Step
Command
Function
Enables MPLS TE
globally, and enters the
TE configuration mode.
Enables MPLS TE on the

interface.
2. Enable the authentication function for an interface.

Step
Command
Function
ZXR10(config-mpls-te-if-interface-name)#authe
Enables the authentication
ntication
function for an interface.
ZXR10(config-mpls-te-if-interface-name)#authent
As the receiver's end,
ication challenge
perform Challenge/Response
handshake with a neighbor.

3
As the sender's end,
ication challenge-imp
perform Challenge/Response
handshake with a neighbor.
ZXR10(config-mpls-te-if-interface-
Sets authentication key.
name)#authentication key passphrase {encrypted
<encrypted-password>:
<encrypted-password>|<password>}
encrypted authentication
key.
<password>: unencrypted
authentication key.
ZXR10(config-mpls-te-if-interface-name)#authen
Specifies an authentication
tication type {md5 | sha1}
type.
Specifies the size of the
ication window-size <window-size>
window for displaying

authentication messages,
range: 164.
3. To displays the configuration results, run the following command:

Command
Function
ZXR10#show ip rsvp authentication
Displays the authentication relationship.
End of Steps
2-36
SJ-20140731105308-012|2014-10-20 (R1.0)
2.4.3 TE Authentication Configuration Instance

Configuration Instruction
As shown in Figure 2-9, the establishment of common RSVP tunnel from P1 to P2 uses
OSPF TE and a strict routing mode. Under the interface, SHA 1 authentication mode is
used.
Figure 2-9 TE Interface Authentication Configuration
Configuration Method
1. Establish OSPF neighbors between P1 and P2 straight-through interfaces, and enable
TE function in the OSPF protocol.
2. Enable TE for P1 and P2 straight-through interfaces. Under these interfaces, use the
authentication mode. Enable challenge and challenge-imp for P1 and P2 interfaces,
and use SHA1 authentication mode. The password is 12345678.
3. On P1, set the tunnel destination and the strict routing mode.
4. Set a static route that routes to the destination on P1. The next hop is Tunnel1. In this
way, messages are forwarded through Tunnel1.
Configuration Steps
The following describes the configuration on P1:
P1(config)#interfacegei-0/1/0/2
2-37
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te-if-gei-0/1/0/2)#authentication
P1(config-mpls-te-if-gei-0/1/0/2)#authentication type sha1
/*Set SHA1 as the authentication type for TE interface*/
P1(config-mpls-te-if-gei-0/1/0/2)#authentication key passphrase 12345678
/*Set authentication key*/
P1(config-mpls-te-if-gei-0/1/0/2)#authentication challenge
P1(config-mpls-te-if-gei-0/1/0/2)#authentication challenge-imp
P1(config-mpls-te-if-gei-0/1/0/2)#authentication window-size 10
The following describes the configuration on P2:

2-38
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-mpls-te-if-gei-0/1/0/2)#authentication
P2(config-mpls-te-if-gei-0/1/0/2)#authentication challenge
P2(config-mpls-te-if-gei-0/1/0/2)#authentication challenge-imp
P2(config-mpls-te-if-gei-0/1/0/2)#authentication type sha1
/*Set SHA1 as the authentication type for TE interface*/
P2(config-mpls-te-if-gei-0/1/0/2)#authentication key passphrase 12345678
/*Set authentication key*/
P2(config-mpls-te-if-gei-0/1/0/2)#authentication window-size 10
The following describes the configuration on R2:

255.255.255.0
On P1, check the tunnel status. The tunnel is in up status, and the authentication
information of Tunnel1 is available:
Signalling Summary:
Forwarding: enabled
tunnel_1 2.1.1.1 - gei-0/1/0/2 up/up
P1(config)#show mpls traffic-eng interface detail gei-0/1/0/2

gei-0/1/0/2:
State:
ENABLE
Traffic-eng metric: 0
Authentication: enabled
Key:
<encrypted>
Type:
sha-1
Challenge:
enabled
Challenge-imp: Implemented
2-39
SJ-20140731105308-012|2014-10-20 (R1.0)

Window size:
10
BFD: disabled
Backup path:
None
SRLGs: None
Intf Fast-Hello: DISABLE
Fast-Hello interval: 10000
Fast-Hello miss: 4
Convergence-Ratio: 100(%)
On P1, check the TE authentication information:

P1#show ip rsvp authentication
Neighbor: 192.168.1.2
Interface: gei-0/1/0/2
Direction: Send
Crypto Auth:Enable
Send Key ID (hex): 0x6896a0010000
Next valid seq:
1c9f 6bafc3
Challenge-imp: Configured
challenge-imp state: CHALL_IMP_WAIT
Direction: recv
Challenge: Configured
challenge state: CHALL_SUCC
Rcv Key ID (hex): 0x6896a0030000
Windowsize: 10
2.5 Confiugration of MPLS TE Crossing Several AS

Domains
2.5.1 MPLS TE Crossing Several AS Domains Overview
MPLS TE Crossing Several AS Domains Introduction
MPLS TE creates an LSP tunnel crossing the network to transmit the traffic. There are two
types of LSPs that crossing the network:
l
Inter-Area TE LSP: The LSP of the MPLS TE tunnel crosses the node in the topology
database that is not in the ingress router. This node is in other OSPF area or the IS-IS
level.
Inter-AS TE LSP: The LSP of the MPLS TE tunnel crosses the node who is not in the
AS of the ingress router.
Inter-Area TE LSP and Inter-AS TE LSP are advertised in the ERO through the sub-object
of the loose hop. The ingress router does not know the strict path of the other areas, so
2-40
SJ-20140731105308-012|2014-10-20 (R1.0)
the loose display mode must be used. The lower router handles the sub-object of these
loose hop and set it to the strict hop.
For the Inter-Area TE tunnel, establish a loose explicit path in the router on the ingress
interface of the tunnel. Specify that the LSP must pass the Area Border Router (ABR)
through the next-address loose command. The ingress router and the ABR in this explicit
path segment the LSP. For each segment, the path to the next ABR or the egress interface
of the tunnel is calculated separately.
For the Inter-AS tunnel, the AS does not know the topology of another AS, so the head-end
LSR can only calculate the LSP of the local Autonomous System Boundary Router (ASBR).
In this case, it is required to set the interface to passive-interface mode on the ASBR and
flood it to the Interior Gateway Protocol (IGP) in the ASBR. After that, the RSVP-TE could
send the signalling to the router where the passive interface is located according to the path
calculated by CSPF. The router sends the receivesignallingng to the ASBR of another AS.
The ASBR calculates the loose path to the strict path. In this case, the TE LSP crossing
several domains is established.
MPLS TE Crossing Several AS Domains Work Flow

The application of RSVP-TE crossing several domains is classified into two categories,
including INTER-AREA and INTER-AS. For the INTER-AREA application, you only need
to set the path (in loose mode) for the router connected with the ingress of the tunnel during
the configuration. At the same time, you needs to specify that the LSP must pass ABR
through the next-address loose command. The working principle of INTER-AS application
is as follows:
To realize INTER-AS application, it is required to calculate the TE LSP. If the AS where the
head-end LSR responsible for calculating the TE LSP is located uses the OSPF protocol,
and the AS is composed of multiple areas, you need to consider how to calculate the
LSP crossing several domains (Inter-AS). An AS does not know the topology structure
of another AS, so the head-end LSR can only calculates the LSP of ASBR. In this case,
the key point is that how to calculate the LSP of the ASBR at the end of the link crossing
different domains. If the LSP of the ASBR at the other end of the link is calculated, the
head-end LSR completes the LSP calculation task. In this case, add the strict explicit path
of the ASBR in another AS to the loose explicit path of the destination node and then send
it to the ASBR of another AS. The remanent loose explicit path is calculated as the strict
explicit path.
As shown in Figure 2-10, it is assumed that LSR1, LSR2 and LSR3 belong to AS100 and
the same area area0, and LSR4, LSR5 and LSR6 belong to AS200. LSR3 is the ASBR for
AS100, and LSR4 is the ASBR for AS200. Now it is required to establish a TE LSP from
LSR1 to LSR6 and calculate this LSP.
2-41
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-10 TE LSP Calculation Scheme
According to the current mechanism, the LSP from the LSR1 to the LSR3 could be
calculated. The LSR3 does not know how to get to the LSR4.
The method is as follows: configure a path to the ASBR (LSR4) of another AS on the ASBR
(LSR3) of the local AS. The LSR3 reports the inter-domain link and LSR4 at the other end
of the link to teh AS100. In this case, the head-end LSR1 could calculate the LSP from
LSR1 to LSR3 and from LSR3 to LSR4. Set the POSO/1 interface on the LSR3 to mpls
traffic-eng passive interface. In this case, the LSR3 forms an Opaque LSA (type 10) or a
TLV22 neighbor.
When RSVP-TE establishes the tunnel, the LSR3 can calculate the strict explicit path to
the ASBR (LSR4) of another AS after the signaling is sent to the ASBR (LSR3) and sends
the strict explicit path to the ASBR (LSR4) of another AS for processing. In this case,
the LSR4 calculates the remanent loose path to the strict path to complete the TE LSP
establishment in different domains.
2.5.2 Configuring the MPLS TE Crossing Several AS Domains

This procedure describes how to configure MPLS TE Crossing Several AS Domains.
Steps
1. Enable the TE function globally.
Command
Function
Enables the TE function globally.
2. Configure the TE interface passive-interface attribute.

Step
Command
Function
Enters the TE interface

configuration mode.
ZXR10(config-mpls-te-if-interface-name)#p
Configures the TE interface
assive-interface nbr-te-id <A.B.C.D>[{[nbr-if-addr
passive-interface attribute.
<if-address>],[nbg-igp-id {isis <sysid>| ospf <sysid>}]}]

2-42
SJ-20140731105308-012|2014-10-20 (R1.0)
<A.B.C.D>: indicates the TE router-id of the peer neighbor router of this link.
<if-addr>: indicates the interface address of the remote ASBR (it is the TE RouterID
of the default neighbor if not configured).
3. To display the configuration results, run the following commands:
Commands
Functions
Displays the detailed configuration of
[<interface-name>]
the TE interface.
ZXR10#show ip ospf database opaque-area
Displays whether the egress of the

ASBR generates Point-to-point LSA
(type 10).
Displays whether the neighbor
ZXR10#show isis database verbose
information crossing several domains

exists in the database.
End of Steps
2.5.3 MPLS TE Crossing Several AS Domains Configuration

Instance
2.5.3.1 Configuring an OSPF TE Crossing Several AS Domains
The network topology is shown in Figure 2-11. R1 and R3 locate in the AS100, and R2
locates in the AS 200. Configure the global OSPF instance and establish the OSPF
neighbor. Enable the TE function on the egress interface of the ASBR1, configure
passive-interface to form an Opaque LSA (point-to-point LAS with type 10) and floods to
its own area.
Figure 2-11 Configuration Instance of OSPF TE Crossing Several AS Domains
2-43
SJ-20140731105308-012|2014-10-20 (R1.0)
Configuration Flow
1. Establish the OSPF neighbor between the R1 and the R3 in the same AS100 and
enable TE.
2. Enable the TE on two interface direct connected with the R1 and the R3.
3. Enable the TE on the egress interface of the ASBR1 and configure passive-interface.
4. Enable OSPF TE on ASBR2 and enable the TE on the gei-0/5/0/3 interface.
5. Configure a TE tunnel from R1 to R2 passing through ASBR1 in loose mode.
6. Configure a static route to the destination on the R1 router. The next hop is Tunnel1.
Interface configuration:
OSPF and OSPF TE configuration:

MPLS-TE configuration:
R1(config-mpls-te)#exit
2-44
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-mpls-te-expl-path-id-100)#next-address loose 61.61.61.3
R1(config-mpls-te-expl-path-id-100)#exit
R1(config)#ip route 172.20.1.2 255.255.255.255 te_tunnel1

OSPF TE configuration:
R2(config-mpls-te-if-gei-0/5/0/3)#end

2-45
SJ-20140731105308-012|2014-10-20 (R1.0)
OSPF and OSPF TE configuration:

R3(config-mpls-te-if-gei-0/1/0/4)#passive-interface nbr-te-id 61.61.61.2
nbr-if-addr 131.4.2.1 nbr-igp-id ospf 61.61.61.2

255.255.255.0
Show the tunnel establishment information on the R1 router:
Signalling Summary:
running
RSVP Process:
running
Forwarding:
enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_100
61.61.61.2
gei-0/1/0/3 up/up
R1(config)#show mpls traffic-eng tunnels te_tunnel 100

Name: tunnel_100
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit identifier 100 (Basis for Setup)

Config Parameters:
2-46
SJ-20140731105308-012|2014-10-20 (R1.0)

Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
Affinity: 0x0/0x0
EBS: 0 byte
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
InLabel:OutLabel:gei-0/1/0/3,147456

RSVP Path Info:
Explicit Route: 131.4.1.1 131.4.1.2 61.61.61.2
Exclude
Route: NULL
Record
Route: NULL
Tspec:ave rate= 0 kbits, burst= 2000 bytes, peak rate = 0 kbits

RSVP Resv Info:
Record
Route: NULL
Fspec:ave rate= 0 kbits, burst= 2000 bytes, peak rate = 0 kbits
Check the database information on the ASBR to see whether the egress interface of the
ASBR generates Point-to-point LSA (type 10):
R3(config)#show ip ospf database opaque-area area 0
2-47
SJ-20140731105308-012|2014-10-20 (R1.0)

Type-10 Opaque Link Area Link States (Area 0.0.0.0)
LS age: 665
Options: (No TOS-capability, DC)
LS Type: Opaque Area Link
Link State ID: 1.0.0.0
Opaque Type: 1
Opaque ID: 0
Advertising Router: 61.61.61.33
LS Seq Number: 0x80000001
Checksum: 0xabf2
Length: 28
Fragment number : 0
MPLS TE router ID : 61.61.61.3
Number of Links : 0
LS age: 735
Opaque Type: 1
Opaque ID: 0
Checksum: 0x5c62
Length: 28
Fragment number : 0
Number of Links : 0
LS age: 752
Opaque Type: 1
Opaque ID: 0
Checksum: 0x5868
Length: 28
Fragment number : 0
2-48
SJ-20140731105308-012|2014-10-20 (R1.0)
Number of Links : 0
LS age: 655
Opaque Type: 1
Opaque ID: 1
Checksum: 0xd66f
Length: 124
Fragment number : 1
Link connected to Broadcast network

Link ID : 131.4.1.1
Interface Address : 131.4.1.2
Neighbor Interface Address : 0.0.0.0
Admin Metric : 1
Maximum bandwidth : 125000000
Maximum reservable bandwidth : 0
Number of Priority : 8
Priority 0 : 0
Priority 1 : 0
Priority 2 : 0
Priority 3 : 0
Priority 4 : 0
Priority 5 : 0
Priority 6 : 0
Priority 7 : 0
Affinity Bit : 0x0
Number of Links : 1
LS age: 664
Opaque Type: 1
Opaque ID: 2
Checksum: 0x99c8
Length: 124
Fragment number : 2
2-49
SJ-20140731105308-012|2014-10-20 (R1.0)

Link ID : 131.4.2.1
Admin Metric : 1
Priority 0 : 0
Priority 1 : 0
Priority 2 : 0
Priority 3 : 0
Priority 4 : 0
Priority 5 : 0
Priority 6 : 0
Priority 7 : 0
Affinity Bit : 0x0
Number of Links : 1
LS age: 659
Opaque Type: 1
Opaque ID: 2
Checksum: 0x6bf8
Length: 124
Fragment number : 2

Link ID : 131.4.1.1
Admin Metric : 1
Priority 0 : 0
Priority 1 : 0
Priority 2 : 0
Priority 3 : 0
Priority 4 : 0
Priority 5 : 0
Priority 6 : 0
Priority 7 : 0
Affinity Bit : 0x0
2-50
SJ-20140731105308-012|2014-10-20 (R1.0)

Number of Links : 1
LS age: 31
Opaque Type: 1
Opaque ID: 4
Checksum: 0x3524
Length: 124
Fragment number : 4
Link connected to Point-to-point network

Link ID : 61.61.61.2
Admin Metric : 1
Priority 0 : 0
Priority 1 : 0
Priority 2 : 0
Priority 3 : 0
Priority 4 : 0
Priority 5 : 0
Priority 6 : 0
Priority 7 : 0
Affinity Bit : 0x0
Number of Links : 1
Show the details about the TE interface on the ASBR.

R3(config)#show mpls traffic-eng interface detail gei-0/1/0/4
gei-0/1/0/4:
State:
ENABLE
Traffic-eng metric:0
Authentication: disabled
Key:
<encrypted>
Type:
md5
Challenge:
disabled
Challenge-imp:
Window size:
Not implemented(simulated)
32
BFD: disable
Passive Info:
2-51
SJ-20140731105308-012|2014-10-20 (R1.0)

nbr_te_id
nbr_if_addr
ospf_rid
61.61.61.2
131.4.2.1
61.61.61.2
isis_id
Backup path:
None
SRLGs: None
Intf Fast-Hello : DISABLE
Fast-Hello interval : 10000
Fast-Hello miss : 4
2.5.3.2 Configuring an IS-IS TE Crossing Several AS Domains

The network topology is shown in Figure 2-12. R1 and R3 locates in AS100 and R2 locates
in AS200. R1 and R3 locate in the same area. Configure the global IS-IS instance and
establish the IS-IS neighbor. Enable the TE function on the egress interface of the ASBR1,
configure passive-interface to form a point-to-point database.
Figure 2-12 Configuration Instance of IS-IS TE Crossing Several AS Domains
Configuration Flow
1. Establish the IS-IS neighbor between the R1 and the R3 in the same AS100 and enable
IS-IS TE.
2. Enable the TE on two interface direct connected with the R1 and the R3.
3. Enable the TE on the egress interface of the ASBR1 and configure passive-interface.
4. Enable IS-IS TE on ASBR2 and enable the TE on the ingress gei-0/5/0/3 interface.
5. Configure a TE tunnel from R1 to R2 passing through ASBR1 in loose mode.
2-52
SJ-20140731105308-012|2014-10-20 (R1.0)

IS-IS and IS-IS TE configuration:

R1(config-isis-1)#area 01
R1(config-mpls-te-expl-path-id-100)#next-address loose 61.61.61.3
R1(config-mpls-te-expl-path-id-100)#exit

2-53
SJ-20140731105308-012|2014-10-20 (R1.0)


R2(config-isis-1)#system-id 2355.255E.3666


2-54
SJ-20140731105308-012|2014-10-20 (R1.0)

R3(config-mpls-te-if-gei-0/1/0/4)#passive-interface nbr-te-id 61.61.61.2
nbr-if-addr 131.4.2.1 nbr-igp-id isis 2355.255e.3666
Check the tunnel establishment on the R1:
Signalling Summary:
running
RSVP Process:
running
Forwarding:
enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_100
61.61.61.2
gei-0/1/0/3 up/up
R1(config)#show mpls traffic-eng tunnels te_tunnel 100

Name: tunnel_100
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit identifier 100 (Basis for Setup)

Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
2-55
SJ-20140731105308-012|2014-10-20 (R1.0)

BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
Affinity: 0x0/0x0
EBS: 0 byte
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled

RSVP Path Info:
Explicit Route: 131.4.1.1 131.4.1.2 61.61.61.2
Exclude
Route: NULL
Record
Route: NULL

RSVP Resv Info:
Record
Route: NULL
Check the database information on the R3.

R3(config)#show isis database verbose level-1
Process ID:0
Process ID:1
IS-IS level 1 link-state database:
LSPID
R3.00-00*
NLPID:
Hostname:
Area Address:
LSP Seq Num
LSP Checksum
LSP Holdtime
ATT/P/OL
0x16
0x27c3
837
0/0/0
0xcc
R3
01
2-56
SJ-20140731105308-012|2014-10-20 (R1.0)

Router ID:
61.61.61.3
Ip address:
1.2.3.82
Metric: 16777215
IS-Extended 2355.255E.3666-00
Affinity: 0x0
Interface IP Address: 131.4.2.2
Physical BW: 1000000 kbits/sec
Reservable Global Pool BW: 0 kbits/sec
Global Pool BW Unreserved:
[0]:
kbits/sec, [1]:
kbits/sec
[2]:
kbits/sec, [3]:
kbits/sec
[4]:
kbits/sec, [5]:
kbits/sec
[6]:
kbits/sec, [7]:
kbits/sec
Metric: 10
IS-Extended R3.03
Affinity: 0x0
[0]:
kbits/sec, [1]:
kbits/sec
[2]:
kbits/sec, [3]:
kbits/sec
[4]:
kbits/sec, [5]:
kbits/sec
[6]:
kbits/sec, [7]:
kbits/sec
Metric: 10
IP 131.4.1.0/24
Metric: 10
IP 166.166.7.0/24
Metric: 10
IP 1.2.3.82/32
Metric: 10
IP 61.61.61.3/32
LSPID
LSP Seq Num
LSP Checksum
LSP Holdtime
ATT/P/OL
R3.03-00*
0x8
0x7404
401
0/0/0
Metric: 0
IS-Extended R1.00
Metric: 0
IS-Extended R3.00
LSPID
LSP Seq Num
LSP Checksum
LSP Holdtime
ATT/P/OL
R1.00-00
0xf
0xb98c
491
0/0/0
NLPID:
0xcc
Area Address:
01
Ip address:
1.2.3.80
Router ID:
61.61.61.1
Hostname:
R1
Metric: 10
IS-Extended R3.03
Affinity: 0x0
[0]:
kbits/sec, [1]:
kbits/sec
[2]:
kbits/sec, [3]:
kbits/sec
2-57
SJ-20140731105308-012|2014-10-20 (R1.0)

[4]:
kbits/sec, [5]:
kbits/sec
[6]:
kbits/sec, [7]:
kbits/sec
Metric: 10
IP 131.4.1.0/24
Metric: 10
IP 166.166.3.0/24
Metric: 10
IP 1.2.3.80/32
Metric: 10
IP 61.61.61.1/32
Check the detailed configuration information of the TE interface on ASBR.

R3(config)#show mpls traffic-eng interface detail gei-0/1/0/4
gei-0/1/0/4:
State:
ENABLE
Key:
<encrypted>
Type:
md5
Challenge:
disabled
Challenge-imp:
Window size:
Not implemented(simulated)
32
BFD: disable
Passive Info:
nbr_te_id
nbr_if_addr
61.61.61.2
131.4.2.1
ospf_rid
isis_id
2355.255e.3666
Backup path:
None
SRLGs: None
Intf Fast-Hello : DISABLE
Fast-Hello interval : 10000
Fast-Hello miss : 4
2.6 TE-FRR Configuration

2.6.1 TE-FRR Overview
TE-FRR Introduction
At present, the traditional IP network uses a "tried" service mode. With the further
development of the network service, the IP network bearing multiple services must reach
the traditional level of the telecommunication network on the aspect of reliability. For
example, the switching protection duration should less than 50 ms. In the last few years
since mid 1990s, the MPLS technology has played an important role in the development
of next generation telecommunication networks, such as quickly transferring, QoS
guarantee and multi-service support.
2-58
SJ-20140731105308-012|2014-10-20 (R1.0)
To ensure the reliability of the MPLS network, the MPLS Fast Reroute (FRR) technology
plays a very important role. This technology provides a quick switching protection function
for the LSP with the help of the MPLS Traffic Engineering (TE). To ensure that the LSP is
not affected by the link or the node fault, the MPLS FRR establishes a local backup path
in advance. When a fault occurs, the device that detects the link or node fault switches
the services from the faulty link to the backup path quickly to reduce the data loss.
The main feature of the MPLS fast rerouting is fast response and timely switching. It
ensures the smooth transition of the service data. At the same time, the LSP tries to find
a new path to re-establish the LSP and switch the data to the new path. Before the new
LSP is established, the service data is transmitted through the protection path.
TE-FRR Features
The MPLS FRR is a mechanism used for the link protection and node protection. When
the LSP link or node is faulty, the MPLS FRR protects the faulty node or link to transmit
the traffic through the protection node or link. In this case, the data transmission is not
interrupted. The header node could continue sending a request to establish the main path
when the data transmission is not affected.
The basic principle of the MPLS FRR is to protect one or more LSPs with a LSP which is
established in advance. The LSP established in advance is called fast rerouting LSP and
the protected LSP is called main LSP. The purpose of the MPLS FRR is as follows: skip
the faulty link or node through the fast rerouting tunnel to protect the main path.
MPLS FRR is implemented based on RSVP TE.
The following two methods are used for the implementation of the fast rerouting.
l
Detour mode (One-to-one Backup): It provides protection to each LSP to be protected,

and create a protection path for each LSP to be protected. This protection path is
called Detour LSP.
Bypass mode (Facility Backup): It protects multiple LSPs through one protection path.
This protection path is called Bypass LSP.
The Bypass mode also has two methods to implement fast rerouting.
l
l
It is required to configure a backup tunnel on the egress interface of the main tunnel by
manual. The protection is classified into the node protection and the link protection.
Backup the tunnel automatically. Establish a backup tunnel for the main tunnel
automatically when the backup condition is met (the node protection is generated
first).
The concept of several terms is as follows:

l
l
l
Main LSP: The main LSP is the protected LSP for the Detour LSP or the Bypass LSP.
PLR: It is a head node of the Detour LSP or the Bypass LSP. It must be on the path
of the main LSP and cannot be the tail node.
MP: It is the tail node of the Detour LSP or the Bypass LSP. It must be on the path of
the main LSP and cannot be the head node.
2-59
SJ-20140731105308-012|2014-10-20 (R1.0)
Link protection: There is a direct link between the PLR and the MP. The main LSP
pass this link. When this link is invalid, all the services are switched to the Detour LSP
path or the Bypass LSP path.
Node protection: There is a router between the PLR and the MP. The main LSP passes
this router. When this router is invalid, all the service are switched to the Detour LSP
path or the Bypass LSP path.
TE-FRR Bandwidth Protection

If a bandwidth is configured for a protection LSP, upon switchover, to ensure the bandwidth
for the services of the protection LSP on the backup path, an additional requirement can
be promoted for bandwidth protection. Once the requirement for bandwidth protection is
promoted, an optimal backup path is calculated through an algorithm so that the backup
path has a sufficient bandwidth for forwarding the services of the protection LSP upon
switchover.
Figure 2-13 shows the active tunnel path RTA-RTB-RTC-RTD-RTE and the backup tunnel
path RTB-RTF-RTD.
The active tunnel is configured to have a 20 M bandwidth and require bandwidth
protection. Two backup tunnels are configured at the RTB node, tunnel back_tnnl1 has a
10 M bandwidth and tunnel back_tnnl2 has a 30 M bandwidth.
Upon selecting backup protection, back_tnnl2 is selected as the backup tunnel because
the backup bandwidth of back_tnnl1 cannot protect the bandwidth of the active tunnel.
Figure 2-13 TE-FRR Bandwidth Protection
HOT_LSP Supporting TE-FRR

When a dynamic IP/MPLS is deployed in the network with end-to-end TE HOT_LSP
protection, TE FRR is only deployed at the core convergence layer due to the complexity
of the network and devices at the access layer. If both the convergence layer and the
access layer are disconnected at the same time and the access device switches over to
the standby LSP, which is not protected by the TE FRR at the convergence layer, services
may be interrupted. In this case, you have to wait till the TE LSP is re-established.
2-60
SJ-20140731105308-012|2014-10-20 (R1.0)
To ensure the minimum traffic loss, configure FRR related protection attributes upon
establishing the standby LSP to implement TE FRR protection on downstream nodes.
At present, if both HOT_LSP protection and FRR protection are configured for a tunnel
and a HOT_LSP has been created, FRR protection forms on downstream nodes of the
HOT_LSP. However, FRR protection is not needed for the downstream nodes of the
HOT_LSP in some cases. To reduce the system calculation load, a configuration item is
added to enable or disable FRR protection for the HOT_LSP of a tunnel.
2.6.2 Configuring TE-FRR

This procedure describes how to configure TE-FRR.
Steps
1. Configure a tunnel to support the FRR function.
Step
Command
Function
Enters tunnel interface
<tunnel-number>
configuration mode.
Enables the fast rerouting
number)#tunnel mpls traffic-eng fast-reroute {facility |
function on the tunnel.
one-to-one}
2. Configure a backup tunnel.

Step
Command
Function
Enters the MPLS-TE interface

configuration mode.
ZXR10(config-mpls-te-if-interface-name)#backup-
Configures the tunnel-id for
path te_tunnel <tunnel-id>
the backup tunnel on the

egress interface of the primary
tunnel.
3. Configure the auto-tunnel backup function.

Step
Command
Function
Enters the MPLS-TE interface

configuration mode.
ZXR10(config-mpls-te-if-interface-name)#auto-tu
Configures the tunnel to
nnel backup
support the auto-tunnel

backup function.
ZXR10(config-mpls-te-if-interface-name)#auto-tu
Indicates that the auto-backup
nnel backup nhop-only
tunnel only supports path

protection.
2-61
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-mpls-te)#auto-tunnel backup
Configures the maximum
tunnel-num min <min-value> max <max-value>
value or the minimum value

for the auto-backup tunnel.
<min-value>: the minimum tunnel-num of the automatic backup tunnel, range:

64536~65535.
<max-value>: the maximum tunnel-num of the automatic backup tunnel, range:
64536~65535.
4. Configure TE-FRR bandwidth protection.
Step
1
Command
Function
Enters the active tunnel.
<tunnel-number>
2
Enables the bandwidth
number)#tunnel mpls traffic-eng fast-reroute {facility|
protection function of the
one-to-one }[bw-protect]
active tunnel.
Exits the active tunnel.
number)#exit
Enters the backup tunnel.
<tunnel-number>
5
Sets a backup bandwidth for
number)#tunnel mpls traffic-eng backup-bw {bandwidth}
the backup tunnel.
5. Enables TE-FRR on the Hot-standby LSP.

Step
Command
Function
<tunnel-number>
configuration mode.
Enables TE-FRR on the
number)#tunnel mpls traffic-eng hot-standby-lsp
Hot-standby LSP in tunnel
fast-reroute
mode.
Enables RRO in tunnel mode.
number)#tunnel mpls traffic-eng record-route

Command
Function
ZXR10#show mpls traffic-eng fast-reroute
Displays the FRR mapping relationship

configured globally.
Displays tunnel information.
ZXR10#show mpls traffic-eng tunnels
2-62
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#show mpls traffic-eng auto-backup tunnels band
Displays the binding information of the
[te_tunnel <tunnelId>]
auto-backup tunnel and the primary

tunnel.
ZXR10#show mpls traffic-eng auto-backup tunnels
Displays the summary of the
summary
auto-backup tunnel.
ZXR10#show mpls traffic-eng auto-backup parameter
Displays the parameters of the

auto-backup tunnel.
ZXR10#show mpls traffic-eng tunnels backup
Displays the backup bandwidth usage

of the backup tunnel and the number of
the protection tunnels.
Displays the debugging information of
ZXR10#debug rsvp fast-reroute
the manual backup tunnel.
End of Steps
2.6.3 TE-FRR Configuration Instance

2.6.3.1 Establishing a Tunnel in Facility Mode Manually
As shown in Figure 2-14, there are two tunnels from the P1 router to the P3 router, tunnel1
and tunnel2. Tunnel1 passes by the P1 router, the P2 router and the P3 router. Tunnel2
passes by the P1 router and the P3 router. Tunnel1 is the active LSP and tunnel2 is
stand-byndby LSP. These two tunnels form the FRR relationship. When the active LSP
has a fault, the stand-by LSP protects it. Traffic is handed over to the stand-by LSP.
2-63
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-14 Establishing a Tunnel in Facility Mode Manually
Configuration Flow
1. Establish OSPF neighbor relationship through the direct-connected interfaces on the
P1 router, the P2 router and the P3 router. Enable OSPF TE.
2. Establish two strict paths. The active path passes by the P1 router, the P2 router and
the P3 router. The stand-by path passes by the P1 router and the P3 router.
3. Enable TE on the interfaces in use on the P1 router, the P2 router and the P3 router.
Configure the stand-by LSP on gei-0/2/1/1 of the P1 router.
4. Create the active path and the standby path. Enable FRR on the active path. The
destination is the TE router-id of P3. The path is in strict mode.
5. Configure a static route to the destination on the P1 router. The next hop is Tunnel. In
this case, the traffic is transmitted through the tunnel.
2-64
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-ospf-1)#network 1.1.1.1
0.0.0.0 area 0

P1(config-mpls-te)#explicit-path name primary
P1(config-mpls-te-expl-path-name)# next-address strict 74.1.1.1
P1(config-mpls-te-expl-path-name)#next-address strict 120.1.1.2
P1(config-mpls-te-expl-path-name)#exit
P1(config-mpls-te)#explicit-path name back
explicit-path name primary
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng record-route
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng fast-reroute facility
P1(config-mpls-te- tunnel-te_tunnel2)#tunnel mpls traffic-eng path-option 1
explicit-path name back
P1(config-mpls-te-if-gei-0/2/1/1)#backup-path te_tunnel 2
2-65
SJ-20140731105308-012|2014-10-20 (R1.0)


0.0.0.0 area 0


2-66
SJ-20140731105308-012|2014-10-20 (R1.0)

0.0.0.0
area 0


When the tunnel is up, check the FRR information on P1, as shown below.
P1#show mpls traffic-eng tunnels brief
Signalling Summary:
Forwarding: enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_1
3.1.1.1
gei-0/2/1/1
up/up
tunnel_2
3.1.1.1
gei-0/2/1/3
up/up
P1#show mpls traffic-eng fast-reroute

Protected Tunnel
Tunnel1
LspID
86

Tun hd
FRR intf/label
gei-0/2/1/1:147456
Tu2:3
Status
ready
2-67
SJ-20140731105308-012|2014-10-20 (R1.0)

LSP identifier
FRR intf/label
Status
When the active LSP has a fault, the traffic will be handed over to the stand-by LSP. FRR
is in active state. At this time, both the active tunnel and the standby tunnel are in up
status. Check the FRR state on P1. When the fault on the active LSP recovers, the FRR
relationship recovers to ready state.
Protected Tunnel
LspID
Tunnel1
86

Tun hd
FRR intf/label
gei-0/2/1/3:147456
Tu2:3
Status
active

LSP identifier
FRR intf/label
Status
2.6.3.2 Establishing a Tunnel in Facility Mode Automatically

As shown in Figure 2-15, there is an active tunnel from P1 to P3. The automatic backup
function is enabled. The displayed path of the active tunnle1 is P1-P2-P3. The FRR facility
protect function is enabled on the active tunnel and the auto-backup relationship is formed.
When the active LSP has a fault, the standby LSP protects it. Traffic is handed over to the
standby LSP.
Figure 2-15 Establishing a Tunnel in Facility Mode Automatically
Configuration Flow
1. Establish OSPF neighbor relationship through the direct-connected interfaces on P1,
P2 and P3. Enable OSPF TE.
2. Enable the au-backup function in TE mode.
2-68
SJ-20140731105308-012|2014-10-20 (R1.0)
3. Create an active tunnel passing P1-P2-P3.

4. Enable T3 on the interfaces in used on P1, P2 and P3.
5. Create the active path. Enable FRR facility on the active path. The destination is the
TE router-id of P3. The path is in strict mode.
6. Configure a static route to the destination on the P1. The next hop is Tunnel1. In this
case, the traffic is transmitted through the tunnel.
0.0.0.0
area 0

P1(config-mpls-te-if-gei-0/2/1/1)#auto-tunnel backup
2-69
SJ-20140731105308-012|2014-10-20 (R1.0)


0.0.0.0
area 0


2-70
SJ-20140731105308-012|2014-10-20 (R1.0)

0.0.0.0
area 0


The P1 router shows that the active tunnel and the auto-backup tunnel are formed.
P1(config)##show mpls traffic-eng tunnels brief
Signalling Summary:
running
RSVP Process:
running
Forwarding:
enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
2-71
SJ-20140731105308-012|2014-10-20 (R1.0)

tunnel_1
3.1.1.1
gei-0/2/1/1
up/up
tunnel_65535
3.1.1.1
gei-0/2/1/3
up/up
The P1 shows that the auto-backup protection relationship is formed.

P1(config)#show mpls traffic-eng fast-reroute
Protected Tunnel
Tunnel1
LspID
2
In-label
Out intf/label
FRR intf/label
Tun hd
gei-0/2/1/1:147456
Tu65535:3
Status
ready

LSP identifier
FRR intf/label
Status
When the active tunnel has a fault, the traffic will be handed over to the standby tunnel.
FRR is in active state. Check the FRR state on P1. When the fault on the active LSP
recovers, the FRR relationship recovers to ready state.
Protected Tunnel
Tunnel1
LspID
2
In-label
Out intf/label
FRR intf/label
Tun hd
gei-0/2/1/1:147456 Tu65535:3
Status
active

LSP identifier
FRR intf/label
Status
2.6.3.3 Establishing a Tunnel in Detour Protection Mode

As shown in Figure 2-16, the active tunnel1 is from R1 to R3 passes R1, R3 and R3.
Enable the FRR one-to-one protection on the active tunnel to form the detour protection
relationship. When the active LSP has a fault, the standby LSP protects it. Traffic is handed
over to the standby LSP.
2-72
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-16 Establishing a Tunnel in Detour Protection Mode
Configuration Flow
1. As shown in Figure 2-16, interconnect the R1, R2, R3 and R4, and configure the
loopback address and the interface address for each router.
2. Establish the OSPF neighbor relationship through the direct-connected interfaces on
the R1, R2, R3 and R4 and enable TE.
3. Configure the FRR one-to-one function on the head node of the tunnel in MPLS TE
mode. The specified strict path is R1-R2-R3.
4. Configure a static route to the destination on the R1. The next hop is Tunnel1. In this
case, the traffic is transmitted through the tunnel.
2-73
SJ-20140731105308-012|2014-10-20 (R1.0)

R1(config-mpls-te)# interface gei-0/0/1/4
R1(config-mpls-te-te_tunnel1)#tunnel destination ipv4 3.3.3.3
R1(config-mpls-te-te_tunnel1)#tunnel mpls traffic-eng path-option 1
explicit-path name zte
R1(config-mpls-te-te_tunnel1)#tunnel mpls traffic-eng record-route
R1(config-mpls-te-te_tunnel1)# tunnel mpls traffic-eng fast-reroute one-to-one
R1(config-mpls-te-)#exit
R1(config-mpls-te)#explicit-path name zte
R1(config-mpls-te-expl-path-name)#next-address strict 10.1.1.2
R1(config-mpls-te-expl-path-name)#next-address strict 40.1.1.3
R1(config-mpls-te-expl-path-name)#exit

255.255.255.255
2-74
SJ-20140731105308-012|2014-10-20 (R1.0)

0.0.0.0 area 0


0 0.0.0.0 area 0

2-75
SJ-20140731105308-012|2014-10-20 (R1.0)


255.255.255.255
0.0.0.0 area 0


255.255.255.0
The R1 router shows that the active tunnel and the detour tunnel are formed.
2-76
SJ-20140731105308-012|2014-10-20 (R1.0)

Signalling Summary:
running
RSVP Process:
running
Forwarding:
enabled
TUNNEL NAME
DESTINATION
tunnel_1
3.3.3.3
tunnel_1 (PLR backup)
3.3.3.3
UP IF
DOWN IF
STATE/PROT
gei-0/0/1/4
up/up
gei-0/0/0/7
up/up

Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit name zte (Basis for Setup)

Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
Detour Fast-reroute: enabled
BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
Affinity: 0x0/0x0
EBS: 0 byte
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
InLabel:-
2-77
SJ-20140731105308-012|2014-10-20 (R1.0)

OutLabel:gei-0/0/1/4,147456

RSVP Path Info:
Explicit Route: 10.1.1.1 10.1.1.2
Exclude
Route: NULL
Record
Route: NULL
40.1.1.2 40.1.1.3 3.3.3.3
RSVP Resv Info:
Record Route: 3.3.3.3 10.1.1.2 40.1.1.3
History:
Tunnel:
None log record.
Name: tunnel_1(PLR backup)(Tunnel) Destination: 3.3.3.3

Status:
Signalling: up

RSVP Path Info:
Explicit Route: 20.1.1.1 20.1.1.3 30.1.1.3 30.1.1.2 40.1.1.2
40.1.1.3
Exclude
Route: NULL
Record Route: NULL

RSVP Resv Info:
Record Route: 3.3.3.3
30.1.1.2
History:
Tunnel:
The R1 router shows that the detour protection relationship is formed.

R1(config)#show mpls traffic-eng fast-reroute
2-78
SJ-20140731105308-012|2014-10-20 (R1.0)

Protected Tunnel
Tunnel1
LspID
1
In-label
Tun hd
Out intf/label
gei-0/0/1/4:147456
FRR intf/label
Tu1:147457
Status
ready

LSP identifier
FRR intf/label
Status
When the active tunnel has a fault, the traffic will be handed over to the standby tunnel.
FRR is in active state. Check the FRR state on R1. When the fault on the active LSP
recovers, the FRR relationship recovers to ready state.
R1(config-if-gei-0/0/1/4)#show mpls traffic-eng fast-reroute
Protected Tunnel
LspID
In-label
Out intf/label
FRR intf/label
Status
Tunnel1
Tun hd
gei-0/0/1/4:147456
Tu1:147457
active
R1(config-if-gei-0/0/1/4)#show mpls traffic-eng fast-reroute

Protected Tunnel
LspID
In-label
Out intf/label
FRR intf/label
Status
Tunnel1
Tun hd
gei-0/0/1/4:147458
Tu1:147459
ready
2.6.3.4 TE-FRR Bandwidth Protection Configuration Instance

In Figure 2-17, a TE tunnel is established among P1-P2-P3 through IGP-TE, for which,
the available bandwidth is configured for the egress interface, the reserved bandwidth is
configured for the tunnel, and the FRR bandwidth protection is enabled. Multiple backup
tunnels are configured for P1-P2 and P1-P3 and a backup width is configured (after a
backup bandwidth is configured for a tunnel, the backup bandwidth is limited. If no backup
bandwidth is configured, the backup bandwidth is unlimited).
Figure 2-17 TE-FRR Bandwidth Protection Configuration Instance
After completing the configuration, you can see on the head node whether the FRR
bandwidth protection is enabled for the active tunnel and whether the backup bandwidth
of the standby tunnel is properly configured.
2-79
SJ-20140731105308-012|2014-10-20 (R1.0)
If no bandwidth is configured or a cti (i0) bandwidth is configured for the active tunnel,
you can only select the backup bandwidth as the unlimited backup tunnel (node protection
is prior to link protection).
If a common bandwidth or a ct0 bandwidth is configured for the active tunnel, a backup
tunnel with a limited backup bandwidth and a less bandwidth waste (node protection is prior
to link protection) is preferentially selected. If the limited backup tunnels are insufficient,
further select unlimited backup tunnels (node protection is prior to link protection).
After an FRR is established, you can check whether the number of the protection LSPs
and the backup bandwidth use on a backup tunnel are correct.
Configuration Flow
1. Configure the interfaces connecting P1, P2, and P3, and the corresponding loopback
interface addresses.
2. Configure OSPF neighbors for P1, P2, and P3, and enable the TE function on the
OSPF neighbors.
3. Enable the TE function on the loopback interfaces of P1, P2, and P3, and configure
the router-id of the TE as the loopback interface address.
4. Enable the TE function on the physical interfaces of P1, P2, and P3, and configure an
available bandwidth of 40 M for the egress interfaces of P1, P2, and P3.
5. Configure TE tunnel 1 on P1, for which, the destination address is set to P3, the explicit
path is set to strictly going through gei-0/1/0/1 of P1, the reserved bandwidth is set to
10 M, and the FRR facility bandwidth protection is enabled.
6. Configure tunnel2 on P1, for which, the destination address is set to P2, the explicit
10 M, and the backup bandwidth is set to 15 M.
7. Configure TE tunnel 3 on P1, the destination address to P2, the display path to
gei-0/1/0/2 of P1, the reserved bandwidth to 5 M, and configure a backup bandwidth
to 20 M.
to 9 M.
to 20 M.
10. Configure tunnel6 on P1, for which, the destination address is set to P3, the explicit
5 M, and the backup bandwidth is set to 20 M.
11. Configure backup tunnels tunnel2, 3, 4, 5, and 6 on the gei-0/1/0/1 interface.
The backup tunnels for TE-FRR bandwidth protection are selected in the following
sequence:
a. Because node protection is prior to link protection, tunnel 1 and tunnel 6 form FRR
protection.
2-80
SJ-20140731105308-012|2014-10-20 (R1.0)
b. If tunnel6 is disabled, tunnel 1 and tunnel 2 form FRR protection.

c.
If tunnel2 and tunnel3 are further disabled, tunnel 1 and tunnel 5 form FRR
protection.
d. If tunnel5 is further disabled, no FRR protection is formed.
P1#configure terminal
P1(config-mpls-te-if-gei-0/1/0/1)#bandwidth dynamic 40000
P1(config-mpls-te)#explicit-path name main
2-81
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#explicit-path name back-1
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng bandwidth 10000
bw-protect
explicit-path name main
P1(config-mpls-te-tunnel-te_tunnel2)#tunnel mpls traffic-eng backup-bw 15000
2-82
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te-tunnel-te_tunnel5)#exi
explicit-path name back-1

2-83
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-mpls-te)#

P3(config-mpls-te)#
2-84
SJ-20140731105308-012|2014-10-20 (R1.0)
1. After bandwidth protection is configured for a tunnel, run the show this command to
check the tunnel configuration and information. The execution result is displayed as
follows:
P1(config-mpls-te-tunnel-te_tunnel1)#show this
!<mpls-te>
tunnel destination ipv4 103.103.103.103
tunnel mpls traffic-eng bandwidth 10000
tunnel mpls traffic-eng record-route
tunnel mpls traffic-eng fast-reroute facility bw-protect
tunnel mpls traffic-eng path-option 1 explicit-path name main
!</mpls-te>
P1(config-mpls-te-tunnel-te_tunnel1)#show mpls traffic-eng tunnels te_tunnel 1
/*If the Bandwidth Protection field is set to enabled, the FRR bandwidth
protection is enabled.*/
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit name: main (Basis for Setup)

Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
Facility Fast-reroute: enabled
Bandwidth Protection: enabled
BFD: disabled
Policy Class: Default
Track Name:
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Affinity(Bit position):
Exclude-any: None
Include-any: None
2-85
SJ-20140731105308-012|2014-10-20 (R1.0)

Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
Without-CSPF: disabled
Src 101.101.101.101, Dst 103.103.103.103, Tun-ID 1, Tun-Instance 4
RSVP Path Info:
Explicit Route: 1.1.1.1 1.1.1.2 9.1.1.2 9.1.1.4 103.103.103.103
Exclude Route: NULL
Record Route: NULL
Tspec: ave rate= 10000 kb, burst= 0 byte, peak rate= 10000 kb
RSVP Resv Info:
Record Route: 102.102.102.102(147457) 1.1.1.2(147457) 103.103.103.103(3)
9.1.1.4(3)
Fspec: ave rate= 10000 kb, burst= 0 byte, peak rate= 10000 kb
History:
Tunnel:
Time Since Created: 0 day, 0 hour, 18 minute, 3 second
Current LSP: Uptime:0 day, 0 hour, 15 minute, 40 second
Last LSP Error Information:
2. Run the show mpls traffic-eng tunnels backup command to check the information
about a backup tunnel after a backup bandwidth is configured for the backup tunnel.
The execution result is displayed as follows, in which, the Backup BW field is the
configured backup bandwidth.
P1#show mpls traffic-eng tunnels backup
Name: tunnel_2
LSP Head: Tunnel2
Admin: up
Oper: up
Src:101.101.101.101,Dest: 102.102.102.102,Instance:1
Fast Reroute Backup Provided:
Protected i/fs: gei-0/1/0/1
Protected lsps: 0
Backup BW: 15000 kbps; inuse: 0 kbps
Name: tunnel_3
2-86
SJ-20140731105308-012|2014-10-20 (R1.0)

LSP Head: Tunnel3
Admin: up
Oper: up
Protected lsps: 0
Name: tunnel_4
LSP Head: Tunnel4
Admin: up
Oper: up
Protected lsps: 0
Name: tunnel_5
LSP Head: Tunnel5
Admin: up
Oper: up
Protected lsps: 0
Backup BW: unlimited; inuse: 0 kbps
Name: tunnel_6
LSP Head: Tunnel6
Admin: up
Oper: up
Protected lsps: 1
3. After FRR protection is formed, run the following commands to check the selected
optimum backup tunnel:
Protected Tunnel
LspID In-label Out intf/label
FRR intf/label
Status
Tunnel1
Tu6:3
ready
FRR intf/label
Status
Tun hd
gei-0/1/0/1:147457

LSP identifier
4. After FRR protection is formed, run the show mpls traffic-eng tunnels backup command
to check the backup tunnel information. The execution result is displayed as follows,
in which, the Protected lsps field is the number of the LSPs under the protection of
the backup tunnel, and the inuse field is the used backup bandwidth of the backup
tunnel.
P1#show mpls traffic-eng tunnels backup
Name: tunnel_2
LSP Head: Tunnel2
Admin: up
Oper: up
2-87
SJ-20140731105308-012|2014-10-20 (R1.0)

Protected lsps: 0
Name: tunnel_3
LSP Head: Tunnel3
Admin: up
Oper: up
Protected lsps: 0
Name: tunnel_4
LSP Head: Tunnel4
Admin: up
Oper: up
Protected lsps: 0
Name: tunnel_5
LSP Head: Tunnel5
Admin: up
Oper: up
Protected lsps: 0
Backup BW: unlimited; inuse: 0 kbps
Name: tunnel_6
LSP Head: Tunnel6
Admin: up
Oper: up
Protected lsps: 1
Backup BW: 20000 kbps; inuse: 10000 kbps (BWP inuse: 10000 kbps)
2.6.3.5 Instance of Configuration for HOT_LSP Supporting TE-FRR

In Figure 2-18, an end-to-end MPLS-TE path protection tunnel is established by using
IGP-TE, the FRR is enabled (facility or one-to-one), and the HOT_LSP is configured
to support TE-FRR. Take ISIS-TE as example, the path of the active LSP Tunnel1 is
the yellow solid line P1->P2->P3, the Tunnel HOT-LSP path is the black dotted line
P1->P4->P2->P3, a backup tunnel Tunnel2 (P2->P4->P5->P3) protection link P2->P3 is
configured on P2.
2-88
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-18 Instance of Configuration for HOT_LSP Supporting TE-FRR
Configuration Flow
1. Configure a loopback address and interface address on each of five devices.
2. Establish the ISIS neighbor relation for all interfaces interconnected in the network,
enable the TE function on the ISIS and interfaces.
3. Configure an MPLS-TE end-to-end path protection tunnel Tunnel1 on P1 to P3,
enable the active LSP to strictly route along P1->P2->P3, and the HOT-LSP along
P1->P4->P2->P3, and enable the FRR facility function.
4. Configure a proper HOT_LSP FRR protection relation on P1 and a protection link
P2-P3 for backup tunnel Tunnel2 (P2->P4->P5->P3) on P2 to form a proper FRR link
protection on P2.
5. If the P1-P2 link becomes invalid, the FRR protection relation on P1 becomes active,
but the FRR protection relation on P2 is not affected, which is still ready.
6. If the P1-P2 link becomes invalid again, the FRR protection relation on both P1 and
P2 is active.
Interface configurations:
2-89
SJ-20140731105308-012|2014-10-20 (R1.0)

ISIS and ISIS-TE configurations:
P1(config-isis-10)#system-id 0000.4444.4444
P1(config-isis-10)#is-type level-1
MPLS-TE configurations:
P1(config-mpls-te)#explicit-path name main
P1(config-mpls-te)#explicit-path name hot-lsp
explicit-path name main
2-90
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng hot-standby protect 1
explicit-path name hot-lsp
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng hot-standby-lsp
fast-reroute

2-91
SJ-20140731105308-012|2014-10-20 (R1.0)

P2 (config-mpls-te-if-gei-0/1/0/18)#exit
P2(config-mpls-te)#explicit-path name P2-P4-P5-P3
explicit-path name P2-P4-P5-P3

P3(config-isis-10)#system-id 2008.561c.41a2
2-92
SJ-20140731105308-012|2014-10-20 (R1.0)


P4(config-if-gei-0/2/0/1)# ip address 208.72.52.72 255.255.255.0
2-93
SJ-20140731105308-012|2014-10-20 (R1.0)


2-94
SJ-20140731105308-012|2014-10-20 (R1.0)

1. Run the show mpls traffic-eng tunnels brief command to check the status of the active
LSP and HOT-LSP on P1. The execution result is displayed as follows, in which up/up
indicates that the active LSP and HOT-LSP are activated.
P1(config-mpls-te)#show mpls traffic-eng tunnels brief
Signalling Summary:
LSP Tunnels Process:running
RSVP Process:running
Forwarding:enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_1
73.73.73.2
gei-0/1/0/13
up/up
tunnel_1 (hot)
73.73.73.2
gei-0/1/0/7
up/up
2. Run the show mpls traffic-eng tunnels command to check the information about the
active LSP and HOT-LSP. The execution result is displayed as follows:
P1(config-mpls-te)#show mpls traffic-eng tunnels
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit name: main (Basis for Setup)

protect option: 1, type explicit name: hot-lsp (Basis for Protect)
Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
2-95
SJ-20140731105308-012|2014-10-20 (R1.0)

BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
Include-any: None
Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
RSVP Path Info:
Explicit Route: 1.0.13.4 1.0.13.52 15.73.52.52 15.73.52.73 73.73.73.2
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: 52.52.52.100(212992) 1.0.13.52(212992) 73.73.73.2(147456) 15
.73.52.73(147456)
History:
Tunnel:
2-96
SJ-20140731105308-012|2014-10-20 (R1.0)

Path-option config changed(lspid:139,errcode:1,errvalue:2).
Tunnel destination changed(lspid:137,errcode:1,errvalue:4).
Name: tunnel_1
(hot) (Tunnel1) Destination: 73.73.73.2
Status:
Signalling: up
Config Parameters:
BFD: disabled
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
Include-any: None
Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
RSVP Path Info:
Explicit Route: 107.44.44.4 107.44.44.72 208.72.52.72 208.72.52.52 15.73.52.52
15.73.52.73 73.73.73.2
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: 72.72.72.1(147458) 107.44.44.72(147458) 52.52.52.100(212994)
208.72.52.52(212994) 73.73.73.2(147462) 15.73.52.73(147462)
2-97
SJ-20140731105308-012|2014-10-20 (R1.0)

History:
Tunnel:
Tunnel destination changed(lspid:137,errcode:1,errvalue:4).
3. Run the show mpls traffic-eng tunnels hot-standby command to check the details of
the HOT-LSP. The execution result is displayed as follows, in which, Hot-standby
Protection:ready indicates that FRR protection is enabled.
P1(config-mpls-te)#show mpls traffic-eng tunnels hot-standby
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Fast Reroute Protection: none

Hot-standby Protection: ready
Config Parameters:
BFD: disabled
RSVP Path Info:
Explicit Route: 107.44.44.4 107.44.44.72 208.72.52.72 208.72.52.52 15.73.5
2.52 15.73.52.73 73.73.73.2
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: 72.72.72.1(147458) 107.44.44.72(147458) 52.52.52.100(212994)
208.72.52.52(212994) 73.73.73.2(147462) 15.73.52.73(147462)
2-98
SJ-20140731105308-012|2014-10-20 (R1.0)
4. Run the show mpls traffic-eng fast-reroute command on P1 to check the FRR protection
relation. The execution result is displayed as follows, in which, ready indicates that
the FRR protection relation is properly established.
P1(config-mpls-te)#show mpls traffic-eng fast-reroute
Protected Tunnel
Tunnel1
143 Tun hd
gei-0/1/0/13:212992
FRR intf/label
Status
Tu1:147458
ready
FRR intf/label
Status

LSP identifier
P1(config-mpls-te)#
5. Run the show mpls traffic-eng tunnels brief command on P2 to check the status of the
backup tunnel Tunnel2. The execution result is displayed as follows, in which, up/up
indicates that Tunnel2 is properly established.
Signalling Summary:
Forwarding:enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_2
73.73.73.2
gei-0/1/0/18
up/up
6. Run the show mpls traffic-eng tunnels te_tunnel 2 command on P2 to check the details
of the backup tunnel Tunnel2. The execution result is displayed as follows:
Name: tunnel_2
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit name: P2-P4-P5-P3 (Basis for Setup)

Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
BFD: disabled
Track Name:
2-99
SJ-20140731105308-012|2014-10-20 (R1.0)

CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
Include-any: None
Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
RSVP Path Info:
Explicit Route: 208.72.52.52 208.72.52.72 13.13.13.1 13.13.13.2 14.1.1.1
14.1.1.2 73.73.73.2
7. Run the show mpls traffic-eng fast-reroute command on P2 to check the FRR link
protection configuration. The execution result is displayed as follows, in which, the
protection link P2->P3 of the backup tunnel Tunnel2 is displayed.
Protected Tunnel
FRR intf/label
Status

LSP identifier
FRR intf/label
Status
4.4.4.100 1/183
212992
gei-0/1/0/15:147456
Tu2:147457
ready
4.4.4.100 1/184
212993
gei-0/1/0/15:147461
Tu2:147457
ready
8. When the P1->P2 link is invalid, the FRR protection relation on P1 becomes active,
for example:
P1(config-if-gei-0/1/0/13)#shutdown
P1(config-if-gei-0/1/0/13)#show mpls traffic-eng fast-reroute
2-100
SJ-20140731105308-012|2014-10-20 (R1.0)

Protected Tunnel
Tunnel1
162 Tun hd
FRR intf/label
Status
Tu1:147459
active
gei-0/1/0/13:212992
Run the show mpls traffic-eng tunnels brief command on P1 to check the information
about Tunnel1. The execution result is displayed as follows:
P1(config-if-gei-0/1/0/13)#show mpls traffic-eng tunnels brief
Signalling Summary:
Forwarding:enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_1
73.73.73.2
gei-0/1/0/7
up/up
P1(config-if-gei-0/1/0/13)#show mpls traffic-eng tunnels te_tunnel 1

Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit name: main

protect option: 1, type explicit name: hot-lsp (Basis for Protect)
Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
Include-any: None
Include-all: None
2-101
SJ-20140731105308-012|2014-10-20 (R1.0)

AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
RSVP Path Info:
Explicit Route: 107.44.44.4 107.44.44.72 208.72.52.72 208.72.52.52 15.73.52.52
15.73.52.73 73.73.73.2
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: 72.72.72.1(147459) 107.44.44.72(147459) 52.52.52.100(212993)
208.72.52.52(212993) 73.73.73.2(147460) 15.73.52.73(147460)
Run the show mpls traffic-eng tunnels hot-standby command on P1 to check the
HOT-LSP protection relation. The execution result is displayed as follows, in which,
backup lsp in use indicates that the traffic on P1 is forwarded through HOT-LSP.
P1(config-if-gei-0/1/0/13)#show mpls traffic-eng tunnels hot-standby
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Fast Reroute Protection: none

Hot-standby Protection: backup lsp in use
Config Parameters:
BFD: disabled
2-102
SJ-20140731105308-012|2014-10-20 (R1.0)
Run the show mpls traffic-eng fast-reroute command on P2 to check the FRR protection
relation. The execution result is displayed as follows, in which, FRR protection relation
is still ready, without being affected.
LSP identifier
FRR intf/label
Status
4.4.4.100 1/162
212992
Tu2:147462
ready
gei-0/1/0/15:147456
9. If the P2->P3 link also becomes invalid, the FRR protection relation on both P1 and
P2 is active, for example:
P2(config-if-gei-0/1/0/15)#show mpls traffic-eng fast-reroute
Protected Tunnel
FRR intf/label
Status

LSP identifier
FRR intf/label
Status
4.4.4.100 1/184
212993
Tu2:147457
active
gei-0/1/0/15:147461
When the P2->P3 link is restored, the FRR protection relation on both P1 and P2 is
active. Only when the P1->P2 link is also restored, can the FRR protection relation on
P1 and P2 be restored to ready.
2.7 FRR Promotion Introduction

2.7.1 FRR Promotion Introduction
Overview
Multiple backup tunnels can be configured on an interface. The FRR promotion function
is used to properly adjust the protection relationships between active and backup tunnels.
For example, if an interface has a backup tunnel only (Tunnel1), only a link protection
relationship can be established between active and backup tunnels. If another backup
tunnel (Tunnel2) is configured on the interface, a node protection relationship can be
established between the backup tunnel and active tunnel by using FRR promotion.
Implementation
After the FRR relationship is established manually, if the corresponding node has FRR
promotion enabled, the FRR relationship is deleted and a new FRR relationship is
established. The process is as follows:
1. Select the optimal backup tunnel for establishing an FRR relationship (facility
mode-based protection).
2. Configure FRR attributes on the protected tunnel.
2-103
SJ-20140731105308-012|2014-10-20 (R1.0)
3. Configure the ID of the backup tunnel on the egress interface of the protected tunnel.
A maximum of 16 tunnels can be configured on an egress interface for FRR protection.
4. Configure FRR promotion: select the optimal tunnel from the configured 16 tunnels,
and establish an FRR relationship between the optimal tunnel and protected tunnel.
The priorities of the conditions for selecting the optimal backup tunnel is as follows:
protection type>bandwidth for backup tunnels>pooling mechanism.
5. FRR promotion takes effect for the backup tunnels in ready status only.
2.7.2 Configuring FRR Promotion

This procedure describes how to configure FRR promotion.
Context
FRR promotion should be configured on an PLR node generated in FRR protection.
Steps
1. To enable MPLS TE, run the following command:
Command
Function

2. To enable FRR promotion, perform the following steps:

Step
Command
Function
ZXR10(config-mpls-te)#fast-reroute promote
Enables FRR promotion

manually.
ZXR10(config-mpls-te)#fast-reroute timers promotion
Enables the FRR promotion

timer.
ZXR10(config-mpls-te)#fast-reroute timers promotion
Configures a periodic interval
interval <interval>
for running FRR promotion.
3. To display the configuration results, run the following command:

Command
Function
ZXR10#show mpls traffic-eng fast-reroute promotion
Displays the FRR promotion

information.
End of Steps
2-104
SJ-20140731105308-012|2014-10-20 (R1.0)
2.7.3 FRR Promotion Configuration Examples

2.7.3.1 FRR Promotion Configuration Example (Node Protection Having a Higher
Priority than Link Protection)
Figure 2-19 shows a sample network topology. It is required to establish a primary tunnel
(Tunnel1) from P1 to P3 and two backup tunnels (Tunnel2 and Tunnel3). Tunnel1 should
pass through P1, P2, and P3, Tunnel2 should pass through P1 and P2, and Tunnel3 should
pass through P1 and P3. Tunnel2 provides link protection, and Tunnel3 provides node
protection.
Figure 2-19 FRR Promotion Configuration Example (Node Protection Having a Higher
Priority than Link Protection)
Configuration Flow
1. Establish OSPF neighbor relationships between the directly-connected interfaces of
P1, P2, and P3, and enable OSPF TE.
2. Establish three tunnels. Tunnel1 (primary tunnel) should pass through P1, P2, and
P3, Tunnel2 (backup tunnel) should pass through P1 and P2, and Tunnel3 (backup
tunnel) should pass through P1 and P3.
3. Enable FRR promotion in the TE configuration mode of P1.
4. Configure Tunnel2 and Tunnel3 to be backup tunnels on the gei-0/2/1/1 interface of
P1.
2-105
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#explicit-path name back1
P1(config-mpls-te)#explicit-path name back2
2-106
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#fast-reroute promote
P1(config-mpls-te)#fast-reroute timers promotion
P1(config-mpls-te)#fast-reroute timers promotion interval 60
path-option 1 explicit-path name primary
fast-reroute facility
P1(config-mpls-te- tunnel-te_tunnel2)#tunnel mpls traffic-eng
path-option 1 explicit-path name back1
path-option 1 explicit-path name back2

2-107
SJ-20140731105308-012|2014-10-20 (R1.0)


2-108
SJ-20140731105308-012|2014-10-20 (R1.0)

After the tunnel goes up, run the show mpls traffic-eng tunnels brief command on P1 to
check whether FRR relationships have been established. The execution result is displayed
as follows:
Signalling Summary:
Forwarding: enabled
tunnel_1 3.1.1.1 - gei-0/2/1/1 up/up
tunnel_22.1.1.1 - gei-0/2/1/4 up/up
tunnel_33.1.1.1 - gei-0/2/1/3 up/up

Protected Tunnel LspIDIn-label Out intf/label FRR intf/label Status
Tunnel186 Tun hd gei-0/2/1/1:147456Tu3:3
ready

LSP identifierIn-label Out intf/label FRR intf/label Status
P1(config)#show mpls traffic-eng fast-reroute promotion

MPLS-TE: Enabled
Periodic FRR Promotion: every 60 seconds, next in 4 second
2.7.3.2 FRR Configuration Example (Bandwidth for Backup Tunnels Being Met)
Figure 2-20 shows a sample network topology. It is required to establish the primary tunnel
(Tunnel1 has a 5000 kbps bandwidth) from P1 to P2 and two backup tunnels (Tunnel2 has
a 6000 kbps bandwidth and Tunnel3 has a 5000 kbps bandwidth) through other two links.
Moreover, FRR promotion should be enabled to establish an FRR relationship between
P1 and P2.
2-109
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-20 FRR Configuration Example (Bandwidth for Backup Tunnels Being Met)
Configuration Flow
P1 and P2, enable OSPF TE, and configure the bandwidth.
2. Establish three strict paths. The primary path is configured between the gei-0/1/0/2
interfaces of P1 and P2, and two backup paths are respectively configured between
the gei-0/1/0/3 interfaces and between the gei-0/1/0/4 interfaces of P1 and P2.
3. Establish the primary tunnel (Tunnel1 with a 5000 kbps bandwidth) and two backup
tunnels (Tunnel2 with a 6000 kbps bandwidth and Tunnel3 with a 5000 kbps
bandwidth).
4. Enable FRR promotion, and configure Tunnel2 and Tunnel3 to be backup tunnels on
the egress interface (gei-0/1/0/2) of the primary tunnel of P1.
2-110
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#fast-reroute timers promotion

P1(config-mpls-te)#fast-reroute timers promotion interval 60
P1(config-mpls-te-if-gei-0/1/0/2)#bandwidth 20000
2-111
SJ-20140731105308-012|2014-10-20 (R1.0)

bandwidth 5000
backup-bw 6000
backup-bw 5000

2-112
SJ-20140731105308-012|2014-10-20 (R1.0)

After the tunnel goes up, run the show mpls traffic-eng tunnels brief command on P1 to
check whether an FRR relationship has been enabled. The execution result is displayed
as follows:
Signalling Summary:
Forwarding: enabled
tunnel_12.1.1.1 -gei-0/1/0/2 up/up
tunnel_22.1.1.1 -gei-0/1/0/3 up/up
tunnel_32.1.1.1 -gei-0/1/0/4 up/up

Protected Tunnel LspID In-label Out intf/label FRR intf/label Status
Tunnel176
Tun hd gei-0/1/0/2:3 Tu3:3
ready

P1(config)#show mpls traffic-eng fast-reroute promotion

MPLS-TE: Enabled
Periodic FRR Promotion: every 60 seconds, next in 4 second
2-113
SJ-20140731105308-012|2014-10-20 (R1.0)
2.8 FRR-Hello Configuration

2.8.1 FRR Hello Introduction
Overview
RSVP FRR protection is a local protection technology used to provide link or node
protection for TE tunnels. When a PLR detects a failure on its downstream node, it
enables the traffic to bypass the faulty link or node along a backup tunnel.
Due to the fast switchover requirements of RSVP FRR, the corresponding fast fault
detection techniques are needed, such as the widespread BFD detection and MPLS
OAM detection. In some cases, however, fault detection on neighbors cannot be
implemented due to some reasons (for example, users do not use the corresponding
detection techniques or neighbor failures are not detected in time). It is required for RSVP
itself to provide one neighbor failure detection technology (RSVP hello fault detection
mechanism).
Implementation
To implement RSVP FRR hello, IETF RFC defines and describes the implementation
process of the function.
RFC defines an extended hello message mechanism. This mechanism provides the basics
of the RSVP-TE FRR HELLO technology, and enables nodes to detect when neighbors
become unreachable or reboot. It also defines an hello object and an hello message (for
more information, refer to the "GR Introduction" section).
The loss of neighbors may be caused by the loss of neighbors on the link-layer plane or
protocol-layer plane. BFD detection can only detect the loss of neighbors on the link-layer
plane, and therefore a technology for detecting the loss of neighbors on the protocol-layer
plane is required (that is, FRR HELLO detection).
RSVP HELLO messages are sent to neighboring devices through a local interface to detect
the reachability. If neighbors cannot be detected, FRR reroute starts to operate on the local
device.
Features
l
A hello component sends a message to detect the reachability of a hello neighbor.

If no hello-ack message is received from the neighbor during the interval misses
period, the neighbor is considered to be unreachable
If a neighbor is considered to be unreachable, FRR switchover is then triggered by
using the MBB technology.
2.8.2 Configuring FRR Hello

This procedure describes how to configure FRR hello.
2-114
SJ-20140731105308-012|2014-10-20 (R1.0)
Context
FRR hello should be configured on the PLR node generated in FRR protection and the
signalling interface of the protected tunnel associated with a neighbor.
The FRR Hello function is conflicted with the GR function.
Steps
Command
Function

2. To enable FRR Hello, perform the following steps:

Step
Command
Function
ZXR10(config-mpls-te)#signalling hello
Enables FRR Hello globally.
Enters the signalling interface

to be protected.
ZXR10(config-mpls-te-if-interface-name)#signall
Enables FRR Hello on the
ing hello
interface.
ZXR10(config-mpls-te-if-interface-name)#signal
Sets the time interval (in
ling hello refresh interval <interval>
milliseconds) for refreshing

hello messages, range:
100030000.
ZXR10(config-mpls-te-if-interface-name)#signall
ing hello refresh misses <num>
times that hello messages can

be lost, range: 410.

Command
Function
ZXR10#show ip rsvp hello instance summary
Displays the summary

information about RSVP Hello
instances.
ZXR10#show ip rsvp hello instance detail
Displays the detailed information

about RSVP Hello instances.
4. To enable FRR Hello, run the following command:
2-115
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#debug rsvp hello
Enables the debugging of FRR

Hello.
End of Steps
2.8.3 FRR Hello Configuration Example

Figure 2-21 shows a sample network topology. It is required to establish two tunnels (with
an FRR relationship between them) from P1 to P3 and enable FRR hello on P1 and P2.
Tunnel 1 (active tunnel) passes through P1, P2, and P3, and Tunnel2 (backup tunnel)
passes through P1 and P3.
Figure 2-21 FRR Hello Configuration Example
Configuration Flow
1. Establish OSPF neighbor relationships between the directly-connected interfaces of
P1, P2, and P3, and enable OSPF TE.
2. Establish two strict paths. The active path is P1>P2>P3, and the backup path is
P1>P3.
3. Enable TE on the interfaces of P1, P2, and P3, and configure the backup tunnel on
the gei-0/2/1/1 interface of P1.
4. Establish active and backup tunnels. Enable FRR facility on the active tunnel (the
destination is the router-id of P2, and the path is a strict path).
5. Enable FRR hello on P1 and P2.
2-116
SJ-20140731105308-012|2014-10-20 (R1.0)
P1(config-mpls-te-expl-path-name)# next-address strict 74.1.1.1
2-117
SJ-20140731105308-012|2014-10-20 (R1.0)

path-option 1 explicit-path name primary
P1(config-mpls-te- tunnel-te_tunnel2)#tunnel mpls traffic-eng
path-option 1 explicit-path name back
P1(config-mpls-te)#signalling hello
P1(config-mpls-te-if-gei-0/2/1/1)#signalling hello

2-118
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-mpls-te)# signalling hello

P2(config-mpls-te-if-gei-0/2/1/1)#signalling hello

2-119
SJ-20140731105308-012|2014-10-20 (R1.0)
After the tunnel goes up, run the show mpls traffic-eng tunnels brief command on P1
to check the status of FRR.
Signalling Summary:
Forwarding: enabled
STATE/PROT
tunnel_1
3.1.1.1
gei-0/2/1/1
up/up
tunnel_2
3.1.1.1
gei-0/2/1/3
up/up

Protected Tunnel LspID In-label Out intf/label FRR intf/label Status
Tunnel1 86 Tun hd gei-0/2/1/1:147456 Tu2:3 ready

LSP identifier In-label Out intf/label FRR intf/label Status
R5(config)#show ip rsvp hello instance summary

Client I/F Neighbor Type State LostCnt LSPs
FRR gei-0/2/1/1 74.1.1.1 ACTIVE UP 0 1
R5(config)#show ip rsvp hello instance detail

Hello Graceful Restart globally disabled
Fast-Hello globally enabled
Neighbor 74.1.1.1 Source 74.1.1.2
Clients:Fast Reroute
State:UP
Type:ACTIVE
I/F: gei-0/2/1/1
LSP num:1
Src_instance 30138456, Dst_instance 28778033
GR HELLO parameters
Refresh Misses Configured:4
Refresh Interval (msec)
Configured:10000
Current :0
Local restart time (msec):120000
Local recovery time (msec):120000
Nbr restart time (msec):0
Nbr recovery time (msec):0
Lost count:0
2-120
SJ-20140731105308-012|2014-10-20 (R1.0)

intf hello
FRR HELLO parameters
Fast_hello_period (msec):10000
Fast_hello_miss:4
Fast_hello_protect_lsps:1
Fast_hello_lost_count:0
Fast_hello_del_time (msec):0
Fast_hello_reroute_time (msec):5900
2.9 MPLS TE End-to-End Protection Path Configuration

2.9.1 MPLS TE End-to-End Path Protection Overview
Both TE FRR and Hot_standby are used to protect the RSVP-TE tunnel. The TE FRR is
used for part protection and the Hot_standby is used for the a single LSP protection from
the head node to the tail node (end-to-end protection).
For the end-to-end protection, a Hot_standby_lsp path is created in advance for one
working LSP before a fault occurs. The paths of these two LSPs on the tunnel do not
intersect except the head node and the tail node. In general, the traffic is transmitted
through the working LSP path. Only when the link or the node of the working LSP is faulty
the traffic passes the Hot_standby_lsp path after the handover.
When a tunnel is established, two LSPs with different paths are established.
l
l
l
Each LSP has its own label switching item. On the head node, the egress interface
and the next hop address are different. The out-label could be the same or be different.
In general, one LSP is set as the primary LSP and another LSP is set as the second
LSP.
On the switching layer, the switching items of these two LSPs are written and the
relationship is bound. In general, the switching item of the primary LSP is used for
switching. Once when the path of the primary LSP is faulty, the switching layer hands
over the traffic to the second LSP. In this case, the fast handover for the hot-backup
item is implemented.
After the handover, the RSVP-TE protocol tries to re-establish a primary LSP. If the
primary LSP is established successfully, the traffic is handed over to this primary LSP
after the switching item of the primary LSP is written.
2.9.2 Path Configuration for MPLS TE End-to-End Protection

This procedure describes how to configure MPLS TE End-to-End Protection.
Steps
1. Configure MPLS TE End-to-End Protection.
2-121
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Commands
Functions
<tunnel-number>
configuration mode.
ZXR10(config-mpls-te-tunnel-te_tunnel-
Enables the hot-standby function
tunnel-number)#tunnel mpls traffic-eng hot-standby
for the specified path option on
protect <protected-path-option-id>{dynamic [
the tunnel.
prefer]|explicit-path {identifier <explicit-path-identifie

r-id>|name <explicit-path-of-name>}[exclude]}
<protected-path-option-id>: specifies the active path-option that the standby LSP needs
to protect, range: 1-16.
dynamic: Specifies the dynamic calculation mode for the path of the standby LSP. If
the prefer option is not configured, the active and standby paths cannot be overlapped
except the head and tail nodes.
prefer: Specifies the dynamic calculation mode for the path of the standby LSP. If this
option is configured, the active and standby paths cannot be completely overlapped.
identifier: Specifies the identity mode for the explicit path of the standby LSP.
<explicit-path-identifier-id>: explicit path ID used by the standby LSP, range: 1-65535.
name: Specifies the name mode for the explicit path of the standby LSP.
<explicit-path-of-name>: explicit path name used by the standby LSP, range: 1-64
characters.
exclude: specifies the hot standby path and forcibly excludes the active path.
2. To display the configuration results, run the following command:
Commands
Functions
ZXR10#show mpls traffic-eng tunnels hot-standby
Displays the detailed information about

the backup LSPs in hot-standby LSP
protection.
End of Steps
2.9.3 Establishing an MPLS TE End-to-End Path Protection

As shown in Figure 2-22, there is an MPLS TE end-to-end path protection tunnel created
through the OSPF-TE protocol in the network. The path for working LSP is R1-R2 and the
path for Hot_standby_lsp is R1-R3-R2.
2-122
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-22 Establishing an MPLS TE End-to-End Path Protection
Configuration Flow
1. As shown in Figure 2-22, interconnect the R1, R2 and R3, and configure the loopback
address and the interface address for each router.
2. Establish the OSPF neighbor relationship through the direct-connected interfaces on
the R1, R2 and R3 and enable TE.
3. Configure the hot-standby function on the head node of the tunnel in MPLS TE mode.
The specified strict path is R1-R2.
4. Check the hot-standby relationship.
5. Configure a static route to the destination on the R1 router. The next hop is Tunnel1.
6. Check the hot-standby relationship when the link of the primary tunnel is invalid.
7. Check the hot-standby relationship when the link of the primary tunnel recoveries
normally.
Interface related configuration:
2-123
SJ-20140731105308-012|2014-10-20 (R1.0)

OSPF and OSPF-TE related configuration:

R1(config-mpls-te)#explicit-path name zte
R1(config-mpls-te-expl-path-name)# next-address strict 10.1.1.2
R1(config-mpls-te)#explicit-path name hot
explicit-path name zte
R1(config-mpls-te-tunnel-te_tunnel1)# tunnel mpls traffic-eng record-route
R1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng hot-standby
protect 1 explicit-path name hot
2-124
SJ-20140731105308-012|2014-10-20 (R1.0)

255.255.255.255

R2(config-ospf-1)#network 2.2.2.2 0 0.0.0.0 area 0
MPLS-TE related configuration:


255.255.255.255
2-125
SJ-20140731105308-012|2014-10-20 (R1.0)



255.255.255.0
Check the R1 to see the status information of the tunnel:
R1#show mpls traffic-eng tunnels brief
Signalling Summary:
running
RSVP Process:
running
Forwarding:
TUNNEL NAME
enabled
DESTINATION
tunnel_1
tunnel_1(hot)
UP IF
DOWN IF
2.2.2.2
2.2.2.2
STATE/PROT
gei-0/0/1/4
up/up
gei-0/0/0 /7
up/up
Check the protection relationship between the hot-standby LSP and the LSP:
R1(config-if)#show mpls traffic-eng tunnels hot-standby
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Signaling: connected
Fast Reroute Protection:disabled
2-126
SJ-20140731105308-012|2014-10-20 (R1.0)

Hot-standby Protection: Ready
Config Parameters:
BFD: disabled
RSVP Signaling Info :
RSVP Path Info:
Explicit Route: 20.1.1.1 20.1.1.3 30.1.1.2
Exclude
30.1.1.3 2.2.2.2
Route: NULL
20.1.1.1
RSVP Resv Info:
20.1.1.3 2.2.2.2
30.1.1.2
When the link of the primary LSP is down, check the protection relationship between
hot-standby LSP and the primary LSP.
R1(config-if-gei-0/0/1/4)#shutdown
R1(config-if-gei-0/0/1/4)#show mpls traffic-eng tunnels hot-standby
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Signaling: connected
Fast Reroute Protection:disabled

Hot-standby Protection: Backup lsp in use
Config Parameters:
BFD: disabled
When the link of the primary LSP recoveries normal, check the protection relationship
between hot-standby LSP and the primary LSP.
After the recovery, the detailed information of the primary LSP and the hot-standby LSP
tunnel is as follows:
R1(config-if)#show mpls traffic-eng tunnels te_tunnel 1
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit name zte (Basis for Setup)

protect option: 1, type explicit name: hot (Basis for Protect)
Config Parameters:
Affinity: 0x0/0x0
Resv-Style: SE
2-127
SJ-20140731105308-012|2014-10-20 (R1.0)

BFD: disabled
Bidirect: disabled
AutoRoute: disabled
RSVP Path Info:
Explicit Route: 10.1.1.1 10.1.1.2 2.2.2.2
Exclude
Route: NONE
Record
Route: NONE

RSVP Resv Info:
Record
Route: 2.2.2.2 10.1.1.2
History:
Tunnel:
Time since path change: 0 days, 0 hours, 0 minutes
Prior LSP: path option 1 [27]
Delete mbb old inuse lsp(lspid:2,errcode:1,errvalue:1).
Path error:rsvp sys error(lspid:3,errcode:23,errvalue:0).
Path error:routing error,no route to destination(lspid:1,errcode:24,errvalue:5)
2.10 Loose Node Re-optimization

2.10.1 Loose Node Re-optimization Introduction
Loose node re-optimization refers to triggering an intermediate node whose next hop is
a loose or abstract node in the LSP path to check whether there is a better local route
in accordance with a scheme. If there is, the route is notified to the head node, which
determines whether to re-optimize the LSP.
2.10.2 Configuring Loose Node Re-optimization

This procedure describes how to configure loose node re-optimization.
2-128
SJ-20140731105308-012|2014-10-20 (R1.0)
Steps
1. (Optional) Configure the loose node re-optimization function.
Step
Command
Function
ZXR10(config-mpls-te)#reoptimize loose-node
Enables the loose node

re-optimization function.
ZXR10(config-mpls-te)#reoptimize timers frequency
Configures the re-optimization
<frequency>
frequency.
<tunnel-number>
configuration mode.
Enables the re-optimization
number)#tunnel mpls traffic-eng auto-reoptimize{
function on the active or
main-lsp | hsb-lsp}
standby LSP.
2. Verify the configurations.

Command
Function
ZXR10#show mpls traffic-eng tunnels summary
Checks whether the loose

node re-optimization function is
successfully configured.
Checks whether the

re-optimization function is
enabled on the tunnel.
End of Steps
2.10.3 Loose Node Re-optimization Configuration Instance

In Figure 2-23, an MPLS TE tunnel is established through OSPF-TE. The tunnel path is
P1->P2->P3, and the explicit path is loosened to P2 first and then P3.
Figure 2-23 Loose Node Re-optimization Configuration Instance
2-129
SJ-20140731105308-012|2014-10-20 (R1.0)
Configuration Flow
1. Configure a loopback address and interface address on P1, P2, and P3.
2. Establish OSPF neighbors on P1, P2, and P3, enable the TE function on the OSPF
neighbors and interfaces, and configure the egress gei-0/2/0/2 of P2 to cost so that
link 1 is prior to link 2.
3. Configure a TE tunnel on P1, configure the explicit path to loosened to P2 first and
then P3, and enable periodical re-optimization on the tunnel.
4. Configure re-optimization at loose node on P2, and set the periodical re-optimization
frequency to 30 seconds.
5. Set the interface gei-0/1/0/5 to shutdown on P2, and check whether the tunnel goes
through link 2 and whether the egress interface is gei-0/2/0/2.
6. Set the interface gei-0/1/0/5 to no shutdown on P2. After OSPF neighbors are
established and the timer expires, check whether the tunnel is MBB re-optimized to
link 1 and the egress interface is gei-0/1/0/5.
P1(config-ospf-1)#network 19.18.17.0 0.0.0.255 area 0.0.0.0
P1(config-ospf-1)#mpls traffic-eng area 0.0.0.0
P1(config-mpls-te)#explicit-path name 1
P1(config-mpls-te-expl-path-name)#next-address loose 2.2.2.2
P1(config-mpls-te-expl-path-name)#next-address loose 3.3.3.3
2-130
SJ-20140731105308-012|2014-10-20 (R1.0)

explicit-path name 1
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng auto-reoptimize main-lsp

P2(config-ospf-1)#interface gei-0/2/0/2
P2(config-ospf-1-if-gei-0/2/0/2)#cost 5
P2(config-ospf-1-if-gei-0/2/0/2)#exit
P2(config-mpls-te)#reoptimize loose-node
P2(config-mpls-te)#reoptimize timers frequency 30

2-131
SJ-20140731105308-012|2014-10-20 (R1.0)

1. Run the show running-config mpls-te command to check the MPLS-TE configuration
on P1, P2, and P3. The execution result is displayed as follows:
P1(config)#show running-config mpls-te
!<mpls-te>
mpls traffic-eng
router-id 1.1.1.1
index 1 next-address loose 2.2.2.2
index 2 next-address loose 3.3.3.3
$
tunnel te_tunnel1
tunnel mpls traffic-eng auto-reoptimize main-lsp
tunnel mpls traffic-eng path-option 1 explicit-path name 1
$
$
interface loopback1
2-132
SJ-20140731105308-012|2014-10-20 (R1.0)

$
$
!</mpls-te>
!<mpls-te>
mpls traffic-eng
router-id 2.2.2.2
reoptimize loose-node
reoptimize timers frequency 30
$
$
$
interface loopback1
$
$
!</mpls-te>
!<mpls-te>
mpls traffic-eng
router-id 3.3.3.3
$
$
interface loopback1
$
$
!</mpls-te>
2. Run the show mpls traffic-eng tunnels remote-tunnel command to check whether the
egress interface gei-0/1/0/5 is shut down on P2, and whether the tunnel goes through
link 2 and the egress interface is gei-0/2/0/2. The execution result is displayed as
follows:
P2(config-if-gei-0/1/0/5)#show mpls traffic-eng tunnels remote-tunnel
Name: tunnel_1
Status:
Signalling: up
InLabel: gei-0/1/0/1, 147456
2-133
SJ-20140731105308-012|2014-10-20 (R1.0)

RSVP Path Info:
Explicit Route: 19.18.17.22 29.28.27.22 29.28.27.33 3.3.3.3
Exclude Route: NULL
Record Route: 1.1.1.1 19.18.17.11
Exclude-any: None
Include-any: None
Include-all: None
RSVP Resv Info:
Record Route: 3.3.3.3(3) 29.28.27.33(3)
History:
Tunnel:
3. Enable the interface gei-0/1/0/5 on P2. After OSPF neighbors are established and the
timer expires, MBB occurs on the tunnel, and re-optimization is performed at loose
nodes. The tunnel goes through link 1 and the egress interface is gei-0/1/0/5. Run the
show mpls traffic-eng tunnels remote-tunnel command to check the related information.
The execution result is displayed as follows:
P2(config-if-gei-0/1/0/5)#show mpls traffic-eng tunnels remote-tunnel
Name: tunnel_1
Status:
Signalling: up
InLabel: gei-0/1/0/1, 147457
RSVP Path Info:
Explicit Route: 19.18.17.22 59.58.57.22 59.58.57.33 3.3.3.3
Exclude Route: NULL
Record Route: 1.1.1.1 19.18.17.11
Exclude-any: None
Include-any: None
Include-all: None
RSVP Resv Info:
Record Route: 3.3.3.3(3) 59.58.57.33(3)
History:
2-134
SJ-20140731105308-012|2014-10-20 (R1.0)

Tunnel:
2.11 Automatic Bandwidth Regulation on an MPLS TE

2.11.1 Introduction to Automatic Bandwidth Regulation Function of
the MPLS TE
With the automatic bandwidth regulation function of the MPLS TE, the bandwidth actually
used by a tunnel is collected, the maximum bandwidth in a sampling period is recorded,
and a subscriber's bandwidth is regulated in accordance with the maximum bandwidth
collected in an automatic bandwidth regulation period. With this function, the bandwidth
reserved for a tunnel is closer to the actual service traffic.
To understand the automatic bandwidth regulation function, you must understand the
following two concepts:
Sampling period: configured in a global MPLS-TE to control the rate of periodically
collecting traffic data on a tunnel. This value must be lower than the regulation period.
Regulation period: configured for a TE tunnel to control the rate of regulating a tunnel
bandwidth. Regulation is determined when a sampling period ends depending on the
sampling data comparison result and whether the tunnel meets the regulation conditions.
2.11.2 Configuring Automatic MPLS TE Bandwidth Regulation

This procedure describes how to configure automatic MPLS TE bandwidth regulation.
Steps
1. Configure automatic global sampling of TE bandwidth and real-time tunnel regulation.
Step
Command
Function
ZXR10(config-mpls-te)#auto-bw timers [frequency
Enables automatic bandwidth
<para>]
sampling and sets the

sampling frequency.
Manually triggers all tunnels
ZXR10(config-mpls-te)#auto-bw adj-now all
with the automatic bandwidth

regulation function to regulate
their bandwidths.
3
ZXR10(config-mpls-te)#auto-bw adj-now tunnel-id
Manually triggers a specific
<tnnlid>
tunnel to immediately
perform automatic bandwidth
regulation.
2-135
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
Enters Tunnel interface
<tunnel-number>
configuration mode.
Enables the automatic
number)#tunnel mpls traffic-eng auto-bw
bandwidth regulation on a
tunnel.
6
Sets the automatic bandwidth
number)#tunnel mpls traffic-eng auto-bw frequency
regulation period.
<freq>
7
Sets the tunnel bandwidth
number)#tunnel mpls traffic-eng auto-bw multiple
regulation rate.
<multiple>
8
Sets the maximum and
number)#tunnel mpls traffic-eng auto-bw adj-bw
minimum of the tunnel
<maxbw>[<minbw>]
bandwidth, between which,

the tunnel bandwidth can be
regulated.
Configures regulation and
number)#tunnel mpls traffic-eng auto-bw overflow
detection upon tunnel
threshold <percent>[min<bandwidth>] limit <limit>
overflow.
<para>: sampling period, range: 60-604800, unit: seconds, default: 300.

<freq>: bandwidth regulation period. Range: 300-604800, unit: seconds.
<multiple>: tunnel bandwidth regulation rate. Range: 50-100, default: 100.
<maxbw>: maximum of the bandwidth. Range: 1-4294967295, units: kb/s.
<minbw>: minimum of the bandwidth. Range: 0-4294967295, units: kb/s, default: 0.
<percent>: specifies the percentage of the overflew bandwidth.Range: 1100.
<bandwidth>: specifies the overflew bandwidth. Range: 10-4294967295, unit: kbps,
default: 10.
<limit>: specifies the threshold of the overflew bandwidth.Range: 1-10.
Command
Function
End of Steps
2-136
SJ-20140731105308-012|2014-10-20 (R1.0)
2.11.3 Instances of Automatic Bandwidth Regulation Configuration

for the MPLS TE
Figure 2-24 shows tunnel1 from PE1 to PE2, which can be strictly or dynamically routed.
When strictly routed, a new LSP is formed following the strict path when the bandwidth
regulation period starts. When dynamically routed, the LSP is re-calculated in accordance
with the required bandwidth and a new LSP is formed when the bandwidth regulation period
starts. The new LSP may be different from the original one.
Figure 2-24 Instance of Automatic Bandwidth Regulation Configuration for the MPLS TE
Configuration Flow
1. Establish a common dynamically routed tunnel through ISIS-TE, with the initial
bandwidth of 10 M.
2. The egress interface gei-0/0/0/3 of PE1 has an available bandwidth of 40 M, the
egress interface gei-0/0/0/1 of PE1 has an available bandwidth of 80 M, the egress
interface gei-0/0/0/1 of PE3 has an available bandwidth of 80 M, and the egress
interface gei-0/0/0/1 of PE4 has an available bandwidth of 80 M.
3. Enable the automatic bandwidth regulation function in global TE mode and set the
sampling period to 60 seconds.
4. Enable automatic bandwidth sampling and regulation function in tunnel interface mode
and set the automatic bandwidth regulation period to 300 seconds.
Configuration for PE1:
ISIS configuration is omitted.
PE1(config)#interface te_tunnel1
2-137
SJ-20140731105308-012|2014-10-20 (R1.0)

PE1(config-if)#ip unnumbered loopback1
PE1(config-if)#exit
PE1(config)#mpls traffic-eng
PE1(config-mpls-te)#auto-bw timers frequency 60 //Sets the sampling period.
PE1(config-mpls-te)#interface gei-0/0/0/3
PE1(config-mpls-te-if)#bandwidth 40000
PE1(config-mpls-te-if)#exit
PE1(config-mpls-te-if)#bandwidth 80000
PE1(config-mpls-te-if)#exit
PE1(config-mpls-te)#tunnel te_tunnel1
PE1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng auto-bw
//Enables the automatic bandwidth regulation function on the tunnel.
PE1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng auto-bw frequency 300
//Sets the bandwidth regulation period.
PE1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng auto-bw adj-bw 1000000 10000
PE1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng auto-bw multiple 100
PE1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng bandwidth 10000
PE1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng path-option 1 dynamic
PE1(config-mpls-te-tunnel-te_tunnel1)#tunnel destination ipv4 2.2.2.2
PE1(config-mpls-te-tunnel-te_tunnel1)#exit
PE1(config-mpls-te)#exit
Configures a static route to the forwarded-to destination address on the PE1, with
the next hop tunnel1.
The TEs configured on the PE2, PE3, and PE4 are the same as that configured when a
common TE tunnel is being established. The commands related to automatic bandwidth
regulation do not need to be configured and are not described in this manual.
Run the show mpls traffic-eng tunnels command to check the tunnel establishment
information on the PE1. The execution result is displayed as follows, in which, the tunnel
establishment path is PE1>PE2.
PE1(config)#show mpls traffic-eng tunnels brief
Signalling Summary:
running
RSVP Process:
running
Forwarding:
enabled
TUNNEL NAME DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_1
gei-0/0/0/3
up/up
2.2.2.2
PE1(config)#show mpls traffic-eng tunnels te_tunnel 1

Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
2-138
SJ-20140731105308-012|2014-10-20 (R1.0)

Config Parameters:
ClassType: 0
Affinity: 0x0/0x0
Bandwidth: 0 kbps

BFD:disable
Fast-reroute: enable
disconnected
down
Auto-bw:(300/117) Samplling Bandwidth:49508
Bandwidth Requested:0
//300 s is the configured bandwidth regulation period, and 117 s is the time
before bandwidth regulation starts.
Adjust Range:0-unconstrained(0)
AutoRoute:disabled
Adjust Multiple:100
AutoRouteMetricType:IGP(default)
AutoRouteMetric: 0
Forwarding adjacency is not enabled

No-cspf:disable
Hot-standby: disabled

RSVP Path Info:
Explicit Route: 172.120.130.17 172.120.130.18 2.2.2.2
Exclude
Route: NONE
Automatically regulates the tunnel bandwidth in accordance with the sampled traffic
on a tunnel. Suppose the sampled traffic on tunnel1 is 49508K, after a bandwidth
regulation period, the bandwidth of tunnel1 is regulated to 49508K, and the path is
PE1->PE3->PE4>PE2.
Run the show mpls traffic-eng tunnels te_tunnel command to check the information about
the regulated tunnel1 on the PE1. The execution result is displayed as follows:
PE1(config)#show mpls traffic-eng tunnels te_tunnel 1
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Config Parameters:
ClassType: 0
Affinity: 0x0/0x0
Bandwidth: 49508 kbps

BFD:disable
Fast-reroute: enable
disconnected
down
Auto-bw:(300/113) Samplling Bandwidth:49508

Adjust Range:0-unconstrained(0)
Bandwidth Requested:49508
Adjust Multiple:100
2-139
SJ-20140731105308-012|2014-10-20 (R1.0)

AutoRoute:disabled
AutoRouteMetricType:IGP(default)
AutoRouteMetric: 0
Forwarding adjacency is not enabled

No-cspf:disable
Hot-standby: disabled

RSVP Path Info:
Explicit Route: 172.20.130.22 172.20.130.21 172.20.130.149 172.20.130.150
172.20.130.157 172.20.130.158 2.2.2.2
Run the show running-config-interface command to display the changed tunnel bandwidth
configuration. The execution result is displayed as follows:
PE1(config)#show running-config-interface te_tunnel1
!<if-intf>
interface te_tunnel1
!
interface te_tunnel1
ip unnumbered loopback1
!
!</if-intf>
!<mpls-te>
mpls traffic-eng
tunnel te_tunnel 1
tunnel mpls traffic-eng auto-bw
tunnel mpls traffic-eng auto-bw frequency 300
tunnel mpls traffic-eng path-option 1 dynamic
$
!</mpls-te>
2.12 TE GR Configuration
2.12.1 GR Introduction
Overview
Control-plane failures are divided into the following types:
2-140
SJ-20140731105308-012|2014-10-20 (R1.0)
l
l
Inter-node communication failure: The control-plane communication between nodes

is lost, but the nodes can still obtain the status of the control plane or forwarding plane.
Node failure: Although the RSVP-TE control plane becomes faulty and the status of
the control plane is lost, the data plane is still operating, and the LSR still remains in
the data forwarding status.
The application of the GR technology enables the control plane to recover from one of the
above failures.
1. Through this technology, the information of the LSR to reboot and whether it supports
GR are advertised to the neighboring LSR.
2. The neighbor detects the time when the failure occurs and the time when the reboot
process is completed, and then re-establishes a hello relationship.
3. The neighbor assists the LSR that reboots in recovering the control plane status and
re-synchronizing the control plane status and data forwarding plane status.
Implementation
To implement RSVP GR, the RFC in IETF define and describe the implementation process
of the function.
l
l
l
RFC defines an extended hello message. This provides the basics of the RSVP-TE
GR technology, and enables nodes to detect when their neighbors become
unreachable or reboot. It also defines a hello object and a hello message.
RFC defines an extended mechanism for hello messages, the flow of processing
control-channel failures and node failures, and an RESTART CAP object.
For the remaining problems (for example, the reboot of the head nodes on LSPs is
not supported and incomplete PATH information), RFC defines the actions for the
downstream of the nodes that are rebooted (that is, the downstream nodes send
RECOVER PATH messages to the upstream nodes). It also defines an optional
summary refresh process and an CAPBILITY object.
RFC describes the GR flow when multiples nodes of an LSP become faulty.
An hello object contains an SRC-INSTANCE and a DST-INSTANCE.

l
SRC-INSTANCE: message sender instance.

SRC-INSTANCE values.
Different neighbors have different
When the message sender reboots or loses communication with a neighbor, this
value must be changed. In other cases, this value remains unchanged. The
SRC-INSTANCE value should not be set to 0. During the implementation, this value
can be set to the system clock.
l
DST-INSTANCE: latest SRC-INSTANCE value carried in the hello message from a

neighbor, also called Neighbor_Src_Instance. Before a hello message is received
from the neighbor, this value is set to 0.
A RESTART CAP object contains an RESTART TIME field and an RECOVER TIME field.
l
RESTART TIME: indicates the time for a message sender to restart the control plane,
from the time when the control plane reboots to the time when the message sender
2-141
SJ-20140731105308-012|2014-10-20 (R1.0)
stops interactions with the neighbor through hello messages. If a control plane failure
does not affect the forwarding of data plane messages, the message sender can reset
the RESTART TIME field to 0XFFFFFF (meaning infinite reboot time).
RECOVER TIME: indicates whether the node that reboots should be kept in the forwarding status. If the node needs not to be kept in the forwarding status, this field is
set to 0. The recovery time begins from the time when the node that reboots re-establishes a neighbor relationship with its neighbor.
A CAPBILITY object contains three flag bits:

l
l
l
RecoveryPath Transmit Enabled (T): The message sender has the capability of
sending a RecoveryPath message.
RecoveryPath Desired (R): The message sender desires to receive a Recover Path
message.
RecoveryPath Srefresh Capable (S): Both R and S flag bits are set to 1, indicating that
the message sender has the capability of receiving and processing the SREFRESH
message (RecoveryPath=1) in a MESSAGE_ID LIST object.
Hello messages provide a mechanism for an RSVP node to detect the unreachable failure
related to a neighboring node.
l
This mechanism provides a means to detect node-to-node failures. When an

unreachable failure is detected, the handling ways that are the same as those for
link-layer communication failures are used.
Hello messages are primarily used to detect the status of the link with a neighboring
node when:
The detection for the status of a link-layer neighboring node becomes invalidated
or does not operate in real time.
A link that is not marked is used.
RECOVER PATH messages use the same format as PATH messages. To distinguish
between the two types of messages, RECOVER PATH messages use message ID 30.
The destination address in the IP header of a RECOVER PATH message must be the same
as that in the IP header of the associated RESV message. Unless otherwise specified, the
objects in an RECOVER PATH message should be the same as those in the corresponding
PATH message (received from the node that reboots).
Features
A GR is divided into three stages:
l
Stage before the reboot: Both upstream and downstream nodes receive the
information carried in the hello messages from the node to reboot, such as the
recovery capability, SRC-INSTANCE value, and DEST-INSTANCE value.
Reboot stage: begins from the time when the node reboots to the time when both
upstream and downstream nodes receive new hello messages from the node that
reboots.
Recovery stage: New neighboring relationships are established between the node
that reboots and upstream and downstream node. At the same time, both upstream
2-142
SJ-20140731105308-012|2014-10-20 (R1.0)
and downstream nodes can determine the failure occurring on the node that becomes
invalidated is a node failure or a control-plane failure.
The upstream node assists an invalidated node in recovering the associated LSP by
carrying a path recovery label in a PATH message. The invalidated node establishes the
control-plane status by processing the PATH message (carrying a path recovery label)
from the upstream, and marks the status of the LSP associated with the forwarding plane
to "Refresh".
The downstream node assists the invalidated node in recovering from the failure by
sending a RECOVER PATH message to the node. Upon receipt of the RECOVER PATH
message from the downstream, the node that reboots searches for the match with the
local LSP status. If an exact match is found, it sends a PATH message to the downstream.
The ERO object in the PATH message should match that in the received RECOVER PATH
message, and the node that reboots should recover from the failure based on other objects
in the received RECOVER PATH message.
Upon receipt of the PATH message, the downstream sends an RESV message to the
upstream. After the node that reboots processes the RESV message, the recovery
process of the LSP is completed.
2.12.2 Configuring GR
This procedure describes how to configure GR.
Context
GR should be configured for each node that a tunnel passes through.
The GR function is conflicted with the FRR HELLO function.
Steps
Command
Function

2. To enable GR, perform the following steps:

Step
Command
Function
ZXR10(config-mpls-te)#signalling graceful-restart
Enables the graceful-restart

function.
2-143
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
Sets the time interval (in
graceful-restart refresh interval <interval>
milliseconds) for refreshing

hello messages, range:
100030000.
graceful-restart refresh misses <num>
times that hello messages can

be lost, range: 410.
Sets the maximum restart
graceful-restart timers restart-time <restart-time>
time (in milliseconds) for

the graceful-restart function,
range: 120000600000.
Sets the maximum recovery
graceful-restart timers recovery-time <recover-time>
time (in milliseconds) for

the graceful-restart function,
range: 120000600000.

Command
Function
ZXR10#show ip rsvp hello graceful-restart
Displays the GR configuration.
ZXR10#show ip rsvp hello instance summary
Displays the summary

information about RSVP HELLO
instances.
ZXR10#show ip rsvp hello instance detail
Displays the detailed information

about RSVP HELLO instances.
4. To maintain the GR function, run the following commands:

Command
Function
ZXR10#debug rsvp hello
Enables the debugging of GR.
End of Steps
2.12.3 GR Configuration Example

tunnel from P1 to P2 by using the OSPF TE-based strict routing mode, and enable the GR
function in the TE configuration mode of P1 and P2.
2-144
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-25 GR Configuration Example
Configuration Flow
4. Enable the GR function in the TE configuration mode of P1 and P2.
2-145
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#signalling graceful-restart

P2(config-mpls-te)#signalling graceful-restart
Signalling Summary:
2-146
SJ-20140731105308-012|2014-10-20 (R1.0)

Forwarding: enabled
tunnel_1
2.1.1.1
STATE/PROT
gei-0/1/0/2 up/up

Run the show ip rsvp hello instance summary command on P1 to check whether GR
has been enabled:
P1(config)#show ip rsvp hello instance summary
Client I/F Neighbor Type StateLostCnt LSPs
GR gei-0/1/0/2 192.168.1.2 ACTIVE UP0
P1(config)#show ip rsvp hello graceful-restart

MPLS-TE: Enabled
Graceful Restart: Enabled
Refresh interval: 10000 msecs
Refresh misses: 4
Advertised restart time: 120000 msecs
Advertised recovery time: 120000 msecs
P1(config)#show ip rsvp hello instance detail

Hello Graceful Restart globally enabled
Fast-Hello globally disabled
Neighbor 192.168.1.2 Source 192.168.1.1
Clients:Graceful Restart
State:UP
Type:ACTIVE
I/F: gei-0/1/0/2
LSP num:1
Src_instance 19002981, Dst_instance 17128690
GR HELLO parameters
Refresh Misses Configured:4
Refresh Interval (msec)
Configured:10000
Current :10000
Local restart time (msec):120000
Local recovery time (msec):120000
Nbr restart time (msec):120000
Nbr recovery time (msec):0
Lost count:0
intf hello
FRR HELLO parameters
Fast_hello_period (msec):10000
Fast_hello_miss:4
2-147
SJ-20140731105308-012|2014-10-20 (R1.0)

Fast_hello_protect_lsps:0
Fast_hello_del_time (msec):0
Fast_hello_reroute_time (msec):0
2.13 TE Tunnel FA Configuration

2.13.1 TE Tunnel FA Introduction
A routing protocol stores the path information related to the forwarding of packets through
a database. When the network topology is very complicated, during the forwarding of
packets, a great amount of system resources are spent in searching for the corresponding
information in the database. If the TE tunnel function is fully utilized by using a TE tunnel
as a forwarding entry of a route, the amount of system resources for the packet forwarding
can be greatly reduced, and the higher-speed forwarding can be achieved. This process
is achieved by using TE tunnel FA.
The status of a TE tunnel is advertised to a routing protocol in real time. This ensure that,
before the packet forwarding over the TE tunnel stops, the routing protocol has sufficient
time to switch over traffic from the TE tunnel to other alternate entities.
2.13.2 Configuring TE Tunnel FA

This procedure describes how to configure TE tunnel FA.
Steps
1. To configure TE tunnel FA, perform the following steps:
Step
Command
Function
<tunnel-number>
configuration mode.
Enables FA and sets the
tunnel-number)#tunnel mpls traffic-eng
holdtime.
forwarding-adjacency[<holdtime>]
<holdtime>: the delay time (in seconds) for informing the local router that the tunnel is
down after the corresponding link is down, range: 04294967295. If this parameter is
set, the local router does not know tunnel flapping.
Command
Function
Displays detailed information

about tunnels.
2-148
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#show mpls traffic-eng forwarding-adjacency

about FA.
End of Steps
2.13.3 TE Tunnel FA Configuration Example

tunnel from P1 to P2 by using the OSPF TE-based strict routing mode, and enable FA on
the tunnel.
Figure 2-26 FA Configuration Example
Configuration Flow
3. Establish a tunnel (Tunnel1) on P1, and establish a reverse tunnel (Tunnel2) on P2.
4. Enable FA on two tunnels.
2-149
SJ-20140731105308-012|2014-10-20 (R1.0)

forwarding-adjacency
forwarding-adjacency holdtime 1000

2-150
SJ-20140731105308-012|2014-10-20 (R1.0)

forwarding-adjacency
forwarding-adjacency holdtime 1000
Run the show mpls traffic-eng tunnels te_tunnel 1 command on P1 to check whether
the tunnel has been established. The execution result is displayed as follows:
Name: tunnel_1 (Tunnel1) Destination: 2.1.1.1
Status:
Admin: up Oper: up Path: valid Signalling: connected
Config Parameters:
Bandwidth: 0 kbps (Global) Priority: 7 7 Affinity: 0x0/0x0
Resv-Style: SE
Metric Type: IGP (default) Upper Limit: 4294967295
BFD: disabled
Auto-bw: disabled
2-151
SJ-20140731105308-012|2014-10-20 (R1.0)

Bidirect: disabled
AutoRoute: disabled
Forwarding adjacency: holdtime 1000s

RSVP Path Info:
Explicit Route: 192.168.1.1 192.168.1.2 2.1.1.1
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
Time since created: 0 days, 0 hours, 56 minutes, 22 seconds
Current LSP: Uptime:0 days, 0 hours, 5 minutes, 39 seconds
Path error: admission fail(lspid:8,errcode:1,errvalue:4).
Tunnel config changed(lspid:7,errcode:1,errvalue:3).
Path error: admission fail(lspid:6,errcode:1,errvalue:4)
P1(config)#show mpls traffic-eng forwarding-adjacency

MPLS TE forwarding-adjacency enabled
Destination 2.1.1.1 has 1 tunnels
TunnelName Destination State Nexthop Holdtime
tunnel_1 2.1.1.1 Up 2.1.1.1 1000s
2.14 TE Tunnel AR Configuration

2.14.1 TE Tunnel AR Introduction
A routing protocol stores the path information related to the forwarding of packets through
a database. When the network topology is very complicated, during the forwarding of
packets, a great amount of system resources are spent in searching for the corresponding
information in the database. If the TE tunnel function is fully utilized by using a TE tunnel as
a forwarding entry in the routing table, the amount of system resources spent in forwarding
packets can be greatly reduced, and the higher-speed forwarding can be achieved.
2-152
SJ-20140731105308-012|2014-10-20 (R1.0)
Auto route advertisement has AR and FR features. Both of the two features use the
principle of involving TE tunnel interfaces in the SPF calculation of IGP.
l
An AR-enabled router uses CR-LSP as an egress interface, but the router does not
advertise the CR-LSP to the upstream router. Therefore, other routers do not store
the CR-LSP information in their link databases, and the CR-LSP cannot be used.
An FA-enabled router advertises the CR-LSP as a common LSA/LSP to its upstream
router while using the CR-LSP as an egress interface. Therefore, other routers store
the CR-LSP information into their link databases, and the CR-LSP can be used.
2.14.2 Configuring TE Tunnel AR

This procedure describes how to configure TE tunnel AR.
Steps
1. To configure TE tunnel AR, perform the following steps:
Step
Command
Function
<tunnel-number>
configuration mode.
Enables AR for the TE tunnel.
number)#tunnel mpls traffic-eng autoroute announce
Specifies the metric value for
number)#tunnel mpls traffic-eng autoroute metric
the AR.
{<value0>| absolute <value1>| relative <value2>}
<value0>: sets the default metric type of AR, default: absolute, range: 14294967295.
absolute <value1>: sets the absolute metric value of AR, range: 14294967295.
relative <value2>: sets the relative metric value of AR, range: -10 to +10.
Command
Function

about tunnels.
ZXR10#show mpls traffic-eng autoroute

about AR.
End of Steps
2-153
SJ-20140731105308-012|2014-10-20 (R1.0)
2.14.3 TE Tunnel AR Configuration Example

tunnel from P1 to P2 by using the OSPF TE-based strict routing mode and enable AR on
the tunnel.
Figure 2-27 AR Configuration Example
Configuration Flow
3. Establish a tunnel (Tunnel1) on P1.
4. Enable AR on the tunnel.
2-154
SJ-20140731105308-012|2014-10-20 (R1.0)

autoroute announce
autoroute metric absolute 12

2-155
SJ-20140731105308-012|2014-10-20 (R1.0)
Status:
Config Parameters:
Resv-Style: SE
Metric Type: IGP (default) Upper Limit: 4294967295
Hop Prior: disabled
Upper Limit: -

BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
Affinity: 0x0/0x0
EBS: 0 byte
AutoRoute: enabledAutoRouteMetricType: absoluteAutoRouteMetric: 12

AUTO-BW: disabled
Crankback: disabled

2-156
SJ-20140731105308-012|2014-10-20 (R1.0)

RSVP Path Info:
Explicit Route: 192.168.1.1 192.168.1.2 2.1.1.1
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
None log record.
P1(config)#show mpls traffic-eng autoroute

MPLS TE autorouting enabled
Destination 2.1.1.1 has 1 tunnels
TunnelName Destination State NexthopMetricType MetricValue
tunnel_1 2.1.1.1 Up 2.1.1.1Absolute 12
2.15 TE Metric Configuration

2.15.1 TE Metric Introduction
After TE metric is enabled on an MPLS TE tunnel and the TE metric values are specified
for associated interfaces, during the CSPF-based path selection process, the path whose
total TE metric values of all associated egress interfaces are the smallest is preferentially
selected. The path for the MPLS TE tunnel can be indirectly specified by changing the
metric values of associated interfaces, which enables the path selection process to be
manageable.
2.15.2 Configuring TE Metric

This procedure describes how to configure TE metric.
Steps
1. To configure TE metric, perform the following steps:
2-157
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
<tunnel-number>
configuration mode.
Specifies the TE metric for the
tunnel-number)#tunnel mpls traffic-eng
tunnel, range: 14294967295.
administrative-weight<value>
3

configuration mode.
ZXR10(config-mpls-te-if-interface-name)#adminis
Specifies the TE metric for the
trative-weight<value>
TE interface, range: 165535.

Command
Function

about tunnels.

about MPLS TE interface.
End of Steps
2.15.3 TE Metric Configuration Example

tunnel from P1 to P2 by using the OSPF TE-based strict routing mode and configure TE
metric on the tunnel and corresponding interfaces.
Figure 2-28 TE Metric Configuration Example
2-158
SJ-20140731105308-012|2014-10-20 (R1.0)
Configuration Flow
3. Establish a tunnel (Tunnel1) on P1.
4. Configure TE metric on the tunnel and corresponding interfaces.
P1(config-mpls-te-if-gei-0/1/0/2)#administrative-weight 7
administrative-weight 12
2-159
SJ-20140731105308-012|2014-10-20 (R1.0)


Status:
Config Parameters:
Resv-Style: SE
Metric Type: TE Upper Limit: 12
Hop Prior: disabled
Upper Limit: -
2-160
SJ-20140731105308-012|2014-10-20 (R1.0)

BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
Affinity: 0x0/0x0
EBS: 0 byte
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled

RSVP Path Info:
Explicit Route: 192.168.1.1 192.168.1.2 2.1.1.1
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
None log record.
P1(config)#show mpls traffic-eng interface detail
2-161
SJ-20140731105308-012|2014-10-20 (R1.0)

gei-0/1/0/2:
State:
ENABLE
Key: <encrypted>
Type: md5
Challenge: disabled
Challenge-imp: Not implemented(simulated)
Window size: 32
BFD: disabled
Backup path:
None
SRLGs: None
Fast-Hello miss: 4
2.16 TE SRLG Configuration

2.16.1 TE SRLG Introduction
If one of the links in an SRLG becomes faulty, other links may also fail to operate. For
example, If an optical fiber or pipe is faulty, all of the optical links belonging to the optical
fiber or pipe may also fail. If an optical fiber is faulty, all associated sublinks also fail to
operate.
SRLG is widely used during the MPLS TE deployment. During the selection of a backup
path, the application of SRLG in MPLS TE prevents the backup path and a protected link
being selected to the same SRLG, which provides better protection.
In an MPLS TE network, some of the interfaces of network devices can be configured
to belong to the same SRLG. OSPF or IS-IS floods the SRLG member information, TE
information (such as the available bandwidth) of links, and other information to other
network devices, and the information is used for the CSPF-based calculation.
TE SRLG is generally used for MPLS TE-FRR services, and can be used to optimize
the selection of backup paths. The SRLG information can be used for the CSPF-based
calculation. If the dynamic generation mode is used, a backup path that is not in the same
SRLG with the protected link can be automatically calculated and generated. If the manual
generation mode is generated, you should avoid the case that the backup path is in the
same SRLG with the protected link.
2-162
SJ-20140731105308-012|2014-10-20 (R1.0)
2.16.2 Configuring TE SRLG

This procedure describes how to configure TE SRLG.
Steps
1. To configure MPLS TE SRLG, perform the following steps:
Step
Command
Function
ZXR10(config-mpls-te)#srlg exclude{auto-tunnel-bac
Specifies the exclusion
kup | facility-frr | hot-standby | one-to-one-frr}{force |
mode of SRLG in global
preferred}
configuration mode, options:
force
preferred

configuration mode.
ZXR10(config-mpls-te-if-interface-name)#srlg<v
Specifies the SRLG value
alue>
for the TE interface, range:

04294967295.
A maximum of three SRLG
values can be set on an
interface.

Command
Function
ZXR10#show mpls traffic-eng auto-backup parameter
Displays the configurations of

the auto-backup tunnel.
Displays the SRLG

configurations of MPLS TE
interfaces.
End of Steps
2.16.3 TE SRLG Configuration Example

tunnel from P1 to P2 by using the OSPF TE-based strict routing mode, configure the auto
backup mode, and configure the SRLG value on the egress interface of the primary tunnel.
It is also required to configure SRLG values on the egress interfaces of other links (the
force mode is used in this example).
2-163
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-29 TE SRLG Configuration Example
Configuration Flow
3. Establish a tunnel (Tunnel1) on P1, and configure the auto backup mode.
4. Configure an SRLG value on the egress interface of the primary tunnel.
5. Configure SRLG values on the egress interfaces of other links.
2-164
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#srlg exclude auto-tunnel-backup force
P1(config-mpls-te-if-gei-0/1/0/2)#auto-tunnel backup
P1(config-mpls-te-if-gei-0/1/0/2)#srlg 1
/*An interface can have a maximum of three SRLG values*/

2-165
SJ-20140731105308-012|2014-10-20 (R1.0)

Run the show mpls traffic-eng auto-backup parameter command on P1 to check
whether the tunnel has been established. The execution result is displayed as follows:
P1(config)#show mpls traffic-eng auto-backup parameter
MPLS-TE: Enabled
The setting of auto-tunnel minID is: 32001
The setting of auto-tunnel maxID is: 33000
Auto-tunnel minID in used is: 33000
Auto-tunnel maxID in used is: 33000
Auto-tunnel backup srlg exclude: Force
P1(config)#show mpls traffic-eng interface detail

gei-0/1/0/2:
State:
ENABLE
2-166
SJ-20140731105308-012|2014-10-20 (R1.0)

Key: <encrypted>
Type: md5
Challenge: disabled
Window size: 32
BFD: disabled
Backup path:
auto-tunnel backup
SRLGs: 1 2 3
Fast-Hello miss: 4
gei-0/1/0/3:
State:
ENABLE
Key: <encrypted>
Type: md5
Challenge: disabled
Window size: 32
BFD: disabled
Backup path:
None
SRLGs: 1
Fast-Hello miss: 4
gei-0/1/0/4:
State:
ENABLE
Key: <encrypted>
Type: md5
Challenge: disabled
Window size: 32
BFD: disabled
Backup path:
None
SRLGs: 4
2-167
SJ-20140731105308-012|2014-10-20 (R1.0)

Fast-Hello miss: 4

Signalling Summary:
Forwarding: enabled
TUNNEL NAMEDESTINATION UP IFDOWN IFSTATE/PROT
tunnel_12.1.1.1 -gei-0/1/0/2 up/up
tunnel_33000 2.1.1.1 -
gei-0/1/0/4
up/up

Protected Tunnel LspIDIn-label Out intf/labelFRR intf/label Status
Tunnel1545
Tun hd
gei-0/1/0/2:3Tu33000:3 ready

2.17 TE Tunnel Reoptimization Configuration

2.17.1 Introduction to TE Tunnel Reoptimization
The optimal path may be not selected during the initial setup stage of a TE tunnel due to
some reasons. When link conditions are improved, the re-optimization technology can be
used to re-select a path for the tunnel that has been established and is in up status.
This technology not only helps in selecting the optimal path for a TE tunnel, but also helps
in switching back the tunnel to the reasonable primary path after a protection switchover.
It also uses the MBB technology to ensure that traffic is not lost during the path selection
process.
2.17.2 Configuring TE Tunnel Re-optimization

This procedure describes how to configure TE tunnel re-optimization.
Steps
1. Configure re-optimization for a point-to-point TE tunnel.
Step
Command
Function
ZXR10(config-mpls-te)#reoptimize events link-up
Enables re-optimization.
ZXR10(config-mpls-te)#reoptimize timers
Sets the re-optimization time
frequency<timer>
interval (in seconds), range:

30604800.
2-168
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-mpls-te)#reoptimize tunnel{<tunnel-i
Enables re-optimization for a
d>|all}
tunnel or all tunnels.

This command is an one-off
triggering command.
ZXR10(config-mpls-te)#tunnel te_tunnel<tunnel-numb
Enters point-to-point tunnel
er>
configuration mode.
Enables tunnel
tunnel-number)#tunnel mpls traffic-eng auto-reoptimize
re-optimization.
{ hsb-lsp|main-lsp}
<tunnel-id>: ID of the specified tunnel.

all: all tunnels.
hsb-lsp: Enables the periodical re-optimization function on the hot-standby LSP.
main-lsp: Enables the periodical re-optimization function on the active LSP.
2. Configure re-optimization for a point-to-multipoint TE tunnel.
Step
Command
Function
ZXR10(config-mpls-te)#reoptimize events link-up
Configures re-optimization
upon link up events.
ZXR10(config-mpls-te)#reoptimize timers
Sets the re-optimization
frequency<timer>
period, range: 30604800,

unit: seconds.
ZXR10(config-mpls-te)#mtunnel mte_tunnel<tunnel-
Enters point-to-multipoint
number>
tunnel configuration mode.
ZXR10(config-mpls-te-mtunnel-mte_tunnel-
Enables tunnel
tunnel-number)#mtunnel mpls traffic-eng reoptimize
re-optimization.
ZXR10(config-mpls-te)#reoptimize mtunnel {< mtunnel
In global mode, configures
id>| all }
manual re-optimization for

one or all point-to-multipoint
tunnels.
This is an one-off triggering
command.
<tunnel-id>: Manually re-optimizes a point-to-multipoint tunnel.

all: Manually re-optimizes all point-to-multipoint tunnels.
2-169
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
Checks the information about

re-optimization for point-to-point
TE tunnels.
ZXR10#show mpls traffic-eng mtunnels summary
Checks the information

about re-optimization for
point-to-multipoint TE tunnels.
End of Steps
2.17.3 TE Tunnel Reoptimization Configuration Example

Figure 2-30 shows a sample network topology. It is required to establish a tunnel from
P1 to P2, and configure three links between P1 and P2. After two of the three links are
broken, a manual re-optimization should be performed.
Figure 2-30 TE Tunnel Re-optimization Configuration Example
Configuration Flow
1. Establish OSPF neighbor relationships on the three links between P1 and P2, and
enable OSPF TE.
2. Configure three path-options (1, 2, and 3), corresponding to the three links.
3. Run the shutdown command on the two links corresponding to path-option 1 and
path-option 2, and run the no shutdown command on the tunnel interface to establish
a tunnel.
4. Run the no shutdown command on the two links corresponding to path-option 1 and
path-option 2, and perform a manual optimization.
2-170
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#reoptimize events link-up
2-171
SJ-20140731105308-012|2014-10-20 (R1.0)


2-172
SJ-20140731105308-012|2014-10-20 (R1.0)

Run the shutdown command on the gei-0/1/0/2 and gei-0/1/0/3 interfaces of P1, and run
the show mpls traffic-eng tunnels brief command to check whether the link between the
gei-0/1/0/4 interfaces of P1 and P2 is selected as the tunnel. The execution result is
Signalling Summary:
Forwarding: enabled
TUNNEL NAMEDESTINATION UP IFDOWN IF
STATE/PROT
tunnel_12.1.1.1 - gei-0/1/0/4 up/up
Run the no shutdown command on the gei-0/1/0/2 and gei-0/1/0/3 interfaces of P1, and
start a manual re-optimization in the TE configuration mode of P1.
P1(config-mpls-te)#reoptimize tunnel 1
Run the show mpls traffic-eng tunnels brief command on P1 to check whether the link
between the gei-0/1/0/2 interfaces of P1 and P2 is selected as the tunnel.
Signalling Summary:
Forwarding: enabled
TUNNEL NAMEDESTINATION UP IFDOWN IF STATE/PROT
tunnel_12.1.1.1 -gei-0/1/0/2 up/up
2.18 TE HOTSTANDBY Configuration

2.18.1 Tunnel Establishment With Only TE HOTSTANDBY
When the ZXR10 M6000-S is being deployed, TE HOTSTANDBY protection is also
deployed, which means that an active path and a standby path are configured. Without
this function, if a TE LSP cannot be established along the active path of a tunnel, the
tunnel cannot be established even if the TE LSP can be established along the standby
path.
If tunnel establishment with only TE HOTSTANDBY is enabled, TE LSP establishment is
attempted along the active path and the standby path in sequence. If a tunnel can be
2-173
SJ-20140731105308-012|2014-10-20 (R1.0)
established along the hot standby path, the tunnel continuously attempts switching back
and finally switches back to the active path once the active path is restored.
2.18.2 Configuring the TE HOTSTANDBY Function

This procedure describes how to configure the TE HOTSTANDBY function of a TE tunnel.
Steps
1. Configure the TE HOTSTANDBY function of a TE tunnel.
Step
Command
Function
<tunnel-number>
configuration mode.
Enables the TE
number)#tunnel mpls traffic-eng reference hot-standby
HOTSTANDBY function
of the tunnel.

Command
Function
End of Steps
2.18.3 TE HOTSTANDBY Function Configuration Instance

In Figure 2-31, a common RSVP tunnel from P1 to P2 is established in strict routing mode
through OSPF TE, and another path is established and used to protect the active path of
the tunnel. In addition, a TE HOTSTANDBY command is configured, and then the tunnel
mpls traffic-eng reference hot-standby command is configured. With this configuration, if
both the active and standby paths of the TE HSB are down, the standby path is restored
and the tunnel can get UP properly and service messages can be properly forwarded.
2-174
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-31 Topological Graph of the Instance for Tunnel Establishment with Only
TE HOTSTANDBY
Configuration Flow
1. Establish OSPF neighbors on the directly-connected interfaces of P1 and P2, and
enable the TE function on the OSPF neighbors.
2. Enable the TE function on the directly-connected interfaces of P1 and P2.
3. Establish Tunnel1 and explicit path 1 on P1.
4. Configure explicit path 2 on P1 and configure HSB protection for tunnel1, so that path
2 can be used to protect path 1.
5. Configure a TE HOTSTANDBY command, and then configure the tunnel mpls traffi
c-eng reference hot-standby command. With this configuration, if both the active and
standby paths of the TE HSB are down, the standby path is restored and the tunnel
can get UP properly and service messages can be properly forwarded.
2-175
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng hot-standby protect 1
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng reference hot-standby

2-176
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-ospf-1)#network 190.168.1 0 0.0.0.255 area 0
Run the show mpls traffic-eng tunnels te_tunnel 1 hot-standby command to check the
information about the tunnel on P1. The execution result is displayed as follows:
P1(config)#show mpls traffic-eng tunnels te_tunnel 1 hot-standby
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Fast Reroute Protection: disabled

Hot-standby Protection: ready
Config Parameters:
BFD: disabled
Hot-standby-lsp Fast-reroute: enabled
RSVP Path Info:
Explicit Route: 190.168.1.1 . 190.168.1.2
1.1.1.1
Exclude Route: 192.168.1.1 . 192.168.1.2

Record Route: NULL
RSVP Resv Info:
Record Route: 2.1.1.1(3)
190.168.1.1 (3)
P1(config)# show mpls traffic-eng tunnels te_tunnel 1
2-177
SJ-20140731105308-012|2014-10-20 (R1.0)
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid
Path option: 1, type explicit identifier :2 (Basis for Setup)

Actual Bandwidth: 0 kbps
protect option: 1, type explicit identifier :1(Basis for Protect)
Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
BFD: disabled
Track Name:
Reference Hot-standby: enabled
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
Include-any: None
Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
Src 1.1.1.1 Dst 2.1.1.1, Tun-ID 1, Tun-Instance 278
2-178
SJ-20140731105308-012|2014-10-20 (R1.0)

RSVP Path Info:
Explicit Route: 190.168.1.1 . 190.168.1.2
1.1.1.1
Exclude Route: 192.168.1.1 . 192.168.1.2

Record Route: NULL
RSVP Resv Info:
Record Route: 2.1.1.1(3)
190.168.1.1 (3)
History:
Tunnel:
Last LSP Error Information
2.19 WTR Configuration for a TE Tunnel

2.19.1 Introduction to TE Tunnel WTR
To ensure the reliability of the MPLS network, the Fast Reroute (FRR) technology acts
an important role in the MPLS network. This technology uses the capability of the MPLS
Traffic Engineering (TE) and provides a fast switchover protection capability for the LSP.
The MPLS FRR previously establishes a local backup path to protect the LSP being
affected by link or node failures. When a fault occurs, the device detecting the link or
node fault can switch over the data traffic from the faulty active path to the standby path
fast to reduce data loss.
Because FRR protection is temporary, after the active path is restored, data traffic must be
switched back to the active path. This switchback can be performed immediately or after
the Wait To Restore (WTR) time. WTR allows data traffic to wait for a period before being
switched back to the active path. During this period, The forwarding information base of
each downstream node gets ready successively and then the head node restores data
traffic to the active path.
2.19.2 Configuring the WTR Function of a TE Tunnel

This procedure describes how to configure the WTR function of a TE tunnel.
Steps
1. Configure the TE WRT time.
2-179
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10(config-mpls-te)#reoptimize timers delay
Sets the WTR period before
installation-delay-time <timer>
switchback in global mode, unit:

seconds.
<timer>: switchback and deletion delay duration.

Command
Function
Checks the WRT duration

configured by a user.
End of Steps
2.19.3 TE Tunnel WTR Configuration Instance

In Figure 2-32, two tunnels are established from P1 to P3, Tunnel1 passes through P1,
P2, and P3, and Tunnel2 passes through P1 and P3. Tunnel1 is the active tunnel, Tunnel2
is the backup tunnel, and they form an FRR relation. Configure the WTR period on P1.
When any fault occurs on the active tunnel, the backup tunnel implements protection and
traffic is switched over to the backup tunnel. If the fault on the active tunnel is cleared,
traffic is switched back to the active tunnel after a WTR period.
Figure 2-32 TE Tunnel WTR Configuration Instance
2-180
SJ-20140731105308-012|2014-10-20 (R1.0)
Configuration Flow
1. Establish OSPF neighbors for the directly-connected interfaces on P1, P2, and P3,
and enable the TE function on the OSPF neighbors.
2. Establish two strict paths. One is the active path through P1, P2, and P3, and the
other is the backup path through P1 and P3.
3. Enable the TE function on all interfaces used on P1, P2, and P3, and configure a
backup tunnel on gei-0/2/1/1 of P1.
4. Create an active tunnel and a standby tunnel, and enable the FRR facility function on
the active tunnel.
5. Configure the WTR period on P1.
6. Configure a static route to the destination on P1, with the next hop Tunnel1. With this
configuration, traffic is forwarded through Tunnel1.
P1(config-mpls-te)#reoptimize timers delay installation-delay-time 600
2-181
SJ-20140731105308-012|2014-10-20 (R1.0)


2-182
SJ-20140731105308-012|2014-10-20 (R1.0)



2-183
SJ-20140731105308-012|2014-10-20 (R1.0)

Run the show mpls traffic-eng tunnels brief command to check the FRR establishment
information on P1 after the tunnel gets up. The execution result is displayed as follows:
Signalling Summary:
Forwarding: enabled
TUNNEL NAME
DESTINATION
tunnel_1
3.1.1.1
UP IF
-
DOWN IF
gei-0/2/1/1
STATE/PROT
up/up
tunnel_2
3.1.1.1
gei-0/2/1/3
up/up

Protected Tunnel LspID In-label Out intf/label
Tunnel1
86
Tun hd
FRR intf/label Status
gei-0/2/1/1:147456 Tu2:3
ready

LSP identifier
Run the show mpls traffic-eng fast-reroute command to check the FRR status on P1 if the
active tunnel is faulty and the traffic is switched over to the standby tunnel, and FRR is in
active status. The execution result is displayed as follows:
Tunnel1
86
Tun hd
gei-0/2/1/3:147456 Tu2:3
active

LSP identifier
After the fault on the active tunnel is cleared, FRR is still active in the WTR period, and
traffic is still forwarded through the standby tunnel. Run the show mpls traffic-eng fast-r
eroute Tunnel head end item information command to check the FRR status on P1. The
execution result is displayed as follows:
Tunnel1
86
Tun hd
gei-0/2/1/3:147456 Tu2:3
active
2-184
SJ-20140731105308-012|2014-10-20 (R1.0)

LSP identifier
After the WRT period reaches 600 s, the FRR status is restored to ready, and traffic is
forwarded through the active tunnel. Run the show mpls traffic-eng fast-reroute command
to check the FRR status on P1. The execution result is displayed as follows:
Tunnel1
86
Tun hd
gei-0/2/1/1:147456 Tu2:3
ready

LSP identifier
2.20 TE Tunnels Supporting Soft Preemption

2.20.1 TE Tunnels Supporting Soft-Preemption
In an MPLS network, when a TE tunnel is established, it has two attributes, priority upon
establishment and priority after establishment.
Priority upon establishment refers to the priority of a tunnel being established, range: 07, 0
is the highest priority. When the resources are insufficient, this priority determines whether
the LSP can preempt the tunnel resources that have been UP.
Priority after establishment refers to the priority when a tunnel is established. Range: 07,
in which 0 is the highest priority. This priority is relative to being preempted. The higher
the priority after establishment of the current node, the more difficult its resources can be
preempted.
In general, the priority upon establishment cannot be higher than the priority after
establishment, that is, the value of the priority upon establishment cannot be lower than
that of the Priority after establishment. Otherwise, the tunnel will be in flapping status.
Tunnel preemption includes hard preemption and soft preemption.
Hard preemption: The preempted tunnel is directly disconnected upon preemption.
Therefore, the services bored on the preempted tunnels may be interrupted.
In Figure 2-33, the priority upon establishment of Tunnel1 is higher than the priority after
establishment of Tunnel2 (R1 and R5 links are interrupted).
l
l
The path of Tunnel2 is R2R1R4 (in UP status).

The path calculated for Tunnel1 is R0R1R4R5 (in signaling status).
2-185
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 2-33 Hard Preemption
Because the bandwidth used between R1 and R4 is insufficient, Tunnel1 preempts the
bandwidth resources of Tunnel2 on the preemption point R1. At this time, Tunnel2 sends
resv-tear to the upstream node at R1 and sends path-tear to the downstream node to tear
the tunnel. After that, Tunnel2 recalculates the path along R2R3R5R4. However,
during Tunnel2 becomes up from down, services bored on Tunnel2 may be interrupted.
Soft preemption: The preempted tunnel is not directly disconnected upon preemption.
Signaling messages are sent to the head node of the tunnel to notify the head node to
perform re-optimization, without going through the link on which preemption occurs. In this
way, the service interruption risk from directly disconnecting a tunnel upon hard preemption
is greatly reduced.
In Figure 2-34, the priority upon establishment of Tunnel1 is higher than the priority after
establishment of Tunnel2 (R1 and R5 links are interrupted).
l
l
The path of Tunnel2 is R2R1R4 (in UP status).

The path calculated by Tunnel1 is R0R1R4R5 (in signaling status).
Figure 2-34 Soft Preemption
Because the bandwidth used between R1 and R4 is insufficient, Tunnel1 preempts the
bandwidth resources of Tunnel2 on the preemption point R1. In this case, Tunnel2
2-186
SJ-20140731105308-012|2014-10-20 (R1.0)
sends a path-err message to the upstream node at R1 to notify the head node R2 of
Tunnel2 to re-optimize Tunnel2, without going through the link R1R4. The recalculated
path is R2R3R5R4. After Tunnel2 is successfully re-optimized, the previous LSP
(R2R1R4) is disconnected, Tunnel2 is not down during preemption and services will
not be interrupted. However, soft preemption cannot completely avoid service interruption
due to preemption. For example, if pre-optimization fails, services may be interrupted.
2.20.2 Configuring a TE Tunnel Supporting Priorities and Soft

Preemption
This procedure describes how to enable a TE tunnel to support priorities and soft
preemption.
Steps
1. Configure a TE tunnel priority.
Step
Command
Function
<tunnel-number>
configuration mode.
Configures the setup priority
tunnel-number)#tunnel mpls traffic-eng priority
and hold priority of a tunnel.
<setup-priority><hold-priority>
The highest priority is 0. The

setup priority cannot be higher
than the hold priority.
<setup-priority>: setup priority of a tunnel, range: 0-7.

<hold-priority>: hold priority of a tunnel, range: 0-7.
2. Configure the soft preemption parameters and enable the soft preemption function of
a tunnel.
Step
Command
Function
ZXR10(config-mpls-te)#soft-preemption timeout
Sets the LSP keepalive time
<timeout>
for MPLS-TE soft preemption.
<tunnel-number>
configuration mode.
Enables the soft preemption
number)#tunnel mpls traffic-eng soft-preemption
function on a tunnel.
<timeout>: LSP keepalive time for MPLS-TE soft preemption.Range: 1-300, detault:
30, unit: seconds.
2-187
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#show mpls traffic-eng soft-preemption
Checks the local tunnel soft

preemption configuration, soft
preemption keepalive time, and
information about the tunnels
involved in soft preemption.
Checks the configuration for
[tunnel-id<tunnel_id> lsp-id<lsp_id> ingress-id <ingress_id>
remote tunnel soft preemption.
egress-id<egress_id>]
End of Steps
2.20.3 Instance of TE Tunnels Supporting Soft Preemption

In Figure 2-35, a TE tunnel (ISIS-TE) is established following IGP-TE. The available
bandwidth of all TE interfaces is 500 M, the reserved bandwidth of Tunnel1 and Tunnel2
is 500 M, and the priority upon establishment of Tunnel2 is higher than the priority after
establishment of Tunnel1.
The path of Tunnel1 (in up status) is P2>P3>P5.
The path calculated by Tunnel2 is P1>P3>P5 (in signaling status).
Because the bandwidth of the link P3>P5 is insufficient, Tunnel2 will preempt the
bandwidth of Tunnel1.
Figure 2-35 Instance of TE Tunnels Supporting Soft Preemption
2-188
SJ-20140731105308-012|2014-10-20 (R1.0)
Configuration Flow
1. Configure a loopback address and interface address on each of six devices.
2. Establish ISIS neighbor relation among interconnected interfaces, enable the TE
function on both ISISs and interfaces, and set an available bandwidth for the dynamic
TE to 500 M.
3. Configure a dynamic TE Tunnel1 on P2 to P5, using dynamic routing, with a reserved
bandwidth of 500 M, the priorities upon and after establishment 7, and the soft preemption function enabled.
4. Configure a dynamic TE Tunnel2 on P1 to P5, using dynamic routing, with a reserved
bandwidth of 500 M, and the priorities upon and after establishment 6.
Because the bandwidth of the link P3>P5 is insufficient, Tunnel2 will preempt the
bandwidth of Tunnel1. Tunnel1 sends a path-err message on P3 to P2 to notify P2 to
re-optimize Tunnel1, without going through the link P3>P5. The re-optimized path is
P2>P4>P6>P5.
P1(config-gei-0/2/0/6)#no shutdown
P1(config-gei-0/2/0/6)#ip address 106.172.1.1 255.255.255.0
P1(config-gei-0/2/0/6)#exit
P1(config)#
2-189
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te-if-gei-0/2/0/6)#bandwidth dynamic 1000000 percent 50
P1(config-mpls-te-tunnel-te_tunnel2)#tunnel mpls traffic-eng priority 6 6

2-190
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng soft-preemption

P3(config-isis-10)#is-type
level-1
2-191
SJ-20140731105308-012|2014-10-20 (R1.0)

P3(config)#

2-192
SJ-20140731105308-012|2014-10-20 (R1.0)


2-193
SJ-20140731105308-012|2014-10-20 (R1.0)


P6(config-isis-10)#system-id 2008.561c.41a2
2-194
SJ-20140731105308-012|2014-10-20 (R1.0)

1. Run the show mpls traffic-eng tunnels brief command to check the establishment
status (path: P2->P3->P5) of Tunnel1 on P2 before configuring Tunnel2 on P1. The
Signalling Summary:
Forwarding:enabled
TUNNEL NAME
DESTINATION
UP IF
DOWN IF
STATE/PROT
tunnel_1
73.73.73.1
gei-0/1/0/7
up/up
P2#show mpls traffic-eng tunnels te_tunnel 1

Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid

Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
BFD: disabled
Track Name:
2-195
SJ-20140731105308-012|2014-10-20 (R1.0)

CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
Include-any: None
Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
Soft Preemption: enabled
RSVP Path Info:
Explicit Route: 107.44.44.4 107.44.44.72 13.13.13.1 13.13.13.2 73.73.73.1
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
Clear mpls rsvp(lspid:2,errcode:1,errvalue:7).
Clear mpls rsvp(lspid:10,errcode:1,errvalue:7).
Path error: admission fail(lspid:9,errcode:1,errvalue:2).
2. After Tunnel2 is configured on P1, Tunnel1 sends a path-err message from P3 to P2.
After receiving the path-err message, P2 re-optimizes Tunnel1. The calculated path
is P2>P4>P6>P5, without going through the link P3>P5. In this way, Tunnel1
is re-optimized, the original LSP (P2>P3>P5) is disconnected, and Tunnel1 will
2-196
SJ-20140731105308-012|2014-10-20 (R1.0)
never get down during preemption. Therefore, services bored on Tunnel1 will not
be interrupted. Run the show mpls traffic-eng tunnels te_tunnel 1 command on P2 to
check the path after re-optimization (P2>P4>P6>P5).
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid

Config Parameters:
Resv-Style: SE
Hop Prior: disabled
Upper Limit: -
BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
Include-any: None
Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
Soft Preemption: enabled
2-197
SJ-20140731105308-012|2014-10-20 (R1.0)

RSVP Path Info:
Explicit Route: 1.0.13.4 1.0.13.52 15.73.52.52 15.73.52.73 14.1.1.2 14.1.1.1
73.73.73.1
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
2.21 Equal Load Sharing on the TE-ECMP

2.21.1 Equal Load Sharing on the TE-ECMP
ECMP configures multiple TE tunnels with the same source and destination addresses to
a load sharing group. A load sharing policy (per-flow or per-packet) is configured for the
group as needed.
2.21.2 Configuring Equal Load Sharing on the TE-ECMP

This procedure describes how to configure equal load sharing on the TE-ECMP.
Steps
1. Configure equal load sharing on the TE-ECMP.
Step
Command
Function
ZXR10(config)#te-ecmp-group <te-ecmp-id>
Configures a TE-ECMP load

sharing group in global mode.
ZXR10(config-te-ecmp-group-te-ecmp-id)#tunnel
Binds the TE tunnel to the
<tunnel-id>
TE-ECMP load sharing group.
ZXR10(config-te-ecmp-group-te-ecmp-id)#load-sha
Sets the load sharing policy
ring policy {per-stream | per-packet}
for the load sharing group to

per flow or per packet.
<te-ecmp-id>: TE-ECMP load sharing group ID. At present, 128 sharing groups can be
configured.
{per-stream | per-packet}>: per-stream indicates per flow, per-packet indicates per
packet.
2-198
SJ-20140731105308-012|2014-10-20 (R1.0)

Command
Function
ZXR10#show te-ecmp-group {all|id}
Checks the configured

load sharing group and the
information about the binding
relation with the TE tunnel.
all: indicates all configured sharing groups; id: indicates a sharing group.
End of Steps
2.21.3 Instance of Equal Load Sharing Configuration on the

TE-ECMP
In Figure 2-36, two common RSVP tunnels are established from P1 to P2 in strict routing
mode through OSPF TE, and the two tunnels are bound to the load sharing group in
accordance with the per packet policy.
Figure 2-36 Instance of Equal Load Sharing Configuration on the TE-ECMP
Configuration Flow
1. Establish OSPF neighbors on the directly-connected interfaces of P1 and P2, and
enable the TE function on the OSPF neighbors.
2. Enable the TE function on the directly-connected interfaces of P1 and P2.
3. Establish Tunnel1 and Tunnel2 on P1 in the same way.
4. Configure a load sharing group, define the per-packet policy, and bind Tunnel1 and
Tunnel2 to the load sharing group.
2-199
SJ-20140731105308-012|2014-10-20 (R1.0)

2-200
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config)#te-ecmp-group 1
P1(config-te-ecmp-group-1)#load-sharing policy per-packet
P1(config-te-ecmp-group-1)#tunnel 1
P1(config-te-ecmp-group-1)#tunnel 2
P1(config-te-ecmp-group-1)#exit

Run the show te-ecmp-group 1 command to check the information about the tunnel ECMP
group. The execution result is displayed as follows:
P1(config)#show te-ecmp-group 1
TE-ECMP group 1
2-201
SJ-20140731105308-012|2014-10-20 (R1.0)

Load-sharing policy: per-packet
Member tunnel: 1
Member tunnel: 2
2.22 TE Affinity
2.22.1 TE Affinity Introduction
TE Color is an abstract TE link attribute. By limiting some types of traffic for some types
of links, or displaying some excluded link types for paths with some types of traffic,
this attribute implements the routing policy for some services and achieves the network
engineering purpose.
2.22.2 Configuring the TE Affinity

This procedure describes how to configure the TE affinity of a TE tunnel.
Steps
1. Configure the value of the MPLS TE affinity.
Step
Command
Function
Enters TE interface
configuration mode.
ZXR10(config-mpls-te-if-interface-name)#affinity
attribute bit-position <value>
Sets the affinity attribute bit

position of a TE interface,
range: 031. At most 32
affinity attribute bits can be
configured for an interface.
<tunnel-number>
configuration mode.
Configures three affinity
number)#tunnel mpls traffic-eng affinity { exclude-any |
attribute constraints in
include-any | include-all } bit-position <value>
accordance with the affinity bit

position, range: 031.
At most three types of affinity
commands (32 commands)
are supported by a TE tunnel.
2-202
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#show mpls traffic-eng interface detail [< interface name
Displays the affinity configuration
>]
on an interface.
ZXR10#show mpls traffic-eng tunnels [te_tunnel <tunnel_id>]
Displays the local tunnel affinity

configuration.
Displays the remote tunnel
[tunnel-id<tunnel_id> lsp-id<lsp_id> ingress-id <ingress_id>
affinity configuration.
egress-id<egress_id>]
End of Steps
2.22.3 TE Affinity Configuration Instance

Figure 2-37 shows a TE tunnel established among P1-P2-P3-P4 through an IGP-TE, the
egress interface is configured to have the affinity attribute, and the tunnel is configured
with affinity constraint, including include-any, include-all, and exclude-any.
Figure 2-37 TE Affinity Configuration Instance
The head node notifies the affinity constraint of the tunnel to downstream nodes through
the flag of the SESSION_ATTRIBUTE object in RSVP-PATH. A tunnel can be established
successfully only when the affinity attributes of all egress interfaces meet the tunnel affinity
constraint.
Configuration Flow
1. Configure the interfaces connecting P1, P2, P3, and P4, and the corresponding
loopback interface addresses.
2. Configure OSPF neighbors for P1, P2, P3, and P4, and enable the TE function on the
OSPF neighbors.
3. Enable the TE function of the loopback interfaces of P1, P2, P3, and P4, and configure
4. Enable the TE function on interfaces of P1, P2, P3, and P4, and configure the following
affinity attributes for the egress interfaces of P1, P2, and P3.
P1:
gei-0/1/0/1: 0, 2, 21, 25, 30
2-203
SJ-20140731105308-012|2014-10-20 (R1.0)

gei-0/1/0/2: 0, 21, 25
P2:
gei-0/2/0/1:
2, 21, 25
gei-0/2/0/2: 6, 21, 25
P3:
gei-0/1/0/3:
0, 2, 25
gei-0/1/0/6: 0, 21, 25, 28
5. Configure tunnel 1 on P1, with the destination address P4 and dynamic routing, and
configure affinity constraint conditions include-any 0, include-any 2, include-all 21,
include-all 25, exclude-any 30, and exclude-any 31.
6. After tunnel 1 gets up, check whether the egress interfaces meet the tunnel affinity
constraint. The egress interfaces are in the following sequence:
gei-0/1/0/2 on P1, gei-0/2/0/1 on P2, and gei-0/1/0/6 on P3.
P1(config-mpls-te-if-gei-0/1/0/1)#affinity attribute bit-position 0
2-204
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te-if-gei-0/1/0/2)exit
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng affinity include-any
bit-position 0
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng affinity include-any
bit-position 2
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng affinity include-all
bit-position 21
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng affinity include-all
bit-position 25
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng affinity exclude-any
bit-position 30
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng affinity exclude-any
bit-position 31

P2(config-if-gei-0/1/0/1)#no shut
2-205
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-mpls-te)#

2-206
SJ-20140731105308-012|2014-10-20 (R1.0)

P3(config-mpls-te)#

2-207
SJ-20140731105308-012|2014-10-20 (R1.0)

P4(config-mpls-te)#
1. Run the show this !<mpls-te> command to check the configuration result after
configuring the affinity attribute on the interface of P1. The execution result is
P1(config-mpls-te-if-gei-0/1/0/1)#show this
!<mpls-te>
affinity attribute bit-position 0
!</mpls-te>
2. Check the interface information on P1, in which the Affinity attributes(Bit position)
field displays the configured affinity attribute.
P1#show mpls traffic-eng interface detail gei-0/1/0/1
gei-0/1/0/1:
State:
ENABLE
Key:
<encrypted>
Type:
md5
Challenge:
disabled
2-208
SJ-20140731105308-012|2014-10-20 (R1.0)

Window size:
32
BFD: disabled
Backup path:
None
SRLGs: None
Affinity attributes(Bit position):
0,2,21,25,30
DSCP: None
Fast-Hello miss: 4
3. Run the show this !<mpls-te> command to check the configuration result after
configuring the affinity constraint on the tunnel of P1. The execution result is displayed
as follows:
!<mpls-te>
tunnel mpls traffic-eng affinity exclude-any bit-position 30
tunnel mpls traffic-eng affinity exclude-any bit-position 31
tunnel mpls traffic-eng affinity include-any bit-position 0
tunnel mpls traffic-eng affinity include-any bit-position 2
tunnel mpls traffic-eng affinity include-all bit-position 21
tunnel mpls traffic-eng affinity include-all bit-position 25
!</mpls-te>
4. Check the tunnel information on P1, in which the Affinity(Bit position) field displays
the configured affinity constraint.
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid

Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
2-209
SJ-20140731105308-012|2014-10-20 (R1.0)

BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: 30-31
Include-any: 0,2
Include-all: 21,25
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
RSVP Path Info:
Explicit Route: 2.1.1.1 2.1.1.2 9.1.1.2 9.1.1.4 17.1.1.4 17.1.1.5
104.104.104.104
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
2-210
SJ-20140731105308-012|2014-10-20 (R1.0)
5. Run the show ip ospf database opaque-area self-originate command to check the
notified affinity attribute of the IGP-TE database interface on P1. The execution result
is displayed as follows:
P1#show ip ospf database opaque-area self-originate
Type-10 Opaque Link Area Link States
(Area 0.0.0.0)
LS age: 282
Opaque Type: 1
Opaque ID: 0
Checksum: 0xe320
Length: 28
Fragment number : 0
Number of Links : 0
LS age: 779
Opaque Type: 1
Opaque ID: 1
LS Seq Number: 0x8000000f
Checksum: 0x71d1
Length: 124
Fragment number : 1
Link ID : 1.1.1.2
Admin Metric : 0
Priority 0 : 2500000
Affinity Bit : 0x42200005

Number of Links : 1
LS age: 1122
2-211
SJ-20140731105308-012|2014-10-20 (R1.0)

Opaque Type: 1
Opaque ID: 2
Checksum: 0xb223
Length: 124
Fragment number : 2
Link ID : 2.1.1.2
Admin Metric : 0
Priority 0 : 0
Priority 1 : 0
Priority 2 : 0
Priority 3 : 0
Priority 4 : 0
Priority 5 : 0
Priority 6 : 0
Priority 7 : 0
Affinity Bit : 0x2200001

Number of Links : 1
6. After the tunnel of P1 gets up, run the show mpls traffic-eng tunnels te_tunnel 1
command to check whether all egress interfaces of the tunnel meet the tunnel affinity
constraint.
Because only gei-0/1/0/2 of P1, gei-0/2/0/1 of P2, and gei-0/1/0/6 of P3 meet the affinity
attribute, the tunnel will not go along other paths.
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid

Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
2-212
SJ-20140731105308-012|2014-10-20 (R1.0)

BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: 30-31
Include-any: 0,2
Include-all: 21,25
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
RSVP Path Info:
Explicit Route: 2.1.1.1 2.1.1.2 9.1.1.2 9.1.1.4 17.1.1.4 17.1.1.5
104.104.104.104
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
2-213
SJ-20140731105308-012|2014-10-20 (R1.0)

2.23 Binding Interfaces Supporting TE Bandwidth

Reservation
2.23.1 Binding Interfaces Supporting TE Bandwidth Reservation
If a binding interface supports TE bandwidth reservation, the TE LSP selects an active
member link of the SG interface to reserve a bandwidth and forwards traffic. Traffic
is forwarded strictly through a member interface and not shared among all member
interfaces.
Similar binding interfaces include the smartgroup, posgroup, and multilink interfaces.
2.23.2 Configuring Binding Interfaces Supporting TE Bandwidth

Reservation
This procedure describes how to enable a binding interface to support TE bandwidth
reservation.
Steps
1. Configure TE tunnel re-optimization.
Step
Command
Function
Enters TE interface
configuration mode.
ZXR10(config-mpls-te-if-interface-name)#te-tr
Enables the TE bandwidth
unk
management mode on the

bound interface.

Command
Function
ZXR10#show mpls traffic-eng interface detail [< interface name
Checks whether the TE
>]
bandwidth management mode is

enabled on the bound interface.
End of Steps
2-214
SJ-20140731105308-012|2014-10-20 (R1.0)
2.23.3 Configuration Instance for Binding Interfaces Supporting TE

Bandwidth Reservation
In Figure 2-38, two interfaces on P1 and P2 are bound to the smartgroup binding interface.
In the network, the MPLS TE tunnel is established through OSPF-TE, the tunnel path is
P1-P2, and the egress of the tunnel is the smartgroup binding interface.
Figure 2-38 Configuration Instance for Binding Interfaces Supporting TE Bandwidth
Reservation
Configuration Flow
1. Configure the smartgroup binding interface, and bind gei-0/1/0/1 and gei-0/1/0/2 to the
smartgroup1 interface on P1 and P2.
2. Configure the routing protocol OSPF on P1 and P2.
3. Configure the MPLS-TE on P1 and P2, and enable the TE function on the smartgroup1
interface.
4. Configure the TE tunnel tunnel1, configure a 10 M reserved bandwidth for the tunnel
and configure the smartgroup1 interface as the egress of the TE tunnel.
5. Set the bandwidth reservation management mode of the smartgroup1 interface to
te-trunk, and the bandwidth to 10 M.
P1(config)#interface smartgroup1
P1(config-if-smartgroup1)#exit
P1(config)#lacp
P1(config-lacp)#interface smartgroup1
P1(config-lacp-sg-if-smartgroup1)#lacp mode 802.3ad
P1(config-lacp-sg-if-smartgroup1)#exit
P1(config-lacp)#interface gei-0/1/0/1
P1(config-lacp-member-if-gei-0/1/0/1)#smartgroup 1 mode active
P1(config-lacp-member-if-gei-0/1/0/1)#exit
P1(config-lacp)#exit
2-215
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-if-smartgroup1)#ip address 19.18.17.11 255.255.255.0
P1(config-mpls-te)#interface smartgroup1
P1(config-mpls-te-if-smartgroup1)#exit
P1(config-mpls-te)#explicit-path name 1
P1(config-mpls-te-if-smartgroup1)#te-trunk
P1(config-mpls-te-if-smartgroup1)#bandwidth 10000

P2(config)#lacp
P2(config-lacp)#interface smartgroup1
P2(config-lacp-sg-if-smartgroup1)#lacp mode 802.3ad
P2(config-lacp-sg-if-smartgroup1)#exit
2-216
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-lacp)#exit
P2(config-if-smartgroup1)#no shutdown
P2(config-if-smartgroup1)#ip address 19.18.17.22 255.255.255.0
P2(config-mpls-te)#
1. Run the show lacp 1 internal command to check the binding interface information on
P1. The execution result is displayed as follows:
P1(config)#show lacp 1 internal
Smartgroup:1
Flags:
* - Port is Active member Port

S - Port is requested in Slow LACPDUs
F - Port is requested in Fast LACPDUs
A - Port is in Active mode
P - Port is in Passive mode
Actor
Agg
LACPDUs
Port[Flags]
State
Interval Pri
Port
Oper
Port
Key
State Machine
RX
Mux
Machine
-------------------------------------------------------------------------------gei-0/1/0/2[SA*]
ACTIVE
30
32768 0x111
0x3d
CURRENT
COLL&DIST
gei-0/1/0/1[SA*]
ACTIVE
30
32768 0x111
0x3d
CURRENT
COLL&DIST
2. Run the show rsvp bandwidth interface command to check the bandwidth reservation
information of the TE interface on P1. The execution result is displayed as follows:
P1(config)#show rsvp bandwidth interface
2-217
SJ-20140731105308-012|2014-10-20 (R1.0)

config: Reserved bandwidth is defined for the future TE-LSP (kbps)
maxAvail: Maximum bandwidth can be allocated (kbps)
used: Bandwidth is allocated for the existed TE-LSP (kbps)
Static perflow: 0
Static percent: 0
Dynamic perflow:0
Dynamic percent:40
Config
MaxAvail
Used
Static
reserve
10000
10000
10000
Dynamic
reserve
Static perflow: 0
Static percent: 0
Dynamic perflow:0
Dynamic percent:40
Config
MaxAvail
Used
Static
reserve
10000
Dynamic
reserve
Interface: smartgroup1
Static perflow: 0
Static percent: 0
Dynamic perflow:0
Dynamic percent:40
Config
MaxAvail
Used
Static
reserve
10000
10000
10000
Dynamic
reserve
3. Run the show mpls traffic-eng tunnels te_tunnel 1 command on P1 to check which
member interface of the smartgroup1 interface is the egress on the tunnel. The
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid

Config Parameters:
Resv-Style: SE
Hop Prior: disabled

Upper Limit: -
2-218
SJ-20140731105308-012|2014-10-20 (R1.0)

BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
Include-any: None
Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
InLabel: OutLabel: smartgroup1(gei-0/1/0/2), 3
RSVP Path Info:
Explicit Route: 19.18.17.11 19.18.17.22 2.2.2.2
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
2-219
SJ-20140731105308-012|2014-10-20 (R1.0)

Resv tear:resv tear(lspid:4,errcode:66,errvalue:0).
The output information shows that the member interface gei-0/1/0/2 of smartgroup1 is
selected as the egress interface of the tunnel.
2.24 RSVP-TEs Supporting Resource Reservation

2.24.1 Resource Reservation in FF Mode on the RSVP-TE
Resource reservation refers to reserving resources for different transmitting ends in the
same session.
The ZXR10 M6000-S supports two reservation modes:
l
l
Fixed Filter (FF): in which, resources are reserved for every transmitting end.
Shared Explicit (SE): in which, resources are shared among specified transmitting
ends.
This function configures a tunnel to dynamically support both the FF and SE modes.
2.24.2 Configuring RSVP-TE Supporting Resource Reservation

This procedure describes how to enable a TE tunnel to support resource reservation.
Steps
1. Enable a TE tunnel to support resource reservation.
Step
Command
Function
<tunnel-number>
configuration mode.
Sets the tunnel to support FF
number)#tunnel mpls traffic-eng resv-style {ff | se}
(ff) or SE (se) style. Default:
se.
The FF style and the
FRR function are mutually
exclusive. If the FRR function
is enabled first on a tunnel, the
FF style cannot be configured.
If the FF style is configured on
a tunnel first, the FRR function
cannot be configured.

2-220
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
End of Steps
2.24.3 Instance for Resource Reservation in FF Mode on the

RSVP-TE
Figure 2-39 shows a configuration instance, in which a tunnel is established among
P1-P2-P3 through the IGP-TE, an available bandwidth is configured for the egress
interface, a reserved bandwidth is configured for the tunnel, and the resource reservation
mode configured for the tunnel is SE (default) or FF.
Figure 2-39 Instance for Resource Reservation Configuration on the RSVP-TE
After a resource reservation mode is successfully configured, you can check whether the
resource reservation mode in the tunnel information is correct on the head node. A tunnel
supports only one resource reservation mode. If you modify the mode of a tunnel, the
tunnel will be cleared and re-established.
To enable a tunnel to support FRR or multiple LSPs of the same tunnel to share the
bandwidth, the resource reservation mode must be set to SE.
Configuration Flow
1. Configure the interfaces connecting P1, P2, and P3, and the corresponding loopback
interface addresses.
2. Configure OSPF neighbors for P1, P2, and P3, and enable the TE function on the
OSPF neighbors.
3. Enable the TE function on the loopback interfaces of P1, P2, and P3, and configure
4. Enable the TE function on the physical interfaces of P1, P2, and P3, and configure an
available bandwidth of 20 M for the egress interfaces of P1 and P2.
5. Configure TE tunnel 1 on P1, with the destination address P3, dynamic routing mode,
reserved bandwidth of 20 M, and resource reservation mode of FF.
2-221
SJ-20140731105308-012|2014-10-20 (R1.0)
Note:
When the FRR function is configured in tunnel 1, the system prompts that the FRR function
is conflicting with the FF resource reservation mode.
P1(config-mpls-te-tunnel-te_tunnel1)#tunnel mpls traffic-eng resv-style ff

2-222
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-mpls-te)#inter gei-0/1/0/1
P2(config-mpls-te)#inter gei-0/2/0/1
P2(config-mpls-te)#

P3(config-mpls-te)#
2-223
SJ-20140731105308-012|2014-10-20 (R1.0)
1. Run the following command to check the configuration of a tunnel. ff in the displayed
result indicates that the resource reservation mode is FF.
!<mpls-te>
tunnel mpls traffic-eng resv-style ff
!</mpls-te>
2.
Run the following command to check the tunnel information on P1. Resv-Style: FF
in the displayed result indicates that the resource reservation mode FF is correct.
Name: tunnel_1
Status:
Admin: up
Oper: up
Path:
valid

Config Parameters:
Resv-Style: FF
Hop Prior: disabled

Upper Limit: -
BFD: disabled
Track Name:
CBS: 0 byte
EIR: 0 kbps
EBS: 0 byte
Exclude-any: None
2-224
SJ-20140731105308-012|2014-10-20 (R1.0)

Include-any: None
Include-all: None
AutoRoute: disabled
AUTO-BW: disabled
Crankback: disabled
RSVP Path Info:
Explicit Route: 1.1.1.1 1.1.1.2 9.1.1.2 9.1.1.4 103.103.103.103
Exclude Route: NULL
Record Route: NULL
RSVP Resv Info:
Record Route: NULL
History:
Tunnel:
3. No that when you configure the FRR with the resource reservation mode set to FF, a
conflict prompt is displayed, for example:
%Error 90953: MPLS-TE resv-style FF and FRR are mutually exclusive.
2-225
SJ-20140731105308-012|2014-10-20 (R1.0)
2-226
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 3
MPLS OAM Configuration

Table of Contents
MPLS OAM Overview ................................................................................................3-1
Configuring MPLS OAM .............................................................................................3-1
MPLS OAM Configuration Example............................................................................3-4
3.1 MPLS OAM Overview

MPLS Operation, Administration and Maintenance (OAM) technology provides a set of
mechanisms for failure detection on MPLS network. Through MPLS OAM, detection
function on the Constraint-based Routing Label Switched Path (CR-LSP) forwarding
plane can be realized.
MPLS OAM aims at the connectivity detection of single LSP, the source end sending/the
destination end detecting. The ingress node sends OAM connectivity detection packets
(Connectivity Verification (CV)/Fast Failure Detection (FFD)) periodically. The egress node
detects the packets periodically. The transit nodes transmit the packets transparently.
When the destination end detects a failure, it will send Backward Defect Indication (BDI)
packets to notify the LSP source node through the reversed tunnel to implement protection
handover.
Network administrators need to configure MPLS OAM function manually. Before the
configuration of MPLS OAM, it is necessary to establish the detecting tunnel and the
reversed tunnel.
It is necessary to configure MPLS OAM function on the ingress node of the detecting
tunnel and the packet type, and then enable OAM to send the detection packets. It is also
necessary to configure MPLS OAM function on the egress node of the detecting tunnel,
and then configure the corresponding command to receive and detect MPLS OAM packets.
3.2 Configuring MPLS OAM

This procedure describes how to configure MPLS OAM.
Steps
1. To enable MPLS OAM globally, run the following command:
3-1
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10(config)#mpls oam
Enables MPLS OAM globally,

and enters MPLS OAM global
configuration mode.
2. To enable MPLS OAM on a tunnel, perform the following steps:

Step
Command
Function
ZXR10(config-mpls-oam)#local te_tunnel < tunnel-id>
Enables MPLS OAM on the
ingress <ingress-id>
local tunnel.
ZXR10(config-mpls-oam-te_tunnel-tunnel-id)#t
Configures the type and
ype cv [ exp <exp-priority>]
priority of MPLS OAM
ZXR10(config-mpls-oam-te_tunnel-tunnel-id)#t
detection packets.
ype ffd frequence <interval >[ exp <exp-priority>]

3
ZXR10(config-mpls-oam-te_tunnel-tunnel-id)#m
Enables MPLS OAM (the
pls oam enable
ingress node starts to send

detection packets).
ZXR10(config-mpls-oam)#egress te_tunnel
Enables MPLS OAM on the
<tunnel-id> ingress <ingress-id> backward-tunnel
tail node of the tunnel.
<tunnel-id>[share] type {cv |ffd frequence <interval>}
exp <exp-priority>: priority of MPLS OAM detection packets, range: 07.

<interval>: time interval (in milliseconds) for sending MPLS OAM detection packets,
options:
l 3.3
l 10
l 20
l 50
l 100
l 200
l 500
Command
Function
ZXR10#show mpls oam information local_tunnel
Displays information about all local

tunnels.
ZXR10#show mpls oam information remote_tunnel
Displays information about all remote

tunnels.
ZXR10#show mpls oam statistics local_tunnel {all | cv |
Displays information about all packets
ffd | bdi |fdi}
or the specified packets over all local

tunnels.
3-2
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 3 MPLS OAM Configuration
Command
Function
ZXR10#show mpls oam statistics local_tunnel
Displays statistical information about
<tunnel-id> ingress <ingress-id>{all | cv | ffd | bdi |fdi}
all packets or specified packets of a

specific local tunnel.
ZXR10#show mpls oam statistics remote_tunnel {all | cv
Displays statistical information about all
| ffd | bdi | fdi}
packets or the specified packets over all

remote tunnels.
ZXR10#show mpls oam statistics remote_tunnel
Displays statistical information about all
<ingress-id> ingress <ingress-id>{all | cv | ffd | bdi | fdi}
packets or the specified packets over

the specified remote tunnel.
Displays the debugging switch state.
ZXR10#show debug mpls-oam
4. Maintain MPLS OAM.

l To collect packet statistics, run the following commands:
Command
Function
ZXR10(config-mpls-oam)#statistics {all | cv | ffd |
Collects statistics on MPLS OAM
fdi | bdi}
packets on all tunnels.
ZXR10(config-mpls-oam-te_tunnel-tunnel-
id)#statistics {all | cv | ffd | fdi | bdi}
packets on the specified local tunnel.
ZXR10(config-mpls-oam)#statistics remote_tunnel
<tunnel-id> ingress <ingress-id>{all | cv | ffd | bdi|
packets on the specified remote
fdi}
tunnel.
There is no output result of the commands to collect packet statistics. After the
commands are executed, run related show commands to display the sending and
receiving statistical information about OAM packets on the tunnels where MPLS
OAM is enabled.
l
To clear packet statistics, run the following commands:

Command
Function
ZXR10#clear mpls oam statistics local_tunnel
Clears the statistics information about
<tunnel-id> ingress <ingress-id>{all | cv | ffd | fdi
the specified packets on the specified
| bdi}
local static tunnel.
ZXR10#clear mpls oam statistics remote_tunnel
Clears the statistical information about
<tunnel-id> ingress <ingress-id>{all | cv | ffd | fdi
the specified packets on the specified
| bdi}
remote static tunnel.
There is no output result of the commands to clear statistics of packets. After

the commands are executed, the result of the packet statistics displayed by using
related show commands are cleared, and the information is collected again.
l
To debug MPLS OAM-related functions, run the following commands:

3-3
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#debug mpls oam all
Enables the debugging of all MPLS OAM

functions.
Enables the debugging of MPLS OAM CV
ZXR10#debug mpls oam cv
packets.
Enables the debugging of MPLS OAM FDI
ZXR10#debug mpls oam fdi
packets.
Enables the debugging of MPLS OAM BDI
ZXR10#debug mpls oam bdi
packets.
End of Steps
3.3 MPLS OAM Configuration Example

Figure 3-1 shows a sample network topology. It is required to establish two tunnels
between PE1 to PE2. Tunnel1001 is the detection tunnel, and Tunnel1002 is the reverse
tunnel.
Figure 3-1 MPLS OAM Configuration Example
Configuration Flow
Set Tunnel1001 to the detecting tunnel, set Tunnel1002 to the reversed tunnel. Enable
MPLS OAM to detect the local tunnels on the head node of Tunnel1001. Enable MPLS
OAM to detect the remote tunnels on the tail node of Tunnel1001.
Run the following commands to configure head node PE1:
3-4
SJ-20140731105308-012|2014-10-20 (R1.0)

PE1(config-if-gei-0/3/0/4)#ip address 81.3.3.1/24
PE1(config)#ip address 4.81.81.81 255.255.255.255
PE1(config-if-te_tunnel1001)#ip unnumbered loopback1
PE1(config-if-te_tunnel1001)#exit
PE1(config-mpls-te)#interface loopback1
PE1(config-mpls-te-if-loopback1)#exit
PE1(config-mpls-te)#router-id 4.81.81.81
PE1(config-mpls-te-if-gei-0/3/0/4)#exit
PE1(config-mpls-te)#static te_tunnel1001
PE1(config-mpls-te-static-te_tunnel1001)#role ingress type unidirectional
PE1(config-mpls-te-static-te_tunnel1001)#ingress-tunnel-id 1001 ingress 4.81.81.81
egress 4.82.82.82
PE1(config-mpls-te-static-te_tunnel1001)#lsp 1
PE1(config-mpls-te-static-te_tunnel1001-lsp)#out-seg-info out-port gei-0/3/0/4
out-label 3 next-hop 81.3.3.2
PE1(config-mpls-te-static-te_tunnel1001-lsp)#exit
PE1(config-mpls-te-static-te_tunnel1001)#exit
PE1(config)#ip route 85.5.5.2 255.255.255.255 te_tunnel1001
Run the following commands to configure the MPLS OAM:

PE1(config)#mpls oam
PE1(config-mpls-oam)#local te_tunnel 1001 ingress 4.81.81.81
PE1(config-mpls-oam-te_tunnel-1001)#type ffd frequence 3.3
PE1(config-mpls-oam-te_tunnel-1001)#mpls oam enable
PE1(config-mpls-oam-te_tunnel-1001)#exit
PE1(config-mpls-oam)#exit
Run the following commands to configure tail node PE2:

PE2(config-if-gei-0/3/1/2)#ip address 81.3.3.2/24
3-5
SJ-20140731105308-012|2014-10-20 (R1.0)

PE2(config-if-te_tunnel91001)#ip unnumbered loopback1
PE2(config-mpls-te-static-te_tunnel91001)#role egress type unidirectional
egress 4.82.82.82
PE2(config-mpls-te-static-te_tunnel91001-lsp)#in-seg-info in-port gei-0/3/1/2 in-label 3
Run the following commands to configure the MPLS OAM:

PE2(config)#mpls oam
PE2(config-mpls-oam)#egress te_tunnel 1002 ingress 4.82.82.82 backward-tunnel 1001
share type ffd frequence 3.3
Run the following commands on P2 (for the basic static tunnel configuration, refer to
Chapter 4. A basic static tunnel has been established in this example).
P2(config)#mpls oam
P2(config-mpls-oam)#egress te_tunnel 2 ingress 1.1.1.2 backward-tunnel
1 share type ffd frequence 3.3
Run the show mpls oam information local_tunnel command to check whether the local
MPLS OAM of a tunnel is enabled on PE1. The execution result is displayed as follows:
PE1#show mpls oam information local_tunnel
Local tunnel Num : 1
State init Num : 0
State up Num
: 0
State down Num : 0

TunnelId
: 1001
LspId
: 1
IngressId
: 4.81.81.81
Node-Role
: Head
3-6
SJ-20140731105308-012|2014-10-20 (R1.0)

Ascription
: Yes
Packet
: FFD, Frequency: 3.3, Priority: 0
BkTunnel
: 0
Share
: No
Enable
: Yes
Trans-State
: OK(hex:0000)
Detect-State : OK(hex:0000)
Run the show mpls oam information remote_tunnel command to check whether the remote
MPLS OAM of a tunnel is enabled on PE2. The execution result is displayed as follows:
PE2#show mpls oam information remote_tunnel
Remote tunnel Num : 1
State init Num : 1
State up Num
: 0
State down Num : 0

TunnelId
: 1002
LspId
: 1
IngressId
: 4.82.82.82
Node-Role
: Tail
Ascription
: No
Packet
: FFD, Frequency: 3.3, Priority: 0
BkTunnel
: 1001
Share
: Yes
Enable
: Yes
Trans-State
: dInitStat(hex:ffff)
Detect-State : dInitStat(hex:ffff)
PE2#show mpls oam statistics remote_tunnel al
Tunnelid: 1002, Ingressid: 4.82.82.82
CV : 0
FFD: 0
BDI: 0
FDI: 0
3-7
SJ-20140731105308-012|2014-10-20 (R1.0)
3-8
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 4
Static Tunnel Configuration

Table of Contents
Static Tunnel Overview...............................................................................................4-1
Configuring a Static Tunnel ........................................................................................4-4
4.1 Static Tunnel Overview

A static tunnel is a tunnel configured manually by network administrators. It is not
necessary to trigger the static tunnel through MPLS signaling or interact with control
packets. Therefore, the static tunnel costs few resources and it is suitable for the networks
with small scale and simple topology. However, a static tunnel cannot be established by
using label distribution protocol to distributing labels dynamically. It is configured manually
by network administrators.
When configuring a static tunnel, network administrators need to distribute labels for the
LSRs manually. The value of the out-label on the previous node should equal to the value
of the in-label on the following node. This is the principle that should be complied with. The
LSRs on the static tunnel are not aware of the whole tunnel. Therefore, the static tunnel
is a local concept.
It is necessary to configure static tunnel commands on the LSRs of the whole tunnel,
including the head node, transit nodes and tail node. Only when the configuration on each
node of the tunnel is correct will the services be forwarded properly on the tunnel.
The connectivity of a static tunnel can be detected by MPLS OAM. When the active tunnel
has a fault, protection handover can be implemented immediately through MPLS OAM
detection.
4.1.1 Associated Bidirectional Tunnels for a Static TE Tunnel

Two types of bidirectional tunnels are provided: Shared and Associated. Shared
bidirectional tunnels can be implemented by enabling a static TE tunnel to forward data
in both forward and backward directions. Associated bidirectional tunnels refer to two
unidirectional tunnels (with the same tail nodes but in reverse directions) bound together
to implement the functions of a bidirectional tunnel. The two reverse paths of associated
bidirectional tunnels are not necessary to be overlapped. The binding relation is perceived
only at two ends. Associated bidirectional tunnels have an advantage over shared
bidirectional tunnels, that is, for associated bidirectional tunnels, signaling expansion is
not needed and resources areseparatelyy reserved. In addition, associated bidirectional
tunnels can be implemented with only the support of the head and tail nodes.
4-1
SJ-20140731105308-012|2014-10-20 (R1.0)
4.1.2 Static TE Tunnels Supporting DS-TE

To calculate the available bandwidth for a node, an important problem is how to distribute
the bandwidth among different CTs. Percentage of the link bandwidth used by a CT or a
group of CTs is call Bandwidth Constraint (BC). Bandwidth limit model indicates the relation
between a CT and the BC. General models include the following:
l
MAM
The Maximum Allocation Model (MAM) maps a BC to another CT, that is, simple
distribution of a link bandwidth among different CTs. For details, see Figure 4-1.
Figure 4-1 MAM
In MAM mode, different CTs can be completely separated. Therefore, no priority

configuration is needed for LSPs with different CT traffics. This mode is suitable for
networks in which preemption is not allowed. In the simple and visual MAM mode,
the CTs cannot share the unused bandwidth, which cannot be used to bear other CTs
and is wasted.
l
RDM
The Russian Dolls Model allows different CTs to share a bandwidth and improves the
bandwidth usage in MAM mode. However, in RDM mode, a BC is mapped to one
or more CTs, which is less visual. In addition, in RDM mode, different CTs cannot
be separated, and preemption is necessary to ensure the bandwidth of the CT. For
details, see Figure 4-2.
4-2
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 4 Static Tunnel Configuration
Figure 4-2 RDM
CT7 refers to the traffic having a most strict QoS requirement, and CT0 refers to Best
Effort Traffic.BC7 refers to a link bandwidth with a fixed proportion and can be reserved
only for CT7 traffic. BC6 refers to a link bandwidth with a proportion larger than BC7
and can be reserved for both CT7 and CT6 traffic. BC5 can be shared by CT7, CT6,
and CT5, and so on. Similarly, BC0 refers to the entire link bandwidth and can be
shared by all CTs. This is similar to Russian dolls, a small doll (BC1) can be put inside
a bigger one (BC0), and a doll (BC2) smaller than BC1 can be put inside BC1, and so
on. BC7 is the smallest one.
If a static tunnel supports the DS-TE function, a CT and bandwidth can be configured
on a static LSP, and the CT range is 0-7, in which 0 indicates the lowest level and 7
indicates the highest level. In MAM model, BCn only ensures the bandwidth of CTn.
In RDM model, different BCs can share a bandwidth, but BCn preferentially ensures
the bandwidth of CTn.To configure a CT and bandwidth on a static LSP, ensure that
they match TE-CLASS-MAP and a sufficient static BC bandwidth is configured on the
interface.
4.1.3 Reserved Bandwidth Sharing on Static TE Tunnels

Static tunnels can share resources by specifying an ID of the bandwidth-shared tunnel and
a shared bandwidth (including CIR/CBS/PIR/EBS). The shared bandwidth does not need
CAC verification but needs QoS reservation.
Two resource reservation modes are configured for sharing tunnels: Reservation and
non-reservation.
l
Reservation: A static tunnel LSP can be configured with a common bandwidth and
a shared tunnel. To configure a common bandwidth, CAC verification is needed. To
configure a shared tunnel, QoS reservation is needed, without CAC verification.
4-3
SJ-20140731105308-012|2014-10-20 (R1.0)
Non-reservation: Only a common bandwidth can be configured for a static tunnel LSP,
without applying for resource CAC.
4.2 Configuring a Static Tunnel

This procedure describes how to configure a static tunnel.
Steps
1. To enable MPLS TE globally and on the specified interface, perform the following steps:
Step
Command
Function
Enables MPLS TE and enters

Enables TE on an interface.
Configures the bandwidth for
[{static|dynamic}]<bandwidth value>
the TE interface.
interface <interface-name>: name of the TE interface.

bandwidth [{static|dynamic}]<bandwidth value>: maximum bandwidth (in kbps, type:
static or dynamic) reserved for the TE interface, range: 14294967295.
2. Configure a Static Tunnel in static tunnel interface configuration mode.
Step
Command
Function
ZXR10(config-mpls-te)#static te-tunnel <tunnel-id>
Enters static tunnel interface

configuration mode.
ZXR10(config-mpls-te-static-te_tunnel-tunnel-
Configures the type and role
id)#role {ingress | transmit | egress} type {unidirectional |
of the MPLS TE static tunnel.
bidirectional}
3
Configures the ingress and
id)#ingress-tunnel-id <tunnel-id> ingress <lsr-id>
egress nodes of the MPLS TE
egress <lsr-id>
static tunnel.
ingress <lsr-id>: router-ID of the ingress node of the tunnel.

egress <lsr-id>: router-ID of the egress node of the tunnel.
3. To configure a static tunnel in static tunnel LSP configuration mode, perform the
following steps:
Step
Command
Function
Enters LSP mode of the static
id)#lsp <1-1>
tunnel.
4-4
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
Configures the forwarding
id-lsp)#in-seg-info in-port <interface-name> in-label
information about the MPLS
<label>
TE static tunnel.
ZXR10(config-mpls-te-static-te_tunnel-tunnelid-lsp)#out-seg-info out-port <interface-name>
out-label <label>[next-hop <ip-address>][bandwidth

<bandwidth>[burst <committed-burst-size>][peak <peak-in
formation-rate>][excess-burst <excess-burst-size>]]
3
Configures the forwarding
id-lsp)#rvs-in-seg-info in-port <interface-name> in-label
information about the
<label>
bidirectional MPLS TE static
tunnel.
id-lsp)#rvs-out-seg-info out-port <interface-name>
out-label <label>[next-hop <ip-address>][bandwidth

<bandwidth>[burst <committed-burst-size>][peak <peak-in
formation-rate>][excess-burst <excess-burst-size>]]
in-lable <label>: value of the in-label for the ingress node of the tunnel, range: 0, 3,
or 161048575.
out-lable <label>: value of the out-label for the egress node of the tunnel, range: 0,
3, or 161048575.
bandwidth <bandwidth>: committed bandwidth for the tunnel LSP.
burst <committed-burst-size>: committed burst size for the tunnel LSP.
peak <peak-information-rate>: peak rate for the tunnel LSP.
excess-burst <excess-burst-size>: excess burst size for the tunnel LSP.
Command
Function
ZXR10#show mpls traffic-eng static [tunnel-id
Displays information about all static
<tunnel-id>]
tunnels, or displays information about

the specified static tunnel.
End of Steps
4.2.1 Configuring Bidirectional BFD for a Static Tunnel

This procedure describes how to configure the bidirectional BFD function of a static tunnel.
Steps
1. Configure the BFD function for a TE static tunnel on both the head and tail nodes.
4-5
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-mpls-te)#static te_tunnel
<tunnel-number>
configuration mode.
<tunnel-number>: Tunnel ID of
the static tunnel node.
Enables the BFD function of
number)#bfd interval <min-send-interval> min-rx
a static tunnel.
<min-receive-interval> multiplier <multiplier>
<min-send-interval>:
Specifies an expected minimum interval for sending
messages.Range: 10-990, unit: ms.
<min-receive-interval>: Specifies an expected minimum interval for receiving
messages.Range: 10-990, unit: ms.
<multiplier>: Specifies the multiplier of the detection timeout period.Range: 3-50.
Command
Function
ZXR10#show mpls traffic-eng static tunnel-id tunnel-number
End of Steps
4.2.2 Configuring the FA Function on a Static Tunnel

This procedure describes how to configure the FA function on a static tunnel.
Steps
1. Configure the FA function on a static tunnel.
Step
Command
Function
Enters static Tunnel interface
<tunnel-number>
configuration mode.
ZXR10(config-mpls-te- static-te_tunnel-
Enables the FA function of
tunnel-number)#forwarding-adjacency [holdtime
the tunnel or enables the FA
<tunnel-down-holdtime>]
function and configure the
value of the holdtime field.
<holdtime>: After the tunnel is down due to link failures, a holdtime duration is
needed to notify te route that the tunnel is down and disable the route to perceive the
tunnel flapping, range: 0-4294967295, unit: seconds.
4-6
SJ-20140731105308-012|2014-10-20 (R1.0)
Command
Function
ZXR10#show mpls traffic-eng forwarding-adjacency
Checks the FA details.
End of Steps
4.2.3 Configuring the AR Function for a Static Tunnel

This procedure describes how to configure the FR function of a static tunnel.
Steps
1. Configure the AR function of a static tunnel.
Step
Command
Function
Enters static Tunnel interface
<tunnel-number>
configuration mode.
ZXR10(config-mpls-te- static-te_tunnel-tunnel-
Enables the AR function of a
number)#autoroute announce
tunnel.
Sets the metric value of the
number)#tunnel mpls traffic-eng autoroute metric
AR function.
{<value0>| absolute <value1>| relative <value2>}
<value0>: Sets the value of the default metric type of the AR function. The default
metric type is absolute, and its value range is 1-4294967295.
absolute <value1>: Explicitly sets the value of an absolute AR metric, range:
1-4294967295.
relative <value2>: Explicitly sets the value of a relative AR metric, range: -10 to +10.
Command
Function
ZXR10#show mpls traffic-eng autoroute
Checks the AR details.
End of Steps
4.2.4 Configuring an Associated Bidirectional Tunnel for a Static

TE Tunnel
This procedure describes how to configure an associated bidirectional tunnel for a static
TE tunnel.
Steps
1. Configure an associated bidirectional tunnel for a static TE tunnel.
4-7
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function

configuration mode.
Configures a ID for the
id)#associate-tunnel {tunnl-id}
associated access tunnel.

Command
Function
ZXR10#show mpls traffic-eng static [tunnel-id <tunnel-id>]
End of Steps
4.2.5 Configuring a Static TE Tunnel Supporting DS-TE

This procedure describes how to configure the DS-TE function of a static TE tunnel.
Steps
1. Enable the DS-TE function and distribute a BC for the interface TE bandwidth on global
and specified interfaces.
Step
Command
Function
Enables the MPLS TE function

and enters TE configuration
mode.
ZXR10(config-mpls-te)#bandwidth model
Configures the ds-te
{mpls-te|extend-mam|mam|rdm|non-te}
bandwidth model.
ZXR10(config-mpls-te)#ds-te te-class <te-class map
Configures the TE-CLASS
id> class-type <class type value> priority <preemption
mapping relation. For a static
priority value>
tunnel, <preemption priority

value> can be set to 0 only at
present.
Enables the MPLS TE function

on the specified interface.
Sets a TE interface bandwidth,
[{static|dynamic}]<bandwidth value>[<perflow
a BC, and the percentages
bandwidth value>][{[bc0 <bandwidth value>],[bc1
of dynamic and static
<bandwidth value>],[bc2 <bandwidth value>],[bc3
bandwidths.

<bandwidth value>]}][percent <percent value>]
4-8
SJ-20140731105308-012|2014-10-20 (R1.0)
mpls-te: common TE model, non ds-te model.

extend-mam: expanded maximum reservation model.
man: maximum reservation model.
rdm: Russian Doll Model.
non-te: non-model model.
<te-class map id>: user-defined te-class, range: 07.
<class type value>: user-defined classtype, range: 01.
interface <interface-name>: TE interface name.
static: static reservation type.
dynamic: dynamic reservation type.
<bandwidth value>: maximum bandwidth that an interface supports TE, range:
1-4294967295, unit: kbps.
<perflow bandwidth value>: bandwidth per flow that the interface supports, range:
14294967295, unit: kbps.
bc0 <bandwidth value>: bc0 bandwidth of the interface, range: 14294967295, unit:
kbps.
kbps.
kbps.
kbps.
kbps.
kbps.
kbps.
kbps.
<percent value>: percentage of the used interface bandwidth, range: 0100. The
default value is determined based on the product specifications. The default dynamic
and static percentages are both 40.
2. Configure a static tunnel in interface configuration mode of the static tunnel.
Step
Command
Function

configuration mode.
4-9
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
Configures the type and role
id)#role {ingress | transmit | egress} type {unidirectional |
of a static MPLS TE tunnel.
bidirectional}
3
Configures the head and tail
id)#ingress-tunnel-id <tunnel-id> ingress <lsr-id>
nodes of a static MPLS TE
egress <lsr-id>
tunnel.
ingress <lsr-id>: Router-ID of the tunnel head node.

egress <lsr-id>: Router-ID of the tunnel tail node.
3. Configure the CT bandwidth required for configuring a static tunnel in static tunnel LSP
configuration mode.
Step
Command
Function
Enters static tunnel LSP
id)#lsp <1-1>
mode.
Configures forwarding
id-lsp)#in-seg-info in-port <interface-name> in-label
messages on a static MPLS
<label>
TE tunnel.
ZXR10(config-mpls-te-static-te_tunnel-tunnelid-lsp)#out-seg-info out-port <interface-name> out-label
<label>[next-hop <ip-address>]
3
Configures the tunnel going
id-lsp)#out-seg-ct class-type <ct> bandwidth
out the CT in forward direction.
<ct-bandwidth>
4
Configures forwarding
id-lsp)#rvs-in-seg-info in-port <interface-name> in-label
messages on a static MPLS
<label>
TE tunnel with bidirectional
nodes.
id-lsp)#rvs-out-seg-info out-port <interface-name>
out-label <label>[next-hop <ip-address>]

5
Configures the tunnel going
id-lsp)#rvs-out-seg-ct class-type <ct> bandwidth
out the CT in backward
<ct-bandwidth>
direction.
in-label <label>: input label value for a tunnel node, static label range: 161048575,
0, or, 3.
out-label <label>: output label value for a tunnel node, static label range: 161048575,
0, or, 3.
<ct>: class-type value of a DS-TE tunnel, range: 07.
4-10
SJ-20140731105308-012|2014-10-20 (R1.0)
<ct-bandwidth>: bandwidth corresponding to the CT, range: 14294967295, unit:

kbps.
Command
Function
Shows the information about

all static tunnels or a single
static tunnel with the specified
tunnel-id.
End of Steps
4.2.6 Configuring Reserved Bandwidth Sharing on Static TE

Tunnels
This procedure describes how to configure the reserved bandwidth sharing function of a
static TE tunnel.
Steps
1. Configure the reserved bandwidth sharing model on a static TE tunnel.
Step
Command
Function

configuration mode.
ZXR10(config-mpls-te-static-te_tunnel-tunnelid)#bandwidth reserve mode< reserve | no-reserve>
Configures the sharing mode

of a specified tunnel to the
reservation or non reservation
mode.
2. Configure a shared tunnel in static tunnel LSP configuration mode.

Step
1
Command
Function
Enters static tunnel LSP
id)#lsp <1-1>
mode.
Specifies a forward bandwidth
id-lsp)#out-seg-info out-port <out-port> out-label
of a tunnel sharing
<out-label>[bandwidth-share <tunnel-name>]
tunnel-name in forward
direction.
Specifies the backward
id-lsp)#rvs-out-seg-info out-port <out-port> out-label
bandwidth of a tunnel sharing
<out-label>[bandwidth-share <tunnel-name>]
tunnel-name in backward
direction.
4-11
SJ-20140731105308-012|2014-10-20 (R1.0)

Command
Function
End of Steps
4-12
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 5
Tunnel Protection Group

Configuration
Table of Contents
Tunnel Protection Group Overview .............................................................................5-1
Configuring a Tunnel Protection Group.......................................................................5-6
Tunnel Protection Group Configuration Example ........................................................5-9
5.1 Tunnel Protection Group Overview

Tunnel Protection Group Introduction
Packet services (such as the transport of VoIP, VPN, and PTV services) and mobile
backhaul (data services-oriented) bring new requirements and challenges to the transport
network. The packetization of the transport network (that is, PTN) gradually becomes a
trend in the telecommunications industry. The PTN is required to transport packet services
effectively, and provide the packet transport technology with telecommunication-grade
OAM and protection.
A tunnel protection group is used to configure and maintain the protection relationship
between a primary tunnel and a backup tunnel, provide auto protection for links and nodes,
and meet the following general requirements:
l
Supporting the handlings of link or node failures, execution of MMLs, and processing
of various priority-based switching requirements.
Supporting the handlings of various failures (such as physical link failures, VP/VC
SF, transit node failures, and SD failures).
Supporting the execution of MMLs providing lockout, forced switchover, and other
functions.
Supporting the configurations of the switching mode (unidirectional or bidirectional),

operation mode (returning the execution result or not), the WTR function, and WTR
time.
Supporting the setting of the protection switching time: In the case where the total
length of the link is not greater than 1200 kilometers and the hold-off time is set to 0,
the service impact time caused by a protection switching should not be greater than
50 ms (except for the SD-triggered protection switching).
Supporting the setting of the hold-off time: When the protection mode is specified for
the bottom-layer network of the PTN, the protection mode of the PTN should support
5-1
SJ-20140731105308-012|2014-10-20 (R1.0)
the setting of the hold-off time (50 or 100 ms). This can avoid a conflict between PTN
protection and bottom-layer network protection.
1+1 Linear Protection

In 1+1 structure, the backup tunnel is specially used for the primary tunnel. The primary
tunnel and the backup tunnel are bridged at the source end of the protection group.
Services are sent to the destination end of the protection domain on the primary tunnel
and the backup tunnel at the same time. The destination end chooses to receive the
services from the primary tunnel or the backup tunnel based on the rules (such as defect
index) defined in advance. To prevent single point of failures, the working connection and
the protection connection are isolated.
There are two switching types of 1+1 linear protection, unidirectional switching and
bidirectional switching. For unidirectional switching, only the services in the affected
direction are switched to the protection path, and the selectors at both ends are
independent of each other. Bidirectional switching mechanism is similar to unidirectional
switching mechanism, and APS signalling is needed for coordination. Bidirectional
protection can prevent one-way faults in both directions. The operational types of 1+1
linear protection can be revertive or non-revertive.
Figure 5-1 shows the structure of unidirectional 1+1 linear protection switching. In
unidirectional protection mode, the selector at the destination end of the protection
group performs the protection switching completely on the basis of the local (that is,
the destination end for the protection) APS information. The working services (the
protected services) are bridged to the working connection and the protection connection
permanently at the source end of the protection group.
5-2
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 5 Tunnel Protection Group Configuration
Figure 5-1 Structure of Unidirectional 1+1 Linear Protection Switching
If a fault occurs on the working connection (in the transport direction from Node A to Node
Z), as shown in Figure 5-2, the fault will be detected on Node Z at the destination end in the
protection domain. Then the selector of Node Z will switch the services to the protection
connection.
5-3
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 5-2 Unidirectional 1+1 Linear Protection Switching (Signal Failure)
1:1 Linear Protection

In 1:1 structure, the backup tunnel is special for the primary tunnel. The protected working
services are transmitted by the working connection or the protection connection. The
selection of the primary tunnel and the backup tunnel is decided by some mechanism.
To prevent single-point invalidation, the working connection and the protection connection
are isolated.
The switching type of 1:1 linear protection is bidirectional. That is, the services in both
the affected and unaffected directions are switched to the protection path. Bidirectional
switching needs APS to coordinate the two ends of the connection.
Figure 5-3 shows the structure of unidirectional 1:1 linear protection switching. In
unidirectional protection mode, the selectors at the source end and the destination end
together perform the protection switching based on the local or near-end information and
the APS protocol information from the other end or a remote end.
5-4
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 5-3 Unidirectional 1:1 Linear Protection Switching (Expressed in Single

Direction)
If a fault occurs on the working connection in the direction from Node Z to Node A, as
shown in Figure 5-4, the fault will be detected on Node A. Then the APS protocol triggers
protection switching. The procedure is described below.
1.
2.
3.
4.
Node A detects the fault.

The selector of Node A is bridged to backup tunnel A-Z.
An APS protection switching request is sent from Node A to Node Z.
When Node Z confirms that the priority of the switching protection request is valid,
Node Z merges it selector into the backup tunnel A-Z.
5. Related APS messages are sent from Node Z to Node A to advertise related switching
information.
6. Service packets are transmitted over the backup tunnel.
5-5
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 5-4 Unidirectional 1:1 Protection Switching (Primary Tunnel Z-A Failure)
5.2 Configuring a Tunnel Protection Group

This procedure describes how to configure a tunnel protection group.
Steps
1. Configure a linear tunnel protection group.
Step
Command
Function
ZXR10(config)#tunnel-group<group-id>
Configures a tunnel protection

group and enters tunnel
protection group mode.
<group-id> is the tunnel
protection group ID configured
for a user.
The minimum value is 1, and
the maximum value depends
on the product specifications.
Default: 32768.
ZXR10(config-tunnel-group-id)#protect-type 1+1
Sets the protection type to
{bidirectional | unidirectional} receiving {both | selective}
1+1 in tunnel protection group

mode.
ZXR10(config-tunnel-group-id)#protect-type 1:1
{bidirectional | unidirectional} receiving {both | selective}
1:1 in tunnel protection group

mode.
5-6
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config-tunnel-group-id)#working-tunnel
Sets the working tunnel of the
<tunnel-id>
tunnel protection group.

For a linear tunnel protection
group, when modifying the
working tunnel, ensure that
the ingress and egress
interfaces of the working
tunnel are the same as those
of the protection tunnel.
An intermediate node tunnel
cannot be added to a linear
tunnel protection group as a
working tunnel.
ZXR10(config-tunnel-group-id)#protect-tunnel
Sets a protection tunnel for a
<tunnel-id>

For a linear tunnel protection
group, when modifying a
working tunnel, ensure that
the ingress and egress
interfaces of the working
tunnel are the same as those
of the protection tunnel.
An intermediate node tunnel
cannot be added to a linear
tunnel protection group as a
protection tunnel.
ZXR10(config-tunnel-group-id)#protect-strategy aps
Sets the protection policy of a

linear tunnel protection group
to aps.
For ring protection, this
command can be omitted.
1:1: 1:1 protection type

1+1: 1+1 protection type
unidirectional: unidirectional protection
bidirectional: bidirectional protection
selective: Messages are received in a selected direction.
both: Messages are received in both directions.
<tunnel-id>: tunnel instance ID, whose range depends on the product specifications.
2. Configure a ring network tunnel protection group.
5-7
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
ZXR10(config)#tunnel-group <group-id>
Configures a tunnel protection

group and enters tunnel
protection group mode.
<group-id> is the tunnel
protection group ID configured
for a user. The minimum
value is 1, and the maximum
value depends on the product
specifications. Default:
32768.
ZXR10(config-tunnel-group-id)#protect-type ring

ring in tunnel protection group
mode.
ZXR10(config-tunnel-group-id)#working-tunnel
Sets a working tunnel for a
<tunnel-id>
ZXR10(config-tunnel-group-id)#protect-tunnel
Sets a protection tunnel of a
<tunnel-id>

For a ring network tunnel
protection group, a protection
tunnel can only be a ring
tunnel.
ZXR10(config-tunnel-group-id)#protect-section
Configures a protection
<sectionid>
segment for a ring network

For linear protection, this
This command can be
configured only after a
working tunnel and protection
tunnel are configured for a
ring tunnel group.
ZXR10(config-tunnel-group-id)#working-tail-aps-id
Sets the destination node
<aps-id>
apsid for the working tunnel

of the ring network protection
group.
For linear protection, this
For inter-ring services,
this command must be
configured. This command
can be configured only after
a protection segment is
5-8
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
configured for the ring tunnel
group.
<tunnel-id>: tunnel instance ID, whose range depends on the product specifications.
<sectionid> is the section ID, range: 14000.
< aps-id >: range: 1127.
Command
Function
ZXR10#show tunnel-group all
Displays the information about all

tunnel protection groups that have been
configured successfully.
ZXR10#show tunnel-group <group-id>
Displays the information about the

specified tunnel protection group.
End of Steps
5.3 Tunnel Protection Group Configuration Example

The network topology of a static TE tunnel protection group is shown in Figure 5-5.
Tunnel1001 is the active tunnel, Tunnel1002 is the backup tunnel, and Tunnel1003 is the
reversed tunnel.
Figure 5-5 Tunnel Protection Group Configuration Example
Configuration Flow
Set Tunnel1001 to the active tunnel, set Tunnel1002 to the backup tunnel and set
Tunnel1003 to the reversed tunnel. Enable MPLS OAM on the header node of Tunnel1001
and Tunnel1002 to detect the local tunnel. Enable MPLS OAM on the tail node of
5-9
SJ-20140731105308-012|2014-10-20 (R1.0)
Tunnel1001 and Tunnel1002 to detect the remote tunnel. Configure tunnel protection
group information on the header node and the tail node.
The configuration of the header node P1:
P1(config)#interface xgei-0/0/0/2
P1(config-if-xgei-0/0/0/2)#ip address 81.1.1.1 255.255.255.0
P1(config-if-xgei-0/0/0/2)#no shutdown
P1(config-if-xgei-0/0/0/2)#exit
P1(config-if-te_tunne97535)#ip unnumbered loopback1
P1(config-if-te_tunne97535)#exit
P1(config)#mpls oam
P1(config-mpls-oam)#local te_tunnel 1001 ingress 4.81.81.81
P1(config-mpls-oam-te_tunnel-1001)#type ffd frequence 500 exp 0
P1(config-mpls-oam-te_tunnel-1001)#mpls oam enable
P1(config-mpls-oam-te_tunnel-1001)#exit
P1(config-mpls-oam)#local te_tunnel 1002 ingress 4.81.81.81
P1(config-mpls-oam-te_tunnel-1002)#type ffd frequence 500 exp 0
P1(config-mpls-oam-te_tunnel-1002)#mpls oam enable
P1(config-mpls-oam-te_tunnel-1002)#exit
P1(config-mpls-oam)#exit
5-10
SJ-20140731105308-012|2014-10-20 (R1.0)

P1(config-mpls-te)#interface xgei-0/0/0/2
P1(config-mpls-te-if-xgei-0/0/0/2)#exit
P1(config-mpls-te)#static te_tunnel1001
P1(config-mpls-te-static-te_tunnel1001)#role ingress type unidirectional
P1(config-mpls-te-static-te_tunnel1001)#ingress-tunnel-id 1001 ingress 4.81.81.81
egress 4.52.52.52
P1(config-mpls-te-static-te_tunnel1001)#lsp 1
P1(config-mpls-te-static-te_tunnel1001-lsp)#out-seg-info out-port xgei-0/0/0/2
P1(config-mpls-te-static-te_tunnel1001)#exit
egress 4.52.52.52
P1(config-mpls-te-static-te_tunnel1002-lsp)#out-seg-info out-port gei-0/3/0/2
P1(config-mpls-te-static-te_tunnel1002-lsp)#exit
P1(config-mpls-te-static-te_tunnel97535)#role egress type unidirectional
egress 4.81.81.81
P1(config-mpls-te-static-te_tunnel97535-lsp)#in-seg-info in-port gei-0/3/0/6 in-label 3
Tunnel protection group configuration:

P1(config)#samgr
P1(config-samgr)#track 1001 mpls-oam tunnel-id 1001 ingress-id 4.81.81.81
P1(config)#tunnel-group 1
P1(config-tunnel-group-1)#protect-type 1+1 unidirectional receiving selective
P1(config-tunnel-group-1)#working-tunnel 1001
P1(config-tunnel-group-1)#protect-tunnel 1002
Configuration of the tail node P2:

P2(config)#interface xgei-0/3/0/21
5-11
SJ-20140731105308-012|2014-10-20 (R1.0)

P2(config-if-xgei-0/3/0/21)#no shutdown
P2(config-if-xgei-0/3/0/21)#ip address 81.1.1.2 255.255.255.0
P2(config-if-xgei-0/3/0/21)#exit
P2(config)#mpls oam
P2(config-mpls-oam)#egress te_tunnel 1001 ingress 4.81.81.81 backward-tunnel 1003
share type ffd frequence 500
P2(config-mpls-oam)#egress te_tunnel 1002 ingress 4.81.81.81 backward-tunnel 1003
share type ffd frequence 500
P2(config-mpls-oam)#exit
P2(config-mpls-te)#interface xgei-0/3/0/21
P2(config-mpls-te-if-xgei-0/3/0/21)#exit
egress 4.81.81.81
P2(config-mpls-te-static-te_tunnel1003-lsp)#out-seg-info out-port gei-0/3/0/9
5-12
SJ-20140731105308-012|2014-10-20 (R1.0)

egress 4.52.52.52
P2(config-mpls-te-static-te_tunnel65536-lsp)#in-seg-info in-port xgei-0/3/0/21 in-label 3
egress 4.52.52.52
P2(config-mpls-te-static-te_tunnel65537-lsp)#in-seg-info in-port gei-0/3/0/5 in-label 3
Tunnel protection group configuration:
P2(config)#samgr
P2(config-samgr)#exit
P2(config)#tunnel-group 1
P2(config-tunnel-group-1)#protect-type 1+1 unidirectional receiving selective
P2(config-tunnel-group-1)#working-tunnel 65536
P2(config-tunnel-group-1)#protect-tunnel 65537
P2(config-tunnel-group-1)#exit
Check the information of tunnel on the P1 router. The tunnel is in up state.
Name: tunnel_1001
Status:
Admin Status: up
Protocol Status: up

Basic Config Parameters:
Ingress-TnnlID:1001
IngressID:4.81.81.81
Tunnel Type: Unidirect
EgressID:4.52.52.52
Role: Ingress

Track Name:
Perf Switch: off
5-13
SJ-20140731105308-012|2014-10-20 (R1.0)

SD Switch: disable
AutoRoute: disabled
Forwarding adjacency: disabled
BFD: disabled
Convergence-Ratio:
Bandwidth Reserve Mode: reserve
Binded LSP 1
Positive Forward Info:
in-port:
in-label:
prev-hop:out-port: xgei-0/0/0/2
out-label: 3
next-hop: 81.1.1.2
bandwidth: 0
burst: 0
peak: 0
excess-burst: 0
Share tunnel: 0
Name: tunnel_1002
Status:
Admin Status: up
Protocol Status: up

Ingress-TnnlID:1002
EgressID:4.52.52.52
Role: Ingress

Track Name:
Perf Switch: off
SD Switch: disable
AutoRoute: disabled
BFD: disabled
Convergence-Ratio:
Binded LSP 1
in-port:
in-label:
prev-hop:-
5-14
SJ-20140731105308-012|2014-10-20 (R1.0)

out-port: gei-0/3/0/2
out-label: 3
next-hop: 81.5.5.2
bandwidth: 0
burst: 0
peak: 0
excess-burst: 0
Share tunnel: 0
Name: tunnel_97535
Status:
Admin Status: up
Protocol Status: up

Ingress-TnnlID:1003
EgressID:4.81.81.81
Role: Egress
Policy Class: N/A

Track Name:
Perf Switch: off
SD Switch: disable
Convergence-Ratio:
Binded LSP 1
in-port: gei-0/3/0/6
in-label: 3
prev-hop:out-port:
out-label:
next-hop: 0.0.0.0
bandwidth: 0
burst: 0
peak: 0
excess-burst: 0
Share tunnel: 0
Check the information of tunnel on the P2 router. The tunnel is in up state.

Name: tunnel_65536
Status:
Admin Status: up
Protocol Status: up

5-15
SJ-20140731105308-012|2014-10-20 (R1.0)

Ingress-TnnlID:1001
EgressID:4.52.52.52
Role: Egress
Policy Class: N/A

Track Name:
Perf Switch: off
SD Switch: disable
Convergence-Ratio:
Binded LSP 1
in-port: xgei-0/3/0/21
in-label: 3
prev-hop:out-port:
out-label:
next-hop: 0.0.0.0
bandwidth: 0
burst: 0
peak: 0
excess-burst: 0
Share tunnel: 0
Name: tunnel_65537
Status:
Admin Status: up
Protocol Status: up

Ingress-TnnlID:1002
EgressID:4.52.52.52
Role: Egress
Policy Class: N/A

Track Name:
Perf Switch: off
SD Switch: disable
Convergence-Ratio:
Binded LSP 1
5-16
SJ-20140731105308-012|2014-10-20 (R1.0)

in-port: gei-0/3/0/5
in-label: 3
prev-hop:out-port:
out-label:
next-hop: 0.0.0.0
bandwidth: 0
burst: 0
peak: 0
excess-burst: 0
Share tunnel:0
Name: tunnel_1003
Status:
Admin Status: up
Protocol Status: up

Ingress-TnnlID:1003
EgressID:4.81.81.81
Role: Ingress

Track Name:
Perf Switch: off
SD Switch: disable
AutoRoute: disabled
BFD: disabled
Convergence-Ratio:
Binded LSP 1
in-port:
in-label:
prev-hop:out-port: gei-0/3/0/9
out-label: 3
next-hop: 81.9.9.1
bandwidth: 0
burst: 0
peak: 0
excess-burst: 0
Share tunnel: 0
Check the configuration of tunnel protection group on P1.
5-17
SJ-20140731105308-012|2014-10-20 (R1.0)

P1#show tunnel-group 1
Tunnel group 1
Protection type: 1+1 unidirectional receiving selective
Protection strategy: unknown
Protection section: 0
Working tunnel: 1001,state: OK
Protection tunnel: 1002,state: OK
Working tunnel tail aps id: 0
Switch: no
Check the configuration of tunnel protection group on P2.

P2#show tunnel-group 1
Tunnel group 1
Protection type: 1+1 unidirectional receiving selective
Protection strategy: unknown
Protection section: 0
Working tunnel: 65536,state: OK
Protection tunnel: 65537,state: OK
Working tunnel tail aps id: 0
Switch: no
5-18
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 6
APS Configuration
Table of Contents
APS Overview ............................................................................................................6-1
Configuring APS.........................................................................................................6-5
APS Configuration Example .......................................................................................6-9
6.1 APS Overview

APS Introduction
With the wide use and application of network, various value-added services are deployed
on network. The demand for network bandwidth is increasing rapidly. A short network
interruption may affect a lot of services, which brings serious loss.
APS is a redundancy protection technology. When a fault occurs on a link, APS sends a
protection switching request through an APS protocol message. The peer device gives
a protection switching reply through a response message, and coordinates the protection
switching mechanism of the switching selectors at both ends. In this way, when there is a
link fault, services can be quickly switched to a link that is working properly, thus ensuring
normal communication.
APS Protection Modes

There are two kinds of APS protection modes: 1+1 linear protection and 1:1 linear
protection. For detailed information, refer to Section 5.1 Tunnel Protection Group
Overview.
APS Protection Modes

APS switching supports two protection modes: revertive mode and non-revertive mode.
l
l
Revertive mode: Once the primary tunnel recovers, packets are forwarded on the
primary tunnel.
Non-revertive mode: When the primary tunnel recovers, packets are still forwarded
on the backup tunnel instead of the primary tunnel.
The following scenarios describe the APS principle by the interactions of some typical APS
messages.
l
Revertive mode
Figure 6-1 shows the APS message interaction procedure of the revertive mode. The
flow is described below.
6-1
SJ-20140731105308-012|2014-10-20 (R1.0)
1. There is no fault detected by both ends of the tunnel. Service traffic is forwarded
on the primary tunnel.
2. The traffic transmitted through the tunnel from the west to the east is interrupted.
The east end generates an SF alarm. Then the east switches packet sending and
receiving to the backup tunnel, and sends an APS SP message to the peer.
3. When the west receives the SF message from the peer, it also switches packet
sending and receiving to the backup tunnel.
4. When the traffic sending from the west to the east recovers, the east reports SF
recovery and becomes WTR state. It sends an APS WTR message to the peer.
5. During the WTR period, the traffic is still forwarded on the backup tunnel.
6. When the WTR timer expires, the east send an APS NR message to the peer to
switch the traffic back to the primary tunnel.
Figure 6-1 Working Flow of the Revertive Mode
6-2
SJ-20140731105308-012|2014-10-20 (R1.0)
Chapter 6 APS Configuration
NR: No Request
r/b: request
signal/bridge signal
WTR: Wait To Restore

service
DNR: Do-Not-Revert
SF: Signal Failure

W->E: west to east
direction
Non-revertive mode
Figure 6-2 shows the APS message interaction procedure when the non-revertive
mode is used. The flow is described below.
1. There is no fault detected by both ends of the tunnel. Service traffic is forwarded
on the primary tunnel.
2. The traffic forwarded by the tunnel from the west to the east is intermitted. The
east generates an SF alarm. Then the east switches packet sending and receiving
to the backup tunnel, and sends an APS SP message to the peer.
3. When the west receives the SF message from the peer, it also switches packet
sending and receiving to the backup tunnel.
4. When the traffic sending from the west to the east recovers, the east reports SF
recovery. The east clears SF state and switches to NR normal state. It sends a
DNR message to the peer.
5. When the west receives the DNR message, it does change its state. The traffic
is still forwarded on the backup tunnel.
6-3
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 6-2 Working Flow of the Non-Revertive Mode
NR: No Request
r/b: request
signal/bridge signal
WTR: Wait To Restore

service
DNR: Do-Not-Revert
SF: Signal Failure

W->E: west to east
direction
APS Applications
Through the APS deployment, protection can be implemented at the following two layers:
l
l
Tunnel protection can be deployed at the tunnel layer, see Figure 6-3.
A PW protection group can be deployed at the PW layer, see Figure 6-4.
In a tunnel protection group, a protection relationship is established between two tunnel

members. When no fault occurs or no request is received, traffic is forwarded through the
primary tunnel. If a fault occurs or a request is received, APS determines which tunnel
6-4
SJ-20140731105308-012|2014-10-20 (R1.0)
should be selected to forward the traffic. The primary tunnel and backup tunnel may pass
through different P nodes (recommended), but they must pass through the same PE node.
Figure 6-3 shows a tunnel protection group. This group contains PE1PPE2 (indicated
by the solid lines) and PE1PE (indicated by the broken line) tunnels . Protection
relationship is established between the two tunnel groups. The PE1PPE2 tunnel
is configured as the primary tunnel, and the PE1PE2 tunnel is configured as the
backup tunnel. Moreover, the corresponding APS instance is configured. When the
primary tunnel becomes faulty, APS switches over the traffic to the backup tunnel after a
calculation, which ensures that the traffic from PE1 to PE2 is not interrupted.
Figure 6-3 Tunnel Protection Group Application
In a PW protection group, a protection relationship is established between the two PW

entities. The closed protection mode (such as a tunnel protection group) or the protection
mode shown in Figure 6-4 can be used. Figure 6-4 shows that PW1 is the working entity,
and PW2 is the protection entity. The corresponding APS instance is configured. When
a fault occurs on PW1, APS can determine which PW is selected to forward the traffic as
needed.
Figure 6-4 PW Protection Group Application
6.2 Configuring APS

Protection groups can be configured at each network layer, corresponding to different APS
instances. APS instances have similar attributes (for example, the revertive mode and
hold-off time), but these attributes must be set in different configuration modes.
6-5
SJ-20140731105308-012|2014-10-20 (R1.0)
Protection groups can be established at the LSP layer. Such a protection group is
automatically created by TECP, and other parameters cannot be set.
6.2.1 Configuring APS for a Tunnel Protection Group

This procedure describes how to configure APS for a tunnel protection group.
Context
The APS instance configuration of a tunnel protection group is independent of the tunnel
protection group configuration. When a protection policy object of the tunnel protection
group is generated, the default parameter settings are used to create the corresponding
APS instance. The following show how to change the attributes of the APS instance.
Steps
1. To configure an APS instance, perform the following steps:
Step
Command
Function
ZXR10(config)#aps
Enters APS configuration

mode.
Enters APS linear protection
ZXR10(config-aps)#linear-protect
mode.
3
ZXR10(config-aps-linear-protect)#tunnel-group
Enters the configuration mode
<group-id>
of the APS instance for the

The group-id parameter is in a
range of 1 to 32768.
2. To set the attributes of the APS instance, perform the following steps:
Step
Command
Function
ZXR10(config-aps-linear-protect-tunnel-
Sets the hold-off time (in
group1)#hold-off <0-100>
100 milliseconds) for APS

switching, range: 0100.
Sets the revertive mode of
group1)#revertive-mode {non-revertive | revertive wtr
APS.
{default |<1-12>}}
6-6
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
group1)#protect-mode {remote | local }
sending and receiving of APS

packets, options:
l
remote (enabling the

sending and receiving of
packets)
local (disabling the

packets)
However, Version 20 and later

versions do not support the
packets. This command is
reserved to be compatible
with other versions only.
4
Configures the APS status,
group1)#active-state { restore-run | pause }
options:
l
restore-run
pause
Configures manual APS
group1)#switch {clear | lockout | force-switch |
switching.
manual-switch | exercise}
When the revertive mode of APS is set to revertive-mode, the WTR time (in minutes,
range: 012, default: 5) should be specified.
APS can calculate the status of the tunnel protection group only when being in
restore-run status. APS does not calculate the status of the tunnel protection group
when being in pause status, that is, APS does not take effect.
The revertive mode of APS can be changed only when APS is in pause status. APS
switching can be configured only when APS is in restore-run status.
Command
Function
ZXR10(config)#show aps linear-protect [{tunnel-group
Displays the statuses of the
<dwTgId>|pw-protector <pw-name>|lsp-group <dwLspgId>}]
APS instances for all tunnel

protection groups or the status of
the specified APS instance.
tunnel-group: displays the status of the APS instance for the tunnel protection group
(its ID is specified by <dwTgId>). The <dwTgId> parameter is in a range of 1 to 32768.
6-7
SJ-20140731105308-012|2014-10-20 (R1.0)
pw-protector: displays the status of the APS instance for the PW protection group
(its name is specified by <pw-name>).
lsp-group : displays the status of the APS instance for the PW protection group (its
ID is specified by <dwLspgId>). The <dwLspgId> parameter is in a range of 1 to 4096.
End of Steps
6.2.2 Configuring APS for a PW Protection Group

This procedure describes how to configure APS for a PW protection group.
Context
The APS instance configuration of a PW protection group is independent of the PW
protection group configuration. When a protection policy object of the PW protection
group is generated, the default parameter settings are used to create the corresponding
APS instance. The following show how to change the attributes of the APS instance.
Steps
1. To configure an APS instance, perform the following steps:
Step
Command
Function
ZXR10(config)#aps
Enters APS configuration

mode.
Enters APS linear protection
ZXR10(config-aps)#linear-protect
mode.
3
ZXR10(config-aps-linear-protect)#pw-protector
Enters the configuration mode
<pw-name>
of the PW protection group.

The backup PW protection
group has the same name
as the primary PW protection
group. The pw-name
parameter is in a range
of 1 to 32768.
2. To set the attributes of the APS instance, perform the following steps:
Step
Command
Function
ZXR10(config-aps-linear-protect-pwprotector-
Sets the hold-off time (in
pw1)#hold-off <0-100>
100 milliseconds) for APS

switching, range: 0-100.
Sets the revertive mode of
pw1)#revertive-mode {non-revertive | revertive wtr
APS.
{default |<1-12>}}
6-8
SJ-20140731105308-012|2014-10-20 (R1.0)
Step
Command
Function
pw1)#protect-mode {remote | local }

packets, options:
l
remote (enabling the

packets)
local (disabling the

packets)
Configures the APS status,
pw1)#active-state { restore-run | pause }
options:
l
restore-run
pause
Configures manual APS
pw1)#switch {clear | lockout | force-switch | manual-switch
switching.
| exercise}
When the revertive mode of APS is set to revertive-mode, the WTR time (in minutes,
range: 0-12, default: 5) should be specified.
APS can calculate the status of the tunnel protection group only when being in
restore-run status. APS does not calculate the status of the tunnel protection group
when being in pause status, that is, APS does not take effect.
The revertive mode of APS can be changed only when APS is in pause status. APS
switching can be configured only when APS is in restore-run status.
Refer to Section 6.2.1 Configuring APS for a Tunnel Protection Group.
End of Steps
6.3 APS Configuration Example

6.3.1 APS Configuration Example (Tunnel Protection Group)
A protection relationship should be configured between the two tunnels in a tunnel
protection group. Therefore, two valid tunnels should be configured before the tunnel
protection group is created. To detect the connectivity of the two tunnels, TP-OAM should
be enabled on the tunnels. Upon detecting an alarm, TP-OAM notifies the corresponding
entity module of the alarm, and then the entity module sends a notification to the tunnel
protection group module. The tunnel protection group informs APS, APS calculates the
6-9
SJ-20140731105308-012|2014-10-20 (R1.0)
status based on actual conditions, and then determines which tunnel should be selected
to forward the traffic.
Figure 6-5 shows a sample network topology. PE1 and PE2 are directly-connected. It
is required to establish two valid tunnels (tunnel1 and tunnel2) between PE1 and PE2.
Tunnel1 should be configured to be the primary tunnel (indicated by the solid line), and
Tunnel2 should be configured to be the backup tunnel (indicated by the broken line).
Figure 6-5 APS Configuration Example (Tunnel Protection Group)
Configuration Flow
1.
2.
3.
4.
5.
6.
Configure the IP addresses of interfaces.

Configure TE interfaces.
Configure tunnels.
Enable TP-OAM on the tunnels.
Configure a tunnel protection group.
Configure an APS instance.
Run the following commands on PE1 (head node of the two tunnels):
/*Run the following commands to configure the IP addresses of interfaces:*/
PE1(config)#interface xgei-0/0/0/2
PE1(config-if-xgei-0/0/0/2)#ip address 81.1.1.1 255.255.255.0
PE1(config-if-xgei-0/0/0/2)#no shutdown
PE1(config-if-xgei-0/0/0/2)#exit
/*Run the following commands to configure TE interfaces: */

/*Run the following commands to configure tunnels:*/

6-10
SJ-20140731105308-012|2014-10-20 (R1.0)

PE1(config-mpls-te)#interface xgei-0/0/0/2
PE1(config-mpls-te-if-xgei-0/0/0/2)#exit
PE1(config-mpls-te)#advertise none-null
PE1(config-mpls-te)# static te_tunnel1001

PE1(config-mpls-te-static-te_tunnel1001)#role ingress type bidirectional
egress 4.52.52.52
PE1(config-mpls-te-static-te_tunnel1001-lsp)#out-seg-info out-port xgei-0/0/0/2
PE1(config-mpls-te-static-te_tunnel1001-lsp)#rvs-in-seg-info in-port xgei-0/0/0/2
in-label 3
egress 4.52.52.52
PE1(config-mpls-te-static-te_tunnel1002-lsp)#out-seg-info out-port gei-0/3/0/2
PE1(config-mpls-te-static-te_tunnel1002-lsp)#rvs-in-seg-info in-port gei-0/3/0/2
in-label 3
PE1(config-mpls-te-static-te_tunnel1002)#exi
/*Run the following commands to enable TP-OAM on the two tunnels*/

/*to detect the connectivity of the tunnels:*/
PE1(config)#mpls-tp oam
PE1(config-tp-oam)#static-tunnel 1001 lspid 1
PE1(config-tp-oam-static-tunnel-1001-lsp-1)#meg 1001
PE1(config-tp-oam-static-tunnel-1001-lsp-1-meg-1001)#meg-id 1001
PE1(config-tp-oam-static-tunnel-1001-lsp-1-meg-1001)#oam enable
PE1(config-tp-oam-static-tunnel-1001-lsp-1-meg-1001)#local-mep 1001 type bidirectional
PE1(config-tp-oam-static-tunnel-1001-lsp-1-meg-1001)#peer-mep 2001 type bidirectional
PE1(config-tp-oam-static-tunnel-1001-lsp-1-meg-1001)#cv enable
PE1(config-tp-oam-static-tunnel-1001-lsp-1-meg-1001)#cv period 1s
PE1(config-tp-oam-static-tunnel-1001-lsp-1-meg-1001)#cc enable
PE1(config-tp-oam-static-tunnel-1001-lsp-1-meg-1001)#exit
6-11
SJ-20140731105308-012|2014-10-20 (R1.0)

PE1(config-tp-oam-static-tunnel-1001-lsp-1)#exit

PE1(config-tp-oam-static-tunnel-1002-lsp-1)#exi
/*Run the following commands to configure a tunnel*/

/*protection group:*/
PE1(config)#tunnel-group 1
PE1(config-tunnel-group-1)#protect-type 1:1 bidirectional receiving both
PE1(config-tunnel-group-1)#working-tunnel 1001
PE1(config-tunnel-group-1)#protect-tunnel 1002
PE1(config-tunnel-group-1)#protect-strategy aps
PE1(config-tunnel-group-1)#exit
/*Run the following commands to configure an APS instance:*/

PE1(config)#aps
PE1(config-aps)#linear-protect
PE1(config-aps-linear-protect)#tunnel-group 1
PE1(config-aps-linear-protect-tunnelgroup1)#switch force-switch
PE1(config-aps-linear-protect-tunnelgroup1)#hold-off 20
PE1(config-aps-linear-protect-tunnelgroup1)#exit
PE1(config-aps-linear-protect)#exit
PE1(config-aps)#exit
Run the following commands on PE2 (tail node of the two tunnels):
6-12
SJ-20140731105308-012|2014-10-20 (R1.0)


PE2(config-mpls-te)# static te_tunnel65536

PE2(config-mpls-te-static-te_tunnel65536)#role egress type bidirectional
egress 4.52.52.52
PE2(config-mpls-te-static-te_tunnel65536-lsp)#in-seg-info in-port xgei-0/3/0/21
in-label 3
PE2(config-mpls-te-static-te_tunnel65536-lsp)#rvs-out-seg-info out-port xgei-0/3/0/21
PE2(config-mpls-te-static-te_tunnel65537)#role egress type bidirectional
egress 4.52.52.52
PE2(config-mpls-te-static-te_tunnel65537-lsp)#in-seg-info in-port gei-0/3/0/5
in-label 3
PE2(config-mpls-te-static-te_tunnel65537-lsp)#rvs-out-seg-info out-port gei-0/3/0/5
/*Run the following commands to enable TP-OAM on the two*/

/*tunnels to detect the connectivity of the tunnels:*/
6-13
SJ-20140731105308-012|2014-10-20 (R1.0)


/*Run the following commands to configure a tunnel protection group:*/

PE2(config)#tunnel-group 1
PE2(config-tunnel-group-1)#protect-type 1:1 bidirectional receiving both
PE2(config-tunnel-group-1)#working-tunnel 65536
PE2(config-tunnel-group-1)#protect-tunnel 65537
PE2(config-tunnel-group-1)#protect-strategy aps
PE2(config-tunnel-group-1)#exit

PE2(config)#aps
PE2(config-aps-linear-protect)#tunnel-group 1
PE2(config-aps-linear-protect-tunnelgroup1)#switch force-switch
PE2(config-aps-linear-protect-tunnelgroup1)#hold-off 20
PE2(config-aps-linear-protect-tunnelgroup1)#exit
PE2(config-aps-linear-protect)#exit
PE2(config-aps)#exit
Run the show aps linear-protect tunnel-group 1 command on PE1 and PE2 to check the
APS configuration and whether APS has been enabled. The execution result is displayed
as follows:
6-14
SJ-20140731105308-012|2014-10-20 (R1.0)

PE1#show aps linear-protect tunnel-group 1
----------[APS Linear Instance]---------Protection group type: tunnel
Protection group id: 1
Protection type: 1:1 bidirectional receiving both
APS is enabled
APS state: NO_REQUEST_NULL
Protection mode: remote
Active-state: restore-run
Revertive mode: revertive, WTR time: 5min
Hold-off time: 0ms,valid hold-off time: 0ms
Switch command: nul
PE2#show aps linear-protect tunnel-group 1
----------[APS Linear Instance]---------Protection group type: tunnel
APS is enabled
APS state: FORCED_SWITCH
Switch command: force-switch
6.3.2 APS Configuration Example (PW Protection Group)

A protection relationship should be configured between the two PWs in a PW protection
group, and the PWs should be associated with tunnels that provide bearer paths.
Therefore, it is required to create two valid tunnels and respectively bind two PWs to the
tunnels. To detect the connectivity of the two PWs, TP-OAM should be enabled on the
PWs. Upon detecting an alarm, TP-OAM notifies the corresponding entity module of the
alarm, and then the entity module sends a notification to the PW protection group module.
At last, the PW protection group informs APS, APS calculates the status based on actual
conditions, and then determines which tunnel should be selected to forward the traffic.
Figure 6-6 shows a sample network topology. It is required to deploy a PW protection
group on the UPE NE, and establish a tunnel from UPE to NPE1 for providing a bearer
path for PW1. It is also required to establish a tunnel from UPE to NPE2 for providing a
bearer path for PW2. At last, a protection relationship should be configured between PW1
(the primary PW) and PW2 (the backup PW).
6-15
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 6-6 APS Configuration Example (PW Protection Group)
Configuration Flow
1.
2.
3.
4.
5.
Configure the IP addresses of interfaces.

Configure TE interfaces.
Configure tunnels.
Configure tunnel policies.
Configure a PW protection group, and respectively bind the two PWs to the
corresponding tunnels.
6. Configure an APS instance.

6-16
SJ-20140731105308-012|2014-10-20 (R1.0)

PE1(config-mpls-te-static-te_tunnel1001)#ingress-tunnel-id 1001 ingress
4.81.81.81 egress 4.82.82.82
PE1(config-mpls-te-static-te_tunnel1001-lsp)#out-seg-info out-port
xgei-0/0/0/2 out-label 3 next-hop 81.1.1.2
PE1(config-mpls-te-static-te_tunnel1001-lsp)#rvs-in-seg-info in-port
xgei-0/0/0/2 in-label 3
PE1(config-mpls-te-static-te_tunnel1002)#ingress-tunnel-id 1002 ingress
4.81.81.81 egress 4.52.52.52
PE1(config-mpls-te-static-te_tunnel1002-lsp)#out-seg-info out-port
xgei-0/0/0/4 out-label 3 next-hop 40.1.1.71
PE1(config-mpls-te-static-te_tunnel1002-lsp)#rvs-in-seg-info in-port
xgei-0/0/0/4 in-label 3
/*Run the following commands to configure tunnel policies:*/

PE1(config)#tunnel-policy work
PE1(config-tunnel-policy-work)#tunnel selecting mpls-te te_tunnel1001
PE1(config-tunnel-policy-work)#exit
PE1(config)#tunnel-policy protect
PE1(config-tunnel-policy-protect)#tunnel selecting mpls-te te_tunnel1002
PE1(config-tunnel-policy-protect)#exit
/*Run the following commands to configure a PW protection group:*/

PE1(config)#pw pw1001
6-17
SJ-20140731105308-012|2014-10-20 (R1.0)

PE1(config)#pw pw1002
PE1(config)#mpls l2vpn enable
PE1(config)#vpls 1001
PE1(config-vpls-1001)#pseudo-wire pw1001 spoke
PE1(config-vpls-1001-spoke-pw-pw1001)#neighbor 4.82.82.82 vcid 1001
PE1(config-vpls-1001-spoke-pw-pw1001-neighbor)#signal static local-label 300
remote-label 300
PE1(config-vpls-1001-spoke-pw-pw1001-neighbor)#exit
PE1(config-vpls-1001-spoke-pw-pw1001)#redundancy-manager
PE1(config-vpls-1001-spoke-pw-pw1001)#protect-type 1:1 bidirectionalreceiving both
protect-strategy aps
PE1(config-vpls-1001-spoke-pw-pw1001)#exit
PE1(config-vpls-1001)#backup-pw pw1002 protect pw1001
PE1(config-vpls-1001-protect-pw1002)#neighbor 4.52.52.52 vcid 1002
PE1(config-vpls-1001-protect-pw1002-neighbor)#signal static local-label 400
remote-label 400
/*Run the following commands to enable TP-OAM on the*/

/*two PWs to detect the connectivity of the PWs:*/
PE1(config-tp-oam)#oam enable
PE1(config-tp-oam)#pw pw1001
PE1(config-tp-oam-pw-pw1001)#meg 33
PE1(config-tp-oam-pw-pw1001-meg-33)#meg-id 33
PE1(config-tp-oam-pw-pw1001-meg-33)#oam enable
PE1(config-tp-oam-pw-pw1001-meg-33)#local-mep 13 type bidirectional
PE1(config-tp-oam-pw-pw1001-meg-33)#peer-mep 31 type bidirectional
PE1(config-tp-oam-pw-pw1001-meg-33)#cv enable
PE1(config-tp-oam-pw-pw1001-meg-33)#cv period 1s
PE1(config-tp-oam-pw-pw1001-meg-33)#cc enable
PE1(config-tp-oam-pw-pw1001-meg-33)#exit
PE1(config-tp-oam-pw-pw1002)#meg 44
PE1(config-tp-oam-pw-pw1002-meg-44)#meg-id 4
PE1(config-tp-oam-pw-pw1002-meg-44)#local-mep 14 type bidirectional
PE1(config-tp-oam-pw-pw1002-meg-44)#peer-mep 41 type bidirectional
PE1(config-tp-oam-pw-pw1002-meg-44)#oam enable
PE1(config-tp-oam-pw-pw1002-meg-44)#cv enable
PE1(config-tp-oam-pw-pw1002-meg-44)#cv period 1s
PE1(config-tp-oam-pw-pw1002-meg-44)#cc enable
PE1(config-tp-oam-pw-pw1002-meg-44)#exit
PE1(config-tp-oam-pw-pw1002)#exit
PE1(config-tp-oam)#exit
6-18
SJ-20140731105308-012|2014-10-20 (R1.0)

PE1(config)#aps
PE1(config-aps-linear-protect)#pw-protector pw1001
PE1(config-aps-linear-protect-pwprotector-pw1001)#switch force-switch
PE1(config-aps-linear-protect-pwprotector-pw1001)#hold-off 20
Run the show aps linear-protect pw-protector pw1 command on PE1 to check the APS
configuration and whether APS has been enabled:
PE1#show aps linear-protect pw-protector pw1001
----------[APS Linear Instance]---------Protection group type: pw
Protection group name: pw1001
APS is enabled
APS state: FORCED_SWITCH
Switch command: force-switch
6-19
SJ-20140731105308-012|2014-10-20 (R1.0)
6-20
SJ-20140731105308-012|2014-10-20 (R1.0)
Figures
Figure 1-1 IP Forwarding .......................................................................................... 1-2
Figure 1-2 ATM Forwarding ...................................................................................... 1-3
Figure 1-3 Position of MPLS ..................................................................................... 1-4
Figure 1-4 MPLS Working Principle .......................................................................... 1-4
Figure 1-5 MPLS Label Structure.............................................................................. 1-5
Figure 1-6 MPLS Label Stack ................................................................................... 1-6
Figure 1-7 MPLS Special Terms................................................................................ 1-8
Figure 1-8 Routing Table Generation ...................................................................... 1-10
Figure 1-9 LIB Generation....................................................................................... 1-10
Figure 1-10 LSP Generation ................................................................................... 1-11
Figure 1-11 Penultimate Hop Popping..................................................................... 1-12
Figure 1-12 Downstream on Demand (DoD) ........................................................... 1-13
Figure 1-13 Downstream Unsolicited ...................................................................... 1-13
Figure 1-14 LDP Session Establishment ................................................................. 1-16
Figure 1-15 Network Topology for IGP Synchronization .......................................... 1-17
Figure 1-16 Implementation of Longest Matching Routes in LSP ............................ 1-19
Figure 1-17 Establishing a Basic LDP Neighbour Session ...................................... 1-30
Figure 1-18 Establishing an LDP Target Session ................................................... 1-33
Figure 1-19 Configuring a Label Distribution Policy ................................................. 1-36
Figure 1-20 LDP Multi-Instance Topology................................................................ 1-39
Figure 1-21 Establishing an LDP FRR .................................................................... 1-42
Figure 1-22 Network Architecture of LDP Graceful Restart Configuration
Instance................................................................................................ 1-49
Figure 1-23 LSP Load-Sharing Configuration Example .......................................... 1-56
Figure 1-24 LDP BFD Configuration Example ......................................................... 1-60
Figure 1-25 PEER BFD Configuration Example ...................................................... 1-64
Figure 1-26 GTSM Configuration Example.............................................................. 1-68
Figure 1-27 LDP IGP Synchronization Configuration Example (OSPF) ................... 1-71
Figure 1-28 LDP IGP Synchronization Configuration Example (IS-IS) ..................... 1-75
Figure 1-29 Network Diagram for LDPIGP Synchronization Integrated with
FRR...................................................................................................... 1-80
Figure 1-30 Packet Filtration Configuration Example............................................... 1-85
I
SJ-20140731105308-012|2014-10-20 (R1.0)
Figure 1-31 Label-Distribution Configuration Example ............................................ 1-88

Figure 1-32 Label-Retention Configuration Example ............................................... 1-90
Figure 1-33 Label-Advertise Configuration Example ............................................... 1-93
Figure 1-34 Label-Request Configuration Example ................................................. 1-96
Figure 1-35 LSP-Control Configuration Example..................................................... 1-99
Figure 1-36 Longest-Match Configuration Example............................................... 1-103
Figure 2-1 LSP Tunnel Establishment 1 .................................................................... 2-4
Figure 2-2 LSP Tunnel Establishment 2 .................................................................... 2-4
Figure 2-3 Establishing a Basic OSPF TE RSVP Tunnel........................................... 2-8
Figure 2-4 Establishing a Strict IS-IS TE RSVP Tunnel ........................................... 2-12
Figure 2-5 Configuring BFD on RSVP Interface ...................................................... 2-16
Figure 2-6 RSVP LSP BFD Configuration Instance ................................................. 2-19
Figure 2-7 TE Summary Refresh Configuration Example ........................................ 2-26
Figure 2-8 TE Message Acknowledgement and Retransmission Configuration
Example ............................................................................................... 2-31
Figure 2-9 TE Interface Authentication Configuration .............................................. 2-37
Figure 2-10 TE LSP Calculation Scheme ................................................................ 2-42
Figure 2-11 Configuration Instance of OSPF TE Crossing Several AS
Domains ............................................................................................... 2-43
Figure 2-12 Configuration Instance of IS-IS TE Crossing Several AS
Domains ............................................................................................... 2-52
Figure 2-13 TE-FRR Bandwidth Protection ............................................................. 2-60
Figure 2-14 Establishing a Tunnel in Facility Mode Manually................................... 2-64
Figure 2-15 Establishing a Tunnel in Facility Mode Automatically............................ 2-68
Figure 2-16 Establishing a Tunnel in Detour Protection Mode ................................. 2-73
Figure 2-17 TE-FRR Bandwidth Protection Configuration Instance ......................... 2-79
Figure 2-18 Instance of Configuration for HOT_LSP Supporting TE-FRR................ 2-89
Figure 2-19 FRR Promotion Configuration Example (Node Protection Having a
Higher Priority than Link Protection).................................................... 2-105
Figure 2-20 FRR Configuration Example (Bandwidth for Backup Tunnels Being
Met) .................................................................................................... 2-110
Figure 2-21 FRR Hello Configuration Example...................................................... 2-116
Figure 2-22 Establishing an MPLS TE End-to-End Path Protection....................... 2-123
Figure 2-23 Loose Node Re-optimization Configuration Instance .......................... 2-129
Figure 2-24 Instance of Automatic Bandwidth Regulation Configuration for the
MPLS TE ............................................................................................ 2-137
Figure 2-25 GR Configuration Example ................................................................ 2-145
II
SJ-20140731105308-012|2014-10-20 (R1.0)
Figures
Figure 2-26 FA Configuration Example ................................................................. 2-149

Figure 2-27 AR Configuration Example ................................................................. 2-154
Figure 2-28 TE Metric Configuration Example....................................................... 2-158
Figure 2-29 TE SRLG Configuration Example....................................................... 2-164
Figure 2-30 TE Tunnel Re-optimization Configuration Example ............................ 2-170
Figure 2-31 Topological Graph of the Instance for Tunnel Establishment with Only
TE HOTSTANDBY .............................................................................. 2-175
Figure 2-32 TE Tunnel WTR Configuration Instance ............................................. 2-180
Figure 2-33 Hard Preemption................................................................................ 2-186
Figure 2-34 Soft Preemption ................................................................................. 2-186
Figure 2-35 Instance of TE Tunnels Supporting Soft Preemption .......................... 2-188
Figure 2-36 Instance of Equal Load Sharing Configuration on the
TE-ECMP ........................................................................................... 2-199
Figure 2-37 TE Affinity Configuration Instance ...................................................... 2-203
Figure 2-38 Configuration Instance for Binding Interfaces Supporting TE
Bandwidth Reservation ....................................................................... 2-215
Figure 2-39 Instance for Resource Reservation Configuration on the
RSVP-TE ............................................................................................ 2-221
Figure 3-1 MPLS OAM Configuration Example ......................................................... 3-4
Figure 4-1 MAM ........................................................................................................ 4-2
Figure 4-2 RDM ........................................................................................................ 4-3
Figure 5-1 Structure of Unidirectional 1+1 Linear Protection Switching ..................... 5-3
Figure 5-2 Unidirectional 1+1 Linear Protection Switching (Signal Failure) ................ 5-4
Figure 5-3 Unidirectional 1:1 Linear Protection Switching (Expressed in Single
Direction) ................................................................................................ 5-5
Figure 5-4 Unidirectional 1:1 Protection Switching (Primary Tunnel Z-A
Failure) ................................................................................................... 5-6
Figure 5-5 Tunnel Protection Group Configuration Example...................................... 5-9
Figure 6-1 Working Flow of the Revertive Mode........................................................ 6-2
Figure 6-2 Working Flow of the Non-Revertive Mode ................................................ 6-4
Figure 6-3 Tunnel Protection Group Application ........................................................ 6-5
Figure 6-4 PW Protection Group Application ............................................................. 6-5
Figure 6-5 APS Configuration Example (Tunnel Protection Group) ......................... 6-10
Figure 6-6 APS Configuration Example (PW Protection Group) .............................. 6-16
III
SJ-20140731105308-012|2014-10-20 (R1.0)
Figures
IV
SJ-20140731105308-012|2014-10-20 (R1.0)
Glossary
ABR
- Area Border Router
AN
- Access Network
APS
- Automatic Protection Switching
AR
- Application Response
ASBR
- Autonomous System Boundary Router
ATM
- Asynchronous Transfer Mode
BDI
- Backward Defect Indication
BGP
- Border Gateway Protocol
CR-LDP
- Constrained Route - Label Distribution Protocol
CR-LSP
- Constraint-based Routing Label Switched Path
CSPF
- Constrained Shortest Path First
CV
- Connectivity Verification
CoS
- Class of Service
DNR
- Do-Not-Revert
DU
- Downstream Unsolicited
DoD
- Downstream-on-Demand
ECMP
- Equal-Cost Multi-Path routing
V
SJ-20140731105308-012|2014-10-20 (R1.0)
FA
- Forwarding Adjacency
FDI
- Forward Defect Indication
FEC
- Forwarding Equivalence Class
FFD
- Fast Failure Detection
FR
- Frame Relay
FRR
- Fast Reroute
GR
- Graceful Restart
GTSM
- Group Traffic State Machine
IETF
- Internet Engineering Task Force
IGP
- Interior Gateway Protocol
IP
- Internet Protocol
IPX
- Internetwork Packet Exchange protocol
IS-IS
- Intermediate System-to-Intermediate System
L2VPN
- Layer 2 Virtual Private Network
L3VPN
- Layer 3 Virtual Private Network
LAN
- Local Area Network
LDP
- Label Distribution Protocol
LER
- Label Edge Router
LIB
- Label Information Base
VI
SJ-20140731105308-012|2014-10-20 (R1.0)
Glossary
LSA
- Link State Advertisement
LSP
- Label Switched Path
LSR
- Label Switch Router
LUB
- Least Upper Bound
MBB
- Make Before Break
MML
- Man Machine Language
MP
- Merge Point
MP-BGP
- Multiprotocol BGP
MPLS
- Multiprotocol Label Switching
NCP
- Network Control Protocol
NE
- Network Element
NPE
- Network Provider Edge
NR
- No Request
OAM
- Operation, Administration and Maintenance
OSPF
- Open Shortest Path First
PE
- Provider Edge
PLR
- Point of Local Repair
PPP
- Point to Point Protocol
PW
- Pseudo Wire
VII
SJ-20140731105308-012|2014-10-20 (R1.0)
QoS
- Quality of Service
RSVP
- Resource Reservation Protocol
RSVP-TE
- Resource Reservation Protocol - Traffic Engineering
SD
- Signal Degrade
SF
- Signal Failure
TCP
- Transmission Control Protocol
TE
- Traffic Engineering
TP
- Transport Protocol
TTL
- Time To Live
UDP
- User Datagram Protocol
UPE
- User-End PE
VC
- Virtual Channel
VCI
- Virtual Channel Identifier
VP
- Virtual Path
VPI
- Virtual Path Identifier
VPN
- Virtual Private Network
VRF
- Virtual Route Forwarding
VoIP
- Voice over Internet Protocol
WTR
- Wait to Restore Time
VIII
SJ-20140731105308-012|2014-10-20 (R1.0)

SJ-20140731105308-012-ZXR10 M6000-S (V3.00.10) Carrier-Class Router Configuration Guide (MPLS) - 608087

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SJ-20140731105308-012-ZXR10 M6000-S (V3.00.10) Carrier-Class Router Configuration Guide (MPLS) - 608087

Uploaded by

Copyright:

Available Formats

ZXR10 M6000-S

Configuration Guide (MPLS)

Additionally, the contents of this document are protected by

contractual confidentiality obligations.

Serial Number: SJ-20140731105308-012

ZTE Proprietary and Confidential

Chapter 2 MPLS TE Configuration............................................................ 2-1

ZTE Proprietary and Confidential

2.2 TE Summary Refresh Introduction..................................................................... 2-24

ZTE Proprietary and Confidential

2.11.1 Introduction to Automatic Bandwidth Regulation Function of the MPLS

ZTE Proprietary and Confidential

2.20.1 TE Tunnels Supporting Soft-Preemption ..............................................2-185

Chapter 3 MPLS OAM Configuration ........................................................ 3-1

Chapter 4 Static Tunnel Configuration ..................................................... 4-1

ZTE Proprietary and Confidential

Chapter 5 Tunnel Protection Group Configuration ................................. 5-1

Chapter 6 APS Configuration .................................................................... 6-1

ZTE Proprietary and Confidential

This page intentionally left blank.

ZTE Proprietary and Confidential

About This Manual

Network planning engineers

What Is in This Manual

Describes the MPLS principle, configuration commands and

Describes the MPLS TE-related principle, configuration commands

and configuration examples.

Chapter 3, MPLS OAM

Describes the MPLS OAM principles, configuration commands and

Chapter 4, Static Tunnel

Describes the Static Tunnel principle, configuration commands and

Chapter 5, Tunnel Protection

Describes the principles for tunnel protection group, configuration

commands and configuration examples.

Chapter 6, APS Configuration

Describes the APS principles, configuration commands and

ZTE Proprietary and Confidential

Separates individual parameter in series of parameters.

ZTE Proprietary and Confidential

1.1 MPLS Overview

ZTE Proprietary and Confidential

ZXR10 M6000-S Configuration Guide (MPLS)

Traditional IP forwarding has the following characteristics:

ATM Forwarding Characteristic

ZTE Proprietary and Confidential

Chapter 1 MPLS Configuration

Figure 1-2 ATM Forwarding

As the implementation of ATM is complicated and expensive and the development of

MPLS Forwarding Characteristic

ZTE Proprietary and Confidential

ZXR10 M6000-S Configuration Guide (MPLS)

Figure 1-3 Position of MPLS

MPLS provides connection-orientated services for IP network.

MPLS Brief Principles

ZTE Proprietary and Confidential

Chapter 1 MPLS Configuration

1.2 MPLS Term

ZTE Proprietary and Confidential

ZXR10 M6000-S Configuration Guide (MPLS)

ZTE Proprietary and Confidential

Chapter 1 MPLS Configuration

LSR, LER, LSP and LDP

Label Switched Router (LSR)